@am_shork/attest 0.11.0 → 1.1.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,466 @@ 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.1.0] - 2026-09-02
+
+### Added
+
+- **`ATX-89`, `ATX-90`, `ATX-91`: `check` reports a workflow document the
+  installed version no longer writes (`stale-workflow-doc`, INFO).** The
+  document `attest init` writes is a pure function of the installed version, and
+  the adopter's tree records nothing about which version wrote it —
+  `skillContent()` and `workflowBody()` take no argument, deliberately, because
+  that is what makes re-running `init` safe. So the file carries no version
+  stamp and a diff against the installed build is the only detector its own
+  design permits. Measured on a 0.9.1 → 0.11.0 upgrade report: **110 changed
+  lines across 9 hunks**, 403 lines against 458, found only because the reporter
+  wrote a script importing `workflowBody()` out of `dist/`, with `check`,
+  `cover`, `verify` and `render --check` all green.
+  *The level is an asymmetry of obligation rather than a severity judgement, and
+  that is the whole argument for it.* Keeping the document current is Attest's
+  obligation, because Attest is what changes it; taking the update is nobody
+  else's, because an adopter is free to run an older workflow, a modified one, or
+  none. A finding whose subject the reader owes nothing about is exactly the
+  finding that may only inform — so `ok`, the exit code and every gate are
+  untouched, and a reader who ignores this forever pays what they pay today.
+  *This is not `init --check`*, which stays rejected below. That gate turns red
+  on a diff the person who must commit it has no way to review: a regenerated
+  `SPEC.md` shows what **you** changed about your promises, and a regenerated
+  `SKILL.md` shows what Attest's authors changed. It also fires in CI, where
+  nobody can run `init`, blocking whoever pushes next for an upgrade somebody
+  else made.
+  *Three requirements because there are three ways to be wrong, and this file
+  already carves the identical problem up this way for renderings.* `ATX-89` is
+  the report; `ATX-90` is that an **absent** document draws nothing, which is the
+  one the obvious implementation breaks — `staleIssue` reports a rendering that
+  was never generated under its own code, and copying that here would fire on two
+  of this repository's own three targets and on the majority of adopters, since
+  `init` writes one target by default and nothing obliges a project to run it;
+  `ATX-91` is that the comparison is of the document rather than the bytes, which
+  is deliberately the **opposite** of `ATX-84` and could not be had by widening
+  `ATX-29`. `ATX-84` compares this repository's copy byte-for-byte and may,
+  because `.gitattributes` here is committed and pins `eol=lf` — that file is
+  Attest's here and nobody's in an adopter's tree, so one rule cannot cover both.
+  *What it costs, measured before it was built:* 0.234 ms for all three target
+  comparisons, plus 4.19 ms to import `targets.ts` and the 26 KB template behind
+  it, against a `check self --json` of 814–1,183 ms — **~0.5%**. No
+  `SCHEMA_VERSION` bump: the field exists, the value is new, and `ok` is
+  untouched because INFO is below `hasError`.
+  *Two things the build found that the proposal did not contain.* The fix hint
+  had to name what `init` does to the file and not only the command — `runInit`
+  writes with `writeAtomic`, no merge and no backup, so an adopter who edited
+  these instructions is being pointed at something destructive. `targets.ts`
+  rule 1 makes that defensible, Attest owning the path being the whole reason it
+  may overwrite, and it was nowhere stated to the reader. And the two negative
+  scenarios had to be **paired with the case that must fire**, in the same
+  scenario, because an absence assertion alone is green in a tree where nothing
+  is implemented — which is the defect `never-red` exists to name, arriving in
+  the scenarios written to attest a rule about not firing.
+  *One cost that is not paid and is stated rather than left to be discovered:*
+  this repository cannot dogfood it. `check` reads the project root, which here
+  is `self/`, while the document sits at the repository root — so `check self`
+  finds it absent and is correctly silent. `ATX-84`'s scenario reaches two
+  directories up because it is a test; a command cannot. All three scenarios
+  build a temporary project, and `self/` gives this rule none of the continuous
+  exercise `ATX-84` gets.
+  *What the judgement tables did with the three ids, since that is the
+  counter-pressure earning its place rather than a chore paid to it.* All four
+  demanded rows and got them. `compound-requirement` **missed `ATX-89`** — two
+  obligations, "reports it" and "at that level", and the keyword heuristic sees
+  one — which is the "never wrong, nearly blind" reading holding at 18 of 42
+  rather than a new finding. `divergent-param` produced a **new false positive
+  and re-keyed an old one**: `level` joins `code`, `file`, `flag` and `field` as
+  a fifth natural word for a kind of constant, and `level:ATX-60,ATX-89` is the
+  second key where the two requirements genuinely *are* related — both about the
+  severity ladder and the `hasError` predicate — while the rule relates them for
+  a reason that is not that. The echo detector flagged both of `ATX-89`'s params
+  and both were measured `independent` by mutation, one `verify self` each,
+  taking it to 4 true positives of 11.
+- **`ATX-88`: `tests-red` names the timeout the run applied and how many
+  scenarios reached it, so a suite that went red on the clock can be told from
+  one that went red on its code.** Filed from a 0.9.1 → 0.11.0 upgrade report
+  where `npx vitest run` was 170/170 green on the same tree on which `verify`
+  was red two runs in three. The standing answer — run the suite yourself under
+  your own reporter — is circular in exactly that case, because the
+  disagreement between the two runs *is* the failure; what the reporter did
+  instead was time every scenario by hand and cross-reference which of eleven
+  over four seconds declared no `timeoutMs`. **This is deliberately not the
+  pass-through**, which stays open at the foot of this file: carrying the
+  child's failures means new fields, a `SCHEMA_VERSION` question and a third
+  party's assertion wording in the field consumers are told not to branch on.
+  It is the narrow half that is not blocked — the isolated child run drops the
+  config that would have raised the timeout, so *did anything run out the clock*
+  is the one question a green direct run cannot answer and this one can, and it
+  needs nothing the report does not already carry. A count and never a list, for
+  the same reason.
+  *The number is read from the resolved child config rather than written down,
+  and that is the half a constant would have got wrong.* It is the one value
+  here Attest does not choose: Vitest's own default when the run is isolated,
+  the supplied config's value when `--vitest-config` raised it. `ATX-88.params`
+  pins the isolated default at 5000 because two documents quote it in prose —
+  the workflow document `init` writes and the troubleshooting page — and until
+  now nothing would have failed if a Vitest release moved it.
+  *Detected by duration and never by the child's error text.* Vitest does say
+  "Test timed out in 5000ms." and matching that would be shorter; it is also the
+  category error this project refuses in its own diagnostics, since a message is
+  prose in somebody else's package too. Measured rather than assumed: a scenario
+  that reaches the ceiling ends `fail` a hair past it — 5015 ms against 5000 —
+  while an assertion failure ends `fail` in under a millisecond, so `>=` needs no
+  tolerance and a tolerance would start claiming timeouts for slow assertions
+  that failed honestly. A missing duration reads as *not* a timeout, which is the
+  direction that fails quietly; the other reports every red as a timeout, which
+  is a wrong diagnosis printed with confidence.
+  *Stated over the run rather than over the two commands that render it*, unlike
+  `ATX-51` beside it, and by this project's own rule rather than by preference:
+  what `verify` and `archive` add is a sentence in `Issue.message`, which is
+  prose and never API, so a scenario asserting it would be asserting wording.
+  Additive to `--json` only in the sense that nothing there moved at all — no
+  field, no code, no `schemaVersion` question.
+
+- **`examples/judgement-table/` states the counting rule, which is the one piece
+  of content that decides nothing and without which two tables cannot be
+  compared.** Decided under `Planned` on 2026-08-31 on the first table built from
+  that example, which distrusted its own obligation column above all its others
+  and said why: two tables that count differently are not a second measurement of
+  the same thing, they are a second vocabulary. The rule is not a column and
+  answers nothing — what a requirement carries is still the adopter's judgement —
+  so it sits on the same side of the split as the two mechanical properties, and
+  was being withheld along with the answers, which was the wrong side. It fixes
+  the test (two clauses are two obligations when an implementation can satisfy
+  one completely and fail the other), the six kinds of clause that read as a
+  second obligation and are not (scope, criterion, purpose, the other side, a
+  consequence, and the states a scenario happens to construct), the
+  one-promise-per-emitted-artifact case, and the tiebreak — perturb one half and
+  see whether the other half's scenario stays green. Extracted from the labels in
+  `tests/intent-rule-candidates.spec.ts` rather than invented, which is why it is
+  a description of a rule already in use and not a proposal. It also names what it
+  does **not** ask: whether the obligations belong under one id is a different
+  question, and keeping the two apart is what lets the count stay a measurement.
+
+### Changed
+
+- **The example's anchor is no longer a field to be typed, because the first
+  table built from that file filled it in for all 80 of its rows mechanically.**
+  `Judgement` shipped with an optional `pin`, documented as not a judgement
+  column and nevertheless the only concrete field in the interface — and a field
+  gets populated. Copying 80 scenario names out of the AST and back into the
+  table is not judgement, and it is exactly the form-filling the empty frame
+  exists to prevent. `pin` is now out of `Judgement` entirely and sits in a
+  sibling `PINS` map, and an anchor on an id declaring fewer than two scenarios is
+  **refused**: with one scenario the anchor is a function of the project,
+  `inspectProject` already computes it, and the line naming it is transcription
+  wearing a judgement's clothes. What survives is the case where the anchor is a
+  real choice, which is the case a machine cannot make. *The cost is named rather
+  than hidden:* a sole scenario deleted and replaced under a different name is a
+  revisit `PINS` will not force. That is what not asking anyone to transcribe
+  costs, and it is paid where a rename cannot change which scenario the row meant.
+- **The frame's emptiness is now typed, which the obvious implementation of this
+  fix would have left unenforced.** Deleting `pin` leaves `interface Judgement {}`,
+  and an empty interface is not an empty row type — it admits `0` and `""`, so
+  every row could quietly acquire anything at all while the file claimed to ship
+  no fields. `Record<string, never>` is the type that means what the sentence
+  says. Caught by `eslint` rather than by reasoning, which is `How an entry is
+  re-measured`'s question about what a repair makes reachable arriving one step to
+  the side of where it was expected. Measured both directions: a row carrying an
+  undeclared field does not compile, and replacing the line with an interface
+  holding one **required** column errors on every existing row.
+- **The example's own subject gained a second scenario**, so `EX-1`'s anchor is a
+  choice among several rather than a value the machine could have derived — the
+  refusal above has nothing to demonstrate on a project where every id declares
+  one scenario. It is also the counting rule standing on its own subject: two
+  scenarios, one obligation, because "before it is stored" is the criterion for
+  "rejected" and not a second promise. All three assertions in the anchor test
+  were shown to fail before this was called done — a derivable anchor, a renamed
+  scenario, and an anchor with no row.
+
+### Documentation
+
+- **Three places carried a backstop claim that is now false — `ATX-84`'s
+  rationale, `skill.ts`'s header, and design §9 in both languages — and all
+  three withdraw it.** The claim is that every mistake a stale workflow
+  document can cause is a diagnostic carrying a fix hint the agent corrects
+  itself from, and it is one of the two arguments for shipping no freshness gate
+  to adopters. An upgrade report measured the counterexample: a
+  copy six weeks and one upgrade behind still described `never-red`'s ordering
+  rule, which `[0.10.0]` archived as `evidence-not-ordering` because the
+  ordering was never in the engine. An agent reading it does something the
+  engine does not require — more conservative, not wrong-shaped — so **no issue
+  fires at any severity** and there is nothing to correct itself from. The
+  backstop covers a stale document producing bad input; it does not cover one
+  producing unnecessary work, and the second is what the drift produced.
+  *All three, because they are one argument stored three times and this
+  repository's whole subject is what happens when those disagree.* Two were
+  known from the entry that priced this; the third was found by grepping for the
+  claim rather than for the files that discuss it, and design §9 is the copy
+  with the widest audience. `ATX-84`'s rationale cites "the decision in
+  `skill.ts`", which cites the design — so correcting any one of them alone
+  leaves a citation pointing at a document that says something else. The
+  workflow document's own bytes are untouched — the claim lives in the module
+  header, above `BODY` — so no `init` re-run is owed and `ATX-84` stays green
+  byte-for-byte.
+  *What does not change is the requirement.* `ATX-84` gates this repository's
+  copy and is not adopter-facing, and the surviving objection — that a gate
+  charges every adopter a diff they did not ask for — carries it alone. What the
+  withdrawal reopens is the adopter-facing question, which is priced under
+  `Under consideration` rather than restated in a rationale, since a second copy
+  of an argument that is still moving is the failure this entry is about.
+- **The workflow document named one of the two things the isolated child run
+  withholds, and the troubleshooting page named both.** Re-measuring this before
+  building it is what found that: the ask was filed as "have the workflow
+  document say that a scenario near the default needs an explicit `timeoutMs`",
+  and that sentence already existed — in `tests-red`'s troubleshooting section,
+  worked example included. What did not exist was the pointer. The workflow
+  document's own bullet on why a green direct run does not predict the gate lists
+  aliases, transforms and a DOM, and stops there; an agent reading it was told
+  about the environment and not about the clock, while the section it links to
+  covers both. So what was owed was a second bullet rather than a new
+  explanation, which is cheaper than the entry priced it.
+- **`tests-red`'s troubleshooting section stops saying the report carries
+  nothing about the failure**, in both languages, because it now carries exactly
+  one thing. The sentence that had to change is the one that reads as a general
+  promise — "not from this report, because it does not carry them" — and the
+  worked example beside it says which half crossed and why the other half is a
+  decision rather than an omission. History rows on `verify` and `archive` in
+  both references, since a reader on 1.0.0 gets the older report.
+- **`CLAUDE.md`'s "it will not tell you why" gotcha gains its exception.** The
+  gotcha is still true of the file, the scenario and the assertion; it is no
+  longer true of the clock, and a gotcha that overstates itself is how somebody
+  stops reading the report.
+
+- **`intent-quality.md` step 2 points at the counting rule, and says why that
+  one pointer does not contradict the page's own sequencing.** The page asks a
+  reader to do step 2 before reading our table, because a table built by someone
+  who read ours first is an echo of ours. A rule that fixes the *unit* is the
+  opposite case — sharing it is what makes a second table comparable, where
+  sharing an answer is what makes it a copy — and a page that withheld both
+  without distinguishing them would have been asking for an incomparable
+  measurement on principle. Both languages, and a line added to *Read our table
+  after step 2, not before* so the exemption is stated where the rule it excepts
+  is. The History row is owed for the second reason rather than the first: step 4
+  tells a reader to **copy** `examples/judgement-table/`, and that file changed
+  under this version, so a copy taken at `[1.0.0]` is no longer the file this
+  page describes — which is exactly what that table is for and the kind of row
+  easiest to miss, because nothing on the page announces that it hands out a
+  file.
+
+## [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 +1458,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 +5052,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 +5265,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 +5864,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
@@ -6284,317 +6760,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,6 +6892,554 @@ have to gather again.
   and the second report of the same shape, which this measurement does not
   supply and does not replace.
 
