wowbagger 0.1.0-alpha.9 → 0.5.0-beta.0

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.9
+npm install -g wowbagger@0.5.0-beta.0
 ```
 
-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.9` and core `contract_version: 5`.**
+`0.5.0-beta.0` and core `contract_version: 5`.**
 
-The distribution pin names the published `0.1.0-alpha.9` release; the cut that
+The distribution pin names the published `0.5.0-beta.0` 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,41 @@ 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.)
+
+Do not confuse that with a full journal. Exit 6
+`claim-store-unavailable` with reason `journal-capacity-exceeded` means the
+65,536-entry or 8,388,608-byte bound was reached before publication. State is
+unchanged and prior history stays intact. Do not upgrade, truncate, compact, or
+hand-edit the journal; no automatic recovery verb exists. Report the capacity
+refusal as the blocker. A real persistence failure remains
+`clock-floor-persistence-failed`, and uncertainty after an intent remains an
+outcome-unknown refusal.
+
+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
@@ -232,7 +282,9 @@ wowbagger patch      --ledger <dir> --input request.json --json
   with a `patch` that brings the successor under the bound.
 - `create` starts an empty ledger on schema version 2 and returns the selected
   version at `result.item.core.schema_version`. A non-empty schema-version-1
-  ledger stays on version 1 until its complete ledger is migrated.
+  ledger stays on version 1 until its complete ledger is migrated. The create
+  request name `extensions` is reserved for the patch container; name extension
+  members directly on `item`.
 - `transition` changes **one** item. If the change would require touching a
   dependent or a child, it refuses. That refusal is correct — make it a
   reviewable multi-file Git change instead of forcing it.
@@ -294,21 +346,30 @@ and `number` is refused because it is immutable identity.
   are required, so a null one returns `candidate-invalid`, exit 2,
   `unchanged`. Use `[]` for a list; send the corrected string for a title.
 - `priority` takes a non-negative integer.
+- For an item whose status is `done`, `killed`, `archived`, or `deferred`, the
+  request date must equal the existing `updated` date for `patch`, `snooze`, and
+  `parent-migrate`. Inspect immediately before the mutation and reuse that date;
+  an earlier date fails the request floor and a later date violates the
+  terminal-date invariant.
 - Patch appends no decision; the Git diff is the audit trail. It never mutates
   a second item, and it cannot touch status or provenance.
 
 **Which fields are yours.** Do not discover this by sending a patch and reading
-the refusal — every frontmatter member is in exactly one of three classes:
+the refusal — every frontmatter member is in exactly one of four classes:
 
-- **Core-owned**, never yours: `schema_version`, `id`, `number`, `status`,
-  `created`, `updated`, the terminal dates (`completed`, `killed`, `archived`,
-  `deferred`), and `decisions`. `transition` writes these; nothing else does.
+- **Core-owned**, never directly editable: `schema_version`, `id`, `number`,
+  `status`, `created`, `updated`, the terminal dates (`completed`, `killed`,
+  `archived`, `deferred`), and `decisions`. The core derives these through
+  lifecycle and mutation commands; `patch` cannot name them.
 - **Consumer-editable through `patch`**: `title`, `priority`, `depends_on`,
   `related`, the body, and every extension member the ledger declares.
-- **Create-once**: `kind`, `provenance`, `parent`, `snoozed_until`. Set at
-  `create` and fixed after. `kind` is refused deliberately — a task-to-epic
-  flip changes which parent and children rules apply and which lifecycle edges
-  are allowed, so it needs its own verb, not a wider `set`.
+- **Dedicated mutations**: use `parent-migrate` to repoint an existing item to
+  an epic or detach it, and use `snooze` to set or clear `snoozed_until`. Both
+  use exact-revision compare-and-swap and accept `--auto-commit`.
+- **Create-once**: `kind` and `provenance`. `kind` is refused deliberately — a
+  task-to-epic flip changes which parent and children rules apply and which
+  lifecycle edges are allowed, so it needs its own future verb, not a wider
+  `set`. Provenance remains byte-identical after create.
 
 **Extension members are patchable only where the ledger declares them.**
 `tags`, `tier`, and a consumer's own identifier fields are consumer-owned. Send
