@am_shork/attest 0.8.0 → 0.9.0

package/CHANGELOG.md

@@ -13,6 +13,457 @@ 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
@@ -4304,8 +4755,8 @@ symptom are worth batching**: individually none justifies a commit, together the
 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 one below* were built and are
-recorded under `[Unreleased]`. The second is where this preamble's own
+*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
@@ -4323,6 +4774,30 @@ 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
@@ -4412,32 +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.
 
-- **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
@@ -4660,29 +5109,137 @@ 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.
 
-- **Whether `isSafeChangeName` is wide enough on Windows, where the filesystem
-  strips trailing dots and spaces from a path component.** The guard's stated
-  test is path safety rather than a character whitelist, and it refuses `''`,
-  `'.'`, `'..'`, both separators and NUL. Win32 normalises `'.. '` to `'..'`
-  below the API, so a name that passes every one of those clauses could still
-  name the parent — and under `--eval` or `archive` the name reaches a module
-  path that is then executed.
-  **What is not known is whether that reproduces at all**, and it is the reason
-  this is here rather than in `Planned`. `path.win32.join` was checked on Linux
-  on 2026-08-09 and does *not* normalise it — `join('C:\\r\\changes', '.. ')`
-  keeps the space — so the whole question is what the Win32 layer does with the
-  resulting path, which no Linux measurement can answer. The repository's own
-  rule applies: say which half is unmeasured rather than describing it as
-  covered.
-  **Even granting it, the reach is one level.** `changes/<name>/…` with the name
-  eaten gives the project root, and going above it needs a second `..`, which
-  needs a separator the guard already refuses. So the outcome is executing a
-  file at another path *inside* the project, not an escape from it — which is
-  what keeps this an open question about the guard's completeness rather than a
-  filed defect. If it reproduces, the fix is one more clause of the same kind:
-  refuse a name that is empty, `.` or `..` after trailing dots and spaces are
-  trimmed. If it does not, the finding to keep is that the guard's clauses are
-  the POSIX spelling of path safety and the file should say so.
+- **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
 
@@ -4694,6 +5251,108 @@ 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)`,
@@ -4855,8 +5514,10 @@ Vitest run that currently shares nothing with that work.
 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 entry above measured `attest check`
-over 6000 spec files at 1.99 s total. Worse, a cache is a correctness hazard
+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
@@ -5265,6 +5926,7 @@ 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