Imported from cyberAlchemyAI/Arcanum (arcana/task-session/SKILL.md). Install upstream with npx skills add cyberAlchemyAI/Arcanum --skill task-session. Copyright stays with the author.

Sigil: Task Session

Every user-facing Task Session terminal result must follow framework/OUTCOME-BRIEF-CONTRACT.md: lead with a short plain-language Outcome Brief, then state Boundary and Next Decision, and only then present the existing detailed Task Session result and any Decision Gate result.

The opening explains the objective, execution result, and why it matters without requiring the operator to decode receipts, admission fields, paths, or internal status identifiers. The boundary explicitly states what changed, what did not, remaining uncertainty, the exact user decision if one exists, and the next bounded action. This human projection does not alter terminal receipts, closeout evidence, authority, promotion, publication, or runtime state.

• there is one explicit task to execute,
• a no-argument invocation should resume one uniquely nearest, evidence-backed SWU from current-session or repository-local continuity evidence,
• the task has dependencies, deliverables, or done criteria,
• implementation choices need visible trade-offs,
• gate failures must stop mutation,
• the task record should be synchronized with evidence after completion.

• explicit task reference or task file,
• task objective,
• dependency list,
• implementation checklist,
• deliverables,
• done criteria,
• done-criterion and validation-obligation criticality when already classified; unclassified obligations fail closed as acceptance-critical,
• relevant constraints,
• validation commands or accepted substitutes,
• optional WORK-PACK.md with task board, SWU manifest, waves, and task contracts,
• optional runtime adapter selection from the installed repository command context.
• optional lifecycle owner and experiment harness path when executing spell or sigil development work.
• optional previous terminal receipt and continuation receipt for repeated-block and cycle detection.
• optional exact continuation authorization evidence from the current user request or a durable approval artifact.
• closeout synchronization target inventory, baseline identities or digests, and validation commands when the task or work-pack already declares them.
• closeout source-receipt contract and expected owner-receipt contract when execution will require evidence, status, route, work-pack, checklist, Dispatch, registry, or declared Craft projection synchronization.
• optional explicit series intent such as --until-blocker, all until blocker, all SWUs, one go, or an equivalent request to traverse one ordered work-pack stream.
• optional native runtime session id, visible-session selector, or repository-local Task Session continuity cursor.

0a. Before selecting one task/SWU, detect explicit series intent from the --until-blocker flag or equivalent current user wording. 0b. Resolve the exact work-pack scope and route it to the installed task-session-until-blocker spell. Pass the stop condition, captured work-pack identity, runtime selector, and current approval boundary. 0c. Stop direct Task Session execution after the handoff. If the spell is missing or the work-pack scope is ambiguous, return BLOCK with that exact gap. Never silently narrow series intent to one SWU and never place several SWUs in one Task Session receipt.

Step 1 - Resolve Task Scope

1. Resolve exactly one target task. Explicit user selectors, --from, to <target>, --task, and --swu always outrank automatic discovery.
2. With no positional target or selector, enter resume-nearest mode and cap execution at one task or SWU.
3. In resume-nearest mode, rank selectors lexicographically in this order: visible current-session context, the exact current native-session continuity cursor (or --session override), the nearest ancestor WORK-PACK.md from the current working directory, then uniquely scope-matched repository-local Task Session continuity.
4. Visible current-session context means the active prompt/session evidence supplied by the runtime. When older conversational content is not available because of compaction, use the durable cursor; never claim access to lost tokens or crawl unscoped user transcripts.
5. Resolve durable cursors from .arcanum/task-session/continuity/<session-or-scope-id>.json using continuity.schema.json. A cursor is selector evidence, not task-readiness authority.
6. Use scripts/resolve-nearest-swu.py when deterministic filesystem resolution is available. --list-nearest returns its ranked candidates and stops before context building or mutation.
7. Reject stale or scope-escaping cursors, non-Task-Session next routes, global-latest telemetry, fuzzy relevance, and cross-project inference. If the highest-priority tier contains multiple candidates, return BLOCK with the ranked candidates and the smallest disambiguation.
8. Re-read the selected live work pack and prove that the candidate exists, is not complete, is selected or the unique next-ready unit, has satisfied dependencies and blockers, and declares write scope, done criteria, and a validation surface. If any check fails, return BLOCK; never fall through to a lower-priority candidate silently.
9. Parse the task objective, dependencies, deliverables, write scope, done criteria, validation surface, and related artifacts that may need synchronization after completion.

