Skip to content
GRPNR.

04 — Steelman Court

Steelman court run 2026-07-19: per candidate, two independent Sonnet agents — an advocate and a prosecutor, each working from the same evidence with no shared context or knowledge of the other’s brief — argued the case, followed by one cross-examination pass where each side read and rebutted the other’s brief. Evidence citations [E1]-[E12] carry over from the phase-1 research digest (evidence/r1-research-digest.txt); candidates A-D are defined in 03-options.md.

Candidate A — All TypeScript

Advocacy

Verdict. Candidate A wins because the decision surface is smaller than it looks: 2 of 4 products (WorkLedger, Atlas) are already pinned to Encore.ts/TS [E2], Harness is architecturally bound to a TS workspace regardless of this ADR [E3], and the obs stack cost (~550-700MB) is identical under every candidate [E5]. That leaves FleetOps as the sole greenfield call, and putting it on one compiled Bun/Hono process with SQLite costs a Bun-floor premium of tens of MB [E6] that is immaterial against a host where hundreds of agents already consume tens of GB [E1] — while avoiding Rust’s markedly worse real-world issue-resolution rate and larger fix blast radius [E7], plus a second toolchain, second CI lane, and a codegen bridge to keep FleetOps’s contracts in sync with TS services it must talk to anyway [E2]. It defers any real bet on a second systems language until hundreds-of-agent-scale evidence actually exists, which today it does not [E9].

  • Footprint is noise at this scale. Three of four always-on cost centers are candidate-invariant (WorkLedger+Atlas on Encore.ts [E2], Harness batch/TS-bound [E3], obs stack fixed ~550-700MB [E5]); the only live decision is FleetOps, where Bun’s ~35-45MB idle premium over Rust/Go floors [E6] is single-digit-to-tens-of-MB against a fleet where 49 processes alone already cost 7.64GB [E1], and one compiled process avoids the 30-75MB-per-extra-process tax a multi-binary polyglot FleetOps would pay repeatedly [E6].
  • Agentic maintainability favors TS. 2-of-4 products are already TS-locked and the third is TS-adjacent by mandate [E2, E3]; extending TS to FleetOps makes it 3-of-4, buying one type system/lint/package-manager surface, against Rust’s 21-28% real-issue resolution vs ~70% for Python-tier languages and 9.8-files/139.9-LOC fix blast radius, plus benchmark failures and jobserver core contention [E7].
  • One ops vocabulary. Encore’s built binary and Bun’s --compile binary converge on “ship one binary, run one binary”; on-call reasoning uses one crash/memory/profiler mental model instead of three, and one OTLP SDK spans every always-on product [E5, E6, E10, E11].
  • Zero net-new toolchain. WorkLedger/Atlas/Harness ship on pre-existing TS templates/ADRs [E2, E3]; FleetOps is the only greenfield build, and Hono plus htmx/Datastar needs no bundler or SPA pipeline, whereas adopting the existing Rust/Go tools means porting terminal-rendering logic into an HTTP+SSE shape AND standing up a CI/lint pipeline that exists nowhere else in the fleet [E2, E3, E4, E8].
  • Future-aware, not pre-committed. FleetOps sits behind an HTTP/SSE contract as one swappable process; committing to a second systems language now, before hundreds-of-agent-scale footprint data exists [E9], is the premature optimization the decision constitution warns against.
  • Lowest CI ceremony. vitest already spans WorkLedger/Atlas/Harness [E3]; FleetOps’ in-process pollers (fake clock/fetch) and SQLite (in-memory/on-disk, no server to stand up) are maximally test-drivable versus a Postgres testcontainer or cross-language integration harness a Rust/Go alternative would need.
  • Compiler-checked cross-context contracts. The four bounded contexts stay isolated at the process/store level regardless of language; TS additionally makes the contracts that do cross contexts compiler-checked shared types instead of a hand-maintained protobuf/OpenAPI bridge a polyglot fleet would need just to let Rust or Go talk to services staying TS anyway [E2].

Strongest single point. Three of four always-on cost centers are already fixed before this decision (WorkLedger+Atlas on Encore.ts [E2], Harness bound to TS by its own ADR [E3]), and the obs stack is candidate-invariant [E5] — so FleetOps is the ONLY live decision, and the footprint delta at stake (Bun ~35-45MB vs Rust ~10-25MB [E6]) is noise against a fleet where hundreds of agents alone consume tens of GB [E1], while the agentic-maintainability delta is not noise: Rust’s real-issue resolution rate is 21-28% vs ~70% for Python-tier languages, with fixes touching 9.8 files/139.9 LOC on average vs 1.25 files/14.3 LOC [E7]. Choosing anything but TS for FleetOps trades a real, compounding maintenance cost for an unmeasurable memory saving.

Prosecution

Verdict. Candidate A’s “one language” pitch is coherent in the deck but not in the running system: it discards 13k LOC of already-working Rust/Go FleetOps tooling [E4] to rebuild ingest+board+pollers from scratch in a single-threaded Bun process whose SQLite writer has a documented degradation ceiling a fleet-wide burst can plausibly reach [E6, E1]; it bets the two highest-stakes always-on products on Encore.ts, a runtime with zero published idle-RSS data in an exercise entirely about idle RSS [E10]; and its homogeneity claim quietly excludes the Python mitmproxy dependency already bound into Harness [E3] and the Go-based VictoriaMetrics/Grafana stack doing the actual observability [E5] — the box agents will actually operate and debug is majority non-TS regardless.

  • Discards 13k LOC for purity. FleetOps is the one genuinely undecided product [E4]; Candidate A throws away the working fleetops Rust TUI (6.4k LOC) and ghmonitor (Go, 6.6k LOC) to rebuild ingest+board+pollers+digest from scratch, violating ladder-rung-2 reuse with no cited TS reference implementation to de-risk it [E4, E2, E3].
  • “One language” is false at the systems level. vmsingle and Grafana are Go binaries, Postgres is C, and Encore.ts’s own runtime is a 67k-LOC Rust core [E5, E10] — the single mental model holds only at the first-party source layer, not at the systems-debugging layer where incidents actually get diagnosed.
  • Hidden Python dependency. Harness’s own binding ADR requires mitmproxy as a separate Python process [E3], a toolchain the “one language” framing quietly omits rather than adds.
  • Bets the riskiest unknown on the least-measured component. The whole decision is an idle-memory exercise [E1], yet Encore.ts — carrying WorkLedger and Atlas — has zero published RSS numbers anywhere in the evidence, only a self-reported req/s benchmark, while [E9] explicitly warns hundreds-of-agent-scale footprint data “exceeds documented public practice” [E10, E1, E11, E9].
  • TS is the weaker pick for the one component with real freedom. [E7]’s own benchmark has TS as slowest/priciest mainstream (133s, $0.62) vs Go (40/40, 101.6s, $0.50); the deeper repo-level real-issue-resolution study has no TS data point at all, so Candidate A leans on the shallower benchmark because the deeper one is silent, not because it supports TS [E7, E4].
  • “One language” does not collapse to “one process.” Every fresh Node/Bun process still pays its own ~30-75MB baseline [E6]; Encore’s built binary, the FleetOps Bun process, and the Harness CLI each pay that tax independently on a host where tooling headroom is already flagged as small [E6, E1, E3].
  • Doesn’t escape build-time core contention either. [E7] flags cargo’s jobserver as a mark against Rust, but Candidate A still carries tsc typechecking, vitest, and Encore’s own Docker-based build path — the risk named against the rejected alternative doesn’t cleanly disappear, it’s just not priced into the pitch [E7, E10].
  • Worst case: fleet-wide burst head-of-line-blocks the one process that matters most. FleetOps’ single Bun event loop serializes ingest, SSE fan-out, polling, and digest computation on one thread; SQLite WAL degrades past ~100 concurrent writer threads [E6], and a coordinated fleet event is exactly the load pattern that could push toward that boundary — during an incident, when the board is most needed live. With the working Rust/Go fallback discarded (point 1) and Encore’s memory behavior unmeasured (point 4), operators have no way to bisect whether the stall is FleetOps’s event loop, SQLite, or Encore [E6, E1, E9, E4, E10].

