docs: initialize Codewalk District
Multi-agent workspace for orchestrating Claude Code agents with task breakdown, worktree management, and fsui. Creates PROJECT.md with requirements and constraints.
This commit is contained in:
71
.planning/PROJECT.md
Normal file
71
.planning/PROJECT.md
Normal file
@@ -0,0 +1,71 @@
|
||||
# Codewalk District
|
||||
|
||||
## What This Is
|
||||
|
||||
A multi-agent workspace for orchestrating multiple Claude Code agents. Manages task breakdown, work coordination, and git worktrees so agents don't collide. Replaces manually juggling terminal sessions where you lose track of what each agent is doing.
|
||||
|
||||
## Core Value
|
||||
|
||||
**Coordinate multiple Claude Code agents without losing track or stepping on each other.**
|
||||
|
||||
If everything else fails, this must work: spawn agents, assign work, know what's happening, don't corrupt the repo.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Validated
|
||||
|
||||
(None yet — ship to validate)
|
||||
|
||||
### Active
|
||||
|
||||
- [ ] **Task breakdown system** — GSD-style initiative → phases → plans → tasks with SQLite backing
|
||||
- [ ] **Orchestration layer** — spawn Claude Code agents, track running work, dispatch tasks from queue
|
||||
- [ ] **File system UI (fsui)** — bidirectional sync between SQLite and filesystem; agent messages appear as files, user responds by editing files
|
||||
- [ ] **Worktree management** — isolated git worktrees per agent; automatic setup/teardown; agents work in parallel without merge conflicts
|
||||
- [ ] **CLI `cw`** — single binary, server mode via `--server`, commands for tasks/initiatives/agents
|
||||
|
||||
### Out of Scope
|
||||
|
||||
- Web dashboard — fsui is the MVP interface, web UI comes later
|
||||
- Devcontainer preview instances — future feature for visual verification
|
||||
- Browser automation for agents — future feature for agents to verify their own work
|
||||
- Knowledge capture suggestions — future feature to auto-extend CLAUDE.md
|
||||
- Multi-user support — solo developer first, stub for future
|
||||
|
||||
## Context
|
||||
|
||||
**Pain point:** Running multiple Claude Code agents in separate terminals. Losing track of what each is doing. Hard to parallelize work. Agents collide on the same files. No central coordination.
|
||||
|
||||
**Reference implementations:**
|
||||
- `reference/gastown/` — Go-based agent workspace with worktree management, session handling
|
||||
- `reference/get-shit-done/` — Planning system with initiative → phase → plan → task breakdown
|
||||
|
||||
**Existing design docs:** Extensive documentation in `docs/` covering:
|
||||
- Task and initiative modules with SQLite schemas
|
||||
- Agent roles (Orchestrator, Worker, Architect, Verifier)
|
||||
- Context engineering (quality degrades predictably with context fill)
|
||||
- Deviation rules for agent autonomy
|
||||
- Verification patterns
|
||||
|
||||
**User workflow:** Solo developer orchestrating Claude Code for all implementation work. Needs to parallelize without chaos.
|
||||
|
||||
## Constraints
|
||||
|
||||
- **Language**: TypeScript — aligns with tRPC/React ecosystem, user preference
|
||||
- **API**: tRPC — type-safe API layer between CLI/agents and server
|
||||
- **Database**: SQLite — single file, no setup, sufficient for solo/small team
|
||||
- **Architecture**: Hexagonal with modular monolith — clear boundaries, swappable adapters
|
||||
- **Agent communication**: STDIO-based MCP — agents communicate via `cw mcp`
|
||||
- **CLI design**: Single `cw` binary serves as both CLI and server (`cw --server`)
|
||||
|
||||
## Key Decisions
|
||||
|
||||
| Decision | Rationale | Outcome |
|
||||
|----------|-----------|---------|
|
||||
| File system UI before web UI | Faster to build, editor is already the user's home, no frontend work for MVP | — Pending |
|
||||
| SQLite over distributed Git (beads) | All agents share same workspace, no need for distributed sync | — Pending |
|
||||
| TypeScript over Go | tRPC ecosystem, user preference, reference impl in Go is for learning not porting | — Pending |
|
||||
| Terminal inbox via fsui, not TUI | Less code, leverage existing editor, bidirectional fs sync already planned | — Pending |
|
||||
|
||||
---
|
||||
*Last updated: 2026-01-30 after initialization*
|
||||
26
.planning/config.json
Normal file
26
.planning/config.json
Normal file
@@ -0,0 +1,26 @@
|
||||
{
|
||||
"mode": "yolo",
|
||||
"depth": "comprehensive",
|
||||
"parallelization": {
|
||||
"enabled": true,
|
||||
"plan_level": true,
|
||||
"task_level": false,
|
||||
"skip_checkpoints": true,
|
||||
"max_concurrent_agents": 3,
|
||||
"min_plans_for_parallel": 2
|
||||
},
|
||||
"gates": {
|
||||
"confirm_project": false,
|
||||
"confirm_phases": false,
|
||||
"confirm_roadmap": false,
|
||||
"confirm_breakdown": false,
|
||||
"confirm_plan": false,
|
||||
"execute_next_plan": false,
|
||||
"issues_review": false,
|
||||
"confirm_transition": false
|
||||
},
|
||||
"safety": {
|
||||
"always_confirm_destructive": true,
|
||||
"always_confirm_external_services": true
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user