Step 2 - Build Context Pack

For an exact Work-Pack-bound execution request, first run scripts/classify-fast-execution-entry.py after resolving the policy, selected unit, execution binding, and execution-entry projection, but before entering Context Builder. The guard reads exactly those four logical inputs in one entry-guard phase. task-ready proceeds to the ordinary Context Builder path; owner-prerequisite returns the exact bound owner packet to the outer loop with no authorization prompt; every other result blocks. A route-owner or block result must leave Context Builder, deep material inspection, mutation admission, target hashing/mutation, and owner dispatch unentered. The guard itself performs zero target mutations and never converts a stop into another authorization question.

For task-ready, persist the exact fast-entry request and receipt and carry both references into the governance runner's work-pack-fast-entry profile. The runner must revalidate the receipt against the original request before it may bypass the legacy prose-selected-row check. It must then bind the Work Pack path, selected SWU, Task Session route, route write scope, expected terminal receipt, plan selection, and single-use admission. A path-only receipt or a receipt detached from its four logical inputs returns BLOCK before run-state writes.

When the bound route also carries lifecycle synchronization and closeout scopes that are intentionally outside the executor admission, use the optional task-session.fast-entry-route-scope-partition.v1 contract. It must partition the exact route scope into executor writes, one exact terminal receipt, and typed lifecycle-owner scopes. The normalized union must equal the bound route, the partitions must be disjoint, executor writes must still close two-way against admission, and every lifecycle scope must name its owner and closed write class. Requests without this opt-in contract retain the legacy exact route-to-executor closure rule.

When actual preparation will persist repository-local control evidence, require the additional task-session.live-control-evidence-partition.v1 opt-in before the first such write. Keep it control-only and enumerate every exact readiness, selection, fast-entry, context, admission, governance, ticket, ledger, reconciliation, commit-evidence, and preparation-receipt output with its owner, write class, attempt, absent baseline, and expected postimage when known. Its normalized union must be disjoint from material, executor, terminal, lifecycle-owner, transient, and run-directory scopes.

Enter that route only through scripts/prepare_live_execution_entry.py. The coordinator must validate the canonical emitted request and exact accepted ACCEPT-{request_id}-{request_digest} response, one-attempt authority ceiling, all absent live baselines, and every versioned invocation input closure before any producer writes. Re-derive each task-session.invocation-input-closure.v1 from its declared owner-package roots and explicit exact cross-package refs; block missing, stale, or extra files. Execute producers in exact-input isolated transactions and atomically materialize only declared postimages after a fresh live-baseline check. Models do not hand-author those control outputs.

When a deliberate or real failure occurs before admission, use the bound task-session.pre-execution-failure-terminalization.v1 profile rather than a successful closeout schema. Its Task Session terminal, Invoke owner-block, and continuity receipts must preserve the accepted request/response, task, SWU, attempt, exact present control subset, schema identities, and canonical blocker fingerprint while explicitly claiming zero admission, ticket, execution, reconciliation, commit, successful owner closeout, material, external, selection, or successor effect. Do not weaken or reinterpret the successful precloseout/terminal contracts.

9a. After exact task/SWU resolution and before Context Builder, classify any declared PreExecutionOwnerPrerequisite with scripts/classify-pre-execution-prerequisite.py. Read only the selected work pack, selected unit, prerequisite record, referenced satisfaction receipt, and separately traced current-request control evidence. 9b. A satisfied or plan-once-ready result permits the normal Context Builder entry. An unmet result without exact authorization fast-blocks with Context Builder, implementation inspection, target hashing, mutation admission, and target mutation all unentered. 9c. For one exactly authorized unmet prerequisite, route through Continuation Router's pre-execution-prerequisite phase. Require its separate, current, digest-and-size-bound owner receipt and a fully bound same-attempt control handle. Task Session does not perform or impersonate the owner's work. 9d. Before resuming, match route, task, SWU, attempt, prerequisite fingerprint, target inventory, structured validation contract, expected package, owner receipt schema, satisfaction predicate, resume point, one-hop budget, and allowed effect. Rehash every live target baseline after the owner hop. 9e. Atomically consume the attempt/fingerprint pair before resuming. Resume the same attempt exactly once at task-session:context-build; do not re-enter selector resolution and do not recursively invoke Task Session. A repeated or partially consumed pair, stale/tampered receipt, baseline drift, expanded package target, unsatisfied owner result, or unjoined helper returns BLOCK.

