konductor 0.12.4 → 0.14.0

package/skills/konductor-exec/references/execution-guide.md

@@ -1,20 +1,22 @@
 # Execution Guide — For Konductor Executor Agents
 
-This guide is for executor subagents that implement individual plans. You are responsible for executing one plan from start to finish.
+This guide is for executor subagents that implement individual tasks. You are responsible for executing one task and writing a per-task summary.
 
 ## Your Role
 
 You are a **konductor-executor** agent. You receive:
-- A plan file with tasks to complete
+- A plan file (for context on the overall goal and prior tasks)
+- A specific task number to execute
+- Summaries from prior completed tasks in this plan (for context)
 - Git configuration (auto-commit, branching strategy)
 - Reference to this guide
 
 Your job:
-1. Read and understand the plan
-2. Execute each task in order
+1. Read and understand the assigned task
+2. Execute the task
 3. Write tests when required (TDD plans)
 4. Commit changes following the protocol
-5. Write a summary when done
+5. Write a per-task summary with your status
 
 ## Deviation Rules
 
@@ -120,15 +122,11 @@ Make commits atomic and descriptive. Follow this protocol for every commit.
 
 ### Commit Frequency
 
-**One commit per task** (preferred):
-- After completing each task, commit the changes
+**One commit per task** (required):
+- After completing your assigned task, commit the changes
 - Keeps history granular and reviewable
 - Easier to roll back individual changes
 
-**Exceptions:**
-- If tasks are tightly coupled and splitting commits would break functionality, combine them
-- Always explain in the commit body why tasks were combined
-
 ### Staging Files
 
 **IMPORTANT:** Stage specific files, never use `git add -A` or `git add .`
