@am_shork/attest 0.9.4 → 0.11.0

package/CHANGELOG.md

@@ -13,6 +13,900 @@ 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
+  `open-unresolved` back to the added ids — the cut that separates it from
+  `never-red`. So do both directions of `keepOutcome`: last-write-wins, where the
+  green run at the end erases the red it exists to remember, and first-write-wins,
+  where a recorded pass can never be corrected. The 46 lines at the top of
+  `red-record.ts` arguing for that asymmetry turn out to be held from both sides.
+
+  Two gaps were real, and both are cases where an existing test passes with the
+  guard removed:
+
+  - **A record whose version is not 2 was discarded by the *schema*, not by the
+    version check.** The case that covers this uses a version-1 record keyed
+    `reqId -> name`, which fails the shape as well — so the verdict is identical
+    either way, exactly as the guard's own comment predicts. Isolating the
+    version needs a record the schema would take: a valid version-2 shape under
+    version 3. Without that, "discarded because the format moved" and "discarded
+    because the file is corrupt" were the same observation, which the comment
+    calls out as how a format change gets made without anyone deciding to.
+  - **Nothing noticed if the record invented a `pass` for a scenario that never
+    executed.** `ATX-30` says the file records *how each scenario ended on its
+    first run*; a skipped scenario has no ending, so a `pass` there is an
+    observation no run produced — in a file that is evidence a reviewer reads and
+    that cannot be recomputed once the change is green. The gate still blocks
+    either way, so no verdict moves; what moves is the advice, since `never-red`
+    picks between "rewrite the assertion" and "run the gate before implementing"
+    on exactly this distinction.
+
+  The third survivor is left alone: `open-unresolved` emitting one error per
+  requirement rather than per question breaks nothing anybody promised. `ATX-81`
+  says the static commands report **each one**, and is pinned per question;
+  `ATX-82` says the gate **blocks**, and says nothing about granularity. Two paths
+  of one shape, one held and one not, and the difference is the two sentences.
+
+  *The harness failed twice more, and the second failure is the one worth
+  keeping.* Mutating a **writer** rather than a reader damages files outside the
+  source it was applied to: `archive` writes `first-run.json` into the e2e
+  fixtures, so a mutant that flipped `keepOutcome` left a committed fixture
+  saying `pass` where it had said `fail`, and every mutant after it read as
+  killed for that reason rather than its own. Restoring tracked fixtures fixed
+  the leak that had been found; a blanket check that the working tree is clean
+  after every mutant then immediately found the one that had not been — an
+  *untracked* record a mutant created, which `git checkout` cannot remove. The
+  broad guard earned its place over the narrow fix by catching what the narrow
+  fix was not written for.
+
+- **Two guards in the registry reader had nothing holding them, found by
+  mutating every decision in `static-registry.ts` and watching what stayed
+  green.** Twenty mutations of the module's semantically load-bearing branches;
+  fourteen died to `tests/static-registry.spec.ts` and `tests/splice.spec.ts`,
+  and six survived the whole suite *and* `self/`. Two of the six were worth
+  closing, and both make the two readers answer **differently** rather than
+  merely reporting differently:
+
+  - `let reqs = defineRequirements({…}); reqs = …; export default reqs` — with
+    the `const` check removed the static reader answers the first registry while
+    the evaluator answers the second. A wrong answer rather than a refusal, which
+    is worse than any code it could have reported.
+  - `export = defineRequirements({…})` — with the `isExportEquals` check removed
+    the static reader accepts it, while the evaluator cannot run it at all.
+
+  Both now have a case in *"a registry that is not a literal"*, and both mutants
+  die to it. The other four survivors are left alone deliberately: one guard is
+  defence-in-depth behind a refusal that already happened upstream (`__proto__`
+  as an entry id, which `readRegistrySource` rejects before a merge can reach the
+  layout), one is a deliberate looseness whose comment says why, and two forbid
+  shapes that cannot compile in the first place. A test contrived to reach them
+  would assert that something upstream is still doing its job.
+
+  *The harness had to be fixed before any of it could be believed, and that is
+  the part worth carrying forward.* Its first run reported all six survivors as
+  killed. The cause was the mutation runner inheriting a working directory with
+  no test files in it, so `vitest` exited non-zero with "No test files found" and
+  every mutant read as covered — a green instrument reporting on nothing, which
+  is the exact failure `ATX-15`'s sweep guards against in as many words: *"a walk
+  that found no files satisfies 'no site orders by locale' while proving the
+  opposite of what it claims."* The runner now pins its working directory and
+  refuses to report at all unless the unmutated tree passes first.
+
+- **The differential corpus now drives the two registry *writers*, not only the
+  two readers.** `tests/static-registry.spec.ts` exists because reading a
+  registry from the AST instead of evaluating it needs the two readers held
+  against each other — but the literal they walk has a third and a fourth
+  consumer, `registryInsertionPoint` and `registryEntryLayouts`, and the table
+  was never pointed at them.
+
+  *Every registry-source defect in this release had its trigger already sitting
+  in that table.* `as-const`, `satisfies` and `parenthesised` are the three
+  spellings whose literal the writers could not locate; `key-forms` carries the
+  duplicate key whose span they located at the wrong offset, under a comment
+  that has said *"a duplicate key: last wins"* since the row was written. The
+  corpus knew about all four inputs. Nothing asked the writers about them.
+  Reverting either fix now turns the table red — measured: the unwrap on all
+  three wrapper rows, the layout guard on `key-forms`.
+
+  **What it asserts is not that every case is writable.** A source the readers
+  accept may be one the writers must refuse, and `key-forms` now is. The
+  property is that a writer's answer is always *located* or *refused for a
+  stated reason*, never the third thing — located, wrongly — and which cases are
+  refused is a table someone has to edit rather than a branch that can drift.
+
+  *Widened while pointing it: the `satisfies` row did not cover the spelling
+  that broke.* It applied the keyword to a param value, where the value reader
+  sees it, and not to the registry argument, where the walk that finds the
+  literal does — so it stayed green through a defect named after it. It now
+  carries both positions, as the `as-const` row beside it always did.
+
+- **`readArchivedChanges`' fan-out is bounded — the fourth one, and the first
+  outside `locate.ts`.** `archive.ts` read every archived first-run record
+  through a `Promise.all(names.map(…))`, so a project with N merged changes held
+  N reads and N parsed `RedRecord`s at once. It is the same shape as the other
+  three against an input nobody here chooses — an `archive/` grows by one folder
+  per change merged and is never pruned, so it is the longest-lived of the four
+  lists a project's shape decides the length of. Measured in
+  `tests/locate-fanout.spec.ts`, which now counts a fourth pool: **64 before, 32
+  after**, on 64 archived changes. Unbounded, the figure is the count of the
+  folders; bounded, it is the constant.
+
+  *Why it hid is that the pool's own doc comment names the rule and this caller
+  is not in the file that has it.* `forEachBounded` says "anything here that
+  reads a list the project's tree decides the length of belongs in this pool,
+  whatever the function around it is called" — and `readArchivedChanges` is
+  exactly that, one module over. The nearest comment to it reasons carefully
+  about concurrency and still says nothing about a bound: `inspectRedEvidence`
+  explains why it runs the archive read *after* `inspectProject` rather than
+  beside it — "overlapping them buys nothing worth a second fan-out" — which is
+  a correct answer about sequencing two reads and not a claim about what happens
+  inside either. That is the third time in this catalogue a considered comment
+  about concurrency has stood where a bound was missing. `forEachBounded` is now
+  exported for it, with a fourth constant on the reason `WALK_CONCURRENCY`
+  already gives.
+
+  **The failure this invites is memory, not descriptors — and that corrects the
+  three entries above.** Each of those closed by calling descriptor exhaustion
+  the invited failure and leaving it unmeasured. Measured now, on Linux: it is
+  not reachable through this shape at all. `fs.promises.readFile` does
+  open-read-close inside one libuv threadpool work item, so concurrent
+  *descriptors* are bounded by the threadpool and never by the fan-out — 3,000
+  unbounded in-flight reads peaked at **53** entries in `/proc/self/fd`, and the
+  read completed cleanly under `ulimit -n 256`, and again under `ulimit -n 128`
+  with `UV_THREADPOOL_SIZE=1024`. What does track the input is heap: on 2,000
+  changes of a 45 KB record, peak `heapUsed` was **352 MB unbounded against 177
+  MB bounded**, over interleaved runs — and the unbounded figure wandered from
+  329 to 580 MB across rounds while the bounded one held 177–181. The stable
+  number is the point; the retained result is the floor, and what the bound
+  removes is the transient pile on top of it. This is the portable-arithmetic
+  standard the three earlier halves were accepted on, so it needs no incident
+  report — but the *reason* is memory, and future sweeps should stop reaching
+  for `ulimit`, which does not govern this on either platform: Windows uses
+  Win32 handles, and on Linux the threadpool gets there first.
+
+  Reached only from `inspectRedEvidence` and so from `@am_shork/attest/inspect`,
+  the published subpath — no CLI command reads the archive, which is why the
+  static-command roster is untouched by this. No behaviour change and no
+  `ATX-n`, on the precedent of the other three: the changes, their order, their
+  paths and the merged record are identical, asserted beside the peak. The
+  result is built by preallocate-and-index rather than by arrival, which is what
+  keeps the sorted folder order true through a pool that completes out of order.
+
+- **The publish job runs on protected tags only, and it says so in the file
+  rather than in a settings page.** `rules` was `if: $CI_COMMIT_TAG`; it is now
+  `if: $CI_COMMIT_TAG && $CI_COMMIT_REF_PROTECTED == "true"`.
+
+  *The reason it needed to be in the file is that the comment beside it claimed
+  a defence that does not exist.* It said the reason to protect release tags had
+  changed — from exposing a masked variable to `id_tokens` being "issued to
+  protected refs only". That is not how GitLab issues them. Every job gets an ID
+  token, and the protection state travels *inside* it as the `ref_protected`
+  claim; a design that reports protection as a payload field is one where an
+  unprotected ref is handed a token too. Nothing on npm's end narrows it either:
+  a GitLab trusted publisher is namespace + project + top-level CI file path +
+  optional environment, with no ref condition available to configure.
+
+  **So the entire ref authorisation was the `rules` line — evaluated from the
+  `.gitlab-ci.yml` at the pushed tag, which is a file the pusher had just
+  written.** "Can push a tag" was therefore "can publish `@am_shork/attest` with
+  a valid provenance attestation", and the `NPM_ID_TOKEN` guard added in the
+  entry below cannot narrow it: that guard asks whether a token exists, never
+  who caused one to be minted. Protected tags in *Settings -> Repository* were
+  the only thing standing there, described by the comment as a belt-and-braces
+  extra.
+
+  This is the shape this repository keeps finding — a defence that reads as
+  present and is not, alongside `bin/attest.js`'s static import, the `hasWarned`
+  spread and `hmr: false` — arriving this time in the sentence explaining a
+  defence rather than in the code implementing one. Keep the protected-tag rule
+  in Settings as well: only that side stops the tag being created, and this side
+  only declines to publish once it has been. *Found by review, not by a run —
+  no pipeline was executed to confirm it, and the two vendor behaviours above
+  are read off GitLab's ID-token documentation and npm's trusted-publisher
+  documentation rather than measured here.*
+
+- **The publish job has no stored credential left: `NPM_TOKEN` and the
+  `_authToken` line are gone, and the guard is on `NPM_ID_TOKEN` instead.**
+  Completes what `[0.9.4]` set up. The deletion test pointed here from the
+  start — what it removes is the only long-lived credential this repository had.
+
+  *It went in on a measurement, and the measurement is the part worth keeping.*
+  The v0.9.4 release published through the trusted publisher, not the token:
+  `_npmUser` on that version is
+  `{"name":"GitLab CI/CD","trustedPublisher":{"id":"gitlab","oidcConfigId":"oidc:…"}}`,
+  by npm 11.19.0. The entry that proposed this recorded that **no account existed
+  anywhere of publishing from GitLab under OIDC** — every report was GitHub
+  Actions — and stated the inference at the strength the evidence carried. That
+  release is the first record. The token was present and unused: `oidc()`
+  overwrites the auth key on success, so the `.npmrc` line never applied.
+
+  **The job's own log could not have told us, and that is why the fallback had
+  to go.** Every path in npm's `oidc.js` logs at `verbose` or `silly` while npm's
+  default level is `notice`, so a successful exchange and a failed one produce
+  byte-identical job output — the v0.9.4 log contains no OIDC line of either
+  kind. Combine that with a fallback written never to throw and the failure mode
+  is exact: an exchange that stops working keeps publishing, on the credential
+  the exchange exists to retire, silently, with the difference visible only in
+  registry metadata nobody reads. **The property that made the rollout cheap is
+  the wrong one to keep**, and this is the first time in this file that a
+  mechanism has been removed for succeeding rather than for failing.
+
+  So the check moves in front of the irreversible step, which is the rule the
+  removed post-publish attestation check failed and this file already argued:
+  verification belongs where it can act on the answer. A missing `NPM_ID_TOKEN`
+  now fails before anything is published; a failed exchange fails the publish
+  outright, loudly and recoverably, because nothing was written.
+
+  *What is not in this repository, and is not done by this entry.* One act on
+  npmjs.com: *Require two-factor authentication and disallow tokens* on the
+  package, which is what stops a leaked token publishing it and which npm states
+  does not affect trusted publishers. Not a commit and not verifiable from here.
+
+  *The `NPM_TOKEN` CI variable stays, deliberately, and the reasoning is worth
+  recording because the first version of this entry had it wrong.* Deleting it
+  was filed beside the npm setting as though the two were equal acts. They are
+  not: the setting removes the **capability** — a token can no longer publish this
+  package — while deleting the variable removes **one copy** of a credential that
+  goes on existing in the npm account either way. Revoking it there is the act
+  that destroys it; removing it from GitLab is housekeeping. The variable is
+  masked, protected, exposed only to protected refs, and now read by no job, so
+  what it costs to keep is nothing. What the setting does not cover is measured
+  rather than assumed: it is per-package, and `@am_shork/attest` is the only
+  package in the scope, so today it covers the account's entire published
+  surface exactly. The gap it leaves is future-conditional — a second package
+  would start without the setting — and that is an obligation attached to
+  publishing a new package, not a reason to move a variable. *And the next tagged release is the test of this change*, the same way
+  v0.9.4 was the test of the last one — except that this time a regression fails
+  the release instead of quietly publishing. That is the intended trade.
+
+### Added
+
+- **`ATX-83` states the three states of that field.** What was missing was never
+  the field; it was a sentence the suite could falsify about *when* the field is
+  there. A requirement saying only "the report carries the paths the merge wrote"
+  is satisfied completely by an implementation that always emits `[]`, and that
+  implementation is wrong in exactly the case the field is reached for — a re-run
+  after a completed merge.
+
+  *Written straight into the registry, not through `changes/`.* That is how
+  existing behaviour is described here, and it is the reading `ATX-80`'s
+  `unarchived` state exists for: `never-red` asks for a recorded failing run only
+  of the ids a change is currently ADDing, so a requirement catching up to
+  behaviour that already shipped carries no such obligation and gains nothing
+  from a workflow whose point is to make a scenario fail before the code exists.
+  The scenario lives beside the other `archiveReport` ones in
+  `self/json.spec.ts`, where a reader looking at that function finds all of them.
+  Nothing records that it discriminates, which is what `unarchived` costs and is
+  worth saying rather than leaving implicit — so it was checked by hand instead:
+  with the one line that spreads the field into the report removed, the scenario
+  fails, and `verify self` reports `tests-red`.
+
+  The measurement in `tests/intent-rule-candidates.spec.ts` moved by exactly one
+  requirement — corpus 93 → 94, universal quantifiers 40 → 41 — and no verdict
+  in it flipped. It also produced the `flag:` divergence key's **fourth**
+  re-keying in four releases, every one triggered by an addition that agrees
+  with a member already there, and the `field:` key's first *extension* rather
+  than re-keying; both are noted where the rule is judged, because which of the
+  two an addition causes turns on vocabulary rather than on how related the
+  requirements are.
+
+- **`archive --apply --json` reports the paths the merge wrote.** The human
+  rendering has listed them since `--apply` shipped, on the grounds that this is
+  the command that edits files the user cannot regenerate and the reader needs to
+  know which ones to look at before committing. The `--json` reader — the one
+  most likely to be automating around the merge — got the change name and nothing
+  else. `written[]` closes that, and both renderings are now handed the same
+  bundle from one place in the shell rather than each being told separately,
+  which is the split that let the verdict disagree with itself in `[0.7.0]`.
+
+  **Absent without `--apply`, `[]` with it.** The two are different facts — no
+  merge was attempted, against a merge that ran and had nothing left to write,
+  which is the ordinary state of a re-run after a completed one — and a field
+  that spelled both `[]` could not say which. Additive, so no `SCHEMA_VERSION`
+  bump: a consumer that has never heard of the field reads the report it always
+  did. ATX-74's sweep covers it like every other string a report quotes out of
+  the checked project.
+
+### Fixed
+
+- **`first-run.json` committed different bytes for the same evidence, depending
+  on how many runs it took to gather.** `mergeRedRecord` rebuilds the record so
+  key order is a function of the data rather than of insertion — and did that at
+  two of its three levels. The rebuild sorts the requirement ids the record
+  already held; the loop after it *appends* the ids this run is the first to
+  observe, in plan order; and the pass at the bottom re-sorted the file and
+  scenario levels while walking the ids in whatever order they were in, because
+  reassigning `record[id]` does not move a key.
+
+  So a change that grew its record over several stage-1 runs committed
+  `{"Z-9": …, "A-1": …}` where the same observations reached in one run committed
+  `{"A-1": …, "Z-9": …}`. Nothing about the outcomes differs; the file does. That
+  matters twice over for this particular file: it is evidence a reviewer reads in
+  a diff, and the gate has to reach the same verdict on a CI checkout as on the
+  author's machine. It also went unnoticed once written — `changed` is decided by
+  the outcomes alone, so an unchanged record is never rewritten and a
+  wrongly-ordered one stays that way.
+
+  *ATX-15 already said this and could not catch it.* The requirement quantifies
+  over "every ordering Attest commits to disk", and the sweep attesting it is
+  deliberately narrower than its own statement: it checks *how* a site orders —
+  every `.sort` in `src/` through `byCodeUnit` — and says so, *"a `red-record.ts`
+  that stopped sorting at all is still green here, and the scenarios above are
+  what speak to the result"*. There was no such scenario for this file. There is
+  now, in `self/red-record.spec.ts`: it reaches the same evidence by both routes
+  and compares the serialised bytes. `archive.ts`'s `sortRecord` had all three
+  levels right and is what this now matches.
+
+- **`--apply` refused a registry whose literal is written with `as const`,
+  `satisfies`, or a bare pair of parentheses.** The reader takes all three —
+  `unwrap` strips the type-level wrappers before `literalValue` reads the object,
+  because none of them changes the value — so the gate read such a file, proved
+  the change green, and handed it to a merge that asked
+  `ts.isObjectLiteralExpression` of the wrapper and got `false`. Both writers
+  refused: the whole change stopped with `internal-error`, whose own message says
+  the file *"read as a registry for the gate but not for the merge"* and whose
+  comment calls the condition unreachable through the command. It was reachable
+  by writing `defineRequirements(({ … }))`.
+
+  *The fix is where the two answers diverged, not where the symptom showed.*
+  `authoringCall` is the single function both sides use to find the registry
+  literal — the module's opening note says a second walker would be a second
+  answer to "is this a literal" — and it handed back the argument node as
+  written, leaving each caller to decide whether to unwrap. The reader did and
+  the writers did not, so the disagreement the shared function exists to prevent
+  was inside it. It now unwraps once, and `literalValue`'s own call becomes the
+  no-op it should always have been.
+
+  The parenthesis is the reachable spelling and the reason this is a fix rather
+  than a nicety: `as const` and `satisfies` are opted into, while nothing about
+  `(({ … }))` looks like a type annotation anyone chose. No `SCHEMA_VERSION`
+  bump and no new code — a change that used to fail now succeeds, which is the
+  benign direction for an exit code, and the History row is what tells a reader
+  on an older build which half of the page applies to them.
+
+- **A registry key written twice made `archive --apply` write bytes outside the
+  value it was replacing — and, measured, outside the registry literal
+  altogether.** `registryEntryLayouts` keys each value's source span by name in
+  a `Map`, and `spliceModifications` walks that map to get its edits in
+  ascending offset order, which is what lets the pass at the bottom be a
+  `reverse()` rather than a sort. `Map.set` on a key it already holds keeps the
+  **first** insertion's position and takes the **last** call's value — so an
+  entry writing `params: { limit: 1, other: 'x', limit: 1 }` describes `limit`
+  at position one carrying the span of the occurrence *after* `other`, and the
+  offsets stop ascending. The earlier edit then moves the bytes under the later
+  one. On a registry the gate had just proved green, changing both values landed
+  the second one past the file's closing `});`.
+
+  *Nothing upstream refuses such a file, which is why this reached the one
+  command that writes.* A duplicate key is a TypeScript **semantic** error, and
+  `parseSource` asks only the syntactic question (`[0.9.0]`, ATX-69) — so both
+  registry readers take the file and hand back the last occurrence, `check` is
+  silent, and the gate passes. The reachable route is an ordinary copy-paste in
+  a hand-written registry, in a project that does not typecheck its
+  `*.reqs.ts`.
+
+  **Refused rather than described, at all three levels.** An entry whose keys
+  repeat is left out of the layout with the repeated key's path recorded beside
+  it, and `spliceModifications` turns that into an `apply-unsupported-delta`
+  refusal — whole, with nothing written — before a single edit is pushed. The
+  id level is not the mild one and is refused for the same reason rather than a
+  weaker one: two entries under a single id put a *later* entry's spans at an
+  *earlier* entry's position, so the disorder is between entries rather than
+  inside one. The guard stays exactly as wide as the danger — an unrelated id in
+  the same file is still written — because a merge that stopped over something
+  it was not asked to touch is the thing `--apply` refuses to do everywhere
+  else.
+
+  *The sibling defect is already in this file and did not generalise on its
+  own.* `[0.8.0]` fixed an integer-like `params` key for the identical
+  invariant — JavaScript hoists it to the front of every object, so a plain
+  object could not carry the file's order — and the repair was to move all three
+  levels to `Map`s. That answered the container and left the *keys*: a `Map`
+  keeps insertion order for every key type, and the one thing it still cannot
+  represent is one key written twice. The test added then, `rewrites two params
+  when one of them has an integer-like key`, is the shape of the three added
+  here, down to needing two changed values of different lengths — one edit
+  cannot be out of order with itself.
+
+  `verifyWritten` did catch the result and stop the merge, so the failure was
+  never silent; the file had already been overwritten by then, which is the
+  "destructive on a file the user cannot regenerate" shape the `AGENTS.md` merge
+  tool was rejected for and the reason a post-hoc check is not where this
+  belongs.
+
+  **Breaking, and narrowly so — this is the entry that decides the version
+  number.** The common case is not: a repeated key usually made the merge write
+  outside the value and the re-read then failed it, so the run already exited 1
+  and only the `code` moves — `internal-error`, raised after the registry had
+  been overwritten, becomes `apply-unsupported-delta`, raised before anything is
+  written.
+
+  But the offsets only go wrong when an earlier edit *changes length*. A
+  modification that replaces a value with one the same size shifts nothing, so
+  on `[0.9.4]` such a merge completed and completed **correctly**. Measured on a
+  registry with a duplicated `statement` and a `budgetMb: 1` → `2` patch: 0.9.4
+  merges it and it reads back as `{"budgetMb":2}`; today it refuses. That is
+  previously-valid input now rejected, which is this file's own definition of
+  breaking, so it takes the **minor** rather than the patch.
+
+  The refusal is still right — the same file with a length-changing patch is the
+  corruption above, and which of the two a merge gets is not something the author
+  chose. What the narrowness costs is that an adopter whose registry happens to
+  carry a duplicate key sees a working command start refusing, so it belongs in a
+  minor with the reason stated rather than in a patch nobody reads.
+
+  No `SCHEMA_VERSION` bump: the envelope, the `Issue` interface and the roster in
+  `core/docs.ts` are all unchanged — the refusal reuses the code `--apply`
+  already raises for a delta it will not write.
+
+  **`ATX-76` is widened to say what it always meant**, through this
+  repository's own workflow — `self/archive/2026-08-21-widen-atx-76`, the second
+  change to go through it and the first carrying a MODIFIED. Its refusal clause
+  named one instance of a class: *"when a span it would overwrite carries a
+  comment"*. Refusing a comment inside a span is not a rule about comments, it is
+  the rule that a replacement may only ever write the value it was asked to
+  write, stated at the one place that value's boundary was known to be in doubt.
+  A repeated name puts it in doubt a second way, so the clause now reads
+  *"wherever the file leaves that span uncertain"* and lists both. What is
+  **not** stated is the refusal as a mechanism: refusing is how *this*
+  implementation keeps the first clause, and a rewrite could keep it by ordering
+  the edits instead — a requirement pinned to the remedy would forbid that repair
+  for no reason.
+
+  *The defect was never that the rule was absent.* The first clause — the unit of
+  the edit is the value — has said this since `[0.9.0]`. What was missing was a
+  sentence the suite could falsify in this direction: both existing scenarios
+  assert something about a **comment**, and neither can go red when the failure
+  is that the span located was the wrong one. `self/merge.spec.ts` now carries a
+  third, looping the three sites a name can repeat with the extent pinned beside
+  the loop. Measured with the fix reverted, at the `spliceModifications` seam:
+  all three wrote without refusing; with it, all three refuse.
+
+### Documentation
+
+- **The CLI reference told readers the `--json` guarantee rests on
+  `JSON.stringify`, which is the reasoning `[0.8.0]` retired.** *Output is safe
+  to read* closed with "`--json` was never exposed: serialising escapes the same
+  characters" — true of C0 and of nothing else, so DEL and the C1 range were
+  never covered by it. The code has been right since `[0.8.0]`, where the
+  replacer in `renderJson` began stripping every string in the document as it
+  serialises one; the page kept the retired argument, in both languages, three
+  hundred lines above its own History row saying the opposite.
+
+  *The comment at the crash site in `cli/action.ts` said it too*, and that copy
+  is the one worth naming: it sat directly above `renderJson(errorReport(…))`
+  and read as a settled argument for why sanitising there was unnecessary. The
+  replacer it argues against is what makes that line safe. Nothing was
+  exploitable — this is a false rationale standing beside a working defence,
+  which is the configuration that gets a defence deleted by someone tidying up.
+
+  Found by an attack-surface review rather than by a gate, and no gate could
+  have found it: the suite checks that a `§n` a comment cites exists and that a
+  version a History table names is a heading here, never whether a sentence is
+  true. Three copies of one retired claim is what that gap looks like from
+  inside. No behaviour changed and no version moved, so there is no new History
+  row — the `[0.8.0]` row was correct all along and is what the prose now agrees
+  with.
+
+- **The method page says which shape a composite param is best at, and the
+  sample is a fixture that runs.** `intent-quality.md` already carried both
+  hazards a list-valued param has — an expectation recomputed from the param it
+  is checking, and a loop whose extent nobody pinned — as the third and fourth
+  of its five findings, named and left there with no shape attached. A **decision table**, rules pairing conditions with the
+  outputs the requirement promises, is where both arrive at once and where the
+  single source pays most, so it is now named. The section states the property
+  the shape actually rests on, which is narrower than "use a table": the
+  implementation reads only the *condition* columns, which leaves the output
+  columns an independent term — and it stops being true the moment the system
+  under test is itself driven by the same rules.
+
+  *The sample is `fixtures/consumer/requirements/cart.reqs.ts` and
+  `fixtures/consumer/cart.spec.ts`*, added here and registered in
+  `PUBLISHED_SAMPLES`, because every `ts` block this page publishes was already
+  a file the packaging test installs from a tarball and runs, and half-real
+  samples teach a reader to check which — after which they stop. **Making it
+  real is what found the constraint the section now documents**: the statement
+  cannot interpolate the table. A `{placeholder}` resolves to a scalar or a list
+  of scalars, so `{rules}` is `non-scalar-interpolation`, and the statement has
+  to name the behaviour in prose while the rules stay a param the scenario reads.
+  A draft written only as prose had it wrong and nothing would have said so.
+
+  It also landed on an existing row rather than needing a new rule:
+  `intent-rule-candidates.spec.ts` classifies it `over: 'roster'`,
+  `owner: 'registry'`, which is the branch that owes a `pin` — a registry-owned
+  list is data an author can shorten, and every assertion inside the loop still
+  passes over the shorter one. The published scenario carries that pin
+  (`expect(rules).toHaveLength(6)`), so a reader who copies the block copies the
+  counter-pressure with it.
+
+  *It was written into the README first, and has moved.* The README is the
+  pitch, the five-minute start and navigation; a hundred lines on how to write a
+  param that pins something is the method page's job, beside the two findings it
+  repairs. The README keeps one paragraph pointing at it. **The move is also
+  what showed `PUBLISHED_SAMPLES` could not say where a sample is published** —
+  it read the README and only the README, which was right while every sample
+  lived there and an obstacle the moment one did not. Each entry now carries its
+  page, so moving a sample between pages is a roster edit rather than a silent
+  loss of the gate that keeps it runnable.
+
 ## [0.9.4] - 2026-08-19
 
 ### Added
