Lifecycle

LumenFlow separates initiative orchestration into six distinct concerns. Keeping them separate is what lets humans, local agents, and compatible remote orchestration surfaces drive the same initiative without re-deriving the rules.

1. Plan

Compute the logical-wave dependency graph. A WU’s logical wave is its shortest-path distance from any root, and it does not change unless the graph changes.

Inputs: initiative YAML, WU YAMLs, lane WIP limits.
Output: plan.json in the attempt bundle (see Artifact bundle).
Run it with pnpm orchestrate:initiative -i INIT-XXX --dry-run (no handoff files written).

2. Handoff

Record the intent to launch a WU. This is the step where the orchestrator produces one universal handoff artifact and writes a launch receipt tying that artifact to (initiative, logical_wave, launch_attempt, handoff_format). Capability-declared adapters may project that artifact for a compatible host, but do not create a separate lifecycle authority.

Prompt emission is not launch. The receipt in launch.json is the durable record; the prompt is adapter output.
wu:brief remains the canonical full handoff surface for a single WU. For an explicit cross-session continuation, its durable lifecycle receipt is carried unchanged as --handoff-receipt to wu:prep, wu:done, or wu:recover. The verifier binds the receipt to the WU, lane, owner, policy, protected WU payload, canonical repository/worktree, expected head and phase, operation, expiry, and one-use-per-operation audit sequence. It rejects changed, stale, replayed, or cross-context receipts; claim-auto does not issue one. A repeat wu:brief of an unchanged claim presents the receipt it already issued (the same scope and its original 24 h expiry; never one that was used, was issued more than 12 h ago or whose ref origin does not already hold) instead of minting another. Its published receipt is then already on origin, so the repeat brief makes one origin read and pushes nothing; any difference publishes and verifies exactly as a first brief does. Launch modes in orchestrate:initiative write the same client-shaped handoff artifacts into the bundle and print the artifact paths by default. When the WU carries an unresolved trajectory:* signal (see below), wu:brief renders a Trajectory redirect block above the acceptance criteria so a worker resuming from a brief sees the evidence before its first tool call.
Same user, any checkout, no receipt. The WU’s assigned_to user may run wu:prep and wu:done from any checkout, on any machine, in any session, including after the claiming session died. The authority is the claim on origin: your own git config user.email equals assigned_to, and refs/lumenflow/claims/<WU> exists on origin (the claim’s atomic push publishes it together with the lane branch). Fetch the lane branch, add a worktree for it, and finish the WU. If origin is unreachable, the identity differs, or the claim ref is gone, the command falls back to the receipt route. A receipt is required only when the WU is handed to a different user. A WU’s own session file is never accepted as the caller identity, and the remote lease does not gate prep or done. A fresh session of the same user runs wu:brief, wu:prep and wu:done with no receipt. When a receipt is used, wu:brief mints it after its own evidence commit, so it never invalidates itself, and every rejection prints its precise reason. For an active claim, wu:edit also accepts a fresh authenticated session bound to that WU when the caller is the assigned user and the live claim is still on origin. From main, wu:edit on an in-progress WU (description, notes and the sizing flags) builds its result from the WU at fresh origin/main, never from a stale local main or the claimed worktree’s older copy, and refuses with no write if the WU is no longer in progress or its claim changed. Other fields are edited from inside the claimed worktree. mem:checkpoint --wu <WU> records the authenticated caller session; --session cannot impersonate another session. Same-user wu:recover --action resume and wu:release are authorized for those actions alone. While the claim’s own session is still recorded on this host, resume never moves the claim to another session; once that session is proven dead, resume binds a fresh one (see the item after next). Other recovery actions and different-user handoffs retain their existing receipt checks.
Carrying the claim’s session to the next command. wu:claim mints the session that authenticates wu:brief, wu:edit, wu:prep and wu:done, but a command cannot export a variable into your shell. When your shell keeps no exports between commands (most agent shells), put the assignment the claim printed in front of each lifecycle command, for example LUMENFLOW_AGENT_SESSION="<id printed by wu:claim>" pnpm -C <worktree> wu:brief --id <WU>. The claim prints this for your host: one line on Linux and macOS, and labelled cmd.exe, PowerShell and Git Bash lines on Windows. wu:brief, wu:prep and wu:recover --action resume print their own next command already prefixed when the command was given a session. A refusal that finds no session for the WU (wu:edit, wu:brief, wu:done, receipt issuance and verification) says whether the variable is unset or not a live session of the WU and prints this remedy. Session files and WU records are never used as caller identity; the id must come from your own wu:claim output. Copying another claim’s id from a committed WU record is impersonation by a process with your OS user, which this handoff does not stop (that boundary is tracked separately).
Continuing a WU after its session dies. wu:rebase and the worktree claim binding compare the active session with the claim’s session, so a claim whose session died is continued from a fresh session in three steps: pnpm wu:brief --id <WU> from the main checkout (the receipt is addressed to the running session, and a session that does not hold the claim is never labelled the claim holder), then pnpm wu:recover --id <WU> --action resume --handoff-receipt <receipt>, which moves the claim’s session to yours on origin and in the worktree’s own record, then wu:rebase, wu:prep and wu:done in the worktree with no receipt. wu:rebase --handoff-receipt <receipt> is also accepted directly. The receipt’s issuer, owner, subject, scope, expiry, addressee and replay checks are unchanged. Re-run resume if it was interrupted; it is idempotent.
Resuming your own WU after its session died, for example after a reboot. Run pnpm wu:recover --id <WU> --action resume from the main checkout. No session needs to be exported, and no receipt or --override-owner is used. When the claim’s session is proven dead, your Git identity is the WU’s assigned_to, and the claim is live on origin, resume mints a fresh session through the same registration path as agent:session --resume, binds the claim to it, and leaves the worktree and its uncommitted files untouched. It then prints two commands in your shell’s own form: the LUMENFLOW_AGENT_SESSION assignment for the new session (export on Linux and macOS; the cmd.exe and PowerShell forms on Windows), and pnpm -C <worktree> wu:brief --id <WU>. wu:brief, wu:prep and wu:done accept the new session. A session that is active in the current boot, or a different user, is refused as before, and resume prints the reason first. A session is proven dead by one of three facts, never by elapsed time alone: its record is gone (a clean agent:session-end removes it), its record was last active before this host booted, or it declared an owner process when it was registered and that process has exited. A launcher that owns an agent’s lifetime (a headless worker host) declares it by exporting its own pid as LUMENFLOW_SESSION_OWNER_PID before the agent registers its session. The record then keeps that pid with its process start identity, so a reused pid or a reboot is told apart from the original process. A session that declared no owner process is never proven dead by a process check, and one whose owner process is still running is refused.
Resuming after a policy refresh. wu:recover --action resume reads the claim’s pin from the integration target. When wu:repair --claim --integration-target --refresh-policy has published its successor generation there but the lane’s own copy of the WU record is still behind it, resume verifies the successor, not the lane’s older copy, so it no longer refuses with “Trusted policy content changed since this claim pinned it”. wu:rebase and the dispatch heartbeat do the same: a lane whose claim record is a verified predecessor of the integration target’s (same WU, same lane branch, the canonical generation descends from it through the recorded refresh chain) is read through the integration target; any other mismatch still refuses. The refresh itself refuses before publishing when the claim worktree has uncommitted changes (so the lane sync cannot fail afterwards), syncs the registered lane worktree when run from the primary checkout, and after a failed sync names what is unfinished: fix the cause and re-run the same refresh command, which resumes.
Resuming from an un-synced checkout. Resume decides whether the retained lane was released from the canonical record on the integration target, not from the main checkout’s working tree, which wu:claim leaves untouched until you sync. A live claim is no longer refused as “released with its lane retained” because the checkout has not been synced yet.
Resuming a blocked WU after its session died. A claim you blocked with wu:block is still your claim, and its lane keeps in_progress by design, so wu:status shows it as blocked and prints the route out. When the session that held it has ended, run pnpm wu:recover --id <WU> --action resume from the main checkout. The same death proof, Git identity and live-origin-claim checks apply as above, and resume binds your fresh session to the blocked claim with one audited claim_rebind and leaves the status blocked. Run pnpm git:sync-main, export the printed session, then run pnpm wu:unblock --id <WU>. It accepts the assigned user’s session bound to the WU once the record’s holder session is proven dead, or is the session resume just bound. Then wu:rebase, wu:prep and wu:done run as usual. No --override-owner and no --action reset is part of this route; reset deletes the worktree and branch. A live holder session, or a different user, keeps the existing refusal. A block and its unblock are recorded in the claim history as one governed step of the same claim generation (exactly one block or unblock ledger event in the same commit as the status change), so wu:rebase and wu:prep keep reading the history after an unblock, including one done with --override-owner.
How a receipt is published. When wu:brief mints a receipt after its own evidence commit, it publishes the lane, the claim marker, the claim history and the durable receipt ref in one atomic push, each under an exact lease, and proves the publication with a single read of the remote afterwards: every ref must hold exactly the value pushed. A remote that rejects the push changes nothing, and a remote that accepts it yet drops or alters the receipt ref makes the brief refuse, naming what may be published and that the receipt must not be used. A rebind that lands while the brief runs is seen: the final issuer proof reads the remote live just before the push. There is no separate receipt push and no read-back fetch.
One holder binding. Every resume, with or without a receipt, ends with one lane commit that writes the claim’s new session, claim time and rebind chain into the lane’s own WU record, together with any checkpoint rows the ended session left uncommitted in the lane ledger. wu:rebase, wu:repair --claim --check, wu:prep and wu:done then read one record. Re-running resume completes a binding an interrupted run left unfinished.

