claude-code-workflow 6.3.53 → 7.0.0

package/.codex/skills/team-lifecycle/phases/01-requirement-clarification.md

@@ -0,0 +1,209 @@
+# Phase 1: Requirement Clarification
+
+> **COMPACT PROTECTION**: This is an execution document. After context compression, phase instructions become summaries only. You MUST immediately re-read this file via `Read("~/.codex/skills/team-lifecycle/phases/01-requirement-clarification.md")` before continuing. Never execute based on summaries.
+
+## Objective
+
+Parse user input, detect execution mode, apply frontend auto-detection, and gather all parameters needed for pipeline initialization. No agents are spawned in this phase -- it is purely orchestrator-local work.
+
+---
+
+## Input
+
+| Input | Source | Required |
+|-------|--------|----------|
+| User arguments | `$ARGUMENTS` (raw user input) | Yes |
+| Project root | Current working directory | Yes |
+| Existing sessions | `.workflow/.team/TLS-*/team-session.json` | No (checked for resume) |
+
+---
+
+## Execution Steps
+
+### Step 1.1: Session Resume Check (Phase 0)
+
+Before requirement parsing, scan for interrupted sessions.
+
+```javascript
+// Scan for active/paused sessions
+const sessionFiles = Glob(".workflow/.team/TLS-*/team-session.json")
+
+// Filter to active or paused
+const activeSessions = sessionFiles
+  .map(f => JSON.parse(Read(f)))
+  .filter(s => s.status === "active" || s.status === "paused")
+```
+
+**Decision table**:
+
+| Active Sessions | Action |
+|----------------|--------|
+| 0 | Proceed to Step 1.2 (new session) |
+| 1 | Ask user: "Found active session <session-id>. Resume? (yes/no)" |
+| 2+ | Ask user to select: "Multiple active sessions found: <list>. Which to resume? (or 'new' for fresh start)" |
+
+If user chooses to resume:
+- Read the selected session's state file
+- Proceed to Session Reconciliation (see orchestrator.md Session Resume section)
+- Skip remaining Phase 1 steps, jump directly to Phase 4
+
+If user chooses new session:
+- Continue to Step 1.2
+
+### Step 1.2: Parse Arguments
+
+Extract explicit settings from user input.
+
+**Recognized parameters** (from argument text or flags):
+
+| Parameter | Detection | Values |
+|-----------|-----------|--------|
+| mode | Explicit mention or `--mode` flag | spec-only, impl-only, full-lifecycle, fe-only, fullstack, full-lifecycle-fe |
+| scope | Main content of user description | Free text |
+| focus | `--focus` flag or explicit mention | Comma-separated areas |
+| depth | `--depth` flag | shallow, normal, deep |
+| execution | `--parallel` or `--sequential` flag | sequential, parallel |
+| spec-path | `--spec` flag (impl-only mode) | File path to existing spec |
+
+**Parsing logic**:
+
+```
+Parse user input text:
+  +- Contains "--mode <value>"? -> extract mode
+  +- Contains "--focus <areas>"? -> extract focus areas
+  +- Contains "--depth <level>"? -> extract depth
+  +- Contains "--parallel"? -> execution = parallel
+  +- Contains "--sequential"? -> execution = sequential
+  +- Contains "--spec <path>"? -> extract spec path
+  +- Remaining text after flag removal -> scope description
+```
+
+### Step 1.3: Ask for Missing Parameters
+
+If critical parameters are not extractable from the input, ask the user.
+
+**Required parameters and fallback defaults**:
+
+| Parameter | Required | Default | Ask If Missing |
+|-----------|----------|---------|----------------|
+| mode | Yes | (none) | Yes - "Which pipeline mode? (spec-only / impl-only / full-lifecycle / fe-only / fullstack / full-lifecycle-fe)" |
+| scope | Yes | (none) | Yes - "Please describe the project scope" |
+| execution | No | parallel | No - use default |
+| depth | No | normal | No - use default |
+| spec-path | Conditional | (none) | Yes, only if mode is impl-only - "Path to existing specification?" |
+
+**Ask format** (output to user, then wait for response):
+
+```
+[orchestrator] Phase 1: Requirement Clarification
+
+Missing parameter: <parameter-name>
+<question-text>
+
+Options: <option-list>
+```
+
+### Step 1.4: Frontend Auto-Detection
+
+For `impl-only` and `full-lifecycle` modes, check if the user description or project structure indicates frontend work.
+
+**Detection signals**:
+
+| Signal | Detection Method | Result |
+|--------|-----------------|--------|
+| FE keywords in scope | Match against keyword list (see below) | FE detected |
+| BE keywords in scope | Match against keyword list | BE detected |
+| FE framework in package.json | Read package.json, check for react/vue/svelte/next dependencies | FE framework present |
+| FE file patterns in project | Glob for *.tsx, *.jsx, *.vue, *.svelte | FE files exist |
+
+**FE keyword list**: component, page, UI, frontend, CSS, HTML, React, Vue, Tailwind, Svelte, Next.js, Nuxt, shadcn, design system, responsive, layout, form, dialog, modal, sidebar, navbar, theme, dark mode, animation
+
+**BE keyword list**: API, database, server, endpoint, backend, middleware, migration, schema, REST, GraphQL, authentication, authorization, queue, worker, cron
+
+**Upgrade decision table**:
+
+| Current Mode | FE Detected | BE Detected | Upgrade To |
+|-------------|-------------|-------------|------------|
+| impl-only | Yes | No | fe-only |
+| impl-only | Yes | Yes | fullstack |
+| impl-only | No | Yes | (no change) |
+| full-lifecycle | Yes | - | full-lifecycle-fe |
+| full-lifecycle | No | - | (no change) |
+| spec-only | - | - | (no change, spec is mode-agnostic) |
+| fe-only | - | - | (no change) |
+| fullstack | - | - | (no change) |
+
+If an upgrade is detected, inform the user:
+
+```
+[orchestrator] Frontend auto-detection: upgraded mode from <old> to <new>
+  Detected signals: <signal-list>
+  To override, specify --mode explicitly.
+```
+
+### Step 1.5: Impl-Only Pre-Check
+
+If mode is `impl-only`, verify that a specification exists:
+
+```
+Mode is impl-only?
+  +- spec-path provided? -> validate file exists -> proceed
+  +- spec-path not provided?
+      +- Scan session dir for existing spec artifacts -> found? use them
+      +- Not found -> error: "impl-only requires existing spec. Provide --spec <path> or use full-lifecycle mode."
+```
+
+### Step 1.6: Store Requirements
+
+Assemble the final requirements object. This will be passed to Phase 2.
+
+```javascript
+const requirements = {
+  mode: "<finalized-mode>",
+  scope: "<scope-description>",
+  focus: ["<area1>", "<area2>"],
+  depth: "<shallow | normal | deep>",
+  execution: "<sequential | parallel>",
+  spec_path: "<path-or-null>",
+  frontend_detected: true | false,
+  frontend_signals: ["<signal1>", "<signal2>"],
+  raw_input: "<original-user-input>"
+}
+```
+
+---
+
+## Output
+
+| Output | Type | Destination |
+|--------|------|-------------|
+| requirements | Object | Passed to Phase 2 |
+| resume_session | Object or null | If resuming, session state passed to Phase 4 |
+
+---
+
+## Success Criteria
+
+- All required parameters captured (mode, scope)
+- Mode finalized (including auto-detection upgrades)
+- If impl-only: spec path validated
+- If resuming: session state loaded and reconciled
+- No ambiguity remaining in execution parameters
+
+---
+
+## Error Handling
+
+| Error | Resolution |
+|-------|------------|
+| Unknown mode value | Report supported modes, ask user to clarify |
+| Spec path not found (impl-only) | Error with suggestion to use full-lifecycle |
+| User provides contradictory flags | Report conflict, ask user to resolve |
+| Session file corrupt during resume check | Skip corrupt session, proceed with new |
+| No user response to question | Wait indefinitely (interactive mode) |
+
+---
+
+## Next Phase
+
+Proceed to [Phase 2: Team Initialization](02-team-initialization.md) with the `requirements` object.