@@ -407,17 +468,26 @@ On a **provisioned** ledger (`claim capabilities` reports
 ```sh
 wowbagger create --ledger <dir> --input request.json --json
 git add <dir> && git commit -m "Record the mutation"
-wowbagger claim-verify --ledger <dir> --json
+wowbagger claim-verify --ledger <dir> --id <item> --json
 wowbagger transition --ledger <dir> --input next.json --json
 ```
 
-The claim store validates every recorded mutation against Git `HEAD`, never
-against working-tree bytes — that is what makes a mutation durable rather than
-a local edit. So an uncommitted mutation blocks the next one. Skip the commit
-and the next `create`, `transition`, `patch`, or `publish-claimed` returns
-exit 6 `claim-store-unavailable` with
-`details.reason: "publication-reconciliation-required"`. `state` is
-`unchanged`, so nothing was written.
+The claim store reconciles every recorded mutation with Git `HEAD` and the
+working tree. It refuses the next mutation when it finds an
+`unauthorized-revision`, requires Git finalization, or requires synchronization
+for the target item. A synchronization finding on an unrelated item remains
+visible to targeted `claim-verify` without blocking that item.
+
+One exact window is nonblocking: an existing item's latest authorized
+working-tree bytes with an earlier authorized revision at `HEAD`. That
+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
@@ -425,30 +495,60 @@ what each finding's `remediation` string says (it names the path), run
 `claim-verify` until it exits 0, then repeat the refused command. Never hand-
 edit a ledger file to get past it.
 
-For migrated ledgers, run the explicit extension declaration workflow before
-managed corrections:
+For an existing ledger, bootstrap patch authority before managed corrections.
+For standard tags, `declaration.json` is:
+
+```json
+{"members":{"tags":"string-list"}}
+```
+
+Review the proposal, then publish the same declaration:
 
 ```sh
 wowbagger extensions-provision --ledger <dir> --input declaration.json --json --dry-run
 wowbagger extensions-provision --ledger <dir> --input declaration.json --json
 ```
 
-The request must name each member and one supported type explicitly. The core
-validates that every selected member exists across the complete ledger with the
-declared type; it never infers authority from one item. Commit the generated
-`.wowbagger/extensions.json` before the first `patch` that uses those members.
+The request names every selected member and type explicitly. The core requires
+a valid complete ledger, validates every occurrence of each selected member,
+and reports occurrence counts; a member need not appear on every item, but it
+must appear at least once. Dry-run writes nothing. Publication creates one
+canonical declaration without changing item bytes and refuses to overwrite a
+different declaration. Commit only `.wowbagger/extensions.json`, inspect the
+target again, then patch `set.extensions.tags`. A YAML anchor or alias on that
+item still refuses `extension-anchored`.
 
-To detach or reparent a live child without recreating its identity, use the
+To detach or reparent an item without recreating its identity, use the
 CAS-fenced relation migration:
 
 ```sh
 wowbagger parent-migrate --ledger <dir> --input relation.json --json [--auto-commit]
 ```
 
-Request must carry `id`, `expected_revision`, `expected_parent`, `parent` (or
-`null`), and `date`. The complete ledger validates the old and new parent
+The parent-migrate request is:
+
+```json
+{"id":"wb_...","expected_revision":"sha256:...","expected_parent":"wb_...","parent":null,"date":"YYYY-MM-DD"}
+```
+
+Every member is required; `expected_parent` and `parent` may be `null`. Inspect
+immediately before sending it. The complete ledger validates old and new parent
 accounting before publication.
 
+Set or clear a snooze date with:
+
+```sh
+wowbagger snooze --ledger <dir> --input snooze.json --json [--auto-commit]
+```
+
+The snooze request is:
+
+```json
+{"id":"wb_...","expected_revision":"sha256:...","snoozed_until":"YYYY-MM-DD","date":"YYYY-MM-DD"}
+```
+
+Use `snoozed_until: null` to clear it. Every member is required.
+
 Successful mutation responses also return `result.changed_paths`: the exact
 ledger-relative paths changed by that invocation. Use this set for manual
 staging; never broaden it to `git add <ledger>` and never treat it as proof of
@@ -456,23 +556,40 @@ 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. There is permanently no
+batch mutation in the direct-Markdown architecture. The create-then-commit loop,
+implemented most briefly as serial `create --auto-commit` calls, is the
+supported bulk path. Ledger item #186 records this permanent decision. Run calls in
+request order and do not start the next until the previous result or recovery
+is final.
 
 ### Or use --auto-commit and let one invocation do it
 
 On a provisioned ledger, `--auto-commit` performs that whole loop inside one
-invocation. It is accepted on `create`, `transition`, `patch`, and
-`publish-claimed`, once each, and only with the flag present — there is no
-setting that turns it on for you.
+invocation. It is accepted on `create`, `transition`, `parent-migrate`, `snooze`,
+`patch`, and `publish-claimed`, once each, and only with the flag present — there
+is no setting that turns it on for you.
 
 ```sh
 wowbagger transition --ledger <dir> --input next.json --json --auto-commit
 ```
 
-One flagged invocation refuses if anything is staged anywhere or any 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.
+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 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
+`claim-verify` without turning a successful mutation into failure. If claim
+verification refuses, the result preserves `claim_verify_code` and
+`claim_verify_reason`; only `claim-store-locked` is retryable.
+
 Success adds `git_commit`, `commit_paths`, and `claim_verified` to `result`.
 
 Say these limits plainly when you use it:
@@ -535,7 +652,7 @@ wowbagger provision --ledger <dir> --json
 wowbagger claim capabilities --ledger <dir> --json
 wowbagger claim read|acquire|renew|release --ledger <dir> --input request.json --json
 wowbagger publish-claimed --ledger <dir> --input request.json --json [--auto-commit]
-wowbagger claim-verify --ledger <dir> --json
+wowbagger claim-verify --ledger <dir> [--id <item>] --json
 wowbagger claim-sync --ledger <dir> --json
 wowbagger claim-merge-verify --ledger <dir> --base <ref> --head <ref> --json
 ```
@@ -565,26 +682,84 @@ 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`, inspect reachable or dangling commits and use
-  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.
+
+**Choose verification scope deliberately.** Bare
+`claim-verify --ledger <dir> --json` is strict repository diagnosis: any
+blocking finding anywhere keeps it at exit 6. After working one item, use
+`claim-verify --ledger <dir> --id <item> --json`. It keeps every repository
+finding visible and marks each with `blocks_verification_scope`, but unrelated
+target-scoped findings do not fail that item's gate. Global barriers still
+fail every target. Never adopt or hand-edit a sibling's item to force either
+scope clean.
+
 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:
 
@@ -626,7 +801,7 @@ Use the claimed write path as one complete loop:
    not in an accessible Git checkout. Stop before mutation.
 2. Run `provision` once for the ledger. Keep its `ledger_namespace`.
 3. Run `claim capabilities --ledger <dir> --json` again. Require
-   `result.operations.work_claim.api_version: 2`. Do not compare the claim
+   `result.operations.work_claim.api_version: 3`. Do not compare the claim
    response's top-level `contract_version` with the core version; it is the
    legacy claim-envelope marker. Stop if the namespace is absent or the mode is
    not `merge-coordinated`.
@@ -638,12 +813,15 @@ Use the claimed write path as one complete loop:
    revision, the candidate bytes and digest, and the active claim fence. Never
    retry with only the operation ID; retry the complete request.
 8. Commit the item change, or merge the worker commit into the coordinating
-   branch. Do this now, not at the end of a batch — the next mutating command
-   refuses while this one is uncommitted.
-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.
+   branch. Do this now, not at the end of a batch. Acceptance of another command
+   does not prove this mutation is durable, and a blocking finding still
+   refuses that command.
+9. Run `claim-verify --ledger <dir> --id <item> --json` 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 block this item, so act on each blocking finding's
+   `remediation` and run it again. Unrelated nonblocking findings remain
+   visible for repository diagnosis.
 10. Release the claim with its current observed state.
 11. Run `validate` and show the resulting diff.
 
@@ -666,8 +844,11 @@ response envelopes, refusal precedence, and recovery rules.
 6. `validate`, then show the diff.
 7. On a provisioned ledger, commit the ledger change now:
    `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`, or `patch`.
+8. On a provisioned ledger, run
+   `claim-verify --ledger <dir> --id <item> --json` and require exit 0 before
+   the next `create`, `transition`, `parent-migrate`, `snooze`, `patch`, or
+   `publish-claimed`. Use bare verification separately for strict
+   repository-wide diagnosis.
 
 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/adapter/core-probe.js

@@ -19,10 +19,9 @@ export const CORE_COMMAND_ORDER = Object.freeze([
   'capabilities', 'create', 'inspect', 'patch', 'ready', 'transition', 'validate',
 ]);
 export const CORE_CONTRACT_VERSION = 5;
-// The work-claim API lives in its own version domain. It moved to 2 with the
-// item-source refusal that replaced publish-claimed's version 1 error for an
-// oversized candidate.
-export const WORK_CLAIM_API_VERSION = 2;
+// Work-claim API lives in its own version domain. Version 3 adds optional
+// target-scoped claim verification while preserving strict bare verification.
+export const WORK_CLAIM_API_VERSION = 3;
 // The report configuration versions this core accepts. Version 1 remains
 // supported unchanged; version 2 names views.
 export const REPORT_CONFIG_VERSIONS = Object.freeze([1, 2]);

package/src/adapter/process-outcome.js

@@ -18,6 +18,13 @@ const WOWBAGGER_ID = /^wb_[0-7][0-9A-HJKMNP-TV-Z]{25}$/;
 const NAMESPACE_ID = /^wbns_[a-f0-9]{32}$/;
 const CANONICAL_UINT64 = /^(0|[1-9][0-9]*)$/;
 const CONTROL_CHARACTER = /[\u0000-\u001F\u007F]/;
+const LOCK_OWNER_OPERATIONS = new Set([
+  'create',
+  'transition',
+  'parent-migrate',
+  'snooze',
+  'patch',
+]);
 const MESSAGES = Object.freeze({
   'mutation-outcome-unknown': 'The mutation may have been applied; inspect current state before retrying.',
   'output-limit-exceeded': 'The core output exceeded the requested bound.',
@@ -1133,7 +1140,7 @@ function validLockHeldDetails(value) {
     && hasExactMembers(value.owner, ['lock_version', 'item_id', 'operation', 'writer_id', 'started_at'])
     && value.owner.lock_version === 1
     && value.owner.item_id === value.id
-    && new Set(['create', 'transition', 'patch']).has(value.owner.operation)
+    && LOCK_OWNER_OPERATIONS.has(value.owner.operation)
     && typeof value.owner.writer_id === 'string'
     && /^[\x21-\x7e]{1,128}$/.test(value.owner.writer_id)
     && isCoreRfc3339Utc(value.owner.started_at);

package/src/claim-capabilities.js

@@ -2,7 +2,7 @@ export function resolveWorkClaimCapability({ gitCommonDir, namespace = null }) {
   if (!gitCommonDir) {
     return {
       supported: false,
-      api_version: 2,
+      api_version: 3,
       mode: 'advisory',
       claim_protected_publication: false,
       fencing_enforced_at: 'none',
@@ -12,7 +12,7 @@ export function resolveWorkClaimCapability({ gitCommonDir, namespace = null }) {
   if (!namespace) {
     return {
       supported: true,
-      api_version: 2,
+      api_version: 3,
       mode: 'advisory',
       claim_protected_publication: false,
       fencing_enforced_at: 'none',
@@ -21,7 +21,7 @@ export function resolveWorkClaimCapability({ gitCommonDir, namespace = null }) {
   }
   return {
     supported: true,
-    api_version: 2,
+    api_version: 3,
     mode: 'merge-coordinated',
     claim_protected_publication: true,
     fencing_enforced_at: 'git-history-reconciliation',