feature-doctor

/feature-doctor - Feature semantic triage

This command does not create tasks, implementation plans, tiers, behavior specs, or canonical SDD design specs.

<input_contract> Require $ARGUMENTS with one FT-<NNN>. Do not auto-select a feature. If the ID is absent, ask for it in interactive mode. In unattended flow, halt before any write with HALT_CLARIFICATION_REQUIRED and report:

• reason: missing required FT-<NNN> argument for /feature-doctor;
• affected command: /feature-doctor;
• owner and next action: the operator supplies the exact feature ID;
• exact resume command: /feature-doctor FT-<NNN>.

Use the caller's existing halt handoff; do not create a durable artifact solely for this missing argument.

Locate exactly one .memory-bank/features/FT-<NNN>-*.md; otherwise stop. Inspect the caller-cited findings or, when none are cited, the target's latest final task-plan REJECT, current blocking task verdicts, and explicit feature blockers. Ignore superseded findings. Read product, requirements, feature, relevant canonical design, affected task/plan, and implementation or verification evidence only as needed to validate the findings and repair impact. </input_contract>

<hard_invariants>

• Optional clarification metadata uses only: clarification_status: pending|complete|blocked, last_clarified: null|YYYY-MM-DD, and a non-negative cumulative clarification_questions count.
• Preserve feature design statuses complete|not_required|blocked; do not add a stale status.
• Preserve stable FT-<NNN>-AC-<NNN> IDs when accepted behavior is unchanged. New or split criteria use the next unused feature-local ID; retired IDs are not reused.
• Validate downstream specifications against governing product intent and accepted authority. Internally consistent downstream wording does not settle a finding when it conflicts with or leaves that intent materially open.
• /feature-doctor may determine repair ownership but must not repair linked SDD specs, create tasks/plans, change tier, or perform implementation repair.
• Preserve acceptance closure: a material edge/failure outcome retains a covering AC or an authoritative out-of-scope disposition with source and /write-prd change route; a material NFR retains its governing REQ, accepted target/qualitative criterion, decisive conditions, and verification method.
• Do not create or change a REQ-level product target locally. Route that change through /write-prd. </hard_invariants>

<operator_decisions> For a material finding, identify only distinct contract-valid options. State each decision's evidence basis, material consequences, likely affected artifacts/features, repair/revalidation surface, and canonical owner.

Recommend only among options that preserve accepted product intent and workflow contracts; prefer the least total canonical, implementation, planning, and revalidation change after evidenced material risk. Do not invent alternatives when authority permits one result.

Interactive flow presents viable alternatives and waits only when an operator decision remains. Unattended flow records the recommended option, basis, consequences, work surface, exact question, owner, and resume route, then returns the caller's existing HALT_CLARIFICATION_REQUIRED or HALT_BLOCKING_QUESTIONS; it never accepts the recommendation. An existing authoritative decision may be applied without asking again. </operator_decisions>

<required_outputs> Create or update only .protocols/FT-<NNN>/clarification.md plus the target feature doc. Do not create a separate decision log or triage report.

Record each finding, its semantic basis, the option analysis above, remaining decision, Design impact: none|feature_design_stale|global_design_stale|blocked, Behavior spec impact: none|refresh_recommended, and immediate route. Name only evidenced likely consumers; /spec-redesign owns exact affected features and the none|bounded|global verdict.