sisyphi 0.1.21 → 0.1.23

package/templates/orchestrator-impl.md

@@ -0,0 +1,116 @@
+# Implementation Phase
+
+## Stage-by-Stage Execution
+
+### Maximize parallelism
+
+Before starting each cycle, ask: **which stages or tasks are independent right now?** If two stages touch different subsystems (e.g., backend vs frontend, separate services, unrelated modules), spawn them concurrently — don't serialize work that doesn't need to be serialized. Use `--worktree` when parallel agents might touch overlapping files.
+
+Sequential execution is the default trap. Fight it actively. At every yield, look for work that can run alongside the next stage — review agents while the next implementation starts, frontend and backend stages in parallel, independent fix agents concurrently. A cycle with one agent running is a wasted cycle if other work was ready.
+
+If the plan has stages that share no file dependencies, **run them in parallel from the start.** Each stage is multiple cycles:
+
+1. **Detail-plan it** — expand the high-level outline into specific file changes, informed by previous stages. If complex enough, spawn a spec agent first.
+2. **Implement it** — spawn agents with self-contained instructions (see Agent Instructions below). May itself take multiple cycles if the stage has enough work.
+3. **Critique and refine it** — spawn parallel review agents, fix what they find, repeat until clean (see below).
+4. **Validate it end-to-end** — spawn a validation agent with the e2e recipe. Don't advance until it passes.
+5. **Update roadmap.md** — mark the stage done in the implementation phase, refine future stage outlines if what you learned changes the approach.
+
+Don't detail-plan all stages up front. What you learn implementing earlier stages should inform later ones.
+
+## Agent Instructions
+
+Implementation agent prompts must be **fully self-contained** — include everything the agent needs so it doesn't have to re-explore or guess. Each spawn instruction should include:
+
+- The overall goal of the session (one sentence)
+- This agent's specific task (files to create/modify, what the change does, done condition)
+- References to relevant context files (`conventions.md`, `explore-architecture.md`, etc.)
+- The e2e recipe reference (`context/e2e-recipe.md`) so the agent can self-verify
+
+**Tell every implementation agent to report clearly when done:** what they built, what files they changed, and any issues or uncertainties they encountered. Testing and validation happens at the orchestrator level (see Critique and Refinement below), not inside each agent.
+
+### Delegate outcomes, not implementations
+
+Your job is to define **what needs to happen and why**, not to write the code yourself. If you find yourself writing exact code snippets, function signatures, or line-by-line fix instructions in agent prompts — you're doing the agent's job.
+
+**Bad**: "Change line 45 from `x === y` to `crypto.timingSafeEqual(Buffer.from(x), Buffer.from(y))`, handle length mismatch..."
+**Good**: "Fix the timing-safe comparison issue in authMiddleware.ts — see report at reports/agent-002-final.md, Major #3"
+
+For fix agents specifically: **pass the review report path and tell the agent to action the items.** The agent reads the report, understands the codebase, and figures out the right fix. This is why you have agents — they're capable of solving problems, not just transcribing solutions. Writing the code for them defeats the purpose of delegation and wastes your context on implementation details you shouldn't be tracking.
+
+The exception is architectural constraints the agent wouldn't know: "use the existing `personRepository.findOrCreateOwner` method for Neo4j sync" or "the Supabase client is at `supabaseService.getClient()`". Give agents the **what** and the **landmarks**, not the **how**.
+
+### Context propagation
+
+The planning phase produced context files — conventions, e2e recipe, architectural findings. Be selective — give each agent the context relevant to their task, not everything. An agent that gets `conventions.md` writes consistent code. An agent that gets `explore-architecture.md` understands where their change fits.
+
+## Code Smell Escalation
+
+Instruct agents to flag problems early rather than working around them. When an agent encounters unexpected complexity, unclear architecture, or code that fights back — the right move is to stop and report clearly. A clear description of the problem is more valuable than a brittle implementation built on a bad foundation.
+
+When you see these reports, investigate before pushing forward. If the smell suggests a design issue, involve the user.
+
+## Critique and Refinement
+
+After implementation agents report, **do not advance to the next stage.** The code needs to be reviewed and refined first. This is not optional.
+
+### Critique cycle
+
+Spawn three review agents in parallel, each attacking a different dimension:
+
+1. **Code reuse reviewer** — searches the codebase for existing utilities, helpers, and patterns that the new code duplicates. Flags any new function that reimplements existing functionality, any inline logic that could use an existing utility.
+
+2. **Code quality reviewer** — looks for hacky patterns: redundant state, parameter sprawl, copy-paste with slight variation, leaky abstractions, stringly-typed code where constants or enums exist, unnecessary nesting or wrapping.
+
+3. **Efficiency reviewer** — looks for unnecessary work (redundant computations, duplicate API calls, N+1 patterns), missed concurrency (independent operations run sequentially), hot-path bloat, unbounded data structures, overly broad operations.
+
+Give each reviewer the full diff and relevant context files. They report problems — they don't fix them.
+
+### Refine cycle
+
+Aggregate the reviewer findings. Spawn fix agents and **point them at the review report** — don't rewrite the findings as line-by-line instructions. The fix agent reads the report, reads the code, and figures out the right solution. You triage (skip false positives, note any architectural constraints) — they implement.
+
+```bash
+sisyphus spawn --name "fix-review-issues" --agent-type sisyphus:implement \
+  "Fix the issues in reports/agent-003-final.md. Skip item #5 (false positive). Run type-check after."
+```
+
+The fix agents should use `/simplify` to systematically review their own changes before reporting.
+
+### Repeat until clean
+
+Spawn reviewers again on the refined code. If they come back with new issues, fix those too. Genuinely nitpicky findings — stylistic preferences, irrelevant edge cases — can be skipped. But if a finding is actually correct, it gets done. **"I don't want to" is not a reason to skip a valid finding.** The distinction is between false positives and laziness. In practice this is usually 1-2 rounds. If it's taking more, the implementation was shaky and you should consider whether the approach needs rethinking rather than patching.
+
+## E2E Validation
+
+After the critique/refine loop produces clean code, **validate end-to-end before advancing.** This is also not optional. The implementing agent is the worst validator of its own work — same blind spots, same assumptions.
+
+Spawn a validation agent with the e2e recipe from `context/e2e-recipe.md`. The agent should:
+- Follow the setup steps exactly (build, start servers, seed data)
+- Run every verification step in the recipe
+- Report exactly what passed and what failed — not "it looks good"
+
+If the recipe involves UI, the validation agent should use `capture` to screenshot and interact with the actual running app. If it involves an API, it should curl the actual endpoints. If it involves CLI behavior, it should exercise it in the terminal.
+
+If the project lacks validation tooling, **create it**. A smoke-test script, a seed command, a health-check endpoint — these pay for themselves immediately and every future validation agent reuses them.
+
+**Only advance to the next stage when validation passes.** If it fails, log the failures, spawn fix agents, and re-validate.
+
+## Worktree Preference
+
+When spawning two or more implementation agents in the same cycle, prefer `--worktree` for each. Worktree isolation eliminates file conflict risk — agents can't clobber each other's changes, each gets a clean branch, and they can commit incrementally. The daemon merges branches back when agents complete and surfaces conflicts in your next cycle's state.
+
+```bash
+sisyphus spawn --name "impl-auth" --agent-type sisyphus:implement --worktree "Add session middleware — see context/conventions.md"
+sisyphus spawn --name "impl-routes" --agent-type sisyphus:implement --worktree "Add login routes — see context/conventions.md and context/explore-architecture.md"
+```
+
+## Returning to Planning
+
+If you discover mid-implementation that the approach is wrong — the architecture is different than expected, a dependency changes the approach, or agents keep hitting the same wall — don't keep pushing. Return to planning:
+
+```bash
+sisyphus yield --mode planning --prompt "Re-evaluate: discovered X changes the approach — write cycle log"
+```
+
+Document what you found in the cycle log before yielding so the planning cycle starts informed. Update roadmap.md to reflect that you're back in an earlier phase.