Strongest single point. The named worst-case scenario is the strongest single attack because it’s concrete and compounding rather than abstract: FleetOps collapses hook-ingest, SSE board, REST pollers, and digest computation onto one single-threaded Bun/Hono process over one SQLite writer [E6], and a fleet-wide burst of hundreds of concurrent agents [E1] is exactly the load pattern that pushes toward SQLite WAL’s documented ~100-concurrent-writer degradation point — at the precise moment operators most need the live board, reproducing the “coordination, not RAM” bottleneck the Anthropic case study already warns about [E9]. It lands hardest because it also indicts the rest of Candidate A’s story: there’s no working Rust/Go fallback to lean on (discarded per point 1) and no measured Encore.ts memory behavior (point 4) to help triage the incident, so a single-process design failure becomes an undiagnosable multi-unknown incident rather than an isolated, bisectable fault.

Cross-examination

Advocate rebuts prosecution. Prosecution’s worst-case misreads what [E6] measures: the 100-concurrent-writer-THREADS ceiling describes multi-threaded contention on a shared connection, but Candidate A’s topology is the opposite — one Bun event loop, one SQLite writer connection, all requests serialized through a single execution context by construction, so the cited degradation mode doesn’t map onto this architecture. The throughput number that DOES map is [E6]’s 8.4k writes/s at 64 workers, orders of magnitude above plausible hook-event cadence from “hundreds of agents,” not sustained max-throughput load. The named failure mode (one process owns ingest+SSE+poll+digest) is a topology choice, not a language property — a Rust or Go single-binary FleetOps built the same way has identical coupling, and the fix (worker_threads, or a second process) is available in Bun just as in Rust/Go, consistent with advocate’s own deferred-evolution point rather than a reason to pre-pay the cost now. And “no measured Encore baseline to triage against” isn’t Candidate-A-specific: Encore.ts carries WorkLedger+Atlas under every candidate [E2], so that unknown is baked into the substrate before this decision starts.

Prosecution rebuts advocacy. Advocate’s strongest point substitutes “Rust” for “any non-TS choice” when the digest doesn’t support that swap: FleetOps’s existing reusable asset is ghmonitor in Go [E4], and Go posts the strongest agentic-fit numbers in the whole packet (40/40, 101.6s, $0.50, near-instant compiles, no jobserver contention) [E7] — the 21-28% real-issue-resolution figure is cited only for Rust, with no TS data point either, so the maintainability delta advocate leans on establishes TS-over-Rust, not TS-over-Go, which isn’t the comparison FleetOps actually forces. Second, “the footprint delta is noise” is proven only for idle RSS, the one metric the digest happens to supply [E6]; FleetOps is the single component whose load scales directly with the host constraint being optimized [E1], and under-load behavior (event-loop serialization, GC pauses vs a no-runtime binary) is exactly the axis idle-RSS numbers don’t capture — and exactly the axis the single-process design’s failure mode lives on.

Residual open questions.

  • Encore.ts’s actual idle RSS at hundreds-of-agent scale is unpublished [E10] — no candidate, including A, can be scored on the substrate’s real footprint, only on FleetOps’s incremental delta.
  • No load-test or event-rate model exists for FleetOps’s expected hook-ingest volume under “hundreds of concurrent agents” — both “SQLite/single-thread is fine” and “it risks head-of-line blocking” are extrapolations from unrelated benchmarks [E6], not measurements of this workload.
  • Whether isolating FleetOps’s ingest/SSE/poll/digest paths onto separate threads or processes (available in Bun/Node, not just Rust/Go) would fully close the coupling risk without abandoning single-language coherence is untested by either side.
  • Whether the existing Rust TUI / Go ghmonitor could be reused as libraries or subprocesses behind a TS-owned HTTP/SSE shell (partial reuse) rather than the all-or-nothing “discard vs. separate binary” frame — the digest evaluates neither hybrid.
  • The repo-level real-issue-resolution study [E7] has no cited Go data point, so whether Go carries Rust’s maintainability penalty (the actual non-TS alternative FleetOps has a reusable asset for) is unresolved.
  • No source addresses V8/Bun GC pause behavior or event-loop latency under sustained concurrent SSE fan-out at fleet scale — a load-behavior gap neither side can close with [E1]-[E12].

Candidate B — Rust local plane

Advocacy

