@am_shork/attest 0.10.0 → 1.0.0

package/CHANGELOG.md

@@ -7,16 +7,620 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## Versioning
 
-Under 0.x SemVer a breaking change bumps the **minor**. "Breaking" means it
+From `[1.0.0]` a breaking change bumps the **major**. "Breaking" means it
 changes the exit code of an existing valid setup, rejects previously-valid
 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.
+not API. The definition has not moved; what moved is the bump it earns, and the
+whole history below `[1.0.0]` was written under the 0.x rule, where the same
+definition earned a **minor**.
+
+**One surface keeps the 0.x rule, and it is named rather than inferred.**
+`./inspect` is excluded from the freeze below, so a breaking change to it is a
+minor until a second adopter's usage exists. Everything else the next section
+lists takes the major.
+
+`schemaVersion` in the `--json` report is a **separate axis** and not a
+restatement of this one: it is bumped whenever the emitted shape changes
+incompatibly, and an additive field bumps neither it nor the package. Removing
+or renaming a `--json` field is breaking by the definition above and is
+therefore both — a `schemaVersion` bump and, from 1.0, a major.
+
+**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.
+
+## What 1.0 freezes
+
+Decided 2026-08-31 and binding since `[1.0.0]`, where the argument, the
+measurement it rests on and what is still unmeasured are recorded. The line
+exists because every open entry waiting on an adopter is asking somebody to build
+on a surface documented as movable, and a line is the only thing that makes that
+a reasonable ask. It is here rather than only there because a stability promise a
+reader cannot find is not one.
+
+**Frozen at 1.0: the CLI — its commands, options and exit codes — and the root
+export `.`.** Both are frozen on evidence that they have stopped moving rather
+than on intention: the CLI's last change of shape was `--apply` on 2026-08-03,
+twelve releases ago, and `src/index.ts` has had its export list edited in three
+commits ever, the last on 2026-07-26.
+
+**Explicitly not frozen at 1.0: `./inspect`.** It shipped in `[0.9.2]` and has
+two releases and one adapter behind it. Freezing it would be freezing on one
+adapter, which is the objection this project raises against every premature
+interface and does not get to waive for its own. It stays under the 0.x rule
+above until a second adopter's usage exists — stated here, rather than left to
+be inferred from a version number that would say otherwise. `./define` sits
+between the two and is frozen with the CLI, on seven releases.
+
+**1.x, not 1.0:** everything currently blocked on an adopter's evidence — the
+judgement schema, any retrieval surface over the archive. The freeze is not a
+claim that those are settled. (A backlink index over `archive/` was named here
+until 2026-09-01, when it was rejected outright; it is not deferred to 1.x, and
+what closed it is at the foot of this file.)
+
+**Not a frozen surface, and deliberately: the workflow document `attest init`
+writes into the adopter's repository.** It is a function of the installed version
+— which is what makes re-running `init` after an upgrade the whole update
+mechanism — so freezing it would freeze the workflow the tool teaches. What 1.0
+does not do is make its drift detectable, and that is a live question at the foot
+of this file rather than something this line settles. It is named here because
+the first adoption measured across an upgrade paid nothing on the four surfaces
+above and 110 stale lines on this one.
+
+*What this costs is the paragraph above.* Under 1.0 a narrowing that closes a
+security hole takes a major, on whatever schedule a hole is found. That price is
+now stated rather than unknown, which is what made the line decidable at all.
+
+## [1.0.0] - 2026-09-01
+
+### Added
+
+- **`ATX-87` gates the CLI's command and option roster, which is the other half
+  of the same freeze.** `What 1.0 freezes` names two surfaces in one sentence —
+  the CLI, its commands, options and exit codes, and the root export `.` — and
+  after `ATX-86` three of those four halves were held: the export by `ATX-86`,
+  the exit codes by the requirement making `hasError` the single predicate the
+  verdict, the JSON `ok` and the process status all read from, and by the one
+  keeping the report alone on stdout. **The roster was held by nothing.** Seven
+  commands and seventeen options, and no test anywhere enumerated either, so
+  deleting a flag or renaming a command broke nothing a contributor runs.
+  `ATX-16.staticCommands` reads like the missing gate and is not: it names four
+  commands in order to say they execute no project code, which is a claim about
+  behaviour rather than a claim that the roster is closed.
+
+  **Read out of `--help` rather than out of `cli/index.ts`, and that is forced
+  rather than preferred.** Every option string in the source is a constant —
+  `JSON_FLAG`, `EVAL_FLAG`, `VITEST_CONFIG_FLAG`, `TARGET_FLAG` — so a static
+  walk for literals sees the command names and almost none of the flags, and
+  resolving the constants would mean reimplementing enough of the emitter to
+  guess what it emits. The built module cannot be introspected either:
+  `program.parseAsync()` runs at module scope and `program` is never exported,
+  so importing `dist/cli/index.js` runs the CLI instead of describing it. What
+  is left is the artifact a consumer actually reads, and it is the right ground
+  truth in both directions — a flag that works and is absent from the help is
+  not on the published surface, and one documented there is, whatever the source
+  says.
+
+  **commander's `-h, --help`, `-V, --version` and `help` command are excluded,
+  and matched by name rather than by shape.** They are not this project's to
+  freeze, and a gate that reddens because a dependency reworded its own built-in
+  is red for a change nobody here decided — the shape this repository refused
+  once already, when it rejected a freshness gate that could fail a fresh clone
+  on somebody else's release. Matching them by long name is what keeps the
+  exclusion from hiding one of ours: `-h, --help` and a hypothetical `-j,
+  --json` are the same shape, so a shape test would silently drop a real flag
+  the day anybody adds a short one.
+
+  The two rosters are asserted apart because they are separately falsifiable: a
+  command list that is exactly right can belong to commands whose flags have all
+  been renamed, and every flag can be correct on a command that should not
+  exist. Measured — perturbing the CLI with one added command *and* one added
+  flag failed both scenarios, while an added command alone would have failed
+  only the first, since the option scenario iterates the registry's list and
+  would never have visited it. Eight child processes, one per help page,
+  spawning `process.execPath` with `bin/attest.js` rather than the installed
+  shim, so no shell is involved on either platform; both scenarios carry an
+  explicit `timeoutMs` because the CLI's start-up cost puts the option scenario
+  over Vitest's 5 s default.
+
+  No engine code changed, no command or flag moved, and no `--json` field or
+  issue `code` was added: this is a self-requirement and a spec file.
+
+- **`ATX-86` gates the shape of what `.` exports, ahead of the release that
+  freezes it.** Nothing in the suite enumerated the public surface, and the
+  three things that looked as though they did each answered a different
+  question: `tests/consumer.spec.ts` asserts that every specifier in the
+  `exports` map *resolves*, which is reachability rather than shape;
+  `tests/smoke.spec.ts` asserts four runtime exports are functions, and is
+  silent about the eleven type-only names beside them and about an export
+  arriving that nobody intended; and the four `*.spec-d.ts` files pin the
+  behaviour of particular types against `src/` rather than against the emitted
+  declarations. So dropping a type export, or widening `Issue.code` back to
+  `string`, broke nothing a contributor runs — on the surface `What 1.0 freezes`
+  promises not to move.
+
+  **Stated over the built package and attested over its two artifacts
+  separately**, which is `ATX-79`'s shape and is not an analogy to it. `export
+  type` is erased whole at emit, so `Issue` is a name in `dist/index.d.ts` and is
+  absent from `dist/index.js`, and a consumer importing it as a value gets
+  nothing. That asymmetry is the claim rather than an accident of it, and it is
+  invisible to any walk over `src/index.ts`, where both kinds are one export
+  list. The declared lists live in `params`, so each scenario compares the
+  registry against the artifact and the two terms are independent in both
+  directions: a barrel the registry does not follow goes red, and so does the
+  reverse.
+
+  **What it does not close, stated here rather than found later.** An edit that
+  removes a name from the barrel *and* the registry moves both terms together
+  and stays green. That is a deliberate registry edit, visible as a `SPEC.md`
+  diff under `render --check`, and review is the gate for it — the same answer
+  the foot of this file reaches for a param whose value moves. The count pinned
+  beside each comparison is the independent term against the careless half of
+  that case and is not a claim to have closed it.
+
+  No engine code changed, no command or flag moved, and no `--json` field or
+  issue `code` was added: this is a self-requirement and a spec file. The entry
+  that proposed it was filed under `Under consideration` on 2026-09-01 from a
+  comparative read of `nostics` 1.2.0, promoted to `Planned` the same day once
+  re-measuring corrected its cost, and the correction is the reason it was
+  buildable immediately — it had priced a build coupling that `self/` already
+  carries, having considered only `tests/` and the consumer suite as homes.
+
+### Changed
+
+- **`uncovered-requirement` stops advertising an affordance that has never
+  existed.** The message read *"Add a scenario, or mark it deferred"*, and
+  `deferred` appears nowhere else in the project: not a field of
+  `RequirementSchema`, not a flag on any command, not a key in the report. The
+  troubleshooting section for the code quoted the message as its symptom and
+  then explained only the first half, because there is no second half to
+  explain. So the one place a reader looks when they hit this error named an
+  escape hatch, in shipped output, in every release to date. It now names the
+  two exits that exist — write a scenario, or delete the entry — and
+  troubleshooting says why there is no third: an id Attest holds is an
+  obligation it holds permanently.
+
+  **The trace of the affordance having been intended is kept rather than
+  deleted**, which is why this waited. `Considered and rejected` gains the
+  entry that found it (*Retiring a requirement*), and design §11 gains the
+  permanence as a property to design against rather than a gap awaiting a
+  mechanism. Rewording the message alone would have removed the only written
+  evidence that anybody ever meant to build the thing.
+
+  `Issue.message` is prose and not API, so no consumer branches on this and no
+  exit code moves; there is no `code`, `level` or `--json` field change and
+  nothing to bump.
+
+- **1.0: the CLI and `.` are frozen, and the freeze ships with the gates that
+  enforce it.** The line itself is at the head of this file under `What 1.0
+  freezes` — a stability promise a reader cannot find is not one — and this is
+  the release that makes it binding. Decided 2026-08-31, cut 2026-09-01.
+
+  **Frozen: the CLI — its commands, options and exit codes — and the root export
+  `.`.** `./define` is frozen with them, on seven releases. Both are frozen on
+  evidence that they had stopped moving rather than on intention: the CLI's last
+  change of shape was `--apply` on 2026-08-03, twelve releases before the
+  decision, and `src/index.ts` has had its export list edited in three commits
+  ever.
+
+  **Not frozen, explicitly: `./inspect`.** It shipped in `[0.9.2]` with two
+  releases and one adapter behind it, and freezing on one adapter is the
+  objection this project raises against every premature interface and does not
+  get to waive for its own. Stating the exclusion is the point: a version number
+  alone would have said the opposite.
+
+  **What the freeze costs is stated rather than discovered later.** Under 1.0 a
+  narrowing that closes a security hole takes a major, on whatever schedule a
+  hole is found. `[0.11.0]` is what made that price knowable — it recorded that
+  such a narrowing takes the bump its definition gives it, and that the
+  `callsAuthoringFn` fix would have been a 2.0 twenty-five days after a 1.0 cut
+  at the fourth breaking commit.
+
+  **The line was decided with neither frozen surface enforced by anything, and
+  that is no longer true.** A frozen surface with no gate on its shape is a
+  promise nothing enforces, and the measurement behind the decision recorded when
+  each surface last *moved*, never what would notice if it moved again. `ATX-86`
+  and `ATX-87` in this release close both halves: the eleven type-only names and
+  four values of the root export, read from the emitted declaration file and the
+  emitted JavaScript separately, and the seven commands and seventeen options of
+  the CLI, read from the help it prints. Neither existed when the line was
+  decided.
+
+  **The exclusion list is one item longer than the four surfaces, and the fifth
+  is the one that moved.** The workflow document `attest init` writes into an
+  adopter's repository is deliberately not frozen — it is a function of the
+  installed version, so freezing it would freeze the workflow the tool teaches.
+  A 0.9.1 → 0.11.0 upgrade report measured it at **110 changed lines over 9
+  hunks**, still stating a `never-red` ordering rule `[0.10.0]` withdrew, with
+  four gates green and nothing reporting it. What 1.0 does **not** do is make
+  that drift detectable; the question is open at the foot of this file, and the
+  release is explicit about it rather than quiet.
+
+  **1.0 settles what an adopter may build on and unblocks nothing else.** The
+  judgement schema and any retrieval surface over the archive stay under `Under
+  consideration` and are explicitly 1.x. The one adoption crossing both of
+  `[0.11.0]`'s breaking changes paid nothing — no file edited, no peer upgrade,
+  no gate going red — but that sample dodged both narrowings, so what is measured
+  is that the release cost a *conforming* adopter zero, not that either narrowing
+  is cheap. And what a release costs its adopters is not known on the day it is
+  cut, which the foot of this file records as a general rule and which applies to
+  this one: the freeze is cut on the strength of the line being **correct**, not
+  on evidence that it is **sufficient**.
+
+## [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
@@ -612,7 +1216,7 @@ not API.
   one scenario asserting the *discrimination* rather than two asserting each
   side, which fails now and still refuses an implementation that warns
   unconditionally later. This is the mechanism catching the exact defect class
-  the tautology entry under *Under consideration* is about, on the first change
+  the tautology entry at the foot of this file is about, on the first change
   it was ever pointed at, in the author's own work.
 
   *A second defect surfaced after `--apply` and is worth recording because
@@ -4206,7 +4810,8 @@ field moved.
   the record would not need to exist at all. So it is the one thing Attest writes
   that cannot be checked by regenerating it, and what stands in for that check is
   a reviewer. (The workflow document has no gate either, but that is a decision —
-  `init --check` was rejected, see below — not an impossibility.)
+  `init --check` was rejected, and has since been reopened at the foot of this
+  file — not an impossibility.)
   Landed in `troubleshooting.md#never-red` and under `attest archive` in the CLI
   reference (both languages), and in the workflow document `attest init` writes —
   where it also became a fourth entry in "things you must not do", beside editing
@@ -4418,9 +5023,10 @@ field moved.
   the first fix written: it makes both maps resolve, at 195 kB and 148 files, to
   serve stepping into the engine from an adopter's `node_modules` — which
   nothing has asked for, and which anyone auditing the reader would do from the
-  repository instead. This file has rejected `init --check`, `divergent-param`
-  and countable obligations for costing more than a demonstrated need, and that
-  standard does not bend for a packaging decision. Turning the two compiler
+  repository instead. This file has rejected `divergent-param` and countable
+  obligations for costing more than a demonstrated need — and rejected
+  `init --check` on the same standard, an entry since reopened on measured
+  drift — and that standard does not bend for a packaging decision. Turning the two compiler
   options off is the cleanest published output, since it leaves no dangling
   `sourceMappingURL` comment, but it also removes the maps from `dist/` here,
   where `verify self` runs through the built CLI and they are the only thing
