Recover, hand off, and close an undertaking

Recover from the actual state before repeating work. Inspect the selected cursor, branch and worktrees, staged and unstaged changes, outputs, still-running workers, and shared resources. Determine what happened after the last recorded update. Preserve incomplete but useful work and verify its evidence. Establish that prior workers have stopped or explicitly transfer ownership before reassigning their files or application state. An interruption is not a reason to discard a partial result or report an unobserved test as failed. App loop §0 · Piping loop §0

If a pointer is missing or contradictory, search the pertinent records and history for the intended target. Do not select a convenient alternative until its relationship to the undertaking is established. If a selected pinned method uses a historical receipt as its recovery cursor, follow its retained integrity checks. The following existing tools inspect the respective historical chains from the checkout; the revised App/Piping loop does not impose them on every graph continuation:

python3 tools/validation/validate_app_dev_loop_receipts.py --repo-root .
python3 tools/validation/validate_piping_loop_receipts.py --repo-root .

A cursor failing its required check cannot support reliance. Independently verified work can continue from a separate sound basis. Validation establishes structural evidence, not authentication of owner prose. PEC has its own live receipt-validation obligation; Runtime explicitly has no corresponding validator claim. App loop · Piping loop · PEC loop · Runtime loop

Use the existing continuation home. For App/Piping development, the current graph and linked results may already contain everything a successor needs; no separate handoff or receipt is required solely because a session ends. A selected formal workflow may still require a handoff, snapshot, or receipt. Runtime and PEC retain their own closeout contracts. Preserve the real method rather than adopting one universal documentation ritual. App instructions · Piping instructions · Runtime loop · PEC loop

A dependable continuation account identifies the intended result, checked revision, local or unmerged changes, accepted inputs, completed contributions, evidence, unresolved checks/findings, active operations and ownership, holds, next safe action, and rerun triggers. Link detail instead of copying it. Before retiring a temporary worktree, retain evidence and results at a location the successor can actually read. Do not point to a deleted output and call the work recoverable. Construct a local work graph §4 · Chirality change conventions

For an undertaking that has adopted the revised development arrangement, complete its promised work, the single planned documentation/governance closeout, and affected deliverable Runs entries; then complete final PR review, required checks and decisions, and merge. Its final merge ends that loop. A premerge candidate can truthfully say “ready for final merge” and cite the PR; Git or the PR service supplies the later merged fact. Earlier substantive merges remain intermediate results. Human manual §§4.11, 7

The revised App/Piping loops make final PR merge their terminal condition; an open required node, review hold or unmerged final PR leaves the undertaking open. The candidate records readiness and its PR URL. Verify the merged fact afterward through Git or the PR service without requiring another commit solely to record it. In-flight programs and Runtime/PEC retain their own accepted completion contracts. A changed completion scope needs its actual owning decision and surviving obligations. Deliverable commitments remain unfulfilled until evidence or an authorized amendment accounts for them; a deferred concern retains its owner and allocation condition. App loop §6 · Piping loop §6 · Construct a local work graph §§3–4

For delivery, identify the exact delivered candidate and applicable human approval, recipient, package, operating limits, and continuing responsibilities. Preserve the difference between build output, transmitted artifact, and accepted baseline. Safety-significant, contractual, and professional work remains subject to its domain authority. Chirality's professional-responsibility model reserves approval, issuance, signature, seal, and reliance decisions to the accountable human; an agent never claims those acts for itself. This manual does not establish jurisdiction-specific legal or code compliance. DIRECTIVE §3 · CONTRACT K-AUTH-1 · Human manual, chapter 6