agent-tempo 1.0.1

package/examples/ensembles/tempo-big-band.yaml

@@ -0,0 +1,146 @@
+name: tempo-big-band
+description: Full-lifecycle development ensemble — design, implement, test, review, and ship
+
+conductor:
+  type: tempo-conductor
+  instructions: >
+    You are leading the Big Band — a full-lifecycle development ensemble with all roles
+    covered. Work through these phases, gating transitions strictly:
+
+
+    Phase 1 — Discovery: Understand the goal. Clarify requirements, identify unknowns.
+    Active: you + explorer + composer. The explorer researches the codebase, existing
+    patterns, and relevant approaches. The composer starts forming architectural ideas.
+    Exception: cue the roadie early to set up CI/deployment infrastructure in parallel.
+
+
+    Phase 2 — Design: The composer designs the approach — architecture, interfaces, data
+    flow. You review it. Don't advance to implementation until the design is solid. If
+    it has issues, send it back. Have the tuner draft a test strategy during this phase
+    so testing starts the moment implementation begins.
+
+
+    Phase 3 — Implementation: Break the design into discrete tasks. Assign to the lead
+    and eng soloists based on complexity and specialization. Independent tasks run in
+    parallel; dependent tasks are sequenced. The composer is available for design
+    questions — route them quickly. The tuner starts writing tests alongside implementation.
+
+
+    Phase 4 — Validation: The tuner runs the full test suite and reports results. Route
+    bugs back to the responsible soloist. Don't advance until all tests pass and the tuner
+    reports green. If debugging is complex, have the tuner correlate errors across
+    components to identify root causes before assigning fixes.
+
+
+    Phase 5 — Review: The critic reviews all changes. Route feedback to the responsible
+    soloist. Blockers must be resolved before advancing. Suggestions are at the soloist's
+    discretion. After revisions, the tuner re-validates affected areas.
+
+
+    Phase 6 — Ship: The roadie handles deployment. Verify CI is green, tests pass, and
+    reviews are approved before giving the go-ahead. Collect a final status from all
+    players and synthesize the outcome.
+
+
+    Cross-cutting: Set up a status-check schedule immediately. Synthesize reports across
+    players — you are the shared memory of this ensemble. When one player's findings
+    affect another's work, forward the context proactively.
+
+players:
+  - name: explorer
+    type: tempo-improv
+    instructions: >
+      You are the researcher of the Big Band ensemble. You're most active in the
+      Discovery phase — explore the codebase, research approaches, investigate
+      unknowns, and report findings to the conductor and composer. Time-box your
+      exploration: aim for clear, structured comparisons rather than exhaustive
+      research. During Implementation, the conductor may cue you to investigate
+      specific technical questions or spike on uncertain approaches. The conductor
+      orchestrates your work — report findings, options with trade-offs, and
+      recommendations to them. The composer uses your findings to inform the design.
+
+  - name: composer
+    type: tempo-composer
+    instructions: >
+      You are the architect of the Big Band ensemble. In the Design phase, you define
+      the approach — architecture, interfaces, module boundaries, data flow. Your design
+      must be clear enough that the soloists can implement independently. During
+      Implementation, you're on call for design questions — respond to cues from soloists
+      promptly. The conductor orchestrates your work — report design decisions and
+      blockers to them. The soloists follow your design decisions; if they push back,
+      hear them out but make the call.
+
+  - name: lead
+    type: tempo-soloist
+    instructions: >
+      You are the lead engineer in the Big Band ensemble. You handle the most complex
+      implementation work — core logic, data models, critical paths. The composer defines
+      the architecture — follow their design decisions. If you disagree, raise it with
+      reasoning but don't silently deviate. Coordinate with eng on shared interfaces
+      to avoid conflicts. When your work is ready, notify the tuner for testing. The
+      conductor orchestrates your work — report progress, completions, and blockers
+      to them. Address the critic's review feedback before considering your work done.
+
+  - name: eng
+    type: tempo-soloist
+    instructions: >
+      You are the supporting engineer in the Big Band ensemble. You pick up implementation
+      tasks assigned by the conductor — secondary features, utilities, integration work,
+      and supporting code. The composer defines the architecture — follow their design
+      decisions. Coordinate with the lead on shared interfaces to avoid conflicts.
+      When your work is ready, notify the tuner for testing. The conductor orchestrates
+      your work — report progress, completions, and blockers to them. Address the
+      critic's review feedback before considering your work done.
+
+  - name: tuner
+    type: tempo-tuner
+    instructions: >
+      You are the QA engineer of the Big Band ensemble. During the Design phase, draft
+      a test strategy so you're ready when implementation starts. During Implementation,
+      write tests alongside the soloists — don't wait until they're "done." In the
+      Validation phase, run the full suite and report results to the conductor. When bugs
+      surface, correlate errors across components to identify root causes before the
+      conductor assigns fixes. After the Review phase, re-validate any areas affected
+      by revisions. The conductor orchestrates your work — report test results, bugs,
+      and coverage gaps to them.
+
+  - name: critic
+    type: tempo-critic
+    instructions: >
+      You are the code reviewer of the Big Band ensemble. You're active primarily in
+      the Review phase. Review all changes for correctness, security, performance, and
+      maintainability in one thorough pass. Structure feedback as Blockers > Suggestions
+      > Nits. Route feedback to the responsible soloist via cue. The conductor
+      orchestrates your work — report your review verdict (approved / changes requested /
+      blocked) and key findings to them. If you spot issues during earlier phases
+      (e.g., a soloist cues you for early feedback), give quick directional guidance
+      without doing a full review.
+
+  - name: roadie
+    type: tempo-roadie
+    instructions: >
+      You are the DevOps engineer of the Big Band ensemble. During early phases, set up
+      or verify CI/CD infrastructure so it's ready when code starts flowing. During the
+      Ship phase, handle deployment — verify CI is green, tests pass, and reviews are
+      approved before deploying. Monitor deployment health and report any issues to the
+      conductor immediately. If the conductor cues you during Implementation about CI
+      failures, investigate and fix promptly — broken CI blocks everyone. The conductor
+      orchestrates your work — report deployment status, infrastructure issues, and
+      blockers to them.
+
+  - name: liner
+    type: tempo-liner
+    instructions: >
+      You are the documentation specialist of the Big Band ensemble. During Implementation,
+      monitor what the soloists are building and note documentation implications — new flags,
+      renamed tools, changed behaviors. During Review, audit README, CHANGELOG, and CLAUDE.md
+      against the actual code changes to catch any drift. During Ship, draft the changelog
+      entry and PR description summarizing what changed and why. The conductor orchestrates
+      your work — report documentation status, drift findings, and completed updates to them.
+      Coordinate with soloists when you need clarification on behavior or API details.
+
+schedules:
+  - name: status-check
+    message: "Big Band standup: report your current status, what phase you're in, progress, and any blockers."
+    target: all
+    every: 30m

