Workflow Panel with Tailwind Migration

.claude/agents/team-leader.md

@@ -0,0 +1,65 @@
+# Team Leader
+
+Orchestrator agent for the Agentic Terminal Wrapper. Decomposes features into tasks, delegates to specialist agents, manages branch lifecycle, and coordinates QA/Guardian reviews.
+
+## Initialization Protocol
+
+Before doing ANY work:
+1. Read `CLAUDE.md` — Project rules and conventions
+2. Read `.claude/docs/ARCHITECTURE.md` — System architecture
+3. Read the progress directory for current feature context
+4. Check `.claude/agents/` to understand available specialists
+
+## Scope — Coordination Only
+
+You do NOT write application code directly. You:
+- Decompose features into agent-ready tasks
+- Assign tasks to specialist agents with clear scope and acceptance criteria
+- Manage the wave execution order
+- Spawn QA reviewer after each task completion
+- Spawn Codebase Guardian before final merge
+- Track progress via /track events
+
+## Agent Roster
+
+| Agent | Domain | Key Files |
+|-------|--------|-----------|
+| desktop-engineer | Main process, IPC, preload | `src/main/`, `src/preload/` |
+| component-engineer | React components, state, pane system | `src/renderer/src/components/PaneContainer.jsx`, `src/renderer/src/App.jsx` |
+| styling-engineer | CSS theme, layout, pane styles | `src/renderer/src/App.css` |
+| terminal-engineer | xterm.js, PTY lifecycle | `src/renderer/src/hooks/useTerminal.js`, `src/renderer/src/components/TerminalPane.jsx` |
+| editor-engineer | CodeMirror, file tabs | `src/renderer/src/components/EditorPanel.jsx` |
+| test-engineer | Test infrastructure, coverage | `tests/`, `*.test.js`, `*.test.jsx` |
+| qa-reviewer | Code review, verification | Read-only on all files |
+| codebase-guardian | Structural integrity | Read-only on all files |
+
+## Pane System Context
+
+Panes are typed (`terminal | editor | timeline | project`). The `createPane(type)` function in App.jsx creates pane objects with `{ id, type, ptyId }`. PaneContainer does type-based rendering — terminal panes use TerminalPane (own header), non-terminal panes get a generic `.typed-pane` wrapper with `.pane-header` (type label + close button). The `+ New` dropdown in the toolbar lets users add any pane type. When decomposing tasks that touch the pane system, assign component-engineer for PaneContainer/App.jsx changes and styling-engineer for CSS.
+
+## Branching Model
+
+- Primary branch: `master`
+- Feature branches: `work/<feature>/<task>`
+- Never commit directly to `master`
+
+## Quality Gates
+
+- Every task gets QA review before merge
+- Final feature gets Codebase Guardian check
+- All tasks must pass lint/build before merge
+
+## Workflow Step Events
+
+When executing a workflow, emit step events to the progress file so the Workflow Panel can track progress in real-time:
+
+```jsonl
+{"type":"workflow_step","step":"<step-id>","status":"active","timestamp":"<ISO>","feature":"<name>"}
+{"type":"workflow_step","step":"<step-id>","status":"completed","timestamp":"<ISO>","feature":"<name>"}
+```
+
+Step IDs: create-plan, implement-plan, team-management, review, test, update-docs
+
+Emit `active` when entering a step and `completed` when leaving it.
+Read the active workflow from `.claude/workflow.json` → `activeWorkflow` field.
+Step documentation lives in `.claude/docs/workflows/<activeWorkflow>/steps/`.

.claude/docs/workflows/default/steps/01-create-plan.md

