@am_shork/attest 0.11.0 → 1.0.0

package/CHANGELOG.md

@@ -7,11 +7,24 @@ 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
@@ -35,6 +48,224 @@ 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
@@ -985,7 +1216,7 @@ paragraph exists to make visible.
   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
@@ -4579,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
@@ -4791,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
@@ -5389,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
@@ -6272,6 +6506,211 @@ 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 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
 
 Candidates with **no decision yet**, between the two sections either side of it
@@ -6284,317 +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 `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.
-
-- **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.
-
-  **(3) A requirement subsumed by a later one**, where the scenario should move
-  rather than go. That is a rename, and `--apply` refuses RENAMED outright, with
-  the reason recorded in `splice.ts` — deleting an entry has no smaller span to
-  fall back to. So it is blocked downstream of a refusal nobody has proposed
-  lifting, which is the *same* blocker the backlink-index entry above carries.
-  Two open entries now rest on that one refusal, which is worth knowing: it makes
-  lifting it a decision with two dependents rather than one, and neither of them
-  is the reason it exists.
-
-  *So the entry narrows to one meaning.* (1) is answered, (3) is somebody else's
-  blocker, and what is actually open is (2) — whether a requirement can stop
-  owing a permanently-run scenario while keeping its intent, which is the one
-  case where deleting the intent to save the scenario inverts what the whole tool
-  claims. Nothing here says it should be built; what changes is that the question
-  is now one question.
-
 - **Running `verify` over a subset of the scenarios, and what a partial run may
   be allowed to say.** `verify` is all-or-nothing and `check` executes nothing,
   so there is no middle. Reported by an adoption where `verify` takes **7m33s**
@@ -6727,222 +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.
-  **Built under `[Unreleased]`, and the second of those two blockers was the
-  buildable one.** `examples/judgement-table/` is in the default suite, the
-  specifier is aliased rather than relativised so the file stays copyable
-  verbatim, and both assertions were shown to fail before it was called done.
-  So the category `pre-commit-check` §6 names now has exactly one member that a
-  gate reaches, and the page's three prose samples are still not it.
-  *Two things the build found that the proposal did not contain.* A third
-  assertion — `issues` empty, before either of the other two — which is not a
-  refinement but a hole: an unread registry file and a smaller project are the
-  same value, and the two completeness directions pass over both. It was found
-  by an invalid mutation during the bite test rather than by reasoning, which is
-  `How an entry is re-measured`'s question about what a repair makes reachable,
-  arriving from the other end. And a **type-level** forcing move the runtime
-  assertion cannot make: a required field added to `Judgement` fails every
-  existing row at compile time, so the schema-shaped half of "a row cannot
-  arrive unjudged" costs one line and no engine rule. That is worth noting
-  against blocker **(1)** above, which is about freezing a `Judgement` type:
-  what shipped freezes nothing, because the type is in the adopter's copy.
-  **What is untouched is the first blocker, and it is now the only thing between
-  this entry and its evidence.** Whether an empty frame reads as an invitation
-  or as a form to fill in is still untested, and cannot be tested here — the
-  people who would answer it are the ones who have not arrived. What the build
-  changes is only that the five voluntary steps are now four, and the one
-  removed was the one with a fixed answer. If the next report is still nobody,
-  the scaffold was not what was missing, and that is worth knowing too.
-
-- **Prefix ownership is inferred rather than declared, and the cost arrives only
-  when adoption succeeds.** Design §11 records that the id grammar has no level
-  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
@@ -6977,92 +6977,64 @@ 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.
-
-- **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 `How an entry is re-measured` records that **what
-  a release costs its adopters is not known on the day it is cut**. There is no
-  measurement to date of anyone adopting either export.
-
-  **Measured on 2026-08-28, before deciding anything. The one-adapter objection
-  splits rather than holds, and a prerequisite this entry does not name has
-  arrived on its own.**
-
-  *The surface has not been moving, which is not what "three releases in five
-  days each added public surface" suggests.* Each entry point's last change to
-  its exported shape, and how many releases have been cut since without touching
-  it:
-
-  | surface | last shape change | releases since |
-  |---|---|---|
-  | CLI commands and options | 2026-08-03 (`--apply`) | 12 |
-  | `.` — the index exports | 2026-07-26 | 19 |
-  | `./define` — public signatures | 2026-08-08 | 7 |
-  | `./inspect` | 2026-08-18 | 2 |
-
-  `src/index.ts` has had its export list edited in **three commits ever**, the
-  last of them five weeks ago. So "freezing on one adapter" is weak for the CLI
-  and `.` — nineteen and twelve releases of evidence that they have stopped
-  moving — and strong exactly where this entry puts it, on `./inspect`, which
-  has two releases, one adapter, and whose single post-shipping change was
-  additive. That argues for a line this entry does not currently offer:
-  **freeze what has stopped moving and explicitly do not freeze `./inspect`.**
-
-  *And the cost of any such line was demonstrated this week, unprompted.* The
-  Versioning section at the head of this file defines breaking to include
-  **rejecting previously-valid input**. There have been four breaking commits in
-  this project's history, the last on 2026-08-03 — and a fifth is sitting in
-  `[Unreleased]` as of 2026-08-28: the `callsAuthoringFn` binding fix, which is
-  breaking *because* it narrows what a static reader accepts, and which says so
-  about itself. Under 1.0 that is a **major** bump. A fix closing a wrong-answer
-  hole in the four commands documented as safe on an untrusted fork MR would
-  have had to ship as 2.0, twenty-five days after 1.0 — or not ship as written.
-
-  *So the decision has a prerequisite, and the prerequisite left this section.*
-  What a narrowing that closes a security hole costs a consumer is undefined,
-  and it is needed whether or not 1.0 is ever cut — so it is under `Planned`
-  above rather than here, where it would have been blocked on everything this
-  entry is blocked on. Until it exists a 1.0 would be promising something whose
-  price nobody has computed; what it does **not** do is unblock the rest of this
-  entry, which turns on evidence no measurement here can supply.
-
-  *What is still unmeasured is unchanged, and it is the whole of the rest.* No
-  adopter of either export, so the thing 1.0 is meant to buy — making "build
-  your own counter-pressure on our export" a reasonable ask — has no measurement
-  behind it in either direction. The `examples/` scaffold under `[Unreleased]`
-  is the other half of that ask and was the cheaper half. Whether the missing
-  half is the freeze, or was never the freeze, is what the next report answers.
+  *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
@@ -7112,6 +7084,182 @@ have to gather again.
   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
 
 Decisions **not** to build something, kept where they can be found before the
@@ -7122,6 +7270,611 @@ 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
@@ -7237,6 +7990,17 @@ 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
@@ -7907,27 +8671,6 @@ is the "cleared by deleting the word that triggered it" failure arriving without
 anyone trying to clear it, which strengthens the rejection rather than
 qualifying it.
 
-### A freshness gate on the file `attest init` writes (`init --check`)
-
-`render --check` is the obvious precedent and is the opposite case. A rendering
-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.
-
 ### A marked block in the adopter's `AGENTS.md` / `CLAUDE.md`
 
 The cross-tool convention Codex, Cursor and Copilot read, and the reason it
@@ -8057,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
 
@@ -8251,8 +8998,9 @@ 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
 
@@ -8331,6 +9079,7 @@ path the repair makes reachable; it is about **everything the repair would make
 
 ## 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