sisyphi 1.2.0 → 1.2.1

package/dist/templates/agent-plugin/hooks/CLAUDE.md

@@ -1,9 +1,9 @@
-- The bundled `hooks.json` here is the **manifest** — the daemon merges it with project (`.sisyphus/agent-plugin/hooks/hooks.json`) and user (`~/.sisyphus/agent-plugin/hooks/hooks.json`) layers at spawn time, then writes the merged result into the per-agent plugin dir. Script edits are invisible to running agents; **respawn required**.
-- A bundled hook script is only copied into a spawned agent's plugin dir if the merged manifest references it for that agent type — scripts whose entries filter out (e.g. `plan-validate.sh` for a `review` agent) are skipped. Higher layers can suppress a bundled script by basename via `"disable": ["script.sh"]` at the manifest's top level.
+- Script edits are invisible to running agents — the daemon copies scripts at spawn time; **respawn required** to pick up changes.
+- Higher layers can suppress a bundled script by basename via `"disable": ["script.sh"]` at the manifest's top level.
 - `interactive: true` in agent frontmatter triggers `condition: "non-interactive"` filtering — entries with that condition (currently the bundled `require-submit.sh` Stop hook) are dropped from the merged manifest for interactive agents.
 - Scripts receive no `{{placeholder}}` substitution — placeholders appear as literal text, unlike `.md` templates.
-- Prompt hooks (`userPrompt`, `systemPrompt`) write raw text to stdout. Pre-tool hooks (e.g. `intercept-send-message.sh`) write `{"decision":"block","reason":"..."}` or exit 0 — wrong format silently does nothing.
+- `UserPromptSubmit` hooks write raw text to stdout. PreToolUse hooks (e.g. `intercept-send-message.sh`) write `{"decision":"block","reason":"..."}` or exit 0 — wrong format silently does nothing.
 - Claude Code invokes hooks unconditionally, not only in sisyphus sessions. Guard: `if [ -z "$SISYPHUS_SESSION_ID" ]; then exit 0; fi`. Stop hooks also need `$SISYPHUS_AGENT_ID`.
-- `userPrompt` fires on **every** message. Single-fire: guard `$SISYPHUS_AGENT_ID` and use a flag file at `/tmp/sisyphus-hooks/${SISYPHUS_SESSION_ID}/${SISYPHUS_AGENT_ID}-{name}`.
+- `UserPromptSubmit` fires on **every** message. Single-fire: guard `$SISYPHUS_AGENT_ID` and use a flag file at `/tmp/sisyphus-hooks/${SISYPHUS_SESSION_ID}/${SISYPHUS_AGENT_ID}-{name}`.
 - Heredoc must use `<<'HINT'` (single-quoted) for static prose — unquoted heredoc silently expands `$SISYPHUS_*`, `$INSTRUCTION`, and backticks. Assign a local var before the heredoc when interpolation is needed. Exception: `$SISYPHUS_SESSION_DIR` and similar env-var references inside `<<'HINT'` are intentional — the agent sees the literal text and expands them itself in Bash tool calls (the pane has these vars set).
 - Stop hooks receive JSON on stdin. If `stop_hook_active` is true, exit 0 immediately — blocking causes an infinite retry loop.

package/dist/templates/agent-plugin/hooks/hooks.json

