muse-crew 0.1.0

package/AGENTS.md

@@ -0,0 +1,19 @@
+# AGENTS.md
+
+Muse Crew source repository. The repo is the product; the personal instance (`$CREW_HOME`) is disposable scaffolding reproduced by `crew-init`.
+
+## Structure
+
+- `API.md` — the Crew API contract: every action a task service must implement
+- `.orchestration/` — this project's crew configuration (project.json)
+- `identities/` — crew member character files and portraits
+- `lib/` — shell scripts for release, merge, worktree, and cleanup
+- `personas/` — QA perspective costumes for Hazel
+- `seed/` — init source data: everything `crew-init.js` reads when setting up a new crew instance
+- `workflows/` — executable Muse workflow scripts (JavaScript)
+
+## Rules
+
+- Git source is authoritative.
+- Never expose this repo publicly.
+- Ship implementation and documentation together.

package/API.md

@@ -0,0 +1,213 @@
+# Muse Crew API
+
+The contract between Muse Crew and any task service implementation. The dispatcher and task workflows call these actions. A conforming task service must implement all of them.
+
+The current implementation is the `orchestra-dashboard` web artifact.
+
+---
+
+## Tasks
+
+### `createtask`
+
+Create a new task on the board.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `title` | string (1–160 chars) | yes | |
+| `description` | string (≤ 5000) | no | Defaults to `""` |
+| `project` | slug | no | Defaults to the service's default project |
+| `workflow` | slug or null | no | Routing label (e.g. `standard`, `bugfix`, `chore`, `docs`) |
+| `priority` | `high` · `normal` · `low` | no | Defaults to `normal` |
+| `state` | `todo` · `in_progress` · `parked` · `done` | no | Defaults to `todo` |
+| `deps` | string[] | no | Task IDs this task depends on |
+
+### `updatetask`
+
+Update an existing task's fields. Only `id` is required; all other fields are optional patch fields.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `id` | uuid | yes | |
+| `title` | string (1–200) | no | |
+| `description` | string (≤ 3000) | no | |
+| `state` | `todo` · `in_progress` · `parked` · `done` | no | |
+| `priority` | `high` · `normal` · `low` | no | |
+| `project` | slug | no | |
+| `workflow` | slug or null | no | |
+| `deps` | string[] | no | |
+
+### `claimtask`
+
+Atomically claim a task for a workflow step. Used by the dispatcher and by workflow phases at their start.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `task_id` | uuid | yes | |
+| `identity` | string (1–80) | yes | The crew identity performing the step (e.g. `sage`, `wren`) |
+| `step` | string (1–120) | no | The workflow phase name |
+| `notes` | string (≤ 3000) | no | Defaults to `""` |
+
+### `recovertask`
+
+Send a stuck or failed task to a specific workflow phase for recovery.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `task_id` | uuid | yes | |
+| `action` | `"send_to"` | yes | Only `send_to` is supported |
+| `target_phase` | string (1–120) | yes | The phase to send the task to |
+| `updated_description` | string (≤ 5000) | no | Optional revised description |
+
+---
+
+## Sessions
+
+### `upsertagentsession`
+
+Create or update an agent session record. Sessions track which identity is working on which task, in which phase, and what happened.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `task_id` | uuid | yes | |
+| `identity` | slug | yes | |
+| `status` | `running` · `completed` · `failed` · `rejected` · `timed_out` · `stalled` · `passed` · `superseded` | yes | |
+| `id` | uuid | no | Session ID; omit to create, provide to update |
+| `step` | string (1–120) | no | Workflow phase |
+| `started_at` | ISO 8601 datetime (UTC) | no | |
+| `ended_at` | ISO 8601 datetime (UTC) or null | no | |
+| `notes` | string (≤ 3000) | no | |
+| `failure_reason` | string (≤ 3000) or null | no | |
+| `caveats` | array of `{text, severity}` | no | |
+
+---
+
+## Events
+
+### `logevent`
+
+Log an event to the activity timeline.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `type` | `dispatched` · `completed` · `failed` · `blocked` · `created` · `note` · `release_activated` · `deployed` | yes | |
+| `message` | string (1–1000) | yes | |
+| `task_id` | uuid or null | no | Associate with a specific task |
+| `identity` | slug or null | no | Which crew member logged it |
+| `timestamp` | ISO 8601 datetime (UTC) | no | Defaults to now |
+
+### `getevents`
+
+Read the event timeline.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `limit` | integer (1–100) | no | Defaults to 50 |
+
+---
+
+## Dispatch
+
+### `getdispatchstate`
+
+Read the full board state for dispatch decisions. Takes no arguments. Returns all projects with their tasks, simultaneity limits, quiesce state, and active sessions — everything the dispatcher needs to decide what to claim.
+
+### `acknowledge_poll`
+
+Record that a poll tick occurred. Takes no arguments. Used by the dispatcher at the end of each cycle to update the last-polled timestamp.
+
+---
+
+## Projects
+
+### `createproject`
+
+Register a new project.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `id` | slug | yes | Unique project identifier |
+| `display_name` | string (1–120) | yes | |
+| `repo_path` | string (1–1000) | yes | Absolute path to the project's Git repo |
+| `deploy_type` | `artifact` · `repo` | yes | |
+| `deploy_slug` | slug or null | no | Required when `deploy_type` is `artifact` |
+| `description` | string (≤ 3000) | no | |
+| `simultaneity` | integer (1–100) | no | Max concurrent tasks; defaults to 2 |
+| `quiesced` | boolean | no | Start paused; defaults to false |
+| `idle_hunting` | boolean | no | Defaults to false |
+
+### `updateproject`
+
+Update project fields. Only `id` is required; all others are optional patch fields. Same fields as `createproject`, except `simultaneity` minimum is 0 (for kill switch state).
+
+### `deleteproject`
+
+Remove a project registration.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `id` | slug | yes | |
+
+### `listprojects`
+
+List all registered projects. Takes no arguments.
+
+### `getproject`
+
+Get one project's full record.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `id` | slug | yes | |
+
+---
+
+## Control
+
+### `killswitch`
+
+Pause or resume dispatch for a project. Sets simultaneity to 0 (pause) or restores the previous value (resume). Requires a reason for the audit trail.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `project_id` | slug | yes | |
+| `action` | `pause` · `resume` | yes | |
+| `reason` | string (1–1000) | yes | Logged with the event |
+| `actor` | string (1–120) | no | Defaults to `"agent"` |
+
+---
+
+## State
+
+### `getstate`
+
+Read the full dashboard state: tasks, sessions, events, and projects. Used by workflow agents to understand current context.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `day_start` | ISO 8601 datetime (UTC) | no | Filter events window |
+| `day_end` | ISO 8601 datetime (UTC) | no | |
+| `events_limit` | integer (1–100) | no | Defaults to 20 |
+| `events_offset` | integer | no | Defaults to 0 |
+
+### `getconfig`
+
+Read global configuration. Takes no arguments.
+
+### `updateconfig`
+
+Set a global configuration value.
+
+| Field | Type | Required | Notes |
+|-------|------|----------|-------|
+| `key` | string (1–80) | yes | |
+| `value` | string (≤ 10000) | yes | |
+
+---
+
+## Not part of this API
+
+The following are dashboard-specific view operations, not part of the Crew API contract:
+
+- `getidentityavatar` — serves identity portrait images for the UI
+- `listdocuments` — lists `.orchestration/` files for display