@@ -0,0 +1,59 @@
+# Create Plan
+
+## Overview
+
+Every feature begins with deep technical planning and task decomposition. No implementation work starts until the plan is complete and recorded in the progress file. This step corresponds to the PLAN phase of the lifecycle: reading requirements, analyzing the codebase, decomposing work into agent-ready tasks, mapping dependencies, and planning wave execution order.
+
+The Team Leader drives this step. The output is a fully decomposed task list with file-level scoping, dependency graphs, wave assignments, context budget estimates, and pre-filled QA checklists for every task. Skipping or rushing this step is the single biggest predictor of feature failure.
+
+Planning also includes risk assessment: identifying files that multiple tasks might need to touch, flagging large tasks that exceed context budget limits, and establishing the conflict prevention layers (file scoping, wave ordering, pre-merge rebase, sequential merges, escalation).
+
+## Process
+
+1. **Read requirements** -- Gather the feature request, user story, or bug report. Clarify ambiguities before proceeding.
+2. **Read project rules** -- Load `CLAUDE.md` and `.claude/docs/ARCHITECTURE.md` to understand conventions, file structure, naming rules, and security constraints.
+3. **Analyze the codebase** -- Identify which existing files, modules, and patterns the feature touches. Map the relevant IPC channels, components, hooks, and CSS.
+4. **Architectural design** -- Decide how the feature fits into the three-process Electron model (main, preload, renderer). Determine which IPC channels to add, which components to create or modify, and which hooks to extract.
+5. **Task decomposition** -- Break the feature into tasks where each task is assignable to exactly one agent, has a clear file scope (specific files to create or modify), has explicit acceptance criteria, and has no file-level overlap with any other task.
+6. **Wave planning** -- Group tasks into waves based on dependencies. Wave 1 is foundation (types, schemas, contracts). Wave 2 is business logic (services, domain logic). Wave 3 is integration (API routes, handlers, state management). Wave 4 is presentation (UI components, styling). Wave 5 is automatic (QA handles doc updates per workbranch).
+7. **Context budget estimation** -- For each task, estimate context usage: `8,000 base + (files x 1,000) + 3,000 margin`. If a task touches 13+ files, it must be split. Tasks touching 8-12 files should be evaluated for splitting.
+8. **Fill QA checklists** -- Copy the QA Checklist Template into every task assignment. Fill in task-specific sections and feature-specific checks. Use auto-fill rules to select sections based on the assigned agent's role.
+9. **Create progress file** -- Write the progress file to `.claude/progress/<feature-name>/events.jsonl` before spawning any agents. Include the task list, dependency graph, wave plan, branch status table, and context budget estimates.
+
+## Rules
+
+- No phase may be skipped in the lifecycle: PLAN > BRANCH > TRACK > ASSIGN > BUILD > QA > MERGE > GUARDIAN > PR.
+- Each task must be assignable to exactly one agent with no file-level overlap.
+- Tasks must have explicit acceptance criteria and a filled QA checklist.
+- The progress file must be created before spawning any agents.
+- Context budget must be estimated before every agent spawn (strict and standard modes).
+- If a task touches more than 10 files, split it using the splitting protocol: identify natural split points (layer, feature, or file group boundaries), create sub-tasks with distinct file sets, assign to adjacent waves.
+- Workflow mode (strict, standard, fast) must be resolved at feature start and recorded in the progress file. Resolution priority: per-invocation override > CLAUDE.md setting > default (strict).
+
+## Checks
+
+- Every task has exactly one assigned agent type from the agent roster.
+- No two tasks modify the same file.
+- Every task has explicit acceptance criteria listed.
+- Every task has a pre-filled QA checklist.
+- Wave dependencies form a DAG (no circular dependencies).
+- Context budget estimates are recorded for each task (strict/standard modes).
+- The progress file exists at `.claude/progress/<feature-name>/events.jsonl` with initial state.
+- Feature branch `<featurePrefix>/<feature-name>` is created from the base branch.
+
+## Inputs
+
+- Feature request, user story, or bug report from the user.
+- Current codebase state (CLAUDE.md, ARCHITECTURE.md, existing files).
+- Workflow mode (strict, standard, or fast).
+- Agent roster from `.claude/agents/`.
+
+## Outputs
+
+- Fully decomposed task list with file scopes and acceptance criteria.
+- Dependency graph mapping task relationships.
+- Wave execution plan (which tasks run in which wave).
+- Context budget estimates per task.
+- Pre-filled QA checklists for every task.
+- Progress file initialized at `.claude/progress/<feature-name>/events.jsonl`.
+- Feature branch created from base branch.

.claude/docs/workflows/default/steps/02-implement-plan.md

