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.

Sigil	Role In Task Session	Required Mode
context-builder	Build a bounded context pack from the selected task/SWU, source links, constraints, related architecture/spec artifacts, write scope, and validation surface before decisions, gates, or runtime handoff. For --via runtime, produce a strict Markdown plus JSON/index handoff pack stored as session evidence.	lean or standard
decision-gate	Convert unresolved blocker-level choices into user-ready option cards with context, trade-offs, recommendation, and a durable decision record before returning BLOCK.	blocker-only
continuation-router	Normalize a terminal Task Session receipt, prevent unchanged re-entry, dispatch and join the required bounded closeout-sync owner hop when eligible, and expose an optional non-closeout owner route without absorbing either owner's work.	one-hop

• 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