wowbagger 0.1.0-alpha.13 → 0.1.0-alpha.17

package/schemas/ledger-repair-proposal.json

@@ -0,0 +1,170 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://github.com/lstutzman/wowbagger/schemas/ledger-repair-proposal.json",
+  "title": "number-repair-proposal result, ledger-repair version 1",
+  "description": "The `result` member of a successful `number-repair-proposal` response. The proposal is read-only: it reads the raw items of a ledger whose complete error set is duplicate numbers and computes the mapping that would repair it, writing nothing. The caller confirms or replaces `suggested_changes` and submits them as a `number-repair` request, which validates every witness again under the repair lock.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "ledger_snapshot_revision",
+    "duplicate_groups",
+    "items",
+    "suggested_changes",
+    "preserved_items",
+    "validation_errors"
+  ],
+  "properties": {
+    "ledger_snapshot_revision": {
+      "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/revision",
+      "description": "The digest over the complete relevant source bytes this proposal was computed from. A repair request replays it so a changed ledger is a conflict rather than a surprise."
+    },
+    "duplicate_groups": {
+      "type": "array",
+      "minItems": 1,
+      "description": "One entry per duplicated number, naming every item that carries it. A repair request must resolve every group.",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "number",
+          "item_ids"
+        ],
+        "properties": {
+          "number": {
+            "type": "integer",
+            "minimum": 1
+          },
+          "item_ids": {
+            "type": "array",
+            "minItems": 2,
+            "uniqueItems": true,
+            "items": {
+              "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+            }
+          }
+        }
+      }
+    },
+    "items": {
+      "type": "array",
+      "minItems": 1,
+      "description": "Every item in a duplicate group, with the configured path and exact source revision a repair request witnesses.",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "item_id",
+          "path",
+          "revision",
+          "number"
+        ],
+        "properties": {
+          "item_id": {
+            "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+          },
+          "path": {
+            "type": "string",
+            "minLength": 1,
+            "description": "The item's configured path, relative to the ledger directory."
+          },
+          "revision": {
+            "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/revision"
+          },
+          "number": {
+            "type": "integer",
+            "minimum": 1
+          }
+        }
+      }
+    },
+    "suggested_changes": {
+      "type": "array",
+      "minItems": 1,
+      "description": "The computed mapping, in the exact shape of the `changes` member of a number-repair request. Each group keeps the number on its lexicographically smallest ULID and moves the rest above the current maximum number.",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "item_id",
+          "expected_revision",
+          "expected_number",
+          "replacement_number"
+        ],
+        "properties": {
+          "item_id": {
+            "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+          },
+          "expected_revision": {
+            "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/revision"
+          },
+          "expected_number": {
+            "type": "integer",
+            "minimum": 1
+          },
+          "replacement_number": {
+            "type": "integer",
+            "minimum": 1
+          }
+        }
+      }
+    },
+    "preserved_items": {
+      "type": "array",
+      "minItems": 1,
+      "description": "Item IDs the proposal keeps at their current number.",
+      "uniqueItems": true,
+      "items": {
+        "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+      }
+    },
+    "references": {
+      "type": "array",
+      "description": "The affected items' relations, exactly as the source carries them. Relations are ULIDs, so a number repair preserves them; they are reported so a caller can confirm that nothing identity-bearing is being rewritten.",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "item_id",
+          "depends_on",
+          "related",
+          "parent"
+        ],
+        "properties": {
+          "item_id": {
+            "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+          },
+          "depends_on": {
+            "type": "array",
+            "items": {
+              "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+            }
+          },
+          "related": {
+            "type": "array",
+            "items": {
+              "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+            }
+          },
+          "parent": {
+            "oneOf": [
+              {
+                "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+              },
+              {
+                "type": "null"
+              }
+            ]
+          }
+        }
+      }
+    },
+    "validation_errors": {
+      "type": "array",
+      "minItems": 1,
+      "description": "The complete current validation errors. A proposal is produced only when every one of them is a duplicate-number error; any other error returns ledger-repair-not-applicable instead.",
+      "items": {
+        "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/validationError"
+      }
+    }
+  }
+}

package/schemas/ledger-repair-request.json

@@ -0,0 +1,61 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://github.com/lstutzman/wowbagger/schemas/ledger-repair-request.json",
+  "title": "number-repair request, ledger-repair version 1",
+  "description": "The strict JSON request `number-repair` reads from stdin or a host-created request file. One request covers the complete duplicate set: a partial mapping is refused, because moving one group cannot produce a valid complete ledger while another group remains. Each change carries the witnesses the apply path compares under the repair lock. `ledger-repair` is its own contract version, separate from the core contract version and the work-claim contract version.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": [
+    "repair_id",
+    "ledger_snapshot_revision",
+    "date",
+    "changes"
+  ],
+  "properties": {
+    "repair_id": {
+      "type": "string",
+      "pattern": "^nr_[0-9]{8}_[0-9]{4}$",
+      "description": "The bounded recovery key: `nr_`, the repair date, and a four-digit sequence within that date. An interrupted apply is resumed by this ID rather than retried blindly."
+    },
+    "ledger_snapshot_revision": {
+      "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/revision",
+      "description": "The complete-snapshot witness the proposal was computed against. A changed snapshot is a conflict, never a repair applied to bytes the caller never read."
+    },
+    "date": {
+      "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/isoDate"
+    },
+    "changes": {
+      "type": "array",
+      "minItems": 1,
+      "description": "One entry per moved item. No `item_id` repeats, because an item moves once, and no `replacement_number` repeats, because two items cannot land on one number. An empty list is an invalid request rather than a no-op.",
+      "items": {
+        "type": "object",
+        "additionalProperties": false,
+        "required": [
+          "item_id",
+          "expected_revision",
+          "expected_number",
+          "replacement_number"
+        ],
+        "properties": {
+          "item_id": {
+            "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/itemId"
+          },
+          "expected_revision": {
+            "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/revision"
+          },
+          "expected_number": {
+            "type": "integer",
+            "minimum": 1,
+            "description": "The number the item carries now, compared as an integer. It is a witness, not a label."
+          },
+          "replacement_number": {
+            "type": "integer",
+            "minimum": 1,
+            "description": "The number the item is moved to. The apply path refuses a collision with any item that is not being moved."
+          }
+        }
+      }
+    }
+  }
+}

