@am_shork/attest 0.7.4 → 0.9.0

package/CHANGELOG.md

@@ -13,6 +13,873 @@ 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.9.0] - 2026-08-12
+
+### Added
+
+- **`--apply` writes MODIFIED requirements back, at the granularity of a value
+  rather than an entry.** `merge.ts` refused any delta carrying `modified` for
+  five releases, and what that refusal cost is on the record rather than
+  estimated: in one adopting project **5 of 19 changes carried `modified`**, each
+  merged by hand with a script the author rewrote five times in a session, which
+  located `  'AUTH-7': { … },` in the registry **by regex**. `[0.6.0]` cites
+  eight hand-written Python scripts — one of them that same regex locator — as
+  the evidence that this step must not be left to the adopter, so the refusal had
+  reproduced the tool it was meant to retire, inside a project that had `--apply`
+  available.
+  **The argument the refusal rested on was subtly wrong, and correcting it is
+  what made this buildable.** `--apply` is allowed to edit a hand-written
+  registry because "the result is checkable by re-reading it", and the entry
+  proposing this narrowed on the wrong axis in consequence — accept an entry only
+  when its whole span is comment-free, which lowers the *rate* of destruction and
+  not its *size*. A re-read compares values and is blind to what was **lost**: a
+  replacement that ate a comment passes one cleanly. So the unit of the edit is
+  the value, not the entry. `statement` and `rationale` replace a string
+  literal's span, where a comment cannot be present by construction; a `params`
+  key replaces that key's value span and a new key is a pure insertion;
+  `outOfScope` replaces the array literal. Everything else in the entry — the
+  keys, the commas, the layout, every comment on a field that did not move — is
+  bytes the edit never addresses.
+  **Refused, still whole, when a span that would be overwritten carries a
+  comment**, as `apply-unsupported-delta` naming the requirement and the field.
+  Measured over this repository's own registry before it was built, on
+  2026-08-11: **75 entries, 3 carrying a comment anywhere inside them, all three
+  inside a `params` value**, and none at all inside a statement or a rationale.
+  So the refusal is the rare case rather than the categorical one, and every
+  refusal is still a merge nobody has to trust.
+  **RENAMED and REMOVED are deliberately still refused, and the granularity is
+  the reason they are now separable.** "REMOVED cannot say which comments
+  belonged to the entry it deletes" is the sentence the two shared, and it
+  survives untouched: deleting an entry has no smaller span to fall back to,
+  while the same question one level in is answered by not replacing that level.
+  **Two things this brought with it.** The re-read is now performed rather than
+  argued — after writing, the registry is read back and every id the edit was
+  answerable for is compared against what the gate proved, ADDED included, since
+  a check covering only the newer half would leave the older claim exactly as it
+  was. And every registry edit is computed before any file is written, so
+  "refused whole" is true of the write-back and not only of the delta's shape;
+  before this, the one thing that could fail during text generation — a
+  `__proto__` param key — failed one file at a time.
+  Held as `ATX-76`, whose scenarios read the registry as **text**: a merge that
+  regenerated the entry would produce a file reading back as exactly the same
+  requirement, so nothing about the parsed end state can tell a value-sized edit
+  from a rewritten one. `ATX-54` keeps the refusal half over what is left.
+  *One limit, recorded so nobody assumes otherwise:* a patch cannot express
+  **deleting** a `params` key — `applyDelta` merges keys and never drops one — so
+  write-back does not cover that, and no amount of span work would.
+
+- **The workflow document now describes an inner loop for stage 2.** Its only
+  instruction there was `attest archive`, which applies the delta and runs the
+  base suite, so an agent iterating toward green paid the full gate after every
+  edit — and `status` cannot help, its two obligations both being settled at the
+  end of stage 1. The addition needs no engine change: run the proposed spec file
+  directly while you are still making it pass, keep the gate for the verdict.
+  Measured before it was written — a `*.proposed.spec.ts` runs under a plain
+  Vitest invocation, delta import included — and it carries the two things that
+  make it safe and the one that makes it not a verdict: nothing but the gate ever
+  writes `first-run.json`, `status` still answers the readable half, and a green
+  file does not predict the gate, because the direct run gets the project's
+  environment and the gate's child run is isolated. That last point is the
+  `tests-red` section's existing subject, so it is pointed at rather than
+  restated.
+
+- **`status` applies the change's delta and refuses the report when it does not
+  fit, which no static command checked at all.** `applyDelta` produces six
+  diagnostics — a rename whose target exists or whose source does not, a
+  modification of an absent id or one leaving the requirement invalid, an
+  addition that is invalid or conflicts — and nothing reached them without
+  running the suite first. `check` reads deltas, but only to attribute proposed
+  specs; it never applies one. So a delta wrong in any of those six ways was
+  first heard from `archive`, in the workflow position where the specs and the
+  implementation are already written, about a fact that was available the moment
+  the delta was saved.
+  Refusal rather than a row, because there is no row that could be right: the
+  states this command reports are progress toward an *applied* registry, and a
+  delta that cannot be applied has none to be progress toward — an `unproven`
+  against it is a true-looking sentence about a change that cannot exist.
+  Held as `ATX-78` rather than under `ATX-33`, which the cheap implementation
+  makes clear: `ATX-33` constrains what an ERROR from this command *means*, and
+  an implementation that never detects an unapplicable delta satisfies it
+  completely, vacuously, having no ERROR to constrain. This is the detection —
+  the same split `ATX-69` records against `ATX-65`.
+  **Behaviour change, and the reader it costs is not the one being fixed.**
+  Applying a delta needs the registry, which this command did not read before, so
+  a project whose registry is not a literal now gets `registry-not-static` and no
+  report where it got a report, and gets it back only under `--eval`. That is the
+  trade `ATX-16` already makes for `check`, `cover` and `render`, arriving at the
+  fourth static command. The registry is read through whichever reader the
+  command was asked for, so `--eval` moves both halves together rather than
+  quietly evaluating one to make the other work.
+
+### Fixed
+
+- **`status` told the reader to write a scenario that was already on disk.**
+  `changeMergedPlan` returns the specs neither parse could read, and says in
+  place why they block: an unreadable proposed spec is a scenario the gate would
+  otherwise report as absent. `archive` acts on that list before it runs
+  anything, on the argument that a plan known to be short cannot grade a change
+  (ATX-65). `status` took the plan from the same call and destructured only
+  `merged`, dropping the issues — and every state it prints is computed *from*
+  that plan, so a claimed `*.proposed.spec.ts` that failed to parse left its
+  requirement with no scenarios in the plan and the row came back
+  `no-scenario`, with `issues` empty and `ok` true.
+  **Not an under-report but the inverse of one**, which is why it is a fix rather
+  than a widening: the command whose stated contract is to be a projection of the
+  gate answered the opposite of the gate about the same change, and the advice it
+  produced — write the scenario — is work the reader has already done. The one
+  thing that makes it recoverable is that `status` writes nothing.
+  **Behaviour change, and it moves an exit code.** A change in that state now
+  fails with `unreadable-file` and exits 1 where it printed a table and exited 0.
+  Anything wrapping `status` in a loop sees red on input that used to pass — but
+  the input is a spec file that does not parse, and the table it used to print
+  was wrong about it.
+  Held under `ATX-33` rather than as a new requirement: the rule it is an
+  exception to is untouched — an unmet obligation is still a row, never a verdict
+  — and what moved is which input that exception covers.
+  **Stating it exposed that the exception could not be enumerated, so it is now a
+  class and the code list is gone rather than extended.** `ATX-33` had named the
+  one code that could make `status` fail, and adding a second is what showed the
+  shape: the roster it can *actually* fail with was already longer than the list
+  on the day the list was written — a rejected change name and an unusable
+  compiler were never in it — and it grows with every input the command learns to
+  read. A param extended per failure path is a name for the implementation rather
+  than a contract, and it fails in the direction that hides, since a code missing
+  from it makes the requirement quietly false rather than red. What the statement
+  carries instead is the property worth preserving: **an ERROR from `status`
+  always means there is no report**, so a reader who sees one never has to ask
+  whether progress was being scored. That is **the first `params` key ever
+  removed from this registry**, against 57 added and one value changed; the
+  removal is the safe direction for the same reason those additions were, since
+  what the scenarios assert is broader than what the list named, not narrower.
+  **The measurement suite priced it in two places and one of them was a
+  finding.** The restated sentence is universally quantified, so
+  `tests/intent-rule-candidates.spec.ts` demanded a `QUANTIFIED` row and got the
+  `sites` shape — the members are early returns in one function, so nothing
+  enumerates them and no scenario can iterate them, which is the `ATX-37`
+  position that table exists to record. Two sites were unreached; one is closed
+  here by a scenario, and **the compiler path stays open as a measured gap,
+  taking that table from one to two**. It was not created here: `status` could
+  always fail that way with nothing attesting it, and naming the failing half as
+  a class is what made the site visible at all.
+  No `SCHEMA_VERSION` bump: `issues[]` already carries this code and the envelope
+  is unchanged. `unreadable-file` is not a new code either — what is new is a
+  fourth command that can raise it, which is why the troubleshooting section now
+  says which commands stop on it and which keep going.
+
+- **The workflow document said a proposed spec stays out of a plain `vitest run`,
+  and it does not.** `*.proposed.spec.ts` ends in `.spec.ts`, so an ordinary
+  `**/*.spec.ts` include — Vitest's own default among them — matches it;
+  confirmed by running one. Only *Attest's* scope excludes it. The claim was
+  wrong in the direction that surprises: during stage 1 those scenarios are red
+  by construction, so an adopter following this document is told their own
+  `npm test` will be unaffected and then watches it go red, at the exact moment
+  the framework is asking them to trust a workflow they have just met. The
+  sentence now claims only what is true, and the optional `exclude` is shown —
+  as the reader's decision about their own suite, which is not one Attest makes
+  for them.
+  *That sample spreads `configDefaults.exclude`, and the reason is worth the
+  line it costs.* Vitest's `exclude` **replaces** its defaults rather than
+  extending them, so the obvious one-liner silently un-excludes
+  `**/node_modules/**` — measured, not inferred: a bare
+  `exclude: ['**/*.proposed.spec.ts']` collects and runs a `*.spec.ts` planted
+  inside `node_modules`. This repository's own `vitest.config.ts` has always
+  re-added those globs by hand, so the trap was already known here and would
+  still have shipped in advice written for someone else. A sample in a document
+  is executed by whoever copies it, and this one was two lines from turning a
+  cosmetic complaint into a broken suite.
+
+- **The workflow document contradicted itself about `apply-unsupported-delta`,
+  and the half an agent branches on was the stale half.** The commit that taught
+  `--apply` to write MODIFIED back edited the prose in `skill.ts` and left the
+  code table eleven lines above it reading `--apply` writes back ADDED only, and
+  this delta carries more. So an agent meeting that code looked it up, concluded
+  the delta carried something unsupported, and would have gone off splitting
+  MODIFIED out of it — when the actual cause is now most often the other one the
+  same code covers, a comment sitting inside the span a MODIFIED value would be
+  written over. **A wrong cause costs more than a missing one**, because it sends
+  the reader to a repair that cannot work; the row now names both.
+  *What this says about the gate that exists.* `ATX-57` holds that every code the
+  workflow names is one the engine can emit, and its rationale records the
+  one-directionality as deliberate — the document has no business naming every
+  code, so the obligation is only that what it names exists. That is untouched
+  here and still right: the code existed, and what moved was its *meaning*.
+  `skill.ts`'s own note said "read this file when a release adds a diagnostic",
+  which is the rule that would not have caught this. It now says *or changes what
+  one means*, and to grep the body for the code rather than trusting that the
+  section just edited was its only mention.
+  *No `ATX-n`.* The obligation this would state — every description in the
+  workflow matches what the engine does — is the one nothing can check, which is
+  why `ATX-57` stops where it does. Adding a requirement that no scenario can
+  falsify would be a green tick over an unguarded property.
+
+- **`attest status`'s documented surface was wider than the command, in three
+  places at once.** All three say some version of "`status` reports what the gate
+  still wants, and the one thing it cannot see is whether the tests pass". It is
+  a strict subset of that: `statusRows` projects the *uncovered* half of gate
+  check 1 and the whole of check 4, both restricted to the ids a change ADDs.
+  Check 3 reads `runtimeCoverage`, which only the suite produces — so a scenario
+  left `skip`ped blocks `archive` with the suite fully green and `status` fully
+  clean, which is exactly the conclusion the sentence invites a reader to rule
+  out. Orphans and unbound params are not projected either. Corrected in design
+  §8 (both languages), in the workflow document, in that document's command
+  table, and in the README's command list — four copies of one gloss, which is
+  the count worth recording: the phrase was not repeated because anyone reasoned
+  it four times, and correcting three of them would have left the repo saying two
+  different things about one command.
+  **Design §8's sentence was wrong on the day it was written, not stale, and the
+  difference was worth checking rather than assuming.** The tidy explanation was
+  that `declared-not-run` had been inserted as check 3 and renumbered the list
+  under a sentence nobody re-read — this file's own recurring lesson, and it fits
+  so well it was nearly written down. `git log -S` says otherwise: the numbering
+  has had check 3 reading `runtimeCoverage` since 2026-07-21, and the sentence
+  claiming check 3 is decidable without running anything arrived six days later.
+  So the mechanism here is not drift at all. **A sentence that enumerates a list
+  written a few lines above it is not checked against that list by anyone,
+  including its author**, and no gate reads prose.
+  *Separately, `status`'s History table was missing `0.8.0`.* Moving the
+  first-run record to `version: 2` — filed against `archive`, where the change
+  was made — also moved `status`'s output, because the two read that file with
+  the same predicate. Measured: the same change reports `✓ AUTH-7 2 scenarios,
+  seen red / 1 ready to archive` on a version-2 record and `● AUTH-7 2 never
+  run / 0 ready to archive` on the version-1 record a 0.7.x change carries. The
+  row is owed by the rule that a History table is the only thing that can tell a
+  reader on an older build which half of the page applies to them, and it is the
+  shape that hides: `status` exits 0 either way, so nothing anywhere turned red.
+
+- **The workflow document never said a delta must be a literal.** It states the
+  rule for `*.reqs.ts` and stops there, while `check` and `status` read
+  `requirements.delta.ts` through the same static reader — so an agent lifting a
+  `const` out of a delta, which is the ordinary thing to do when two params share
+  a value, meets `registry-not-static` pointing at a file the rule it was given
+  never mentioned. Confirmed by running it rather than by reading the reader:
+  `attest status` on a delta whose param is an identifier reports
+  `registry-not-static` at that line. `changes/` is also the more exposed of the
+  two files, being by definition the one still under review, so it is the worse
+  of the two to leave undocumented.
+  *The same roster was short in `CLAUDE.md`*, which named three commands that
+  execute nothing where `ATX-16.staticCommands` names four — `status` being the
+  one missing, for the same reason: what it reads statically is a delta rather
+  than a registry, so it falls outside a sentence scoped to `*.reqs.ts` while
+  being squarely inside the security property that sentence exists to teach.
+
+- **`check` had no `empty-spec` guard for four releases, and the reference said
+  it did.** A root with zero requirements answered `✓ No issues.` and exit 0,
+  while `verify` reported it as an ERROR. Reported by an adoption on 0.8.0,
+  which reached it the way it will usually be reached: `check` is the cheap CI
+  pre-check, so it is the command most likely to be pointed at a directory a
+  moved registry or a wrong `dir` argument has emptied — and the expensive gate
+  that would have caught it runs minutes later, or on a matrix leg that does not
+  run at all. What makes it a defect rather than a proposal is that the contract
+  was already written down and the implementation was what disagreed with it:
+  `cli-reference.md` lists `empty-spec` among the codes **`check`** reports, and
+  its own History row credits `0.2.0` with adding it, so the `0.2.0` change
+  landed on one of the two commands the reference describes it on and nothing
+  compared them since. `troubleshooting.md` closes the loop by telling a reader
+  who meets this to run `attest check .` — advice to a command that could not
+  say it.
+  **The fix is a layer move, not a branch added to a second command**, and that
+  is what settles the ambiguity the entry was filed with. The rule needs nothing
+  executed to decide it — the registry alone answers it — so it belongs to
+  structural validation, which is where `validateStructure` already lives and
+  which both commands already call with the same three arguments. Both design
+  documents said this twice and did not agree: the sentence stating the rule sat
+  in **§5.4**, under "what a run runs, and what `passed` may not mean", while
+  the account of what `init` writes cited **§5.3** for the same code in a
+  context where nothing has run at all. §5.3 is now the one place it is stated,
+  which makes that citation correct for the first time.
+  **Re-measured before a line was written, and the re-measure found a case the
+  entry had not counted** — the section's own discipline, and the third time it
+  has paid on the *reachability* question rather than on a number. The reported
+  half reproduced exactly. What the walk added is that `verify` fires
+  `empty-spec` **beside** `registry-invalid` when the registry was found and
+  failed to load, and its message tells the reader to point Attest at the
+  directory holding the `*.reqs.ts` files — a file that is sitting right there,
+  where the fix is the load error already in the report and following the hint
+  would move a path that was correct. So the obvious implementation, "make
+  `check` agree with `verify`", would have imported a latent misdiagnosis into
+  the command adopters run first. `empty-spec` is now withdrawn when a registry
+  file failed to load, on both commands: the same withdrawal `validateStructure`
+  already makes for `orphan-test`, against the same input, for the same reason.
+  A registry that could not be read is not an absent one, and the two take
+  opposite repairs.
+  **Stated beside the findings it explains, not instead of them.** The louder
+  symptom in the report was measured at 135 `orphan-test` ERRORs, one distinct
+  code, and the actual diagnosis — there is no registry under this root — not
+  among them. Each orphan is true of the root as given, so the alternative is
+  rejected explicitly rather than by omission: what was missing is the single
+  line saying why they are all true at once. `verify` already had it this way,
+  which answered the question by measurement rather than by argument.
+  Held as `ATX-18`, widened from `verify` to the layer, and `ATX-77` for the
+  withdrawal — kept apart because the two are falsifiable in opposite
+  directions, and both were observed doing exactly that before the branch was
+  written: reporting nothing satisfies `ATX-77` and fails `ATX-18`'s four
+  scenarios, reporting unconditionally satisfies `ATX-18` and fails `ATX-77`'s
+  two.
+  *A root that reported success now reports an error, which this file's
+  Versioning section makes a **minor** bump.*
+
+- **`--apply` skipped the delta import it is supposed to repoint whenever the
+  specifier carried no file extension, and reported success.** `[0.6.0]` records
+  this exact failure being found and fixed — a merged spec left importing a path
+  step 3 has just moved to `archive/`, `check` silent, only the merged suite
+  showing it — and the fix covered the two spellings *this* repository writes.
+  `resolvesTo` (`core/splice.ts`) accepted the delta's own path or the NodeNext
+  `.js`-for-`.ts` spelling of it, and nothing else. A project on bundler
+  resolution writes neither: every import in it is extensionless, including the
+  one this is looking for. Reported by an adoption that is extensionless
+  throughout — application modules and all 35 spec files — so it hit this on
+  **every** applied change, nine in a row, and after the first one pre-empted it
+  by hand. That is the shape worth recording rather than the bug: the workaround
+  is cheap enough to become habit, so the defect stops producing reports while
+  continuing to happen.
+  **Re-measured before a line was written, and the entry's own account of the
+  repair was wrong.** The reading half reproduced exactly as filed, against the
+  current source rather than the `dist/` the report used. The writing half was
+  filed as needing nothing — "extensionless in, extensionless out falls out of
+  the empty case" — and the empty case sat behind `if (ext)`, so it left the
+  target's `.ts` in place. That guard was correct only while the empty case was
+  unreachable, which is precisely what widening the match changes. Fixing the
+  reported half alone would have written an extension into a project that writes
+  none: the reading half repaired, the writing half newly broken, and the
+  uniformity the whole fix exists to respect broken by the fix for it. This is
+  the second time an entry that named its own fix had the fix turn out to be the
+  wrong half, after the C1 stripping in `[0.8.0]`, and it is the case least
+  likely to be re-examined for exactly that reason.
+  Held as `ATX-75` with a scenario per spelling rather than by widening
+  `ATX-52`, which attests that the merged project verifies clean: a merged
+  project whose spec never imported the delta verifies clean either way. The
+  assertions are on the specifier the command wrote, not on the health of what
+  surrounds it, which is what makes the two separately falsifiable in the
+  direction that matters.
+
+- **`ATX-72`'s second scenario could not run on Windows at all, and the
+  requirement's own rationale said it could.** The injection needs the registry
+  file's name to carry the *specifier's own* quote — that is what makes the two
+  quote styles two scenarios rather than a loop — and the rationale argued the
+  name was "legal on Windows too since neither is among the characters it
+  reserves". True of the apostrophe, and false of the double quote, which is in
+  the set that same sentence enumerates. So `writeFile` threw before the emitter
+  was reached and `verify self` was red on win32, from `[0.8.0]`.
+  **What hid it is worth more than the fix.** CI is Linux, where both names are
+  legal, so no pipeline could have reported it — `CLAUDE.md`'s two-platform rule
+  arriving on a requirement that had already written the platform argument down
+  and got it half right. The argument was written while this requirement covered
+  one quote; widening it to two left the reasoning for the first standing over
+  both, unre-examined. A rationale is not re-read when the thing it justifies
+  grows.
+  The obligation is unchanged and holds on both platforms, because it is about
+  what the emitter writes. What is platform-limited is the end-to-end route to
+  it, so the win32 run now reaches the same assertion through `repointImport`
+  directly rather than skipping — a skipped scenario is `declared-not-run`
+  (`ATX-71`), which would trade a red suite for a red gate. The honest reading,
+  recorded in the requirement: a repository holding that name cannot be checked
+  out on Windows at all, so the exposure the end-to-end case stands for is
+  POSIX-only.
+
+### Changed
+
+- **`status`'s closing line names `check` as well as `archive`.** It said what
+  this report is short of on one side — the verdict — and nothing about the
+  other: a proposed spec no delta claims, or one whose merged name is already
+  taken, is a static fact about this change that `check` already reports. Naming
+  it is deliberately the whole of the fix. Reporting those here too would put a
+  second answer to one question in the tree, which is the arrangement this
+  project takes apart everywhere else, and the reader who wanted one command was
+  going to run `archive` anyway.
+
+- **`divergent-param` re-keyed a fourth time, and this one carries something the
+  first three did not.** `ATX-77` writes `ATX-18` out of the `code` group by
+  carrying the same `empty-spec`, on the rule's usual arithmetic — one id per
+  distinct value, later writer wins. The churn itself is now unremarkable and
+  that is the point of counting it. What is new is *which* pair it hid: `ATX-18`
+  and `ATX-77` were split deliberately, because each is falsifiable in a
+  direction the other is blind to, which makes them the most tightly related
+  pair in this registry — and the group can show only one of them. That is the
+  second time the one real relationship in this group has been the invisible
+  one, after `ATX-66`/`ATX-73`, and twice makes the mechanism legible rather
+  than the coincidence: two ids are related when they name the **same**
+  constant, which is exactly the case the deduplication discards. The rule is
+  not blind to relatedness by omission — its key is built by throwing the
+  evidence of it away.
+
+- **`divergent-param`'s finding for `flag` had to be re-keyed a second time**, on
+  a requirement carrying the same `--apply` as the member it displaced. The
+  divergence itself did not change — the same three unrelated constants under
+  the same param name — but the grouping keeps one id per distinct *value* and
+  the later writer wins, so the row's identity moved and a human had to re-judge
+  a finding about which nothing was new. Once was a curiosity worth a line; twice
+  makes it the candidate rule's behaviour, and names a maintenance cost paid per
+  addition on top of the zero precision already recorded. Note which additions
+  trigger it: the ones that **agree** with an existing member.
+
+- **`findFiles` opened one directory per directory in the tree; it now opens
+  32.** The recursion was `Promise.all(subdirs.map(walk))`, so every sibling at a
+  level was in flight at once and each of their children after them. The walk is
+  now a bounded pool a level at a time, which makes the peak a constant — the
+  same figure and the same shape as `parseSpecs`, whose bound `[0.7.0]` added.
+  *The entry this closes was half stale, and that is the part worth recording.*
+  `[0.7.0]` fixed the `parseSpecs` half and wrote down, in this file, that the
+  `findFiles` half was deliberately left; the `Under consideration` entry was
+  never narrowed to match, so it went on describing `parseSpecs` as reading every
+  source into memory for four releases after that stopped being true. An entry
+  whose other half ships is not re-read either — the same shape as a rationale
+  not re-read when the thing it justifies grows (`ATX-72`, above), arriving on
+  the section whose own discipline is to re-measure before building. Re-measuring
+  is what found it: the memory arithmetic the entry rested on was the half
+  already fixed.
+  *What retires the blocker is that it named the wrong failure.* `[0.7.0]` held
+  this back on "no report, and no demonstrated failure anywhere", where the
+  failure it meant was descriptor exhaustion — unreachable on either development
+  platform, and on Windows not even governed by `ulimit -n`, since Node uses
+  Win32 handles there. That is still true and still unmeasured. But it is not the
+  only cost: the peak itself is portable arithmetic, which is the standard the
+  `parseSpecs` half was accepted on. Measured in `tests/locate-fanout.spec.ts`,
+  which now counts in-flight `readdir` as well as in-flight `readFile`, on a
+  64-wide tree two levels deep: **64 before, 32 after** — and 200 before on a
+  200-wide one, which is the point. Unbounded, the figure is the width of the
+  level; the tree is the attacker's to choose, and `check` is the command this
+  project tells people to run first on an untrusted fork MR.
+  *The 200-wide tree is not what ships, and why is worth a line.* Building it
+  timed this file's `beforeAll` out on win32 under the parallel suite,
+  intermittently — two runs in three — and the failure arrived in the shape
+  `CLAUDE.md` records for `tests/consumer.spec.ts`: a throw in a hook reports
+  every test in the file as **skipped**, so the count moves from 385 passed to
+  383 passed and 2 skipped, and nothing says the property went unchecked. The
+  tree is now 64 wide, built concurrently, with an explicit hook timeout. A test
+  that is sometimes not run is worth less than a smaller one that always is.
+  *Both fan-outs now go through one `forEachBounded`*, extracted at the second
+  call site rather than the first: `parseSpecs` had the pool written inline, and
+  a shape written twice is the one a later fix reaches only one copy of — which
+  is, in miniature, what this entry is about. `parseSpecs` keeps its own
+  constant rather than sharing one, because the two bound different resources
+  and a shared figure could not be tuned for either. Its peak is unchanged at 32,
+  re-measured through the helper rather than assumed.
+  *A level at a time rather than one pool over a growing queue*, because a queue
+  fed by its own workers has to keep them alive while it is momentarily empty and
+  another worker may still push — a termination condition worth not owning for a
+  barrier paid in tree *depth*, which the filesystem bounds, against a fan-out
+  paid in tree *width*, which nothing does.
+  No behaviour change and no `ATX-n`, on the precedent `[0.7.0]` set for the
+  other half: the returned list is byte-identical, sorted the same way, with
+  `SKIP_DIRS` excluded the same way — all three asserted beside the peak — so
+  there is no contract here a consumer could branch on.
+
+## [0.8.0] - 2026-08-09
+
+### Security
+
+- **The `--json` document escaped every C0 control and no C1, while every other
+  surface stripped both.** `control()` (`core/terminal.ts`) covers
+  `\x00-\x1f`, DEL and `\x80-\x9f`, the last of those held deliberately for
+  8-bit CSI; the machine path rested on `JSON.stringify`, and the claim written
+  above it — that serialising to JSON escapes the same characters — is true of
+  C0 and of nothing else. Re-measured before a line was written, as this file's
+  discipline asks: `U+009B` and `U+007F` both leave `renderJson` verbatim.
+  Reachable from every `--json` command including `check --json`, which executes
+  nothing and still quotes scenario names, file paths and reqIds out of the
+  repository being checked; under `verify` and `archive` a thrown message joins
+  them.
+  **Filed at the strength the evidence carries, and that has not changed.**
+  Exploiting it needs a terminal that treats UTF-8-decoded C1 as control —
+  believed to split VTE from xterm's default, still **not measured on either** —
+  and a reader looking at the JSON rather than parsing it. What makes it worth
+  closing is not the size of that window but the asymmetry: design §9.1 is
+  stated as a property of every artifact Attest writes, and one emitter opting
+  out through a true-but-narrower guarantee is exactly how two `catch` blocks
+  came to print a raw stack beside sanitised diagnostics once already.
+  **Re-measuring moved where the fix goes.** The entry proposed a map over
+  `issues`, on the `withDocs` model. Walking the report showed that is the wrong
+  half: `change`, `outFile`, `outFiles` and — two levels down — a status row's
+  scenario name and file all carry text from the project under test, and none of
+  them passes through the envelope. Enumerating them is the arrangement §9.1
+  already names as the cause of the defect, so the rule sits at serialisation
+  instead, which is the *document* arrangement the section describes — one point
+  of assembly, before any of it is seen, covering a field nobody has added yet.
+  `outFiles` and `docsUrl` were both added after the envelope and would each
+  have needed remembering. `reqId` needed none of this and is worth recording as
+  the case that is safe by construction: `RegistryIdSchema` holds every id to
+  `^[A-Z]+-\d+$` on both readers, which is the same argument `render` uses for
+  not sanitising ids.
+  No `SCHEMA_VERSION` bump: the shape is unchanged, and the field values a
+  consumer parses differ only where they previously carried a control character.
+  Attested as `ATX-74` rather than by widening `ATX-37`, which claimed this
+  surface was exempt — the two are separately falsifiable in the direction that
+  matters, since `ATX-37` holds at every print site today while this one failed.
+  That rationale, and the same claim in `core/terminal.ts`, are corrected in
+  place.
+
+- **`render --out` wrote through a committed symlink, because the per-segment
+  resolution `init` performs had exactly one caller.** `resolveDest` resolves
+  every segment of an `init` destination and refuses with `unsafe-target-path`;
+  the `--out` path was `resolve(cwd, opts.out)` and went straight to
+  `writeAtomic`. Measured before a line was written, as this file's discipline
+  asks, and the filed claim held: with `docs` committed as a symlink to a
+  sibling directory, `attest render <dir> --out <dir>/docs/SPEC.md` reported
+  `✓ Wrote …` and the document appeared outside the root. The victim's `--out`
+  is the one their own README or CI documents, and the content redirected is the
+  rendered document — the statements and rationales their repository wrote.
+  **The leaf was already safe, which is why the gap was exactly the directory
+  segments.** `writeAtomic` lands by `rename`, which replaces a symlink instead
+  of following it — measured: a `SPEC.md` symlinked at a file outside the root
+  left that file's bytes untouched. `wx` does not reach this either and was
+  never scoped to: it guards the temporary path, and the temporary path is
+  `dirname(dest)`, i.e. already inside whatever directory the link chose. So
+  both held perfectly while the whole write happened somewhere it should not.
+  **The scope is the part that is not inherited from `init`.** `init` owns its
+  destinations, so containment there is unconditional; `--out` is an argument,
+  and `--out ../site/SPEC.md` is a destination the caller can see they chose.
+  Refusing it would be refusing the flag. The check therefore applies exactly
+  where the argument stops being evidence of where the file goes: a path that
+  reads as staying inside the project. It is asked against the root in both
+  spellings, lexical and resolved, because they differ whenever the project
+  itself sits under a link — testing only the resolved one would skip the check
+  for every such checkout, failing open on precisely the layout that has links
+  in it.
+  **`--check` goes through the same resolution**, which the filed entry did not
+  cover. It reads the destination rather than writing it, and a freshness gate
+  comparing a fresh document against a file outside the project answers about
+  the wrong document — quietly, since both verdicts it can reach are ones it
+  reports normally.
+  So this is `resolveDest` gaining its second caller rather than a new
+  indirection; by this repository's own rule it was a hypothetical seam with one
+  adapter and is now a real one. `changes/<name>/` remains the candidate third
+  and stays unmeasured.
+  **The repair moved the write, not just the check, and the reason is the shape
+  of the defect rather than tidiness.** `render`'s `writeAtomic` was the only
+  call to it outside `core/` — `runInit` writes in the pipeline, `merge.ts`
+  writes in the pipeline, and this one write sat in the CLI, which is exactly
+  how it reached the filesystem without the resolution `runInit` had performed
+  since `[0.7.3]`. Guarding it in the shell would have left that intact: the
+  obligation to call the check would still belong to a caller who can forget it,
+  which is the situation `pipeline.spec.ts`'s compiler-guard gate already exists
+  to catch elsewhere ("delete the line and every scenario stays green"). So
+  `runRender` takes the destination and owns the write, `runRenderCheck`
+  resolves the path it reads, and the resolution is **private to the module** —
+  there is no longer an entry point that writes a document without resolving
+  where it goes. The CLI lost its `writeAtomic` import, and with it the last
+  policy decision it was making; `hasError` before the write is now what stops a
+  broken registry overwriting a good committed document, stated where the write
+  is. No existing test changed: `runRenderCheck` keeps its signature, because
+  `target` already carried the spelling a diagnostic echoes and asking a caller
+  for it twice is a clump waiting to disagree with itself.
+  Two things the move surfaced that a guard bolted onto the shell would have
+  hidden. **The compiler guard has to stay the first statement**, which
+  delegation gave `runRenderCheck` for free and a resolution placed above it
+  quietly took away — an unsupported TypeScript would have come back as a path
+  refusal. Both entry points call `compilerIssue` first now, and
+  `runRenderCheck` leaves the exemption table in `tests/pipeline.spec.ts`, which
+  is what that table is for: a list of exemptions exists to be decided about
+  rather than to drift. And **"never overwrite a good document with the output
+  of a broken registry" was a comment with nothing behind it** — the write lived
+  in the CLI, where no test could reach it. It is asserted now, where the write
+  is, and is red without the guard: a half-loaded registry renders a document
+  that silently omits requirements, so overwriting the committed one destroys
+  the only correct copy and the next `--check` passes against the damage. The ATX-73 scenarios drive
+  the binary, so they are what proves the move changed no behaviour, and three
+  mutants confirm they still bite: writing without resolving, refusing every
+  path that leaves the root, and `--check` skipping the resolution are each red.
+  Stated as `ATX-73` with three scenarios: the write path and the `--check` path
+  both driven through the real CLI against a project carrying a planted link —
+  spawned rather than called, because the defect was never in the resolution but
+  in the write not going through one, so a scenario calling `resolveOutFile`
+  directly would have passed against the broken build — and a third holding the
+  scope, that a destination spelled outside the project is still written where
+  it says. All three are red against the previous build.
+  One further behaviour change falls out of resolving rather than checking, and
+  it is a repair rather than a cost: a link *inside* the project is now
+  **followed** instead of replaced. `rename` used to overwrite `docs/SPEC.md ->
+  build/SPEC.md` with a regular file while `--check` read straight through it,
+  so the two halves of the gate disagreed about which file the document was;
+  measured, the link now survives and `build/SPEC.md` receives the bytes.
+  **This turns a passing run red for anyone whose `--out` currently resolves
+  through a link out of the project**, which is the behaviour change that
+  matters and is the point of it. No
+  `SCHEMA_VERSION` bump: `unsafe-target-path` is an existing code reported by an
+  additional command, `src/cli/json.ts` is untouched, and no field moves.
+
+- **`--apply` wrote the registry's own file name into a spec's import as text
+  rather than as a string, so a registry whose name carried a quote closed the
+  literal and everything after it became code.** `splice.ts` states that every
+  generated byte is escaped — `tsString` for statement, rationale and
+  `outOfScope`, `keySource` for param keys, a `throw` rather than a guess for
+  `__proto__` — and `repointImport` was the one site that interpolated instead.
+  What it interpolated is the value the *checked repository* names: `to` is the
+  registry file `--apply` decided the ids belong in, and `isReqsFile` tests only
+  the suffix.
+  **The deletion test says what this was worth, and it is not execution.**
+  `archive --apply` runs the suite in the same invocation, so the attacker
+  already executes there. What the injection added is **persistence**: the
+  payload lands in a `*.spec.ts` that the merge then commits, and runs on every
+  later clone and CI job, inside a diff `--apply` advertises as a rename plus one
+  specifier. **Not platform-scoped** — Windows rejects `\ / : * ? " < > |` in a
+  file name and neither `'` nor `;` is among them.
+  Re-measured before a line was written, as this file's discipline asks, and the
+  filed claim held with one correction it did not have: the payload must carry
+  **the file's own quote character**, so the double-quoted spec survives a `'`
+  and vice versa. That is why the repair is not "escape `'`". `tsString` splits
+  into a `tsStringBody(value, quote)` that is *told* which quote it writes
+  between, and the specifier edit passes the quote already in the file — the
+  file's quote style stays exactly as it was, which is the property that ruled
+  out `JSON.stringify` here in the first place. No refusal path was needed:
+  escaping has an answer for every name, since a specifier is a string and
+  `tsStringBody` can spell any string as one, so `repointImport` still cannot
+  throw and `merge.ts` keeps the one `UnwritableValue` site it had.
+  The regression is asserted as a **round-trip** rather than against escaped
+  bytes — the file still parses, carries its original four statements, and the
+  specifier reads back as the path — under both quote styles, because escaping
+  the wrong quote is as wrong as escaping neither. Both cases are red against
+  the previous emitter.
+  Stated as `ATX-72` with a scenario per quote style, driving the real
+  `--apply` over a project whose registry file is named with the payload. Its
+  first draft is worth recording because a gate caught it and not a reviewer:
+  written as a quantifier over every value the emitter writes, the `sites` table
+  in `tests/intent-rule-candidates.spec.ts` demanded a scenario per site and
+  found three the sentence claimed which no `self/` scenario reaches. The hole
+  was in the *statement*, not the coverage — the other three sites are attested
+  in `tests/splice.spec.ts` and were never part of this change — so the repair
+  was to narrow the sentence to the one value the checked repository names.
+  §7 gains the general form, since it already carried the emitter's rule ("it
+  may emit no text whose evaluation differs from the value it was handed") and
+  carried it as a rule about the *registry*: `--apply` writes a second file, and
+  a file name is not something a tool is in a position to restrict, so it is
+  something the writer is obliged to escape.
+  No `SCHEMA_VERSION` bump: `src/cli/json.ts` is untouched, no code or field
+  moves, and no valid input changes behaviour — for any registry not named to
+  attack, the bytes `--apply` writes are the bytes it wrote before.
+
+- **A registry file that swaps its prototype was read as the requirements the
+  prototype carried, under the reader that evaluates.** `{ '__proto__': { … } }`
+  written as a literal is a swap, not a key: the object has **no own keys at
+  all**, so what the loader reported never depended on the swap but on what
+  happened to be behind it. The static reader refuses such a source outright as
+  `registry-not-static` and always did — the two readers agreeing is a security
+  property, not a convenience — so this was the two of them disagreeing about
+  whether a file is a registry at all.
+  **A fixture for exactly this existed and was passing for the wrong reason.**
+  `tests/static-registry.spec.ts` put *malformed* ids on the prototype, and zod
+  v3's record enumerates with `for…in`, which walks the chain — so those
+  inherited keys were tested against the id grammar and failed it. The red was
+  incidental to the swap, and the whole guarantee rested on it.
+  Put a **well-formed** id on the prototype instead and the same shape is
+  **accepted**, with the entire registry built out of a prototype the source
+  does not declare. That is measured on the zod this release ships with, not
+  inferred: the new differential case is red without the guard and the old
+  fixture stays green beside it, which is the defect and its camouflage in one
+  run. Found while evaluating the move to zod v4 — which enumerates own keys
+  only, so the swapped object is simply empty and even the malformed fixture
+  goes green — but the acceptance is reachable today and is fixed here, ahead of
+  that port and independently of it.
+  Refused now by the `isPlainObject` guard `params` has carried since a param
+  became any JSON value, applied one level up to the registry itself — **stated
+  over the shape rather than over the name `__proto__`**, because a blocklist of
+  names is a second answer to "is this data" and the guard is already the first.
+  A class instance and a `Date` fail it for the same reason. `registry-invalid`
+  rather than a code of its own: the obligation is identical to every other way
+  the schema refuses a registry, and so is the reader's situation.
+  Stated as `ATX-70` with three scenarios, and the fixture the suite was missing
+  — the well-formed-id swap — is now the one the differential suite runs.
+
+### Changed
+
+- **The guidance now says which quantifier to write, where before it only said
+  what a scenario must read.** `[0.7.0]` added the `QUANTIFIED` table after
+  `ATX-37` — "**everything** the CLI writes to a terminal MUST replace every
+  control character" — was found to have scenarios for the two formatters that
+  existed the day it was written, while `render` built a document by
+  concatenation that never went past the sanitiser. What the table taught was
+  never written down anywhere an author would meet it, and it is the more useful
+  half of that work: **which surface a quantifier ranges over decides whether
+  scenarios can keep up with it**, and there are three, not the two the original
+  proposal assumed. Over *values* one site processes, representative inputs
+  settle it. Over a *roster* the code enumerates, a scenario looping that roster
+  covers a new member by construction. Over *sites* in the implementation, each
+  needing a hand-written scenario, a new site is a new obligation and nothing
+  enumerates them — the only one of the three that can silently stop being true,
+  and what `ATX-37` was. So the rule is *prefer a quantifier a scenario can
+  iterate*.
+  *Where it landed.* Design §11 as a residual weakness, beside the two `params`
+  bullets it completes — those say what an assertion must do with a value it
+  read; this says what the statement above them should quantify over in the first
+  place. The `init` skill gets the adopter-facing form in the same model section
+  as those two rules, so a project adopting Attest is told before it writes the
+  statement rather than after the gap is found by reading. Both languages, one
+  commit, per the reason `[0.5.0]` records for doing this shape of change in one
+  pass.
+  *No engine change, and the entry stays open for the one that is still not
+  proposed.* Which surface a sentence names is prose judgement — the ground truth
+  §0 refuses to compute for someone else's requirements — and the detector that
+  exists flags the quantifier only, missing the article form ("A registry that
+  cannot be read MUST …"). What ships here is counter-pressure, which is what §11
+  now says: a hand-judged table for this registry, plus a rule an author can
+  follow. The carve-out is carried with it, because it is the failure mode of any
+  such table: rewriting a statement to name its surfaces takes it back out of the
+  flagged set, so the table admits rows for ids nothing flags.
+
+- **Zod moves from v3 to v4 (`zod@^3.23.0` → `^4.4.3`).** The reason is supply,
+  not speed: v3 is in maintenance, so fixes land on v4. The port of the schema as
+  it stood was the **one API change** the plan predicted — `errorMap` → `error` —
+  with `z.custom().pipe()`, `z.record`, `z.lazy` and the recursive `paramValue`
+  all carrying over unedited, and `red-record.ts`'s `z.ZodType` untouched. A
+  `as z.ZodType<ParamValue>` on `paramValue` became unnecessary and is gone. The
+  count is one *for the schema the plan measured*: the prototype guard added in
+  the commit before this one brought a second options bag with it, so the port
+  actually touched two — which is the ordinary way a plan's cost estimate goes
+  stale, by the code moving under it rather than by the estimate being wrong.
+  **The plan's "no `package.json` change" framing was about the evaluation, and
+  taking it as the destination would have shipped a broken package.** It rested
+  on `zod@3.25.76` exporting a `./v4` subpath — true of the *installed* version
+  and not of the *declared range*: `zod@3.23.8` is inside `^3.23.0` and exports
+  no `./v4` at all, so importing `zod/v4` while keeping that range yields a
+  package that fails to resolve on a legitimate install of its own dependency.
+  It is a real bump or it is nothing.
+  *Re-measured here, and the entry's central type claim does not survive.* The
+  plan recorded instantiations as **unchanged** (27,681 → 27,671). On this
+  codebase they go **36,211 → 89,831**, about 2.5×, with build check time
+  0.58 s → 0.71 s. Controlled for the prototype guard, which accounts for 292 of
+  that — the growth is the port. The consumer-side `.d.ts` footprint is worse
+  than predicted too: **14 files / 68 KiB → 80 files / 217 KiB** (the plan said
+  66 / 181 KiB), and a consumer's own instantiations 71,935 → 131,044. Runtime
+  goes the other way and by less than advertised: parsing this registry is
+  **0.873 ms → 0.143 ms**, 6.1× rather than 13×, and worth ~0.7 ms against the
+  hundreds `attest check self` takes. None of it blocks a migration whose reason
+  is supply, and all of it is recorded because "v4 is also faster to typecheck"
+  is the sentence that would otherwise reach the commit message — and on this
+  schema it is false in a way the plan did not have: the plan called the type
+  side neutral, and it is a cost.
+  *One diagnosis regression, found and repaired.* A v4 record reports a bad key
+  as "Invalid key in record" and does not surface the key schema's own message,
+  so a mistyped requirement id — the commonest way to fail this schema — stopped
+  being told the grammar it had missed. The record now carries an explicit
+  `error`, which restores it.
+
+- **`RegistryValidationError.issues` has a shape of this project's own, and no
+  longer exposes `z.ZodIssue`.** Zod was otherwise fully absorbed — `Requirement`
+  and `Registry` are `z.infer` aliases, so a consumer resolves them to plain
+  object types and never names the library. This field was the single exception,
+  and it was the load-bearing one: it is reached through the `./define` subpath
+  that `defineRequirements` is imported from, and `ZodIssue` is a discriminated
+  union zod reshaped between v3 and v4. So a dependency bump this project should
+  have been free to make was a **breaking change for anyone who had destructured
+  the field**. The element type is now `RegistryValidationIssue` — `path:
+  PropertyKey[]` and `message: string`, exported from the same subpath — which is
+  the same boundary `Issue.message` already holds, with the difference that
+  `Issue` was designed with the boundary and this was not.
+  **Breaking, for the narrow surface that read past those two fields**, which is
+  why it is a minor under 0.x. Nothing in this repository was in that surface:
+  re-measured before a line was written, the only two readers are `formatIssues`
+  in `registry.ts` and `firstMessage` in `apply.ts`, and **nothing anywhere reads
+  `code`, `expected`, `received` or `fatal`** — which is what made this a rename
+  rather than a redesign. A consumer that only formats what it is given, as both
+  of those do, sees no change at all.
+  *`path` is `PropertyKey[]` rather than `(string | number)[]` deliberately.* It
+  is the wider of the two spellings zod has used, so a validator failure assigns
+  to it under either — which is the whole point, since the release that moves
+  that type is the one this change exists for.
+  *One thing the plan glossed, found by doing it.* The two formatters were said
+  to read the same two fields, and they did — but not the same way: `apply.ts`
+  spelled the path `.map(String).join('.')` and `registry.ts` spelled it
+  `.join('.')`. Under `(string | number)[]` those are identical; under
+  `PropertyKey[]` the second **throws** on a symbol key, because `join` cannot
+  convert one. The shared formatter uses the safe spelling. `ATX-44` is what made
+  the rest checkable rather than hopeful: the `a.b.c` path spelling is a stated
+  requirement with a scenario on it, so the property that had to survive already
+  had something asserting it.
+
+- **`changes/<name>/first-run.json` moves to `version: 2`, and a version-1 file
+  is discarded whole.** The record now nests the scenario name under the spec
+  file, so the old shape cannot be read as the new one. Discarding is the safe
+  direction — an empty record makes every obligation "never observed", which the
+  gate blocks on — and the cost is one stage-1 run to re-observe, for a change
+  in flight across this upgrade only. The version is *checked* rather than
+  inferred from the old shape failing the schema: it would fail it anyway, but
+  "discarded because the format moved" and "discarded because the file is
+  corrupt" are different facts, and reading one as the other is how a format
+  change happens without anyone deciding to make it. Unrelated to the report
+  `schemaVersion`, which does not move — `src/cli/json.ts` is untouched, and no
+  envelope, field or `code` changed.
+
+### Fixed
+
+- **A scenario that never ran was reported as attested, when another spec file
+  declared a scenario of the same name under the same `requirement()`.** Runtime
+  coverage was keyed `(reqId, scenario name)` with no file, so two spec files
+  declaring `scenario('x')` under `requirement('APP-1')` were one entry, and
+  whichever of them executed vouched for both. `declared-not-run` — the check
+  whose whole job is to catch a declared scenario that did not execute — was
+  answering about the wrong scenario, and answering "fine".
+  Reproduced on 2026-08-09 with no flag, no `--eval` and default configuration:
+  a `real.spec.ts` whose `scenario('x')` runs beside a `ghost.spec.ts` whose
+  `scenario('x')` sits in a branch that never registers gives
+  `✓ No issues. — 1 requirement / 2 scenarios`. Renaming the ghost to `'y'`
+  produces the `declared-not-run` naming it, so the collision was the whole of
+  the difference — the check was present and was looking at the wrong key.
+  **This is the failure this tool exists to refuse**, which is what put it ahead
+  of everything else in flight: a report that says a scenario attested a
+  requirement when the scenario did not execute.
+  **The same key reached the first-run record, and there it is worse.** The
+  record is monotonic toward `fail`, so two scenarios of one added requirement
+  sharing a name meant one going red satisfied the other's `never-red`
+  obligation — mechanism 2 certifying a discrimination that never happened.
+  That half was inferred from the shared key when this was filed and is measured
+  here: both halves go red independently under control, which is why `ATX-71` is
+  two obligations rather than one.
+  Fixed by carrying the file into the key rather than by adding a check. `walk`
+  already descends from the file task, which is the only level holding a path,
+  and `ParsedScenario` has carried `file` since it existed — so both sides of
+  design §5.4's one cross-process channel had the field and only the maps
+  forgot it. It goes through `relativePath` for the reason `unloadedFiles` does:
+  the key is compared against a plan built on POSIX paths, and a native
+  separator on Windows would turn this false green into a false red.
+  Nested (`reqId -> file -> name`) rather than a composite key string, at both
+  ends: no separator has to be chosen that a path or a scenario name could
+  contain, and `first-run.json` stays a file a reviewer reads.
+  **What the fix cost, and the alternative that was rejected.** Keyed by the
+  name on disk, the record broke `--apply`'s resume: step 2 renames
+  `x.proposed.spec.ts` to `x.spec.ts`, so a resume after that rename looked up a
+  key written under the proposed name, found nothing, and blocked a change whose
+  scenarios *had* been observed red — the gate refusing its own evidence, caught
+  by `ATX-53`'s two resume scenarios. Rewriting the record beside the rename was
+  the obvious repair and is worse: two files that must move together, in a
+  design whose entire resume story is that each step is separately idempotent.
+  So the record keys by the **merged** spelling from the start, which the rename
+  cannot move. It still separates two spec files, which is the collapse the key
+  exists to prevent; what it deliberately does not separate is a file from its
+  own proposed name, because those are the same file.
+  Not claimed: that a scenario name is unique within one file. It need not be,
+  and this key does not make two same-named scenarios in one file
+  distinguishable. What it closes is the cross-*file* case, which is the one
+  reachable by ordinary means — two authors adding a scenario to the same
+  requirement from two files is how a requirement grows, while a duplicate name
+  inside one file is visible in the file being read.
+  Measured on Linux; **Windows is unmeasured**, and the path-shaped half of the
+  fix is exactly what differs there.
+
+- **An error class was being used as a formatter, at two sites that never threw
+  it.** `locate.ts` and `static-registry.ts` each constructed a
+  `RegistryValidationError` purely to borrow its `.message`, because both report
+  the same `registry-invalid` as the throwing path and the message has to be
+  identical rather than merely similar. The formatter is what those sites wanted
+  and it is now the thing they can ask for — `registryValidationMessage` in the
+  new `core/registry-issues.ts`, which all three sites share. That sharing is
+  what makes the messages structurally identical instead of a coincidence
+  maintained by hand.
+  The module is separate from `registry.ts` rather than added to it because
+  `./define` maps to the whole of `registry.ts`, so everything that file exports
+  is a public contract. The issue *type* has to be public; the formatter does
+  not, and both of its callers are internal.
+
+### Added
+
+- **`tests/registry-error-types.spec-d.ts` pins the shape that was just
+  narrowed.** The property is entirely type-level — it has no runtime footprint,
+  and the engine reads registries from the AST — so a `.spec-d.ts` is the only
+  thing that can catch a regression in it, and a green suite would otherwise
+  carry one through to users untouched. It pins both halves: that the element
+  type is exactly the two fields (`toEqualTypeOf`, so a future edit widening it
+  back to a union fails), and that a real parse failure still assigns to it with
+  no cast. Confirmed to go red on the exact regression it exists to catch by
+  reverting the field to `z.ZodIssue[]` and re-running it.
+
 ## [0.7.4] - 2026-08-08
 
 ### Added
@@ -3875,15 +4742,139 @@ checked.** The discipline aims at keeping the *argument*, not at re-testing the
 evidence under it, so the first act of building one is re-measuring what it
 claims rather than implementing what it proposes. That has paid three times:
 once killing an entry outright, when the spans it rested on turned out not to be
-spans; twice correcting an entry's own numbers before a line of it was written —
-a call-site count that a regex had inflated, and a cost filed as "a fixture per
-diagnostic" that the corpus put at one fixture. **What a release costs its adopters is not known on the day it is cut**
+spans; four times correcting an entry's own numbers or scope before a line of it
+was written — a call-site count that a regex had inflated, a cost filed as "a
+fixture per diagnostic" that the corpus put at one fixture, an injection whose
+payload turned out to need the target file's *own* quote character, which is the
+difference between escaping one quote and escaping the right one, and a fix
+filed as a map over `issues` that the report's own shape moved to the
+serialiser, four fields and one nesting level further out. **What a release costs its adopters is not known on the day it is cut**
 — several entries arrived from one adoption report, about shapes the tool made
 someone work around without ever erroring. And **the fixes with no observable
 symptom are worth batching**: individually none justifies a commit, together they
 cost about an hour, and they are the group no gate could have found, since having
 no symptom is the definition of what a gate cannot see.
 
+*The five entries this section carried before the ones below* were built and are
+recorded under `[0.8.0]`. The second is where this preamble's own
+discipline paid again: it went in on an entry whose headline type
+measurement — instantiations unchanged — was false on re-measure, and the
+re-measure is the only reason the release notes do not repeat it. The fourth is
+the other outcome the discipline has, and worth a line because the first three
+were all corrections: the `render --out` symlink measurement reproduced exactly
+as filed, down to the leaf being safe for the reason given. What re-measuring
+added was not a correction but a **surface the entry had not counted** —
+`--check` reads the same destination, so the same link makes a freshness gate
+date a document outside the project. Re-measuring an entry is therefore not only
+a test of the number it quotes; walking the code the claim is about is what
+shows the claim's own edges. The fifth is that lesson arriving where an entry
+had already named its own fix: the C1 measurement reproduced exactly, and the
+repair it proposed — a map over `issues` — was still the wrong half, because
+four more fields and a nested scenario name carry the same untrusted text and
+never pass the envelope. An entry that ends with a fix is the one least likely
+to have its fix re-examined, which is the case worth naming.
+
+*That has now happened twice, so it is a pattern rather than an incident.* The
+extensionless-import entry likewise reproduced exactly on its reported half and
+was wrong about its own repair — it recorded that the writing half needed
+nothing, and the writing half was guarded by a condition that was correct only
+while the reading half stayed broken. Both times the error had the same shape: an
+entry reasons about the code path it can see failing, and the repair makes a
+second path reachable that nobody has looked at because nothing could reach it.
+So the re-measure that matters is not "does the reported symptom reproduce" —
+both did, exactly — but **what does the proposed fix make reachable for the first
+time**.
+
+*The first time that question was asked in advance, it paid, and how it paid is
+worth a line because it is not what the two cases above would predict.* The
+`check` `empty-spec` entry — `[Unreleased]`, the third entry to reproduce exactly
+on its reported half — was not wrong about its own repair. Asking the question
+anyway found the defect one step to the side: the fix it proposed was correct,
+and the *obvious implementation of it* — make `check` agree with `verify` —
+would have copied a misdiagnosis `verify` had been emitting unnoticed, because
+the reference implementation an entry points at is not itself re-read. So the
+question generalises past the shape it was learned from. It is not only about a
+path the repair makes reachable; it is about **everything the repair would make
+`check` agree with**, and an entry that names the right fix can still be
+implemented wrongly by copying the half nobody has audited.
+
+- **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
@@ -3896,51 +4887,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.
 
-- **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.
-  *What blocks the decision, and it is evidence rather than principle.* Whether
-  npm's trusted publishers accept a **gitlab.com-hosted** project on the plan
-  this package publishes under has not been verified against this project — it
-  was not checked when the provenance job was written, and an entry claiming it
-  works would be exactly the unverified confidence the rest of this file avoids.
-  It also cannot be tested except by publishing: as with provenance, there is no
-  dry run, so a failed experiment is a release. The cheap next step is reading
-  npm's current trusted-publisher documentation for GitLab support before
-  writing any YAML.
-
-- **Bounding the fan-out in `findFiles` and `parseSpecs`.** Both walk the
-  project with no concurrency limit: `findFiles` recurses through
-  `Promise.all(subdirs.map(walk))`, so every directory in the tree is opened at
-  once, and `parseSpecs` does `Promise.all(files.map(readFile))`, which reads
-  every spec file into memory before parsing any of them. Neither is bounded by
-  anything, and `check` is the command this repository tells people to run first
-  in a pipeline on an untrusted fork MR — so the input size is not ours to
-  assume.
-  *The evidence, and why it is not enough to act on.* Measured on a synthetic
-  tree of 6000 spec files: the fan-out is real and unbounded — peak in-flight
-  `readFile` calls came back as exactly 6000 — and `attest check` finished in
-  1.99 s without erroring. It could not be made to fail. Windows is why: Node
-  uses Win32 handles there rather than POSIX descriptors, so the `ulimit -n` of
-  3200 that the shell reports does not govern the process, and the one platform
-  where descriptor exhaustion is plausible is the one CI runs and this
-  measurement could not reach (`CLAUDE.md`'s two-platform rule, pointing the
-  unusual way round). What *is* portable is the memory: `parseSpecs` holds every
-  source at once, which at a realistic 8 KiB per spec file is ~47 MiB at this
-  count — noticeable, not fatal.
-  So the fix is known and cheap — a concurrency limit of ~32 at both sites, and
-  parsing each source as it arrives rather than after all of them, which makes
-  the peak constant — and it is held back by this file's own standard: no report,
-  and no demonstrated failure on any platform. Recorded here so that the day
-  someone hits an `EMFILE` from `attest check`, the diagnosis is already written
-  down rather than rediscovered.
-
 - **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
@@ -4116,115 +5062,6 @@ have to gather again.
   out below* — the entry is kept whole here because the two were measured in one
   pass and separating them is the finding.
 
-- **Whether `check` and `verify` should refuse a half-loaded registry the way
-  `cover` and `render` do.** Those two return early on `hasError(loadIssues)`,
-  and the argument is recorded at both call sites: a report computed from a
-  half-loaded registry is a lie, and a lie that reads as a pass is the worst
-  shape it can take — `cover` in particular used to answer `ok: true` on a repo
-  whose intent layer had stopped being readable, because an empty registry is
-  fully covered. `check` and `verify` carry on regardless.
-  *What that produces, measured* on a project with one unreadable `*.reqs.ts`:
-  a `registry-invalid`, then an `orphan-test` for **every** scenario belonging to
-  that file's requirements, plus `empty-spec`, `tests-red` and a
-  `declared-not-run` per scenario — six derived findings from one cause. Worse,
-  `orphan-test`'s fix hint ("Add it to the registry, or fix the id") is *wrong*
-  for an id already sitting in the registry that failed to load, so the loudest
-  advice in the report points at work that must not be done. In a multi-file
-  registry it scales with the broken file's scenario count, and the one true
-  finding is at the top where a wall of red pushes it out of view.
-  *Why it is not simply the same call as `cover` and `render`.* Each of those
-  produces exactly **one** artifact, and refusing to produce it is the whole of
-  the decision. `check` is the command a pipeline runs first and its contract is
-  breadth — returning three findings instead of nine because one of the nine was
-  a load failure makes it quieter about problems it can still see perfectly well,
-  which is the opposite of what it is for. `verify` has the same shape with a run
-  attached.
-  *What blocks the decision.* The narrower move — keep reporting everything
-  except the findings **derived from** the missing registry, i.e. suppress
-  `orphan-test` for ids whose prefix belongs to a file that failed to load —
-  needs a prefix→file mapping for a file that never parsed, and that is exactly
-  the file `loadRegistry` has no ids from. Recovering the mapping means reading
-  the prefix out of something other than the registry's own keys (the file name,
-  or a partial AST read that survives the failure), and whether either is
-  trustworthy enough to gate a suppression on is unmeasured. Suppressing on the
-  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.**
-  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
-  read that returns ids and builds nothing, so the failure modes that matter —
-  a truncated file, a missing default export, a non-literal value, a
-  schema-invalid entry, a module that throws at import — all give them up. The
-  six derived findings from one cause are now two ERRORs and one WARNING, and
-  the collapse is per id rather than per prefix, which is strictly more precise
-  than what was blocked: a genuine typo sharing a prefix with the broken file
-  stays reported. **The lesson is the entry, not the fix.** It sat here for two
-  releases behind a blocker stated as "the mapping is unavailable", which was
-  true and was about a mapping nothing needed; the evidence it carried was about
-  the right problem and the mechanism it proposed was not, and nothing rereads a
-  blocker that has already been written down. That is the same failure the
-  section's own preamble records about a figure nobody re-checks, one level up:
-  the *shape* of the proposal goes stale as quietly as its numbers do.
-  *What is left of this entry is only the original question* — whether `check`
-  and `verify` should refuse a half-loaded registry outright, the way `cover`
-  and `render` do — **and the evidence that motivated it has been spent.** The
-  argument for refusing was never the load failure itself; it was the wall of
-  derived findings burying it, and that wall is gone. What remains is the
-  breadth argument recorded above, which points the other way for both commands.
-  It stays here rather than moving down because "the reason to do it was
-  removed" is not the same as "it was decided against", and the case would come
-  back the moment another finding is found to scale with a broken registry
-  rather than with the number of problems.
-
-- **A statement that quantifies over a surface, with scenarios covering only the
-  part that existed when it was written.** Found by reading, and it had already
-  cost something: `ATX-37` says "**everything** the CLI writes to a terminal —
-  a report, and the stack of a crash — MUST replace every control character",
-  and `self/report.spec.ts` covers `formatIssues` and `formatCrash`. Those were
-  the two functions that existed when it was written. `render` builds a document
-  by concatenation that never went past the sanitiser, and a registry could drive
-  the reviewer's terminal from `attest render` with no flag at all — shipped
-  under `[0.7.0]` as the fix, but the *shape* is not fixed and is not
-  specific to that requirement.
-  The shape: a universal quantifier in the statement, a finite set of scenarios,
-  and nothing anywhere that holds the two together. It reads as covered — the id
-  has scenarios, `cover` is green, `check` is green — and the quantifier is the
-  part no gate is looking at. Every one of the three mechanisms this project
-  sells operates *below* it: coverage asks whether an id has a scenario,
-  never-red asks whether that scenario discriminated, drift asks whether it reads
-  the params. None asks whether the scenarios span what the sentence claims.
-  *What blocks the decision.* Detecting it means knowing which surface a
-  statement names, which is prose judgement — the same judgement
-  `tests/intent-rule-candidates.spec.ts` records as the reason obligation
-  counting can never be an engine rule ("asserting a ground truth Attest cannot
-  compute for someone else's requirements, which is exactly what §0 refuses").
-  So the shippable form may not exist.
-  **The repo half has shipped, and this entry is now only about the engine
-  half.** `[0.7.0]` adds the `QUANTIFIED` table it described — hand-judged,
-  a row per flagged statement, every named scenario asserted to exist — and it
-  closed the way an entry built from a strict read is supposed to: it found a
-  live hole on `ATX-62`, the one requirement written specifically to avoid this
-  shape, where the archive gate path was claimed by the statement and asserted by
-  nothing. Two things came back that the entry did not predict. The useful one is
-  that "names a surface" splits three ways rather than two — `values`, `roster`,
-  `sites` — and only `sites` carries the risk, because a `roster` scenario
-  iterates the set the code owns and grows with it. That is a sharper statement
-  of the defect than "the scenarios do not span the sentence", and it is a rule
-  an author can act on: **prefer a quantifier a scenario can iterate.** The other
-  is that the remedy — rewriting the statement to name its surfaces, as `ATX-62`
-  did — takes it out of the flagged set, so the table has to allow rows for ids
-  the detector does not flag or it loses the binding exactly when the author does
-  the right thing.
-  *What stays open is the engine half, and nothing above touches it.* The three
-  kinds are prose judgement, the detector misses the article form ("A registry
-  that cannot be read MUST …") which is a universal too, and no rule can tell
-  which surface a sentence claims without being told. The repo half is a
-  counter-pressure, not a detector, and it holds for one registry whose authors
-  agreed to maintain it.
-
 - **Whether a requirement can ever be retired, and what it costs that none can.**
   The registry is at **69 requirements and 192 scenarios, 2.78 each**, and
   every one is a permanent obligation: `uncovered-requirement` is an ERROR, so a
@@ -4272,6 +5109,138 @@ have to gather again.
   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.
 
+- **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**
+  wall clock — three requirements are strength gates that play twelve long games
+  each — with the consequence stated as a change in *when* the tool gets used:
+  `verify` became a run-at-the-end command, and `archive` became the everyday
+  one, paying the full suite on every invocation because its verdict was the one
+  needed. The ask is a selector — `--only`/`--skip` over ids or tags, or simply
+  honouring a Vitest name filter — with the partial scope reported loudly enough
+  that a subset pass cannot be read as a pass.
+  *The cost is not Attest's, and that is the first thing the decision turns on.*
+  Every expensive scenario in that report is behavioural: the engine's own
+  overhead is not what makes 7m33s. So this is a selector over someone else's
+  suite, and Vitest already has one — the question is whether Attest reporting
+  *over* a filtered run is worth owning, not whether the run can be filtered.
+  *What blocks it — three, and they are about the report rather than the run.*
+  **(1)** Coverage is computed against the whole registry: under a filter every
+  unselected requirement has no scenario that ran, which is `uncovered-requirement`
+  and `declared-not-run` firing on requirements that are fine. Either those codes
+  gain a meaning that depends on which flags the run carried — and a `code` is
+  the one thing in a report consumers are told to branch on — or the report has to carry its scope
+  explicitly and the codes have to be computed within it. **(2)** `archive`'s
+  gate cannot accept a partial run at all: "done" having a hard definition is the
+  claim the tool is for. So the flag has to be refused there, which means two
+  shapes of `verify` and a rule for which commands may carry it. **(3)** `--json`
+  is where a partial run does its damage — a consumer branching on `ok` must not
+  read a subset pass as a pass, so this needs a field naming the scope and a
+  decision about `SCHEMA_VERSION`, and that is the cheapest part to price first
+  because it decides whether the feature is additive at all.
+  *What would move it.* A second report of the same shape, ideally one where the
+  slow half is smaller, so the question is a selector's ergonomics rather than
+  one project's gates; and a scored answer to whether a scope-carrying report can
+  be stated in a way that a `--json` consumer written before it cannot misread.
+  **Measured on 2026-08-12, before building anything, per this section's
+  discipline. The second of those two is now answered, and the answer is a
+  refusal; the first blocker was wrong; and the whole feature turns out to be a
+  different, much cheaper one.**
+  *The cost claim reproduces on a second corpus.* `verify self`: the static half
+  — scan, registry load, `parseSpecs` — is **79 ms of 30,539 ms, 0.26%**. So a
+  selector cannot save engine work anywhere; it can only save scenarios, and the
+  entry was right that this is a selector over someone else's suite.
+  *Blocker **(1)** conflates two codes with different inputs, and no arrangement
+  fires both.* `uncovered-requirement` reads registry × plan and is purely
+  static; `declared-not-run` reads plan × runtime coverage. Measured over 77
+  requirements and 214 scenarios, selecting one requirement: filtering the **run
+  scope** while leaving the plan whole gives 209–213 spurious `declared-not-run`
+  and **zero** `uncovered-requirement`; filtering the **plan** gives 76
+  `uncovered-requirement` and **zero** `declared-not-run`. The choice of where
+  the filter goes decides which one misfires, and the entry priced a case that
+  cannot occur.
+  *And on the run-scope arrangement it does not misfire at all, which is the
+  finding that collapses the rest.* A run that did not execute a declared
+  scenario really has not attested it, so `declared-not-run` is **true** under a
+  filter — only its message guesses the wrong cause ("skipped, or excluded by an
+  `.only`?"). The premise under "the codes have to be computed within [the
+  scope]" is therefore false: the report is already honest, and a subset run is
+  already loudly not a pass. 209 ERRORs on a one-requirement filter is the
+  loudness the entry asked to build.
+  *Blocker **(3)**, scored, comes back **impossible rather than expensive**.* The
+  contract `cli-reference.md` publishes to consumers is that "a consumer can
+  always parse stdout and branch on `ok`"; the next paragraph describes
+  `schemaVersion` as a producer-side promise — what the emitter bumps — and
+  checked across the whole tree rather than that page, every other mention of it
+  is producer-side too, `ATX-5` included, which obliges the report to *declare*
+  it. Nothing tells a consumer to gate on it before trusting `ok`. A consumer
+  written before a `scope` field does not read new fields — that is what makes it
+  a consumer written before them — so no
+  additive shape can protect it, and a `SCHEMA_VERSION` bump is a signal to a
+  reader who is not looking. Exactly one design is safe: a subset run never
+  reports `ok: true`. That is what already happens, for free, by the paragraph
+  above. So the correct answer to "does this need a scope field and a schema
+  decision" is **neither**.
+  *Blocker **(2)** dissolves into that.* `archive` refusing a partial run stops
+  being a rule to design and becomes a consequence: a partial run cannot be
+  `ok`, and the gate already refuses what is not.
+  *What the measurement also shows is that the feature as asked would not have
+  helped the reporter.* Their report says `archive` became the everyday command
+  **because its verdict was the one needed**. A subset run cannot carry a
+  verdict — that is the whole of blocker (3) — so a selector would have given
+  them a fast non-verdict, which they already have by running Vitest directly.
+  *The argument that survives is one the entry does not make, and it is the
+  strongest available.* The child run is `config: false` — no aliases, no DOM, no
+  plugins — so `npx vitest run one.spec.ts` executes in a **different
+  environment** from the one the verdict comes from, and a green there does not
+  predict `verify`. Owning a selector is the only way to run a subset in Attest's
+  environment. That moves the justification off speed, where Vitest is the
+  incumbent and wins, and onto parity between the fast loop and the verdict,
+  where nothing else can serve.
+  *So the thing to build, if a second report arrives, is not what this entry
+  proposed.* Not a scoped verdict but a **development-loop command**: runs a
+  subset in Attest's environment, reports what did not run as `declared-not-run`
+  because that is true, and exits non-zero always. It claims no pass, so it never
+  touches the impossibility above; it needs no field, no `SCHEMA_VERSION`
+  decision, and no code whose meaning depends on a flag.
+  *A second argument arrived on 2026-08-12, from the author's reason for building
+  `status` rather than from an adoption, and it says a hole exists at all — which
+  is the half the parity argument above does not supply.* `status` was added so
+  that when collaborating with an agent there would be a fast way to know where a
+  change stands without paying `verify` every turn. It delivers that for **stage
+  1 only**, and structurally rather than by omission: its two obligations — has
+  each ADDed id a scenario, has each been recorded failing — are both settled by
+  the end of stage 1 and never move again, so it reads all-`proven` for the whole
+  of stage 2. Stage 2 is the long half, and the workflow document tells the agent
+  to run `attest archive` there every iteration, correctly, because
+  `*.proposed.spec.ts` is deliberately outside `verify`'s scope: the gate is the
+  only Attest command that runs a change's own scenarios at all. So the everyday
+  full-gate run in that adoption report was not a habit — it is what this
+  project's own shipped instructions require.
+  **The cost curve is per-turn, not per-CI-run**, which is what makes this
+  different from the report the entry was filed on. A saving that looks small
+  against one pipeline run is multiplied by every iteration of a conversation, and
+  the agent is the consumer this framework writes a document *for*.
+  *Labelled for what it is:* not the second adoption report this entry asks for,
+  but a structural argument from this repository's own workflow, which is a
+  different kind of evidence — no user was surveyed, and nothing here measures how
+  much stage 2 actually costs anyone. What it does is narrow the thing to build
+  one more notch. The development-loop command above is a **stage-2** tool, and
+  its user is mostly an agent.
+  *The cheap interim was written into the workflow document rather than left for
+  this entry to deliver*, since it needs no engine change: run the proposed spec
+  file directly for the inner loop, keep the gate for the verdict. Measured
+  first — a `*.proposed.spec.ts` runs under a plain Vitest invocation, delta
+  import and all — and it is safe in the one way that matters, because only the
+  gate writes `first-run.json`. It is *not* a substitute, for the parity reason
+  above, and that is why the entry stays open: the interim buys speed by leaving
+  Attest's environment, which is precisely what a real selector would not do.
+  *Still unmeasured, and both need the reporter's repo rather than this one:*
+  whether their fast loop and their verdict actually diverge under `config:
+  false`, which is what decides whether the surviving argument is real for them;
+  and the second report of the same shape, which this measurement does not
+  supply and does not replace.
+
 ## Considered and rejected
 
 Decisions **not** to build something, kept where they can be found before the
@@ -4282,6 +5251,327 @@ 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.
 
+### Widening `status` to the rest of the gate's static half
+
+Scoped and decided on 2026-08-12, in the session that gave `status` its two
+refusals (an input it could not read, and a delta that will not apply). The
+question behind both was whether `status` should report *everything* about a
+change that is decidable without running anything — the gate has a static half,
+and `status` was projecting two of its checks. Four candidates were priced. Two
+shipped; these two did not, for opposite reasons, and the reasons are worth
+keeping because the shape of the proposal will recur.
+
+*`validateStructure`'s ERRORs over the merged plan — already decided, and not
+here.* The proposal was to project the gate's first check whole: `orphan-test`,
+duplicate ids, and `uncovered-requirement` for every id rather than only the
+ADDed ones. Design §8 had settled it before the proposal was written — `status`
+projects "the *uncovered* half of check 1 and the whole of check 4, both
+restricted to the ids the change ADDs", and orphans and unbound params are named
+as **not** projected, "being facts about the whole applied registry rather than
+progress on an added id". So this was not a new decision to make but an old one
+the proposal had not read, and the finding is procedural rather than technical:
+the design document answers scoping questions about `status` that a reading of
+`status.ts` alone will not. Rebuilding it means changing §8 first and arguing
+against that sentence, which nothing here does.
+
+*The proposed-spec findings — the only genuinely new shape, rejected on
+duplication.* `proposed-spec-unclaimed`, `proposed-spec-name-taken` and
+`spec-in-change-dir` are static facts about *this change*, and unlike the
+refusals that shipped they leave the report perfectly computable — every row
+stays correct. So they are neither progress nor a failure to compute, which is
+the one case the existing `issues` contract has no room for, and pricing that
+room was expected to be the expensive part. It never had to be priced: **`check`
+already reports all three**, and already reads each change's delta to attribute
+proposed specs, so `status` reporting them would put a second answer to one
+question in the tree — the arrangement this project takes apart everywhere else,
+and the reason `declaredNotRunIssues` and `hasError` are each one function. What
+was built instead is one line: `status`'s closing line now names `check`
+alongside `archive`. The cost is real and is not hidden — an agent in stage 2
+runs two commands where it wanted one — and naming it is the whole of the
+compensation.
+
+*The consequence worth recording is that the `--json` question dissolved.* The
+open design decision that had been sequenced ahead of all four candidates was
+what shape new `status` findings take in the report: whether `issues` widens
+from "the report could not be computed" to "here are findings", or a second
+field arrives, and whether either moves `SCHEMA_VERSION`. After these two
+rejections there is nothing left to decide, because everything that survives is
+either a refusal — existing `issues` semantics, `ok: false`, no new field — or
+`check`'s to report. A blocking decision that evaporates once the candidates
+either side of it are settled is a sequencing error, not a hard question, and
+that is the transferable part: the shape of a report is decided by what is left
+to put in it, so the scoping goes first.
+
+*What would reopen either.* For the first, an argument against design §8's
+sentence, not a fresh proposal that has not met it. For the second, a measured
+cost of the two-command loop — the same evidence the `Under consideration` entry
+on a stage-2 development-loop command is waiting for, and it would arrive from
+the same place.
+
+### A trailing-dot-and-space clause in `isSafeChangeName`, for a Windows normalisation that does not happen
+
+Filed under `Under consideration` on 2026-08-09 and rejected on 2026-08-11 by
+the measurement it was waiting for. The premise was that Win32 strips trailing
+dots and spaces from a path component below the API, so `'.. '` — which passes
+every clause the guard has, being neither `''`, `'.'`, `'..'`, a separator nor
+NUL — would name `changes/`'s parent, and under `--eval` or `archive` that name
+reaches a module path that is then executed. The entry recorded that no Linux
+measurement could answer it and named both outcomes in advance: a fourth clause
+if it reproduced, or a note about the clauses' character if it did not.
+
+*It does not reproduce.* Measured on Windows 11 26200, Node v22.23.2, NTFS.
+`mkdir` of `changes/.. ` creates a **literal directory named `.. `** —
+`readdir` returns `[".. "]` — and a write through the name lands inside it,
+leaving a file planted at the project root untouched. End to end through the
+CLI with a payload delta at the root, all of `status '.. '`, `status '.. '
+--eval` and `archive '.. '` fail with `change-not-found` naming
+`changes/.. /requirements.delta.ts`, and the payload never executes. Both
+readers were exercised deliberately, because they resolve differently and only
+one of them is the dangerous path: the static read and the Vite loader keep the
+trailing space alike. `'..  '`, `'.. .'`, `'...'` and `'. '` behave the same.
+
+*The neighbouring win32-specific vectors were measured in the same pass*, since
+the guard's clauses are POSIX-shaped and this was the moment to ask what else
+they cannot see. `'C:'`, `'C:x'` and `'a:b'` pass the guard, and `join` splices
+no drive: every one stays under `changes/` and fails `ENOENT` at the colon.
+`'CON'` and `'NUL'` create ordinary directories. `'..x'` and `'x..'` are
+literal. Nothing escaped, and the root file was intact after all of them.
+
+**What the entry's own fallback asks to keep, now earned rather than assumed:
+the clauses are the POSIX spelling of path safety, and on this platform that is
+the complete spelling.** The guard's doc comment says the test is path safety
+rather than a character whitelist — that claim survives the measurement, and it
+survives it on the platform most likely to have broken it.
+
+*Rejected at the strength the evidence carries.* This is one Windows build and
+one Node version, so what is refuted is the general premise, not every future
+libuv. **The reach was always one level** — the name eaten gives the project
+root, and going above it needs a second `..`, which needs a separator the guard
+already refuses — so even a reproduction would have meant executing a file
+elsewhere *inside* the project. That bound is why a negative result closes this
+rather than merely deferring it: the cost of being wrong is bounded and the
+reopen condition is cheap, being a single `mkdir` on a machine where it behaves
+differently.
+
+### Refusing a half-loaded registry in `check` and `verify`, the way `cover` and `render` do
+
+`cover` and `render` return early on `hasError(loadIssues)`,
+and the argument is recorded at both call sites: a report computed from a
+half-loaded registry is a lie, and a lie that reads as a pass is the worst
+shape it can take — `cover` in particular used to answer `ok: true` on a repo
+whose intent layer had stopped being readable, because an empty registry is
+fully covered. `check` and `verify` carry on regardless.
+*What that produces, measured* on a project with one unreadable `*.reqs.ts`:
+a `registry-invalid`, then an `orphan-test` for **every** scenario belonging to
+that file's requirements, plus `empty-spec`, `tests-red` and a
+`declared-not-run` per scenario — six derived findings from one cause. Worse,
+`orphan-test`'s fix hint ("Add it to the registry, or fix the id") is *wrong*
+for an id already sitting in the registry that failed to load, so the loudest
+advice in the report points at work that must not be done. In a multi-file
+registry it scales with the broken file's scenario count, and the one true
+finding is at the top where a wall of red pushes it out of view.
+*Why it is not simply the same call as `cover` and `render`.* Each of those
+produces exactly **one** artifact, and refusing to produce it is the whole of
+the decision. `check` is the command a pipeline runs first and its contract is
+breadth — returning three findings instead of nine because one of the nine was
+a load failure makes it quieter about problems it can still see perfectly well,
+which is the opposite of what it is for. `verify` has the same shape with a run
+attached.
+*What blocks the decision.* The narrower move — keep reporting everything
+except the findings **derived from** the missing registry, i.e. suppress
+`orphan-test` for ids whose prefix belongs to a file that failed to load —
+needs a prefix→file mapping for a file that never parsed, and that is exactly
+the file `loadRegistry` has no ids from. Recovering the mapping means reading
+the prefix out of something other than the registry's own keys (the file name,
+or a partial AST read that survives the failure), and whether either is
+trustworthy enough to gate a suppression on is unmeasured. Suppressing on the
+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.**
+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
+read that returns ids and builds nothing, so the failure modes that matter —
+a truncated file, a missing default export, a non-literal value, a
+schema-invalid entry, a module that throws at import — all give them up. The
+six derived findings from one cause are now two ERRORs and one WARNING, and
+the collapse is per id rather than per prefix, which is strictly more precise
+than what was blocked: a genuine typo sharing a prefix with the broken file
+stays reported. **The lesson is the entry, not the fix.** It sat here for two
+releases behind a blocker stated as "the mapping is unavailable", which was
+true and was about a mapping nothing needed; the evidence it carried was about
+the right problem and the mechanism it proposed was not, and nothing rereads a
+blocker that has already been written down. That is the same failure the
+section's own preamble records about a figure nobody re-checks, one level up:
+the *shape* of the proposal goes stale as quietly as its numbers do.
+*What is left of this entry is only the original question* — whether `check`
+and `verify` should refuse a half-loaded registry outright, the way `cover`
+and `render` do — **and the evidence that motivated it has been spent.** The
+argument for refusing was never the load failure itself; it was the wall of
+derived findings burying it, and that wall is gone. What remains is the
+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
+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
+because one of the nine was a load failure makes it quieter about problems it
+diagnoses perfectly well. `verify` is the same shape with a run attached.
+
+*What would reopen it*, stated because a rejection whose condition is unwritten
+gets re-proposed on a hunch: another finding found to scale with a **broken
+registry** rather than with the number of real problems. That is the shape that
+justified this once and could again; a merely noisy report is not.
+
+### An engine rule for a statement whose scenarios do not span its quantifier
+
+The shape was found by reading, and it had already
+cost something: `ATX-37` says "**everything** the CLI writes to a terminal —
+a report, and the stack of a crash — MUST replace every control character",
+and `self/report.spec.ts` covers `formatIssues` and `formatCrash`. Those were
+the two functions that existed when it was written. `render` builds a document
+by concatenation that never went past the sanitiser, and a registry could drive
+the reviewer's terminal from `attest render` with no flag at all — shipped
+under `[0.7.0]` as the fix, but the *shape* is not fixed and is not
+specific to that requirement.
+The shape: a universal quantifier in the statement, a finite set of scenarios,
+and nothing anywhere that holds the two together. It reads as covered — the id
+has scenarios, `cover` is green, `check` is green — and the quantifier is the
+part no gate is looking at. Every one of the three mechanisms this project
+sells operates *below* it: coverage asks whether an id has a scenario,
+never-red asks whether that scenario discriminated, drift asks whether it reads
+the params. None asks whether the scenarios span what the sentence claims.
+**Everything this entry established about the shape has left it, and the two
+halves left by different doors.** The repo half shipped in `[0.7.0]` as the
+`QUANTIFIED` table it described — hand-judged, a row per flagged statement,
+every named scenario asserted to exist — and it closed the way an entry built
+from a strict read is supposed to: it found a live hole on `ATX-62`, the one
+requirement written specifically to avoid this shape, where the archive gate
+path was claimed by the statement and asserted by nothing. What that table
+taught is now **design §11**, both languages, because it is a permanent
+property of the design rather than a candidate: which surface a quantifier
+ranges over — `values`, `roster`, `sites` — decides whether scenarios can keep
+up with it, only `sites` can silently stop being true, and the rule an author
+can act on is *prefer a quantifier a scenario can iterate*. The adopter-facing
+half of that rule is in the `init` skill beside the two `params` rules it
+completes. Neither was predicted here: the entry proposed a detector and
+expected a two-way split, and what came back was a three-way one and an
+authoring rule, which is the more useful object and needed no engine at all.
+The table's own trap is recorded with it — the remedy of rewriting a statement
+to name its surfaces takes it out of the flagged set, so the table must admit
+rows for ids nothing flags, or it loses the binding exactly when the author
+does the right thing.
+*What stays here is the engine half alone, and it is undecided rather than
+blocked-with-evidence.* Detecting this means knowing which surface a statement
+names, which is prose judgement — the same judgement
+`tests/intent-rule-candidates.spec.ts` records as the reason obligation
+counting can never be an engine rule ("asserting a ground truth Attest cannot
+compute for someone else's requirements, which is exactly what §0 refuses").
+The detector that exists flags the quantifier and nothing more, and it misses
+the article form ("A registry that cannot be read MUST …") which is a universal
+too. So the shippable form may not exist, and what §11 ships instead is a
+counter-pressure that holds for one registry whose authors agreed to maintain
+it. *What rejected it is a measurement that was already in the repository when this
+entry was trimmed, and went unread.* The inline snapshot in
+`tests/intent-rule-candidates.spec.ts` scores the detector against the real
+corpus: it flags **30 of 70** requirements, and of those 30, **21 are `values`
+or `roster`** — correct by construction, nothing for an author to do. A shipped
+WARNING would therefore fire on 43% of this registry and be wrong about 70% of
+what it fired on, with no way for the author to discharge it except by rewording
+the statement.
+
+*And rewording is both the evasion and the legitimate fix*, which is what makes
+the precision figure fatal rather than merely bad. `ATX-62` was improved by
+being rewritten to name its surfaces, and that rewrite takes it out of the
+flagged set by exactly the same mechanism a lazy reword would. The detector
+cannot tell them apart, so it grades the wording rather than the coverage. That
+is the failure design §11 records for every intent-layer detector tried — each
+"either saw almost nothing, or was cleared by deleting the word that triggered
+it" — and this one is squarely the second: `compound-requirement` sits
+at the other pole, never wrong and nearly blind, and the two together are the
+measured range of what a token detector over prose can do here.
+
+*What survives is not this proposal.* The three-way classification and the
+authoring rule are design §11, the adopter-facing form is in the `init` skill,
+and the hand-judged table is the counter-pressure that did survive measurement.
+Reopening this needs a signal that is not the quantifier token — the reach limit
+is the detector's input, not its threshold, so tuning it is the measurement
+bending to the corpus.
+
+### A precomputed analysis written to disk for the child run to read
+
+`@ark/attest` analyses the whole project once, writes it to
+`.attest/assertions/*.json`, and has the test process do position lookups
+against that file instead of a compiler — because its assertions need a full
+`ts.Program`, which cannot be afforded per test. The shape maps onto `verify`
+exactly: the parent parses registries and specs, then `runAndCollect` spawns a
+Vitest run that currently shares nothing with that work.
+*What rejected it is that the case for it was never made and the case against it
+is structural.* There is **no
+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
+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
+that has just appeared, and it would do so silently. Any version of this needs
+an invalidation story stronger than a mtime before it is worth the seconds it
+saves, and the repo already has one cautionary precedent in the same
+direction — `bin/attest.js` loading `dist/` rather than `src/` is a cache with
+no invalidation at all, and it is in `CLAUDE.md`'s Gotchas because of how
+quietly it misleads. Note also what arktype gets wrong in the same file and
+what not to copy with it: the assertion cache and the queue of pending
+snapshot writes share one JSON document, so two things with unrelated
+lifetimes are invalidated together.
+
+*What would reopen it* is a measurement, and the entry names which one: a
+parse cost large enough to be worth a cache, on a real project rather than a
+synthetic tree. Until that exists this is a correctness hazard bought with
+seconds nobody has shown are being spent, and the invalidation story would have
+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
+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 —
+type instantiations down from **27,681 to 6,581**, check time 0.25 s → 0.14 s.
+
+*What rejected it is that both winners are collected by the wrong party.* Mini
+exists for tree-shaken bundle size in a browser. This ships as a Node CLI loaded
+from `dist/`, where bundle size is not a constraint on anything — apply the
+deletion test to mini's benefit and nothing in this repository changes. The
+instantiation saving is real but it is paid to **this project's own
+`pnpm typecheck`**, not to any adopter, and it is 0.11 s off a build already
+measured in seconds. The runtime saving is 3.2 ms against a 390 ms command.
+
+*And the cost lands on the file least able to afford it.* Mini's API is
+functional rather than chained:
+
+```ts
+params: z.record(z.string(), paramValue).default({})     // v3 / v4
+params: z._default(z.record(z.string(), paramValue), {}) // mini
+```
+
+`src/core/schema.ts` describes itself as the single source of truth for the
+shape of the intent layer, and it is written as one — the comments on
+`isPlainObject` and on the `params` union are longer than the code they sit
+over, because the file is read as a document by anyone deciding what a
+requirement may contain. Trading its legibility, and accepting an
+underscore-prefixed `_default` in it, buys 3 ms on a command nobody is waiting
+for.
+
+This reopens only if something makes bundle size a constraint here — a browser
+or edge build of the registry reader, which nothing currently proposes — and not
+on a faster benchmark, since the benchmark was never what was in doubt.
+
 ### Region-marked samples, so a partial quote could be bound too
 
 Decided **yes** and filed under `Planned`, then killed by building the count it
@@ -4636,6 +5926,8 @@ requirement, and human review at propose is still the whole answer. What is
 rejected is grouping as a way to assist it, and this reopens only on a
 contradiction that grouping would have caught.
 
+[0.9.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.9.0
+[0.8.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.8.0
 [0.7.4]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.4
 [0.7.3]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.3
 [0.7.2]: https://gitlab.com/Pseudorca/attest/-/tags/v0.7.2