Uh oh!
There was an error while loading. Please reload this page.
chore(release): prepare Runtime 0.176.0 - #1017
Conversation
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — d1e89c87
This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.
tangletools · auto-approval · reason: drewstone_author · 2026-08-28T20:09:48Z
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 5 (3 medium-concern, 2 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 218.1s (2 bridge agents) |
| Total | 218.1s |
💰 Value — sound-with-nits
A 9-commit stack that lets supervisors run and durably re-attach provider-owned native interactive processes (composing existing retained-run/Scope seams, not reinventing them) plus a cohort-pinned release pipeline — architecturally sound and in-grain, but the release commit itself cannot ship as wr
- What it does: Three things. (1) Feature stack:
workerFromInteractiveProvider(src/runtime/supervise/interactive-worker.ts:118) turns a provider's native interactive coding-agent process into a supervised worker through the existingMakeWorkerAgentseam; durable per-worker binding files plusattachWorker(src/runtime/supervise/worker-interactive.ts:167) reconstruct the exact process from a different proces - Goals it achieves: Supervised workers that are real provider-owned interactive terminals, attachable cross-process after crash or from another tool (the Braid LIVE11 supervisor use case named in provision-supervisor.ts:7); retry-safe, idempotent steer with honest runtime acknowledgements instead of fire-and-forget inbox appends; reproducible release verification against one exact declared dependency cohort instead o
- Assessment: Good on its merits and squarely in the codebase's grain. The new modules fill seams that already existed on main rather than building parallel systems:
interactive-admission.tsimplements theRetainedInteractiveAdmissionhook thatstartRetainedInteractiveRunalready demanded (its header says so, and scope.ts wires it at the existing admission seam);attachWorkercomposesloadSpawnForest - Better / existing approach: none — this is the right approach. Searched for prior art before concluding: (a) main already exports
reconnectRetainedInteractiveRun/claimRetainedInteractiveControland in-processscope.interactive(nodeId)(origin/main scope.ts:1316), but that handle dies with the owning process — durable disk bindings are exactly the missing piece, and the new code reuses that machinery rather than forking - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error event without a message: {"type":"error","timestamp":1787947924783,"sessionID":"ses_fb5ffc439ffeoRsuCq1QAiKv2e","error":{"name":"UnknownError","data":{"message":"Unexpected server error. Check server logs for details.","ref":"err_e32df095"}}}
🎯 Usefulness — sound-with-nits
A coherent provider-backed interactive-worker capability (durable attach/steer, terminal replay delegated to Sandbox's exact session handle) wired end-to-end with a live imminent consumer (Braid), plus a genuine single-source-of-truth release-cohort improvement; only self-reported release sequencing
- Integration: Fully reachable now. workerFromInteractiveProvider is consumed by provisionSupervisor (provision-supervisor.ts:197) which composes the existing MCP coordination tools' spawn_agent path; Scope writes durable interactive bindings via the interactiveReady seam (scope.ts:710,765-766); attachWorker (worker-interactive.ts:167) reconnects that binding through the provider's public get/interactive contrac
- Fit with existing patterns: Fits the codebase grain deliberately. The design comments state and the code honors: no second stream/replay buffer/session id — the provider owns process state, Scope owns journal/budget/inbox (interactive-worker.ts:2-7), and provision-supervisor.ts:2-9 composes existing primitives (coordination tools, Scope, spawn journal, sandboxClientAsProvider) rather than adding a parallel supervisor protoco
- Real-world viability: Error paths are handled, not just the happy path: attachWorker fails closed with typed reasons for unknown-node, not-live, missing/stale binding, unregistered provider, no interactive contract, and settled sessions (worker-interactive.ts:167-225); binding writes use atomic link + EEXIST race arbitration (worker-interactive.ts:141-159); provisionSupervisor uses a non-recursive mkdir as a cross-proc
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
🎯 Usefulness Audit
🟠 Ships as 0.175.1 but the repo's own version gate requires 0.176.0[robustness] ``
api-surface.json records shape changes to existing exports (Executor 3c6cee1f0aaa→4510f9089ec2, SpawnEvent, SupervisorOpts, WorkerSteerRequest, writeWorkerSteer, CoordinationTools, TopJournalEvent); scripts/check-version-bump.mjs:52-56 treats a moved shape as breaking, which below 1.0 demands a minor. Publishing changed export shapes as a patch would break ~0.175 consumers. Entirely fixable in-repo: renumber this release to 0.176.0 (and bench accordingly) before merge. The PR body self-reports t
🟡 Branch cannot pass frozen install until Sandbox 0.33.2 publishes[integration] ``
package.json:184 and pnpm-workspace.yaml:28 declare >=0.33.2 <0.34.0 but pnpm-lock.yaml:1298 still resolves 0.33.1 and npm has no 0.33.2 (E404, per PR body). The peer floor itself is correct — attach fails closed without attachAgentTerminal (environment-provider.ts:966), so admitting 0.33.1 would produce a runtime-unusable attach. Correctly staged against the Sandbox changeset (8f03b5a315 establishing 0.33.2); no design change needed, only re-running frozen install and packed-package verificatio
💰 Value Audit
🟠 Release version 0.175.1 fails the repo's own version gate; it must be 0.176.0[maintenance] ``
The repo classifies any moved exported SHAPE as breaking (scripts/lib/api-surface.mjs:277-282), and breaking on a 0.x package requires a minor bump (api-surface.mjs:344). api-surface.json in this PR moves shapes for Executor, RunGraphOptions, SupervisorOpts, ScopeArgs, SpawnEvent, WorkerSteerRequest, CoordinationTools, TopJournalEvent, WorkerInteractiveUnavailableReason, and adds exports (attachWorker, provisionSupervisor, ...). So
check:version-bumprejects 0.175.1 and demands 0.176.0 — the P
🟠 Peer floor >=0.33.2 references an unpublished Sandbox version, blocking frozen install[against-grain] ``
npm view @tangle-network/sandbox versionreturns 0.33.1 and pnpm-lock.yaml:1298 still resolves@tangle-network/sandbox@0.33.1, which does not satisfy the new catalog/peer range>=0.33.2 <0.34.0(pnpm-workspace.yaml:28, package.json:184). Frozen install and the packed-cohort/packed-package verification (scripts/lib/packed-package-test.mjs:3-4, scripts/verify-packed-cohort.mjs) cannot pass until Sandbox 0.33.2 publishes and the lockfile refreshes. Also note the range jumps two minors (0.31 →
🟡 'chore(release)' title carries a ~7.5k-line feature stack[proportion] ``
git diff origin/main..HEAD --stat shows 59 files, ~7,554 insertions — the release prep itself is ~12 files. The commits are cleanly split conventional-commit style and each is reviewable in isolation (matching repo history: #983, #991, #1007 were similarly large), so this is a reviewability note, not a defect. The practical cost is visible in finding 1: the release number and changelog were authored before the feature shapes settled against the version gate. Landing features and cutting the rele
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 581bd0b8
This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.
tangletools · auto-approval · reason: drewstone_author · 2026-08-28T20:28:02Z
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 3 (3 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 329.7s (2 bridge agents) |
| Total | 329.7s |
💰 Value — sound-with-nits
Lands a coherent provider-backed interactive-worker capability (durable attach/steer, capability-gated Sandbox terminal delegation) plus a single-sourced release cohort manifest and the 0.176.0 release; it composes existing primitives in the codebase's grain and should ship once Sandbox 0.33.2 publi
- What it does: Three things in one release branch. (1) Interactive workers:
sandboxClientAsProvidernow exposes the Sandbox SDK's native interactive agent sessions (startInteractive/claimControl/attach/sendPrompt/stop) through the existing AgentEnvironmentProvider contract, gated on the deployment's declared capabilities and delegating exact terminal attach/replay to the SDK's new `InteractiveSessionHandle.att - Goals it achieves: Let an external system (Braid) provision, attach a terminal to, steer, and cleanly tear down a provider-backed interactive coding-agent process under Runtime supervision, with crash-safe recovery coordinates and the provider — not Runtime — owning process state and exact replay. Secondarily: single-source the first-party verification cohort (three SHAs were duplicated across two workflows with onl
- Assessment: Good on its merits. The change is explicitly and verifiably layered on existing machinery rather than parallel to it: worker-interactive.ts imports reconnectRetainedInteractiveRun; interactive-worker.ts imports startRetainedInteractiveRun/claimRetainedInteractiveControl; provision-supervisor.ts is composition of createSupervisor/createCoordinationTools plus the new acknowledgers — module headers s
- Better / existing approach: none — this is the right approach. Searched for prior equivalents before concluding: workerFromBackend (Runtime-driven backend loops — different thing, the new code is provider-native processes), sandbox-session.ts (steerable box/session/turn loop over SandboxLineage — precursor pattern, not duplicated), retained-interactive.ts / retained-interactive-handle.ts (pre-existed at base e7cdc19 and are
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error event without a message: {"type":"error","timestamp":1787948930115,"sessionID":"ses_fb5f06d23ffeiS2CaQz7JTBvtt","error":{"name":"UnknownError","data":{"message":"Unexpected server error. Check server logs for details.","ref":"err_208c2cad"}}}
🎯 Usefulness — sound
A coherent provider-backed interactive-worker capability (provision → supervise → durable steer/cancel → cross-process attach) composed entirely from existing Runtime primitives, with a verified imminent external caller (Braid LIVE-11) and one acknowledged external sequencing gate (Sandbox 0.33.2 no
- Integration: Reachable and consumed on three levels. (1) External: Braid's LIVE-11 conformance path calls runtimeApi.provisionSupervisor and runtimeApi.attachWorker and validates the full ProvisionedSupervisor receipt field-for-field (/home/drew/code/.worktrees/braid-live11-supervisor/scripts/live-required/supervisor.mjs:77-78,420-434,595-603; worktree HEAD d48a73f matches the commits the PR body names). (2) I
- Fit with existing patterns: Fits the codebase grain precisely. The steer acknowledger deliberately mirrors the established cancel-acknowledger in the same file (createSteerAcknowledger vs createCancelAcknowledger, coordination-driver.ts:392-522, same turn/final lifecycle and at-most-once crash boundary), and the steerWorker seam reuses the identical authorize/record/deliver down-leg as the steer_agent MCP tool rather than a
- Real-world viability: Built for non-happy paths: bindings use atomic wx-flag writes with fsync and link-based dedupe plus symlink-escape guards (src/runtime/supervise/worker-interactive.ts:97-160,402-420); attachWorker fails closed with typed unavailable reasons for stale/not-live/unknown-node/unregistered-provider (:167-225); provisioning uses the run dir as a cross-process lock against duplicate starts (provision-sup
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
💰 Value Audit
🟡 Three private durable-write helpers added in one PR[duplication] ``
interactive-admission.ts:407
writeDurableFile, worker-interactive.ts:352writeDurableFile, and provision-supervisor.ts:741writeStateeach re-implement tmp-file + rename + fsync-file + fsync-dir (~15-20 lines each), all new in this branch, while src/durable/spawn-journal.ts already owns durability machinery these modules import from. Extract one shared helper (e.g. next to run-layout.ts, which all three already depend on) rather than keeping three lockstep copies that must evolve together.
🟡 Sandbox peer range stays multi-sourced while the cohort got single-sourced[maintenance] ``
The literal '>=0.33.2 <0.34.0' now lives in package.json:185, pnpm-workspace.yaml:28, scripts/lib/packed-package-test.mjs:3, and scripts/conformance-manifest.test.mjs:59 — this PR edited all four in lockstep (a pre-existing pattern it extends). The PR's own cohort work demonstrates the better shape (one manifest + a checker); the sandbox range could be read from package.json in packed-package-test.mjs the same way the workflow now reads refs from release/cohort.json, so the next bump touches one
🎯 Usefulness Audit
🟡 provisionSupervisor's timeoutMs is documented as an admission wait but implemented as the whole run's wall-clock deadline[ergonomics] ``
ProvisionSupervisorRequest.timeoutMs is documented as 'Maximum time to wait for worker admission and terminal readiness' (src/runtime/supervise/provision-supervisor.ts:74), but rootBudget wires the same value as budget.deadlineMs (:414-419), which bounds the entire provisioned supervisor session — the worker is killed when it fires. Braid's caller already treats it as the run-lifetime knob (supervisor.mjs:509-512), so adoption is not blocked, but a future caller following the doc would set a sho
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 2 (2 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 407.9s (2 bridge agents) |
| Total | 407.9s |
💰 Value — sound-with-nits
A release train that adds provider-owned interactive workers (durable attach, steer-with-acks, provisionSupervisor) by correctly delegating terminal replay to Sandbox's exact session handle instead of mirroring it, plus a single-source release-cohort manifest replacing hand-pinned CI refs — coherent
- What it does: Despite the 'chore(release)' title, this is a 12-commit release train (7554 insertions, git rev-list origin/main..HEAD = 12). Concretely it adds: (1) a new worker seam, workerFromInteractiveProvider (src/runtime/supervise/interactive-worker.ts:118), whose executor starts one provider-owned native coding-agent TUI per supervised worker and composes the pre-existing retained-interactive lifecycle (s
- Goals it achieves: Let a supervised worker be a live provider-native interactive process that survives supervisor crashes and can be re-attached and steered by another process or a human — with exactly one owner of session state (the provider) and Runtime holding only digested binding/ack files. The PR body's own blocker is resolved at HEAD: commit e65eb09 locked pnpm-lock.yaml to @tangle-network/sandbox@0.34.0 with
- Assessment: Good, and unusually disciplined about non-duplication. The interactive-worker header states the contract explicitly ('does not create a second stream, replay buffer, session id, or cancellation protocol' — interactive-worker.ts:4-6) and the code honors it: every session operation routes through the retained-interactive module that already existed on main (origin/main:src/runtime/index.ts already e
- Better / existing approach: None — this is the right approach. Searches run: git grep for attachAgentTerminal on origin/main (absent), interactive in origin/main:src/runtime/environment-provider.ts (absent), workerFromBackend/attachWorker usage (the existing workerFromBackend seam serves bridge-backed loop workers — a different ownership model, and the new seam composes rather than forks it), and retained-interactive* module
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error event without a message: {"type":"error","timestamp":1787950231130,"sessionID":"ses_fb5dc9318ffelmGxpDQOqbNP2K","error":{"name":"UnknownError","data":{"message":"Unexpected server error. Check server logs for details.","ref":"err_f0314ae6"}}}
🎯 Usefulness — sound
A coherent release+delegation change: Runtime deletes its own terminal-replay implementation in favor of Sandbox's exact attachAgentTerminal API (peer range moved to the one Sandbox version that has it, now published and locked), and consolidates previously-duplicated workflow dependency pins into o
- Integration: Fully wired and reachable. (1) The cohort manifest is consumed by both workflows: .github/workflows/publish.yml:31-33 and .github/workflows/ci.yml:81-83 run scripts/release-cohort.mjs --github-output, and I ran node scripts/check-publish-workflow.mjs successfully — it asserts the cohort reader step, one checkout per cohort package driven by manifest outputs, and --cohort-manifest usage in both fil
- Fit with existing patterns: Improves fit rather than competing. Commit 19709d3 removed ~276 lines from src/runtime/environment-provider.ts, replacing Runtime's own replay/attach machinery with delegation to Sandbox's InteractiveSessionHandle.attachAgentTerminal — one owner for the exact session handle instead of two. The cohort manifest replaces hardcoded ref pins duplicated across ci.yml and publish.yml (which had already d
- Real-world viability: Holds up past the happy path. Duplicate invocation is rejected via non-recursive mkdir as a cross-process lock (provision-supervisor.ts:155-166); durable bindings are digest-verified with fail-loud collision detection (worker-interactive.ts:84-88) and written with fsync/atomic-rename discipline; missing Sandbox capability degrades to an explicit ValidationError naming the gap rather than an obscur
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
💰 Value Audit
🟡 Durable-file helper trio triplicated across supervise modules[duplication] ``
writeDurableFile/syncDirectory/assertNoSymlinkDescendant are now private copies in three files: pre-existing run-layout.ts:948,966 (extended by this PR) and new interactive-admission.ts:407-452 and worker-interactive.ts:352-420. These ~60-line helpers carry subtle correctness (wx-flag writes, fsync ordering, EEXIST race handling, symlink-traversal guards); a fix in one copy will drift from the others. Extracting a shared durable-file module in src/runtime/supervise/ would remove the risk. Weak b
🟡 provisionSupervisor embeds product-specific defaults in the shared runtime package[maintenance] ``
src/runtime/supervise/provision-supervisor.ts:45 hardcodes DEFAULT_SANDBOX_ENDPOINT 'https://sandbox.tangle.tools', :46 a fixed WORKER_TASK string, and :191 reads the Braid-specific environment key BRAID_SUPERVISOR_WORKSPACE. A caller-facing composition API in @tangle-network/agent-runtime carrying one product's endpoint and env-key names is a boundary smell; endpoint should default at the caller (Braid) and the workspace key generalized or passed explicitly. Acceptable as @experimental (marked
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
tangletools
commented
Aug 28, 2026
|
| State | Detail |
|---|---|
| Interrupted | webhook restarted |
No review verdict was produced for this run. Trigger a fresh review on the current PR head if the PR is still open.
tangletools · #1017 · model: kimi-for-coding · updated 2026-08-28T21:21:33Z
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — c6e5a019
This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.
tangletools · auto-approval · reason: drewstone_author · 2026-08-28T21:22:25Z
tangletools
commented
Aug 28, 2026
|
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 5d84de67
This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.
tangletools · auto-approval · reason: drewstone_author · 2026-08-28T21:43:40Z
drewstone
commented
Aug 28, 2026
@tangletools review now |
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 5d84de67
This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.
This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.
tangletools · auto-approval · reason: drewstone_author · 2026-08-28T21:45:11Z
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 4 (4 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 109.8s (2 bridge agents) |
| Total | 109.8s |
💰 Value — sound-with-nits
A large but coherent release that adapts Runtime to Sandbox 0.34's interactive sessions (terminal attach/replay delegated to the provider's exact session handle), adds caller-owned durable supervisor provisioning over the existing worker/coordination seams, and pins releases to an exact first-party
- What it does: Four concrete deltas. (1) Sandbox peer range moves >=0.31 <0.32 to >=0.34 <0.35 (package.json:184) and src/runtime/environment-provider.ts grows the adapter for Sandbox 0.34 interactive sessions: startInteractive/interactive(ref)/attachAgentTerminal are mapped onto the neutral AgentEnvironmentProvider contract with exact-ref validation (environment-provider.ts:911-984), so terminal attach and repl
- Goals it achieves: Unlock Sandbox 0.34's native interactive-agent capability under Runtime's durable control contracts; make a provider-backed worker attachable and steerable across processes using the already-existing acknowledged steer/cancel inbox pattern (writeWorkerSteer/cancelWorker predate this PR at origin/main run-layout.ts:237/396 — this extends, not forks); make published Runtime verifiable against one ex
- Assessment: Good on its merits. It follows the repo's stated layering: Sandbox-specific wire stays in the adapter, the neutral contract stays in agent-interface, workers enter through the one MakeWorkerAgent seam, and the supervisor entry is documented and structured as a thin owner of existing primitives — no second supervisor protocol. The durable-file.ts consolidation is real, not nominal: run-layout.ts:62
- Better / existing approach: None — this is the right approach. I searched for prior art before concluding: no existing provisioning entry duplicated provisionSupervisor (grep provisionSupervisor — only the new TUI export and tests); interactive workers reuse retained-run/reconnectRetainedInteractiveRun rather than building a second replay path (interactive-worker.ts:28, worker-interactive.ts:183); the steer/cancel acknowledg
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error event without a message: {"type":"error","timestamp":1787953457380,"sessionID":"ses_fb5ab585cffeuULXsyk2ZPhGZG","error":{"name":"UnknownError","data":{"message":"Unexpected server error. Check server logs for details.","ref":"err_e1bfd72f"}}}
🎯 Usefulness — sound-with-nits
A coherent release: Sandbox 0.34 cohort enforced mechanically from package.json as single source of truth, genuine dedup of durability primitives into one shared helper, and a caller-owned provisionSupervisor that composes existing Runtime primitives rather than inventing a parallel protocol.
- Integration: Fully wired. provisionSupervisor (provision-supervisor.ts:145) is exported from both the runtime entry (src/runtime/index.ts:820) and the TUI entry, whose comment names the imminent external caller: 'Braid imports the TUI entrypoint beside the kernel entrypoint' (src/tui/index.ts:24-32). attachWorker consumes the binding that provisionSupervisor waits for (worker-interactive.ts:147, provision-supe
- Fit with existing patterns: Fits the codebase grain. durable-file.ts is true consolidation, not a new layer: the diff removes the previously duplicated inline syncFile/syncDirectory/isAlreadyExists/assertNoSymlinkDescendant from run-layout.ts (124 lines removed) and identical no-clobber publication code from interactive-admission.ts and worker-interactive.ts; all four modules now import the shared helpers. provisionSuperviso
- Real-world viability: Error paths are handled, not just the happy path: the duplicate-start race is closed by exclusive mkdir of the run directory before any resource exists (provision-supervisor.ts:159-170); cleanup is idempotent with a frozen receipt and fails loud on unconfirmed teardown (lines 331-378, 358-362); timeoutMs is the full-lifecycle deadline and post-admission expiry is tested (test:471-489); attachWorke
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
🎯 Usefulness Audit
🟡 ProvisionSupervisorConnection.credentialRef is declared but never read[ergonomics] ``
rg over src/ and scripts/ shows the only occurrence is the declaration at provision-supervisor.ts:64. The doc says Runtime neither resolves nor persists it, so it is inert surface on an experimental interface — a caller may assume it selects a credential. Drop the field or keep it only if the named external consumer (Braid) actually passes it for its own bookkeeping.
🟡 Two write-then-rename sites in run-layout.ts were not consolidated onto writeAtomicDurableFile[problem-fit] ``
writeWorkerCancellation (run-layout.ts:558-565) and writeRunCancellation (run-layout.ts:677-684) still hand-roll tmp+renameSync with no fsync, while the new shared writeAtomicDurableFile (durable-file.ts:105) fsyncs file and directory. Pre-existing code, so not a regression, but the PR that centralizes durable writes leaves two durability-weaker siblings beside the helper; a follow-up one-line swap each would finish the consolidation.
💰 Value Audit
🟡 Cancellation acknowledgement writers not migrated to the shared durable writer[duplication] ``
The PR's stated goal is one durable writer shared across run-layout steer files, and it delivers for steer (writeWorkerSteerAcknowledgement uses writeAtomicDurableFile, run-layout.ts:478). But the documented steer/cancel twins writeWorkerCancellation (run-layout.ts:558-565) and writeRunCancellation (run-layout.ts:677-684) still hand-roll randomUUID-tmp + writeFileSync + renameSync with no fsync, in the same file the PR heavily edited. Pre-existing code, so the PR doesn't worsen it, but the ackno
🟡 Third atomic no-clobber writer now coexists in the package[duplication] ``
src/candidate-execution/claim-file-store.ts:349-396 keeps its own async linkSync-based no-clobber writer (writeRecordIfAbsent + syncDirectory + isNodeError) with the same EEXIST/ENOENT semantics as the new sync publishExclusiveDurableFile (durable-file.ts:30-61, 145-160). The sync/async split and the authorizePublish hook make immediate unification nontrivial, and durable-file.ts is correctly local to supervise/, but the package now carries three atomic-write implementations (claim-file-store, d
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
Uh oh!
There was an error while loading. Please reload this page.
Summary
Verification
Review fixes
Release state