@am_shork/attest 0.4.3 → 0.6.0

package/CHANGELOG.md

@@ -13,6 +13,396 @@ 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.6.0] - 2026-08-03
+
+### Added
+
+- **The workflow `attest init` writes now describes this release, and one line
+  of it was telling agents to undo correct work.** The skill is the document an
+  agent reads without a human in the loop, and it had drifted twice.
+  **The wrong line.** Its merge step said the specs are renamed in place with
+  *"no import changes; if you find yourself editing a specifier, the spec was not
+  written at its merged location and stage 1 was the place to fix that."* Sixty
+  lines above, the same document teaches a stage-1 scenario to read its proposed
+  params from the delta — `import reqs from '../../changes/<name>/requirements.delta.ts'`
+  — with the comment *"only this line changes at merge"*. So the file contradicted
+  itself, and an agent following it either left a merged spec importing a path
+  that step 3 had moved into `archive/`, or concluded a correctly-written spec was
+  wrong and moved it, producing the very rewrite the sentence claimed to prevent.
+  Exactly the defect `--apply` hit while being built, sitting in the document that
+  is trusted furthest.
+  The merge step is now `attest archive <name> --apply`, with the by-hand path
+  kept for the operations it refuses and stated correctly: one specifier changes,
+  and it changes because the delta moves, not because the spec was misplaced.
+  Two prevention lines added where they cost nothing — a spec under `changes/`
+  is `spec-in-change-dir`, and a proposed name whose merged form is taken is
+  `proposed-spec-name-taken`, which is an authoring-time choice and so belongs in
+  the authoring guide rather than only in a diagnostic. `compiler-unsupported` is
+  deliberately **not** added to the stage-2 table: that table answers "what does
+  this mean for my change in flight", and a toolchain failure is not something an
+  agent fixes by editing the change.
+  **The gate that was missing** is now `ATX-57`. Troubleshooting is asserted
+  against `ISSUE_CODES` in both languages and the CLI reference against this file,
+  while the skill's content was held by four `toContain` calls and otherwise by
+  eye — the wrong footing for the one document whose reader is not a person and
+  who branches on the codes in it. Every code-shaped token it names is checked
+  against the roster, one-directionally: the workflow has no business naming every
+  code, so the obligation is only that what it does name exists. `ATX-40` is the
+  same shape pointing the other way over the other document. Given a requirement
+  rather than left a plain test for the reason this project exists: a gate that is
+  not itself gated is a gate someone deletes, and without one over it, removing
+  the check is a green diff.
+  `attest init` is idempotent and takes no input, so re-running it after upgrading
+  is the whole update mechanism; nothing here changes that.
+
+- **A compiler with no AST API is now a diagnosis rather than a crash
+  (`compiler-unsupported`).** Discovered by building the `typescript` matrix in
+  `[0.4.2]`, which is what a matrix is for. `typescript@7` is the native port: its
+  package resolves, imports cleanly and still answers `version`, while the AST
+  moved behind `typescript/unstable/ast*` — so `createSourceFile` and every
+  `ts.isX` guard both registry readers and the spec parser call is `undefined`,
+  and the first one touched throws. Measured: `attest check` died with
+  `TypeError: Cannot read properties of undefined (reading 'Latest')` and a raw
+  stack — no code, no fix hint, and nothing saying which compiler it wanted, on
+  the crash path `[0.4.2]` had just finished sanitising.
+  **The declared range excludes 7, and that is not the same as being safe from
+  it.** A caret is a request, not a constraint an adopter cannot override:
+  `pnpm.overrides` and Yarn `resolutions` both pin a transitive dependency across
+  a whole tree, and a repo standardising on one compiler is exactly the repo that
+  uses them — this one has an `overrides` block of its own. So the reachable case
+  is a deliberate, reasonable act answered with a stack trace.
+  Every AST-reading command now refuses before it opens a file, naming the version
+  it found and the supported range. The range lives in `ATX-56`'s `params` and its
+  scenario compares that against `package.json`: a diagnostic naming a range that
+  has drifted from the dependency it describes is worse than one naming none.
+  The refusal takes a compiler rather than reaching for the import, because the
+  condition exists only on a compiler this repository cannot install beside the
+  one it builds with — and a check nothing can make fail is the `never-red` shape
+  the gate exists to catch.
+  *What it does not do is make Attest work on TypeScript 7.* That is a migration
+  to `typescript/unstable/ast`, against an API whose own name says not to depend
+  on it yet. The honest answer for now is a supported ceiling that says so, and
+  `troubleshooting.md` carries the override-scoping escape for anyone pinning the
+  compiler tree-wide.
+  This is a behaviour change only in the sense that a crash became an exit code:
+  nothing that worked before reports it.
+
+- **`attest archive <change> --apply` finishes the merge its gate approved.**
+  The gate proved a delta green, covered and drift-free, and a human then
+  transcribed it by hand with nothing checking the transcription — the verdict did
+  not cover the step acting on it. Reported by `mine-capablanca`: eight changes,
+  eight hand-written Python scripts, one of which located the delta's block by
+  `split('added: {', 1)`, trimmed two spaces of indent per line and re-terminated
+  the registry on `assert t.endswith('});')`.
+  Three steps, and the gate runs first in the same invocation: splice each ADDED
+  requirement into the registry file owning its prefix, repoint and rename the
+  change's proposed specs, move `changes/<name>/` to `archive/<date>-<name>/`.
+  Every path touched is printed. A red gate writes nothing, and there is no flag
+  that skips it — a merge acting on an earlier run's verdict could file an
+  unfinished change as done, which is the one thing this tool must not ship.
+  **Why this is not the `AGENTS.md` merge tool, which stays rejected.** That was
+  refused because "each of its failure modes is destructive on a file the user
+  cannot regenerate". The registry is a literal Attest defines, statically
+  parseable, with two readers already asserted to agree on it — so the result of an
+  edit is checkable by re-reading it. That clause only holds if the edit is a
+  **pure insertion**, so nothing renders a registry back out of a `Registry`
+  object: doing so would be easier and would drop every comment and layout choice
+  in a hand-written file while passing a re-read with flying colours, because the
+  values all survived. `tests/splice.spec.ts` asserts the insertion is pure by
+  reconstructing the original from the result, rather than by looking for the
+  comments — the comments are a sample of the property, not the property.
+  **Re-runnable rather than atomic, which is what pinned the step order.** No
+  primitive spans one edit, N renames and a directory move, and a scratch copy of
+  the project root would have to be swapped back through the same non-atomic set
+  again. So every step is derived from the tree as it currently is, and a partial
+  application is finished by running the same command again. `ATX-53` states that
+  and deliberately **not** the order it is bought with: an order is not observable —
+  every ordering agrees on the happy path — so a requirement about it could not be
+  falsified, which is the `never-red` shape the gate exists to catch. Resumability
+  can be falsified, and it fails exactly when the order is wrong: move the folder
+  first and the recovery has no delta left to re-derive from; rename before
+  splicing and the intermediate tree has merged specs reading a registry without
+  their ids.
+  **ADDED only, and refused whole otherwise** (`apply-unsupported-delta`,
+  `apply-no-prefix-owner`). The gate still applies all four operations in memory,
+  so nothing becomes unverifiable — only the write-back stops, because REMOVED
+  cannot say which comments belonged to the entry it deletes and MODIFIED is a
+  formatting-preserving edit inside an existing literal. Both are the shape the
+  rejection named. Whole rather than partial because an implementation that merged
+  the half it understood would hand back a change the author believes is done.
+  **The collision that would have destroyed work** ships with it as
+  `proposed-spec-name-taken`, reported by `check`. `isSpecFile` and
+  `isProposedSpecFile` are disjoint, so `session.spec.ts` and
+  `session.proposed.spec.ts` coexist with nothing objecting — and the rename would
+  overwrite the first. Not a corner: a proposed spec is written beside the code it
+  attests, so a change to an already-tested module reaches for exactly that name.
+  Held in `check` rather than only refused at merge time, so the fix is a rename
+  while renaming is still free.
+  **One clause of this entry's own argument was wrong, and building it is what
+  found out.** It recorded that `[0.5.0]` had removed the import-rewriting blocker
+  outright, because a proposed spec sits at its merged location and merging it is
+  "a rename in place". True of its *location* — but `[0.5.0]` also made a delta
+  read as the registry it proposes, so a stage-1 scenario imports the delta, and
+  step 3 moves the delta away. The first working version of this command moved all
+  three things correctly and left every merged spec importing a path that no longer
+  existed; `check` was silent, and only running the merged suite showed it. So one
+  specifier is repointed after all — located by AST, replaced as text, with the
+  expression around it untouched because `reqs['AUTH-7'].params.x` reads the same
+  on both sides. Far smaller than "rewriting arbitrary TypeScript", but not the
+  zero this file claimed. `ATX-52` therefore attests that the *merged project
+  verifies clean*, not that three files moved: the broken version would have passed
+  the second.
+  **It does not re-render a committed `SPEC.md`,** and cannot: nothing in a project
+  records where its rendering lives, so the entry listing that as a fourth step was
+  describing something with no input. `render --out` afterwards, which a pipeline
+  running `render --check` already asks for.
+  `ATX-52`–`ATX-55`, with eight scenarios. `--apply` is additive — no exit code
+  moves for anyone not passing it — but `proposed-spec-name-taken` is a new ERROR
+  on `check` and **will turn some CI red**: a layout that passed before now fails,
+  and everything it fails would have been destroyed by the first merge.
+
+- **`check` now names a spec left under `changes/`, where nothing walks it
+  (`spec-in-change-dir`).** `[0.5.0]` moved a change's specs to their merged
+  location and told anyone with an open change directory to move each file,
+  rename it `*.proposed.spec.ts` and fix its imports once. It did not account for
+  the state *before* that is carried out. `changes` is in the project walk's
+  skip list, and `[0.5.0]` removed `changeExcludeGlobs` — the mechanism by which
+  `attest archive <name>` used to include `changes/<name>/specs/` explicitly.
+  Both halves are right on their own; together they mean the old location is
+  walked by no command.
+  **Measured before it was fixed**, on a copy of `fixtures/e2e-archive` with its
+  proposed spec put back at `changes/add-totp/specs/totp.spec.ts` and its two
+  specifiers re-depthed: `attest check` exited **0** with `✓ No issues.`, and the
+  only command that spoke was the gate — `uncovered-requirement`, verbatim
+  *"Requirement "AUTH-7" has no scenario attesting it. Add a scenario, or mark it
+  deferred."* The author had written two, and both were correct. So the one
+  diagnostic available told them to write what they had written, or to defer a
+  requirement they had finished. That is the misdiagnosis shape `ATX-49` records,
+  arriving from the other direction — there the verdict pointed away from a load
+  failure, here away from a path — and in both cases it spends the reader's
+  attention on files that are fine.
+  In `check` rather than the gate: the gate at least fails, while `check` is both
+  the command a pipeline runs first and the one that said nothing at all. Both
+  spellings are reported, because a `*.proposed.spec.ts` under `changes/` is a
+  migration done halfway — the right marker at the wrong path — and no more
+  reachable than one never begun. An ERROR rather than a warning for `ATX-47`'s
+  reason: a spec that runs nowhere is a total failure, not a misplaced one.
+  *It is not transitional and does not expire.* After `[0.5.0]` a spec under
+  `changes/` is wrong permanently; catching an unfinished upgrade is what it is
+  worth first, not what it is for.
+  **This is a behaviour change and turns some CI red** — a layout that passed
+  `check` in `[0.5.0]` now fails it. That is the point, and everything it fails
+  was already running nowhere. `ATX-51`, with three scenarios: the pre-move
+  spelling, the half-migrated one, and a proposed spec at its merged location
+  that must *not* be reported, because a check firing on the documented workflow
+  would be §9's "usually wrong about staleness" failure again.
+  Found while asking whether a *different* proposed check — the merged-name
+  collision under `attest archive --apply`, still in `Planned` — would help
+  anyone upgrading. It would not; this does.
+
+## [0.5.0] - 2026-08-03
+
+### Changed
+
+- **Design §11 now states what earns a `params` entry, and the README no longer
+  states a rule that produces the defect it warns about.** Two prose changes,
+  one subject, and both came out of the same adoption report.
+  *What earns a param:* **params for promises, plain constants for tuning.** A
+  value belongs in `params` when the requirement promises it — a timeout the user
+  is owed, a budget someone would file a bug about; a value that only tunes
+  behaviour stays an ordinary constant, because nothing is owed to anyone when a
+  tuning knob changes. `mine-capablanca` arrived at this unaided and applied it
+  consistently across 34 requirements (11 carrying params, 19 values), which is
+  the best available evidence that it is the natural rule — and it was written
+  down nowhere. It pushes back on the second of the two ways intent bloats, the
+  one §11's lumping bullet does not cover: a registry that accumulates every knob
+  in the project. Folded into the same paragraph, because it is the same rule
+  stated over the *type* rather than the value: what a param may therefore be — a
+  scalar, or an array of scalars. Stating those apart is what let one adopter
+  derive the first unaided and meet the second as `Invalid input`.
+  *And the rule that was half-wrong:* "Read the param inside the assertion, not
+  beside it" appeared in the README, the `init` skill and the `possible-drift`
+  section, and it is **necessary but not sufficient** — an assertion that
+  recomputes its expectation from the same param the code under test just read
+  has no independent term, so both sides move together and no edit can make it
+  fail. Measured, not theorised: a mine-density band moved by 3.3× with the whole
+  suite green, `check` silent, and the drift heuristic correctly quiet, because a
+  covering scenario did read the param. Every site now says what the evidence
+  supports — *the expectation must not be a function of the param the code under
+  test consumed* — and `possible-drift` carries a worked ✗/✓ pair. §11 records
+  the sharper statement of the hole: a tautological assertion is a scenario that
+  cannot fail, which the red-before-implement gate exists to catch, and it does
+  catch them in a change — but **changing an existing param's value goes through
+  no gate at all**.
+  No behaviour changed and no gate moved; the detector for the tautological form
+  stays under `Under consideration`, with all three of its blockers intact.
+  Documenting a trap is not the same as deciding not to detect it.
+
+- **A change's spec files now live at the location they will be merged to,
+  marked `*.proposed.spec.ts`.** `changes/<name>/` keeps `proposal.md`,
+  `requirements.delta.ts` and `first-run.json`; the scenarios sit beside the code
+  they attest, and merging one is a rename in place. Reported by
+  `mine-capablanca`: every one of eight merges rewrote the relative imports of
+  the change's specs, and the imports were the only thing that moved.
+  **"Depth" was the wrong word for it, and finding that out changed the
+  design.** The entry that queued this said the specs sat at a *different depth*
+  from where they land. They do not — `changes/<name>/specs/` and
+  `lib/game/specs/` are both three levels down. What differs is the **path**, so
+  no layout that keeps a spec under `changes/` can make one relative specifier
+  resolve in both places; mirroring the destination inside the change folder
+  fails for the same reason, one level further out. The only fix that costs no
+  mechanism is to write the file where it will live, which is what shipped.
+  *Two jobs the folder used to do at once, now done separately.* Keeping a
+  proposal's specs out of the base suite is by **name**, because it has to hold
+  for commands that never heard of a change: those scenarios are red by
+  construction, and a `verify` that swept them up would call every project with
+  a change in flight broken. Deciding which change a spec belongs to is by
+  **id** — a change claims the proposed specs declaring a scenario for an id it
+  ADDs, renames to, or MODIFIEs — because a file name carries no change, and the
+  delta already enumerates what the change is about. That keeps the property the
+  folder had and a `specs: []` list in the delta would have lost: nothing names a
+  path, so nothing can fall out of step with the files. REMOVED ids claim
+  nothing; a file is claimed whole or not at all, because the run scope is a set
+  of files.
+  *What it cost, stated rather than netted off.* A change is no longer one
+  folder a reviewer can read end to end — the delta still enumerates every id and
+  `attest status <name>` still answers what a change contains, but the specs are
+  now found by their marker rather than by looking in one place. And separating
+  the two jobs opened a gap the folder did not have, which is the `Added` entry
+  below. Held by `ATX-45` (excluded by name) and `ATX-46` (claimed by id), split
+  because they fail independently.
+  *Migration, for anyone with an open change directory:* move each spec from
+  `changes/<name>/specs/` to where it will merge, rename it to
+  `*.proposed.spec.ts`, and fix its imports once. That is the rewrite the merge
+  was going to charge anyway, done earlier and once. `first-run.json` is
+  unaffected — it is keyed by requirement id and scenario name, neither of which
+  moves.
+  Gone with the folder: `changeExcludeGlobs`, the sibling-exclusion globs that
+  kept one proposal's specs out of another's gate run. A directory glob could not
+  have told two proposals apart once the specs left `changes/`, and keeping one
+  beside the claim check would be a second scoping rule able to disagree with it.
+
+### Added
+
+- **A change delta now reads as the registry of what it adds.** `delta(…)`
+  returns the delta *and* a record keyed by the ids it ADDs, each carrying the
+  params its author wrote — so a stage-1 scenario reads a proposed param with
+  the expression a merged one uses:
+  ```ts
+  import reqs from '../../changes/add-2fa/requirements.delta.ts';  // ← only this line changes at merge
+  const window = reqs['AUTH-7'].params.totpWindowSec;              // typed at 30, no cast
+  ```
+  Reported by `mine-capablanca`, which hit this on 3 of 8 changes and wrote a
+  throwaway accessor each time, then rewrote every import at merge.
+  **The reason this was a defect and not an ergonomic complaint is which stage
+  it landed on.** Stage 1 is where the scenario must be written and must go red —
+  the entire content of the red-before-implement gate — so the tool pushed the
+  author off `params`, the single source the rest of it exists to reward, at
+  precisely the moment that source is load-bearing, and then billed them the
+  rewrite at merge for having complied. Every hand-written accessor is a second
+  place the value lives, open during the only stage where the assertion is being
+  authored against a value nobody has implemented yet.
+  *Why one value can be both.* A requirement id matches `/^[A-Z]+-\d+$/`, so no
+  id can ever be spelled `added`, `modified`, `removed` or `renamed` — the union
+  is safe by grammar rather than by convention, and neither surface shadows the
+  other. Both readers build it through one function, so the differential suite in
+  `tests/static-registry.spec.ts` still finds them agreeing about what a delta is.
+  *Deliberately not readable this way:* MODIFIED ids and rename targets. A
+  modified requirement's end state is the base entry with the patch applied, the
+  base is not in that file, and a view of the patch alone would answer one key
+  and `undefined` for every other key the requirement has — a shape that reads as
+  the merged requirement and is not one. Still no validation either: a delta
+  carrying an id the registry would refuse stays the gate's verdict (`ATX-41`).
+  Held by `ATX-48`, attested by compiling a fixture — a type has no runtime
+  footprint — with the assertion written as an equality against the merged read,
+  because sameness is the property that makes merging a change of import.
+  *Behaviour change, for whom:* the object `delta()` returns now carries the
+  added ids as own enumerable keys, so `Object.keys(d)` and a deep-equality
+  assertion over a whole delta see them. Nothing in Attest reads a delta that
+  way — `applyDelta` and both registry readers name the four sections — but a
+  consumer that snapshots a delta value will see its snapshot move. Reading
+  `.added`, `.modified`, `.removed` and `.renamed` is unchanged.
+
+- **`added-id-unmerged`: the gate now names why a spec file failed to load,
+  instead of blaming the spec.** Reported by `mine-capablanca`. `archive`
+  applies the delta in memory and gates the result; the suite is a child process
+  that imports `*.reqs.ts` from disk. So implementation code doing what the
+  skill's rule 3 requires — `reqs['FOG-4'].params.modestRisk` for an id the
+  change *adds* — throws at import, every spec transitively importing that module
+  fails to load, and the gate reported `tests-red` plus a `declared-not-run` per
+  scenario, whose message sends the reader to look for a `skip` or an `.only`
+  that is not there. **The change could not be made green by the documented
+  workflow, and the verdict pointed away from the reason.**
+  The gate now carries load failures out of the run alongside the coverage, and
+  when the change adds ids the on-disk registry lacks it reports one ERROR per
+  unloaded file, naming the file and the ids. The `declared-not-run` lines it
+  replaces are dropped — the absence has been explained, and restating it as a
+  guess about a skip costs the reader attention on files that are not at fault.
+  Only in the gate: `verify` keeps reporting them, having no diagnosis to put in
+  their place, and a wrong message still beats silence.
+  **This is the diagnosis and deliberately not the fix.** The way through is to
+  merge the added requirement into the registry before running the gate, which
+  the idempotent ADDED rule makes free — the `added:` entry stays and still
+  documents the intent. The alternative considered was to show the child run the
+  applied registry through an alias or a scratch overlay: it unblocks the
+  workflow and spends the property that the registry the suite ran against is the
+  file on disk, on the one command path that already evaluates project code. That
+  property cannot be given back by a later diagnostic; the convenience can.
+  *The condition is a conjunction and therefore a heuristic* — a module can fail
+  to import for reasons unrelated to any requirement id — so the message states
+  the two facts and the inference between them rather than asserting a cause.
+  Held by `ATX-49` (name the file and the ids) and `ATX-50` (withdraw the lines
+  it replaces), which are two requirements rather than one for the reason
+  `ATX-24` was split out of `ATX-23`: pushing one more issue satisfies the first
+  in full and leaves every misleading line sitting underneath it, so an
+  implementation can pass it and fail the reader exactly as before.
+  *Behaviour change, for whom:* no run goes from green to red — the new ERROR
+  only fires on a run that was already failing, because a file that did not load
+  is a failing run. What does move is what a machine consumer reads: for this
+  case `archive` now emits `added-id-unmerged` where it emitted one
+  `declared-not-run` per scenario. `verify` is untouched, and `declared-not-run`
+  is unchanged everywhere else.
+
+- **`proposed-spec-unclaimed`: a proposed spec no change claims is an ERROR from
+  `attest check`.** This is the cost of the split above, made loud. A file the
+  base suite skips by name and every gate skips by id executes nowhere, and both
+  skips are individually correct, so neither command is positioned to notice.
+  `check` is, because it is the only one that reads the deltas without being
+  about a single change — and reading them is something it already owed, since a
+  change delta is intent and the reporting commands read intent from source
+  (design §5.1). Reported per file, driven off the scanned tree rather than the
+  parsed plan so a proposed spec declaring no scenario at all is caught too. A
+  delta that cannot be read is reported as itself rather than turned into
+  accusations against its specs: not knowing what a change claims is a different
+  finding from knowing it claims nothing. Held by `ATX-47`.
+
+### Fixed
+
+- **`add-invalid` and `modify-invalid` now name the field that failed.** Both
+  quoted the schema's message and dropped the path it came from, so a
+  requirement whose `params` the schema refused reported `Invalid input` and
+  nothing else — no key, no accepted shape. Reported by an adopter who found the
+  failing param by reading `node_modules/@am_shork/attest/dist/core/schema.d.ts`,
+  which is the only place the constraint was written down.
+  *The form is not new, and that is the sharpest part of it.* `troubleshooting.md`
+  has quoted `Added requirement "AUTH-7" is invalid: rationale: Required` since
+  the section was written, and `RegistryValidationError` has spelled paths
+  `a.b.c` since the registry shipped — so the documented sample was one this
+  code could not produce, and the two sites that format the same zod failure
+  disagreed. The fix is the path, in the spelling already documented, from the
+  one function both callers go through. Where there is no path — the id itself,
+  under `introducedIdIssue` — nothing is prefixed rather than `(root)`, because
+  the message's own prefix has already named the thing.
+  Also on the way through: the `params` value union now carries its own message
+  instead of a bare `Invalid input`, so the refusal states what is accepted at
+  the moment it fires, and `registry-invalid` gains the same sentence for free.
+  Message text, so not a behaviour change under this file's own Versioning rule
+  — the codes and the accepted values are untouched, and no existing invocation
+  changes its exit code. Held by `ATX-44`, which states the contract over the
+  *path* rather than the sentence: the separator is the one property a scenario
+  can pin without asserting a word of the wording, which is what keeps
+  `Issue.message` prose while making its information content falsifiable.
+
 ## [0.4.3] - 2026-08-01
 
 ### Added
