autopilot

/autopilot - Run an existing product JSON task queue

In this command, task and queue mean only indexed records whose feature is not FT-000. FT-000 records are read-only Foundation history.

<input_contract> Require:

• non-empty .memory-bank/tasks/index.json and resolving schema-valid .memory-bank/tasks/*.task.json records;
• .memory-bank/schemas/task.schema.json;
• installed .memory-bank/workflows/{tier-policy,execute-loop,autonomy-policy,mb-sync}.md exist;
• load tier policy #tier-obligations and #closure-authority, plus #hard-write-boundary only for a task/parallel boundary and #tier-classification-and-escalation only for a tier gap;
• load autonomy policy #phase-ownership, #experimental-parallel-execution when opted in, #durable-run-checkpoint, #required-gates, #failure-budgets, #scheduler-failure-handling, #terminal-fallback, #run-state, and #terminal-states;
• valid Global Backbone Status and Foundation anchors/dependencies; when Foundation is required, its named final gate is done and no FT-000 record remains planned|ready|in_progress|blocked;
• positive integer Global Backbone Planning Revision;
• at least one indexed product task whose feature is not FT-000;
• classify each task-linked feature as eligible only when its body lacks PLANNING_RECONCILIATION_REQUIRED and its latest /review-tasks-plan APPROVE has exact REVIEWED_PLANNING_REVISION: <N> equal to the current Planning Revision;
• no unresolved blocking operator decision;
• invoke node .memory-bank/scripts/mb-doctor.mjs --strict before the run, including resume, and before every later task selection required below. A new run requires PASS. A resumed run also requires PASS unless its only failing findings are the durable consequences of the exact unfinished scheduler checkpoint being recovered; in that case permit only that recovery action, then require PASS again before promotion, selection, or terminal success. Any unrelated finding uses the existing quality halt.

Every product task must preserve JSON schema, matching ID/tier/feature/wave segments, legal lifecycle, valid dependencies, feature existence, product W1+/reserved FT-000 W0 rules, and authoritative task.tier. Every T2/T3 task must have the complete single-card handoff: purpose/outcome, direct applicable canonical SDD links, expected advisory change surface and/or deliberate hard write boundary, verification path, concrete REQ links, and valid dependencies.

Tasks whose title starts with Production acceptance: are production-only acceptance work. During development, exclude them from promotion, selection, unfinished/deadlock checks, and success gates. Leave them planned for explicit /exe <TASK_ID> after production deployment.

For mixed work, write done_for_prod after development gates pass when only production acceptance remains; historical verify entries do not create queue work.

If no product record exists, return HALT_QUALITY_GATES: no schema-backed product task records found in .memory-bank/tasks/index.json and route the next explicit product feature to a fresh /feature-to-tasks FT-<NNN> session. If the Foundation gate is unfinished or any FT-000 work remains unresolved, return HALT_QUALITY_GATES with /autonomous as the Foundation execution/resume owner. Missing/invalid tier is HALT_POLICY_VIOLATION; clarification/design/Foundation/ handoff/readiness gaps use the applicable clarification or quality halt and repair route.

A missing/invalid Global Planning Revision halts all product work and routes /spec-design; it does not prove feature impact. With a valid revision, a missing/mismatched approval or reconciliation marker makes only that task-linked feature ineligible. Keep task statuses unchanged and reconcile ineligible features one at a time through the Fresh Feature Tasking Boundary. </input_contract>