package/.codex/skills/team-lifecycle/phases/02-team-initialization.md

@@ -0,0 +1,205 @@
+# Phase 2: Team Initialization
+
+> **COMPACT PROTECTION**: This is an execution document. After context compression, phase instructions become summaries only. You MUST immediately re-read this file via `Read("~/.codex/skills/team-lifecycle/phases/02-team-initialization.md")` before continuing. Never execute based on summaries.
+
+## Objective
+
+Create the session directory structure, initialize the state file (`team-session.json`), set up wisdom and exploration cache directories. No agents are spawned in this phase.
+
+---
+
+## Input
+
+| Input | Source | Required |
+|-------|--------|----------|
+| requirements | Phase 1 output | Yes |
+| requirements.mode | Finalized pipeline mode | Yes |
+| requirements.scope | Project scope description | Yes |
+| requirements.execution | sequential or parallel | Yes |
+| Project root | Current working directory | Yes |
+
+---
+
+## Execution Steps
+
+### Step 2.1: Generate Session ID
+
+```javascript
+// Generate slug from scope description (max 20 chars, kebab-case)
+const slug = requirements.scope
+  .toLowerCase()
+  .replace(/[^a-z0-9]+/g, '-')
+  .replace(/^-|-$/g, '')
+  .slice(0, 20)
+
+// Date in YYYY-MM-DD format
+const date = new Date().toISOString().slice(0, 10)
+
+const sessionId = `TLS-${slug}-${date}`
+const sessionDir = `.workflow/.team/${sessionId}`
+```
+
+### Step 2.2: Create Directory Structure
+
+```bash
+mkdir -p "<session-dir>/spec/requirements"
+mkdir -p "<session-dir>/spec/architecture"
+mkdir -p "<session-dir>/spec/epics"
+mkdir -p "<session-dir>/discussions"
+mkdir -p "<session-dir>/plan/tasks"
+mkdir -p "<session-dir>/explorations"
+mkdir -p "<session-dir>/architecture"
+mkdir -p "<session-dir>/analysis"
+mkdir -p "<session-dir>/qa"
+mkdir -p "<session-dir>/wisdom"
+```
+
+**Directory purpose reference**:
+
+| Directory | Purpose | Written By |
+|-----------|---------|-----------|
+| spec/ | Specification artifacts (briefs, PRDs, architecture, epics) | analyst, writer |
+| discussions/ | Discussion records from inline discuss subagent | discuss subagent |
+| plan/ | Implementation plan and task breakdown | planner |
+| explorations/ | Shared codebase exploration cache | explore subagent |
+| architecture/ | Architect assessments, design tokens | architect |
+| analysis/ | Analyst design intelligence (UI mode) | analyst |
+| qa/ | QA audit reports | fe-qa |
+| wisdom/ | Cross-task knowledge accumulation | all agents |
+
+### Step 2.3: Initialize Wisdom Directory
+
+Create the four wisdom files with empty starter content:
+
+```javascript
+// learnings.md
+Write("<session-dir>/wisdom/learnings.md",
+  "# Learnings\n\nPatterns and insights discovered during this session.\n")
+
+// decisions.md
+Write("<session-dir>/wisdom/decisions.md",
+  "# Decisions\n\nArchitecture and design decisions made during this session.\n")
+
+// conventions.md
+Write("<session-dir>/wisdom/conventions.md",
+  "# Conventions\n\nCodebase conventions identified during this session.\n")
+
+// issues.md
+Write("<session-dir>/wisdom/issues.md",
+  "# Issues\n\nKnown risks and issues flagged during this session.\n")
+```
+
+### Step 2.4: Initialize Explorations Cache
+
+```javascript
+Write("<session-dir>/explorations/cache-index.json",
+  JSON.stringify({ entries: [] }, null, 2))
+```
+
+### Step 2.5: Initialize Shared Memory
+
+```javascript
+Write("<session-dir>/shared-memory.json",
+  JSON.stringify({
+    design_intelligence: null,
+    design_token_registry: null,
+    component_inventory: null,
+    style_decisions: null,
+    qa_history: null,
+    industry_context: null,
+    exploration_cache: null
+  }, null, 2))
+```
+
+### Step 2.6: Determine Task Counts
+
+Compute expected task counts based on mode:
+
+| Mode | Tasks | Pipeline Composition |
+|------|-------|---------------------|
+| spec-only | 6 | Spec pipeline (6) |
+| impl-only | 4 | Impl pipeline (4) |
+| fe-only | 3 | FE pipeline (3) + possible GC loop tasks |
+| fullstack | 6 | Fullstack pipeline (6) |
+| full-lifecycle | 10 | Spec (6) + Impl (4) |
+| full-lifecycle-fe | 12 | Spec (6) + Fullstack (6) + possible GC loop tasks |
+
+### Step 2.7: Write State File (team-session.json)
+
+```javascript
+const state = {
+  session_id: sessionId,
+  mode: requirements.mode,
+  scope: requirements.scope,
+  focus: requirements.focus || [],
+  depth: requirements.depth || "normal",
+  execution: requirements.execution || "parallel",
+  status: "active",
+  started_at: new Date().toISOString(),
+  updated_at: new Date().toISOString(),
+  tasks_total: taskCount,       // from Step 2.6
+  tasks_completed: 0,
+  pipeline: [],                  // populated in Phase 3
+  active_agents: [],
+  completed_tasks: [],
+  revision_chains: {},
+  wisdom_entries: [],
+  checkpoints_hit: [],
+  gc_loop_count: 0,
+  frontend_detected: requirements.frontend_detected || false,
+  spec_path: requirements.spec_path || null,
+  raw_input: requirements.raw_input
+}
+
+Write("<session-dir>/team-session.json",
+  JSON.stringify(state, null, 2))
+```
+
+### Step 2.8: Output Confirmation
+
+```
+[orchestrator] Phase 2: Session initialized
+  Session ID: <session-id>
+  Session directory: <session-dir>
+  Mode: <mode> (<task-count> tasks)
+  Scope: <scope-summary>
+  Execution: <sequential | parallel>
+```
+
+---
+
+## Output
+
+| Output | Type | Destination |
+|--------|------|-------------|
+| sessionId | String | Passed to Phase 3 |
+| sessionDir | String | Passed to Phase 3 |
+| state | Object | Written to team-session.json, passed to Phase 3 |
+
+---
+
+## Success Criteria
+
+- Session directory created with all subdirectories
+- Wisdom files initialized (4 files)
+- Explorations cache-index.json created (empty entries)
+- Shared-memory.json created
+- team-session.json written with correct mode, scope, task count
+- State file is valid JSON and readable
+
+---
+
+## Error Handling
+
+| Error | Resolution |
+|-------|------------|
+| Directory already exists with same session ID | Append random suffix to slug to ensure uniqueness |
+| Write permission denied | Report error, suggest alternative directory |
+| Disk space insufficient | Report error, suggest cleanup |
+| Invalid mode in requirements | Should not happen (Phase 1 validates), but fail with message |
+
+---
+
+## Next Phase
+
+Proceed to [Phase 3: Task Chain Creation](03-task-chain-creation.md) with `sessionId`, `sessionDir`, and `state`.