10. Run context-builder in lean or standard mode for the selected task/SWU.
11. Include the task contract, source links, architecture/spec references, work-pack row, dependency rows, blocker rows, write scope, done criteria, validation surface, and known repository conventions.
12. When --via runtime is set, request a runtime handoff pack from Context Builder, emitted as Markdown plus JSON/index and persisted under session/run evidence.
13. Extract hard constraints and cross-artifact obligations from the context pack before selecting an implementation path.
14. If linked context is missing, contradictory, stale, unsafe, too weak, missing write scope, missing validation, or lacks strict coverage for a runtime handoff, return BLOCK with the missing context or contradiction and stop before mutation.
15. Record the context pack summary, handoff artifact paths, strict coverage status, and the source artifacts that controlled execution.

Step 3 - Build Decision Pack

16. Enumerate unresolved task decisions with more than one viable option.
17. For each decision, build option cards with:

• what the option entails,
• short-term consequence,
• long-term consequence,
• speed impact,
• complexity impact,
• risk impact,
• maintenance impact,
• recommended option with rationale.

18. Classify each decision as blocker, deferrable, or assumption. Independently classify the proposed choice as consequential or nonconsequential and as reversible or irreversible.
19. Ask the user to choose each blocker decision when the blocker is discovered before mutation.
20. If --auto is provided, auto-select only an option explicitly classified both nonconsequential and reversible. Otherwise ask when interactive or return BLOCK in unattended auto mode, and record the missing or disqualifying classification.
21. If a blocker-level decision remains unresolved and consequential work cannot proceed, invoke decision-gate before returning BLOCK; include the exact context, option cards, recommendation, and decision artifact path in the task-session report.

Step 4 - Evaluate Gates

22. Check task dependencies, stated constraints, required approvals, source links, context-pack obligations, strict handoff coverage when applicable, write scope, and available validation paths.
23. If a blocker exists because a human approval, policy choice, destructive cleanup, irreversible mutation, cost/risk acceptance, or rollout option is unresolved, run decision-gate for that blocker before continuing to Step 4A or returning BLOCK.
24. If a blocker exists for missing evidence, missing files, unavailable tools, or contradictory context with no meaningful user option, preserve BLOCK, record exact unblock actions, and continue only to Step 4A when a terminal owner handoff can be formed. Stop mutation inside the selected task, then continue to Step 8 for required closeout synchronization.
25. If the task can proceed with assumptions, record those assumptions before mutation. 25a. When a passing terminal receipt would require closeout synchronization, run the closeout prerequisite preflight before mutation admission. Require the declared target inventory, live baseline identities or exact digests, source-receipt contract, owner validation commands, expected owner-receipt contract, admitted delta classes, and unique-successor policy. 25b. Persist the preflight result with the controlling work-pack identity and current target baselines. Missing, ambiguous, stale, expanded, or forbidden closeout inputs return BLOCK before implementation writes and before owner dispatch. 25c. This preflight proves only that a later terminal result can be synchronized within declared bounds. The actual typed deltas, source receipt, owner dispatch, joined receipt, and cursor remain Step 8 obligations.

Step 4A - Resolve One Terminal Continuation

26. When the gate is terminal, emit a normalized continuation handoff containing the source result, receipt path, target scope, blocker class, controlling evidence identities or digests, blocker fingerprint, explicit next-route advice, and unblock actions.
27. Preserve this handoff for Step 8 closeout synchronization. Do not return before the closeout-sync decision is complete.
28. For continuation beyond synchronization, invoke continuation-router to expose one to three probable routes. Do not re-enter Task Session when the same blocker fingerprint and source evidence are unchanged.
29. Without --follow-next-route, do not dispatch the optional non-closeout route. This does not disable required Step 8 closeout synchronization.
30. With --follow-next-route, pass the exact --authorize-route tuple and current approval evidence to Continuation Router only after closeout synchronization. It may dispatch at most one non-closeout owner route and must run that owner's own gates.
31. Preserve the Task Session source result even when either owner route succeeds. Every owner returns a separate receipt and next route; Task Session must not recursively execute it.
32. Treat an ambiguous optional route, missing optional-route authorization, cycle, owner validation failure, or unjoined helper as BLOCK and report the exact missing condition.