Verdict. Candidate B is the only FleetOps architecture that turns the program’s two hardest constraints — RSS floor at fleet scale [E1, E6] and “boring tech = reuse what’s already there” — into the same decision instead of a tradeoff. It reuses 6.4k LOC of already-correct, already-shipping Rust domain logic in-process [E4] rather than rewriting or bridging to it, lands at the bottom of the measured RSS range for this service shape [E6], and keeps the local-plane tool estate on one toolchain (4-of-5 tools already Rust [E4]) without touching the pinned Encore.ts/Postgres decisions [E2] or the TS harness ADR [E3]. Its one honest cost — Rust’s weaker agentic-fit numbers [E7] — is structurally contained by keeping the Rust surface to a single small crate/binary, which is also the mitigation [E9] independently points to for avoiding parallel-compile thrash.

  • Footprint hits the actual constraint, not just a low number. [E1] shows the budget is already tight before FleetOps exists (49 processes cost 7.64GB); [E6]’s floor comparison (axum 1-25MB vs Go 6-60MB vs Bun 35-45MB vs Node 60-75MB) is the difference between FleetOps being noise or a real line item, and Candidate B’s ~10-25MB target sits at the bottom, avoiding the per-extra-process tax by running pollers as tokio tasks instead of separate processes.
  • In-process reuse of the 6.4k-LOC Rust core is the strongest “boring tech” move available. [E4] shows session-discovery/status-derivation logic already exists and ships; linking it as a library crate means zero new domain logic and zero IPC, versus reimplementing 6.4k LOC in Go/TS or reintroducing subprocess lifecycle management and a serialize/parse hop.
  • Agentic friction is real but scoped away from where it bites. Rust’s weaker real-world numbers [E7] describe large, tangled repos; Candidate B is a small, single-purpose binary, and the compile-fix loop still functions (Claude Code beat Cursor 72% vs 58% on a Rust benchmark) — the borrow checker is a compile-time guardrail against data races in exactly the shared-state service other agents depend on for fleet visibility.
  • Single static binary, no second asset pipeline. rust-embed bundles the UI with no node_modules or build step; rusqlite WAL is one file with no separate DB process, keeping FleetOps’s blast radius isolated from the shared Postgres WorkLedger/Atlas depend on [E2, E8].
  • Least new code of any cross-language alternative. The hard part — deriving agent/session status across a live fleet — is done; every rival architecture pays for a rewrite of that 6.4k LOC or a subprocess-polling bridge to it, work that is 100% net-new regardless of which other language is chosen.
  • Resolves only the one open decision. FleetOps language is the one placement question actually undecided [E4]; WorkLedger+Atlas and Harness stay on their already-pinned substrates [E2, E3] untouched — solve the binding constraint now, defer the non-binding one.
  • Clean ports-and-adapters, and the SQLite single-writer weakness becomes moot by construction. Domain crate, axum adapter, and rusqlite adapter are independently testable; FleetOps ingest is naturally single-writer by design, so the BEGIN IMMEDIATE serialization pitfall [E11] never triggers.
  • Plugs into the already-evidenced minimal observability stack and de-risks the open TUI-vs-Web ADR. OTLP direct to vmsingle, no new component [E5]; because the web board is a thin adapter over the same reused domain crate, if the founder’s own TUI-vs-Web question [E12] resolves toward TUI later, only the outermost adapter is discarded.

Strongest single point. The in-process reuse of the existing 6.4k-LOC Rust session-discovery/status-derivation core [E4] is uniquely available to this candidate and simultaneously wins on two axes at once: it is the largest reduction in new code of any option (no rewrite, no subprocess-polling bridge, no IPC/serialize hop) AND it is what makes the ~10-25MB RSS floor [E6] achievable, since eliminating a poller subprocess also eliminates that subprocess’s own baseline memory tax. No Go or TS candidate can make this same claim, because the reusable asset itself is written in Rust — reuse and footprint collapse into one argument instead of two competing ones.

Prosecution

Verdict. Candidate B wins on a narrow, unverified metric (idle RSS) while losing on every axis the decision constitution and evidence digest actually weight: agentic-fit (Rust is the only benchmarked language with real failures, 21-28% real-issue resolution vs Python’s ~70%, 7-10x larger fix footprints [E7]) for the exact component under continuous AI development; CPU contention via cargo’s jobserver against the stated hundreds-of-agents hard constraint, evidenced by a real case study rather than speculation [E9, E1]; an unaudited async-safety risk from merging a TUI-era crate into a live SSE reactor [E4]; an inflated reuse argument that counts LOC from unrelated Rust tools [E4]; an RSS estimate extrapolated from minimal benchmarks rather than measured for this composition [E6, E9]; hidden model-escalation cost under the cheapest-agent-first operating mode [E7]; and a stack-fragmentation cost against the constitution’s own boring-tech weighting [E2].

  • Agentic-fit inversion. Rust is the only benchmarked language with outright failures (38/40) and 21-28% real-issue resolution vs Python’s ~70%, fixes touching 9.8 files/139.9 LOC on average — yet the merged-in surface Candidate B creates (SSE handlers, rusqlite WAL, tokio cron, the crate boundary) is exactly the new, actively-touched code, not the frozen 6.4k LOC being “reused” [E7].
  • Cargo jobserver contention hits the actual scarce resource. Grit named parallel Rust compiles as the dominant real hardware bottleneck via swap/CPU thrash; the host has 14 cores serving hundreds of agents with thin headroom, so every FleetOps compile-edit-test loop periodically starves the rest of the fleet — a recurring CPU event the RSS headline says nothing about [E9, E1, E7].
  • “Compiler-as-guardrail” is contradicted by the same benchmark it leans on. Rust has the worst repo-level resolution rate cited despite being compiled and statically checked, with 7-10x larger fix footprints — the guardrail catches lifetime/type errors, not logic errors, and its cost is slower iteration and larger diffs, the opposite of “test-drivable, agent-developed” [E7].
  • In-process merge of the ported TUI crate is an unaudited async-safety risk dressed as “reuse.” The crate was built for a TUI’s occasional-refresh polling; nothing establishes it’s non-blocking or spawn_blocking-isolated, so if session discovery does synchronous filesystem/process scanning, it stalls the axum reactor for every connected client as live-session count scales toward hundreds [E4, E1].
  • The reuse case is inflated. Only the 6.4k LOC fleetops-TUI crate is domain-relevant; “four of five tools are Rust” bundles in unrelated tools, while ghmonitor (Go, 6.6k LOC) is an equally-sized, domain-adjacent asset never weighed against Rust [E4].
  • The RSS estimate is extrapolated, not measured. The cited 1-25MB axum figures come from hello-world benchmarks; Candidate B’s actual binary adds rusqlite WAL, rust-embed payload, SSE fanout, and live-session scanning at scale, and nobody has published footprint data for this composition [E6, E9, E1].
  • Hidden dollar-cost escalation. Rust’s higher failure rate and larger per-fix footprint statistically force more retries and costlier-model escalations under the cheapest-agent-first operating mode, on top of Rust already costing more per successful run than Go ($0.54 vs $0.50) [E7].
  • Fragments the stack against the constitution’s own uniformity weighting. WorkLedger+Atlas are pinned to TS/Encore; adding Rust as FleetOps’s primary language locks a 2-primary-language split, and the candidate’s own stated justification includes “matches Robert’s instinct” — a self-disclosed non-technical tiebreaker outside the stated criteria [E2, E4].
  • Worst-case: an emergency FleetOps hotfix at peak fleet load. An urgent fix to the merged crate — statistically touching ~9.8 files, in the one language with measured failures — triggers repeated cargo builds that grab the full 14-core jobserver, stalling the fleet exactly when load is highest, while FleetOps’s own SSE reactor shares that same address space and core budget, degrading the operator’s ability to see the slowdown the build itself is causing [E9, E1, E7, E4].