+  *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.
+
+  **Blocker (3)'s two cheap answers are built under `[1.1.0]`, and the
+  entry stays open on the other two.** `ATX-88` has `tests-red` name the timeout
+  that applied and how many scenarios reached it, and the workflow document now
+  says the isolated run drops your `testTimeout` along with the rest of your
+  config. Neither touches (1) or (2): no field was added, no `SCHEMA_VERSION`
+  question was asked, and no assertion text from the child crossed into an
+  `Issue`. What the entry proposes — passing the child's failures through — is
+  unchanged and undecided.
+  *Two things the re-measure corrected, and one is the second cheap answer's
+  whole shape.* The workflow-document line was filed as content to write, and it
+  was already written: `tests-red`'s troubleshooting section carries it, worked
+  example included. What was missing was a pointer from the workflow document's
+  own bullet about why a green direct run does not predict the gate, which lists
+  aliases, transforms and a DOM and stops before the clock. And the first
+  answer's phrasing — "the timeout it **imposed**" — was wrong about who imposes
+  it: Attest sets no timeout, it inherits Vitest's default by isolating, so the
+  number has to be read off the resolved child config rather than stated. That
+  distinction is what makes the answer correct under `--vitest-config` too,
+  where the ceiling is the adopter's.
+  *What this does not do, stated so the entry is not read as smaller than it
+  is.* It answers whether the clock was involved. It does not name the scenario,
+  the file or the assertion, so a red `verify` whose cause is not a timeout is
+  exactly as opaque as it was — which is the case this entry is still waiting on
+  an instance of.
+
+- **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 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
+  **change** — a delta, proposed specs, a recorded failing run — and a param edit
+  is none of those. It is one literal in a merged `*.reqs.ts`, and every gate
+  reads it as fine: `check` finds it schema-valid, because a param is any JSON
+  value; `possible-drift` is quiet by construction, since `ATX-8` makes it ask
+  whether *any* covering scenario reads the params at all rather than whether a
+  value moved; and `verify` stays green wherever the assertion derives its
+  expectation from the same param, which is the pair of green rows measured in
+  the entry this was split from.
+  *What is left is `render`, and it was measured here rather than assumed.*
+  Across **89 params on 59 of this repository's 79 requirements, 82 — 92.1% —
+  are interpolated into their own statement**, so editing one changes
+  `self/requirements/SPEC.md` and `render --check` fails until the document is
+  regenerated. That is a review surface and not a gate: the new value lands in a
+  committed generated file where a reader can see it, and nothing anywhere asks
+  whether the move was intended.
+  *The other seven leave no trace outside the line that was edited, and which
+  seven they are is the finding rather than the count.* Five are **structurally
+  uninterpolatable**: `ATX-7.payloadKinds` and `ATX-63.payloadKinds` are
+  kind → payload tables, and `ATX-15.sortMethods`, `ATX-15.bannedApis` and
+  `ATX-72.quotes` are lists. A statement cannot carry any of them —
+  `non-scalar-interpolation` is the diagnostic that refuses it — so the params
+  with no record are disproportionately the shape §2 widened the params rule to
+  cover **precisely because lists and tables are the most drift-prone constants
+  there are**. The remaining two, `ATX-15.comparator` and `ATX-26.code`, are
+  scalars their author simply did not interpolate.
+  *What this is not.* It is not a re-proposal of the committed params snapshot
+  rejected below. That was rejected on the argument that the mechanism guarding a
+  param is a scenario reading it rather than a file recording it, and nothing
+  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.
+  *Blocker **(1)** was answered on 2026-08-31, in the direction that opens the
+  entry rather than closing it.* It read that frequency is unmeasured and that
+  the one corpus anybody had looked at pointed at zero: 8 commits touching
+  `*.reqs.ts` in the reporting repository, every `params:` line in every diff an
+  addition. A 0.9.1 → 0.11.0 upgrade report from `mine-capablanca` re-ran that
+  count over the **41 revisions** that have touched the same registry, evaluating
+  the file at each revision and comparing key by key rather than reading diffs,
+  and it reads **2 keys added, 1 removed and 7 values changed**. The 8-commit
+  figure was a sample and not an answer; it is withdrawn here and in the
+  tautology entry under `Considered and rejected` that quoted it.
+  *One of the seven landed with nothing capable of objecting, and it is the
+  general case rather than an accident of that commit.* A single commit moved
+  `AI-14.sampledCandidates` from 8 to 3 and `AI-14.samplingTemperature` from 5 to
+  20, and its entire diff is a proposal, a delta, the registry and the
+  regenerated `SPEC.md`. **No spec file and no implementation file.** Nine
+  implementation modules in that project import the registry and read params out
+  of it at runtime, so the opponent's behaviour on the easy setting changed with
+  the suite green — the scenarios read the same two values the implementation
+  reads, so both sides moved together. `render --check` did not object and
+  structurally cannot: it enforces that the rendering *moved*, never that the
+  movement was intended. What caught it was a reviewer on ten lines of `SPEC.md`
+  diff, with a 63-line proposal beside it arguing for exactly that move.
+  *So review is the gate, and the second corpus says it holds for a reason
+  nothing enforces.* That registry is **58 of 58** params interpolated into their
+  own statement, against 82 of 89 — 92.1% — here. Every param edit there moves a
+  line of `SPEC.md`, which is why the commit above was visible at all, and the
+  reporter is explicit that nothing makes this true: `check` is at zero issues,
+  and a declared key that no statement interpolates is not a problem at any
+  severity. A 100% discipline held over 41 revisions with nothing behind it is
+  one careless commit away from being 98%.
+  *What blocks the decision now — and **(2)** has become the opposite of what it
+  said.* **(2) A shape is obvious, and it is small.** `check` already reports
+  `unbound-param` for a placeholder with no key; the reverse — a declared key no
+  statement interpolates — is reported at no severity, and it is the exact static
+  test for "this param's edit leaves no trace outside the line that changed". It
+  needs no previous value, so it is not the rejected snapshot wearing a hat: it
+  is a property of one revision. The nearest precedent is `rationale-placeholder`,
+  a WARNING deliberately below `hasError` so that an existing green registry
+  gains a line of output and keeps its exit code, and that is the level this would
+  take. **(3) What it would fire on here is the objection.** Five of this
+  repository's seven uninterpolated params are **structurally uninterpolatable** —
+  `ATX-7.payloadKinds` and `ATX-63.payloadKinds` are kind → payload tables,
+  `ATX-15.sortMethods`, `ATX-15.bannedApis` and `ATX-72.quotes` are lists, and
+  `non-scalar-interpolation` is the diagnostic that refuses a statement carrying
+  any of them. So the rule must exempt non-scalars, and what is left is
+  `ATX-15.comparator` and `ATX-26.code`: two params, in one repository, that
+  their author simply did not interpolate. A warning firing twice on its own
+  corpus and zero times on the only other one measured is a rule looking for a
+  population. And the exemption is the hole rather than a detail — the five it
+  must skip are precisely the shape §2 widened the params rule to cover
+  **because lists and tables are the most drift-prone constants there are**.
+  *What would decide it:* an adopter whose interpolation rate is below 100% and
+  whose uninterpolated params are scalars. Both corpora sit at the extremes —
+  58 of 58 there, and here the gap is almost entirely the shape the rule cannot
+  see — so nobody has yet measured the population it would serve. Until then the
+  answer for the five that matter may still be nothing more than a line in
+  `intent-quality.md`, the four things no gate is looking at already being that
+  page's subject and this being a fifth of the same kind.
+
+- **The intent layer is separable from the repository it describes, and the
+  verification layer is not — so a third party can audit intent and never
+  obtain a verdict.** Filed 2026-08-22 from a design evaluation of using Attest
+  as an external audit tool that touches none of the auditee's implementation.
+  The separability is already bought and is stronger than it looks: §2 requires
+  a registry to be a *literal*, no imported constant and no computed value, so
+  `*.reqs.ts` names nothing in the project it is about and is a file another
+  party could own outright. The four static commands execute none of the
+  auditee's code, which is the posture an auditor needs and is already the
+  documented reason for the split. The arrangement that follows is a two-party
+  contract with `check` as its interface: the auditing party writes the SHALL,
+  the developing party owes each id a scenario, and `uncovered-requirement` and
+  `orphan-test` are the two directions that contract can be broken in.
+
+  *What blocks it, in the order that decides it.* **The verdict half cannot
+  cross the boundary, and that is §1 rather than a gap.** `verify` and `archive`
+  run the suite, the suite's specs import the implementation, and the environment
+  those specs need is the auditee's — reachable only by trusting their
+  `--vitest-config`. So what a decoupled auditor can obtain is the readable
+  obligations and never `tests-red`, which is the same asymmetry `status` already
+  carries and states about itself. That would be tolerable if the static report
+  read as procedural, and it does not: an audit reader takes a full-coverage
+  `check` as a claim about behaviour, while §11 records that coverage is binary,
+  that an assertion can echo the param it is measuring, that shortening a
+  list-valued param silently removes cases, that a quantifier is covered only as
+  far as hand-written scenarios reach, and that two contradictory ids under
+  different prefixes both pass. **The mechanism assumes one tree.** `locate.ts`
+  scans a single project root, and mechanism 1 needs the spec to `import` the
+  registry, so the externally-owned file has to be physically in the tree before
+  any command runs — a checkout step, not a flag. Naming a registry outside the
+  root would be a second answer to where intent lives, which is the shape this
+  repository refuses elsewhere. **The flat ID space bills exactly here.** §11
+  already records that nothing allocates a prefix and that the cost arrives when
+  adoption succeeds; two parties sharing one registry *is* that case, and
+  `duplicate-prefix` can only report a collision after both files were read.
+  **And `--apply` writes into the other party's file.** The merge splices ADDED
+  requirements into the registry, so the one command that edits a file the user
+  cannot regenerate would be editing a document whose owner is not in the
+  repository. Nothing about that is unsafe; it is that the ownership the
+  arrangement exists to establish is the thing the merge step quietly crosses.
+
+  *What would settle it, and what it costs to try.* The whole arrangement is
+  derivable from the design and has been run by nobody, so this is n=0 and cheap
+  to move: the checkout-step form needs no engine change at all, and one
+  adopter running it would say whether the two-party report is read as procedural
+  or over-read as a behavioural claim. That is the measurement, and it is a
+  question about the reader rather than about the code.
+
+- **A freshness gate on the file `attest init` writes (`init --check`).**
+  Rejected 2026-08-19, and **reopened 2026-08-31 by the first measurement of the
+  exposure it was rejected on.** The rejection is kept below in full because it
+  is still the argument to beat, and what beat one of its two load-bearing claims
+  is a 0.9.1 → 0.11.0 upgrade report from `mine-capablanca`: the committed
+  `.claude/skills/attest/SKILL.md` in that repository, written by `init` at
+  0.9.1, differs from the 0.11.0 body by **9 hunks and 110 changed lines, 403
+  lines against 458**. It was found only because the reporter wrote a script
+  importing `workflowBody()` out of the installed build and diffed it. `check`,
+  `cover`, `verify` and `render --check` were all green with the document stale.
+  *The backstop is what failed, and it failed on the worst available case.* The
+  rejection's second claim is that every mistake a stale document can cause is
+  already a diagnostic with a fix hint — "a registry written the old way is
+  `registry-not-static`", so the agent corrects itself from the report. The stale
+  text here is `never-red`'s ordering rule, which `[0.10.0]` archived as
+  `evidence-not-ordering` on the grounds that the ordering was never in the
+  engine. An agent reading that document is told to do something the engine does
+  not require. Its behaviour is more conservative, not wrong-shaped, so **no
+  issue fires at any severity** — there is nothing to correct itself from,
+  because nothing it does is an error. The backstop covers a stale document
+  producing bad input. It does not cover a stale document producing unnecessary
+  work, and the second is what six weeks of drift actually produced.
+  *The first claim survives, and it is still the objection.* A gate on this file
+  does turn red on a change the user did not make and is cleared by a commit
+  containing no decision. Nothing in the report disputes that. What the report
+  supplies is the other side of the ledger, which the rejection priced as "one
+  honest and small exposure": 110 lines, over one upgrade, undetectable without
+  writing a script against `dist/`.
+  *And the property that makes `init` idempotent is the same one that makes the
+  drift invisible.* `skillContent()` and `workflowBody()` take no argument — not
+  the version, not the project — deliberately, so that re-running `init` after an
+  upgrade is always safe. The consequence is that the file carries **no version
+  stamp**: nothing in the adopter's repository records which version wrote it,
+  and *"Re-run `attest init` after upgrading"* — which the CLI prints once, at
+  `init` time, to a reader who is not upgrading — is only actionable by somebody
+  who already knows they need to. A diff against the installed build is not one
+  detector among several. It is the only one the file's own design permits.
+  *What is undecided is the shape, and the rejection narrows it rather than being
+  answered by it.* A red `init --check` in CI is the thing that was rejected, and
+  the report does not rehabilitate it: it would fail a fresh clone on somebody
+  else's release, which is the same standard `render --check` was held to when a
+  freshness gate that calls a fresh clone stale was called worse than no gate.
+  What was never proposed, and is not what the heading names, is a **notice on a
+  command the adopter is already running** — the same information at the cost of
+  no gate and no chore commit. Pricing that is the next step; it is not a
+  decision already taken, and it needs its own answer to which command, at what
+  level, and whether a WARNING nobody can clear without running `init` is a
+  chore in a diagnostic's clothes after all.
+  *What is still unmeasured:* whether the drift cost that reporter anything. 110
+  changed lines measures the document, not the work, and the report is explicit
+  that it did not run `init` and did not act on the withdrawn rule. Nobody has
+  yet followed a stale instruction and paid for it, and the rejection below is
+  entitled to that until somebody has.
+
+  **Priced on 2026-09-02, per `How an entry is re-measured`, and the three
+  questions have answers: `check`, `INFO`, and no — the chore is the exit code
+  rather than the line.**
+  *The re-measure corrected the entry's framing of the detector first.* "A diff
+  against the installed build is the only detector the file's own design
+  permits" reproduces exactly, and what it makes reachable is the opposite of
+  how it reads: the comparison needs no version stamp, because `skillContent()`
+  is already inside the process that would report. Measured against this
+  repository's own copy — byte-equal and document-equal at 26,584 bytes both
+  sides — and against the other two targets, which are **absent**, that being
+  the population the notice has to be right about. Cost is **0.234 ms** per run
+  for all three comparisons plus **4.19 ms** to import `targets.ts` and through
+  it the 26 KB template in `skill.ts`, which `check` does not import today;
+  `check self --json` is 814–1,183 ms over three runs, so the notice is **~0.5%**
+  of the command it rides on.
+  *Which command, and the objection to it is answered by precedent rather than
+  by argument.* `check` is the only command an adopter runs unconditionally and
+  is the one the workflow document tells the agent to run. `status` takes a
+  `<change>`, so it is silent during exactly the brownfield adoption whose
+  document is stalest; `cover` and `render` are narrower; `verify` and `archive`
+  are the expensive verdicts, where a non-verdict line is noise at the worst
+  available price. The objection is that this would be `check`'s first finding
+  that is not about the project's intent layer — and it would not be:
+  `compilerIssue()` is the first statement of `runCheck`, and
+  `compiler-unsupported` is a finding about the *installed environment*, at
+  ERROR. What ATX-16 scopes `check` to is executing nothing, never intent only.
+  *What level, and `WARNING` is wrong for a reason the roster states.* All three
+  existing WARNINGs — `rationale-placeholder`, `requirement-open`,
+  `orphan-from-failed-registry` — are defects in the reader's own intent layer
+  that the static half declines to fail on. A stale document is neither a defect
+  nor theirs. `INFO` has exactly one member, `possible-drift`, and it is this
+  shape precisely: something here may be drifting and nothing can prove it cost
+  you anything — which is also what this entry's own unmeasured half says.
+  `ERROR` is `init --check`, and that stays rejected.
+  *The chore question dissolves at that level, on a fact about when the drift
+  appears.* The rejection's standard is a gate that "turns red on a change the
+  user did not make". Drift appears only when the installed version moves, which
+  is a lockfile edit and is a change they made; a fresh clone at a pinned version
+  compares equal and is silent, so the failure mode that forced `render --check`
+  off byte comparison — calling a fresh clone stale — cannot occur here. What
+  makes a thing a chore is the exit code, not the line, and at INFO there is
+  nothing to clear: a reader who ignores it forever pays what they pay today.
+  *The repair makes one thing reachable that the entry does not contain, which
+  is the question the method exists to ask.* `runInit` writes with `writeAtomic`
+  unconditionally — no merge, no backup — and the notice cannot tell a stale file
+  from an edited one. Today that overwrite happens only when the user chooses to
+  run `init`; a notice prompts them into it on the tool's schedule, so the fix
+  hint has to say that `init` rewrites the file rather than merely naming the
+  command. `targets.ts` rule 1 makes that defensible — Attest owns the path, and
+  that is the whole reason it may overwrite — but defensible and unstated are
+  different things.
+  *And the obvious implementation is wrong twice, both times by copying
+  `staleIssue`, which is the reference implementation this entry points at and
+  therefore the one nobody re-reads.* **(a)** It emits `missing-spec-doc` for an
+  absent file. Here an absent file is a project that never ran `init` — two of
+  this repository's own three targets — and firing on it would be the tool
+  scattering findings about editors nobody uses, which is the argument
+  `DEFAULT_TARGET` already makes. Absent must be silent, so this takes one code
+  and not two. **(b)** `sameDocument` normalises CRLF and has to here, for the
+  reason `render --check` needs it: Attest does not own an adopter's
+  `.gitattributes`. That is the **opposite** of ATX-84, which compares this
+  repository's copy byte-for-byte, and whose rationale already argues why the two
+  must differ. The comparisons are deliberately not the same one.
+  *What the re-measure found that belongs to no proposal: ATX-84's rationale
+  carries the standing version of this argument, and one clause of it is now
+  false.* It records that a gate here does not reverse `skill.ts`'s decision
+  against shipping one, on the grounds that "every mistake an old document can
+  cause is a diagnostic carrying a fix hint the agent corrects itself from".
+  That is the clause the `mine-capablanca` report falsified — the withdrawn
+  `never-red` ordering produces unnecessary work rather than bad input, and
+  nothing fires at any severity. **Withdrawn under `[1.1.0]` on 2026-09-02,
+  in all three places that carried it**, since the correction was owed whether or not
+  the notice ships; what the withdrawal leaves standing is the diff-nobody-asked-for
+  objection alone, which is the argument this entry now has to beat.
+  *One cost the entry did not price: this repository cannot dogfood it.* `check`
+  reads the project root, which here is `self/`, and the document is at the repo
+  root — so `check self` would find the file absent and be correctly silent.
+  ATX-84's scenario reaches two directories up because it is a test; a command
+  cannot. The scenario would land on a fixture, and `self/` would give the notice
+  none of the continuous exercise ATX-84's rationale calls the only detector this
+  document has.
+  *What it does not need, priced because the entries around it spend most of
+  their length on exactly this:* no `SCHEMA_VERSION` bump — the field exists, the
+  value is new, and `ok` is untouched because INFO is below `hasError`, the same
+  reading that has held the version at 1 across all 41 codes. One roster entry
+  and one troubleshooting section per language, both made mandatory by
+  `docs-consistency.spec.ts` rather than by remembering.
+  *The one form still worth arguing is the cheapest one, and it loses on the
+  exposure's own shape.* A dim line after the report — `init`'s own "Re-run
+  `attest init` after upgrading", moved to where it is actionable — needs no
+  code, no roster entry and no section in two languages. It is also invisible
+  under `--json`, and the drift in that report was found by a reader writing a
+  script against `dist/`. A detector a machine cannot read reproduces the
+  invisibility it exists to remove.
+
+  **Built under `[1.1.0]` on 2026-09-02, and the entry stays here because
+  what was built is not what it names.** The priced form shipped exactly as
+  priced — `check`, INFO, one code, silent on an absent file, document rather
+  than bytes — as `ATX-89`, `ATX-90` and `ATX-91`. The re-measure corrected none
+  of the three answers, which is worth recording against the two cases in `How
+  an entry is re-measured` where it corrected an entry outright.
+  *What the build added that the pricing did not have is the argument the
+  approver gave, and it is better than the one written here.* This entry argues
+  the level from the negative — a gate is a chore, so do not gate. The reason
+  actually adopted is positive and is an **asymmetry of obligation**: keeping
+  this document current is Attest's obligation, because Attest is what changes
+  it, and taking the update is nobody else's. A finding whose subject the reader
+  owes nothing about is exactly the finding that may only inform. That reaches
+  the same level by a route that does not depend on calling anything a chore,
+  and it is what `ATX-89`'s rationale carries.
+  *What is left of this entry is the gate alone, and it is unchanged.* A notice
+  is not a weaker gate, it is a different artifact: it can be ignored, and by a
+  CI-only adopter who never reads `check` output it certainly will be. That is
+  the cost of the choice rather than an oversight — the trade taken was "never
+  blocks anyone" against "guaranteed to be seen". The thing that would move the
+  gate is what it always was, and the notice does not supply it: an adopter who
+  followed a stale instruction and paid for it. Nobody 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.
+
 - **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
