@am_shork/attest 0.9.3 → 0.10.0

package/CHANGELOG.md

@@ -13,6 +13,759 @@ 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.
 
+## [0.10.0] - 2026-08-22
+
+### Changed
+
+- **The same mutation pass over the verdict and its evidence: 24 mutations of
+  `gate.ts` and `red-record.ts`, 21 dead, and two of the three survivors closed.**
+  Every step of `evaluateGate` dies when removed, including scoping
+  `open-unresolved` back to the added ids — the cut that separates it from
+  `never-red`. So do both directions of `keepOutcome`: last-write-wins, where the
+  green run at the end erases the red it exists to remember, and first-write-wins,
+  where a recorded pass can never be corrected. The 46 lines at the top of
+  `red-record.ts` arguing for that asymmetry turn out to be held from both sides.
+
+  Two gaps were real, and both are cases where an existing test passes with the
+  guard removed:
+
+  - **A record whose version is not 2 was discarded by the *schema*, not by the
+    version check.** The case that covers this uses a version-1 record keyed
+    `reqId -> name`, which fails the shape as well — so the verdict is identical
+    either way, exactly as the guard's own comment predicts. Isolating the
+    version needs a record the schema would take: a valid version-2 shape under
+    version 3. Without that, "discarded because the format moved" and "discarded
+    because the file is corrupt" were the same observation, which the comment
+    calls out as how a format change gets made without anyone deciding to.
+  - **Nothing noticed if the record invented a `pass` for a scenario that never
+    executed.** `ATX-30` says the file records *how each scenario ended on its
+    first run*; a skipped scenario has no ending, so a `pass` there is an
+    observation no run produced — in a file that is evidence a reviewer reads and
+    that cannot be recomputed once the change is green. The gate still blocks
+    either way, so no verdict moves; what moves is the advice, since `never-red`
+    picks between "rewrite the assertion" and "run the gate before implementing"
+    on exactly this distinction.
+
+  The third survivor is left alone: `open-unresolved` emitting one error per
+  requirement rather than per question breaks nothing anybody promised. `ATX-81`
+  says the static commands report **each one**, and is pinned per question;
+  `ATX-82` says the gate **blocks**, and says nothing about granularity. Two paths
+  of one shape, one held and one not, and the difference is the two sentences.
+
+  *The harness failed twice more, and the second failure is the one worth
+  keeping.* Mutating a **writer** rather than a reader damages files outside the
+  source it was applied to: `archive` writes `first-run.json` into the e2e
+  fixtures, so a mutant that flipped `keepOutcome` left a committed fixture
+  saying `pass` where it had said `fail`, and every mutant after it read as
+  killed for that reason rather than its own. Restoring tracked fixtures fixed
+  the leak that had been found; a blanket check that the working tree is clean
+  after every mutant then immediately found the one that had not been — an
+  *untracked* record a mutant created, which `git checkout` cannot remove. The
+  broad guard earned its place over the narrow fix by catching what the narrow
+  fix was not written for.
+
+- **Two guards in the registry reader had nothing holding them, found by
+  mutating every decision in `static-registry.ts` and watching what stayed
+  green.** Twenty mutations of the module's semantically load-bearing branches;
+  fourteen died to `tests/static-registry.spec.ts` and `tests/splice.spec.ts`,
+  and six survived the whole suite *and* `self/`. Two of the six were worth
+  closing, and both make the two readers answer **differently** rather than
+  merely reporting differently:
+
+  - `let reqs = defineRequirements({…}); reqs = …; export default reqs` — with
+    the `const` check removed the static reader answers the first registry while
+    the evaluator answers the second. A wrong answer rather than a refusal, which
+    is worse than any code it could have reported.
+  - `export = defineRequirements({…})` — with the `isExportEquals` check removed
+    the static reader accepts it, while the evaluator cannot run it at all.
+
+  Both now have a case in *"a registry that is not a literal"*, and both mutants
+  die to it. The other four survivors are left alone deliberately: one guard is
+  defence-in-depth behind a refusal that already happened upstream (`__proto__`
+  as an entry id, which `readRegistrySource` rejects before a merge can reach the
+  layout), one is a deliberate looseness whose comment says why, and two forbid
+  shapes that cannot compile in the first place. A test contrived to reach them
+  would assert that something upstream is still doing its job.
+
+  *The harness had to be fixed before any of it could be believed, and that is
+  the part worth carrying forward.* Its first run reported all six survivors as
+  killed. The cause was the mutation runner inheriting a working directory with
+  no test files in it, so `vitest` exited non-zero with "No test files found" and
+  every mutant read as covered — a green instrument reporting on nothing, which
+  is the exact failure `ATX-15`'s sweep guards against in as many words: *"a walk
+  that found no files satisfies 'no site orders by locale' while proving the
+  opposite of what it claims."* The runner now pins its working directory and
+  refuses to report at all unless the unmutated tree passes first.
+
+- **The differential corpus now drives the two registry *writers*, not only the
+  two readers.** `tests/static-registry.spec.ts` exists because reading a
+  registry from the AST instead of evaluating it needs the two readers held
+  against each other — but the literal they walk has a third and a fourth
+  consumer, `registryInsertionPoint` and `registryEntryLayouts`, and the table
+  was never pointed at them.
+
+  *Every registry-source defect in this release had its trigger already sitting
+  in that table.* `as-const`, `satisfies` and `parenthesised` are the three
+  spellings whose literal the writers could not locate; `key-forms` carries the
+  duplicate key whose span they located at the wrong offset, under a comment
+  that has said *"a duplicate key: last wins"* since the row was written. The
+  corpus knew about all four inputs. Nothing asked the writers about them.
+  Reverting either fix now turns the table red — measured: the unwrap on all
+  three wrapper rows, the layout guard on `key-forms`.
+
+  **What it asserts is not that every case is writable.** A source the readers
+  accept may be one the writers must refuse, and `key-forms` now is. The
+  property is that a writer's answer is always *located* or *refused for a
+  stated reason*, never the third thing — located, wrongly — and which cases are
+  refused is a table someone has to edit rather than a branch that can drift.
+
+  *Widened while pointing it: the `satisfies` row did not cover the spelling
+  that broke.* It applied the keyword to a param value, where the value reader
+  sees it, and not to the registry argument, where the walk that finds the
+  literal does — so it stayed green through a defect named after it. It now
+  carries both positions, as the `as-const` row beside it always did.
+
+- **`readArchivedChanges`' fan-out is bounded — the fourth one, and the first
+  outside `locate.ts`.** `archive.ts` read every archived first-run record
+  through a `Promise.all(names.map(…))`, so a project with N merged changes held
+  N reads and N parsed `RedRecord`s at once. It is the same shape as the other
+  three against an input nobody here chooses — an `archive/` grows by one folder
+  per change merged and is never pruned, so it is the longest-lived of the four
+  lists a project's shape decides the length of. Measured in
+  `tests/locate-fanout.spec.ts`, which now counts a fourth pool: **64 before, 32
+  after**, on 64 archived changes. Unbounded, the figure is the count of the
+  folders; bounded, it is the constant.
+
+  *Why it hid is that the pool's own doc comment names the rule and this caller
+  is not in the file that has it.* `forEachBounded` says "anything here that
+  reads a list the project's tree decides the length of belongs in this pool,
+  whatever the function around it is called" — and `readArchivedChanges` is
+  exactly that, one module over. The nearest comment to it reasons carefully
+  about concurrency and still says nothing about a bound: `inspectRedEvidence`
+  explains why it runs the archive read *after* `inspectProject` rather than
+  beside it — "overlapping them buys nothing worth a second fan-out" — which is
+  a correct answer about sequencing two reads and not a claim about what happens
+  inside either. That is the third time in this catalogue a considered comment
+  about concurrency has stood where a bound was missing. `forEachBounded` is now
+  exported for it, with a fourth constant on the reason `WALK_CONCURRENCY`
+  already gives.
+
+  **The failure this invites is memory, not descriptors — and that corrects the
+  three entries above.** Each of those closed by calling descriptor exhaustion
+  the invited failure and leaving it unmeasured. Measured now, on Linux: it is
+  not reachable through this shape at all. `fs.promises.readFile` does
+  open-read-close inside one libuv threadpool work item, so concurrent
+  *descriptors* are bounded by the threadpool and never by the fan-out — 3,000
+  unbounded in-flight reads peaked at **53** entries in `/proc/self/fd`, and the
+  read completed cleanly under `ulimit -n 256`, and again under `ulimit -n 128`
+  with `UV_THREADPOOL_SIZE=1024`. What does track the input is heap: on 2,000
+  changes of a 45 KB record, peak `heapUsed` was **352 MB unbounded against 177
+  MB bounded**, over interleaved runs — and the unbounded figure wandered from
+  329 to 580 MB across rounds while the bounded one held 177–181. The stable
+  number is the point; the retained result is the floor, and what the bound
+  removes is the transient pile on top of it. This is the portable-arithmetic
+  standard the three earlier halves were accepted on, so it needs no incident
+  report — but the *reason* is memory, and future sweeps should stop reaching
+  for `ulimit`, which does not govern this on either platform: Windows uses
+  Win32 handles, and on Linux the threadpool gets there first.
+
+  Reached only from `inspectRedEvidence` and so from `@am_shork/attest/inspect`,
+  the published subpath — no CLI command reads the archive, which is why the
+  static-command roster is untouched by this. No behaviour change and no
+  `ATX-n`, on the precedent of the other three: the changes, their order, their
+  paths and the merged record are identical, asserted beside the peak. The
+  result is built by preallocate-and-index rather than by arrival, which is what
+  keeps the sorted folder order true through a pool that completes out of order.
+
+- **The publish job runs on protected tags only, and it says so in the file
+  rather than in a settings page.** `rules` was `if: $CI_COMMIT_TAG`; it is now
+  `if: $CI_COMMIT_TAG && $CI_COMMIT_REF_PROTECTED == "true"`.
+
+  *The reason it needed to be in the file is that the comment beside it claimed
+  a defence that does not exist.* It said the reason to protect release tags had
+  changed — from exposing a masked variable to `id_tokens` being "issued to
+  protected refs only". That is not how GitLab issues them. Every job gets an ID
+  token, and the protection state travels *inside* it as the `ref_protected`
+  claim; a design that reports protection as a payload field is one where an
+  unprotected ref is handed a token too. Nothing on npm's end narrows it either:
+  a GitLab trusted publisher is namespace + project + top-level CI file path +
+  optional environment, with no ref condition available to configure.
+
+  **So the entire ref authorisation was the `rules` line — evaluated from the
+  `.gitlab-ci.yml` at the pushed tag, which is a file the pusher had just
+  written.** "Can push a tag" was therefore "can publish `@am_shork/attest` with
+  a valid provenance attestation", and the `NPM_ID_TOKEN` guard added in the
+  entry below cannot narrow it: that guard asks whether a token exists, never
+  who caused one to be minted. Protected tags in *Settings -> Repository* were
+  the only thing standing there, described by the comment as a belt-and-braces
+  extra.
+
+  This is the shape this repository keeps finding — a defence that reads as
+  present and is not, alongside `bin/attest.js`'s static import, the `hasWarned`
+  spread and `hmr: false` — arriving this time in the sentence explaining a
+  defence rather than in the code implementing one. Keep the protected-tag rule
+  in Settings as well: only that side stops the tag being created, and this side
+  only declines to publish once it has been. *Found by review, not by a run —
+  no pipeline was executed to confirm it, and the two vendor behaviours above
+  are read off GitLab's ID-token documentation and npm's trusted-publisher
+  documentation rather than measured here.*
+
+- **The publish job has no stored credential left: `NPM_TOKEN` and the
+  `_authToken` line are gone, and the guard is on `NPM_ID_TOKEN` instead.**
+  Completes what `[0.9.4]` set up. The deletion test pointed here from the
+  start — what it removes is the only long-lived credential this repository had.
+
+  *It went in on a measurement, and the measurement is the part worth keeping.*
+  The v0.9.4 release published through the trusted publisher, not the token:
+  `_npmUser` on that version is
+  `{"name":"GitLab CI/CD","trustedPublisher":{"id":"gitlab","oidcConfigId":"oidc:…"}}`,
+  by npm 11.19.0. The entry that proposed this recorded that **no account existed
+  anywhere of publishing from GitLab under OIDC** — every report was GitHub
+  Actions — and stated the inference at the strength the evidence carried. That
+  release is the first record. The token was present and unused: `oidc()`
+  overwrites the auth key on success, so the `.npmrc` line never applied.
+
+  **The job's own log could not have told us, and that is why the fallback had
+  to go.** Every path in npm's `oidc.js` logs at `verbose` or `silly` while npm's
+  default level is `notice`, so a successful exchange and a failed one produce
+  byte-identical job output — the v0.9.4 log contains no OIDC line of either
+  kind. Combine that with a fallback written never to throw and the failure mode
+  is exact: an exchange that stops working keeps publishing, on the credential
+  the exchange exists to retire, silently, with the difference visible only in
+  registry metadata nobody reads. **The property that made the rollout cheap is
+  the wrong one to keep**, and this is the first time in this file that a
+  mechanism has been removed for succeeding rather than for failing.
+
+  So the check moves in front of the irreversible step, which is the rule the
+  removed post-publish attestation check failed and this file already argued:
+  verification belongs where it can act on the answer. A missing `NPM_ID_TOKEN`
+  now fails before anything is published; a failed exchange fails the publish
+  outright, loudly and recoverably, because nothing was written.
+
+  *What is not in this repository, and is not done by this entry.* One act on
+  npmjs.com: *Require two-factor authentication and disallow tokens* on the
+  package, which is what stops a leaked token publishing it and which npm states
+  does not affect trusted publishers. Not a commit and not verifiable from here.
+
+  *The `NPM_TOKEN` CI variable stays, deliberately, and the reasoning is worth
+  recording because the first version of this entry had it wrong.* Deleting it
+  was filed beside the npm setting as though the two were equal acts. They are
+  not: the setting removes the **capability** — a token can no longer publish this
+  package — while deleting the variable removes **one copy** of a credential that
+  goes on existing in the npm account either way. Revoking it there is the act
+  that destroys it; removing it from GitLab is housekeeping. The variable is
+  masked, protected, exposed only to protected refs, and now read by no job, so
+  what it costs to keep is nothing. What the setting does not cover is measured
+  rather than assumed: it is per-package, and `@am_shork/attest` is the only
+  package in the scope, so today it covers the account's entire published
+  surface exactly. The gap it leaves is future-conditional — a second package
+  would start without the setting — and that is an obligation attached to
+  publishing a new package, not a reason to move a variable. *And the next tagged release is the test of this change*, the same way
+  v0.9.4 was the test of the last one — except that this time a regression fails
+  the release instead of quietly publishing. That is the intended trade.
+
+### Added
+
+- **`ATX-83` states the three states of that field.** What was missing was never
+  the field; it was a sentence the suite could falsify about *when* the field is
+  there. A requirement saying only "the report carries the paths the merge wrote"
+  is satisfied completely by an implementation that always emits `[]`, and that
+  implementation is wrong in exactly the case the field is reached for — a re-run
+  after a completed merge.
+
+  *Written straight into the registry, not through `changes/`.* That is how
+  existing behaviour is described here, and it is the reading `ATX-80`'s
+  `unarchived` state exists for: `never-red` asks for a recorded failing run only
+  of the ids a change is currently ADDing, so a requirement catching up to
+  behaviour that already shipped carries no such obligation and gains nothing
+  from a workflow whose point is to make a scenario fail before the code exists.
+  The scenario lives beside the other `archiveReport` ones in
+  `self/json.spec.ts`, where a reader looking at that function finds all of them.
+  Nothing records that it discriminates, which is what `unarchived` costs and is
+  worth saying rather than leaving implicit — so it was checked by hand instead:
+  with the one line that spreads the field into the report removed, the scenario
+  fails, and `verify self` reports `tests-red`.
+
+  The measurement in `tests/intent-rule-candidates.spec.ts` moved by exactly one
+  requirement — corpus 93 → 94, universal quantifiers 40 → 41 — and no verdict
+  in it flipped. It also produced the `flag:` divergence key's **fourth**
+  re-keying in four releases, every one triggered by an addition that agrees
+  with a member already there, and the `field:` key's first *extension* rather
+  than re-keying; both are noted where the rule is judged, because which of the
+  two an addition causes turns on vocabulary rather than on how related the
+  requirements are.
+
+- **`archive --apply --json` reports the paths the merge wrote.** The human
+  rendering has listed them since `--apply` shipped, on the grounds that this is
+  the command that edits files the user cannot regenerate and the reader needs to
+  know which ones to look at before committing. The `--json` reader — the one
+  most likely to be automating around the merge — got the change name and nothing
+  else. `written[]` closes that, and both renderings are now handed the same
+  bundle from one place in the shell rather than each being told separately,
+  which is the split that let the verdict disagree with itself in `[0.7.0]`.
+
+  **Absent without `--apply`, `[]` with it.** The two are different facts — no
+  merge was attempted, against a merge that ran and had nothing left to write,
+  which is the ordinary state of a re-run after a completed one — and a field
+  that spelled both `[]` could not say which. Additive, so no `SCHEMA_VERSION`
+  bump: a consumer that has never heard of the field reads the report it always
+  did. ATX-74's sweep covers it like every other string a report quotes out of
+  the checked project.
+
+### Fixed
+
+- **`first-run.json` committed different bytes for the same evidence, depending
+  on how many runs it took to gather.** `mergeRedRecord` rebuilds the record so
+  key order is a function of the data rather than of insertion — and did that at
+  two of its three levels. The rebuild sorts the requirement ids the record
+  already held; the loop after it *appends* the ids this run is the first to
+  observe, in plan order; and the pass at the bottom re-sorted the file and
+  scenario levels while walking the ids in whatever order they were in, because
+  reassigning `record[id]` does not move a key.
+
+  So a change that grew its record over several stage-1 runs committed
+  `{"Z-9": …, "A-1": …}` where the same observations reached in one run committed
+  `{"A-1": …, "Z-9": …}`. Nothing about the outcomes differs; the file does. That
+  matters twice over for this particular file: it is evidence a reviewer reads in
+  a diff, and the gate has to reach the same verdict on a CI checkout as on the
+  author's machine. It also went unnoticed once written — `changed` is decided by
+  the outcomes alone, so an unchanged record is never rewritten and a
+  wrongly-ordered one stays that way.
+
+  *ATX-15 already said this and could not catch it.* The requirement quantifies
+  over "every ordering Attest commits to disk", and the sweep attesting it is
+  deliberately narrower than its own statement: it checks *how* a site orders —
+  every `.sort` in `src/` through `byCodeUnit` — and says so, *"a `red-record.ts`
+  that stopped sorting at all is still green here, and the scenarios above are
+  what speak to the result"*. There was no such scenario for this file. There is
+  now, in `self/red-record.spec.ts`: it reaches the same evidence by both routes
+  and compares the serialised bytes. `archive.ts`'s `sortRecord` had all three
+  levels right and is what this now matches.
+
+- **`--apply` refused a registry whose literal is written with `as const`,
+  `satisfies`, or a bare pair of parentheses.** The reader takes all three —
+  `unwrap` strips the type-level wrappers before `literalValue` reads the object,
+  because none of them changes the value — so the gate read such a file, proved
+  the change green, and handed it to a merge that asked
+  `ts.isObjectLiteralExpression` of the wrapper and got `false`. Both writers
+  refused: the whole change stopped with `internal-error`, whose own message says
+  the file *"read as a registry for the gate but not for the merge"* and whose
+  comment calls the condition unreachable through the command. It was reachable
+  by writing `defineRequirements(({ … }))`.
+
+  *The fix is where the two answers diverged, not where the symptom showed.*
+  `authoringCall` is the single function both sides use to find the registry
+  literal — the module's opening note says a second walker would be a second
+  answer to "is this a literal" — and it handed back the argument node as
+  written, leaving each caller to decide whether to unwrap. The reader did and
+  the writers did not, so the disagreement the shared function exists to prevent
+  was inside it. It now unwraps once, and `literalValue`'s own call becomes the
+  no-op it should always have been.
+
+  The parenthesis is the reachable spelling and the reason this is a fix rather
+  than a nicety: `as const` and `satisfies` are opted into, while nothing about
+  `(({ … }))` looks like a type annotation anyone chose. No `SCHEMA_VERSION`
+  bump and no new code — a change that used to fail now succeeds, which is the
+  benign direction for an exit code, and the History row is what tells a reader
+  on an older build which half of the page applies to them.
+
+- **A registry key written twice made `archive --apply` write bytes outside the
+  value it was replacing — and, measured, outside the registry literal
+  altogether.** `registryEntryLayouts` keys each value's source span by name in
+  a `Map`, and `spliceModifications` walks that map to get its edits in
+  ascending offset order, which is what lets the pass at the bottom be a
+  `reverse()` rather than a sort. `Map.set` on a key it already holds keeps the
+  **first** insertion's position and takes the **last** call's value — so an
+  entry writing `params: { limit: 1, other: 'x', limit: 1 }` describes `limit`
+  at position one carrying the span of the occurrence *after* `other`, and the
+  offsets stop ascending. The earlier edit then moves the bytes under the later
+  one. On a registry the gate had just proved green, changing both values landed
+  the second one past the file's closing `});`.
+
+  *Nothing upstream refuses such a file, which is why this reached the one
+  command that writes.* A duplicate key is a TypeScript **semantic** error, and
+  `parseSource` asks only the syntactic question (`[0.9.0]`, ATX-69) — so both
+  registry readers take the file and hand back the last occurrence, `check` is
+  silent, and the gate passes. The reachable route is an ordinary copy-paste in
+  a hand-written registry, in a project that does not typecheck its
+  `*.reqs.ts`.
+
+  **Refused rather than described, at all three levels.** An entry whose keys
+  repeat is left out of the layout with the repeated key's path recorded beside
+  it, and `spliceModifications` turns that into an `apply-unsupported-delta`
+  refusal — whole, with nothing written — before a single edit is pushed. The
+  id level is not the mild one and is refused for the same reason rather than a
+  weaker one: two entries under a single id put a *later* entry's spans at an
+  *earlier* entry's position, so the disorder is between entries rather than
+  inside one. The guard stays exactly as wide as the danger — an unrelated id in
+  the same file is still written — because a merge that stopped over something
+  it was not asked to touch is the thing `--apply` refuses to do everywhere
+  else.
+
+  *The sibling defect is already in this file and did not generalise on its
+  own.* `[0.8.0]` fixed an integer-like `params` key for the identical
+  invariant — JavaScript hoists it to the front of every object, so a plain
+  object could not carry the file's order — and the repair was to move all three
+  levels to `Map`s. That answered the container and left the *keys*: a `Map`
+  keeps insertion order for every key type, and the one thing it still cannot
+  represent is one key written twice. The test added then, `rewrites two params
+  when one of them has an integer-like key`, is the shape of the three added
+  here, down to needing two changed values of different lengths — one edit
+  cannot be out of order with itself.
+
+  `verifyWritten` did catch the result and stop the merge, so the failure was
+  never silent; the file had already been overwritten by then, which is the
+  "destructive on a file the user cannot regenerate" shape the `AGENTS.md` merge
+  tool was rejected for and the reason a post-hoc check is not where this
+  belongs.
+
+  **Breaking, and narrowly so — this is the entry that decides the version
+  number.** The common case is not: a repeated key usually made the merge write
+  outside the value and the re-read then failed it, so the run already exited 1
+  and only the `code` moves — `internal-error`, raised after the registry had
+  been overwritten, becomes `apply-unsupported-delta`, raised before anything is
+  written.
+
+  But the offsets only go wrong when an earlier edit *changes length*. A
+  modification that replaces a value with one the same size shifts nothing, so
+  on `[0.9.4]` such a merge completed and completed **correctly**. Measured on a
+  registry with a duplicated `statement` and a `budgetMb: 1` → `2` patch: 0.9.4
+  merges it and it reads back as `{"budgetMb":2}`; today it refuses. That is
+  previously-valid input now rejected, which is this file's own definition of
+  breaking, so it takes the **minor** rather than the patch.
+
+  The refusal is still right — the same file with a length-changing patch is the
+  corruption above, and which of the two a merge gets is not something the author
+  chose. What the narrowness costs is that an adopter whose registry happens to
+  carry a duplicate key sees a working command start refusing, so it belongs in a
+  minor with the reason stated rather than in a patch nobody reads.
+
+  No `SCHEMA_VERSION` bump: the envelope, the `Issue` interface and the roster in
+  `core/docs.ts` are all unchanged — the refusal reuses the code `--apply`
+  already raises for a delta it will not write.
+
+  **`ATX-76` is widened to say what it always meant**, through this
+  repository's own workflow — `self/archive/2026-08-21-widen-atx-76`, the second
+  change to go through it and the first carrying a MODIFIED. Its refusal clause
+  named one instance of a class: *"when a span it would overwrite carries a
+  comment"*. Refusing a comment inside a span is not a rule about comments, it is
+  the rule that a replacement may only ever write the value it was asked to
+  write, stated at the one place that value's boundary was known to be in doubt.
+  A repeated name puts it in doubt a second way, so the clause now reads
+  *"wherever the file leaves that span uncertain"* and lists both. What is
+  **not** stated is the refusal as a mechanism: refusing is how *this*
+  implementation keeps the first clause, and a rewrite could keep it by ordering
+  the edits instead — a requirement pinned to the remedy would forbid that repair
+  for no reason.
+
+  *The defect was never that the rule was absent.* The first clause — the unit of
+  the edit is the value — has said this since `[0.9.0]`. What was missing was a
+  sentence the suite could falsify in this direction: both existing scenarios
+  assert something about a **comment**, and neither can go red when the failure
+  is that the span located was the wrong one. `self/merge.spec.ts` now carries a
+  third, looping the three sites a name can repeat with the extent pinned beside
+  the loop. Measured with the fix reverted, at the `spliceModifications` seam:
+  all three wrote without refusing; with it, all three refuse.
+
+### Documentation
+
+- **The CLI reference told readers the `--json` guarantee rests on
+  `JSON.stringify`, which is the reasoning `[0.8.0]` retired.** *Output is safe
+  to read* closed with "`--json` was never exposed: serialising escapes the same
+  characters" — true of C0 and of nothing else, so DEL and the C1 range were
+  never covered by it. The code has been right since `[0.8.0]`, where the
+  replacer in `renderJson` began stripping every string in the document as it
+  serialises one; the page kept the retired argument, in both languages, three
+  hundred lines above its own History row saying the opposite.
+
+  *The comment at the crash site in `cli/action.ts` said it too*, and that copy
+  is the one worth naming: it sat directly above `renderJson(errorReport(…))`
+  and read as a settled argument for why sanitising there was unnecessary. The
+  replacer it argues against is what makes that line safe. Nothing was
+  exploitable — this is a false rationale standing beside a working defence,
+  which is the configuration that gets a defence deleted by someone tidying up.
+
+  Found by an attack-surface review rather than by a gate, and no gate could
+  have found it: the suite checks that a `§n` a comment cites exists and that a
+  version a History table names is a heading here, never whether a sentence is
+  true. Three copies of one retired claim is what that gap looks like from
+  inside. No behaviour changed and no version moved, so there is no new History
+  row — the `[0.8.0]` row was correct all along and is what the prose now agrees
+  with.
+
+- **The method page says which shape a composite param is best at, and the
+  sample is a fixture that runs.** `intent-quality.md` already carried both
+  hazards a list-valued param has — an expectation recomputed from the param it
+  is checking, and a loop whose extent nobody pinned — as the third and fourth
+  of its five findings, named and left there with no shape attached. A **decision table**, rules pairing conditions with the
+  outputs the requirement promises, is where both arrive at once and where the
+  single source pays most, so it is now named. The section states the property
+  the shape actually rests on, which is narrower than "use a table": the
+  implementation reads only the *condition* columns, which leaves the output
+  columns an independent term — and it stops being true the moment the system
+  under test is itself driven by the same rules.
+
+  *The sample is `fixtures/consumer/requirements/cart.reqs.ts` and
+  `fixtures/consumer/cart.spec.ts`*, added here and registered in
+  `PUBLISHED_SAMPLES`, because every `ts` block this page publishes was already
+  a file the packaging test installs from a tarball and runs, and half-real
+  samples teach a reader to check which — after which they stop. **Making it
+  real is what found the constraint the section now documents**: the statement
+  cannot interpolate the table. A `{placeholder}` resolves to a scalar or a list
+  of scalars, so `{rules}` is `non-scalar-interpolation`, and the statement has
+  to name the behaviour in prose while the rules stay a param the scenario reads.
+  A draft written only as prose had it wrong and nothing would have said so.
+
+  It also landed on an existing row rather than needing a new rule:
+  `intent-rule-candidates.spec.ts` classifies it `over: 'roster'`,
+  `owner: 'registry'`, which is the branch that owes a `pin` — a registry-owned
+  list is data an author can shorten, and every assertion inside the loop still
+  passes over the shorter one. The published scenario carries that pin
+  (`expect(rules).toHaveLength(6)`), so a reader who copies the block copies the
+  counter-pressure with it.
+
+  *It was written into the README first, and has moved.* The README is the
+  pitch, the five-minute start and navigation; a hundred lines on how to write a
+  param that pins something is the method page's job, beside the two findings it
+  repairs. The README keeps one paragraph pointing at it. **The move is also
+  what showed `PUBLISHED_SAMPLES` could not say where a sample is published** —
+  it read the README and only the README, which was right while every sample
+  lived there and an obstacle the moment one did not. Each entry now carries its
+  page, so moving a sample between pages is a roster edit rather than a silent
+  loss of the gate that keeps it runnable.
+
+## [0.9.4] - 2026-08-19
+
+### Added
+
+- **A requirement can say a value is not decided yet, as `open` (`ATX-81`,
+  `ATX-82`).** The registry had two states, schema-valid or an ERROR, and there
+  was no third — so an author who could not determine a value had nowhere to put
+  that fact. What they do instead is pick one, and a scenario written against an
+  invented number is drift no gate can see: the single source is perfectly
+  consistent and describes a promise nobody made, arriving through the mechanism
+  meant to stop it. `open` is a free-text list of what is still undecided about a
+  requirement, one entry per question. The static commands report each as a
+  `requirement-open` WARNING and keep their exit code; the archive gate refuses
+  with `open-unresolved` while any remains. Promoted from *Under consideration*,
+  where the blockers were an unmeasured frequency and the permanent surface a
+  schema field costs.
+
+  *The asymmetry is the design, and it is `never-red`'s.* A proposal may be
+  legitimately half-finished while it is being written, and the four static
+  commands are where an author works during that; failing there would push them
+  back to inventing a value, which is the behaviour being replaced. Archiving is
+  where "done" acquires a hard definition, and a registry carrying an unanswered
+  question is not done.
+
+  *Re-measuring the entry before implementing it corrected it in four places,
+  per this file's own discipline.* **(1)** The proposed "WARNING from `check`,
+  ERROR at the gate" cannot be one diagnostic at two levels: `evaluateGate`'s
+  structure step already filters `validateStructure` to ERROR, so every WARNING
+  is discarded there. It needs its own gate step, which is what `never-red`
+  being the stated precedent actually implies. **(2)** The scope is the whole
+  merged registry, not the ids the change ADDs — and that is where it parts
+  company with `never-red`, whose narrower scope exists because "was ever
+  observed failing" is a fact about history that cannot be demanded
+  retroactively. An open question is a claim about the present. **(3)** The
+  entry over-counted the static extractor, which reads any literal property and
+  needed nothing, and under-counted `render`: without a section there, `SPEC.md`
+  — the only human review surface a requirement has — would not show that a
+  shipped requirement is open.
+
+  ***(4)* is the one that had to ship in the same change, and it is the
+  question `Planned`'s preamble says to ask.** `splice.ts` carries the comment
+  *"Any other field is one the schema does not define, and not this module's to
+  rewrite or to remove"*, and that sentence is true **only while `open` is off
+  the schema**. Adding the field without adding the two writer branches would
+  mean a change that *answers* a question is approved by the gate against an end
+  state the registry on disk does not match — the merge commits a file still
+  carrying the closed question, with nothing anywhere comparing the two. Not a
+  path the entry's own reasoning could reach, because it reasons about the field
+  being added and this is about the field being removed.
+
+  *Cost, stated rather than hidden.* One unresolved question anywhere blocks
+  every unrelated change from archiving. That is the intended reading of a
+  registry that is not done, it is recoverable by answering the question, and it
+  is the same all-or-nothing shape `verify` already has. `SCHEMA_VERSION` is
+  unchanged: two new `code` values are additive to the `--json` envelope. The
+  type surface **does** move — `Requirement` gains a required `open`, so code
+  constructing one by hand rather than through `defineRequirements` needs the
+  field. In this repository that was 26 sites, every one of them a test literal
+  that already spelled `outOfScope: []`; no adopter reading requirements is
+  affected, and `defineRequirements` still takes it as optional.
+
+- **This repository ran its own `changes/` → `status` → `archive` workflow for
+  the first time, and the change above is what went through it.** Every one of
+  the 80 requirements before it was written straight into the registry, so
+  `archive/` did not exist and `inspectRedEvidence` — shipped in `[0.9.3]` to
+  read it — reported all 252 declared scenarios as `unarchived`. The export had
+  no consumer that was not a test of itself for the second release running, and
+  this time the reason was not that nothing had been built on it but that the
+  repository had never produced the input it reads.
+
+  **The gate's first run failed on two of the five scenarios, and it was right.**
+  Both were the negative half of a pair — "says nothing when the list is empty",
+  "lets the gate through once every question is closed" — and both passed on
+  their first run, because an engine that has never heard of the field satisfies
+  "stays silent" trivially. `never-red` named them individually. The repair is
+  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
+  it was ever pointed at, in the author's own work.
+
+  *A second defect surfaced after `--apply` and is worth recording because
+  nothing catches it.* The proposed spec read its params through `delta.added`
+  rather than by id. A delta is *also* keyed by the ids it ADDs
+  (`withProposedRequirements`), which is what makes the import the only line the
+  merge has to change — reaching through `added` loads during stage 1 and throws
+  once the import is repointed at the registry. The gate cannot see it, because
+  the gate runs before the rename; `check` cannot, because it executes nothing.
+  It appeared at the next `verify` as `spec-load-failed`. The workflow document
+  already shows the by-id accessor; what it does not say is that the other one
+  works until it doesn't.
+
+  *What the archive now reports*, and it is the shape the design predicts rather
+  than a backlog: one archived change, 5 `fail` rows, 228 `unarchived`. The two
+  retired scenario names remain in `first-run.json` as `pass` and produce no
+  rows at all, which is `inspectRedEvidence`'s documented behaviour for a record
+  naming a scenario no spec declares any more — measured here for the first time
+  rather than reasoned about.
+
+### Changed
+
+- **The publish job publishes through `npm` and requests an npm OIDC token, so
+  trusted publishing becomes a setting rather than a rewrite.** The provenance
+  work in `[0.7.2]` signs the release but does not change what authorises it: a
+  long-lived automation token, masked and protected, that publishes as us to
+  anyone holding it. This is the half of removing it that lives in the
+  repository. Promoted from `Planned`; what remains there is narrowed to the two
+  npmjs.com settings that actually retire the credential.
+
+  *The one thing the entry was promoted with as unmeasured is now measured, and
+  it decides the rollout.* The question was whether a failed OIDC exchange falls
+  back to the `_authToken` already in `.npmrc` or fails the publish outright.
+  It falls back. Read off npm 11.10.1's `lib/utils/oidc.js` rather than inferred:
+  the function documents itself as intended never to throw, every failure path
+  logs at verbose and returns, the whole body sits inside a `try/catch` that also
+  returns, and `opts[authTokenKey]` is assigned only on success. So this lands
+  beside the existing token with nothing registered yet, and a failed exchange is
+  a quiet fall back rather than a failed release — which is what makes the first
+  tagged release a cheap test instead of an irreversible bet.
+
+  *`pnpm publish` was never going to work, and that is now an observation rather
+  than a strong inference.* The entry reasoned from `pnpm/pnpm#11526` that pnpm
+  gets out of the way and npm does the work. The call site confirms it:
+  `npm/lib/commands/publish.js` invokes `lib/utils/oidc.js`, so the exchange is
+  inside npm's publish command and no flag passed to pnpm reaches it. Hence the
+  client swap, which is a cost this file has already priced once in the other
+  direction.
+
+  *Two details the swap turned up that the entry had not counted.* `npm publish`
+  has no `--no-git-checks` — it warns *"Unknown cli config"* and does no git
+  checks at all — so the flag is dropped rather than translated. And the job now
+  runs `corepack enable pnpm` rather than the bare `corepack enable` plus the
+  `COREPACK_ENABLE_STRICT` override the entry expected to re-add: naming the shim
+  leaves the image's own npm alone for `npm i -g npm@^11.5.1` to upgrade, which
+  is the same outcome with one fewer environment variable and no refusal that can
+  be switched off by accident. `--provenance` stays explicit even though npm's
+  OIDC path can enable it by itself, because it only does so while `provenance`
+  is at its default — passing it keeps the setting this job's decision rather
+  than a side effect of whether the exchange succeeded.
+
+  *What is not claimed.* Nothing here has run. The job is exercised once per
+  release and cannot be tested any other way, which is why the fallback
+  measurement came first and why the token and its guard both stay. `NPM_TOKEN`
+  is still required and still what authorises the publish until a release is
+  observed going out without it.
+
+
+- **This repository's own judgement table now reads its scenario names through
+  `@am_shork/attest/inspect`, and what that measured is the point of the
+  change.** `intent-quality.md` names one read as the rot check every hand-judged
+  table needs — that a scenario a row claims is one a spec really declares — and
+  tells an adopter to get it from `inspectProject`. This repository's table got
+  it from `parseSpecs` and `findFiles` directly, because it was written while
+  both were internal. So the export shipped in `[0.9.2]` had **no consumer that
+  was not a test of itself**: `self/inspect.spec.ts` attests it, and nothing
+  built anything on it. Passing its own tests is not evidence that an export is
+  sufficient for the thing it was added for, and the only party who could have
+  found out otherwise was an adopter.
+
+  *Equivalence was measured rather than assumed, in both directions.*
+  `scanProject` sorts the same `findFiles` walk with the same `isSpecFile`
+  predicate, so the two reads should agree — and they do, compared as sorted
+  `(reqId, names)` pairs over the whole repo before the old call was deleted.
+  Then mutation-checked, because an assertion that still passes when the read
+  returns nothing is not reading anything: with the map stubbed empty the
+  rot-binding test fails and the other nine pass, which is the blast radius the
+  call actually has.
+
+  **What would not go through the export is the finding, and it is one thing.**
+  `Inspection.registry` is merged across registry files, so an id arrives with no
+  record of which file declared it. `corpus()` needs that — `source` is the scope
+  a cross-requirement rule sees, `divergentParam` keys on it, and the DOMAINS
+  completeness check uses it to hold the fixture registries out — and nothing in
+  the public export can reconstruct it. That half still deep-imports
+  `readRegistrySource`, with the reason written at the call site rather than left
+  as an unexplained inconsistency. It is filed as a measurement and **not** as a
+  decision to add a field: one caller wanting per-file attribution is one
+  adapter, and the entry under *Under consideration* about an outward-facing
+  judgement schema is waiting on exactly the second one.
+
+  *Cost.* `inspectProject` reads the registry as well, which this caller does not
+  need — one extra static read on a tree `corpus()` already walks once per call,
+  seven times per run. Paid deliberately: the alternative is deep-importing the
+  function whose reachability from outside the package is the thing being
+  demonstrated.
+
+### Documentation
+
+- **Design §11 now states that evidence outranks testimony, and that a
+  disagreement between them is a finding.** The registry and the gate's verdict
+  are evidence — machine-checked, recomputable, true of the tree as it stands. An
+  archived `proposal.md` is testimony: prose about a decision taken on one past
+  date that nothing has re-read since. A reader holding both holds claims in two
+  tenses with no stated order, and the order matters most exactly when they
+  conflict, because a stale proposal is more fluent than a registry and reads as
+  the more authoritative of the two. Decided from *Under consideration*, where it
+  had sat behind a blocker that was circular.
+
+  *The blocker was circular and naming the circle is what dissolved it.* The rule
+  was held back for describing a workflow the tool does not have — nothing read
+  the prose half — and the prose half was read by nothing **because no rule
+  existed for reading it**. Neither side moves on its own. The way out is the
+  split `[0.9.3]` already made for the propose-stage questions, where two of five
+  went to `CLAUDE.md` rather than into the document `init` writes: **this lands in
+  §11 only, and deliberately not in the instruction document.** §11 is a permanent
+  property of the design and its cost is paid once, here; the §10 document's cost
+  is paid in every adopting project's agent context forever, and that cost is what
+  the blocker was actually about. It is also the statement any later retrieval
+  surface would have to be built against, so writing it first is cheaper than
+  writing it after something depends on it.
+
+  *Re-measuring it before writing found the entry's own subject had stopped being
+  hypothetical, and falsified something this file recorded.* `[0.9.3]` states that
+  `proposal.md` in this repository "carries a link" — `CLAUDE.md` makes
+  `CHANGELOG.md` the single decision record, so a proposal restating an argument
+  would be a second store of it with nothing comparing the two — and concludes
+  there is nothing in it for an index to offer but its path. The very next change
+  to archive carries a proposal of **sixty-nine lines across five sections**, most
+  of its argument also present in the changelog entry. So the second store arrived
+  by ordinary means, in the first change that could produce one, written by an
+  author who knew the rule. The archived file is left as it is rather than trimmed
+  to a pointer: it is what the gate approved, and rewriting an archive to agree
+  with a claim about it is the failure this section is about, performed on itself.
+  §11 cites it as the measurement instead.
+
+  *What is deliberately not claimed.* The typed half cannot produce this conflict
+  — `first-run.json` is an `Outcome` in a schema-validated envelope, and a
+  scenario either is in the record or is not, so `inspectRedEvidence` reports an
+  absence rather than a contradiction. Nothing enforces the rule and nothing can:
+  reconciling prose against a registry is the ground truth §0 refuses to compute.
+  What §11 states is only the direction to reconcile in.
+
 ## [0.9.3] - 2026-08-18
 
 ### Added