Which route after a holder session dies. Each cell below is verified by a real-Git test that lands the WU. “Same user” means a fresh session of the assignee running wu:brief, wu:prep and wu:done with no receipt. Run wu:unblock before landing when the claim is blocked. A lane whose wu:done was interrupted keeps its record unbound until release and claim. A receipt hands over only what the canonical record publishes, so a claim whose spec carries wu:edit changes still local to its lane is continued by its assignee with resume instead.

Holder died after	Same user	`wu:recover --action resume`	Receipt (`--handoff-receipt`)	`wu:release --keep-branch`, then `wu:claim`
`wu:claim`	lands	lands	no receipt exists: use resume	lands
`wu:brief`	lands	lands	refused (`receipt_context_mismatch`) while the spec has unpublished `wu:edit` changes: use resume	lands
a refused lane push	lands	lands	no receipt exists: use resume	lands
`wu:block`	lands	lands	refused (`differs from the active claim`): use resume, then unblock	refused while the ended session’s ledger row is uncommitted: use resume
`wu:prep`	lands	lands	refused (`receipt_context_mismatch`) while the spec has unpublished `wu:edit` changes: use resume	lands
`wu:done`, before it published	refused (`INTERRUPTED_DONE`): use release, then claim	same	refused (`receipt_context_mismatch`): use release, then claim	lands