Step 5 - Select Runtime

33. Resolve the current repository runtime from the installed command context or --runtime.
34. If --via runtime is set, load the matching runtime adapter from arcana/task-session/runtime-adapters/.
35. For durable Arcanum runtime runs, use the runtime-handoff adapter and selected executor adapter such as native-skill, codex-skill, claude-skill, copilot-instructions, dry-run, or explicit legacy codex-exec.
36. If --via runtime is set and the session lacks a complete session-evidence handoff pack with Markdown plus JSON/index and strict coverage, return BLOCK.
37. If the adapter cannot safely produce a runtime command, return BLOCK with the exact missing field or setup action.

Step 5A - Verify Routed Mutation Admission

37a. When the selected path claims routed or reusable mutation readiness, assemble a mutation-admission request that binds the live task/SWU, exact controlling artifact references, dependency frontier, material writes, validation-owned execution outputs, their complete allowed-write union, validation commands, lifecycle owner, authority class, and publication class. When execution needs temporary repository-local files or directories, declare them separately as transientOutputs: an exact nonempty subset of execution outputs that requires the transient-aware admission version. Material target baselines remain material-only. The strict context pack must repeat the complete execution contract so the consumer can detect a material target relabeled as an execution output. Standalone non-mutating execution does not require this request. 37b. Derive the write profile from the normalized partitions. A material-bound profile has one or more material writes and must include the material package, producer receipt, and exact producer-owned receipt schema. An execution-output-only profile has no material writes, one or more execution outputs, and must omit all three material artifacts. Run scripts/verify-mutation-readiness.py; never copy or reimplement the Invoke material-package validator inside Task Session. 37c. Run the consumer after scope, context, gates, and runtime resolution and immediately before the first local write or mutating runtime handoff. It must re-read every exact controlling artifact and dependency, compare the strict context execution contract to the request, and compare declared targets, validation, ownership, authority, and publication against the live request. For material-bound, it must also bind the material package to the producer receipt digest. Normalize and validate all three write lists, require material writes and execution outputs to be disjoint, require their union to equal allowed writes, and, for material-bound, require package changes, target inventory, and producer validated paths to equal only the material-write set. 37d. An absent, schema-invalid, stale, mismatched, expanded, or unclassified input returns BLOCK before mutation. Rebuild the bounded context/material handoff only through its owner; approval does not repair a failed binding. 37e. Persist the schema-valid mutation-admission receipt. Only admissionVerdict=admit and mutationReady=true may cross this gate. not-applicable is valid only for standalone-nonmutating. 37f. The admission receipt is execution evidence, not mutation, lifecycle, promotion, or publication authority. Live done-criterion and post-mutation validation in Step 7 remain mandatory. 37g. Mutation admission authorizes the ordered lifecycle only: apply admitted material writes when the profile is material-bound; then run the declared validation that may create only predeclared execution outputs, verify every declared output, and persist the terminal Task Session receipt as the final write. An execution-output-only admission grants no material mutation, promotion, publication, or lifecycle authority. Execution outputs are not required to exist at admission time and may not expand the admitted union. Transient outputs are never durable staged postimages. The governance request and ticket must type them separately, require absent pre-execution state, repository containment, non-overlap, and no symbolic-link traversal, and the executor receipt must record exact touch and cleanup evidence. Every transient must be absent before that receipt and remain absent through reconciliation and commit. A transient scope must also be disjoint by equality and ancestry from the run directory, plan-admission consumption ledger, pre-execution prerequisite ledger and resume receipt, the executor receipt, durable material and declared outputs, and terminal Task Session receipt. The executor receipt path remains exactly <run-dir>/terminal-executor-receipt.json; configuration may not move it outside the run directory. Enforce the complete reservation before the first run write. Bind the exact execution-ticket bytes to the ticketed checkpoint, then re-read the ticket's exact governance request and mutation-admission control. Require ordered transient equality across request, ticket, and admission, plus complete material, execution-output, and allowed-write partition closure. Recheck these bindings at status, executor launch and join, reconciliation, and commit. Existing non-transient requests retain the legacy contract unchanged. 37h. When the audit profile is selected-unit-at-task-session, require the exact Plan Semantic Manifest and selection receipt before accepting material. Bind task, SWU, plan epoch, unit-contract digest, attempt, complete structured validation-contract digest, target inventory and baselines, lifecycle owner, authority, and publication through the Invoke package, producer receipt, mutation-admission request, and admission receipt. 37i. Rehash every selected material target against its present/absent baseline at admission and again at the mutating adapter boundary. A missing future package blocks only mutation; it does not invalidate the audited semantic plan. Any plan semantic drift routes to Invoke Refresh and readiness re-audit. 37j. Treat plan-once admission as single-use. The governance runner must bind the admission token to attempt_id = run_id, atomically create the deterministic receipt-digest consumption ledger immediately before executor launch, carry the admission chain into the execution ticket, and require the terminal receipt to record the consumed receipt, token, attempt, and ledger reference. A second ticket or pre-joined executor output cannot reuse or bypass that admission.

