Claim state freshness

wu:claim fetches the configured integration target before it validates the WU. It reads the WU spec from that fetched tracking ref and compares it with the local copy. When the local spec is missing or different, claim advances the primary local integration branch to the exact fetched commit using the governed fast-forward path. The refreshed checkout provides the current WU spec and board state for status and overlap validation, with no second fetch.

When the local checkout cannot advance

The governed fast-forward refuses if tracked local changes are present or local history has diverged from the fetched target. It also refuses when local main is ahead of the fetched target, even if that target is an ancestor. It leaves local files and refs in place and prints an actionable error that points to pnpm git:sync-main. Resolve the reported checkout condition with the normal governed workflow, then retry the claim. Claim does not overwrite local edits or authorize a divergent history update.

When the fetched WU spec already matches the local file, claim leaves local main as it is. If the spec is absent from both the local checkout and fetched target, normal WU preflight reports it missing. Existing local-only spec behavior remains unchanged when the fetched target has no copy of that spec.

This applies to the local worktree claim path. Local-only, no-push and cloud claim paths keep their existing behavior.

Recovering a pending legacy claim binding

If a legacy wu:repair --claim --integration-target attempt has only written its journal and trusted origin/main advances before the binding commit is published, the authenticated original holder can retry the same target after the repair re-proves the repository, destination, claim selectors, holder, lane evidence and current trusted policy. The old intent remains in the audit journal and is marked superseded before a fresh attempt is written. The retry does not change the original destination or silently refresh the policy pin.

An attempt with a published binding resumes only from its exact verified genesis. A marker, partial outcome, malformed or ambiguous journal, foreign or wrong-WU holder, changed selector or policy authority, broken ancestry, or evidence that publication began prevents supersession. --check stays read-only. After a successful binding upgrade, the holder must rebase, create a fresh brief and run prep again because the prior evidence is invalidated.

The history proof validates complete ledger snapshots and compares the target WU’s raw event rows in order. It can follow unrelated ledger compaction or remove-and-readd history when those target rows and the WU document stay byte-identical. A child-delegation row is accepted only as one append to an otherwise unchanged ledger and with exactly the native delegation fields. Removing, rewriting or reordering any event that references the target remains a refusal, even if a later commit restores it. The binding commit itself must append exactly the intended upgrade event to an otherwise byte-identical ledger prefix; it cannot combine unrelated compaction or extra events with the WU binding change.