package/schemas/ledger-repair-response.json

@@ -0,0 +1,90 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://github.com/lstutzman/wowbagger/schemas/ledger-repair-response.json",
+  "title": "ledger-repair responses, contract version 1",
+  "description": "Every `number-repair-proposal` and `number-repair` --json response. The root carries a `namespace` member: dispatch on `namespace` before reading any version field. `contract_version` is the repair domain's own version 1 — the core contract version and the work-claim contract version are separate and unchanged by it. A future change to the request or the repaired source shape requires a new repair contract version rather than a silent reinterpretation of version 1.",
+  "type": "object",
+  "oneOf": [
+    {
+      "title": "repair success",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "ok",
+        "namespace",
+        "command",
+        "contract_version",
+        "state",
+        "result"
+      ],
+      "properties": {
+        "ok": {
+          "const": true
+        },
+        "namespace": {
+          "const": "ledger-repair"
+        },
+        "command": {
+          "enum": [
+            "number-repair-proposal",
+            "number-repair"
+          ]
+        },
+        "contract_version": {
+          "const": 1
+        },
+        "state": {
+          "enum": [
+            "unchanged",
+            "committed"
+          ],
+          "description": "A proposal changes nothing, so it is always `unchanged`. An applied repair is `committed`."
+        },
+        "result": {
+          "type": "object",
+          "description": "The proposal result is the ledger-repair-proposal schema. The apply result names the repair ID, the snapshot it was applied against, the changed items, and the Git commit when one was established."
+        }
+      }
+    },
+    {
+      "title": "repair refusal",
+      "type": "object",
+      "additionalProperties": false,
+      "required": [
+        "ok",
+        "namespace",
+        "command",
+        "contract_version",
+        "state",
+        "error"
+      ],
+      "properties": {
+        "ok": {
+          "const": false
+        },
+        "namespace": {
+          "const": "ledger-repair"
+        },
+        "command": {
+          "enum": [
+            "number-repair-proposal",
+            "number-repair"
+          ]
+        },
+        "contract_version": {
+          "const": 1
+        },
+        "state": {
+          "enum": [
+            "unchanged",
+            "unknown"
+          ],
+          "description": "`unchanged` states that no ledger byte was written. `unknown` is reserved for an outcome this core could not resolve; it never accompanies a refusal raised before any write was attempted."
+        },
+        "error": {
+          "$ref": "https://github.com/lstutzman/wowbagger/schemas/common.json#/$defs/error"
+        }
+      }
+    }
+  ]
+}

