sisyphi 1.0.13 → 1.1.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/dist/{chunk-T7ETTIQK.js → chunk-M7LZ2ZHD.js} +3 -27
- package/dist/chunk-M7LZ2ZHD.js.map +1 -0
- package/dist/{chunk-JXKUI4P6.js → chunk-REUQ4B45.js} +7 -38
- package/dist/chunk-REUQ4B45.js.map +1 -0
- package/dist/{chunk-LWWRGQWM.js → chunk-Z32YVDMY.js} +2 -2
- package/dist/chunk-Z32YVDMY.js.map +1 -0
- package/dist/cli.js +75 -56
- package/dist/cli.js.map +1 -1
- package/dist/daemon.js +776 -629
- package/dist/daemon.js.map +1 -1
- package/dist/{paths-NUUALUVP.js → paths-IJXOAN4E.js} +4 -6
- package/dist/templates/CLAUDE.md +16 -14
- package/dist/templates/agent-plugin/agents/CLAUDE.md +17 -6
- package/dist/templates/agent-plugin/agents/design.md +134 -0
- package/dist/templates/agent-plugin/agents/explore.md +39 -0
- package/dist/templates/agent-plugin/agents/operator.md +24 -0
- package/dist/templates/agent-plugin/agents/plan.md +15 -20
- package/dist/templates/agent-plugin/agents/problem.md +119 -0
- package/dist/templates/agent-plugin/agents/requirements.md +138 -0
- package/dist/templates/agent-plugin/agents/review/CLAUDE.md +29 -0
- package/dist/templates/agent-plugin/agents/review/compliance.md +6 -6
- package/dist/templates/agent-plugin/agents/review-plan/code-smells.md +4 -4
- package/dist/templates/agent-plugin/agents/review-plan/requirements-coverage.md +62 -0
- package/dist/templates/agent-plugin/agents/review-plan/security.md +1 -1
- package/dist/templates/agent-plugin/agents/review-plan.md +9 -8
- package/dist/templates/agent-plugin/agents/review.md +1 -1
- package/dist/templates/agent-plugin/agents/test-spec.md +3 -3
- package/dist/templates/agent-plugin/hooks/CLAUDE.md +2 -2
- package/dist/templates/agent-plugin/hooks/explore-user-prompt.sh +13 -0
- package/dist/templates/agent-plugin/hooks/plan-user-prompt.sh +1 -1
- package/dist/templates/agent-plugin/hooks/require-submit.sh +70 -3
- package/dist/templates/agent-plugin/hooks/review-plan-user-prompt.sh +4 -4
- package/dist/templates/agent-plugin/hooks/review-user-prompt.sh +1 -1
- package/dist/templates/agent-suffix.md +0 -2
- package/dist/templates/orchestrator-base.md +169 -145
- package/dist/templates/orchestrator-impl.md +92 -57
- package/dist/templates/orchestrator-planning.md +46 -56
- package/dist/templates/orchestrator-plugin/commands/sisyphus/design.md +13 -0
- package/dist/templates/orchestrator-plugin/commands/sisyphus/problem.md +13 -0
- package/dist/templates/orchestrator-plugin/commands/sisyphus/requirements.md +13 -0
- package/dist/templates/orchestrator-plugin/commands/sisyphus/strategize.md +19 -0
- package/dist/templates/orchestrator-plugin/hooks/explore-gate.sh +15 -0
- package/dist/templates/orchestrator-plugin/hooks/hooks.json +14 -1
- package/dist/templates/orchestrator-plugin/skills/orchestration/task-patterns.md +34 -27
- package/dist/templates/orchestrator-plugin/skills/orchestration/workflow-examples.md +56 -24
- package/dist/templates/orchestrator-strategy.md +233 -0
- package/dist/templates/orchestrator-validation.md +94 -0
- package/dist/tui.js +2730 -2924
- package/dist/tui.js.map +1 -1
- package/package.json +2 -4
- package/templates/CLAUDE.md +16 -14
- package/templates/agent-plugin/agents/CLAUDE.md +17 -6
- package/templates/agent-plugin/agents/design.md +134 -0
- package/templates/agent-plugin/agents/explore.md +39 -0
- package/templates/agent-plugin/agents/operator.md +24 -0
- package/templates/agent-plugin/agents/plan.md +15 -20
- package/templates/agent-plugin/agents/problem.md +119 -0
- package/templates/agent-plugin/agents/requirements.md +138 -0
- package/templates/agent-plugin/agents/review/CLAUDE.md +29 -0
- package/templates/agent-plugin/agents/review/compliance.md +6 -6
- package/templates/agent-plugin/agents/review-plan/code-smells.md +4 -4
- package/templates/agent-plugin/agents/review-plan/requirements-coverage.md +62 -0
- package/templates/agent-plugin/agents/review-plan/security.md +1 -1
- package/templates/agent-plugin/agents/review-plan.md +9 -8
- package/templates/agent-plugin/agents/review.md +1 -1
- package/templates/agent-plugin/agents/test-spec.md +3 -3
- package/templates/agent-plugin/hooks/CLAUDE.md +2 -2
- package/templates/agent-plugin/hooks/explore-user-prompt.sh +13 -0
- package/templates/agent-plugin/hooks/plan-user-prompt.sh +1 -1
- package/templates/agent-plugin/hooks/require-submit.sh +70 -3
- package/templates/agent-plugin/hooks/review-plan-user-prompt.sh +4 -4
- package/templates/agent-plugin/hooks/review-user-prompt.sh +1 -1
- package/templates/agent-suffix.md +0 -2
- package/templates/orchestrator-base.md +169 -145
- package/templates/orchestrator-impl.md +92 -57
- package/templates/orchestrator-planning.md +46 -56
- package/templates/orchestrator-plugin/commands/sisyphus/design.md +13 -0
- package/templates/orchestrator-plugin/commands/sisyphus/problem.md +13 -0
- package/templates/orchestrator-plugin/commands/sisyphus/requirements.md +13 -0
- package/templates/orchestrator-plugin/commands/sisyphus/strategize.md +19 -0
- package/templates/orchestrator-plugin/hooks/explore-gate.sh +15 -0
- package/templates/orchestrator-plugin/hooks/hooks.json +14 -1
- package/templates/orchestrator-plugin/skills/orchestration/task-patterns.md +34 -27
- package/templates/orchestrator-plugin/skills/orchestration/workflow-examples.md +56 -24
- package/templates/orchestrator-strategy.md +233 -0
- package/templates/orchestrator-validation.md +94 -0
- package/dist/chunk-JXKUI4P6.js.map +0 -1
- package/dist/chunk-LWWRGQWM.js.map +0 -1
- package/dist/chunk-T7ETTIQK.js.map +0 -1
- package/dist/templates/agent-plugin/agents/review-plan/spec-coverage.md +0 -44
- package/dist/templates/agent-plugin/agents/spec-draft.md +0 -78
- package/dist/templates/agent-plugin/hooks/hooks.json +0 -25
- package/dist/templates/agent-plugin/hooks/spec-user-prompt.sh +0 -19
- package/dist/templates/orchestrator-plugin/skills/git-management/SKILL.md +0 -111
- package/templates/agent-plugin/agents/review-plan/spec-coverage.md +0 -44
- package/templates/agent-plugin/agents/spec-draft.md +0 -78
- package/templates/agent-plugin/hooks/hooks.json +0 -25
- package/templates/agent-plugin/hooks/spec-user-prompt.sh +0 -19
- package/templates/orchestrator-plugin/skills/git-management/SKILL.md +0 -111
- /package/dist/{paths-NUUALUVP.js.map → paths-IJXOAN4E.js.map} +0 -0
|
@@ -94,13 +94,15 @@ Action: complete — "Fixed WebSocket message loss during reconnection. Messages
|
|
|
94
94
|
|
|
95
95
|
**Starting task**: "Add rate limiting to the REST API — per-user, configurable limits"
|
|
96
96
|
|
|
97
|
-
### Cycle 1 —
|
|
97
|
+
### Cycle 1 — Problem exploration
|
|
98
98
|
```
|
|
99
99
|
roadmap.md:
|
|
100
100
|
## Feature: API Rate Limiting
|
|
101
101
|
|
|
102
|
-
###
|
|
103
|
-
- [ ]
|
|
102
|
+
### Requirements & Design
|
|
103
|
+
- [ ] Problem exploration — understand rate limiting needs
|
|
104
|
+
- [ ] Requirements — define acceptance criteria
|
|
105
|
+
- [ ] Design — architecture for rate limiting
|
|
104
106
|
- [ ] Plan implementation
|
|
105
107
|
- [ ] Review plan
|
|
106
108
|
|
|
@@ -114,45 +116,75 @@ roadmap.md:
|
|
|
114
116
|
- [ ] Review implementation
|
|
115
117
|
|
|
116
118
|
Agents spawned:
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
Questions to
|
|
120
|
-
|
|
119
|
+
problem agent → "Explore the codebase and understand the API rate limiting landscape.
|
|
120
|
+
Check existing middleware patterns in src/api/middleware/.
|
|
121
|
+
Questions to explore: current request handling, existing auth/middleware chain,
|
|
122
|
+
what storage backends are available (Redis?), user identification mechanisms."
|
|
121
123
|
```
|
|
122
124
|
|
|
123
|
-
### Cycle 2 —
|
|
125
|
+
### Cycle 2 — Requirements (after human reviews problem doc)
|
|
124
126
|
```
|
|
125
|
-
Agent report: "
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
Open questions resolved with user: Redis is already in stack, use it."
|
|
127
|
+
Agent report: "Problem document saved to context/problem-rate-limiting.md.
|
|
128
|
+
Current middleware chain uses Express middleware pattern. Redis is already in stack.
|
|
129
|
+
Users are identified by JWT sub claim. No existing rate limiting."
|
|
129
130
|
|
|
130
|
-
roadmap.md updated
|
|
131
|
-
- [x] ~~
|
|
131
|
+
roadmap.md updated:
|
|
132
|
+
- [x] ~~Problem exploration~~
|
|
133
|
+
- [ ] Requirements — define acceptance criteria
|
|
134
|
+
...
|
|
135
|
+
|
|
136
|
+
Agents spawned:
|
|
137
|
+
requirements agent → "Draft acceptance criteria for per-user API rate limiting.
|
|
138
|
+
Read context/problem-rate-limiting.md for context.
|
|
139
|
+
Questions to resolve: limit granularity (per-endpoint vs global),
|
|
140
|
+
response format for rate-limited requests, override mechanisms."
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
### Cycle 3 — Design (after human reviews requirements)
|
|
144
|
+
```
|
|
145
|
+
Agent report: "Requirements saved to context/requirements-rate-limiting.md.
|
|
146
|
+
Covers: per-user limits, endpoint-specific overrides, 429 response format,
|
|
147
|
+
Retry-After headers. User confirmed Redis-backed approach."
|
|
148
|
+
|
|
149
|
+
Agents spawned:
|
|
150
|
+
design agent → "Create technical design for rate limiting based on
|
|
151
|
+
context/requirements-rate-limiting.md and context/problem-rate-limiting.md."
|
|
152
|
+
```
|
|
153
|
+
|
|
154
|
+
### Cycle 4 — Plan (after human reviews design)
|
|
155
|
+
```
|
|
156
|
+
Agent report: "Design saved to context/design-rate-limiting.md.
|
|
157
|
+
Approach: Redis-backed sliding window middleware. Per-user with endpoint-specific
|
|
158
|
+
overrides. Standard 429 response with Retry-After header. Config via environment variables."
|
|
159
|
+
|
|
160
|
+
roadmap.md updated:
|
|
161
|
+
- [x] ~~Problem exploration~~, [x] ~~Requirements~~, [x] ~~Design~~
|
|
132
162
|
- [ ] Plan implementation
|
|
133
163
|
...
|
|
134
164
|
|
|
135
165
|
Agents spawned:
|
|
136
|
-
plan agent → "Create implementation plan from
|
|
137
|
-
|
|
166
|
+
plan agent → "Create implementation plan from context/requirements-rate-limiting.md
|
|
167
|
+
and context/design-rate-limiting.md"
|
|
168
|
+
test-spec agent → "Define behavioral properties for rate limiting from
|
|
169
|
+
context/requirements-rate-limiting.md"
|
|
138
170
|
```
|
|
139
171
|
|
|
140
|
-
### Cycle
|
|
172
|
+
### Cycle 5 — Review plan
|
|
141
173
|
```
|
|
142
174
|
Both agents complete. Plan at context/plan-rate-limiting.md.
|
|
143
175
|
Plan has 3 phases: middleware, config, response format.
|
|
144
176
|
|
|
145
177
|
Agents spawned:
|
|
146
178
|
review-plan agent → "Validate plan at context/plan-rate-limiting.md
|
|
147
|
-
against
|
|
179
|
+
against context/requirements-rate-limiting.md and context/design-rate-limiting.md"
|
|
148
180
|
```
|
|
149
181
|
|
|
150
|
-
### Cycle
|
|
182
|
+
### Cycle 6 — Implement phases 1+2 (parallel, low-risk foundation)
|
|
151
183
|
```
|
|
152
184
|
Plan review: PASS.
|
|
153
185
|
|
|
154
186
|
roadmap.md updated (plan review done, starting implementation):
|
|
155
|
-
- [x] ~~
|
|
187
|
+
- [x] ~~Requirements~~, [x] ~~Design~~, [x] ~~Plan~~, [x] ~~Review plan~~
|
|
156
188
|
- [ ] Implement rate limiting middleware
|
|
157
189
|
- [ ] Implement rate limit configuration
|
|
158
190
|
- [ ] Critique phases 1-2 — review before integration phase
|
|
@@ -167,7 +199,7 @@ Agents spawned (parallel — phases touch different files):
|
|
|
167
199
|
rate limit configuration in src/config/rate-limits.ts"
|
|
168
200
|
```
|
|
169
201
|
|
|
170
|
-
### Cycle
|
|
202
|
+
### Cycle 7 — Critique before integration builds on top
|
|
171
203
|
```
|
|
172
204
|
Both implementation agents complete.
|
|
173
205
|
|
|
@@ -185,7 +217,7 @@ Agents spawned:
|
|
|
185
217
|
config schema matches what middleware expects."
|
|
186
218
|
```
|
|
187
219
|
|
|
188
|
-
### Cycle
|
|
220
|
+
### Cycle 8 — Implement phase 3 + address critique
|
|
189
221
|
```
|
|
190
222
|
Review: 2 findings — middleware doesn't handle Redis connection failure gracefully,
|
|
191
223
|
config schema allows negative rate limits.
|
|
@@ -197,7 +229,7 @@ Agents spawned (parallel):
|
|
|
197
229
|
rate limit headers and 429 error responses in src/api/middleware/rate-limit.ts"
|
|
198
230
|
```
|
|
199
231
|
|
|
200
|
-
### Cycle
|
|
232
|
+
### Cycle 9 — Validate end-to-end
|
|
201
233
|
```
|
|
202
234
|
Phase 3 and fixes complete.
|
|
203
235
|
|
|
@@ -210,7 +242,7 @@ Agents spawned:
|
|
|
210
242
|
Test per-user isolation, endpoint-specific overrides, Redis failover behavior."
|
|
211
243
|
```
|
|
212
244
|
|
|
213
|
-
### Cycle
|
|
245
|
+
### Cycle 10 — Complete
|
|
214
246
|
```
|
|
215
247
|
Validation: PASS. Final review agent confirms no issues.
|
|
216
248
|
Complete — "Added per-user API rate limiting with Redis-backed sliding window,
|
|
@@ -0,0 +1,233 @@
|
|
|
1
|
+
# Strategy Phase
|
|
2
|
+
|
|
3
|
+
You are in strategy mode. Your job is to understand the goal and produce a strategy that maps out how to get there — but only as far as you can currently see.
|
|
4
|
+
|
|
5
|
+
Strategy is a living map. You detail the stages you can see clearly, sketch the ones you can't yet, and compress the ones behind you. Don't try to plan the entire session upfront. Map what's visible, acknowledge what's ahead, and trust that the strategy will be extended as the picture clarifies.
|
|
6
|
+
|
|
7
|
+
If a strategy.md already exists, you're here because the goal has fundamentally shifted or the approach needs rethinking. Read the existing strategy, assess what's changed, and revise it — don't start from scratch unless the old strategy is truly obsolete.
|
|
8
|
+
|
|
9
|
+
<ownership>
|
|
10
|
+
|
|
11
|
+
## You Own the Lifecycle
|
|
12
|
+
|
|
13
|
+
The user is a stakeholder, not a project manager. They are busy. They answer questions, express preferences, and approve plans — but they don't drive the process. You do.
|
|
14
|
+
|
|
15
|
+
This means every stage you design needs to be self-sufficient: the orchestrator should know what to do next without the user pushing it forward. When a stage needs user input, define exactly what you need from them (a decision, approval, clarification) and handle everything else autonomously.
|
|
16
|
+
|
|
17
|
+
The user's role at each stage:
|
|
18
|
+
- **Discovery/exploration**: answer questions about their intent, constraints, priorities
|
|
19
|
+
- **Requirements/design**: approve requirements and architecture decisions
|
|
20
|
+
- **Implementation**: mostly hands-off — they see progress, intervene if something looks wrong
|
|
21
|
+
- **Validation**: sign off on the final result
|
|
22
|
+
|
|
23
|
+
Design your stages around this. Don't create stages that require the user to manage the work. Create stages where you manage the work and bring the user in at decision points.
|
|
24
|
+
|
|
25
|
+
</ownership>
|
|
26
|
+
|
|
27
|
+
<goal-refinement>
|
|
28
|
+
|
|
29
|
+
## Refine the Goal
|
|
30
|
+
|
|
31
|
+
The user's starting prompt is an input, not a goal. It may be vague, ambiguous, or assume context you don't have. Your job is to turn it into a clear goal statement.
|
|
32
|
+
|
|
33
|
+
**Process:**
|
|
34
|
+
1. Read the starting prompt
|
|
35
|
+
2. Explore the codebase enough to understand what's relevant
|
|
36
|
+
3. If the goal is unclear, **ask the user** — do NOT guess. Surface ambiguity, propose interpretations, get confirmation.
|
|
37
|
+
4. Write `goal.md` to the session directory
|
|
38
|
+
|
|
39
|
+
**goal.md should answer:**
|
|
40
|
+
- What does "done" look like?
|
|
41
|
+
- What's in scope and what's explicitly not?
|
|
42
|
+
- Who or what is affected?
|
|
43
|
+
|
|
44
|
+
Keep it short — a paragraph, not a document. This is a north star, not a requirements doc.
|
|
45
|
+
|
|
46
|
+
</goal-refinement>
|
|
47
|
+
|
|
48
|
+
<design-philosophy>
|
|
49
|
+
|
|
50
|
+
## Design Philosophy
|
|
51
|
+
|
|
52
|
+
You're choosing *how to think* about the problem before doing any work. These frameworks inform that choice:
|
|
53
|
+
|
|
54
|
+
- **Double Diamond** — Diverge to explore, converge on a definition; diverge on solutions, converge on implementation. Use when requirements are unclear or the problem needs defining.
|
|
55
|
+
- **OODA (Observe–Orient–Decide–Act)** — Tight sensing/reacting loops. Use when the situation is fluid and the cost of wrong moves is low (debugging, spikes, incident response).
|
|
56
|
+
- **Cynefin** — Match approach to domain. Clear → best practice. Complicated → analyze then execute. Complex → probe, sense, respond. Chaotic → act to stabilize.
|
|
57
|
+
|
|
58
|
+
Don't follow a framework mechanically. Use them to *select the right process shape* for each stage.
|
|
59
|
+
|
|
60
|
+
</design-philosophy>
|
|
61
|
+
|
|
62
|
+
<strategy-generation>
|
|
63
|
+
|
|
64
|
+
## Generate the Strategy
|
|
65
|
+
|
|
66
|
+
### Step 1: Assess What You Can See
|
|
67
|
+
|
|
68
|
+
Sisyphus sessions are for large, complex work — multi-phase features, sweeping refactors, research-heavy initiatives, or messy combinations of all three. The work often doesn't fit neatly into a category, and the shape of it may not be clear at the start.
|
|
69
|
+
|
|
70
|
+
Start by asking: **how much of the path can I see right now?**
|
|
71
|
+
|
|
72
|
+
- **Goal is clear, path is visible** → map out the full stage progression. Detail the first stage, sketch the rest.
|
|
73
|
+
- **Goal is clear, path is uncertain** → detail an exploration/investigation stage to understand the landscape. Sketch what you think comes after.
|
|
74
|
+
- **Goal is vague** → the first stage is figuring out what the goal actually is. Ask the user, explore the codebase, converge on a real goal. Everything else is "TBD."
|
|
75
|
+
|
|
76
|
+
### Step 2: Map the Stage Progression
|
|
77
|
+
|
|
78
|
+
Identify the stages you'll need but **only detail the first one** (or the stage you're entering). Sketch the rest as one-liners. The progression depends entirely on the problem — there's no fixed template. Common patterns to draw from:
|
|
79
|
+
|
|
80
|
+
```
|
|
81
|
+
discovery → product-design → technical-investigation → architecture → implementation → validation
|
|
82
|
+
exploration → spike → design → implementation → validation
|
|
83
|
+
investigation → recommendation → (user decides) → implementation
|
|
84
|
+
analysis → phased-transformation → verification
|
|
85
|
+
discovery → requirements → design → planning → implementation → validation
|
|
86
|
+
```
|
|
87
|
+
|
|
88
|
+
Mix and match. The orchestrator plays different roles at different stages — product designer during discovery, architect during design, engineering lead during implementation. A massive refactor might start with investigation, move through phased transformation, and end with validation. A research-heavy feature might cycle between exploration and prototyping before ever reaching a design stage. Let the problem dictate the shape.
|
|
89
|
+
|
|
90
|
+
Not every stage needs to appear. Skip what's already clear. Add stages the patterns don't show — spikes, prototypes, migration stages, compatibility checks, whatever the problem demands. Stages can be anything — they're not limited to the patterns below.
|
|
91
|
+
|
|
92
|
+
### Step 3: Build Each Detailed Stage
|
|
93
|
+
|
|
94
|
+
Use the stage patterns below as starting points — not a menu. Invent new stage types when the problem demands it. Adapt patterns to fit. Add backtrack edges where you can foresee things going wrong. Give every stage an exit condition concrete enough to evaluate.
|
|
95
|
+
|
|
96
|
+
<stage-patterns>
|
|
97
|
+
|
|
98
|
+
<stage name="discovery" use-when="Goal is broad or ambiguous — need to understand what the user actually wants before scoping the work">
|
|
99
|
+
Process: explore the existing system to understand context → research relevant domain patterns → engage the user with targeted questions (not open-ended — propose interpretations, ask them to confirm or redirect) → draft a product brief or problem definition
|
|
100
|
+
Exit: user-confirmed understanding of what they want, documented in context/
|
|
101
|
+
Produces: product brief, problem definition, or scoping document
|
|
102
|
+
Note: the orchestrator acts as product designer here — asking the right questions, proposing structure, synthesizing vague desires into concrete scope
|
|
103
|
+
</stage>
|
|
104
|
+
|
|
105
|
+
<stage name="exploration" use-when="Need to understand the technical landscape before committing to an approach">
|
|
106
|
+
Process: spawn explore agents (each producing a focused context doc) → review findings → identify gaps → re-explore or converge
|
|
107
|
+
Exit: enough understanding to make decisions about the next stage — key questions answered, relevant patterns documented
|
|
108
|
+
Produces: context documents (one per investigation angle, not one sprawling doc)
|
|
109
|
+
Backtrack: N/A (usually early stage)
|
|
110
|
+
</stage>
|
|
111
|
+
|
|
112
|
+
<stage name="spike" use-when="Feasibility is uncertain — need to prove an approach works before investing in full design">
|
|
113
|
+
Process: identify the riskiest assumption → build a minimal prototype that tests it → evaluate results → present findings to user if the spike changes the approach
|
|
114
|
+
Exit: feasibility confirmed or denied with evidence, decision on path forward
|
|
115
|
+
Produces: spike findings in context/, prototype code (may be throwaway)
|
|
116
|
+
Backtrack: if spike fails → re-explore alternatives
|
|
117
|
+
</stage>
|
|
118
|
+
|
|
119
|
+
<stage name="requirements" use-when="Need to define what to build before designing how">
|
|
120
|
+
Process: draft requirements from exploration/discovery findings → review for feasibility against actual codebase → align with user → revise
|
|
121
|
+
Exit: user-approved requirements with testable acceptance criteria
|
|
122
|
+
Produces: requirements document in context/
|
|
123
|
+
Backtrack: if problem was misframed → re-explore or re-discover
|
|
124
|
+
</stage>
|
|
125
|
+
|
|
126
|
+
<stage name="design" use-when="Requirements approved, need to define the architecture and approach">
|
|
127
|
+
Process: explore viable approaches → draft design (architecture, component boundaries, data models, contracts) → review for feasibility and gaps → align with user
|
|
128
|
+
Exit: user-approved design document
|
|
129
|
+
Produces: design doc in context/
|
|
130
|
+
Backtrack: if requirements wrong or incomplete → update requirements
|
|
131
|
+
</stage>
|
|
132
|
+
|
|
133
|
+
<stage name="planning" use-when="Design approved, need an executable breakdown">
|
|
134
|
+
Process: spawn plan lead with requirements + design as inputs → adversarial review of plan → create e2e verification recipe
|
|
135
|
+
Exit: reviewed plan + executable e2e-recipe.md that defines how to prove the feature works
|
|
136
|
+
Produces: phased implementation plan + e2e recipe in context/
|
|
137
|
+
Backtrack: if plan reveals design infeasibility → revisit design
|
|
138
|
+
</stage>
|
|
139
|
+
|
|
140
|
+
<stage name="implementation" use-when="Plan exists, time to build">
|
|
141
|
+
Process: for each phase → detail-plan → spawn implement agents → critique → refine → validate phase
|
|
142
|
+
Exit: all phases validated with evidence, no critical review findings remain
|
|
143
|
+
Produces: code changes, phase validation results
|
|
144
|
+
Loops: critique/refine within each phase (cap at 3 rounds before escalating to plan/design)
|
|
145
|
+
Backtrack: if 2+ agents hit same unexpected complexity → revisit plan or design
|
|
146
|
+
</stage>
|
|
147
|
+
|
|
148
|
+
<stage name="validation" use-when="Implementation complete, need to prove it works end-to-end">
|
|
149
|
+
Process: run full e2e recipe → collect evidence (command output, screenshots, responses) → assess against success criteria → step back and check if the goal is actually met
|
|
150
|
+
Exit: all recipe steps pass with concrete evidence, original goal satisfied
|
|
151
|
+
Produces: validation report with evidence
|
|
152
|
+
Backtrack: if bugs found → implementation; if architectural issues → design
|
|
153
|
+
</stage>
|
|
154
|
+
|
|
155
|
+
</stage-patterns>
|
|
156
|
+
|
|
157
|
+
### Step 4: Write strategy.md
|
|
158
|
+
|
|
159
|
+
Write the strategy to the session directory using this structure:
|
|
160
|
+
|
|
161
|
+
```markdown
|
|
162
|
+
## Completed
|
|
163
|
+
[Nothing yet — compressed summaries of finished stages appear here as work progresses]
|
|
164
|
+
|
|
165
|
+
## Current Stage: [name]
|
|
166
|
+
[Detailed process flow with exit criteria and backtrack triggers]
|
|
167
|
+
[Customized from stage patterns above for this specific problem]
|
|
168
|
+
|
|
169
|
+
## Ahead
|
|
170
|
+
[Sketched future stages — one line each: name + what it covers]
|
|
171
|
+
[Only as far as you can currently see — it's OK if this is vague]
|
|
172
|
+
```
|
|
173
|
+
|
|
174
|
+
**Principles:**
|
|
175
|
+
- **Detail the current stage** — concrete enough that the orchestrator can execute without re-reading this template
|
|
176
|
+
- **Sketch what's ahead** — enough continuity that future updates don't lose the thread, not so much that you're committing to unknowns
|
|
177
|
+
- **Every detailed stage gets exit criteria** — concrete enough to evaluate, not so rigid they become checkboxes
|
|
178
|
+
- **Include user gates** — where does this stage need the user? What decision or approval? Be specific so the orchestrator knows when to engage them and when to proceed autonomously.
|
|
179
|
+
|
|
180
|
+
</strategy-generation>
|
|
181
|
+
|
|
182
|
+
<strategy-evolution>
|
|
183
|
+
|
|
184
|
+
## Strategy Evolution
|
|
185
|
+
|
|
186
|
+
strategy.md is not frozen after this cycle. Future orchestrator cycles will update it when:
|
|
187
|
+
|
|
188
|
+
- **The goal crystallizes** — you were exploring something vague, now you know what to build. Extend the strategy: detail the next stage, flesh out the "Ahead" section.
|
|
189
|
+
- **The goal shifts** — new information changes what "done" looks like. Revise the affected stages.
|
|
190
|
+
- **A stage completes** — compress it to a one-line summary with artifacts produced (move to "Completed"). Promote the next sketched stage to "Current Stage" and detail it.
|
|
191
|
+
- **The approach is wrong** — backtracking reveals a fundamental issue. Revise the strategy to match.
|
|
192
|
+
|
|
193
|
+
Updates happen every few cycles, not every cycle. If the orchestrator is just progressing within a stage, roadmap.md handles that. Strategy updates are for when the shape of the work changes.
|
|
194
|
+
|
|
195
|
+
</strategy-evolution>
|
|
196
|
+
|
|
197
|
+
<roadmap-initialization>
|
|
198
|
+
|
|
199
|
+
## Initialize the Roadmap
|
|
200
|
+
|
|
201
|
+
After writing goal.md and strategy.md, initialize roadmap.md:
|
|
202
|
+
|
|
203
|
+
```markdown
|
|
204
|
+
## Current Stage
|
|
205
|
+
[Stage name from strategy.md and brief status]
|
|
206
|
+
|
|
207
|
+
## Exit Criteria
|
|
208
|
+
[Concrete, evaluable conditions for leaving this stage]
|
|
209
|
+
|
|
210
|
+
## Active Context
|
|
211
|
+
[No context files yet — populated as work begins]
|
|
212
|
+
|
|
213
|
+
## Next Steps
|
|
214
|
+
[What to do next within the current stage]
|
|
215
|
+
```
|
|
216
|
+
|
|
217
|
+
The roadmap tracks cycle-to-cycle progress within a stage. The strategy tracks the shape of the work across stages.
|
|
218
|
+
|
|
219
|
+
</roadmap-initialization>
|
|
220
|
+
|
|
221
|
+
<transition>
|
|
222
|
+
|
|
223
|
+
## Transition
|
|
224
|
+
|
|
225
|
+
Once goal.md, strategy.md, and roadmap.md are written:
|
|
226
|
+
|
|
227
|
+
```bash
|
|
228
|
+
sisyphus yield --mode planning --prompt "Strategy complete — goal.md, strategy.md, and roadmap.md initialized. Begin first stage."
|
|
229
|
+
```
|
|
230
|
+
|
|
231
|
+
Future orchestrator cycles will read strategy.md to orient, consult roadmap.md for current position, and update strategy.md when the shape of the work changes.
|
|
232
|
+
|
|
233
|
+
</transition>
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
# Validation Phase
|
|
2
|
+
|
|
3
|
+
You are in validation mode. Your job is not to build — it is to **prove that what was built actually works.** No new implementation unless a validation failure demands it. No assumptions about correctness. No hedging.
|
|
4
|
+
|
|
5
|
+
The standard: **exercise the feature end-to-end, observe the results, and confirm they match the success criteria.** If you can't demonstrate it works, it doesn't work.
|
|
6
|
+
|
|
7
|
+
## Start From the Recipe
|
|
8
|
+
|
|
9
|
+
Read `context/e2e-recipe.md`. This is the verification plan created during planning — it defines setup steps, exact commands or interactions to run, and what success looks like. Every validation cycle starts here.
|
|
10
|
+
|
|
11
|
+
If the recipe doesn't exist or doesn't cover what was implemented:
|
|
12
|
+
1. Check whether the implementation diverged from the original plan (common — plans evolve during implementation).
|
|
13
|
+
2. Write or update the recipe to match what was actually built. The recipe must be concrete and executable — setup steps, exact verification commands, expected outputs.
|
|
14
|
+
3. Then validate against the updated recipe.
|
|
15
|
+
|
|
16
|
+
If you genuinely cannot determine how to verify the feature — transition back to planning:
|
|
17
|
+
|
|
18
|
+
```bash
|
|
19
|
+
sisyphus yield --mode planning --prompt "Cannot determine verification method for [feature] — need to establish e2e recipe"
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
## The Operator Is Not Optional
|
|
23
|
+
|
|
24
|
+
**If the feature touches anything user-facing — UI, frontend, visual output, browser interactions — you MUST spawn a `sisyphus:operator` agent.** Not "consider spawning." Must.
|
|
25
|
+
|
|
26
|
+
The operator has `capture` for full browser automation: navigate pages, click elements, fill forms, take screenshots, read the accessibility tree, inspect network requests. It exercises the app the way a user would. Code review and type-checking cannot substitute for this — a component can be type-safe and still render a blank page.
|
|
27
|
+
|
|
28
|
+
For non-UI features, validation agents exercise the feature via CLI, API calls, test suites, or log inspection. The principle is the same: actually run it, actually observe the result.
|
|
29
|
+
|
|
30
|
+
## What Counts as Proof
|
|
31
|
+
|
|
32
|
+
Every claim in a validation report must have evidence behind it. The validation agent ran a command — what was the output? It loaded a page — what did it see? It called an endpoint — what came back?
|
|
33
|
+
|
|
34
|
+
**Acceptable evidence:**
|
|
35
|
+
- Command output showing expected behavior
|
|
36
|
+
- Screenshots of UI state (with file paths in the report)
|
|
37
|
+
- HTTP responses with status codes and bodies
|
|
38
|
+
- Test suite output showing pass/fail
|
|
39
|
+
- Log lines confirming expected behavior occurred
|
|
40
|
+
- Accessibility tree dumps showing expected DOM structure
|
|
41
|
+
|
|
42
|
+
**Not evidence:**
|
|
43
|
+
- "The code looks correct"
|
|
44
|
+
- "Tests should pass based on the implementation"
|
|
45
|
+
- "The component renders properly" (without a screenshot or DOM inspection)
|
|
46
|
+
- "It appears to work" / "It should work" / "It seems correct"
|
|
47
|
+
- Restating what the implementation does without exercising it
|
|
48
|
+
|
|
49
|
+
If a validation agent reports without evidence, their report is incomplete. Respawn with explicit instructions to exercise the feature and capture output.
|
|
50
|
+
|
|
51
|
+
## Running Validation
|
|
52
|
+
|
|
53
|
+
Spawn validation agents with clear, specific instructions:
|
|
54
|
+
|
|
55
|
+
1. **Reference the recipe** — point the agent at `context/e2e-recipe.md`
|
|
56
|
+
2. **Specify what to validate** — which parts of the recipe, which flows, which endpoints
|
|
57
|
+
3. **Require evidence** — tell the agent to capture output, screenshots, or responses for every claim
|
|
58
|
+
|
|
59
|
+
For broad features, parallelize: spawn multiple agents each covering a distinct area. An operator for the UI flows, a CLI agent for backend verification, etc.
|
|
60
|
+
|
|
61
|
+
### Review the evidence yourself
|
|
62
|
+
|
|
63
|
+
When validation reports come back, **read them critically.** Check that the evidence actually supports the claims. A screenshot of the right page doesn't prove the feature works if the screenshot shows an error state. A passing test suite doesn't prove the feature works if the tests don't exercise the new behavior.
|
|
64
|
+
|
|
65
|
+
If a report says "all checks pass" but the evidence is thin or missing — that's a failed validation. Respawn.
|
|
66
|
+
|
|
67
|
+
## Handling Failures
|
|
68
|
+
|
|
69
|
+
When validation surfaces real bugs:
|
|
70
|
+
|
|
71
|
+
```bash
|
|
72
|
+
sisyphus yield --mode implementation --prompt "Validation failed — [specific failures]. See reports/agent-XXX-final.md for details."
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
Log what failed and why in the cycle log before yielding. The implementation cycle needs clear context on what to fix.
|
|
76
|
+
|
|
77
|
+
When validation reveals that the approach itself is flawed — not bugs, but architectural issues or fundamental misunderstandings:
|
|
78
|
+
|
|
79
|
+
```bash
|
|
80
|
+
sisyphus yield --mode planning --prompt "Validation revealed [architectural issue] — approach needs rethinking. See cycle log."
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
**Do not attempt fixes in validation mode** beyond trivial issues (a missed import, a config typo). If the fix requires design decisions or touches multiple files, transition to implementation mode where the orchestrator has the right guidance for managing that work.
|
|
84
|
+
|
|
85
|
+
## Completion Gate
|
|
86
|
+
|
|
87
|
+
Only call `sisyphus complete` when:
|
|
88
|
+
- Every recipe step has been executed (not skipped, not assumed)
|
|
89
|
+
- Every step has evidence of success in the validation report
|
|
90
|
+
- The evidence actually matches the success criteria from the recipe
|
|
91
|
+
|
|
92
|
+
If the recipe was updated during validation, re-validate against the updated version. Completion means the current recipe passes, not that an earlier draft would have.
|
|
93
|
+
|
|
94
|
+
Before completing, step back: does the validated behavior actually satisfy the original goal? It's possible to pass every recipe step and still miss the point. The recipe is a tool, not a substitute for judgment.
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"sources":["../src/shared/paths.ts"],"sourcesContent":["import { homedir } from 'node:os';\nimport { basename, join } from 'node:path';\n\nexport function globalDir(): string {\n return join(homedir(), '.sisyphus');\n}\n\nexport function socketPath(): string {\n return join(globalDir(), 'daemon.sock');\n}\n\nexport function globalConfigPath(): string {\n return join(globalDir(), 'config.json');\n}\n\nexport function daemonLogPath(): string {\n return join(globalDir(), 'daemon.log');\n}\n\nexport function daemonPidPath(): string {\n return join(globalDir(), 'daemon.pid');\n}\n\nexport function daemonUpdatingPath(): string {\n return join(globalDir(), 'updating');\n}\n\nexport function projectDir(cwd: string): string {\n return join(cwd, '.sisyphus');\n}\n\nexport function projectConfigPath(cwd: string): string {\n return join(projectDir(cwd), 'config.json');\n}\n\nexport function projectOrchestratorPromptPath(cwd: string): string {\n return join(projectDir(cwd), 'orchestrator.md');\n}\n\nexport function sessionsDir(cwd: string): string {\n return join(projectDir(cwd), 'sessions');\n}\n\nexport function sessionDir(cwd: string, sessionId: string): string {\n return join(sessionsDir(cwd), sessionId);\n}\n\nexport function statePath(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'state.json');\n}\n\nexport function reportsDir(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'reports');\n}\n\nexport function reportFilePath(cwd: string, sessionId: string, agentId: string, suffix: string): string {\n return join(reportsDir(cwd, sessionId), `${agentId}-${suffix}.md`);\n}\n\nexport function messagesDir(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'messages');\n}\n\nexport function promptsDir(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'prompts');\n}\n\nexport function contextDir(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'context');\n}\n\nexport function roadmapPath(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'roadmap.md');\n}\n\nexport function goalPath(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'goal.md');\n}\n\nexport function logsDir(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'logs');\n}\n\nexport function cycleLogPath(cwd: string, sessionId: string, cycle: number): string {\n return join(logsDir(cwd, sessionId), `cycle-${String(cycle).padStart(3, '0')}.md`);\n}\n\n// Backwards compat for old sessions\nexport function legacyLogsPath(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'logs.md');\n}\n\nexport function snapshotsDir(cwd: string, sessionId: string): string {\n return join(sessionDir(cwd, sessionId), 'snapshots');\n}\n\nexport function snapshotDir(cwd: string, sessionId: string, cycle: number): string {\n return join(snapshotsDir(cwd, sessionId), `cycle-${cycle}`);\n}\n\nexport function worktreeConfigPath(cwd: string): string {\n return join(projectDir(cwd), 'worktree.json');\n}\n\nexport function worktreeBaseDir(cwd: string): string {\n return join(cwd, '..', `${basename(cwd)}-sisyphus-wt`);\n}\n"],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;AAAA,SAAS,eAAe;AACxB,SAAS,UAAU,YAAY;AAExB,SAAS,YAAoB;AAClC,SAAO,KAAK,QAAQ,GAAG,WAAW;AACpC;AAEO,SAAS,aAAqB;AACnC,SAAO,KAAK,UAAU,GAAG,aAAa;AACxC;AAEO,SAAS,mBAA2B;AACzC,SAAO,KAAK,UAAU,GAAG,aAAa;AACxC;AAEO,SAAS,gBAAwB;AACtC,SAAO,KAAK,UAAU,GAAG,YAAY;AACvC;AAEO,SAAS,gBAAwB;AACtC,SAAO,KAAK,UAAU,GAAG,YAAY;AACvC;AAEO,SAAS,qBAA6B;AAC3C,SAAO,KAAK,UAAU,GAAG,UAAU;AACrC;AAEO,SAAS,WAAW,KAAqB;AAC9C,SAAO,KAAK,KAAK,WAAW;AAC9B;AAEO,SAAS,kBAAkB,KAAqB;AACrD,SAAO,KAAK,WAAW,GAAG,GAAG,aAAa;AAC5C;AAEO,SAAS,8BAA8B,KAAqB;AACjE,SAAO,KAAK,WAAW,GAAG,GAAG,iBAAiB;AAChD;AAEO,SAAS,YAAY,KAAqB;AAC/C,SAAO,KAAK,WAAW,GAAG,GAAG,UAAU;AACzC;AAEO,SAAS,WAAW,KAAa,WAA2B;AACjE,SAAO,KAAK,YAAY,GAAG,GAAG,SAAS;AACzC;AAEO,SAAS,UAAU,KAAa,WAA2B;AAChE,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,YAAY;AACtD;AAEO,SAAS,WAAW,KAAa,WAA2B;AACjE,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,SAAS;AACnD;AAEO,SAAS,eAAe,KAAa,WAAmB,SAAiB,QAAwB;AACtG,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,GAAG,OAAO,IAAI,MAAM,KAAK;AACnE;AAEO,SAAS,YAAY,KAAa,WAA2B;AAClE,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,UAAU;AACpD;AAEO,SAAS,WAAW,KAAa,WAA2B;AACjE,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,SAAS;AACnD;AAEO,SAAS,WAAW,KAAa,WAA2B;AACjE,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,SAAS;AACnD;AAEO,SAAS,YAAY,KAAa,WAA2B;AAClE,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,YAAY;AACtD;AAEO,SAAS,SAAS,KAAa,WAA2B;AAC/D,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,SAAS;AACnD;AAEO,SAAS,QAAQ,KAAa,WAA2B;AAC9D,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,MAAM;AAChD;AAEO,SAAS,aAAa,KAAa,WAAmB,OAAuB;AAClF,SAAO,KAAK,QAAQ,KAAK,SAAS,GAAG,SAAS,OAAO,KAAK,EAAE,SAAS,GAAG,GAAG,CAAC,KAAK;AACnF;AAGO,SAAS,eAAe,KAAa,WAA2B;AACrE,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,SAAS;AACnD;AAEO,SAAS,aAAa,KAAa,WAA2B;AACnE,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,WAAW;AACrD;AAEO,SAAS,YAAY,KAAa,WAAmB,OAAuB;AACjF,SAAO,KAAK,aAAa,KAAK,SAAS,GAAG,SAAS,KAAK,EAAE;AAC5D;AAEO,SAAS,mBAAmB,KAAqB;AACtD,SAAO,KAAK,WAAW,GAAG,GAAG,eAAe;AAC9C;AAEO,SAAS,gBAAgB,KAAqB;AACnD,SAAO,KAAK,KAAK,MAAM,GAAG,SAAS,GAAG,CAAC,cAAc;AACvD;","names":[]}
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"sources":["../src/shared/config.ts","../src/shared/env.ts","../src/shared/exec.ts"],"sourcesContent":["import { readFileSync } from 'node:fs';\nimport { globalConfigPath, projectConfigPath } from './paths.js';\n\nexport interface WorktreeConfig {\n copy?: string[];\n clone?: string[];\n symlink?: string[];\n init?: string;\n}\n\nexport type EffortLevel = 'low' | 'medium' | 'high' | 'max';\n\nexport interface Config {\n model?: string;\n tmuxSession?: string;\n orchestratorPrompt?: string;\n pollIntervalMs?: number;\n autoUpdate?: boolean;\n orchestratorEffort?: EffortLevel;\n agentEffort?: EffortLevel;\n editor?: string;\n}\n\nconst DEFAULT_CONFIG: Config = {\n pollIntervalMs: 5000,\n orchestratorEffort: 'high',\n agentEffort: 'medium',\n};\n\nfunction readJsonFile(filePath: string): Partial<Config> {\n try {\n const content = readFileSync(filePath, 'utf-8');\n return JSON.parse(content) as Partial<Config>;\n } catch {\n return {};\n }\n}\n\nexport function loadConfig(cwd: string): Config {\n const global = readJsonFile(globalConfigPath());\n const project = readJsonFile(projectConfigPath(cwd));\n return { ...DEFAULT_CONFIG, ...global, ...project };\n}\n","/**\n * Build a PATH string that includes common binary directories\n * across package managers and platforms.\n *\n * Prepends known directories that exist on the system to the current PATH.\n * This ensures tmux commands can find binaries installed by Homebrew,\n * MacPorts, nix, and other package managers.\n */\nexport function augmentedPath(): string {\n const rawPath = process.env['PATH'];\n const basePath = rawPath !== undefined && rawPath.length > 0 ? rawPath : '/usr/bin:/bin';\n\n // Common binary directories across platforms/package managers.\n // Only prepend ones that aren't already in PATH.\n const candidates = [\n '/opt/homebrew/bin', // Homebrew (Apple Silicon macOS)\n '/opt/homebrew/sbin', // Homebrew sbin\n '/usr/local/bin', // Homebrew (Intel macOS), manual installs\n '/usr/local/sbin', // Manual installs\n '/opt/local/bin', // MacPorts\n '/opt/local/sbin', // MacPorts\n '/home/linuxbrew/.linuxbrew/bin', // Linuxbrew\n ];\n\n // Check for nix profile paths\n const nixProfile = process.env['NIX_PROFILES'];\n if (nixProfile) {\n for (const p of nixProfile.split(' ').reverse()) {\n candidates.push(`${p}/bin`);\n }\n }\n\n const existing = new Set(basePath.split(':'));\n const prepend = candidates.filter(dir => !existing.has(dir));\n\n return prepend.length > 0 ? `${prepend.join(':')}:${basePath}` : basePath;\n}\n\n/**\n * Environment variables for child processes that need access to\n * user-installed binaries (tmux, git, claude, etc.).\n */\nexport function execEnv(): Record<string, string | undefined> {\n return {\n ...process.env,\n PATH: augmentedPath(),\n };\n}\n","import { execSync } from 'node:child_process';\nimport { execEnv } from './env.js';\n\nexport const EXEC_ENV = execEnv();\n\nexport function exec(cmd: string, cwd?: string): string {\n return execSync(cmd, { encoding: 'utf-8', env: EXEC_ENV, cwd }).trim();\n}\n\nexport function execSafe(cmd: string, cwd?: string): string | null {\n try {\n return execSync(cmd, { encoding: 'utf-8', env: EXEC_ENV, cwd, stdio: ['pipe', 'pipe', 'pipe'] }).trim();\n } catch { return null; }\n}\n"],"mappings":";;;;;;;AAAA,SAAS,oBAAoB;AAuB7B,IAAM,iBAAyB;AAAA,EAC7B,gBAAgB;AAAA,EAChB,oBAAoB;AAAA,EACpB,aAAa;AACf;AAEA,SAAS,aAAa,UAAmC;AACvD,MAAI;AACF,UAAM,UAAU,aAAa,UAAU,OAAO;AAC9C,WAAO,KAAK,MAAM,OAAO;AAAA,EAC3B,QAAQ;AACN,WAAO,CAAC;AAAA,EACV;AACF;AAEO,SAAS,WAAW,KAAqB;AAC9C,QAAM,SAAS,aAAa,iBAAiB,CAAC;AAC9C,QAAM,UAAU,aAAa,kBAAkB,GAAG,CAAC;AACnD,SAAO,EAAE,GAAG,gBAAgB,GAAG,QAAQ,GAAG,QAAQ;AACpD;;;AClCO,SAAS,gBAAwB;AACtC,QAAM,UAAU,QAAQ,IAAI,MAAM;AAClC,QAAM,WAAW,YAAY,UAAa,QAAQ,SAAS,IAAI,UAAU;AAIzE,QAAM,aAAa;AAAA,IACjB;AAAA;AAAA,IACA;AAAA;AAAA,IACA;AAAA;AAAA,IACA;AAAA;AAAA,IACA;AAAA;AAAA,IACA;AAAA;AAAA,IACA;AAAA;AAAA,EACF;AAGA,QAAM,aAAa,QAAQ,IAAI,cAAc;AAC7C,MAAI,YAAY;AACd,eAAW,KAAK,WAAW,MAAM,GAAG,EAAE,QAAQ,GAAG;AAC/C,iBAAW,KAAK,GAAG,CAAC,MAAM;AAAA,IAC5B;AAAA,EACF;AAEA,QAAM,WAAW,IAAI,IAAI,SAAS,MAAM,GAAG,CAAC;AAC5C,QAAM,UAAU,WAAW,OAAO,SAAO,CAAC,SAAS,IAAI,GAAG,CAAC;AAE3D,SAAO,QAAQ,SAAS,IAAI,GAAG,QAAQ,KAAK,GAAG,CAAC,IAAI,QAAQ,KAAK;AACnE;AAMO,SAAS,UAA8C;AAC5D,SAAO;AAAA,IACL,GAAG,QAAQ;AAAA,IACX,MAAM,cAAc;AAAA,EACtB;AACF;;;AC/CA,SAAS,gBAAgB;AAGlB,IAAM,WAAW,QAAQ;AAEzB,SAAS,KAAK,KAAa,KAAsB;AACtD,SAAO,SAAS,KAAK,EAAE,UAAU,SAAS,KAAK,UAAU,IAAI,CAAC,EAAE,KAAK;AACvE;AAEO,SAAS,SAAS,KAAa,KAA6B;AACjE,MAAI;AACF,WAAO,SAAS,KAAK,EAAE,UAAU,SAAS,KAAK,UAAU,KAAK,OAAO,CAAC,QAAQ,QAAQ,MAAM,EAAE,CAAC,EAAE,KAAK;AAAA,EACxG,QAAQ;AAAE,WAAO;AAAA,EAAM;AACzB;","names":[]}
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"sources":["../src/shared/utils.ts","../src/shared/format.ts","../src/tui/lib/reports.ts","../src/tui/lib/context.ts","../src/shared/client.ts"],"sourcesContent":["import type { Session } from './types.js';\n\n/**\n * Compute the total wall-clock milliseconds during which at least one\n * orchestrator cycle or agent was running. Merges overlapping intervals\n * so parallel agents aren't double-counted.\n */\nexport function computeActiveTimeMs(session: Session): number {\n const now = Date.now();\n const intervals: Array<[number, number]> = [];\n\n for (const cycle of session.orchestratorCycles) {\n const start = new Date(cycle.timestamp).getTime();\n const end = cycle.completedAt ? new Date(cycle.completedAt).getTime() : now;\n if (end > start) intervals.push([start, end]);\n }\n\n for (const agent of session.agents) {\n const start = new Date(agent.spawnedAt).getTime();\n const end = agent.completedAt ? new Date(agent.completedAt).getTime() : now;\n if (end > start) intervals.push([start, end]);\n }\n\n if (intervals.length === 0) return 0;\n\n intervals.sort((a, b) => a[0] - b[0]);\n\n const merged: Array<[number, number]> = [intervals[0]!];\n for (let i = 1; i < intervals.length; i++) {\n const last = merged[merged.length - 1]!;\n const cur = intervals[i]!;\n if (cur[0] <= last[1]) {\n last[1] = Math.max(last[1], cur[1]);\n } else {\n merged.push(cur);\n }\n }\n\n return merged.reduce((sum, [start, end]) => sum + (end - start), 0);\n}\n","/** Format milliseconds or ISO date range to human-readable duration */\nexport function formatDuration(startOrMs: string | number, endIso?: string | null): string {\n let totalMs: number;\n if (typeof startOrMs === 'number') {\n totalMs = startOrMs;\n } else {\n const start = new Date(startOrMs).getTime();\n const end = endIso ? new Date(endIso).getTime() : Date.now();\n totalMs = end - start;\n }\n const totalSeconds = Math.floor(totalMs / 1000);\n if (totalSeconds < 0) return '0s';\n const hours = Math.floor(totalSeconds / 3600);\n const minutes = Math.floor((totalSeconds % 3600) / 60);\n const seconds = totalSeconds % 60;\n if (hours > 0) return `${hours}h${minutes}m`;\n if (minutes > 0) return `${minutes}m${seconds}s`;\n return `${seconds}s`;\n}\n\n/** Map session/agent status to a color name */\nexport function statusColor(status: string): string {\n switch (status) {\n case 'active':\n case 'running':\n return 'green';\n case 'completed':\n return 'cyan';\n case 'paused':\n return 'yellow';\n case 'killed':\n case 'crashed':\n return 'red';\n case 'lost':\n return 'gray';\n default:\n return 'white';\n }\n}\n","import { readFileSync } from 'node:fs';\nimport type { AgentReport } from '../../shared/types.js';\n\nexport interface ReportBlock {\n type: 'update' | 'final';\n timestamp: string;\n content: string;\n summary: string;\n}\n\nfunction loadReportContent(report: AgentReport): string {\n try {\n return readFileSync(report.filePath, 'utf-8');\n } catch {\n return report.summary;\n }\n}\n\nexport function resolveReports(reports: AgentReport[]): ReportBlock[] {\n return [...reports].reverse().map((r) => ({\n type: r.type as 'update' | 'final',\n timestamp: r.timestamp,\n content: loadReportContent(r),\n summary: r.summary,\n }));\n}\n","import { readFileSync, readdirSync } from 'node:fs';\nimport { goalPath, roadmapPath, sessionsDir, statePath } from '../../shared/paths.js';\nimport { resolveReports } from './reports.js';\nimport type { Session, AgentStatus } from '../../shared/types.js';\n\nfunction readFileSafe(filePath: string): string | null {\n try {\n return readFileSync(filePath, 'utf-8');\n } catch {\n return null;\n }\n}\n\nfunction escapeXml(s: string): string {\n return s\n .replace(/&/g, '&')\n .replace(/</g, '<')\n .replace(/>/g, '>')\n .replace(/\"/g, '"');\n}\n\nexport function buildCompanionContext(cwd: string): string {\n let sessionDirs: string[];\n try {\n sessionDirs = readdirSync(sessionsDir(cwd));\n } catch {\n return '<sessions>No sessions found.</sessions>';\n }\n\n const now = Date.now();\n const sevenDaysMs = 7 * 24 * 60 * 60 * 1000;\n const sessionBlocks: string[] = [];\n\n for (const sessionId of sessionDirs) {\n const stateRaw = readFileSafe(statePath(cwd, sessionId));\n if (!stateRaw) continue;\n\n let session: Session;\n try {\n session = JSON.parse(stateRaw) as Session;\n } catch {\n continue;\n }\n\n // Skip completed sessions older than 7 days\n if (session.status === 'completed' && session.completedAt) {\n if (now - new Date(session.completedAt).getTime() > sevenDaysMs) continue;\n }\n\n const lines: string[] = [];\n const nameAttr = session.name ? ` name=\"${escapeXml(session.name)}\"` : '';\n lines.push(` <session id=\"${escapeXml(session.id)}\"${nameAttr} status=\"${escapeXml(session.status)}\">`);\n lines.push(` <task>${escapeXml(session.task)}</task>`);\n lines.push(` <created>${escapeXml(session.createdAt)}</created>`);\n lines.push(` <cycles>${session.orchestratorCycles.length}</cycles>`);\n\n if (session.status === 'completed') {\n if (session.completionReport) {\n const snippet = session.completionReport.slice(0, 300).replace(/\\n+/g, ' ').trim();\n lines.push(` <completion-report>${escapeXml(snippet)}${session.completionReport.length > 300 ? '…' : ''}</completion-report>`);\n }\n } else {\n // Agent summary by status\n if (session.agents.length > 0) {\n const counts = new Map<AgentStatus, number>();\n for (const agent of session.agents) {\n counts.set(agent.status, (counts.get(agent.status) ?? 0) + 1);\n }\n const summary = [...counts.entries()].map(([status, n]) => `${n} ${status}`).join(', ');\n lines.push(` <agents>${escapeXml(summary)}</agents>`);\n }\n\n // Goal: first meaningful line\n const goalContent = readFileSafe(goalPath(cwd, session.id));\n if (goalContent) {\n const firstLine = goalContent.split('\\n').map(l => l.trim()).find(l => l.length > 0 && !l.startsWith('#'));\n if (firstLine) lines.push(` <goal>${escapeXml(firstLine)}</goal>`);\n }\n\n // Roadmap unchecked todos (up to 5)\n const roadmapContent = readFileSafe(roadmapPath(cwd, session.id));\n if (roadmapContent) {\n const todos = roadmapContent\n .split('\\n')\n .filter(l => l.includes('- [ ]'))\n .slice(0, 5)\n .map(l => l.trim());\n if (todos.length > 0) {\n lines.push(' <todos>');\n for (const todo of todos) lines.push(` ${escapeXml(todo)}`);\n lines.push(' </todos>');\n }\n }\n }\n\n lines.push(' </session>');\n sessionBlocks.push(lines.join('\\n'));\n }\n\n if (sessionBlocks.length === 0) {\n return '<sessions>No sessions found.</sessions>';\n }\n\n return ['<sessions>', ...sessionBlocks, '</sessions>'].join('\\n');\n}\n\nexport function buildSessionContext(session: Session, cwd: string): string {\n const goal = readFileSafe(goalPath(cwd, session.id));\n const roadmap = readFileSafe(roadmapPath(cwd, session.id));\n\n const agentsXml = session.agents.map((agent) => {\n const reportBlocks = resolveReports(agent.reports);\n // resolveReports returns newest-first; reverse to chronological for context\n const reportsXml = [...reportBlocks].reverse().map((block) => {\n return ` <report type=\"${block.type}\" time=\"${escapeXml(block.timestamp)}\">${escapeXml(block.content)}</report>`;\n }).join('\\n');\n\n return [\n ` <agent id=\"${escapeXml(agent.id)}\" name=\"${escapeXml(agent.name)}\" type=\"${escapeXml(agent.agentType)}\" status=\"${escapeXml(agent.status)}\">`,\n ` <instruction>${escapeXml(agent.instruction)}</instruction>`,\n ...(reportsXml ? [reportsXml] : []),\n ` </agent>`,\n ].join('\\n');\n }).join('\\n');\n\n const cyclesXml = session.orchestratorCycles.map((cycle) => {\n const agents = cycle.agentsSpawned.join(', ');\n const mode = cycle.mode ? ` mode=\"${escapeXml(cycle.mode)}\"` : '';\n return ` <cycle number=\"${cycle.cycle}\"${mode} agents=\"${escapeXml(agents)}\" />`;\n }).join('\\n');\n\n const lines: string[] = [\n '<context>',\n `<session id=\"${escapeXml(session.id)}\" status=\"${escapeXml(session.status)}\">`,\n ` <task>${escapeXml(session.task)}</task>`,\n ` <cwd>${escapeXml(session.cwd)}</cwd>`,\n ];\n\n if (goal) lines.push(` <goal>${escapeXml(goal)}</goal>`);\n if (roadmap) lines.push(` <roadmap>${escapeXml(roadmap)}</roadmap>`);\n\n if (session.agents.length > 0) {\n lines.push(' <agents>');\n lines.push(agentsXml);\n lines.push(' </agents>');\n }\n\n if (session.orchestratorCycles.length > 0) {\n lines.push(' <cycles>');\n lines.push(cyclesXml);\n lines.push(' </cycles>');\n }\n\n if (session.completionReport) {\n lines.push(` <completion-report>${escapeXml(session.completionReport)}</completion-report>`);\n }\n\n lines.push('</session>');\n lines.push('</context>');\n\n return lines.join('\\n');\n}\n","import { connect } from 'node:net';\nimport { socketPath } from './paths.js';\nimport type { Request, Response } from './protocol.js';\n\nexport function rawSend(request: Request, timeoutMs = 10_000): Promise<Response> {\n const sock = socketPath();\n\n return new Promise<Response>((resolve, reject) => {\n const socket = connect(sock);\n let data = '';\n\n const timeout = setTimeout(() => {\n socket.destroy();\n reject(new Error(`Request timed out after ${(timeoutMs / 1000).toFixed(0)}s. The daemon may be overloaded.\\n Check: sisyphus doctor\\n Logs: tail -20 ~/.sisyphus/daemon.log`));\n }, timeoutMs);\n\n socket.on('connect', () => {\n socket.write(JSON.stringify(request) + '\\n');\n });\n\n socket.on('data', (chunk) => {\n data += chunk.toString();\n const newlineIdx = data.indexOf('\\n');\n if (newlineIdx !== -1) {\n clearTimeout(timeout);\n const line = data.slice(0, newlineIdx);\n socket.destroy();\n try {\n resolve(JSON.parse(line) as Response);\n } catch {\n reject(new Error(`Invalid JSON response from daemon: ${line}`));\n }\n }\n });\n\n socket.on('error', (err) => {\n clearTimeout(timeout);\n reject(err);\n });\n });\n}\n"],"mappings":";;;;;;;;;;AAOO,SAAS,oBAAoB,SAA0B;AAC5D,QAAM,MAAM,KAAK,IAAI;AACrB,QAAM,YAAqC,CAAC;AAE5C,aAAW,SAAS,QAAQ,oBAAoB;AAC9C,UAAM,QAAQ,IAAI,KAAK,MAAM,SAAS,EAAE,QAAQ;AAChD,UAAM,MAAM,MAAM,cAAc,IAAI,KAAK,MAAM,WAAW,EAAE,QAAQ,IAAI;AACxE,QAAI,MAAM,MAAO,WAAU,KAAK,CAAC,OAAO,GAAG,CAAC;AAAA,EAC9C;AAEA,aAAW,SAAS,QAAQ,QAAQ;AAClC,UAAM,QAAQ,IAAI,KAAK,MAAM,SAAS,EAAE,QAAQ;AAChD,UAAM,MAAM,MAAM,cAAc,IAAI,KAAK,MAAM,WAAW,EAAE,QAAQ,IAAI;AACxE,QAAI,MAAM,MAAO,WAAU,KAAK,CAAC,OAAO,GAAG,CAAC;AAAA,EAC9C;AAEA,MAAI,UAAU,WAAW,EAAG,QAAO;AAEnC,YAAU,KAAK,CAAC,GAAG,MAAM,EAAE,CAAC,IAAI,EAAE,CAAC,CAAC;AAEpC,QAAM,SAAkC,CAAC,UAAU,CAAC,CAAE;AACtD,WAAS,IAAI,GAAG,IAAI,UAAU,QAAQ,KAAK;AACzC,UAAM,OAAO,OAAO,OAAO,SAAS,CAAC;AACrC,UAAM,MAAM,UAAU,CAAC;AACvB,QAAI,IAAI,CAAC,KAAK,KAAK,CAAC,GAAG;AACrB,WAAK,CAAC,IAAI,KAAK,IAAI,KAAK,CAAC,GAAG,IAAI,CAAC,CAAC;AAAA,IACpC,OAAO;AACL,aAAO,KAAK,GAAG;AAAA,IACjB;AAAA,EACF;AAEA,SAAO,OAAO,OAAO,CAAC,KAAK,CAAC,OAAO,GAAG,MAAM,OAAO,MAAM,QAAQ,CAAC;AACpE;;;ACtCO,SAAS,eAAe,WAA4B,QAAgC;AACzF,MAAI;AACJ,MAAI,OAAO,cAAc,UAAU;AACjC,cAAU;AAAA,EACZ,OAAO;AACL,UAAM,QAAQ,IAAI,KAAK,SAAS,EAAE,QAAQ;AAC1C,UAAM,MAAM,SAAS,IAAI,KAAK,MAAM,EAAE,QAAQ,IAAI,KAAK,IAAI;AAC3D,cAAU,MAAM;AAAA,EAClB;AACA,QAAM,eAAe,KAAK,MAAM,UAAU,GAAI;AAC9C,MAAI,eAAe,EAAG,QAAO;AAC7B,QAAM,QAAQ,KAAK,MAAM,eAAe,IAAI;AAC5C,QAAM,UAAU,KAAK,MAAO,eAAe,OAAQ,EAAE;AACrD,QAAM,UAAU,eAAe;AAC/B,MAAI,QAAQ,EAAG,QAAO,GAAG,KAAK,IAAI,OAAO;AACzC,MAAI,UAAU,EAAG,QAAO,GAAG,OAAO,IAAI,OAAO;AAC7C,SAAO,GAAG,OAAO;AACnB;AAGO,SAAS,YAAY,QAAwB;AAClD,UAAQ,QAAQ;AAAA,IACd,KAAK;AAAA,IACL,KAAK;AACH,aAAO;AAAA,IACT,KAAK;AACH,aAAO;AAAA,IACT,KAAK;AACH,aAAO;AAAA,IACT,KAAK;AAAA,IACL,KAAK;AACH,aAAO;AAAA,IACT,KAAK;AACH,aAAO;AAAA,IACT;AACE,aAAO;AAAA,EACX;AACF;;;ACtCA,SAAS,oBAAoB;AAU7B,SAAS,kBAAkB,QAA6B;AACtD,MAAI;AACF,WAAO,aAAa,OAAO,UAAU,OAAO;AAAA,EAC9C,QAAQ;AACN,WAAO,OAAO;AAAA,EAChB;AACF;AAEO,SAAS,eAAe,SAAuC;AACpE,SAAO,CAAC,GAAG,OAAO,EAAE,QAAQ,EAAE,IAAI,CAAC,OAAO;AAAA,IACxC,MAAM,EAAE;AAAA,IACR,WAAW,EAAE;AAAA,IACb,SAAS,kBAAkB,CAAC;AAAA,IAC5B,SAAS,EAAE;AAAA,EACb,EAAE;AACJ;;;ACzBA,SAAS,gBAAAA,eAAc,mBAAmB;AAK1C,SAAS,aAAa,UAAiC;AACrD,MAAI;AACF,WAAOC,cAAa,UAAU,OAAO;AAAA,EACvC,QAAQ;AACN,WAAO;AAAA,EACT;AACF;AAEA,SAAS,UAAU,GAAmB;AACpC,SAAO,EACJ,QAAQ,MAAM,OAAO,EACrB,QAAQ,MAAM,MAAM,EACpB,QAAQ,MAAM,MAAM,EACpB,QAAQ,MAAM,QAAQ;AAC3B;AAEO,SAAS,sBAAsB,KAAqB;AACzD,MAAI;AACJ,MAAI;AACF,kBAAc,YAAY,YAAY,GAAG,CAAC;AAAA,EAC5C,QAAQ;AACN,WAAO;AAAA,EACT;AAEA,QAAM,MAAM,KAAK,IAAI;AACrB,QAAM,cAAc,IAAI,KAAK,KAAK,KAAK;AACvC,QAAM,gBAA0B,CAAC;AAEjC,aAAW,aAAa,aAAa;AACnC,UAAM,WAAW,aAAa,UAAU,KAAK,SAAS,CAAC;AACvD,QAAI,CAAC,SAAU;AAEf,QAAI;AACJ,QAAI;AACF,gBAAU,KAAK,MAAM,QAAQ;AAAA,IAC/B,QAAQ;AACN;AAAA,IACF;AAGA,QAAI,QAAQ,WAAW,eAAe,QAAQ,aAAa;AACzD,UAAI,MAAM,IAAI,KAAK,QAAQ,WAAW,EAAE,QAAQ,IAAI,YAAa;AAAA,IACnE;AAEA,UAAM,QAAkB,CAAC;AACzB,UAAM,WAAW,QAAQ,OAAO,UAAU,UAAU,QAAQ,IAAI,CAAC,MAAM;AACvE,UAAM,KAAK,kBAAkB,UAAU,QAAQ,EAAE,CAAC,IAAI,QAAQ,YAAY,UAAU,QAAQ,MAAM,CAAC,IAAI;AACvG,UAAM,KAAK,aAAa,UAAU,QAAQ,IAAI,CAAC,SAAS;AACxD,UAAM,KAAK,gBAAgB,UAAU,QAAQ,SAAS,CAAC,YAAY;AACnE,UAAM,KAAK,eAAe,QAAQ,mBAAmB,MAAM,WAAW;AAEtE,QAAI,QAAQ,WAAW,aAAa;AAClC,UAAI,QAAQ,kBAAkB;AAC5B,cAAM,UAAU,QAAQ,iBAAiB,MAAM,GAAG,GAAG,EAAE,QAAQ,QAAQ,GAAG,EAAE,KAAK;AACjF,cAAM,KAAK,0BAA0B,UAAU,OAAO,CAAC,GAAG,QAAQ,iBAAiB,SAAS,MAAM,WAAM,EAAE,sBAAsB;AAAA,MAClI;AAAA,IACF,OAAO;AAEL,UAAI,QAAQ,OAAO,SAAS,GAAG;AAC7B,cAAM,SAAS,oBAAI,IAAyB;AAC5C,mBAAW,SAAS,QAAQ,QAAQ;AAClC,iBAAO,IAAI,MAAM,SAAS,OAAO,IAAI,MAAM,MAAM,KAAK,KAAK,CAAC;AAAA,QAC9D;AACA,cAAM,UAAU,CAAC,GAAG,OAAO,QAAQ,CAAC,EAAE,IAAI,CAAC,CAAC,QAAQ,CAAC,MAAM,GAAG,CAAC,IAAI,MAAM,EAAE,EAAE,KAAK,IAAI;AACtF,cAAM,KAAK,eAAe,UAAU,OAAO,CAAC,WAAW;AAAA,MACzD;AAGA,YAAM,cAAc,aAAa,SAAS,KAAK,QAAQ,EAAE,CAAC;AAC1D,UAAI,aAAa;AACf,cAAM,YAAY,YAAY,MAAM,IAAI,EAAE,IAAI,OAAK,EAAE,KAAK,CAAC,EAAE,KAAK,OAAK,EAAE,SAAS,KAAK,CAAC,EAAE,WAAW,GAAG,CAAC;AACzG,YAAI,UAAW,OAAM,KAAK,aAAa,UAAU,SAAS,CAAC,SAAS;AAAA,MACtE;AAGA,YAAM,iBAAiB,aAAa,YAAY,KAAK,QAAQ,EAAE,CAAC;AAChE,UAAI,gBAAgB;AAClB,cAAM,QAAQ,eACX,MAAM,IAAI,EACV,OAAO,OAAK,EAAE,SAAS,OAAO,CAAC,EAC/B,MAAM,GAAG,CAAC,EACV,IAAI,OAAK,EAAE,KAAK,CAAC;AACpB,YAAI,MAAM,SAAS,GAAG;AACpB,gBAAM,KAAK,aAAa;AACxB,qBAAW,QAAQ,MAAO,OAAM,KAAK,SAAS,UAAU,IAAI,CAAC,EAAE;AAC/D,gBAAM,KAAK,cAAc;AAAA,QAC3B;AAAA,MACF;AAAA,IACF;AAEA,UAAM,KAAK,cAAc;AACzB,kBAAc,KAAK,MAAM,KAAK,IAAI,CAAC;AAAA,EACrC;AAEA,MAAI,cAAc,WAAW,GAAG;AAC9B,WAAO;AAAA,EACT;AAEA,SAAO,CAAC,cAAc,GAAG,eAAe,aAAa,EAAE,KAAK,IAAI;AAClE;AAEO,SAAS,oBAAoB,SAAkB,KAAqB;AACzE,QAAM,OAAO,aAAa,SAAS,KAAK,QAAQ,EAAE,CAAC;AACnD,QAAM,UAAU,aAAa,YAAY,KAAK,QAAQ,EAAE,CAAC;AAEzD,QAAM,YAAY,QAAQ,OAAO,IAAI,CAAC,UAAU;AAC9C,UAAM,eAAe,eAAe,MAAM,OAAO;AAEjD,UAAM,aAAa,CAAC,GAAG,YAAY,EAAE,QAAQ,EAAE,IAAI,CAAC,UAAU;AAC5D,aAAO,uBAAuB,MAAM,IAAI,WAAW,UAAU,MAAM,SAAS,CAAC,KAAK,UAAU,MAAM,OAAO,CAAC;AAAA,IAC5G,CAAC,EAAE,KAAK,IAAI;AAEZ,WAAO;AAAA,MACL,kBAAkB,UAAU,MAAM,EAAE,CAAC,WAAW,UAAU,MAAM,IAAI,CAAC,WAAW,UAAU,MAAM,SAAS,CAAC,aAAa,UAAU,MAAM,MAAM,CAAC;AAAA,MAC9I,sBAAsB,UAAU,MAAM,WAAW,CAAC;AAAA,MAClD,GAAI,aAAa,CAAC,UAAU,IAAI,CAAC;AAAA,MACjC;AAAA,IACF,EAAE,KAAK,IAAI;AAAA,EACb,CAAC,EAAE,KAAK,IAAI;AAEZ,QAAM,YAAY,QAAQ,mBAAmB,IAAI,CAAC,UAAU;AAC1D,UAAM,SAAS,MAAM,cAAc,KAAK,IAAI;AAC5C,UAAM,OAAO,MAAM,OAAO,UAAU,UAAU,MAAM,IAAI,CAAC,MAAM;AAC/D,WAAO,sBAAsB,MAAM,KAAK,IAAI,IAAI,YAAY,UAAU,MAAM,CAAC;AAAA,EAC/E,CAAC,EAAE,KAAK,IAAI;AAEZ,QAAM,QAAkB;AAAA,IACtB;AAAA,IACA,gBAAgB,UAAU,QAAQ,EAAE,CAAC,aAAa,UAAU,QAAQ,MAAM,CAAC;AAAA,IAC3E,WAAW,UAAU,QAAQ,IAAI,CAAC;AAAA,IAClC,UAAU,UAAU,QAAQ,GAAG,CAAC;AAAA,EAClC;AAEA,MAAI,KAAM,OAAM,KAAK,WAAW,UAAU,IAAI,CAAC,SAAS;AACxD,MAAI,QAAS,OAAM,KAAK,cAAc,UAAU,OAAO,CAAC,YAAY;AAEpE,MAAI,QAAQ,OAAO,SAAS,GAAG;AAC7B,UAAM,KAAK,YAAY;AACvB,UAAM,KAAK,SAAS;AACpB,UAAM,KAAK,aAAa;AAAA,EAC1B;AAEA,MAAI,QAAQ,mBAAmB,SAAS,GAAG;AACzC,UAAM,KAAK,YAAY;AACvB,UAAM,KAAK,SAAS;AACpB,UAAM,KAAK,aAAa;AAAA,EAC1B;AAEA,MAAI,QAAQ,kBAAkB;AAC5B,UAAM,KAAK,wBAAwB,UAAU,QAAQ,gBAAgB,CAAC,sBAAsB;AAAA,EAC9F;AAEA,QAAM,KAAK,YAAY;AACvB,QAAM,KAAK,YAAY;AAEvB,SAAO,MAAM,KAAK,IAAI;AACxB;;;ACjKA,SAAS,eAAe;AAIjB,SAAS,QAAQ,SAAkB,YAAY,KAA2B;AAC/E,QAAM,OAAO,WAAW;AAExB,SAAO,IAAI,QAAkB,CAAC,SAAS,WAAW;AAChD,UAAM,SAAS,QAAQ,IAAI;AAC3B,QAAI,OAAO;AAEX,UAAM,UAAU,WAAW,MAAM;AAC/B,aAAO,QAAQ;AACf,aAAO,IAAI,MAAM,4BAA4B,YAAY,KAAM,QAAQ,CAAC,CAAC;AAAA;AAAA,wCAAqG,CAAC;AAAA,IACjL,GAAG,SAAS;AAEZ,WAAO,GAAG,WAAW,MAAM;AACzB,aAAO,MAAM,KAAK,UAAU,OAAO,IAAI,IAAI;AAAA,IAC7C,CAAC;AAED,WAAO,GAAG,QAAQ,CAAC,UAAU;AAC3B,cAAQ,MAAM,SAAS;AACvB,YAAM,aAAa,KAAK,QAAQ,IAAI;AACpC,UAAI,eAAe,IAAI;AACrB,qBAAa,OAAO;AACpB,cAAM,OAAO,KAAK,MAAM,GAAG,UAAU;AACrC,eAAO,QAAQ;AACf,YAAI;AACF,kBAAQ,KAAK,MAAM,IAAI,CAAa;AAAA,QACtC,QAAQ;AACN,iBAAO,IAAI,MAAM,sCAAsC,IAAI,EAAE,CAAC;AAAA,QAChE;AAAA,MACF;AAAA,IACF,CAAC;AAED,WAAO,GAAG,SAAS,CAAC,QAAQ;AAC1B,mBAAa,OAAO;AACpB,aAAO,GAAG;AAAA,IACZ,CAAC;AAAA,EACH,CAAC;AACH;","names":["readFileSync","readFileSync"]}
|
|
@@ -1,44 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: spec-coverage
|
|
3
|
-
description: Spec coverage reviewer — verifies every spec requirement maps to a concrete plan section, classifies as Covered/Partial/Missing.
|
|
4
|
-
model: sonnet
|
|
5
|
-
---
|
|
6
|
-
|
|
7
|
-
You are a spec coverage reviewer. Your job is to verify that every requirement in the spec has a concrete, actionable plan section.
|
|
8
|
-
|
|
9
|
-
## How to Review
|
|
10
|
-
|
|
11
|
-
For each requirement in the spec, classify:
|
|
12
|
-
- **Covered**: Plan addresses with file-level detail sufficient to start coding
|
|
13
|
-
- **Partial**: Plan mentions but lacks specifics (which file, which function, what signature)
|
|
14
|
-
- **Missing**: Not addressed at all
|
|
15
|
-
|
|
16
|
-
Check specifically:
|
|
17
|
-
- API contracts (routes, methods, request/response shapes, status codes)
|
|
18
|
-
- Data model changes (fields, types, nullability, indexes, migrations)
|
|
19
|
-
- UI requirements (components, layout, interactions, states)
|
|
20
|
-
- Error handling (what errors, how surfaced, user-facing messages)
|
|
21
|
-
- Edge cases explicitly called out in spec
|
|
22
|
-
|
|
23
|
-
## What Counts as Blocking
|
|
24
|
-
|
|
25
|
-
Flag **blocking** gaps only — things an implementer would have to stop and ask about:
|
|
26
|
-
- Missing endpoint definitions (route, method, shape)
|
|
27
|
-
- Data model fields mentioned in spec but not in plan
|
|
28
|
-
- Error scenarios with no handling strategy
|
|
29
|
-
- UI states (loading, empty, error) not addressed
|
|
30
|
-
|
|
31
|
-
## Do NOT Flag
|
|
32
|
-
|
|
33
|
-
- Minor wording differences between spec and plan
|
|
34
|
-
- Implementation details the plan intentionally leaves to the developer
|
|
35
|
-
- Non-functional requirements that don't affect correctness
|
|
36
|
-
|
|
37
|
-
## Output
|
|
38
|
-
|
|
39
|
-
For each gap:
|
|
40
|
-
- **Severity**: Critical (missing entirely) / High (partial, blocks implementation) / Medium (partial, non-blocking)
|
|
41
|
-
- **Spec requirement**: Quote the specific requirement
|
|
42
|
-
- **Plan status**: Covered / Partial / Missing
|
|
43
|
-
- **Evidence**: What the plan says (or doesn't say)
|
|
44
|
-
- **Fix**: What the plan should add
|