Fix #382: cache-class-by-mutability law + guard #389
No reviewers
Labels
No labels
actions
bug
cli
duplicate
enhancement
fork
forum
git storage
help wanted
insights
invalid
issues
moderation
oidc
ownership transfer
packages
pr/merge protection rules
projects
pull requests
question
releases
sponsorships
tags
webhooks
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
crueber/walhub!389
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/issue-382"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Supersedes #259 systemic remainder (after #381/#384/#385 merged).
Law: addressability does not decide the cache class — mutability does (07_api.md section 4, DEVIATIONS.md D-API-3). SWR's stale-serve window is only safe for content whose staleness is bounded by ref movement; user-mutable GETs revalidate every read (version ETag keeps 304 economics).
What changed:
internal/cachepolicy— the five header values + rule doc +Checkguard (SWR + version-ETag fails). api + issues/social/releases/pulls/identity alias it; zero literal stragglers.cacheclass_test.gocontract: every served cacheable GET pinned to its exact class +Checkper pair +ExposedTemplatescoverage (row or explicit mutation-only set). Break-verified: summary flipped to SWR goes red, revert goes green.Verification: gofmt/vet clean; -race green on all 7 touched packages (cachepolicy, api, issues, social, releases, pulls, identity); coverage cachepolicy 100.0%, api 95.3%, issues 96.3%, social 99.5%, releases 99.8%, pulls 97.7%, identity 95.6% (all at/above the 95% gate). No new deps, no client changes, git-content headers byte-identical.