standards: verify claims about deployed behavior against the running system, never infer them from config

Problem

Config files declare intent. Only the running system declares behavior. Reviews, comments, and PR bodies routinely assert the second while having checked the first, and the assertion reads as authoritative because it cites a real file.

A single session on TimZander/AudioClassifier produced five wrong claims this way, from five different authors including two independent review agents and the reviewer who was actively warning everyone else about it.

Evidence

pwa/_headers declares /sw.js: no-cache. The deployed site serves max-age=14400 — a Cloudflare zone in front of the origin rewrites it. _headers was correct and applied; the site still did something else. From that one gap:

Each took one curl to settle. Nobody ran it, because the config file looked like the answer.

The same shape appeared in tests: a smoke test asserted deployed Cache-Control and passed against a deploy with every file deleted, because the edge derives the header from the URL, not the file. It was "mutation-tested" — but only the expectations were mutated, never the deployment.

Why documentation of the config is not a substitute

The config was accurate. The trap isn't stale config — it's that config is one input to a stack (CDN, zone settings, platform defaults, dashboard toggles) whose output nobody had observed. The zone rewrite lives in a dashboard: invisible to code review, invisible to grep, and it silently defeated a documented design.

Proposed — add to standards/CLAUDE.md

Claims about deployed behavior must be measured, not derived. A config file states intent; the deployed system states behavior, and the two diverge through CDNs, zone settings, platform defaults, and dashboard toggles that never appear in the repo.

Before asserting how a deployed system behaves — in a review, a comment, a PR body, or an issue:

• Observe it. curl -I the real URL, run the real client, drive the real flow. One request usually settles what an hour of reasoning cannot.
• Compare layers when one exists. Origin vs CDN vs custom domain frequently disagree; measuring only the one you can see proves nothing about the one users hit.
• Say which you did. "Verified on prod" must mean a command was run. If you reasoned it out, write "inferred, not measured" — an explicit inference is useful; an inference dressed as a measurement is worse than silence.
• Absence of config is not evidence of behavior. "There is no 404.html, therefore it 404s" is a guess about a platform default.

When a claim is load-bearing enough to argue about, it is load-bearing enough to assert in CI against the deployed artifact.

Related: /deep-review should enforce this

The deep-review skill produced one of the false claims above and marked it ✅ verified. Its Step 12 self-check covers formatting and severity coverage but never asks whether a runtime claim was observed or derived.

Suggested addition to the skill's self-check:

Measured vs inferred. For every finding or ✅ asserting how the deployed system behaves (headers, status codes, caching, redirects, runtime config), confirm you ran a command and can paste the output. If you derived it from a config file or the absence of one, either measure it now or label it explicitly as unverified.

Acceptance criteria

• standards/CLAUDE.md carries the rule above, in or beside Troubleshooting Failures (which already says "state your confidence level" — this makes it concrete for deployed systems).
• The distinction between measured and inferred is required vocabulary in reviews, not optional.
• plugins/'s deep-review self-check gains the measured-vs-inferred step.
• The rule names the specific failure: absence of config is not evidence of behavior.

Start with standards/CLAUDE.md, especially Troubleshooting Failures, and then inspect the deep-review skill under plugins/. Compare both locations with the proposed measured-vs-inferred guidance and acceptance criteria. Done means the rule, required vocabulary, self-check step, and absence-of-config warning are present in both relevant areas.