@iowarp/clio-coder 0.3.0 → 0.3.2

package/docs/architecture.md

@@ -1,11 +1,11 @@
 # Clio Coder Architecture and Boundaries
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/architecture_blueprint.html](html/architecture_blueprint.html) (Version: 0.3.0).
+> **Interactive Spec Available:** An interactive dashboard is located at [docs/html/architecture_blueprint.html](html/architecture_blueprint.html) (Version: 0.3.2).
 
 Clio Coder is an experimental, terminal-first coding harness for the CLIO ecosystem. CLIO stands for Context Layer for Input/Output; the project is named for the Greek muse of history and developed by the Gnosis Research Center at Illinois Tech. Its architecture favors small, auditable subsystems over a single monolithic agent loop: CLI entry points, the interactive TUI, provider/runtime code, worker subprocesses, tools, and feature domains are kept separate so local-model support and scientific-software workflows can evolve without collapsing safety boundaries.
 
-This page is source-code aligned for the current `v0.3.0` development line.
+This page is source-code aligned for the current `v0.3.2` development line.
 
 ---
 
@@ -31,12 +31,13 @@ Registered domain modules include:
 | agents | `src/domains/agents/**` | Built-in, user, and project agent recipes. |
 | components | `src/domains/components/**` | Component snapshots, diffs, and classification. |
 | config | `src/domains/config/**`, `src/core/config.ts` | `settings.yaml`, keybindings, hot reload. |
-| context | `src/domains/context/**` | `CLIO-CODER.md`, codewiki indexer, repository context. |
+| context | `src/domains/context/**` | Layered `CLIO-CODER.md` and subtree `CLIO-CODER.override.md` guidance, codewiki indexer, repository context. |
 | dispatch | `src/domains/dispatch/**` | Fleet-agent jobs, receipts, worker spawning, route policies. |
 | eval | `src/domains/eval/**` | Local evaluation harness, suites, JUnit/SWE-bench reports. |
 | evidence | `src/domains/evidence/**` | Forensic evidence bundles, failure attribution. |
 | evolution | `src/domains/evolution/**` | Authority-tiered self-edit manifests and gates. |
 | extensions | `src/domains/extensions/**` | Extension discovery, packaging, and lifecycle. |
+| interop | `src/domains/interop/**` | The agent-kind registry, bounded detection of other coding agents, and consent to wire one as a delegation peer. |
 | lifecycle | `src/domains/lifecycle/**` | Doctor diagnostics, upgrade mechanics, uninstallation. |
 | memory | `src/domains/memory/**` | Approved long-term memory, proactive task intervention. |
 | middleware | `src/domains/middleware/**` | Declarative and programmatic lifecycle hooks and budgets. |
@@ -49,6 +50,26 @@ Registered domain modules include:
 | session | `src/domains/session/**` | Append-only JSONL transcripts, tree navigation, compaction. |
 | share | `src/domains/share/**` | Portable workspace and resource archive export/import. |
 
+The `interop` domain owns one question: which other coding agents are on this
+machine and in this project. `src/domains/interop/registry.ts` is pure data, one
+entry per known agent carrying its binaries, the directories it owns, its skill
+and prompt roots, its instruction filenames, and the ACP launch recipe when it
+has one. Every other module that used to keep its own copy of that list now
+derives it: the skills loader and the prompts loader take their compatibility
+roots from the table, the adoption scanner takes its candidate files from it,
+and the safety path policy takes the foreign directories it refuses to write
+into from it.
+
+The domain owns detection and consent, and nothing else. It never executes a
+foreign agent's work command, never loads a skill, prompt, or rule itself, and
+never reads under a foreign agent's `sessions`, `history`, `cache`, `projects`,
+or `state` directory. Detection resolves binaries with `access(X_OK)` and no
+shell, checks install directories, and runs a bounded `--version` only when the
+caller asks and only for a binary that already resolved; a probe that cannot
+answer reports `unknown` and never `absent`. The one durable configuration write
+is an append to `delegation.agents`, and it happens only after an operator
+decision.
+
 ---
 
 ## Session Routing vs. Persisted Settings
@@ -81,9 +102,83 @@ Source: `src/core/workspace-files.ts`, `src/core/c-header-language.ts`.
    - Tier 2: Distinctive `#include` directives (standard C++ headers vs standard C headers).
    - Tier 3: Language-exclusive tokens (`template<`, `namespace `, `class `, `nullptr`, `constexpr`).
 
