@matt82198/aesop 0.1.0 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +89 -2
- package/README.md +63 -12
- package/bin/cli.js +164 -41
- package/daemons/run-watchdog.sh +16 -4
- package/daemons/selfheal.sh +231 -0
- package/docs/ANY-REPO.md +427 -0
- package/docs/CONTRIBUTING.md +72 -0
- package/docs/DEMO.md +334 -0
- package/docs/INSTALL.md +70 -1
- package/docs/QUICKSTART.md +80 -0
- package/docs/README.md +33 -3
- package/docs/TEAM-STATE.md +540 -0
- package/driver/CLAUDE.md +148 -0
- package/driver/README.md +383 -0
- package/driver/aesop.config.example.json +80 -0
- package/driver/agent_driver.py +355 -0
- package/driver/backend_config.py +253 -0
- package/driver/claude_code_driver.py +198 -0
- package/driver/codex_driver.py +626 -0
- package/driver/openai_compatible_driver.py +249 -0
- package/driver/openai_transport.py +146 -0
- package/driver/verification_policy.py +75 -0
- package/driver/wave_bridge.py +246 -0
- package/driver/wave_loop.py +1041 -0
- package/hooks/pre-push-policy.sh +109 -28
- package/mcp/server.mjs +320 -4
- package/package.json +23 -15
- package/skills/CLAUDE.md +132 -2
- package/skills/buildsystem/SKILL.md +330 -0
- package/skills/buildsystem/wave-flat-dispatch.template.mjs +658 -0
- package/skills/fleet/SKILL.md +113 -0
- package/skills/power/SKILL.md +246 -131
- package/state_store/__init__.py +2 -1
- package/state_store/api.py +19 -4
- package/state_store/coordination.py +209 -0
- package/state_store/identity.py +51 -0
- package/state_store/store.py +185 -73
- package/templates/wave-presets/data.json +65 -0
- package/templates/wave-presets/library.json +65 -0
- package/templates/wave-presets/saas.json +64 -0
- package/tools/audit_report.py +388 -0
- package/tools/bench_runner.py +100 -3
- package/tools/ci_merge_wait.py +256 -35
- package/tools/ci_workflow_lint.py +430 -0
- package/tools/claudemd_drift.py +394 -0
- package/tools/claudemd_lint.py +359 -0
- package/tools/common.py +39 -3
- package/tools/cost_ceiling.py +63 -31
- package/tools/cost_econ.py +480 -0
- package/tools/defect_escape.py +252 -0
- package/tools/doctor.js +1 -1
- package/tools/eod_sweep.py +58 -0
- package/tools/fleet.js +260 -0
- package/tools/fleet_ledger.py +209 -7
- package/tools/git_identity_check.py +315 -0
- package/tools/health-score.js +40 -0
- package/tools/health_score.py +361 -0
- package/tools/metrics_gate.py +13 -4
- package/tools/mutation_test.py +401 -0
- package/tools/portability_check.py +206 -0
- package/tools/reconcile.py +7 -4
- package/tools/secret_scan.py +137 -50
- package/tools/self_stats.py +20 -0
- package/tools/transcript_digest.py +380 -0
- package/tools/verify_activity_filter.py +437 -0
- package/tools/verify_agent_inspector.py +2 -0
- package/tools/verify_dash.py +2 -0
- package/tools/verify_dispatch_panel.py +301 -0
- package/tools/verify_failure_drilldown.py +188 -0
- package/tools/verify_prboard.py +2 -0
- package/tools/verify_scorecards.py +281 -0
- package/tools/verify_submit_encoding.py +2 -0
- package/tools/verify_ui_trio.py +409 -0
- package/tools/verify_wave_telemetry.py +268 -0
- package/tools/wave_backlog_analyzer.py +490 -0
- package/tools/wave_ledger_hook.py +150 -0
- package/tools/wave_preflight.py +512 -0
- package/tools/wave_resume.py +215 -0
- package/tools/wave_templates.py +215 -0
- package/ui/agents.py +68 -14
- package/ui/collectors.py +0 -55
- package/ui/config.py +7 -2
- package/ui/cost.py +231 -12
- package/ui/handler.py +183 -0
- package/ui/quality_scorecard.py +232 -0
- package/ui/wave_audit_tail.py +213 -0
- package/ui/wave_dispatch.py +280 -0
- package/ui/wave_failure.py +288 -0
- package/ui/wave_gantt.py +152 -0
- package/ui/wave_reasoning_tail.py +176 -0
- package/ui/wave_telemetry.py +377 -0
- package/ui/web/dist/assets/index-BGbgw2Nh.js +9 -0
- package/ui/web/dist/assets/index-DqZLgwNg.css +1 -0
- package/ui/web/dist/index.html +2 -2
- package/bin/CLAUDE.md +0 -76
- package/daemons/CLAUDE.md +0 -36
- package/dash/CLAUDE.md +0 -32
- package/docs/archive/README.md +0 -3
- package/docs/archive/spikes/tiered-cognition/ACTIVATION.md +0 -125
- package/docs/archive/spikes/tiered-cognition/DESIGN.md +0 -287
- package/docs/archive/spikes/tiered-cognition/FINDINGS.md +0 -113
- package/docs/archive/spikes/tiered-cognition/README.md +0 -27
- package/docs/archive/spikes/tiered-cognition/aesop-cognition.example.md +0 -32
- package/docs/archive/spikes/tiered-cognition/force-model-policy.merged.mjs +0 -673
- package/docs/archive/spikes/tiered-cognition/strip-tools-hook.mjs +0 -434
- package/hooks/CLAUDE.md +0 -89
- package/mcp/CLAUDE.md +0 -213
- package/monitor/CLAUDE.md +0 -40
- package/scan/CLAUDE.md +0 -30
- package/state_store/CLAUDE.md +0 -39
- package/tools/CLAUDE.md +0 -79
- package/ui/CLAUDE.md +0 -127
- package/ui/web/dist/assets/index-0qQYnvMC.js +0 -9
- package/ui/web/dist/assets/index-BdIlFieV.css +0 -1
|
@@ -0,0 +1,72 @@
|
|
|
1
|
+
# Contributing to Aesop
|
|
2
|
+
|
|
3
|
+
Aesop is **source-available** under the [PolyForm Strict License 1.0.0](../LICENSE). You may read, run, and use the software for any permitted purpose (noncommercial, personal, or organizational research), but **modification and redistribution are not permitted**.
|
|
4
|
+
|
|
5
|
+
## Contribution Policy
|
|
6
|
+
|
|
7
|
+
**Outside code patches cannot be merged as contributions** due to license terms. However, feedback and collaboration are genuinely welcome:
|
|
8
|
+
|
|
9
|
+
- **Issues and bug reports** — describe what's broken or confusing.
|
|
10
|
+
- **Discussion and ideas** — feature requests, design critiques, use-case questions.
|
|
11
|
+
- **Code snapshots for discussion** — propose changes in issues or discussions without expecting merge.
|
|
12
|
+
|
|
13
|
+
Code changes are made by the maintainer at their discretion. If you'd like to propose a change, open an issue first — describe the problem, your approach, and why it matters.
|
|
14
|
+
|
|
15
|
+
## Running the Test Suites
|
|
16
|
+
|
|
17
|
+
Aesop has three test suites:
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
# Node.js tests (orchestration skills, monitor, UI API)
|
|
21
|
+
npm run test:node
|
|
22
|
+
|
|
23
|
+
# Python tests (state_store, log rotation, secret-scan)
|
|
24
|
+
npm run test:py
|
|
25
|
+
|
|
26
|
+
# Bash tests (daemons, watchdog, hook policy)
|
|
27
|
+
npm run test:sh
|
|
28
|
+
|
|
29
|
+
# All suites
|
|
30
|
+
npm run test:all
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Each suite is self-contained and idempotent. Run them before proposing any changes.
|
|
34
|
+
|
|
35
|
+
## Workflow (for Maintainers)
|
|
36
|
+
|
|
37
|
+
Aesop develops itself via its own `/buildsystem` wave cycle. The process:
|
|
38
|
+
|
|
39
|
+
1. **One issue per branch** — `feature/issue-name` branches only (never main).
|
|
40
|
+
2. **Commit and push** — each commit triggers the pre-push hook.
|
|
41
|
+
3. **Secret-scan gate** — `hooks/pre-push-policy.sh` blocks any credentials before they leave your machine.
|
|
42
|
+
4. **Pull request** — PR runs CI and waits for merge-train coordination.
|
|
43
|
+
5. **Checkpoint** — STATE.md and BUILDLOG.md capture wave state; both are git-committed and survive wipes.
|
|
44
|
+
|
|
45
|
+
See [docs/ARCHITECTURE.md](./ARCHITECTURE.md) for the wave cycle diagram and [docs/HOW-THE-LOOP-WORKS.md](./HOW-THE-LOOP-WORKS.md) for a concrete walkthrough.
|
|
46
|
+
|
|
47
|
+
## Code Style
|
|
48
|
+
|
|
49
|
+
**Python**: Stdlib-first (no external deps except asyncio). Docstrings required; snake_case for functions and variables. See `tools/secret_scan.py` and `state_store/` for examples.
|
|
50
|
+
|
|
51
|
+
**Node.js/JavaScript**: Node stdlib for tooling only (no external packages). Use async/await. See `daemons/`, `monitor/`, and `bin/` for patterns.
|
|
52
|
+
|
|
53
|
+
**Bash**: POSIX-safe (no Bashisms; works in Git Bash on Windows). Sourceable scripts must guard with `[[ "${BASH_SOURCE[0]}" == "${0}" ]]`. See `hooks/pre-push-policy.sh` for structure.
|
|
54
|
+
|
|
55
|
+
## Attribution
|
|
56
|
+
|
|
57
|
+
Commits are authored with your git user.name. The repo signs all commits and uses co-author trailers for multi-person changes:
|
|
58
|
+
|
|
59
|
+
```
|
|
60
|
+
git commit -m "message
|
|
61
|
+
|
|
62
|
+
Co-Authored-By: Alice <alice@example.com>
|
|
63
|
+
Co-Authored-By: Bob <bob@example.com>"
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## License & DCO
|
|
67
|
+
|
|
68
|
+
By proposing changes, you affirm that you own or have the right to contribute your work and agree to license it under PolyForm Strict 1.0.0. See [LICENSE](../LICENSE) for the full terms.
|
|
69
|
+
|
|
70
|
+
## Questions?
|
|
71
|
+
|
|
72
|
+
Open an issue or discussion on GitHub. Read [docs/GOVERNANCE.md](./GOVERNANCE.md) for details on the decision-making process and [docs/RELIABILITY.md](./RELIABILITY.md) for the engineering principles behind Aesop.
|
package/docs/DEMO.md
ADDED
|
@@ -0,0 +1,334 @@
|
|
|
1
|
+
# Init-Prime-Demo: Your First Complete Aesop Flow
|
|
2
|
+
|
|
3
|
+
**TL;DR**: This 10-minute walkthrough takes you from nothing to a working orchestration harness, primed and ready for your first wave.
|
|
4
|
+
|
|
5
|
+
Covered in this demo:
|
|
6
|
+
1. Create a toy project (just a git repo)
|
|
7
|
+
2. Scaffold Aesop into a fleet harness
|
|
8
|
+
3. Run `/power` to prime the orchestrator
|
|
9
|
+
4. Understand what happens next
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
|
|
13
|
+
## What You'll Need
|
|
14
|
+
|
|
15
|
+
Before starting, ensure you have:
|
|
16
|
+
|
|
17
|
+
- **Node.js** v18+ (for scaffolder and CLI)
|
|
18
|
+
- **Git** v2.40+ (for repo setup)
|
|
19
|
+
- **Bash** v4+ (for daemons; Windows: Git Bash)
|
|
20
|
+
- **Claude Code CLI** v0.1+ (for `/power` and `/buildsystem` skills)
|
|
21
|
+
|
|
22
|
+
Check versions:
|
|
23
|
+
```bash
|
|
24
|
+
node --version
|
|
25
|
+
git --version
|
|
26
|
+
bash --version
|
|
27
|
+
claude --version
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
---
|
|
31
|
+
|
|
32
|
+
## Step 1: Create a Toy Project (2 min)
|
|
33
|
+
|
|
34
|
+
This simulates a real project that Aesop will manage.
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
# Create a new directory and initialize git
|
|
38
|
+
mkdir ~/my-demo-project
|
|
39
|
+
cd ~/my-demo-project
|
|
40
|
+
git init
|
|
41
|
+
|
|
42
|
+
# Configure git (required for commits)
|
|
43
|
+
git config user.email "demo@aesop.test"
|
|
44
|
+
git config user.name "Demo User"
|
|
45
|
+
|
|
46
|
+
# Create a sample file and make an initial commit
|
|
47
|
+
echo "# My Demo Project" > README.md
|
|
48
|
+
git add README.md
|
|
49
|
+
git commit -m "Initial commit"
|
|
50
|
+
```
|
|
51
|
+
|
|
52
|
+
Your toy project is now ready. It's a clean git repo with one commit.
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## Step 2: Scaffold Aesop (2 min)
|
|
57
|
+
|
|
58
|
+
Create a fleet harness in a separate directory. The harness orchestrates your project(s).
|
|
59
|
+
|
|
60
|
+
```bash
|
|
61
|
+
# Go to a working directory (e.g., your home or ~/projects)
|
|
62
|
+
cd ~
|
|
63
|
+
|
|
64
|
+
# Scaffold Aesop (creates ~/demo-fleet/)
|
|
65
|
+
npx @matt82198/aesop demo-fleet \
|
|
66
|
+
--name "demo-fleet" \
|
|
67
|
+
--repos "~/my-demo-project" \
|
|
68
|
+
--yes
|
|
69
|
+
|
|
70
|
+
# Move into the harness
|
|
71
|
+
cd ~/demo-fleet
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
What this does:
|
|
75
|
+
- Creates `daemons/`, `skills/`, `monitor/`, `tools/`, `ui/`, `docs/` subdirectories
|
|
76
|
+
- Generates `aesop.config.json` with your project path
|
|
77
|
+
- Creates `CLAUDE.md` (orchestrator brain template)
|
|
78
|
+
- Installs a git pre-push hook for secret scanning
|
|
79
|
+
- Initializes a git repo in the harness
|
|
80
|
+
|
|
81
|
+
Expected output:
|
|
82
|
+
```
|
|
83
|
+
✓ Creating ~/demo-fleet...
|
|
84
|
+
✓ Copying scaffold files...
|
|
85
|
+
✓ Generating CLAUDE.md...
|
|
86
|
+
✓ Generating aesop.config.json...
|
|
87
|
+
✓ Installing pre-push hook...
|
|
88
|
+
✓ Initializing git repo...
|
|
89
|
+
|
|
90
|
+
Next steps:
|
|
91
|
+
1. cd ~/demo-fleet
|
|
92
|
+
2. npx @matt82198/aesop doctor # Verify preflight checks
|
|
93
|
+
3. /power # Prime orchestrator brain
|
|
94
|
+
4. /buildsystem # Run your first wave
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
---
|
|
98
|
+
|
|
99
|
+
## Step 3: Verify Installation (1 min)
|
|
100
|
+
|
|
101
|
+
Run preflight checks to ensure everything is ready.
|
|
102
|
+
|
|
103
|
+
```bash
|
|
104
|
+
npx @matt82198/aesop doctor
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Expected output:
|
|
108
|
+
```
|
|
109
|
+
[doctor] Checking prerequisites...
|
|
110
|
+
✓ Node.js v18.14.0 found
|
|
111
|
+
✓ Git v2.42.0 found
|
|
112
|
+
✓ Bash v5.1.16 found
|
|
113
|
+
✓ Python v3.11.0 found (optional)
|
|
114
|
+
✓ aesop.config.json is readable
|
|
115
|
+
✓ Pre-push hook is installed and executable
|
|
116
|
+
✓ Port 8770 is available (for dashboard)
|
|
117
|
+
|
|
118
|
+
All checks passed. Ready to start.
|
|
119
|
+
```
|
|
120
|
+
|
|
121
|
+
If you see warnings about missing optional tools (Python, jq), that's OK for this demo. You can install them later.
|
|
122
|
+
|
|
123
|
+
---
|
|
124
|
+
|
|
125
|
+
## Step 4: Prime the Orchestrator (/power) (3 min)
|
|
126
|
+
|
|
127
|
+
Now open Claude Code and invoke the `/power` skill. This reads your configuration and verifies the orchestrator is healthy.
|
|
128
|
+
|
|
129
|
+
```
|
|
130
|
+
/power
|
|
131
|
+
```
|
|
132
|
+
|
|
133
|
+
What `/power` does:
|
|
134
|
+
1. Reads `~/.claude/CLAUDE.md` (your global orchestrator rules)
|
|
135
|
+
2. Reads `aesop.config.json` (your fleet configuration)
|
|
136
|
+
3. Checks `state/STATE.md` (current phase and next steps)
|
|
137
|
+
4. Validates that daemons are healthy (checks heartbeat files)
|
|
138
|
+
5. Reports a health brief
|
|
139
|
+
|
|
140
|
+
Expected output:
|
|
141
|
+
```
|
|
142
|
+
Orchestrator Brain Loaded
|
|
143
|
+
|
|
144
|
+
✓ Global rules (CLAUDE.md) loaded
|
|
145
|
+
✓ Fleet config (aesop.config.json) loaded
|
|
146
|
+
- 1 repo configured: my-demo-project
|
|
147
|
+
- Brain root: ~/.claude
|
|
148
|
+
- State root: ~/demo-fleet/state
|
|
149
|
+
✓ Fleet daemons: healthy (watchdog heartbeat ~30s old)
|
|
150
|
+
✓ STATE.md initialized: Phase 1, ready for backlog
|
|
151
|
+
|
|
152
|
+
NEXT STEPS:
|
|
153
|
+
(1) Create a backlog (P1/P2 tasks)
|
|
154
|
+
(2) Run /buildsystem to execute a complete wave cycle
|
|
155
|
+
```
|
|
156
|
+
|
|
157
|
+
If you see errors about missing CLAUDE.md or heartbeat files, don't worry—they'll be created on first startup. Re-run `/power` after a few seconds.
|
|
158
|
+
|
|
159
|
+
---
|
|
160
|
+
|
|
161
|
+
## Step 5: Understand the Backlog (Optional, 2 min)
|
|
162
|
+
|
|
163
|
+
Before running your first wave, you need a backlog of work. The orchestrator dispatches agents to complete these tasks.
|
|
164
|
+
|
|
165
|
+
Example backlog:
|
|
166
|
+
```markdown
|
|
167
|
+
## Wave 1 Backlog
|
|
168
|
+
|
|
169
|
+
- **P1: Add setup documentation** (backend-dev) — Document the initial setup process
|
|
170
|
+
- **P2: Fix README formatting** (docs-agent) — Improve readability of README.md
|
|
171
|
+
- **P3: Add a test scaffold** (test-bot) — Create tests/ directory with example test
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
Each task should:
|
|
175
|
+
- Fit in 5–15 minutes for a Haiku agent
|
|
176
|
+
- Be scoped (not "refactor everything")
|
|
177
|
+
- Have a priority (P1=blocker, P2=quality, P3=tech debt)
|
|
178
|
+
- Be assigned to an agent type
|
|
179
|
+
|
|
180
|
+
For this demo, you can skip this step and just observe what `/buildsystem` would do. Or create 2–3 simple tasks.
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
|
|
184
|
+
## Step 6: Run Your First Wave (Optional, 10+ min)
|
|
185
|
+
|
|
186
|
+
Once you have a backlog, invoke `/buildsystem` in Claude Code:
|
|
187
|
+
|
|
188
|
+
```
|
|
189
|
+
/buildsystem
|
|
190
|
+
```
|
|
191
|
+
|
|
192
|
+
What `/buildsystem` does:
|
|
193
|
+
1. **Rank & Assign** — Reads your backlog, assigns agents to tasks
|
|
194
|
+
2. **Dispatch Fleet** — Spawns 3–8 Haiku agents in parallel worktrees
|
|
195
|
+
3. **Execute** — Each agent works on its task independently
|
|
196
|
+
4. **Verify** — Runs tests, checks compilation, validates changes
|
|
197
|
+
5. **Merge Train** — Commits and pushes completed tasks
|
|
198
|
+
6. **Checkpoint** — Saves state (STATE.md, BUILDLOG.md)
|
|
199
|
+
|
|
200
|
+
You'll see live updates as agents work. Each task runs in isolation (no conflicts).
|
|
201
|
+
|
|
202
|
+
Expected output:
|
|
203
|
+
```
|
|
204
|
+
Wave 1 / Rank & Assign
|
|
205
|
+
✓ Task 1: Add setup documentation (backend-dev)
|
|
206
|
+
✓ Task 2: Fix README formatting (docs-agent)
|
|
207
|
+
✓ Task 3: Add test scaffold (test-bot)
|
|
208
|
+
→ Dispatching 3 Haiku agents (est. 45–60 min)...
|
|
209
|
+
|
|
210
|
+
[Agent 1: backend-dev] Working on Task 1...
|
|
211
|
+
[Agent 2: docs-agent] Working on Task 2...
|
|
212
|
+
[Agent 3: test-bot] Working on Task 3...
|
|
213
|
+
|
|
214
|
+
Wave 1 / Merge Train
|
|
215
|
+
✓ All agents completed
|
|
216
|
+
✓ 3 PRs created
|
|
217
|
+
✓ All tests passed
|
|
218
|
+
✓ Merging to main...
|
|
219
|
+
|
|
220
|
+
Wave 1 Complete
|
|
221
|
+
Duration: 47 minutes
|
|
222
|
+
Cost: 3,200 tokens
|
|
223
|
+
Files changed: 12
|
|
224
|
+
NEXT STEPS: Review BUILDLOG.md, run Wave 2 if needed
|
|
225
|
+
```
|
|
226
|
+
|
|
227
|
+
---
|
|
228
|
+
|
|
229
|
+
## What Happened?
|
|
230
|
+
|
|
231
|
+
You just ran a complete Aesop wave cycle:
|
|
232
|
+
|
|
233
|
+
1. **Orchestrator** (you) → defined the backlog
|
|
234
|
+
2. **Dispatch** (Aesop) → analyzed tasks, assigned agents
|
|
235
|
+
3. **Execution** → 3+ Haiku agents worked in parallel (each in their own worktree)
|
|
236
|
+
4. **Verification** → tests passed, code reviewed, merged
|
|
237
|
+
5. **Checkpoint** → progress saved to `state/STATE.md` and `state/BUILDLOG.md`
|
|
238
|
+
|
|
239
|
+
Each wave is independent. You can run wave 2 with a new backlog, or pause and review results.
|
|
240
|
+
|
|
241
|
+
---
|
|
242
|
+
|
|
243
|
+
## Exploring the Harness
|
|
244
|
+
|
|
245
|
+
Now that you've seen it work, explore:
|
|
246
|
+
|
|
247
|
+
### 1. Check the state files
|
|
248
|
+
```bash
|
|
249
|
+
cat state/STATE.md # Current phase and next steps
|
|
250
|
+
cat state/BUILDLOG.md # Append-only progress log
|
|
251
|
+
```
|
|
252
|
+
|
|
253
|
+
### 2. View the dashboard (optional)
|
|
254
|
+
```bash
|
|
255
|
+
npx @matt82198/aesop dash # Launches http://localhost:8770
|
|
256
|
+
```
|
|
257
|
+
|
|
258
|
+
Monitor waves in real-time: see active agents, heartbeats, logs, and costs.
|
|
259
|
+
|
|
260
|
+
### 3. Check the daemons
|
|
261
|
+
```bash
|
|
262
|
+
ls -la daemons/
|
|
263
|
+
bash daemons/run-watchdog.sh --once # Run watchdog once (no daemon)
|
|
264
|
+
```
|
|
265
|
+
|
|
266
|
+
The watchdog handles backup, secret scanning, and fleet health checks.
|
|
267
|
+
|
|
268
|
+
### 4. Review the configuration
|
|
269
|
+
```bash
|
|
270
|
+
cat aesop.config.json # Your fleet configuration
|
|
271
|
+
cat CLAUDE.md # Orchestrator brain (domain map, rules)
|
|
272
|
+
```
|
|
273
|
+
|
|
274
|
+
---
|
|
275
|
+
|
|
276
|
+
## Scaling to Real Projects
|
|
277
|
+
|
|
278
|
+
Once you're comfortable with the demo flow, you can:
|
|
279
|
+
|
|
280
|
+
1. **Add more repos** — Edit `aesop.config.json` and list your real projects
|
|
281
|
+
2. **Customize domains** — Edit `CLAUDE.md` to define your team structure
|
|
282
|
+
3. **Tune the backlog** — Work with your team to prioritize tasks
|
|
283
|
+
4. **Run continuous waves** — Schedule `/buildsystem` to run on a cadence
|
|
284
|
+
5. **Set cost ceilings** — Add spending limits to prevent runaway bills
|
|
285
|
+
|
|
286
|
+
See [CONFIGURE.md](CONFIGURE.md) and [INSTALL.md](INSTALL.md) for full details.
|
|
287
|
+
|
|
288
|
+
---
|
|
289
|
+
|
|
290
|
+
## Troubleshooting
|
|
291
|
+
|
|
292
|
+
**Q: `/power` says "CLAUDE.md not found"**
|
|
293
|
+
- A: Copy the skills to your Claude Code home:
|
|
294
|
+
```bash
|
|
295
|
+
cp -r skills/power ~/.claude/skills/
|
|
296
|
+
cp -r skills/buildsystem ~/.claude/skills/
|
|
297
|
+
```
|
|
298
|
+
|
|
299
|
+
**Q: `aesop doctor` reports missing Python**
|
|
300
|
+
- A: Python is optional for the demo. If you want secret scanning or log rotation, install it:
|
|
301
|
+
```bash
|
|
302
|
+
python3 --version # Check if installed
|
|
303
|
+
pip install pyyaml # If needed
|
|
304
|
+
```
|
|
305
|
+
|
|
306
|
+
**Q: Watchdog fails with "not inside a git repository"**
|
|
307
|
+
- A: Make sure you've run the scaffold from a location with git installed and initialized. Re-run scaffold:
|
|
308
|
+
```bash
|
|
309
|
+
npx @matt82198/aesop demo-fleet --yes
|
|
310
|
+
```
|
|
311
|
+
|
|
312
|
+
**Q: Dashboard won't open (port 8770 in use)**
|
|
313
|
+
- A: The scaffold will use the next available port (8771, 8772, etc). Check `aesop.config.json` for the actual port.
|
|
314
|
+
|
|
315
|
+
See [INSTALL.md](INSTALL.md) for more troubleshooting and [CONCEPTS.md](CONCEPTS.md) for deeper understanding.
|
|
316
|
+
|
|
317
|
+
---
|
|
318
|
+
|
|
319
|
+
## Next Steps
|
|
320
|
+
|
|
321
|
+
1. **Run the full test suite** — Verify everything works:
|
|
322
|
+
```bash
|
|
323
|
+
npm run test:all
|
|
324
|
+
```
|
|
325
|
+
|
|
326
|
+
2. **Read [FIRST-WAVE.md](FIRST-WAVE.md)** — Deep dive into the wave cycle
|
|
327
|
+
|
|
328
|
+
3. **Explore [CONCEPTS.md](CONCEPTS.md)** — Understand the dispatch model and state architecture
|
|
329
|
+
|
|
330
|
+
4. **Add your real repos** — Scale from demo to production
|
|
331
|
+
|
|
332
|
+
5. **Set up continuous integration** — Schedule waves to run automatically
|
|
333
|
+
|
|
334
|
+
Enjoy! 🚀
|
package/docs/INSTALL.md
CHANGED
|
@@ -33,7 +33,7 @@ The fastest way to get started is to use the Aesop template scaffolder. It creat
|
|
|
33
33
|
### Step 1: Scaffold the harness
|
|
34
34
|
|
|
35
35
|
```bash
|
|
36
|
-
npx @matt82198/aesop
|
|
36
|
+
npx @matt82198/aesop my-fleet \
|
|
37
37
|
--name "my-api" \
|
|
38
38
|
--repos "/path/to/repo1,/path/to/repo2"
|
|
39
39
|
```
|
|
@@ -196,6 +196,75 @@ export DEBUG=1
|
|
|
196
196
|
|
|
197
197
|
---
|
|
198
198
|
|
|
199
|
+
## Using Non-Claude Backends
|
|
200
|
+
|
|
201
|
+
By default, Aesop uses Claude Code (the orchestration harness) as its backend. You can configure it to use other models via the **AgentDriver abstraction**—enabling Ollama, OpenAI-compatible endpoints, OpenRouter, and more.
|
|
202
|
+
|
|
203
|
+
### Configure a backend in aesop.config.json
|
|
204
|
+
|
|
205
|
+
Add or modify the `backend` section:
|
|
206
|
+
|
|
207
|
+
```json
|
|
208
|
+
{
|
|
209
|
+
"backend": "openai-compatible",
|
|
210
|
+
"model": "ollama-mistral",
|
|
211
|
+
"base_url": "http://localhost:11434/v1",
|
|
212
|
+
"api_key_env": "OLLAMA_API_KEY"
|
|
213
|
+
}
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
Supported backends:
|
|
217
|
+
- `"claude"` (default) — Claude Code CLI harness
|
|
218
|
+
- `"openai-compatible"` — OpenAI Chat Completions API (Ollama, OpenRouter, etc.)
|
|
219
|
+
- `"codex"` — CodeX OpenAI backend (legacy)
|
|
220
|
+
|
|
221
|
+
### Example: Local Ollama
|
|
222
|
+
|
|
223
|
+
To run Aesop against Mistral locally via Ollama:
|
|
224
|
+
|
|
225
|
+
```bash
|
|
226
|
+
# 1. Install Ollama (https://ollama.ai) and start the daemon
|
|
227
|
+
ollama serve
|
|
228
|
+
|
|
229
|
+
# 2. In another terminal, pull a model
|
|
230
|
+
ollama pull mistral
|
|
231
|
+
|
|
232
|
+
# 3. Configure Aesop to use it
|
|
233
|
+
cat > aesop.config.json <<EOF
|
|
234
|
+
{
|
|
235
|
+
"backend": "openai-compatible",
|
|
236
|
+
"model": "mistral",
|
|
237
|
+
"base_url": "http://localhost:11434/v1",
|
|
238
|
+
"api_key_env": "OLLAMA_API_KEY"
|
|
239
|
+
}
|
|
240
|
+
EOF
|
|
241
|
+
|
|
242
|
+
# 4. Start Aesop (it will use Mistral for subagent dispatch)
|
|
243
|
+
npx @matt82198/aesop my-fleet --name "my-api"
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
### Verification tiers: weaker backends get more checking
|
|
247
|
+
|
|
248
|
+
The AgentDriver framework applies **honest verification tiers** — weaker backends (lower accuracy, no structured output) trigger stronger verification in the orchestrator:
|
|
249
|
+
|
|
250
|
+
| Backend | Accuracy | Verification Tier | What it means |
|
|
251
|
+
|---------|----------|-------------------|---------------|
|
|
252
|
+
| Claude Code | ~0.99 | 1 (minimal) | Orchestrator trusts output; spot-check tests |
|
|
253
|
+
| OpenAI (GPT-4) | ~0.95 | 2 | Validate all JSON, run full test suite |
|
|
254
|
+
| Ollama (Mistral) | ~0.70 | 4 (maximum) | Validate all JSON, adversarial review, expensive repair cap |
|
|
255
|
+
|
|
256
|
+
Lower tiers cost less but require more orchestrator work. See [driver/README.md](../driver/README.md) for full verification-policy details.
|
|
257
|
+
|
|
258
|
+
### Troubleshooting
|
|
259
|
+
|
|
260
|
+
**Backend won't connect**: Check `OLLAMA_API_KEY` (or your backend's API key env var) is set and the `base_url` is reachable.
|
|
261
|
+
|
|
262
|
+
**Verification tier too strict**: If your backend is over-verified (tier 4 when it should be tier 2), update `probe_capabilities()` in the driver to report higher accuracy scores honestly.
|
|
263
|
+
|
|
264
|
+
For more details, see [driver/README.md](../driver/README.md).
|
|
265
|
+
|
|
266
|
+
---
|
|
267
|
+
|
|
199
268
|
## Pre-push Hook Installation
|
|
200
269
|
|
|
201
270
|
The `npx` scaffold installs the pre-push hook automatically. If you cloned the repo manually, install it:
|
|
@@ -0,0 +1,80 @@
|
|
|
1
|
+
# Quickstart: 5 Minutes to Your First Wave
|
|
2
|
+
|
|
3
|
+
Get from `npx @matt82198/aesop` to a working wave cycle: scaffold, verify, run the orchestrator skills, and watch it work.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## Step 1: Scaffold
|
|
8
|
+
|
|
9
|
+
```bash
|
|
10
|
+
cd ~/my-repo
|
|
11
|
+
npx @matt82198/aesop .
|
|
12
|
+
```
|
|
13
|
+
|
|
14
|
+
Or if your repo is new:
|
|
15
|
+
```bash
|
|
16
|
+
npx @matt82198/aesop my-fleet && cd my-fleet
|
|
17
|
+
```
|
|
18
|
+
|
|
19
|
+
This installs daemons, skills, config, and a pre-push hook. Edit `aesop.config.json` to add repos.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## Step 2: Verify & Test
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
npx @matt82198/aesop doctor # Preflight: Git, Node, Python, CLI, skills
|
|
27
|
+
bash daemons/run-watchdog.sh --once # Test the watchdog daemon
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
Expected: all green. See [INSTALL.md](INSTALL.md) if not.
|
|
31
|
+
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
## Step 3: Launch Dashboard (Optional)
|
|
35
|
+
|
|
36
|
+
```bash
|
|
37
|
+
npx @matt82198/aesop dash # Opens http://localhost:8770
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Monitor waves in real-time. View logs, agents, heartbeats, backlog.
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## Step 4: Run Your First Wave (in Claude Code)
|
|
45
|
+
|
|
46
|
+
### Priming
|
|
47
|
+
```
|
|
48
|
+
/power
|
|
49
|
+
```
|
|
50
|
+
Loads orchestrator brain, verifies system health, outputs next steps.
|
|
51
|
+
|
|
52
|
+
### Orchestrating
|
|
53
|
+
```
|
|
54
|
+
/buildsystem
|
|
55
|
+
```
|
|
56
|
+
Runs one complete iteration: ranks backlog → dispatches Haiku agents → verifies merges → checkpoints state → audits fleet. Typically 30 min–2 hours.
|
|
57
|
+
|
|
58
|
+
---
|
|
59
|
+
|
|
60
|
+
## Key Concepts
|
|
61
|
+
|
|
62
|
+
**Local + Claude Code**: Orchestrator runs in Claude Code; subagents are Haiku dispatched via `/buildsystem`. Daemons run locally (watchdog, dashboard).
|
|
63
|
+
|
|
64
|
+
**State survives wipes**: `STATE.md` and `BUILDLOG.md` are committed to git. Resume anytime.
|
|
65
|
+
|
|
66
|
+
**Cost**: ~$0.03–$0.05 per wave (1 Opus + 5–8 Haikus).
|
|
67
|
+
|
|
68
|
+
**No modification of your repos**: Each agent works in a sibling worktree. Primary tree stays clean.
|
|
69
|
+
|
|
70
|
+
---
|
|
71
|
+
|
|
72
|
+
## Next Steps
|
|
73
|
+
|
|
74
|
+
- [CONFIGURE.md](CONFIGURE.md) — Customize repos and ports
|
|
75
|
+
- [CONCEPTS.md](CONCEPTS.md) — Dispatch model and architecture
|
|
76
|
+
- [FIRST-WAVE.md](FIRST-WAVE.md) — Detailed expectations and monitoring
|
|
77
|
+
- [ANY-REPO.md](ANY-REPO.md) — Adapt to any codebase (no stack lock-in)
|
|
78
|
+
- [HOW-THE-LOOP-WORKS.md](HOW-THE-LOOP-WORKS.md) — Concrete walkthrough
|
|
79
|
+
|
|
80
|
+
**Troubleshooting**: [INSTALL.md#troubleshooting](INSTALL.md)
|
package/docs/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# Aesop Documentation
|
|
2
2
|
|
|
3
|
-
Aesop is
|
|
3
|
+
Aesop is an autonomous developer system that crawls into any repository and orchestrates intelligent work. It ranks tasks, dispatches parallel Haiku agents, verifies merges, audits the work, and feeds the next iteration. **State persists across multiple instances via a durable SQLite event log**, so your whole team uses one coordinated system.
|
|
4
4
|
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -12,7 +12,7 @@ If you're new to Aesop, follow this 4-stage path:
|
|
|
12
12
|
**[INSTALL.md](INSTALL.md)** — Prerequisites, `npx` scaffold, what gets created
|
|
13
13
|
|
|
14
14
|
- System requirements (Claude Code CLI, Git, Bash, Node.js, Python)
|
|
15
|
-
- Quick-start: `npx @matt82198/aesop
|
|
15
|
+
- Quick-start: `npx @matt82198/aesop my-fleet`
|
|
16
16
|
- Manual setup for development (git clone)
|
|
17
17
|
- Pre-push hook installation
|
|
18
18
|
|
|
@@ -56,6 +56,33 @@ If you're new to Aesop, follow this 4-stage path:
|
|
|
56
56
|
|
|
57
57
|
---
|
|
58
58
|
|
|
59
|
+
## Core Concepts: /power and /buildsystem
|
|
60
|
+
|
|
61
|
+
### /power — System Initialization
|
|
62
|
+
The `/power` skill initializes Aesop into your repository. It:
|
|
63
|
+
- Loads your orchestrator brain (cardinal rules, domain map, team memory, system state)
|
|
64
|
+
- Verifies the system is healthy (filesystem, git, API keys, watchdog)
|
|
65
|
+
- Outputs a health brief and next-step recommendations
|
|
66
|
+
|
|
67
|
+
Run `/power` at the start of each Claude Code session. It's idempotent—safe to run multiple times. See [skills/power/SKILL.md](../skills/power/SKILL.md) for details.
|
|
68
|
+
|
|
69
|
+
### /buildsystem — One Complete Wave Cycle
|
|
70
|
+
The `/buildsystem` skill runs **one complete iteration of the autonomous delivery loop**. It:
|
|
71
|
+
1. **Ranks** the backlog (priority, dependencies, team affinity)
|
|
72
|
+
2. **Dispatches** parallel Haiku agents on file-disjoint domains (tests, build, docs, UI, review, etc.)
|
|
73
|
+
3. **Verifies** each merge (CI, security scans, audit spot-checks)
|
|
74
|
+
4. **Checkpoints** (STATE.md + BUILDLOG.md committed to git, survive wipes)
|
|
75
|
+
5. **Audits** fleet health and feeds next backlog (monitor signals, signal collectors, findings)
|
|
76
|
+
|
|
77
|
+
This is the repeatable loop that runs your delivery cycle indefinitely, with each wave learning from the prior audit. You can run `/buildsystem` once per wave (typically 30 min–2 hours depending on backlog size). See [HOW-THE-LOOP-WORKS.md](HOW-THE-LOOP-WORKS.md) for a concrete walkthrough.
|
|
78
|
+
|
|
79
|
+
### Team State & Multi-Instance Design
|
|
80
|
+
**Current Status (0.1.0)**: Single-instance proven. A team uses Aesop by designating one operator who runs the wave loop. State is durably checkpointed in git (STATE.md, BUILDLOG.md, tracker.json exports).
|
|
81
|
+
|
|
82
|
+
**In Design**: Multi-instance coordination via the state_store substrate. The event-sourced SQLite layer is production-ready but currently opt-in. A future release will enable multiple Aesop instances (e.g., per-team subgroups or geographic regions) to coordinate around a single source of truth—a Postgres-backed event log, with git as a diffable export. See [TEAM-STATE.md](TEAM-STATE.md) (design in progress) for the vision and current architecture decisions.
|
|
83
|
+
|
|
84
|
+
---
|
|
85
|
+
|
|
59
86
|
## Deep-Dive Reference Docs
|
|
60
87
|
|
|
61
88
|
Once you've completed the adopter journey, use these for operational reference:
|
|
@@ -108,12 +135,15 @@ Once you've completed the adopter journey, use these for operational reference:
|
|
|
108
135
|
**I want to understand the cost model**
|
|
109
136
|
→ [DISPATCH-MODEL.md](DISPATCH-MODEL.md) or [HOW-THE-LOOP-WORKS.md](HOW-THE-LOOP-WORKS.md#why-its-fast--cheap)
|
|
110
137
|
|
|
111
|
-
**I want to know what's actually proven vs. claimed (the
|
|
138
|
+
**I want to know what's actually proven vs. claimed (the 0.1.0 milestone)**
|
|
112
139
|
→ [autonomous-swe.md](autonomous-swe.md)
|
|
113
140
|
|
|
114
141
|
**I need to understand how state survives a crash**
|
|
115
142
|
→ [CHECKPOINTING.md](CHECKPOINTING.md)
|
|
116
143
|
|
|
144
|
+
**I want to understand multi-instance coordination**
|
|
145
|
+
→ [TEAM-STATE.md](TEAM-STATE.md)
|
|
146
|
+
|
|
117
147
|
**I'm reviewing a PR that changes orchestration behavior**
|
|
118
148
|
→ [BEHAVIORAL-PR-REVIEW.md](BEHAVIORAL-PR-REVIEW.md)
|
|
119
149
|
|