@sublang/playbook 2.0.0 → 3.1.0

package/reference/sdlc/code.playbook/code.gears.md

@@ -15,7 +15,7 @@ Players:
 
 When Boss gives a coding intent, Captain shall relay it to Coder along with the following prompt:
 > Assess whether this can be completed in a single commit, following best practices.
-> If yes, implement and test, updating both code and specs; otherwise, decompose into tasks as a new IR under @specs/iterations and stop without implementing any IR task.
+> If yes, implement and test, updating both code and specs; otherwise, decompose into tasks as a new IR under @specs/intents (or @specs/iterations in older scaffolds) and stop without implementing any IR task.
 > For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
 > Ensure @specs/map.md reflects the changes.
 > Do not commit.
@@ -42,9 +42,9 @@ When an IR is done, Captain shall prompt Coder:
 > Read IR-<#> and corresponding commits.
 > According to @specs/meta.md, add or update spec items to fully capture:
 >
-> - the user requirements in @specs/user,
-> - the system behavior in @specs/dev, and
-> - the integration/system test cases in @specs/test.
+> - the external behavior users rely on,
+> - the internal system behavior, and
+> - the integration/system test cases.
 >
 > The spec items should be the *minimal* set needed to reimplement code without the IR.
 > The set should be complete and coherent.
@@ -58,15 +58,17 @@ For each finding in a review round, Coder either addresses it with changes or ch
 Any code change to address findings starts a new round of review, even if some findings are also rebutted.
 Rounds continue until Reviewer raises no findings.
 
+Spec item files are the files under @specs/ that hold spec items — @specs/packages/ and @specs/compositions/ in the current layout, or @specs/user/, @specs/dev/, and @specs/test/ in the legacy one; decision and intent records (iteration records in older scaffolds), @specs/map.md, and @specs/meta.md are not spec item files.
+
 ### CODE-5
 
-When Committer commits Initial Changes from a Boss coding intent involving changes only in @specs/user/, @specs/dev/, or @specs/test/, Captain shall relay the Boss's coding intent to Reviewer along with the following prompt:
+When Committer commits Initial Changes from a Boss coding intent involving changes only in spec item files, Captain shall relay the Boss's coding intent to Reviewer along with the following prompt:
 > Review the latest commit.
 > Refer to the commit message.
 > Verify any affected spec items are:
 >
 > - Complete & coherent: sufficient for you to reimplement code.
-> - Right level: user requirements (in @specs/user) or system behavior (in @specs/dev), not implementation specifics; integration/system testing (in @specs/test), not unit testing.
+> - Right level: external behavior users rely on or internal system behavior (organized per @specs/meta.md), not implementation specifics; integration/system testing, not unit testing.
 > - Minimal: essential and concise; every item earns its place; also check with other items.
 > - Well organized: spec packages are finely scoped, with high cohesion and low coupling.
 >
@@ -78,7 +80,7 @@ When Committer commits Initial Changes from a Boss coding intent involving chang
 
 ### CODE-6
 
-When Committer commits Initial Changes from a Boss coding intent involving changes only outside @specs/user/, @specs/dev/, and @specs/test/, Captain shall relay the Boss's coding intent to Reviewer along with the following prompt:
+When Committer commits Initial Changes from a Boss coding intent involving changes only outside spec item files, Captain shall relay the Boss's coding intent to Reviewer along with the following prompt:
 > Review the latest commit.
 > Refer to the commit message.
 > Flag any issues or improvements (numbered; no duplication).
@@ -90,7 +92,7 @@ When Committer commits Initial Changes from a Boss coding intent involving chang
 
 ### CODE-7
 
-When Committer commits Initial Changes from a Boss coding intent involving changes both in and outside @specs/user/, @specs/dev/, and @specs/test/, Captain shall relay the Boss's coding intent to Reviewer along with the following prompt:
+When Committer commits Initial Changes from a Boss coding intent involving changes both in and outside spec item files, Captain shall relay the Boss's coding intent to Reviewer along with the following prompt:
 > Review the latest commit.
 > Refer to the commit message.
 > Flag any issues or improvements (numbered; no duplication).