Strongest single point. Candidate B’s headline metric (idle RSS, ~10-25MB) answers a question the hard constraint doesn’t actually turn on during active development: the scarce resource when hundreds of agents run concurrently on a 14-core host is CPU, not idle memory, and cargo’s jobserver-driven full-core grab on every compile — named directly in the case-study evidence (Grit: swap/CPU thrash from parallel Rust compiles as the dominant real hardware limit) — means every FleetOps dev iteration imposes a fleet-wide stall that the candidate’s own metric never measures and cannot rebut. It picks the one language on the table structurally worst-suited to a compile-heavy TDD loop, for the one product with continuous agentic churn, on the host whose stated hard constraint is exactly the resource that loop consumes.

Cross-examination

Advocate rebuts prosecution. Prosecution’s jobserver argument conflates two different load shapes: Grit’s thrash describes 200+ agents each compiling Rust in parallel across a fleet-wide Rust surface, not one bounded crate iterated on by whichever handful of agents currently own a FleetOps ticket — the evidence never quantifies FleetOps-specific Rust concurrency as more than that. Jobserver core-grabbing is also a tunable default (-j N, CARGO_BUILD_JOBS, cgroup caps), standard practice rather than speculative mitigation, and incremental compilation means a TDD edit-recompile cycle on an already-built, narrow-scope crate recompiles only changed units — a full-core stall is a clean-build/dependency-bump event, rare once the crate stabilizes. And the “emergency hotfix” scenario assumes the compile-time guardrail buys nothing; if it prevents a data race in shared SSE state every other agent reads for fleet visibility, a slower-but-correct fix is arguably safer during an incident than a fast Go/TS fix that typechecks but ships a runtime concurrency bug into the same always-on board. This narrows the risk from “structural, disqualifying” to “real but tunable and load-scoped” — the honest ceiling, not a full defeat.

Prosecution rebuts advocacy. The advocate’s strongest point — “reuse and footprint collapse into one argument” — holds only if the 6.4k-LOC crate is already a clean, async-safe, Send+Sync-callable library. [E4] never establishes that; it documents that the logic exists and ships as a TUI, not that it exposes a public lib.rs API or is safe to invoke concurrently from tokio pollers while an SSE reactor reads shared state live. A TUI built for occasional-refresh polling plausibly does blocking filesystem/process scans between paints — exactly the pattern that stalls a single-threaded-per-core async reactor without a spawn_blocking audit. Converting that crate into a genuinely reusable in-process library is real, unscoped engineering (extract-to-lib, audit every I/O call, verify shared-state safety) the candidate’s framing bundles into “reuse” for free — and that refactor is itself cross-cutting, multi-call-site work, precisely the shape where Rust’s agentic-fit is weakest [E7], landing in the highest-risk part of the stack: concurrent, shared, always-on state. The headline synergy is real only after an un-costed, unaudited integration step is paid for, and nothing in the evidence says that step is small.

Residual open questions.

  • Is the 6.4k-LOC fleetops crate currently built as a lib crate with a public API, or bin-only — i.e., is in-process reuse even mechanically available without a restructure? [E4] doesn’t say.
  • Does the crate’s session-discovery/status-derivation logic perform blocking filesystem/process I/O, and if so, does calling it from tokio tasks under an SSE reactor require spawn_blocking wrapping? No evidence characterizes its I/O model.
  • What is the measured (not extrapolated) RSS of the actual composed binary under a live workload of hundreds of sessions, versus the cited 1-25MB minimal-benchmark figures? [E9] confirms this composition has never been published by anyone.
  • How many agents will realistically be compiling/editing FleetOps concurrently in steady-state versus during an incident — is Grit’s 200+-parallel-compile scenario a plausible FleetOps-specific load, or does actual dispatch route only one or two agents to a given always-on service at a time?
  • Does capping cargo’s jobserver reliably prevent fleet-wide stalls in practice, or can dependency-graph-wide recompiles (lockfile bumps, crate upgrades) still spike core usage unpredictably despite the cap? Untested by either side.
  • Was ghmonitor (Go, 6.6k LOC) evaluated and rejected as a reuse base for the same domain logic, or simply not considered — has anyone costed a Go port against the Rust async-safety-audit cost this exchange surfaced?
  • Is founder instinct a legitimate input to weigh alongside the six stated constitution criteria, or does citing it concede the technical case isn’t fully sufficient on its own?

Candidate C — Go local plane

Advocacy

