wowbagger 0.1.0-alpha.6 → 0.1.0-alpha.8

package/CHANGELOG.md

@@ -5,6 +5,505 @@ A change to what a command accepts, refuses, emits, or writes is a behaviour
 change even when the commit that carried it was labelled refactor, docs, or
 consolidation. The first tagged release inherits this file.
 
+## Unreleased
+
+## 0.1.0-alpha.8 - 2026-08-23
+
+### Added
+
+- **A published launch seam for a host that cannot run a shell.** The package
+  now declares `exports`, and its main entry `wowbagger` exposes
+  `CORE_SCRIPT_PATH`, `MINIMUM_NODE_MAJOR`, and `resolveCoreLaunch(argv)`, which
+  returns the exact process tuple a direct-core host needs: an absolute Node
+  executable, an argument array whose first element is the absolute
+  `bin/wowbagger.js`, and `shell: false`. A host that resolves its own runtime
+  gets `resolveCoreLaunch(argv, { nodeExecutable })`, and a relative or bare
+  executable name is refused rather than left for PATH to answer. The script
+  path is also resolvable on its own as `wowbagger/wowbagger.js` for a host that
+  wants the path without importing anything. Deep imports that already worked —
+  `wowbagger/src/limits.js` and every other published path — keep resolving
+  through an explicit `"./*"` subpath. No command accepts, refuses, emits, or
+  writes anything different.
+
+- **The machine contract ships as JSON Schema, not only as prose and fixtures.**
+  Seventeen JSON Schema 2020-12 documents under `schemas/` are published with
+  the package and resolvable as `wowbagger/schemas/<file>.json`, with
+  `schemas/index.json` naming each one's response domain and that domain's
+  version. They cover the core envelope and its four exact root shapes, the
+  capabilities envelope with every advertised limit as a constant, the two bare
+  results, the list query and its page and refusals, the default and workbench
+  inspect projections, the transition request, success, and every documented
+  refusal with its mutation state, the `ledger-mutation` fence refusals, report
+  configuration versions 1 and 2, and the report responses including a named
+  view. Every schema fixes its root members exactly and pins the version of its
+  own domain, so a core envelope refuses a namespaced refusal, a version 4
+  envelope, or an extra root member, and a version 1 report configuration
+  refuses a version 2 one. Exactness reaches the members too: an item core must
+  carry both relation lists, because the core view always emits them, and a
+  refusal raised before a commit is established pins its state to `unchanged`
+  rather than admitting the indeterminate state that only an interrupted write
+  can report. The validator is a test-only dependency; the runtime still has
+  exactly one dependency.
+
+### Documentation
+
+- **`docs/host-contract.md` publishes the direct-core host boundary.** One
+  document now states what a UI plugin or other non-agent consumer needs and
+  what it must supply itself: the package resolution seam and the four-part
+  launch — Node.js 20 or later, an absolute Node executable, the absolute
+  `wowbagger.js`, an argument array, and `shell: false`; bounded stdin or a
+  host-created request file, never shell source and never inline unbounded argv
+  JSON; captured stdout and stderr; the owning-host path rule for a worktree, a
+  plain folder, direct SSH, and WSL, with no cross-runtime path guessing;
+  namespace-first response dispatch and the exit table; every advertised limit
+  with its exact value; the once-only dispatch sequence for a lost response; and
+  the seventeen packaged JSON Schemas by domain. It states that a missing
+  executable is a host-level result rather than malformed Wowbagger JSON, that
+  the host owns executable discovery, working directory, timeout, cancellation,
+  process-tree containment, stream caps, and routing, and that Wowbagger will
+  not add automatic transitions, mirrored ledger state, operation identity,
+  remote routing, or a daemon. The full `inspect` read is documented as
+  deliberately unbounded, with the reason. The README, the installed skill, and
+  `SPEC.md` section 10 point at it, and it ships in the npm package.
+- **The public version and lifecycle vocabulary agrees with the runtime.**
+  `SPEC.md` section 10 said core mutation contracts 1 and 2 were defined and
+  that the runtime emitted version 2; it now says 1 through 5 and version 5. The
+  mutation contract's status line said versions 1, 2, and 3 with the runtime on
+  3; it now says 1 through 5 and version 5. `deferred` has been a real status
+  since it shipped, but `SPEC.md` omitted it from the status field, the
+  lifecycle table, the transition table, the terminal-date invariants, the
+  decision-action list, and the terminal-decision table, and the mutation
+  contract omitted the `deferred` date from the lossless core view; all seven
+  now name it, along with the `resolve`, `defer`, and `undefer` decision actions
+  the validator has always accepted. No behaviour changed: these were prose
+  omissions, and the tests that guard them read the vocabularies from
+  `src/lifecycle.js` and `src/validate.js` rather than retyping them.
+- **Response loss is a named contract instead of folklore.** The mutation
+  contract, the adapter contract, the README, and the installed skill now carry
+  the same sequence for a mutation whose response never arrived: dispatch once,
+  never replay, invalidate the inspected revision, reconnect, then re-read the
+  ledger. The mutation contract's new section 10 table separates the outcomes a
+  caller may act on — committed success, proven non-write, committed recovery,
+  unknown publication — from the two that establish nothing, a signalled or
+  timed-out transport and a missing envelope, and states that a later item state
+  never proves that the lost dispatch caused it. Adapter contract section 6.2
+  documents the `mutation_outcome: "unknown"` envelope and its per-command
+  `recovery` object exactly as the adapter emits them, and states that exit 4
+  `revision-conflict` is a proven non-write that is never relabelled response
+  loss. There is no operation ID, durable outcome store, or replay endpoint;
+  adding correlation requires a new contract decision. No command accepts,
+  refuses, emits, or writes anything different. Two conformance vectors now pin
+  the core's own exit-6 `write-outcome-unknown` and `post-commit-recovery-required`
+  envelopes at the adapter's process-outcome seam, taking the adapter vector set
+  to 212 assertions.
+- **The exit tables state where `report` actually lands.** Both contracts filed
+  exit 1 as a bare-result-only condition and exit 3 as every invalid ledger,
+  while `report` answers an invalid ledger, an unreadable input, and a failed
+  publication at exit 1. The mutation contract now carries an exit 1 row naming
+  those codes, lists `report-config-invalid` and `report-view-not-found` in its
+  exit 2 row, and scopes exit 3 to every command except `report`; the host
+  contract's exit 1 and exit 3 conditions say the same. Two guards assert the
+  rows against the codes the runtime emits.
+
+### Changed
+
+- **The report filters by facet groups instead of one value at a time.** The
+  drill-down's single-value mapped-field selects and its All/Ready/Blocked/
+  Ineligible buttons are gone. In their place is one group of checkbox chips per
+  dimension of the open set — Readiness, Status, Kind, and every configured
+  mapped field, so a mapped `class: bug` is a chip rather than a value hidden in
+  a dropdown. Values inside a group are alternatives, groups narrow each other,
+  and the search box is one more condition; every chip states the count it would
+  leave, measured against the search and the other groups but never against its
+  own, so two selections in one group cannot make their siblings read zero. A
+  visible result count, per-chip selected state, and `Clear filters` are new, and
+  opening a Work next or Attention row still clears whatever detached its card,
+  facets included.
+- **The ledger graph filters by lifecycle status.** One chip group above the
+  stage carries the statuses the ledger holds, all selected, with `Select all`
+  and `Clear`. Deselecting a status drops its nodes, every link incident to one,
+  and their labels, reheats the layout in place, and takes a hidden node off the
+  hover card; the roster and node count follow the same selection, and an empty
+  selection draws an empty graph that says so. The legend, the WebGL-less
+  roster, camera interaction, and the no-fetch contract are unchanged, and
+  nothing here reads or writes the ledger.
+
+### Fixed
+
+- **A report failure before publication says so, and never arrives causeless.**
+  An output path the filesystem cannot resolve — a `--out` under a regular
+  file, an unreadable directory on the way to it — was a raw runtime error
+  escaping into the command's catch-all, answered as `report-write-failed` with
+  empty `details` even though nothing had been rendered or replaced. It is now
+  `report-read-failed` with `details.operation` naming which resolution failed,
+  `details.path` naming the path the caller configured or passed, and
+  `details.cause` naming the filesystem's own code. An error no report path
+  throws on purpose still answers `report-write-failed`, because nothing
+  reached the output path, but it now carries `{operation, cause}` instead of
+  `{}`. Every `details.cause` is a bounded token — an error code, or the
+  error's kind when the runtime gave no code — so a publication failure no
+  longer republishes a runtime message, and the paths, credentials, and
+  run-specific values a message carries stay out of the envelope. Atomic
+  publication is unchanged: a report already at the selected path survives
+  every one of these refusals.
+- **An empty named view stops blaming the reader.** A view whose criteria
+  matched nothing rendered the drill-down's `No items match these filters.` and
+  the graph's `No status is selected`, sending a reader to controls that could
+  not bring an item back. A named artifact with no items now states
+  `No ledger item matches this view's criteria.` and, in the graph, that it has
+  nothing to draw — visibly, without waiting for scripting. A report that holds
+  items keeps the filter and status copy, which is the honest answer when the
+  reader is the one who narrowed it, and the base report's bytes are unchanged.
+- **`core-report-response.json` named a member the report never emitted.** The
+  published `ledger-invalid` refusal required `details.validation_errors`,
+  which is the mutation commands' member name; `report` has always emitted
+  `details.errors`. A consumer validating a real refusal against the shipped
+  schema failed on the runtime's own bytes. The schema now states `errors`, and
+  a live invalid-ledger report run is validated against it.
+
+## 0.1.0-alpha.7 - 2026-08-18
+
+### Changed
+
+- **The item source is bounded at every candidate door, and the core contract
+  moves to 4.** The published version 3 core accepted a 50-MiB `create` with
+  exit `0` and state `committed` in 0.70 s: `create`, `transition`, and `patch`
+  had no bound
+  anywhere, and `publish-claimed` alone bounded candidates but reported an
+  oversized, perfectly canonical candidate as `The candidate source is not
+  canonical base64.` One shared `MAX_ITEM_SOURCE_BYTES` of 8,388,608 now bounds
+  the complete serialized successor at all four doors, and every one of them
+  answers the same named refusal: `item-source-too-large`, exit 2, state
+  `unchanged`, details exactly `{id, size_bytes, limit_bytes}` in the core
+  domain and `{item_id, size_bytes, limit_bytes}` in the ledger-publication
+  domain. The measurement is serialized UTF-8 bytes, so frontmatter, decisions,
+  extensions, and body all draw on the same budget; `transition` is bounded
+  because its decision block can push a legal stored item past it. Core
+  capabilities advertises the value at `result.limits.max_item_source_bytes`.
+  This narrows accepted input against a published version, so the core contract
+  moves to 4 and version 3 consumers fail closed at negotiation. A ledger
+  committed before the bound does not brick: an oversized item still validates,
+  still inspects, and a patch that shrinks it under the bound is accepted.
+
+- **The work-claim API moves to 2.** The oversized-candidate response replaces
+  the error `publish-claimed` version 1 pinned for that input, so
+  `result.operations.work_claim.api_version` is now `2` and version 1 consumers
+  fail closed. Malformed base64 keeps its version 1 `invalid-request`: without
+  canonical base64 there is no item source to measure. The base64-character
+  precheck is gone — the 11,534,336-byte serialized-request bound already caps
+  what a candidate can decode to, and the precheck was the remaining path that
+  answered a genuine size refusal with a false base64 message. That transport
+  bound is unchanged and still measures a different object.
+- **A claimed publication no longer takes one cooperative lock per ledger
+  item.** `publish-claimed` computed its lock closure from every item in the
+  loaded ledger, so publishing one item on a 1,500-item ledger created, wrote,
+  fsynced, and unlinked 1,503 lock files. It runs from journal replay through
+  its terminal record inside the namespace write lock, and every other
+  cooperative writer of a provisioned ledger enters that same lock before it
+  writes, so the per-item closure excluded nobody the namespace lock did not
+  already exclude. Publication now takes no per-item locks. Newly instrumented
+  phase counters measured the cost this removes: on 1,500 items the lock phase
+  was 11.2 s of the 12.6 s the publication took, against 0.2 s for reading Git
+  HEAD. Everything else is unchanged and proved byte-for-byte identical against
+  the previous implementation across all six publication outcome classes —
+  success, fence refusal, revision conflict, validation refusal, idempotent
+  replay, and indeterminate publication — in envelope, claim journal, and item
+  bytes. Every cooperative writer of one ledger must be upgraded together: a
+  writer that honors only per-ID locks can race one that honors only the
+  namespace lock.
+- **The README installs with `@next` and says why.** The registry mandates a
+  `latest` dist-tag, so `latest` mirrors `next`; `@next` stays the documented
+  spelling and the explicit prerelease consent.
+- **Cuts happen on the release branch, not in a session worktree.** Merge
+  session work first, then cut; the cut command refuses to run anywhere but the
+  branch tip. The previous two-phase topology is why the last two release tags
+  name merge commits rather than their cut commits.
+  `docs/adapter-release-path.md` records the ritual.
+
+### Fixed
+
+- **A live publication is no longer reported as a broken lock.** Publication
+  lock files recorded `"operation": "publish-claimed"`, but the lock reader
+  accepts only `create`, `transition`, and `patch`, so a concurrent writer that
+  hit a live publication lock classified it `invalid-shape` — a diagnostic that
+  says the lock is corrupt. Publication writes no lock files at all now, so
+  there is nothing to misclassify.
+
+- **A committed `patch` is forwarded instead of reported as an unknown
+  outcome.** The shipped adapter engine still named the pre-widening patchable
+  pair `number` and `priority`, so every patch a consumer actually sends — a
+  body rewrite, a title correction, a relation-list replacement, a declared
+  extension member — read as a non-canonical request, failed result
+  correlation, and came back `mutation-outcome-unknown` with recovery guidance
+  about a write that had provably committed. `number` is the immutable item
+  identity and was never patchable at all. The patchable field set is now what
+  mutation contract section 9 names — `title`, `priority`, `depends_on`,
+  `related`, `body`, `body_append`, and `extensions` — with the two body write
+  modes mutually exclusive and the extensions container judged only on its own
+  shape, and correlation follows each member to the surface it is observable
+  on. The independent reference model already had all of this, so the drift was
+  one-sided and no differential test could see it; the new end-to-end
+  core-outcome vectors found it on their first run.
+
+- **`publish-claimed` now reconciles the journal unconditionally, like every
+  other mutating command.** The work-claim contract has always said an
+  uncommitted prior mutation refuses the next `create`, `transition`, `patch`,
+  **or `publish-claimed`**. The code only reconciled when it happened to
+  observe an unresolved `publish-intent`, and an uncommitted legacy mutation
+  leaves none behind. A fixture pinned the gap: with a legacy create and
+  transition sitting uncommitted, `claim-verify` returned exit 6 and a legacy
+  `create` refused with `publication-reconciliation-required`, while
+  `publish-claimed` on a claimed item published straight over the unreconciled
+  ledger. It now reconciles before the fence decision on every publication and
+  refuses with exit 6 `claim-store-unavailable`,
+  `details.reason: "publication-reconciliation-required"`, and
+  `details.findings` — the same envelope the legacy fence emits, so one
+  `claim-verify` clears every blocked path. **A publication behind an
+  unresolvable prior intent now returns that refusal instead of exit 6
+  `publication-outcome-unknown`.** The old code named the refused publication's
+  own outcome uncertain when it had not run at all; `state: "unchanged"` is the
+  honest answer, and the blocking finding still travels in `details.findings`.
+  The cost is honest about which read is new. Reconciliation adds no
+  complete-ledger read: it produces the snapshot the candidate validation and
+  the mutation engine's pre-lock read already share, so a claimed publication
+  still reads the working-tree ledger exactly twice. It does add the Git `HEAD`
+  read — `rev-parse`, one `ls-tree`, and a batched `cat-file` over every item
+  blob at `HEAD` — to every publication that previously had no unresolved
+  intent. That is the same read `create`, `transition`, `patch`, and every
+  claim lifecycle command already perform, so `publish-claimed` now pays the
+  toll its peers pay rather than a new one. Each publication persists one clock
+  floor, as it did before; a publication behind a pending intent, which used to
+  persist two, now persists one as well.
+
+- **A shipped adapter no longer advertises trusted approval it cannot
+  exercise.** The three shipped entrypoints declared
+  `trusted_approval: {"supported": true, "sources": ["consumer"]}` while
+  `runAdapterEntrypoint` passed no approval, clock, nonce store, or core
+  executable identity to the invoke engine, so `create`, `transition`, and
+  `patch` through every shipped adapter refused `consumer-approval-required`
+  and could not succeed on any input. The declaration now reflects the runtime
+  of the invocation, the way `optional_features.claims` already reflects the
+  core probe: a bare entrypoint run declares no trusted approval and refuses a
+  mutation `capability-unavailable` with `missing: ["trusted-approval"]`, the
+  refusal section 5.1 already required for an absent declaration, and a host
+  that wires an approval source declares it truthfully. The two refusals stay
+  distinguishable, because they are different facts — no approval source at all
+  versus a source that produced no approval for this invocation — and conformance
+  case `07-mutation-approval` now pins both against the runtimes that produce
+  them, adding one assertion to the conformance suite.
+- **A committed `create` is forwarded instead of reported as an unknown
+  outcome.** Both adapter engines required `schema_version: 1` in a create
+  result and re-serialized the expected candidate with the schema 1 default, so
+  every create against a real ledger — an empty ledger is schema 2 — failed the
+  result correlation, was judged an invalid core envelope, and came back as
+  `mutation-outcome-unknown` with recovery guidance about a write that had
+  provably committed. The ledger's schema version and the number the core
+  assigns under its own lock are the only two members of the answer a caller
+  could not have known; both engines now read those from the result and
+  re-derive the whole candidate from the request bytes, leaving every other
+  member pinned by an exact byte comparison against the source the core
+  returned. The defect was unreachable while every shipped mutation refused
+  before launch, and surfaced the moment a host runtime carried a real approval
+  through to the core.
+- Adapter contract section 5's core-request table and section 5.1's approval
+  rule named only `create` and `transition`. Both have accepted `patch` since
+  adapter contract version 2; the prose now says so.
+
+### Added
+
+- **`inspect` answers a bounded per-item lifecycle affordance projection.**
+  `inspect --ledger <dir> (--id <id> | --number <n>) --workbench --as-of
+  YYYY-MM-DD --json` returns, from one complete validated ledger snapshot,
+  `result.workbench`: the projection version, the as-of date, the ledger
+  snapshot witness, an `observation` member, a bounded item summary, and one
+  `transition_options` entry for every lifecycle target the native edge table
+  allows out of that item's kind and status. Each option names its target
+  status, its generated decision action or `null`, whether a caller-supplied
+  summary and rationale are required, the minimum legal transition date
+  `max(created, updated)`, its observed enabled state, and the observed
+  precondition issues and multi-item blockers in the exact `transition`
+  vocabulary. A workbench can now show a person which transitions an item can
+  take without duplicating lifecycle logic and without submitting a mutating
+  probe.
+
+  The read is an observation, not a lease, and says so in the response:
+  `observation.authority` is `observed-snapshot` and `observation.rechecked_by`
+  names what a later `transition` rechecks under lock — revision, lock, claim
+  fence, reconciliation, and candidate validation. It writes no item, lock,
+  claim journal, reconciliation log, or Git state, and it takes no lock.
+  `transition` and the projection share one lifecycle definition
+  (`src/lifecycle.js`), and a differential guard dispatches every projected
+  option and every unadvertised target through the real mutation, so an
+  advertised affordance cannot drift from what the mutation does.
+
+  Every variable-size field is bounded and says what it left out: the projected
+  title, the relation lists, each option's issues and blockers, and the related
+  IDs inside an issue. `--workbench` requires `--as-of`, an unpaired `--as-of`
+  is refused rather than ignored, and an `inspect` invocation without
+  `--workbench` is byte-identical to before. `capabilities` advertises
+  `operations.inspect.workbench` and the three exact bounds
+  `max_workbench_title_characters`, `max_workbench_collection_entries`, and
+  `max_workbench_response_bytes`; the core contract version stays 5, and the
+  projection is negotiated by its own `projection_version`. An invalid ledger is
+  `ledger-invalid` at exit 3 with no projection attached, and a projection that
+  would exceed its response bound is refused whole with
+  `workbench-response-too-large` at exit 2.
+
+- **The conformance suite now measures real core outcomes end to end.** A new
+  equivalence case, `16-core-outcome-e2e`, carries nine hand-authored scenarios
+  that each run the direct real core in one isolated temporary workspace and,
+  separately, spawn the real shipped entrypoint over the bootstrap wire against
+  the real core in a second workspace materialized from the same before state:
+  `inspect` item-not-found, a committed `create`, a committed `transition`, a
+  committed `patch` by body replacement and by declared extension member, the
+  six-member date refusal, and all three `ledger-mutation` claim-fence refusal
+  classes. Success vectors match the exact core exit, stdout bytes, decoded
+  adapter streams with their digests and lengths, and the exact ledger
+  post-state; refusal vectors match the exact nonzero exit and unchanged ledger
+  bytes, and the fence refusals arrive as `ok: true` adapter transport results
+  rather than adapter errors. Before this case, no conformance assertion and no
+  bootstrap-wire test carried a mutation through a spawned entrypoint into a
+  launched core, which is how two real adapter defects shipped. The suite is
+  210 assertions across 16 cases.
+
+  Determinism comes from fixed inputs and never from normalizing output: a
+  caller-supplied ULID, seeded revisions on isolated temporary ledgers, literal
+  dates, and — for the two real claim-fence read-backs — a fixed namespace, a
+  hand-authored claim journal, and a seeded future clock floor, so the emitted
+  `observed_at` is `max(physical_now, floor)` and therefore the floor. That
+  makes the refusal bytes fixed without mocking the core clock, and it expires:
+  both runners fail loudly and name `2031-01-15T12:01:00.000Z` once wall time
+  reaches it. Goldens are authored from the adapter contract, the work-claim
+  contract, and the normative `spec/fixtures/mutations/**` bytes; every byte
+  reused from those fixtures carries a `derived_from` pin, so drift on either
+  side stops the vector and asks for a reviewed golden change instead of
+  regenerating one. Only base64, SHA-256, and byte length are derived, and only
+  from an already hand-authored byte string.
+
+  The conformance host gains a granting approval mode, without which no
+  mutation can cross the spawned entrypoint at all. **Adapter contract section
+  10 previously said no conformance fixture could manufacture authority; that
+  is no longer true, and the claim is withdrawn rather than quietly narrowed.**
+  What replaces it is narrower and checkable: the granting mode is reachable
+  only from a fixture's own runtime configuration, which no shipped adapter
+  package reads and no wire this contract defines carries; every granting
+  scenario runs against a throwaway temporary ledger; the approval is minted
+  from the binding the engine resolved and canonicalized by the independent
+  reference model. The evidence label is the production adapter engine under a
+  conformance host approval provider, not a live consumer approval mechanism.
+
+- **A host process can wire consumer approval into a shipped adapter
+  entrypoint.** `runAdapterEntrypoint` now accepts an optional `hostRuntime`
+  carrying the approval source, the current time, the redeemed-nonce store, and
+  the core executable identity the host attests. It is a code-level parameter of
+  the embedding process and is deliberately absent from every wire: the
+  bootstrap request root schema is exact and has no approval member, so an
+  approval a model places on the request is an `invalid-invocation` that never
+  reaches the gate, exactly as adapter contract section 5.1 requires. The
+  approval may be a finished event or a resolver the adapter calls with the
+  exact binding it has just resolved — the argument vector, absolute workspace
+  paths, and instruction and handoff digests an approval covers do not exist
+  until the adapter has built them, so an interactive consumer prompt cannot
+  mint the approval any earlier. A resolver that fails produced no approval and
+  the mutation refuses; it never proceeds unapproved. The default is unchanged
+  and remains no approval. `test/adapter-host-approval-wire.test.js` carries the
+  first approved mutation in this repository to cross a spawned entrypoint into
+  a launched core and change a ledger, with its binding digest canonicalized by
+  the independent reference model rather than by the engine under test. No
+  version moved in any domain: `host.trusted_approval` has been optional since
+  version 1, the approval object and binding are untouched, and the mechanism is
+  invisible on every wire the contract defines. Adapter contract sections 3.2,
+  3.3, 5.1, 10, and 12 state the seam, the honesty rule, the two-runtime
+  evidence, and the version argument.
+
+- **The cut is one command, and version drift now fails the cut instead of
+  shipping.** `npm run release:cut -- <version> --date YYYY-MM-DD` runs on the
+  tip of the release branch, proves every version site is accounted for, plans
+  the new bytes in memory, runs the full release gate over them, and leaves one
+  `Cut <version>` commit and one annotated `v<version>` tag. It stops there:
+  push, `npm publish --tag next`, and the registry check stay separate named
+  steps, because no local command can undo any of them. Coverage is proved by
+  exact-set equality against a hand-maintained
+  `scripts/release-version-sites.json`, not by a global grep — the changelog and
+  the dated design records must keep naming old versions, so "grep finds
+  nothing" would be the wrong test. A release site added next month is
+  unmanifested and refuses the cut. `--dry-run` runs the same planner and the
+  same gate against a copy of HEAD and then proves the repository unchanged.
+  Reruns converge rather than repair: a cut tag at a clean HEAD reports
+  `already cut`, a complete cut commit without its tag resumes at tagging, and a
+  tag pointing elsewhere refuses.
+- **The changelog can no longer lose its Unreleased section.** A cut opens a
+  fresh empty `## Unreleased` and files the released notes beneath it. The two
+  previous cuts renamed the heading instead, which left later changes landing
+  under an already published release.
+- **The prerelease channel policy is stated and checkable.**
+  `npm run release:channels -- check|repair <version>` encodes it: `latest`
+  mirroring `next` at the published version and the first published alpha
+  deprecated. The first-choice policy — no `latest` at all, so a bare install
+  fails loudly — was refused by the registry itself: npm rejects deleting the
+  `latest` tag with E400 (verified live), so the current prerelease replaces
+  the dead first alpha as the forced default. `check` is read-only and is the
+  post-publish verification step; `repair` is idempotent and never unpublishes.
+
+- **`--auto-commit` folds the commit-per-mutation ceremony into the mutation.**
+  The invariant is correct and the ceremony around it was the consumer's most
+  frequent daily cost: mutate, `git add`, `git commit`, `claim-verify`, repeat,
+  ten times for ten items. On a provisioned merge-coordinated ledger the new
+  opt-in bare flag on `create`, `transition`, `patch`, and `publish-claimed`
+  does that loop inside one invocation. It takes a per-working-tree mutex,
+  refuses any staged path anywhere and any dirty path under the ledger, checks
+  Git identity, runs an internal pre-mutation `claim-verify`, runs the mutation
+  unchanged, then commits **exactly** the changed item plus at most one
+  `.wowbagger/reconcile-<namespace>.md` under a fixed subject
+  (`wowbagger: transition item #7`; the canonical item ID for a schema-1 item
+  with no number). It verifies the resulting commit's parent, subject,
+  changed-path set, and every blob, then runs `claim-verify` again before it
+  answers. Success adds `git_commit`, `commit_paths`, and `claim_verified` to
+  `result`.
+
+  There is no configuration file setting, environment default, or repository
+  default, because a hidden default would make existing mutation automation
+  create Git commits unexpectedly. An invocation without the flag is
+  byte-identical to before, so the core contract stays 3 and the work-claim API
+  stays 1. The flag is direct-CLI only in this release; no adapter advertises or
+  constructs it.
+
+  What it will not do: commit anything on `state: "unchanged"` or
+  `state: "unknown"`, including the documented reconcile-log residue a refused
+  `publish-claimed` leaves behind; stage a path outside the ledger; broad-add,
+  amend, squash, reset, clean, stash, or unstage; pass `--no-verify` or disable
+  signing; fabricate an author; customize a commit message; or push, fetch,
+  pull, merge, or rebase. Hooks through `core.hooksPath`, `commit.gpgSign`, and
+  signing programs are honoured, and a hook that rewrites the subject or the
+  tree is reported rather than accepted.
+
+- **An honest commit-failed contract, and one idempotent recovery verb.** A
+  post-publication Git failure that proves the commit is absent is exit 6
+  `git-commit-failed` with `state: "committed"` — the state still describes item
+  publication, not Git finalization — carrying the published revision, the exact
+  ledger-relative commit set with digests, `failure_stage`, `reason`, and a
+  bounded `recovery_token`. `create`, `transition`, and `patch` keep the core
+  domain; `publish-claimed` keeps `ledger-publication` and its top-level
+  `operation_id`. An **ambiguous** Git outcome is `git-commit-outcome-unknown`,
+  never `git-commit-failed`, and a commit that stands while reconciliation then
+  refuses is `post-commit-reconciliation-failed`. No failure envelope carries
+  hook output, signing output, absolute paths, or environment values.
+
+  New command: `wowbagger mutation-finalize --ledger <dir> --recovery-token
+  <token> --json`, answering in the work-claim domain because it changes Git
+  reconciliation state and no item byte. It re-derives every path from the
+  ledger and the provisioned namespace — the token is a witness, never authority
+  to select a path — re-checks the current bytes and the foreign-change rules,
+  creates the exact commit if it is absent, then runs `claim-verify`. When
+  `HEAD` already holds that exact commit it verifies and returns it without
+  creating a second one, so a lost response and a failed commit recover through
+  the same command, and repeating it is safe.
+
+  A failed attempt leaves its own commit set staged, because the design forbids
+  unstaging. Recovery tolerates exactly that residue and refuses anything else
+  staged; until it runs, the next `--auto-commit` invocation refuses on
+  `staged-paths-present`, which is the intended signal.
+
 ## 0.1.0-alpha.6 - 2026-08-17
 
 ### Added
@@ -263,7 +762,7 @@ consolidation. The first tagged release inherits this file.
   every read and every guarded mutation on that ledger, including ones that
   never touch the misplaced item, so the refusal has to say where the item
   belongs. The claim fence is not involved: `claim-verify` reports no finding
-  on such a ledger, refuting the PropertyCompass2 PR #2184 claim that a
+  on such a ledger, refuting an earlier consumer report that a
   root-misplaced item makes the fence report `stale-write-detected` with
   `actual_revision: null`. Fixtures pin both configuration orders — layout
   bound first, and layout bound after the item was already committed at the