--print-handoffs replays the stored handoff artifacts inline when a human needs manual copy/paste output.
Clients that can spawn workers directly do so here; clients that cannot leave the handoff as a pending payload the human copies into their agent.

3. Execution

The worker claims the WU (wu:claim), runs wu:brief, implements the change, runs wu:prep, and completes via wu:done. Initiative supervision does not participate in this phase — it is pure lifecycle evidence, the same evidence any LumenFlow WU produces whether it came from an initiative or not. When a host wants LumenFlow to run one WU’s execution itself, it uses the direct worker mode below, which produces exactly the same evidence.

Every generated handoff — wu:brief, wu:delegate, and the launch artifacts this orchestration writes — renders that same two-step contract from one shared renderer and states it as the worker’s only completion authority: run wu:prep, then execute only the exact command it prints, from main. No generated handoff offers a competing path (raw gates plus a standalone verification command, a status poll with a hand-typed wu:done, or worker return) alongside it.

For local worktree and worktree-pr claims, claimed_branch is a durable binding rather than a branch-name hint. Remote-backed claims persist it in both canonical and worktree WU documents only after WU/lane/status/claim-time, owner, active session, configured-root realpath, current branch, exactly one Git worktree registration, and both active state ledgers agree. Local worktree claims using --no-push or git.requireRemote=false are refused before mutation because they cannot establish that dual-document authority; use branch-only mode for offline work. Branch-PR/cloud behavior remains unchanged.