@@ -5194,7 +5947,7 @@ time**.
 
 *The first time that question was asked in advance, it paid, and how it paid is
 worth a line because it is not what the two cases above would predict.* The
-`check` `empty-spec` entry — `[Unreleased]`, the third entry to reproduce exactly
+`check` `empty-spec` entry — `[0.9.0]`, the third entry to reproduce exactly
 on its reported half — was not wrong about its own repair. Asking the question
 anyway found the defect one step to the side: the fix it proposed was correct,
 and the *obvious implementation of it* — make `check` agree with `verify` —
@@ -5205,83 +5958,6 @@ path the repair makes reachable; it is about **everything the repair would make
 `check` agree with**, and an entry that names the right fix can still be
 implemented wrongly by copying the half nobody has audited.
 
-- **Trusted publishing, which would delete `NPM_TOKEN` rather than add to it.**
-  The provenance work in `[0.7.2]` signs the release but does not change
-  what authorises it: a long-lived automation token, masked and protected, that
-  publishes as us to anyone holding it. npm's trusted publishing exchanges the
-  same OIDC identity the attestation already uses for a short-lived credential,
-  which would remove the stored secret entirely and grant provenance as a
-  property of the flow rather than a flag on the command. The deletion test
-  points the right way for once: what it removes is the only long-lived
-  credential this repository has.
-  **The blocker this entry was filed with is retired, and it was the wrong
-  question** — checked against npm's documentation on 2026-08-08. It asked
-  whether npm's trusted publishers accept a **gitlab.com-hosted** project on the
-  plan this package publishes under, and both halves come back clean: GitLab
-  CI/CD is a first-class provider alongside GitHub Actions, and no plan
-  requirement is stated anywhere in the documentation. The four fields it wants
-  are `Pseudorca`, `attest`, the top-level CI file path (`.gitlab-ci.yml`, and it
-  must carry the extension) and the allowed actions; environment name is optional
-  and this project uses no GitLab environments. Shared runners are the only ones
-  supported and the publish job carries no `tags:`, so it is already on them. The
-  `repository.url` cross-check needs no separate verification — provenance
-  already passes it with the same identity.
-  Two things the entry did not anticipate, both of which change the shape of the
-  change rather than blocking it. **`SIGSTORE_ID_TOKEN` is not replaced**: the
-  documented GitLab snippet declares `NPM_ID_TOKEN` with
-  `aud: "npm:registry.npmjs.org"` *beside* it, so this is an addition to the
-  `id_tokens` block, not a swap. And **the YAML is not what deletes the
-  credential** — enabling a trusted publisher leaves the automation token just as
-  able to publish; what retires it is `Require two-factor authentication and
-  disallow tokens` on the package, which npm states does not affect trusted
-  publishers. That setting is the one that closes the loop this job's own comment
-  opens, where an automation token is used *because* a granular token fails
-  against 2FA on writes: trusted publishing does not bypass the prompt, it stops
-  being a token.
-  *What blocks the decision now is `pnpm`, and it is not a version to wait for.*
-  **pnpm does not implement the OIDC exchange at all.** `pnpm/pnpm#11526` — the
-  fix for the pnpm 11 regression that made this look like a supported path —
-  shows what its "OIDC support" is: `actions/setup-node` writes
-  `_authToken=${NODE_AUTH_TOKEN}` into `.npmrc`, pnpm used to pass the unresolved
-  placeholder through verbatim, and the fix treats it as empty so that **npm's**
-  credential exchange can be the sole auth source. pnpm gets out of the way; npm
-  does the work. That matches npm's own wording, which requires publishing
-  through npm directly or indirectly, and it matches the reports: every account
-  of pnpm publishing under OIDC is GitHub Actions, and there is **no record of
-  pnpm + GitLab + OIDC succeeding**. Stated at the strength the evidence carries:
-  this is a strong negative inference, not a documented refusal.
-  So the real cost is a tooling swap — `pnpm publish` back to `npm publish` in
-  this one job — and it is a swap this file has already priced once in the other
-  direction. The comment above records that moving to pnpm took
-  `COREPACK_ENABLE_STRICT` with it, that override having existed only so a bare
-  `npm` could run under a `packageManager` pinning pnpm; going back re-adds it.
-  It also needs npm ≥ 11.5.1 where `node:22-slim` ships 10.x, so the job gains an
-  npm upgrade step. None of that is prohibitive. It is simply a different
-  decision from the one this entry was filed as, which is why it stays here.
-  *One correction to the entry's own risk framing.* "It cannot be tested except
-  by publishing" is half wrong: registering a trusted publisher on npmjs.com is
-  free and reversible, and `NPM_TOKEN` can stay in place while it is tried. What
-  decides whether this can be rolled out incrementally is whether a failed OIDC
-  exchange falls back to the `_authToken` already in `.npmrc` or fails the
-  publish outright — unmeasured, and the thing to establish before touching the
-  job.
-  *Method note, because it is the reusable part.* The pinned pnpm bundle was the
-  obvious place to look and was the wrong one — `pnpm publish --help` on 10.28.0
-  omits the flags it accepts, exactly as this job's comment already records for
-  `--provenance`, so neither the help text nor the shipped bundle would have
-  answered it. The answer was in the upstream pull request.
-  **Promoted from `Under consideration` on 2026-08-08**, and what moved it is
-  that the question it was filed as is answered. It asked whether npm's trusted
-  publishers would accept this project at all; they will. What is left is a
-  known tooling swap with a priced cost, which is a decision to build rather
-  than a question — the preamble's own line, *a decision with an argument
-  attached*. One thing stays unmeasured and is the first act of building it, per
-  the discipline three paragraphs up: whether a failed OIDC exchange falls back
-  to the `_authToken` already in `.npmrc` or fails the publish outright. That
-  decides whether this rolls out incrementally beside the existing token or in
-  one cut, and it is cheap to establish because registering a trusted publisher
-  is free and reversible.
-
 ## Under consideration
 
 Candidates with **no decision yet**, between the two sections either side of it