+## Codewiki ownership and worker boundary
+
+Codewiki keeps its boot-time read surface separate from its build graph:
+
+- `src/domains/context/codewiki/schema.ts`, `artifact.ts`, and `paths.ts` own the
+  stable data shapes, normalized artifact compatibility, synchronous and
+  asynchronous reads, serialization, and cheap path classification. Reading a
+  cached artifact does not load tree-sitter.
+- `indexer.ts` owns full, synchronized, and incremental candidate construction.
+  Its tree-sitter adapter is a real dynamic import; grammars load only for the
+  source paths an actual build needs.
+- `build-worker.ts` is the sole runtime execution boundary for codewiki
+  candidate walks, freshness fingerprinting, and parsing. Other context surfaces
+  independently detect project metadata, but the interactive process does not
+  run a codewiki scan or an uninterruptible parser call on its render/input loop.
+- `coordinator.ts` owns production commits. One FIFO per workspace establishes
+  generation order inside a process, and `withStateFileLock` extends that order
+  across Clio processes. Each transaction rereads the artifact after acquiring
+  the lease, publishes atomically, and updates freshness state before releasing
+  ownership.
+
+Session-start refresh, parallel tool demand, incremental mutation notices,
+explicit index/refresh, context bootstrap, wiki grounding, and context reset all
+enter this transaction boundary. A never-indexed workspace remains untouched by
+background session startup. `code_nav` still waits for a fresh demand result;
+reset queues behind already-admitted work and therefore cannot be undone by an
+older completion. Context-domain shutdown drains both mutation admission and the
+coordinator lane before returning. The direct builder and artifact writer remain
+available to build scripts and test fixtures, but production workspace writes
+must go through the coordinator.
+
+## Lazy built-in tool boundary
+
+The registry always owns one complete, immutable `ToolSpec` surface before a
+model turn starts. `context`, `code_nav`, `verify`, `web_fetch`, `dispatch`,
+`monitor`, and `steer` keep their
+name, description, TypeBox schema, action class, execution mode, synchronous
+argument hooks, source provenance, and policy metadata in lightweight surface
+modules. `registerAllTools` registers those surfaces in the same order as every
+other built-in; capability discovery, worker attestation, provider schema
+serialization, safety classification, autonomy and permission admission, and
+`before_tool` middleware therefore run without evaluating the implementation.
+The worker composition root imports `core-bootstrap.ts` directly, so its real
+built entry never evaluates the orchestrator-only dispatch, monitor, or steer
+runners. The orchestrator appends those three tools in their historical order.
+
+Dispatch is the one stateful lazy boundary. Its synchronous admission controller
+owns the exact WeakMap/WeakSet identities for trusted plans, parsed requests,
+capacity reservations, Scout plans, and prepared arguments. The dynamically
+loaded runner receives that same controller state; it never reconstructs an
+approved call. A deeply frozen, discriminated execution snapshot also pins the
+normalized requests, mode, review/compete settings, detach flag, timeout, output
+bound, and an `apply_winner` branch plus absolute repository destination before
+middleware or an approval prompt can expose the prepared argument identity. The
+winner destination is part of the rendered and hashed approval artifact.
+Admission disposal is one registry-owned finally boundary, so a
+middleware guard block, ordinary return, or thrown body releases a provisional
+reservation exactly once.
+
+Only the admitted `run` step crosses `src/tools/lazy-tool.ts`. One cached promise
+owns the implementation import, including a deterministic failure, so concurrent
+first calls cannot initialize competing implementations. The loaded spec must
+match the advertised surface before its body can run. Ordinary body exceptions,
+result shaping, `after_tool` middleware, abort signals, and telemetry continue
+through the registry's existing path. This mechanism is built-in-only; it does
+not turn extension manifests or provider plugins into an executable tool loader.
+Source-built and installed-package coverage contracts locate implementations by
+stable behavior provenance, prove them absent during a real provider capability
+request, and prove only the invoked implementation present after first use.
+
 ## Boundary invariants
 