Verdict. Candidate C is the strongest evidence-backed choice for FleetOps specifically: it lands in the same low-footprint tier as the only comparable rival (Rust) without that rival’s two disqualifying agentic costs — a build system that fights the fleet for cores and a demonstrated collapse in real-issue-resolution reliability with wide-blast-radius diffs [E7] — while adding zero new runtime family to a host already pinned to Encore/Node for WorkLedger+Atlas [E2, E5, E6]. It reuses the existing fleetops/ghmonitor subprocess-JSON seam with no rewrite [E4], needs no Docker/daemon unlike Encore [E10], fits SQLite’s proven single-writer envelope exactly [E6, E11], and closes the loop on the already-decided vmsingle/no-collector/linked-Grafana obs cut while undercutting the case for reinstated Loki [E5, E12].

  • Footprint is additive, not multiplicative. Expected 15-40MB RSS sits in the same band as shipping Go precedents (PocketBase 10MB, Beszel 45-100MB) [E6], and adds no new runtime family beyond the Node/Bun-class runtime WorkLedger+Atlas already commit to [E2, E5] — every avoided fresh interpreter baseline is real headroom returned to the fleet.
  • Best combined success-rate/speed/cost among low-footprint languages, and no CPU fight with the fleet. Go scores 40/40 at 101.6s/$0.50 [E7], matching Python/JS’s pass rate in the cheap-footprint tier, while Rust is 38/40, slower, pricier, and its real-issue resolution collapses to 21-28% with wide blast radius; critically, cargo’s jobserver grabs all cores while go build compiles near-instantly and doesn’t cannibalize the fleet’s CPU budget [E7, E1].
  • One binary, no daemon, no Docker, reuses an existing subprocess seam. go:embed + net/http + SQLite + SSE ships as one static binary; FleetOps consumes fleetops (Rust TUI) and ghmonitor (already Go) through the existing “fleet snapshot” subprocess-JSON seam with zero new integration surface [E4, E10].
  • Stdlib-plus-one-dependency matches the boring-tech constitution directly. net/http + go:embed + a SQLite driver is essentially stdlib; agent iteration speed (not just LOC) favors Go’s fast success-rate/latency/cost numbers over Rust’s borrow-checker compile-fix friction [E7, E8].
  • SQLite is right-sized here, and the substrate stays swappable later. FleetOps’ ingest is board/dashboard-shaped — one writer process producing a read-heavy view — exactly SQLite WAL’s proven envelope; the Postgres-justifying SKIP LOCKED requirement is specific to WorkLedger’s claim path and doesn’t exist in FleetOps’ domain [E6, E11].
  • Trivial, infra-free test seams. net/http handlers are directly testable with stdlib httptest; SQLite tests run against in-memory/tmpfile DBs with zero external infra, unlike an Encore-hosted equivalent needing the Encore daemon for local test runs [E7, E10].
  • Genuinely separate bounded context, no ADR pins it elsewhere. Nothing pins FleetOps’ language or placement [E4]; the subprocess-JSON seam functions as a clean anti-corruption layer, capping blast radius so a FleetOps crash can’t touch WorkLedger’s Postgres-backed claim path [E2, E4].
  • Closes the loop on the obs cut and undercuts reinstated Loki. A Go binary emitting OTLP natively slots into vmsingle with no collector [E5]; because FleetOps’ own SQLite is already the event log for its domain, it removes the strongest remaining argument for the heaviest reconsidered line item, ADR-9’s reinstated Loki [E5, E12].

Strongest single point. The CPU-contention argument in [E7]: cargo’s jobserver grabs all cores during any Rust build/compile-fix cycle, directly cannibalizing the CPU budget the other hundreds of concurrent Claude Code agents need on this exact host [E1] — while Go compiles near-instantly and carries no such contention profile. This is not a marginal footprint delta (Go’s 15-40MB vs Rust’s 1-25MB [E6] is a wash at fleet scale); it is a structural conflict between the nearest low-footprint rival’s tooling and the single hardest constraint stated for this decision. Combined with Rust’s real-issue resolution collapsing to 21-28% vs Python-tier ~70% with 9.8-file/139.9-LOC blast radius per fix [E7], Go is the only low-footprint language in the evidence set that is simultaneously cheap, fast, agent-reliable, and non-competing for the fleet’s own compute.

Prosecution

Verdict. Candidate C’s RSS/CPU-floor argument (~15-40MB, near-Rust) is real and evidence-backed for the idle case [E6], and reusing fleetops/ghmonitor via subprocess is a legitimate boring-tech move [E4]. But its load-bearing claims fray under its own cited evidence at exactly the scale this decision targets. Three risk classes converge: a technical scaling cliff (SQLite’s single-writer assumption [E6] collides with Candidate C’s own multi-poller, subprocess-fan-out design under hundreds of concurrent agents [E1], and the specified CGO driver adds uncapped OS-thread growth on top of that); a portfolio/schedule risk (FleetOps under Candidate C is the only one of four products with zero internal precedent [E2, E3, E4, E10]); and a scope-creep/compliance risk (reviving a Web board with CORS/CSP/HSTS obligations under this repo’s own binding OWASP rules, against the founder’s own recorded TUI preference [E12] and the cited industry precedent [E8]).

  • SQLite single-writer cliff sits directly under FleetOps’s own workload shape. [E6]’s comfort figure explicitly assumes “hook ingest is one writer process”; Candidate C’s design is board+ingest+pollers(plural)+digest in one binary fanning out subprocess calls per monitored session and writing results back to one SQLite file — under hundreds of concurrent sessions, that’s N poller goroutines contending on one DB handle, not the single-writer case the comfort figure describes [E6, E1, E4].
  • mattn/CGO SQLite trades away the single-binary simplicity it’s pitched on. CGO requires a C toolchain at build time and complicates cross-compilation; every blocked cgo call pins its own OS thread, so a burst of concurrent poller/ingest goroutines can grow threads uncapped by GOMAXPROCS, undermining the GOMEMLIMIT discipline the candidate claims — a pure-Go driver (modernc.org/sqlite) sidesteps this and the candidate names CGO as an unforced choice.
  • FleetOps is the only greenfield stack in the whole decision. WorkLedger/Atlas fork an existing Encore.ts template with a published production case study [E2, E10]; Harness is a common TS workspace package [E3]; Candidate C lands on Go+CGO-SQLite+Datastar/htmx-via-go:embed, a combination with zero cited internal precedent anywhere in the digest [E4].
  • Web board revives OWASP obligations the founder’s own TUI answer would have avoided. [E12] records the founder explicitly asking whether the honest interface is a TUI pane and calling it “the cheapest possible pivot”; Candidate C doubles down on Web without revisiting that signal, opting back into the repo’s mandatory CORS/CSP/HSTS checklist that a TUI would opt out of entirely [E12, E8].
  • One binary fuses four failure domains against the DDD-boundaries requirement. Ingest, board, SSE fan-out, pollers, and digest generation share one process with no isolation forcing boundary; concurrent goroutine/channel code is also the hardest Go pattern to TDD deterministically, in tension with “must be test-drivable” — [E7]’s 40/40 measured isolated single-task completion, not this concurrent-systems pattern.
  • “Best agentic-fit” cites the friendlier of two benchmarks. [E7]’s isolated-task benchmark (Go 40/40, mostly tied with everything including TS) is not the harder repo-level real-issue-resolution benchmark, which has zero reported Go figure — the claim overstates what the evidence supports.
  • Subprocess fan-out adds fork/exec load exactly where headroom is thinnest. Every poll cycle pays process-spawn cost and re-parses full JSON; the host already runs hundreds of processes against thin free memory at only 49 processes today [E1], and FleetOps’s own ingest mechanism competes for the same scarce process-creation bandwidth the fleet needs, scaling with the exact condition it exists to monitor [E1, E4].

Strongest single point. The SQLite single-writer cliff ([E6]) is the strongest attack because it is directly evidence-cited, quantitative, and non-speculative: the digest’s own comfort figure for SQLite (“hundreds of events/sec, easily”) is explicitly conditioned on a single writer process, and Candidate C’s architecture — one binary running multiple concurrent pollers each subprocess-fetching and writing fleet-snapshot data — is precisely the multi-writer shape the same evidence item flags as degrading past ~100 concurrent writer threads. Compounded by the CGO (mattn) driver’s OS-thread-per-blocked-call behavior, which can grow threads uncapped by GOMAXPROCS under exactly that concurrent load, this is not a hypothetical edge case but the direct, foreseeable consequence of the candidate’s stated design meeting its stated target scale.

