claude-code-workflow 7.2.15 → 7.2.16

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

@@ -1,209 +0,0 @@
-# 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("~/~  or <project>/.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

@@ -1,263 +0,0 @@
-# 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("~/~  or <project>/.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"
-mkdir -p "<session-dir>/.msg"
-```
-
-**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 |
-| .msg/ | Message bus: meta.json (pipeline metadata) + messages.jsonl (event log) | orchestrator |
-
-### 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: Initialize Message Bus (CRITICAL for UI)
-
-Initialize `.msg/meta.json` with pipeline metadata so the frontend can display dynamic pipeline stages. This is the **same format** used by the Claude version's `team_msg` tool with `type: "state_update"`.
-
-**pipeline_stages**: Array of role names representing pipeline stages. The UI displays these as the pipeline workflow visualization.
-
-```javascript
-// Determine pipeline_stages and roles based on mode
-const PIPELINE_CONFIG = {
-  "spec-only":          { stages: ["analyst", "writer", "reviewer"],                                                    roles: ["coordinator", "analyst", "writer", "reviewer"] },
-  "impl-only":          { stages: ["planner", "executor", "tester", "reviewer"],                                        roles: ["coordinator", "planner", "executor", "tester", "reviewer"] },
-  "fe-only":            { stages: ["planner", "fe-developer", "fe-qa"],                                                 roles: ["coordinator", "planner", "fe-developer", "fe-qa"] },
-  "fullstack":          { stages: ["planner", "executor", "fe-developer", "tester", "fe-qa", "reviewer"],               roles: ["coordinator", "planner", "executor", "fe-developer", "tester", "fe-qa", "reviewer"] },
-  "full-lifecycle":     { stages: ["analyst", "writer", "planner", "executor", "tester", "reviewer"],                   roles: ["coordinator", "analyst", "writer", "planner", "executor", "tester", "reviewer"] },
-  "full-lifecycle-fe":  { stages: ["analyst", "writer", "planner", "executor", "fe-developer", "tester", "fe-qa", "reviewer"], roles: ["coordinator", "analyst", "writer", "planner", "executor", "fe-developer", "tester", "fe-qa", "reviewer"] }
-}
-
-const config = PIPELINE_CONFIG[requirements.mode]
-
-// Write meta.json (read by API for frontend pipeline display)
-const meta = {
-  status: "active",
-  pipeline_mode: requirements.mode,
-  pipeline_stages: config.stages,
-  roles: config.roles,
-  team_name: "lifecycle",
-  updated_at: new Date().toISOString()
-}
-
-Write("<session-dir>/.msg/meta.json", JSON.stringify(meta, null, 2))
-
-// Initialize messages.jsonl with session init event
-const initMsg = {
-  id: "MSG-001",
-  ts: new Date().toISOString(),
-  from: "coordinator",
-  to: "coordinator",
-  type: "state_update",
-  summary: "Session initialized",
-  data: {
-    pipeline_mode: requirements.mode,
-    pipeline_stages: config.stages,
-    roles: config.roles,
-    team_name: "lifecycle"
-  }
-}
-
-Write("<session-dir>/.msg/messages.jsonl", JSON.stringify(initMsg) + "\n")
-```
-
-> **Why**: The frontend API reads `.msg/meta.json` to derive pipeline stages, roles, and team_name for the dynamic pipeline UI. Without this file, the UI falls back to hardcoded 4-stage pipeline or message inference which may be inaccurate.
-
-### Step 2.9: 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>
-  Message bus: .msg/meta.json initialized
-```
-
----
-
-## 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 |
-| meta | Object | Written to .msg/meta.json (read by frontend API) |
-
----
-
-## Success Criteria
-
-- Session directory created with all subdirectories (including `.msg/`)
-- 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
-- `.msg/meta.json` written with pipeline_stages, roles, team_name, pipeline_mode
-- `.msg/messages.jsonl` initialized with session init event
-- 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`.