Step 6 - Execute Task

38. Convert selected options, context-pack obligations, and checklist items into an ordered execution path.
39. If a runtime adapter is used, pass the handoff pack Markdown path and JSON/index path to the runtime handoff and preserve the Task Session synchronization obligations.
40. If running locally, make only the changes required for the task scope.
41. Avoid unrelated refactors or opportunistic cleanup unless they are necessary for completion.

Step 7 - Validate Completion

42. Classify every done criterion and validation obligation as acceptance-critical or noncritical before evaluating completion. Unclassified done criteria and validation obligations are acceptance-critical.
43. Validate against every done criterion and context-pack obligation.
44. Run relevant checks based on touched assets.
45. If a runtime adapter performed execution, review the runtime result against the original work-pack contract, context pack, handoff pack/index, and any reported fallback exploration.
46. If Task Session or Continuation Router spawned, inherited, or requested subagents, verify the subagent lifecycle ledger before reporting success: every agent must be joined, closed, blocked with residue, timed out with residue and reroute, or handed off with reroute.
47. Treat hidden open agents, pending joins, pending closes, and unreported thread-cap failures as BLOCK, not as successful fallback exploration.
48. If acceptance-critical validation fails or cannot be run, attempt bounded recovery or a named accepted equivalent. Until the original validation or accepted equivalent passes, return BLOCK; recording a substitute does not itself satisfy the obligation. 48a. For routed or reusable mutation, reconcile durable staged postimages against the ticket's declared_outputs one-to-one with material targets. Separately reconcile every admitted transient against its exact touch and cleanup result and recheck live absence. Block on an undeclared output, missing durable output, missing or substituted transient evidence, transient residue, or any write outside allowedWrites. Write the terminal Task Session receipt only after this reconciliation passes.
49. Return FLAG only for named noncritical residue that cannot falsify any done criterion. Unnamed residue or residue that can falsify a done criterion returns BLOCK.

Step 8 - Synchronize Evidence

50. Assemble a CloseoutSync record from the terminal Task Session receipt: source result and receipt, declared target inventory, baseline identities or digests, typed deltas, validation commands, expected owner receipt, and the mechanically determined next route when one exists. Revalidate the Step 4 closeout preflight against the live targets; target drift invalidates the preflight and returns BLOCK.
51. Treat synchronization as required when the terminal receipt changes evidence, blocker, status, route, work-pack, checklist, traceability, Dispatch, registry, or declared Craft projection state. Treat it as no-op only when current artifacts already represent the terminal receipt.
52. Admit automatic closeout synchronization only when:
    • the route is exactly invoke:refresh:apply-approved;
    • every target is in the declared closeout inventory;
    • every delta is one of evidence_added, blocker_opened, blocker_resolved, status_changed, or route_changed;
    • source receipt, target baselines, validation commands, and expected owner receipt are present;
    • any successor selection is the one unique, already declared, dependency-ready successor; and
    • the delta does not execute implementation or another task, change authority, promote, publish, deploy, perform destructive cleanup, accept policy/cost/risk, or touch unrelated targets.