package/templates/orchestrator-planning.md

@@ -0,0 +1,131 @@
+# Planning Phase
+
+## Exploration
+
+Use explore agents to build understanding before making decisions. Each agent should save a focused context document to `.sisyphus/sessions/$SISYPHUS_SESSION_ID/context/` — these artifacts get passed to downstream agents so they don't have to re-explore the codebase themselves.
+
+Adapt the number and focus of explore agents to the task. Key principles:
+
+- **Each agent produces a focused artifact** — not one sprawling document. Focused documents can be selectively passed to downstream agents. An agent implementing auth gets `conventions.md` + `architecture.md`, not a 500-line dump.
+- **Conventions and patterns are high-value** to capture. Implementation agents that receive convention context write consistent code. Ones that don't produce code you'll have to fix.
+- **Exploration serves different purposes at different stages.** Early exploration is architectural — understanding the system and what needs to change. Later exploration before a specific stage is tactical — identifying files, patterns to follow, utilities to reuse. Both are valuable.
+- **Delegate understanding of unfamiliar territory.** If the task touches a library or subsystem you don't know, spawn an agent to investigate and report.
+
+## Spec Alignment
+
+Before investing in a detailed spec, make sure the goal itself is well-defined. If you're making assumptions about scope, requirements, or constraints — surface them to the user. A spec built on wrong assumptions wastes every cycle downstream.
+
+For significant features, spec refinement is iterative:
+- Draft the spec based on exploration findings
+- Have agents review for feasibility and code smells (can this actually work given the codebase?)
+- Seek user alignment on the high-level approach and any decisions that set direction
+- **Apply corrections back to the spec itself** — the spec is the single source of truth. Don't create a separate corrections file and pass both downstream; update the spec and delete the corrections. Plan agents should read one authoritative document, not reconcile two contradictory ones.
+
+Not every stage needs a standalone spec document — a well-defined stage might just be a detailed section in the implementation plan. Use judgment about how much formality each stage warrants.
+
+## Delegating to Plan Agents
+
+Point plan agents at **inputs** (spec, context docs, corrections) — not a pre-made structure. Don't pre-decide staging, ordering, or design decisions. The plan agent has `effort: max` reasoning and will produce a better plan when given room to think through the structure itself.
+
+For cross-domain tasks, consider spawning parallel plan agents scoped to independent domains (e.g., one for backend, one for frontend, one for IPC). Each produces a focused sub-plan. This is faster and produces better domain-specific plans than one agent trying to plan everything.
+
+## Progressive Development
+
+Not all tasks need the same process depth. A 2-file bug fix can go straight to implementation. A cross-repo feature with multiple domains needs full phased development.
+
+### Decision heuristic
+
+- **Small task** (1-3 files, single domain): Skip phases — roadmap is just a short task checklist (diagnose, fix, validate). Single plan agent, single implement agent.
+- **Large task** (3+ stages, multiple domains or repos): Full phased development. The roadmap tracks development phases, and each phase produces artifacts in `context/`.
+
+Signs you need phased development: the task touches multiple unfamiliar subsystems, the task description spans different concerns (backend, frontend, IPC, etc.), or a spec exists with more than 3 distinct work areas.
+
+### How phased development works
+
+The roadmap tracks **development phases**, not implementation stages. A large feature's roadmap looks like:
+
+```markdown
+## Goal: Implement Worker System
+
+### Phases
+1. Research — explore architecture, conventions, constraints [current]
+2. Spec — validate/refine spec, align with user [outlined]
+3. Plan — break into implementation stages [outlined]
+4. Implement — execute stage-by-stage with review cycles [outlined]
+5. Validate — e2e verification [outlined]
+```
+
+Each phase expands when you enter it. Implementation stages only appear once Phase 3 (Plan) produces them — and they live in `context/`, not the roadmap itself.
+
+### Phase expansion
+
+When entering a new phase, expand it in the roadmap with concrete items:
+
+```markdown
+### Phase 1: Research (current)
+- [x] Core architecture exploration (scheduler, presets, routing)
+- [x] Agent IPC + runtime patterns
+- [ ] Gateway patterns (RTK Query, components)
+
+### Phase 3: Plan (current)
+- Implementation plan: see context/plan-implementation.md
+- [x] High-level stage outline
+- [ ] Detail-plan stage 1 (types + migration)
+- [ ] Review plan against spec
+```
+
+Future phases stay as one-liners until reached. What you learn in earlier phases informs how later phases get expanded.
+
+### Implementation stages are context artifacts
+
+When Phase 3 (Plan) runs, it produces implementation stage breakdowns saved to `context/`:
+- `context/plan-implementation.md` — overall stage outline with dependencies
+- `context/plan-stage-1-types.md` — detailed plan for stage 1
+- `context/plan-stage-2-service.md` — detailed plan for stage 2 (written when stage 1 is underway)
+
+The roadmap references these but doesn't contain them. During Phase 4 (Implement), the roadmap tracks which stages are done:
+
+```markdown
+### Phase 4: Implement (current)
+See context/plan-implementation.md for stage breakdown.
+- [x] Stage 1: Types + migration — verified
+- [ ] Stage 2: Worker service — in progress (see context/plan-stage-2-service.md)
+- [ ] Stage 3: Gateway UI — outlined
+```
+
+### Don't front-load phases
+
+Detail-plan one stage at a time. What you learn implementing stage N informs stage N+1's detail plan. The stage outline evolves — stages get added, removed, reordered, or split as understanding grows. That's the system working correctly.
+
+Detailed plans for stages 4-7 written before stage 1 is implemented are fiction. Defer detail until you're about to execute.
+
+## E2E Verification Recipe
+
+Before implementation begins, determine how to concretely verify the change works end-to-end. This is the single most common failure mode: agents report success but nothing actually works.
+
+The tooling explorer should have mapped the available infrastructure. Common patterns:
+
+- **Browser automation**: `capture` CLI for UI changes — click through affected flows, screenshot results
+- **CLI verification**: exercise changed behavior interactively in tmux
+- **API testing**: dev server + curl/httpie for endpoint changes
+- **Integration tests**: existing e2e or integration test suite
+- **Smoke script**: create one if nothing else exists
+
+If you cannot determine a concrete verification method, **ask the user**. Offer 2-3 specific options. Do not proceed to implementation without a verification plan.
+
+Write the recipe to `context/e2e-recipe.md` with:
+- Setup steps (start dev server, build, seed data, etc.)
+- Exact commands or interactions to verify
+- What success looks like (expected output, visual state, response codes)
+
+Implementation agents and validation agents both reference this file. Write it to be executable, not aspirational.
+
+## Transitioning to Implementation
+
+When you have enough understanding, a reviewed plan, and a verification recipe — transition explicitly:
+
+```bash
+sisyphus yield --mode implementation --prompt "Begin implementation — see roadmap.md and context/plan-implementation.md"
+```
+
+The `--mode implementation` flag loads implementation-phase guidance for the next cycle. Pass a prompt that orients the next cycle to where things stand.

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

