@sublang/playbook 5.0.0 → 7.0.0

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

@@ -1,294 +1,82 @@
 <!-- SPDX-License-Identifier: Apache-2.0 -->
 <!-- SPDX-FileCopyrightText: 2026 SubLang International <https://sublang.ai> -->
 
-# CODE: Coding Workflow
+# CODE: Commit-Based Coding Workflow
 
 Players:
 
 - Coder
-- Reviewer
-- Committer = Coder | Reviewer
 
 ## Coder
 
 ### CODE-1
 
-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/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.
-The resulting changes are Initial Changes.
+When the first coding phase begins, Captain shall prompt Coder:
 
-### CODE-2
-
-When Reviewer raises any findings, Captain shall relay them to Coder along with the following prompt:
-> For each review item below for the above changes, challenge or accept it, with strong reasoning, solid evidence, and comprehensive thinking.
-> Stage all current changes that belong in the repo before making any edits, and leave your edits unstaged/untracked.
-
-### CODE-3
-
-When a new IR or IR task passes review and is committed, Captain shall prompt Coder:
-> Continue to implement IR-<#> if not all deliverables and tasks are done.
-> Implement one task at a time (including corresponding tests if any).
-> Stop after each task for review — do not commit yet.
-> If relevant, mark progress in the IR.
-The resulting changes are Initial Changes.
-
-### CODE-4
-
-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 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.
-> Avoid implementation specifics.
-> Avoid redundant spec items.
-> Ensure @specs/map.md reflects the changes.
-
-## Reviewer
-
-For each finding in a review round, Coder either addresses it with changes or challenges it with a rebuttal.
-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 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: 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.
->
-> Flag anything missing, redundant, over-specified, or under-specified.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-
-### CODE-6
-
-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).
-> Think thoroughly — don't just approve or reject.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-
-### CODE-7
-
-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).
-> Think thoroughly — don't just approve or reject.
-> Verify any affected spec items are:
+> > <caller-input>
+> > <run-results>
 >
-> - Complete & coherent: sufficient for you to reimplement code.
-> - 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.
->
-> Flag anything missing, redundant, over-specified, or under-specified.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-
-### CODE-8
-
-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:
+> Assess whether the coding intent can be completed well in one commit.
+> If yes, implement and test it, update the affected specs, and ensure @specs/map.md remains accurate.
+> Otherwise, decompose it into tasks sized to exactly one commit each, add a new IR under @specs/intents, and do not implement any IR task in this phase.
+> Plan affected spec updates before, with, or after their corresponding code changes, either as standalone IR tasks or as explicit work within related tasks.
 >
-> - Complete & coherent: sufficient for you to reimplement code.
-> - 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.
+> Consult @specs/map.md for relevant context and @specs/meta.md for spec requirements, if needed.
 >
-> Flag anything missing, redundant, over-specified, or under-specified.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
+> Do not re-run tests or builds whose inputs have not changed since any previous reported run.
+> Make the phase's minimal changes and then one new commit, following @specs/packages/git.md; never amend an existing commit.
+> Make the commit message explain concisely what changed and why, including relevant verification.
+> Report it as exactly one final-response line beginning `Commit: `, followed only by the exact commit identity.
+> Coder is <coder-llm>; format the model token in conventional human form.
 
-### CODE-9
+Results:
+- `directCommit`: Coder completed and committed the direct implementation phase. Output shall include `coderOutput: <verbatim final text>` and `latestCommit: <commit identity>`.
+- `irCommit`: Coder created and committed a new IR without implementing an IR task. Output shall include `coderOutput: <verbatim final text>`, `latestCommit: <commit identity>`, `irNumber`, and `irTask` naming the exact next unfinished task.
 
-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).
-> Think thoroughly — don't just approve or reject.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-
-### CODE-10
-
-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).
-> Think thoroughly — don't just approve or reject.
-> Verify any affected spec items are:
->
-> - Complete & coherent: sufficient for you to reimplement code.
-> - 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.
->
-> Flag anything missing, redundant, over-specified, or under-specified.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-
-### CODE-11
-
-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: 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.
->
-> Flag anything missing, redundant, over-specified, or under-specified.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-
-### CODE-12
-
-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).
-> Think thoroughly — don't just approve or reject.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-
-### CODE-13
-
-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).
-> Think thoroughly — don't just approve or reject.
-> Verify any affected spec items are:
->
-> - Complete & coherent: sufficient for you to reimplement code.
-> - 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.
->
-> Flag anything missing, redundant, over-specified, or under-specified.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-
-### CODE-14
+### CODE-2
 
-When Coder raises rebuttals without making code changes, Captain shall relay them to Reviewer along with the following prompt:
-> For each rebuttal below, challenge or accept it, with strong reasoning, solid evidence, and comprehensive thinking.
-> Do not edit files or commit; report findings only.
+When the first phase has one new commit, Captain shall call playbook `review`:
 