@@ -201,84 +199,144 @@ Check `config.toml` field `git.auto_commit`:
 - Reading referenced interfaces from dependencies (doesn't count)
 - First-time codebase exploration at start of plan (first 3 reads don't count)
 
+## Implementer Status Protocol
+
+After completing a task (or failing to), report exactly one of these four statuses in your summary file. The orchestrator uses your status to decide what happens next.
+
+### DONE
+
+Task completed successfully. All files created/modified, tests pass, verify step satisfied.
+
+**Orchestrator action:** Proceed to spec review, then code quality review.
+
+### DONE_WITH_CONCERNS
+
+Task completed, but you have doubts or observations the orchestrator should know about.
+
+**Orchestrator triage:**
+- **Actionable concerns** (potential correctness issues, security risks, spec deviations) → orchestrator dispatches an executor to address them before proceeding to review.
+- **Informational concerns** (considered alternative approach, style preferences, future improvement ideas) → orchestrator proceeds directly to review.
+
+**Examples of actionable concerns:**
+- "The spec says validate email format, but I used a simple regex that may miss edge cases"
+- "This endpoint accepts user input without rate limiting"
+- "The plan says return 404, but the existing codebase returns 204 for missing resources"
+
+**Examples of informational concerns:**
+- "Considered using a builder pattern but kept it simple per the plan"
+- "This function could be split further in a future refactor"
+
+### NEEDS_CONTEXT
+
+You cannot complete the task because information is missing. Be specific about what you need.
+
+**Orchestrator action:** Provide the missing context and re-dispatch you. Maximum 2 retries — if still blocked after 2 attempts, escalate to user.
+
+**Your summary must include a `## Missing Context` section listing exactly what you need.**
+
+### BLOCKED
+
+You cannot complete the task due to a technical or architectural issue.
+
+**Orchestrator assessment:**
+- **Context problem** → provide context and re-dispatch
+- **Task too complex** → split into smaller tasks
+- **Plan wrong** → escalate to user
+
+**Your summary must include a `## Blocker` section describing the issue.**
+
+**Default rule:** If you encounter an issue you cannot classify into the other three statuses, use BLOCKED with a description.
+
 ## Summary Writing
 
-After completing all tasks (or encountering a blocker), write a summary file.
+After completing each task (or encountering a blocker), write a per-task summary file.
 
-**File location:** `.konductor/phases/{phase}/plans/{plan-number}-summary.md`
+**File location:** `.konductor/phases/{phase}/plans/{plan}-task-{n}-summary.md`
 
 **File name examples:**
-- `001-summary.md`
-- `002-summary.md`
-- `010-summary.md`
+- `001-task-1-summary.md` — Plan 001, Task 1
+- `001-task-2-summary.md` — Plan 001, Task 2
+- `003-task-1-summary.md` — Plan 003, Task 1
 
 ### Summary Structure
 
 ```markdown
-# Plan {plan-number} Summary
+# Plan {plan} — Task {n} Summary
 
-## Status
-[Completed | Blocked | Partial]
+## Status: DONE
 
 ## Files Created
 - `src/models/user.rs` — User struct with password hashing
-- `src/db/migrations/001_users.sql` — Users table migration
 
 ## Files Modified
-- `src/routes/auth.rs` — Added registration endpoint
 - `Cargo.toml` — Added bcrypt dependency
 
 ## Tests Added
 - `user::test_password_hashing` — Verifies bcrypt integration
-- `auth::test_registration_endpoint` — Verifies POST /auth/register
 
 ### Test Results
 ```
 cargo test user
-   Compiling auth-system v0.1.0
-    Finished test [unoptimized + debuginfo] target(s) in 2.3s
-     Running unittests (target/debug/deps/auth_system-abc123)
-running 2 tests
+running 1 test
 test user::test_password_hashing ... ok
-test auth::test_registration_endpoint ... ok
-
-test result: ok. 2 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
+test result: ok. 1 passed; 0 failed
 ```
 
 ## Deviations from Plan
-1. **Rule 1:** Fixed type error in existing auth routes that prevented compilation
-2. **Rule 2:** Added email validation to registration endpoint (plan didn't specify)
-3. **Rule 3:** Added bcrypt to Cargo.toml (plan assumed it was already present)
+1. **Rule 3:** Added bcrypt to Cargo.toml (plan assumed it was already present)
 
 ## Decisions Made
-- Used bcrypt cost factor of 12 (industry standard for password hashing)
-- Made password_hash field private to prevent accidental exposure
-- Added index on users.email for faster lookups during login
-
-## Blockers Encountered
-None. All tasks completed successfully.
+- Used bcrypt cost factor of 12 (industry standard)
 
 ## Verification
-All must_haves from plan frontmatter verified:
-- [x] Users can register with email and password (POST /auth/register returns 201)
-- [x] Passwords are hashed with bcrypt (verified in test)
-- [x] User model imported by auth routes (compiler confirms)
+- [x] User model exists with password hashing (compiler confirms)
+```
+
+### Conditional Sections by Status
+
+Include these sections only when the status requires them:
+
+**DONE_WITH_CONCERNS** — add `## Concerns`:
+```markdown
+## Status: DONE_WITH_CONCERNS
+
+## Concerns
+- Email validation uses a simple regex that may miss edge cases (potential correctness issue)
+- Considered using a builder pattern but kept it simple per the plan (informational)
+```
+
+**NEEDS_CONTEXT** — add `## Missing Context`:
+```markdown
+## Status: NEEDS_CONTEXT
+
+## Missing Context
+- What authentication strategy does the existing codebase use? (JWT vs sessions)
+- Is there an existing User type in `src/models/` that should be extended?
+```
+
+**BLOCKED** — add `## Blocker`:
+```markdown
+## Status: BLOCKED
+
+## Blocker
+The plan requires adding a DynamoDB table, but the SAM template uses a format incompatible with the existing deployment pipeline. This is an architectural decision (Rule 4).
 ```
 
 ### Summary Requirements
 
 Your summary MUST include:
-- **Status:** One of [Completed, Blocked, Partial]
-- **Files created:** List with brief descriptions
-- **Files modified:** List with brief descriptions
-- **Tests added:** Test names and what they verify
-- **Test results:** Actual output from test runner (paste full output)
+- **Status:** One of DONE, DONE_WITH_CONCERNS, NEEDS_CONTEXT, BLOCKED
+- **Files created:** List with brief descriptions (if any)
+- **Files modified:** List with brief descriptions (if any)
+- **Tests added:** Test names and what they verify (if any)
+- **Test results:** Actual output from test runner (if tests were run)
 - **Deviations:** Every deviation with rule number and explanation
 - **Decisions:** Technical choices you made
-- **Blockers:** Any issues that stopped you (or "None")
-- **Verification:** Checklist of must_haves from plan frontmatter
+- **Verification:** Checklist of task verify/done criteria from the plan
+
+**Conditional sections:** Include Concerns, Missing Context, or Blocker as required by your status.
 
-**If blocked:** Explain clearly what stopped you and what information or decision is needed to proceed.
+**Note:** After both spec compliance and code quality reviews pass, the orchestrator appends `## Review Status: passed` to your summary file. You do not write this field yourself — it is managed by the orchestrator.
 
 ## Working with TDD Plans
 

package/skills/konductor-next/SKILL.md

@@ -21,152 +21,181 @@ Call the `state_get` MCP tool to read current state. Also read:
 - `.konductor/roadmap.md` — phase list and status
 
 If `.konductor/` does not exist, tell the user:
-> "No Konductor project found. Say 'initialize my project' to get started."
+> "No Konductor project found. Say 'spec' to get started."
 Then stop.
 
 ## Step 2: Determine Next Action
 
 Based on the `current.step` field from `state_get`:
 
-### Case: `step = "initialized"` or `step = "discussed"`
+### Case: `step = "specced"` or `step = "discussed"`
 
-The phase needs planning. Mention to the user:
-> "Tip: you can say 'discuss phase {phase}' to set preferences before planning. Proceeding to plan."
+The phase needs design. Mention to the user:
+> "Tip: you can say 'discuss phase {phase}' to set preferences before design. Proceeding to design."
 
-Then run the **Planning Pipeline**:
+Then run the **Design Pipeline**:
 
-1. **Research** (if `config.toml` `features.research = true`):
+1. **Discover** (if `config.toml` `features.research = true`):
    Read `.konductor/phases/{phase}/context.md` if it exists.
-   Use the **konductor-researcher** agent to research phase {phase}. Provide it with:
+   Use the **konductor-researcher** agent to discover the ecosystem for phase {phase}. Provide it with:
    - The phase name and goal from roadmap.md
    - User decisions from context.md (if exists)
    - Relevant requirements from requirements.md
    The researcher will write to `.konductor/phases/{phase}/research.md`.
    Wait for completion.
 
-2. **Plan**:
+2. **Design**:
+   Use the **konductor-designer** agent to create the phase-level architecture. Provide it with:
+   - research.md (if discover was run)
+   - requirements.md
+   - roadmap.md (for phase goal and success criteria)
+   - project.md (tech stack and constraints)
+   The planner will write `.konductor/phases/{phase}/design.md` with overall architecture, component interactions, key decisions, interfaces, and trade-offs.
+   Wait for completion.
+
+3. **Update State**:
+   Write `.konductor/.results/design-{phase}.toml`:
+   ```toml
+   step = "design"
+   phase = "{phase}"
+   status = "ok"
+   timestamp = {current ISO timestamp}
+   ```
+   Call `state_transition` with `step = "designed"`.
+   Tell the user: "Phase {phase} design complete. Say 'next' to create execution plans."
+
+### Case: `step = "designed"`
+
+The phase needs task planning. Run the **Planning Pipeline**:
+
+1. **Plan**:
    Use the **konductor-planner** agent to create execution plans. Provide it with:
-   - research.md (if research was run)
+   - `.konductor/phases/{phase}/design.md`
+   - research.md (if exists)
    - requirements.md
    - roadmap.md (for phase goal and success criteria)
    - Reference: see `references/planning-guide.md` in the konductor-plan skill
-   The planner will first write `.konductor/phases/{phase}/design.md` with the phase-level architecture, then write plan files with `## Design` sections to `.konductor/phases/{phase}/plans/`.
+   The planner will write plan files to `.konductor/phases/{phase}/plans/`.
    Wait for completion.
 
-3. **Check Plans** (if `config.toml` `features.plan_checker = true`):
+2. **Check Plans** (if `config.toml` `features.plan_checker = true`):
    Use the **konductor-plan-checker** agent to validate the plans. Provide it with:
    - All plan files in `.konductor/phases/{phase}/plans/`
    - requirements.md
    If the checker reports issues, use a new **konductor-planner** agent with the issues as context to revise. Then re-check. Maximum 3 iterations.
 
-4. **Design Review** (if `config.toml` `features.design_review = true`):
-   Use the **konductor-design-reviewer** agent to review the design. Provide it with:
-   - `.konductor/phases/{phase}/design.md`
-   - All plan files in `.konductor/phases/{phase}/plans/`
-   - requirements.md, roadmap.md, project.md
-   The reviewer writes `.konductor/phases/{phase}/review.md` with a verdict (pass/revise/reject) and issues.
-   If verdict is "revise": spawn a new **konductor-planner** with the review feedback to revise design.md and affected plans, then re-run the reviewer. Maximum 2 iterations.
-   Present the review summary to the user. Ask: "Approve plans for execution? (approve / reject)".
-   On approve: proceed to step 5.
-   On reject: stop. Do not advance state.
-
-5. **Update State**:
+3. **Update State**:
    Write `.konductor/.results/plan-{phase}.toml`:
    ```toml
    step = "plan"
    phase = "{phase}"
    status = "ok"
    timestamp = {current ISO timestamp}
+   plan_count = {number of plan files created}
    ```
-   Update state: call `state_transition` with `step = "planned"`.
-   Tell the user: "Phase {phase} planned with N plans in M waves. Say 'next' to execute."
+   Call `state_transition` with `step = "planned"`.
+   Tell the user: "Phase {phase} planned with N plans in M waves. Say 'next' to review."
 
 ### Case: `step = "planned"`
 
-The phase is ready for execution. Run the **Execution Pipeline**:
+The phase is ready for review then execution. Run the **Review + Execution Pipeline**:
+
+**Review** (if `config.toml` `features.design_review = true`):
+Use the **konductor-design-reviewer** agent to review the design. Provide it with:
+- `.konductor/phases/{phase}/design.md`
+- All plan files in `.konductor/phases/{phase}/plans/`
+- requirements.md, roadmap.md, project.md
+The reviewer writes `.konductor/phases/{phase}/review.md` with a verdict (pass/revise/reject) and issues.
+If verdict is "revise": spawn a new **konductor-planner** with the review feedback to revise design.md and affected plans, then re-run the reviewer. Maximum 2 iterations.
+If verdict is "reject": stop. Tell the user to fix issues and re-run design.
+Present the review summary to the user. Ask: "Approve plans for execution? (approve / reject)".
+On approve: proceed to execution.
+On reject: stop. Do not advance state.
+
+**Execution:**
 
 1. Read `config.toml` for `execution.max_wave_parallelism` and `git.auto_commit`.
 2. Read all plan files from `.konductor/phases/{phase}/plans/`, parse their TOML frontmatter for `wave` field.
 3. Group plans by wave number (wave 1 first, then 2, etc.).
 4. Call `state_transition` with `step = "executing"`.
 
-5. **For each wave** (in order):
-   Update wave tracking as needed.
+5. **Per-Task Wave Execution Loop:**
+
+   For each wave (in ascending order):
 
-   **If `max_wave_parallelism > 1` (parallel mode):**
-   For each plan in this wave, use the **konductor-executor** agent to execute it. Launch all plans in the wave simultaneously. Each executor receives:
-   - Its specific plan file path
-   - Whether to auto-commit (`git.auto_commit`)
-   - The branching strategy (`git.branching_strategy`)
-   - Reference: see `references/execution-guide.md` in the konductor-exec skill
-   Wait for ALL executors to complete (check for summary files).
+   For each plan in the wave (parallel if `max_wave_parallelism > 1`, sequential otherwise):
+   Parse the plan's `## Tasks` section to extract individual tasks. For each task (sequential within a plan):
 
-   **If `max_wave_parallelism = 1` (sequential mode):**
-   Execute plans one at a time, in order within the wave.
+   **5a. Dispatch executor:**
+   Spawn a fresh **konductor-executor** agent with:
+   - The plan file path and the specific task number to execute
+   - Summaries from prior completed tasks in this plan (for context)
+   - Git config: `git.auto_commit` and `git.branching_strategy`
+   - Reference: see `references/execution-guide.md` in the konductor-exec skill (status protocol, deviation rules)
+   Wait for `{plan}-task-{n}-summary.md` in `.konductor/phases/{phase}/plans/`.
 
-   After each wave completes, track progress.
+   **5b. Handle implementer status:**
+   Read the `## Status` field from the task summary:
+   - **DONE** → proceed to 5c (two-stage review).
+   - **DONE_WITH_CONCERNS** → read `## Concerns`. If actionable (correctness, security, spec deviations): dispatch a fresh executor to address them, then proceed to 5c. If informational: proceed to 5c.
+   - **NEEDS_CONTEXT** → provide the requested information, re-dispatch. Maximum 2 retries. If still NEEDS_CONTEXT, treat as BLOCKED.
+   - **BLOCKED** → assess and attempt resolution. If 3+ tasks BLOCKED, trigger circuit breaker: stop and report all blockers.
 
-6. Write `.konductor/.results/execute-{phase}-plan-{n}.toml` for each completed plan.
-7. **Code Review** (if `config.toml` `features.code_review = true`):
-   Spawn **konductor-code-reviewer** agent with: `.konductor/.tracking/modified-files.log`, all `*-summary.md` files from plans directory, phase name. The reviewer writes `.konductor/phases/{phase}/code-review.md`.
-   If issues found: spawn a **konductor-executor** agent with the issues to fix them, then re-run the reviewer. Maximum 3 review-fix iterations. If still unresolved, call `state_add_blocker` and report to user.
-8. Call `state_transition` with `step = "executed"`.
-9. Tell the user: "Phase {phase} executed. N plans completed. Say 'next' to verify."
+   **5c. Two-stage review** (if `features.code_review = true`; skip if disabled, append `## Review Status: passed` to summary):
+
+   **Stage 1 — Spec Compliance:** Spawn **konductor-spec-reviewer**. If issues: fix and re-review (max 2 iterations).
+   **Stage 2 — Code Quality:** Spawn **konductor-code-reviewer**. If issues: fix and re-review (max 2 iterations).
+   After both pass: append `## Review Status: passed` to task summary.
+
+   **5d. Write result file** after each plan completes.
+
+6. **Phase-Level Code Review** (holistic final pass, if `features.code_review = true`):
+   Check cross-task consistency. Spawn **konductor-code-reviewer** with modified-files.log and all task summaries. Fix issues (max 3 iterations).
+7. Call `state_transition` with `step = "executed"`.
+8. Tell the user: "Phase {phase} executed. Say 'next' to verify."
 
 ### Case: `step = "executing"`
 
-Execution was interrupted. Resume:
-1. Check which `{plan}-summary.md` files exist in `.konductor/phases/{phase}/plans/`.
-2. Plans with summaries are complete — skip them.
-3. Resume from the first incomplete plan in the current wave.
-4. Continue the Execution Pipeline from step 5 above.
+Execution was interrupted. Resume at task-level granularity:
+1. Scan for `{plan}-task-{n}-summary.md` files.
+2. A task is complete when its summary has `## Status: DONE` AND `## Review Status: passed`.
+3. Check for NEEDS_CONTEXT or BLOCKED tasks — report before resuming.
+4. Resume from the first incomplete task.
+5. Continue the Execution Pipeline from step 5 above.
 
 ### Case: `step = "executed"`
 
 The phase needs verification. Run the **Verification Pipeline**:
 
-1. Check if `config.toml` `features.verifier = false`. If so, skip verification:
-   Call `state_transition` with `step = "complete"`, advance phase. Stop.
+1. If `config.toml` `features.verifier = false`: skip verification, call `state_transition` with `step = "complete"`, advance phase. Stop.
 
-2. Use the **konductor-verifier** agent to verify the phase. Provide it with:
-   - All summary files from `.konductor/phases/{phase}/plans/`
-   - requirements.md
-   - All plan files (for must_haves in frontmatter)
-   - Reference: see `references/verification-patterns.md` in the konductor-verify skill
-   The verifier writes `.konductor/phases/{phase}/verification.md`.
-   Wait for completion.
+2. Use the **konductor-verifier** agent. The verifier writes `.konductor/phases/{phase}/verification.md`.
 
 3. Read `verification.md`. Write `.konductor/.results/verify-{phase}.toml`.
-4. If status = "ok":
-   Call `state_transition` with `step = "complete"`.
-   Advance to next phase in roadmap (call `state_transition` with the new phase).
-   Tell user: "Phase {phase} verified and complete. Advancing to next phase."
-5. If status = "issues-found":
-   Keep current step as "executed".
-   Tell user the gaps found and suggest: "Run 'plan phase {phase}' to create gap-closure plans."
+4. If status = "ok": call `state_transition` with `step = "complete"`. Advance to next phase. Tell user: "Phase {phase} verified and complete."
+5. If status = "issues-found": keep step as "executed". Tell user the gaps and suggest re-planning.
 
 ### Case: `step = "complete"`
 
 Current phase is done. Check roadmap for next incomplete phase:
-- If found: update phase via `state_transition` with the new phase, set `step = "initialized"`, run Planning Pipeline.
+- If found: update phase via `state_transition`, run Design Pipeline.
 - If all phases complete: tell user "All phases complete! Say 'ship' to finalize."
 
 ### Case: `step = "shipped"`
 
-The project has been shipped. Check `.konductor/roadmap.md` for any phases not yet completed.
-
-- If a new phase exists in the roadmap that hasn't been executed: call the `state_advance_phase` MCP tool with the new phase identifier and the updated `phases_total` from the roadmap. This preserves project history (phases_complete, initialized date, metrics, blockers) while starting the new phase. Then run the Planning Pipeline for the new phase.
-- If no new phases exist: tell the user "All phases complete and shipped! To continue, add new phases to roadmap.md and requirements.md, then say 'next' again."
+Check `.konductor/roadmap.md` for any phases not yet completed.
+- If a new phase exists: call `state_advance_phase` MCP tool. Then run the Design Pipeline.
+- If no new phases: tell the user "All phases complete and shipped! To continue, add new phases to roadmap.md and requirements.md, then say 'next' again."
 
 ### Case: `step = "blocked"`
 
-Tell the user about the blocker from the `state_get` response `blockers` list. Suggest:
+Tell the user about the blocker. Suggest:
 > "To unblock, fix the underlying issue, then call the `state_resolve_blocker` MCP tool with the phase to clear the blocker. After that, say 'next' to continue."
 
 ## Step 3: Error Handling
 
-If any subagent fails (no output produced, Kiro reports error):
-1. Write `.konductor/.results/{step}-{phase}.toml` with `status = "error"` and error description.
-2. Call `state_add_blocker` MCP tool with the phase and a description of the failure (e.g., "Subagent {agent-name} failed: {error details}").
-3. Report the failure to the user with actionable context.
+If any subagent fails:
+1. Write `.konductor/.results/{step}-{phase}.toml` with `status = "error"`.
+2. Call `state_add_blocker` MCP tool with the phase and failure description.
+3. Report the failure to the user.
 4. Do NOT automatically retry a crashed subagent.

package/skills/konductor-plan/SKILL.md

@@ -1,59 +1,42 @@
 ---
 name: konductor-plan
-description: Plan a phase for execution. Research the ecosystem, create execution plans, and validate them. Use when the user says plan phase, plan, research and plan, or prepare phase.
+description: Break a phase design into execution plans with tasks. Use when the user says plan, create tasks, break down, or task planning.
 ---
 
-# Konductor Plan — Phase Planning Pipeline
+# Konductor Plan — Task Planning
 
-You are the Konductor orchestrator. Plan a phase by researching the ecosystem, creating execution plans, and validating them.
+You are the Konductor orchestrator. Break a phase design into execution plans with tasks, acceptance criteria, and wave ordering.
 
 ## Critical Rules
 
-1. **Only YOU manage state transitions** — use the MCP tools (`state_get`, `state_transition`, `state_add_blocker`) instead of writing `state.toml` directly. Subagents write their own output files.
-2. **Read config via MCP** — call `config_get` to get feature flags (research, plan_checker, design_review).
+1. **Only YOU manage state transitions** — use the MCP tools (`state_get`, `state_transition`, `state_add_blocker`) instead of writing `state.toml` directly.
+2. **Read config via MCP** — call `config_get` to get feature flags (plan_checker).
 3. **Report errors, don't retry crashes** — if a subagent fails, set status to "blocked".
-4. **Accept a phase argument** — the user may say "plan phase 01" or "plan phase 01-auth-system". Resolve short form by scanning `.konductor/phases/` directories.
+4. **Accept a phase argument** — the user may say "plan phase 01". Resolve short form by scanning `.konductor/phases/` directories.
 
 ## Step 1: Validate State
 
 Call the `state_get` MCP tool to read current state, and call the `config_get` MCP tool to read configuration.
 
-Validate that `current.step` is `"initialized"` or `"discussed"`. If not, tell the user:
-> "Phase {phase} is not ready for planning. Current step: {step}. Run 'discuss' or 'init' first."
+Validate that `current.step` is `"designed"`. If not, tell the user:
+> "Phase {phase} is not ready for task planning. Current step: {step}. Run 'design' first."
 Then stop.
 
-Validate that the specified phase exists in `.konductor/roadmap.md`.
-Create the phase directory if it doesn't exist:
-```bash
-mkdir -p .konductor/phases/{phase}/plans
-```
-
-## Step 2: Research (if enabled)
-
-If `config.toml` `features.research = true`:
-
-Read `.konductor/phases/{phase}/context.md` if it exists (user decisions from `konductor-discuss`).
+Verify `.konductor/phases/{phase}/design.md` exists.
 
-Use the **konductor-researcher** agent to research this phase. Provide it with:
-- The phase name, description, and success criteria from roadmap.md
-- User decisions from context.md (if exists)
-- Relevant requirements from `.konductor/requirements.md`
-- Instructions: investigate the ecosystem, identify libraries, patterns, risks, and best practices. Write findings to `.konductor/phases/{phase}/research.md`.
-
-Wait for the researcher to complete. Verify `research.md` was created.
-
-## Step 3: Create Plans
+## Step 2: Create Plans
 
 Use the **konductor-planner** agent to decompose the phase into execution plans. Provide it with:
-- `.konductor/phases/{phase}/research.md` (if research was run)
+- `.konductor/phases/{phase}/design.md`
+- `.konductor/phases/{phase}/research.md` (if exists)
 - `.konductor/requirements.md`
 - `.konductor/roadmap.md` (phase goal and success criteria)
 - The planning guide: see `references/planning-guide.md`
-- Instructions: first write `.konductor/phases/{phase}/design.md` with the phase-level architecture (see planning guide "Phase-Level Design Document" section), then create plan files in `.konductor/phases/{phase}/plans/` using TOML frontmatter format with `## Design` sections in each plan
+- Instructions: create plan files in `.konductor/phases/{phase}/plans/` using TOML frontmatter format with tasks, acceptance criteria, and wave ordering.
 
-Wait for the planner to complete. Verify `design.md` was created and at least one plan file exists.
+Wait for the planner to complete. Verify at least one plan file exists.
 
-## Step 4: Validate Plans (if enabled)
+## Step 3: Validate Plans (if enabled)
 
 If `config.toml` `features.plan_checker = true`:
 
@@ -67,66 +50,7 @@ If the checker reports issues that it could not fix:
 - Re-run the **konductor-plan-checker**
 - Maximum 3 iterations. If still unresolved, report to user.
 
-## Step 5: Design Review (if enabled)
-
-If `config.toml` `features.design_review = true`:
-
-Use the **konductor-design-reviewer** agent to review the technical design. Provide it with:
-- `.konductor/phases/{phase}/design.md`
-- All plan files in `.konductor/phases/{phase}/plans/`
-- `.konductor/requirements.md`
-- `.konductor/roadmap.md` (phase goal and success criteria)
-- `.konductor/project.md` (tech stack and constraints)
-- Instructions: analyze the phase design and per-plan Design sections, then write a structured review to `.konductor/phases/{phase}/review.md`
-
-**Review criteria the agent must evaluate:**
-1. Architectural soundness of design.md — do the components and interactions make sense?
-2. Feasibility of per-plan Design sections — are the proposed interfaces and approaches realistic?
-3. Cross-plan consistency — do shared interfaces match across plans that depend on each other?
-4. Requirement coverage — every REQ-XX for this phase is addressed
-5. Risk identification — missing error handling, security concerns, dependency issues
-
-**Review output format** (written to `.konductor/phases/{phase}/review.md`):
-```markdown
-# Design Review: Phase {phase}
-
-## Summary
-{one paragraph overall assessment}
-
-## Verdict: {pass | revise | reject}
-
-## Issues
-
-### Issue 1: {title}
-- **Severity:** critical | warning | info
-- **Affected plan:** {plan number or "design.md"}
-- **Description:** {what's wrong}
-- **Suggestion:** {how to fix}
-
-## Strengths
-{what the design does well}
-```
-
-Wait for the reviewer to complete. Verify `review.md` was created.
-
-**If verdict is "pass":** Proceed to Step 6.
-
-**If verdict is "revise"** (has critical or warning issues):
-1. Spawn a new **konductor-planner** agent with the review feedback as additional context
-2. Instruct it to revise `design.md` and the affected plans in-place
-3. Re-run the **konductor-design-reviewer**
-4. Maximum 2 review-revise iterations. If still "revise" after 2 iterations, proceed to user approval with warnings noted.
-
-**If verdict is "reject":** Stop. Do not advance state. Tell the user:
-> "Design rejected by reviewer. See `.konductor/phases/{phase}/review.md` for details. Fix the fundamental issues and re-run planning."
-
-**Present the review summary to the user.** Ask:
-> "Approve plans for execution? (approve / reject)"
-
-- **On approve:** Proceed to Step 6.
-- **On reject:** Stop. Do not advance state. Tell the user: "Plans not approved. Edit the plans in `.konductor/phases/{phase}/plans/` or re-run planning."
-
-## Step 6: Update State
+## Step 4: Update State
 
 Write `.konductor/.results/plan-{phase}.toml`:
 ```toml
@@ -137,14 +61,12 @@ timestamp = {current ISO timestamp}
 plan_count = {number of plan files created}
 ```
 
-Update state using MCP tools:
-- Call `state_transition` with `step = "planned"` to advance the pipeline
-- The tool automatically updates status and timestamps
+Call `state_transition` with `step = "planned"` to advance the pipeline.
 
 Tell the user:
 - How many plans were created
 - How many waves
-- Suggest: "Say 'next' to execute, or review the plans in `.konductor/phases/{phase}/plans/`"
+- Suggest: "Say 'next' to review the design and plans, or inspect them in `.konductor/phases/{phase}/plans/`"
 
 ## Error Handling