Every wu:rebase path—including --dry-run, --continue, and --abort—and the first local-worktree wu:done preflight consume that binding. An explicit WU id cannot authorize an arbitrary custom branch. If the binding is absent, first run pnpm wu:repair --claim --id WU-XXX --check; remove --check only after reviewing the evidence. Repair fills absent fields only, rechecks both readbacks, remains retry-safe after a partial write, and refuses conflicts or inactive lifecycle state.

Command hook registration

Pack-owned lifecycle commands receive the same host hooks through CLI dispatch, bin commands, and the direct tool runners used by MCP and kernel tools. The host registers hooks on the executing pack module before calling its handler. This restores validation, preflight, escalation, capacity, lane, initiative and plan telemetry across those routes.

Escalation registers its telemetry callback together with delegated caller, review and gate verification ports. A missing delegated port still refuses resolution. These verification ports load their evidence dependencies only when used; ordinary commands and CLI help do not run those checks.

Direct tool runners use the shared registrar exported by the CLI library through the existing host compatibility adapter. Standalone pack execution without a visible CLI installation keeps optional telemetry unavailable; this bridge does not expand sandbox access or grant authority. No command flags or workspace settings are needed.

Direct worker mode (one WU)

pnpm orchestrate:initiative --worker WU-XXXX --adapter <embedded|subprocess> \
  --worker-handoff <file>

Runs ONE ready WU through a governed local worker adapter, independently of initiative supervision. It refuses every supervision option (--initiative, --dry-run, --progress, --checkpoint-per-wave, --no-checkpoint, --print-handoffs, --strict-preflight, --max-active-workers, --client), and the adapter is always explicit.

The host prepares the handoff. The trusted host claims the WU with the ordinary wu:claim (lane WIP and code-path overlap locks apply unchanged) plus --dispatch-key <key> --worker-id <id>, runs wu:brief, and writes the handoff file with the same two values. The claim records them atomically as claim_dispatch (both or neither, each a bounded host token); a release or a rolled-back claim clears it, and a claim without the flags records none. The handoff file holds the work-only assignment, the complete post-claim brief, the session and the trusted worker binding (brief digest, dispatch key, worker id, WU, canonical workspace root and initial head). It is host input, never model output; the file is read once, parsed strictly, bound to --worker and digested, and lease fields are refused. The brief must be complete: every contract marker once, in order, ending with the terminal sentinel, matching the binding’s digest.
Two adapters, one composition. embedded runs in process on the production persistent execution binding. subprocess launches a guarded child of the same built module with a fixed executable, argv and working directory (the canonical workspace root) and an allow-listed environment that never carries your session, receipt or acceptance variables. The child’s report counts only after it has closed with a valid protocol and names the requested WU and worker; it is never publication authority.
Refusals before any effect. An agent_runtime.models profile whose api_key_env or base_url_env names a reserved LumenFlow variable (session, handoff receipt, gate admission lineage, EULA acceptance or a licence file pointer, matched case-insensitively) is refused by name before the worker claims its local assignment lease, runs, spawns a child or sends a provider request; the host has already made the ordinary WU claim and written the brief. The worker needs the local tool-exec confinement envelope; today that is Linux with bubblewrap, and any other host refuses with a typed confinement error and starts nothing.
Resume. A fresh session of the same user resumes through its own live origin claim, never through a transferred session id, and only when that claim’s claim_dispatch equals the handoff’s dispatch key and worker id: a host that lost its claim acknowledgment adopts only its own claim, never another or an unattributed claim of the same user. Run the resumed host as the WU’s authenticated session (pnpm agent:session --wu <WU> --resume): the fresh wu:brief render refuses without it. Only an adopted run receives the complete fresh wu:brief render as a continuation message; the original brief and binding stay frozen.
Completion is publication, not a report. After the assignment is confirmed against its canonical protected record, the worker reaches completed only through: the independent-review state from the worker execution contract; the exact request derived from its own verified wu:prep evidence (candidate, prep result, the exact printed wu:done command and its working directory, and the verified destination); a host-only, one-use grant for exactly that request; a durable reservation; Done run once as its own process group; and a fresh destination requery that proves completion at the fetched tip. A grant comes only from a policy callback the embedding host retains, such as an explicit standing host policy, never from JSON, the model or the handoff, and a request that moved since the policy answered consumes nothing.
Typed waits. A run that neither completes nor fails stops at a typed wait recorded once on the existing canonical checkpoint event: worker_publication_approval_required (with a cause such as no_host_policy, policy_refused or capability_expired), worker_publication_review_required, worker_publication_review_state_unknown, publication_reserved_effect_pending, publication_outcome_unknown and done_effect_failed. The public command composes no host policy, so it stops at the approval wait. The destination is the claim’s pinned delivery remote and branch, proven by the same canonical claim loader wu:prep and wu:done use; a claim that cannot be proven (for example a legacy claim without an integration-target binding) waits with cause claim_integration_verification_unavailable until pnpm wu:repair --claim --integration-target binds it.
Exit codes and restart. 0 completed, 1 failed, 2 typed wait, 3 unknown outcome; a wait or unknown outcome is never reported as done. A cold restart first settles any retained publication record of the same identity through the destination requery, never by running Done again. After clearing a wait, run the same command again.
Concurrency. Each worker holds its own claim, worktree, session and binding, so several run at once; the mode adds no scheduler, and the claim’s WIP and overlap locks still refuse an unsafe extra claim.