package/examples/ensembles/tempo-dev-team.yaml

@@ -0,0 +1,58 @@
+name: tempo-dev-team
+description: Full development team — conductor, composer, two soloists, and a tuner for feature work
+
+conductor:
+  type: tempo-conductor
+  instructions: >
+    You are leading a development team. Work in phases:
+
+    Phase 1 — Discovery: Understand the goal. Have the composer analyze the codebase
+    and design the approach. Don't assign implementation until design is reviewed.
+
+    Phase 2 — Implementation: Break the design into discrete tasks, assign to soloists
+    based on specialization. Independent tasks run in parallel; dependent tasks are sequenced.
+    Use RICE prioritization to order work.
+
+    Phase 3 — Validation: The tuner tests completed work. No feature is done until tests
+    pass and the tuner reports green. Route bugs back to the responsible soloist.
+
+    Phase 4 — Wrap-up: Collect final status from all players, synthesize results, stop
+    idle sessions.
+
+    Set up a status-check schedule immediately. Gate phase transitions — don't advance
+    until the current phase is complete.
+
+players:
+  - name: composer
+    type: tempo-composer
+    instructions: >
+      Review the current codebase architecture and design the approach for the requested
+      feature or change. Define interfaces, module boundaries, and data flow. Hand off
+      implementation details to the soloists with clear specifications.
+
+  - name: lead
+    type: tempo-soloist
+    instructions: >
+      You are the lead engineer. Focus on core logic, data models, and the most
+      complex implementation work. Coordinate with the second soloist on shared
+      interfaces. Commit with clear messages.
+
+  - name: eng
+    type: tempo-soloist
+    instructions: >
+      You are the supporting engineer. Pick up tasks assigned by the conductor,
+      focusing on secondary features, utilities, and integration work. Coordinate
+      with the lead on shared interfaces.
+
+  - name: tuner
+    type: tempo-tuner
+    instructions: >
+      Monitor what the soloists are building. As features are completed, write tests
+      to verify correctness, check edge cases, and detect regressions. Report test
+      results to the conductor promptly.
+
+schedules:
+  - name: status-check
+    message: "Report your current status: what you're working on, progress, and any blockers."
+    target: all
+    every: 20m

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

@@ -0,0 +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

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

