First identify what changed. A local implementation choice, an observed defect, a stale description, an unresolved design question, a changed accepted commitment, and a new human priority require different responses. Record the affected statement or interface, candidate, observation, consequence, and proposed next step. Exercise ordinary discretion inside the brief. An explicit adopted choice, protected criterion, owner-held act, or material scope change needs its owning decision before reversal. WORKING_ITEMS · App selection and decisions · Piping decisions

Prepare human decisions as concrete reviewable packages. Explain the current basis, finding, alternatives, recommendation, affected scope, risks, reversibility, and what each choice enables. Include the proposed text or artifact when feasible. Name the actual act requested: choosing an interface, accepting an amendment, opening a fence, freezing a candidate, or authorizing release. Do not smuggle several different acts into a generic “approve.” Preserve the human's words and distinguish them from the agent's interpretation; silence is no ruling. Root entry · CONTRACT K-AUTH-1, K-BIND-1

For accepted decomposition change, use the selected applicable scope-change method. Its current package groups preparation around the requested change and impact, the exact amendment and propagation plan, and the independently examined poststate. Preserve stable identity and lineage. Apply only accepted changes, route remediation to the owners of affected surfaces, regenerate or explicitly account for derivatives, and return unresolved obligations. Use the project's adopted checkpoint edition rather than imposing a new one from this guide. Scope change · Decomposition standard

Follow consequences through consumers. An upstream amendment can affect local context, contracts, dependency records, graph snapshots, active briefs, and earlier verification. A graph helps locate relationships; it does not decide the impact. Under the invariant catalog, changed governed inputs create dirtiness and downstream staleness for human triage. Preserve earlier evidence as history and explain whether a current claim needs rework, review, or a supported no-impact disposition. CONTRACT K-STALE-1, K-STALE-2, K-VAL-1

Instruction changes need their own authorized scope and tranche manifest. A designated current-graph pointer update inside an authorized undertaking is navigation maintenance; changing loop behavior is an instruction amendment. Notify affected loops whose pinned authority corpus or mirrors are changed. A notice communicates a change; the receiver decides adoption and updates its own basis. Do not write sibling records or re-pin their contracts under a general desire for consistency. Root entry · Chirality change conventions

Keep ordinary pending work in its owning execution arrangement. Waiting for a review slot, input, or planned later node is not last-resort deferral. First seek an appropriate node in the current authorized undertaking or an identified owned successor. A material concern with neither home—because ownership, scope, or an external precursor remains unresolved—can be preserved as a conditional Task Management candidate. Name the affected commitment, source, failed allocation, responsible reconsideration, and condition that could give it a home. Human manual §5.6 · Task Management workflow

Apply the same eligibility during a substantive PR and the final closeout: route an actual allocation problem when found, and link its transfer or pending intake from the originating PR or graph node. The PR boundary or completion of a node creates no automatic intake, harvest, or register row. Existing owned work stays with its graph; invocation and register writes follow the actual Task Management contract and human disposition. Human manual §§1.10, 4.2, 5.6 · Task Management intake eligibility

Task Management makes concerns visible for human disposition and routes resulting work to its owner. An Action Item register does not replace a work graph, production contract, decision register or scope-change workflow, and has no execution-progress state. Recording an unallocated concern preserves the obligation without accepting it, reducing scope, setting priority authority, or changing lifecycle. An unfulfilled production obligation remains until fulfilled or changed by its owning authority. Task Management workflow · CONTRACT §1.14

Index the run without duplicating its decisions

Under the revised arrangement, add a terse entry near final PR preparation in each affected deliverable's MEMORY.md Runs table. Use a stable run ID and date, state the work performed in that deliverable, and link the PR, central evidence, applicable rulings, scope changes, and Task Management transfers. Include only applicable references. Decision substance and detailed rationale stay at their central sources; label a pending proposal or intake as pending. The table has no future-work queue. Human manual §§4.11, 5.6, 5.8

This illustrative shape follows the canonical MEMORY template, titled # MEMORY - {{DEL-ID}} with a ## Runs table. The accepted amendment replaces D-GOV-17 M4-A's minimum section for future entries only; its other dispositions remain. Preserve existing headings and entries. Use MEMORY.md for new authorized writes; legacy _MEMORY.md consolidation needs explicit scope and preserved links/history. While a PR URL is unavailable, use a stable run/branch link and bind the actual URL before final candidate checks. Do not assert a future merge SHA or require a later commit solely to record that merge. Accepted instruction amendment · SPEC §8 · App loop §5 · Piping loop §5