package/.codex/skills/team-lifecycle/phases/03-task-chain-creation.md

@@ -0,0 +1,251 @@
+# Phase 3: Task Chain Creation
+
+> **COMPACT PROTECTION**: This is an execution document. After context compression, phase instructions become summaries only. You MUST immediately re-read this file via `Read("~/.codex/skills/team-lifecycle/phases/03-task-chain-creation.md")` before continuing. Never execute based on summaries.
+
+## Objective
+
+Build the full pipeline task chain based on the selected mode, write all tasks to the state file (`team-session.json`). Each task entry contains its ID, owner agent, dependencies, description, and inline discuss metadata. No agents are spawned in this phase.
+
+---
+
+## Input
+
+| Input | Source | Required |
+|-------|--------|----------|
+| sessionId | Phase 2 output | Yes |
+| sessionDir | Phase 2 output | Yes |
+| state | Phase 2 output (team-session.json) | Yes |
+| state.mode | Pipeline mode | Yes |
+| state.scope | Project scope | Yes |
+| state.spec_path | Spec file path (impl-only) | Conditional |
+
+---
+
+## Execution Steps
+
+### Step 3.1: Mode-to-Pipeline Routing
+
+Select the pipeline definition based on mode.
+
+| Mode | Pipeline | First Task | Checkpoint |
+|------|----------|------------|------------|
+| spec-only | Spec pipeline (6 tasks) | RESEARCH-001 | None |
+| impl-only | Impl pipeline (4 tasks) | PLAN-001 | None |
+| fe-only | FE pipeline (3 tasks) | PLAN-001 | None |
+| fullstack | Fullstack pipeline (6 tasks) | PLAN-001 | None |
+| full-lifecycle | Spec (6) + Impl (4) | RESEARCH-001 | After QUALITY-001 |
+| full-lifecycle-fe | Spec (6) + Fullstack (6) | RESEARCH-001 | After QUALITY-001 |
+
+### Step 3.2: Build Task Entries
+
+For each task in the selected pipeline, create a task entry object.
+
+**Task entry schema**:
+
+```javascript
+{
+  id: "<TASK-ID>",
+  owner: "<agent-role>",
+  status: "pending",
+  blocked_by: ["<dependency-task-id>", ...],
+  description: "<task description>",
+  inline_discuss: "<DISCUSS-NNN or null>",
+  agent_id: null,
+  artifact_path: null,
+  discuss_verdict: null,
+  discuss_severity: null,
+  started_at: null,
+  completed_at: null,
+  revision_of: null,
+  revision_count: 0,
+  is_checkpoint_after: false
+}
+```
+
+**Task description template** (every task gets this format):
+
+```
+<task-description-from-pipeline-table>
+Session: <session-dir>
+Scope: <scope>
+InlineDiscuss: <DISCUSS-NNN or none>
+```
+
+### Step 3.3: Spec Pipeline Tasks
+
+Used by: spec-only, full-lifecycle, full-lifecycle-fe
+
+| # | ID | Owner | BlockedBy | Description | InlineDiscuss |
+|---|-----|-------|-----------|-------------|---------------|
+| 1 | RESEARCH-001 | analyst | (none) | Seed analysis and context gathering | DISCUSS-001 |
+| 2 | DRAFT-001 | writer | RESEARCH-001 | Generate Product Brief | DISCUSS-002 |
+| 3 | DRAFT-002 | writer | DRAFT-001 | Generate Requirements/PRD | DISCUSS-003 |
+| 4 | DRAFT-003 | writer | DRAFT-002 | Generate Architecture Document | DISCUSS-004 |
+| 5 | DRAFT-004 | writer | DRAFT-003 | Generate Epics and Stories | DISCUSS-005 |
+| 6 | QUALITY-001 | reviewer | DRAFT-004 | 5-dimension spec quality + sign-off | DISCUSS-006 |
+
+QUALITY-001 has `is_checkpoint_after: true` for full-lifecycle and full-lifecycle-fe modes (signals orchestrator to pause for user confirmation before impl phase).
+
+### Step 3.4: Impl Pipeline Tasks
+
+Used by: impl-only, full-lifecycle (PLAN-001 blockedBy QUALITY-001)
+
+| # | ID | Owner | BlockedBy | Description | InlineDiscuss |
+|---|-----|-------|-----------|-------------|---------------|
+| 1 | PLAN-001 | planner | (none) | Multi-angle exploration and planning | none |
+| 2 | IMPL-001 | executor | PLAN-001 | Code implementation | none |
+| 3 | TEST-001 | tester | IMPL-001 | Test-fix cycles | none |
+| 4 | REVIEW-001 | reviewer | IMPL-001 | 4-dimension code review | none |
+
+For full-lifecycle mode: PLAN-001 `blocked_by` includes `QUALITY-001`.
+
+TEST-001 and REVIEW-001 both depend on IMPL-001 and can run in parallel.
+
+### Step 3.5: FE Pipeline Tasks
+
+Used by: fe-only
+
+| # | ID | Owner | BlockedBy | Description | InlineDiscuss |
+|---|-----|-------|-----------|-------------|---------------|
+| 1 | PLAN-001 | planner | (none) | Planning (frontend focus) | none |
+| 2 | DEV-FE-001 | fe-developer | PLAN-001 | Frontend implementation | none |
+| 3 | QA-FE-001 | fe-qa | DEV-FE-001 | 5-dimension frontend QA | none |
+
+GC loop: if QA-FE-001 verdict is NEEDS_FIX, the orchestrator dynamically creates DEV-FE-002 and QA-FE-002 during Phase 4. These are NOT pre-created here.
+
+### Step 3.6: Fullstack Pipeline Tasks
+
+Used by: fullstack, full-lifecycle-fe (PLAN-001 blockedBy QUALITY-001)
+
+| # | ID | Owner | BlockedBy | Description | InlineDiscuss |
+|---|-----|-------|-----------|-------------|---------------|
+| 1 | PLAN-001 | planner | (none) | Fullstack planning | none |
+| 2 | IMPL-001 | executor | PLAN-001 | Backend implementation | none |
+| 3 | DEV-FE-001 | fe-developer | PLAN-001 | Frontend implementation | none |
+| 4 | TEST-001 | tester | IMPL-001 | Backend test-fix cycles | none |
+| 5 | QA-FE-001 | fe-qa | DEV-FE-001 | Frontend QA | none |
+| 6 | REVIEW-001 | reviewer | TEST-001, QA-FE-001 | Full code review | none |
+
+IMPL-001 and DEV-FE-001 run in parallel (both depend only on PLAN-001).
+TEST-001 and QA-FE-001 run in parallel (each depends on its respective impl).
+REVIEW-001 is a sync barrier -- depends on both TEST-001 and QA-FE-001.
+
+For full-lifecycle-fe: PLAN-001 `blocked_by` includes `QUALITY-001`.
+
+### Step 3.7: Composite Mode Assembly
+
+For composite modes, concatenate pipelines and adjust cross-pipeline dependencies.
+
+**full-lifecycle** = Spec (6) + Impl (4):
+
+```
+Spec pipeline tasks (Step 3.3)
+  +
+Impl pipeline tasks (Step 3.4)
+  with: PLAN-001.blocked_by = ["QUALITY-001"]
+  with: QUALITY-001.is_checkpoint_after = true
+```
+
+**full-lifecycle-fe** = Spec (6) + Fullstack (6):
+
+```
+Spec pipeline tasks (Step 3.3)
+  +
+Fullstack pipeline tasks (Step 3.6)
+  with: PLAN-001.blocked_by = ["QUALITY-001"]
+  with: QUALITY-001.is_checkpoint_after = true
+```
+
+### Step 3.8: Impl-Only Pre-Check
+
+If mode is `impl-only`, verify specification exists:
+
+```
+state.spec_path is set?
+  +- YES -> read spec file -> include path in PLAN-001 description
+  +- NO -> error: "impl-only requires existing spec"
+```
+
+Add to PLAN-001 description: `Spec: <spec-path>`
+
+### Step 3.9: Write Pipeline to State File
+
+```javascript
+// Read current state
+const state = JSON.parse(Read("<session-dir>/team-session.json"))
+
+// Set pipeline
+state.pipeline = taskEntries  // array of task entry objects from steps above
+state.tasks_total = taskEntries.length
+state.updated_at = new Date().toISOString()
+
+// Write back
+Write("<session-dir>/team-session.json",
+  JSON.stringify(state, null, 2))
+```
+
+### Step 3.10: Validation
+
+Before proceeding, validate the constructed pipeline.
+
+| Check | Criteria | On Failure |
+|-------|----------|-----------|
+| Task count | Matches expected count for mode | Error with mismatch details |
+| Dependencies | Every blocked_by reference exists as a task ID in the pipeline | Error with dangling reference |
+| No cycles | Topological sort succeeds (no circular dependencies) | Error with cycle details |
+| Owner assignment | Each task owner matches a valid agent from Agent Registry | Error with unknown agent |
+| Unique IDs | No duplicate task IDs | Error with duplicate ID |
+| Inline discuss | Spec tasks have correct DISCUSS-NNN assignment per round config | Warning if mismatch |
+| Session reference | Every task description contains `Session: <session-dir>` | Fix missing references |
+
+### Step 3.11: Output Confirmation
+
+```
+[orchestrator] Phase 3: Task chain created
+  Mode: <mode>
+  Tasks: <count>
+  Pipeline:
+    <task-id> (<owner>) [blocked_by: <deps>]
+    <task-id> (<owner>) [blocked_by: <deps>]
+    ...
+  First ready task(s): <task-ids with empty blocked_by>
+```
+
+---
+
+## Output
+
+| Output | Type | Destination |
+|--------|------|-------------|
+| state (updated) | Object | Written to team-session.json |
+| state.pipeline | Array | Task chain with all entries |
+| Ready task IDs | Array | Tasks with empty blocked_by (passed to Phase 4) |
+
+---
+
+## Success Criteria
+
+- Pipeline array written to state file with correct task count
+- All dependencies are valid (no dangling, no cycles)
+- Each task has owner, description, blocked_by, inline_discuss
+- Composite modes have correct cross-pipeline dependencies
+- Spec tasks have inline discuss metadata
+- At least one task has empty blocked_by (pipeline can start)
+
+---
+
+## Error Handling
+
+| Error | Resolution |
+|-------|------------|
+| Unknown mode | Should not happen (Phase 1 validates), fail with supported mode list |
+| Missing spec for impl-only | Error, suggest spec-only or full-lifecycle |
+| Dependency cycle detected | Report cycle, halt pipeline creation |
+| State file read/write error | Report error, suggest re-initialization |
+| Duplicate task ID | Skip duplicate, log warning |
+
+---
+
+## Next Phase
+
+Proceed to [Phase 4: Pipeline Coordination](04-pipeline-coordination.md) with the ready task IDs.