-`npm run check:boundaries` executes the boundary check suite (`tests/boundaries/check-boundaries.ts`). Treat these checks as executable specifications.
+`npm run lint` executes the boundary checker (`tests/boundaries/check-boundaries.ts`, imported by `scripts/check-hygiene.ts`). Treat these checks as executable specifications.
+
+The enforced import rules below are complemented by the maintained
+[Pi SDK boundary table](pi-boundary.md), which records the semantic owner of
+each overlapping helper and the Clio deltas that must survive an SDK upgrade.
 
 These five enforced boundary rules constrain dependency **direction**, never import **form** (whether static vs dynamic, default vs named):
 
@@ -91,7 +186,7 @@ These five enforced boundary rules constrain dependency **direction**, never imp
 
 Only files under `src/engine/**` may import `@earendil-works/*` packages. Since the 0.83.0 engine-boundary rework, no file outside `src/engine/**` may import `@earendil-works/*` at all, value or type-only. Domain modules import erased engine shapes (`EngineModel`, `Api`, `Model`) directly from `src/engine/types.ts`.
 
-Why: provider SDKs and pi-ai engine values must remain swappable behind one engine boundary. Domains and presentation layers operate against Clio contracts rather than vendor or runtime implementations.
+Why: provider SDKs and pi-ai engine values must remain swappable behind one engine boundary. Domains and presentation layers operate against Clio contracts rather than vendor or runtime implementations. `src/engine/api-registry.ts` composes Pi's public lazy API factories in their canonical order, retains provider-owned authentication/header dispatch, and lets Clio's local-runtime adapters override API families without importing the deprecated compatibility aggregate. The only `pi-ai/compat` edge is dynamic: before a configured out-of-tree runtime evaluates, Clio joins Pi's process-global registry and mirrors its overrides so external provider plugins retain the same registry identity and last-writer-wins order. No configured plugin means no compatibility aggregate. OpenAI-compatible sampler fields and vLLM thinking budgets flow through Pi's `samplingParams` and `supportsThinkingTokenBudget` contracts; Clio's adapter retains only catalog selection and runtime-specific payload deltas. Tool head/tail truncation, byte formatting, and grep-line clipping likewise flow through pi-agent-core's `truncateHead`, `truncateTail`, `formatSize`, and `truncateLine`; Clio retains only its 16 KiB per-observation default and its exported line-count helper. Tool string enums come from pi-ai's `StringEnum` (`src/engine/ai.ts`), the model-facing text for replayed bash executions and branch or compaction summaries comes from pi-agent-core's `bashExecutionToText` and summary prefixes (`src/engine/messages.ts`), and Anthropic thinking payloads are assembled by Pi's narrow lazy stream implementation with no Clio rewrite.
 
 ### Rule 2: Workers do not value-import domains except runtime rehydration
 
@@ -154,16 +249,71 @@ Clio uses in-process event buses for status and audit surfaces, but safety is no
 - `src/tools/registry.ts` is the admission point for every tool invocation.
 - `src/domains/dispatch/receipt-integrity.ts` and related dispatch files persist receipts used by evidence and cost surfaces.
 