@@ -98,7 +100,7 @@ When Committer commits Initial Changes from a Boss coding intent involving chang
 > Verify any affected spec items are:
 >
 > - Complete & coherent: sufficient for you to reimplement code.
-> - Right level: user requirements (in @specs/user) or system behavior (in @specs/dev), not implementation specifics; integration/system testing (in @specs/test), not unit testing.
+> - Right level: external behavior users rely on or internal system behavior (organized per @specs/meta.md), not implementation specifics; integration/system testing, not unit testing.
 > - Minimal: essential and concise; every item earns its place; also check with other items.
 > - Well organized: spec packages are finely scoped, with high cohesion and low coupling.
 >
@@ -110,13 +112,13 @@ When Committer commits Initial Changes from a Boss coding intent involving chang
 
 ### CODE-8
 
-When Committer commits Initial Changes from an IR task involving changes only in @specs/user/, @specs/dev/, or @specs/test/, Captain shall relay the IR's task description to Reviewer along with the following prompt:
+When Committer commits Initial Changes from an IR task involving changes only in spec item files, Captain shall relay the IR's task description to Reviewer along with the following prompt:
 > Review the latest commit.
 > Refer to the commit message.
 > Verify any affected spec items are:
 >
 > - Complete & coherent: sufficient for you to reimplement code.
-> - Right level: user requirements (in @specs/user) or system behavior (in @specs/dev), not implementation specifics; integration/system testing (in @specs/test), not unit testing.
+> - Right level: external behavior users rely on or internal system behavior (organized per @specs/meta.md), not implementation specifics; integration/system testing, not unit testing.
 > - Minimal: essential and concise; every item earns its place; also check with other items.
 > - Well organized: spec packages are finely scoped, with high cohesion and low coupling.
 >
@@ -128,7 +130,7 @@ When Committer commits Initial Changes from an IR task involving changes only in
 
 ### CODE-9
 
-When Committer commits Initial Changes from an IR task involving changes only outside @specs/user/, @specs/dev/, and @specs/test/, Captain shall relay the IR's task description to Reviewer along with the following prompt:
+When Committer commits Initial Changes from an IR task involving changes only outside spec item files, Captain shall relay the IR's task description to Reviewer along with the following prompt:
 > Review the latest commit.
 > Refer to the commit message.
 > Flag any issues or improvements (numbered; no duplication).
@@ -140,7 +142,7 @@ When Committer commits Initial Changes from an IR task involving changes only ou
 
 ### CODE-10
 
-When Committer commits Initial Changes from an IR task involving changes both in and outside @specs/user/, @specs/dev/, and @specs/test/, Captain shall relay the IR's task description to Reviewer along with the following prompt:
+When Committer commits Initial Changes from an IR task involving changes both in and outside spec item files, Captain shall relay the IR's task description to Reviewer along with the following prompt:
 > Review the latest commit.
 > Refer to the commit message.
 > Flag any issues or improvements (numbered; no duplication).
@@ -148,7 +150,7 @@ When Committer commits Initial Changes from an IR task involving changes both in
 > Verify any affected spec items are:
 >
 > - Complete & coherent: sufficient for you to reimplement code.
-> - Right level: user requirements (in @specs/user) or system behavior (in @specs/dev), not implementation specifics; integration/system testing (in @specs/test), not unit testing.
+> - Right level: external behavior users rely on or internal system behavior (organized per @specs/meta.md), not implementation specifics; integration/system testing, not unit testing.
 > - Minimal: essential and concise; every item earns its place; also check with other items.
 > - Well organized: spec packages are finely scoped, with high cohesion and low coupling.
 >
@@ -160,13 +162,13 @@ When Committer commits Initial Changes from an IR task involving changes both in
 
 ### CODE-11
 
-When Coder makes unreviewed changes (outside of any Initial Changes) involving changes only in @specs/user/, @specs/dev/, or @specs/test/ without raising rebuttals, Captain shall prompt Reviewer to begin a review round:
+When Coder makes unreviewed changes (outside of any Initial Changes) involving changes only in spec item files without raising rebuttals, Captain shall prompt Reviewer to begin a review round:
 > Review the unstaged and untracked changes in the context of the staged changes.
 > Understand the intent.
 > Verify any affected spec items are:
 >
 > - Complete & coherent: sufficient for you to reimplement code.