@@ -2046,37 +2436,26 @@ feedback reports are triaged into issues or `Unreleased` and deliberately not
 kept in this tree; that rule stands, and holds for anything with a reporter, a
 repro, or a state to track. What is kept here is the narrower thing this file
 already keeps one section of: a **decision with an argument attached**, where
-losing the argument would cost more than losing the task. The last below came out
-of reading another repository against this one — `msw`. The first came out of
-building something queued here, which is the other way an entry arrives: a gate
-that finds a defect on its first run files the defect.
-
-- **A diagnosable refusal when the resolved compiler has no AST API.**
-  Discovered by building the `typescript` matrix (see `[0.4.2]`), which is
-  what a matrix is for. `typescript@7` is the native port: its npm package's main
-  export is `{ version, versionMajorMinor }`, and the AST moved behind
-  `typescript/unstable/ast*` — so `ts.createSourceFile` and every `ts.isX` guard
-  the two readers call is `undefined`. Measured: `attest check` on it dies with
-  `TypeError: Cannot read properties of undefined (reading 'Latest')` and a raw
-  stack, on the crash path this release just finished sanitising. No issue code,
-  no fix hint, and nothing saying which compiler it wanted.
-  **The range excludes 7, and that is not the same as being safe from it.** A
-  caret is a request, not a constraint the adopter cannot override: `pnpm.overrides`
-  and Yarn `resolutions` both pin a transitive dependency across the whole tree,
-  and a repo standardising on one compiler is exactly the repo that uses them —
-  this one has an `overrides` block of its own. So the reachable case is a
-  deliberate, reasonable act by an adopter, answered with a stack trace.
-  What is planned is a check of the API surface where the readers are entered,
-  reported as an ERROR naming the resolved version and the supported range. Cheap,
-  and it converts the one dependency failure this tool cannot survive from a crash
-  into a diagnosis. *Deliberately not folded into the matrix commit*: a new ERROR
-  is a behaviour change, it needs an issue code, a troubleshooting section in both
-  languages and an `ATX-n` with a scenario, and none of that belongs in a commit
-  whose whole claim is that nothing about behaviour moved.
-  *What it cannot do:* make Attest work on TypeScript 7. That is a migration to
-  `typescript/unstable/ast`, against an API whose own name says not to depend on
-  it yet — a separate decision, with the honest answer for now being that the
-  supported range has a ceiling and says so.
+losing the argument would cost more than losing the task. The one below came out
+of reading another repository against this one — `msw`.
+
+Five entries have left by being built, and the last three left together in
+`[0.6.0]`. `compiler-unsupported` came from building something queued here,
+which is one way an entry arrives: a gate that finds a defect on its first run
+files the defect, and the `typescript` matrix `[0.4.2]` added is what found this
+one.
+`--apply` came from an adoption report (`mine-capablanca`, 0.4.2, 34 requirements
+/ 56 scenarios / greenfield) — a third way an entry arrives: not a defect, but a
+shape the tool made an adopter work around eight times without ever erroring. It
+took `spec-in-change-dir` out with it, by a fourth way worth naming: designing one
+of `--apply`'s checks surfaced a different one, against a migration this file had
+itself shipped. **What a release costs its adopters is not fully known on the day
+it is cut** — and building the entry is what finds out, which is also how
+`--apply` discovered that one clause of its own argument here was wrong. Both are
+recorded under `[0.6.0]`, and two earlier entries from the same report left
+by shipping in `[0.5.0]` — a change's specs moving to their merged location, and
+the delta reading as the registry of what it adds — their arguments recorded
+there, including the part of the first one that turned out to be wrong.
 
 - **Region-marked samples, so a partial quote can be bound too.** The whole-file
   half of this shipped in `[0.4.3]`: the README's two getting-started blocks