+## Interactive render transactions
+
+The interactive shell owns one concrete pi-tui renderer. Clio's instrumented
+subclasses bracket the renderer's protected `doRender()` seam, so one render
+transaction receives one `frameId` even when regular-screen cursor/IME work
+issues several terminal writes. Protocol, startup, and shutdown writes outside
+a render retain `frameId: null`; they are never fabricated into frames.
+
+The root component is timed in place so its identity and fullscreen layout
+markers do not change. Public pi-tui seams provide component/layout, overlay,
+normalization, and cursor-extraction phases. Viewport selection, diffing, ANSI
+construction, and remaining cursor work are reported honestly as one combined
+remainder because the engine does not expose narrower hooks. The stdout
+boundary records enqueue duration, return value, backpressure, and drain.
+
+Canonical text/thinking events are numbered at the beginning of the primary
+projection, before any consumer. Panel admission/application and the first
+committed frame's high water establish event causality without changing the
+public event object or fan-out order. Input is numbered after terminal protocol
+decoding and before the application controller mutates editor, overlay, scroll,
+or submit state. The first frame whose input high water includes that id is the
+input-to-stdout-commit endpoint.
+
+Adaptive streaming remains inside that presentation boundary. One semantic
+classifier drops only transparent raw text/thinking mirrors, sends derived
+visible content through one generation/epoch FIFO, and treats every other
+transcript mutation as an ordered drain boundary. Pacer slices mutate the
+panel directly and are never re-emitted on the public bus, so session storage,
+replay/export, tool-call formation, and cumulative tool-result behavior keep
+their canonical synchronous inputs. Abort, retry, interrupt, submit, mode
+change, and teardown drain the queue and can await the containing committed
+frame. The stdout gate stops later frame construction after a false write and
+coalesces to current model state until `drain`; it is not installed for the
+default `off` path and therefore cannot become a second unbounded SSH buffer.
+
+Interactive boot has one terminal owner across its two stages. The
+`TerminalLease` creates one terminal/TUI/root host/editor and owns raw mode,
+decoded input, resize, protocol initialization, signal routing, and teardown.
+Stage 0 mounts a small static shell on that owner. Stage 1 hydrates services and
+atomically replaces the root plus input/signal delegates while preserving the
+editor object and buffer. Submissions accepted before attachment are immutable
+FIFO records shown in the shell and admitted exactly once through the normal
+slash/bash/chat pipeline after attachment. A generation guard rejects a late
+hydration after shutdown; every failure path shares one idempotent close and
+terminal restoration transaction. The built-graph contract bounds the Stage 0
+closure and rejects provider, tool, codewiki, tree-sitter, and orchestrator
+implementation markers. ACP, headless, ordinary non-TTY invocation, help, and
+subcommands never construct a lease; the established explicit
+`CLIO_CODER_INTERACTIVE=1` non-TTY override remains force-interactive.
+
+Tracing is opt-in and content-free. Its bounded asynchronous writer never does
+filesystem append I/O on the render stack, and shutdown awaits a bounded flush.
+See [performance-methodology.md](performance-methodology.md) for vocabulary,
+commands, PTY limitations, and baseline evidence.
+
 ## Command spec
 