-### CODE-15
+> > Initial intent: <caller-input>
+> > Coder output: <coder-output>
 
-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: 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.
->
-> Flag anything missing, redundant, over-specified, or under-specified.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-> For each rebuttal below, challenge or accept it, with strong reasoning, solid evidence, and comprehensive thinking.
+Workflow outcomes:
+- Exact approval after a direct implementation phase completes `code`.
+- Exact approval after a new-IR phase continues with its next unfinished IR task.
+- An authored `review` abort, error, or invalid approval terminates `code` with the failure and last `code`-owned commit.
+- Any other nested-call error parks `code` as failed and retains the control-plane error.
 
-### CODE-16
-
-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).
-> Think thoroughly — don't just approve or reject.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-> For each rebuttal below, challenge or accept it, with strong reasoning, solid evidence, and comprehensive thinking.
+### CODE-3
 
-### CODE-17
+When a reviewed IR has a next unfinished task, Captain shall prompt Coder:
 
-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).
-> Think thoroughly — don't just approve or reject.
-> Verify any affected spec items are:
+> > <ir-task>
+> > <run-results>
 >
-> - Complete & coherent: sufficient for you to reimplement code.
-> - 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.
+> Read IR-<#> and implement exactly the next unfinished task, including corresponding tests or specs if any.
+> Do not implement a later task in this phase.
+> Mark the IR's progress and deliverables when relevant.
+> If the IR will be finished after this phase, double-check that all acceptance criteria are met.
 >
-> Flag anything missing, redundant, over-specified, or under-specified.
-> For context discovery, @specs/map.md indexes all spec files and @specs/meta.md describes the spec format.
-> Verify @specs/map.md reflects the changes.
-> If the change is ready to commit or push, don't raise nitpicks.
-> Do not edit files or commit; report findings only.
-> For each rebuttal below, challenge or accept it, with strong reasoning, solid evidence, and comprehensive thinking.
-
-## Committer
+> Do not re-run tests or builds whose inputs have not changed since any previous reported run.
+> Make the phase's minimal changes and then one new commit, following @specs/packages/git.md; never amend an existing commit.
+> Make the commit message explain concisely what changed and why, including relevant verification.
+> Report it as exactly one final-response line beginning `Commit: `, followed only by the exact commit identity.
+> Coder is <coder-llm>; format the model token in conventional human form.
 
-### CODE-18
+Results:
+- `moreTasks`: Coder completed and committed the current IR task and at least one task remains. Output shall include `coderOutput: <verbatim final text>`, `latestCommit: <commit identity>`, and `irTask` naming the exact next unfinished task.
+- `finalTask`: Coder completed and committed the final IR task. Output shall include `coderOutput: <verbatim final text>` and `latestCommit: <commit identity>`.
 
-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/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`).
-
-Result guard: `needsBossInput` — Committing requires additional Boss input or rescoping rather than a specific answer to resume this same state.
+### CODE-4
 
-### CODE-19
+When an IR-task phase has one new commit, Captain shall call playbook `review`:
 
-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/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`).
+> > IR task: <ir-task>
+> > Coder output: <coder-output>
 
-Result guard: `needsBossInput` — Committing requires additional Boss input or rescoping rather than a specific answer to resume this same state.
+Workflow outcomes:
+- Exact approval after a nonfinal IR-task phase continues with its next unfinished IR task.
+- Exact approval after the final IR-task phase completes `code`.
+- An authored `review` abort, error, or invalid approval terminates `code` with the failure and last `code`-owned commit.
+- Any other nested-call error parks `code` as failed and retains the control-plane error.

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

@@ -1,54 +1,15 @@
-import { normalizeErrorCompact, normalizeErrorFull, type PlaybookPlayerInput, type RuntimeBoundaryCalls } from '../../../src/xstate-runtime.js';
-import { type PlayerInput, type PlayerOutput, type CodingEvent, type CodingInput } from './code.fsm.js';
-import type { CaptainCallOptions, CaptainResult, JsonValue, NormalizedError, PlayerCallOptions, PlaybookCallRequest, PlaybookCallResult, PlaybookCallStart, PlaybookPendingCall, PlaybookRunResult, PlaybookRuntimeSnapshot, PlaybookSession, PlaybookState, PlaybookStateValue, PlaybookTraceEvent, PlaybookTraceType, PlaybookPorts, PlaybookRuntime, PlaybookRuntimeFactory, PlayerResult } from '@sublang/playbook/runtime';
-export type { CaptainCallOptions, CaptainResult, JsonValue, NormalizedError, PlayerCallOptions, PlaybookCallRequest, PlaybookCallResult, PlaybookCallStart, PlaybookPendingCall, PlaybookRunResult, PlayerResult, PlaybookPorts, PlaybookSession, PlaybookState, PlaybookStateValue, PlaybookTraceEvent, PlaybookTraceType, PlaybookRuntime, PlaybookRuntimeFactory, PlaybookRuntimeSnapshot, };
+import { type CodingInput, type PlayerInput } from './code.fsm.js';
+import type { CaptainCallOptions, CaptainResult, JsonValue, NormalizedError, PlayerCallOptions, PlaybookCallRequest, PlaybookCallResult, PlaybookCallStart, PlaybookControlReceipt, PlaybookControlView, PlaybookPendingCall, PlaybookPorts, PlaybookRunResult, PlaybookRuntime, PlaybookRuntimeFactory, PlaybookRuntimeSnapshot, PlaybookSession, PlaybookState, PlaybookStateValue, PlaybookTraceEvent, PlaybookTraceType, PlayerResult, PlayerSessionStore } from '@sublang/playbook/runtime';
+export type { CaptainCallOptions, CaptainResult, JsonValue, NormalizedError, PlayerCallOptions, PlaybookCallRequest, PlaybookCallResult, PlaybookCallStart, PlaybookControlReceipt, PlaybookControlView, PlaybookPendingCall, PlaybookPorts, PlaybookRunResult, PlaybookRuntime, PlaybookRuntimeFactory, PlaybookRuntimeSnapshot, PlaybookSession, PlaybookState, PlaybookStateValue, PlaybookTraceEvent, PlaybookTraceType, PlayerResult, PlayerSessionStore, };
 export type CodePlaybookOptions = CodingInput;