@@ -5373,96 +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.
-
-- **Retiring `NPM_TOKEN`, which is now two settings on npmjs.com rather than
-  anything in this repository.** The mechanism landed under `[0.9.4]`: the
-  publish job requests an npm OIDC token and publishes through `npm`, which is
-  the only client that performs the exchange. What that did **not** do is remove
-  the credential, and the distinction is the point — enabling a trusted publisher
-  leaves an automation token just as able to publish. Two acts remain, neither of
-  them a commit:
-  **(1)** register the trusted publisher on the package — `Pseudorca`, `attest`,
-  `.gitlab-ci.yml` with the extension, the allowed actions; environment name is
-  optional and this project uses none, and shared runners are the only supported
-  kind, which the job already uses because it carries no `tags:`. Free and
-  reversible, and safe to do at any time: a failed exchange falls back to the
-  token rather than failing the publish (measured — see the `[0.9.4]`
-  entry). **(2)** set *Require two-factor authentication and disallow tokens* on
-  the package, which npm states does not affect trusted publishers. That is the
-  one that closes the loop the job's own comment opens, where an automation token
-  is used *because* a granular token fails against 2FA on writes: trusted
-  publishing does not bypass the prompt, it stops being a token.
-  *What is unmeasured, and it is not measurable from here.* Whether the exchange
-  actually succeeds against a gitlab.com project. Every documented ingredient
-  checks out and no plan requirement is stated anywhere, but there is no record
-  of anyone publishing from GitLab under OIDC — every account is GitHub Actions.
-  The first tagged release after the `[0.9.4]` change is the test, and the
-  fallback is what makes running it cheap: if the exchange fails, the release
-  still publishes and the job's verbose log says why. **Do not delete the token
-  before a release has been observed publishing without it.**
+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
 