@@ -0,0 +1,55 @@
+# Implement Plan
+
+## Overview
+
+Implementation is executed by specialist agents working in isolated worktrees. Each agent follows a mandatory phased workflow with blocking gates between phases. This structure exists because agents tend to skip planning, chase errors down rabbit holes, run out of context, and produce work that ignores project conventions. The phased workflow with written plans prevents all of these failure modes.
+
+Every agent -- coding, QA, and Guardian -- operates under the same phased structure. The Team Leader spawns agents using full templates from the playbook that embed the phased workflow and error recovery directly into the agent's prompt. Minimal prompts like "implement X in file Y" are never used.
+
+Agents work exclusively in their assigned worktree directory. They never commit directly to the feature branch. Each worktree is created from the feature branch HEAD at the start of its wave, giving the agent a clean, isolated working directory with its own index and HEAD.
+
+## Process
+
+1. **Phase 0: Load Rules** -- The agent reads all required files before doing any work. This includes `CLAUDE.md` (project rules), `.claude/docs/ARCHITECTURE.md` (system architecture), the agent's own definition from `.claude/agents/`, the task description with acceptance criteria, and the QA checklist. The agent must not skim; this phase is blocking.
+2. **Phase 1: Write Execution Plan** -- The agent produces a written plan that cites specific rules by name. The plan includes: task summary, applicable rules (cited by section), files to create/modify/avoid, step-by-step implementation order, acceptance criteria mapping, and risk assessment. No code is written until the plan is complete.
+3. **Phase 2: Execute Plan** -- The agent follows its plan step by step, stating each step before executing it. On any error, the Error Recovery Protocol fires: stop, re-read the Phase 1 plan, classify the error scope (in scope my file, in scope not my file, out of scope), and fix with a maximum of 2 attempts. The agent never modifies files outside its scope, never refactors unrelated code, and never abandons the plan for tangential investigation.
+4. **Phase 3: Self-Review** -- The agent re-reads its Phase 1 plan and verifies every acceptance criterion is met. It checks that all files listed in the plan were created or modified as intended, that no files outside scope were touched, and that the work follows project conventions.
+5. **Phase 4: Spawn QA** -- The agent spawns a QA Review Agent on the same workbranch, passing along its Phase 1 plan so QA can verify the agent followed it. The QA checklist and task context are included in the spawn.
+
+## Rules
+
+- Every agent operates under the mandatory phased workflow. No phase may be skipped.
+- Phase gates are blocking: Phase 0 must complete before Phase 1, Phase 1 before Phase 2, etc.
+- Written plans must cite specific rules by name, proving the agent read and understood them.
+- The Error Recovery Protocol limits fix attempts to 2 per error. After 2 failures, the agent reports to the Team Leader.
+- Agents never modify files outside their assigned scope.
+- Agents never commit directly to the feature branch -- only to their workbranch.
+- All IPC goes through the preload bridge -- agents must not import `electron` in renderer code.
+- `contextIsolation: true` and `nodeIntegration: false` must always be maintained.
+- Components must clean up effects on unmount (event listeners, timers, observers, PTY processes).
+- Naming conventions must be followed: PascalCase components, camelCase hooks with `use` prefix, `namespace:kebab-action` IPC channels, BEM CSS classes.
+
+## Checks
+
+- Agent's Phase 1 plan exists as text output before any code is written.
+- All files created or modified match the task's file scope.
+- No files outside the task's scope were modified.
+- Error Recovery Protocol was followed for any errors encountered (max 2 attempts per error).
+- All acceptance criteria from the task description are addressed.
+- Code follows project conventions from CLAUDE.md (naming, patterns, security).
+- Agent committed its work to the workbranch, not the feature branch.
+- QA Review Agent was spawned with the Phase 1 plan included.
+
+## Inputs
+
+- Task description with acceptance criteria and file scope (from Create Plan step).
+- Pre-filled QA checklist for the task.
+- Worktree created from the feature branch HEAD.
+- Agent spawn template with embedded phased workflow and error recovery.
+
+## Outputs
+
+- Completed code committed to the workbranch in the agent's worktree.
+- Phase 1 plan (text output, preserved in context for QA).
+- Self-review results confirming acceptance criteria are met.
+- QA Review Agent spawned on the same workbranch.

.claude/docs/workflows/default/steps/03-team-management.md

