konductor 0.10.0 → 0.12.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "konductor",
-  "version": "0.10.0",
+  "version": "0.12.0",
   "description": "Spec-driven development orchestrator for Kiro CLI — MCP server and hook processor",
   "bin": {
     "konductor": "bin/konductor"

package/skills/konductor-exec/SKILL.md

@@ -10,13 +10,13 @@ You are the Konductor orchestrator. Execute the plans for a phase by spawning ex
 ## 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 (summary files, result files).
-2. **Read `config.toml` first** — respect parallelism settings and git configuration.
+2. **Read config via MCP** — call `config_get` to get parallelism settings and git configuration.
 3. **Report errors, don't retry crashes** — if an executor fails, write an error result for that plan, continue with remaining plans, and report all failures at the end.
 4. **Resume support** — scan for existing summary files to skip completed plans.
 
 ## Step 1: Read State and Config
 
-Call the `state_get` MCP tool to read current state, and read `.konductor/config.toml` for execution settings (parallelism, git config).
+Call the `state_get` MCP tool to read current state, and call the `config_get` MCP tool for execution settings (parallelism, git config).
 
 Validate that `[current].step` is either:
 - `"planned"` — ready to start execution

package/skills/konductor-init/SKILL.md

@@ -10,7 +10,11 @@ You are the Konductor orchestrator. Initialize a new spec-driven development pro
 ## Step 1: Check Existing State
 
 Check if `.konductor/` directory already exists.
-- If it exists, call the `state_get` MCP tool. If it returns valid state, warn the user: "A Konductor project already exists here. Reinitializing will overwrite project.md, requirements.md, and roadmap.md. Proceed? (y/n)"
+- If it exists, call the `state_get` MCP tool. If it returns valid state:
+  - If `current.step` is `"shipped"`: ask the user: "Project is shipped. Do you want to (a) add a new phase to the existing project, or (b) reinitialize from scratch?"
+    - If (a): ask for the new phase name. Read `.konductor/roadmap.md` to determine the updated `phases_total`. Call the `state_advance_phase` MCP tool with the new phase identifier and updated phases_total. Skip to Step 8 (report success).
+    - If (b): proceed with normal reinitialization below.
+  - Otherwise: warn the user: "A Konductor project already exists here. Reinitializing will overwrite project.md, requirements.md, and roadmap.md. Proceed? (y/n)"
 - If user declines, stop.
 
 ## Step 2: Create Directory Structure
@@ -62,23 +66,7 @@ Call the `state_init` MCP tool with:
 
 This creates `.konductor/state.toml` with the correct initial structure.
 
-Write `.konductor/config.toml`:
-```toml
-[general]
-default_model = "claude-sonnet-4"
-
-[execution]
-max_wave_parallelism = 4
-
-[git]
-auto_commit = true
-branching_strategy = "none"
-
-[features]
-research = true
-plan_checker = true
-verifier = true
-```
+Call the `config_init` MCP tool to create `.konductor/config.toml` with defaults.
 
 ## Step 7: Sync Steering Files
 

package/skills/konductor-map-codebase/SKILL.md

@@ -88,7 +88,6 @@ mkdir -p .kiro/steering
 Provide the mapper with:
 - The target directory (absolute path)
 - The output file paths (absolute paths)
-- Reference to `references/codebase-analysis.md` if it exists
 
 Wait for the mapper to complete.
 
@@ -149,11 +148,7 @@ These files will be used as context for planning and execution.
 
 ## Step 7: Optional State Update
 
-If a Konductor project exists (`.konductor/state.toml`), update the metrics:
-- Increment `[metrics].total_agent_sessions`
-- Update `[metrics].last_activity`
-
-Write a result file at `.konductor/.results/map-codebase.toml`:
+If a Konductor project exists (`.konductor/state.toml`), write a result file at `.konductor/.results/map-codebase.toml`:
 
 ```toml
 step = "map"

package/skills/konductor-next/SKILL.md

@@ -11,13 +11,13 @@ You are the Konductor orchestrator. Your job is to determine the next step in th
 
 1. **Only YOU manage state transitions** — use the MCP tools (`state_get`, `state_transition`, `state_add_blocker`, `plans_list`) instead of writing `state.toml` directly. Subagents never touch state. They write their own output files.
 2. **`.results/` is the source of truth** — if state and `.results/` conflict, trust `.results/`.
-3. **Read `config.toml` first** — respect feature flags and parallelism settings.
+3. **Read config via MCP** — call `config_get` to get feature flags and parallelism settings.
 4. **Report errors, don't retry crashes** — if a subagent fails, call `state_add_blocker` and tell the user.
 
 ## Step 1: Read State
 
 Call the `state_get` MCP tool to read current state. Also read:
-- `.konductor/config.toml` — feature flags and settings
+- Call the `config_get` MCP tool for feature flags and settings
 - `.konductor/roadmap.md` — phase list and status
 
 If `.konductor/` does not exist, tell the user:
@@ -151,9 +151,17 @@ 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 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."
+
 ### Case: `step = "blocked"`
 
-Tell the user about the blocker from the `state_get` response `blockers` list and ask how to proceed.
+Tell the user about the blocker from the `state_get` response `blockers` list. 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
 

package/skills/konductor-plan/SKILL.md

@@ -10,13 +10,18 @@ You are the Konductor orchestrator. Plan a phase by researching the ecosystem, c
 ## 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.toml` first** — respect feature flags (research, plan_checker, design_review).
+2. **Read config via MCP** — call `config_get` to get feature flags (research, plan_checker, design_review).
 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.
 
 ## Step 1: Validate State
 
-Call the `state_get` MCP tool to read current state, and read `.konductor/config.toml`.
+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."
+Then stop.
+
 Validate that the specified phase exists in `.konductor/roadmap.md`.
 Create the phase directory if it doesn't exist:
 ```bash
@@ -112,6 +117,9 @@ Wait for the reviewer to complete. Verify `review.md` was created.
 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)"
 

package/skills/konductor-ship/SKILL.md

@@ -38,7 +38,7 @@ Spawn the **konductor-verifier** agent with instructions to perform a cross-phas
 - Check that API contracts are honored
 - Test critical user flows that span multiple phases
 - Look for integration gaps or inconsistencies between phase boundaries
-- Reference: see `references/verification.md` for verification patterns
+- Reference: see `skills/konductor-verify/references/verification-patterns.md` for verification patterns
 
 Provide the verifier with:
 - All phase directories: `.konductor/phases/*/`

package/skills/konductor-status/SKILL.md

@@ -95,8 +95,9 @@ Last activity: {last_activity_relative} ({last_activity_absolute})
 - `planned` → "Say 'exec' to execute the plans."
 - `executing` → "Execution in progress. Wait for completion or check logs."
 - `executed` → "Say 'next' to verify the phase."
-- `verified` → "Say 'next' to mark phase complete and advance."
 - `complete` → "Phase {n} complete. Say 'next' to move to phase {n+1}."
+- `shipped` → "All phases shipped. Add new phases to roadmap.md or say 'init' to start a new project."
+- `blocked` → "Resolve the blocker with `state_resolve_blocker`, then say 'next'."
 
 ## Error Handling
 

package/skills/konductor-verify/SKILL.md

@@ -10,13 +10,13 @@ You are the Konductor orchestrator. Verify a phase after execution to validate t
 ## 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.toml` first** — respect feature flags and settings.
+2. **Read config via MCP** — call `config_get` to get feature flags and settings.
 3. **Report errors, don't retry crashes** — if the verifier fails, set status to "blocked".
 4. **Use the 3-level verification framework** — Exists, Substantive, Wired (see references/verification-patterns.md).
 
 ## Step 1: Read State and Validate Phase
 
-Call the `state_get` MCP tool to read current state, and read `.konductor/config.toml` for verification settings.
+Call the `state_get` MCP tool to read current state, and call the `config_get` MCP tool for verification settings.
 
 Validate that `[current].step` is `"executed"`.
 

package/skills/konductor-plan/references/verification-patterns.md

@@ -1,400 +0,0 @@
-# Verification Patterns — 3-Level Verification Framework
-
-This guide defines how to verify that phase execution actually achieved its goals, not just created files.
-
-## The Three Levels
-
-Verification proceeds in three increasingly rigorous levels:
-
-### Level 1: Exists
-**Question:** Is the artifact present?
-
-**Checks:**
-- File exists at expected path
-- Directory structure is correct
-- Database tables exist
-- API endpoints are defined
-
-**Commands:**
-```bash
-# File existence
-[ -f src/models/user.rs ] && echo "OK" || echo "MISSING"
-
-# Directory structure
-[ -d src/routes ] && [ -d src/models ] && echo "OK"
-
-# Database table (PostgreSQL)
-psql -d mydb -c "\dt users" | grep -q users && echo "OK"
-
-# API endpoint defined (grep for route definition)
-grep -r "POST.*auth/register" src/routes/ && echo "OK"
-```
-
-**When Level 1 fails:** The most basic requirement is unmet. Execution did not complete.
-
-### Level 2: Substantive
-**Question:** Is the artifact a real implementation, not a stub?
-
-**Checks:**
-- File has meaningful content (>minimum line count)
-- Not just comments or placeholders
-- No TODO/FIXME/PLACEHOLDER patterns
-- Contains expected code structures (functions, classes, exports)
-
-**Thresholds:**
-- Model files: >20 lines
-- Route handlers: >15 lines
-- Component files: >25 lines
-- Test files: >30 lines
-- Migration files: >10 lines
-
-**Anti-patterns to detect:**
-```rust
-// STUB: Not substantive
-pub struct User {
-    // TODO: implement fields
-}
-
-// REAL: Substantive
-pub struct User {
-    pub id: Uuid,
-    pub email: String,
-    password_hash: String,
-    created_at: DateTime<Utc>,
-}
-```
-
-**Commands:**
-```bash
-# Line count check (exclude comments)
-lines=$(grep -v '^[[:space:]]*#' src/models/user.rs | grep -v '^[[:space:]]*$' | wc -l)
-[ "$lines" -gt 20 ] && echo "OK" || echo "STUB"
-
-# TODO/FIXME detection
-grep -i 'TODO\|FIXME\|PLACEHOLDER\|STUB' src/models/user.rs && echo "INCOMPLETE"
-
-# Meaningful structure (has at least one pub fn)
-grep -q 'pub fn' src/models/user.rs && echo "OK"
-```
-
-**When Level 2 fails:** Execution created files but didn't implement them properly. This is common with autonomous executors that hit errors.
-
-### Level 3: Wired
-**Question:** Is the artifact connected to the rest of the system?
-
-**Checks:**
-- Imported by other files
-- Actually used (not just imported)
-- Part of the call graph
-- No orphaned code
-
-**Common wiring patterns:**
-
-**Component → API fetch:**
-```javascript
-// In component file
-import { fetchUsers } from '../api/users'
-// And uses it
-const users = await fetchUsers()
-```
-
-**API → Database query:**
-```python
-# In API handler
-from models.user import User
-# And uses it
-user = User.query.filter_by(email=email).first()
-```
-
-**Form → Handler:**
-```rust
-// In form component
-<form action="/auth/register" method="POST">
-// And in routes
-pub async fn register(form: Form<RegisterData>) -> Response
-```
-
-**State → Render:**
-```jsx
-// In state file
-export const userSlice = createSlice({ ... })
-// And in component
-import { selectUser } from '../store/userSlice'
-const user = useSelector(selectUser)
-```
-
-**Commands:**
-```bash
-# Check if User model is imported anywhere
-grep -r "use.*models::user" src/ --exclude-dir=models | wc -l
-
-# Check if User is actually used (not just imported)
-# Look for User:: or User.new or similar
-grep -r "User::\|User\.new\|User\.find" src/ | wc -l
-
-# Check bidirectional wiring (component imports API, API returns component data)
-grep -q "fetchUsers" src/components/UserList.tsx && \
-grep -q "export.*fetchUsers" src/api/users.ts && echo "WIRED"
-```
-
-**When Level 3 fails:** Execution implemented features but they're isolated. Integration work is missing.
-
-## Must-Haves Derivation
-
-Every plan should have a `must_haves` section in its frontmatter:
-
-```toml
-[must_haves]
-truths = [...]
-artifacts = [...]
-key_links = [...]
-```
-
-Verification uses these to determine what to check.
-
-### Option A: From Plan Frontmatter
-
-If the plan has a `must_haves` section, use it directly.
-
-**Example plan frontmatter:**
-```toml
-[must_haves]
-truths = ["Users can register with email", "Passwords are hashed"]
-artifacts = ["src/models/user.rs", "src/routes/auth.rs"]
-key_links = ["User imported by auth routes", "bcrypt used in user.rs"]
-```
-
-**Verification:**
-1. For each truth, derive a test (manual or automated)
-2. For each artifact, check Levels 1-3
-3. For each key_link, verify the connection exists
-
-### Option B: From Roadmap Success Criteria
-
-If the plan doesn't have `must_haves`, fall back to the phase's success criteria from `roadmap.md`.
-
-**Example roadmap:**
-```markdown
-## Phase 01: Authentication System
-
-Success criteria:
-- Users can register with email and password
-- Users can log in and receive a session token
-- Passwords are securely hashed
-```
-
-**Derive must_haves:**
-- **truths:** Each success criterion becomes a truth
-- **artifacts:** Infer from common patterns (User model, auth routes, migrations)
-- **key_links:** Infer from dependencies (auth routes use User model)
-
-### Option C: Goal-Backward Derivation
-
-If neither plan frontmatter nor roadmap success criteria are available, work backward from the phase goal.
-
-**Steps:**
-1. Read the phase goal from roadmap.md
-2. Ask: "What must be true for this goal to be achieved?"
-3. Ask: "What files must exist?"
-4. Ask: "How must those files be connected?"
-
-**Example:**
-- **Goal:** "Implement user authentication"
-- **Truths:** Users can register, Users can log in, Sessions are managed
-- **Artifacts:** User model, auth routes, session middleware
-- **Key links:** Auth routes import User, Middleware validates sessions
-
-## Gap Structuring
-
-When verification finds issues, structure them as "gaps" for the next planning cycle.
-
-**Gap format:**
-```toml
-[[gaps]]
-truth = "Users can register with email"
-status = "failed"
-reason = "Registration endpoint returns 500"
-artifacts = ["src/routes/auth.rs"]
-missing = ["Error handling", "Email validation"]
-```
-
-**Fields:**
-- `truth`: Which must_have truth failed
-- `status`: "failed" or "partial" or "incomplete"
-- `reason`: Specific error or issue
-- `artifacts`: Which files are involved
-- `missing`: What needs to be added/fixed
-
-**Write gaps to:** `.konductor/phases/{phase}/gaps.toml`
-
-The next planning cycle can read this file and create gap-closure plans.
-
-## Verification Commands by Language
-
-### Rust
-```bash
-# Compilation check
-cargo check
-
-# Test execution
-cargo test
-
-# Import check
-grep -r "use crate::models::User" src/
-
-# Usage check
-grep -r "User::" src/ | grep -v "^src/models/user.rs"
-```
-
-### Python
-```bash
-# Import check
-python -c "from models.user import User; print('OK')"
-
-# Test execution
-pytest tests/
-
-# Import usage
-grep -r "from models.user import" src/ | wc -l
-
-# Usage check
-grep -r "User(" src/ | grep -v "models/user.py"
-```
-
-### JavaScript/TypeScript
-```bash
-# Compilation check (TypeScript)
-npx tsc --noEmit
-
-# Test execution
-npm test
-
-# Import check
-grep -r "import.*from.*models/user" src/
-
-# Usage check
-grep -r "new User\|User\.find\|User\.create" src/
-```
-
-### Go
-```bash
-# Compilation check
-go build ./...
-
-# Test execution
-go test ./...
-
-# Import check
-grep -r "\"myapp/models\"" . | wc -l
-
-# Usage check
-grep -r "models\.User" . | grep -v "models/user.go"
-```
-
-## Example Verification Report
-
-A verification report should follow this structure:
-
-```markdown
-# Verification Report: Phase 01 — Authentication System
-
-**Status:** Issues Found
-**Date:** 2026-03-19
-**Plans Verified:** 3
-
-## Level 1: Exists ✓
-
-All expected artifacts are present:
-- ✓ src/models/user.rs
-- ✓ src/routes/auth.rs
-- ✓ src/db/migrations/001_users.sql
-- ✓ tests/auth_test.rs
-
-## Level 2: Substantive ✓
-
-All files contain real implementations:
-- ✓ User model has 45 lines, includes fields and methods
-- ✓ Auth routes have 67 lines, no TODOs
-- ✓ Migration file creates users table with all columns
-- ✓ Tests have 52 lines with 6 test cases
-
-## Level 3: Wired ⚠
-
-Issues found:
-- ⚠ User model is imported by auth routes (OK)
-- ⚠ Auth routes use User::new (OK)
-- ✗ Registration endpoint returns 500 error
-- ✗ No middleware validates session tokens
-
-## Gaps
-
-```toml
-[[gaps]]
-truth = "Users can register with email"
-status = "failed"
-reason = "POST /auth/register returns 500: database connection error"
-artifacts = ["src/routes/auth.rs", "src/db/connection.rs"]
-missing = ["Database connection pool initialization", "Error handling"]
-
-[[gaps]]
-truth = "Sessions are validated on protected routes"
-status = "incomplete"
-reason = "Session middleware exists but is not applied to routes"
-artifacts = ["src/middleware/session.rs", "src/main.rs"]
-missing = ["Apply middleware to protected routes"]
-```
-
-## Next Steps
-
-1. Run `konductor plan phase 01 --gaps` to create gap-closure plans
-2. Or manually fix: Initialize DB connection pool in main.rs
-3. Re-run verification after fixes
-```
-
-## Verification Automation
-
-Verification should be automated where possible.
-
-**Pattern: Verification script per plan**
-
-Create `.konductor/phases/{phase}/verify-plan-{n}.sh`:
-```bash
-#!/bin/bash
-set -e
-
-# Level 1: Exists
-[ -f src/models/user.rs ] || { echo "FAIL: user.rs missing"; exit 1; }
-
-# Level 2: Substantive
-lines=$(grep -v '^[[:space:]]*//' src/models/user.rs | grep -v '^[[:space:]]*$' | wc -l)
-[ "$lines" -gt 20 ] || { echo "FAIL: user.rs is stub"; exit 1; }
-
-# Level 3: Wired
-grep -q "User::" src/routes/auth.rs || { echo "FAIL: User not used in auth"; exit 1; }
-
-# Truth verification
-cargo test auth::test_register || { echo "FAIL: registration test failed"; exit 1; }
-
-echo "PASS: Plan 1 verified"
-```
-
-Then run: `bash .konductor/phases/{phase}/verify-plan-{n}.sh`
-
-## Verification vs. Testing
-
-**Testing** checks that code is correct (unit tests, integration tests).
-**Verification** checks that execution achieved the phase goal (end-to-end validation).
-
-**Testing:**
-- Runs during execution (per task)
-- Checks individual functions
-- Passes/fails per test case
-- Developer-focused
-
-**Verification:**
-- Runs after all plans execute
-- Checks the entire phase
-- Validates against must_haves
-- User-focused (does it deliver the feature?)
-
-**Both are necessary.** Tests catch bugs. Verification catches gaps.