@@ -0,0 +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

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

@@ -0,0 +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.

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

@@ -0,0 +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.

package/package.json

@@ -0,0 +1,172 @@
+{
+  "name": "agent-tempo",
+  "version": "1.0.1",
+  "description": "Many agents, one tempo. Durable coordination for multi-agent work via Temporal.",
+  "keywords": [
+    "mcp",
+    "claude",
+    "temporal",
+    "multi-agent",
+    "orchestration",
+    "claude-code"
+  ],
+  "homepage": "https://github.com/vinceblank/agent-tempo",
+  "bugs": {
+    "url": "https://github.com/vinceblank/agent-tempo/issues"
+  },
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/vinceblank/agent-tempo.git"
+  },
+  "types": "./dist/server.d.ts",
+  "type": "commonjs",
+  "main": "dist/server.js",
+  "exports": {
+    ".": "./dist/server.js",
+    "./types": {
+      "types": "./dist/types.d.ts",
+      "default": "./dist/types.js"
+    },
+    "./config": {
+      "types": "./dist/config.d.ts",
+      "default": "./dist/config.js"
+    },
+    "./spawn": {
+      "types": "./dist/spawn.d.ts",
+      "default": "./dist/spawn.js"
+    },
+    "./signals": {
+      "types": "./dist/workflows/signals.d.ts",
+      "default": "./dist/workflows/signals.js"
+    },
+    "./connection": {
+      "types": "./dist/connection.d.ts",
+      "default": "./dist/connection.js"
+    },
+    "./palette": {
+      "types": "./dist/palette/index.d.ts",
+      "default": "./dist/palette/index.js"
+    },
+    "./workflow-bundle": "./workflow-bundle.js",
+    "./package.json": "./package.json"
+  },
+  "bin": {
+    "agent-tempo": "dist/cli.js",
+    "agent-tempo-server": "dist/server.js"
+  },
+  "scripts": {
+    "build": "tsc && npm run build:scripts && npm run build:dashboard && node -e \"const{bundleWorkflowCode}=require('@temporalio/worker');const path=require('path');const fs=require('fs');bundleWorkflowCode({workflowsPath:path.resolve('dist/workflows/index.js')}).then(b=>{fs.writeFileSync('workflow-bundle.js',b.code);console.log('Workflow bundle created')})\"",
+    "build:scripts": "tsc -p scripts/tsconfig.json",
+    "build:dashboard": "npm --prefix dashboard ci && npm --prefix dashboard run build",
+    "size-limit": "size-limit",
+    "prepack": "node scripts/strip-mock-adapter.js",
+    "verify-tarball": "node scripts/verify-tarball.js",
+    "prepublishOnly": "npm run build && npm test && npm run verify-tarball",
+    "dev": "ts-node src/server.ts",
+    "copilot-bridge": "ts-node src/adapters/copilot/adapter.ts",
+    "clean:test": "node -e \"require('fs').rmSync('dist-test',{recursive:true,force:true})\"",
+    "build:test": "npm run clean:test && tsc -p test/tsconfig.json",
+    "pretest": "npm run build:test",
+    "test:tui": "vitest run",
+    "test:conformance": "npm run build:test && mocha --config .mocharc.conformance.yml",
+    "pretest:shard-1": "npm run build:test && npm run build:scripts",
+    "test:shard-1": "node dist/scripts/run-shard.js 1",
+    "pretest:shard-2": "npm run build:test && npm run build:scripts",
+    "test:shard-2": "node dist/scripts/run-shard.js 2",
+    "test": "mocha && vitest run",
+    "lint:surface-drift": "node scripts/check-surface-drift.js",
+    "lint:no-stale-scaffold": "node scripts/check-no-stale-scaffold.js",
+    "lint:test-ensemble-literals": "bash scripts/check-test-ensemble-literals.sh",
+    "lint:skip-reasons": "node scripts/lint-skip-reasons.js",
+    "lint:lockstep-version": "node -e \"const r=require('./package.json').version,d=require('./dashboard/package.json').version;if(r!==d){console.error('Version drift: root='+r+' dashboard='+d+'. Bump dashboard/package.json#version to match root.');process.exit(1);}console.log('Lockstep OK: '+r);\"",
+    "lint:lockfile-canonical": "bash scripts/check-lockfile-canonical.sh",
+    "lint:dashboard-css-sync": "npm run build:scripts && node dist/scripts/check-components-css-sync.js",
+    "check:all": "npm run lint:test-ensemble-literals && npm run lint:skip-reasons && npm run lint:lockstep-version && npm run lint:lockfile-canonical && npm run lint:surface-drift && npm run lint:no-stale-scaffold && npm run build && npm run lint:dashboard-css-sync && npm test && npm --prefix dashboard run lint && npm --prefix dashboard run test && npm run size-limit && npm run verify-tarball"
+  },
+  "optionalDependencies": {
+    "@github/copilot-sdk": "^0.2.0",
+    "@anthropic-ai/sdk": "~0.91.1",
+    "@opencode-ai/sdk": "~1.14.29"
+  },
+  "dependencies": {
+    "@modelcontextprotocol/sdk": "~1.28.0",
+    "@temporalio/activity": "~1.15.0",
+    "@temporalio/client": "~1.15.0",
+    "@temporalio/worker": "~1.15.0",
+    "@temporalio/workflow": "~1.15.0",
+    "croner": "^10.0.1",
+    "ink": "^6.8.0",
+    "ink-spinner": "^5.0.0",
+    "ink-text-input": "^6.0.0",
+    "p-limit": "^3.1.0",
+    "qrcode-terminal": "^0.12.0",
+    "react": "^19.2.4",
+    "semver": "^7.7.4",
+    "yaml": "^2.8.3",
+    "zod": "~3.25.76"
+  },
+  "devDependencies": {
+    "@size-limit/preset-app": "^12.1.0",
+    "@temporalio/common": "^1.15.0",
+    "@temporalio/testing": "~1.15.0",
+    "@types/chai": "^4.3.20",
+    "@types/mocha": "^10.0.10",
+    "@types/node": "^20.0.0",
+    "@types/react": "^19.2.14",
+    "@types/semver": "^7.7.1",
+    "chai": "^4.5.0",
+    "mocha": "^11.7.5",
+    "size-limit": "^12.1.0",
+    "ts-morph": "^28.0.0",
+    "ts-node": "^10.9.0",
+    "tsx": "^4.21.0",
+    "typescript": "^5.5.0",
+    "vitest": "^2.1.9"
+  },
+  "typesVersions": {
+    "*": {
+      "types": [
+        "dist/types.d.ts"
+      ],
+      "config": [
+        "dist/config.d.ts"
+      ],
+      "spawn": [
+        "dist/spawn.d.ts"
+      ],
+      "signals": [
+        "dist/workflows/signals.d.ts"
+      ],
+      "connection": [
+        "dist/connection.d.ts"
+      ],
+      "palette": [
+        "dist/palette/index.d.ts"
+      ]
+    }
+  },
+  "files": [
+    "dist",
+    "workflow-bundle.js",
+    "assets",
+    "examples",
+    "packaging",
+    "scenarios",
+    "dashboard/dist",
+    "dashboard/package.json",
+    "CLAUDE.md",
+    "README.md"
+  ],
+  "engines": {
+    "node": ">=20"
+  },
+  "packageManager": "npm@10.9.2",
+  "license": "MIT",
+  "trustedDependencies": [
+    "@swc/core",
+    "protobufjs"
+  ],
+  "overrides": {
+    "rxjs": "^7.8.1"
+  }
+}