Select the bounded Task Management invocation

WORKING_ITEMS selects chirality-root:bundled:workflow:task-management directly with the invoking loop, purpose, authority and exact write boundary. No separate Task Management init prompt or retired role is needed. TASK may inspect bounded sources but never writes register rows or delegates. Promotion, disposition and external assignment remain actual human acts. Ordinary development has no standing sweep, service or register gate. Task Management workflow · Task Management contract

Establish federation before each requested mode. Survey canonical Git-tracked registers and closed-row archives across the sanctioned Root, project, domain and Domain Engine shapes. Validate inputs and derive relationships from governed fields such as ActionItemID, SourceRef, NoticeRef, ElevatedTo, Status and Disposition, not Notes prose. Present complete inventory, exclusions, integrity errors and COMPLETE or PARTIAL coverage. Partial evidence cannot support global absence or closure; unrelated development can continue. An unavailable helper requires equivalent read-only inspection with truthful limits. Task Management contract, entry and federation

The following is a template from the repository root. Omitting --out uses <register-home>/.candidates/federation.json. Authorize the destination and verify that it is Git-ignored before execution; the helper does not enforce ignoring. The derivative remains rebuildable and non-authoritative.

python3 tools/taskmgmt/taskmgmt.py federation \
  --register <invoking-loop-register.csv> --out <authorized-gitignored-path>

Assess supplied concerns without rediscovering a backlog. Intake requires material evidence, no reasonable route through current authorized work/investigation/decision/reconciliation/scope change, no identified successor or receiving owner already carrying it, and a missing allocation, decision or precursor. Use the undertaking rather than the session as the boundary. Cite a source already preserving the concern; otherwise retain one concise candidate note in the invoking Task Management home, such as intake/<concern>.md. An explicit execution finding can support intake, but graph nodes and memory are not mined for future assignments. Pending intake remains in its Task Management home, linked from the originating PR/node and closeout as applicable. Task Management contract, eligibility and capture

Retire legacy sources only under an explicit finite assignment. Bind the named census/list by revision and hash, then account for current additions, changed or removed entries, compound meanings and no-current-task markers. Preserve each original identity, meaning and evidence. Group proposed treatments with individually named exceptions and real destinations. Ordinary future requirements already preserved in governing scope need no invented graph node, register row or memory assignment. Apply actual human decisions, verify the destination, then remove only the authorized source entries. Missing decisions or destinations leave those entries intact. Preserve lifecycle/history and frozen inputs; the closed account becomes historical migration evidence rather than a second backlog. The App/Piping PR #855 censuses are named inputs to this separately authorized retirement, not complete project backlogs or instructions to delete entries. Task Management retirement contract and method · Task Management method · App notice · Piping notice

Keep register reviews inside the requested modes. A scoped harvest may inspect decisions, notices, review findings, hold concerns, packet questions/conflicts, TBD registers and explicitly named escalation records. The current helper implements only its listed structured classes; run-record markers, review-report sections, memory and per-document token scanning are not implemented. Inspect explicitly supplied concerns directly, or make a bounded manual supplement where the requested harvest includes unsupported sources. Report actual coverage. Compare cited source/evidence hashes for staleness and closure echoes without silently re-closing rows or editing source truth. Task Management method, helpers and limits

For selected deferred rows, examine their exact trigger against current evidence and report:

These classifications support human decisions; they authorize no execution or closure. When neither a supplied concern nor a review mode is given, show the local open-row position and relevant currency findings, then obtain the requested scope. Child-loop reviews followed by Root remain an optional human scheduling choice. Task Management method, register review

Record and route actual decisions. WORKING_ITEMS writes only the invoking loop's adopted register, preserving its schema, IDs, source/evidence identities and closure grounds. Proposals remain proposals until the human decides. Route implementation, investigation, deliverable amendment, scope change or external work through its actual owner and authority. A notice alone does not assign another loop or authorize a foreign register write. A concern can gain a home before its underlying obligation is fulfilled. Validate changed live/archive structure; archive already-closed rows only when requested or within the assignment. Task Management contract, ownership and resolution

Return one maintained result. Report exact register changes, their human basis, evidence, pending decisions and unresolved consequences. Keep the result at its Task Management home and return a pointer to the caller. Graph-led App/Piping closeout needs no new loop receipt or duplicate narrative. A different loop's explicitly retained receipt contract still applies; preserve historical receipts and their validation. Ending intake never completes an unmet requirement in the originating graph. Task Management contract, completion