feat: JSONata moderator engine (Phase 2 of #294)

- evaluateModerator(rules, context) with JSONata expression evaluation
- Fallback (when: null), conditional branching, no-match → __end__
- Full develop workflow moderator ported to JSONata
- 31 tests passing

Closes #295
小橘 <xiaoju@shazhou.work>

.cards/_index.md

@@ -0,0 +1,35 @@
+# Uncaged Workflow Architecture
+
+Uncaged Workflow is a monorepo implementing a workflow engine that executes single-file ESM bundles. Each workflow is identified by an XXH64 hash (Crockford Base32); execution state is stored in a content-addressable store (CAS) as immutable Merkle nodes. Agents are pluggable — the same workflow definition runs with Cursor, Hermes, a raw LLM, or a ReAct loop.
+
+## Core Concepts
+
+| Card | Description |
+|------|-------------|
+| [Bundle](./bundle.md) | A single-file `.esm.js` module with an XXH64 hash identity, stored in `~/.uncaged/workflow/bundles/` |
+| [Thread](./thread.md) | A single execution instance of a workflow, identified by a ULID, with CAS-linked state nodes |
+| [CAS](./cas.md) | The content-addressable store that holds all immutable blobs — content, start nodes, and state nodes |
+| [Registry](./registry.md) | `workflow.yaml` — maps workflow names to current and historical bundle hashes |
+
+## Execution
+
+| Card | Description |
+|------|-------------|
+| [Engine](./engine.md) | The three-phase loop that drives the workflow `AsyncGenerator` and writes each step to CAS |
+| [Role](./role.md) | A named actor defined as pure data (`RoleDefinition`) — description, system prompt, and Zod schema |
+| [Agent Binding](./agent-binding.md) | The runtime binding that connects a role to a concrete agent implementation via `AdapterFn` |
+| [Reactor](./reactor.md) | The ReAct loop abstraction for LLM function-calling, used by both the extract phase and agent adapters |
+
+## Tooling
+
+| Card | Description |
+|------|-------------|
+| [CLI](./cli.md) | The `uncaged-workflow` command-line tool for managing workflows, threads, and CAS |
+| [Dashboard](./dashboard.md) | A private React app for inspecting threads, workflows, and live execution via the gateway |
+| [Package Map](./package-map.md) | All packages in the monorepo with their layer positions and dependency graph |
+
+## Authoring
+
+| Card | Description |
+|------|-------------|
+| [Workflow Templates](./workflow-templates.md) | The `solve-issue` and `develop` reference templates and how to author custom workflows |

.cards/agent-binding.md

@@ -0,0 +1,104 @@
+# Agent Binding
+
+> The runtime connection between a workflow's role definitions and a concrete agent implementation, expressed as an `AdapterBinding` passed to `createWorkflow`.
+
+## Overview
+
+Agent binding is how a workflow author specifies which agent executes each role. Roles are pure data (see [Role](./role.md)); the binding supplies the execution strategy. The same `WorkflowDefinition` can be run with different agents by changing the `AdapterBinding` — useful for testing, cost optimization, or environment-specific deployment.
+
+An `AdapterFn` receives a role's `systemPrompt` and Zod `schema`, and returns a `RoleFn` — a function that takes `ThreadContext` and `WorkflowRuntime` and returns `RoleResult<T>`. The adapter is responsible for producing typed structured output directly; there is no separate extract phase when using adapters.
+
+## Key Types
+
+```typescript
+// The core adapter interface
+type AdapterFn = <T>(prompt: string, schema: z.ZodType<T>) => RoleFn<T>;
+
+type RoleFn<T> = (ctx: ThreadContext, runtime: WorkflowRuntime) => Promise<RoleResult<T>>;
+
+type RoleResult<T> = { meta: T; childThread: string | null };
+
+// The binding passed to createWorkflow
+type AdapterBinding = {
+  adapter: AdapterFn;
+  overrides: Partial<Record<string, AdapterFn>> | null;
+};
+```
+
+`overrides` allows per-role adapters — for example, using Cursor for one role and an LLM for another within the same workflow.
+
+## AgentFn (Legacy / Low-level)
+
+Below the adapter layer, the original `AgentFn` type still exists for agent implementations that produce raw strings rather than structured output:
+
+```typescript
+type AgentFn<Opt = void> = Opt extends void
+  ? (ctx: ThreadContext) => Promise<string>
+  : (ctx: ThreadContext, options: Opt) => Promise<string>;
+```
+
+The `createAgentAdapter` utility in `@uncaged/workflow-util-agent` wraps an `AgentFn` into an `AdapterFn` by composing it with extraction logic.
+
+## Concrete Implementations
+
+| Package | Export | Agent |
+|---------|--------|-------|
+| `@uncaged/workflow-agent-cursor` | `createCursorAgent` | Runs `cursor` CLI non-interactively in a workspace directory |
+| `@uncaged/workflow-agent-hermes` | `createHermesAgent` | Runs `hermes chat` with `--yolo --quiet` (Nerve-style argv) |
+| `@uncaged/workflow-agent-llm` | `createLlmAdapter` | Direct LLM completion via the OpenAI-compatible chat endpoint |
+| `@uncaged/workflow-agent-react` | `createReactAdapter` | ReAct loop with file and shell tools (read, write, patch, exec) |
+
+All four return an `AdapterFn` suitable for use in `AdapterBinding.adapter`.
+
+## workflow-util-agent
+
+`@uncaged/workflow-util-agent` provides two helpers shared by adapter implementations:
+
+- **`buildThreadInput(ctx)`** — constructs the user-message string from thread context (task, previous steps, tool hints). Used by all CLI-based agents.
+- **`spawnCli(command, args, opts)`** — spawns an external process (e.g., `cursor`, `hermes`) and captures stdout, with optional timeout.
+- **`createAgentAdapter(agentFn, optionsFn)`** — wraps an `AgentFn<Opt>` into an `AdapterFn`, handling the options extraction step.
+
+## Cursor Agent
+
+`createCursorAgent(config)` invokes the `cursor` CLI binary:
+
+```
+cursor -p <fullPrompt> --model <model> --workspace <path> --output-format text --trust --force
+```
+
+The workspace path is taken from `config.workspace` or extracted from the thread context via `runtime.extract`.
+
+## Hermes Agent
+
+`createHermesAgent(config)` invokes `hermes chat`:
+
+```
+hermes chat -q <fullPrompt> --yolo --max-turns 90 --quiet [--model <model>]
+```
+
+## LLM Adapter
+
+`createLlmAdapter(provider)` calls the OpenAI-compatible chat completions endpoint directly. It builds a two-message conversation (system + user) from the role's `systemPrompt` and `buildThreadInput` output, then extracts structured output from the response.
+
+## React Adapter
+
+`createReactAdapter(config)` creates a ReAct loop agent with four default tools: `read_file`, `write_file`, `patch_file`, and `shell_exec`. The loop continues until the agent calls the structured extraction tool or until `maxRounds` is exceeded.
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-protocol` | `src/types.ts` | `AdapterFn`, `AdapterBinding`, `RoleFn`, `RoleResult`, `AgentFn` |
+| `@uncaged/workflow-runtime` | `src/create-workflow.ts` | `createWorkflow` — dispatches `adapterForRole` each iteration |
+| `@uncaged/workflow-util-agent` | `src/build-agent-prompt.ts` | `buildThreadInput`, `buildAgentPrompt` |
+| `@uncaged/workflow-util-agent` | `src/spawn-cli.ts` | `spawnCli` — subprocess runner with timeout |
+| `@uncaged/workflow-util-agent` | `src/create-agent-adapter.ts` | `createAgentAdapter` — wraps `AgentFn` into `AdapterFn` |
+| `@uncaged/workflow-agent-cursor` | `src/index.ts` | `createCursorAgent` |
+| `@uncaged/workflow-agent-hermes` | `src/index.ts` | `createHermesAgent` |
+| `@uncaged/workflow-agent-llm` | `src/create-llm-adapter.ts` | `createLlmAdapter` |
+| `@uncaged/workflow-agent-react` | `src/create-react-adapter.ts` | `createReactAdapter` |
+
+## See Also
+
+- [Role](./role.md) — the pure data that the binding executes
+- [Engine](./engine.md) — the loop that invokes the bound adapter each step

.cards/bundle.md

@@ -0,0 +1,83 @@
+# Bundle
+
+> A self-contained single-file ESM module (`.esm.js`) that implements one workflow, identified by its XXH64 hash encoded as 13-char Crockford Base32.
+
+## Overview
+
+A bundle is the physical unit of workflow distribution. Workflow authors build their TypeScript source into a single ESM file using `bun build` with `@uncaged/*` packages as externals. The resulting `.esm.js` is the artifact that gets registered and executed.
+
+Every bundle is immutable and content-addressed: its identity is the XXH64 hash of its bytes, encoded as 13 characters of Crockford Base32 (e.g., `3TNKQRJ7BM4XH`). Registering a bundle with a new version simply adds a new hash entry; old hashes stay in the registry history and remain valid.
+
+Bundles are stored on disk at `~/.uncaged/workflow/bundles/<hash>/` after registration. The `cas/` and `threads.json` for that bundle's execution state live under the same directory.
+
+## Exports
+
+Every valid bundle must export exactly two named exports — no default export is permitted:
+
+| Export | Type | Description |
+|--------|------|-------------|
+| `run` | `WorkflowFn` | The `AsyncGenerator` that drives the execution loop |
+| `descriptor` | `WorkflowDescriptor` | Serializable metadata: description, roles, and routing graph |
+
+```typescript
+// Minimal bundle shape
+export const run: WorkflowFn = createWorkflow(def, binding);
+export const descriptor: WorkflowDescriptor = buildDescriptor(def);
+```
+
+The validator in `@uncaged/workflow-register` enforces this contract before a bundle can be registered — see `extractBundleExports`.
+
+## Hash Algorithm
+
+The bundle hash is computed with **XXH64** (seed 0) over the raw bytes of the `.esm.js` file, then encoded as 13-char Crockford Base32 using `encodeUint64AsCrockford`:
+
+```typescript
+// packages/workflow-cas/src/hash.ts
+export function hashWorkflowBundleBytes(data: Uint8Array): string {
+  const buf = Buffer.from(data.buffer, data.byteOffset, data.byteLength);
+  const digest = XXH.h64(0).update(buf).digest();
+  return encodeUint64AsCrockford(digestToUint64(digest));
+}
+```
+
+The same algorithm hashes CAS blob content (`hashString`), so all IDs in the system are consistent Crockford Base32 strings.
+
+## Build Process
+
+Bundles are not distributed from the monorepo directly. The typical flow is:
+
+1. Create a separate workspace (e.g., `my-workflows/`) with `@uncaged/workflow-runtime` as a dependency.
+2. Write a TypeScript workflow module that imports `createWorkflow` from `@uncaged/workflow-runtime`.
+3. Run `bun build --entrypoints src/my-workflow.ts --outfile dist/my-workflow.esm.js --format esm --external '@uncaged/*'`.
+4. Register with `uncaged-workflow workflow add <name> dist/my-workflow.esm.js`.
+
+## Storage Layout
+
+```
+~/.uncaged/workflow/
+  workflow.yaml                     # registry (name → hash mapping)
+  bundles/
+    <hash>/
+      threads.json                  # active thread index
+      history/
+        YYYY-MM-DD.jsonl            # completed thread records
+  cas/
+    <hash>.txt                      # CAS blobs (all bundles share one global CAS)
+```
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-cas` | `src/hash.ts` | `hashWorkflowBundleBytes` and `hashString` — XXH64 + Crockford encoding |
+| `@uncaged/workflow-register` | `src/bundle/extract-bundle-exports.ts` | Loads a `.esm.js` bundle and validates `run` + `descriptor` |
+| `@uncaged/workflow-register` | `src/bundle/bundle-validator.ts` | Schema validation of bundle exports |
+| `@uncaged/workflow-runtime` | `src/create-workflow.ts` | `createWorkflow` — the primary bundle authoring function |
+| `@uncaged/workflow-util` | `src/base32.ts` | `encodeUint64AsCrockford` — Crockford Base32 encoding |
+| `@uncaged/workflow-util` | `src/storage-root.ts` | `getDefaultWorkflowStorageRoot` → `~/.uncaged/workflow` |
+
+## See Also
+
+- [Registry](./registry.md) — how bundles are registered and named in `workflow.yaml`
+- [Thread](./thread.md) — how a bundle's `run` export is executed as a thread
+- [Engine](./engine.md) — the executor that drives the bundle's `AsyncGenerator`

.cards/cas.md

@@ -0,0 +1,111 @@
+# CAS (Content-Addressable Storage)
+
+> An append-only store where every blob is identified by its XXH64 hash, used to persist all workflow thread state as immutable Merkle nodes.
+
+## Overview
+
+CAS is the persistence substrate for the entire workflow engine. Rather than mutating a database row, every piece of state — agent output, role metadata, thread start parameters — is serialized as a YAML blob and stored under its hash. Because content determines identity, the same content always maps to the same hash, and writes are idempotent.
+
+The `CasStore` interface is intentionally simple: `put`, `get`, `delete`, `list`. The default filesystem implementation stores each blob as `<hash>.txt` under `~/.uncaged/workflow/cas/`. Writes use an atomic rename-from-tmp pattern to prevent partial writes.
+
+## Hash Algorithm
+
+All hashes in the system are **XXH64** (seed 0) over UTF-8 content, encoded as 13-char Crockford Base32. This applies to both CAS blob hashes and bundle file hashes. The encoding function `encodeUint64AsCrockford` lives in `@uncaged/workflow-util`.
+
+## Node Types
+
+The CAS holds three types of YAML nodes, all sharing the `{ type, payload, refs }` envelope:
+
+### `content` node
+Stores the raw text output of an agent or the initial prompt. `refs` lists any artifact hashes the content references.
+
+```yaml
+type: content
+payload: "The implementation is complete. Changed files: src/foo.ts"
+refs:
+  - 3TNKQRJ7BM4XH   # optional artifact refs
+```
+
+### `start` node
+Written once when a thread begins. Anchors the thread to a specific workflow name, bundle hash, and depth level.
+
+```yaml
+type: start
+payload:
+  name: solve-issue
+  hash: 3TNKQRJ7BM4XH
+  depth: 0
+  parentState: null
+refs:
+  - <promptHash>
+```
+
+### `state` node
+Written once per completed role step. Points back to the `start` node, the role's content node, and maintains an ancestor skip-list for traversal.
+
+```yaml
+type: state
+payload:
+  role: coder
+  meta: { status: "done", completedPhase: "..." }
+  start: <startHash>
+  content: <contentHash>
+  ancestors: [<prev_state>, ...]
+  compact: null
+  timestamp: 1716000000000
+  childThread: null
+refs:
+  - <contentHash>
+  - <startHash>
+  - <ancestor hashes>
+```
+
+## Merkle Structure
+
+The `ancestors` array in each `StateNode` implements a **skip-list** capped at 11 entries (1 direct parent + up to 10 skip-list ancestors). This allows `O(log n)` traversal of the chain without loading every node, while keeping each blob self-contained.
+
+```mermaid
+graph LR
+    S[StartNode] --> C1[content₁]
+    N1[StateNode₁] --> S
+    N1 --> C1
+    N2[StateNode₂] --> N1
+    N2 --> S
+    N2 --> C2[content₂]
+    END[StateNode __end__] --> N2
+    END --> S
+```
+
+## CasStore Interface
+
+```typescript
+type CasStore = {
+  put(content: string): Promise<string>;    // returns hash
+  get(hash: string): Promise<string | null>;
+  delete(hash: string): Promise<void>;
+  list(): Promise<string[]>;
+};
+```
+
+`put` normalizes raw strings into `content` Merkle nodes before hashing; pre-serialized RFC v3 nodes pass through unchanged.
+
+## Garbage Collection
+
+`cas gc` performs a mark-and-sweep over all CAS blobs. It seeds the reachable set from `head` and `start` hashes in every `threads.json` and `history/*.jsonl`, then traverses `refs` edges transitively. Unreachable blobs are deleted. The result reports `scannedThreads`, `activeRefs`, and `deletedEntries`.
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-protocol` | `src/types.ts` | `CasStore` interface definition |
+| `@uncaged/workflow-protocol` | `src/cas-types.ts` | `StartNode`, `StateNode`, `ContentMerkleNode` types |
+| `@uncaged/workflow-cas` | `src/cas.ts` | `createCasStore` — filesystem implementation |
+| `@uncaged/workflow-cas` | `src/hash.ts` | `hashString`, `hashWorkflowBundleBytes` — XXH64 + Crockford |
+| `@uncaged/workflow-cas` | `src/nodes.ts` | `putStartNode`, `putStateNode`, `putContentNodeWithRefs`, `parseCasThreadNode` |
+| `@uncaged/workflow-cas` | `src/merkle.ts` | `parseMerkleNode`, `serializeMerkleNode`, `getContentMerklePayload` |
+| `@uncaged/workflow-cas` | `src/reachable.ts` | Reachability traversal for GC |
+| `@uncaged/workflow-execute` | `src/engine/gc.ts` | GC orchestration |
+
+## See Also
+
+- [Thread](./thread.md) — how thread execution state maps to CAS nodes

.cards/cli.md

@@ -0,0 +1,107 @@
+# CLI
+
+> `uncaged-workflow` — the command-line tool for registering bundles, running threads, inspecting CAS, and connecting to the gateway.
+
+## Overview
+
+The CLI (`@uncaged/cli-workflow`) is the primary human interface to the workflow engine. It is a multi-level command dispatcher: top-level command groups (`workflow`, `thread`, `cas`, `init`, `setup`) each have a set of subcommands. Two shortcuts (`run`, `live`) alias frequently-used subcommands.
+
+The storage root defaults to `~/.uncaged/workflow` and can be overridden with `WORKFLOW_STORAGE_ROOT` or `UNCAGED_WORKFLOW_STORAGE_ROOT` environment variables.
+
+## Command Reference
+
+### Workflow Registry (`workflow`)
+
+| Subcommand | Args | Description |
+|-----------|------|-------------|
+| `workflow add` | `<name> <file.esm.js> [--types <path>]` | Register a workflow bundle in the registry |
+| `workflow list` | | List all registered workflows |
+| `workflow show` | `<name>` | Show bundle hash, timestamp, and descriptor |
+| `workflow rm` | `<name>` | Remove a workflow from the registry |
+| `workflow history` | `<name>` | Show version history for a workflow |
+| `workflow rollback` | `<name> [hash]` | Roll back to a previous version |
+
+### Thread Execution (`thread`)
+
+| Subcommand | Args | Description |
+|-----------|------|-------------|
+| `thread run` | `<name> [--prompt <text>]` | Start a new thread for a workflow; prints thread ID |
+| `thread list` | `[name]` | List threads, optionally filtered by workflow name |
+| `thread show` | `<id>` | Show thread steps and state from CAS |
+| `thread rm` | `<id>` | Remove a thread (from index and history) |
+| `thread fork` | `<thread-id> [--from-role <role>]` | Fork from an existing thread |
+| `thread ps` | | List running (active) threads |
+| `thread kill` | `<thread-id>` | Send kill signal to a running thread |
+| `thread live` | `<thread-id> \| --latest [--debug] [--role <name>]` | Attach and stream output live |
+| `thread pause` | `<thread-id>` | Pause a running thread |
+| `thread resume` | `<thread-id>` | Resume a paused thread |
+
+### CAS Inspection (`cas`)
+
+| Subcommand | Args | Description |
+|-----------|------|-------------|
+| `cas get` | `<hash>` | Print a CAS blob by hash |
+| `cas put` | `<content>` | Store content in CAS, print hash |
+| `cas list` | | List all hashes in CAS |
+| `cas rm` | `<hash>` | Remove a CAS entry |
+| `cas gc` | | Garbage-collect unreferenced entries |
+
+### Other Commands
+
+| Command | Args | Description |
+|---------|------|-------------|
+| `run <name> [...]` | | Shortcut for `thread run` |
+| `live <id> [...]` | | Shortcut for `thread live` |
+| `init` | | Scaffold a workflow workspace |
+| `setup` | | Configure LLM providers in `workflow.yaml` |
+| `connect [--name NAME] [--gateway URL]` | | Connect to gateway via WebSocket |
+| `skill [topic]` | | Print agent-consumable docs (`cli`, `develop`, `author`) |
+
+## Common Usage Examples
+
+```bash
+# Register a bundle
+uncaged-workflow workflow add solve-issue dist/solve-issue.esm.js
+
+# Run a workflow (prints thread ID)
+uncaged-workflow run solve-issue --prompt "Fix the login bug in auth.ts"
+
+# Watch live output
+uncaged-workflow live <thread-id>
+
+# Inspect a CAS blob
+uncaged-workflow cas get 3TNKQRJ7BM4XH
+
+# Show all running threads
+uncaged-workflow thread ps
+
+# Garbage-collect
+uncaged-workflow cas gc
+
+# Roll back to previous version
+uncaged-workflow workflow rollback solve-issue
+```
+
+## Environment Variables
+
+| Variable | Description |
+|----------|-------------|
+| `WORKFLOW_STORAGE_ROOT` | Override storage directory (default: `~/.uncaged/workflow`) |
+| `UNCAGED_WORKFLOW_STORAGE_ROOT` | Internal override; takes priority over `WORKFLOW_STORAGE_ROOT` |
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/cli-workflow` | `src/cli-dispatch.ts` | Top-level command router (`COMMAND_TABLE`) |
+| `@uncaged/cli-workflow` | `src/cli-usage.ts` | Usage text formatting |
+| `@uncaged/cli-workflow` | `src/commands/workflow/dispatch.ts` | `WORKFLOW_SUBCOMMAND_TABLE` |
+| `@uncaged/cli-workflow` | `src/commands/thread/dispatch.ts` | `THREAD_SUBCOMMAND_TABLE` |
+| `@uncaged/cli-workflow` | `src/commands/cas/dispatch.ts` | `CAS_SUBCOMMAND_TABLE` |
+| `@uncaged/cli-workflow` | `src/cli.ts` | CLI entry point |
+
+## See Also
+
+- [Bundle](./bundle.md) — what `workflow add` registers
+- [Thread](./thread.md) — what `thread run` creates
+- [Registry](./registry.md) — the `workflow.yaml` that `workflow` commands manage

.cards/dashboard.md

@@ -0,0 +1,74 @@
+# Dashboard
+
+> A private React single-page application for browsing workflows, inspecting thread execution records, and triggering runs via a connected gateway.
+
+## Overview
+
+The dashboard (`workflow-dashboard`) is a read-mostly web UI that surfaces thread history and workflow metadata. It is a private package (not published to npm) and is deployed separately from the CLI. It communicates with one or more remote workflow engine instances through the `workflow-gateway` WebSocket gateway, which proxies API calls back to each connected CLI client.
+
+The dashboard is not required to use the workflow engine — it is an optional observability layer on top of the same data that the CLI exposes.
+
+## Tech Stack
+
+| Concern | Choice |
+|---------|--------|
+| Framework | React (functional components, hooks) |
+| Build | Vite |
+| Styling | CSS variables via Tailwind-compatible utility classes |
+| Charts/graphs | ReactFlow (workflow graph visualization) |
+| HTTP | Native `fetch` with Bearer token auth |
+| Transport | REST over HTTP (proxied through the gateway) |
+
+## Data Sources
+
+The dashboard consumes four REST endpoints per connected client (proxied by the gateway):
+
+| Endpoint | Data |
+|----------|------|
+| `GET /workflows` | List of registered workflows with current hash and timestamp |
+| `GET /workflows/:name` | Full workflow detail including `WorkflowDescriptor` and version history |
+| `GET /threads` | All threads (active + completed) with summary fields |
+| `GET /threads/:id` | Thread records: `ThreadStartRecord`, `RoleRecord[]`, `WorkflowResultRecord` |
+
+The gateway multiplexes multiple CLI clients; the sidebar allows switching between them.
+
+## Views
+
+| View | Description |
+|------|-------------|
+| **Workflows** | Lists all registered workflows; clicking shows hash, descriptor, role graph, and version history |
+| **Threads** | Lists all threads; clicking shows the full step-by-step execution record with role metadata |
+| **Run dialog** | Form to start a new thread by picking a workflow and entering a prompt |
+
+### Workflow Graph
+
+Each workflow's `WorkflowDescriptor.graph` is rendered as an interactive ReactFlow diagram. Nodes represent roles (plus `__start__` and `__end__` terminals); edges represent moderator transitions labeled with condition names.
+
+## Authentication
+
+A Bearer token (stored in `localStorage` under `workflow-api-key`) is sent with every API request. The login page prompts for this key on first load. The gateway validates the token before proxying requests to connected clients.
+
+## Gateway Connection
+
+`uncaged-workflow connect [--name NAME] [--gateway URL]` registers the local workflow engine as a named client with the gateway over a WebSocket. The gateway then forwards REST API calls from the dashboard to the connected CLI process. The dashboard calls `GET /api/gateway/endpoints` to discover connected clients.
+
+## Private App Status
+
+`workflow-dashboard` has `"private": true` in its `package.json` and is excluded from the changeset versioning pipeline. It is developed alongside the engine packages but distributed separately (e.g., as a static build hosted alongside the gateway server).
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `workflow-dashboard` | `src/app.tsx` | Root component — routing, auth state, view switching |
+| `workflow-dashboard` | `src/api.ts` | All API functions + endpoint types (`ThreadRecord`, `WorkflowDetail`, etc.) |
+| `workflow-dashboard` | `src/components/thread-detail.tsx` | Thread step viewer |
+| `workflow-dashboard` | `src/components/workflow-graph/workflow-graph.tsx` | ReactFlow graph of workflow roles and transitions |
+| `workflow-dashboard` | `src/components/sidebar.tsx` | Client selector and view navigation |
+| `@uncaged/workflow-gateway` | `src/index.ts` | Gateway server entry point |
+| `@uncaged/workflow-gateway` | `src/ws-protocol.ts` | WebSocket message protocol between CLI and gateway |
+
+## See Also
+
+- [Thread](./thread.md) — the execution records the dashboard displays
+- [Engine](./engine.md) — the process that produces those records

.cards/engine.md

@@ -0,0 +1,110 @@
+# Engine
+
+> The execution loop that drives a workflow bundle's `AsyncGenerator`, persisting each yielded `RoleOutput` as a CAS `StateNode` and managing thread lifecycle.
+
+## Overview
+
+The engine (`executeThread`) takes a `WorkflowFn` and runs it to completion. It is responsible for three concerns: persisting each role output to CAS, updating the active-thread index after every step, and terminating the thread cleanly when the generator finishes, is aborted, or is killed by the supervisor.
+
+The engine does not interact with LLMs directly — that responsibility belongs to the workflow bundle's `run` function and its bound agent adapters. The engine only observes `RoleOutput` values yielded by the generator.
+
+## Execution Flow
+
+```mermaid
+flowchart TD
+    A[executeThread] --> B[putStartNode → CAS]
+    B --> C[publishHead → threads.json]
+    C --> D{generator.next}
+    D -- done --> E[finalizeThread]
+    D -- yield RoleOutput --> F[appendStateForStep → CAS]
+    F --> G[publishHead → threads.json]
+    G --> H{supervisorInterval?}
+    H -- kill --> E
+    H -- continue --> I{awaitAfterEachYield}
+    I --> D
+    D -- AbortSignal --> J[finalizeAbortedThread]
+    E --> K[removeThreadEntry]
+    K --> L[appendThreadHistoryEntry]
+```
+
+## Role Loop (inside the bundle's `createWorkflow`)
+
+The `WorkflowFn` produced by `createWorkflow` runs its own loop — one iteration per role step:
+
+1. **Moderator**: calls `pickNext(ctx)` (derived from the `ModeratorTable`) → returns a role name or `END`.
+2. **Adapter**: calls the bound `AdapterFn` with the role's `systemPrompt` and Zod schema → returns `RoleFn` → executes → returns `RoleResult<T>`.
+3. **Persist**: calls `putContentNodeWithRefs` to store the role output in CAS, constructs a `RoleStep`, and `yield`s a `RoleOutput` to the engine.
+
+```mermaid
+sequenceDiagram
+    participant E as Engine
+    participant W as WorkflowFn (bundle)
+    participant M as Moderator
+    participant A as AdapterFn
+    participant C as CAS
+
+    E->>W: generator.next()
+    W->>M: pickNext(ctx) → roleName
+    W->>A: adapter(systemPrompt, schema)(ctx, runtime)
+    A-->>W: RoleResult { meta, childThread }
+    W->>C: putContentNodeWithRefs(JSON.stringify(meta))
+    W-->>E: yield RoleOutput
+    E->>C: putStateNode(StateNodePayload)
+    E->>E: publishHead(threads.json)
+```
+
+## Key Types
+
+```typescript
+// Engine input
+type ExecuteThreadOptions = {
+  depth: number;
+  parentStateHash: string | null;
+  signal: AbortSignal;
+  awaitAfterEachYield: () => Promise<void>;  // used for pause/resume gate
+  forkContinuation: ForkContinuationOptions | null;
+  prefilledDiskSteps: PrefilledDiskStep[] | null;
+  replayTimestamps: readonly number[] | null;
+  storageRoot: string;
+};
+
+// Engine output
+type WorkflowResult = {
+  returnCode: number;
+  summary: string;
+  rootHash: string;   // hash of the __end__ StateNode
+};
+```
+
+## Pause Gate
+
+`awaitAfterEachYield` is a function injected by the worker/runner that can block the loop between steps. The `ThreadPauseGate` in `thread-pause-gate.ts` provides `pause()` / `resume()` operations that control this gate. When paused, the loop suspends after writing the current step but before requesting the next one.
+
+## Supervisor
+
+If `workflowConfig.supervisorInterval > 0`, the engine runs a supervisor check after every `supervisorInterval` steps. The supervisor calls an LLM with a summary of recent steps and returns `"continue"` or `"kill"`. A `"kill"` decision finalizes the thread immediately with `returnCode: 1` and a summary string.
+
+## Summarizer
+
+On normal completion (generator returns), the engine calls `createSummarizer` to produce a single LLM-generated summary string from recent step content. This summary replaces the bundle's raw `WorkflowCompletion.summary` in the final history record.
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-execute` | `src/engine/engine.ts` | `executeThread` — main engine entry point |
+| `@uncaged/workflow-execute` | `src/engine/types.ts` | `ExecuteThreadOptions`, `ExecuteThreadIo`, `ChainState`, `ThreadPauseGate` |
+| `@uncaged/workflow-execute` | `src/engine/threads-index.ts` | `threads.json` persistence, history append |
+| `@uncaged/workflow-execute` | `src/engine/supervisor.ts` | Supervisor LLM check (`"continue"` / `"kill"`) |
+| `@uncaged/workflow-execute` | `src/engine/summarizer.ts` | Post-completion LLM summary |
+| `@uncaged/workflow-execute` | `src/engine/thread-pause-gate.ts` | Pause/resume gate |
+| `@uncaged/workflow-execute` | `src/engine/worker.ts` | Worker-process entry that spawns `executeThread` in a subprocess |
+| `@uncaged/workflow-runtime` | `src/create-workflow.ts` | `createWorkflow` — the role loop inside the bundle |
+| `@uncaged/workflow-protocol` | `src/types.ts` | `WorkflowFn`, `RoleOutput`, `WorkflowCompletion`, `AdvanceOutcome` |
+
+## See Also
+
+- [Role](./role.md) — what the moderator selects each iteration
+- [Agent Binding](./agent-binding.md) — what executes a role and returns its output
+- [Reactor](./reactor.md) — used internally for the extract and supervisor LLM calls
+- [Thread](./thread.md) — the CAS-persisted result of running the engine

.cards/package-map.md

@@ -0,0 +1,129 @@
+# Package Map
+
+> All packages in the monorepo with their responsibilities, dependency layers, and publication status.
+
+## Overview
+
+The monorepo is organized as a strict dependency DAG. Each layer may only depend on layers below it. The execution stack flows from the shared protocol types at the bottom up to the CLI at the top. Agent packages and template packages are leaf nodes that depend on the runtime layer but are not depended upon by the core stack.
+
+## Package List
+
+| Package | Description |
+|---------|-------------|
+| `@uncaged/workflow-protocol` | Shared types (`ThreadContext`, `RoleDefinition`, `CasStore`, `Result`, etc.) and constants (`START`, `END`) |
+| `@uncaged/workflow-runtime` | `createWorkflow`, type re-exports; primary dependency for bundle authors |
+| `@uncaged/workflow-util` | Utilities: Crockford Base32, ULID, structured logger, storage paths |
+| `@uncaged/workflow-reactor` | `createThreadReactor` (ReAct loop), `createLlmFn` (OpenAI-compatible LLM caller) |
+| `@uncaged/workflow-cas` | `createCasStore` (filesystem CAS), XXH64 hashing, Merkle node serialization |
+| `@uncaged/workflow-register` | Bundle validation, `workflow.yaml` registry read/write, model resolution |
+| `@uncaged/workflow-execute` | Engine (`executeThread`), extract phase, fork, GC, `workflowAsAgent` |
+| `@uncaged/cli-workflow` | `uncaged-workflow` CLI — command dispatcher for all user-facing operations |
+| `@uncaged/workflow-agent-cursor` | Adapter that runs the `cursor` CLI non-interactively in a workspace |
+| `@uncaged/workflow-agent-hermes` | Adapter that runs `hermes chat` (Nerve-style CLI agent) |
+| `@uncaged/workflow-agent-llm` | Adapter for direct LLM chat completions |
+| `@uncaged/workflow-agent-react` | Adapter with ReAct loop and file/shell tools |
+| `@uncaged/workflow-util-agent` | Shared agent utilities: `buildThreadInput`, `spawnCli`, `createAgentAdapter` |
+| `@uncaged/workflow-template-develop` | `develop` workflow template (planner → coder → reviewer → tester → committer) |
+| `@uncaged/workflow-template-solve-issue` | `solve-issue` workflow template (preparer → developer → submitter) |
+| `@uncaged/workflow-gateway` | WebSocket gateway for remote CLI-to-dashboard communication |
+| `workflow-dashboard` | React dashboard (private, unpublished) — thread/workflow viewer |
+
+## Dependency Layer Diagram
+
+```mermaid
+graph TD
+    subgraph Layer 0 — Protocol
+        P[workflow-protocol]
+    end
+
+    subgraph Layer 1 — Foundations
+        RT[workflow-runtime]
+        UT[workflow-util]
+        RX[workflow-reactor]
+    end
+
+    subgraph Layer 2 — Storage & Register
+        CAS[workflow-cas]
+        REG[workflow-register]
+    end
+
+    subgraph Layer 3 — Execute
+        EX[workflow-execute]
+    end
+
+    subgraph Layer 4 — CLI
+        CLI[cli-workflow]
+    end
+
+    subgraph Agents (leaf)
+        AGC[workflow-agent-cursor]
+        AGH[workflow-agent-hermes]
+        AGL[workflow-agent-llm]
+        AGR[workflow-agent-react]
+        UA[workflow-util-agent]
+    end
+
+    subgraph Templates (leaf)
+        TD[workflow-template-develop]
+        TS[workflow-template-solve-issue]
+    end
+
+    subgraph Dashboard
+        GW[workflow-gateway]
+        DB[workflow-dashboard]
+    end
+
+    RT --> P
+    UT --> P
+    RX --> P
+    CAS --> P
+    REG --> P
+    REG --> UT
+    EX --> RT
+    EX --> UT
+    EX --> CAS
+    EX --> REG
+    EX --> RX
+    CLI --> EX
+    CLI --> UT
+    CLI --> REG
+    AGC --> RT
+    AGC --> UT
+    AGC --> UA
+    AGH --> RT
+    AGH --> UA
+    AGL --> RT
+    AGR --> RT
+    AGR --> RX
+    UA --> RT
+    TD --> RT
+    TS --> RT
+    DB --> GW
+```
+
+## Published vs. Private
+
+All `@uncaged/*` packages are published to **npmjs.org** under a fixed versioning scheme (all packages share the same version number via `@changesets/cli` in fixed mode).
+
+| Status | Packages |
+|--------|---------|
+| **Published** | All packages with `@uncaged/` scope |
+| **Private** | `workflow-dashboard` (no `@uncaged/` scope, `"private": true`) |
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-protocol` | `src/types.ts` | Root type definitions for the entire stack |
+| `@uncaged/workflow-runtime` | `src/index.ts` | Public API for bundle authors |
+| `@uncaged/workflow-util` | `src/index.ts` | Utility re-exports |
+| `@uncaged/workflow-execute` | `src/index.ts` | Engine public API |
+| `@uncaged/cli-workflow` | `src/cli-dispatch.ts` | Top-level command table |
+
+## See Also
+
+- [Bundle](./bundle.md) — produced by workspace authors using `@uncaged/workflow-runtime`
+- [Engine](./engine.md) — the core of `@uncaged/workflow-execute`
+- [Reactor](./reactor.md) — `@uncaged/workflow-reactor`
+- [Registry](./registry.md) — `@uncaged/workflow-register`
+- [CLI](./cli.md) — `@uncaged/cli-workflow`

.cards/reactor.md

@@ -0,0 +1,102 @@
+# Reactor
+
+> A generic ReAct (Reason + Act) loop that drives an LLM through multiple tool-call rounds until it produces structured output matching a Zod schema.
+
+## Overview
+
+The reactor is a reusable abstraction for LLM interactions that require tool use. It runs a multi-turn conversation loop: the LLM is presented with a user message and a set of tools, and responds either with a tool call (which the reactor dispatches and feeds back) or with a plain JSON object matching the expected schema. The loop repeats until structured output is obtained or `maxRounds` is exhausted.
+
+The reactor is used in two places:
+
+1. **Extract phase** — `createExtract` in `@uncaged/workflow-execute` uses a CAS-backed reactor to extract typed `meta` from a role's content hash.
+2. **React agent** — `createReactAdapter` in `@uncaged/workflow-agent-react` uses the reactor as its execution backbone.
+
+## createThreadReactor
+
+```typescript
+function createThreadReactor<TThread>(
+  config: ThreadReactorConfig<TThread>,
+): ThreadReactorFn<TThread>
+```
+
+`ThreadReactorConfig` bundles:
+
+| Field | Purpose |
+|-------|---------|
+| `llm` | The `LlmFn` to call each round |
+| `staticTools` | Tools always available (e.g., `cas_get`) |
+| `structuredToolFromSchema` | Derives a schema-specific extraction tool from the Zod schema |
+| `systemPromptForStructuredTool` | Constructs the system prompt given the extraction tool name |
+| `toolHandler` | Handles non-structured tool calls; receives the raw `ToolCall` and thread context |
+| `maxRounds` | Hard stop after N rounds; returns `err("max_react_rounds_exceeded")` |
+
+## Round Lifecycle
+
+```mermaid
+sequenceDiagram
+    participant R as Reactor
+    participant L as LLM
+    participant H as toolHandler
+
+    R->>L: messages + tools
+    L-->>R: response
+
+    alt plain JSON (valid schema)
+        R-->>R: return ok(value)
+    else plain JSON (invalid)
+        R->>L: correction message
+    else tool_calls
+        loop each call
+            alt structured tool
+                R-->>R: validate args → return ok(value)
+            else static tool
+                R->>H: toolHandler(call, thread)
+                H-->>R: content string
+                R->>L: tool result message
+            end
+        end
+    end
+```
+
+## LlmFn
+
+```typescript
+type LlmFn = (input: {
+  messages: ChatMessage[];
+  tools: readonly ToolDefinition[];
+}) => Promise<Result<string, string>>;
+```
+
+`createLlmFn(provider)` in `@uncaged/workflow-reactor` builds an `LlmFn` that calls the OpenAI-compatible chat completions endpoint and returns the raw response body as a string for the reactor to parse.
+
+## Extract Phase
+
+`createExtract(provider, { cas })` in `@uncaged/workflow-execute` creates a `CasReactor` — a preconfigured `ThreadReactorFn` with a `cas_get` static tool. The extract function loads the content payload for a given hash, sends it to the reactor with the role's Zod schema, and returns `ExtractResult<T>`.
+
+```typescript
+type ExtractFn = <T extends Record<string, unknown>>(
+  schema: z.ZodType<T>,
+  contentHash: string,
+) => Promise<ExtractResult<T>>;
+```
+
+The `cas_get` tool allows the LLM to dereference CAS hashes during extraction — important when the content node references artifact hashes.
+
+## Relationship to Engine
+
+The reactor is called within `AdapterFn` implementations (e.g., `createLlmAdapter`, `createReactAdapter`) when the agent needs multi-turn tool interaction to complete a role. The engine itself does not call the reactor directly — it only drives the outer `WorkflowFn` generator and persists `RoleOutput` values.
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-reactor` | `src/thread-reactor.ts` | `createThreadReactor` — generic ReAct loop |
+| `@uncaged/workflow-reactor` | `src/llm-fn.ts` | `createLlmFn` — OpenAI-compatible LLM caller |
+| `@uncaged/workflow-reactor` | `src/types.ts` | `LlmFn`, `ThreadReactorConfig`, `ToolCall`, `ToolDefinition`, `ChatMessage` |
+| `@uncaged/workflow-execute` | `src/cas-reactor.ts` | `createCasReactor` — reactor with `cas_get` static tool |
+| `@uncaged/workflow-execute` | `src/extract/extract-fn.ts` | `createExtract` — extract phase using the CAS reactor |
+
+## See Also
+
+- [Engine](./engine.md) — drives the workflow generator; extract is called inside the adapter layer
+- [Agent Binding](./agent-binding.md) — adapter implementations that use the reactor internally

.cards/registry.md

@@ -0,0 +1,95 @@
+# Registry
+
+> `workflow.yaml` — the local file that maps workflow names to their current and historical bundle hashes, plus global LLM provider configuration.
+
+## Overview
+
+The registry is a single YAML file at `<storageRoot>/workflow.yaml` (default: `~/.uncaged/workflow/workflow.yaml`). It is the authoritative index of which bundles are available on a machine and what name each one is known by. All CLI workflow commands read or write this file.
+
+The registry is read on every `uncaged-workflow run` invocation to look up the bundle hash for a given name, then used again to resolve the `extract` model configuration. It is written atomically via the `writeWorkflowRegistry` function.
+
+## Schema
+
+```yaml
+config:
+  maxDepth: 3
+  supervisorInterval: 5
+  providers:
+    openrouter:
+      baseUrl: "https://openrouter.ai/api/v1"
+      apiKey: "sk-or-..."
+  models:
+    extract: "openrouter/anthropic/claude-sonnet-4-5"
+    supervisor: "openrouter/anthropic/claude-haiku-3-5"
+
+workflows:
+  solve-issue:
+    hash: "3TNKQRJ7BM4XH"
+    timestamp: 1716000000000
+    history:
+      - hash: "2BMJPQ6YAK3WG"
+        timestamp: 1715000000000
+  develop:
+    hash: "7VQWX8NRHK1ZT"
+    timestamp: 1716100000000
+    history: []
+```
+
+## Types
+
+```typescript
+type WorkflowRegistryFile = {
+  config: WorkflowConfig | null;
+  workflows: Record<string, WorkflowRegistryEntry>;
+};
+
+type WorkflowRegistryEntry = {
+  hash: string;       // current bundle hash (13-char Crockford Base32)
+  timestamp: number;  // Unix epoch ms when this version was registered
+  history: WorkflowHistoryEntry[];
+};
+
+type WorkflowHistoryEntry = {
+  hash: string;
+  timestamp: number;
+};
+```
+
+## Bundle Registration Flow
+
+1. `uncaged-workflow workflow add <name> <file.esm.js>` is called.
+2. The bundle bytes are hashed with XXH64 → 13-char Crockford Base32.
+3. The bundle file is copied into `<storageRoot>/bundles/<hash>/` (if not already present).
+4. `registerWorkflowVersion` prepends the current head to `history` and sets the new hash as head.
+5. The updated registry is written back to `workflow.yaml`.
+
+## Version History
+
+Every `workflow add` on an already-registered name pushes the previous hash into `history`. History is ordered most-recent-first. `workflow rollback <name> [hash]` swaps the specified history entry back to head (or defaults to `history[0]`).
+
+## Model Resolution
+
+The `config.models` section uses `provider/model` references (e.g., `"openrouter/anthropic/claude-sonnet-4-5"`). `resolveModel` splits the reference on the first `/`, looks up the provider in `config.providers`, and returns a `ResolvedModel` with `{ baseUrl, apiKey, model }`. This is used by the engine to configure the `extract` LLM.
+
+```typescript
+// packages/workflow-register/src/config/resolve-model.ts
+export function resolveModel(
+  config: WorkflowConfig,
+  modelKey: string,
+): Result<ResolvedModel, string>
+```
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-register` | `src/registry/registry.ts` | `readWorkflowRegistry`, `writeWorkflowRegistry`, `registerWorkflowVersion`, `rollbackWorkflowToHistoryHash` |
+| `@uncaged/workflow-register` | `src/registry/types.ts` | `WorkflowRegistryFile`, `WorkflowRegistryEntry`, `WorkflowHistoryEntry` |
+| `@uncaged/workflow-register` | `src/registry/registry-normalize.ts` | YAML normalization for the registry root |
+| `@uncaged/workflow-register` | `src/config/resolve-model.ts` | `resolveModel` — splits `provider/model` refs |
+| `@uncaged/workflow-register` | `src/bundle/extract-bundle-exports.ts` | Validates bundle exports before registration |
+| `@uncaged/workflow-protocol` | `src/types.ts` | `WorkflowConfig`, `ProviderConfig`, `ResolvedModel` |
+
+## See Also
+
+- [Bundle](./bundle.md) — what is stored and indexed in the registry

.cards/role.md

@@ -0,0 +1,72 @@
+# Role
+
+> A named actor within a workflow defined entirely as pure data — a description, a system prompt, an extraction schema, and an optional refs extractor — with no embedded agent logic.
+
+## Overview
+
+A role is a `RoleDefinition<Meta>` value: a plain TypeScript object that describes what an actor in the workflow does and how its output should be structured. Roles are authored in the template or bundle source and passed to `createWorkflow` as part of the `WorkflowDefinition`. They never hold a reference to an agent implementation.
+
+This separation of concerns is deliberate. The same role definition can be executed by different agents (Cursor, Hermes, an LLM, a React loop) simply by changing the `AdapterBinding` passed to `createWorkflow`. Roles are also serialized into the `WorkflowDescriptor` for tooling like the dashboard.
+
+## RoleDefinition Type
+
+```typescript
+type RoleDefinition<Meta extends Record<string, unknown>> = {
+  description: string;
+  systemPrompt: string;
+  schema: z.ZodType<Meta>;
+  extractRefs: ((meta: Meta) => string[]) | null;
+};
+```
+
+| Field | Purpose |
+|-------|---------|
+| `description` | Human-readable summary for tooling and the `WorkflowDescriptor` |
+| `systemPrompt` | Passed to the adapter as the agent's persona/instruction for this role |
+| `schema` | Zod v4 schema that defines the structured output (`Meta`) of the role |
+| `extractRefs` | Optional function that extracts CAS hashes from `meta` to record as artifact refs |
+
+## Schema and Extraction
+
+Each role's `schema` is a Zod v4 type parameterized to the role's `Meta` type. When a role executes via an `AdapterFn`, the adapter is responsible for producing a value that satisfies this schema directly (the `AdapterFn` receives the schema and system prompt and returns a `RoleFn` that yields `RoleResult<T>`).
+
+If `extractRefs` is non-null, the engine calls it on the completed `meta` to collect additional CAS hashes that should appear in the `StateNode.refs` skip-list, enabling traversal of artifacts produced by the role.
+
+## WorkflowDefinition
+
+Roles are collected into a `WorkflowDefinition<M>` alongside the moderator table:
+
+```typescript
+type WorkflowDefinition<M extends RoleMeta> = {
+  description: string;
+  roles: { [K in keyof M & string]: RoleDefinition<M[K]> };
+  table: ModeratorTable<M>;
+};
+```
+
+`M` is the `RoleMeta` map that binds each role name to its concrete `Meta` type. This gives full TypeScript type safety across the moderator, adapter, and CAS storage layers.
+
+## WorkflowRoleDescriptor (Serialized)
+
+The `WorkflowDescriptor` (stored in the bundle's `descriptor` export) contains a `roles` map of `WorkflowRoleDescriptor` objects — a JSON-serializable projection of each `RoleDefinition`:
+
+```typescript
+type WorkflowRoleDescriptor = {
+  description: string;
+  systemPrompt: string;
+  schema: WorkflowRoleSchema;  // JSON-compatible schema shape
+};
+```
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-protocol` | `src/types.ts` | `RoleDefinition`, `WorkflowDefinition`, `RoleMeta`, `WorkflowRoleDescriptor`, `WorkflowDescriptor` |
+| `@uncaged/workflow-runtime` | `src/create-workflow.ts` | Consumes `WorkflowDefinition` roles in the adapter dispatch loop |
+| `@uncaged/workflow-register` | `src/bundle/build-descriptor.ts` | Serializes `RoleDefinition[]` to `WorkflowDescriptor` |
+
+## See Also
+
+- [Engine](./engine.md) — the loop that selects and executes roles
+- [Agent Binding](./agent-binding.md) — the runtime binding that executes a role via a concrete agent

.cards/thread.md

@@ -0,0 +1,97 @@
+# Thread
+
+> A single execution instance of a workflow, identified by a ULID, whose state is stored as a linked chain of immutable CAS nodes.
+
+## Overview
+
+A thread is the runtime envelope around one call to a workflow's `run` function. It carries a unique ULID (26-char Crockford Base32) and tracks the full sequence of role steps that have executed. Because all state is written to CAS as immutable blobs, threads are append-only and fully auditable.
+
+Every thread belongs to a specific workflow bundle (identified by hash). The engine writes a `StartNode` when the thread begins and one `StateNode` per completed role step — including a final `__end__` state on completion or abort. Steps accumulate in `ThreadContext.steps` and are replayed into the context whenever a thread is resumed.
+
+## Lifecycle
+
+```mermaid
+stateDiagram-v2
+    [*] --> Active: thread run / fork
+    Active --> Active: role step yielded
+    Active --> Paused: pause signal
+    Paused --> Active: resume signal
+    Active --> Completed: generator returns WorkflowCompletion
+    Active --> Aborted: kill signal / AbortSignal
+    Completed --> [*]: entry in history/*.jsonl
+    Aborted --> [*]: entry in history/*.jsonl (returnCode=130)
+```
+
+## Identity
+
+Thread IDs are ULIDs: 26-char Crockford Base32 strings composed of a 10-char timestamp prefix and a 16-char random suffix. Generated by `generateUlid` from `@uncaged/workflow-util`.
+
+## State Storage
+
+Thread state is stored entirely in CAS as a linked list of nodes:
+
+```
+StartNode  (type: "start")
+  payload: { name, hash, depth, parentState }
+  refs: [promptHash, parentState?]
+
+StateNode  (type: "state")  ← one per role step
+  payload: { role, meta, start, content, ancestors[], compact, timestamp, childThread }
+  refs: [contentHash, startHash, ancestor hashes...]
+
+StateNode  (type: "state", role: "__end__")  ← final node
+  payload: { returnCode, summary }
+```
+
+The `ancestors` array implements a skip-list (capped at 11 entries: 1 direct parent + up to 10 ancestors) to allow efficient traversal without loading every node in the chain.
+
+## Index Files
+
+| File | Purpose |
+|------|---------|
+| `<bundleDir>/threads.json` | Active thread index — maps `threadId → { head, start, updatedAt }` |
+| `<bundleDir>/history/YYYY-MM-DD.jsonl` | Completed thread records — one JSON line per completed/aborted thread |
+| `<storageRoot>/cas/` | All CAS blobs shared across all bundles |
+
+A thread is "active" while it appears in `threads.json`. On completion, its entry is removed from `threads.json` and a record appended to the appropriate `history/*.jsonl` file.
+
+## ThreadContext
+
+The `ThreadContext` type is the read-only view passed into every role and moderator call:
+
+```typescript
+type ThreadContext<M extends RoleMeta = RoleMeta> = {
+  threadId: string;
+  depth: number;
+  bundleHash: string;
+  start: StartStep;
+  steps: RoleStep<M>[];
+};
+```
+
+`depth` tracks nesting for sub-workflow invocations (workflow-as-agent). `steps` grows by one entry after each successful role execution.
+
+## Fork
+
+A thread can be forked from any completed role step via `thread fork <id> [--from-role <role>]`. The fork reuses the original `StartNode` (same `startHash`) and replays CAS steps up to the fork point before resuming the generator. The forked thread gets a new ULID.
+
+## Debug Logs
+
+Each thread writes structured JSONL debug logs to `.info.jsonl` in the bundle directory. Each log line is `{ tag, content, timestamp }` where `tag` is an 8-char Crockford Base32 call-site identifier.
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-protocol` | `src/types.ts` | `ThreadContext`, `StartStep`, `RoleStep`, `RoleMeta` types |
+| `@uncaged/workflow-protocol` | `src/cas-types.ts` | `StartNode`, `StartNodePayload`, `StateNode`, `StateNodePayload` |
+| `@uncaged/workflow-execute` | `src/engine/threads-index.ts` | `threads.json` read/write, history append, `ThreadIndexEntry` |
+| `@uncaged/workflow-execute` | `src/engine/engine.ts` | `executeThread` — starts, drives, and finalizes a thread |
+| `@uncaged/workflow-execute` | `src/engine/fork-thread.ts` | Fork logic |
+| `@uncaged/workflow-util` | `src/ulid.ts` | `generateUlid` — ULID generation |
+
+## See Also
+
+- [CAS](./cas.md) — the storage layer that holds all thread state nodes
+- [Engine](./engine.md) — the execution loop that drives the thread
+- [Bundle](./bundle.md) — the workflow being executed in this thread

.cards/workflow-templates.md

@@ -0,0 +1,153 @@
+# Workflow Templates
+
+> Pre-built `WorkflowDefinition` objects exported from `@uncaged/workflow-template-*` packages that bundle authors can import, customize, or use directly.
+
+## Overview
+
+Templates are the reference implementations of common workflow patterns. They export a complete `WorkflowDefinition<M>` — typed roles with Zod schemas, and a `ModeratorTable` — ready to be passed to `createWorkflow`. A bundle author imports a template definition, supplies an `AdapterBinding`, calls `createWorkflow`, and exports the result as `run`.
+
+Templates are published as regular `@uncaged/*` npm packages. They are not bundles themselves; they are TypeScript libraries that become part of a bundle when the author's workspace is built.
+
+## solve-issue Template
+
+**Package**: `@uncaged/workflow-template-solve-issue`
+
+Resolves an issue end-to-end by preparing the repository, delegating implementation to a nested `develop` workflow, and opening a pull request.
+
+### Roles
+
+| Role | Description |
+|------|-------------|
+| `preparer` | Reads the issue, clones/checks out the repo, sets up the environment |
+| `developer` | Delegates to the `develop` workflow via `workflowAsAgent` (child thread) |
+| `submitter` | Opens a pull request with the completed changes |
+
+### Moderator Table
+
+```
+__start__ → preparer → developer → submitter → __end__
+```
+
+Linear routing — each role runs exactly once in sequence.
+
+### Meta Types
+
+```typescript
+type SolveIssueMeta = {
+  preparer: PreparerMeta;
+  developer: DeveloperMeta;
+  submitter: SubmitterMeta;
+};
+```
+
+## develop Template
+
+**Package**: `@uncaged/workflow-template-develop`
+
+Plans an implementation in phases, codes each phase incrementally, reviews, verifies with tests/build/lint, and commits.
+
+### Roles
+
+| Role | Description |
+|------|-------------|
+| `planner` | Produces an ordered list of implementation phases with hashes |
+| `coder` | Implements one phase; reports `completedPhase` hash in meta |
+| `reviewer` | Reviews the accumulated changes; approves or requests changes |
+| `tester` | Runs tests/lint/build; reports `passed` or `failed` |
+| `committer` | Creates the final git commit |
+
+### Moderator Table
+
+```
+__start__ → planner
+planner   → __end__      (if status == "aborted")
+planner   → coder        (fallback)
+coder     → reviewer     (if allPhasesComplete)
+coder     → coder        (fallback — repeat per phase)
+reviewer  → tester       (if status == "approved")
+reviewer  → coder        (fallback — request changes)
+tester    → committer    (if status == "passed")
+tester    → coder        (fallback — fix failures)
+committer → __end__
+```
+
+### Meta Types
+
+```typescript
+type DevelopMeta = {
+  planner: PlannerMeta;
+  coder: CoderMeta;
+  reviewer: ReviewerMeta;
+  tester: TesterMeta;
+  committer: CommitterMeta;
+};
+```
+
+## Writing a Custom Template
+
+A minimal custom workflow:
+
+```typescript
+import { createWorkflow, type WorkflowDefinition, END, START } from "@uncaged/workflow-runtime";
+import { z } from "zod/v4";
+import type { AdapterBinding } from "@uncaged/workflow-runtime";
+
+type MyMeta = {
+  analyst: { summary: string; confidence: number };
+  writer: { report: string };
+};
+
+const def: WorkflowDefinition<MyMeta> = {
+  description: "Analyse then write a report.",
+  roles: {
+    analyst: {
+      description: "Analyses the input and produces a structured summary.",
+      systemPrompt: "You are an expert analyst...",
+      schema: z.object({ summary: z.string(), confidence: z.number() }),
+      extractRefs: null,
+    },
+    writer: {
+      description: "Writes the final report.",
+      systemPrompt: "You are a technical writer...",
+      schema: z.object({ report: z.string() }),
+      extractRefs: null,
+    },
+  },
+  table: {
+    [START]: [{ condition: "FALLBACK", role: "analyst" }],
+    analyst: [{ condition: "FALLBACK", role: "writer" }],
+    writer: [{ condition: "FALLBACK", role: END }],
+  },
+};
+
+// In the bundle entry point:
+export const run = createWorkflow(def, binding);
+export const descriptor = buildDescriptor(def);
+```
+
+## Template → Bundle Relationship
+
+Templates are TypeScript library packages, not bundles. To use a template:
+
+1. Install the template package from npm: `bun add @uncaged/workflow-template-develop`.
+2. Import the definition: `import { developWorkflowDefinition } from "@uncaged/workflow-template-develop"`.
+3. Supply an `AdapterBinding` and call `createWorkflow`.
+4. Build with `bun build` to produce `.esm.js`.
+5. Register with `uncaged-workflow workflow add`.
+
+## Code Pointers
+
+| Package | File | What it does |
+|---------|------|-------------|
+| `@uncaged/workflow-template-solve-issue` | `src/index.ts` | `solveIssueWorkflowDefinition`, role and moderator exports |
+| `@uncaged/workflow-template-solve-issue` | `src/roles.ts` | `SolveIssueMeta`, `solveIssueRoles` |
+| `@uncaged/workflow-template-solve-issue` | `src/moderator.ts` | `solveIssueTable` — linear transition table |
+| `@uncaged/workflow-template-develop` | `src/index.ts` | `developWorkflowDefinition`, role and moderator exports |
+| `@uncaged/workflow-template-develop` | `src/roles.ts` | `DevelopMeta`, `developRoles` |
+| `@uncaged/workflow-template-develop` | `src/moderator.ts` | `developTable` — conditional multi-phase table |
+
+## See Also
+
+- [Bundle](./bundle.md) — the build artifact produced from a template + adapter
+- [Role](./role.md) — the `RoleDefinition` type each template role implements
+- [Engine](./engine.md) — the execution loop that drives the template's `WorkflowFn`

packages/workflow-protocol/__tests__/jsonata-moderator.test.ts

@@ -0,0 +1,284 @@
+import { describe, expect, test } from "bun:test";
+
+import type { ModeratorRule } from "../src/jsonata-moderator.js";
+import { evaluateModerator } from "../src/jsonata-moderator.js";
+import type { ModeratorContext, StartStep } from "../src/types.js";
+import { END, START } from "../src/types.js";
+
+// ── Helpers ─────────────────────────────────────────────────────────
+
+const BASE_START: StartStep = {
+  role: START,
+  content: "test task",
+  meta: {},
+  timestamp: 1000,
+  parentState: null,
+};
+
+function makeCtx(
+  steps: Array<{ role: string; meta: Record<string, unknown> }>,
+  overrides: Partial<ModeratorContext> = {},
+): ModeratorContext {
+  return {
+    threadId: "01JTESTTHREADID000",
+    depth: 0,
+    bundleHash: "TESTHASH00001",
+    start: BASE_START,
+    steps: steps.map((s, i) => ({
+      ...s,
+      contentHash: `hash-${i}`,
+      refs: [],
+      timestamp: 2000 + i,
+    })) as ModeratorContext["steps"],
+    ...overrides,
+  };
+}
+
+// ── Step 1: FALLBACK rule (when=null) always matches ────────────────
+
+describe("Step 1: FALLBACK rule", () => {
+  test("when=null always matches → returns rule.to", async () => {
+    const rules: ModeratorRule[] = [{ from: START, to: "planner", when: null }];
+    const result = await evaluateModerator(rules, makeCtx([]));
+    expect(result).toBe("planner");
+  });
+});
+
+// ── Step 2: No matching rules → __end__ ─────────────────────────────
+
+describe("Step 2: no matching rules", () => {
+  test("empty steps, no rule for __start__ → __end__", async () => {
+    const rules: ModeratorRule[] = [{ from: "planner", to: "coder", when: null }];
+    const result = await evaluateModerator(rules, makeCtx([]));
+    expect(result).toBe(END);
+  });
+
+  test("current state has no matching from rules → __end__", async () => {
+    const rules: ModeratorRule[] = [{ from: START, to: "planner", when: null }];
+    const result = await evaluateModerator(rules, makeCtx([{ role: "planner", meta: {} }]));
+    expect(result).toBe(END);
+  });
+});
+
+// ── Step 3: JSONata condition — truthy → match ────────────────────
+
+describe("Step 3: JSONata condition evaluation", () => {
+  test("truthy expression matches and returns rule.to", async () => {
+    const rules: ModeratorRule[] = [
+      {
+        from: "planner",
+        to: END,
+        when: "steps[role='planner'].meta.status = 'aborted'",
+      },
+      { from: "planner", to: "coder", when: null },
+    ];
+    const ctx = makeCtx([{ role: "planner", meta: { status: "aborted" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe(END);
+  });
+
+  test("falsy expression skips to next rule (FALLBACK)", async () => {
+    const rules: ModeratorRule[] = [
+      {
+        from: "planner",
+        to: END,
+        when: "steps[role='planner'].meta.status = 'aborted'",
+      },
+      { from: "planner", to: "coder", when: null },
+    ];
+    const ctx = makeCtx([{ role: "planner", meta: { status: "planned" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("coder");
+  });
+});
+
+// ── Step 4: plannerAborted condition ─────────────────────────────
+
+describe("Step 4: plannerAborted", () => {
+  const plannerAbortedRules: ModeratorRule[] = [
+    {
+      from: "planner",
+      to: END,
+      when: "steps[role='planner'].meta.status = 'aborted'",
+    },
+    { from: "planner", to: "coder", when: null },
+  ];
+
+  test("planner aborted → __end__", async () => {
+    const ctx = makeCtx([{ role: "planner", meta: { status: "aborted" } }]);
+    expect(await evaluateModerator(plannerAbortedRules, ctx)).toBe(END);
+  });
+
+  test("planner planned → coder", async () => {
+    const ctx = makeCtx([{ role: "planner", meta: { status: "planned", phases: [] } }]);
+    expect(await evaluateModerator(plannerAbortedRules, ctx)).toBe("coder");
+  });
+});
+
+// ── Step 5: reviewApproved / testsPassed (negative index) ────────
+
+describe("Step 5: last-step conditions", () => {
+  const rules: ModeratorRule[] = [
+    {
+      from: "reviewer",
+      to: "tester",
+      when: "steps[-1].meta.status = 'approved'",
+    },
+    { from: "reviewer", to: "coder", when: null },
+    {
+      from: "tester",
+      to: "committer",
+      when: "steps[-1].meta.status = 'passed'",
+    },
+    { from: "tester", to: "coder", when: null },
+  ];
+
+  test("reviewer approved → tester", async () => {
+    const ctx = makeCtx([{ role: "reviewer", meta: { status: "approved" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("tester");
+  });
+
+  test("reviewer changes-requested → coder", async () => {
+    const ctx = makeCtx([{ role: "reviewer", meta: { status: "changes-requested" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("coder");
+  });
+
+  test("tester passed → committer", async () => {
+    const ctx = makeCtx([{ role: "tester", meta: { status: "passed" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("committer");
+  });
+
+  test("tester failed → coder", async () => {
+    const ctx = makeCtx([{ role: "tester", meta: { status: "failed" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("coder");
+  });
+});
+
+// ── Step 6: allPhasesComplete condition ──────────────────────────
+
+describe("Step 6: allPhasesComplete", () => {
+  // The JSONata expression checks if all planned phase hashes appear in coder completedPhase values.
+  // Approximation using $count approach:
+  // Use JSONata 'in' operator inside $filter to check if each planned phase hash
+  // appears in the coder completedPhase values.
+  const allPhasesExpr =
+    "$count(steps[role='planner'].meta.phases) = 0 or $count(steps[role='planner'].meta.phases ~> $filter(function($p) { $p.hash in steps[role='coder'].meta.completedPhase })) >= $count(steps[role='planner'].meta.phases)";
+
+  const rules: ModeratorRule[] = [
+    { from: "coder", to: "reviewer", when: allPhasesExpr },
+    { from: "coder", to: "coder", when: null },
+  ];
+
+  test("no phases (empty array) → all complete → reviewer", async () => {
+    const ctx = makeCtx([
+      { role: "planner", meta: { status: "planned", phases: [] } },
+      { role: "coder", meta: { completedPhase: "PHASE001" } },
+    ]);
+    expect(await evaluateModerator(rules, ctx)).toBe("reviewer");
+  });
+
+  test("all phases completed → reviewer", async () => {
+    const ctx = makeCtx([
+      {
+        role: "planner",
+        meta: {
+          status: "planned",
+          phases: [{ hash: "PHASE001" }, { hash: "PHASE002" }],
+        },
+      },
+      { role: "coder", meta: { completedPhase: "PHASE001" } },
+      { role: "coder", meta: { completedPhase: "PHASE002" } },
+    ]);
+    expect(await evaluateModerator(rules, ctx)).toBe("reviewer");
+  });
+
+  test("not all phases completed → coder (loop)", async () => {
+    const ctx = makeCtx([
+      {
+        role: "planner",
+        meta: {
+          status: "planned",
+          phases: [{ hash: "PHASE001" }, { hash: "PHASE002" }],
+        },
+      },
+      { role: "coder", meta: { completedPhase: "PHASE001" } },
+    ]);
+    expect(await evaluateModerator(rules, ctx)).toBe("coder");
+  });
+});
+
+// ── Step 7: Full develop workflow routing table ───────────────────
+
+describe("Step 7: full develop workflow routing", () => {
+  const allPhasesExpr =
+    "$count(steps[role='planner'].meta.phases) = 0 or $count(steps[role='planner'].meta.phases ~> $filter(function($p) { $p.hash in steps[role='coder'].meta.completedPhase })) >= $count(steps[role='planner'].meta.phases)";
+
+  const rules: ModeratorRule[] = [
+    { from: START, to: "planner", when: null },
+    { from: "planner", to: END, when: "steps[role='planner'].meta.status = 'aborted'" },
+    { from: "planner", to: "coder", when: null },
+    { from: "coder", to: "reviewer", when: allPhasesExpr },
+    { from: "coder", to: "coder", when: null },
+    { from: "reviewer", to: "tester", when: "steps[-1].meta.status = 'approved'" },
+    { from: "reviewer", to: "coder", when: null },
+    { from: "tester", to: "committer", when: "steps[-1].meta.status = 'passed'" },
+    { from: "tester", to: "coder", when: null },
+    { from: "committer", to: END, when: null },
+  ];
+
+  test("initial state → planner", async () => {
+    expect(await evaluateModerator(rules, makeCtx([]))).toBe("planner");
+  });
+
+  test("planner planned, no phases → coder", async () => {
+    const ctx = makeCtx([{ role: "planner", meta: { status: "planned", phases: [] } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("coder");
+  });
+
+  test("planner aborted → __end__", async () => {
+    const ctx = makeCtx([{ role: "planner", meta: { status: "aborted" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe(END);
+  });
+
+  test("coder completed single phase → reviewer", async () => {
+    const ctx = makeCtx([
+      { role: "planner", meta: { status: "planned", phases: [{ hash: "PH1" }] } },
+      { role: "coder", meta: { completedPhase: "PH1" } },
+    ]);
+    expect(await evaluateModerator(rules, ctx)).toBe("reviewer");
+  });
+
+  test("coder incomplete phases → coder", async () => {
+    const ctx = makeCtx([
+      {
+        role: "planner",
+        meta: { status: "planned", phases: [{ hash: "PH1" }, { hash: "PH2" }] },
+      },
+      { role: "coder", meta: { completedPhase: "PH1" } },
+    ]);
+    expect(await evaluateModerator(rules, ctx)).toBe("coder");
+  });
+
+  test("reviewer approved → tester", async () => {
+    const ctx = makeCtx([{ role: "reviewer", meta: { status: "approved" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("tester");
+  });
+
+  test("reviewer rejected → coder", async () => {
+    const ctx = makeCtx([{ role: "reviewer", meta: { status: "changes-requested" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("coder");
+  });
+
+  test("tester passed → committer", async () => {
+    const ctx = makeCtx([{ role: "tester", meta: { status: "passed" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("committer");
+  });
+
+  test("tester failed → coder", async () => {
+    const ctx = makeCtx([{ role: "tester", meta: { status: "failed" } }]);
+    expect(await evaluateModerator(rules, ctx)).toBe("coder");
+  });
+
+  test("committer done → __end__", async () => {
+    const ctx = makeCtx([{ role: "committer", meta: {} }]);
+    expect(await evaluateModerator(rules, ctx)).toBe(END);
+  });
+});

packages/workflow-protocol/package.json

@@ -28,5 +28,8 @@
   },
   "publishConfig": {
     "access": "public"
+  },
+  "dependencies": {
+    "jsonata": "^2.2.0"
   }
 }

packages/workflow-protocol/src/index.ts

@@ -54,3 +54,8 @@ export { END, START } from "./types.js";
 // ── Constructor functions ──────────────────────────────────────────
 
 export { err, ok } from "./result.js";
+
+// ── JSONata moderator ──────────────────────────────────────────────
+
+export type { ModeratorRule } from "./jsonata-moderator.js";
+export { evaluateModerator } from "./jsonata-moderator.js";

packages/workflow-protocol/src/jsonata-moderator.ts

@@ -0,0 +1,66 @@
+import jsonata from "jsonata";
+
+import type { ModeratorContext, RoleMeta, StartStep } from "./types.js";
+import { END, START } from "./types.js";
+
+// ── Types ───────────────────────────────────────────────────────────
+
+export type ModeratorRule = {
+  from: string;
+  to: string;
+  when: string | null;
+};
+
+type JsonataContext = {
+  threadId: string;
+  depth: number;
+  start: StartStep;
+  steps: ReadonlyArray<{ role: string; meta: Record<string, unknown> }>;
+};
+
+// ── Evaluator ───────────────────────────────────────────────────────
+
+/**
+ * Evaluate a JSONata-based moderator rule set against the given thread context.
+ * Returns the next role name or '__end__'.
+ */
+export async function evaluateModerator(
+  rules: ReadonlyArray<ModeratorRule>,
+  context: ModeratorContext,
+): Promise<string> {
+  const lastStep = context.steps.length > 0 ? context.steps[context.steps.length - 1] : null;
+  const currentState: string = lastStep ? lastStep.role : START;
+
+  const matching = rules.filter((r) => r.from === currentState);
+
+  const jsonataCtx: JsonataContext = {
+    threadId: context.threadId,
+    depth: context.depth,
+    start: context.start,
+    steps: context.steps as ReadonlyArray<{ role: string; meta: Record<string, unknown> }>,
+  };
+
+  for (const rule of matching) {
+    if (rule.when === null) {
+      return rule.to;
+    }
+
+    const expr = jsonata(rule.when);
+    const result = await expr.evaluate(jsonataCtx);
+
+    if (result) {
+      return rule.to;
+    }
+  }
+
+  return END;
+}
+
+// ── Context helper ──────────────────────────────────────────────────
+
+/** Build a ModeratorContext from its constituent parts (convenience for tests / callers). */
+export function makeModeratorContext<M extends RoleMeta>(
+  ctx: ModeratorContext<M>,
+): ModeratorContext<M> {
+  return ctx;
+}