53. When Step 52 passes, derive an exact closeout authorization bound to the route tuple, source receipt, target inventory, baseline identities or digests, delta classes, and validation surface. This is the current Task Session's authorization for closeout bookkeeping only; do not ask for a second user approval.
54. Dispatch the closeout authorization through continuation-router. Continuation Router must run the Invoke Refresh owner's strict apply-approved gates, dispatch exactly one owner hop, and join a separate validated owner receipt. Task Session never edits the owner's targets directly.
55. Update the task result with separate execution and closeout outcomes. Preserve the execution result even if synchronization blocks. A required closeout with missing inputs, target drift, ambiguous successor, owner validation failure, cycle, or unjoined owner receipt makes the Task Session result BLOCK.
56. If the task belongs to a spell or sigil lifecycle, preserve experiment harness status and report whether reusable-behavior validation is updated, pending, blocked, or not applicable.
57. Return the synchronized next route but never execute the next task/SWU as part of closeout.
58. After a joined closeout owner receipt or receipt-backed no-op, emit or update one repository-local Task Session continuity cursor. Prefer the native runtime session id; when unavailable, use a stable scope-derived id so repeated calls in the same work-pack scope update one cursor. The cursor records the scope root, work pack, source SWU/result/receipt, closeout owner receipt, returned next route/SWU, and blocker fingerprint. It must conform to continuity.schema.json and must never rewrite work-pack authority.
59. If no synchronization is needed, report the receipt-backed no-op reason.

Step 9 - Report

60. Return a compact task-session report in Outcome Brief -> Boundary and Next Decision -> Technical Details order, followed by resolution mode/source, candidates considered, session recovery status, context pack, handoff pack artifact, strict coverage, fallback-search status, decisions and their classifications, runtime adapter, gate verdict, execution result, closeout-sync status and authorization, closeout owner receipt, continuity cursor, continuation handoff, probable non-closeout routes, optional continuation status, optional owner receipt, returned next route, subagent closeout, files updated, validation criticality and outcomes, experiment harness status, and remaining follow-up.
61. Report subagent closeout as n/a, pass, flag, or block; when it is not n/a, include counts for spawned, joined, closed, blocked, timed-out, handed-off, open, plus residue and reroute paths.
62. When the result is BLOCK because a decision is required, append a Decision Gate Result section that names the target scope, lists the blocker question, presents 2-4 concrete options with trade-offs, records the recommended option if one exists, and points to the decision artifact path.

Recommended signals:

• task reference,
• resolution mode and source,
• session recovery status,
• continuity cursor path,
• candidate count, ambiguity count, stale exclusions, and cross-scope rejects,
• context pack status and source count,
• handoff pack markdown and JSON/index paths when runtime delegation is used,
• strict coverage status,
• fallback exploration/search status,
• decision count,
• gate result,
• subagent closeout result and unresolved agent count when delegated execution is present,
• files changed count,
• validation commands,
• validation result,
• completion status,
• follow-up count,
• dry-run or auto mode usage.
• selected runtime and adapter when used,
• runtime handoff command shape or blocked fallback.
• experiment harness status when the task belongs to spell or sigil lifecycle work.
• continuation handoff path, blocker fingerprint, candidate count, probable route tuples, selection and authorization status,
• continuation dispatch status, owner receipt, returned next route, and repeated-route or cycle detection.
• mutation-admission mode, verdict, receipt path, request/package/producer schema digests, derived write profile, bound task/SWU, controlling paths, dependency IDs, allowed writes, validation commands, boundary classes, live-validation requirement, and block reasons.
• closeout-sync required/no-op status, source receipt, target count, baseline status, delta classes, derived authorization identity, owner dispatch and receipt, validation result, and synchronized next route.

