agent-tempo 1.2.0 → 1.3.1

package/examples/ensembles/tempo-headless-jam.yaml

@@ -1,77 +1,77 @@
-name: tempo-headless-jam
-description: >
-  Subscription-billed headless ensemble for scheduled / CI / background work
-  where you don't want to spawn visible terminals or burn Console workspace
-  credits. Every player runs `agent: claude-code-headless` — the host's
-  installed `claude` CLI is invoked per-turn via `claude -p`, so turns bill
-  against the operator's existing Claude Code subscription extra-usage
-  pool (Pro / Max plans), NOT a `sk-ant-api03-...` Console key.
-
-  Requires:
-    - `claude` binary on PATH (`npm install -g @anthropic-ai/claude-code`
-      or follow https://claude.com/download)
-    - Logged-in Claude Code session (`claude auth login`) — the recruit
-      pre-flight rejects with an actionable error if either check fails
-
-  Use cases:
-    - Scheduled cleanup PRs, doctor checks, gate evaluators that you want
-      to run without a human-in-the-loop terminal window
-    - CI / build-bot ensembles on hosts where the operator already has
-      a Pro / Max subscription and wants to use it instead of Console credits
-    - "Pair with claude-code-headless" runs where one headless explorer +
-      one headless prototyper iterate on a problem, with the operator
-      reading transcripts via the dashboard rather than driving via
-      terminal interactions
-
-  Headless players have FULL Claude Code tool access (Bash, Read, Write,
-  Edit, Glob, Grep, WebSearch, WebFetch) by inheritance from the spawned
-  CLI — strictly more capable than `claude-api` headless players (which
-  have MCP-only tool access).
-
-  See [docs/design/520-claude-code-headless-adapter.md](../../docs/design/520-claude-code-headless-adapter.md)
-  for the full design and §16 spike findings.
-
-conductor:
-  type: tempo-conductor
-  agent: claude-code-headless
-  permissionMode: acceptEdits
-  instructions: >
-    You are driving a headless ensemble for scheduled or CI work. Your
-    players have full Claude Code tool access AND the agent-tempo MCP
-    surface. Decompose the operator's task, delegate to the explorer +
-    prototyper, synthesize results. Report cleanly via `report` —
-    operators read transcripts via the dashboard, not by joining a
-    terminal session.
-
-players:
-  - name: explorer
-    type: tempo-improv
-    agent: claude-code-headless
-    permissionMode: acceptEdits
-    instructions: >
-      You are the headless researcher. Investigate the operator's task
-      via Read / Grep / Glob / WebSearch / WebFetch. Report findings
-      with structured comparisons (pros / cons / trade-offs / recommendation).
-      You have full file-read access — no per-tool gating beyond
-      Claude Code's default `acceptEdits` permission mode. Show your
-      work — document what you tried and what you ruled out.
-
-  - name: prototyper
-    type: tempo-soloist
-    agent: claude-code-headless
-    permissionMode: acceptEdits
-    instructions: >
-      You build small implementations to validate the explorer's
-      findings. Write minimal code with Bash + Edit + Write. Run tests
-      where appropriate. Don't over-engineer — focus on proving or
-      disproving the approach. Report what worked and what didn't.
-
-# No `schedules` block — headless ensembles are typically driven by
-# external triggers (cron, CI hooks) or operator cues from the dashboard.
-# Add a `schedules:` block if you want a periodic progress check, e.g.:
-#
-#   schedules:
-#     - name: progress-check
-#       message: "Share what you've found so far."
-#       target: all
-#       every: 30m
+name: tempo-headless-jam
+description: >
+  Subscription-billed headless ensemble for scheduled / CI / background work
+  where you don't want to spawn visible terminals or burn Console workspace
+  credits. Every player runs `agent: claude-code-headless` — the host's
+  installed `claude` CLI is invoked per-turn via `claude -p`, so turns bill
+  against the operator's existing Claude Code subscription extra-usage
+  pool (Pro / Max plans), NOT a `sk-ant-api03-...` Console key.
+
+  Requires:
+    - `claude` binary on PATH (`npm install -g @anthropic-ai/claude-code`
+      or follow https://claude.com/download)
+    - Logged-in Claude Code session (`claude auth login`) — the recruit
+      pre-flight rejects with an actionable error if either check fails
+
+  Use cases:
+    - Scheduled cleanup PRs, doctor checks, gate evaluators that you want
+      to run without a human-in-the-loop terminal window
+    - CI / build-bot ensembles on hosts where the operator already has
+      a Pro / Max subscription and wants to use it instead of Console credits
+    - "Pair with claude-code-headless" runs where one headless explorer +
+      one headless prototyper iterate on a problem, with the operator
+      reading transcripts via the dashboard rather than driving via
+      terminal interactions
+
+  Headless players have FULL Claude Code tool access (Bash, Read, Write,
+  Edit, Glob, Grep, WebSearch, WebFetch) by inheritance from the spawned
+  CLI — strictly more capable than `claude-api` headless players (which
+  have MCP-only tool access).
+
+  See [docs/design/520-claude-code-headless-adapter.md](../../docs/design/520-claude-code-headless-adapter.md)
+  for the full design and §16 spike findings.
+
+conductor:
+  type: tempo-conductor
+  agent: claude-code-headless
+  permissionMode: acceptEdits
+  instructions: >
+    You are driving a headless ensemble for scheduled or CI work. Your
+    players have full Claude Code tool access AND the agent-tempo MCP
+    surface. Decompose the operator's task, delegate to the explorer +
+    prototyper, synthesize results. Report cleanly via `report` —
+    operators read transcripts via the dashboard, not by joining a
+    terminal session.
+
+players:
+  - name: explorer
+    type: tempo-improv
+    agent: claude-code-headless
+    permissionMode: acceptEdits
+    instructions: >
+      You are the headless researcher. Investigate the operator's task
+      via Read / Grep / Glob / WebSearch / WebFetch. Report findings
+      with structured comparisons (pros / cons / trade-offs / recommendation).
+      You have full file-read access — no per-tool gating beyond
+      Claude Code's default `acceptEdits` permission mode. Show your
+      work — document what you tried and what you ruled out.
+
+  - name: prototyper
+    type: tempo-soloist
+    agent: claude-code-headless
+    permissionMode: acceptEdits
+    instructions: >
+      You build small implementations to validate the explorer's
+      findings. Write minimal code with Bash + Edit + Write. Run tests
+      where appropriate. Don't over-engineer — focus on proving or
+      disproving the approach. Report what worked and what didn't.
+
+# No `schedules` block — headless ensembles are typically driven by
+# external triggers (cron, CI hooks) or operator cues from the dashboard.
+# Add a `schedules:` block if you want a periodic progress check, e.g.:
+#
+#   schedules:
+#     - name: progress-check
+#       message: "Share what you've found so far."
+#       target: all
+#       every: 30m

package/examples/ensembles/tempo-jam-session.yaml

@@ -1,41 +1,41 @@
-name: tempo-jam-session
-description: Exploratory ensemble for spikes, research, and problems where the path forward is unclear
-
-conductor:
-  type: tempo-conductor
-  instructions: >
-    You are leading a jam session — the goal is exploration, not delivery. Break the
-    unknown into research questions, assign them to the improv player and soloist,
-    and have the composer evaluate findings architecturally. Synthesize discoveries
-    into a clear recommendation or next steps. Time-box aggressively — report
-    findings even if incomplete.
-
-players:
-  - name: explorer
-    type: tempo-improv
-    instructions: >
-      You are the primary researcher. Investigate the unknown: read docs, explore
-      codebases, test hypotheses, evaluate options. Report findings with structured
-      comparisons (pros, cons, trade-offs, recommendation). Show your work —
-      document what you tried and what you ruled out.
-
-  - name: prototyper
-    type: tempo-soloist
-    instructions: >
-      You build throwaway prototypes to test hypotheses from the explorer's findings.
-      Write quick, minimal code to prove or disprove an approach. Don't over-engineer —
-      this is a spike, not production code. Report what worked and what didn't.
-
-  - name: composer
-    type: tempo-composer
-    instructions: >
-      Evaluate the explorer's findings and prototyper's results through an architectural
-      lens. Assess how each option would fit into the existing system. Identify risks,
-      integration challenges, and long-term implications. Provide a recommendation
-      to the conductor.
-
-schedules:
-  - name: progress-check
-    message: "Share what you've found so far, even if incomplete. What have you tried? What looks promising? What's a dead end?"
-    target: all
-    every: 15m
+name: tempo-jam-session
+description: Exploratory ensemble for spikes, research, and problems where the path forward is unclear
+
+conductor:
+  type: tempo-conductor
+  instructions: >
+    You are leading a jam session — the goal is exploration, not delivery. Break the
+    unknown into research questions, assign them to the improv player and soloist,
+    and have the composer evaluate findings architecturally. Synthesize discoveries
+    into a clear recommendation or next steps. Time-box aggressively — report
+    findings even if incomplete.
+
+players:
+  - name: explorer
+    type: tempo-improv
+    instructions: >
+      You are the primary researcher. Investigate the unknown: read docs, explore
+      codebases, test hypotheses, evaluate options. Report findings with structured
+      comparisons (pros, cons, trade-offs, recommendation). Show your work —
+      document what you tried and what you ruled out.
+
+  - name: prototyper
+    type: tempo-soloist
+    instructions: >
+      You build throwaway prototypes to test hypotheses from the explorer's findings.
+      Write quick, minimal code to prove or disprove an approach. Don't over-engineer —
+      this is a spike, not production code. Report what worked and what didn't.
+
+  - name: composer
+    type: tempo-composer
+    instructions: >
+      Evaluate the explorer's findings and prototyper's results through an architectural
+      lens. Assess how each option would fit into the existing system. Identify risks,
+      integration challenges, and long-term implications. Provide a recommendation
+      to the conductor.
+
+schedules:
+  - name: progress-check
+    message: "Share what you've found so far, even if incomplete. What have you tried? What looks promising? What's a dead end?"
+    target: all
+    every: 15m

package/examples/ensembles/tempo-mock-jam.yaml

@@ -1,79 +1,79 @@
-name: tempo-mock-jam
-description: >
-  All-mock ensemble for autonomous validation harnesses (ADR 0014 §5.5).
-  One-command spin-up of a multi-player dev environment with mixed modes —
-  no real LLM calls, no terminal windows, no "trust this folder" prompts.
-  Pair with `agent-tempo --dev up --lineup tempo-mock-jam` and drive via
-  Chrome MCP / dashboard / `cue`.
-
-  Mode mix exercises every PR-3 mock surface in one ensemble:
-    - conductor      → scripted (conductor-recruit-mock scenario)
-    - alice          → scripted (multi-player-handoff scenario)
-    - bob            → echo (baseline round-trip; default mock behavior)
-    - silent-witness → silent (heartbeat-stale phase validation)
-    - chaos-monkey   → chaos (probabilistic fail/crash injection)
-
-  All five slots are mock — zero real LLM calls, zero terminal windows,
-  zero "trust this folder" prompts. Use the dashboard / TUI / `cue` to
-  drive the ensemble from outside.
-
-  To swap the conductor back to real Claude (human-driven demo):
-  open the TUI (/recruit-conductor) or use the MCP `recruit` tool with
-  agent: "claude" — the mock conductor will be replaced on the next
-  `claimAttachment`.
-
-  Override the scripted player's scenario per-run via the CLI:
-    agent-tempo --dev up --lineup tempo-mock-jam --scenario echo-roundtrip
-  That forces EVERY mock player into `mockMode: scripted` with the named
-  scenario regardless of the per-player `mockMode` here. Useful for
-  one-command "all mocks reply via this scenario" runs.
-
-conductor:
-  type: tempo-conductor
-  agent: mock
-  mockMode: scripted
-  mockScenario: conductor-recruit-mock
-  instructions: >
-    You're driving a mock-only ensemble for autonomous validation. The
-    players reply deterministically — no real LLM calls, no terminal
-    windows, no human-in-the-loop. Cue them, watch the dashboard, capture
-    bugs as scenario YAMLs.
-
-players:
-  - name: alice
-    agent: mock
-    mockMode: scripted
-    mockScenario: multi-player-handoff
-    instructions: >
-      Scripted three-way handoff player. Try: `cue alice "ship feature
-      caching"`. Splits the task to bob + carol-shaped peers, reports
-      progress through the conductor's outbox.
-
-  - name: bob
-    agent: mock
-    mockMode: echo
-    instructions: >
-      Echo round-trip baseline. Used as the receiving end of multi-player
-      handoff scenarios; every inbound cue comes back as `[ECHO] <text>`.
-
-  - name: silent-witness
-    agent: mock
-    mockMode: silent
-    instructions: >
-      Drains messages without ever replying. The heartbeat watcher should
-      transition this player to `awaiting` after the staleness threshold;
-      the dashboard should render the staleness indicator. Useful for
-      validating timeout / encore / pause flows.
-
-  - name: chaos-monkey
-    agent: mock
-    mockMode: chaos
-    instructions: >
-      Probabilistic failure injection. Configure rates via env vars on the
-      daemon: `AGENT_TEMPO_MOCK_CHAOS_DELAY_MS`,
-      `AGENT_TEMPO_MOCK_CHAOS_FAIL_RATE`,
-      `AGENT_TEMPO_MOCK_CHAOS_CRASH_RATE`,
-      `AGENT_TEMPO_MOCK_CHAOS_SEED` (pin for reproducibility). Defaults
-      are conservative (5 % fail, 1 % crash, no delay) so an idle ensemble
-      doesn't churn — set higher rates explicitly to stress the
-      supervisor-restart + outbox-retry paths.
+name: tempo-mock-jam
+description: >
+  All-mock ensemble for autonomous validation harnesses (ADR 0014 §5.5).
+  One-command spin-up of a multi-player dev environment with mixed modes —
+  no real LLM calls, no terminal windows, no "trust this folder" prompts.
+  Pair with `agent-tempo --dev up --lineup tempo-mock-jam` and drive via
+  Chrome MCP / dashboard / `cue`.
+
+  Mode mix exercises every PR-3 mock surface in one ensemble:
+    - conductor      → scripted (conductor-recruit-mock scenario)
+    - alice          → scripted (multi-player-handoff scenario)
+    - bob            → echo (baseline round-trip; default mock behavior)
+    - silent-witness → silent (heartbeat-stale phase validation)
+    - chaos-monkey   → chaos (probabilistic fail/crash injection)
+
+  All five slots are mock — zero real LLM calls, zero terminal windows,
+  zero "trust this folder" prompts. Use the dashboard / TUI / `cue` to
+  drive the ensemble from outside.
+
+  To swap the conductor back to real Claude (human-driven demo):
+  open the TUI (/recruit-conductor) or use the MCP `recruit` tool with
+  agent: "claude" — the mock conductor will be replaced on the next
+  `claimAttachment`.
+
+  Override the scripted player's scenario per-run via the CLI:
+    agent-tempo --dev up --lineup tempo-mock-jam --scenario echo-roundtrip
+  That forces EVERY mock player into `mockMode: scripted` with the named
+  scenario regardless of the per-player `mockMode` here. Useful for
+  one-command "all mocks reply via this scenario" runs.
+
+conductor:
+  type: tempo-conductor
+  agent: mock
+  mockMode: scripted
+  mockScenario: conductor-recruit-mock
+  instructions: >
+    You're driving a mock-only ensemble for autonomous validation. The
+    players reply deterministically — no real LLM calls, no terminal
+    windows, no human-in-the-loop. Cue them, watch the dashboard, capture
+    bugs as scenario YAMLs.
+
+players:
+  - name: alice
+    agent: mock
+    mockMode: scripted
+    mockScenario: multi-player-handoff
+    instructions: >
+      Scripted three-way handoff player. Try: `cue alice "ship feature
+      caching"`. Splits the task to bob + carol-shaped peers, reports
+      progress through the conductor's outbox.
+
+  - name: bob
+    agent: mock
+    mockMode: echo
+    instructions: >
+      Echo round-trip baseline. Used as the receiving end of multi-player
+      handoff scenarios; every inbound cue comes back as `[ECHO] <text>`.
+
+  - name: silent-witness
+    agent: mock
+    mockMode: silent
+    instructions: >
+      Drains messages without ever replying. The heartbeat watcher should
+      transition this player to `awaiting` after the staleness threshold;
+      the dashboard should render the staleness indicator. Useful for
+      validating timeout / encore / pause flows.
+
+  - name: chaos-monkey
+    agent: mock
+    mockMode: chaos
+    instructions: >
+      Probabilistic failure injection. Configure rates via env vars on the
+      daemon: `AGENT_TEMPO_MOCK_CHAOS_DELAY_MS`,
+      `AGENT_TEMPO_MOCK_CHAOS_FAIL_RATE`,
+      `AGENT_TEMPO_MOCK_CHAOS_CRASH_RATE`,
+      `AGENT_TEMPO_MOCK_CHAOS_SEED` (pin for reproducibility). Defaults
+      are conservative (5 % fail, 1 % crash, no delay) so an idle ensemble
+      doesn't churn — set higher rates explicitly to stress the
+      supervisor-restart + outbox-retry paths.

package/examples/ensembles/tempo-review-squad.yaml

@@ -1,32 +1,32 @@
-name: tempo-review-squad
-description: Three critics with different focus areas for thorough parallel code review
-
-conductor:
-  type: tempo-conductor
-  instructions: >
-    You are coordinating a code review squad. Assign code areas or PRs to critics
-    based on their specialization. Each critic reviews the same changes but focuses
-    on their area. Collect their feedback, synthesize findings into a unified review,
-    and report the overall verdict.
-
-players:
-  - name: security-critic
-    type: tempo-critic
-    instructions: >
-      Focus your review on security: input validation, authentication, authorization,
-      injection vulnerabilities, secrets handling, OWASP top 10, and dependency risks.
-      Flag anything that could be exploited. Blockers only for real vulnerabilities.
-
-  - name: perf-critic
-    type: tempo-critic
-    instructions: >
-      Focus your review on performance: algorithmic complexity, memory usage, unnecessary
-      allocations, N+1 queries, caching opportunities, bundle size, and hot paths.
-      Flag anything that would degrade user experience under load.
-
-  - name: quality-critic
-    type: tempo-critic
-    instructions: >
-      Focus your review on code quality: readability, maintainability, test coverage,
-      error handling, naming conventions, and adherence to project standards. Flag
-      anything that would make the code harder to work with in six months.
+name: tempo-review-squad
+description: Three critics with different focus areas for thorough parallel code review
+
+conductor:
+  type: tempo-conductor
+  instructions: >
+    You are coordinating a code review squad. Assign code areas or PRs to critics
+    based on their specialization. Each critic reviews the same changes but focuses
+    on their area. Collect their feedback, synthesize findings into a unified review,
+    and report the overall verdict.
+
+players:
+  - name: security-critic
+    type: tempo-critic
+    instructions: >
+      Focus your review on security: input validation, authentication, authorization,
+      injection vulnerabilities, secrets handling, OWASP top 10, and dependency risks.
+      Flag anything that could be exploited. Blockers only for real vulnerabilities.
+
+  - name: perf-critic
+    type: tempo-critic
+    instructions: >
+      Focus your review on performance: algorithmic complexity, memory usage, unnecessary
+      allocations, N+1 queries, caching opportunities, bundle size, and hot paths.
+      Flag anything that would degrade user experience under load.
+
+  - name: quality-critic
+    type: tempo-critic
+    instructions: >
+      Focus your review on code quality: readability, maintainability, test coverage,
+      error handling, naming conventions, and adherence to project standards. Flag
+      anything that would make the code harder to work with in six months.