@@ -5515,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
@@ -5670,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
@@ -5692,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.
@@ -5728,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,
@@ -5762,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
@@ -5980,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
@@ -6101,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
@@ -6241,10 +7011,107 @@ 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.
 
+  **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
 
 Decisions **not** to build something, kept where they can be found before the
@@ -6255,6 +7122,233 @@ 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
+rejected by the measurement that was supposed to confirm it.
+
+`prose` (`core/render.ts`) walks a statement character by character, and at every
+`{` it runs `/^\{\w+\}/.exec(text.slice(i))`. Read as source that is the §2
+quadratic-scan shape exactly: one fresh copy of the remaining string per `{`, so
+a statement of n braces copies n²/2 bytes — and a statement is prose a fork
+contributor writes and `render --check` reads under the static reader, which is
+the class that has actually shipped defects here. The fix was to be a sticky
+`/\{\w+\}/y` with `lastIndex = i`, which allocates nothing.
+
+**It is not quadratic, because V8 does not copy.** `String.prototype.slice` on a
+string past a small threshold returns a *sliced string* — a view onto the parent
+with an offset, made in constant time — and an anchored regex over it reads only
+the few characters it needs, so the copy the source implies never happens.
+Measured through `renderMarkdown` on the built output, three adversarial shapes
+(all braces; alternating `{a`; a brace run followed by a word run), at 100k
+through 800k characters: every one of them scaled at a ratio of **1.77–1.89 per
+doubling**, i.e. linear, and 800,000 braces rendered in **106 ms** against
+ATX-59's 1,000 ms budget. A quadratic implementation at that size would be tens
+of seconds; this is the same order as the linear cases beside it.
+
+So there is no defect and no change. What the sticky rewrite would buy is a
+constant factor nobody has shown a need for, against §5's rule that
+micro-optimisation with no named input is out of scope — the input *is* named
+here, and it is already absorbed. Filed rather than dropped because the site
+reads like the defect on inspection and will be proposed again by the next sweep
+that greps for `.slice(` near a loop: the answer is that V8's representation is
+load-bearing, the measurement is the evidence, and the thing to re-run is the
+ratio rather than the reasoning. Note the limit of that claim — it rests on a V8
+representation rather than on anything the language promises, which is safe for a
+Node CLI and would not transfer to a runtime that flattens eagerly.
+
 ### Deferring the `typescript` import so `init` and `--version` do not pay it
 
 Priced on 2026-08-13, in the session that enabled the compile cache above, and
@@ -6442,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`
@@ -6800,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
@@ -7147,8 +8254,85 @@ 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
 [0.9.2]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.2