@@ -0,0 +1,61 @@
+# Team Management
+
+## Overview
+
+The Team Leader orchestrates agent teams across waves with dependency tracking, progress monitoring, and crash recovery. This step covers the ongoing coordination work that happens throughout the feature lifecycle: creating teams and tasks, spawning agents on worktrees, tracking progress, managing wave transitions, and recovering from crashes.
+
+Wave execution is the core coordination pattern. Tasks are grouped into waves based on dependencies. Within a wave, agents that touch different files run in parallel in isolated worktrees. Between waves, a fence check verifies the feature branch is stable before the next wave starts. The Team Leader never writes application code directly -- it decomposes, delegates, monitors, and coordinates.
+
+Progress tracking is crash-safe by design. The progress file on disk (`.claude/progress/<feature-name>/events.jsonl`) survives terminal close, process kill, and session timeout. Git branches persist independently. When a new session picks up interrupted work, it reads the progress file and branch status to resume from the exact point of interruption.
+
+## Process
+
+1. **Create the team** -- Use `TeamCreate` with the feature name and description.
+2. **Create tasks with dependencies** -- Use `TaskCreate` for each task, then `TaskUpdate` with `addBlockedBy` to establish the dependency chain. Standard dependency flow: types/schemas (no blockers) > business logic (blocked by types) > integration (blocked by logic) > presentation (blocked by integration).
+3. **Create worktrees for Wave 1** -- From the feature branch HEAD, create a worktree per task: `git worktree add <worktreeDir>/<feature>/<task-slug> -b <workPrefix>/<feature>/<task-slug>`. All prefixes are configurable in `.claude/workflow.json`.
+4. **Spawn agents** -- Use the full spawn templates from the playbook. Each agent prompt includes all 4 phases with blocking gates, the Error Recovery Protocol, task context, acceptance criteria, file scope, and QA checklist. Never use minimal prompts.
+5. **Monitor progress** -- Update the progress file after every significant state change: team/tasks created, workbranch created, agent completes work, QA cycle (pass/fail), workbranch merged, integration complete.
+6. **Complete a wave** -- Wait for all agents in the wave to report QA PASS. Merge all workbranches sequentially (one at a time, in task-number order). Delete merged workbranches. Run the wave fence check based on workflow mode.
+7. **Wave fence verification** -- In strict mode: verify all workbranches merged and deleted, feature branch is clean, run lint/typecheck/test/build. In standard mode: verify workbranches merged, run lint only. In fast mode: skip fence entirely.
+8. **Start next wave** -- After the fence passes, create new worktrees from the updated feature branch HEAD. Spawn agents for the next wave. Update the wave status table.
+9. **Handle fence failures** -- For lint/typecheck failures: identify the responsible merged task, fix on the feature branch directly or create a fix task. For test failures: determine if from a new or existing test, investigate the gap. For build failures: fix missing imports or type mismatches on the feature branch.
+10. **Crash recovery** -- Check for existing progress files, workbranches, feature branches, and teams. Read the JSONL event log. Resume from the first non-COMPLETE task: if workbranch has commits check QA status, if workbranch has no commits re-spawn the agent, if workbranch doesn't exist create it and spawn.
+
+## Rules
+
+- The Team Leader does not write application code directly. It decomposes, delegates, monitors, and coordinates.
+- Agents work exclusively in their worktree directory -- no direct commits to the feature branch.
+- Workbranches are merged one at a time, in wave order, then task-number order within a wave.
+- After each merge, rebase the next workbranch on the updated feature branch HEAD before merging.
+- Conflict prevention has 5 layers: file scoping, wave ordering, pre-merge rebase, sequential merges, and escalation.
+- If rebase conflicts are non-trivial, escalate to the user. Never force through conflicts silently.
+- Wave fence mode follows the workflow mode: strict = full verify, standard = lint only, fast = skip.
+- QA round limits depend on workflow mode: strict = 3 rounds max, standard = 2 rounds, fast = 1 round.
+- The progress file must be updated after every significant state change.
+- Worktrees are removed after successful merge: `git worktree remove <worktreeDir>/<feature>/<task-slug>`.
+
+## Checks
+
+- Team exists with all tasks created and dependencies established.
+- Each wave's worktrees were created from the correct feature branch HEAD.
+- All agents were spawned with full templates (not minimal prompts).
+- Progress file is up-to-date with current state of all tasks, branches, and waves.
+- Wave status table shows correct status for each wave (PENDING, IN_PROGRESS, FENCE_CHECK, COMPLETE, BLOCKED).
+- Branch status table shows correct state for each workbranch (status, merged flag).
+- Workbranches are deleted after successful merge.
+- Wave fence check passed before starting the next wave (in strict/standard modes).
+
+## Inputs
+
+- Decomposed task list with dependencies, wave assignments, and file scopes (from Create Plan).
+- Feature branch created from the base branch.
+- `.claude/workflow.json` configuration (prefixes, worktree directory, mode).
+- Agent roster from `.claude/agents/`.
+
+## Outputs
+
+- All workbranches merged to the feature branch in wave order.
+- Progress file fully updated with task statuses, QA results, merge log, and wave status.
+- All worktrees removed after merge.
+- Feature branch stable and passing fence checks.
+- Ready for Codebase Guardian final gate.