Cross-examination

Advocate rebuts prosecution. Prosecution’s cliff argument assumes an unserialized-writer implementation Candidate C never specified. The board/ingest/poller/digest split is I/O-fan-out shaped: N pollers subprocess-fetch JSON concurrently, but nothing requires each poller goroutine to hold the DB handle — the standard Go pattern for exactly this shape is fan-out/fan-in, pollers write results to a channel, one dedicated writer goroutine drains it and owns the SQLite handle, preserving [E6]’s “one writer process” comfort case regardless of poller count at zero additional dependencies. Actual write rate is bounded by poll interval, not writer count, and hundreds of agents polled every N seconds is nowhere near [E6]’s 8.4k writes/s comfort ceiling. On CGO: conceded outright — mattn’s thread-pinning is real and unmeasured, but it’s an implementation detail, not a design commitment; modernc.org/sqlite (pure Go, no CGO) is an available drop-in that eliminates the thread-pinning risk and the C-toolchain cross-compile dependency, at no cost to the “one static binary” pitch. Prosecution’s compound attack loses its second half for free and its first half to a channel that was always the idiomatic Go answer to this fan-out shape.

Prosecution rebuts advocacy. The jobserver argument conflates build-time cost with the stated runtime constraint. cargo’s all-cores grab fires during compile-fix loops, not while a compiled binary serves requests; the hard constraint is “lowest possible always-on memory/CPU/latency,” and on that specific axis [E6]’s own numbers put Rust’s runtime RSS floor at parity-or-better versus Go’s — a compiled Rust binary at idle is a static artifact indistinguishable from Go’s. Advocate’s “structural conflict” is a development-cadence cost, not a production-footprint cost. It also doesn’t even apply to Candidate C’s own architecture: fleetops, bridge, ground-control, and tokenomics are existing, stable, already-built Rust binaries [E4] consumed via subprocess-JSON — nobody is proposing new Rust source that agents will be iteratively recompiling during peak fleet load; the actual new code (board/ingest/pollers) is Go either way in Candidate C. Finally, the 40/40-vs-38/40 delta is drawn from the isolated-task benchmark prosecution already flagged as the friendlier of two measures, with zero Go data point on the harder repo-level metric where Rust’s 21-28% is known-bad but Go’s equivalent is simply absent from evidence — the advocate cannot claim “best combined success-rate grade” and rest it on a benchmark it elsewhere needs to discount for Rust.

Residual open questions.

  • Does the fan-out/fan-in channel pattern (pollers → single writer goroutine) actually hold under real hundreds-of-agent load, or does channel backpressure itself become the bottleneck?
  • What is FleetOps’ actual target write rate at fleet scale — bounded by a configurable poll interval, or does the board need near-real-time push that multiplies write pressure toward SQLite’s cited limits?
  • Is modernc.org/sqlite (pure-Go, no CGO) performance-equivalent to mattn/CGO for this workload, or does it carry its own unmeasured penalty?
  • No evidence item measures actual OS-thread growth under CGO blocked-calls at the specific concurrency level FleetOps would hit — is this a real cliff at target scale or a theoretical one never exercised?
  • Is the founder’s TUI signal [E12] still a live, reconsiderable objection to Candidate C’s Web board, or was ADR-2’s override final and out of scope for this round?
  • Does the mandatory OWASP header/CORS/CSP checklist apply at full force to a loopback-only, 1-2-operator tool, or is there a documented internal carve-out for non-internet-facing services?
  • What is Go’s repo-level real-issue-resolution rate — the harder metric where Rust collapses to 21-28% and Python holds ~70%? [E7] has no Go data point, so “best agentic fit” is asserted, not evidenced, by either side.
  • What is the measured (not inferred) CPU/scheduling cost of repeated subprocess fork/exec at hundreds-of-pollers scale?
  • Has anyone load-tested this exact composed shape at even a fraction of “hundreds of agents,” or does the comparison rest entirely on component-level benchmarks never composed into the actual system?

Candidate D — Do less: TUI + Grafana only

Advocacy

Verdict. Candidate D wins on every axis the constitution weights most (footprint, simplicity, boring tech, DDD boundary correctness) by declining to build anything new that would need to run continuously: it reuses the existing fleetops TUI [E4], writes hook events straight to SQLite with no daemon, runs pollers/digest as host cron, and folds the web requirement into the Grafana surface already standing per ADR-5 [E12] — landing at ~500-600MB always-on, under even the research’s own aggressively cut observability floor [E5], with zero new services to deploy, test-harness, or hand off. It is not a novel bet; it answers the fleet-monitor plan’s own founder question [E12] in the direction the evidence points, without touching the underlying SQLite/Postgres data model a future board would need anyway. The honest costs — concurrent-writer contention on SQLite hook ingest and a small new Rust surface in an agent-unfavorable language [E6, E7] — are both real but tightly bounded by scope.

  • Footprint below the research’s own already-cut floor. [E5]’s cut plan still assumes a new board service and ingest daemon get built; Candidate D never builds either, so there’s no fresh runtime baseline to pay for — only a near-zero-delta TUI pane [E4] and zero-idle-cost cron scripts, landing at or under [E5]’s ~550-700MB floor with strictly fewer components [E1, E4, E5].
  • Subtraction, not addition. Every rival adds at least one new always-on service; D adds zero — the hook path writes directly to SQLite from a short-lived CLI invocation, pollers/digest are host cron, and the only stateful long-running processes left are Postgres and Grafana, both already required regardless [E5, E11, E12].
  • Hours-to-days to ship. Four small pieces — a TUI pane (read-only SQLite query + render function), a hook script (one INSERT with busy_timeout), cron scripts, and Grafana panel JSON — none require new CI/CD plumbing, secrets, or a deploy target; they ride on infrastructure already running [E4, E6].
  • Completes a pivot the research already flagged, forecloses nothing. Founder Q1 [E12] explicitly asked whether the honest interface is a TUI pane and called it “the cheapest possible pivot”; D answers it using evidence the plan didn’t have when it reinstated Loki, since [E5] shows the same content-free-event problem is already solved by SQLite. If Robert later wants the ambient board, the same SQLite/Postgres schema serves it — D defers UI, not data model [E5, E12].
  • SQLite for operational state is the constitution’s own exception, not a violation. Postgres-first governs domain/business state; fleet monitoring has no claim semantics or cross-row transactional invariant, and [E6] shows SQLite WAL comfortably absorbs the write volume in question — two backends matched correctly to two consistency requirements [E2, E6, E11].
  • Every piece is a pure function or diffable config, not a system to mock. The hook insert, the TUI pane’s read-of-rows-to-render function, cron scripts, and Grafana JSON all have obvious, cheap test seams — versus the HTTP routes, data-fetching layer, and integration tests a new board service would require [E4].
  • Two risks named and bounded, not hidden. Concurrent hook writers are many short-lived processes, not [E6]’s single long-lived-writer model, but busy_timeout/WAL retry is the exact mechanism that figure was measured under, and fleet hook-event rates sit orders of magnitude below the 64-concurrent-worker saturation point; the new Rust surface is a single read-only pane reusing existing logic, not a repo-level fix or compile-heavy rewrite [E4, E6, E7].