• route explicit series intent to task-session-until-blocker without executing more than one SWU inside Task Session,
• resolve exactly one task scope,
• make a no-argument invocation resume at most one uniquely nearest, evidence-backed SWU,
• recover from missing conversational context only through runtime-supplied current-session evidence or repository-local continuity,
• revalidate every cursor-selected candidate against the live work pack,
• classify declared pre-execution prerequisites before Context Builder,
• join only a digest-and-size-bound owner receipt under the exact authorized route and revalidate its package, scope, predicate, and live baselines,
• atomically consume each prerequisite attempt/fingerprint and permit exactly one same-attempt Context Builder resume,
• resolve exactly one work-pack task or SWU when the input is a work-pack,
• build a bounded context pack before decisions, gates, runtime selection, or mutation,
• require strict handoff-pack coverage before --via runtime delegation,
• block when required source context is missing, contradictory, or too weak to check constraints,
• expose meaningful implementation trade-offs,
• auto-select only choices explicitly classified both nonconsequential and reversible,
• stop before mutation when blockers remain,
• emit an actionable machine-readable continuation handoff for a terminal result when owner routing evidence exists,
• expose one to three probable routes before any continuation dispatch,
• dispatch at most one exactly authorized continuation route and preserve the selected owner's gates,
• prevent unchanged blocked Task Session re-entry and recursive continuation,
• run decision-gate before reporting blocker-level human approval, destructive cleanup, rollout, or policy choices,
• keep runtime delegation behind an explicit adapter boundary,
• require a current producer-schema-validated, digest-bound mutation-admission receipt immediately before routed or reusable mutation,
• for plan-once execution, require a current non-authoritative selection receipt and atomically consume its attempt-bound admission exactly once,
• bind admission to the live task/SWU, controlling artifacts, dependency frontier, allowed writes, validation surface, and authority/publication class,
• derive material-bound versus execution-output-only from normalized write partitions and bind it to the strict context execution contract,
• for broad fast-entry routes, require an explicit versioned partition whose executor, terminal, and typed lifecycle-owner scopes exactly reconstruct the already-bound route and remain ticket-bound through closure,
• require producer material evidence only for material-bound and forbid it for execution-output-only,
• leave standalone non-mutating execution outside the receipt requirement,
• retain live post-mutation validation after admission,
• block success when delegated subagents remain open, pending, hidden, or only implicitly abandoned,
• keep edits within the declared task scope,
• validate all available done criteria,
• classify validation obligations and block unmet acceptance-critical validation unless a named accepted equivalent passes,
• reserve FLAG for named noncritical residue that cannot falsify a done criterion,
• distinguish task/SWU execution evidence from reusable-behavior experiment evidence,
• synchronize required completion and blocker evidence before returning,
• fail before implementation mutation when required closeout inputs are absent, ambiguous, stale, expanded, or forbidden,
• derive closeout authorization only for the exact receipt-bound target inventory, admitted delta classes, and validation surface,
• join a validated owner receipt for required closeout synchronization,
• block closeout when synchronization inputs, baselines, owner validation, or lifecycle joins are incomplete,
• return but never execute the next task/SWU selected by closeout,
• emit a schema-valid continuity cursor after joined closeout or a receipt-backed no-op,
• return a report that a reviewer can audit without reconstructing the full session.
• lead every terminal user-facing report, including BLOCK, with a plain-language Outcome Brief and explicit boundary/decision layer.

• using the sigil for many unrelated tasks at once,
• silently narrowing explicit all, one go, or until blocker series intent to one SWU instead of routing to the outer-loop owner,
• emitting one Task Session receipt that claims execution of several SWUs,
• choosing the globally latest work pack, telemetry row, or cursor,
• treating fuzzy relevance or cross-project recency as “nearest,”
• assuming compacted conversational tokens remain readable,
• treating a continuity cursor as readiness or completion authority,
• treating an Invoke material receipt alone as Task Session admission without binding it to the live task/SWU and strict execution controls,
• copying Invoke material-package validity logic into Task Session,
• inventing a placeholder material write for output-only or audit-only work,
• relabeling a material target as an execution output to bypass the producer package,
• reusing a mutation-admission receipt after any controlling artifact, dependency, write scope, validation command, owner, authority, or publication binding changes,
• treating a plan-once selection receipt as mutation authority, omitting the live target-baseline recheck, or launching an executor before atomic admission consumption,
• globally weakening fast-entry route closure to subset containment, inferring lifecycle ownership from pathnames, or relabeling lifecycle-owner scopes as executor writes,
• treating mutation admission as a substitute for live validation or as lifecycle authority,
• falling through to a lower-priority candidate when the selected evidence is stale or contradictory,
• executing from the task file alone when source links, architecture, or work-pack context can change the correct implementation choice,
• delegating through --via runtime without a complete session-evidence handoff pack and JSON/index,
• treating --auto as permission to guess consequential user choices,
• treating a recommendation, confidence judgment, or “clearly safe” label as an automatic-choice classification,
• changing files outside the task scope without recording why,
• marking completion without evidence,
• discovering a predictable missing closeout inventory, baseline, validation, or expected owner receipt only after implementation writes,
• skipping validation because the edit looks small,
• hiding failed checks inside a success report,
• returning FLAG for failed or unavailable acceptance-critical validation,
• returning FLAG for unnamed residue or residue that can falsify a done criterion,
• letting synchronization updates rewrite unrelated planning or status history.
• ending a terminal task with a separate proposal-only Refresh or apply-approval request when the required closeout delta is deterministic and satisfies the bounded closeout-sync policy.
• ending with a vague approval request when a blocker-level decision could be presented as concrete options with context.
• hardcoding Codex as the only possible runtime,
• treating a generated runtime handoff as completed work before evidence returns.
• reporting AFK research as successful while subagent joins, closes, residues, or reroutes are unproven.
• treating free-text next_route as mutation approval.
• re-entering Task Session with the same blocker fingerprint and unchanged controlling evidence.
• accepting a path-only prerequisite owner receipt, a mismatched control handle, expanded package target, or a second resume for a consumed attempt/fingerprint,
• performing Invoke Refresh, Decision Gate, Goal, or another owner's mutation directly inside Task Session instead of dispatching and joining the owner.
• deriving closeout authorization for implementation, another task, authority, promotion, publication, deployment, destructive cleanup, policy/cost/risk acceptance, an ambiguous successor, or an undeclared target.
• recursively executing the next route returned by a continuation owner.
• leading with receipt mechanics, gate fields, or paths before explaining the practical execution outcome and boundary.

