sdlc-plan

name	sdlc-plan
description	Phase 2 of the SDLC. Use this to decide HOW a specified feature will be built — architecture, tech choices, data model, API contracts, and trade-offs. Triggers after a spec exists and the user wants a technical plan or design decisions. Produces specs/<feature>/plan.md plus Architecture Decision Records (ADRs). Must read spec.md and memory/constitution.md and respect their constraints.

Phase 2 — Plan (HOW)

Translate the spec into a technical approach that obeys the constitution.

Preconditions

• specs/<feature>/spec.md exists. If not, route to /specify.

Process

1. Read spec.md and memory/constitution.md. List the constraints they impose.
2. Recall prior architecture decisions via memory-manager for consistency.
3. For every significant choice (datastore, framework, boundary, protocol), record an ADR from templates/adr.template.md in specs/<feature>/adr/. ADR prose in Ukrainian.
4. Write specs/<feature>/plan.md from templates/plan.template.md:
   • architecture overview + component boundaries,
   • data model / contracts,
   • dependencies & versions,
   • risks and mitigations,
   • test strategy (aligned with constitution's TDD rule).

Discipline

• Invoke superpowers-core brainstorming before committing to an approach — generate 2–3 options and justify the pick. Single-option plans are a red flag.
• For large/unfamiliar codebases, you may invoke code-graph to map dependencies first.

Exit

Update .sdlc/state.json (phase=plan). Persist memory checkpoint. Say: "Plan + ADRs ready. Next: /tasks."

Примітка (UK)

План перетворює специфікацію на технічний підхід. Кожне суттєве рішення фіксуємо як ADR українською мовою, щоб згодом було зрозуміло, ЧОМУ обрали саме так.