wu:release

Release orphaned WU (in_progress to ready)

pnpm wu:release --id <wuId> --reason <reason>

Pending spec edits

Release carries pending authored wu:edit fields (including notes, code paths, acceptance and spec references) into the released record in the same release commit, on worktree and branch-PR paths. It reads the existing pending journal and legacy ledger in order and prints the fields carried over. Claim-managed fields are never replayed; raised escalation remains raise-only. An unappliable authored field refuses before remote lease release, interrupted-done unwind or record publication, listing every affected field. Re-record it as an ordinary spec field with pnpm wu:edit --id WU-XXXX, then rerun wu:release.

Interrupted wu:done

A wu:done stopped after it committed the done record on the lane branch but before landing leaves the lane branch saying done while the integration target still says in_progress. That lane holds unlanded work: wu:repair reports it as INTERRUPTED_DONE (never ORPHAN_WORKTREE_DONE), never auto-repairs it, and no orphan cleanup deletes a lane branch whose commits are not on the integration target. Every refusal of this state prints its one exit:

pnpm wu:release --id WU-XXXX --keep-branch --reason "<why>"
pnpm wu:claim --id WU-XXXX --lane "<lane>"
pnpm wu:rebase --id WU-XXXX

then wu:prep and wu:done. The release backs the lane tip up to backup/<wu-id>-interrupted-done-<sha>, removes only the unlanded done commit (what wu:done itself rolls back when a landing fails) and replays every later commit, so the reclaim continues ordinary retained work. Without --keep-branch the release refuses.

Releasing after a takeover

The successor-activity guard (30-minute window) ignores activity the releasing session itself recorded. A session the claim was handed to (a rotated agent:session --resume session, or one a takeover minted) counts as the holder once your Git identity and the live origin claim are proven, and the session named in the claim record counts as its predecessor. Commits, memory checkpoints and ledger events of those two sessions never block the release, so the takeover sequence needs no manual commit step; a ledger event recorded by any other session inside the window still blocks it, and so does a dirty worktree.

Stale-generation claim marker

A claim policy refresh whose publication failed (for example at a pre-push hook) leaves the remote marker refs/lumenflow/claims/<WU> at the previous generation while the local claim moved on. wu:release deletes that marker, and wu:claim replaces it, only on positive proof that it is not live: its generation is the newest in the claim generation history chain of the WU, it has the same repository identity and lane branch, and the canonical ledger records a claim of that generation by the same user followed by a release. The delete or the replacement leases the observed marker sha. A marker that cannot be proven (another user, history missing, no recorded release) is kept and the refusal names the marker generation, the claim generation, the missing evidence and the one next step.

Options:

Flag	Description	Required
`-i, --id <wuId>`	Work Unit ID. Required except on wu:create, which auto-generates the next sequential ID when omitted.	Yes
`-r, --reason <reason>`	Reason for action (required with —skip-gate, —override-owner)	Yes
`--override-owner`	Override ownership check (requires —reason)	No
`--keep-branch`	Retain the lane branch instead of deleting it (overrides wu_release.branch_action)	No

← Back to CLI Commands