@@ -5770,55 +6446,45 @@ have to gather again.
   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.
-
-- **A registry cannot say a value is deliberately undecided, and an agent that
-  cannot determine one will invent it.** From a read of GitHub's spec-kit
-  against this design — the first time another SDD toolkit has been compared
-  here rather than OpenSpec, and the source of this entry and the three that
-  followed it — of which two have since been decided: the audit of this
-  repository's own rules is rejected below, and the propose-stage coverage scan
-  shipped under `[0.9.3]`, as three questions rather than nine categories.
-  spec-kit marks an unresolved decision inline as `[NEEDS CLARIFICATION: …]`,
-  greppable, with a command whose whole job is converging them. Attest's
-  registry has two states: schema-valid, or an ERROR. There is no third.
-  *Why that matters here specifically, rather than as a general nicety.* The
-  workflow is written for an agent to follow — that is what `init` writes — and
-  an agent drafting a delta that cannot determine a timeout does not leave the
-  field out, because the schema will not let it. It picks a number. A fabricated
-  `params` value, then pinned by a scenario written to match it, is exactly the
-  drift this project exists to prevent, arriving through the mechanism meant to
-  stop it: the single source is perfectly consistent and describes a promise
-  nobody made.
-  *A precedent that is not one, recorded because it reads like one.*
-  `rationale-placeholder` already warns about authoring sloppiness in a prose
-  field, and the `init` document already teaches it — but it is about
-  interpolation syntax written into the wrong field, not about a value nobody
-  has decided. The engine's willingness to warn on prose is the precedent; the
-  diagnostic is not the feature.
-  *The gap is narrower than "the registry cannot express doubt".* `changes/` is
-  already the place where a whole proposal is undecided, and the archive gate is
-  what settles it. What has no expression is **one field** of an otherwise
-  well-formed requirement.
-  *Shape, if it is built:* an additive `open?: string[]`, naming the fields or
-  questions still unresolved; a WARNING from `check`, so a proposal may be
-  legitimately half-finished, and an ERROR at the archive gate, so "done" is not
-  diluted. The same asymmetry `never-red` already runs on.
-  *What blocks the decision — three things.* **(1)** The frequency is entirely
-  unmeasured. No adoption report has recorded an agent inventing a param; the
-  argument above is structural, and this project has twice been wrong about a
-  hazard it reasoned to rather than measured. **(2)** The cheap half already
-  works: writing the uncertainty into `rationale` as prose costs nothing, and
-  the propose stage is human-reviewed regardless. What that does not buy is a
-  gate, which is the whole question. **(3)** It is permanent surface — a schema
-  field, a code, two troubleshooting sections, a History row, an `ATX-n` and its
-  scenarios forever — for a hazard nobody has yet reported.
+  **Nothing currently makes that table arrive, which is a separate problem from
+  the three blockers and the one that gates all of them.** Raised in a product
+  review of `[0.9.1]`–`[0.9.3]` on 2026-08-19. The deciding evidence is an
+  artifact only an adopter can produce, and the path to producing it is: a row in
+  the README's document table, then a 214-line page, then a hand pass over four
+  questions, then writing the two mechanical properties from a prose
+  description, then choosing to report back. Five voluntary steps with no
+  scaffold at any of them, against a decision this entry has been waiting on
+  since `[0.9.2]`. An entry blocked on evidence that no shipped surface asks for
+  is blocked indefinitely, and the wait is not itself evidence of anything.
+  *The proposal is scaffolding the mechanism while still withholding the answer,*
+  which is the same split `[0.9.2]` already made and not a retreat from it: an
+  `examples/` directory holding the completeness and rot-binding assertions with
+  **no columns** — the enumeration that forces a row, and the check that a named
+  scenario is one `inspectProject` really declares — and the judgement columns
+  left for the adopter to add. What the page withholds is this repository's four
+  columns, and that stays withheld; what it currently also withholds is the two
+  properties it names as *mechanical*, and those are the half where a copy is not
+  an echo, because their content is fixed and the fourth finding does not apply
+  to them.
+  *What blocks it.* Whether a skeleton with no columns is still a shape that
+  comes back as a copy — the page's argument is that a template makes the answer
+  return its own question, and it is untested whether an adopter reads an empty
+  frame as an invitation or as a form to fill in. And it is a second artifact
+  claiming to be runnable consumer usage of the public API, which `pre-commit-check`
+  §6 already records as the category no gate reaches: the page's three samples
+  are unasserted today, and a fourth in a directory that looks executable would
+  be worse than a fenced block, not better, unless something runs it.
 
 - **Prefix ownership is inferred rather than declared, and the cost arrives only
   when adoption succeeds.** Design §11 records that the id grammar has no level
   above the requirement: the prefix is a convention, nothing allocates it, and
   `duplicate-prefix` can only report a collision that already happened.
   spec-kit's answer is a roadmap table — a stable id, an intent, a scope