@@ -1,15 +1 @@
-{
-  "hooks": {
-    "PreToolUse": [
-      {
-        "matcher": "Task",
-        "hooks": [
-          {
-            "type": "command",
-            "command": "\"${CLAUDE_PLUGIN_ROOT}/scripts/block-task.sh\""
-          }
-        ]
-      }
-    ]
-  }
-}
+{"hooks":{}}

package/templates/orchestrator-plugin/skills/git-management/SKILL.md

@@ -85,7 +85,7 @@ Scan the project root for gitignored files that agents will need:
 
 ## Handling Merge Conflicts
 
-When the daemon merges agent branches back, conflicts appear in the `## Worktrees` section of your state block. For each conflicting agent you'll see:
+When the daemon merges agent branches back, conflicts appear in the `## Worktrees` section of your prompt. For each conflicting agent you'll see:
 - The branch name (still exists, unmerged)
 - The worktree path (still exists on disk)
 - The conflict details (git merge stderr output)

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

@@ -10,7 +10,7 @@ How to structure sisyphus sessions for common task types. This skill helps the o
 
 ## Core Principles
 
-1. **plan.md is the orchestrator's memory.** plan.md and agent reports persist across cycles — they're all you have. Keep plan.md current and specific enough that a fresh orchestrator can pick up where you left off.
+1. **roadmap.md is the orchestrator's memory.** roadmap.md and agent reports persist across cycles — they're all you have. Keep roadmap.md current and specific enough that a fresh orchestrator can pick up where you left off.
 
 2. **Agents are disposable.** Each agent gets one focused instruction. If it fails or the scope changes, spawn a new one — don't try to redirect a running agent.
 