package/skills/wowbagger/SKILL.md

@@ -14,14 +14,18 @@ publish something.
 Install the core separately before using this skill:
 
 ```sh
-npm install -g wowbagger@0.1.0-alpha.13
+npm install -g wowbagger@0.1.0-alpha.17
 ```
 
-The core requires Node.js 20 or later. This plugin ships only agent
+The core requires Node.js 24 or later. This plugin ships only agent
 instructions; it does not bundle the core, an MCP server, a remote service, a
 hook, or a background process. It operates on the ledger and its Git working
 copy through the core's validated CLI.
 
+The supported runtime matrix is Node 24.20.0. Node 26 remains excluded until
+the separate Vitest incompatibility reported by Lee is resolved; do not certify
+Node 26 based on ambient availability.
+
 ## Before anything else: check the core
 
 This skill does **not** bundle the wowbagger core. It drives an installed one,
@@ -34,9 +38,9 @@ wowbagger capabilities --json
 
 Read the plain distribution version from the first command and the top-level
 `contract_version` from the second. **This skill requires distribution version
-`0.1.0-alpha.13` and core `contract_version: 5`.**
+`0.1.0-alpha.17` and core `contract_version: 5`.**
 
-The distribution pin names the published `0.1.0-alpha.13` release; the cut that
+The distribution pin names the published `0.1.0-alpha.17` release; the cut that
 publishes core `contract_version: 5` moves it. Earlier cores report
 `contract_version: 3` or lower and lack behavior this skill requires, including
 the bounded item source, so the version check refuses them. Do not soften
@@ -63,6 +67,17 @@ either pin to make a check pass.
 Run both commands once per session before the first ledger command, not before
 every command.
 
+Run the read-only drift preflight before the first ledger mutation:
+
+```sh
+wowbagger version-drift --json
+```
+
+It compares the installed skill pin with the required distribution and core
+contract, then compares those requirements with the running core. If it refuses,
+do not mutate the ledger. Update the stale package, plugin cache, or linked
+checkout named by `result.error.details.provenance`, then rerun the preflight.
+
 You drive the core as an agent, through the commands below. A UI plugin or
 another non-agent consumer drives it as a process instead: absolute Node
 executable, absolute `wowbagger.js`, argument array, `shell: false`. If the
@@ -184,6 +199,32 @@ work read as ready.
   redaction and no access control. Say that plainly if a user asks for a report
   that hides work from a reader.
 
+## Every writer must be on the same core before the first create
+
+On a provisioned ledger, `create` now records its allocation in the shared
+claim journal before it publishes anything. That grammar is new, so the upgrade
+is a hard cutover with no automatic migration and no mixed-version grace
+period: **upgrade every writer in one Git coordination domain to the current
+core before the first alpha.14 create.** A worktree left on the old core does
+not write a duplicate — it stops making claim-protected mutations, which is the
+safe outcome, not a usable one.
+
+An old core cannot read the new create entry and says so badly. It answers
+exit 6, `error.code` `claim-store-unavailable`, message
+`The durable claim store is unavailable.`, and `error.details.reason`
+`claim-store-unreadable`, leaves state unchanged, and writes no item. Read that
+exact combination as **this repository was written by a newer Wowbagger;
+upgrade this worktree to continue**, and say so to the user: the old binary is
+immutable and can never print better guidance. (Item #185 is open for general
+version-drift detection.)
+
+Say what the fix does and does not cover. It closes the reported
+PropertyCompass2 collision: cooperating alpha.14 worktrees of one clone that
+share one Git common directory can no longer commit two items carrying the same
+number. Separate clones, separate machines, alpha.13 writers before the hard
+cutover, and noncooperating writes stay outside that fence and still rely on
+branch integration plus `validate`.
+
 ## Writing
 
 Every write is an explicit, reviewable Git change. Show the user the command