-> - Right level: user requirements (in @specs/user) or system behavior (in @specs/dev), not implementation specifics; integration/system testing (in @specs/test), not unit testing.
+> - Right level: external behavior users rely on or internal system behavior (organized per @specs/meta.md), not implementation specifics; integration/system testing, not unit testing.
 > - Minimal: essential and concise; every item earns its place; also check with other items.
 > - Well organized: spec packages are finely scoped, with high cohesion and low coupling.
 >
@@ -178,7 +180,7 @@ When Coder makes unreviewed changes (outside of any Initial Changes) involving c
 
 ### CODE-12
 
-When Coder makes unreviewed changes (outside of any Initial Changes) involving changes only outside @specs/user/, @specs/dev/, and @specs/test/ without raising rebuttals, Captain shall prompt Reviewer to begin a review round:
+When Coder makes unreviewed changes (outside of any Initial Changes) involving changes only outside spec item files without raising rebuttals, Captain shall prompt Reviewer to begin a review round:
 > Review the unstaged and untracked changes in the context of the staged changes.
 > Understand the intent.
 > Flag any issues or improvements (numbered; no duplication).
@@ -190,7 +192,7 @@ When Coder makes unreviewed changes (outside of any Initial Changes) involving c
 
 ### CODE-13
 
-When Coder makes unreviewed changes (outside of any Initial Changes) involving changes both in and outside @specs/user/, @specs/dev/, and @specs/test/ without raising rebuttals, Captain shall prompt Reviewer to begin a review round:
+When Coder makes unreviewed changes (outside of any Initial Changes) involving changes both in and outside spec item files without raising rebuttals, Captain shall prompt Reviewer to begin a review round:
 > Review the unstaged and untracked changes in the context of the staged changes.
 > Understand the intent.
 > Flag any issues or improvements (numbered; no duplication).
@@ -198,7 +200,7 @@ When Coder makes unreviewed changes (outside of any Initial Changes) involving c
 > Verify any affected spec items are:
 >
 > - Complete & coherent: sufficient for you to reimplement code.
-> - Right level: user requirements (in @specs/user) or system behavior (in @specs/dev), not implementation specifics; integration/system testing (in @specs/test), not unit testing.
+> - Right level: external behavior users rely on or internal system behavior (organized per @specs/meta.md), not implementation specifics; integration/system testing, not unit testing.
 > - Minimal: essential and concise; every item earns its place; also check with other items.
 > - Well organized: spec packages are finely scoped, with high cohesion and low coupling.
 >
@@ -216,13 +218,13 @@ When Coder raises rebuttals without making code changes, Captain shall relay the
 
 ### CODE-15
 
-When Coder makes unreviewed changes (outside of any Initial Changes) involving changes only in @specs/user/, @specs/dev/, or @specs/test/ and also raises rebuttals, Captain shall prompt Reviewer to begin a review round and relay the rebuttals along with the following prompt:
+When Coder makes unreviewed changes (outside of any Initial Changes) involving changes only in spec item files and also raises rebuttals, Captain shall prompt Reviewer to begin a review round and relay the rebuttals along with the following prompt:
 > Review the unstaged and untracked changes in the context of the staged changes.
 > Understand the intent.
 > Verify any affected spec items are:
 >
 > - Complete & coherent: sufficient for you to reimplement code.
-> - Right level: user requirements (in @specs/user) or system behavior (in @specs/dev), not implementation specifics; integration/system testing (in @specs/test), not unit testing.
+> - Right level: external behavior users rely on or internal system behavior (organized per @specs/meta.md), not implementation specifics; integration/system testing, not unit testing.
 > - Minimal: essential and concise; every item earns its place; also check with other items.
 > - Well organized: spec packages are finely scoped, with high cohesion and low coupling.
 >
@@ -235,7 +237,7 @@ When Coder makes unreviewed changes (outside of any Initial Changes) involving c
 
 ### CODE-16
 