-  boundary, dependencies — authored above the specs it decomposes into.
+  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 —
@@ -5857,53 +6523,26 @@ have to gather again.
   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:* the empty archive — the subject of the entry that
-  shipped under `[0.9.3]`, whose promotion this one does **not** inherit,
-  because the two changes that produced that corpus were ADDED-only and
-  exercised no rename at all — which makes a backlink index testable only
-  against fixtures; and one question the OpenViking reading
-  does not answer, which is whether the chain is wanted at all. §7 applies
+  *What blocks the decision, restated on 2026-08-19 because half of what was
+  filed here is no longer true.* This entry was blocked on the empty archive and
+  on the corpus being rename-free, and only the second still holds. `archive/`
+  now has a real change in it — the `open` field, put through the workflow the
+  same day — so the store this would index exists. Its delta carries `added` and
+  nothing else, measured rather than assumed, so a backlink index is still
+  testable only against fixtures for the operation it is actually about. Note
+  what that says about the odds of the blocker clearing on its own: `--apply`
+  refuses RENAMED outright, so no change this repository archives can ever
+  exercise a rename until that refusal is lifted, and lifting it is a separate
+  decision with its own reason (`splice.ts` — deleting an entry has no smaller
+  span to fall back to). The blocker is therefore not "waiting for a rename to
+  happen"; it is downstream of a refusal nobody has proposed removing. And one
+  question the OpenViking reading does not answer, which is whether the chain is
+  wanted at all. §7 applies
   `RENAMED` to a `Map<id, Requirement>` and the old id is then simply gone —
   deliberately, as far as anything written says. The case for recovering it is an
   external reference that outlives the rename, a ticket or a commit message
   naming a retired id, and nobody has reported one.
 