-declare function normalizeEventForTelemetry(event: unknown): unknown;
+/**
+ * Preserve authored Markdown quote markers around every line of relayed
+ * runtime text. The generic composer preserves the marker itself; CODE's
+ * override additionally keeps a multiline value inside that quote.
+ */
 declare function composePlayerPrompt(input: PlayerInput): string;
-declare function resolvePlayerId(input: PlayerInput): string;
-declare function adjudicate(input: PlayerInput, finalText: string, ports: PlaybookPorts, signal: AbortSignal, boundary?: RuntimeBoundaryCalls): Promise<PlayerOutput>;
-declare function classifyBossText(text: string, ports: PlaybookPorts, signal: AbortSignal, snapshotOrState?: unknown, boundary?: RuntimeBoundaryCalls): Promise<CodingEvent | undefined>;
-declare function captainBridge(ports: PlaybookPorts, getActiveSignal?: () => AbortSignal | undefined, boundary?: RuntimeBoundaryCalls, onControlPlaneError?: (error: unknown) => void): import("xstate").PromiseActorLogic<import("../../../src/xstate-playbook-runtime.js").PlaybookActorOutput, PlaybookPlayerInput>;
-interface StateMetadata {
-    player: PlayerInput['player'];
-    sourceItem: string;
-    label: string;
-}
-type BossReplyQuestionId = NonNullable<Extract<CodingEvent, {
-    type: 'BOSS_REPLY';
-}>['questionId']>;
-interface PendingBossQuestionForStatus {
-    questionId: BossReplyQuestionId;
-    resumeStateId: string;
-    sourceItem: string;
-    player: string;
-    question: string;
-}
-declare function pendingBossQuestionFromContext(context: Record<string, unknown>): PendingBossQuestionForStatus | undefined;
-declare function formatAwaitBossReplyQuestion(context: Record<string, unknown>): string;
-declare function formatAwaitBossReplyMarker(context: Record<string, unknown>): string;
-declare function formatStateEntry(stateId: string): string | undefined;
-declare function formatTransition(event: unknown): string | undefined;
-declare function formatClassification(eventType: string): string;
-declare function stateTelemetryPayload(from: unknown, to: string, event: unknown, context: Record<string, unknown>): Record<string, unknown>;
 export declare const _internal: {
     composePlayerPrompt: typeof composePlayerPrompt;
-    resolvePlayerId: typeof resolvePlayerId;
-    adjudicate: typeof adjudicate;
-    classifyBossText: typeof classifyBossText;
-    captainBridge: typeof captainBridge;
-    STATE_LABELS: Readonly<Record<string, string>>;
-    stateMetadata: ReadonlyMap<string, StateMetadata>;
-    pendingBossQuestionFromContext: typeof pendingBossQuestionFromContext;
-    formatAwaitBossReplyQuestion: typeof formatAwaitBossReplyQuestion;
-    formatAwaitBossReplyMarker: typeof formatAwaitBossReplyMarker;
-    formatStateEntry: typeof formatStateEntry;
-    formatTransition: typeof formatTransition;
-    formatClassification: typeof formatClassification;
-    stateTelemetryPayload: typeof stateTelemetryPayload;
-    normalizeErrorCompact: typeof normalizeErrorCompact;
-    normalizeErrorFull: typeof normalizeErrorFull;
-    normalizeEventForTelemetry: typeof normalizeEventForTelemetry;
     VERBATIM_PAYLOAD_FIELDS: ReadonlySet<string>;
 };
 declare const createPlaybookRuntime: PlaybookRuntimeFactory<CodePlaybookOptions>;