sisyphi 1.1.36 → 1.1.37

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.
@@ -133,12 +133,13 @@ roadmap.md tracks **where you are in the strategy** and what's immediately ahead
133
133
 
134
134
  You are respawned fresh each cycle — without roadmap.md, you'd have no idea where you are in the strategy or what happened last cycle.
135
135
 
136
- **roadmap.md has exactly four sections. Nothing else belongs there.**
136
+ **roadmap.md has exactly three sections. Nothing else belongs there.**
137
137
 
138
- 1. **Current Stage** — stage name (matching strategy.md) and brief status
138
+ 1. **Current Stage** — stage name (matching strategy.md) and a status line describing what is happening *right now* in this cycle
139
139
  2. **Exit Criteria** — concrete, evaluable conditions for leaving this stage
140
140
  3. **Active Context** — list of context files currently relevant to the work
141
- 4. **Next Steps** — immediate actions for this and the next cycle
141
+
142
+ **Do not predict future work in the roadmap.** No "next steps," no "what's next," no upcoming-action lists. The roadmap captures present state, not plans. Next-cycle orientation belongs in the yield prompt; longer-term shape belongs in `strategy.md`; tactical predictions for the user belong in `digest.json`'s `whatsNext`.
142
143
 
143
144
  **Delete completed items entirely.** Do not mark them done, check them off, or summarize them. Completed work belongs in cycle logs, not the roadmap. The roadmap should get shorter as work completes, not longer. No `[done]` markers, no phase summaries, no completion history.
144
145
 
@@ -153,7 +154,7 @@ Example roadmap:
153
154
  ```markdown
154
155
  ## Current Stage
155
156
  Stage: develop
156
- Status: addressing design review feedback before plan stage
157
+ Status: review-fix agents addressing token refresh findings; waiting on user sign-off on revised design
157
158
 
158
159
  ## Exit Criteria
159
160
  - Critical review findings on token refresh flow resolved
@@ -164,14 +165,9 @@ Status: addressing design review feedback before plan stage
164
165
  - context/explore-auth-patterns.md
165
166
  - context/explore-session-store.md
166
167
  - context/requirements-auth.md (draft, under review)
167
-
168
- ## Next Steps
169
- - Address review feedback on token refresh flow
170
- - Get user sign-off on revised design
171
- - Transition to plan stage
172
168
  ```
173
169
 
174
- **Remove completed items as stages finish** — exit criteria that are met, context files that are no longer relevant, next steps that are done. The roadmap reflects only outstanding work.
170
+ **Remove completed items as stages finish** — exit criteria that are met, context files that are no longer relevant. The roadmap reflects only outstanding work.
175
171
 
176
172
  ### Cycle Logs — Audit trail (write-only)
177
173
 
@@ -208,7 +204,7 @@ Keep all fields concise (under 120 characters each, except unusualEvents items w
208
204
 
209
205
  ### Keeping Files Current
210
206
 
211
- Each cycle: Read roadmap.md. Update it (advance phase status, refine next steps). Update digest.json. Spawn agents. Write your cycle summary to the log file. Then yield.
207
+ Each cycle: Read roadmap.md. Update it (advance phase status, refresh the current-activity line, prune completed exit criteria and stale context entries). Update digest.json. Spawn agents. Write your cycle summary to the log file. Then yield.
212
208
 
213
209
  When something changes the approach: update roadmap.md immediately. If an agent reports something that invalidates the approach, rethink the affected phases — don't patch around it.
214
210
 
@@ -244,7 +240,7 @@ Each session lives at `$SISYPHUS_SESSION_DIR/`:
244
240
  - `strategy.md` — Problem-solving map: completed stages (compressed), current stage (detailed), future stages (sketched)
245
241
  - `goal.md` — Refined goal statement (written during discovery)
246
242
  - `initial-prompt.md` — Immutable record of the original user prompt
247
- - `roadmap.md` — Working memory: current stage, exit criteria, next steps (you own this, update every cycle)
243
+ - `roadmap.md` — Working memory: current stage, exit criteria, active context (you own this, update every cycle)
248
244
  - `digest.json` — Dashboard status summary (you own this, update every cycle)
249
245
  - `logs.md` — Session log/memory (you own this)
250
246
  - `context/` — Persistent artifacts: requirements, designs, plans, exploration findings
@@ -160,7 +160,7 @@ Strategy generation is usually fast — the shape of the work is often obvious o
160
160
 
161
161
  ## Initialize the roadmap
162
162
 
163
- After writing `goal.md` and `strategy.md`, initialize `roadmap.md`. Populate Current Stage and Exit Criteria from the first stage in `strategy.md`. Active Context starts empty; Next Steps lists immediate actions.
163
+ After writing `goal.md` and `strategy.md`, initialize `roadmap.md`. Populate Current Stage and Exit Criteria from the first stage in `strategy.md`. Active Context starts empty.
164
164
 
165
165
  </roadmap-initialization>
166
166
 
@@ -62,7 +62,7 @@ If you're unsure, spawn the spec agent. The cost of a short spec conversation is
62
62
 
63
63
  <plan-delegation>
64
64
 
65
- Once you have context docs and aligned spec outputs (requirements + design), revisit the roadmap — this is the first point where you understand real scope. Roadmap refinement means updating the four canonical sections: current stage, exit criteria, active context references, and next steps. Decisions from exploration and spec work fold into context documents — not the roadmap.
65
+ Once you have context docs and aligned spec outputs (requirements + design), revisit the roadmap — this is the first point where you understand real scope. Roadmap refinement means updating the three canonical sections: current stage, exit criteria, and active context references. Decisions from exploration and spec work fold into context documents — not the roadmap.
66
66
 
67
67
  Spawn **one plan lead** per feature (or per phase — see phase-scoped planning below). Point it at inputs (requirements, design, context docs) — not a pre-made structure. The plan lead handles its own decomposition: it assesses scope, delegates sub-plans if needed, runs adversarial reviews, and delivers a synthesized master plan. **Delegate outcomes, not implementations** — tell the plan lead what needs planning and why, not how to structure the plan.
68
68