exe

/exe - Execute one TASK

<input_contract> Expected $ARGUMENTS: one concrete TASK-NNN-TN-FT-NNN-WN.

The caller has already selected this task. /exe never scans the queue or chooses another task.

Require and resolve:

• .memory-bank/tasks/index.json and exactly one matching indexed task record;
• .memory-bank/workflows/tier-policy.md#tier-obligations;
• #task-claim-and-dependency-ownership;
• #tier-classification-and-escalation only when observed scope may require a higher tier, #closure-authority only for manual T0/T1 closure, #hard-write-boundary only when a boundary/alias is non-empty, #task-scoped-acceptance-evidence when its fields are populated, and #claim-linked-red--green-for-t2t3 only for T2/T3;
• the task's direct feature/REQ context needed to interpret its outcome;
• direct task-linked canonical SDD specs and executable constraints;
• current boundary-map.md module, dependency-graph, and contract blocks when the task changes or crosses a registered module boundary;
• behavior specs only when linked in source_artifacts and useful as non-authoritative examples.

For a product task whose feature is not FT-000, also require a positive Global Backbone Planning Revision and the latest feature-specific /review-tasks-plan APPROVE report with exact standalone REVIEWED_PLANNING_REVISION: <N> equal to it. FT-000 keeps its dedicated Foundation gate and does not use product task-plan review.

Use task purpose, success_outcome, anti_goals, source_artifacts, normative_inputs, constraints, invariants, verification_targets, evidence_required, and runtime_context when present. For T0/T1, do not load broad global planning docs by default. For T2/T3, direct task-linked applicable canonical specs are mandatory; feature links and spec-index.md alone are not execution context.

Point-of-use preflight must confirm:

• index/file/ID resolution and matching ID tier/feature/wave segments;
• valid tier: T0|T1|T2|T3 and executable lifecycle state;
• every dependency exists and is done|done_for_prod;
• dependency outcomes are authoritative prerequisites; execute only the selected task's owned outcome and integration delta;
• no recorded blocker or unresolved required gate in the resolved task context;
• success is observable from AC/REQ/spec/gates/verification targets;
• the selected task, its direct feature/REQ context, and direct task-linked canonical specs are mutually consistent;
• for a product task, its feature lacks PLANNING_RECONCILIATION_REQUIRED and its reviewed and current Planning Revision are equal;
• T2/T3 direct canonical coverage is applicable and concrete enough to avoid guessing shape, rules, errors, and verification;
• every current accepted planned|ready T2/T3 task satisfies the prospective proof-path contract in tier policy;
• actual work fits the semantic outcome/AC/REQ/spec boundary, tier, deliberate hard allowed/forbidden scopes, and stop conditions;
• when linked rules define architecture boundaries, the tactic keeps state changes and cross-module orchestration with their accepted owners, uses required public boundaries, preserves source-of-truth and dependency direction, creates no unaccepted cross-module contract or forbidden command/write bypass, and honors linked orchestration-placement rules;
• for a task that changes a provider, current graph traversal covers every affected consumer until a compatible contract stops propagation; uncovered consumers make the feature tasking surface stale;
• within an open domain-modeling choice, prefer the affected area's local style; material boundary or ownership changes use the existing operator-decision routes;
• before creating, moving, or renaming a project-authored source file, resolve its applicable ownership, reuse, or tooling boundary; inspect the nearest relevant local pattern and governing manifests, configuration, resolution, or registration; preserve framework placement, required or reserved filename parts, import/module identity, public path, package export, route, and build target; then choose the minimum complete path with sufficient durable context;
• for an Alembic migration under an accepted linear topology, preflight may resolve the current head transiently to set or verify the new revision's direct down_revision; do not propagate it as a repository-current-head assertion or update historical feature tests, and run the existing project-level graph contract unchanged;
• the tier-required existing protocol is coherent, or every missing protocol file can be initialized from its framework-owned template before task start.