@sublang/playbook 5.0.0 → 6.0.0

package/README.md

@@ -25,7 +25,8 @@ Run `playbook` for an interactive tmux UI powered by [cligent](https://github.co
 
 ## Quick start
 
-Out of the box, Playbook includes **CODE**, a coding-and-review loop, and **DISCUSS**, in which two agents develop, reconcile, and review a specification.
+Out of the box, Playbook includes **CODE** for implementation, **REVIEW** for commit-based review and fixes, and **DECIDE** for independently proposed and reviewed specification decisions.
+CODE and DECIDE call REVIEW as a nested playbook.
 
 The interactive starter config uses Claude as both Captain and Coder, and Codex as Reviewer.
 
@@ -51,17 +52,20 @@ cd /path/to/your/project
 playbook
 ```
 
-Type a task, or enter `/code <task>` to select CODE directly.
+Type a task, enter `/code <task>` for implementation, or enter
+`/decide <question>` for an independently proposed and reviewed decision.
 
 On first launch, Playbook writes its config to `${XDG_CONFIG_HOME:-$HOME/.config}/playbook/playbook.config.yaml`.
 
 One-shot runs use separate defaults instead of the interactive lineup.
-Without configured `run` defaults, the Captain and every player use Claude; retain the Codex Reviewer with:
+Without configured `run` defaults, the Captain and every player use Claude; run standalone REVIEW with a Codex Reviewer using:
 
 ```sh
-playbook run @sublang/playbook/code/registry "add a test for parseArgs" --player reviewer=codex --json
+playbook run @sublang/playbook/review/registry "review the latest commit" --player reviewer=codex --json
 ```
 
+CODE and DECIDE require interactive `playbook` because the one-shot host does not drive nested calls.
+
 See [Using the CLI](docs/cli.md) for flags and session resume, [Configuring agents](docs/configuration.md) for lineups, [Embedding](docs/embedding.md) for custom hosts, and the [changelog](CHANGELOG.md) for releases.
 
 ## Create your own playbook
@@ -85,7 +89,7 @@ SLC's `playbook` pipeline has three phases:
 3. **FSM → runtime** ([slc/link.md](slc/link.md)) — links the machine to a host-independent interface for user input, agent calls, status, and telemetry.
 
 The default [optimization pass](slc/optimize.md) replaces eligible mechanical steps with local shell scripts; `--no-optimize` skips it.
-Inspect the complete [Captain](reference/sdlc/captain.md), [CODE](reference/sdlc/code.md), and [DISCUSS](reference/sdlc/discuss.md) examples.
+Inspect the complete [Captain](reference/sdlc/captain.md), [CODE](reference/sdlc/code.md), [REVIEW](reference/sdlc/review.md), and [DECIDE](reference/sdlc/decide.md) examples.
 
 ## Contributing
 
@@ -108,8 +112,8 @@ pnpm playbook   # drive a Boss turn against the source tree
 ```
 
 Playbook is itself spec-driven: the compiler phases are specs in [`slc/`](slc), and the reference playbooks are regenerated from their prose sources.
-Edit a source, regenerate its GEARS, FSM, and runtime artifacts, sync the tests and downstream specs until `pnpm test` passes, and commit with co-author trailers per [`specs/dev/git.md`](specs/dev/git.md).
-The gears↔FSM contract ([the PLAYBOOK dev items](specs/dev/playbook.md)) and the runtime contract ([the PBRT dev items](specs/dev/playbook-runtime.md)) are pinned in [`specs/dev/`](specs/dev) and verified by the test suite.
+Edit a source, regenerate its GEARS, FSM, and runtime artifacts, sync the tests and downstream specs until `pnpm test` passes, and commit with co-author trailers per [`specs/packages/git.md`](specs/packages/git.md).
+The gears↔FSM contract ([the playbook package](specs/packages/playbook.md)) and runtime contract ([the playbook-runtime package](specs/packages/playbook-runtime.md)) are pinned in [`specs/packages/`](specs/packages) and verified by the test suite.
 
 ## License
 

package/docs/cli.md

@@ -50,7 +50,7 @@ runtime is reported as not installed; a stale one with its installed
 and required versions, never as absent. Either way the remedy printed
 is cligent's pinned install, `npm install -g <package>@<version>`, so
 following it cannot install a version the gate refuses again
-([PBCLI-40](../specs/user/playbook-cli.md#pbcli-40)).
+([[playbook-cli-40](../specs/packages/playbook-cli.md#playbook-cli-40)]).
 
 ## Interactive
 
@@ -81,53 +81,56 @@ The command resolves its config (seeding it on first run), composes a
 `tmux-play` config, checks adapter readiness, and launches. It exits
 with tmux-play's status, re-raises a terminating signal on itself, and
 exits `127` when it cannot launch at all
-([PBCLI-1](../specs/user/playbook-cli.md#pbcli-1),
-[PBCLI-2](../specs/user/playbook-cli.md#pbcli-2)).
+([[playbook-cli-1](../specs/packages/playbook-cli.md#playbook-cli-1)],
+[[playbook-cli-2](../specs/packages/playbook-cli.md#playbook-cli-2)]).
 
 ### Running a Boss turn
 
 The Boss pane starts at the Playbook Captain shell, where the session
-Captain runs for the whole session and sees every turn. Use
-`/code <task>` to select the CODE playbook explicitly — a registered
-command resolves deterministically, with no model call parsing it: at
-idle it starts that playbook, at its own leaf it delivers the rest of
-the line, an enabled command absent from the active path switches to it,
-and a bare `/code` answers with status or a clarification instead of
-restarting anything. Type ordinary text and the session Captain decides
-the turn instead: it chats back, starts or switches a playbook, hands
-the text to the working playbook, dismisses it, or applies one recovery
-action the running playbook currently offers. It never does the
-specialized work itself, and a conversational turn — including a
-progress or status question — leaves the engagement, its parked state,
-and any pending player question untouched
-([CAPTAIN-1](../specs/user/playbook-captain.md#captain-1),
-[CAPTAIN-2](../specs/user/playbook-captain.md#captain-2)).
-
-Once a turn reaches CODE, the CODE judge classifies it into an FSM event
-— start a coding turn, continue or summarize an iteration, interrupt to
-a named state, or nothing
-([PBRT-1](../specs/user/playbook-runtime.md#pbrt-1)). When a player
-surfaces a clarifying question the FSM parks, the pane shows the
-question, and your next turn is normally classified as the reply — a
-fresh directive abandons it
-([PBRT-2](../specs/user/playbook-runtime.md#pbrt-2)).
+Captain runs for the whole session and sees every turn. Use `/code`,
+`/review`, or `/decide` followed by a task to select one of the bundled
+playbooks explicitly. A registered command resolves deterministically,
+with no model call parsing it: at idle it starts that playbook, at its
+own leaf it delivers the rest of the line, an enabled command absent
+from the active path switches to it, and a bare command answers with
+status or a clarification instead of restarting anything. Type ordinary
+text and the session Captain decides the turn instead: it chats back,
+starts or switches a playbook, hands the text to the working playbook,
+dismisses it, or applies one recovery action the running playbook
+currently offers. It never does the specialized work itself, and a
+conversational turn — including a progress or status question — leaves
+the engagement, its parked state, and any pending player question
+untouched
+([[playbook-captain-1](../specs/packages/playbook-captain.md#playbook-captain-1)],
+[[playbook-captain-2](../specs/packages/playbook-captain.md#playbook-captain-2)]).
+
+The current CODE, REVIEW, and DECIDE workflows take their deterministic
+initial event from the selecting Boss turn. CODE and DECIDE then call
+REVIEW as a nested playbook: an exact same-name child role continues the
+ancestor's player pane and backend conversation, while any additional
+role uses REVIEW's configured fallback. When a player surfaces a
+clarifying question the FSM parks, the pane shows the question, and a
+judge classifies your next turn as its reply or a fresh directive that
+abandons it
+([[playbook-runtime-2](../specs/packages/playbook-runtime.md#playbook-runtime-2)]).
 
 The Captain pane shows start/stop/finished status with `◇` lines and
 streams progress with captain-speech classification and questions
-([PBRT-3](../specs/user/playbook-runtime.md#pbrt-3)), while player
+([[playbook-runtime-3](../specs/packages/playbook-runtime.md#playbook-runtime-3)]), while player
 prompts ride their own panes. A turn that actually did something ends
 with one Captain reply summarizing what changed, composed only from that
 turn's reported outcome; a turn that changed nothing ends with an
 ordinary reply and no saved-counts line
-([CAPTAIN-19](../specs/user/playbook-captain.md#captain-19)).
+([[playbook-captain-19](../specs/packages/playbook-captain.md#playbook-captain-19)]).
 
 ## Non-interactive
 
 `playbook run <from> [task]` runs one playbook once, without tmux-play
-and without a config entry — point it straight at a registry module:
+and without an interactive config entry. For example, run REVIEW
+directly against the latest commit:
 
 ```sh
-playbook run @sublang/playbook/code/registry "add a test for parseArgs" \
+playbook run @sublang/playbook/review/registry "review the latest commit" \
   --player coder=claude --player reviewer=codex --cwd ./my-repo
 ```
 
@@ -138,7 +141,7 @@ intents the same way you would to `claude -p` or `codex exec`.
 | --- | --- |
 | `--player <role>=<agent>` | bind a required role |
 | `--captain <agent>` | set the captain/judge agent |
-| `--option <key>=<value>` | a playbook option (CODE's `committer`) |
+| `--option <key>=<value>` | a registry-defined playbook option (none in the current bundled workflows) |
 | `--cwd <dir>` | the agents' working directory |
 | `--json` | one envelope: `outcome`, `sessionId`, output or questions |
 | `--no-provision` | never create engine links beside a filesystem `<from>` |
@@ -152,7 +155,7 @@ config supplies [run defaults](configuration.md#defaults-for-playbook-run).
 
 Exit codes: `0` terminal, `1` bad argument or module, `2` failure, `3`
 the playbook needs a Boss reply
-([PBCLI-18](../specs/user/playbook-cli.md#pbcli-18)).
+([[playbook-cli-18](../specs/packages/playbook-cli.md#playbook-cli-18)]).
 
 ### Engine provisioning
 
@@ -164,7 +167,7 @@ install with no project-local packages —
 `node_modules/xstate` and `node_modules/@sublang/playbook` beside the
 module as symlinks to the running host's own packages and prints one
 line naming what it linked
-([PBCLI-36](../specs/user/playbook-cli.md#pbcli-36),
+([[playbook-cli-36](../specs/packages/playbook-cli.md#playbook-cli-36)],
 [DR-024](../specs/decisions/024-runtime-engine-provisioning.md)).
 A directory where the imports already resolve is never touched — a
 project-local install always wins — and `--no-provision` disables the
@@ -193,5 +196,5 @@ lineup, options, and working directory are stored with the session, so
 `resume` takes no binding flags. In scripts, capture the session id from
 the `--json` envelope, like Claude Code's `session_id` or
 `codex exec resume`
-([PBCLI-22](../specs/user/playbook-cli.md#pbcli-22),
+([[playbook-cli-22](../specs/packages/playbook-cli.md#playbook-cli-22)],
 [DR-014](../specs/decisions/014-durable-one-shot-run-sessions.md)).

package/docs/configuration.md

@@ -33,8 +33,8 @@ Within a `playbooks.<id>` block, `from` (the registry module), `command`
 every other key is that playbook's option slice. The launcher injects
 the rest — you do not write host wiring by hand.
 
-The seeded config runs the Coder on Claude Opus 4.8 1m and the Reviewer
-on GPT-5.5:
+The seeded config runs each Coder on Claude Opus 4.8 1m and each
+Reviewer on GPT-5.5:
 
 ```yaml
 captain:
@@ -54,6 +54,16 @@ playbooks:
         effort: xhigh
         permissions:
           mode: auto # protected auto mode for the Claude Coder
+
+  review:
+    from: '@sublang/playbook/review/registry'
+    players:
+      coder:
+        adapter: claude
+        model: claude-opus-4-8[1m]
+        effort: xhigh
+        permissions:
+          mode: auto
       reviewer:
         adapter: codex
         model: gpt-5.5
@@ -62,15 +72,47 @@ playbooks:
           mode: auto
           writablePaths:
             - .git # allow git metadata writes under Codex auto mode
-    committer: coder # which role commits — `coder` or `reviewer`
+
+  decide:
+    from: '@sublang/playbook/decide/registry'
+    players:
+      coder:
+        adapter: claude
+        model: claude-opus-4-8[1m]
+        effort: xhigh
+        permissions:
+          mode: auto
+      reviewer:
+        adapter: codex
+        model: gpt-5.5
+        effort: xhigh
+        permissions:
+          mode: auto
+          writablePaths:
+            - .git
 ```
 
-`committer` is CODE's one option: an alias naming which role runs the
-commit turn (fallback semantics:
-[PBRT-8](../specs/dev/playbook-runtime.md#pbrt-8)). Each role's per-run
-prompt names its pinned `model`, else its `adapter`
-([PBRT-4](../specs/user/playbook-runtime.md#pbrt-4)), so commit trailers
-credit the concrete model rather than the adapter family.
+The current bundled workflows accept no workflow-specific options.
+Each role's per-run prompt names its pinned `model`, else its `adapter`
+([[playbook-runtime-4](../specs/packages/playbook-runtime.md#playbook-runtime-4)]),
+so commit trailers credit the concrete model rather than the adapter
+family.
+
+## Nested roles and sessions
+
+The launcher creates a namespaced fallback player for every configured
+playbook role, but a nested call maps an exact same-name role to the
+nearest ancestor's effective player and backend conversation. CODE's
+nested REVIEW therefore continues CODE's `coder` and uses REVIEW's
+configured `reviewer`; DECIDE's nested REVIEW continues both of
+DECIDE's roles. A standalone REVIEW starts with REVIEW's own configured
+players, and every new root engagement starts fresh
+([DR-030](../specs/decisions/030-shared-mapped-player-continuity.md)).
+
+The separate fallback entries are still required because tmux creates
+its roster at launch time. The host changes which existing panes are
+visible as the active nested leaf changes; it does not create a new
+host player or backend agent session for a mapped role.
 
 ## Choosing the Captain agent
 
@@ -80,7 +122,7 @@ instead of doing the work itself. Claude enforces
 that at the provider level. The Codex adapter cannot — it rejects any
 tool list — so a `captain:` on `codex` falls back to a prompt-level
 restriction
-([DR-013 A1](../specs/decisions/013-routing-only-captain-control.md#addendum-a1-prompt-level-isolation-for-adapters-without-tool-enforcement)).
+([DR-013](../specs/decisions/013-routing-only-captain-control.md) A1).
 Codex remains a good choice for *players*, where full tools are wanted.
 
 Adapter readiness is intentionally light: `claude` is ready with local
@@ -109,8 +151,8 @@ playbooks:
         effort: medium
         permissions:
           mode: auto
-          # The seeded `committer` is `coder`, so this role runs the commit
-          # turn; a Codex agent needs the `.git` grant to write git metadata.
+          # CODE's Coder commits, so Codex needs the `.git` grant to write
+          # repository metadata.
           writablePaths:
             - .git
 ```
@@ -122,7 +164,7 @@ role switched to `codex` needs its own `writablePaths` grant, because
 the base Claude block had no reason to carry one.
 
 The global file is never modified, and `--with` is not forwarded to
-`tmux-play` ([PBCLI-25](../specs/user/playbook-cli.md#pbcli-25)).
+`tmux-play` ([[playbook-cli-25](../specs/packages/playbook-cli.md#playbook-cli-25)]).
 
 ## Defaults for `playbook run`
 
@@ -131,7 +173,7 @@ lineup so you stop retyping flags — `run.captain`, `run.players.<role>`,
 and a `run.player` catch-all for any other required role, each an
 `<adapter>[:<model>][@<effort>]` string. Flags win per role, and
 `resume` always keeps the lineup stored with the parked session
-([PBCLI-28](../specs/user/playbook-cli.md#pbcli-28),
+([[playbook-cli-28](../specs/packages/playbook-cli.md#playbook-cli-28)],
 [DR-017](../specs/decisions/017-run-defaults-config.md)).
 
 ```yaml
@@ -139,6 +181,7 @@ run:
   captain: claude:claude-opus-4-8@high
   players:
     coder: claude:claude-opus-4-8[1m]@xhigh
+    reviewer: codex:gpt-5.5@xhigh
 ```
 
 ## Migrating from `profiles`
@@ -153,7 +196,7 @@ do by hand.
 
 For a one-off, pass a raw `tmux-play` config explicitly. This bypasses
 the seed, composition, and readiness gate, forwarding arguments to
-`tmux-play` verbatim ([PBCLI-1](../specs/user/playbook-cli.md#pbcli-1)):
+`tmux-play` verbatim ([[playbook-cli-1](../specs/packages/playbook-cli.md#playbook-cli-1)]):
 
 ```sh
 playbook --config ./tmux-play.config.yaml

package/docs/embedding.md

@@ -8,7 +8,7 @@ one host, and [spex](https://github.com/sublang-ai/spex) (the desktop
 app) is another. This guide shows how to wire a playbook runtime into
 your own host.
 
-> **Release note:** this guide targets the semver-stable 1.0 six-port
+> **Release note:** this guide targets the current semver-stable six-port
 > contract; see the [CHANGELOG](../CHANGELOG.md) for migration details.
 
 ## The runtime contract
@@ -17,11 +17,11 @@ The port and runtime contracts live in the type-only module
 [`@sublang/playbook/runtime`](../src/runtime.ts) — a public,
 semver-stable surface (`PlayerResult`, `PlaybookPorts`,
 `PlaybookRuntime`, `PlaybookSession`, `PlayerCallOptions`,
-`CaptainCallOptions`, `CaptainResult`, `PlaybookTraceEvent`, and
-`PlaybookRuntimeFactory`) that imports no CODE or FSM types, so a host
-satisfies it once and inherits every playbook. The CODE runtime
-re-exports `PlayerResult`, `PlaybookPorts`, `PlaybookSession`, and
-`PlaybookRuntime` from `@sublang/playbook/code/playbook`;
+`PlayerSessionStore`, `CaptainCallOptions`, `CaptainResult`,
+`PlaybookTraceEvent`, and `PlaybookRuntimeFactory`) that imports no CODE
+or FSM types, so a host satisfies it once and inherits every playbook.
+The generated CODE, REVIEW, and DECIDE modules re-export their shared
+runtime contract types from their public `playbook` subpaths;
 `PlaybookRuntimeFactory` is available from `@sublang/playbook/runtime`.
 
 Generated linked runtimes reuse the XState integration engine exposed
@@ -32,7 +32,7 @@ nested-playbook bridge.
 ## Constructing a runtime against your own ports
 
 ```ts
-import createPlaybookRuntime from '@sublang/playbook/code/playbook';
+import createPlaybookRuntime from '@sublang/playbook/review/playbook';
 import type {
   CaptainCallOptions,
   CaptainResult,
@@ -104,20 +104,20 @@ const ports: PlaybookPorts = {
 };
 
 const runtime = createPlaybookRuntime({
-  coderPlayer: 'claude',
-  reviewerPlayer: 'codex',
+  coderLlm: 'claude-opus-4-8[1m]',
+  reviewerLlm: 'gpt-5.5',
 });
 
 const playbookSessionId = randomUUID();
 await runtime.init({
   sessionId: playbookSessionId,
-  playbookId: 'code',
+  playbookId: 'review',
   rootSessionId: playbookSessionId,
   depth: 0,
   ports,
 });
 await runtime.handleBossInput({
-  text: 'Start fixing the bug',
+  text: 'Review the latest commit against the requested intent',
   signal: new AbortController().signal,
 });
 await runtime.dispose();
@@ -129,11 +129,19 @@ Every init-to-dispose lifecycle is one playbook session. Its
 `playbook.trace` telemetry carries that immutable ID plus a contiguous
 sequence across exact Boss input, judge/player calls, FSM transitions,
 visible Captain work, nested playbook calls, status, settlement, and
-disposal. Each resolved player starts fresh in a new playbook session
-and then resumes only from the latest opaque `resumeToken` its adapter
-returned; trace data and tokens never enter Boss-visible status text.
-Because trace observers do receive opaque resume tokens, persisted
-traces should be protected as sensitive data.
+disposal. Without `PlaybookSession.playerSessions`, a standalone runtime
+starts each player fresh and privately retains the latest opaque
+`resumeToken` its adapter returned.
+
+A composing host can instead supply a frame-local `PlayerSessionStore`
+view over one root-owned continuation map. The host maps each local role
+to its effective binding, so a nested exact same-name role selects and
+updates the ancestor conversation while an unmatched child role gets
+its own binding. Child return or disposal does not clear the root's
+token, and a new root engagement starts fresh. Trace data and tokens
+never enter Boss-visible status text. Because trace observers do receive
+opaque resume tokens, persisted traces should be protected as sensitive
+data.
 
 See
 [`code.playbook.test.ts`](../reference/sdlc/code.playbook/code.playbook.test.ts)

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "@sublang/playbook",
-  "version": "5.0.0",
+  "version": "6.0.0",
   "type": "module",
-  "description": "Composable XState v5 playbook runtime with compiled Captain, CODE, and DISCUSS workflows driven by GEARS specs.",
+  "description": "Composable XState v5 playbook runtime with compiled Captain, CODE, REVIEW, and DECIDE workflows driven by GEARS specs.",
   "license": "Apache-2.0",
   "homepage": "https://github.com/sublang-ai/playbook#readme",
   "repository": {
@@ -40,7 +40,8 @@
     "slc/optimize.md",
     "reference/sdlc/captain.md",
     "reference/sdlc/code.md",
-    "reference/sdlc/discuss.md",
+    "reference/sdlc/review.md",
+    "reference/sdlc/decide.md",
     "reference/sdlc/captain.playbook/captain.gears.md",
     "reference/sdlc/captain.playbook/captain.fsm.ts",
     "reference/sdlc/captain.playbook/captain.fsm.js",
@@ -69,16 +70,26 @@
     "reference/sdlc/code.playbook/bin/run.js",
     "reference/sdlc/code.playbook/bin/provision.js",
     "reference/sdlc/code.playbook/bin/adapter-sdk.js",
-    "reference/sdlc/discuss.playbook/discuss.gears.md",
-    "reference/sdlc/discuss.playbook/discuss.fsm.ts",
-    "reference/sdlc/discuss.playbook/discuss.fsm.js",
-    "reference/sdlc/discuss.playbook/discuss.fsm.d.ts",
-    "reference/sdlc/discuss.playbook/discuss.playbook.ts",
-    "reference/sdlc/discuss.playbook/discuss.playbook.js",
-    "reference/sdlc/discuss.playbook/discuss.playbook.d.ts",
-    "reference/sdlc/discuss.playbook/discuss.registry.ts",
-    "reference/sdlc/discuss.playbook/discuss.registry.js",
-    "reference/sdlc/discuss.playbook/discuss.registry.d.ts",
+    "reference/sdlc/review.playbook/review.gears.md",
+    "reference/sdlc/review.playbook/review.fsm.ts",
+    "reference/sdlc/review.playbook/review.fsm.js",
+    "reference/sdlc/review.playbook/review.fsm.d.ts",
+    "reference/sdlc/review.playbook/review.playbook.ts",
+    "reference/sdlc/review.playbook/review.playbook.js",
+    "reference/sdlc/review.playbook/review.playbook.d.ts",
+    "reference/sdlc/review.playbook/review.registry.ts",
+    "reference/sdlc/review.playbook/review.registry.js",
+    "reference/sdlc/review.playbook/review.registry.d.ts",
+    "reference/sdlc/decide.playbook/decide.gears.md",
+    "reference/sdlc/decide.playbook/decide.fsm.ts",
+    "reference/sdlc/decide.playbook/decide.fsm.js",
+    "reference/sdlc/decide.playbook/decide.fsm.d.ts",
+    "reference/sdlc/decide.playbook/decide.playbook.ts",
+    "reference/sdlc/decide.playbook/decide.playbook.js",
+    "reference/sdlc/decide.playbook/decide.playbook.d.ts",
+    "reference/sdlc/decide.playbook/decide.registry.ts",
+    "reference/sdlc/decide.playbook/decide.registry.js",
+    "reference/sdlc/decide.playbook/decide.registry.d.ts",
     "docs"
   ],
   "bin": {
@@ -110,18 +121,26 @@
       "default": "./reference/sdlc/code.playbook/playbook-captain.js"
     },
     "./slc/*": "./slc/*",
-    "./discuss/playbook": {
-      "types": "./reference/sdlc/discuss.playbook/discuss.playbook.d.ts",
-      "default": "./reference/sdlc/discuss.playbook/discuss.playbook.js"
+    "./review/playbook": {
+      "types": "./reference/sdlc/review.playbook/review.playbook.d.ts",
+      "default": "./reference/sdlc/review.playbook/review.playbook.js"
     },
-    "./discuss/registry": {
-      "types": "./reference/sdlc/discuss.playbook/discuss.registry.d.ts",
-      "default": "./reference/sdlc/discuss.playbook/discuss.registry.js"
+    "./review/registry": {
+      "types": "./reference/sdlc/review.playbook/review.registry.d.ts",
+      "default": "./reference/sdlc/review.playbook/review.registry.js"
+    },
+    "./decide/playbook": {
+      "types": "./reference/sdlc/decide.playbook/decide.playbook.d.ts",
+      "default": "./reference/sdlc/decide.playbook/decide.playbook.js"
+    },
+    "./decide/registry": {
+      "types": "./reference/sdlc/decide.playbook/decide.registry.d.ts",
+      "default": "./reference/sdlc/decide.playbook/decide.registry.js"
     }
   },
   "scripts": {
     "build": "tsc",
-    "test": "vitest run",
+    "test": "spex lint && vitest run",
     "test:acceptance": "vitest run --config vitest.acceptance.config.ts",
     "smoke:release": "node scripts/release-smoke.mjs",
     "check:links": "node scripts/check-links.mjs",
@@ -133,7 +152,7 @@
   },
   "dependencies": {
     "@sublang/cligent": "^0.19.0",
-    "@sublang/spex": "^0.3.0",
+    "@sublang/spex": "^2.1.1",
     "p-queue": "^9.3.1",
     "xstate": "^5.19.4",
     "yaml": "^2.9.0"

package/reference/sdlc/captain.playbook/captain.playbook.js

@@ -520,6 +520,8 @@ const runtimeSpec = {
     snapshotOptions: snapshotCaptainOptions,
     machineInput: (options) => ({ enabledPlaybooks: options.enabledPlaybooks }),
     classifyBossText: (text, ports, signal, snapshotOrState, boundary, options) => classifyControllerTurn(text, ports, signal, snapshotOrState, boundary, options),
+    playerStates: {},
+    classificationStatus: () => undefined,
     captainStrategy: controllerCaptainStrategy,
     // CAPPLAY-10 / PBRT-52: the Captain's own ControlView context projection —
     // the settlement evidence the machine retains for its decision and reply

package/reference/sdlc/captain.playbook/captain.playbook.ts

@@ -810,6 +810,8 @@ const runtimeSpec: XStatePlaybookRuntimeSpec<ValidatedCaptainOptions> = {
       boundary,
       options,
     ) as Promise<import('xstate').EventObject | undefined>,
+  playerStates: {},
+  classificationStatus: () => undefined,
   captainStrategy: controllerCaptainStrategy,
   // CAPPLAY-10 / PBRT-52: the Captain's own ControlView context projection —
   // the settlement evidence the machine retains for its decision and reply