## Outcome Brief

<Two to five plain-language sentences explaining what task was attempted, what
completed or why it stopped, and why that matters.>

- Objective: <what this Task Session was trying to accomplish>
- Result: <what completed, was flagged, or is blocked>
- Why it matters: <practical consequence for the operator or next owner>

## Boundary and Next Decision

- Changed: <files, evidence, closeout state, or none>
- Unchanged: <unexecuted work, authority, promotion, publication, deployment, or other explicit boundaries>
- Open questions: <remaining uncertainty or none>
- User decision: <exact decision needed or none>
- Next action: <next bounded action and owner>

## Technical Details

## Task Session Result

- Task: <task-reference>
- Series intent: none | routed to task-session-until-blocker | blocked, <handoff path or reason>
- Resolution mode: explicit | resume-nearest | list-nearest
- Resolution source: explicit-source | visible-session-context | exact-session-cursor | cwd-ancestor-work-pack | scope-matched-continuity
- Session recovery: visible | durable-cursor | cwd-work-pack | scoped-continuity | unavailable
- Resolution candidates: <ranked count, rejected stale/cross-scope count, ambiguity | none>
- Result: PASS | BLOCK | FLAG
- Execution result: PASS | BLOCK | FLAG
- Decisions: <resolved count and summary>
- Decision classifications: <consequence and reversibility per automatic choice | none>
- Context pack: <source count and controlling constraints | blocked reason>
- Handoff pack: <markdown path and JSON/index path | none | blocked reason>
- Strict coverage: pass | block | n/a
- Fallback search: none | named gaps only | blocked
- Runtime: <runtime id or local>
- Adapter: <adapter id or none>
- Gate verdict: <summary>
- Closeout sync: pass | no-op | block
- Closeout authorization: derived | not-needed | not-derivable, <exact bound tuple and scope identity | reason>
- Closeout owner receipt: <path | none>
- Closeout validation: <owner checks and join result | none>
- Continuity cursor: <path | none | blocked reason>
- Continuation handoff: <path or inline id | none>
- Blocker fingerprint: <stable identifier | none>
- Probable routes: <ranked 1-3 capability/mode tuples | none>
- Optional continuation: not-requested | not-authorized | ambiguous | blocked | completed | flagged
- Continuation owner receipt: <path | none>
- Returned next route: <capability>:<mode> <target | none>
- Subagent closeout: n/a | pass | flag | block, <spawned/joined/closed/blocked/timed_out/handed_off/open counts, residue, reroute>
- Files updated: <paths or none>
- Validation: <commands and results>
- Validation criticality: <acceptance-critical/noncritical classification, accepted equivalents, and residue>
- Experiment harness: pass | flag | block | not_run | not_applicable
- Synchronized records: <paths or none>
- Follow-up: <items or none>

## Decision Gate Result

- Target scope: <scope | n/a>
- Result: PASS | BLOCK | n/a
- Decisions resolved: <count>
- Blockers remaining: <count>
- Decision artifact: <path | none>
- Options: <numbered option cards with benefit, cost/risk, when to choose, downstream impact | none>
- Recommendation: <recommended option and rationale | none>
- Next step: <proceed | ask remaining decision | stop>