@@ -6767,26 +7480,29 @@ have to gather again.
   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
+  (104 entries as of 1.1.0, 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
+  **(1) `compound-requirement`** — 42 requirements carry more than one
+  obligation, it flags 18, is **wrong about none**, and misses 24. Never wrong
+  and nearly blind, and the 24 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
+  36 correct, but 14 wrong and still 6 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
+  — 9 divergences on this repo, **all 9 judged wrong**, zero true positives ever
+  recorded. The `code` group now spans 22 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
+  that changed no verdict, and once more under `code` at 1.1.0. `level` arriving
+  there as a fifth param name is the second key whose two requirements genuinely
+  *are* related — `ATX-60` and `ATX-89` are both about the severity ladder — and
+  the rule still relates them by the one thing that is not the relation. 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
@@ -6817,7 +7533,10 @@ have to gather again.
   *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.
+  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
@@ -6846,7 +7565,7 @@ have to gather again.
   §6 already records as the category no gate reaches: the page's three samples
   are unasserted today, and a fourth in a directory that looks executable would
   be worse than a fenced block, not better, unless something runs it.
-  **Built under `[Unreleased]`, and the second of those two blockers was the
+  **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.
@@ -6871,246 +7590,80 @@ have to gather again.
   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.
-
-- **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
-  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
-  **change** — a delta, proposed specs, a recorded failing run — and a param edit
-  is none of those. It is one literal in a merged `*.reqs.ts`, and every gate
-  reads it as fine: `check` finds it schema-valid, because a param is any JSON
-  value; `possible-drift` is quiet by construction, since `ATX-8` makes it ask
-  whether *any* covering scenario reads the params at all rather than whether a
-  value moved; and `verify` stays green wherever the assertion derives its
-  expectation from the same param, which is the pair of green rows measured in
-  the entry this was split from.
-  *What is left is `render`, and it was measured here rather than assumed.*
-  Across **89 params on 59 of this repository's 79 requirements, 82 — 92.1% —
-  are interpolated into their own statement**, so editing one changes
-  `self/requirements/SPEC.md` and `render --check` fails until the document is
-  regenerated. That is a review surface and not a gate: the new value lands in a
-  committed generated file where a reader can see it, and nothing anywhere asks
-  whether the move was intended.
-  *The other seven leave no trace outside the line that was edited, and which
-  seven they are is the finding rather than the count.* Five are **structurally
-  uninterpolatable**: `ATX-7.payloadKinds` and `ATX-63.payloadKinds` are
-  kind → payload tables, and `ATX-15.sortMethods`, `ATX-15.bannedApis` and
-  `ATX-72.quotes` are lists. A statement cannot carry any of them —
-  `non-scalar-interpolation` is the diagnostic that refuses it — so the params
-  with no record are disproportionately the shape §2 widened the params rule to
-  cover **precisely because lists and tables are the most drift-prone constants
-  there are**. The remaining two, `ATX-15.comparator` and `ATX-26.code`, are
-  scalars their author simply did not interpolate.
-  *What this is not.* It is not a re-proposal of the committed params snapshot
-  rejected below. That was rejected on the argument that the mechanism guarding a
-  param is a scenario reading it rather than a file recording it, and nothing
-  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.
-
-- **The intent layer is separable from the repository it describes, and the
-  verification layer is not — so a third party can audit intent and never
-  obtain a verdict.** Filed 2026-08-22 from a design evaluation of using Attest
-  as an external audit tool that touches none of the auditee's implementation.
-  The separability is already bought and is stronger than it looks: §2 requires
-  a registry to be a *literal*, no imported constant and no computed value, so
-  `*.reqs.ts` names nothing in the project it is about and is a file another
-  party could own outright. The four static commands execute none of the
-  auditee's code, which is the posture an auditor needs and is already the
-  documented reason for the split. The arrangement that follows is a two-party
-  contract with `check` as its interface: the auditing party writes the SHALL,
-  the developing party owes each id a scenario, and `uncovered-requirement` and
-  `orphan-test` are the two directions that contract can be broken in.
-
-  *What blocks it, in the order that decides it.* **The verdict half cannot
-  cross the boundary, and that is §1 rather than a gap.** `verify` and `archive`
-  run the suite, the suite's specs import the implementation, and the environment
-  those specs need is the auditee's — reachable only by trusting their
-  `--vitest-config`. So what a decoupled auditor can obtain is the readable
-  obligations and never `tests-red`, which is the same asymmetry `status` already
-  carries and states about itself. That would be tolerable if the static report
-  read as procedural, and it does not: an audit reader takes a full-coverage
-  `check` as a claim about behaviour, while §11 records that coverage is binary,
-  that an assertion can echo the param it is measuring, that shortening a
-  list-valued param silently removes cases, that a quantifier is covered only as
-  far as hand-written scenarios reach, and that two contradictory ids under
-  different prefixes both pass. **The mechanism assumes one tree.** `locate.ts`
-  scans a single project root, and mechanism 1 needs the spec to `import` the
-  registry, so the externally-owned file has to be physically in the tree before
-  any command runs — a checkout step, not a flag. Naming a registry outside the
-  root would be a second answer to where intent lives, which is the shape this
-  repository refuses elsewhere. **The flat ID space bills exactly here.** §11
-  already records that nothing allocates a prefix and that the cost arrives when
-  adoption succeeds; two parties sharing one registry *is* that case, and
-  `duplicate-prefix` can only report a collision after both files were read.
-  **And `--apply` writes into the other party's file.** The merge splices ADDED
-  requirements into the registry, so the one command that edits a file the user
-  cannot regenerate would be editing a document whose owner is not in the
-  repository. Nothing about that is unsafe; it is that the ownership the
-  arrangement exists to establish is the thing the merge step quietly crosses.
-
-  *What would settle it, and what it costs to try.* The whole arrangement is
-  derivable from the design and has been run by nobody, so this is n=0 and cheap
-  to move: the checkout-step form needs no engine change at all, and one
-  adopter running it would say whether the two-party report is read as procedural
-  or over-read as a behavioural claim. That is the measurement, and it is a
-  question about the reader rather than about the code.
+  **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.
+  **Both are built under `[1.1.0]`, and moving here on 2026-09-01 is what
+  follows from that.** The counting rule and the anchor fix are the whole of what
+  was decided on 2026-08-31, and they are recorded there. The re-measure before
+  building corrected nothing this entry claims — the report's three asks
+  reproduce as filed — and what it added is the finding the two cases in `How an
+  entry is re-measured` would predict: the obvious implementation of "ship no
+  fields" is an empty interface, and an empty interface admits `0` and `""`, so
+  the frame would have gone on claiming an emptiness its own type did not hold.
+  *The move is the entry's own state changing, not bookkeeping.* `Planned` means
+  decided and unbuilt, and nothing left here is that: the schema, the
+  clause-to-scenario binding and the out-of-scope `venue` column are all waiting
+  on a second table somebody has maintained, which is the definition of this
+  section rather than the one above. What it costs is that `Planned` is empty
+  again — the state that moved `How an entry is re-measured` out of it, so that
+  the method would not go unreachable whenever this happened — and that is the
+  honest reading of where the project stands rather than a gap in the file:
+  nothing is currently decided and unbuilt.
 
 ## Considered and rejected
 
@@ -7122,6 +7675,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 +8395,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 +9076,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 +9205,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 +9403,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 +9484,8 @@ path the repair makes reachable; it is about **everything the repair would make
 
 ## Releases
 
+[1.1.0]: https://gitlab.com/Pseudorca/attest/-/tags/v1.1.0
+[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