# Coding Manager Plan ## The Opportunity Claude Code March promotion: **double tokens during off-peak hours** (outside 5-11 AM PT), March 13-27. That gives us ~13 days where capacity is 2x from 11 AM PT through 5 AM PT — 18 hours per day of doubled throughput. The play: I act as a coding manager. I break Linear tasks into specs, spin up Claude Code sessions in isolated worktrees, monitor them, verify their output, and report results. Junwon reviews PRs. Everything else is automated. ## Architecture ``` ┌─────────────┐ │ Linear │ │ (tasks) │ └──────┬──────┘ │ pull tasks with │ palaceapp/palacelab labels ┌──────▼──────┐ │ Manager │ │ (Ace CLI) │ │ │ │ • spec │ │ • dispatch │ │ • monitor │ │ • verify │ │ • report │ └──────┬──────┘ │ spawn via claude -p │ in worktrees ┌────────────┼────────────┐ │ │ │ ┌─────▼─────┐┌────▼─────┐┌─────▼─────┐ │ Worker 1 ││ Worker 2 ││ Worker 3 │ │ worktree/ ││ worktree/││ worktree/ │ │ feat-auth ││ fix-nav ││ add-feed │ └─────┬──────┘└────┬─────┘└─────┬─────┘ │ │ │ ▼ ▼ ▼ ┌─────────────────────────────────────┐ │ Verification Gate │ │ build ✓ test ✓ typecheck ✓ │ │ diff non-empty ✓ stall-free ✓ │ └─────────────────┬───────────────────┘ │ ┌─────▼─────┐ │ PR │ │ (Junwon │ │ reviews) │ └───────────┘ ``` ## The Five Components ### 1. Task Intake (Linear → Spec) The manager pulls issues from Linear with `palaceapp` or `palacelab` labels. For each: - Reads the issue description, comments, and any linked files - Writes a `spec.md` in the task directory with: goal, acceptance criteria, files to touch, test requirements - If the issue description is too vague for autonomous work, posts a Linear comment asking for clarification and moves on This replaces the "Spec Agent" from MAN-3 — I write the specs myself since I have full context. ### 2. Dispatch (Spec → Worker) For each spec'd task: ```bash claude -p "$(cat spec.md)" \ --output-format stream-json \ --allowedTools "Read,Edit,Write,Bash,Glob,Grep,Agent" \ --max-turns 50 \ --worktree "task-MAN-XX" \ --append-system-prompt "$(cat worker-rules.md)" ``` `worker-rules.md` contains hard rules: - Never modify existing tests to make them pass - Never suppress errors or warnings - Commit after each meaningful change with a descriptive message - Run `turbo build && turbo type-check && turbo test` before declaring done - Output a structured JSON result: `{status, files_changed, tests_added, tests_passing, build_passing}` Workers run in isolated worktrees — they can't interfere with each other or the main branch. ### 3. Progress Monitor (Watchdog) A monitoring loop that checks every 2 minutes: | Check | Signal | Response | |-------|--------|----------| | Git diff in worktree | No new commits in 15 min | Warning → kill at 30 min | | Process alive | Claude process exited | Check exit code, log result | | Token burn rate | >$2/turn average | Kill — likely stuck in a loop | | Same error 3x | Grep stdout for repeated errors | Kill, flag for manual review | | Turn count | Approaching max-turns | Log warning | Stall detection is the key insight from your email. A session that's "running" but not changing files is dead weight. The watchdog: 1. Takes a git snapshot (file hashes) every 5 minutes 2. If two consecutive snapshots are identical AND the process is still running → stalled 3. Stalled sessions get killed and the task gets flagged in Linear with a comment explaining what happened ### 4. Verification Gate When a worker reports done (or hits max-turns), the manager: 1. **Checks the diff**: `git diff main...task-branch` — if empty, task failed 2. **Runs the build**: `cd worktree && pnpm turbo build` — must exit 0 3. **Runs type-check**: `pnpm turbo type-check` — must exit 0 4. **Runs tests**: `pnpm turbo test` — must exit 0 5. **Checks test coverage delta**: new code should have tests (count test files added vs source files added) 6. **Reads the worker's output**: parse the structured JSON result 7. **Opens the changed files and reviews them**: I (Ace, the manager) actually read the diff and judge quality — this is the "automation discovers, Ace judges" rule If any gate fails: log the failure, post a Linear comment, and either retry with a more specific prompt or flag for Junwon. ### 5. Reporting After each worker completes: - Update the Linear issue with: what was done, what files changed, test results, verification status - If verified: create a PR with a clean description - If failed: comment on Linear with the failure reason and what the worker actually did Daily summary email to Junwon: - Tasks attempted, completed, failed - Token usage and cost - PRs ready for review - Blocked tasks needing input ## Implementation: What We Build ### Phase 0: Worker Rules + Spec Template (Day 1) Create `worker-rules.md` — the system prompt injected into every worker session. This is the most important piece. A worker that doesn't follow rules wastes tokens. Create `spec-template.md` — standardized format for task specs that workers can parse reliably. ### Phase 1: Manager Script (Day 1-2) `domains/palacering/manager/manager.ts` — the orchestrator: ``` manager.ts ├── intake.ts — pull from Linear, generate specs ├── dispatch.ts — spawn workers, manage worktrees ├── monitor.ts — watchdog loop, stall detection ├── verify.ts — run verification gates └── report.ts — Linear comments, PR creation, email summary ``` Runs as a launchd daemon. Uses ClaudeBridge pattern but adapted for worker management (multiple concurrent bridges, each in a worktree). ### Phase 2: First Workers (Day 2-3) Start with the simplest coding tasks to validate the pipeline: - MAN-51 (tasks-tree-viewer.html improvements) - MAN-41 (Palace Fate — remaining items) These are contained, testable, low-risk. If a worker breaks something, the blast radius is small. ### Phase 3: Full Pipeline (Day 3+) Once Phase 2 validates the flow: - Spec and dispatch larger PalaceApp tasks - Run multiple workers concurrently during off-peak hours - Scale up to 3-5 concurrent sessions ## Task Queue (What to Advance) Current coding tasks by priority: | Task | Project | Scope | Risk | Priority | |------|---------|-------|------|----------| | MAN-3 | palaceapp | Build the dev pipeline itself | Meta — this IS the pipeline | Bootstrap | | MAN-57 | default | Publish Palace Apps | Deployment, multi-app | High | | MAN-41 | palacelab | Palace Fate (downloadable, topics, ads) | Web features | High | | MAN-51 | default | Tasks tree viewer | Frontend, self-contained | Medium | | MAN-42 | palacelab | Add palaceschool | New app, greenfield | Medium | | MAN-43 | palacelab | Wireframing skill (Penpot MCP) | Tool integration | Low (blocked on Penpot) | ## Key Risks 1. **Token waste on stuck workers**: Mitigated by watchdog + max-turns. Budget a 30% waste rate initially, optimize down. 2. **Workers producing garbage**: Mitigated by verification gate + my review of every diff. No PR gets opened without Ace reading the code. 3. **Workers conflicting**: Mitigated by worktree isolation. Each worker is on its own branch. 4. **Specs too vague**: If I can't write a clear spec from the Linear issue, I ask Junwon before dispatching. No vague specs to workers. 5. **Off-peak timing**: Doubled capacity is 11 AM-5 AM PT. Schedule heavy dispatch for these hours. Light work during 5-11 AM PT. ## What I Need From Junwon 1. **Confirm the architecture above** — any changes before I build? 2. **Prioritize the task queue** — which coding tasks should workers tackle first? 3. **PR review cadence** — how quickly can you review PRs? Workers are blocked until PRs merge for dependent tasks. 4. **Budget ceiling** — any max daily spend you want me to stay under? 5. **palaceapp repo access** — the submodule needs to be pullable for workers. Confirm the repo is set up for worktree branching.