@@ -20,21 +20,9 @@ How to structure sisyphus sessions for common task types. This skill helps the o
 
 5. **Reports are handoffs.** Agent reports should contain everything the next cycle's orchestrator needs — what was done, what was found, what's unresolved, where artifacts were saved.
 
-## Agent Types Quick Reference
-
-| Agent | Model | Use For |
-|-------|-------|---------|
-| `sisyphus:general` | sonnet | Ad-hoc tasks, summarization, simple questions |
-| `sisyphus:debug` | opus | Bug diagnosis and root cause analysis |
-| `sisyphus:spec-draft` | opus | Feature investigation and spec drafting |
-| `sisyphus:plan` | opus | Implementation planning from spec |
-| `sisyphus:review-plan` | opus | Validate plan covers spec completely |
-| `sisyphus:test-spec` | opus | Define behavioral properties to verify |
-| `sisyphus:implement` | sonnet | Execute plan phases, write code |
-| `sisyphus:validate` | opus | Verify implementation matches plan |
-| `sisyphus:review` | opus | Code review with parallel concern subagents |
-| `sisyphus:tactician` | opus | Track plan progress, dispatch next task |
-| `sisyphus:triage` | sonnet | Classify tickets by type/size |
+## Agent Types
+
+Available agent types are listed under **Available Agent Types** in your prompt. Use `--agent-type` with `sisyphus spawn`.
 
 For task breakdown patterns per workflow type, see [task-patterns.md](task-patterns.md).
 For end-to-end workflow examples, see [workflow-examples.md](workflow-examples.md).

