@am_shork/attest 0.10.0 → 0.11.0

package/CHANGELOG.md

@@ -13,10 +13,383 @@ input, removes/renames a public API or `--json` field, or changes a default
 runtime behavior an existing invocation relies on — diagnostic message text is
 not API.
 
+**A narrowing that closes a security hole is breaking by that definition, and
+takes the bump that definition gives it — including a major.** There is no
+carve-out for it and no flag. The two alternatives were priced and both cost
+more than the version number: an exemption needs a test for what counts as a
+security narrowing, and nothing here can hold a prose rule to one, so the label
+would be available to every inconvenient narrowing and judged by the person
+making it. Shipping the new refusal behind an opt-in that defaults off is worse
+for the case it is meant to serve — the four commands documented as safe on an
+untrusted fork MR are the ones a reviewer runs on a file they have not read, and
+a default that keeps answering wrong unless the reviewer knows to pass a flag
+has not been fixed.
+
+*What that costs is stated rather than hidden.* Under 0.x it costs nothing: the
+same fix is a minor either way, which is why this could go undecided for so
+long. Under 1.0 it is a major on whatever schedule a hole is found — the
+`callsAuthoringFn` binding fix, the fifth breaking commit in this project's
+history, would have been a 2.0 twenty-five days after a 1.0 cut at the fourth.
+The pressure that creates lands on the version number, and the failure it
+invites is the other one: a fix weakened until it fits a bump somebody
+preferred. A narrowing that ships smaller than the defect it closes is what this
+paragraph exists to make visible.
+
+## [0.11.0] - 2026-08-28
+
+### Added
+
+- **`examples/judgement-table/` — the enforcement half of the intent-quality
+  method, as one runnable file with no columns.** `intent-quality.md` has told
+  an adopter to build a judgement table since `[0.9.2]` shipped `/inspect`, and
+  the path to producing one was five voluntary steps with a scaffold at none of
+  them: a row in a document table, a 214-line page, a hand pass over four
+  questions, then writing the two *mechanical* properties from a prose
+  description. The last of those is the step that did not need to be voluntary.
+  Completeness and rot-binding do not depend on what the adopter decided to
+  measure — their content is fixed — so they are the half where a copy is not an
+  echo, and the four judgement columns stay withheld for the reason `[0.9.2]`
+  gave: a second table built by copying ours is evidence about nothing.
+
+  **The columns are absent by construction rather than left blank.**
+  `Judgement` ships one optional `pin` — the anchor rot-binding needs, holding a
+  scenario name rather than a judgement about one — and adding a required field
+  to it makes **every existing row fail to compile**, measured rather than
+  claimed: one added field, `TS2741` on both rows. So the type does at author
+  time what the completeness assertion does at run time, and a row cannot be
+  added without a decision.
+
+  **It runs in the default suite, and that is the point rather than a detail.**
+  `pre-commit-check` §6 already records that the three usage samples on
+  `intent-quality.md` are consumer usage of the public API that no gate reaches;
+  a fourth copy of them in a directory that *looks* executable would be worse
+  than a fenced block, not better. So `vitest.config.ts` includes
+  `examples/**/*.spec.ts`, the specifier `@am_shork/attest/inspect` is aliased to
+  source there and in `tsconfig.typecheck.json`, and both assertions were shown
+  to bite before this was called done — a third requirement added to the sample
+  fails completeness with `[ 'EX-3' ]`, and renaming the pinned scenario fails
+  rot-binding by name. What the alias deliberately does not check is that the
+  specifier resolves in an installed package; `tests/consumer.spec.ts` owns that
+  against a real `npm install`, and the two together are the whole claim.
+
+  A third assertion is in the skeleton that is in neither the page nor this
+  entry's proposal: `expect(issues).toEqual([])`, **before** the other two. A
+  registry file that will not read statically contributes nothing to `registry`,
+  so an unread file is indistinguishable from a project with fewer requirements
+  and both completeness directions pass over it. It was not written from
+  reasoning — an invalid mutation during the bite test produced exactly that
+  state, `registry: {}` with one `registry-invalid` issue, and the guard is what
+  caught it.
+
+  *What it cost elsewhere, because it is the part that does not announce
+  itself.* The sample project is a registry, and `tests/intent-rule-candidates.spec.ts`
+  walks every `*.reqs.ts` in the tree — so the corpus moved **95 → 97** and the
+  `compound-requirement` snapshot was re-read rather than re-baselined:
+  `compound`, `correct` and `missed` are all unchanged, so no rate quoted
+  anywhere moved and only the denominator did. Those two ids are deliberately
+  dull, which is a biased sample, and it is admitted in the snapshot's comment
+  rather than held out — one example directory is one adapter, and a hold-out is
+  a seam this repository does not buy until something varies across it.
+
+- **This repository now carries the workflow document it ships (`ATX-84`).**
+  `attest init` has written `.claude/skills/attest/SKILL.md` since 0.6.0, and this
+  repository had never run it: `.claude/skills/` held three hand-written skills and
+  no `attest/`, so the workflow half was reachable here only by opening
+  `src/core/skill.ts` — the exact gap `ATX-27` exists to close, open in the project
+  that ships the fix. Nothing could report it, because an absent file is
+  indistinguishable from a repository that has not adopted Attest. `.gitattributes`
+  has named the file among the generated files it pins since `fcd6140`, a sentence
+  false on the day it was written.
+
+  The requirement holds the committed file byte-identical to `skillContent()`, so
+  editing the workflow text turns `attest verify self` red until `attest init` is
+  re-run. That is deliberately *not* the freshness gate `src/core/skill.ts` argues
+  against shipping: that argument is about adopters, whose copy goes stale only at
+  an upgrade and whose every resulting mistake is a diagnostic carrying a fix hint.
+  This is the one place where `skillContent()` changes while the file exists, so
+  staleness is an ordinary edit rather than an upgrade event, and the gate costs one
+  string comparison. Byte equality rather than `ATX-29`'s document comparison for
+  the same reason the distinction runs the other way for `render --check`: that gate
+  runs in repositories where Attest does not own `.gitattributes`, this one only
+  here, where `eol=lf` is committed.
+
+  No engine behaviour changes. The document is unchanged, `init` is unchanged, and
+  nothing an adopter runs is affected.
+
+### Changed
+
+- **`delta()` no longer offers the requirements it adds under `added`, because
+  that was the one spelling stage 1 could not tell from the right one
+  (`ATX-85`).** `delta()` returns the delta *and* the registry of what it
+  proposes, so `d.added['AUTH-7'].params.x` and `d['AUTH-7'].params.x` are both
+  correct while a change is being authored — and only the second survives
+  `--apply`, which repoints the spec's import at the merged registry, and a
+  registry has no `added`. Nothing in the pipeline could separate them: the
+  archive gate runs *before* the rename, so the spec it graded is not the spec
+  the merge commits; `check` executes nothing, so it never evaluates the
+  accessor; and the compiler is satisfied on either side because it only ever
+  sees whichever half is on disk. The failure arrived one command later as a
+  `spec-load-failed` naming the file and not the cause.
+
+  **The guidance already existed and did not prevent it, which is why this is a
+  type and not a warning.** `registry.ts` documents the intended expression and
+  the rejected one on the function itself, and the document `init` writes shows
+  the by-id form in its worked example; the reach-through was written anyway, by
+  the author of the workflow tooling, on the first change this repository put
+  through its own flow. The alternative priced against it was a `check`
+  WARNING — which would have had to be a warning, since enumerating what a
+  change adds is legitimate, and a warning is exactly the strength that already
+  failed. `DefinedDelta` withholds the key instead: no diagnostic, no roster
+  entry, no runtime cost.
+
+  **`added?: never` rather than a bare `Omit`, and the difference is nine call
+  sites.** `RegistryDelta`'s four fields are all optional, so an added-only delta
+  with `added` removed shares *no* property with it and TypeScript's weak-type
+  check refuses `applyDelta(base, delta({ added: … }))` outright — measured at 11
+  errors, of which 9 are that shape and every one correct. An optional `never`
+  restores the overlap and still refuses the read, past both escape hatches:
+  `d.added!` and `d.added?.[…]` bottom out in `never`, and only an explicit
+  `as any` compiles. That last property is the whole reason this beats the
+  WARNING, so it is pinned in `tests/delta-types.spec-d.ts` rather than left to
+  hold by luck — a type has no runtime footprint, so a regression here would
+  otherwise ship green.
+
+  **Breaking, and it takes the bump this file's Versioning section gives it.** A
+  stage-1 spec reading through `added` stops compiling. The type also now
+  deliberately understates its own value — `withProposedRequirements` still
+  spreads `added`, and `applyDelta` and the loader still read it through
+  `RegistryDelta` — so what is withheld is the authoring surface and not the
+  data; `self/registry.spec.ts` keeps asserting exactly that, through a cast that
+  is itself the assertion.
+
+  *Re-measured before implementing, per `How an entry is re-measured`, and the
+  filed figures reproduced exactly* — 11 errors in the same two kinds, 11 → 2
+  under the variant, `typecheck` clean throughout, all three escape-hatch results
+  as recorded. **What the re-measure added was a surface the entry had not
+  counted, and it falsified this requirement's first draft before it shipped.**
+  `modified`, `removed` and `renamed` vanish at the merge too, and reading any of
+  them compiles on both sides — so the statement first drafted for `ATX-85`, that
+  withholding `added` leaves the by-id read "the only expression that resolves",
+  was false. They are left readable on purpose: none has a by-id equivalent, so
+  there is no correct spelling to redirect an author to, and a spec reading one
+  is reading delta-only data rather than misspelling a right thing. The narrowed
+  statement claims only what the refusal actually buys.
+
+  *And the exposure claim was one notch too wide.* The entry recorded the window
+  between `--apply` and the next `verify` as the whole exposure. In this
+  repository it is not: post-merge, reading through any of the four fields fails
+  to compile under `noUncheckedIndexedAccess`, so `typecheck:all` bounds it. The
+  unbounded form is an adopter's, whose spec files need be in no `tsc` project at
+  all — which is the case the refusal is for.
+
+  *Two things this change made the existing counter-pressure say.* The judgement
+  tables refused the new id until it carried a hand-judged row, which is that
+  mechanism working on its own author rather than on a hypothetical adopter — and
+  the corpus moved 97 → 98 with no rate disturbed. And `divergent-param` churned
+  its `field` key a **fourth** time — `ATX-85`'s `added` joining ATX-20, ATX-82
+  and ATX-83 — changing no verdict again, which is one more measurement for the
+  entry recording that this rule keys on the evidence it discards.
+
+### Security
+
+- **The static reader matched the authoring call by spelling, so a file could
+  shadow `defineRequirements` and hand the two readers different registries.**
+  `callsAuthoringFn` accepted any identifier named `defineRequirements` — the
+  bare name was added unconditionally as a fallback for a global or a harness —
+  and any property access whose *last* segment was that name. So a
+  `*.reqs.ts` opening with `const defineRequirements = (r) => ({ ...r,
+  'ADMIN-1': … })`, or with a local object carrying a method of that name, was
+  read by parsing it as the literal argument in front of the call, while the
+  evaluator answered with whatever that function returned.
+
+  Not a refusal but a **wrong answer**, and pointed at under-reporting: `check`
+  called the registry covered, `cover` counted rows that were not the rows, and
+  `render` wrote a document with an id missing from it. The reach is what makes
+  it worth a section — `check`, `cover`, `render` and `status` are the commands
+  documented as safe on an untrusted fork MR *because they execute nothing*
+  (`ATX-16`), so they are exactly the ones a reviewer runs on a file they have
+  not read, and the registry they report is the one nothing else will mention.
+  Two readers of one file disagreeing is the condition the differential suite
+  exists to prevent (design §5.2), and it could not have caught this: every
+  registry it runs over calls the real function.
+
+  The rule is now about the **binding** rather than the spelling. An import
+  binding is trusted, a name the file never binds is trusted — that is what the
+  bare-name fallback has always been for — and a `const` / `let` / `var` /
+  `function` / `class` in the file itself is not, whether the callee is that
+  name or an object property reached through it. A file that contradicts itself
+  becomes `registry-not-static`, with `--eval` named as the way back, which is
+  `ATX-17` unchanged rather than a new promise.
+
+  **What this still does not see is the module graph, and it is not written
+  to.** `import { defineRequirements } from './wrapper.js'` binds the name by an
+  import and is accepted; what that module exports is not a question the source
+  text of *this* file answers, and resolving it would mean reading and then
+  trusting another file, which is the evaluator's job. The line drawn is what
+  the file contradicts about itself.
+
+  Rejects input that was previously accepted, so it is breaking under this
+  project's 0.x rule — though the shapes it rejects are ones no working registry
+  has: the four accepted spellings (the import, an alias, a namespace or default
+  import's property, and the bare name) all still read, and each is pinned.
+
+- **`repointImport` wrote back at offsets taken from a source it never checked
+  compiles.** `ATX-69` states that a source that does not compile must be
+  refused rather than read out of whatever the parser recovered, and names the
+  three readers that open with `createSourceFile`. This was the fourth site and
+  the only one that *writes*: `--apply` repoints a proposed spec's import of the
+  delta at the registry, and it opened the compiler itself, so it asked nobody.
+  `ts.createSourceFile` recovers — a half-saved spec still yields an import
+  declaration and a set of offsets — and those offsets were then written over
+  the bytes of a `*.spec.ts` the user cannot regenerate.
+
+  Unreachable through the command today, because the gate refuses a spec it
+  could not parse before a merge starts, and fixed for that reason rather than
+  in spite of it: a defence that holds only because something upstream holds is
+  not a defence, which is the standard `keySource` in the same file is written
+  to. A source that does not compile now comes back unchanged, so `applyMerge`
+  — which writes only when the text moved — renames the spec with the import it
+  already had, and a re-run finds and reports that state instead of a file
+  rewritten at offsets nobody can trust.
+
+### Documentation
+
+- **`## Versioning` now says what a security narrowing costs a consumer, which
+  was undefined and which 0.x was the only reason nobody had to ask.** The
+  definition at the head of this file counts *rejecting previously-valid input*
+  as breaking and says nothing about security, so under 0.x the question was
+  invisible: the same fix is a minor either way. It stopped being hypothetical in
+  the same week it was measured — the `callsAuthoringFn` binding fix below is
+  breaking precisely *because* it narrows what a static reader accepts, and it
+  closes a wrong-answer hole in the four commands documented as safe to run on an
+  untrusted fork MR.
+
+  **Decided: such a fix takes the bump the existing definition gives it,
+  including a major.** The three candidate answers are not equivalent and only
+  one needed no new machinery. A carve-out naming security narrowings as exempt
+  requires a test for what counts as one, and this repository has already
+  rejected that shape under another name — *Countable obligations*, killed on the
+  argument that **nothing can force the count to be true**; a label nothing can
+  hold is available to every inconvenient narrowing and judged by the person
+  making it. Reaching the same end additively — the new refusal behind a flag,
+  defaulting off until the next major — is the only answer that costs the
+  consumer nothing, and it is disqualified by the case it would have to serve
+  first: a default that keeps answering wrong unless a reviewer knows to pass a
+  flag has not fixed a hole in the commands a reviewer runs on a file they have
+  not read.
+
+  *What it is not.* Not a vulnerability-disclosure policy and not a security
+  section for the README — one paragraph in `## Versioning`, in the vocabulary
+  that section already uses. And it was needed either way: if 1.0 is never cut
+  the paragraph documents a real property of the tool, and if it is, the
+  paragraph is a precondition, because a 1.0 without it promises something whose
+  price nobody has computed. That is why this could be settled while the 1.0
+  entry below stays open — it is decidable from this repository alone, which is
+  the property that entry is missing.
+
+- **`intent-quality.md` tells people to build on `/inspect` and never said
+  whether the shapes move.** `inspect.ts` exports five of them and the page
+  carries three samples destructuring them; `SCHEMA_VERSION` governs the `--json`
+  envelope and governs none of these. **The policy was not missing — its
+  statement was.** The Versioning section already binds them: removing or
+  renaming a public API is breaking, and under 0.x that is the minor bump. The
+  gap is that the reader this export was written for arrives through a method
+  page reached from the README's document table, and nothing on that path said
+  so.
+
+  **Which of two sentences to write was the whole decision, and it turned on
+  1.0.** Restating the existing promise reads as a stability guarantee and is the
+  honest summary of current policy; saying the shape may move before 1.0 is the
+  more useful warning and discourages exactly the adopter whose judgement table
+  would settle the schema entry below. With 1.0 not being cut for this release,
+  the second is the true one, and the cost is accepted rather than hidden: the
+  page now warns off the reader it most needs. It is written as a promise about
+  being *told* rather than about nothing changing, which is what the versioning
+  policy actually offers.
+
+- **`tests-red` told you to read the failures out of a report that does not carry
+  them.** The troubleshooting page said "`attest verify` gives you the same run
+  with the individual failures". It does not, and never did: `verify` and
+  `archive` both run the child suite with `quiet: true` because the CLI renders
+  its own report, so the whole output is one `tests-red` — no file, no scenario
+  name, no assertion. A reader following that sentence runs the command it names
+  and learns nothing new. Both languages now say to run the spec directly with
+  your own test command, and say why that is safe (a direct run writes nothing,
+  so it cannot touch `first-run.json`) and why it is not a verdict.
+
+  Found by dogfooding `ATX-84`: making the installed workflow document stale on
+  purpose, to check that the scenario's failure carries a fix hint, produced a
+  `verify self` output with no failure in it at all.
+
 ## [0.10.0] - 2026-08-22
 
 ### Changed
 
+- **`never-red` no longer claims to be a rule about writing the test first.**
+  Archived as `evidence-not-ordering`. The obligation is unchanged in every
+  observable way — same code, same scoping to the ids a change ADDs, same
+  blocking condition — and what moved is the registry's account of it, plus
+  every document that had turned "red before you implement" into the rule.
+
+  **The finding is that the ordering was never in the engine.** `keepOutcome` is
+  monotonic toward failure in one direction only: a recorded fail is permanent, a
+  recorded **pass is provisional**. Its motive was to let an author fix a
+  scenario that passed on its first run rather than hand-delete the evidence, but
+  the consequence is larger than the motive — a failure observed *after* the
+  implementation exists replaces the pass and satisfies `neverRedIssues`
+  identically to one observed before it. `self/red-record.spec.ts` has asserted
+  that at the record level since the mechanism shipped. So the gate has always
+  taken the evidence without caring when it was obtained, and three pieces of
+  prose said otherwise: `ATX-30`'s statement stopped at "its first run",
+  `ATX-31`'s rationale named running the gate first as *the* remedy, and the
+  workflow document said "Run this before you implement anything", which is
+  false as written.
+
+  **Removing it closes nothing, which is the argument for removing it.** A
+  stage-1 red can come from a typo in the spec, a missing import, or a fixture
+  that is not there yet — none of which is the requirement being unimplemented.
+  A failure observed before the implementation was therefore never *better*
+  evidence than one observed after it, only earlier. What the gate can actually
+  demand is that the scenario was seen to fail with its subject absent, and both
+  routes to that produce the same fact by the same command: run the gate before
+  writing the implementation, or remove the implementation, run the gate, and
+  restore it. The second route is now documented, with the `git stash` shape
+  spelled out in `troubleshooting.md`.
+
+  **Why this is worth the churn rather than a footnote.** The rule as written
+  declared malformed the one workflow that is becoming ordinary — intent,
+  scenario and implementation authored in one pass — and told those authors to
+  redo finished work in a different order to satisfy a gate that would have
+  accepted their evidence anyway. Separating the discipline (*an assertion has
+  to be able to fail*) from the habit (*write it first*) is what keeps the
+  strong half enforceable and stops the weak half from being enforced by
+  documentation the engine does not back.
+
+  `ATX-30` gains the clause the suite already checked — a recorded pass is
+  replaced by any later failure — and stops calling the record a snapshot of the
+  first run. `ATX-31` keeps its statement, which was always order-free, and
+  loses the ordering from its rationale. `ATX-48`, `ATX-53` and `ATX-56` carry a
+  one-phrase rationale patch each, because all three named it "the
+  red-before-implement gate" and a registry that contradicts itself is the drift
+  this tool exists to report. **`first-run.json` keeps its name**: archived
+  records already carry it, `inspectRedEvidence` reads them back, and spending
+  that to correct a word is the wrong trade — the sentence is where the meaning
+  lives.
+
+  One side effect worth reading: the reworded `ATX-30` statement moved from
+  `correct` to `missed` in the compound-requirement measurement, on both
+  variants, and the snapshot in `tests/intent-rule-candidates.spec.ts` carries
+  it. The requirement did not get less compound — the second clause became a
+  participle instead of a second `MUST` — so this is new evidence about *why*
+  that rule sees almost nothing, filed with the rejection it belongs to.
+
+  Two diagnostic messages are reworded and no `code` moves, so `schemaVersion`
+  does not move either; `Issue.message` is prose, and this is exactly the kind of
+  rewording that contract exists to allow. One assertion in `tests/skill.spec.ts`
+  moved from the phrase `must be red` to the code `never-red` — a test pinned to
+  a sentence the document is free to reword, which is the same mistake one level
+  down.
+
 - **The same mutation pass over the verdict and its evidence: 24 mutations of
   `gate.ts` and `red-record.ts`, 21 dead, and two of the three survivors closed.**
   Every step of `evaluateGate` dies when removed, including scoping
@@ -5894,69 +6267,10 @@ losing the argument would cost more than losing the task.
 **Where an entry went is recorded under the version that shipped it.** This
 section keeps no ledger of its own departures — one was maintained here by hand
 for several releases, and a count kept in prose with nothing to check it is a
-claim that goes wrong quietly. What is worth keeping is what the section learned
-about itself, which is three things.
-
-**An entry can sit here for releases on the strength of a figure nobody has
-checked.** The discipline aims at keeping the *argument*, not at re-testing the
-evidence under it, so the first act of building one is re-measuring what it
-claims rather than implementing what it proposes. That has paid three times:
-once killing an entry outright, when the spans it rested on turned out not to be
-spans; four times correcting an entry's own numbers or scope before a line of it
-was written — a call-site count that a regex had inflated, a cost filed as "a
-fixture per diagnostic" that the corpus put at one fixture, an injection whose
-payload turned out to need the target file's *own* quote character, which is the
-difference between escaping one quote and escaping the right one, and a fix
-filed as a map over `issues` that the report's own shape moved to the
-serialiser, four fields and one nesting level further out. **What a release costs its adopters is not known on the day it is cut**
-— several entries arrived from one adoption report, about shapes the tool made
-someone work around without ever erroring. And **the fixes with no observable
-symptom are worth batching**: individually none justifies a commit, together they
-cost about an hour, and they are the group no gate could have found, since having
-no symptom is the definition of what a gate cannot see.
-
-*The five entries this section carried before the ones below* were built and are
-recorded under `[0.8.0]`. The second is where this preamble's own
-discipline paid again: it went in on an entry whose headline type
-measurement — instantiations unchanged — was false on re-measure, and the
-re-measure is the only reason the release notes do not repeat it. The fourth is
-the other outcome the discipline has, and worth a line because the first three
-were all corrections: the `render --out` symlink measurement reproduced exactly
-as filed, down to the leaf being safe for the reason given. What re-measuring
-added was not a correction but a **surface the entry had not counted** —
-`--check` reads the same destination, so the same link makes a freshness gate
-date a document outside the project. Re-measuring an entry is therefore not only
-a test of the number it quotes; walking the code the claim is about is what
-shows the claim's own edges. The fifth is that lesson arriving where an entry
-had already named its own fix: the C1 measurement reproduced exactly, and the
-repair it proposed — a map over `issues` — was still the wrong half, because
-four more fields and a nested scenario name carry the same untrusted text and
-never pass the envelope. An entry that ends with a fix is the one least likely
-to have its fix re-examined, which is the case worth naming.
-
-*That has now happened twice, so it is a pattern rather than an incident.* The
-extensionless-import entry likewise reproduced exactly on its reported half and
-was wrong about its own repair — it recorded that the writing half needed
-nothing, and the writing half was guarded by a condition that was correct only
-while the reading half stayed broken. Both times the error had the same shape: an
-entry reasons about the code path it can see failing, and the repair makes a
-second path reachable that nobody has looked at because nothing could reach it.
-So the re-measure that matters is not "does the reported symptom reproduce" —
-both did, exactly — but **what does the proposed fix make reachable for the first
-time**.
-
-*The first time that question was asked in advance, it paid, and how it paid is
-worth a line because it is not what the two cases above would predict.* The
-`check` `empty-spec` entry — `[0.9.0]`, the third entry to reproduce exactly
-on its reported half — was not wrong about its own repair. Asking the question
-anyway found the defect one step to the side: the fix it proposed was correct,
-and the *obvious implementation of it* — make `check` agree with `verify` —
-would have copied a misdiagnosis `verify` had been emitting unnoticed, because
-the reference implementation an entry points at is not itself re-read. So the
-question generalises past the shape it was learned from. It is not only about a
-path the repair makes reachable; it is about **everything the repair would make
-`check` agree with**, and an entry that names the right fix can still be
-implemented wrongly by copying the half nobody has audited.
+claim that goes wrong quietly. What these sections have learned about
+re-measuring an entry before building it is at the foot of the file, under
+`How an entry is re-measured` — it applies to all three, and was filed here only
+because the first of it was written here.
 
 ## Under consideration
 
@@ -6009,12 +6323,20 @@ have to gather again.
   tautology.
   **The framing that probably resolves it: this is `never-red` wearing different
   clothes.** A tautological assertion is a scenario that cannot fail, which is
-  the exact defect `archive`'s red-before-implement gate exists to catch — and it
-  did catch two of them in this very repo (`CHECK-2`, `FOG-3`, both confirmed
+  the exact defect `archive`'s `never-red` gate exists to catch — and it did
+  catch two of them in this very repo (`CHECK-2`, `FOG-3`, both confirmed
   correct by the reporter). The reason it did not catch these is structural:
   **changing the value of an existing param goes through no gate at all.**
   `archive` gates a change; a param edit is not a change. That is a cleaner
   statement of the gap than "params can be tautological".
+  *Re-read against `evidence-not-ordering`, which separated that gate's
+  obligation from the ordering it used to be described by.* Nothing here moves:
+  the blocker was never that the observation had to be taken first, it is that a
+  param edit produces no change folder for any observation to be recorded
+  against. If anything the framing gets sharper — what `never-red` demands is
+  evidence that a scenario can fail, which is precisely what is missing for a
+  tautological assertion, and the reason it goes undemanded is still the absence
+  of a gate rather than the absence of a route to the evidence.
   **That observation is now its own entry at the foot of this section**, split
   out and measured on 2026-08-18, because it asks what happens when a value
   moves rather than whether an assertion is a real comparison, and neither
@@ -6164,7 +6486,7 @@ have to gather again.
   pass and separating them is the finding.
 
 - **Whether a requirement can ever be retired, and what it costs that none can.**
-  The registry is at **79 requirements and 221 scenarios, 2.80 each**, and
+  The registry is at **85 requirements and 240 scenarios, 2.82 each**, and
   every one is a permanent obligation: `uncovered-requirement` is an ERROR, so a
   requirement without a scenario cannot exist, and nothing ever removes one.
   `delta.removed` exists and `applyDelta` applies it, but `--apply` refuses to
@@ -6186,7 +6508,7 @@ have to gather again.
   requirement, where the scenario should move rather than go. Only the second is
   really about cost, and it is the one where deleting the intent to save the
   scenario inverts what the whole tool claims — that intent outlives its tests.
-  Nothing here is urgent at 69. It is filed now because the moment to write the
+  Nothing here is urgent at 85. It is filed now because the moment to write the
   argument down is while the reasoning is available, and because a project whose
   requirement count only rises should have decided in advance what would make
   one leave.
@@ -6222,6 +6544,56 @@ have to gather again.
   no longer supported is the acceleration. **Reopening on cost needs the ratio to
   move again**; reopening on the three meanings of "retire" needs none of these
   figures, and that is still the part nobody has separated.
+  *A fourth measurement, on 2026-08-28, and the cost half is now closed rather
+  than merely unsupported.* **85 requirements and 240 scenarios**, counted the
+  way `verify self` prints them: the ratio runs 2.56 → 2.78 → 2.80 → **2.82**.
+  Three consecutive readings within 0.05 of each other, across twenty-five days
+  and twenty-four requirements, are not a curve that is about to move. The
+  reopening condition this entry set itself has now failed to trigger twice, so
+  the cost argument is not waiting for evidence — it has been answered, in the
+  negative, by its own test. What survives untouched is the half that was never
+  about the ratio: the absolute total only rises, and permanence is the claim.
+
+  **The three meanings, separated — which is what the entry has been asking for
+  and needs none of the figures above.** They are not one question, and only one
+  of the three is open.
+
+  **(1) A requirement that turned out wrong.** Not a retirement at all, and the
+  mechanism already exists: the record of being wrong belongs in `Considered and
+  rejected`, which is what that section is, and removing the id is a manual
+  registry edit nobody has argued against. Nothing is missing here. Filing it
+  under "retire" was what made the question look bigger than it is.
+
+  **(2) A requirement still true but no longer worth a permanently-run
+  scenario.** The only one of the three that is about cost, and the only one with
+  no mechanism — and the sharpest thing this separation turned up is that the
+  tool has been *advertising* one. `uncovered-requirement` reads "Add a scenario,
+  or **mark it deferred**", and `deferred` appears nowhere else in `src/`: not a
+  field, not a flag, not a schema key. The troubleshooting section for that code
+  quotes the message as its symptom and then explains only the first half,
+  because there is no second half to explain. So the escape hatch this meaning
+  needs has been named in shipped output, and in the one place a reader looks
+  when they hit the error, since before anyone asked the question. That is a
+  defect in its own right — the message is prose and free to reword — but it is
+  recorded here rather than fixed there, because rewording it would delete the
+  only written trace that this affordance was ever intended, which is the thing
+  this entry exists to keep.
+
+  **(3) A requirement subsumed by a later one**, where the scenario should move
+  rather than go. That is a rename, and `--apply` refuses RENAMED outright, with
+  the reason recorded in `splice.ts` — deleting an entry has no smaller span to
+  fall back to. So it is blocked downstream of a refusal nobody has proposed
+  lifting, which is the *same* blocker the backlink-index entry above carries.
+  Two open entries now rest on that one refusal, which is worth knowing: it makes
+  lifting it a decision with two dependents rather than one, and neither of them
+  is the reason it exists.
+
+  *So the entry narrows to one meaning.* (1) is answered, (3) is somebody else's
+  blocker, and what is actually open is (2) — whether a requirement can stop
+  owing a permanently-run scenario while keeping its intent, which is the one
+  case where deleting the intent to save the scenario inverts what the whole tool
+  claims. Nothing here says it should be built; what changes is that the question
+  is now one question.
 
 - **Running `verify` over a subset of the scenarios, and what a partial run may
   be allowed to say.** `verify` is all-or-nothing and `check` executes nothing,
@@ -6256,8 +6628,8 @@ have to gather again.
   slow half is smaller, so the question is a selector's ergonomics rather than
   one project's gates; and a scored answer to whether a scope-carrying report can
   be stated in a way that a `--json` consumer written before it cannot misread.
-  **Measured on 2026-08-12, before building anything, per this section's
-  discipline. The second of those two is now answered, and the answer is a
+  **Measured on 2026-08-12, before building anything, per `How an entry is
+  re-measured`. The second of those two is now answered, and the answer is a
   refusal; the first blocker was wrong; and the whole feature turns out to be a
   different, much cheaper one.**
   *The cost claim reproduces on a second corpus.* `verify self`: the static half
@@ -6474,6 +6846,31 @@ have to gather again.
   §6 already records as the category no gate reaches: the page's three samples
   are unasserted today, and a fourth in a directory that looks executable would
   be worse than a fenced block, not better, unless something runs it.
+  **Built under `[Unreleased]`, and the second of those two blockers was the
+  buildable one.** `examples/judgement-table/` is in the default suite, the
+  specifier is aliased rather than relativised so the file stays copyable
+  verbatim, and both assertions were shown to fail before it was called done.
+  So the category `pre-commit-check` §6 names now has exactly one member that a
+  gate reaches, and the page's three prose samples are still not it.
+  *Two things the build found that the proposal did not contain.* A third
+  assertion — `issues` empty, before either of the other two — which is not a
+  refinement but a hole: an unread registry file and a smaller project are the
+  same value, and the two completeness directions pass over both. It was found
+  by an invalid mutation during the bite test rather than by reasoning, which is
+  `How an entry is re-measured`'s question about what a repair makes reachable,
+  arriving from the other end. And a **type-level** forcing move the runtime
+  assertion cannot make: a required field added to `Judgement` fails every
+  existing row at compile time, so the schema-shaped half of "a row cannot
+  arrive unjudged" costs one line and no engine rule. That is worth noting
+  against blocker **(1)** above, which is about freezing a `Judgement` type:
+  what shipped freezes nothing, because the type is in the adopter's copy.
+  **What is untouched is the first blocker, and it is now the only thing between
+  this entry and its evidence.** Whether an empty frame reads as an invitation
+  or as a form to fill in is still untested, and cannot be tested here — the
+  people who would answer it are the ones who have not arrived. What the build
+  changes is only that the five voluntary steps are now four, and the one
+  removed was the one with a fixed answer. If the next report is still nobody,
+  the scaffold was not what was missing, and that is worth knowing too.
 
 - **Prefix ownership is inferred rather than declared, and the cost arrives only
   when adoption succeeds.** Design §11 records that the id grammar has no level
@@ -6595,127 +6992,6 @@ have to gather again.
   looking at already being that page's subject, and this being a fifth of the
   same kind.
 
-- **`/inspect` returns five exported shapes and the page telling people to build
-  on them says nothing about whether they move.** Filed 2026-08-19 from a product
-  review of `[0.9.1]`–`[0.9.3]`. `inspect.ts` exports `Inspection`,
-  `ScenarioEvidence`, `EvidenceRow`, `ArchivedChangeRef` and
-  `RedEvidenceInspection`, and `intent-quality.md` carries three samples
-  destructuring them. `SCHEMA_VERSION` governs the `--json` envelope and nothing
-  governs these.
-  *The policy is not missing — its statement is.* The Versioning section at the
-  head of this file already binds them: removing or renaming a public API bumps
-  the minor, and under 0.x that is the breaking bump. So a reader who finds that
-  section is already told what they need. The gap is that the reader this export
-  was written for arrives through `intent-quality.md`, which is a method page
-  reached from the README's document table, and nothing on the path between the
-  two states it.
-  *Why it is worth a decision rather than a one-line edit.* The two candidate
-  sentences say opposite things to the person this needs. Restating the existing
-  promise reads as a stability guarantee and is the honest summary of current
-  policy; saying the shape may move before 1.0 is the more useful warning and
-  discourages exactly the adopter whose table would decide the judgement-schema
-  entry above. Which one is right depends on the 1.0 entry below, which is why
-  this is filed rather than fixed.
-  *One thing already measured, in the other direction.* `pre-commit-check` §6
-  records that changing what `/inspect` returns breaks three usage samples that
-  no gate can see. The internal awareness of this surface's fragility therefore
-  exists and is written down; the outward-facing half is what does not.
-
-- **The store worth retrieving is this file, not `archive/`, and no shape has
-  been proposed for either.** Filed 2026-08-19 from a product review of
-  `[0.9.1]`–`[0.9.3]`, and it is the OpenViking reading turned back on the
-  repository that did the reading. Everything that came out of it is about
-  `archive/`, and the entries are no longer counted here — the number was wrong
-  on the day it was written, was corrected on 2026-08-19, and was wrong again by
-  the next commit, when the precedence rule left for design §11. Three strikes on
-  one figure is the section's own preamble arriving in the first person: a count
-  kept in prose with nothing to check it goes wrong quietly, and the repair is to
-  stop keeping one rather than to keep fixing it. But `archive/` holds `first-run.json` — typed,
-  low-information, and now read — beside a `proposal.md` that in this repository
-  carries a link, for the reason `[0.9.3]` gives: `CLAUDE.md` makes this file the
-  single decision record. **So the store that actually holds decisions with their
-  evidence attached is `CHANGELOG.md`, at 7,100 lines with the three foot
-  sections past 1,700 of them,** and the property that makes it valuable — a
-  design evaluated, priced and killed, with the reasoning that killed it — is
-  exactly the property that makes it unreadable in one pass. It is append-only
-  with no retrieval, which is the shape the OpenViking reading was about.
-  *What an agent would actually consume is a composition, not a new store.*
-  Given an `ATX-n`: its statement and params, the scenarios covering it, the
-  first-run evidence for each, and the paths to the change that introduced it.
-  Four of the five are already computable — `inspectProject` answers two,
-  `inspectRedEvidence` the third and the archived refs the fourth — and the fifth,
-  the reasoning, is the one with no index and no key. That asymmetry is the
-  finding: the retrieval problem is not in the half that was just made readable.
-  *One thing to unmerge before deciding.* `[0.9.3]` settled a question against
-  the fifth static command, and it settled it correctly and on the right
-  grounds — `first-run.json` is JSON, and `ATX-16`'s subject is reading
-  TypeScript without evaluating it, so joining that roster would turn a security
-  promise into a list of commands that do not run the suite. But that is a
-  ruling about **roster membership**, and it is being carried as though it also
-  ruled on whether such a command should exist. Those are separate, and only the
-  first was argued.
-  *What blocks the decision, and what would cheaply unblock it.* No measurement
-  exists of whether a bundle like this changes what an agent does — the one datum
-  quoted in `[0.9.3]` measured demand to read the archive **as prose**, which is
-  a third question again. The proposal is therefore a probe and not a build,
-  per this section's own discipline of re-measuring before implementing: assemble
-  the bundle by hand for one requirement, run one real change against it, and
-  record whether it was used, ignored, or used wrongly. One session, and it
-  decides between a command, a skill surface, and nothing. Building any of the
-  three before that measurement is the order `divergent-param` was designed in
-  and the order this file has already paid for once.
-
-- **A stage-1 spec can read its params through `delta.added` instead of by id,
-  and the merge that repoints its import cannot repoint that.** Filed 2026-08-19
-  from the first change this repository put through its own `changes/` workflow,
-  where it was written by the author of the workflow's own tooling — which is
-  most of why it is worth an entry rather than a fix.
-  `delta()` returns the delta *and* the registry of what it adds
-  (`withProposedRequirements`), so `reqs['ATX-81'].params.field` reads a proposed
-  requirement before the merge and a merged one after it. That is the whole
-  reason merging a spec changes its import and nothing else. Reaching through
-  `added` — `d.added['ATX-81'].params.field` — is equally correct during stage 1
-  and throws the moment `--apply` repoints the specifier at the registry, because
-  a registry has no `added`.
-  **Nothing catches it, and the reason is structural rather than an oversight.**
-  The archive gate runs *before* the rename, so the spec it graded is not the
-  spec the merge commits; `check` executes nothing, so it never evaluates the
-  accessor; and the type checker is satisfied on both sides of the merge only
-  because it is run against whichever half is currently on disk. It surfaced at
-  the next `verify`, as `spec-load-failed` — a correct diagnosis of the symptom
-  that names the file and not the cause. The window between `--apply` and the
-  next `verify` is the whole exposure, and in a workflow that ends at `--apply`
-  it is unbounded.
-  **The guidance already exists and did not prevent it, which is the finding.**
-  `registry.ts`'s doc comment on `delta` states the intended expression and the
-  rejected one, in those terms, on the function itself; the document `init`
-  writes shows the by-id form in its worked example. So this is not a gap in what
-  is written. It is a case of the correct form and an incorrect one being
-  *indistinguishable at the moment of writing* — both compile, both pass, both go
-  red for the right reason — with the difference appearing one command later.
-  *Two shapes, and they point opposite ways, which is why this is filed rather
-  than fixed.* **(1)** A `check` diagnostic: `parser.ts` already walks property
-  accesses inside spec bodies to find `.params`, so finding `.added` on a binding
-  imported from a `requirements.delta` path is the same walk and the same file.
-  It has to be a WARNING, because enumerating what a change adds is a legitimate
-  thing for a spec to do, and a WARNING is exactly the strength that did not stop
-  the author here. **(2)** A type-level refusal: have `delta()` return a type
-  without `added`, so `typecheck:all` refuses it with no new diagnostic, no
-  roster entry and no runtime cost. `DefinedDelta<T> = T & ProposedRequirements<T>`
-  carries `added` because `T` does, so this means `Omit<T, 'added'>` — and that
-  breaks the evaluating loader, which hands the same default export to
-  `applyDelta` typed as `RegistryDelta`. Whether that break is real or just needs
-  the internal path to name a different type is **unmeasured, and is the first
-  thing to establish**; it decides between the two shapes rather than being a
-  detail of one.
-  *What blocks the decision:* frequency, and it is the same blocker the `open`
-  entry carried before it — one occurrence, in one repository, on the first
-  change ever run through the workflow. That is a report rather than a
-  hypothetical, which is more than most entries here start with, and it is still
-  n=1. What would settle it cheaply is the next change: if the by-id form is
-  written without prompting, the guidance is sufficient and this is an anecdote;
-  if the reach-through appears again, the two shapes above are worth pricing.
-
 - **Nothing is frozen, and the evidence this repository is waiting for requires
   somebody to build on something.** Filed 2026-08-19 from a product review of
   `[0.9.1]`–`[0.9.3]`. Three releases in five days each added public surface, and
@@ -6735,48 +7011,106 @@ have to gather again.
   on one adapter, which is the objection this repository raises against every
   other premature interface and does not get to waive for its own. And the
   release-notes discipline cuts both ways here: a 1.0 is a claim about what the
-  cost of adoption will be, and `Planned`'s own preamble records that **what a
-  release costs its adopters is not known on the day it is cut**. There is no
+  cost of adoption will be, and `How an entry is re-measured` records that **what
+  a release costs its adopters is not known on the day it is cut**. There is no
   measurement to date of anyone adopting either export.
 
-- **When one requirement carries several scenarios, some of those sets are
-  differential evidence and nothing in the model says which.** Prompted by an
-  external write-up (`columns.chicken-house.net`, 2025-11-10, "AI-First Testing
-  Workflow"), which ran one test case against a system's REST API and against its
-  web UI and found the empty-basket check implemented in the UI and absent from
-  the API. Neither run failed against its own expectation; the finding was that
-  two runs of the *same* case disagreed.
-
-  Attest already permits the arrangement — a `reqId` takes any number of
-  attesting scenarios, and `cover` asks only for ≥1. What it cannot see is the
-  difference between three scenarios covering three edges of one requirement and
-  three scenarios crossing three interfaces at the *same* edge. The second set
-  can be asserted to agree; the first cannot, and there is nothing to compare.
-  This repository runs the pattern on itself — `tests/static-registry.spec.ts`
-  asserts the two registry readers agree — so the structure is known to work
-  where the two adapters are known to be two adapters.
-
-  *What blocks it, in the order that decides it.* **The seam is unmeasured.** One
-  adapter is a hypothetical seam and two is a real one; nothing has been walked
-  to establish whether any adopted registry has a `reqId` whose scenarios
-  genuinely cross interfaces rather than covering one surface repeatedly. Until
-  that is counted this is a pattern observed in somebody else's codebase, and it
-  is cheap to count. **The fact is not in the model.** Which interface a scenario
-  crosses is recorded nowhere the engine reads, so supplying it means new
-  registry or spec surface — a per-scenario axis — paid for by every adopter
-  including all of the ones with a single interface, in the shape of a thing they
-  must learn not to write. Whatever carried it would also have to be a literal in
-  the AST, because `cover` executes nothing and that is not negotiable for it.
-  **There is no verdict to emit.** The engine cannot perform the comparison;
-  agreement between two runs is an assertion and assertions belong to the test.
-  The most it could report is that a requirement has scenarios on more than one
-  axis, which is information with no pass or fail attached — a new output
-  category rather than a new check. **And the prose alternative is untried.**
-  Apply the deletion test before the field: if the workflow document `init`
-  writes (§9) simply says that two scenarios crossing one requirement at
-  different interfaces should assert the same expectations, does the practice
-  happen anyway? If it does, the engine gained nothing and charged everyone a
-  field for it.
+  **Measured on 2026-08-28, before deciding anything. The one-adapter objection
+  splits rather than holds, and a prerequisite this entry does not name has
+  arrived on its own.**
+
+  *The surface has not been moving, which is not what "three releases in five
+  days each added public surface" suggests.* Each entry point's last change to
+  its exported shape, and how many releases have been cut since without touching
+  it:
+
+  | surface | last shape change | releases since |
+  |---|---|---|
+  | CLI commands and options | 2026-08-03 (`--apply`) | 12 |
+  | `.` — the index exports | 2026-07-26 | 19 |
+  | `./define` — public signatures | 2026-08-08 | 7 |
+  | `./inspect` | 2026-08-18 | 2 |
+
+  `src/index.ts` has had its export list edited in **three commits ever**, the
+  last of them five weeks ago. So "freezing on one adapter" is weak for the CLI
+  and `.` — nineteen and twelve releases of evidence that they have stopped
+  moving — and strong exactly where this entry puts it, on `./inspect`, which
+  has two releases, one adapter, and whose single post-shipping change was
+  additive. That argues for a line this entry does not currently offer:
+  **freeze what has stopped moving and explicitly do not freeze `./inspect`.**
+
+  *And the cost of any such line was demonstrated this week, unprompted.* The
+  Versioning section at the head of this file defines breaking to include
+  **rejecting previously-valid input**. There have been four breaking commits in
+  this project's history, the last on 2026-08-03 — and a fifth is sitting in
+  `[Unreleased]` as of 2026-08-28: the `callsAuthoringFn` binding fix, which is
+  breaking *because* it narrows what a static reader accepts, and which says so
+  about itself. Under 1.0 that is a **major** bump. A fix closing a wrong-answer
+  hole in the four commands documented as safe on an untrusted fork MR would
+  have had to ship as 2.0, twenty-five days after 1.0 — or not ship as written.
+
+  *So the decision has a prerequisite, and the prerequisite left this section.*
+  What a narrowing that closes a security hole costs a consumer is undefined,
+  and it is needed whether or not 1.0 is ever cut — so it is under `Planned`
+  above rather than here, where it would have been blocked on everything this
+  entry is blocked on. Until it exists a 1.0 would be promising something whose
+  price nobody has computed; what it does **not** do is unblock the rest of this
+  entry, which turns on evidence no measurement here can supply.
+
+  *What is still unmeasured is unchanged, and it is the whole of the rest.* No
+  adopter of either export, so the thing 1.0 is meant to buy — making "build
+  your own counter-pressure on our export" a reasonable ask — has no measurement
+  behind it in either direction. The `examples/` scaffold under `[Unreleased]`
+  is the other half of that ask and was the cheaper half. Whether the missing
+  half is the freeze, or was never the freeze, is what the next report answers.
+
+- **The intent layer is separable from the repository it describes, and the
+  verification layer is not — so a third party can audit intent and never
+  obtain a verdict.** Filed 2026-08-22 from a design evaluation of using Attest
+  as an external audit tool that touches none of the auditee's implementation.
+  The separability is already bought and is stronger than it looks: §2 requires
+  a registry to be a *literal*, no imported constant and no computed value, so
+  `*.reqs.ts` names nothing in the project it is about and is a file another
+  party could own outright. The four static commands execute none of the
+  auditee's code, which is the posture an auditor needs and is already the
+  documented reason for the split. The arrangement that follows is a two-party
+  contract with `check` as its interface: the auditing party writes the SHALL,
+  the developing party owes each id a scenario, and `uncovered-requirement` and
+  `orphan-test` are the two directions that contract can be broken in.
+
+  *What blocks it, in the order that decides it.* **The verdict half cannot
+  cross the boundary, and that is §1 rather than a gap.** `verify` and `archive`
+  run the suite, the suite's specs import the implementation, and the environment
+  those specs need is the auditee's — reachable only by trusting their
+  `--vitest-config`. So what a decoupled auditor can obtain is the readable
+  obligations and never `tests-red`, which is the same asymmetry `status` already
+  carries and states about itself. That would be tolerable if the static report
+  read as procedural, and it does not: an audit reader takes a full-coverage
+  `check` as a claim about behaviour, while §11 records that coverage is binary,
+  that an assertion can echo the param it is measuring, that shortening a
+  list-valued param silently removes cases, that a quantifier is covered only as
+  far as hand-written scenarios reach, and that two contradictory ids under
+  different prefixes both pass. **The mechanism assumes one tree.** `locate.ts`
+  scans a single project root, and mechanism 1 needs the spec to `import` the
+  registry, so the externally-owned file has to be physically in the tree before
+  any command runs — a checkout step, not a flag. Naming a registry outside the
+  root would be a second answer to where intent lives, which is the shape this
+  repository refuses elsewhere. **The flat ID space bills exactly here.** §11
+  already records that nothing allocates a prefix and that the cost arrives when
+  adoption succeeds; two parties sharing one registry *is* that case, and
+  `duplicate-prefix` can only report a collision after both files were read.
+  **And `--apply` writes into the other party's file.** The merge splices ADDED
+  requirements into the registry, so the one command that edits a file the user
+  cannot regenerate would be editing a document whose owner is not in the
+  repository. Nothing about that is unsafe; it is that the ownership the
+  arrangement exists to establish is the thing the merge step quietly crosses.
+
+  *What would settle it, and what it costs to try.* The whole arrangement is
+  derivable from the design and has been run by nobody, so this is n=0 and cheap
+  to move: the checkout-step form needs no engine change at all, and one
+  adopter running it would say whether the two-party report is read as procedural
+  or over-read as a behavioural claim. That is the measurement, and it is a
+  question about the reader rather than about the code.
 
 ## Considered and rejected
 
@@ -6788,6 +7122,198 @@ it sat between 0.2.0 and 0.1.7 for two releases, where standing still meant
 sinking one version deeper each time a release was cut above it, and a rejection
 filed under a version reads as belonging to it.
 
+### An id-keyed retrieval bundle over `archive/` and this file
+
+Proposed 2026-08-19 inside the entry now titled *The decisions worth retrieving
+are in this file*: given an `ATX-n`, assemble its statement and params, the
+scenarios covering it, the first-run evidence for each, and the paths to the
+change that introduced it — the reasoning being the fifth part and, as filed,
+"the one with no index and no key". The entry declined to build it and specified
+a probe instead: assemble the bundle by hand for one requirement, run one real
+change against it, and record whether it was used, ignored, or used wrongly.
+**One session, and it decides between a command, a skill surface, and nothing.**
+
+Run on 2026-08-28 on `ATX-79`, against the `examples/judgement-table/` change
+shipped in the same pass. **The answer is nothing.**
+
+**Four of the five parts came back in one script**, as the entry predicted:
+statement, params and `outOfScope` from `inspectProject`; three scenarios with
+their evidence states and four archived change refs from `inspectRedEvidence`.
+No new surface was needed to assemble it. A command would therefore be a wrapper
+over two functions that already ship, which is the shallow-module case rather
+than a retrieval mechanism.
+
+**The row that did the work is a plain field, and not the one this was about.**
+`outOfScope: ['judging the quality of what it reports', …]` settled the change's
+central design question — ship the enforcement, withhold the columns — and it
+has been a field of `inspectProject` since `[0.9.2]`. What the composition added
+was that it was *present at the moment of the decision*, which is a claim about
+assembly rather than about a missing store, and assembly is what a caller with
+two function calls already has.
+
+**The evidence half is structurally empty for most ids here.** All three rows
+came back `unarchived`, which is correct — `ATX-79` was written straight into
+the registry — and which `ATX-80` defines as **not a finding**. So for any
+brownfield id that quarter of the bundle carries nothing, and brownfield is most
+of this registry. The bundle's information content varies enormously by which id
+is asked about, which nothing in the proposal anticipated.
+
+**And the fifth part is not where the proposal placed it.** The reasoning *for a
+requirement* is keyed twice over: `rationale` is a field of `inspectProject`, so
+it was already part one, and design §10 carries the argument under a section
+number. What `CHANGELOG.md` contributed to this bundle was **two grep hits for
+`ATX-79`, neither of them about `ATX-79`** — one a parenthetical inside
+`[0.9.2]` about a different requirement's import closure, the other a false
+positive inside the tautology entry, where `ATX-79.subpath` appears as an
+example of a detector firing wrongly. Zero useful rows and two misleading ones.
+
+So what this rejects is not only the command but the **key**. A design that was
+evaluated and killed has no `ATX-n`, so an id-keyed index over the decision
+store returns the entries that were not rejected — the opposite of the content
+the original entry correctly identified as the valuable part. That half is not
+rejected and stays open above, without a key and without a proposed mechanism.
+
+*Labelled for what it is.* n=1, one requirement, one change, and the person who
+assembled the bundle is the person who made the change — so "was it used" is a
+self-report, and the honest reading is that one row was load-bearing and one
+quarter was empty by construction. That is a thin basis for building something
+and an adequate one for not building it, which is the asymmetry the probe was
+specified to exploit.
+
+### A retrieval mechanism over this file's decision sections
+
+Proposed inside *The decisions worth retrieving are in this file*, which stayed
+open on the grounds that **no key had been proposed, and that was the whole of
+the problem rather than a step before it**. The entry specified the inverse of
+the probe that killed the id-keyed bundle above: take an entry from this section
+that was re-proposed and caught here, and ask what somebody would have had to
+type to find it before proposing it again. One session, no build. It was run on
+2026-08-28 and it produced a key — which already exists, in this file, and is the
+reason nothing needs building.
+
+*The store is 24 entries, not 8,300 lines.* That is the measurement the entry's
+premise was missing. `Considered and rejected` holds **24 `###` entries over
+1,086 lines**, and every plausible search term a re-proposer would reach for
+narrows to a handful: `obligations` → 2 entries, `judge` → 5, `compound` → 2,
+`countable` → 1. Grep over one section already retrieves. An index would be a
+second copy of a table of contents the headings are.
+
+***And 23 of the 24 headings name the artifact or the mechanism*** — `zod/v4-mini`,
+`isSafeChangeName`, `typescript` as a peer dependency, a freshness gate on the
+file `init` writes, grouping `render`'s output by prefix. A proposer arrives
+holding the artifact they are about to touch, which is why the heading is the
+key: it is the one field written in the vocabulary the next person will have.
+
+*The exception is the finding.* The single heading that names a **problem**
+rather than an artifact — *Nothing resists a bloated requirement, and nothing
+resists a duplicated one* — is the entry that was re-proposed and caught, as the
+judgement-schema entry's blocker (2). The second documented catch, the quantifier
+detector reused as `quantifier-unjudged`, is filed under *An engine rule for a
+statement whose scenarios do not span its quantifier*, which is problem-shaped
+too. The one artifact-shaped heading anybody has been recorded checking against —
+*A committed snapshot of the params* — was found by its re-proposer unaided, and
+they said so in the entry. Four events, so this is a correlation and not a rate;
+what makes it worth recording is that it points at a rule with no mechanism
+behind it.
+
+*So what replaces the proposal is a sentence about headings, not a feature.* A
+rejection is filed under the name of the thing it declined to build. That is
+already true of 23 of 24 and needs enforcing by nobody, because it is what an
+author writing a heading naturally does when the thing has a name — the
+exception is the entry that declined **three** mechanisms at once and had no
+single artifact to name, which is the case to watch rather than a rule to state.
+
+*What the probe also confirmed, in passing, is the claim the entry rested on.*
+**15 of the 24 rejected entries carry no `ATX-n` at all**; the nine that do
+mention one as evidence inside an argument about something else. A design that
+was evaluated and killed has no id because nothing was built to carry one, so an
+id-keyed index retrieves precisely the entries that were *not* rejected. That
+half of the entry was right and is now measured rather than reasoned.
+
+*What is not solved, and it is next door.* `Under consideration` has no headings
+at all — its twelve entries are bullets whose first bolded sentence is the only
+handle — so the key found here exists for one of the three foot sections and not
+for the section most likely to be read before a proposal. Nothing was changed
+about that here: restructuring twelve open entries is a larger edit than the
+finding justifies, and the finding is only four events old.
+
+### A per-scenario axis recording which interface a scenario crosses
+
+Prompted by an external write-up (`columns.chicken-house.net`, 2025-11-10, "AI-First
+Testing Workflow"), which ran one test case against a system's REST API and
+against its web UI and found the empty-basket check implemented in the UI and
+absent from the API. Neither run failed against its own expectation; the finding
+was that two runs of the *same* case disagreed. Attest already permits the
+arrangement — a `reqId` takes any number of attesting scenarios — but cannot
+tell three scenarios covering three edges of one requirement from three
+scenarios crossing three interfaces at the *same* edge. The second set can be
+asserted to agree; the first has nothing to compare. The proposal was to put
+that fact in the model, as a per-scenario axis that would have to be a literal
+in the AST, because `cover` executes nothing.
+
+Filed 2026-08-22 with four blockers, and rejected on 2026-08-28. **The blocker
+that decides it needed no measurement, and the one that was measured came back
+at the floor.**
+
+**There is no verdict to emit, and that is fatal on its own.** The engine cannot
+perform the comparison: agreement between two runs is an assertion, and
+assertions belong to the test. The most any axis could report is that a
+requirement has scenarios on more than one of them — information with no pass or
+fail attached, a new output *category* rather than a new check. So the field
+would be a thing every adopter has to learn about, including all of the ones
+with a single interface, in exchange for a report that decides nothing. This
+holds whatever the frequency turns out to be, which is why it is stated first.
+
+**And the frequency, counted because the entry said it was cheap to count and it
+was.** Over `self/` through `inspectProject`: 84 requirements, all covered, **69
+carrying two or more scenarios**, of which 6 have scenarios in more than one
+spec file. Over the seventeen fixture projects: 15 ids, 6 multi-scenario, **0**
+cross-file. Cross-file is only a proxy — nothing records which interface a
+scenario crosses, which is the entry's own point — so all 6 were read by hand,
+and **exactly one is the shape**: `ATX-60`, whose statement says the `--json`
+`ok` and the human verdict printed beside it are decided by one predicate
+"never by a second spelling of that question", with `json.spec.ts` and
+`report.spec.ts` asserting the two surfaces separately.
+
+*How the other five fail is the useful half.* `ATX-14` and `ATX-63` pair the
+validator with the renderer, which is two **different obligations** of one
+requirement — one reports the bad placeholder, the other omits it — so there is
+nothing to compare. `ATX-15` is five edges of one ordering rule. `ATX-80` is one
+interface run against a fixture and against a change the suite really archived.
+`ATX-25` is the near-miss worth naming: `pipeline.spec.ts` checks the producer
+and `json.spec.ts` the serialised report, which is one pipeline observed at two
+**layers** — downstream-coupled, so they cannot independently disagree, and
+independence is the property differential evidence is made of.
+
+*The finding that carries more than the count.* This repository's own canonical
+instance of the pattern — `tests/static-registry.spec.ts`, the two registry
+readers required to agree, cited in `CLAUDE.md` as what makes that seam real —
+is bound to **no requirement id at all**. It is in the engine suite, outside
+`self/`'s registry, and the only `requirement(` in it is a string fixture. A
+repository that runs the pattern deliberately, and says so in its own design
+vocabulary, contributes zero rows to a count of it. The rate is 1 in 69, and the
+one is weaker than the pair that prompted the entry.
+
+**What survives, and it is the part that costs nothing.** The deletion test the
+entry proposed is untried and is now the cheaper half by a wide margin: if the
+workflow document `init` writes (§9) simply says that two scenarios crossing one
+requirement at different interfaces should assert the same expectations, the
+practice may happen anyway — in which case the engine would have gained nothing
+and charged everyone a field for it. That sentence needs no decision
+infrastructure and is not what this rejects. The permanent property the
+rejection leaves in place — that Attest cannot distinguish covering N edges from
+crossing N interfaces, so a fully-covered requirement says nothing about how
+many surfaces were asked — is recorded in design §11 rather than only here.
+
+**What this rejection does not claim.** One corpus, and the limit `[0.9.2]`
+states about this repository applies: the two-adapter arrangements it has are
+engine-internal, so the count measures Attest's habits rather than an adopter's.
+The prompting report is from a real system nobody here can walk. What is
+corpus-independent is the first argument — no verdict to emit — and that is what
+this is rejected on. A reporter whose registry has the shape at a rate that
+makes a **descriptive** output worth having would be re-opening a different
+proposal, not this one.
+
 ### Rewriting the placeholder scan in `prose` to drop its tail slice
 
 Priced on 2026-08-21, during a standing sweep for more of the ATX-59 shapes, and
@@ -7010,7 +7536,7 @@ releases behind a blocker stated as "the mapping is unavailable", which was
 true and was about a mapping nothing needed; the evidence it carried was about
 the right problem and the mechanism it proposed was not, and nothing rereads a
 blocker that has already been written down. That is the same failure the
-section's own preamble records about a figure nobody re-checks, one level up:
+`How an entry is re-measured` records about a figure nobody re-checks:
 the *shape* of the proposal goes stale as quietly as its numbers do.
 *What is left of this entry is only the original question* — whether `check`
 and `verify` should refuse a half-loaded registry outright, the way `cover`
@@ -7368,6 +7894,19 @@ matching between statements (token overlap, embeddings). That reintroduces the
 fuzzy comparison design §0 exists to remove; real semantic duplication needs
 judgement and belongs to human review at the propose stage.
 
+**New evidence for "sees almost nothing", from `evidence-not-ordering`
+(2026-08-28), and it is about *why*.** `ATX-30`'s statement was reworded — same
+three obligations, one of them stated for the first time — and the detector
+moved it from `correct` to `missed` on both variants. Nothing about the
+requirement got less compound; what changed is that the second clause is now a
+participle (*"keeping a recorded failure … and replacing a recorded pass"*)
+rather than a second `MUST`. So the rule is not weakly detecting compoundness,
+it is detecting one **grammatical spelling** of it, and an author's ordinary
+choice between two ways of writing the same sentence decides the verdict. That
+is the "cleared by deleting the word that triggered it" failure arriving without
+anyone trying to clear it, which strengthens the rejection rather than
+qualifying it.
+
 ### A freshness gate on the file `attest init` writes (`init --check`)
 
 `render --check` is the obvious precedent and is the opposite case. A rendering
@@ -7715,8 +8254,84 @@ and `grep` genuinely stop working — but the first thing to try then is the
 declared prefix ownership already under consideration above, which addresses,
 rather than a scorer, which ranks.
 
+## How an entry is re-measured
+
+What the three sections above have learned about themselves, kept apart from all
+three because it belongs to none of them. Every lesson below was learned on an
+entry that has since left the section it was written in — five built entries now
+recorded under `[0.8.0]`, the `check` `empty-spec` entry under `[0.9.0]`,
+`divergent-param` and the committed params snapshot down in `Considered and
+rejected`. That is the argument rather than a coincidence: the method outlives
+every entry it was learned from, and filed under `Planned` it is unreachable in
+the stretches when `Planned` is empty, which is the state it is in as this is
+written. It was there because that is where the first of it happened to be
+written, which is not a reason.
+
+**An entry can sit in these sections for releases on the strength of a figure
+nobody has checked.** The discipline aims at keeping the *argument*, not at re-testing the
+evidence under it, so the first act of building one is re-measuring what it
+claims rather than implementing what it proposes. It has paid in two ways:
+once killing an entry outright, when the spans it rested on turned out not to be
+spans; and five times correcting an entry's own numbers or scope before a line
+of it was written — a call-site count that a regex had inflated, a cost filed as
+"a fixture per diagnostic" that the corpus put at one fixture, an injection whose
+payload turned out to need the target file's *own* quote character, which is the
+difference between escaping one quote and escaping the right one, a fix
+filed as a map over `issues` that the report's own shape moved to the
+serialiser, four fields and one nesting level further out, and a type-level
+refusal filed as breaking the evaluating loader, which turned out not to touch
+it and to break the one delta shape the entry was about instead. **What a release costs its adopters is not known on the day it is cut**
+— several entries arrived from one adoption report, about shapes the tool made
+someone work around without ever erroring. And **the fixes with no observable
+symptom are worth batching**: individually none justifies a commit, together they
+cost about an hour, and they are the group no gate could have found, since having
+no symptom is the definition of what a gate cannot see.
+
+*The five entries `Planned` carried before it emptied* were built and are
+recorded under `[0.8.0]`. The second is where this
+discipline paid again: it went in on an entry whose headline type
+measurement — instantiations unchanged — was false on re-measure, and the
+re-measure is the only reason the release notes do not repeat it. The fourth is
+the other outcome the discipline has, and worth a line because the first three
+were all corrections: the `render --out` symlink measurement reproduced exactly
+as filed, down to the leaf being safe for the reason given. What re-measuring
+added was not a correction but a **surface the entry had not counted** —
+`--check` reads the same destination, so the same link makes a freshness gate
+date a document outside the project. Re-measuring an entry is therefore not only
+a test of the number it quotes; walking the code the claim is about is what
+shows the claim's own edges. The fifth is that lesson arriving where an entry
+had already named its own fix: the C1 measurement reproduced exactly, and the
+repair it proposed — a map over `issues` — was still the wrong half, because
+four more fields and a nested scenario name carry the same untrusted text and
+never pass the envelope. An entry that ends with a fix is the one least likely
+to have its fix re-examined, which is the case worth naming.
+
+*That has now happened twice, so it is a pattern rather than an incident.* The
+extensionless-import entry likewise reproduced exactly on its reported half and
+was wrong about its own repair — it recorded that the writing half needed
+nothing, and the writing half was guarded by a condition that was correct only
+while the reading half stayed broken. Both times the error had the same shape: an
+entry reasons about the code path it can see failing, and the repair makes a
+second path reachable that nobody has looked at because nothing could reach it.
+So the re-measure that matters is not "does the reported symptom reproduce" —
+both did, exactly — but **what does the proposed fix make reachable for the first
+time**.
+
+*The first time that question was asked in advance, it paid, and how it paid is
+worth a line because it is not what the two cases above would predict.* The
+`check` `empty-spec` entry — `[0.9.0]`, the third entry to reproduce exactly
+on its reported half — was not wrong about its own repair. Asking the question
+anyway found the defect one step to the side: the fix it proposed was correct,
+and the *obvious implementation of it* — make `check` agree with `verify` —
+would have copied a misdiagnosis `verify` had been emitting unnoticed, because
+the reference implementation an entry points at is not itself re-read. So the
+question generalises past the shape it was learned from. It is not only about a
+path the repair makes reachable; it is about **everything the repair would make
+`check` agree with**, and an entry that names the right fix can still be
+
 ## Releases
 
+[0.11.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.11.0
 [0.10.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.10.0
 [0.9.4]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.4
 [0.9.3]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.3