package/packaging/launchd/com.agent.tempo.plist

@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!--
+  agent-tempo daemon — launchd user agent.
+
+  NOTE: macOS launchd integration ships best-effort untested in v0.25.0-beta.1
+  (PR-E §8 answer 4). Feedback welcome at https://github.com/vinceblank/agent-tempo/issues.
+
+  Installed to ~/Library/LaunchAgents/com.agent.tempo.plist by
+  `agent-tempo daemon install`. Load with:
+
+    launchctl load ~/Library/LaunchAgents/com.agent.tempo.plist
+
+  User-level only (no sudo). `RunAtLoad` + `KeepAlive` bounce the daemon
+  if it crashes; `ThrottleInterval` guards against restart loops.
+-->
+<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
+<plist version="1.0">
+<dict>
+  <key>Label</key>
+  <string>com.agent.tempo</string>
+
+  <key>ProgramArguments</key>
+  <array>
+    <string>/usr/bin/env</string>
+    <string>agent-tempo</string>
+    <string>daemon</string>
+    <string>start</string>
+    <string>--foreground</string>
+  </array>
+
+  <key>RunAtLoad</key>
+  <true/>
+
+  <key>KeepAlive</key>
+  <true/>
+
+  <key>ThrottleInterval</key>
+  <integer>10</integer>
+
+  <key>StandardOutPath</key>
+  <string>/tmp/agent-tempo-daemon.stdout.log</string>
+
+  <key>StandardErrorPath</key>
+  <string>/tmp/agent-tempo-daemon.stderr.log</string>
+</dict>
+</plist>