Strongest single point. D is the only candidate that goes below [E5]’s own already-cut observability floor (~550-700MB) rather than merely matching it — by never building the ingest daemon or board service that floor still assumes, it lands ~500-600MB with strictly fewer moving parts, which is the direct, load-bearing answer to the stated hard constraint (lowest possible always-on memory/CPU on a host where hundreds of agents already claim tens of GB, [E1]).

Prosecution

Verdict. Candidate D’s minimum-footprint claim is real but small (roughly a 50-100MB marginal delta over the obs stack [E5] already prices in, per [E6]’s RSS floors) and it is bought with structural risk concentrated at the fleet’s peak-load moment. The zero-daemon SQLite hook-ingest design cites [E6]’s throughput number for a single-writer-process model while implementing a many-concurrent-writer-process model, coupling ingest contention directly to synchronous agent-hook latency — the exact constraint leg the mandate calls hard — right as concurrency scales toward “hundreds” of agents [E1]. Cron-based pollers substitute a known daemon cost for an unmeasured CPU-churn cost with no overlap guard [E4]. The “Grafana-only” web surface both overclaims its cited precedent and quietly drops write-back/triage action to a terminal-only surface, while reversing a standing ADR [E12] on the strength of an anticipated-not-resolved question.

  • Zero-daemon SQLite ingest inverts the concurrency model the cited evidence actually validates. [E6]’s throughput claim is explicitly qualified “hook ingest is one writer process”; D’s design forks N independent OS processes concurrently across however many agents are mid-tool-call at once — cross-process contention (lock acquisition, busy_timeout backoff, fresh connection setup, fork/exec cost) is a materially different and more expensive regime than the in-process-thread case [E6] validates [E1, E6].
  • Hook-path contention becomes agent tool-call latency. Claude Code hooks execute synchronously in the tool-invocation path; a per-event write blocking on lock contention delays every agent’s tool call, threatening the “lowest possible… latency” leg of the hard constraint precisely at “hundreds of concurrent agents” scale — and the daemon D rejects to save RSS is also the component that would have decoupled hook latency from write latency via buffering [E1, E6].
  • Cron pollers swap a bounded cost for an unbounded one. fleetops’ logic has no published cost curve at scale; moving it to cron forces a choice between tight intervals (CPU churn competing with the fleet, no stated overlap guard) or loose intervals (stale attention-queue) — a known daemon RSS line item traded for unmeasured, potentially unbounded CPU churn [E1, E4].
  • Its own cited precedent licenses a shell it declines to build. [E8]’s actual documented pattern is “thin nav shell + links + Grafana LINKED, not embedded,” costed as near-free (11-17KB, zero build step); D’s marginal saving is really “avoiding a near-free nav shell,” not “avoiding a heavy web app” (already ruled out regardless of winner), while losing whatever cross-product landing surface that shell would provide [E8].
  • No write-back path. Grafana is a dashboard tool, not a workflow/actuation surface; if the attention-queue’s value is triage, D leaves the only actuation surface as the TUI reachable solely via live SSH/tmux — “web overview” quietly narrows to “web view-only,” an unnamed functional regression [E12].
  • Reverses a standing ADR on an anticipated question, not a resolved one. [E12] shows ADR-2 already chose Web board, and the founder’s Q1 “anticipated” this pivot — an anticipated question is not a resolved answer, and nothing shows ADR-2’s original reasoning (non-terminal operator access, on-call visibility off the WSL2 box) was mistaken [E12].
  • Community SQLite Grafana plugin adds unpriced ops/trust burden. Grafana has no first-party SQLite datasource; the community plugin option typically requires enabling unsigned-plugin loading, a supply-chain and documentation-coverage cost absent from D’s “hours-days” estimate (flagged as inference, not in [E1]-[E12]).
  • Headline footprint number is mostly [E5]’s cut plan restated. D’s “~500-600MB, zero new services” is [E5]’s baseline minus roughly one avoided board process and one avoided ingest daemon — a 50-100MB marginal delta oversold as “minimum footprint,” disproportionate to the structural risks named above [E5, E6].

Strongest single point. The ingest design is the load-bearing flaw, and it fails worst exactly when the system is needed most. D removes the always-on hook-ingest daemon and replaces it with a per-event CLI/helper invocation — turning ingest into N independent OS processes contending for one SQLite file, precisely as agent count scales into the hundreds [E1]. The SQLite throughput evidence cited to justify this ([E6]: 8.4k writes/s, degrades past ~100 concurrent writer threads) explicitly assumes a single writer PROCESS with in-process threads, a model D’s own architecture does not implement. Because Claude Code hooks execute synchronously in the tool-call path, lock contention or busy_timeout backoff on that shared file is imposed directly on agent tool-call latency — the one leg of the stated hard constraint this design is positioned to violate. Worst case: a fleet burst toward hundreds of agents causes write retries to stack, and either agent tool calls stall system-wide as hooks block on contended writes, or an under-robust helper silently drops events under load, corrupting the attention-queue exactly during the high-agent-count, high-failure-probability conditions FleetOps exists to monitor — the tool goes blind precisely when something is most likely to need catching, with no buffering layer anywhere in the ingest path to absorb the burst.

Cross-examination