@@ -434,6 +475,11 @@ authorized predecessor/successor window produces no finding, so another
 mutation can run before the first is committed. Do not mistake acceptance for
 durability. Commit each mutation anyway, then run `claim-verify`.
 
+`create` never gets that window. A new item has no earlier authorized revision,
+so Git `HEAD` is the only place its authorized bytes can live, and an
+uncommitted create blocks every later mutation — including the next create —
+with `git-finalization-required`.
+
 **`claim-verify` is the reconciliation procedure for that refusal.** Do not go
 looking for another verb; there is none. Read `details.findings`, do exactly
 what each finding's `remediation` string says (it names the path), run
@@ -491,7 +537,10 @@ commit. With `--auto-commit`, `changed_paths` matches `commit_paths`, and
 `git_commit` proves the commit.
 
 Batch work is where this bites: filing ten items means ten commits, not one
-commit at the end. Tell the user that before starting a batch.
+commit at the end. Tell the user that before starting a batch. There is no
+batch mutation to reach for — the create-then-commit loop is the supported bulk
+pattern, and item #186 is open to design a safe batch create. `--auto-commit`
+on each `create` is the shortest form of that loop.
 
 ### Or use --auto-commit and let one invocation do it
 
@@ -508,9 +557,11 @@ One flagged invocation refuses if anything is staged anywhere or any foreign
 path under the ledger is dirty, reconciles, runs the mutation unchanged,
 commits exactly the changed item plus at most one
 `.wowbagger/reconcile-<namespace>.md` with a fixed subject, verifies that commit,
-and runs `claim-verify` before it answers. A command that owns the claim journal
-may rebuild only its derived reconciliation log during preflight. `create`
-remains strict, and every other dirty ledger path still refuses.
+and runs `claim-verify` before it answers. A successful `create --auto-commit`
+commits exactly two paths: the created item and that reconciliation log. Every
+command rebuilds its own derived reconciliation log during preflight, but
+`create` refuses a log that was already dirty when you invoked it, and every
+other dirty ledger path still refuses.
 
 Preflight and post-commit reconciliation block findings for the requested item.
 An unrelated `worktree-synchronization-required` finding remains visible to
@@ -610,29 +661,87 @@ envelope's `limits.cross_worktree_coordination: false` as permission to write
 with hostile or noncooperating tools — it only says the core never synchronizes
 checkouts.
 
-A recorded `transition`, `patch`, or claimed publication blocks mutations
-targeting that same item with exit 6 `claim-store-unavailable`, reason
-`publication-reconciliation-required`. An unrelated item mutation may proceed
-when the only finding is `worktree-synchronization-required`. `create` records
-nothing, so it never creates a publication block.
+A recorded `create`, `transition`, `patch`, or claimed publication blocks
+mutations targeting that same item with exit 6 `claim-store-unavailable`,
+reason `publication-reconciliation-required`. An unrelated item mutation may
+proceed when the only finding is `worktree-synchronization-required`.
+
+`create` is the one exception to that scoping, because it allocates the next
+number from the items this checkout can see. It also refuses when the journal
+records a committed item this worktree does not hold at all: that item carries
+a number nobody here can read, so the next number allocated here might already
+be taken. A stale revision of an item this worktree does hold is not a blocker
+for `create` — a number is immutable, so the local maximum is still right. The
+refusal is the same exit 6 `claim-store-unavailable` with reason
+`publication-reconciliation-required`, state `unchanged`, and no item file
+written; integrate the missing item, run `claim-verify` until it exits 0, and
+resend the same request, which then takes the next number.
+
+That fence stops new collisions; it does not repair old ones through core
+version 5 or claim operations. Existing duplicate numbers are item #182
+recovery work. Use the separate `ledger-repair` contract:
+`number-repair-proposal --ledger <dir> --json` is read-only and writes no item
+file; `number-repair --ledger <dir> --input <repair.json> --json` applies a
+reviewed complete mapping under the shared namespace fence. Number-only repair
+preserves ULID identities and relation values. Never hand-edit the ledger:
+arbitrary edits can damage IDs, paths, or references.
 
 Read `error.details.findings[0].reason` and act on the named item:
 
 - `git-finalization-required` — you wrote the item here and have not committed.
   Commit, then `claim-verify`.