@@ -2147,6 +2526,84 @@ have to gather again.
   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
+  full gate on each mutation:
+
+  | mutation | who reads it | `check` | `verify` |
+  |---|---|---|---|
+  | `GEN-1.maxCandidatesPerPiece` 64 → 4 | scenario only | ok | **red** |
+  | `BOARD-1.boardSize` 10 → 12 | app + fixtures | ok | **red** |
+  | `BOARD-2.maxMines` 12 → **40** | app + assertion | ok | **green** |
+  | `BOARD-2.minMines` 9 → **1** | app + assertion | ok | **green** |
+
+  The mine-density band — the one number deciding whether that game is playable —
+  moved by 3.3× with the whole suite green, `check` silent, and `possible-drift`
+  correctly not firing, because a covering scenario *does* read the param.
+  **Read the third and fourth rows against the second, because that is the
+  finding.** The reporter's diagnosis was "app and spec both read it", but row 2
+  is app-and-spec and goes red. What distinguishes the green rows is narrower and
+  more useful: the assertion **derives its expectation from the same param the
+  code under test used**, so both sides move together and the comparison has no
+  independent term. Row 2's expectation lives in fixtures, which do not move when
+  the param does, and the mechanism works. So the failing condition is a property
+  of the assertion, not of who reads the value — which matters, because it means
+  the answer is a rule about how to write the assertion, and *not* the detector
+  the reporter proposed.
+  **What this falsifies is written in this file.** The rejection of a committed
+  params snapshot, below, closes on *"the mechanism that guards a param is a
+  scenario reading it, not a file recording it"* — a sufficiency claim, and rows
+  3 and 4 are counterexamples to it. A scenario reading the param is necessary
+  and not sufficient. That entry stays rejected on its own argument, which was
+  never about detection power, but its fallback clause is now known incomplete
+  and is annotated accordingly. The README's §"killer move" has the same shape:
+  it says noticing a param *moved* is `verify`'s job "only when a scenario asserts
+  on the value it read from `params`" — literally a necessary condition, and read
+  by an adopter as a sufficient one, with the very next line (*"Read the param
+  inside the assertion, not beside it"*) being the instruction that produces the
+  tautology.
+  **The framing that probably resolves it: this is `never-red` wearing different
+  clothes.** A tautological assertion is a scenario that cannot fail, which is
+  the exact defect `archive`'s red-before-implement gate exists to catch — and it
+  did catch two of them in this very repo (`CHECK-2`, `FOG-3`, both confirmed
+  correct by the reporter). The reason it did not catch these is structural:
+  **changing the value of an existing param goes through no gate at all.**
+  `archive` gates a change; a param edit is not a change. That is a cleaner
+  statement of the gap than "params can be tautological".
+  *What blocks the decision — three things, all of them real.* **(1)** Every
+  mutation above is synthetic. Across 8 commits touching `*.reqs.ts` in that
+  repo, **no param value was ever modified** — every `params:` line in every diff
+  is an addition. So the hole is proven as a logical property and its frequency is
+  entirely unmeasured, from one greenfield repo. **(2)** The reporter's proposed
+  mechanism — a WARNING when one param id is read from both a spec and a non-spec
+  file — is the wrong shape twice over: it fires on row 2, which is correct usage
+  and goes red, and it would fire on the arrangement the README actively
+  recommends, which is §9's "usually wrong about staleness" failure mode again.
+  It also needs a static sweep of the whole project for `reqs['X'].params.y`,
+  far past the two registry readers' current surface. **(3)** No mechanism is yet
+  known that separates "the assertion pins this independently" from "the assertion
+  echoes it" without executing the scenario twice under different values — which
+  is mutation testing, a much larger thing to own.
+  **The guidance half has shipped; this entry is now only about the detector.**
+  "Read the param inside the assertion" was insufficient and half-wrong as
+  written, and `[0.5.0]` replaces it everywhere it appeared — README, the
+  `init` skill, `possible-drift`, and design §11 — with what the evidence
+  supports: **the expectation must not be a function of the param the code under
+  test consumed**, pinned in a fixture, a literal, or a second independently
+  derived value. Row 2 is the worked example, and the reporter's own
+  `CHECK-2`/`FOG-3` fixes are the same move. It was held back once because
+  rewording the central claim of the tool is not a line appended; that is what
+  was then done, deliberately and in one pass.
+  **What stays undecided is the mechanism**, and all three blockers above are
+  untouched by the rewording: the frequency is still unmeasured from one
+  greenfield repo, the reporter's proposed detector is still the wrong shape
+  twice over, and nothing short of mutation testing separates an independent pin
+  from an echo. What the guidance does not do is close the hole — a tautological
+  assertion is still green, still silent, and still reachable — so this stays
+  here rather than moving to `Considered and rejected`: documenting a trap is
+  not the same as deciding not to detect it.
+
 ## Considered and rejected
 
 Decisions **not** to build something, kept where they can be found before the
@@ -2393,6 +2850,21 @@ no scenario caught it, and `possible-drift` was **not** already printing —
 because if it was printing, what failed was reading the report, and a second
 gate does not fix that.
 
+*Annotated after `mine-capablanca` (0.4.2): the last two sentences above are
+wrong and the rejection is not.* "A scenario reading it" is necessary and not
+sufficient — where the assertion recomputes its expectation from the same param
+the code under test consumed, the value moved 3.3× with the suite green and
+`possible-drift` correctly silent, so "the only condition under which a moved
+param goes unnoticed" names one condition out of two. The reopen clause is
+therefore satisfied in substance while failing on its own literal terms, since it
+was written expecting the uncovered case and the demonstrated one has a covering
+scenario. **What that changes here is nothing**: this entry was rejected on the
+population a snapshot fires on — every legitimate param edit, fix a commit with
+no decision in it — and that objection is untouched by the new evidence, which
+concerns detection the snapshot was never denied having. The live question moved
+to `Under consideration` above, where it belongs, because the mechanism now in
+question is a rule about assertions rather than a file beside the registry.
+
 ### Grouping `render`'s output by prefix
 
 The *detection* half of this is already rejected above (every automatic
@@ -2417,7 +2889,44 @@ 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.
 
-[Unreleased]: https://gitlab.com/Pseudorca/attest/-/compare/v0.4.3...main
+### Nested objects in `params`, so a lookup table can be registry-owned
+
+Raised by `mine-capablanca` (0.4.2) and explicitly not as a request, which is
+why it is recorded with its own answer rather than left as a complaint about a
+message. A `params` value is a scalar or a list of scalars; a table — piece kind
+to weight, tier to limit — is refused, and the only way to register one is to
+split it across parallel arrays, which reads worse in the rendered spec than it
+buys. *What rejected it: the two properties a param has, and a table has
+neither.* A param is **rendered into `SPEC.md` as a value a human checks at a
+glance**, and it is **read by a scenario as the one place that value lives**. A
+nested object fails the first by construction — there is no reading of a
+five-row table that a reviewer verifies the way they verify `30`. It fails the
+second more quietly: a table has many readers by definition, so "the one place"
+becomes "the one file", which is what an ordinary module already is. The
+schema's own comment records where the line was drawn and why arrays were let
+in — list constants are the most drift-prone values, and an array still has one
+owner read by one scenario. A table does not clear that bar; the reason arrays
+did is exactly the reason it does not.
+*The reporter's own resolution is the argument's strongest form.* The table went
+to a shared module, is not registry-owned, and **nothing was lost** — because a
+piece-value table is tuning, not a promise. That is the rule design §11 now
+states — *params for promises, plain constants for tuning* — derived
+independently by the same adopter before it was written anywhere. Under it this
+candidate is not a limitation of `params` at all: it is a value that was never a
+requirement's to hold, and §11 carries this rejection's own argument in the same
+paragraph, as the rule stated over the type rather than over the value.
+*What ships instead*, in `[0.5.0]`: the refusal now says what is accepted
+instead of `Invalid input`, and `troubleshooting.md` states the constraint and
+where such a value belongs — the reporter's actual ask, which was for the
+decision to be visible rather than discovered by reading the shipped `.d.ts`.
+The permanent half goes to design §11 with the params rule, not here.
+*This reopens on* a report where the value is genuinely promised — a table an
+adopter owes their users, whose rows a reviewer would want in the rendered spec.
+None has been seen; the one that raised it was tuning.
+
+[Unreleased]: https://gitlab.com/Pseudorca/attest/-/compare/v0.6.0...main
+[0.6.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.6.0
+[0.5.0]: https://gitlab.com/Pseudorca/attest/-/tags/v0.5.0
 [0.4.3]: https://gitlab.com/Pseudorca/attest/-/tags/v0.4.3
 [0.4.2]: https://gitlab.com/Pseudorca/attest/-/tags/v0.4.2
 [0.4.1]: https://gitlab.com/Pseudorca/attest/-/tags/v0.4.1