-Interactive slash commands in Clio Coder are governed by a unified declarative command specification registry. This declarative system replaces hand-rolled parsing logic with structured specifications that define the names, aliases, flags, positionals, and subcommands for each entry. The central registry acts as the single source of truth for command matching, argument parsing, autocomplete suggestion generation, and usage help output. The parser processes user input strings using these declarative specifications to generate structured argument objects and canonical command representations. By deriving all command-related behavior from these specifications, the system ensures consistency across usage help messages and autocomplete overlays.
+Interactive slash commands in Clio Coder are governed by a unified declarative command specification registry. This declarative system replaces hand-rolled parsing logic with structured specifications that define the names, flags, positionals, and subcommands for each entry. The central registry acts as the single source of truth for command matching, argument parsing, autocomplete suggestion generation, and usage help output. The parser processes user input strings using these declarative specifications to generate structured argument objects and canonical command representations. By deriving all command-related behavior from these specifications, the system ensures consistency across usage help messages and autocomplete overlays.
 
 ---
 
 ## Verification commands
 
 ```bash
-npm run check:boundaries
+npm run lint
 npm run typecheck
 npm run test
 npm run build

package/docs/artifact-placement.md

@@ -0,0 +1,101 @@
+# Artifact Placement
+
+Every file Clio generates has one home, decided by who reads it. The rule that
+follows from that: **the repo working tree holds files a human asked for.**
+Anything Clio produced on its own initiative lands in the gitignored project
+directory or under the XDG dirs, never beside your source.
+
+This page is the contract. `src/core/artifact-paths.ts` is the code that
+implements the part of it the `artifact` tool owns.
+
+## Three audiences
+
+| Audience | What it means | Where it goes |
+| --- | --- | --- |
+| Human deliverable | A file the user asked to keep, and will read and commit | Repo working tree, at the path the user named |
+| Human transient | Something a human may want to read once; losing it costs nothing | Project-local `.clio-coder/` (gitignored) |
+| Agent-to-agent state | Machine-read plumbing between turns, workers, and sessions | `.clio-coder/` for per-project state; XDG data/state/cache for per-machine state |
+
+A class is human-facing only if a person is expected to open it. A plan an
+agent wrote for its own next step is agent-to-agent state even though it is
+Markdown.
+
+## Placement by class
+
+| Class | Location | Audience |
+| --- | --- | --- |
+| `artifact` tool plan / review / report | `.clio-coder/artifacts/PLAN.md`, `REVIEW.md`, `REPORT.md` | Human transient |
+| Any artifact the user named a path for | that path, inside the workspace | Human deliverable |
+| RCA write-ups for shipped fixes | the GitHub issue's closing comment, never a committed file | Human deliverable |
+| Codewiki index | `.clio-coder/codewiki.json` | Agent-to-agent |
+| Markdown wiki | `.clio-coder/wiki/` | Human transient |
+| Session context state | `.clio-coder/state.json` | Agent-to-agent |
+| Task-memory handoffs | `.clio-coder/handoffs/` | Agent-to-agent |
+| Dispatch proposals | `.clio-coder/proposals/` | Agent-to-agent |
+| Compete worktrees | `.clio-coder/worktrees/` | Agent-to-agent |
+| Test scratch | `.clio-coder/test-scratch/` | Agent-to-agent |
+| Evidence bundles | XDG data `evidence/` | Human transient (`clio-coder evidence`) |
+| Approved memory | XDG data `memory/` | Human transient (`clio-coder memory`) |
+| Eval artifacts | XDG data `evals/` | Human transient (`clio-coder eval`) |
+| Session ledgers | XDG state `sessions/` | Agent-to-agent |
+| Dispatch receipts | XDG state `receipts/` | Human transient (`clio-coder trace`) |
+| Audit records | XDG state `audit/` | Human transient |
+| Interview transcripts | XDG state `interviews/` | Agent-to-agent |
+| Harness scratch | XDG state `scratch/` | Agent-to-agent |
+| Caches | XDG cache | Agent-to-agent |
+
+`clio-coder paths` prints the resolved XDG directories for your machine.
+
+## The `artifact` tool default
+
+`artifact(kind: plan|review|report)` without a `path` writes to
+`.clio-coder/artifacts/` under the workspace root. Passing `path` writes exactly
+there instead, working tree included, because a path the user named is a file
+the user asked for. A path that escapes the workspace is refused.
+
+The default is a pure function of `kind`, and has to stay that way. The action
+classifier, the policy engine's write-root check, and the protected-artifacts
+guard all predict where a pathless call will write, from its arguments alone,
+before the tool runs. A default keyed on a session id or a timestamp would make
+that prediction impossible and leave the safety layer guarding a path nobody
+writes. The consequence is one file per kind: a second report overwrites the
+first. Keep several by naming explicit paths.
+
+## `.clio-coder/` and git
+
+`.clio-coder/` is gitignored in full. Everything above that lands there is
+generated, reproducible, and worthless in a diff, and the whole point of the
+contract is that a dogfooding session ends with `git status` clean.
+
+Some `.clio-coder/` content is authored rather than generated, and a project
+that wants it reviewed and shared commits it deliberately by adding negations
+next to the ignore:
+
+```gitignore
+.clio-coder/
+!.clio-coder/fleets/          # fleet contracts: repo-owned dispatch policy
+!.clio-coder/fleets/**
+!.clio-coder/rules/           # path-scoped project rules
+!.clio-coder/rules/**
+!.clio-coder/safety.yaml      # project safety policy
+!.clio-coder/agents/          # project agent recipes
+!.clio-coder/agents/**
+```
+
+This repository commits none of those, so its `.clio-coder/` stays fully
+ignored except the seeded soak fixtures under `benchmarks/soak/fixtures/`,
+which are test inputs rather than session output.
+
+## Finding what was hidden
+
+Hiding transient output from the working tree must not mean losing it.
+
+- `.clio-coder/artifacts/` is a plain directory; open it.
+- `clio-coder evidence` lists and inspects evidence bundles.
+- `clio-coder trace` queries the dispatch trace mirror and its receipts.
+- `clio-coder memory` lists proposed and approved memory.
+- `clio-coder paths` locates every XDG root.
+
+Related: [evidence-and-memory.md](evidence-and-memory.md),
+[trace-store.md](trace-store.md), [observability.md](observability.md),
+[development-pipeline.md](development-pipeline.md) for where RCAs are committed.

package/docs/artifact-versions.md

@@ -1,6 +1,6 @@
 # Artifact Versions & Serialization Contracts
 
-This document is the canonical registry of all versioned file formats, serialized data structures, integrity digests, and migration rules across Clio Coder in `v0.3.0`.
+This document is the canonical registry of all versioned file formats, serialized data structures, integrity digests, and migration rules across Clio Coder in `v0.3.2`.
 
 ---
 

package/docs/built-in-agents.md

@@ -3,7 +3,7 @@
 Clio Coder dispatches focused fleet agents from Markdown recipes. Recipes are data files, not hidden code plugins: YAML frontmatter declares identity, mode, tools, optional target/model hints, and thinking level; the Markdown body is the agent instruction text.
 
 > [!TIP]
-> **Interactive Spec Available:** An interactive dashboard for the agent registry and dispatch admission check gates is located at [docs/html/agents_blueprint.html](html/agents_blueprint.html) (Version: 0.3.0).
+> **Interactive Spec Available:** An interactive dashboard for the agent registry and dispatch admission check gates is located at [docs/html/agents_blueprint.html](html/agents_blueprint.html) (Version: 0.3.2).
 
 The source of truth is `src/domains/agents/**`. Clio's agent dispatch engine and execution boundaries are built upon the [@earendil-works/pi-agent-core](https://www.npmjs.com/package/@earendil-works/pi-agent-core) library.
 
@@ -72,6 +72,8 @@ Grounding is checked against the run's own reads, not just against the file. The
 
 Every contract-bearing agent gets bounded in-worker repair. When the terminal result misses its contract, the worker replays the validator's own reason, the exact accepted shape, and the `path:line` locations this run actually read, then asks for the result again. Two repair rounds is the whole allowance; after that the run fails with `result_contract_exhausted`. This is what keeps a small local model that gathered the right evidence from being failed for a shape mistake nobody told it about.
 
+Two rounds only help when the reason is actionable, so a validator reason names the mistake and shows the value that would have passed. A `mutation-report` with `"validations":[]` is told the array was empty and is given one entry shaped like `{"name":"npm test","passed":true,"evidence":"exit 0"}`, and a report whose entries are malformed is told which keys each entry carries. Naming the requirement alone left a small model re-emitting the same empty array through both rounds.
+
 ---
 
 ## Frontmatter schema
@@ -115,7 +117,7 @@ Skills are knowledge attachments declared under `skills: [...]` in the YAML fron
 
 *   **Visibility**: Normal `clio-coder agents` lists user-visible (base/custom) agents. The `/agents` slash command shows both Clio fleet agents and ACP delegation agents. The command `clio-coder agents --all` includes shadow/internal specs reserved for Clio orchestration.
 *   **Invocation limits**: User-origin `/run` and `clio-coder run --agent` **cannot** invoke shadow/internal agents.
-*   **Orchestrator dispatch**: Internal main-agent dispatch can invoke shadow agents through the `dispatch` tool. The operating contract and Scout's catalog description steer the model to dispatch Scout for broad repository reconnaissance, while narrow file or symbol inspection remains local to the main agent. If a turn reaches 9 or more manual read-only exploration calls without completing Scout dispatch, a threshold nudge advises delegation on the continuation.
+*   **Orchestrator dispatch**: Internal main-agent dispatch can invoke shadow agents through the `dispatch` tool. The operating contract and Scout's catalog description steer the model to dispatch Scout for broad repository reconnaissance, while narrow file or symbol inspection remains local to the main agent. If a turn reaches 9 or more manual read-only exploration calls without completing Scout dispatch, a threshold nudge advises delegation once, as a transcript notice. It never carries the turn onward into another model round.
 *   **TUI rendering and control**: Shadow dispatch rows are marked with an `sh:` prefix. The Fleet Runs island and board show the bounded task, run ID, live tools, tokens, priced cost, retry state, and terminal outcome. Select an HTTP/SDK run to steer it or cancel any active worker/retry timer.
 *   **ACP Delegation**: The `/delegate` command is reserved for ACP delegation only, which is separate from Clio fleet subagents.
 

package/docs/capacity-and-scheduling.md

@@ -1,6 +1,6 @@
 # Capacity Leases & Fleet Scheduling
 
-This document specifies the multi-process capacity leasing protocols, node scheduling models, cross-process transaction locks, and failure recovery mechanics implemented in Clio Coder `v0.3.0`.
+This document specifies the multi-process capacity leasing protocols, node scheduling models, cross-process transaction locks, and failure recovery mechanics implemented in Clio Coder `v0.3.2`.
 
 Source implementations: `src/domains/scheduling/` and `src/domains/dispatch/capacity-lease.ts`.