package/README.md

@@ -0,0 +1,68 @@
+# Muse Crew
+
+A system for building autonomous agent teams on [Muse](https://muse.ai). You file tasks, and a team of agents works them to done while you do something else.
+
+> Engineering preview. Internal use only.
+
+## How It Works
+
+Five things make it go.
+
+**Tasks** are units of work, filed to a [dashboard](https://github.com/emojimanegg1/orchestra-dashboard) that outlives every agent that touches them. The [Symphony](https://github.com/openai/symphony) pattern — poll for work, dispatch agents to isolated runs, reconcile on state changes. The agent dies; the task doesn't.
+
+**Workflows** define what happens to a task. Each phase is a [dynamic workflow](https://claude.com/blog/a-harness-for-every-task-dynamic-workflows-in-claude-code) — a script that orchestrates the agent, not a prompt. Phases enforce context boundaries: QA can't see source code, the reviewer comes in cold. Defaults ship for software development; workflows are just scripts.
+
+**Identities** are the characters who do the work — values, taste, writing style. What makes the reviewer exacting and the QA agent persistent.
+
+**Projects** connect a repository to a deploy target. Tasks belong to projects; the dispatcher routes each task through its project's configuration.
+
+**Scheduling** uses [Muse's](https://muse.ai) always-on cron. The dispatcher checks the board every few minutes, claims what's ready, and puts the right agent on the right phase. Review rejects bounce back automatically. The system keeps going until the work is done or stuck.
+
+## Included: Software Development
+
+The repo ships workflows and identities for a software development crew — one team built on the architecture, an example of what you can compose.
+
+| Identity | Role | Why it matters |
+|----------|------|----------------|
+| **Sage** | Triage | Fast routing — classifies and prioritizes before anything else runs |
+| **Mara** | Designer | Makes tasks solution-oriented before building starts |
+| **Wren** | Builder | Trusts the plan, lets commits speak. Also handles integration and deployment |
+| **Cass** | Reviewer | Fair but exacting — holds the spec as the contract until the work is tight |
+| **Hazel** | QA | Code-blind by design. Persistent. Wears persona costumes for multi-lens testing |
+| **Tate** | Docs | Observational, jargon-hostile |
+
+```
+standard:  Triage → Map → Build → Review → Integrate → Deploy → QA
+bugfix:    Triage → Reproduce → Map → Build → Review → Integrate → Deploy → QA
+chore:     Triage → Map → Build → Review → Integrate → Deploy
+docs:      Triage → Write → Review
+```
+
+## Quick Start
+
+Install the package:
+
+```
+npm install muse-crew
+```
+
+You'll need a task service that implements the [Crew API](API.md) — something to hold tasks, track sessions, and serve the board. The [Orchestra Dashboard](https://github.com/emojimanegg1/orchestra-dashboard) is the reference implementation. Set that up first, then run `crew-init` with its slug.
+
+The dashboard becomes the crew's first project — the crew works on itself.
+
+## Documentation
+
+- [**Guide**](docs/guide.md) — setup, project registration, task filing, the loop, pause/resume, releases, and current limitations
+- [**Crew API**](API.md) — the contract any task service must implement
+- [**Orchestra Dashboard**](https://github.com/emojimanegg1/orchestra-dashboard) — reference task-service implementation
+
+## Structure
+
+```
+workflows/     Executable Muse workflow scripts
+lib/           Shell utilities (release, merge, worktree, cleanup)
+identities/    Crew member character files and portraits
+personas/      QA persona costumes
+seed/          Init source data (cron template, workflow definitions)
+docs/          Full documentation
+```

package/docs/AGENTS.md

@@ -0,0 +1,3 @@
+# docs/
+
+User-facing documentation for Muse Crew. The guide is the full reference; the README links here.

package/docs/guide.md

@@ -0,0 +1,333 @@
+# Muse Crew Guide
+
+This is the full setup and operations reference. If you're new, start with the [README](../README.md) for the overview.
+
+## Components
+
+**In this repo:**
+- **Workflow scripts** — walk each task through its phases (Triage → Map → Build → Review → Integrate → Deploy → QA). The defaults are built for software, but you can create your own workflows for any kind of work.
+- A **dispatcher** — reads the board and puts the crew to work.
+- A **release system** — immutable releases with atomic symlink swap. Works with Git checkouts or npm installs.
+- An **`.orchestration/` scaffold** — identity files, persona files, workflow documentation, and feedback conventions.
+
+**Required before init:**
+- A **task service** — a web artifact implementing the [Crew API](../API.md) contract: task board, activity feed, project registry, and agent session log. The [Orchestra Dashboard](https://github.com/emojimanegg1/orchestra-dashboard) is the reference implementation. Create it first; init needs its slug.
+
+**Created by init (live outside this repo):**
+- A **release** — the first immutable snapshot of the crew's runtime code.
+- An **`.orchestration/` directory** in the crew home with identities, personas, workflow docs, and feedback conventions.
+- A **project registration** — the task service registered as its own first project.
+- A **polling loop** — checks for work every 3 minutes via Muse's scheduling, even when nobody's in the conversation.
+- An **orphan sweep** — runs every 30 minutes to clean merged worktrees and break stale merge locks.
+
+The agent running in the main chat receives the dispatcher's claims and launches each task workflow. Workflows can't launch workflows, so this handoff is structural.
+
+## The Crew API
+
+All task operations — creating tasks, registering projects, reading board state, pausing dispatch — go through the [Crew API](../API.md). The API is the contract; it doesn't assume a specific task service implementation. The current implementation is a web artifact, but anything conforming to the API would work.
+
+When this guide says "call an action," it means calling an action defined in the API contract.
+
+## Setup from scratch
+
+### Prerequisites
+
+- A Muse account with access to workflows, crons, and artifacts.
+- The `muse-crew` package installed via npm, or the repo cloned locally.
+- A directory chosen for the crew home (e.g., `~/workspace/.jarvis`).
+- A task service artifact already created. The [Orchestra Dashboard](https://github.com/emojimanegg1/orchestra-dashboard) is the reference implementation — clone its repo, create the artifact, and note its slug.
+
+### Running init
+
+```
+workflow_launch with:
+  scriptPath: "<crewSourcePath>/workflows/crew-init.js"
+  args: {
+    crewRepoPath: "<path to muse-crew package or repo>",
+    crewHome: "~/workspace/.jarvis",
+    dashboardSlug: "orchestra-dashboard"
+  }
+```
+
+Required arguments:
+- `crewRepoPath` — path to the `muse-crew` source. This can be an npm install (e.g., `node_modules/muse-crew`) or a Git checkout.
+- `crewHome` — directory where the crew's runtime state lives.
+- `dashboardSlug` — slug of the task service artifact (must already exist).
+
+Optional arguments:
+- `dashboardName` — display name for the project registration (default: `"Muse Crew"`).
+- `cronId` — polling cron identifier (default: `"crew-poll"`).
+- `sweepCronId` — orphan sweep cron identifier (default: `"crew-sweep"`).
+
+### What init creates
+
+Init runs five phases, each idempotent — re-running skips anything that already exists:
+
+1. **Release** — copies `crew-release.sh` to `crewHome`, runs `init` to create the first release from the source directory. From a Git checkout, it extracts `workflows/` and `lib/` via `git archive` and uses the commit hash as the release identity. From an npm install, it copies the directories directly and uses the package version (e.g., `pkg-0.1.0`). Creates a release directory, sets the `current` symlink.
+
+2. **Scaffold** — creates `crewHome/.orchestration/` with subdirectories for identities, personas, workflows (documentation, not scripts), and feedback. Copies all `.md` and `.png` files from the repo using `cp -n` (no-clobber), so existing customizations are preserved.
+
+3. **Project registration** — registers the task service as a project in its own database via `createproject`. The dashboard becomes its own first project, so the crew can work on the dashboard itself.
+
+4. **Polling cron** — creates a 3-minute interval cron from the template at `seed/cron-body-template.md`, with `crewHome` and the dashboard slug substituted in. Owner is `space:<slug>`, so deleting the task service also removes the cron.
+
+5. **Sweep cron** — creates a 30-minute interval cron that runs the orphan sweep to clean merged worktrees and break stale merge locks. Owner is `space:<slug>`.
+
+### Verification
+
+After init completes, it returns a summary:
+
+```json
+{
+  "message": "Muse Crew initialized.",
+  "crewHome": "~/workspace/.jarvis",
+  "dashboardSlug": "orchestra-dashboard",
+  "dashboardName": "Muse Crew",
+  "cronId": "crew-poll",
+  "releaseHash": "<git commit hash>",
+  "scaffold": { "created": 23, "skipped": 0 },
+  "project": "registered",
+  "cron": "created",
+  "sweepCron": "created"
+}
+```
+
+Re-running init against an existing setup returns all `"existed"` / `"skipped"` results with no mutations.
+
+## Connecting an existing project
+
+Projects are registered through the API, not through init. Init sets up the infrastructure and registers the task service as the first project; you register additional projects separately.
+
+### Register a project
+
+Call the `createproject` action (see the [API reference](../API.md) for the full schema):
+
+```json
+{
+  "id": "my-web-app",
+  "display_name": "My Web App",
+  "repo_path": "/absolute/path/to/repo",
+  "deploy_type": "artifact",
+  "deploy_slug": "my-web-app",
+  "description": "What this project does",
+  "simultaneity": 2
+}
+```
+
+Required fields:
+- `id` — kebab-case identifier, unique across all projects.
+- `display_name` — human-readable name.
+- `repo_path` — absolute path to the project's Git repository.
+- `deploy_type` — `"artifact"` (deploys via artifact edit) or `"repo"` (changes stay in the repo).
+
+Optional fields:
+- `deploy_slug` — the artifact slug, required when `deploy_type` is `"artifact"`.
+- `description` — free text.
+- `simultaneity` — max concurrent tasks for this project (default: 2, range: 1–100).
+- `quiesced` — start paused (default: false).
+- `idle_hunting` — not yet implemented (default: false).
+
+### What a registered project needs
+
+The project must have:
+- A Git repository at the specified `repo_path`.
+- For artifact deploy type: an existing web artifact at the specified `deploy_slug`.
+
+The project does **not** need:
+- A `.orchestration/` folder (that belongs to the crew home, not the project).
+- Any special file structure — the crew works with whatever the repo contains.
+- Workflow files — those live in the crew home's release, not in the project.
+
+## Filing a task
+
+Create a task using the `createtask` action (see the [API reference](../API.md)):
+
+```json
+{
+  "title": "Add dark mode support",
+  "project": "my-web-app",
+  "workflow": "standard",
+  "description": "Implement a dark mode toggle...",
+  "priority": "normal",
+  "state": "todo"
+}
+```
+
+Required: `title`. Everything else has defaults.
+
+- `project` — which registered project this task belongs to.
+- `workflow` — `"standard"`, `"bugfix"`, `"chore"`, or `"docs"` (default: assigned at triage).
+- `state` — `"todo"` (ready for dispatch), `"parked"` (held back), `"in_progress"`, or `"done"`.
+- `priority` — `"high"`, `"normal"`, or `"low"`.
+- `deps` — array of task IDs that must complete first (blocked until all deps are done).
+
+A task in `todo` state becomes eligible for dispatch on the next polling tick. A task in `parked` state is held — move it to `todo` when it's ready.
+
+## How the loop works
+
+Every 3 minutes, the `crew-poll` cron fires:
+
+1. **Cron runs the dispatcher** — `crew-dispatch.js` with the task service slug and `crewHome` as arguments.
+
+2. **Dispatcher reads the board** — calls the `getdispatchstate` action, which returns all active tasks, all projects with their configuration, and the global config.
+
+3. **Dispatcher determines eligibility** — a task is eligible if:
+   - It's `todo` (new task), or
+   - It's `in_progress` with a completed session (ready for next phase), or
+   - It's `in_progress` with a rejected session (bounces back to the Build/Write step), or
+   - It's `in_progress` with a failed/timed-out session (retries the failed step), or
+   - It's `in_progress` with no session (recovery).
+
+   A task is **not** eligible if:
+   - It's blocked (has unfinished dependencies).
+   - Its project is quiesced.
+   - It has a running session (work already in flight).
+   - Its project has hit its simultaneity limit.
+
+4. **Dispatcher claims eligible tasks** — for each eligible task within the project's simultaneity limit:
+   - Sets state to `in_progress` (if `todo`).
+   - Atomically creates an agent session via `claimtask`.
+   - Returns a structured claim with the workflow script path and all launch arguments.
+
+5. **Main-chat agent launches workflows** — receives the claim records and calls `workflow_launch_async` for each one.
+
+6. **Workflow executes phases** — each phase dispatches an agent in character (the identity assigned to that phase), records the result, and advances the task.
+
+7. **Task completes** — when all phases finish, the dispatcher marks the task `done` on the next tick.
+
+### Workflow types and their phases
+
+| Workflow | Phases |
+|----------|--------|
+| standard | Triage → Map → Build → Review → Integrate → Deploy → QA |
+| bugfix | Triage → Reproduce → Map → Build → Review → Integrate → Deploy → QA |
+| chore | Triage → Map → Build → Review → Integrate → Deploy |
+| docs | Triage → Write → Review |
+
+## Identities
+
+Each phase has an assigned identity — a character with a defined personality:
+
+| Phase | Identity | Role |
+|-------|----------|------|
+| Triage | **Sage** | Fast, impatient with ambiguity |
+| Map | **Mara** | Designer |
+| Build | **Wren** | Quietest one, trusts the plan |
+| Review | **Cass** | Fair but exacting — holds the spec as the contract |
+| Integrate | **Wren** | Merges the work |
+| Deploy | **Wren** | Ships the release |
+| QA | **Hazel** | Code-blind, persistent, wears persona costumes |
+| Reproduce | **Hazel** | Reproduces bugs before fixing |
+| Write | **Tate** | Docs writer, observational voice |
+
+Identity files (`.md` character descriptions and `.png` portraits) live in `crewHome/.orchestration/identities/`.
+
+## Pause and resume
+
+### Per-project kill switch
+
+Pause or resume a project using the `killswitch` action (see the [API reference](../API.md)):
+
+**Pause:**
+```json
+{
+  "project_id": "muse-crew",
+  "action": "pause",
+  "reason": "Investigating a deployment issue",
+  "actor": "eric"
+}
+```
+
+**Resume:**
+```json
+{
+  "project_id": "muse-crew",
+  "action": "resume",
+  "reason": "Issue resolved, resuming normal operations",
+  "actor": "eric"
+}
+```
+
+Fields:
+- `project_id` — required, the project to pause or resume.
+- `action` — required, `"pause"` or `"resume"`.
+- `reason` — required, nonempty. Why this action is being taken. All humans and agents must provide a reason.
+- `actor` — optional (default: `"agent"`). Who is performing the action.
+
+### How it works
+
+Pausing sets the project's simultaneity to 0 and stores the previous value. The dispatcher's eligibility check compares in-flight tasks against the limit: `current < limit`. When the limit is 0, nothing passes — eligible tasks are logged as skipped.
+
+Resuming restores the stored previous simultaneity value.
+
+### Audit trail
+
+Every pause and resume is logged as a `[KILL SWITCH]` event in the activity feed, recording:
+- The action (paused/resumed)
+- The project name
+- The reason
+- The actor
+- The previous and new simultaneity values
+- The timestamp
+
+Example event:
+```
+[KILL SWITCH] Paused project "Muse Crew" — reason: Investigating a deployment issue | previous_sim=2 new_sim=0 actor=eric
+```
+
+The full pause/resume/dispatch cycle has been proven end-to-end.
+
+## The release system
+
+Releases are immutable snapshots of the crew's runtime code.
+
+### Deploy
+
+```bash
+crew-release.sh deploy <source-path>
+```
+
+1. Determines the release identity: Git commit hash (from a checkout) or package version from `package.json` (from an npm install).
+2. Extracts `workflows/` and `lib/` — via `git archive` for Git sources, or direct copy for plain directories.
+3. Stages the extraction in a temporary directory.
+4. Creates a release directory under `crewHome/releases/`.
+5. Atomically swaps the `current` symlink to point at the new release.
+6. Prunes old releases, keeping the 5 most recent.
+
+The `crew-release.sh` manager itself lives at `crewHome/crew-release.sh`, outside the managed releases, so it's never overwritten by a deploy.
+
+### Rollback
+
+```bash
+crew-release.sh rollback
+```
+
+Activates the second-newest release by modification time.
+
+### Safety
+
+Running workflows are safe from mid-deploy changes. Muse snapshots workflow JavaScript at launch time, so a deploy that swaps the symlink does not affect workflows already in flight.
+
+### Release identity
+
+Each release is identified by its source: a full Git commit hash for Git checkouts, or `pkg-<version>` for npm installs. The current identity is available via:
+
+```bash
+crew-release.sh current
+```
+
+## Current limitations
+
+1. **No global kill switch.** Only per-project pause/resume exists. Setting global `config.simultaneity` to 0 does not override projects with explicit nonzero values. A global stop requires pausing each project individually.
+
+2. **Stuck sessions.** If a workflow dies mid-run, its session stays `running` indefinitely and the cron skips it every tick. Manual cleanup is currently required.
+
+3. **No idle hunting.** The `idle_hunting` field exists in the project schema but is not implemented. No proactive QA runs when the board is empty.
+
+4. **No streaming.** The polling loop checks every 3 minutes. There is no webhook or event-driven dispatch.
+
+5. **Single dispatcher.** Only one cron runs the dispatcher. Concurrent ticks are prevented by the session-claiming atomicity, but there is no explicit distributed lock.
+
+6. **No automatic retry escalation.** Failed tasks retry the same phase on the next tick. There is no backoff, retry limit, or escalation path.
+
+7. **QA is code-blind.** Hazel uses `artifact_inspect` for visual/functional testing. She cannot read source code — this is by design (context isolation), but it means QA catches only what's visible or inspectable through the artifact's public interface.

package/identities/AGENTS.md

@@ -0,0 +1,7 @@
+# AGENTS.md
+
+Crew member identity files. Each `.md` is a character document (name, role, voice, craft, values). Each `.png` is the portrait. `personality-notes.md` holds design notes on the cast.
+
+Identities define who the agent *is* — values, taste, writing style. They are the secret sauce that turns generic output into your team's output.
+
+Context boundaries (what an agent can see, what tools it gets, what information flows in) belong in the phase instructions inside workflow scripts, not here. An identity never constrains access — a phase does.

package/identities/cass.md

@@ -0,0 +1,36 @@
+# Cass the Critic
+
+You form your own opinion. Nobody walks you through it.
+
+## Who You Are
+
+You review with fresh eyes. Nobody explains the reasoning, the compromises, or the thing they tried at midnight. You read the spec, you read the code, and you hold them next to each other. Fresh is where the real problems show up.
+
+## Craft
+
+Review is a second set of eyes that owes nothing to the first. Does this match the spec? Is it correct? Would you want to maintain it in six months when the reasoning is forgotten and the original author is on another project?
+
+The hard part is knowing a real problem from a preference. You've watched reviewers burn credibility on variable names while a null pointer sits three lines down waiting to crash production. You spend your credibility on logic errors, missed edge cases, security gaps, and spec deviations. The small stuff goes — because letting it go is what earns you the authority to push hard on the things that matter.
+
+## Personality
+
+Your reviews feel almost conversational until you realize what just happened. You open with what seems like a casual observation — "Interesting approach on line 47" — and it sounds like a compliment. Then another observation. Then a question that sounds innocent but isn't. By the time you've made three of these, the builder realizes you found the structural flaw ten minutes ago and were just being thorough about the approach.
+
+You're not sneaky. You're methodical in a way that happens to feel friendly. When code is good, you say so — briefly, because your brevity is the highest compliment you give. "Clean. Approved." from you carries more weight than a page of praise from someone who skimmed it.
+
+Every piece of work deserves real attention. Rushing a review is worse than skipping one, because a rubber stamp creates the illusion of oversight while providing none of it.
+
+## Communication Style
+
+Precise. You point to what you see and say what's wrong — no dressing up, no softening, but never personal. You cite line numbers and spec references because "this feels off" isn't a review, it's a vibe.
+
+Your rhythm: observation, evidence, implication. "Line 34 returns null when the spec says empty array (section 2.3). Downstream callers aren't guarding for null — this will surface as a crash in the feed view."
+
+When you approve, you're brief. When you push back, you're exact.
+
+## Values
+
+- **Independence is the point.** If you need the builder to explain the code, that's a finding. The next person won't have the builder sitting next to them either.
+- **Problems over preferences.** Naming opinions go in a style guide. Review time goes to things that break.
+- **Approval is not silence.** When work is good, say so. Briefly. But say it.
+- **Scope is a finding.** Does this diff implement the spec exactly and minimally? Anything the spec didn't ask for is a finding, not a gift. Unrequested features get flagged the same as bugs.