-- `worktree-synchronization-required` — another worktree wrote the item. If the
+- `worktree-synchronization-required` — another worktree wrote the item.
+  `owner_ref` names an **active named worktree** and nothing else: it is always
+  the branch of a live worktree that carries the expected revision. If the
   finding names `owner_ref` and `owner_commit`, WAIT for that owner to publish,
-  then synchronize this checkout and run `claim-verify`. If it carries
-  `owner_unavailable: true`, follow its `remediation`: a revision that is not
-  yet reachable means WAIT for the owning worktree to commit, then synchronize;
-  only ownership that cannot be established from reachable refs calls for
-  inspecting reachable or dangling commits with explicit restore or
-  `claim-adopt`. Never merge unrelated live work.
+  then synchronize this checkout and run `claim-verify`. `owner_unavailable:
+  true` means no such worktree exists, and it covers three cases: the expected
+  revision is not reachable at all, a live sibling holds it on a detached
+  `HEAD`, or it is reachable only from a tag, a remote-tracking ref, or a
+  branch no worktree has checked out. Reachability is not ownership; a ref you
+  can see is not a worktree that can publish. Follow the `remediation`, which
+  separates those cases. A revision that is **not yet reachable** means WAIT for
+  the owning worktree to commit, then synchronize. A revision that is
+  **reachable in Git while no active named worktree owner is established** —
+  a tag, a remote-tracking ref, an unchecked-out branch, or a detached sibling
+  carries it — is not a wait at all: inspect that reachable history, then
+  restore the authorized bytes or use explicit `claim-adopt` after review.
+  Ownership that **cannot be established from reachable refs** — the item has
+  never existed in this checkout — calls for inspecting reachable or dangling
+  commits with the same explicit restore or `claim-adopt`. Never merge unrelated
+  live work.
 - `unauthorized-revision` — the item changed outside the protocol. Two remedies
   are explicit: **restore** the authorized revision and run `claim-verify` to
   discard the edit, or **adopt** the committed revision and run `claim-verify`
   to keep it. Ask before discarding reviewed work.
 
+Two live worktrees answering to one identity, or a worktree roster the
+coordinator could not finish reading, refuse before anything is classified.
+You get exit 6 `claim-store-unavailable`, reason `claim-store-unreadable`, with
+`error.details.identity_diagnostic`: `duplicate-worktree-identity` naming the
+`worktree_id` and `live_worktree_count`, or `worktree-enumeration-failed` with
+no further member. Auto-commit reports the same diagnostic inside
+`auto-commit-preflight-failed` with `retryable: false`. Neither is retryable
+and neither is yours to repair by editing files. Report the diagnostic verbatim,
+including the `worktree_id` and `live_worktree_count`: a duplicate means two
+live worktrees hold the same identity file, usually because a private Git
+directory was copied, and which worktree keeps the UUID is a person's decision.
+An enumeration failure means a registered worktree path could not be read. The
+identity itself is an opaque UUID a worktree writes once into its private Git
+directory. Never create, copy, or edit it.
+
+**`claim-verify` is repository-wide, and a clean mutation does not make it
+exit 0.** It names no target, so any blocking finding anywhere in the
+repository keeps it at exit 6 — including a finding on an item belonging to
+work you have nothing to do with. On a repository with live sibling worktrees
+you may commit every one of your own mutations and still never see
+`claim-verify` exit 0. That is current behavior; item #184 is open in triage to
+decide the supported verification surface. When the remaining findings all name
+items you are not working on, say so and stop; do not hand-edit an item, and do
+not run `claim-adopt` on a sibling's item to force exit 0. Adoption moves the
+coordinator's authorized revision and is not a way to silence someone else's
+finding.
+
 Adoption is per item and per revision explicit. Name the item and both
 revisions, take them from the finding, and commit the edited bytes first:
 