Independent review (worker execution contract)

Every WU resolves to one worker execution contract: an effective independent-review mode, its source, its risk reasons and a digest over those resolved fields. The contract is computed, not written in prose, and the same resolution runs at three points: the worker’s final wu:prep, the pre-merge boundary inside wu:done, and the publication seam on whatever commit actually lands — re-checked after each auto-rebase and contention retry, on every landing route including branch-only, branch-PR and --already-merged recovery, where the merged lane commit is judged under the record as it stood before finalization. The generated brief shows it in a Worker Execution Contract block whose heading names the rollout stage — enforced for authored and legacy-floored requirements, observed (reported, not refused) for requirements the risk policy derived — deliberately distinct from the advisory Suggested Routing block above it.

The worker owns the whole lifecycle either way. A reviewer, when the contract asks for one, is read-only: they assess a candidate the worker froze, and they never complete the WU.

Independent review is opt-in, never on by default. Reviews are decided by the person or agent instructions running the WU. With no configuration, every WU with no explicit independent_review value resolves to none, P0 and safety-critical paths included. Two levers sit below the per-WU value and above that default:

A workspace can opt every such WU into the conservative risk policy (or require review by default) with software_delivery.independent_review.default_mode: auto|required|none in workspace.yaml (default none).

The per-WU independent_review field and the legacy requires_review: true floor still win over both.

Solo ad-hoc WU — no reviewer. The ordinary case. No configured workspace default or agent override, so an ordinary WU (P0 or not) resolves to none:

pnpm wu:review --id WU-XXXX --contract
# Independent review: none (authored auto, source workspace-default)
# Contract digest: <sha256>

pnpm wu:review --id WU-XXXX --review-status
# State: ready
# Next action: proceed

pnpm wu:prep --id WU-XXXX   # normal gates, no reviewer step
pnpm wu:done --id WU-XXXX   # exactly the command wu:prep printed

Nothing extra runs: no reviewer, no supervisor process, and no host attestation that was never requested.

--contract, --review-status and wu:status read the claimed WU’s effective spec: the record with your pending wu:edit changes projected on, the same spec wu:brief, wu:prep and wu:done enforce, so the mode and contract digest they print match those boundaries. --set-independent-review edits that same effective spec, so it changes only independent_review and never reverts other pending wu:edit changes.

Required review — request, record, then land. Either authored (--set-independent-review required), floored by a legacy requires_review: true, or derived by the risk policy:

# Author the policy (recorded through the governed edit path; the effective
# mode is still resolved, so an explicit none cannot weaken an active floor)
pnpm wu:review --id WU-XXXX --set-independent-review required