@@ -24,7 +24,7 @@
     ],
     "PostToolUse": [
       {
-        "matcher": "Task",
+        "matcher": "Task|Agent",
         "agentTypes": ["all"],
         "hooks": [{ "type": "command", "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/register-bg-task.sh" }]
       }

package/dist/templates/agent-plugin/hooks/register-bg-task.sh

@@ -1,8 +1,8 @@
 #!/bin/bash
-# PostToolUse hook (matcher: Task): register background-Task agentIds for require-submit.sh.
-# Only fires when Claude Code itself flagged the Task as run_in_background=true —
-# structured signal, not prose scraping. Eliminates the false-positive class where
-# a non-background Task's output happens to contain the word "background".
+# PostToolUse hook (matcher: Task|Agent): register background sub-agent IDs for require-submit.sh.
+# For Task: only fires when Claude Code itself flagged run_in_background=true —
+# structured signal, not prose scraping.
+# For Agent (FleetView): always async; the run_in_background gate is skipped.
 # Passthrough (exit 0) if not in a sisyphus session.
 
 if [ -z "$SISYPHUS_SESSION_ID" ] || [ -z "$SISYPHUS_AGENT_ID" ]; then
@@ -11,9 +11,12 @@ fi
 
 INPUT=$(cat)
 
-RIB=$(echo "$INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('tool_input',{}).get('run_in_background',False))" 2>/dev/null)
-if [ "$RIB" != "True" ]; then
-  exit 0
+TOOL_NAME=$(echo "$INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('tool_name',''))" 2>/dev/null)
+if [ "$TOOL_NAME" != "Agent" ]; then
+  RIB=$(echo "$INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('tool_input',{}).get('run_in_background',False))" 2>/dev/null)
+  if [ "$RIB" != "True" ]; then
+    exit 0
+  fi
 fi
 
 # tool_response may be a string or structured; normalize to a string before grepping.

package/dist/templates/orchestrator-base.md

@@ -33,7 +33,7 @@ Each cycle:
 5. **Don't skip what you notice.** When agent reports or your own review surface minor issues — code smells, small inconsistencies, rough edges — address them. Deprioritizing small things is how quality erodes.
 6. Decide what to do next: break down work, spawn agents, re-plan, validate, or complete.
 7. If you need user input, ask and wait — **do NOT yield.** Yielding kills your process. You'll be respawned with no memory of the question and loop forever.
-8. Update roadmap.md and digest.json, spawn agents, write the cycle log, then `sis orch yield --prompt "what to focus on next cycle"`
+8. Update roadmap.md and digest.json, spawn agents, write the cycle log, then `sis orch yield --mode <current-or-next-mode> --prompt "what to focus on next cycle"`
 
 Be proactive. Don't wait for work to arrive — look ahead. If the current stage is wrapping up, prepare context for the next one. If a review found issues, spawn fix agents immediately. If you can run a review alongside the next stage's implementation, do it. Every cycle should maximize agents doing useful work.
 
@@ -51,7 +51,7 @@ When you need user input — alignment questions, clarification, decisions — o
 
 ### Mode Transitions
 
-Each yield can switch your mode — the mode determines the system prompt for the next cycle. Omitting `--mode` keeps the current mode.
+Every yield must specify `--mode`. The mode determines the system prompt for the next cycle. Pass the **current mode** to stay in it (no transition); pass a **different mode** to switch phases. There is no implicit "keep current mode" — be explicit every cycle.
 
 {{ORCHESTRATOR_MODES}}
 
@@ -80,20 +80,20 @@ A good yield prompt has two parts: **what happened** (one clause naming the arti
 
 <example>
 <good>
-sis orch yield --prompt "Three per-commit reviews complete. Address what they raised, work with the user if any finding is ambiguous, then decide between deeper investigation and synthesis."
+sis orch yield --mode implementation --prompt "Three per-commit reviews complete. Address what they raised, work with the user if any finding is ambiguous, then decide between deeper investigation and synthesis."
 </good>
 <good>
-sis orch yield --prompt "Explore agents returned maps of the auth and session layers. Open question: whether session refactor is in scope or a follow-up."
+sis orch yield --mode planning --prompt "Explore agents returned maps of the auth and session layers. Open question: whether session refactor is in scope or a follow-up."
 </good>
 <bad>
-sis orch yield --prompt "Read the three review docs. If any agent produced thin findings, respawn with narrower scope. Then run cross-cutting pass. Then synthesize into context/report.md sorted by severity."
+sis orch yield --mode implementation --prompt "Read the three review docs. If any agent produced thin findings, respawn with narrower scope. Then run cross-cutting pass. Then synthesize into context/report.md sorted by severity."
 </bad>
 <rationale>The bad version scripts the next cycle's plan before it has read anything. The good versions name what arrived and what's unresolved, then stop.</rationale>
 </example>
 
 **Write the prompt as orienting content, not as guidance about how to write yield prompts.** Meta-instructions ("don't pre-decide", "stay open", "pick from what surfaced") are for you, the current orchestrator — they belong in your reasoning, not in the string you hand the next cycle. The next orchestrator already has this section; repeating the rules at it wastes the prompt.
 
-Mode-transition yields (`--mode X --prompt Y`) follow the same shape — the mode signals the phase change, the prompt orients.
+When the mode changes between cycles, the `--mode` token itself signals the phase transition — the prompt still just orients with what happened and what's open.
 
 </continuation-prompt>
 
@@ -271,7 +271,7 @@ Rigor calibration:
 
 You have unlimited cycles. Failed implementations, deferred issues, and skipped reviews are far more expensive than extra cycles. Each feature is multiple cycles, not one:
 
-- **Critique** — spawn review agents to find flaws, code smells, missed edge cases. They report problems, not fixes.
+- **Critique** — spawn review agents on meaningful code changes to find flaws, code smells, missed edge cases. They report problems, not fixes. Trust agents at their word about what they did — don't spawn a review just to confirm an agent did what it claimed. Reviews target substantive work; they are not audits of agent honesty.
 - **Refine** — spawn agents to fix what reviewers found.
 - **Validate** — e2e verification that the feature actually works. When all stages are done, transition to `validation` mode for the comprehensive final pass.
 
@@ -314,9 +314,7 @@ For open-ended understanding questions mid-flow — "why does this agent behave
 ## CLI Reference
 
 ```bash
-sis orch yield                                           # yield — NEVER use when waiting for user input
-sis orch yield --prompt "focus on auth middleware next"   # yield with guidance for next cycle
-sis orch yield --mode <mode> --prompt "guidance"          # switch mode for next cycle
+sis orch yield --mode <mode> --prompt "guidance"          # yield — NEVER use when waiting for user input. --mode is required: pass the current mode to stay in it, or a new mode to transition.
 sis session clone <goal> [-c text] [--strategy] [-n name]   # fork a sub-concern into a new independent session
 ```
 

package/dist/templates/orchestrator-impl.md

@@ -100,7 +100,11 @@ A clean report ("No concerns") is a valid and common outcome. When you get one,
 
 ## Refine Pass
 
-Aggregate reviewer findings. Spawn fix agents and **point them at the review report** — don't rewrite findings as line-by-line instructions. You triage (skip false positives, note architectural constraints) — they implement.
+Aggregate reviewer findings, then **route each finding to where the fix actually lives**:
+
+- **Many code corrections** — spawn fix agents and point them at the review report. You triage (skip false positives, note architectural constraints); they implement. Don't rewrite findings as line-by-line instructions.
+- **Plan or context-doc fixes** — edit the document yourself. A clarified requirement, a corrected assumption, or a tweaked plan section is faster done in the orchestrator than handed to an agent. Spawning an agent to edit a markdown file is overhead, not delegation. (Massive replans are different — see backtrack guidance below.)
+- **A handful of trivial code edits** (a missed import, a typo, a one-line constant) — make them yourself rather than spinning up an agent. The agent overhead exceeds the work.
 
 ```bash
 sis agent spawn --name "fix-review-issues" --agent-type sisyphus:implement \

package/dist/templates/orchestrator-plugin/skills/orchestration/CLAUDE.md

@@ -1 +1 @@
-- `sis orch yield --mode discovery`, `--mode validation`, etc. must be explicit at mode-transition cycles. Omitting silently defaults to `implementation` mode, skipping guardrails the subsequent cycle expects.
+- `sis orch yield --mode <mode>` is required on every yield. Pass the current mode to stay in it; pass a different mode to transition. There is no implicit "keep current mode" fallback — the CLI rejects yields without `--mode`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sisyphi",
-  "version": "1.2.0",
+  "version": "1.2.1",
   "description": "tmux-integrated orchestration daemon for Claude Code multi-agent workflows",
   "license": "MIT",
   "repository": {
@@ -40,7 +40,7 @@
     "prepublishOnly": "npm run build && npm test"
   },
   "dependencies": {
-    "@crouton-kit/humanloop": "^0.1.3",
+    "@crouton-kit/humanloop": "^0.1.4",
     "@r-cli/sdk": "^1.2.0",
     "commander": "^13.1.0",
     "string-width": "^5.1.2",

package/templates/agent-plugin/hooks/CLAUDE.md

@@ -1,9 +1,9 @@
-- The bundled `hooks.json` here is the **manifest** — the daemon merges it with project (`.sisyphus/agent-plugin/hooks/hooks.json`) and user (`~/.sisyphus/agent-plugin/hooks/hooks.json`) layers at spawn time, then writes the merged result into the per-agent plugin dir. Script edits are invisible to running agents; **respawn required**.
-- A bundled hook script is only copied into a spawned agent's plugin dir if the merged manifest references it for that agent type — scripts whose entries filter out (e.g. `plan-validate.sh` for a `review` agent) are skipped. Higher layers can suppress a bundled script by basename via `"disable": ["script.sh"]` at the manifest's top level.
+- Script edits are invisible to running agents — the daemon copies scripts at spawn time; **respawn required** to pick up changes.
+- Higher layers can suppress a bundled script by basename via `"disable": ["script.sh"]` at the manifest's top level.
 - `interactive: true` in agent frontmatter triggers `condition: "non-interactive"` filtering — entries with that condition (currently the bundled `require-submit.sh` Stop hook) are dropped from the merged manifest for interactive agents.
 - Scripts receive no `{{placeholder}}` substitution — placeholders appear as literal text, unlike `.md` templates.
-- Prompt hooks (`userPrompt`, `systemPrompt`) write raw text to stdout. Pre-tool hooks (e.g. `intercept-send-message.sh`) write `{"decision":"block","reason":"..."}` or exit 0 — wrong format silently does nothing.
+- `UserPromptSubmit` hooks write raw text to stdout. PreToolUse hooks (e.g. `intercept-send-message.sh`) write `{"decision":"block","reason":"..."}` or exit 0 — wrong format silently does nothing.
 - Claude Code invokes hooks unconditionally, not only in sisyphus sessions. Guard: `if [ -z "$SISYPHUS_SESSION_ID" ]; then exit 0; fi`. Stop hooks also need `$SISYPHUS_AGENT_ID`.
-- `userPrompt` fires on **every** message. Single-fire: guard `$SISYPHUS_AGENT_ID` and use a flag file at `/tmp/sisyphus-hooks/${SISYPHUS_SESSION_ID}/${SISYPHUS_AGENT_ID}-{name}`.
+- `UserPromptSubmit` fires on **every** message. Single-fire: guard `$SISYPHUS_AGENT_ID` and use a flag file at `/tmp/sisyphus-hooks/${SISYPHUS_SESSION_ID}/${SISYPHUS_AGENT_ID}-{name}`.
 - Heredoc must use `<<'HINT'` (single-quoted) for static prose — unquoted heredoc silently expands `$SISYPHUS_*`, `$INSTRUCTION`, and backticks. Assign a local var before the heredoc when interpolation is needed. Exception: `$SISYPHUS_SESSION_DIR` and similar env-var references inside `<<'HINT'` are intentional — the agent sees the literal text and expands them itself in Bash tool calls (the pane has these vars set).
 - Stop hooks receive JSON on stdin. If `stop_hook_active` is true, exit 0 immediately — blocking causes an infinite retry loop.

package/templates/agent-plugin/hooks/hooks.json

@@ -24,7 +24,7 @@
     ],
     "PostToolUse": [
       {
-        "matcher": "Task",
+        "matcher": "Task|Agent",
         "agentTypes": ["all"],
         "hooks": [{ "type": "command", "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/register-bg-task.sh" }]
       }

package/templates/agent-plugin/hooks/register-bg-task.sh

@@ -1,8 +1,8 @@
 #!/bin/bash
-# PostToolUse hook (matcher: Task): register background-Task agentIds for require-submit.sh.
-# Only fires when Claude Code itself flagged the Task as run_in_background=true —
-# structured signal, not prose scraping. Eliminates the false-positive class where
-# a non-background Task's output happens to contain the word "background".
+# PostToolUse hook (matcher: Task|Agent): register background sub-agent IDs for require-submit.sh.
+# For Task: only fires when Claude Code itself flagged run_in_background=true —
+# structured signal, not prose scraping.
+# For Agent (FleetView): always async; the run_in_background gate is skipped.
 # Passthrough (exit 0) if not in a sisyphus session.
 
 if [ -z "$SISYPHUS_SESSION_ID" ] || [ -z "$SISYPHUS_AGENT_ID" ]; then
@@ -11,9 +11,12 @@ fi
 
 INPUT=$(cat)
 
-RIB=$(echo "$INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('tool_input',{}).get('run_in_background',False))" 2>/dev/null)
-if [ "$RIB" != "True" ]; then
-  exit 0
+TOOL_NAME=$(echo "$INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('tool_name',''))" 2>/dev/null)
+if [ "$TOOL_NAME" != "Agent" ]; then
+  RIB=$(echo "$INPUT" | python3 -c "import json,sys; print(json.load(sys.stdin).get('tool_input',{}).get('run_in_background',False))" 2>/dev/null)
+  if [ "$RIB" != "True" ]; then
+    exit 0
+  fi
 fi
 
 # tool_response may be a string or structured; normalize to a string before grepping.

package/templates/orchestrator-base.md

@@ -33,7 +33,7 @@ Each cycle:
 5. **Don't skip what you notice.** When agent reports or your own review surface minor issues — code smells, small inconsistencies, rough edges — address them. Deprioritizing small things is how quality erodes.
 6. Decide what to do next: break down work, spawn agents, re-plan, validate, or complete.
 7. If you need user input, ask and wait — **do NOT yield.** Yielding kills your process. You'll be respawned with no memory of the question and loop forever.
-8. Update roadmap.md and digest.json, spawn agents, write the cycle log, then `sis orch yield --prompt "what to focus on next cycle"`
+8. Update roadmap.md and digest.json, spawn agents, write the cycle log, then `sis orch yield --mode <current-or-next-mode> --prompt "what to focus on next cycle"`
 
 Be proactive. Don't wait for work to arrive — look ahead. If the current stage is wrapping up, prepare context for the next one. If a review found issues, spawn fix agents immediately. If you can run a review alongside the next stage's implementation, do it. Every cycle should maximize agents doing useful work.
 
@@ -51,7 +51,7 @@ When you need user input — alignment questions, clarification, decisions — o
 
 ### Mode Transitions
 
-Each yield can switch your mode — the mode determines the system prompt for the next cycle. Omitting `--mode` keeps the current mode.
+Every yield must specify `--mode`. The mode determines the system prompt for the next cycle. Pass the **current mode** to stay in it (no transition); pass a **different mode** to switch phases. There is no implicit "keep current mode" — be explicit every cycle.
 
 {{ORCHESTRATOR_MODES}}
 
@@ -80,20 +80,20 @@ A good yield prompt has two parts: **what happened** (one clause naming the arti
 
 <example>
 <good>
-sis orch yield --prompt "Three per-commit reviews complete. Address what they raised, work with the user if any finding is ambiguous, then decide between deeper investigation and synthesis."
+sis orch yield --mode implementation --prompt "Three per-commit reviews complete. Address what they raised, work with the user if any finding is ambiguous, then decide between deeper investigation and synthesis."
 </good>
 <good>
-sis orch yield --prompt "Explore agents returned maps of the auth and session layers. Open question: whether session refactor is in scope or a follow-up."
+sis orch yield --mode planning --prompt "Explore agents returned maps of the auth and session layers. Open question: whether session refactor is in scope or a follow-up."
 </good>
 <bad>
-sis orch yield --prompt "Read the three review docs. If any agent produced thin findings, respawn with narrower scope. Then run cross-cutting pass. Then synthesize into context/report.md sorted by severity."
+sis orch yield --mode implementation --prompt "Read the three review docs. If any agent produced thin findings, respawn with narrower scope. Then run cross-cutting pass. Then synthesize into context/report.md sorted by severity."
 </bad>
 <rationale>The bad version scripts the next cycle's plan before it has read anything. The good versions name what arrived and what's unresolved, then stop.</rationale>
 </example>
 
 **Write the prompt as orienting content, not as guidance about how to write yield prompts.** Meta-instructions ("don't pre-decide", "stay open", "pick from what surfaced") are for you, the current orchestrator — they belong in your reasoning, not in the string you hand the next cycle. The next orchestrator already has this section; repeating the rules at it wastes the prompt.
 
-Mode-transition yields (`--mode X --prompt Y`) follow the same shape — the mode signals the phase change, the prompt orients.
+When the mode changes between cycles, the `--mode` token itself signals the phase transition — the prompt still just orients with what happened and what's open.
 
 </continuation-prompt>
 
@@ -271,7 +271,7 @@ Rigor calibration:
 
 You have unlimited cycles. Failed implementations, deferred issues, and skipped reviews are far more expensive than extra cycles. Each feature is multiple cycles, not one:
 
-- **Critique** — spawn review agents to find flaws, code smells, missed edge cases. They report problems, not fixes.
+- **Critique** — spawn review agents on meaningful code changes to find flaws, code smells, missed edge cases. They report problems, not fixes. Trust agents at their word about what they did — don't spawn a review just to confirm an agent did what it claimed. Reviews target substantive work; they are not audits of agent honesty.
 - **Refine** — spawn agents to fix what reviewers found.
 - **Validate** — e2e verification that the feature actually works. When all stages are done, transition to `validation` mode for the comprehensive final pass.
 
@@ -314,9 +314,7 @@ For open-ended understanding questions mid-flow — "why does this agent behave
 ## CLI Reference
 
 ```bash
-sis orch yield                                           # yield — NEVER use when waiting for user input
-sis orch yield --prompt "focus on auth middleware next"   # yield with guidance for next cycle
-sis orch yield --mode <mode> --prompt "guidance"          # switch mode for next cycle
+sis orch yield --mode <mode> --prompt "guidance"          # yield — NEVER use when waiting for user input. --mode is required: pass the current mode to stay in it, or a new mode to transition.
 sis session clone <goal> [-c text] [--strategy] [-n name]   # fork a sub-concern into a new independent session
 ```
 

package/templates/orchestrator-impl.md

@@ -100,7 +100,11 @@ A clean report ("No concerns") is a valid and common outcome. When you get one,
 
 ## Refine Pass
 
-Aggregate reviewer findings. Spawn fix agents and **point them at the review report** — don't rewrite findings as line-by-line instructions. You triage (skip false positives, note architectural constraints) — they implement.
+Aggregate reviewer findings, then **route each finding to where the fix actually lives**:
+
+- **Many code corrections** — spawn fix agents and point them at the review report. You triage (skip false positives, note architectural constraints); they implement. Don't rewrite findings as line-by-line instructions.
+- **Plan or context-doc fixes** — edit the document yourself. A clarified requirement, a corrected assumption, or a tweaked plan section is faster done in the orchestrator than handed to an agent. Spawning an agent to edit a markdown file is overhead, not delegation. (Massive replans are different — see backtrack guidance below.)
+- **A handful of trivial code edits** (a missed import, a typo, a one-line constant) — make them yourself rather than spinning up an agent. The agent overhead exceeds the work.
 
 ```bash
 sis agent spawn --name "fix-review-issues" --agent-type sisyphus:implement \

package/templates/orchestrator-plugin/skills/orchestration/CLAUDE.md

@@ -1 +1 @@
-- `sis orch yield --mode discovery`, `--mode validation`, etc. must be explicit at mode-transition cycles. Omitting silently defaults to `implementation` mode, skipping guardrails the subsequent cycle expects.
+- `sis orch yield --mode <mode>` is required on every yield. Pass the current mode to stay in it; pass a different mode to transition. There is no implicit "keep current mode" fallback — the CLI rejects yields without `--mode`.