-When Coder makes unreviewed changes (outside of any Initial Changes) involving changes only outside @specs/user/, @specs/dev/, and @specs/test/ and also raises rebuttals, Captain shall prompt Reviewer to begin a review round and relay the rebuttals along with the following prompt:
+When Coder makes unreviewed changes (outside of any Initial Changes) involving changes only outside spec item files and also raises rebuttals, Captain shall prompt Reviewer to begin a review round and relay the rebuttals along with the following prompt:
 > Review the unstaged and untracked changes in the context of the staged changes.
 > Understand the intent.
 > Flag any issues or improvements (numbered; no duplication).
@@ -248,7 +250,7 @@ When Coder makes unreviewed changes (outside of any Initial Changes) involving c
 
 ### CODE-17
 
-When Coder makes unreviewed changes (outside of any Initial Changes) involving changes both in and outside @specs/user/, @specs/dev/, and @specs/test/ and also raises rebuttals, Captain shall prompt Reviewer to begin a review round and relay the rebuttals along with the following prompt:
+When Coder makes unreviewed changes (outside of any Initial Changes) involving changes both in and outside spec item files and also raises rebuttals, Captain shall prompt Reviewer to begin a review round and relay the rebuttals along with the following prompt:
 > Review the unstaged and untracked changes in the context of the staged changes.
 > Understand the intent.
 > Flag any issues or improvements (numbered; no duplication).
@@ -256,7 +258,7 @@ When Coder makes unreviewed changes (outside of any Initial Changes) involving c
 > Verify any affected spec items are:
 >
 > - Complete & coherent: sufficient for you to reimplement code.
-> - Right level: user requirements (in @specs/user) or system behavior (in @specs/dev), not implementation specifics; integration/system testing (in @specs/test), not unit testing.
+> - Right level: external behavior users rely on or internal system behavior (organized per @specs/meta.md), not implementation specifics; integration/system testing, not unit testing.
 > - Minimal: essential and concise; every item earns its place; also check with other items.
 > - Well organized: spec packages are finely scoped, with high cohesion and low coupling.
 >
@@ -272,7 +274,8 @@ When Coder makes unreviewed changes (outside of any Initial Changes) involving c
 ### CODE-18
 
 When Coder makes any Initial Changes and Reviewer has not played since the last commit, Captain shall prompt Committer:
-> Make a commit of the changes that belong in the repo, following @specs/dev/git.md (reread if necessary).
+> Make a commit of the changes that belong in the repo, following @specs/packages/git.md (reread if necessary).
+> If that spec is absent, follow the legacy @specs/dev/git.md; if neither exists, follow the repository's existing commit conventions and do not search elsewhere.
 > Write the commit message concisely.
 > Coder is <coder-llm>.
 > Format the `Co-authored-by` `<model>` token as the conventional human form of the substituted id (e.g., `claude-opus-4-7` → `Claude-Opus-4.7`, `gpt-5.5` → `GPT-5.5`).
@@ -282,7 +285,8 @@ Result guard: `needsBossInput` — Committing requires additional Boss input or
 ### CODE-19
 
 When Coder makes any Initial Changes and Reviewer has played since the last commit, or Reviewer raises no findings on uncommitted changes and Coder has played since the last commit, Captain shall prompt Committer:
-> Make a commit of the changes that belong in the repo, following @specs/dev/git.md (reread if necessary).
+> Make a commit of the changes that belong in the repo, following @specs/packages/git.md (reread if necessary).
+> If that spec is absent, follow the legacy @specs/dev/git.md; if neither exists, follow the repository's existing commit conventions and do not search elsewhere.
 > Write the commit message concisely.
 > Coder is <coder-llm>; Reviewer is <reviewer-llm>.
 > Format the `Co-authored-by` `<model>` token as the conventional human form of the substituted id (e.g., `claude-opus-4-7` → `Claude-Opus-4.7`, `gpt-5.5` → `GPT-5.5`).

package/reference/sdlc/code.playbook/code.playbook.js