@@ -692,7 +801,9 @@ Use the claimed write path as one complete loop:
 9. Run `claim-verify` after the commit or merge. It finalizes the Git outcome,
    repairs response-loss cases, and reports later revision drift. Require exit
    0 before the next mutating command; exit 6 means findings remain, so act on
-   each `remediation` string and run it again.
+   each `remediation` string and run it again. If every remaining finding names
+   an item you are not working on, that is the repository-wide scope described
+   above, not a failure of your work: report it instead of forcing exit 0.
 10. Release the claim with its current observed state.
 11. Run `validate` and show the resulting diff.
 
@@ -717,7 +828,8 @@ response envelopes, refusal precedence, and recovery rules.
    `git add <dir> && git commit`.
 8. On a provisioned ledger, run `claim-verify --ledger <dir> --json` and
    require exit 0 before the next `create`, `transition`, `parent-migrate`,
-   `snooze`, `patch`, or `publish-claimed`.
+   `snooze`, `patch`, or `publish-claimed`. Findings that name only unrelated
+   items are repository-wide scope; report them rather than forcing exit 0.
 
 Write, commit, `claim-verify`, next write. The unclaimed loop obeys the same
 rule as the claimed one, because both run through the same coordinator. Steps 7

package/src/claim-coordinator.js

@@ -37,6 +37,12 @@ export async function withLegacyMutationFence(
   const capability = resolveWorkClaimCapability({ gitCommonDir, namespace });
   if (!capability.claim_protected_publication) return write();
 
+  // A create is the one mutation that reads an identity it was not given: it
+  // allocates the ledger's next number from the items this checkout holds. Its
+  // reconciliation therefore stays target-scoped like every other mutation, and
+  // gains one extra barrier below, for the coordinated items this working
+  // ledger cannot see at all.
+  const create = command === 'create-v1';
   const storePath = claimStorePath(gitCommonDir, namespace);
   const journalPath = claimJournalPath(gitCommonDir, namespace);
   let intent = null;
@@ -61,9 +67,15 @@ export async function withLegacyMutationFence(
         physicalNow: new Date().toISOString(),
         targetItemId: itemId,
         writeLogOnUnsafe: false,
-        writeLogWhenEmpty: command !== 'create-v1',
+        writeLogWhenEmpty: !create,
       });
-      if (reconciled.unsafe) {
+      // The extra create barrier promised above rides on the same refusal: a
+      // coordinated item this checkout does not hold carries a number nobody
+      // here can read, so the next number this create would allocate may be one
+      // a sibling worktree already published. A stale revision of an item that
+      // is present hides no number: an item's number is immutable, so target
+      // scoping above still lets that create through.
+      if (reconciled.unsafe || (create && reconciled.missingCoordinatedItems.length > 0)) {
         return claimStoreUnavailable(responseCommand, 'publication-reconciliation-required', {
           findings: reconciled.findings,
         });
@@ -75,7 +87,7 @@ export async function withLegacyMutationFence(
       const projected = [...reconciled.entries];
       const record = reconciled.state.claims.find((entry) => entry.item_id === itemId)
         ?? { item_id: itemId, last_epoch: '0', active: null };
-      const mustRefuse = command === 'create-v1'
+      const mustRefuse = create
         ? record.last_epoch !== '0'
         : record.active !== null && observedAt < record.active.expires_at;
       if (mustRefuse) return legacyRefusal(responseCommand, namespace, itemId, observedAt, record);
@@ -110,6 +122,7 @@ export async function withLegacyMutationFence(
           attempt_id: attemptId,
           ledger_namespace: namespace,
           item_id: itemId,
+          ...(create ? { command } : {}),
           observed_revision: expectedRevision,
           observed_at: observedAt,
         };
@@ -180,6 +193,7 @@ export async function withLegacyMutationFence(
             attempt_id: intent.attempt_id,
             ledger_namespace: namespace,
             item_id: itemId,
+            ...(create ? { command } : {}),
             observed_revision: intent.expected_revision,
             observed_at: observedAt,
           }));