Advocate rebuts prosecution. Prosecution’s process-vs-thread distinction is real but not dispositive: SQLite’s WAL locking serializes at the file-lock level regardless of whether the contending writer lives in-process or freshly forked, and WAL’s canonical use case is exactly “several separate OS processes touching one file” — the busy_timeout/retry mechanism [E6] measured is the general-purpose one, not one specific to in-process threading. What genuinely doesn’t transfer is fork/exec + fresh-connection overhead per event and burstiness — real gaps, not fabricated — but hook events are gated by tool-call boundaries, not token streams, so realistic concurrent-write pressure at “hundreds of agents” is plausibly orders of magnitude below [E6]’s ~100-concurrent-writer degradation threshold. The actual failure mode prosecution names — a hook write blocking the tool call indefinitely — is a spec gap in D-as-sketched, not a structural property of “no daemon”: a short write timeout with fail-open-drop-and-count bounds worst-case agent-facing latency to that timeout, exactly as a fire-and-forget daemon write would itself need to do to avoid the identical problem. Both open unknowns — real hook-fire concurrency at fleet scale, and whether a bounded-timeout helper stays inside SQLite’s safe operating range — are answerable with a few hours of load-testing against a temp DB before shipping, cheap precisely because D’s ingest surface is a single INSERT, not a service requiring integration-test infrastructure.

Prosecution rebuts advocacy. The floor-comparison is real but small and mis-scoped: 500-600MB vs [E5]’s already-cut 550-700MB is a marginal delta of roughly one avoided process plus one avoided lightweight daemon — order 50-100MB, not a categorical win, and trivial against the ~15-30GB+ the fleet itself commits at “hundreds of agents” [E1]. More importantly the constraint is “memory/CPU/latency” jointly, not memory alone, and advocate’s footprint number is not independent of the latency/correctness risk the ingest critique names: [E5]’s baseline was priced for a design that still has a daemon absorbing burst write load without blocking the caller; D’s smaller number is smaller specifically because it removes that decoupling component. The savings and the risk load onto the same variable — agent count — and both peak together: the moment “hundreds of concurrent agents” makes memory tightest is exactly the moment per-process SQLite writers contend hardest and hook-path latency is most exposed. Advocate’s framing treats the 50-100MB as a clean, one-dimensional win; it is more accurately a small, narrowly-scoped memory saving purchased by concentrating risk on the latency leg of that same constraint, at the load level where the tradeoff matters most.

Residual open questions.

  • No published throughput/latency data exists for SQLite writes under many-concurrent-OS-process contention at hook-fire rates (vs. [E6]’s single-process-many-threads model) — the exact regime this whole exchange turns on, and [E9] confirms nobody has published footprint data for hundreds of concurrent agents on one host at all.
  • Real hook-fire frequency/burst shape across hundreds of concurrent agents (sparse per-tool-call vs. correlated bursts) is not in the evidence digest — both “far below saturation” and “contention stacks at scale” are extrapolations without this number.
  • Claude Code’s hook execution semantics on a slow/hung hook process (hard timeout? retry? does the tool call block, error, or silently proceed?) are undocumented, and load-bearing for both the “bounded worst case via timeout” rebuttal and the “unbounded latency coupling” attack.
  • Cron-poller CPU cost curve and overlap/skip-if-running guard behavior at hundreds-of-agent scale is unmeasured — [E4] gives LOC counts only, no runtime cost.
  • Whether FleetOps’ “web requirement” needs write-back/triage actuation or tolerates view-only Grafana is not settled by the digest — [E12] names the attention-queue’s existence but not its required interaction model.
  • Resolution status of founder Q1 (posed-and-left-open vs. implicitly answered) is ambiguous from [E12] alone — both “D completes an anticipated pivot” and “D reverses a standing ADR on an unresolved question” readings are equally consistent with the evidence.
  • Maturity/trust posture of the community Grafana SQLite datasource plugin (unsigned-plugin risk, agent-legibility cost) is flagged by prosecution as inference only, outside the digest, real as a concern but unpriced.

What the court settled vs. left open

Settled.

  • The maintainability evidence establishes TS-over-Rust, not TS-over-Go. [E7]’s 21-28%-vs-~70% real-issue-resolution gap is a Rust-specific number with no TS or Go data point at that depth; Candidate A’s cross-exam concedes its strongest agentic argument only rules out Rust, and Go — FleetOps’s actual reusable non-Rust asset via ghmonitor — posts the strongest raw success-rate numbers in the packet [E7].
  • Candidate D’s daemon-less ingest inverts the single-writer-process model its own throughput evidence assumes, and couples ingest latency to synchronous hook execution. [E6]’s 8.4k-writes/s comfort figure is qualified on one writer process; D forks N concurrent OS processes instead, and because Claude Code hooks run synchronously in the tool-call path, any lock contention or busy_timeout backoff lands on agent-facing latency — the one leg of the hard constraint (“memory/CPU/latency”) this design is positioned to violate, with no daemon left to buffer the burst.
  • Candidate B’s in-process reuse claim depends on an unverified lib-crate/async-safety premise. [E4] documents that the fleetops TUI’s session-discovery logic exists and ships, not that it’s a public, Send+Sync-callable library safe to drive from tokio tasks under a live SSE reactor — the “reuse collapses code-reduction and footprint-reduction into one argument” synergy only holds after an un-costed extract-to-lib-and-audit step the candidate’s framing treats as free.
  • Candidate C’s SQLite cliff attack is answered by the fan-out/fan-in single-writer-goroutine pattern. Prosecution’s “N poller goroutines contending on one DB handle” assumes an architecture Candidate C never specified; routing all writes through one dedicated writer goroutine fed by a channel is the idiomatic Go answer to this exact shape, preserves [E6]’s single-writer comfort case regardless of poller count, and costs zero new dependencies — though the separate, conceded CGO/mattn thread-pinning risk is real and swapped out for free via modernc.org/sqlite.

Left open.

  • Encore.ts’s real idle RSS at hundreds-of-agent scale is unpublished [E10] — every candidate’s total budget rests on an unmeasured two-thirds of its own baseline.
  • The real hook-event burst rate under “hundreds of concurrent agents” is unmeasured — both SQLite-is-fine and SQLite-risks-head-of-line-blocking arguments (Candidates A and D alike) are extrapolations from unrelated benchmarks, not this workload.
  • Go’s repo-level real-issue-resolution rate has no data point in [E7] — Candidate C’s “best agentic fit among low-footprint languages” claim, and Candidate A’s cross-exam rebuttal leaning on Go, both assert rather than evidence this.
  • The modernc.org/sqlite (pure Go) vs. mattn/CGO choice for Candidate C is unresolved on performance grounds — the fix that neutralizes the CGO thread-pinning risk hasn’t been benchmarked for this workload.
  • The fleetops crate’s lib-crate/async-I/O status for Candidate B is undocumented — whether in-process reuse is mechanically available today, or requires the unscoped audit prosecution surfaces, is the single fact that would most directly resolve B’s strongest-point-vs-strongest-rebuttal standoff.