@@ -189,6 +189,10 @@ function extractRequiredFields(description) {
 }
 function buildJudgePrompt(input, finalText) {
     const lines = [];
+    lines.push('This is hidden control work. Do not call tools, inspect files, or ' +
+        'seek external evidence. Decide only from the supplied player output ' +
+        'and outcome descriptions. Reply with exactly one JSON object and no prose.');
+    lines.push('');
     lines.push(`The ${input.player} just produced this output:`);
     lines.push('');
     lines.push('```');

package/reference/sdlc/code.playbook/code.playbook.ts

@@ -290,6 +290,12 @@ function extractRequiredFields(description: string): string[] {
 
 function buildJudgePrompt(input: PlayerInput, finalText: string): string {
   const lines: string[] = [];
+  lines.push(
+    'This is hidden control work. Do not call tools, inspect files, or ' +
+      'seek external evidence. Decide only from the supplied player output ' +
+      'and outcome descriptions. Reply with exactly one JSON object and no prose.',
+  );
+  lines.push('');
   lines.push(`The ${input.player} just produced this output:`);
   lines.push('');
   lines.push('```');

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

@@ -2,7 +2,7 @@
 // SPDX-FileCopyrightText: 2026 SubLang International <https://sublang.ai>
 import { randomUUID } from 'node:crypto';
 import PQueue from 'p-queue';
-import { registerPlaybookAbortCleanup } from '../../../src/xstate-runtime.js';
+import { hiddenControlEnvelope, registerPlaybookAbortCleanup, } from '../../../src/xstate-runtime.js';
 import createDefaultCaptainRuntime from '../captain.playbook/captain.playbook.js';
 class VisibilityControlError extends Error {
     constructor(cause) {
@@ -27,6 +27,47 @@ function visibleChatEnvelope(message) {
         message,
     ].join('\n\n');
 }
+// DR-013 A1: adapters with no provider-enforced tool-restriction surface.
+// Cligent's Codex adapter rejects any `allowedTools` value — including the
+// empty list that expresses tool-free — because the supported Codex SDK
+// cannot enforce one, so requesting it fails every control call before the
+// model is reached. Omitting the option is the only way such an adapter can
+// run a control call at all; its isolation then rests on the authored
+// hidden-judge envelope below rather than on provider enforcement.
+const ADAPTERS_WITHOUT_TOOL_ENFORCEMENT = new Set([
+    'codex',
+]);
+// The tool half of a control call's options. An empty allowlist means "no
+// tools available" and is distinct from omission, which grants the adapter's
+// full native tool surface — so omit only where the empty list would be
+// refused, and keep requesting enforcement whenever the adapter is unknown.
+function controlCallToolOptions(captainAdapter) {
+    if (captainAdapter !== undefined &&
+        ADAPTERS_WITHOUT_TOOL_ENFORCEMENT.has(captainAdapter)) {
+        return {};
+    }
+    return { allowedTools: [] };
+}
+// A runtime-requested allowlist forwarded to the captain agent. The empty
+// list is the runtime's way of saying "tool-free", so it is the only value
+// the host substitutes; a non-empty list is a real restriction and stays
+// fail-closed on an adapter that cannot enforce it.
+function forwardedToolOptions(requested, captainAdapter) {
+    if (requested === undefined)
+        return {};
+    if (requested.length === 0)
+        return controlCallToolOptions(captainAdapter);
+    return { allowedTools: requested };
+}
+function readCaptainAdapter(options) {
+    if (typeof options !== 'object' || options === null)
+        return undefined;
+    const adapter = options.captainAdapter;
+    return typeof adapter === 'string' && adapter.length > 0
+        ? adapter
+        : undefined;
+}
+const hiddenJudgeEnvelope = hiddenControlEnvelope;
 function visibleTurnSummaryEnvelope(input) {
     return [
         'You are the Playbook Captain shell.',
@@ -176,6 +217,10 @@ export function createPlaybookCaptainShell(options, deps = {}) {
     const loadModule = deps.loadModule ?? ((specifier) => import(specifier));
     const createSessionId = deps.createSessionId ?? randomUUID;
     const createCaptainRuntime = deps.createCaptainRuntime ?? createDefaultCaptainRuntime;
+    // DR-013 A1: the launcher passes the resolved captain adapter through
+    // `captain.options`; a raw `--config` launch leaves it undefined, which
+    // keeps the enforced empty allowlist and its fail-closed behavior.
+    const captainAdapter = readCaptainAdapter(options);
     let entries = [];
     let byCommand = new Map();
     let byId = new Map();
@@ -382,9 +427,7 @@ export function createPlaybookCaptainShell(options, deps = {}) {
             const result = await callCaptainQueued(frame, activeContext, prompt, {
                 visibility: options.visibility,
                 resume: options.resume,
-                ...(options.allowedTools === undefined
-                    ? {}
-                    : { allowedTools: options.allowedTools }),
+                ...forwardedToolOptions(options.allowedTools, captainAdapter),
             }, signal);
             return {
                 status: result.status,
@@ -398,7 +441,11 @@ export function createPlaybookCaptainShell(options, deps = {}) {
             if (!activeContext) {
                 throw new Error('callJudge invoked outside a Boss turn');
             }
-            const result = await callCaptainQueued(frame, activeContext, prompt, { visibility: 'hidden', resume: false, allowedTools: [] }, signal);
+            const result = await callCaptainQueued(frame, activeContext, hiddenJudgeEnvelope(prompt), {
+                visibility: 'hidden',
+                resume: false,
+                ...controlCallToolOptions(captainAdapter),
+            }, signal);
             if (result.status !== 'ok') {
                 throw new Error(result.error ?? `callCaptain status "${result.status}"`);
             }
@@ -1101,13 +1148,21 @@ export function createPlaybookCaptainShell(options, deps = {}) {
         }
     };
     const callVisibleChat = async (frame, context, message) => {
-        const result = await callCaptainQueued(frame, context, visibleChatEnvelope(message), { visibility: 'visible', resume: false, allowedTools: [] }, context.signal);
+        const result = await callCaptainQueued(frame, context, visibleChatEnvelope(message), {
+            visibility: 'visible',
+            resume: false,
+            ...controlCallToolOptions(captainAdapter),
+        }, context.signal);
         if (result.status !== 'ok') {
             throw new Error(result.error ?? `callCaptain status "${result.status}"`);
         }
     };
     const callVisibleTurnSummary = async (frame, context, input) => {
-        const result = await callCaptainQueued(frame, context, visibleTurnSummaryEnvelope(input), { visibility: 'visible', resume: false, allowedTools: [] }, context.signal);
+        const result = await callCaptainQueued(frame, context, visibleTurnSummaryEnvelope(input), {
+            visibility: 'visible',
+            resume: false,
+            ...controlCallToolOptions(captainAdapter),
+        }, context.signal);
         if (result.status !== 'ok') {
             throw new Error(result.error ?? `callCaptain status "${result.status}"`);
         }
@@ -1151,7 +1206,11 @@ export function createPlaybookCaptainShell(options, deps = {}) {
         }
         let decision;
         try {
-            const result = await callCaptainQueued(leaf, context, hiddenLifecycleEnvelope(turn.prompt), { visibility: 'hidden', resume: false, allowedTools: [] }, context.signal);
+            const result = await callCaptainQueued(leaf, context, hiddenLifecycleEnvelope(turn.prompt), {
+                visibility: 'hidden',
+                resume: false,
+                ...controlCallToolOptions(captainAdapter),
+            }, context.signal);
             if (result.status === 'ok' && result.finalText !== undefined) {
                 decision = parseLifecycleDecision(result.finalText);
             }

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

@@ -20,7 +20,10 @@ import type {
   PlaybookRuntime,
   PlaybookState,
 } from '@sublang/playbook/runtime';
-import { registerPlaybookAbortCleanup } from '../../../src/xstate-runtime.js';
+import {
+  hiddenControlEnvelope,
+  registerPlaybookAbortCleanup,
+} from '../../../src/xstate-runtime.js';
 import createDefaultCaptainRuntime from '../captain.playbook/captain.playbook.js';
 import type { PlaybookSummaryPolicy, RegistryPlayer } from './code.registry.js';
 
@@ -154,6 +157,56 @@ function visibleChatEnvelope(message: string): string {
   ].join('\n\n');
 }
 
+// DR-013 A1: adapters with no provider-enforced tool-restriction surface.
+// Cligent's Codex adapter rejects any `allowedTools` value — including the
+// empty list that expresses tool-free — because the supported Codex SDK
+// cannot enforce one, so requesting it fails every control call before the
+// model is reached. Omitting the option is the only way such an adapter can
+// run a control call at all; its isolation then rests on the authored
+// hidden-judge envelope below rather than on provider enforcement.
+const ADAPTERS_WITHOUT_TOOL_ENFORCEMENT: ReadonlySet<string> = new Set([
+  'codex',
+]);
+
+// The tool half of a control call's options. An empty allowlist means "no
+// tools available" and is distinct from omission, which grants the adapter's
+// full native tool surface — so omit only where the empty list would be
+// refused, and keep requesting enforcement whenever the adapter is unknown.
+function controlCallToolOptions(
+  captainAdapter: string | undefined,
+): { allowedTools?: readonly string[] } {
+  if (
+    captainAdapter !== undefined &&
+    ADAPTERS_WITHOUT_TOOL_ENFORCEMENT.has(captainAdapter)
+  ) {
+    return {};
+  }
+  return { allowedTools: [] };
+}
+
+// A runtime-requested allowlist forwarded to the captain agent. The empty
+// list is the runtime's way of saying "tool-free", so it is the only value
+// the host substitutes; a non-empty list is a real restriction and stays
+// fail-closed on an adapter that cannot enforce it.
+function forwardedToolOptions(
+  requested: readonly string[] | undefined,
+  captainAdapter: string | undefined,
+): { allowedTools?: readonly string[] } {
+  if (requested === undefined) return {};
+  if (requested.length === 0) return controlCallToolOptions(captainAdapter);
+  return { allowedTools: requested };
+}
+
+function readCaptainAdapter(options: unknown): string | undefined {
+  if (typeof options !== 'object' || options === null) return undefined;
+  const adapter = (options as Record<string, unknown>).captainAdapter;
+  return typeof adapter === 'string' && adapter.length > 0
+    ? adapter
+    : undefined;
+}
+
+const hiddenJudgeEnvelope = hiddenControlEnvelope;
+
 function visibleTurnSummaryEnvelope(input: {
   playbookId: string;
   submittedText: string;
@@ -368,6 +421,10 @@ export function createPlaybookCaptainShell(
   const createCaptainRuntime: NonNullable<
     PlaybookCaptainDeps['createCaptainRuntime']
   > = deps.createCaptainRuntime ?? createDefaultCaptainRuntime;
+  // DR-013 A1: the launcher passes the resolved captain adapter through
+  // `captain.options`; a raw `--config` launch leaves it undefined, which
+  // keeps the enforced empty allowlist and its fail-closed behavior.
+  const captainAdapter = readCaptainAdapter(options);
   let entries: readonly PlaybookCaptainRegistryEntry[] = [];
   let byCommand = new Map<string, PlaybookCaptainRegistryEntry>();
   let byId = new Map<string, PlaybookCaptainRegistryEntry>();
@@ -650,9 +707,7 @@ export function createPlaybookCaptainShell(
         {
           visibility: options.visibility,
           resume: options.resume,
-          ...(options.allowedTools === undefined
-            ? {}
-            : { allowedTools: options.allowedTools }),
+          ...forwardedToolOptions(options.allowedTools, captainAdapter),
         },
         signal,
       );
@@ -671,8 +726,12 @@ export function createPlaybookCaptainShell(
       const result = await callCaptainQueued(
         frame,
         activeContext,
-        prompt,
-        { visibility: 'hidden', resume: false, allowedTools: [] },
+        hiddenJudgeEnvelope(prompt),
+        {
+          visibility: 'hidden',
+          resume: false,
+          ...controlCallToolOptions(captainAdapter),
+        },
         signal,
       );
       if (result.status !== 'ok') {
@@ -1495,7 +1554,11 @@ export function createPlaybookCaptainShell(
       frame,
       context,
       visibleChatEnvelope(message),
-      { visibility: 'visible', resume: false, allowedTools: [] },
+      {
+        visibility: 'visible',
+        resume: false,
+        ...controlCallToolOptions(captainAdapter),
+      },
       context.signal,
     );
     if (result.status !== 'ok') {
@@ -1519,7 +1582,11 @@ export function createPlaybookCaptainShell(
       frame,
       context,
       visibleTurnSummaryEnvelope(input),
-      { visibility: 'visible', resume: false, allowedTools: [] },
+      {
+        visibility: 'visible',
+        resume: false,
+        ...controlCallToolOptions(captainAdapter),
+      },
       context.signal,
     );
     if (result.status !== 'ok') {
@@ -1577,7 +1644,11 @@ export function createPlaybookCaptainShell(
         leaf,
         context,
         hiddenLifecycleEnvelope(turn.prompt),
-        { visibility: 'hidden', resume: false, allowedTools: [] },
+        {
+          visibility: 'hidden',
+          resume: false,
+          ...controlCallToolOptions(captainAdapter),
+        },
         context.signal,
       );
       if (result.status === 'ok' && result.finalText !== undefined) {

package/reference/sdlc/code.playbook/playbook.config.template.yaml

@@ -6,39 +6,25 @@
 # The launcher injects captain.from and the namespaced <id>-<role> host
 # players, then launches cligent's tmux-play under the Playbook Captain shell.
 
-# Reusable agent settings. A profile id must not be an adapter shorthand
-# (claude, codex). Reference a profile by id from captain / players below.
-# Profile ids name the underlying agent/model (e.g. claude-opus,
-# codex-gpt) so they read distinctly from the captain / coder / reviewer
-# player roles that reference them.
+# Every agent — the Captain and each playbook role — carries its own
+# settings inline: an adapter shorthand (claude, codex) or a block with
+# adapter/model/effort/permissions. Retuning one agent never changes
+# another.
 # Every seeded agent runs in cligent's protected auto mode
 # (permissions.mode: auto): claude maps it to permissionMode auto, codex to
 # on-request + auto_review. Codex roles also grant writablePaths: ['.git']
 # so commit turns can write git metadata under the codex sandbox.
-profiles:
-  claude-opus:
-    adapter: claude
-    model: claude-opus-4-8
-    reasoningEffort: high
-    permissions:
-      mode: auto
-  claude-opus-1m:
-    adapter: claude
-    model: claude-opus-4-8[1m]
-    reasoningEffort: xhigh
-    permissions:
-      mode: auto
-  codex-gpt:
-    adapter: codex
-    model: gpt-5.5
-    reasoningEffort: xhigh
-    permissions:
-      mode: auto
-      writablePaths: ['.git']
 
-# The Captain/Judge agent: a profile id, an adapter shorthand, or a full
-# tmux-play agent block (which may carry a `profile:` key).
-captain: claude-opus
+# The Captain/Judge agent.
+# Captain routing/adjudication calls run tool-free. Claude enforces that at
+# the provider level; the codex adapter cannot enforce a tool list, so a
+# codex captain degrades to a prompt-level restriction (DR-013 A1).
+captain:
+  adapter: claude
+  model: claude-opus-4-8
+  effort: high
+  permissions:
+    mode: auto
 
 # Host notifications. Omitting turn_aborted resolves it to off.
 notifications:
@@ -53,8 +39,19 @@ playbooks:
   code:
     from: "@sublang/playbook/code/registry"
     players:
-      coder: claude-opus-1m
-      reviewer: codex-gpt
+      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: coder
 
 # The DISCUSS playbook: two agents converge on spec items or decision
@@ -63,8 +60,17 @@ playbooks:
 #  discuss:
 #    from: "@sublang/playbook/discuss/registry"
 #    players:
-#      host: claude-opus
-#      participant: codex-gpt
+#      host:
+#        adapter: claude
+#        model: claude-opus-4-8
+#        permissions:
+#          mode: auto
+#      participant:
+#        adapter: codex
+#        model: gpt-5.5
+#        permissions:
+#          mode: auto
+#          writablePaths: ['.git']
 #    committer: host
 
 # Non-interactive `playbook run` defaults (optional). Each value is an