@@ -5016,9 +5622,10 @@ every platform, which is what makes them work on Windows at all.
   than assumed: there isn't one, and that is the design.** A committed
   instruction file is a function of the installed version, so it does go stale on
   upgrade — but staleness only *costs* anything if the tool also ships a gate to
-  turn red about it, and `init --check` is rejected on its own terms under
-  "Considered and rejected", together with the exposure that leaves and the
-  backstop that keeps it small. What belongs here is what the absence of a gate
+  turn red about it, and `init --check` was rejected on its own terms, together
+  with the exposure that leaves and the backstop that keeps it small — an entry
+  since reopened at the foot of this file, on the first measurement of that
+  exposure and the failure of that backstop. What belongs here is what the absence of a gate
   bought: with none to serve there is no reason to keep the prose out of the file
   either, so it lives in the skill, where an agent reads it with no extra call,
   and a skill body is loaded on demand — a long document costs context only when
@@ -5894,69 +6501,215 @@ 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.
+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.
 
-**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.
+- **An outward-facing form of the judgement tables, so an adopter can run this
+  counter-pressure on their own registry.**
+  `tests/intent-rule-candidates.spec.ts` maintains four hand-judged tables over
+  this repo's registry and enforces their completeness. Design §11 records the
+  properties they defend and that nothing enforces any of them; what the tables
+  add is a counter-pressure holding for **one** registry whose authors agreed to
+  maintain it. An adopter got none of it, and the reason was sharper
+  than "nobody wrote it for them": the package exported `requirement`,
+  `scenario`, `defineRequirements`, `delta` and types, and nothing else.
+  `parseSpecs`, `findFiles` and `readRegistrySource` were internal, so an
+  adopter **could not enumerate their own scenario names** — the table's central
+  rot check, that a claimed scenario is one a spec really declares, was not
+  merely unwritten downstream but unreachable. **That half shipped under
+  `[0.9.2]` as `@am_shork/attest/inspect`** and is recorded at the foot of
+  this entry; what stays here is the schema built on top of it, and the three
+  blockers below are untouched by the export.
+  *The shape that makes it shippable at all is a split, not a feature.* The
+  engine can compute which ids exist, which statements match the universal
+  quantifier regex, which params are list-valued, and whether a named scenario
+  is declared — all four already, all statically. It cannot compute how many
+  obligations a requirement carries, what a quantifier ranges over, or whether a
+  scenario iterates a param. So the shippable object is **the enforcement, never
+  the judgement**: an opt-in `*.judge.ts` read by the same static reader and
+  under the same literal-only rule the registry is (it is metadata about
+  requirements under review, so `check` must execute nothing to read it), whose
+  contents are entirely the adopter's. Opting in is creating the file; once it
+  exists, `requirement-unjudged`, `orphan-judgement`, `unbound-site` and
+  `quantifier-unjudged` make it complete and keep it from rotting. The
+  asymmetry is the only way this can exist without Attest asserting a ground
+  truth it refuses to compute (§0), and it is the same asymmetry `never-red`
+  already runs on: the archive gate would owe judgement only for ids a change
+  ADDs, so a brownfield adoption is not blocked wholesale.
+  *One part of the existing table cannot ship in any form.* `DOMAINS.pin` comes
+  in two kinds — a scenario name, checkable against the AST, and a **source-text
+  fragment** grepped out of the spec file. The second is asserting on the
+  wording of somebody's test, which is the `Issue.message` category error under
+  another name. Only the scenario-name kind is exportable, and what that costs
+  is real: the grep is what caught a deleted pin that `toContain` had passed.
+  *Why no detector ships with it, and this is the part that is already
+  measured.* Three rule families were built and scored against the whole corpus
+  (86 entries, counting a fixture id once per registry file) before any was
+  written into the engine, which is the order `divergent-param` was originally
+  designed in the wrong way round. Every figure below is a quotation of the
+  suite's inline snapshots; the snapshot is the fresh copy, and this paragraph
+  is only ever as fresh as its last edit.
+  **(1) `compound-requirement`** — 34 requirements carry more than one
+  obligation, it flags 16, is **wrong about none**, and misses 18. Never wrong
+  and nearly blind, and the 18 are the form the coverage incentive actually
+  rewards: extra clauses under a single keyword. **(2) The widened variant** —
+  29 correct, but 14 wrong and still 5 missed, and it is silenced by deleting an
+  "and". A rule whose cheapest fix degrades the artifact it protects does not
+  ship, and its precision falls as the registry grows. **(3) `divergent-param`**
+  — 5 divergences on this repo, **all 5 judged wrong**, zero true positives ever
+  recorded. The `code` group now spans 19 ids, and the failure is structural
+  rather than a matter of naming: the key is built by discarding the evidence of
+  relatedness, so the one genuinely paired divergence in the group is the one it
+  cannot show, and the key has churned three times under `flag` on additions
+  that changed no verdict. A fourth candidate — the echo detector, scored at
+  half precision — belongs to the tautology-detector entry now under
+  *Considered and rejected* and is not re-quoted here, because a figure stated in two places goes stale in one. Taken together
+  these are the measured range of what a token or single-body detector over
+  prose can do here, and they are why the proposal is enforcement-only.
+  *What blocks the decision — three things.* **(1) One adapter.** This
+  repository's table is the only one that exists, and its author wrote both the
+  schema and every answer in it. By this project's own rule a second table is
+  what makes the seam real, and freezing a `Judgement` type now is deciding for
+  everyone from 34 requirements written by one person. **(2) The breaking form
+  of this was already rejected** — see *Countable obligations* below — and one
+  of its three reasons survives the separate-file shape intact: **nothing can
+  force the count to be true.** The other two do not survive, which is what is
+  new here: a separate artifact touches no `--json` field, no delta apply and no
+  `render` output, and completeness *across ids* is computable in a way
+  completeness *within* an obligation array never was. So this is a re-proposal
+  with one of three objections answered and the sharpest one standing.
+  **(3) `quantifier-unjudged` reuses a rejected detector as its trigger.**
+  Firing on the quantifier token was rejected below at 43% reach and 70% wrong;
+  the claim here is that the same regex is acceptable when it asks a question an
+  author discharges in one line (`over: 'values'`) rather than issuing a
+  verdict. That claim is untested on anyone who did not also write the regex.
+  *The half that is not blocked has shipped, under `[0.9.2]`.*
+  `@am_shork/attest/inspect` is one function answering what a project declares —
+  AST-only, no runner peer, landing on the existing static/executing boundary.
+  It ships no schema and decides nothing, which is why it could go ahead of the
+  three blockers rather than waiting on them. What it changes about this entry
+  is the *kind* of thing that is now missing: the mechanism is no longer
+  unreachable, only unwritten, so a second table is something an adopter can
+  build rather than something only this repository could.
+  *What would decide it:* one judgement table maintained by someone who did not
+  design it. If it comes back the same shape, the seam is real and the schema
+  follows; if it comes back different, `inspect` was the whole answer and the
+  schema never needs to exist. *(One came back on 2026-08-31, and the disjunction
+  above is too clean to survive it: partly the same shape, partly not, and the
+  same half is the contaminated half. The close of this entry is where that is
+  read.)*
+  **Nothing currently makes that table arrive, which is a separate problem from
+  the three blockers and the one that gates all of them.** Raised in a product
+  review of `[0.9.1]`–`[0.9.3]` on 2026-08-19. The deciding evidence is an
+  artifact only an adopter can produce, and the path to producing it is: a row in
+  the README's document table, then a 214-line page, then a hand pass over four
+  questions, then writing the two mechanical properties from a prose
+  description, then choosing to report back. Five voluntary steps with no
+  scaffold at any of them, against a decision this entry has been waiting on
+  since `[0.9.2]`. An entry blocked on evidence that no shipped surface asks for
+  is blocked indefinitely, and the wait is not itself evidence of anything.
+  *The proposal is scaffolding the mechanism while still withholding the answer,*
+  which is the same split `[0.9.2]` already made and not a retreat from it: an
+  `examples/` directory holding the completeness and rot-binding assertions with
+  **no columns** — the enumeration that forces a row, and the check that a named
+  scenario is one `inspectProject` really declares — and the judgement columns
+  left for the adopter to add. What the page withholds is this repository's four
+  columns, and that stays withheld; what it currently also withholds is the two
+  properties it names as *mechanical*, and those are the half where a copy is not
+  an echo, because their content is fixed and the fourth finding does not apply
+  to them.
+  *What blocks it.* Whether a skeleton with no columns is still a shape that
+  comes back as a copy — the page's argument is that a template makes the answer
+  return its own question, and it is untested whether an adopter reads an empty
+  frame as an invitation or as a form to fill in. And it is a second artifact
+  claiming to be runnable consumer usage of the public API, which `pre-commit-check`
+  §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 `[0.11.0]`, 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.
+  **Decided 2026-08-31: build the counting rule, and not the schema.** The
+  blocker was whether an empty frame reads as an invitation or as a form to fill
+  in, it could not be tested here, and a 0.9.1 → 0.11.0 upgrade report from
+  `mine-capablanca` tested it. The answer is **invitation**, and the report names
+  the sentence that did it: not the empty `interface Judgement`, which reads as a
+  stub and sent the reporter looking for what belonged in it, but the comment
+  above it — *"It ships with no columns, and that is the finished state of this
+  file rather than a gap in it."* Declaring the absence finished is what turns a
+  blank into a question, and it is the cheapest sentence in the example.
+  *The forcing move was one the build found rather than one it proposed.* The
+  instruction to add the first column as a **required** field made all 80 rows
+  stop compiling at once, and there was then no path back to green that did not
+  go through having an opinion about all 80 — *"a form gets partially filled in;
+  a type does not"*. That is the type-level forcing move described above,
+  working on somebody who did not write it.
+  *And the frame leaks in one place, which is a defect in the example rather
+  than in the idea.* `pin` is documented as not a judgement column and is the
+  only concrete field in the interface, so the reporter's first act was to
+  populate it for all 80 rows mechanically — *"there is a field, populate it"*.
+  Defensible, since it makes rot-binding bite for 80 rows instead of none, and
+  exactly the form-filling behaviour the frame exists to prevent. Generating
+  `pin` from `inspectProject` rather than leaving a field to be typed is the fix,
+  and it belongs in the example.
+  *What does **not** follow, and the report is why it does not.* Two of the three
+  columns that came back are the same shape as two of this repository's —
+  `clauses` is `OBLIGATIONS`, `quantifier` is a flattened `QUANTIFIED` — and it
+  is tempting to read that as the seam being real. It cannot be read that way:
+  the reporter names the `attest init` workflow document as prior influence, and
+  that document discusses quantifiers and param pinning at length. So the
+  convergence says **something** transmits those two ideas, and the document is
+  at least as likely a channel as the frame. What is uncontaminated is the third
+  column, `venue`, which has no counterpart here: nine of its rows record a
+  promise held by a Playwright suite Attest's scope does not reach. A column this
+  repository could not have written came back, which is a seam behaving like one.
+  *What to build is smaller than a schema, and the three things the reporter
+  wanted and did not get are its specification.* **(1) A counting rule for
+  "obligation" precise enough that two people count the same.** The report
+  distrusts its own `clauses` column above all the others and says why: two
+  tables that count differently are not comparable, which defeats the point of
+  there being a second one. A counting rule is content that does **not** depend
+  on the adopter — the same category as the two mechanical assertions — and it is
+  currently withheld along with the columns, which is the wrong side of the
+  split. **(2) A way to bind a clause to a scenario rather than a row.**
+  Rot-binding binds a row to *a* scenario; nothing binds the sixth obligation of
+  a six-clause requirement to anything, so a six-clauses-three-scenarios row is a
+  number a reader has to notice instead of an assertion that fails. **(3)
+  Somewhere for a row to say the promise is held where Attest cannot see it.**
+  Nine `ui-node` rows and a 902-line Playwright suite, citable only in prose.
+  *So what is planned is (1) and the `pin` fix, and (2) and (3) explicitly are
+  not.* (1) is a paragraph in the example, costs no engine surface, and is the
+  one thing that makes a second table comparable to the first — without it two
+  tables are two vocabularies and the seam cannot be read either way. (2) and (3)
+  are both new schema, and blocker **(1)** of the proposal above — one adapter —
+  is not answered by a report that is the second adapter's first hour. Two hours
+  of one agent is not two adapters. **The `*.judge.ts` schema stays undecided**,
+  and when it moves it will move on a second table that somebody has maintained
+  rather than built, which is a different measurement from the one that arrived.
 
 ## Under consideration
 
@@ -5970,259 +6723,6 @@ deletion. What each entry has to carry is the evidence currently blocking the
 decision, because that is what a re-proposal a year from now would otherwise
 have to gather again.
 