package/templates/orchestrator-plugin/skills/orchestration/task-patterns.md

@@ -1,6 +1,6 @@
 # Work Breakdown Patterns
 
-Patterns for how the orchestrator should structure plan.md for common workflow types. Each pattern shows the plan structure, agent assignments, cycle sequencing, and failure handling.
+Patterns for how the orchestrator should structure roadmap.md for common workflow types. Each pattern shows the plan structure, agent assignments, cycle sequencing, and failure handling.
 
 ---
 
@@ -106,45 +106,44 @@ Phases without dependencies can run in parallel. Types/interfaces (Phase 1) must
 ## Feature Build (Large — 10+ files)
 
 ### When to use
-Cross-cutting feature, multiple domains, needs team coordination.
+Cross-cutting feature, multiple domains, needs team coordination. Uses **progressive planning** — high-level outline first, then detail-plan each stage as it's reached.
 
 ### Plan structure
 ```
 ## Feature: [description]
 
-### Spec & Planning
+### Spec
 - [ ] Draft spec
-- [ ] Create master implementation plan
-- [ ] Review plan against spec
-- [ ] Define behavioral test properties
+- [ ] Review spec
 
-### Implementation
-- [ ] Phase 1 — [domain A foundation]
-- [ ] Phase 2 — [domain B foundation]
-- [ ] Phase 3 — [domain A implementation]
-- [ ] Phase 4 — [domain B implementation]
-- [ ] Phase 5 — [integration layer]
+### Stage Outline (high-level only — no file-level detail yet)
+1. [domain A foundation] — no deps — ~N cycles
+2. [domain B foundation] — no deps — ~N cycles
+3. [domain A implementation] — depends on 1 — ~N cycles
+4. [domain B implementation] — depends on 2 — ~N cycles
+5. [integration layer] — depends on 3, 4 — ~N cycles
+6. [integration tests] — depends on all — ~N cycles
 
-### Validation
-- [ ] Validate full implementation
-- [ ] Review implementation
-- [ ] Adversarial validation against test spec
+### Current Stage: [whichever is active]
+See context/plan-stage-N-{name}.md for detail plan.
+- [ ] [task-level items from detail plan]
 ```
 
 ### Cycle plan
 - **Cycle 1**: Spawn `sisyphus:spec-draft` for spec. Yield.
