cool-workflow 0.1.87 → 0.1.89

package/dist/workflow-api.js

@@ -3,8 +3,10 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.workflow = workflow;
 exports.phase = phase;
 exports.parallel = parallel;
+exports.loop = loop;
 exports.createWorkflowApi = createWorkflowApi;
 exports.agent = agent;
+exports.subWorkflow = subWorkflow;
 exports.artifact = artifact;
 exports.input = input;
 exports.slugify = slugify;
@@ -46,19 +48,50 @@ function phase(name, tasks, options = {}) {
 function parallel(name, tasks, options = {}) {
     return phase(name, tasks, { mode: "parallel", ...options });
 }
+/** A BOUNDED DYNAMIC LOOP phase: `tasks` are a per-round template. After each round
+ *  completes, the registered `until` predicate decides whether to run another round
+ *  (a fresh appended phase with the same tasks, round-suffixed ids) or stop; capped
+ *  at `maxRounds`. Sugar over phase() that sets `loop`; plain phases are unaffected. */
+function loop(name, tasks, spec, options = {}) {
+    if (!spec || typeof spec.maxRounds !== "number" || spec.maxRounds < 1) {
+        throw new Error(`loop ${name} requires a positive integer maxRounds`);
+    }
+    const until = spec.until;
+    const valid = until
+        && ((until.kind === "predicate" && Boolean(until.ref))
+            || (until.kind === "budget-target" && typeof until.target === "number" && until.target > 0));
+    if (!valid) {
+        throw new Error(`loop ${name} requires until: { kind: "predicate", ref } or { kind: "budget-target", target }`);
+    }
+    return phase(name, tasks, { loop: { maxRounds: Math.floor(spec.maxRounds), until }, ...options });
+}
 function createWorkflowApi() {
     return {
         workflow,
         phase,
         parallel,
+        loop,
         agent,
         artifact,
+        subWorkflow,
         input
     };
 }
 function agent(id, prompt, options = {}) {
     return task("agent", id, prompt, options);
 }
+/** A task fulfilled by an inline SUB-WORKFLOW: instead of spawning an agent, the
+ *  drive plans + drives the child `appId` and binds its report back as this task's
+ *  result. The prompt is recorded for provenance but is not sent to an agent. */
+function subWorkflow(id, appId, options = {}) {
+    if (!appId)
+        throw new Error(`subWorkflow task ${id} requires an appId`);
+    const { inputs, bindResult, prompt, ...rest } = options;
+    return task("agent", id, prompt || `Delegate to sub-workflow app: ${appId}`, {
+        ...rest,
+        subWorkflow: { appId, ...(inputs ? { inputs } : {}), ...(bindResult ? { bindResult } : {}) }
+    });
+}
 function artifact(id, prompt, options = {}) {
     return task("artifact", id, prompt, options);
 }

package/dist/workflow-app-framework.js

@@ -522,6 +522,26 @@ function validatePhase(phaseDefinition, issues, pathName, seenPhaseIds) {
     if (!Array.isArray(phaseValue.tasks) || !phaseValue.tasks.length) {
         issues.push(issue("workflow-phase-tasks", `Workflow phase ${String(phaseValue.id || phaseValue.name || "")} must have tasks`, joinPath(pathName, "tasks")));
     }
+    // Bounded dynamic loop spec (fail-closed shape check; the predicate ref need not be
+    // registered at validation time — the expander stops fail-closed if it is missing).
+    if (phaseValue.loop !== undefined) {
+        const loop = phaseValue.loop;
+        if (!isRecord(loop)) {
+            issues.push(issue("workflow-phase-loop", "Workflow phase loop must be an object", joinPath(pathName, "loop")));
+        }
+        else {
+            if (typeof loop.maxRounds !== "number" || !Number.isInteger(loop.maxRounds) || loop.maxRounds < 1) {
+                issues.push(issue("workflow-phase-loop-maxrounds", "loop.maxRounds must be a positive integer", joinPath(pathName, "loop.maxRounds")));
+            }
+            const until = loop.until;
+            const validUntil = isRecord(until)
+                && ((until.kind === "predicate" && isNonEmptyString(until.ref))
+                    || (until.kind === "budget-target" && typeof until.target === "number" && until.target > 0));
+            if (!validUntil) {
+                issues.push(issue("workflow-phase-loop-until", 'loop.until must be { kind: "predicate", ref } or { kind: "budget-target", target }', joinPath(pathName, "loop.until")));
+            }
+        }
+    }
 }
 function validateTask(taskDefinition, issues, pathName, seenTaskIds, options) {
     if (!isRecord(taskDefinition)) {

package/docs/agent-delegation-drive.7.md

@@ -309,3 +309,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+Orchestration-parity for the agent drive: `run --drive --incremental` step-level resume (unchanged-input tasks replay from a content-addressed cache, zero re-spawns), inline `subWorkflow()` nesting (a task runs a child app and binds its verified report back, bounded depth + cycle guard, no telemetry fabricated), bounded dynamic `loop()` phases that expand at runtime under a static replay-stable cap, and a `claude -p` wrapper now on the canonical result contract.
+
+## 0.1.89 (v0.1.89)
+
+The one-command `cw -q` headline now routes the question and defaults the repo to the caller cwd before driving the agent; the delegation contract, drive, and accept path are unchanged.

package/docs/capability-topology-registry.7.md

@@ -2,69 +2,92 @@
 
 ## Name
 
-`capability-dispatcher`, `registerCapabilityHandler`, `registerTopology` — open registries for agent-driven CW extension
+`capability-registry`, `registerTopology` — the declared capability contract and the open topology registry for agent-driven CW extension
 
 ## Description
 
-v0.1.53 adds two open registries. They let agents grow CW at runtime
-with no need to wire things by hand in many files. New capabilities put
-themselves in the registry and then work by themselves across CLI, MCP, and Workbench. New topologies put
-themselves in the registry too and then come up by themselves in `topology list`, `topology validate`, and `topology apply`.
-
-BSD way: keep **mechanism** (Map / pipe) apart from **policy** (entries).
-Fail-closed on unknown ids.
+CW keeps two layers here. The **capability registry**
+(`src/capability-registry.ts`) is the one declared source of truth for every
+capability CW exposes; it is read at build/check time, not written to at
+runtime. The **topology registry** (`src/topology.ts`) is an open runtime
+registry: new topologies put themselves in it with `registerTopology()` and
+then come up by themselves in `topology list`, `topology validate`, and
+`topology apply`.
+
+> History: v0.1.53 also shipped a dynamic *capability* dispatcher
+> (`capability-dispatcher.ts`, `registerCapabilityHandler`,
+> `dispatchCapability`, `resolveCliPath`, `resolveMcpTool`) meant to let
+> capabilities register handlers and be routed at runtime. It had zero call
+> sites — the handler map was always empty and every dispatch path was
+> unreachable — so it was removed as dead code in v0.1.81 (#131). Capabilities
+> are **declared**, not runtime-registered; see below. (The unrelated
+> `cw dispatch` command, which writes a subagent dispatch manifest, is a normal
+> declared capability, not that dispatcher.)
+
+BSD way: keep **mechanism** (the registry / the open Map) apart from **policy**
+(the entries). Fail-closed on unknown ids.
 
 ## Capability Registry
 
-### Interface
+The capability registry, `src/capability-registry.ts`, is the SINGLE declared
+source of truth for every capability CW exposes — and the contract both front
+doors (CLI and MCP) are checked against. It is a static, read-only array of
+descriptors, `CAPABILITY_REGISTRY`. There is no runtime "register a handler"
+seam and no dynamic dispatcher: capabilities are data here, not code that wires
+itself in.
 
-```typescript
-interface CapabilityHandler {
-  descriptor: CapabilityDescriptor;
-  run(args: Record<string, unknown>, ctx: CapabilityContext): unknown | Promise<unknown>;
-}
+### Descriptor
 
-interface CapabilityContext {
-  runner: CoolWorkflowRunner;
-  cwd: string;
+```typescript
+interface CapabilityDescriptor {
+  capability: string;   // canonical dot-namespaced id, e.g. "worker.list"
+  summary: string;      // one-line description
+  entry: string;        // the ONE shared core entry both surfaces route through
+  surface: "both" | "cli-only" | "mcp-only";
+  cli?: { path: string[]; jsonMode: "default" | "flag" | "human" };
+  mcp?: { tool: string; requiredArgs?: string[] };
+  payloadIdentical?: boolean;  // CLI --json === MCP result (default true for "both")
+  reason?: string;             // required when surface !== "both" or payloadIdentical === false
 }
 ```
 
-### Registering a new capability
+### Adding a capability
+
+A capability is declared once, as data, in `CAPABILITY_REGISTRY`, against one
+shared core `entry`:
 
 ```typescript
-import { registerCapabilityHandler } from "./capability-registry";
-
-registerCapabilityHandler({
-  descriptor: {
-    capability: "my.new.tool",          // canonical dot-namespaced id
-    summary: "Does something useful.",   // one-line description
-    entry: "myNewTool",                  // core entry name
-    surface: "both",                     // "both" | "cli-only" | "mcp-only"
-    cli: { path: ["my", "new-tool"], jsonMode: "default" },
-    mcp: { tool: "cw_my_new_tool" }
-  },
-  run: async (args, ctx) => {
-    // ctx.runner exposes all orchestrator methods
-    return ctx.runner.listWorkflows();
-  }
-});
+{
+  capability: "my.new.tool",
+  summary: "Does something useful.",
+  entry: "myNewTool",
+  surface: "both",
+  cli: { path: ["my", "new-tool"], jsonMode: "default" },
+  mcp: { tool: "cw_my_new_tool" }
+}
 ```
 
+`cli.ts` and `mcp-server.ts` each route their surface to the shared `entry` with
+their own explicit `switch` routing (plus a few `if (action === …)` branches).
+The registry is what those switches are validated against, not something they
+call into — there is no fallback dynamic dispatch.
+
 ### How it works
 
-1. `registerCapabilityHandler()` keeps the handler in a `Map<string, CapabilityHandler>`
-2. CLI: `resolveCliPath(["my", "new-tool"])` turns the CLI path into the capability id
-3. MCP: `resolveMcpTool("cw_my_new_tool")` turns the tool name into the capability id
-4. `dispatchCapability(id, args, ctx)` calls `handler.run(args, ctx)`
-5. Both the CLI and MCP surfaces drop through to the dynamic dispatcher when
-   their hardcoded switch statements do not match an unknown command/tool
+1. `CAPABILITY_REGISTRY` declares every capability once — one row per capability.
+2. CLI: `cli.ts` matches the command in its explicit `switch` and calls the core `entry`.
+3. MCP: `mcp-server.ts` matches the tool name in its explicit `switch` and calls the same `entry`.
+4. The parity gate (`scripts/parity-check.js --check`) fails closed on any drift:
+   a CLI command or MCP tool live on one surface but absent on the other or
+   undeclared, an undeclared payload divergence, or a surface-specific capability
+   with no recorded `reason`.
 
-### Existing capabilities
+### How many capabilities
 
-All 182 capabilities that are there now keep working through their hardcoded switch
-cases in `cli.ts` and `mcp-server.ts`. The dynamic dispatch is a **fallback**
-— it turns on only for commands/tools not found in the old switches.
+Run `node plugins/cool-workflow/scripts/parity-check.js --check` and read
+`registrySize` for the live count (199 at the time of writing). The full
+CLI <-> MCP matrix lives in `docs/cli-mcp-parity.7.md`, which is generated from
+the same registry.
 
 ## Topology Registry
 
@@ -160,8 +183,8 @@ expansion. Now it reads `role.count` on each role spec:
 
 ## See Also
 
-- `capability-registry.ts` — the one true source for all capabilities
-- `capability-dispatcher.ts` — the thin Map-based dispatch pipe
+- `capability-registry.ts` — the one declared source for all capabilities
+- `capability-core.ts` — the shared core entries both surfaces route through
 - `topology.ts` — topology definitions and the registry
 - `types/topology.ts` — topology type definitions
 - `docs/cli-mcp-parity.7.md` — CLI <-> MCP parity gate

package/docs/cli-mcp-parity.7.md

@@ -82,13 +82,16 @@ relationship. `identical` means `cw <cmd> --json` is equal to the `cw_<tool>`
 payload; `projected` means a declared divergence with a reason; `cli-only` marks
 a surface-specific capability with a recorded reason. The matrix is
 <!-- gen:parity:count -->
-machine-complete by design: 196 capabilities, 186 MCP tools.
+machine-complete by design: 199 capabilities, 186 MCP tools.
 <!-- /gen:parity:count -->
 
 <!-- gen:parity:table -->
 | Capability | CLI command | MCP tool | Core entry | Surface | Payload |
 | --- | --- | --- | --- | --- | --- |
 | `help` | `cw help` | `—` | `formatHelp` | cli-only | cli-only |
+| `version` | `cw version` | `—` | `CURRENT_COOL_WORKFLOW_VERSION` | cli-only | cli-only |
+| `update` | `cw update` | `—` | `npmUpdate` | cli-only | cli-only |
+| `fix` | `cw fix` | `—` | `runDoctor` | cli-only | cli-only |
 | `list` | `cw list` | `cw_list` | `listWorkflows` | both | identical |
 | `info` | `cw info` | `—` | `showApp` | cli-only | cli-only |
 | `search` | `cw search` | `—` | `listApps` | cli-only | cli-only |
@@ -298,9 +301,12 @@ A capability may be on one surface only, but never without word of it — it mus
 carry a recorded reason in the registry.
 
 <!-- gen:parity:cliOnly -->
-Ten capabilities are CLI-only:
+13 capabilities are CLI-only:
 
 - `help` — Human help text. MCP hosts enumerate capabilities via tools/list, not a help command.
+- `version` — Version string — no structured data contract.
+- `update` — Self-update via npm — inherently local shell operation, no MCP surface.
+- `fix` — Environment fix commands are local diagnostics, same reasoning as doctor.
 - `info` — Human-focused workflow discovery tool (like Homebrew's `brew info`). MCP agents discover workflows via cw_list and cw_app_show tools.
 - `search` — Human-focused workflow discovery (like Homebrew's `brew search`). MCP agents discover workflows via cw_list tool.
 - `man` — Human documentation viewer. MCP agents read docs/ directly via file tools.
@@ -507,3 +513,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+CLI surface simplified to 6 commands with agent stderr streaming on by default and vendor agent flags; the drive gains a `--incremental` flag (added to DRIVE_RUNTIME_KEYS so it never poisons run.inputs or the cache key). MCP tools stay the derived mirror of the same capabilities.
+
+## 0.1.89 (v0.1.89)
+
+CLI golden-path fixes: `cw -q "…"` routes the question (was read as an app id → "Workflow app not found"), auto-detects the cwd as the repo (run anywhere, no `--repo`), and `cw help` wraps its command list with a trailing newline; the CLI↔MCP parity contract and the help-token parser are unchanged.

package/docs/contract-migration-tooling.7.md

@@ -149,3 +149,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+_No behavioral change in v0.1.88 (no schema-migration edge was added; the incremental result cache uses a self-contained schemaVersion:2 key that never collides with the opt-in v1 cache and is not a run-state or app-schema migration)._
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/control-plane-scheduling.7.md

@@ -133,3 +133,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+_No behavioral change in v0.1.88 (the `sched` priority/readiness selection, concurrency ceiling, leases, backoff retry, and fail-closed park state are unchanged)._
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/durable-state-and-locking.7.md

@@ -132,3 +132,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+_No behavioral change in v0.1.88 (atomic writes, fsync-durability for audit-essential state, and lock-serialized cross-process stores are unchanged; the in-place `appendRunNode` optimization keeps `writeRunNode` and the persisted bytes identical)._
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/evidence-adoption-reasoning-chain.7.md

@@ -293,3 +293,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+_No behavioral change in v0.1.88 (the evidence adoption reasoning chain and its fingerprinted, fail-closed derivation are unchanged)._
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/execution-backends.7.md

@@ -323,3 +323,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+Agent stderr live-streaming is now on by default when stderr is a TTY (CW_AGENT_STREAM=0 / CW_NO_STREAM=1 force it off; CI and pipes stay silent); stdout is still always captured as data and the driver model / sandbox contract are unchanged.
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/launch/launch-kit.md

@@ -41,9 +41,9 @@ to trust or breach.
 
   npx cool-workflow demo tamper
 
-It builds a real signed ledger, forges it two ways (flip a verdict + re-seal its
-hash; inflate reported tokens + reuse the signature), and catches both offline with
-only the public key. On a real run, `cw telemetry verify <run>` re-proves the
+It builds a real signed ledger, forges it three ways (flip a verdict + re-seal its
+hash; inflate reported tokens + reuse the signature; edit a signed finding), and
+catches all three offline with only the public key. On a real run, `cw telemetry verify <run>` re-proves the
 recorded ledger on disk — recomputing the chain so any later edit to a verdict or
 usage digest is caught; add `--pubkey <public.pem>` to re-run each attested hop's
 signature check offline too. I keep an
@@ -111,9 +111,9 @@ npm: https://www.npmjs.com/package/cool-workflow
 > npx cool-workflow demo tamper
 > ```
 >
-> It builds a real signed ledger, forges it two ways (flip a verdict + re-seal its
-> hash; inflate reported tokens + reuse the signature), and catches both offline with
-> only the public key. On a real run, `cw telemetry verify <run>` re-proves the
+> It builds a real signed ledger, forges it three ways (flip a verdict + re-seal its
+> hash; inflate reported tokens + reuse the signature; edit a signed finding), and
+> catches all three offline with only the public key. On a real run, `cw telemetry verify <run>` re-proves the
 > recorded ledger on disk — recomputing the chain so any later edit to a verdict or
 > usage digest is caught; add `--pubkey <public.pem>` to re-run each attested hop's
 > signature check offline too. I keep an
@@ -142,9 +142,9 @@ npm: https://www.npmjs.com/package/cool-workflow
 1/ Your agent pipeline trusts what the model *says* it did. Cool Workflow proves
 it instead. `npx cool-workflow demo tamper` — 30s, no install:
 
-2/ It builds a real ed25519-signed telemetry ledger, forges it two ways, and
-catches both offline with only the public key. A control-plane that delegates
-model execution but can still prove the bill is real.
+2/ It builds a real ed25519-signed telemetry ledger, forges it three ways (incl.
+editing a signed finding), and catches all three offline with only the public key.
+A control-plane that delegates model execution but can still prove the bill is real.
 
 3/ Also: concurrent batches that don't deadlock when an agent hangs, schema-gated
 outputs, token budgets vs the host's recorded usage (attested-telemetry gate is

package/docs/multi-agent-cli-mcp-surface.7.md

@@ -291,3 +291,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+The host-facing surface tracks the CLI simplification to 6 commands (streaming on by default, vendor agent flags); the multi-agent control loop verbs and their MCP-tool mirrors are otherwise unchanged.
+
+## 0.1.89 (v0.1.89)
+
+The host-facing surface tracks the CLI golden-path fixes (`cw -q` routing + repo auto-detect + clean help); the multi-agent verbs and their MCP-tool mirrors are unchanged.

package/docs/multi-agent-eval-replay-harness.7.md

@@ -325,3 +325,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+_No change in behavior in v0.1.88 (no harness code changed; the new `loop-control` state node and loop result nodes replay byte-identically through the existing normalize/replay machinery, and pre-0.1.88 snapshots load unchanged)._
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/multi-agent-operator-ux.7.md

@@ -337,3 +337,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+_No behavioral change in v0.1.88 (no operator-view code changed; the new sub-workflow `subRunId`/`subRunDir` and `loopRound` run-state fields surface read-only through the existing derived graph/dependency/evidence views, which neither fabricate state nor guess success)._
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/node-snapshot-diff-replay.7.md

@@ -158,3 +158,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+A new `loop-control` StateNodeKind now flows through per-node snapshot/diff/replay (loop decisions are recorded as deterministic, replay-stable nodes); `appendRunNode` was optimized to mutate `run.nodes` in place (O(1) per append vs O(N^2) churn) with byte-identical persisted state, so snapshot/replay digests are unchanged.
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/observability-cost-accounting.7.md

@@ -217,3 +217,11 @@ No other change to this page in v0.1.84.
 ## 0.1.87 (v0.1.87)
 
 npm test parallel, 4-vendor wrappers (Claude/Codex/Gemini/OpenCode), Homebrew-style CLI UX (colors/did-you-mean/categorized help/error tips/cw info/cw search/cw man/doctor --fix), post-success summaries, agent execution timing
+
+## 0.1.88 (v0.1.88)
+
+Attestation now signs the agent's RESULT, not just its usage: `TelemetryAttestationRecord.resultDigest` hash-binds sha256(result.md) into the ed25519-signed, hash-chained ledger so an offline re-verifier reconstructs the exact signed payload. Budget-aware loop scaling reads the SAME recorded usage total (`deriveUsageTotals`) the fail-closed cost cap reads, so a `until:{kind:"budget-target"}` loop stops on a token target while the cap stays the absolute backstop.
+
+## 0.1.89 (v0.1.89)
+
+_No behavioral change in v0.1.89 (CLI-surface golden-path + help-output fixes only; this subsystem is unchanged)._

package/docs/project-index.md

@@ -1,15 +1,15 @@
 # Cool Workflow Project Index
 
-Generated from the current repository code on 2026-06-19 by `npm run sync:project-index`.
+Generated from the current repository code on 2026-06-21 by `npm run sync:project-index`.
 
 ## Snapshot
 
 - Package: `cool-workflow`
-- Version: `0.1.87`
-- Source modules: `64`
+- Version: `0.1.89`
+- Source modules: `65`
 - Workflow apps: `7`
-- Docs: `51`
-- Smoke tests: `115`
+- Docs: `52`
+- Smoke tests: `130`
 - Repository: https://github.com/coo1white/cool-workflow
 
 ## Architecture
@@ -92,6 +92,7 @@ multi-agent host -> topology -> blackboard/coordinator
 - [evidence-reasoning.ts](../src/evidence-reasoning.ts)
 - [execution-backend.ts](../src/execution-backend.ts)
 - [gates.ts](../src/gates.ts)
+- [loop-expansion.ts](../src/loop-expansion.ts)
 - [mcp-surface.ts](../src/mcp-surface.ts)
 - [multi-agent-eval.ts](../src/multi-agent-eval.ts)
 - [multi-agent-operator-ux.ts](../src/multi-agent-operator-ux.ts)
@@ -160,6 +161,7 @@ multi-agent host -> topology -> blackboard/coordinator
 - [Operator UX](operator-ux.7.md)
 - [PIPELINE-RUNNER(7)](pipeline-runner.7.md)
 - [Cool Workflow Project Index](project-index.md)
+- [Cool Workflow](readme-v0.1.87-full.md)
 - [Real Execution Backend Integrations](real-execution-backends.7.md)
 - [Release And Migration Discipline](release-and-migration.7.md)
 - [Cool Workflow Release History](release-history.md)
@@ -188,6 +190,7 @@ multi-agent host -> topology -> blackboard/coordinator
 Smoke tests mirror the public contracts. The high-signal suites are:
 
 - [agent-delegation-drive-smoke.js](../test/agent-delegation-drive-smoke.js)
+- [append-run-node-no-realloc-smoke.js](../test/append-run-node-no-realloc-smoke.js)
 - [architecture-review-fast-automation-smoke.js](../test/architecture-review-fast-automation-smoke.js)
 - [architecture-review-fast-smoke.js](../test/architecture-review-fast-smoke.js)
 - [artifact-integrity-smoke.js](../test/artifact-integrity-smoke.js)
@@ -195,6 +198,7 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [backend-registry-smoke.js](../test/backend-registry-smoke.js)
 - [blackboard-state-explosion-management-smoke.js](../test/blackboard-state-explosion-management-smoke.js)
 - [block-unapproved-tag-smoke.js](../test/block-unapproved-tag-smoke.js)
+- [budget-scaling-loop-smoke.js](../test/budget-scaling-loop-smoke.js)
 - [bump-version-idempotent-smoke.js](../test/bump-version-idempotent-smoke.js)
 - [candidate-scoring-smoke.js](../test/candidate-scoring-smoke.js)
 - [canonical-workflow-apps-smoke.js](../test/canonical-workflow-apps-smoke.js)
@@ -221,10 +225,15 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [error-feedback-smoke.js](../test/error-feedback-smoke.js)
 - [evidence-adoption-reasoning-smoke.js](../test/evidence-adoption-reasoning-smoke.js)
 - [evidence-content-extraction-smoke.js](../test/evidence-content-extraction-smoke.js)
+- [execution-backend-agent-smoke.js](../test/execution-backend-agent-smoke.js)
+- [execution-backend-ci-smoke.js](../test/execution-backend-ci-smoke.js)
 - [execution-backends-smoke.js](../test/execution-backends-smoke.js)
 - [freebsd-audit-fixes-smoke.js](../test/freebsd-audit-fixes-smoke.js)
 - [gemini-agent-wrapper-smoke.js](../test/gemini-agent-wrapper-smoke.js)
 - [h7-custom-profile-persist-smoke.js](../test/h7-custom-profile-persist-smoke.js)
+- [headline-commands-smoke.js](../test/headline-commands-smoke.js)
+- [incremental-resume-smoke.js](../test/incremental-resume-smoke.js)
+- [loop-bounded-expansion-smoke.js](../test/loop-bounded-expansion-smoke.js)
 - [mcp-app-surface-smoke.js](../test/mcp-app-surface-smoke.js)
 - [mcp-surface-registry-smoke.js](../test/mcp-surface-registry-smoke.js)
 - [multi-agent-cli-mcp-surface-smoke.js](../test/multi-agent-cli-mcp-surface-smoke.js)
@@ -239,6 +248,7 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [multi-agent-trust-policy-audit-smoke.js](../test/multi-agent-trust-policy-audit-smoke.js)
 - [no-false-green-smoke.js](../test/no-false-green-smoke.js)
 - [node-snapshot-diff-replay-smoke.js](../test/node-snapshot-diff-replay-smoke.js)
+- [npm-global-install-smoke.js](../test/npm-global-install-smoke.js)
 - [npm-trusted-publish-smoke.js](../test/npm-trusted-publish-smoke.js)
 - [observability-cost-accounting-smoke.js](../test/observability-cost-accounting-smoke.js)
 - [one-way-boundary-smoke.js](../test/one-way-boundary-smoke.js)
@@ -253,8 +263,10 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [project-index-sync-smoke.js](../test/project-index-sync-smoke.js)
 - [quickstart-bundle-smoke.js](../test/quickstart-bundle-smoke.js)
 - [quickstart-check-smoke.js](../test/quickstart-check-smoke.js)
+- [quickstart-no-agent-smoke.js](../test/quickstart-no-agent-smoke.js)
 - [quickstart-readme-path-smoke.js](../test/quickstart-readme-path-smoke.js)
 - [quickstart-smoke.js](../test/quickstart-smoke.js)
+- [readme-trust-claim-smoke.js](../test/readme-trust-claim-smoke.js)
 - [real-execution-backends-smoke.js](../test/real-execution-backends-smoke.js)
 - [registry-corrupt-fail-closed-smoke.js](../test/registry-corrupt-fail-closed-smoke.js)
 - [release-flow-smoke.js](../test/release-flow-smoke.js)
@@ -265,16 +277,20 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [result-normalize-smoke.js](../test/result-normalize-smoke.js)
 - [robustness-failclosed-smoke.js](../test/robustness-failclosed-smoke.js)
 - [robustness-hardening-smoke.js](../test/robustness-hardening-smoke.js)
+- [run-all-agent-env-hermetic-smoke.js](../test/run-all-agent-env-hermetic-smoke.js)
 - [run-all-json-summary-smoke.js](../test/run-all-json-summary-smoke.js)
+- [run-export-cross-machine-smoke.js](../test/run-export-cross-machine-smoke.js)
 - [run-export-import-smoke.js](../test/run-export-import-smoke.js)
 - [run-export-restore-rerun-smoke.js](../test/run-export-restore-rerun-smoke.js)
 - [run-export-restore-resume-smoke.js](../test/run-export-restore-resume-smoke.js)
 - [run-fixture-compat-smoke.js](../test/run-fixture-compat-smoke.js)
+- [run-import-path-traversal-smoke.js](../test/run-import-path-traversal-smoke.js)
 - [run-import-tamper-failclosed-smoke.js](../test/run-import-tamper-failclosed-smoke.js)
 - [run-inspect-archive-smoke.js](../test/run-inspect-archive-smoke.js)
 - [run-registry-control-plane-smoke.js](../test/run-registry-control-plane-smoke.js)
 - [run-resume-drive-smoke.js](../test/run-resume-drive-smoke.js)
 - [run-retention-reclamation-smoke.js](../test/run-retention-reclamation-smoke.js)
+- [sample-determinism-smoke.js](../test/sample-determinism-smoke.js)
 - [sandbox-profile-smoke.js](../test/sandbox-profile-smoke.js)
 - [sched-policy-validation-smoke.js](../test/sched-policy-validation-smoke.js)
 - [schedule-routine-daemon-smoke.js](../test/schedule-routine-daemon-smoke.js)
@@ -284,6 +300,7 @@ Smoke tests mirror the public contracts. The high-signal suites are:
 - [source-context-batch-smoke.js](../test/source-context-batch-smoke.js)
 - [source-context-profile-smoke.js](../test/source-context-profile-smoke.js)
 - [state-node-smoke.js](../test/state-node-smoke.js)
+- [sub-workflow-nesting-smoke.js](../test/sub-workflow-nesting-smoke.js)
 - [surface-explicit-cwd-smoke.js](../test/surface-explicit-cwd-smoke.js)
 - [tamper-evidence-demo-smoke.js](../test/tamper-evidence-demo-smoke.js)
 - [team-collaboration-smoke.js](../test/team-collaboration-smoke.js)