foundation-to-tasks

/foundation-to-tasks - Foundation decision -> FT-000 JSON tasks

<input_contract> Supported arguments:

• no argument: create or reconcile the required foundation queue;
• --verify-existing: verify an existing brownfield executable baseline.

Require:

• .memory-bank/foundation.md produced by /spec-design;
• clarified PRD, requirements, epics, product features, and current Feature Pressure Map;
• .memory-bank/spec-backbone.md with Global Backbone Status complete, or valid minimal with explicit not-applicable rationales, and positive integer Planning Revision;
• pure .memory-bank/spec-index.md plus applicable linked canonical specs;
• .memory-bank/tasks/index.json and .memory-bank/schemas/task.schema.json;
• .memory-bank/workflows/tier-policy.md#tier-classification-and-escalation, #hard-write-boundary, #task-claim-and-dependency-ownership, #task-scoped-acceptance-evidence, and #claim-linked-red--green-for-t2t3.

Read enough of those sources to prove the selected baseline, spec identity, task shape, dependencies, and tier. The agent chooses the efficient reading and exploration order, except that the task schema and tier policy must be loaded before drafting durable task records.

Require this parseable anchor block:

## Gate Anchors
- Foundation Required: true|false
- Foundation Requirement: REQ-000
- Foundation Pseudo-Feature: FT-000
- Foundation Gate Task: pending_foundation_to_tasks|TASK-<NNN>-T<N>-FT-000-W<N>|not_required

If the initial backbone or Foundation decision is missing/incomplete, route to /spec-design. If an accepted positive-revision backbone, Foundation decision, anchors, or Feature Pressure Map needs change, route to /spec-redesign before foundation writes. </input_contract>

<hard_invariants>

• Foundation is the minimum executable baseline, not product implementation or a future-ready platform.
• Apply the accepted architecture, composition, module/slice boundaries, and code roots that constrain the walking skeleton; do not revise or reinterpret them while tasking Foundation.
• REQ-000, FT-000, and product-foundation W0 are reserved. Product features must not use FT-000; product tasks must not use W0.
• Foundation uses only .memory-bank/tasks/TASK-*.task.json, .memory-bank/tasks/index.json, the existing task schema/lifecycle, and the tier-selected protocol/evidence paths. Do not add a foundation registry, schema, status machine, task fields, or protocol family.
• Task IDs use TASK-NNN-TN-FT-000-WN; ID tier/feature/wave segments match the record. Existing IDs are not renumbered.
• Lifecycle and closure ownership come from .memory-bank/workflows/tier-policy.md#closure-authority. This command creates/reconciles planning state only and never marks the final gate done.
• touched_files is advisory and non-exhaustive. A non-empty runtime_context.write_boundary is a deliberate hard boundary, never a mechanical copy of touched_files; forbidden_scope and stop conditions remain hard.
• New specs use subject-based canonical paths without FT-000 or product feature identity. spec-index.md remains Type | Path | Status | Scope | Change route, without decision bodies, ownership, or used_by metadata.
• Do not invent future endpoints, event payloads, domain behavior, state machines, schemas, migrations, security policy, or operational layers that are not needed to prove the baseline.
• When the accepted target uses capability slices, scaffold only the composition root and slice roots required by the walking skeleton. Do not create layer-centric application structure, empty future slices, cross-slice business behavior, or speculative shared abstractions.
• Never resolve competing canonical paths by creating a third spec. </hard_invariants>