sisyphi 1.1.36 → 1.1.38

package/dist/deploy/shared/cloud-init.yaml.tpl

@@ -67,7 +67,13 @@ write_files:
 runcmd:
   # 1. Base packages.
   - apt-get update
-  - DEBIAN_FRONTEND=noninteractive apt-get install -y curl git tmux fzf neovim build-essential ufw mosh ca-certificates gnupg
+  - DEBIAN_FRONTEND=noninteractive apt-get install -y curl git tmux fzf neovim build-essential ufw mosh ca-certificates gnupg pipx
+
+  # 1b. termrender — TUI markdown rendering. Without it the dashboard falls
+  # back to plain text. Install system-wide via pipx so the binary lands in
+  # /usr/local/bin and resolves on PATH for both interactive shells and
+  # systemd user services (same convention as the pbcopy/pbpaste shims).
+  - PIPX_HOME=/opt/pipx PIPX_BIN_DIR=/usr/local/bin pipx install termrender
 
   # 2. Node 22 via NodeSource. /usr/bin/node, /usr/bin/npm.
   - curl -fsSL https://deb.nodesource.com/setup_22.x | bash -

package/dist/templates/orchestrator-base.md

@@ -133,12 +133,13 @@ roadmap.md tracks **where you are in the strategy** and what's immediately ahead
 
 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.
 
-**roadmap.md has exactly four sections. Nothing else belongs there.**
+**roadmap.md has exactly three sections. Nothing else belongs there.**
 
-1. **Current Stage** — stage name (matching strategy.md) and brief status
+1. **Current Stage** — stage name (matching strategy.md) and a status line describing what is happening *right now* in this cycle
 2. **Exit Criteria** — concrete, evaluable conditions for leaving this stage
 3. **Active Context** — list of context files currently relevant to the work
-4. **Next Steps** — immediate actions for this and the next cycle
+
+**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`.
 
 **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.
 
@@ -153,7 +154,7 @@ Example roadmap:
 ```markdown
 ## Current Stage
 Stage: develop
-Status: addressing design review feedback before plan stage
+Status: review-fix agents addressing token refresh findings; waiting on user sign-off on revised design
 
 ## Exit Criteria
 - Critical review findings on token refresh flow resolved
@@ -164,14 +165,9 @@ Status: addressing design review feedback before plan stage
 - context/explore-auth-patterns.md
 - context/explore-session-store.md
 - context/requirements-auth.md (draft, under review)
-
-## Next Steps
-- Address review feedback on token refresh flow
-- Get user sign-off on revised design
-- Transition to plan stage
 ```
 
-**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.
+**Remove completed items as stages finish** — exit criteria that are met, context files that are no longer relevant. The roadmap reflects only outstanding work.
 
 ### Cycle Logs — Audit trail (write-only)
 
@@ -208,7 +204,7 @@ Keep all fields concise (under 120 characters each, except unusualEvents items w
 
 ### Keeping Files Current
 
-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.
+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.
 
 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.
 
@@ -244,7 +240,7 @@ Each session lives at `$SISYPHUS_SESSION_DIR/`:
 - `strategy.md` — Problem-solving map: completed stages (compressed), current stage (detailed), future stages (sketched)
 - `goal.md` — Refined goal statement (written during discovery)
 - `initial-prompt.md` — Immutable record of the original user prompt
-- `roadmap.md` — Working memory: current stage, exit criteria, next steps (you own this, update every cycle)
+- `roadmap.md` — Working memory: current stage, exit criteria, active context (you own this, update every cycle)
 - `digest.json` — Dashboard status summary (you own this, update every cycle)
 - `logs.md` — Session log/memory (you own this)
 - `context/` — Persistent artifacts: requirements, designs, plans, exploration findings

package/dist/templates/orchestrator-discovery.md

@@ -160,7 +160,7 @@ Strategy generation is usually fast — the shape of the work is often obvious o
 
 ## Initialize the roadmap
 
-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.
+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.
 
 </roadmap-initialization>
 

package/dist/templates/orchestrator-planning.md

@@ -62,7 +62,7 @@ If you're unsure, spawn the spec agent. The cost of a short spec conversation is
 
 <plan-delegation>
 
-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.
+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.
 
 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.