-- **Cycle 2**: Spawn `sisyphus:plan` for plan + `sisyphus:test-spec` for test properties (parallel). Yield.
-- **Cycle 3**: Spawn `sisyphus:review-plan` for review. Yield.
-- **Cycle 4**: Spawn `sisyphus:implement` for Phase 1 + Phase 2 (parallel — independent domains). Yield.
-- **Cycle 5**: Validate Phase 1 + Phase 2, then spawn Phase 3 + Phase 4 (parallel). Yield.
-- **Cycle 6+**: Integration, validation, review.
+- **Cycle 2**: Spawn `sisyphus:plan` for **high-level stage outline only**. Instruction: "Outline stages, dependencies, one-sentence descriptions, cycle estimates. Do not detail any stage — no file-level specifics." Spawn `sisyphus:test-spec` for test properties (parallel). Yield.
+- **Cycle 3**: Review outline. Spawn `sisyphus:plan` to **detail-plan stage 1 only** (provide outline as context). Output to `context/plan-stage-1-{name}.md`. Yield.
+- **Cycle 4**: Spawn `sisyphus:implement` for stage 1. If stage 2 is independent, spawn `sisyphus:plan` to detail-plan stage 2 in parallel. Yield.
+- **Cycle 5**: Validate stage 1. Spawn `sisyphus:implement` for stage 2 (if detail-planned). Detail-plan stage 3 in parallel if independent. Yield.
+- **Cycle 6+**: Continue pattern — implement current stage, validate previous, detail-plan next. Each stage follows implement → critique → refine → validate.
 
 ### Failure modes
+- **Detail-plan agent can't produce quality output**: The stage is still too large. Break it into sub-stages in the outline and detail-plan each sub-stage individually.
 - **Integration failures**: Often means contracts between domains don't match. Spawn debug agent targeting the integration seam.
-- **Test spec violations**: Feed specific property failures back to implement.
+- **Stage N implementation invalidates stage N+1 outline**: Update the high-level outline. This is expected — it's why you don't detail-plan everything upfront.
 
 ### Parallelization
-Maximize. Independent domains run in parallel. Foundation phases complete before implementation phases in the same domain. Integration waits for all domain implementations.
+Maximize within the progressive pattern. Independent stages run in parallel. Detail-planning the next stage runs alongside implementing the current one. Foundation stages complete before dependent stages. Integration waits for all domain implementations.
 
 ---
 

package/templates/orchestrator-plugin/skills/orchestration/workflow-examples.md

@@ -10,7 +10,7 @@ End-to-end examples showing how the orchestrator structures cycles for real scen
 
 ### Cycle 1 — Diagnosis
 ```
-plan.md:
+roadmap.md:
   ## Bug Fix: WebSocket message loss during reconnection
 
   - [ ] Diagnose message loss during WebSocket reconnection
@@ -33,7 +33,7 @@ Agent report: "Root cause: reconnect() clears the message queue before the new s
   but should be deferred until onReconnect confirms the new socket is live.
   Confidence: High."
 
-plan.md updated:
+roadmap.md updated:
   - [x] ~~Diagnose message loss during WebSocket reconnection~~
   - [ ] Fix root cause — queue.clear() at L47 of reconnect.ts runs too early
   - [ ] Validate fix under concurrent load
@@ -51,7 +51,7 @@ Agents spawned:
 Agent report: "Fixed. Moved queue.clear() to onReconnect callback after socket.readyState
   confirms OPEN. Added message buffer during reconnection window. 2 files changed."
 
-plan.md updated:
+roadmap.md updated:
   - [x] ~~Diagnose message loss~~
   - [x] ~~Fix root cause~~
   - [ ] Validate fix under concurrent load
@@ -67,7 +67,7 @@ Agents spawned:
 ```
 Validation: PASS. Existing tests pass, reconnection preserves messages.
 