-- **An assertion that recomputes its expectation from the param the code under
-  test just read is a tautology, and nothing says so.** Reported by
-  `mine-capablanca`, which probed it by mutating the registry and running the
-  full gate on each mutation:
-
-  | mutation | who reads it | `check` | `verify` |
-  |---|---|---|---|
-  | `GEN-1.maxCandidatesPerPiece` 64 → 4 | scenario only | ok | **red** |
-  | `BOARD-1.boardSize` 10 → 12 | app + fixtures | ok | **red** |
-  | `BOARD-2.maxMines` 12 → **40** | app + assertion | ok | **green** |
-  | `BOARD-2.minMines` 9 → **1** | app + assertion | ok | **green** |
-
-  The mine-density band — the one number deciding whether that game is playable —
-  moved by 3.3× with the whole suite green, `check` silent, and `possible-drift`
-  correctly not firing, because a covering scenario *does* read the param.
-  **Read the third and fourth rows against the second, because that is the
-  finding.** The reporter's diagnosis was "app and spec both read it", but row 2
-  is app-and-spec and goes red. What distinguishes the green rows is narrower and
-  more useful: the assertion **derives its expectation from the same param the
-  code under test used**, so both sides move together and the comparison has no
-  independent term. Row 2's expectation lives in fixtures, which do not move when
-  the param does, and the mechanism works. So the failing condition is a property
-  of the assertion, not of who reads the value — which matters, because it means
-  the answer is a rule about how to write the assertion, and *not* the detector
-  the reporter proposed.
-  **What this falsifies is written in this file.** The rejection of a committed
-  params snapshot, below, closes on *"the mechanism that guards a param is a
-  scenario reading it, not a file recording it"* — a sufficiency claim, and rows
-  3 and 4 are counterexamples to it. A scenario reading the param is necessary
-  and not sufficient. That entry stays rejected on its own argument, which was
-  never about detection power, but its fallback clause is now known incomplete
-  and is annotated accordingly. The README's §"killer move" has the same shape:
-  it says noticing a param *moved* is `verify`'s job "only when a scenario asserts
-  on the value it read from `params`" — literally a necessary condition, and read
-  by an adopter as a sufficient one, with the very next line (*"Read the param
-  inside the assertion, not beside it"*) being the instruction that produces the
-  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
-  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".
-  **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
-  answer settles the other. What stays here is the detector.
-  *What blocks the decision — three things, all of them real.* **(1)** Every
-  mutation above is synthetic. Across 8 commits touching `*.reqs.ts` in that
-  repo, **no param value was ever modified** — every `params:` line in every diff
-  is an addition. So the hole is proven as a logical property and its frequency is
-  entirely unmeasured, from one greenfield repo. **(2)** The reporter's proposed
-  mechanism — a WARNING when one param id is read from both a spec and a non-spec
-  file — is the wrong shape twice over: it fires on row 2, which is correct usage
-  and goes red, and it would fire on the arrangement the README actively
-  recommends, which is §9's "usually wrong about staleness" failure mode again.
-  It also needs a static sweep of the whole project for `reqs['X'].params.y`,
-  far past the two registry readers' current surface. **(3)** No mechanism is yet
-  known that separates "the assertion pins this independently" from "the assertion
-  echoes it" without executing the scenario twice under different values — which
-  is mutation testing, a much larger thing to own. *One has since been built and
-  scored, and it does not lift this blocker.* The syntactic candidate — flag a
-  scenario whose expectation is derived from the param the code under test
-  consumed, decided inside one body without executing anything — flags 9 params
-  here, of which **4 are real echoes and 5 are pinned by something outside the
-  body it cannot see**. Under half precision, and the failure is the one
-  predicted above rather than a tuning problem: what pins a value is often a
-  fixture or a second derivation in another file, so a single-body detector is
-  looking in the wrong place by construction. The newest false positive is the
-  clearest instance — `ATX-79.subpath` is compared against `package.json`, which
-  is not the code under test and does not read the registry, so the independent
-  term is in another file entirely. Precision has fallen on every addition
-  measured so far, which is the direction that matters. The score is quoted from the
-  suite's snapshot and re-read with the judgement-table entry above, which is
-  where the same measurement is used for a different decision.
-  **The guidance half has shipped; this entry is now only about the detector.**
-  "Read the param inside the assertion" was insufficient and half-wrong as
-  written, and `[0.5.0]` replaces it everywhere it appeared — README, the
-  `init` skill, `possible-drift`, and design §11 — with what the evidence
-  supports: **the expectation must not be a function of the param the code under
-  test consumed**, pinned in a fixture, a literal, or a second independently
-  derived value. Row 2 is the worked example, and the reporter's own
-  `CHECK-2`/`FOG-3` fixes are the same move. It was held back once because
-  rewording the central claim of the tool is not a line appended; that is what
-  was then done, deliberately and in one pass.
-  **What stays undecided is the mechanism**, and all three blockers above are
-  untouched by the rewording: the frequency is still unmeasured from one
-  greenfield repo, the reporter's proposed detector is still the wrong shape
-  twice over, and nothing short of mutation testing separates an independent pin
-  from an echo. What the guidance does not do is close the hole — a tautological
-  assertion is still green, still silent, and still reachable — so this stays
-  here rather than moving to `Considered and rejected`: documenting a trap is
-  not the same as deciding not to detect it.
-  **Re-measured after `[0.7.1]` widened `params`, on this registry rather than
-  the reporter's — the first time this experiment has been run here.** Twelve
-  mutations, each followed by the whole gate. Two results matter, and they point
-  opposite ways.
-  *The shape is now reachable here, and the widening is why.* `self/render.spec.ts`
-  asserts `expect(md).toContain(JSON.stringify(kinds))` over the same
-  `payloadKinds` it feeds to the renderer — the expectation is a function of the
-  value under test, verbatim row 3, and it could not have been written before
-  the widening because the param could not be an object. The mechanism is
-  sharper than a frequency count and is the strongest thing this entry has
-  gained: **the prescribed remedy costs in proportion to the value's
-  complexity.** Same repo, adjacent files, same value shape — `ATX-7` pins two
-  numbers with literals and goes red; `ATX-63` would have had to hand-write a
-  rendered JSON block, so it echoed. Depth raises the defect rate and the cost
-  of avoiding it along one axis.
-  *And its cost here is nil, which is the honest other half.* Both composite
-  params are fixtures for the renderer and the validator; the numbers stand for
-  nothing, so the green is arguably correct. Blocker **(1)** is therefore only
-  half retired — the shape is reproduced in a second, mature repo, and the count
-  of *harmful* instances is still zero. Blocker **(2)** is reinforced rather than
-  weakened: all four green mutations were on params `src/` never reads, so the
-  reporter's "read from both a spec and a non-spec file" detector would have
-  flagged none of them. Blocker **(3)** is untouched.
-  *The frequency is no longer unmeasured, and it points away from building
-  anything.* Blocker **(1)** rested on 8 commits of one greenfield repo. Parsed
-  at every one of the **38** revisions that have touched this registry — all 38
-  readable by the current static reader, so nothing was skipped — the history is
-  **57 param keys added, 0 removed, and exactly 1 value changed**: `ATX-16.staticCommands`
-  gaining `status`. That single edit is a roster *widening*, the safe direction,
-  and it is on the one list that was already pinned, so it could not have been
-  made without updating the pin. Two independent codebases, one greenfield and
-  one at 64 requirements, and the event this whole entry is about has happened
-  zero times in either. What that argues is not that the hole is unreal — it is
-  reachable, demonstrated above — but that it is **rare and silent**, which is
-  the profile `divergent-param` was rejected on rather than the profile that
-  justifies an engine rule.
-  *The same number says the split-out fix below has also never been triggered.*
-  0 removals ever means no domain has ever been shortened here. Those pins close
-  a live *exposure*, not a live *loss*, and the case for them is that they cost
-  one line each against a failure with no symptom — not that anything was
-  currently broken.
-  *Blocker **(3)** assumed mutation testing was the only separator. A cheaper
-  candidate existed, has now been scored, and does not survive it.* The idea was
-  a **syntactic** discriminator over one test body — flag an assertion whose
-  expected value derives from a param that also reached the arrange/act part —
-  which is exactly the difference between the two cases the widening produced:
-  `renderMarkdown({params: {payloadKinds: kinds}})` … `toContain(JSON.stringify(kinds))`
-  against `expect(kinds.json.maxBytes).toBe(1_048_576)`. Scored the way
-  `divergent-param` should have been and was not: implemented in
-  `tests/intent-rule-candidates.spec.ts`, run over the specs that attest this
-  repo, and then **every param it fires on mutated with the whole gate run —
-  fifteen of them, one gate run each. Four went green; eleven went red.**
-  *Then the detector was found to be wrong, which is the more useful half.* Its
-  first implementation counted an identifier in any position as a read of a
-  local with that name, so `i.code` in `issues.map((i) => i.code)` looked like a
-  use of a param named `code` — and `code` is this repo's commonest param name.
-  Corrected to count reference positions only, it flags **8, not 15**, and the
-  seven it drops are exactly seven the mutations had already shown to be pinned
-  by `src/`. The honest score is therefore **4 of 8, not 4 of 15** — precision
-  50%, not 27%. The conclusion does not move, because it never rested on the
-  precision figure; what moves is how much of the original number was the
-  candidate failing and how much was the measurement being wrong, and that is
-  worth writing down rather than quietly restating.
-  The remaining false positives are not near-misses. They are independent terms
-  the detector cannot see: **the runtime is the term** — `ATX-14`'s
-  `inheritedKey` is `'toString'`, and a mutated spelling is not a prototype key
-  at all, so the behaviour under test changes; **`src/` is the term** —
-  `ATX-51`'s `code` is a second copy of a string the engine emits as a literal;
-  and **arithmetic is the term** — `threshold + 3` builds a derived expectation
-  that mutation breaks.
-  And the four true positives fail the second test, which is the one that
-  decides it: **none is harmful.** `ATX-10` and `ATX-3` assert that a value was
-  substituted or applied, where the identity of the number is not the
-  obligation; `ATX-51`'s is a path prefix and `ATX-63`'s a rendering fixture.
-  Telling those from a mine-density band that must not move is a judgement about
-  whether the value *means* anything — the ground truth §0 refuses to compute
-  for someone else's registry. **50% precision on the shape, 0% on the harm.**
-  Two limits on that number, stated because a score with an unstated method is
-  what this file exists to prevent. The mutation has **one direction per kind**
-  — numbers +1, lists drop-last, strings suffixed — and direction can decide the
-  verdict: `ATX-40.languages` is red at 2→3 and was green at 2→1 before it was
-  pinned, so the true-positive count is a floor. And **recall is unmeasured**:
-  the eight params mutated earlier that this detector does not flag all went
-  red, which is eight correct negatives and not a recall figure.
-  The detector and its verdict table are kept in the measurement suite, with the
-  reach recomputed on every run and the table asserted to cover exactly what
-  fires — because the reach figure quoted for `compound-requirement` went stale
-  in this very file for want of that.
-  *A scoping limit on all of the above.* This repo cannot settle blocker **(2)**.
-  `src/` reads no param at all — every `reqs[…].params` in it is a comment or a
-  doc string — so params here are test vocabulary, while in the reporter's repo
-  they are application constants the app itself consumes. The reporter's
-  detector keys on exactly that difference, so it is inert here and this corpus
-  is evidence neither for nor against it.
-  *What the re-measurement did find is a different defect, and it has been split
-  out below* — the entry is kept whole here because the two were measured in one
-  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
-  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
-  write it back, deliberately and with the reason recorded — REMOVED "cannot say
-  which comments belonged to the entry it deletes". So retiring one is a manual
-  registry edit, which is fine as a mechanism and says nothing about whether it
-  is ever the right move.
-  *What the growth actually costs, measured on this session rather than
-  estimated.* One small fix took: a requirement, its scenarios, a hand-judged
-  row in the `OBLIGATIONS` table, two inline snapshots, a `[Unreleased]` entry,
-  History rows in two languages, and a regenerated `SPEC.md`. That is
-  proportionate for a spec framework that has to dogfood — the ceremony *is* the
-  product being used on itself — and it is also a number that only goes up.
-  *What blocks the decision, and it is not the mechanism.* It is that "retire"
-  has at least three meanings this file has never had to separate: a requirement
-  that turned out **wrong** (which should leave a record of being wrong, and
-  `Considered and rejected` is where that already goes); one still **true** but
-  no longer worth a permanently-run scenario; and one **subsumed** by a later
-  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
-  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.
-  *The figures above were restated on 2026-08-08, and how they were wrong is
-  itself the section's own warning happening.* As filed on 2026-08-03 this entry
-  said "62 requirements and 160 scenarios, roughly 2.6 each" while closing on
-  "the number is 61" — an inconsistency inside one entry, and the closing half
-  was the right one. Re-measured at the entry's own commit with the current
-  parser: **61 requirements, 156 scenarios**, so both opening figures were wrong
-  on the day they were written, and only the ratio survived. Measured the same
-  way today it is 69 and 192, and the method is the same one `verify self`
-  prints — the control is that today's `self/` counted this way returns exactly
-  what the runner does, which is what makes the 2026-08-03 number trustworthy. The
-  cheap way — `grep -c 'scenario('` — answers 211 against today's true 192, and
-  is what would have been reached for: comments and prose count, which is the
-  `ATX-15` error again.
-  **What moved in five days sharpens the argument rather than dating it.** +8
-  requirements and +36 scenarios, concentrated in three sessions rather than
-  accrued at a rate, so nothing here is a trend line. The part worth keeping is
-  the ratio: 2.56 → 2.78. The cost of a requirement is not flat and it is not
-  falling, which is the premise the whole entry rests on, and it is the first
-  time this file has had two measurements of it to compare.
-  *A third measurement, on 2026-08-18, and it points the other way from the
-  second.* **79 requirements and 221 scenarios**, counted the way `verify self`
-  prints them, which is the control the 2026-08-08 restatement established. The
-  ratio runs 2.56 → 2.78 → **2.80**, so the step that carried the argument was
-  the first one and the second is **+0.015**, which is flat. The premise this
-  entry rests on now has one measurement for it and one against, and the honest
-  statement is the narrower one: per-requirement cost has held at about 2.8
-  scenarios across ten days and ten requirements. What is unchanged is the
-  absolute total, which only rises — that half of the argument is untouched, and
-  it was always the half about permanence rather than about acceleration. What is
-  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.
-
 - **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,
   so there is no middle. Reported by an adoption where `verify` takes **7m33s**
@@ -6256,8 +6756,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
@@ -6355,197 +6855,94 @@ have to gather again.
   and the second report of the same shape, which this measurement does not
   supply and does not replace.
 
-- **An outward-facing form of the judgement tables, so an adopter can run this
-  counter-pressure on their own registry.**
-  `tests/intent-rule-candidates.spec.ts` maintains four hand-judged tables over
-  this repo's registry and enforces their completeness. Design §11 records the
-  properties they defend and that nothing enforces any of them; what the tables
-  add is a counter-pressure holding for **one** registry whose authors agreed to
-  maintain it. An adopter got none of it, and the reason was sharper
-  than "nobody wrote it for them": the package exported `requirement`,
-  `scenario`, `defineRequirements`, `delta` and types, and nothing else.
-  `parseSpecs`, `findFiles` and `readRegistrySource` were internal, so an
-  adopter **could not enumerate their own scenario names** — the table's central
-  rot check, that a claimed scenario is one a spec really declares, was not
-  merely unwritten downstream but unreachable. **That half shipped under
-  `[0.9.2]` as `@am_shork/attest/inspect`** and is recorded at the foot of
-  this entry; what stays here is the schema built on top of it, and the three
-  blockers below are untouched by the export.
-  *The shape that makes it shippable at all is a split, not a feature.* The
-  engine can compute which ids exist, which statements match the universal
-  quantifier regex, which params are list-valued, and whether a named scenario
-  is declared — all four already, all statically. It cannot compute how many
-  obligations a requirement carries, what a quantifier ranges over, or whether a
-  scenario iterates a param. So the shippable object is **the enforcement, never
-  the judgement**: an opt-in `*.judge.ts` read by the same static reader and
-  under the same literal-only rule the registry is (it is metadata about
-  requirements under review, so `check` must execute nothing to read it), whose
-  contents are entirely the adopter's. Opting in is creating the file; once it
-  exists, `requirement-unjudged`, `orphan-judgement`, `unbound-site` and
-  `quantifier-unjudged` make it complete and keep it from rotting. The
-  asymmetry is the only way this can exist without Attest asserting a ground
-  truth it refuses to compute (§0), and it is the same asymmetry `never-red`
-  already runs on: the archive gate would owe judgement only for ids a change
-  ADDs, so a brownfield adoption is not blocked wholesale.
-  *One part of the existing table cannot ship in any form.* `DOMAINS.pin` comes
-  in two kinds — a scenario name, checkable against the AST, and a **source-text
-  fragment** grepped out of the spec file. The second is asserting on the
-  wording of somebody's test, which is the `Issue.message` category error under
-  another name. Only the scenario-name kind is exportable, and what that costs
-  is real: the grep is what caught a deleted pin that `toContain` had passed.
-  *Why no detector ships with it, and this is the part that is already
-  measured.* Three rule families were built and scored against the whole corpus
-  (86 entries, counting a fixture id once per registry file) before any was
-  written into the engine, which is the order `divergent-param` was originally
-  designed in the wrong way round. Every figure below is a quotation of the
-  suite's inline snapshots; the snapshot is the fresh copy, and this paragraph
-  is only ever as fresh as its last edit.
-  **(1) `compound-requirement`** — 34 requirements carry more than one
-  obligation, it flags 16, is **wrong about none**, and misses 18. Never wrong
-  and nearly blind, and the 18 are the form the coverage incentive actually
-  rewards: extra clauses under a single keyword. **(2) The widened variant** —
-  29 correct, but 14 wrong and still 5 missed, and it is silenced by deleting an
-  "and". A rule whose cheapest fix degrades the artifact it protects does not
-  ship, and its precision falls as the registry grows. **(3) `divergent-param`**
-  — 5 divergences on this repo, **all 5 judged wrong**, zero true positives ever
-  recorded. The `code` group now spans 19 ids, and the failure is structural
-  rather than a matter of naming: the key is built by discarding the evidence of
-  relatedness, so the one genuinely paired divergence in the group is the one it
-  cannot show, and the key has churned three times under `flag` on additions
-  that changed no verdict. A fourth candidate — the echo detector, scored at
-  half precision — belongs to the tautology entry above and is not re-quoted
-  here, because a figure stated in two places goes stale in one. Taken together
-  these are the measured range of what a token or single-body detector over
-  prose can do here, and they are why the proposal is enforcement-only.
-  *What blocks the decision — three things.* **(1) One adapter.** This
-  repository's table is the only one that exists, and its author wrote both the
-  schema and every answer in it. By this project's own rule a second table is
-  what makes the seam real, and freezing a `Judgement` type now is deciding for
-  everyone from 34 requirements written by one person. **(2) The breaking form
-  of this was already rejected** — see *Countable obligations* below — and one
-  of its three reasons survives the separate-file shape intact: **nothing can
-  force the count to be true.** The other two do not survive, which is what is
-  new here: a separate artifact touches no `--json` field, no delta apply and no
-  `render` output, and completeness *across ids* is computable in a way
-  completeness *within* an obligation array never was. So this is a re-proposal
-  with one of three objections answered and the sharpest one standing.
-  **(3) `quantifier-unjudged` reuses a rejected detector as its trigger.**
-  Firing on the quantifier token was rejected below at 43% reach and 70% wrong;
-  the claim here is that the same regex is acceptable when it asks a question an
-  author discharges in one line (`over: 'values'`) rather than issuing a
-  verdict. That claim is untested on anyone who did not also write the regex.
-  *The half that is not blocked has shipped, under `[0.9.2]`.*
-  `@am_shork/attest/inspect` is one function answering what a project declares —
-  AST-only, no runner peer, landing on the existing static/executing boundary.
-  It ships no schema and decides nothing, which is why it could go ahead of the
-  three blockers rather than waiting on them. What it changes about this entry
-  is the *kind* of thing that is now missing: the mechanism is no longer
-  unreachable, only unwritten, so a second table is something an adopter can
-  build rather than something only this repository could.
-  *What would decide it:* one judgement table maintained by someone who did not
-  design it. If it comes back the same shape, the seam is real and the schema
-  follows; if it comes back different, `inspect` was the whole answer and the
-  schema never needs to exist.
-  **Nothing currently makes that table arrive, which is a separate problem from
-  the three blockers and the one that gates all of them.** Raised in a product
-  review of `[0.9.1]`–`[0.9.3]` on 2026-08-19. The deciding evidence is an
-  artifact only an adopter can produce, and the path to producing it is: a row in
-  the README's document table, then a 214-line page, then a hand pass over four
-  questions, then writing the two mechanical properties from a prose
-  description, then choosing to report back. Five voluntary steps with no
-  scaffold at any of them, against a decision this entry has been waiting on
-  since `[0.9.2]`. An entry blocked on evidence that no shipped surface asks for
-  is blocked indefinitely, and the wait is not itself evidence of anything.
-  *The proposal is scaffolding the mechanism while still withholding the answer,*
-  which is the same split `[0.9.2]` already made and not a retreat from it: an
-  `examples/` directory holding the completeness and rot-binding assertions with
-  **no columns** — the enumeration that forces a row, and the check that a named
-  scenario is one `inspectProject` really declares — and the judgement columns
-  left for the adopter to add. What the page withholds is this repository's four
-  columns, and that stays withheld; what it currently also withholds is the two
-  properties it names as *mechanical*, and those are the half where a copy is not
-  an echo, because their content is fixed and the fourth finding does not apply
-  to them.
-  *What blocks it.* Whether a skeleton with no columns is still a shape that
-  comes back as a copy — the page's argument is that a template makes the answer
-  return its own question, and it is untested whether an adopter reads an empty
-  frame as an invitation or as a form to fill in. And it is a second artifact
-  claiming to be runnable consumer usage of the public API, which `pre-commit-check`
-  §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.
-
-- **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
-  above the requirement: the prefix is a convention, nothing allocates it, and
-  `duplicate-prefix` can only report a collision that already happened.
-  spec-kit's answer is a roadmap table — a stable id, an intent, a scope
-  boundary, dependencies — authored above the specs it decomposes into. That
-  comparison is stated here rather than referred to, because the entry that
-  introduced the spec-kit reading has since been built and now sits under
-  `[0.9.4]` as the `open` field: an entry whose evidence rests on a
-  neighbour is one a promotion silently empties.
-  *Two things have changed since that reading, and they point opposite ways.*
-  The proposal is **smaller** than it looked: the mechanism partly exists.
-  `loadRegistry` returns `prefixOwners` — first claim in sorted file order —
-  `merge.ts` uses it to decide which file an ADDED id belongs in, and
-  `apply-no-prefix-owner` already refuses a prefix nobody owns. So what is
-  proposed is declaration replacing inference, not a new layer. And it is
-  **weaker**: `/inspect` shipped in `[0.9.2]`, so the cross-repository half —
-  the one §11 says no command can see across — is now something an adopter
-  computes from two registries in about ten lines. Attest does not have to own
-  it to make it possible.
-  *What blocks the decision:* nobody has the problem. §11 states the cost
-  arrives "exactly when adoption succeeds: two teams sharing a registry have
-  someone owning prefix allocation by hand", and no such adoption has been
-  reported. Building the declared form now would be deciding prefix semantics
-  for everyone from one repository whose five prefixes — `ATX` and the four
-  fixture ones — are each declared by exactly one file, so the allocation
-  question this would answer has never been asked here.
-
-
-- **A merged requirement carries no trace of the change that produced it, and
-  the rename chain is the part actually lost.** `RequirementSchema` is
-  `statement`, `rationale`, `params`, `outOfScope`; the splice writes those and
-  nothing else, so after `--apply` no field and no sidecar records which change
-  introduced an id, which modified it, or that one id used to be another. The
-  delta that knew is in `archive/`, which nothing reads. Proposed from
-  OpenViking's `.relations.json`: links between memories live in a
-  directory-level sidecar, deliberately kept out of the content, and are
-  rendered on demand at retrieval time (`docs/design/memory-link-design.md`).
-  *The argument for the sidecar over a field is in their competitor analysis
-  rather than their design.* The same document reads GBrain, which writes links
-  into the page body, and records what that costs: rename a page and every
-  inbound link still points at the old slug, with fuzzy matching at the read end
-  as the only mitigation. A `supersedes:` or `introducedBy:` field on a
-  requirement would be that mistake in this repository's terms — the registry is
-  a literal and a single source (§2), and a field naming a folder that a later
-  rename can move is a second source with nothing comparing it against the
-  first. A derived index has no such copy to go stale: it is recomputed from the
-  archived deltas every time it is read.
-  *What blocks the decision, restated on 2026-08-19 because half of what was
-  filed here is no longer true.* This entry was blocked on the empty archive and
-  on the corpus being rename-free, and only the second still holds. `archive/`
-  now has a real change in it — the `open` field, put through the workflow the
-  same day — so the store this would index exists. Its delta carries `added` and
-  nothing else, measured rather than assumed, so a backlink index is still
-  testable only against fixtures for the operation it is actually about. Note
-  what that says about the odds of the blocker clearing on its own: `--apply`
-  refuses RENAMED outright, so no change this repository archives can ever
-  exercise a rename until that refusal is lifted, and lifting it is a separate
-  decision with its own reason (`splice.ts` — deleting an entry has no smaller
-  span to fall back to). The blocker is therefore not "waiting for a rename to
-  happen"; it is downstream of a refusal nobody has proposed removing. And one
-  question the OpenViking reading does not answer, which is whether the chain is
-  wanted at all. §7 applies
-  `RENAMED` to a `Map<id, Requirement>` and the old id is then simply gone —
-  deliberately, as far as anything written says. The case for recovering it is an
-  external reference that outlives the rename, a ticket or a commit message
-  naming a retired id, and nobody has reported one.
+  *The second report arrived on 2026-08-31 and it is not the second report this
+  entry asked for*, which is itself the finding. A 0.9.1 → 0.11.0 upgrade report
+  from `mine-capablanca` — the same adoption this entry was filed on, six weeks
+  later, now at 46 spec files, 170 scenarios and a `verify` median of **564
+  seconds** against the 7m33s originally reported — asks for nothing named here.
+  It does not ask for a selector.
+  *The cost claim reproduces a third time, and the speed argument is finished.*
+  `check` against `verify` on that project is **3,403 ms against 564,279 ms**,
+  and the reporter is careful that this is a lower bound on engine share rather
+  than an estimate of it, since `check` also pays a process start `verify` pays
+  once. Either way the direction is settled on a corpus eighteen times slower
+  than this one: over 99% of a `verify` there is that project's own search engine
+  running. A selector saves no engine work anywhere, and now on two registries.
+  *The parity argument — the one this entry called the strongest available —
+  could not be tested there, and why it could not is a fact about it.* That
+  project has **no `vitest.config.ts` and no `vite.config.ts`**, no spec
+  importing through an alias, and no DOM anywhere in its specs, so `config:
+  false` withholds nothing a direct run would have had. `--vitest-config` is
+  passed by no script and no pipeline; it never became necessary. That does not
+  refute the argument, it **bounds** it: the parity gap is real only for an
+  adopter carrying a config, the population is therefore smaller than "adopters",
+  and nobody has yet reported being in it.
+  *What that adoption does have is a divergence, and it is not the one this entry
+  predicted.* On the same tree, `npx vitest run` was 170/170 green while `attest
+  verify` reported `tests-red` on **two runs out of three**. The mechanism the
+  reporter reaches — labelled there as the strongest available inference and not
+  as an observation — is one scenario measured at **4,971 ms against Vitest's
+  undeclared 5,000 ms default**: 1.3 s alone, four times slower under suite
+  contention, and the only one of eleven scenarios over four seconds that
+  declares no explicit `timeoutMs`. That is `CLAUDE.md`'s own timing gotcha
+  arriving in somebody else's repository, where no `CLAUDE.md` carries it.
+  *So the residue of this entry is a different entry.* What that reporter needed
+  was not a way to run less; it was a way to learn **which** of 170 scenarios was
+  red, and `verify` cannot say. That is filed separately below rather than folded
+  in here, because a selector and a diagnosis are different artifacts and this
+  entry has already been narrowed twice by refusing to let them merge.
+  *What is left blocking this one, restated:* an adopter who carries a Vitest
+  config, and whose fast loop and verdict actually diverge because of it. That is
+  the whole of it. The stage-2 cost argument above is unchanged and still comes
+  from this repository rather than from a user.
+
+- **`verify` reports that the suite is red and cannot say which scenario, and
+  the documented way to find out fails in exactly the case that needs it.**
+  Filed 2026-08-31 from a 0.9.1 → 0.11.0 upgrade report from `mine-capablanca`.
+  `verify` and `archive` run the child suite with `quiet: true` because the CLI
+  renders its own report, so the whole of a failure is one `tests-red` issue with
+  no file, no scenario and no assertion — in the human output and in `--json`
+  alike. The standing answer is to run the suite yourself under Vitest's
+  reporter, which is what this repository does with `pnpm debug:self`.
+  *The report is that this answer is circular where it is needed.* On that
+  project `npx vitest run` was green, twice, on the same tree on which `verify`
+  was red two runs in three. Running the suite yourself reproduces nothing,
+  because the disagreement between the two runs **is** the failure. What the
+  reporter did instead was time every scenario in the suite, compare alone
+  against in-suite durations, and cross-reference which of the eleven scenarios
+  over four seconds declared no timeout. That is a defensible inference and the
+  report labels it as one; it is not a thing a tool should require.
+  *What separates this from the entry above is that nothing here is a selector.*
+  No scope, no partial verdict, no `--json` field naming what ran, no
+  `SCHEMA_VERSION` question. The run is exactly the run it already is, and what
+  changes is only how much of the child's output survives into the report.
+  *What blocks it — and the first blocker is the reason `quiet: true` is there.*
+  **(1)** The CLI renders its own report, and a child suite printing its own on
+  top of that is two reports disagreeing about their own format. Passing the
+  child's failures through means deciding what a `tests-red` issue carries — a
+  file, a scenario name, a message — and each is a new field with a
+  `SCHEMA_VERSION` question attached, which is the cheapest part to price first
+  because it decides whether this is additive at all. **(2)** A failure message
+  is somebody else's assertion text, and this project's rule is that
+  `Issue.message` is prose and never API. Carrying a Vitest assertion into an
+  `Issue` puts a third party's wording in the field consumers are told not to
+  branch on. That is either harmless or a category error and nobody has decided
+  which, and the decision is not obvious in either direction: the wording is not
+  Attest's to keep stable, which is an argument both for carrying it and against.
+  **(3)** The instance that produced this report may not be a diagnosis problem
+  at all. A scenario 29 ms under a default it never declared is a known trap with
+  a known fix, and the cheaper answers are for `verify` to name **the timeout it
+  imposed** when a scenario fails on time, or for the workflow document to say
+  that a scenario anywhere near the default needs an explicit `timeoutMs`. Both
+  are much smaller than passing failures through, and whether either covers the
+  general case is unmeasured, because n=1.
+  *What would move it:* a red `verify` on an adopter's tree whose cause is not a
+  timeout. Every instance anybody has is this one.
 
 - **Changing the value of an existing param passes no gate, and for seven of
-  them there is no record either.** Split out of the tautology entry at the
-  head of this section on 2026-08-18, where it was one sentence inside the
+  them there is no record either.** Split out of the tautology entry that
+  headed this section on 2026-08-18, and which is now under *Considered and
+  rejected*, where it was one sentence inside the
   reframing paragraph. It is a different question: that entry asks whether an
   assertion is a real comparison, this one asks what happens when the number
   itself moves, and neither answer settles the other. `archive` gates a
@@ -6580,203 +6977,288 @@ have to gather again.
   here disputes that or needs a second copy of the values. The observation is
   narrower: the **edit** is unremarkable to every gate, which is a different
   claim from the values being unguarded.
-  *What blocks the decision — and the first is the one that blocks the entry this
-  came from.* **(1)** Frequency is unmeasured, and the one corpus anybody has
-  looked at points at zero: across 8 commits touching `*.reqs.ts` in the
-  reporting repository, no param value was ever modified — every `params:` line
-  in every diff is an addition. A defect nobody has committed is a hazard rather
-  than a report. **(2)** No shape is obvious. A param edit is not a change, so
-  `archive` is the wrong place; making `check` notice one needs a previous value
-  to compare against, which is the rejected snapshot wearing a different hat. The
-  only mechanism needing no stored copy is review, and review already sees the
-  `SPEC.md` diff for 82 of the 89. **(3)** What is left after that is seven
-  params in one repository, and the right answer for the five that matter may be
-  nothing more than a line in `intent-quality.md` — the four things no gate is
-  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
-  as of `[0.9.3]` the CLI, `./define`, `./inspect`, the archive layout, the
-  judgement schema and any retrieval surface are all simultaneously open. Every
-  entry in this section that is blocked on an adopter — the judgement table above
-  being the sharpest — is asking someone to invest in a surface that is
-  documented as movable. That is a coherent thing to ask under 0.x and it is also
-  the reason the ask may never be answered.
-  *The proposal is a line rather than a milestone:* 1.0 freezes the CLI, `./define`
-  and `./inspect`, and everything currently blocked on an adopter's evidence —
-  the judgement schema, the backlink index, any archive retrieval — is explicitly
-  1.x. What that buys is not a version number; it is the only condition under
-  which "build your own counter-pressure on our export" is a reasonable thing to
-  ask of somebody.
-  *What blocks it.* Freezing `./inspect` five days after shipping it is freezing
-  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
-  measurement to date of anyone adopting either export.
-
-- **When one requirement carries several scenarios, some of those sets are
-  differential evidence and nothing in the model says which.** Prompted by an
-  external write-up (`columns.chicken-house.net`, 2025-11-10, "AI-First Testing
-  Workflow"), which ran one test case against a system's REST API and against its
-  web UI and found the empty-basket check implemented in the UI and absent from
-  the API. Neither run failed against its own expectation; the finding was that
-  two runs of the *same* case disagreed.
-
-  Attest already permits the arrangement — a `reqId` takes any number of
-  attesting scenarios, and `cover` asks only for ≥1. What it cannot see is the
-  difference between three scenarios covering three edges of one requirement and
-  three scenarios crossing three interfaces at the *same* edge. The second set
-  can be asserted to agree; the first cannot, and there is nothing to compare.
-  This repository runs the pattern on itself — `tests/static-registry.spec.ts`
-  asserts the two registry readers agree — so the structure is known to work
-  where the two adapters are known to be two adapters.
-
-  *What blocks it, in the order that decides it.* **The seam is unmeasured.** One
-  adapter is a hypothetical seam and two is a real one; nothing has been walked
-  to establish whether any adopted registry has a `reqId` whose scenarios
-  genuinely cross interfaces rather than covering one surface repeatedly. Until
-  that is counted this is a pattern observed in somebody else's codebase, and it
-  is cheap to count. **The fact is not in the model.** Which interface a scenario
-  crosses is recorded nowhere the engine reads, so supplying it means new
-  registry or spec surface — a per-scenario axis — paid for by every adopter
-  including all of the ones with a single interface, in the shape of a thing they
-  must learn not to write. Whatever carried it would also have to be a literal in
-  the AST, because `cover` executes nothing and that is not negotiable for it.
-  **There is no verdict to emit.** The engine cannot perform the comparison;
-  agreement between two runs is an assertion and assertions belong to the test.
-  The most it could report is that a requirement has scenarios on more than one
-  axis, which is information with no pass or fail attached — a new output
-  category rather than a new check. **And the prose alternative is untried.**
-  Apply the deletion test before the field: if the workflow document `init`
-  writes (§9) simply says that two scenarios crossing one requirement at
-  different interfaces should assert the same expectations, does the practice
-  happen anyway? If it does, the engine gained nothing and charged everyone a
-  field for it.
+  *Blocker **(1)** was answered on 2026-08-31, in the direction that opens the
+  entry rather than closing it.* It read that frequency is unmeasured and that
+  the one corpus anybody had looked at pointed at zero: 8 commits touching
+  `*.reqs.ts` in the reporting repository, every `params:` line in every diff an
+  addition. A 0.9.1 → 0.11.0 upgrade report from `mine-capablanca` re-ran that
+  count over the **41 revisions** that have touched the same registry, evaluating
+  the file at each revision and comparing key by key rather than reading diffs,
+  and it reads **2 keys added, 1 removed and 7 values changed**. The 8-commit
+  figure was a sample and not an answer; it is withdrawn here and in the
+  tautology entry under `Considered and rejected` that quoted it.
+  *One of the seven landed with nothing capable of objecting, and it is the
+  general case rather than an accident of that commit.* A single commit moved
+  `AI-14.sampledCandidates` from 8 to 3 and `AI-14.samplingTemperature` from 5 to
+  20, and its entire diff is a proposal, a delta, the registry and the
+  regenerated `SPEC.md`. **No spec file and no implementation file.** Nine
+  implementation modules in that project import the registry and read params out
+  of it at runtime, so the opponent's behaviour on the easy setting changed with
+  the suite green — the scenarios read the same two values the implementation
+  reads, so both sides moved together. `render --check` did not object and
+  structurally cannot: it enforces that the rendering *moved*, never that the
+  movement was intended. What caught it was a reviewer on ten lines of `SPEC.md`
+  diff, with a 63-line proposal beside it arguing for exactly that move.
+  *So review is the gate, and the second corpus says it holds for a reason
+  nothing enforces.* That registry is **58 of 58** params interpolated into their
+  own statement, against 82 of 89 — 92.1% — here. Every param edit there moves a
+  line of `SPEC.md`, which is why the commit above was visible at all, and the
+  reporter is explicit that nothing makes this true: `check` is at zero issues,
+  and a declared key that no statement interpolates is not a problem at any
+  severity. A 100% discipline held over 41 revisions with nothing behind it is
+  one careless commit away from being 98%.
+  *What blocks the decision now — and **(2)** has become the opposite of what it
+  said.* **(2) A shape is obvious, and it is small.** `check` already reports
+  `unbound-param` for a placeholder with no key; the reverse — a declared key no
+  statement interpolates — is reported at no severity, and it is the exact static
+  test for "this param's edit leaves no trace outside the line that changed". It
+  needs no previous value, so it is not the rejected snapshot wearing a hat: it
+  is a property of one revision. The nearest precedent is `rationale-placeholder`,
+  a WARNING deliberately below `hasError` so that an existing green registry
+  gains a line of output and keeps its exit code, and that is the level this would
+  take. **(3) What it would fire on here is the objection.** Five of this
+  repository's seven uninterpolated params are **structurally uninterpolatable** —
+  `ATX-7.payloadKinds` and `ATX-63.payloadKinds` are kind → payload tables,
+  `ATX-15.sortMethods`, `ATX-15.bannedApis` and `ATX-72.quotes` are lists, and
+  `non-scalar-interpolation` is the diagnostic that refuses a statement carrying
+  any of them. So the rule must exempt non-scalars, and what is left is
+  `ATX-15.comparator` and `ATX-26.code`: two params, in one repository, that
+  their author simply did not interpolate. A warning firing twice on its own
+  corpus and zero times on the only other one measured is a rule looking for a
+  population. And the exemption is the hole rather than a detail — the five it
+  must skip are precisely the shape §2 widened the params rule to cover
+  **because lists and tables are the most drift-prone constants there are**.
+  *What would decide it:* an adopter whose interpolation rate is below 100% and
+  whose uninterpolated params are scalars. Both corpora sit at the extremes —
+  58 of 58 there, and here the gap is almost entirely the shape the rule cannot
+  see — so nobody has yet measured the population it would serve. Until then the
+  answer for the five that matter may still be nothing more than a line in
+  `intent-quality.md`, the four things no gate is looking at already being that
+  page's subject and this being a fifth of the same kind.
+
+- **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.
+
+- **A freshness gate on the file `attest init` writes (`init --check`).**
+  Rejected 2026-08-19, and **reopened 2026-08-31 by the first measurement of the
+  exposure it was rejected on.** The rejection is kept below in full because it
+  is still the argument to beat, and what beat one of its two load-bearing claims
+  is a 0.9.1 → 0.11.0 upgrade report from `mine-capablanca`: the committed
+  `.claude/skills/attest/SKILL.md` in that repository, written by `init` at
+  0.9.1, differs from the 0.11.0 body by **9 hunks and 110 changed lines, 403
+  lines against 458**. It was found only because the reporter wrote a script
+  importing `workflowBody()` out of the installed build and diffed it. `check`,
+  `cover`, `verify` and `render --check` were all green with the document stale.
+  *The backstop is what failed, and it failed on the worst available case.* The
+  rejection's second claim is that every mistake a stale document can cause is
+  already a diagnostic with a fix hint — "a registry written the old way is
+  `registry-not-static`", so the agent corrects itself from the report. The stale
+  text here is `never-red`'s ordering rule, which `[0.10.0]` archived as
+  `evidence-not-ordering` on the grounds that the ordering was never in the
+  engine. An agent reading that document is told to do something the engine does
+  not require. Its behaviour is more conservative, not wrong-shaped, so **no
+  issue fires at any severity** — there is nothing to correct itself from,
+  because nothing it does is an error. The backstop covers a stale document
+  producing bad input. It does not cover a stale document producing unnecessary
+  work, and the second is what six weeks of drift actually produced.
+  *The first claim survives, and it is still the objection.* A gate on this file
+  does turn red on a change the user did not make and is cleared by a commit
+  containing no decision. Nothing in the report disputes that. What the report
+  supplies is the other side of the ledger, which the rejection priced as "one
+  honest and small exposure": 110 lines, over one upgrade, undetectable without
+  writing a script against `dist/`.
+  *And the property that makes `init` idempotent is the same one that makes the
+  drift invisible.* `skillContent()` and `workflowBody()` take no argument — not
+  the version, not the project — deliberately, so that re-running `init` after an
+  upgrade is always safe. The consequence is that the file carries **no version
+  stamp**: nothing in the adopter's repository records which version wrote it,
+  and *"Re-run `attest init` after upgrading"* — which the CLI prints once, at
+  `init` time, to a reader who is not upgrading — is only actionable by somebody
+  who already knows they need to. A diff against the installed build is not one
+  detector among several. It is the only one the file's own design permits.
+  *What is undecided is the shape, and the rejection narrows it rather than being
+  answered by it.* A red `init --check` in CI is the thing that was rejected, and
+  the report does not rehabilitate it: it would fail a fresh clone on somebody
+  else's release, which is the same standard `render --check` was held to when a
+  freshness gate that calls a fresh clone stale was called worse than no gate.
+  What was never proposed, and is not what the heading names, is a **notice on a
+  command the adopter is already running** — the same information at the cost of
+  no gate and no chore commit. Pricing that is the next step; it is not a
+  decision already taken, and it needs its own answer to which command, at what
+  level, and whether a WARNING nobody can clear without running `init` is a
+  chore in a diagnostic's clothes after all.
+  *What is still unmeasured:* whether the drift cost that reporter anything. 110
+  changed lines measures the document, not the work, and the report is explicit
+  that it did not run `init` and did not act on the withdrawn rule. Nobody has
+  yet followed a stale instruction and paid for it, and the rejection below is
+  entitled to that until somebody has.
+
+  The rejection, kept as it was written:
+
+  `render --check` is the obvious precedent and is the opposite case. A rendering
+  is a function of the *user's registry*, so its staleness means the user moved
+  intent without regenerating — a real signal, with the fix in their hands. The
+  skill is a function of the *installed version*, so a gate on it turns red on a
+  change the user did not make, and is cleared by a commit containing no decision.
+  That is a chore wearing a diagnostic's clothes, and a gate that cannot be about
+  anything the reader did is worse than no gate — the same standard 0.1.6 set when
+  it gave `render` no formatting options at all. An earlier draft of `attest init`
+  spent a second command, this gate and a second self-requirement on it. What that
+  would have bought is immunity to one honest and small exposure: an old file
+  describes an old workflow to an agent that trusts it. The backstop is that every
+  mistake it can cause is already a diagnostic with a fix hint — a registry
+  written the old way is `registry-not-static` — so the agent corrects itself from
+  the report, and `init` is idempotent, which makes re-running it the entire
+  update mechanism. Recorded here rather than left in the 0.3.0 entry that shipped
+  `init`, because the queue above depends on it: a gate is the first thing
+  proposed each time a new agent target is considered, and the answer must not
+  need re-deciding per target.
+
+  *One locator moved with the entry.* "The queue above" was written from inside
+  `Considered and rejected` and means the queue of agent targets, not the entries
+  now above this one; the point it makes — that the answer must not need
+  re-deciding per target — is unaffected by where the entry sits.
+
+- **A `fix` field on `Issue`, derived from `code` the way `docsUrl` is.** From
+  `nostics` 1.2.0 (vercel-labs), read 2026-09-01, whose `Diagnostic` carries
+  `why` / `fix` / `docs` as three fields rather than one prose message. Most of
+  what that library is for is already here and stricter — its docs link is
+  authored per code with a `docs: false` opt-out, ours is derived from the code
+  at render time and cannot be forgotten or disagreed with — so the `why`/`fix`
+  split is the one half of it this file has no answer for.
+  *What the roster says, and it is not what the proposal assumed.* The claim
+  filed was that a fix is either buried in prose or absent. Reading all 41
+  rendered messages in `docs/en/troubleshooting.md`: **11 state an action to
+  take** (`uncovered-requirement`, `never-red`, `orphan-test`, `open-unresolved`
+  and seven more), **5 state the constraint but not the action**
+  (`registry-no-default`, `non-scalar-interpolation`, `unknown-target`,
+  `compiler-unsupported`, `invalid-change-name`), and **25 state only what is
+  wrong** — `registry-not-static` is the whole of "Value is not a literal.", and
+  `tests-red`, `unbound-param`, `duplicate-requirement` and `possible-drift` are
+  the same shape. So the distribution is uneven and unenforced rather than
+  absent, which is a weaker premise than the one filed but a more precise one:
+  what is missing is not the text, it is anything that makes the text obligatory.
+  (Classified by reading. A first pass by pattern undercounted — it missed the
+  lowercase mid-sentence imperatives in `never-red` and `empty-spec` — and its
+  number is deliberately not quoted here.)
+  *The derivation argument holds, and it is the reason to file this at all.* 31
+  of the 41 codes appear as a `code: '…'` literal, across 43 sites; the other 10
+  are built by a ternary or handed through a variable, which is the shape
+  `types.ts` narrows `code` to `IssueCode` for rather than policing with a regex.
+  A `fix` authored at issue sites inherits that split and can be forgotten at any
+  of the 43. A `fix` keyed on `code` and resolved when a report is rendered
+  cannot be — it covers all 41 including the 10, which is exactly the argument
+  `docs.ts` already makes for the link, applied to the other half of the line.
+  *What blocks it is that the text would then exist four times.* Every one of the
+  41 codes already has a `**Solution**` block in `docs/en/troubleshooting.md` and
+  its counterpart in `docs/zh` — 41 sections each, checked by
+  `docs-consistency.spec.ts` for existence and by nothing for content. A `fix`
+  string makes a fourth statement of the same thing, and no gate can check the
+  four agree. That is the failure mode `docsUrl` was designed to avoid, arriving
+  through the field added next to it.
+  *And a surface the proposal had not counted: 80 Symptom blocks.* Each of the 41
+  sections opens with a fenced block quoting real output, in both languages — 82
+  blocks, of which **80 quote the terminal rendering** and would be dated the
+  moment `formatIssues` gains a `fix:` line. (The other two are `internal-error`,
+  whose Symptom is a `--json` document, so it is the one section a rendering
+  change leaves alone. It is worth naming rather than rounding away: it is the
+  same carve-out `docs-consistency.spec.ts` already makes for that code.) **No
+  test reads any of them** — that suite asserts the code-to-section
+  correspondence and the pinned docs URLs, and has no assertion over a Symptom
+  block at all — so nothing would demand the 80 edits and nothing would catch
+  them being skipped. The documentation cost is larger than the feature.
+  *What would move it.* Either a gate binding a code's `fix` to its `Solution`
+  section, so the fourth copy is checked rather than merely written — which would
+  also retire the 82-block exposure by making one of the two a function of the
+  other — or an adoption report that one of the 25 action-less messages actually
+  cost somebody a round trip. Without the first, this trades a derivable field for
+  an underivable duplicate.
+
+- **A Stop hook that will not let an agent end a turn while `check self` is red.**
+  From the same read: `nostics` ships `hooks/consume-diagnostic.mjs`, a Claude
+  Code Stop hook that reads the log its dev-server collector writes and returns
+  `{"decision": "block"}` with the diagnostic as the reason, so the agent keeps
+  working rather than stopping on a red application. Three details there are the
+  design and not the plumbing, and are the transferable part: it guards on
+  `stop_hook_active` so a blocked stop cannot loop; it feeds back **one**
+  diagnostic per turn rather than the whole log; and when it consumes one it drops
+  every other entry sharing that code and file, so a fault at twenty call sites is
+  one round trip and not twenty.
+  *Why the shape fits this repository specifically.* `CLAUDE.md`'s "Before
+  committing" and the whole of `pre-commit-check` are discipline: nothing runs
+  `check self` unless a person or an agent remembers to, and the repeat-grouping
+  that hook does by hand is something `formatIssues` already computes. `.claude/`
+  here holds five skills, no hooks and no `settings.json`, so this would be the
+  first of its kind rather than an extension of anything.
+  *Measured cost, 2026-09-01.* `node bin/attest.js check self --json` runs in
+  **1.04–1.57 s** over three consecutive runs; `status self --json` in 0.78 s.
+  That is paid at the end of every turn, which is the number to weigh rather than
+  the wall clock of a single invocation.
+  *What blocks it is the stale-`dist/` trap, and a hook is the worst place to meet
+  it.* `bin/attest.js` loads `dist/`, not `src/` — the Gotcha this repository
+  already keeps — so a Stop hook reports on the last build. After a `src/` edit it
+  blocks on a diagnostic the working tree has already fixed, or clears while the
+  tree is broken, and in both directions it is a gate arguing about a state nobody
+  is in. Either the hook builds first, adding seconds to every turn, or it runs the
+  engine from source and stops being the thing an adopter could copy.
+  *And the larger question it sits in front of.* If this is right here it is right
+  for an adopter, which makes it a question about what `attest init` writes rather
+  than about `.claude/` in this repository. A hook that can block an agent's stop
+  is a much larger commitment than a document, and the rejection quoted in full
+  inside the `init --check` entry in this section — the gate on the installed
+  skill's freshness — turned on exactly the distinction it needs:
+  a signal about work the reader actually did, against a chore the tool imposes. A
+  block on `check` is the first kind, which is the argument for it, and that
+  argument should be made explicitly rather than arrived at by shipping.
+  *What would move it.* Running it here, unshipped and repo-local, for a few weeks,
+  and counting how often it blocks on something that would otherwise have been
+  committed. If that count is zero the discipline was already working and the hook
+  is overhead; if it is not, the number is the case for `init` writing one.
 
 ## Considered and rejected
 
@@ -6788,6 +7270,814 @@ 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.
 
+### A backlink index over `archive/`, recording which change introduced or renamed an id
+
+Proposed from OpenViking's `.relations.json`, restated twice on measurement, and
+rejected 2026-09-01. It is kept as it was written under *Under consideration*,
+because what closed it is the argument the entry had already assembled against
+itself rather than anything that arrived afterwards; the closing paragraphs are
+at the foot of the entry.
+
+**A merged requirement carries no trace of the change that produced it, and
+the rename chain is the part actually lost.** `RequirementSchema` is
+`statement`, `rationale`, `params`, `outOfScope`; the splice writes those and
+nothing else, so after `--apply` no field and no sidecar records which change
+introduced an id, which modified it, or that one id used to be another. The
+delta that knew is in `archive/`, which nothing reads. Proposed from
+OpenViking's `.relations.json`: links between memories live in a
+directory-level sidecar, deliberately kept out of the content, and are
+rendered on demand at retrieval time (`docs/design/memory-link-design.md`).
+*The argument for the sidecar over a field is in their competitor analysis
+rather than their design.* The same document reads GBrain, which writes links
+into the page body, and records what that costs: rename a page and every
+inbound link still points at the old slug, with fuzzy matching at the read end
+as the only mitigation. A `supersedes:` or `introducedBy:` field on a
+requirement would be that mistake in this repository's terms — the registry is
+a literal and a single source (§2), and a field naming a folder that a later
+rename can move is a second source with nothing comparing it against the
+first. A derived index has no such copy to go stale: it is recomputed from the
+archived deltas every time it is read.
+*What blocks the decision, restated on 2026-08-19 because half of what was
+filed here is no longer true.* This entry was blocked on the empty archive and
+on the corpus being rename-free, and only the second still holds. `archive/`
+now has a real change in it — the `open` field, put through the workflow the
+same day — so the store this would index exists. Its delta carries `added` and
+nothing else, measured rather than assumed, so a backlink index is still
+testable only against fixtures for the operation it is actually about. Note
+what that says about the odds of the blocker clearing on its own: `--apply`
+refuses RENAMED outright, so no change this repository archives can ever
+exercise a rename until that refusal is lifted, and lifting it is a separate
+decision with its own reason (`splice.ts` — deleting an entry has no smaller
+span to fall back to). The blocker is therefore not "waiting for a rename to
+happen"; it is downstream of a refusal nobody has proposed removing. And one
+question the OpenViking reading does not answer, which is whether the chain is
+wanted at all. §7 applies
+`RENAMED` to a `Map<id, Requirement>` and the old id is then simply gone —
+deliberately, as far as anything written says. The case for recovering it is an
+external reference that outlives the rename, a ticket or a commit message
+naming a retired id, and nobody has reported one.
+*Measured against a second corpus on 2026-08-31, and it points the same way.* A
+0.9.1 → 0.11.0 upgrade report from `mine-capablanca` walked all 41 revisions of
+that project's single registry and all 49 of its archived changes: **80 ids have
+ever appeared in it and 80 are in it now — zero removed, zero renamed** — and
+neither `removed:` nor `renamed:` appears in non-empty form in any delta.
+Commit messages on every branch, the whole tree and the issue tracker were
+searched for id-shaped tokens the registry does not define. The external
+reference this entry waits for did not turn up in sixteen days and forty-nine
+changes.
+*One id did outlive itself, from the other direction, and the reason it was left
+alone is a mechanism this entry did not have.* `AI-10` has never been in that
+registry, and two committed documents discuss the gap it leaves. The archived
+proposal's stated reason for not renumbering to close it is that doing so "would
+mean re-recording a failing run against an implementation that already exists".
+So `never-red` prices a rename directly: an id cannot be renumbered without
+re-earning its evidence, and an author facing that bill chose to write about the
+hole instead. That is a second reason the corpus is rename-free, independent of
+`--apply`'s refusal, and it argues the rate **stays** at zero rather than that
+nobody has got round to it.
+*What this does to the entry:* nothing is refuted, and the blocker is now
+blocked twice over. It was already downstream of a refusal nobody has proposed
+removing; it is also downstream of an obligation that makes the operation
+expensive on purpose. An index over an event that two independent mechanisms
+discourage is an index over an empty set.
+*Rejected 2026-09-01, on the entry's own last sentence rather than on anything
+new.* What closes it is that the two mechanisms are not a coincidence of one
+corpus and not a stage adoption passes through. `--apply` refuses RENAMED for a
+reason recorded in `splice.ts` — deleting an entry has no smaller span to fall
+back to — and `never-red` prices the operation independently, since an id cannot
+be renumbered without re-earning its evidence. The second is the stronger of the
+two because it does not depend on a refusal anybody could lift: an author who
+faced that bill wrote about the hole `AI-10` leaves instead of closing it, which
+is the mechanism arguing the rate **stays** at zero rather than that nobody has
+got round to it. An index whose subject two independent mechanisms discourage is
+not waiting for evidence; it is waiting for a decision nobody has proposed, taken
+for reasons that have nothing to do with this.
+
+*What was measured, and it is the whole of the case against.* Across the second
+corpus: 80 ids have ever appeared and 80 are in it now, over 49 archived changes
+— zero removed, zero renamed — with neither `removed:` nor `renamed:` appearing
+in non-empty form in any delta. Commit messages on every branch, the whole tree
+and the issue tracker were searched for id-shaped tokens the registry does not
+define. The external reference this entry existed to serve is the one thing that
+would have justified it, and sixteen days and forty-nine changes produced none.
+
+*One structural consequence, recorded because it is a change to somebody else's
+entry.* Two open entries rested on `--apply`'s refusal of RENAMED; closing this
+one leaves **one**, the third meaning under *Retiring a requirement* below. That
+matters in the direction of not lifting the refusal: a decision with two
+dependents is easier to justify than a decision with one, and the count is now
+one. Both cross-references have been corrected rather than left to be inferred.
+
+*What would reopen it.* Not a report of the drift this entry describes — that
+report is what sixteen days and two corpora failed to produce. It reopens if
+`--apply`'s refusal of RENAMED is lifted for its own reason, because the
+operation then becomes available and the corpus stops being evidence about a
+population that cannot exist. That is the one event that changes the argument,
+and it is not this entry's to trigger.
+
+### A detector for an assertion that recomputes its expectation from the param under test
+
+Proposed 2026-08-03 from `mine-capablanca`'s report, carried through three
+re-measurements, and rejected 2026-08-31. The defect it describes is real and
+stays undetected: an assertion deriving its expectation from the same param the
+code under test consumed has no independent term, so the value can move with the
+suite green, `check` silent and `possible-drift` correctly not firing. *What
+killed it is the detector's own score, and that is now the whole of the case.*
+The one anybody built scores **50% on the shape and 0% on the harm**: of 8 flags, 4 are real echoes and
+none of the 4 is harmful, while the false positives are pinned by a term in
+another file that a single-body detector cannot see by construction. Precision
+fell on every addition measured.
+
+*The frequency half of this rejection was wrong on the day it was written, and it
+is withdrawn.* It read that frequency is "approximately zero across two
+codebases", on 8 commits in the reporting repository across which no param value
+was ever modified. A 0.9.1 → 0.11.0 upgrade report from `mine-capablanca` on
+2026-08-31 re-ran that count properly — all **41 revisions** of the same
+registry, the file evaluated at each and compared key by key rather than read out
+of diff hunks — and it comes back with **seven values changed**. Not
+approximately zero. The breakdown belongs to the param-value entry under `Under
+consideration` and is not re-quoted here, because a figure stated in two places
+goes stale in one. The 8-commit sample was what was reachable on the day and not
+an answer to the question, and quoting it as one is the failure this file's own
+method section warns about. 38 revisions of *this* registry with 57 keys added, 0
+removed and exactly 1 value changed still stands, and is now the outlier rather
+than the confirmation.
+
+*What that leaves is a rejection standing on one leg, deliberately.* A defect
+occurring seven times in six weeks in one adopting repository is not a hazard
+nobody has committed; it is a thing that happens. The detector is still refused,
+because scoring 0% on harm is a property of the mechanism that no frequency
+improves — a rule that flags four true echoes and is right about the danger of
+none of them is not made useful by there being more echoes to flag. Where the
+frequency finding goes instead is the param-value entry under `Under
+consideration`, which was always the entry about the move rather than about the
+assertion, and which the same report reinforces rather than settles.
+
+*And the reopening condition was very nearly met, which is worth recording
+precisely.* It asks for a param whose value moved, whose assertion echoed it, and
+where the move was **harmful**. The report supplies the first two in one commit:
+two `AI-14` params changed, the scenarios reading the same values the
+implementation reads, the whole suite green, and a diff containing no spec file
+and no implementation file at all. The third leg fails, and fails cleanly — that
+move was the entire point of the change, argued for in a 63-line proposal
+committed beside it. So the closest instance anybody has is a **correct** edit
+that no gate could have objected to, which is evidence about the gate and not
+about the assertion.
+
+*The guidance half is not what is rejected here.* `[0.5.0]` replaced "read the
+param inside the assertion" everywhere it appeared with what the evidence
+supports — the expectation must not be a function of the param the code under
+test consumed — and that shipped. What is rejected is the mechanism, and the
+hole stays open: a tautological assertion is still green and still silent.
+Documenting a trap is not detecting it, and this section is where that
+difference is recorded rather than hidden.
+
+*Two things this leaves standing, neither of them a mechanism.* Design §11
+carries the property in the reader's form, so an adopter meets it where the
+method is taught. And the detector stays in
+`tests/intent-rule-candidates.spec.ts` with its verdict table recomputed on
+every run: it is the evidence that killed this, and deleting it would leave the
+rejection resting on a figure nothing checks — the exact failure this file has
+already had once, when the reach quoted for `compound-requirement` went stale in
+it.
+
+*Reopening needs the one thing neither corpus supplied:* a param whose value
+moved, whose assertion echoed it, and where the move was **harmful**. Precision
+on the shape is a tuning question. Precision on the harm is the whole question,
+and telling a rendering fixture from a mine-density band is a judgement about
+whether the value *means* anything — which is the ground truth §0 refuses to
+compute for somebody else's registry. Nothing short of running each scenario
+twice under different values separates an independent pin from an echo, and that
+is mutation testing, a much larger thing to own.
+
+The claim and the measurements, kept as they were taken:
+
+**An assertion that recomputes its expectation from the param the code under
+test just read is a tautology, and nothing says so.** Reported by
+`mine-capablanca`, which probed it by mutating the registry and running the
+full gate on each mutation:
+
+| mutation | who reads it | `check` | `verify` |
+|---|---|---|---|
+| `GEN-1.maxCandidatesPerPiece` 64 → 4 | scenario only | ok | **red** |
+| `BOARD-1.boardSize` 10 → 12 | app + fixtures | ok | **red** |
+| `BOARD-2.maxMines` 12 → **40** | app + assertion | ok | **green** |
+| `BOARD-2.minMines` 9 → **1** | app + assertion | ok | **green** |
+
+The mine-density band — the one number deciding whether that game is playable —
+moved by 3.3× with the whole suite green, `check` silent, and `possible-drift`
+correctly not firing, because a covering scenario *does* read the param.
+**Read the third and fourth rows against the second, because that is the
+finding.** The reporter's diagnosis was "app and spec both read it", but row 2
+is app-and-spec and goes red. What distinguishes the green rows is narrower and
+more useful: the assertion **derives its expectation from the same param the
+code under test used**, so both sides move together and the comparison has no
+independent term. Row 2's expectation lives in fixtures, which do not move when
+the param does, and the mechanism works. So the failing condition is a property
+of the assertion, not of who reads the value — which matters, because it means
+the answer is a rule about how to write the assertion, and *not* the detector
+the reporter proposed.
+**What this falsifies is written in this file.** The rejection of a committed
+params snapshot, below, closes on *"the mechanism that guards a param is a
+scenario reading it, not a file recording it"* — a sufficiency claim, and rows
+3 and 4 are counterexamples to it. A scenario reading the param is necessary
+and not sufficient. That entry stays rejected on its own argument, which was
+never about detection power, but its fallback clause is now known incomplete
+and is annotated accordingly. The README's §"killer move" has the same shape:
+it says noticing a param *moved* is `verify`'s job "only when a scenario asserts
+on the value it read from `params`" — literally a necessary condition, and read
+by an adopter as a sufficient one, with the very next line (*"Read the param
+inside the assertion, not beside it"*) being the instruction that produces the
+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 `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
+answer settles the other. What stays here is the detector.
+*What blocks the decision — three things, all of them real.* **(1)** Every
+mutation above is synthetic. Across 8 commits touching `*.reqs.ts` in that
+repo, **no param value was ever modified** — every `params:` line in every diff
+is an addition. So the hole is proven as a logical property and its frequency is
+entirely unmeasured, from one greenfield repo. **(2)** The reporter's proposed
+mechanism — a WARNING when one param id is read from both a spec and a non-spec
+file — is the wrong shape twice over: it fires on row 2, which is correct usage
+and goes red, and it would fire on the arrangement the README actively
+recommends, which is §9's "usually wrong about staleness" failure mode again.
+It also needs a static sweep of the whole project for `reqs['X'].params.y`,
+far past the two registry readers' current surface. **(3)** No mechanism is yet
+known that separates "the assertion pins this independently" from "the assertion
+echoes it" without executing the scenario twice under different values — which
+is mutation testing, a much larger thing to own. *One has since been built and
+scored, and it does not lift this blocker.* The syntactic candidate — flag a
+scenario whose expectation is derived from the param the code under test
+consumed, decided inside one body without executing anything — flags 9 params
+here, of which **4 are real echoes and 5 are pinned by something outside the
+body it cannot see**. Under half precision, and the failure is the one
+predicted above rather than a tuning problem: what pins a value is often a
+fixture or a second derivation in another file, so a single-body detector is
+looking in the wrong place by construction. The newest false positive is the
+clearest instance — `ATX-79.subpath` is compared against `package.json`, which
+is not the code under test and does not read the registry, so the independent
+term is in another file entirely. Precision has fallen on every addition
+measured so far, which is the direction that matters. The score is quoted from the
+suite's snapshot and re-read with the judgement-table entry above, which is
+where the same measurement is used for a different decision.
+**The guidance half has shipped; this entry is now only about the detector.**
+"Read the param inside the assertion" was insufficient and half-wrong as
+written, and `[0.5.0]` replaces it everywhere it appeared — README, the
+`init` skill, `possible-drift`, and design §11 — with what the evidence
+supports: **the expectation must not be a function of the param the code under
+test consumed**, pinned in a fixture, a literal, or a second independently
+derived value. Row 2 is the worked example, and the reporter's own
+`CHECK-2`/`FOG-3` fixes are the same move. It was held back once because
+rewording the central claim of the tool is not a line appended; that is what
+was then done, deliberately and in one pass.
+**What stays undecided is the mechanism**, and all three blockers above are
+untouched by the rewording: the frequency is still unmeasured from one
+greenfield repo, the reporter's proposed detector is still the wrong shape
+twice over, and nothing short of mutation testing separates an independent pin
+from an echo. What the guidance does not do is close the hole — a tautological
+assertion is still green, still silent, and still reachable — so this stays
+here rather than moving to `Considered and rejected`: documenting a trap is
+not the same as deciding not to detect it.
+**Re-measured after `[0.7.1]` widened `params`, on this registry rather than
+the reporter's — the first time this experiment has been run here.** Twelve
+mutations, each followed by the whole gate. Two results matter, and they point
+opposite ways.
+*The shape is now reachable here, and the widening is why.* `self/render.spec.ts`
+asserts `expect(md).toContain(JSON.stringify(kinds))` over the same
+`payloadKinds` it feeds to the renderer — the expectation is a function of the
+value under test, verbatim row 3, and it could not have been written before
+the widening because the param could not be an object. The mechanism is
+sharper than a frequency count and is the strongest thing this entry has
+gained: **the prescribed remedy costs in proportion to the value's
+complexity.** Same repo, adjacent files, same value shape — `ATX-7` pins two
+numbers with literals and goes red; `ATX-63` would have had to hand-write a
+rendered JSON block, so it echoed. Depth raises the defect rate and the cost
+of avoiding it along one axis.
+*And its cost here is nil, which is the honest other half.* Both composite
+params are fixtures for the renderer and the validator; the numbers stand for
+nothing, so the green is arguably correct. Blocker **(1)** is therefore only
+half retired — the shape is reproduced in a second, mature repo, and the count
+of *harmful* instances is still zero. Blocker **(2)** is reinforced rather than
+weakened: all four green mutations were on params `src/` never reads, so the
+reporter's "read from both a spec and a non-spec file" detector would have
+flagged none of them. Blocker **(3)** is untouched.
+*The frequency is no longer unmeasured, and it points away from building
+anything.* Blocker **(1)** rested on 8 commits of one greenfield repo. Parsed
+at every one of the **38** revisions that have touched this registry — all 38
+readable by the current static reader, so nothing was skipped — the history is
+**57 param keys added, 0 removed, and exactly 1 value changed**: `ATX-16.staticCommands`
+gaining `status`. That single edit is a roster *widening*, the safe direction,
+and it is on the one list that was already pinned, so it could not have been
+made without updating the pin. Two independent codebases, one greenfield and
+one at 64 requirements, and the event this whole entry is about has happened
+zero times in either. What that argues is not that the hole is unreal — it is
+reachable, demonstrated above — but that it is **rare and silent**, which is
+the profile `divergent-param` was rejected on rather than the profile that
+justifies an engine rule.
+*The same number says the split-out fix below has also never been triggered.*
+0 removals ever means no domain has ever been shortened here. Those pins close
+a live *exposure*, not a live *loss*, and the case for them is that they cost
+one line each against a failure with no symptom — not that anything was
+currently broken.
+*Blocker **(3)** assumed mutation testing was the only separator. A cheaper
+candidate existed, has now been scored, and does not survive it.* The idea was
+a **syntactic** discriminator over one test body — flag an assertion whose
+expected value derives from a param that also reached the arrange/act part —
+which is exactly the difference between the two cases the widening produced:
+`renderMarkdown({params: {payloadKinds: kinds}})` … `toContain(JSON.stringify(kinds))`
+against `expect(kinds.json.maxBytes).toBe(1_048_576)`. Scored the way
+`divergent-param` should have been and was not: implemented in
+`tests/intent-rule-candidates.spec.ts`, run over the specs that attest this
+repo, and then **every param it fires on mutated with the whole gate run —
+fifteen of them, one gate run each. Four went green; eleven went red.**
+*Then the detector was found to be wrong, which is the more useful half.* Its
+first implementation counted an identifier in any position as a read of a
+local with that name, so `i.code` in `issues.map((i) => i.code)` looked like a
+use of a param named `code` — and `code` is this repo's commonest param name.
+Corrected to count reference positions only, it flags **8, not 15**, and the
+seven it drops are exactly seven the mutations had already shown to be pinned
+by `src/`. The honest score is therefore **4 of 8, not 4 of 15** — precision
+50%, not 27%. The conclusion does not move, because it never rested on the
+precision figure; what moves is how much of the original number was the
+candidate failing and how much was the measurement being wrong, and that is
+worth writing down rather than quietly restating.
+The remaining false positives are not near-misses. They are independent terms
+the detector cannot see: **the runtime is the term** — `ATX-14`'s
+`inheritedKey` is `'toString'`, and a mutated spelling is not a prototype key
+at all, so the behaviour under test changes; **`src/` is the term** —
+`ATX-51`'s `code` is a second copy of a string the engine emits as a literal;
+and **arithmetic is the term** — `threshold + 3` builds a derived expectation
+that mutation breaks.
+And the four true positives fail the second test, which is the one that
+decides it: **none is harmful.** `ATX-10` and `ATX-3` assert that a value was
+substituted or applied, where the identity of the number is not the
+obligation; `ATX-51`'s is a path prefix and `ATX-63`'s a rendering fixture.
+Telling those from a mine-density band that must not move is a judgement about
+whether the value *means* anything — the ground truth §0 refuses to compute
+for someone else's registry. **50% precision on the shape, 0% on the harm.**
+Two limits on that number, stated because a score with an unstated method is
+what this file exists to prevent. The mutation has **one direction per kind**
+— numbers +1, lists drop-last, strings suffixed — and direction can decide the
+verdict: `ATX-40.languages` is red at 2→3 and was green at 2→1 before it was
+pinned, so the true-positive count is a floor. And **recall is unmeasured**:
+the eight params mutated earlier that this detector does not flag all went
+red, which is eight correct negatives and not a recall figure.
+The detector and its verdict table are kept in the measurement suite, with the
+reach recomputed on every run and the table asserted to cover exactly what
+fires — because the reach figure quoted for `compound-requirement` went stale
+in this very file for want of that.
+*A scoping limit on all of the above.* This repo cannot settle blocker **(2)**.
+`src/` reads no param at all — every `reqs[…].params` in it is a comment or a
+doc string — so params here are test vocabulary, while in the reporter's repo
+they are application constants the app itself consumes. The reporter's
+detector keys on exactly that difference, so it is inert here and this corpus
+is evidence neither for nor against it.
+*What the re-measurement did find is a different defect, and it has been split
+out below* — the entry is kept whole here because the two were measured in one
+pass and separating them is the finding.
+
+### Retiring a requirement
+
+Filed 2026-08-03 on the cost of permanence, re-measured four times, and rejected
+2026-08-31 **by its own reopening condition**. The entry nominated the test —
+reopen if the cost per requirement moves — and the ratio has read 2.56 → 2.78
+→ 2.80 → 2.82 scenarios per requirement across twenty-five days and
+twenty-four requirements. Three consecutive readings within 0.05 of each other
+are not a curve about to move, and the condition has now failed to trigger
+twice. The cost argument is therefore not waiting for evidence; it was answered
+in the negative by the thing the entry itself chose to be judged on.
+
+*The three meanings it ended by separating are why the rest closes rather than
+merely goes quiet.* **(1) A requirement that turned out wrong** was never a
+retirement — the record of being wrong belongs in this section, which is what
+this section is, and removing the id is a manual registry edit nobody has argued
+against. **(3) A requirement subsumed by a later one** is a rename, blocked
+downstream of `--apply`'s refusal of RENAMED (`splice.ts`: deleting an entry has
+no smaller span to fall back to). That is somebody else's blocker, and lifting it
+is a decision which is not this one. It was shared with the backlink-index entry
+until 2026-09-01, when that entry was rejected; this is now the only thing
+resting on the refusal. **(2) A requirement still true and no
+longer worth a permanently-run scenario** was the only one ever about cost, and
+it is the one the ratio answers.
+
+*What (2) left behind was a defect rather than a mechanism, and it is fixed.*
+`uncovered-requirement` read "Add a scenario, or **mark it deferred**", and
+`deferred` appeared nowhere else in the project — not a field, not a flag, not
+a schema key — so the escape hatch this meaning needs had been named in shipped
+output, in the one place a reader looks when they hit the error, since before
+anybody asked the question. `[Unreleased]` rewords it, troubleshooting now says
+what the second exit actually is, and design §11 records the permanence as a
+property to design against rather than a gap awaiting a mechanism. **This entry
+is where the trace of the affordance having been intended now lives**, which is
+why the rewording waited for the rejection instead of going in as a stray fix:
+changing the message first would have deleted the only written evidence that
+anybody ever meant to build it.
+
+*The permanence itself is not rejected and is not a defect.* Deleting an intent
+in order to save the scenario attesting it inverts the claim the whole tool
+exists to make. Reopening needs the case (2) names — a requirement whose intent
+is still true and whose scenario is genuinely not worth running — together with
+a mechanism that keeps the first while dropping the second. Nobody has proposed
+one, and the message that implied there already was one is the reason the
+question looked bigger than it is.
+
+The measurements, kept as they were taken:
+
+**Whether a requirement can ever be retired, and what it costs that none can.**
+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
+write it back, deliberately and with the reason recorded — REMOVED "cannot say
+which comments belonged to the entry it deletes". So retiring one is a manual
+registry edit, which is fine as a mechanism and says nothing about whether it
+is ever the right move.
+*What the growth actually costs, measured on this session rather than
+estimated.* One small fix took: a requirement, its scenarios, a hand-judged
+row in the `OBLIGATIONS` table, two inline snapshots, a `[Unreleased]` entry,
+History rows in two languages, and a regenerated `SPEC.md`. That is
+proportionate for a spec framework that has to dogfood — the ceremony *is* the
+product being used on itself — and it is also a number that only goes up.
+*What blocks the decision, and it is not the mechanism.* It is that "retire"
+has at least three meanings this file has never had to separate: a requirement
+that turned out **wrong** (which should leave a record of being wrong, and
+`Considered and rejected` is where that already goes); one still **true** but
+no longer worth a permanently-run scenario; and one **subsumed** by a later
+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 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.
+*The figures above were restated on 2026-08-08, and how they were wrong is
+itself the section's own warning happening.* As filed on 2026-08-03 this entry
+said "62 requirements and 160 scenarios, roughly 2.6 each" while closing on
+"the number is 61" — an inconsistency inside one entry, and the closing half
+was the right one. Re-measured at the entry's own commit with the current
+parser: **61 requirements, 156 scenarios**, so both opening figures were wrong
+on the day they were written, and only the ratio survived. Measured the same
+way today it is 69 and 192, and the method is the same one `verify self`
+prints — the control is that today's `self/` counted this way returns exactly
+what the runner does, which is what makes the 2026-08-03 number trustworthy. The
+cheap way — `grep -c 'scenario('` — answers 211 against today's true 192, and
+is what would have been reached for: comments and prose count, which is the
+`ATX-15` error again.
+**What moved in five days sharpens the argument rather than dating it.** +8
+requirements and +36 scenarios, concentrated in three sessions rather than
+accrued at a rate, so nothing here is a trend line. The part worth keeping is
+the ratio: 2.56 → 2.78. The cost of a requirement is not flat and it is not
+falling, which is the premise the whole entry rests on, and it is the first
+time this file has had two measurements of it to compare.
+*A third measurement, on 2026-08-18, and it points the other way from the
+second.* **79 requirements and 221 scenarios**, counted the way `verify self`
+prints them, which is the control the 2026-08-08 restatement established. The
+ratio runs 2.56 → 2.78 → **2.80**, so the step that carried the argument was
+the first one and the second is **+0.015**, which is flat. The premise this
+entry rests on now has one measurement for it and one against, and the honest
+statement is the narrower one: per-requirement cost has held at about 2.8
+scenarios across ten days and ten requirements. What is unchanged is the
+absolute total, which only rises — that half of the argument is untouched, and
+it was always the half about permanence rather than about acceleration. What is
+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. *That held until the entry itself closed, and no
+longer applies:* the trace is the paragraph above, the rejection is what makes
+it durable, and `[Unreleased]` rewords the message. The condition on the
+rewording was never that it stay wrong — it was that somewhere else had to say
+the affordance had been meant first.
+
+**(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 carried until
+that entry was rejected on 2026-09-01. Two open entries rested on that one
+refusal and now **one** does, which is worth knowing and cuts the other way from
+how it was first written: a decision with two dependents is easier to justify
+than a decision with one, so the case for ever lifting the refusal got weaker
+rather than the blocker getting closer to clearing. This entry is not the reason
+the refusal exists, and it is now the only thing waiting on it.
+
+*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.
+
+### Declared prefix ownership instead of inferred
+
+Filed 2026-08-19 from a spec-kit reading, rejected 2026-08-31 on the two things
+that moved under it. *What rejected it: the proposal is smaller than it looked,
+weaker than it looked, and answers a question nobody here has asked.*
+`loadRegistry` already returns `prefixOwners`, `merge.ts` already uses it to
+place an ADDED id, and `apply-no-prefix-owner` already refuses a prefix nobody
+owns — so what was proposed is declaration replacing inference, not a new
+layer. And `/inspect` shipped in `[0.9.2]`, so the cross-repository half — the
+one §11 says no command can see across — is now about ten lines of an
+adopter's own code over two registries. Attest does not have to own it to make
+it possible.
+
+The third is what decides it. This repository's five prefixes — `ATX` and the
+four fixture ones — are each declared by exactly one file, so the allocation
+question a declaration would answer has never arisen here. Building it now is
+deciding prefix semantics for everyone from a corpus in which those semantics
+are unexercised, which is the objection this project raises against every
+premature interface.
+
+§11 keeps the property in place unchanged: one flat global id space, the
+prefix a convention rather than a scope, and `duplicate-prefix` able only to
+report a collision that already happened. **The cost still arrives exactly when
+adoption succeeds** — two teams sharing a registry have somebody allocating
+prefixes by hand — and that is the reopening condition. It is also the
+condition the two-party audit entry under consideration would satisfy, so the
+first adopter who shares a registry decides both.
+
+The reading this was filed from, kept as it was written:
+
+**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
+above the requirement: the prefix is a convention, nothing allocates it, and
+`duplicate-prefix` can only report a collision that already happened.
+spec-kit's answer is a roadmap table — a stable id, an intent, a scope
+boundary, dependencies — authored above the specs it decomposes into. That
+comparison is stated here rather than referred to, because the entry that
+introduced the spec-kit reading has since been built and now sits under
+`[0.9.4]` as the `open` field: an entry whose evidence rests on a
+neighbour is one a promotion silently empties.
+*Two things have changed since that reading, and they point opposite ways.*
+The proposal is **smaller** than it looked: the mechanism partly exists.
+`loadRegistry` returns `prefixOwners` — first claim in sorted file order —
+`merge.ts` uses it to decide which file an ADDED id belongs in, and
+`apply-no-prefix-owner` already refuses a prefix nobody owns. So what is
+proposed is declaration replacing inference, not a new layer. And it is
+**weaker**: `/inspect` shipped in `[0.9.2]`, so the cross-repository half —
+the one §11 says no command can see across — is now something an adopter
+computes from two registries in about ten lines. Attest does not have to own
+it to make it possible.
+*What blocks the decision:* nobody has the problem. §11 states the cost
+arrives "exactly when adoption succeeds: two teams sharing a registry have
+someone owning prefix allocation by hand", and no such adoption has been
+reported. Building the declared form now would be deciding prefix semantics
+for everyone from one repository whose five prefixes — `ATX` and the four
+fixture ones — are each declared by exactly one file, so the allocation
+question this would answer has never been asked here.
+
+### 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.
+
+*The counts above are the 2026-08-28 measurement and have since moved; recounted
+2026-08-31.* `Considered and rejected` holds **27 `###` entries**, not 24 —
+entries were decided into it in the meantime, and `init --check` left it,
+reopened — and `Under consideration` holds **six** bullets, not twelve. The
+heading ratio is deliberately not recounted: judging a heading artifact-shaped is
+a hand call, so re-running it would be a new measurement rather than a repair of
+this one, and the entry rests on the argument rather than on the ratio. What the
+recount does settle is the aside above about the section next door — at six
+bullets the case for giving it headings is weaker than it was at twelve, not
+stronger.
+
+### A per-scenario axis recording which interface a scenario crosses
+
+Prompted by an external write-up (`columns.chicken-house.net`, 2025-11-10, "AI-First
+Testing Workflow"), which ran one test case against a system's REST API and
+against its web UI and found the empty-basket check implemented in the UI and
+absent from the API. Neither run failed against its own expectation; the finding
+was that two runs of the *same* case disagreed. Attest already permits the
+arrangement — a `reqId` takes any number of attesting scenarios — but cannot
+tell three scenarios covering three edges of one requirement from three
+scenarios crossing three interfaces at the *same* edge. The second set can be
+asserted to agree; the first has nothing to compare. The proposal was to put
+that fact in the model, as a per-scenario axis that would have to be a literal
+in the AST, because `cover` executes nothing.
+
+Filed 2026-08-22 with four blockers, and rejected on 2026-08-28. **The blocker
+that decides it needed no measurement, and the one that was measured came back
+at the floor.**
+
+**There is no verdict to emit, and that is fatal on its own.** The engine cannot
+perform the comparison: agreement between two runs is an assertion, and
+assertions belong to the test. The most any axis could report is that a
+requirement has scenarios on more than one of them — information with no pass or
+fail attached, a new output *category* rather than a new check. So the field
+would be a thing every adopter has to learn about, including all of the ones
+with a single interface, in exchange for a report that decides nothing. This
+holds whatever the frequency turns out to be, which is why it is stated first.
+
+**And the frequency, counted because the entry said it was cheap to count and it
+was.** Over `self/` through `inspectProject`: 84 requirements, all covered, **69
+carrying two or more scenarios**, of which 6 have scenarios in more than one
+spec file. Over the seventeen fixture projects: 15 ids, 6 multi-scenario, **0**
+cross-file. Cross-file is only a proxy — nothing records which interface a
+scenario crosses, which is the entry's own point — so all 6 were read by hand,
+and **exactly one is the shape**: `ATX-60`, whose statement says the `--json`
+`ok` and the human verdict printed beside it are decided by one predicate
+"never by a second spelling of that question", with `json.spec.ts` and
+`report.spec.ts` asserting the two surfaces separately.
+
+*How the other five fail is the useful half.* `ATX-14` and `ATX-63` pair the
+validator with the renderer, which is two **different obligations** of one
+requirement — one reports the bad placeholder, the other omits it — so there is
+nothing to compare. `ATX-15` is five edges of one ordering rule. `ATX-80` is one
+interface run against a fixture and against a change the suite really archived.
+`ATX-25` is the near-miss worth naming: `pipeline.spec.ts` checks the producer
+and `json.spec.ts` the serialised report, which is one pipeline observed at two
+**layers** — downstream-coupled, so they cannot independently disagree, and
+independence is the property differential evidence is made of.
+
+*The finding that carries more than the count.* This repository's own canonical
+instance of the pattern — `tests/static-registry.spec.ts`, the two registry
+readers required to agree, cited in `CLAUDE.md` as what makes that seam real —
+is bound to **no requirement id at all**. It is in the engine suite, outside
+`self/`'s registry, and the only `requirement(` in it is a string fixture. A
+repository that runs the pattern deliberately, and says so in its own design
+vocabulary, contributes zero rows to a count of it. The rate is 1 in 69, and the
+one is weaker than the pair that prompted the entry.
+
+**What survives, and it is the part that costs nothing.** The deletion test the
+entry proposed is untried and is now the cheaper half by a wide margin: if the
+workflow document `init` writes (§9) simply says that two scenarios crossing one
+requirement at different interfaces should assert the same expectations, the
+practice may happen anyway — in which case the engine would have gained nothing
+and charged everyone a field for it. That sentence needs no decision
+infrastructure and is not what this rejects. The permanent property the
+rejection leaves in place — that Attest cannot distinguish covering N edges from
+crossing N interfaces, so a fully-covered requirement says nothing about how
+many surfaces were asked — is recorded in design §11 rather than only here.
+
+**What this rejection does not claim.** One corpus, and the limit `[0.9.2]`
+states about this repository applies: the two-adapter arrangements it has are
+engine-internal, so the count measures Attest's habits rather than an adopter's.
+The prompting report is from a real system nobody here can walk. What is
+corpus-independent is the first argument — no verdict to emit — and that is what
+this is rejected on. A reporter whose registry has the shape at a rate that
+makes a **descriptive** output worth having would be re-opening a different
+proposal, not this one.
+
 ### Rewriting the placeholder scan in `prose` to drop its tail slice
 
 Priced on 2026-08-21, during a standing sweep for more of the ATX-59 shapes, and
@@ -7010,7 +8300,7 @@ releases behind a blocker stated as "the mapping is unavailable", which was
 true and was about a mapping nothing needed; the evidence it carried was about
 the right problem and the mechanism it proposed was not, and nothing rereads a
 blocker that has already been written down. That is the same failure the
-section's own preamble records about a figure nobody re-checks, one level up:
+`How an entry is re-measured` records about a figure nobody re-checks:
 the *shape* of the proposal goes stale as quietly as its numbers do.
 *What is left of this entry is only the original question* — whether `check`
 and `verify` should refuse a half-loaded registry outright, the way `cover`
@@ -7368,26 +8658,18 @@ 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.
 
-### A freshness gate on the file `attest init` writes (`init --check`)
-
-`render --check` is the obvious precedent and is the opposite case. A rendering
-is a function of the *user's registry*, so its staleness means the user moved
-intent without regenerating — a real signal, with the fix in their hands. The
-skill is a function of the *installed version*, so a gate on it turns red on a
-change the user did not make, and is cleared by a commit containing no decision.
-That is a chore wearing a diagnostic's clothes, and a gate that cannot be about
-anything the reader did is worse than no gate — the same standard 0.1.6 set when
-it gave `render` no formatting options at all. An earlier draft of `attest init`
-spent a second command, this gate and a second self-requirement on it. What that
-would have bought is immunity to one honest and small exposure: an old file
-describes an old workflow to an agent that trusts it. The backstop is that every
-mistake it can cause is already a diagnostic with a fix hint — a registry
-written the old way is `registry-not-static` — so the agent corrects itself from
-the report, and `init` is idempotent, which makes re-running it the entire
-update mechanism. Recorded here rather than left in the 0.3.0 entry that shipped
-`init`, because the queue above depends on it: a gate is the first thing
-proposed each time a new agent target is considered, and the answer must not
-need re-deciding per target.
+**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 marked block in the adopter's `AGENTS.md` / `CLAUDE.md`
 
@@ -7518,9 +8800,13 @@ was written expecting the uncovered case and the demonstrated one has a covering
 scenario. **What that changes here is nothing**: this entry was rejected on the
 population a snapshot fires on — every legitimate param edit, fix a commit with
 no decision in it — and that objection is untouched by the new evidence, which
-concerns detection the snapshot was never denied having. The live question moved
-to `Under consideration` above, where it belongs, because the mechanism now in
-question is a rule about assertions rather than a file beside the registry.
+concerns detection the snapshot was never denied having. The live question
+moved to `Under consideration`, because the mechanism then in question was a
+rule about assertions rather than a file beside the registry, and it has since
+been rejected in its own right — above in this section, on a frequency of about
+zero across two codebases and a detector scoring 0% on harm. So the hole both
+entries describe is now recorded as open with nothing watching it, which is a
+weaker position than either entry claimed on its own and is the honest one.
 
 ### Grouping `render`'s output by prefix
 
@@ -7712,11 +8998,89 @@ fallback to evaluation. The same answer applies here for the same reason.
 
 Worth reopening if an adopter's registry reaches a size where prefix grouping
 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.
+declared prefix ownership recorded above in this section — rejected on there
+being no adoption that needs it, which is the same condition this sentence
+supposes — 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
 
+[1.0.0]: https://gitlab.com/Pseudorca/attest/-/tags/v1.0.0
+[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