-- **The instruction document says how to write intent and nothing about how to
-  read the record back.** §10's one-document-many-targets file is entirely about
-  authoring, and the moment anything reads `archive/` — the entry above, and the
-  one that shipped under `[0.9.3]` — an
-  agent is holding prose from a proposal agreed on some past date against a
-  registry that is current, with no stated order between them. OpenViking states
-  one for its own store in the skill it ships to coding agents
-  (`agent-plugins/skills/openviking-memory/SKILL.md`): retrieved memory is
-  advisory, and the order is system and developer instructions, then the current
-  request, then current environment and tool evidence, then memory — with "prior
-  success never authorizes a destructive action now", and "store conclusions,
-  not scrollback".
-  *Here the same rule has a harder form, because the authoritative half is
-  machine-checked.* The registry and the gate's verdict are evidence; an
-  archived proposal is testimony about a decision taken once. Where they
-  disagree, the disagreement is a finding — the exact thing this tool exists to
-  report — and not something for a reader to reconcile quietly in favour of
-  whichever it read last. That is a property of the design rather than of a
-  file, so if it is taken it lands in design §11 first and in the instruction
-  document second.
-  *What blocks the decision:* it is a rule for reading a store nothing reads yet,
-  so on its own it would document a hazard that cannot currently arise. It is the
-  cheapest of the three and could ship first, at the price of being the only
-  paragraph in that file describing a workflow the tool does not have — and §10's
-  economics make that price the same in every adopter's agent instructions at
-  once.
-  **That blocker is retired, and what replaced it is narrower than the entry
-  assumed.** Something reads `archive/` as of `[0.9.3]`, so the hazard can
-  now arise. But what shipped reads the **typed** half — `first-run.json`, whose
-  every value is an `Outcome` in a schema-validated envelope — and evidence that
-  parses cannot disagree with the registry in the way testimony can: a scenario
-  either is in the record or is not. The rule this entry wants is about the prose
-  half, and the prose half is still read by nothing. So the store is no longer
-  write-only and the entry's own subject is still hypothetical, which is a
-  different blocker from the one it was filed with rather than none.
-
 - **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