pnpm wu:review --id WU-XXXX --review-status
# State: awaiting-review
# Next action: request-independent-review

# The reviewer — a different principal, holding an externally signed,
# single-use grant — assesses the frozen candidate read-only and records:
pnpm wu:review --id WU-XXXX --record --verdict approved \
  --reviewer-session <id> --scope-key <key> --grant <token>

pnpm wu:review --id WU-XXXX --review-status
# State: complete
# Next action: proceed

pnpm wu:prep --id WU-XXXX
pnpm wu:done --id WU-XXXX

A changes-required verdict returns state changes-required and next action address-findings. The verdict binds to the exact candidate SHA and the contract digest: a material edit after the review asks for re-review-current-candidate, and a policy change that moves the digest invalidates the old evidence rather than carrying the approval forward. Missing, stale, wrong-WU, self-issued, negative and unsupported authority evidence all fail closed — advisory signals and prose certify nothing.

Enforcement is staged at launch. A requirement that was authored, carried over from a legacy requires_review: true floor, or produced by an unsupported policy value refuses the boundary. A requirement the risk policy derived on its own is reported in full — effective mode, refusal code, digest and next action — and refuses nothing, until reviewer grants are provisioned. Nothing is skipped or weakened in that stage: the effective mode stays required, no evidence is fabricated, and no per-run flag moves a WU between stages.

4. Reconciliation

Read the durable evidence and classify every WU into an orchestration state:

WU YAML status + .done stamps
Worktree presence on disk
Launch receipt from launch.json
Delegation registry pickup timestamp
Checkpoint + signal activity in shared memory
WU lease/session evidence and lane branch presence
Main-checkout contamination (from git status)
Stalled worktrees (no activity past the configured threshold)

Reconciliation is the heart of the control plane. The canonical @hellmai/lumenflow-packs-software-delivery pack ships a single classifier that the CLI and MCP tools share, so the answer is the same no matter which surface you look at. The historical @hellmai/lumenflow-initiatives package is a deprecated compatibility shell that forwards its published entrypoints to that pack.

orchestrate:monitor uses this same evidence before calling a delegation stuck. Stale rows for WUs that are already done or otherwise settled become reconciled stale results, while contradictory rows are surfaced as conflicts requiring recovery. A vendor/client/model label is never the lifecycle key.

Trajectory supervision

Reconciliation answers “is the agent alive?”. A separate, ledger-backed classifier answers a harder question: “is the agent getting anywhere?” orchestrate:monitor reads the per-gate gate_attempt ledger, lane-branch commits, and checkpoint/signal evidence for every active WU and classifies it as productive, slow, stagnating, thrashing, awaiting-wake, or unknown — with no wall-clock term: a WU can be classified stagnating minutes after claim if the ledger shows the same gate failing repeatedly with no diff change.

stagnating, thrashing, and awaiting-wake each emit one A2A signal (trajectory:stagnating, trajectory:thrashing, trajectory:awaiting-wake); two or more active WUs sharing one root cause emit a single trajectory:shared-failure signal instead of one per WU. orchestrate:monitor --recover lists a redirect suggestion for each — a copyable mem:signal --to <worker> --intent PROPOSE command and a wu:block alternative — beside the existing stuck-delegation suggestions. These are suggestions only: the classifier and --recover never call wu:block, delegation recovery, session termination, or re-dispatch on their own authority. See Trajectory Supervision for the full design.

5. Finish

Drive WUs that are ready_for_finish through wu:prep + wu:done. Completion semantics differ by claimed mode:

Worktree mode — wu:done succeeds, the .done stamp exists, the worktree is cleaned up. Binding evidence is re-attested immediately before completion and again before cleanup.
Branch-PR / cloud mode — wu:done creates a PR and the WU enters awaiting_merge; it becomes done only after the merge and wu:cleanup produce the terminal stamp.

wu:done is non-interactive: it never opens an editor, so it lands the same on a laptop, in a container, or under env -i with no EDITOR and TERM=dumb. If another machine lands code while it runs, it catches the main checkout up and rebuilds any stale built packages before its metadata commit, outside the merge lock, so the commit hooks never meet a stale build. If origin moves again in the seconds between, the landing is released with a named error and the rerun rebuilds first.

