sisyphi 1.1.9 → 1.1.11

package/dist/{paths-IJXOAN4E.js → paths-3EL2SCHI.js}

@@ -24,8 +24,9 @@ import {
   snapshotsDir,
   socketPath,
   statePath,
-  strategyPath
-} from "./chunk-REUQ4B45.js";
+  strategyPath,
+  tuiScratchDir
+} from "./chunk-GSXF3TCZ.js";
 export {
   contextDir,
   cycleLogPath,
@@ -51,6 +52,7 @@ export {
   snapshotsDir,
   socketPath,
   statePath,
-  strategyPath
+  strategyPath,
+  tuiScratchDir
 };
-//# sourceMappingURL=paths-IJXOAN4E.js.map
+//# sourceMappingURL=paths-3EL2SCHI.js.map

package/dist/templates/CLAUDE.md

@@ -9,6 +9,7 @@ System prompt templates for orchestrator and agent initialization.
 - **orchestrator-strategy.md** — Strategy-phase orchestrator guidance. Maps out visible stages, acknowledges constraints ahead, and establishes lifecycle ownership.
 - **orchestrator-impl.md** — Implementation-phase orchestrator guidance. Context propagation from planning, code smell escalation, and verification patterns. Appended when `--mode implementation`.
 - **orchestrator-validation.md** — Validation-phase orchestrator guidance. Emphasis on proving features work end-to-end via e2e recipes and operator agents for UI features.
+- **orchestrator-completion.md** — Completion-phase orchestrator guidance. Appended when `--mode completion`.
 - **agent-suffix.md** — Agent system prompt suffix. Contains `{{SESSION_ID}}` and `{{INSTRUCTION}}` placeholders. Rendered once per agent spawn.
 - **dashboard-claude.md** — Dashboard companion prompt. Guides a Claude instance embedded in the TUI to help users manage sessions. Contains `{{CWD}}` and `{{SESSIONS_CONTEXT}}` placeholders.
 - **banner.txt** — ASCII banner (cosmetic).
@@ -32,6 +33,7 @@ System prompt templates for orchestrator and agent initialization.
    - `--mode strategy`: orchestrator-strategy.md
    - `--mode implementation`: orchestrator-impl.md
    - `--mode validation`: orchestrator-validation.md
+   - `--mode completion`: orchestrator-completion.md
 3. Inject session state with agent reports, cycle count, roadmap.md/logs.md references
 4. Load settings from `orchestrator-settings.json` (or project override)
 5. Pass via `--append-system-prompt` flag

package/dist/templates/orchestrator-base.md

@@ -95,7 +95,7 @@ Every cycle, read strategy.md first. It tells you:
 **Strategy is a living document.** Update it when:
 - **The goal crystallizes** — you now see further ahead than when the strategy was written. Detail the next stage, flesh out "Ahead."
 - **The goal shifts** — new information changes what "done" looks like. Revise the affected stages.
-- **A stage completes** — compress it to a one-line summary with artifacts produced. Promote and detail the next stage.
+- **A stage completes** — delete it entirely and promote the next stage. Completed work belongs in cycle logs, not the strategy.
 - **The approach is wrong** — backtracking reveals a fundamental issue. Revise the strategy.
 
 Strategy updates happen every few cycles, not every cycle. The roadmap tracks cycle-to-cycle progress within a stage; the strategy tracks the shape of the work across stages.
@@ -113,6 +113,8 @@ You are respawned fresh each cycle — without roadmap.md, you'd have no idea wh
 3. **Active Context** — list of context files currently relevant to the work
 4. **Next Steps** — immediate actions for this and the next cycle
 
+**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.
+
 **Decisions do not go in the roadmap.** When exploration, review, or user feedback resolves a question or changes the approach, fold the result into the relevant context document (spec, plan, design) or create a new context file. The roadmap references these artifacts but never contains decision content, rationale, or design detail.
 
 **The roadmap is not an implementation plan.** Stage breakdowns, design decisions, and file-level detail live in `context/` files.
@@ -142,7 +144,7 @@ Status: iterating on design after review feedback
 - If clean, transition to plan stage
 ```
 
-**Remove completed context as stages finish** — the roadmap reflects outstanding work, not history.
+**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.
 
 ### Cycle Logs — Audit trail (write-only)
 
@@ -261,7 +263,8 @@ sisyphus yield --mode strategy --prompt "re-evaluate"    # return to strategy mo
 sisyphus yield --mode planning --prompt "re-evaluate"    # switch to planning mode
 sisyphus yield --mode implementation --prompt "begin"    # switch to implementation mode
 sisyphus yield --mode validation --prompt "validate"     # switch to validation mode
-sisyphus complete --report "summary of accomplishments"  # complete the session
+sisyphus yield --mode completion --prompt "validated"     # switch to completion mode (user sign-off)
+sisyphus complete --report "summary of accomplishments"  # complete the session (only from completion mode)
 sisyphus continue                                        # reactivate a completed session
 sisyphus status                                          # check session status
 sisyphus message "note for next cycle"                   # queue message for yourself
@@ -276,14 +279,21 @@ If multiple agents run concurrently, ensure they don't edit the same files. If o
 
 <completion>
 
-Call `sisyphus complete` only when ALL of the following are true:
+**`sisyphus complete` should only be called from completion mode, after explicit user confirmation.**
+
+The completion flow:
+1. Validation passes → yield to completion mode (`sisyphus yield --mode completion`)
+2. Completion mode presents a summary to the user and waits for confirmation
+3. User confirms → `sisyphus complete --report "summary"`
+
+Before yielding to completion mode, verify ALL of the following:
 
 - [ ] The overall goal is genuinely achieved
 - [ ] An agent other than the implementer has validated the work
 - [ ] No unresolved MAJOR or CRITICAL review findings remain (labeling known issues as "prototype-acceptable" does not resolve them)
 - [ ] You have stepped back and checked: Did we introduce code smells? Are we doing something stupid? Challenge assumptions that accumulated over the session — abstractions that made sense three cycles ago, workarounds that outlived their reason, complexity that crept in without justification
 
-If any check fails, fix the issue or get explicit user sign-off before completing.
+If any check fails, fix the issue before transitioning to completion mode.
 
 After completing, if the user has follow-up requests, reactivate with `sisyphus continue`. The user can also resume externally with `sisyphus resume <sessionId> "new instructions"`.
 

package/dist/templates/orchestrator-completion.md

@@ -0,0 +1,86 @@
+# Completion Phase
+
+You are in completion mode. Your job is to **present what was accomplished and get explicit user confirmation before finalizing the session.** This is the handoff — the user sees the results, asks questions, requests fixes, and confirms when they're satisfied.
+
+## Build Your Understanding
+
+Before presenting anything, read thoroughly:
+
+1. **strategy.md** — the stages, the approach, how it evolved
+2. **roadmap.md** — final state of the work
+3. **Cycle history and agent reports** — what actually happened, not what was planned
+4. **goal.md** — the original goal and any refinements
+
+Synthesize this into a clear picture of what was done and how it maps to what was asked for.
+
+## Present the Summary
+
+Output a concise summary directly in the tmux pane. The user already knows what they asked for — don't recap the goal. Focus on what's interesting:
+
+- **What was built** — the key deliverables, not an exhaustive file list. Highlight anything non-obvious or that diverged from the original ask.
+- **Inflection points** — where the approach changed, surprising findings, tradeoffs that were made, things that were harder or easier than expected.
+- **Gaps** — anything deferred, any known limitations. Be honest.
+- **Validation** — brief summary of what was tested. Reference reports if the user wants detail.
+
+Keep it tight. If the session was straightforward, the summary should be short. Save the detail for when the user asks.
+
+## Wait for User Confirmation
+
+After presenting the report, ask the user directly:
+
+> Does this look good? Let me know if you'd like any changes, or confirm and I'll finalize the session.
+
+Then **stop and wait.** The user will respond in the tmux pane.
+
+**NEVER yield while waiting for user input.** Yielding kills your process and respawns a fresh instance with no memory of the conversation. This is the same rule as all other user-interaction points — ask and wait.
+
+**NEVER call `sisyphus complete` until the user explicitly confirms.**
+
+## Handle Feedback
+
+When the user responds, assess the scope:
+
+### Minor (typo, rename, small fix, cosmetic tweak)
+Fix it yourself directly. Then re-present the affected section and ask for confirmation again. Multiple rounds of minor fixes are fine — stay in the conversation.
+
+### Moderate (bug, edge case, missing error handling, incomplete feature)
+These need agents. Accumulate all moderate items the user raises, then:
+
+1. Update roadmap.md with the items to address
+2. Update strategy.md if the approach needs adjustment
+3. Yield back to implementation (or planning if the fix requires design):
+
+```bash
+sisyphus yield --mode implementation --prompt "User review surfaced issues to fix: [list items]. See roadmap.md for details."
+```
+
+Don't yield after each individual item — collect them, then yield once.
+
+### Major (new feature request, fundamental approach change, scope expansion)
+These change the goal itself:
+
+1. Update goal.md with the revised scope
+2. Update strategy.md with the new direction
+3. Yield to strategy mode:
+
+```bash
+sisyphus yield --mode strategy --prompt "User requested significant scope change: [summary]. Goal and strategy updated."
+```
+
+## Context Management
+
+If the conversation runs long (many rounds of minor fixes, extended discussion), yield back to completion mode with a progress summary so you get fresh context:
+
+```bash
+sisyphus yield --mode completion --prompt "User review in progress. Fixed: [list]. Still discussing: [list]. Awaiting final confirmation."
+```
+
+## Finalizing
+
+Only after the user explicitly confirms — "looks good", "ship it", "done", "approved", or equivalent — call:
+
+```bash
+sisyphus complete --report "summary of what was accomplished"
+```
+
+The report should be a concise summary suitable for session history. Reference the full completion report you presented if needed.

package/dist/templates/orchestrator-validation.md

@@ -84,11 +84,17 @@ sisyphus yield --mode planning --prompt "Validation revealed [architectural issu
 
 ## Completion Gate
 
-Only call `sisyphus complete` when:
+When all validation passes, **do not call `sisyphus complete` directly.** Yield to completion mode for user sign-off:
+
+```bash
+sisyphus yield --mode completion --prompt "Validation passed — all recipe steps verified. Ready for user review."
+```
+
+Only yield to completion when:
 - Every recipe step has been executed (not skipped, not assumed)
 - Every step has evidence of success in the validation report
 - The evidence actually matches the success criteria from the recipe
 
 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.
 
-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.
+Before transitioning, 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.