@@ -5956,6 +6595,189 @@ have to gather again.
   looking at already being that page's subject, and this being a fifth of the
   same kind.
 
+- **`/inspect` returns five exported shapes and the page telling people to build
+  on them says nothing about whether they move.** Filed 2026-08-19 from a product
+  review of `[0.9.1]`–`[0.9.3]`. `inspect.ts` exports `Inspection`,
+  `ScenarioEvidence`, `EvidenceRow`, `ArchivedChangeRef` and
+  `RedEvidenceInspection`, and `intent-quality.md` carries three samples
+  destructuring them. `SCHEMA_VERSION` governs the `--json` envelope and nothing
+  governs these.
+  *The policy is not missing — its statement is.* The Versioning section at the
+  head of this file already binds them: removing or renaming a public API bumps
+  the minor, and under 0.x that is the breaking bump. So a reader who finds that
+  section is already told what they need. The gap is that the reader this export
+  was written for arrives through `intent-quality.md`, which is a method page
+  reached from the README's document table, and nothing on the path between the
+  two states it.
+  *Why it is worth a decision rather than a one-line edit.* The two candidate
+  sentences say opposite things to the person this needs. Restating the existing
+  promise reads as a stability guarantee and is the honest summary of current
+  policy; saying the shape may move before 1.0 is the more useful warning and
+  discourages exactly the adopter whose table would decide the judgement-schema
+  entry above. Which one is right depends on the 1.0 entry below, which is why
+  this is filed rather than fixed.
+  *One thing already measured, in the other direction.* `pre-commit-check` §6
+  records that changing what `/inspect` returns breaks three usage samples that
+  no gate can see. The internal awareness of this surface's fragility therefore
+  exists and is written down; the outward-facing half is what does not.
+
+- **The store worth retrieving is this file, not `archive/`, and no shape has
+  been proposed for either.** Filed 2026-08-19 from a product review of
+  `[0.9.1]`–`[0.9.3]`, and it is the OpenViking reading turned back on the
+  repository that did the reading. Everything that came out of it is about
+  `archive/`, and the entries are no longer counted here — the number was wrong
+  on the day it was written, was corrected on 2026-08-19, and was wrong again by
+  the next commit, when the precedence rule left for design §11. Three strikes on
+  one figure is the section's own preamble arriving in the first person: a count
+  kept in prose with nothing to check it goes wrong quietly, and the repair is to
+  stop keeping one rather than to keep fixing it. But `archive/` holds `first-run.json` — typed,
+  low-information, and now read — beside a `proposal.md` that in this repository
+  carries a link, for the reason `[0.9.3]` gives: `CLAUDE.md` makes this file the
+  single decision record. **So the store that actually holds decisions with their
+  evidence attached is `CHANGELOG.md`, at 7,100 lines with the three foot
+  sections past 1,700 of them,** and the property that makes it valuable — a
+  design evaluated, priced and killed, with the reasoning that killed it — is
+  exactly the property that makes it unreadable in one pass. It is append-only
+  with no retrieval, which is the shape the OpenViking reading was about.
+  *What an agent would actually consume is a composition, not a new store.*
+  Given an `ATX-n`: its statement and params, the scenarios covering it, the
+  first-run evidence for each, and the paths to the change that introduced it.
+  Four of the five are already computable — `inspectProject` answers two,
+  `inspectRedEvidence` the third and the archived refs the fourth — and the fifth,
+  the reasoning, is the one with no index and no key. That asymmetry is the
+  finding: the retrieval problem is not in the half that was just made readable.
+  *One thing to unmerge before deciding.* `[0.9.3]` settled a question against
+  the fifth static command, and it settled it correctly and on the right
+  grounds — `first-run.json` is JSON, and `ATX-16`'s subject is reading
+  TypeScript without evaluating it, so joining that roster would turn a security
+  promise into a list of commands that do not run the suite. But that is a
+  ruling about **roster membership**, and it is being carried as though it also
+  ruled on whether such a command should exist. Those are separate, and only the
+  first was argued.
+  *What blocks the decision, and what would cheaply unblock it.* No measurement
+  exists of whether a bundle like this changes what an agent does — the one datum
+  quoted in `[0.9.3]` measured demand to read the archive **as prose**, which is
+  a third question again. The proposal is therefore a probe and not a build,
+  per this section's own discipline of re-measuring before implementing: assemble
+  the bundle by hand for one requirement, run one real change against it, and
+  record whether it was used, ignored, or used wrongly. One session, and it
+  decides between a command, a skill surface, and nothing. Building any of the
+  three before that measurement is the order `divergent-param` was designed in
+  and the order this file has already paid for once.
+
+- **A stage-1 spec can read its params through `delta.added` instead of by id,
+  and the merge that repoints its import cannot repoint that.** Filed 2026-08-19
+  from the first change this repository put through its own `changes/` workflow,
+  where it was written by the author of the workflow's own tooling — which is
+  most of why it is worth an entry rather than a fix.
+  `delta()` returns the delta *and* the registry of what it adds
+  (`withProposedRequirements`), so `reqs['ATX-81'].params.field` reads a proposed
+  requirement before the merge and a merged one after it. That is the whole
+  reason merging a spec changes its import and nothing else. Reaching through
+  `added` — `d.added['ATX-81'].params.field` — is equally correct during stage 1
+  and throws the moment `--apply` repoints the specifier at the registry, because
+  a registry has no `added`.
+  **Nothing catches it, and the reason is structural rather than an oversight.**
+  The archive gate runs *before* the rename, so the spec it graded is not the
+  spec the merge commits; `check` executes nothing, so it never evaluates the
+  accessor; and the type checker is satisfied on both sides of the merge only
+  because it is run against whichever half is currently on disk. It surfaced at
+  the next `verify`, as `spec-load-failed` — a correct diagnosis of the symptom
+  that names the file and not the cause. The window between `--apply` and the
+  next `verify` is the whole exposure, and in a workflow that ends at `--apply`
+  it is unbounded.
+  **The guidance already exists and did not prevent it, which is the finding.**
+  `registry.ts`'s doc comment on `delta` states the intended expression and the
+  rejected one, in those terms, on the function itself; the document `init`
+  writes shows the by-id form in its worked example. So this is not a gap in what
+  is written. It is a case of the correct form and an incorrect one being
+  *indistinguishable at the moment of writing* — both compile, both pass, both go
+  red for the right reason — with the difference appearing one command later.
+  *Two shapes, and they point opposite ways, which is why this is filed rather
+  than fixed.* **(1)** A `check` diagnostic: `parser.ts` already walks property
+  accesses inside spec bodies to find `.params`, so finding `.added` on a binding
+  imported from a `requirements.delta` path is the same walk and the same file.
+  It has to be a WARNING, because enumerating what a change adds is a legitimate
+  thing for a spec to do, and a WARNING is exactly the strength that did not stop
+  the author here. **(2)** A type-level refusal: have `delta()` return a type
+  without `added`, so `typecheck:all` refuses it with no new diagnostic, no
+  roster entry and no runtime cost. `DefinedDelta<T> = T & ProposedRequirements<T>`
+  carries `added` because `T` does, so this means `Omit<T, 'added'>` — and that
+  breaks the evaluating loader, which hands the same default export to
+  `applyDelta` typed as `RegistryDelta`. Whether that break is real or just needs
+  the internal path to name a different type is **unmeasured, and is the first
+  thing to establish**; it decides between the two shapes rather than being a
+  detail of one.
+  *What blocks the decision:* frequency, and it is the same blocker the `open`
+  entry carried before it — one occurrence, in one repository, on the first
+  change ever run through the workflow. That is a report rather than a
+  hypothetical, which is more than most entries here start with, and it is still
+  n=1. What would settle it cheaply is the next change: if the by-id form is
+  written without prompting, the guidance is sufficient and this is an anecdote;
+  if the reach-through appears again, the two shapes above are worth pricing.
+
+- **Nothing is frozen, and the evidence this repository is waiting for requires
+  somebody to build on something.** Filed 2026-08-19 from a product review of
+  `[0.9.1]`–`[0.9.3]`. Three releases in five days each added public surface, and
+  as of `[0.9.3]` the CLI, `./define`, `./inspect`, the archive layout, the
+  judgement schema and any retrieval surface are all simultaneously open. Every
+  entry in this section that is blocked on an adopter — the judgement table above
+  being the sharpest — is asking someone to invest in a surface that is
+  documented as movable. That is a coherent thing to ask under 0.x and it is also
+  the reason the ask may never be answered.
+  *The proposal is a line rather than a milestone:* 1.0 freezes the CLI, `./define`
+  and `./inspect`, and everything currently blocked on an adopter's evidence —
+  the judgement schema, the backlink index, any archive retrieval — is explicitly
+  1.x. What that buys is not a version number; it is the only condition under
+  which "build your own counter-pressure on our export" is a reasonable thing to
+  ask of somebody.
+  *What blocks it.* Freezing `./inspect` five days after shipping it is freezing
+  on one adapter, which is the objection this repository raises against every
+  other premature interface and does not get to waive for its own. And the
+  release-notes discipline cuts both ways here: a 1.0 is a claim about what the
+  cost of adoption will be, and `Planned`'s own preamble records that **what a
+  release costs its adopters is not known on the day it is cut**. There is no
+  measurement to date of anyone adopting either export.
+
+- **When one requirement carries several scenarios, some of those sets are
+  differential evidence and nothing in the model says which.** Prompted by an
+  external write-up (`columns.chicken-house.net`, 2025-11-10, "AI-First Testing
+  Workflow"), which ran one test case against a system's REST API and against its
+  web UI and found the empty-basket check implemented in the UI and absent from
+  the API. Neither run failed against its own expectation; the finding was that
+  two runs of the *same* case disagreed.
+
+  Attest already permits the arrangement — a `reqId` takes any number of
+  attesting scenarios, and `cover` asks only for ≥1. What it cannot see is the
+  difference between three scenarios covering three edges of one requirement and
+  three scenarios crossing three interfaces at the *same* edge. The second set
+  can be asserted to agree; the first cannot, and there is nothing to compare.
+  This repository runs the pattern on itself — `tests/static-registry.spec.ts`
+  asserts the two registry readers agree — so the structure is known to work
+  where the two adapters are known to be two adapters.
+
+  *What blocks it, in the order that decides it.* **The seam is unmeasured.** One
+  adapter is a hypothetical seam and two is a real one; nothing has been walked
+  to establish whether any adopted registry has a `reqId` whose scenarios
+  genuinely cross interfaces rather than covering one surface repeatedly. Until
+  that is counted this is a pattern observed in somebody else's codebase, and it
+  is cheap to count. **The fact is not in the model.** Which interface a scenario
+  crosses is recorded nowhere the engine reads, so supplying it means new
+  registry or spec surface — a per-scenario axis — paid for by every adopter
+  including all of the ones with a single interface, in the shape of a thing they
+  must learn not to write. Whatever carried it would also have to be a literal in
+  the AST, because `cover` executes nothing and that is not negotiable for it.
+  **There is no verdict to emit.** The engine cannot perform the comparison;
+  agreement between two runs is an assertion and assertions belong to the test.
+  The most it could report is that a requirement has scenarios on more than one
+  axis, which is information with no pass or fail attached — a new output
+  category rather than a new check. **And the prose alternative is untried.**
+  Apply the deletion test before the field: if the workflow document `init`
+  writes (§9) simply says that two scenarios crossing one requirement at
+  different interfaces should assert the same expectations, does the practice
+  happen anyway? If it does, the engine gained nothing and charged everyone a
+  field for it.
+
 ## Considered and rejected
 
 Decisions **not** to build something, kept where they can be found before the
@@ -5966,6 +6788,41 @@ 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.
 
+### Rewriting the placeholder scan in `prose` to drop its tail slice
+
+Priced on 2026-08-21, during a standing sweep for more of the ATX-59 shapes, and
+rejected by the measurement that was supposed to confirm it.
+
+`prose` (`core/render.ts`) walks a statement character by character, and at every
+`{` it runs `/^\{\w+\}/.exec(text.slice(i))`. Read as source that is the §2
+quadratic-scan shape exactly: one fresh copy of the remaining string per `{`, so
+a statement of n braces copies n²/2 bytes — and a statement is prose a fork
+contributor writes and `render --check` reads under the static reader, which is
+the class that has actually shipped defects here. The fix was to be a sticky
+`/\{\w+\}/y` with `lastIndex = i`, which allocates nothing.
+
+**It is not quadratic, because V8 does not copy.** `String.prototype.slice` on a
+string past a small threshold returns a *sliced string* — a view onto the parent
+with an offset, made in constant time — and an anchored regex over it reads only
+the few characters it needs, so the copy the source implies never happens.
+Measured through `renderMarkdown` on the built output, three adversarial shapes
+(all braces; alternating `{a`; a brace run followed by a word run), at 100k
+through 800k characters: every one of them scaled at a ratio of **1.77–1.89 per
+doubling**, i.e. linear, and 800,000 braces rendered in **106 ms** against
+ATX-59's 1,000 ms budget. A quadratic implementation at that size would be tens
+of seconds; this is the same order as the linear cases beside it.
+
+So there is no defect and no change. What the sticky rewrite would buy is a
+constant factor nobody has shown a need for, against §5's rule that
+micro-optimisation with no named input is out of scope — the input *is* named
+here, and it is already absorbed. Filed rather than dropped because the site
+reads like the defect on inspection and will be proposed again by the next sweep
+that greps for `.slice(` near a loop: the answer is that V8's representation is
+load-bearing, the measurement is the evidence, and the thing to re-run is the
+ratio rather than the reasoning. Note the limit of that claim — it rests on a V8
+representation rather than on anything the language promises, which is safe for a
+Node CLI and would not transfer to a runtime that flattens eagerly.
+
 ### Deferring the `typescript` import so `init` and `--version` do not pay it
 
 Priced on 2026-08-13, in the session that enabled the compile cache above, and
@@ -6138,7 +6995,7 @@ weaker signal "some registry file failed to load, so suppress all
 `orphan-test`" is the other candidate and is a strictly worse `check` on a
 multi-file registry, where the other files are fine and their orphans are real.
 **The wrong *advice* was separated out and fixed in `[0.7.0]`; the noise is
-fixed under `[Unreleased]`, and the blocker above was the wrong question.**
+fixed under `[0.7.4]`, and the blocker above was the wrong question.**
 The mapping this entry called for could not be recovered, and did not have to
 be: what a suppression needs is not the broken file's *prefix* but the ids it
 declares, and those are written in its source. Reading them back is a source
@@ -6164,7 +7021,7 @@ breadth argument recorded above, which points the other way for both commands.
 *What rejected it is that the argument for it was entirely the noise, and the
 noise is gone.* Refusing was never justified by the load failure itself — it was
 justified by the wall of derived findings burying it, and the collapse under
-`[Unreleased]` removed the wall without touching either command's breadth. What
+`[0.7.4]` removed the wall without touching either command's breadth. What
 is left on the table is the breadth argument alone, and it points the other way
 for both: `check` is the command a pipeline runs first, its contract is seeing
 everything it can still see, and answering with three findings instead of nine
@@ -6265,7 +7122,7 @@ measurement** saying parsing costs anything here — this reader is
 `createSourceFile` per file with no type checking, which is the cheap half of
 what arktype pays for, and the fan-out measurement — filed as an entry in
 `Under consideration`, and now shipped as the two concurrency bounds in
-`[0.7.0]` and `[Unreleased]` — clocked `attest check` over 6000 spec files at
+`[0.7.0]` and `[0.9.0]` — clocked `attest check` over 6000 spec files at
 1.99 s total. Worse, a cache is a correctness hazard
 of precisely the kind this tool exists to detect: a stale analysis makes a
 **drift detector** report drift that has already been fixed, or miss drift
@@ -6287,7 +7144,7 @@ to be stronger than an mtime before the trade is even worth pricing.
 
 ### Zod Mini (`zod/v4-mini`) for the registry schema
 
-Evaluated alongside v4 (which shipped under `[Unreleased]`), on the same
+Evaluated alongside v4 (which shipped under `[0.8.0]`), on the same
 schema and the same 69-requirement registry, and it wins both numbers it is
 supposed to win:
 **0.249 ms** per parse against v3's 3.47 ms, and — the one v4 does not deliver —
@@ -6569,7 +7426,7 @@ current.
 
 The mechanism `ATX-37` sat under `Under consideration` waiting for, kept there
 on cost, and killed by measuring that cost rather than by paying it. The three
-sites it was aimed at are closed under `[Unreleased]` by hand-written scenarios;
+sites it was aimed at are closed under `[0.7.4]` by hand-written scenarios;
 what is rejected is the roster, and the argument is that **`src/cli/report.ts`'s
 exports are the wrong roster in both directions at once.**
 
@@ -6860,6 +7717,8 @@ rather than a scorer, which ranks.
 
 ## Releases
 
+[0.10.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.10.0
+[0.9.4]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.4
 [0.9.3]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.3
 [0.9.2]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.2
 [0.9.1]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.1