feature-to-tasks

/feature-to-tasks - Feature design -> implementation plan -> JSON tasks

This command plans; it never executes tasks.

<input_contract> Accept exactly one product FT-<NNN>. Without arguments, ask the operator to select one feature in interactive mode; unattended callers must supply it explicitly. Reject FT-000 and every non-single-feature target; Foundation tasking belongs to /foundation-to-tasks.

Before any durable plan or task write, require:

• target feature, linked epic, governing REQ/RTM, clarified PRD, and applicable Constitution rules;
• .memory-bank/spec-backbone.md Global Backbone Status complete, or valid minimal with explicit global/shared not-applicable rationales, and positive integer Planning Revision;
• .memory-bank/spec-index.md plus existing feature links and plausible subject-based canonical specs;
• .memory-bank/contracts/boundary-map.md as the canonical accepted module/change-unit inventory and dependency topology;
• a valid Foundation decision. When Foundation is required, the concrete indexed FT-000 final gate must be done and its ID retained as a direct or transitive dependency of every product task;
• .memory-bank/tasks/index.json, every existing indexed task for the target, and existing plan/protocol/behavior evidence used for reconciliation;
• .memory-bank/workflows/execute-loop.md#fresh-feature-tasking-boundary, #execution-cohesive-task-boundary, and .memory-bank/workflows/tier-policy.md#task-claim-and-dependency-ownership before slicing;
• available .memory-bank/schemas/task.schema.json and remaining applicable tier-policy sections; parse them after boundary acceptance and before drafting task records.

Block task drafting when clarification is explicitly pending|blocked, feature design is blocked, a decomposition-relevant unresolved marker remains, global backbone/foundation readiness is invalid, or schema/tier policy is unavailable or incompatible. PLANNING_RECONCILIATION_REQUIRED is an instruction to reconcile, not a blocker. Missing clarification metadata alone is allowed. </input_contract>

<hard_invariants>

• JSON task records and .memory-bank/tasks/index.json are the only task model. Do not add a schema, registry, planning mode field, nested context model, or lifecycle value.
• Concrete IDs use TASK-NNN-TN-FT-NNN-WN; ID tier/feature/wave segments match record fields. Product tasks use dependency-driven W1+; W0 belongs only to FT-000.
• Lifecycle/status ownership is defined by .memory-bank/workflows/tier-policy.md#closure-authority. Planning writes planned, or ready only when dependencies and blockers are already satisfied; it does not claim scheduler closure/promotion ownership.
• Existing queue reconciliation is the default. Preserve ID, feature, wave, tier, dependencies, lifecycle status, verification evidence, protocol links, and the semantic basis of in_progress|done|done_for_prod|failed records. Full re-slicing requires an explicit operator request.
• If repair needs identity, tier, wave, dependency, AC, or material-scope changes, report rebuild_required; do not hide a new task behind repair.
• Every task boundary satisfies .memory-bank/workflows/execute-loop.md#execution-cohesive-task-boundary.
• Product feature, architecture slice/module, and task are distinct. A feature may cross slices and a slice may support several features. A task normally has one primary owning slice/module. A task may cross slices only after the execution-cohesion rule leaves one indivisible outcome; an orchestration owner and explicit crossed boundaries establish ownership, not merge evidence.
• boundary-map.md alone owns module identity and topology; plans and tasks link relevant graph/contract blocks without copying the subgraph.
• touched_files is advisory and non-exhaustive. A non-empty runtime_context.write_boundary is a deliberate hard boundary and not a copy of touched_files; forbidden_scope and stop conditions remain hard.
• Features compose product behavior and canonical links; they do not own default FT-* multi-concern design hubs.
• New specs use subject-based canonical paths.
• spec-index.md remains the pure Type | Path | Status | Scope | Change route registry.
• Never resolve competing canonical paths by creating a third spec.
• Behavior specs are optional JSON given/when/then examples linked only through feature ## Behavior specs and task source_artifacts. They are not a registry, schema, task field, readiness gate, verification target, or done criterion. </hard_invariants>