-plan.md updated:
+roadmap.md updated:
   - [x] ~~Diagnose~~, [x] ~~Fix~~, [x] ~~Validate~~
   - [ ] Review fix
 
@@ -82,7 +82,7 @@ Agents spawned:
 Review: Clean. One medium finding — buffer should have a max size to prevent
   memory issues if reconnect fails indefinitely. Not blocking.
 
-All plan.md items complete.
+All roadmap.md items complete.
 
 Action: complete — "Fixed WebSocket message loss during reconnection. Messages now
   buffered during reconnection window and drained on successful reconnect."
@@ -96,7 +96,7 @@ Action: complete — "Fixed WebSocket message loss during reconnection. Messages
 
 ### Cycle 1 — Spec
 ```
-plan.md:
+roadmap.md:
   ## Feature: API Rate Limiting
 
   ### Spec & Planning
@@ -127,7 +127,7 @@ Agent report: "Spec saved to context/spec-rate-limiting.md.
   Standard 429 response with Retry-After header. Config via environment variables.
   Open questions resolved with user: Redis is already in stack, use it."
 
-plan.md updated (spec item marked done):
+roadmap.md updated (spec item marked done):
   - [x] ~~Draft spec for API rate limiting~~
   - [ ] Plan implementation
   ...
@@ -151,7 +151,7 @@ Agents spawned:
 ```
 Plan review: PASS.
 
-plan.md updated (plan review done, starting implementation):
+roadmap.md updated (plan review done, starting implementation):
   - [x] ~~Draft spec~~, [x] ~~Plan~~, [x] ~~Review plan~~
   - [ ] Implement rate limiting middleware
   - [ ] Implement rate limit configuration
@@ -174,7 +174,7 @@ Agents spawned:
 
 ### Cycle 1 — Plan + baseline
 ```
-plan.md:
+roadmap.md:
   ## Refactor: Extract Token Service
 
   - [ ] Plan auth refactor — extract token service
@@ -197,7 +197,7 @@ Agents spawned (parallel):
 ```
 Plan complete, baseline captured (47 tests passing).
 
-plan.md updated:
+roadmap.md updated:
   - [x] ~~Plan auth refactor~~
   - [x] ~~Capture behavioral baseline~~ (47 tests passing)
   - [ ] Create TokenService class with extracted logic
@@ -232,6 +232,6 @@ Agents spawned (parallel):
 ### Cycle 5 — Complete
 ```
 All 47 tests passing. Review clean.
-All plan.md items complete.
+All roadmap.md items complete.
 Complete — "Extracted token logic into TokenService. All existing tests pass."
 ```

package/dist/chunk-LTAW6OWS.js.map

@@ -1 +0,0 @@
-{"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 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 planPath(cwd: string, sessionId: string): string {\n  return join(sessionDir(cwd, sessionId), 'plan.md');\n}\n\nexport function logsPath(cwd: string, sessionId: string): string {\n  return join(sessionDir(cwd, sessionId), 'logs.md');\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,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,SAAS,KAAa,WAA2B;AAC/D,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,SAAS;AACnD;AAEO,SAAS,SAAS,KAAa,WAA2B;AAC/D,SAAO,KAAK,WAAW,KAAK,SAAS,GAAG,SAAS;AACnD;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":[]}

package/dist/templates/orchestrator-plugin/scripts/block-task.sh

@@ -1,11 +0,0 @@
-#!/bin/bash
-# Block Task tool — orchestrator should use sisyphus spawn CLI directly.
-# Passthrough (exit 0) if not in a sisyphus session.
-
-if [ -z "$SISYPHUS_SESSION_ID" ]; then
-  exit 0
-fi
-
-cat <<'EOF'
-{"decision":"block","reason":"Do not use the Task tool. Use the sisyphus CLI to spawn agents:\n- sisyphus spawn --name \"agent-name\" --agent-type sisyphus:implement \"instruction\"\n- echo \"instruction\" | sisyphus spawn --name \"agent-name\"\nThen call sisyphus yield when done spawning."}
-EOF