In worktree mode, wu:done first validates the effective spec and checks that its declared code_paths are committed. Only then does it append the native evidence for materializing pending edits. This lets a clean committed event ledger be part of the WU’s scope. Existing staged or unstaged changes to that ledger or another declared path still refuse before the evidence is appended. If a later step fails before the metadata commit, the existing rollback restores the prior ledger, metadata, user files and Git index.

Worker return is not completion. A subagent stopping, a delegation completing, or a prep-ready worktree showing up only mean the classifier now has stronger evidence.

Host guarantees the lifecycle depends on

Every phase above writes state and scaffolding, and those writes carry the same contract on Windows, macOS and Linux — satisfied by each host’s own native primitive rather than by exporting one host’s model to the others:

Safety and launch wrappers are native. scripts/safe-git ships with a scripts/safe-git.cmd companion enforcing the identical guards, and wu:brief --launch-script / wu:delegate emit both a .sh and a .cmd launch wrapper, advertising only the one this host can run. Needing Git Bash is not an acceptable native result.
Protected local state is owner-isolated. Gate-comparison artifacts and lifecycle mutation evidence are readable by the owning OS principal and no other, through a POSIX mode off Windows and a native access-control list that limits access to the file owner on it. If the boundary cannot be applied the operation refuses; it never silently succeeds having restricted nothing.
State writes replace atomically. Publishing a rewritten event log, a lifecycle receipt or an installed pack goes through one shared helper that retries a Windows open-handle failure within a bounded budget and, if that budget is exhausted, leaves the previous valid copy untouched.
Remediation text is pasteable where you are. An out-of-memory retry hint prints the POSIX environment-prefix form on Linux and macOS, and both the cmd.exe and PowerShell forms on Windows.
A reboot ends every claim’s processes, and LumenFlow knows it. Every lock and lease records the boot it was written in: the kernel boot id on Linux, the boot session UUID on macOS, and the boot time on Windows (with a 60-second tolerance for clock corrections). A record from an earlier boot is treated as dead at once, without checking the process. After a reboot, wu:release and wu:recover --action reset or --action restore ignore checkpoints, events and commits written before the boot, but only those that this host can prove it wrote itself. Proof comes from the local memory store, this host’s own lifecycle journals, the worktree’s reflog, and the writer stamp that each new ledger row carries: a random per-host id (never the hostname) and the boot the row was written in. The message says so (boot discount), and you need no 30-minute wait and no --override-owner. Evidence that came in through Git from another machine is never ignored, because a successor working the same WU on another machine may still be alive. That evidence still blocks for up to 30 minutes, exactly as before. So does a ledger entry written by an older LumenFlow build, which carries no stamp and has no local record. Uncommitted files in the worktree still block, because they are data. A session that is alive in the current boot is refused exactly as before. LumenFlow reads the boot identity at most once per command. If the boot identity cannot be read, the earlier rules apply. Windows Fast Startup resumes the system rather than booting it, so it does not count as a reboot. A copied host configuration directory carries its host id to the copy; delete the copy’s host-id file to give it a new one.

6. Status

Project the reconciled truth to humans, agents, and remote surfaces:

Stdout — concise human summary + next-step commands.
Launch stdout — wave summary, artifact bundle paths, and per-WU handoff file paths by default; --print-handoffs replays stored handoffs inline.
--json — authoritative machine-readable state for agents and remote launchers.
Artifact bundle — durable files for resume, audit, and adapter generation.
Capability-declared adapter projections — optional host-specific views on top of the control-plane contract; they do not alter lifecycle authority.

Every surface answers the same question: what is the next safe action for this initiative?

State machine — the vocabulary this lifecycle produces.
Artifact bundle — the durable files each phase writes.
Capacity + integrity — how reconciliation refuses to advance unsafely.
Trajectory Supervision — the productivity classifier behind orchestrate:monitor --recover’s redirect suggestions and wu:brief’s Trajectory redirect block.