Skip to content
GRPNR.

Steelman court

Advocate and Prosecutor ran as 8 independent Sonnet agents (disjoint prompts, shared evidence pack [E1]-[E10] from 01-deep-dive.md). Uncited arguments marked RHETORIC by the agents themselves. Cross-examination + verdict inputs added by Fable (auditor).

Option A — Full Factory

Advocate (strongest honest case)

  1. Option A is the only construction that fully honors the collision constraint: it puts zero Robert-fleet PRs into Tomas’s review queue, which is the single scarcest resource in this whole system.
    • Evidence: [E8] Tomas is decision-bound (“více agentů mi nepomůže”), his human hours ARE the rulebook, and the measured cost of sharing a repo with more agents is brutal — AI PRs wait 4.6x longer and land at 32.7% acceptance vs 84.4% for humans. A standalone factory plane doesn’t need CODEOWNERS partitioning, claim-queues, or worktree caps to protect Tomas’s bandwidth — there is no shared bandwidth to protect. Every other construction (shared repo, shared services) has to manage that contention; Option A structurally avoids it.
  2. Option A isn’t a schism from Zaruba’s architecture — it’s his own two-plane doctrine applied one level up, so it scores well on DDD boundary fit rather than fighting it.
    • Evidence: [E2] Zaruba already built core+internal as two planes where the internal plane writes to core ONLY via proposal endpoints, on the explicit thesis that “hundreds of agents need structural, not procedural, boundaries.” A Robert-owned factory plane that talks to core via APIs/clients only is the identical pattern at the next boundary out — factory-plane -> core-plane, structural not procedural. Judges scoring DDD fit should read this as consistency with the system of record’s own stated taste, not a deviation from it.
  3. Several factory apps require stack and doctrine choices Zaruba’s greenfield has already rejected outright; owning a separate stack avoids relitigating settled decisions inside his repo.
    • Evidence: [E4] Greenfield is Claude-only tooling with no LiteLLM gateway anywhere, MBUS was actively DROPPED (“replaced by direct Pub/Sub and the Adyen webhook”), and there is no codemod/ast-grep/GritQL and no knowledge graph anywhere in the doctrine. Yet Robert’s mandate includes a rewrite engine (GritQL/ast-grep), a knowledge-graph MCP, and an MBUS bridge/adapter — exactly the things Zaruba’s repo has no appetite for. Building these as Robert-owned services integrating only via API means Robert never has to win an argument inside Zaruba’s repo about tools Zaruba has already said no to.
  4. Several overlapping services already exist in Zaruba’s repo, deliberately scoped down; building inside would mean either colliding on ownership/naming or reopening someone else’s already-shipped scoping decisions. Building alongside, consumed via API, avoids both.
    • Evidence: [E3] tasks (generic human-task infra, no agent-scale dedup/batch/rate-limit), workflow-management (full Temporal platform), service-management (catalog only — health/cost/incidents deliberately dropped, “re-add later, never inline”), mcp (OAuth+registry skeleton, zero code-graph tools) and docs already exist. Robert’s fleet-monitor, question-triage, and knowledge-graph MCP are exactly the “re-add later” and “zero code-graph tools” gaps — but they’re gaps in Tomas’s already-shipped, deliberately-scoped services. Extending those in place means modifying code Tomas scoped on purpose; standing up Robert’s own and consuming Tomas’s via client avoids the ambiguity of whose service a merged ‘mcp’ or ‘tasks’ actually is.
  5. A separate repo/dir makes a failed or superseded factory app cheap to delete, which matters because this exact failure mode — half-finished migration tooling rotting in a live repo — is already observed in the legacy estate.
    • Evidence: [E6] The 26-repo sample turned up TWO half-finished strangler migrations still rotting in the code (VIS3 still calling legacy VIS; identity-service abandoned since 2022), plus ~12% delete candidates even in a curated sample. Factory apps are inherently higher-variance bets than the Orders flagship (rewrite engine, knowledge graph, and fleet monitor are all explicitly unproven — see [E7]). Housing them outside the system of record means an app that doesn’t pan out gets deleted, not left as a second zombie strangler pattern inside Zaruba’s core repo for the next audit to trip over.
  6. The factory apps Robert needs to operate his fleet responsibly right now cannot wait on the core migration’s provisioning cadence, which is currently at zero.
    • Evidence: [E5] monorepo-infra is 0% provisioned (GCP billing gate, human-only), Temporal+Grafana Helm scripts are ready-not-applied, Grafana has zero dashboards and zero alerting, and Temporal is scoped to a single Encore app connection. A verification harness and fleet monitor are exactly what keeps a multi-agent fleet honest ([E9]: tangling base rate 53.9%, Bun migration’s 19 escaped regressions) — Robert can’t defer that need to whenever the core plane’s GCP billing gate clears. Owning the stack means Robert can stand up Postgres+Grafana today, per his own constitution ([E10]: Postgres-first, boring tech), independent of core’s provisioning timeline.
  7. The factory-app problem space (fleet monitoring at 50-100 sessions, question-triage dedup) is genuinely unsolved in public literature and needs fast, cheap iteration — not the kill-gate/business-panel process built for a customer-facing money-chain migration.
    • Evidence: [E7] Verified twice: nothing off-the-shelf covers 50-100 concurrent sessions with task-level metrics; dedup/rate-limit/stakeholder-overload for question-triage is “genuinely unsolved in public literature” — the plan is adopt-and-adapt (fork ColeMurray/claude-code-otel + thin custom layer). [E1] The core migration’s discipline — Given/When/Then specs, dual-run to 99.999% parity, M4/M8/M12 kill gates, business-panel sign-off — is calibrated to Orders’ money chain. Exploratory internal tooling shouldn’t inherit that gate cadence; a separate plane lets Robert prototype, throw away, and re-try at his own tempo. Strongest point: Option A is the only construction where the collision constraint [E8] is solved structurally rather than procedurally: with a separate repo/plane there is no shared review queue for Tomas’s scarce, non-scalable hours to bottleneck on, and the architecture that achieves this isn’t a departure from Zaruba’s taste but a literal application of his own core/internal two-plane doctrine [E2] one level further out — factory-plane to core-plane, via proposal-style API calls only, structural boundaries for a fleet of agents rather than procedural ones. Concessions: Honest weak spots: (1) Two of the nine apps cut against “own stack” cleanly — the migration ledger/orchestrator overlaps hard with Zaruba’s already-built, full-featured workflow-management Temporal platform [E3b], and the MBUS bridge/adapter integrates with something Zaruba’s own doctrine actively killed [E4]. For those two specifically, standalone construction risks either reinventing orchestration Zaruba already has or building a bridge to a pattern he’s declared dead — the strongest counter is “consume workflow-management via its API instead of building a parallel orchestrator,” which is still compatible with Option A’s “integrate via APIs only” framing, but it’s a real tension, not a clean win. (2) Standalone-by-default has a duplication cost: Robert re-derives scaffolding (task queues, admin UI patterns, auth) that already exists in tasks/mcp/docs rather than extending it, and the two islands need real API contracts to stay integrated rather than drift into shadow systems — that glue work is not free and is easy to under-budget. (3) “Zero collision” is slightly overstated: Option A still needs at least one negotiated seam (the client/API contracts into core), so some Tomas attention is unavoidable — just far less than a shared repo would demand.

Prosecutor (strongest honest attack)

  1. This is a rebuild of infrastructure that already exists and works. Apps 2 (question-triage), 3 (fleet monitor’s admin surface), 5 (MCP), and the orchestrator/ledger concept in app 1 all substantially overlap Zaruba’s already-BUILT tasks service (TaskType.INFORMATION_REQUEST/APPROVAL/SIGNATURE, assignee queues, TaskWorkflowStamp, human-answers-via-tokenized-link-then-Temporal-signal), workflow-management (full Temporal platform: definitions/executions/logs/schedules CRUD, worker pool, admin UI), service-management (catalog), and mcp service (OAuth+tool-registry skeleton). Building 4 of the 9 apps from scratch in a parallel plane when the core primitives are done, reviewed, and running is not greenfield work, it’s duplicate work that now needs its own maintenance forever.
    • Evidence: [E3]
  2. App 9 (MBUS bridge/adapter) builds infrastructure for a pattern Zaruba’s team has already killed on purpose. orders_mbus_client was explicitly DROPPED and replaced with direct Pub/Sub plus the Adyen webhook. Robert building an MBUS bridge as factory-plane infra isn’t neutral tooling, it’s re-introducing the exact coupling mechanism the greenfield owner spent engineering effort to remove, on the money-chain flagship no less. This is the single fastest way to read as working against the doctrine rather than alongside it.
    • Evidence: [E4], [E1]
  3. A separate Temporal orchestrator/ledger (app 1) plus a factory-owned migration ledger creates a second system of record and a second structural-boundary regime in a codebase whose entire stated ethos is ‘hundreds of agents need structural, not procedural, boundaries,’ and whose collision protocol (CODEOWNERS partition, claim-before-work queue, OWNERSHIP.md, MADR ADRs with DRI) presumes ONE system of record: monorepo-development. Two orchestrators, two manifests, two sources of truth for ‘what state is the migration in’ is exactly the procedural-boundary failure mode the two-plane architecture was built to prevent, now cubed to a third plane.
    • Evidence: [E2], [E8]
  4. Apps 5, 6, 7 (knowledge-graph MCP, GritQL/ast-grep rewrite engine, backend service scaffolder) are codemod/strangler tooling built for a migration doctrine that explicitly does not strangle. E1’s doctrine is rebuild-from-audit: legacy code is ‘evidence, NEVER ported,’ verified by production telemetry and dual-run parity, then switched off wholesale. A rewrite engine and codebase knowledge-graph are the toolkit for surgical in-place transformation of legacy source, solving a problem (safely editing 1M LOC of Ruby/Java in place) that the chosen migration strategy deliberately sidesteps. That’s capability built for the wrong migration shape, and E6 shows what happens when a strangler approach is half-committed to: VIS3 still calling legacy VIS, identity-service abandoned in 2022, two rotting half-migrations already in the corpus. Building strangler tooling risks handing the fleet a third one.
    • Evidence: [E1], [E4], [E6]
  5. Ops burden doubles in an environment that cannot handle the load it already has. monorepo-infra is 0% provisioned (GCP billing gate), Grafana has zero dashboards and zero alerting, and Temporal is scoped to a single Encore app connection. Option A adds a second Temporal deployment (app 1) plus a from-scratch OTel-to-Prometheus-to-Grafana fleet-monitor pipeline (app 3) that E7 itself concedes has no off-the-shelf answer at this scale. Robert now owns two unproven observability stacks and two Temporal clusters, on infra that hasn’t cleared its billing gate for the first one.
    • Evidence: [E5], [E7]
  6. Question-triage and dedup/rate-limiting for hundreds of agents is an explicitly unsolved research problem, not a shippable app. E7 states plainly that dedup, rate-limiting, and stakeholder-overload for agent-generated questions are ‘genuinely unsolved in public literature,’ with langchain agent-inbox as the only live reference point. Treating this as app #2 of 9 on a fixed roadmap means committing scope and a delivery expectation to a problem nobody has solved publicly, and E9 confirms the entire industry’s largest concurrent-agent validation is 64 agents (Bun migration), with zero published validation anywhere near the ‘hundreds of agents’ scale E2’s own architecture is designed for. The factory is sized for a scale claim nothing in the evidence pack validates.
    • Evidence: [E7], [E9], [E2]
  7. The factory adds supply exactly where the evidence says the system is already bottlenecked. E8 states the scaling constraint is human review capacity: AI PRs wait 4.6x longer and land at 32.7% acceptance vs 84.4% for human PRs. Nine new standalone services, each needing its own review, ADRs, and DRI sign-off, pours more reviewable surface into the one resource E8 identifies as already saturated, with no corresponding plan in Option A to expand or protect review throughput. Building more agent output when the constraint is human eyeballs on that output is optimizing the wrong stage of the pipeline.
    • Evidence: [E8]
  8. The collaboration model itself is adversarial to the partner’s stated posture. Tomas is decision-bound (‘vice agentu mi nepomuze’) and wary of collision; Robert committed specifically to execution tooling plus fleet monitor, not a parallel nine-app platform. Standing up a Robert-owned factory plane that reimplements ledger/orchestration/task-routing/knowledge-graph primitives Tomas already built, integrating only via API, reads to the greenfield owner as ‘built a shadow platform instead of the two things I asked for’, a trust cost no evidence entry quantifies but every entry about Tomas’s posture (E1, E2, E8) predicts.
    • Evidence: [E8], [E2], [E1] Strongest point: The overlap argument (apps 2/3/5 duplicating tasks/workflow-management/service-management/mcp, [E3]) combined with the MBUS bridge directly contradicting an explicit architectural rejection ([E4]) together show Option A isn’t just redundant, it actively rebuilds and in one case reverses decisions the greenfield owner already made, which is the fastest route to a collision Tomas has said he doesn’t want. Concessions: The proposal is honest about integrating via APIs/clients only rather than forking Zaruba’s repos, which is the correct instinct given the collision-avoidance doctrine in E8, it just doesn’t go far enough, since duplicating the capability causes the same two-systems-of-record problem as duplicating the code. The fleet-monitor and codebase-knowledge-graph pieces (apps 3, 5) also address real, evidenced gaps E3/E4 confirm are missing (no code-graph tools, orphaned health dashboard calling dead endpoints), the critique is about doing all nine as a parallel plane at once, not that zero of the nine have merit standalone. And E10’s ‘evolution path named’ constitution is at least nominally satisfiable by API-only integration, which is more disciplined than a full fork would have been.

Cross-examination

  • Best advocate point (structural collision avoidance; two-plane doctrine applied one level out) → rebuttal: the collision gain is real but purchasable at a fraction of the cost — a CODEOWNERS-partitioned lane inside the internal plane (Option C) yields the same structural isolation without duplicating tasks/workflow-management [E3]. And no plane placement rescues apps whose demand died with the doctrine (rewrite engine, MBUS bridge, full KG) [E1][E4] — the plane argument defends the shape, not the contents.
  • Best prosecutor point (rebuilds existing infra; MBUS bridge reverses an explicit rejection — fastest route to collision) → rebuttal: overreaches only in breadth: fleet monitor, harness, and triage-dedup are genuine, evidenced gaps ([E3] “re-add later”, [E7] unsolved). The attack demolishes the 9-app standalone shape, not every app in it. Verdict input: A’s plane concept survives as the fallback posture (A-lite: own repo consuming APIs) if assumption A1 fails.

Option B — Zaruba-Native Extension

Advocate (strongest honest case)

  1. The collision constraint is the deciding factor, and it’s existential, not just a nice-to-have. Tomas is decision-bound — his human hours ARE the rulebook — and review capacity is already the scaling bottleneck (AI PRs wait 4.6x longer, 32.7% acceptance vs 84.4% human). A standalone triage/ledger/monitor app is a new system that eventually needs Tomas’s architectural sign-off; a TaskType, a row, a dashboard panel does not. The two-plane architecture was built precisely so hundreds of agents could write safely WITHOUT per-agent structural review, via proposal endpoints into core. Option B is the only option that spends zero extra review-cycles on ‘is this a legitimate new system’ — it only ever asks ‘is this row/screen correct,’ which is the question Tomas’s conventions already answer.
    • Evidence: [E8], [E2]
  2. Triage, ledger substrate, docs search, and an OAuth/tool-registry are not gaps to fill — they are live systems Robert would otherwise duplicate. Building standalone apps for functionality that already runs is the exact complexity Robert’s own constitution disclaims (‘simplicity wins, boring tech’). Extending the tasks service’s TaskType enum and workflow-management’s executions/logs is strictly less code than reimplementing human-in-the-loop task routing and a Temporal-equivalent platform from zero.
    • Evidence: E3, [E10]
  3. monorepo-infra is 0% provisioned and gated on human-only GCP billing approval. A standalone app has nowhere to deploy that a Zaruba-native extension doesn’t already have — tasks, workflow-management, docs, and mcp services are running today. Choosing Option B means Robert’s triage/ledger work ships now, on infra already cleared, instead of queuing behind the same billing gate a new app would also have to wait on.
    • Evidence: [E5]
  4. DDD boundary fit favors extension: new TaskTypes and ledger views slot into bounded contexts Tomas is already defining and evolving (tasks service, workflow-management), so Robert’s fleet output stays inside one coherent domain model. A standalone app forces Robert to invent his own bounded contexts that must later be reconciled with the core/internal-plane split — the very failure mode the two-plane doctrine (‘hundreds of agents need structural, not procedural, boundaries’) was designed to prevent, now self-inflicted by Robert instead.
    • Evidence: [E2], E3
  5. Risk and reversibility are asymmetric in Option B’s favor. A migration, an enum value, a dashboard JSON, or a coverage-status.md row can be reverted in one commit with a blast radius of one row or screen. The legacy estate already shows what happens when a parallel system is started and loses momentum — two half-finished strangler migrations (VIS3, identity-service) rotting mid-flight. Because Option B never stands up a separate system, it structurally cannot produce a third rotting strangler; there is nothing standalone to abandon.
    • Evidence: [E6]
  6. Delivery speed: Robert inherits working TDD/Given-When-Then discipline, the dual-run/reconciliation-oracle parity method, .claude/skills institutional memory, and CODEOWNERS/worktree collision conventions on day one. Building a standalone app means bootstrapping an equivalent SDLC first — CI, auth, an environment.md-equivalent, ADR practice — before writing the first line of triage logic. Extension skips the entire bootstrap phase.
    • Evidence: [E1], [E2], [E8]
  7. Cost is close to zero marginal spend: OAuth+tool-registry, full-text docs search with a freshness gate, and a Temporal worker pool are already paid for and running. Robert’s incremental cost is schema rows and UI screens, not a second auth system, a second search index, or a second workflow engine.
    • Evidence: E3
  8. Conceded and reframed: agent-scale dedup/batch/rate-limiting for triage genuinely doesn’t exist in the tasks service, and it doesn’t exist anywhere in public literature either — the langchain agent-inbox gap is unsolved industry-wide. Forking a standalone inbox wouldn’t buy Robert a solved problem, only a second unsolved one to maintain. Better to extend the one TaskType/queue that’s already load-bearing. Likewise Grafana has zero dashboards today and is infra-gated — but the OTel-fork-plus-thin-layer plan is exactly what Option B already prescribes (‘Grafana dashboards only once infra provisioned’), so the option isn’t behind the recommended architecture, it’s just sequenced behind Tomas’s infra timeline rather than duplicated on a separate stack.
    • Evidence: [E3a], [E7], [E5] Strongest point: The collision constraint decides this: Tomas’s review bandwidth is fixed and already the bottleneck (4.6x wait, 32.7% acceptance for AI PRs). The two-plane architecture exists specifically so hundreds of agents can write safely without per-agent structural review via proposal endpoints. Option B is the only path where Robert’s fleet output never has to clear a new-system bar with Tomas — it only ever asks whether a row or screen is correct, a question already answered by conventions Tomas maintains. Every other judge criterion (speed, cost, reversibility, DDD fit) follows from this same fact: riding an already-approved substrate instead of building a parallel one. Concessions: Real gaps exist and Option B doesn’t paper over them: the tasks service has no agent-scale dedup/batch/rate-limiting (a genuine unsolved problem industry-wide, not just here); Grafana has zero dashboards/alerting today and is infra-gated behind human-only GCP billing approval, so Robert’s observability need during the exact startup-mode crunch (through ~2027-01) is hostage to a timeline he doesn’t control; KG/rewrite/scaffolder/MBUS are dropped entirely, leaving the 34-agent legacy-characterization effort (EOL runtimes, MBUS load-bearing in half the sampled components) without dedicated tooling, only docs and skills; and the harness pattern is explicitly ‘largely Tomas’s own build,’ meaning Robert’s autonomy there is thin at best. Option B trades some near-term capability and independence for structural safety and speed — an honest trade, not a free one.

Prosecutor (strongest honest attack)

  1. The harness’s proposed foundation — extending the reconciliation-oracle pattern — has no slot for the single most important finding of the legacy analysis. Zaruba’s oracle was built for Orders money-chain parity (order aggregate/billing-event ledger/Adyen adapter) and MBUS was actively DROPPED from that design (‘orders_mbus_client DROPPED, replaced by direct Pub/Sub’). Yet legacy characterization found MBUS load-bearing in 16 of 33 sampled components. An extension of a pattern built to not-need MBUS has no natural place to characterize a dependency that’s architecturally central to the estate it’s supposed to triage — the instrument was purpose-built to look away from what Robert’s fleet most needs to see.
    • Evidence: [E1] + [E4] + [E6]
  2. The tasks service Robert would extend for triage explicitly lacks ‘agent-scale dedup/batch/rate-limit’ — and Tomas’s own stated position is ‘více agentů mi nepomůže’ (more agents won’t help me), because his human hours ARE the rulebook. Grafting a 50-100-session fleet’s question-triage onto infrastructure whose owner is decision-bound and whose generic human-task plumbing was never built for agent volume isn’t a scaling risk — it’s a stated, acknowledged mismatch between the tool’s design center and the load Option B would put on it.
    • Evidence: [E3a] + [E8]
  3. The monitor leg is contingent on infra that is 0% provisioned and gated behind a human-only GCP billing step nobody in the evidence pack is shown actively pushing, and Grafana today has zero dashboards and zero alerting. ‘Once infra provisioned’ is doing enormous unacknowledged load — it makes Robert’s fleet observability hostage to a dependency outside both his and Tomas’s committed near-term work (Orders flagship, kill gates), which is exactly the kind of deadlock that leaves 50+ agents running with no operator inbox for weeks.
    • Evidence: [E5]
  4. Dropping KG entirely severs the very tool class that produced the hub/dependency evidence Option B is being judged against. The hub map (orders 9 in-edges, voucher-inventory 8, deal-catalog-jtier 7) and the MBUS load-bearing finding required cross-repo structural analysis across 26 repos/11GB — Zaruba’s mcp service offers docs search only, zero code-graph tools, and greenfield doctrine treats legacy purely as characterization input, not an artifact to be graphed for reuse. An option that defers KG to ‘his skills and docs’ is deferring to a system with no equivalent capability, for a legacy estate that specifically needs it.
    • Evidence: [E3d] + [E4] + [E6]
  5. Routing triage/ledger/harness as PRs into monorepo-development inverts the stated bottleneck rather than relieving it: AI-authored PRs already wait 4.6x longer with 32.7% acceptance vs 84.4% for human PRs, and Tomas’s review capacity is the named scaling constraint. Making 100% of Robert’s own execution tooling changes flow through that same solo-authored, 2-day-old, review-bandwidth-constrained repo means Robert’s fleet velocity is now capped by the exact chokepoint the evidence pack identifies as the system’s tightest constraint — for tooling that has nothing to do with Tomas’s core rebuild.
    • Evidence: [E8]
  6. The shape of the two missions doesn’t match: Zaruba’s doctrine is narrow and depth-first — one flagship domain, human-gated business-panel scope, M4/M8/M12 kill gates, dual-run parity to five nines on a single money chain. Robert’s fleet’s job is breadth-first archaeology across ~1.05M LOC, 26 repos, EOL runtimes (Rails 3.2, Ruby 1.9.3, JRuby 1.7) and two already-rotting half-finished stranglers. Bending Orders-cadence screens and Temporal-execution tracking to a 26-repo characterization sweep produces agent-illegible artifacts: dashboards tuned to one flagship’s kill gates don’t tell an operator anything about queue depth or rework rate across 25 other repos.
    • Evidence: [E1] + [E6]
  7. ‘Ledger = rows/views on workflow-management + coverage-status.md conventions’ downgrades tracking to exactly the ad hoc, non-queryable state the fleet-monitor market scan concluded was insufficient — the scan’s own verdict was to build task success rate, rework rate, cost-per-merged-unit, and queue depth as first-class metrics because nothing off-the-shelf (including markdown conventions) covers 50-100 concurrent sessions. A markdown file and Temporal’s execution log were not designed to answer ‘which of my 80 sessions needs input right now,’ which is the exact inbox model the evidence pack says operators need.
    • Evidence: [E7]
  8. Decommission has no home in Zaruba’s doctrine at all — his pattern is rebuild-and-cutover for services being actively replaced under dual-run parity, not orphan cleanup. There is no decommission runbook anywhere in the evidence for legacy systems that are simply dying, not being replaced — yet legacy analysis already found two half-finished strangler migrations rotting mid-flight (VIS3 still calling legacy VIS; identity-service abandoned since 2022) and ~12% delete candidates even in a curated sample. Deferring decommission to ‘his skills and docs’ defers it to a doctrine that has never once modeled a clean kill-without-replacement.
    • Evidence: [E1] + [E6] Strongest point: The reconciliation-oracle/MBUS collision (argument 1) is the fairest and sharpest: it isn’t speculative risk, it’s a documented architectural decision (MBUS dropped) colliding with a documented empirical finding (MBUS load-bearing in half the sampled legacy estate) inside the exact pattern Option B proposes reusing — a proponent has to explain how the harness sees what its own foundation was built to ignore. Concessions: Option B’s proponents have real ground: it reuses infra that is genuinely BUILT and working (tasks service, workflow-management, docs sync), avoids duplicate governance surfaces in a startup-mode, collision-wary partnership, keeps a single system of record per E8’s own collision protocol, and correctly skips MBUS/KG/codemod tooling that greenfield legitimately doesn’t need for its own narrow, money-chain-first mission. The prosecution’s case is not that these are bad decisions for Zaruba’s rebuild — it’s that a doctrine tuned for a narrow, human-gated, depth-first flagship rebuild does not generalize to Robert’s breadth-first, high-agent-count legacy characterization mission, and Option B asserts that generalization without evidence it holds.

Cross-examination

  • Best advocate point (zero new-system review bar; rides approved substrate; near-zero cost) → rebuttal: conflates file-level safety with capability fit. The tasks service lacks agent-scale semantics by design [E3a], Grafana’s timeline is hostage to a human-only billing gate [E5], and Robert’s committed deliverable (fleet monitor) cannot be hostage to a timeline neither lead controls. B also leaves Robert without any owned bounded context, contradicting the DRI split both leads need per research/12.
  • Best prosecutor point (the reconciliation-oracle foundation was purpose-built to look away from MBUS, which is load-bearing in 16/33 legacy components — depth-first doctrine doesn’t generalize to breadth-first archaeology) → rebuttal: the attack is correct about foundation, wrong about consequence: it argues for Robert OWNING the harness as a distinct service that extends beyond the oracle pattern (Option C’s flagship), not against reusing tasks/workflow-management where the fit is genuine. Verdict input: B is the right posture for the two reuse targets (tasks, workflow-management) and wrong as a whole-portfolio strategy.

Option C — Two-Lane Thin Factory

Advocate (strongest honest case)

  1. Option C spends its one big R&D bet exactly where the evidence says the gap actually is — agent-scale question triage (dedup/embedding-cluster/rate-limit/knowledge-write-back) — instead of re-solving problems Zaruba already solved. Everything else in the option is BUILD-ON, ADOPT, SCOPE-DOWN, or DROP. That’s the discipline a thin factory needs: one hard novel component, not six.
    • Evidence: [E7] states plainly that dedup/rate-limit/stakeholder-overload for agent questions is ‘genuinely unsolved in public literature’ and the only live reference (langchain agent-inbox) doesn’t cover it. [E3a] confirms Zaruba’s tasks service gives generic human-task infra (TaskType, assignee queues, Temporal signal-resume) but explicitly ‘NO agent-scale dedup/batch/rate-limit.’ Option C builds only the missing layer on top of that service rather than a parallel task system.
  2. The verification/dual-run harness as flagship isn’t a new invention — it’s Zaruba’s own proven pattern (3-oracle reconciliation, ≥99.999% ledger reconciliation on the Orders flagship) generalized to every migrated domain. That’s the single highest-leverage bet available, because it attacks the risk the industry has actually flagged as unsolved at scale.
    • Evidence: [E1] documents the pattern already working: ‘Dual-run live by week 6… write ramp 1→100% with ledger reconciliation ≥99.999%,’ with a working reconciliation oracle on Orders (order aggregate, billing-event ledger, Adyen adapter). [E9] shows impact-analysis-selected tests are ‘the best-evidenced regression cut (~70%)’ and flags that nothing published validates 1000 concurrent agents while agent tangling runs at a 53.9% base rate — i.e., the regression-safety net is exactly where the portfolio’s real risk concentrates, and it’s the one place Robert proposes to go deep rather than wide.
  3. Building ON the substrate (tasks, workflow-management, the two-plane Encore architecture) rather than beside it directly serves the collision constraint — it means less net-new surface for Tomas to review, and it fits inside boundaries he already owns rather than creating a rival stack that competes for his scarce decision-hours.
    • Evidence: [E8]: Tomas is decision-bound (‘více agentů mi nepomůže’), his human hours ARE the rulebook, and ‘review capacity is the scaling constraint’ — AI PRs already wait 4.6× longer with only 32.7% acceptance vs 84.4% for humans. [E2]’s two-plane doctrine (‘hundreds of agents need structural, not procedural, boundaries’) and CODEOWNERS/OWNERSHIP.md/shared-ADR protocol in [E8] are designed precisely for this: Option C’s ledger and question-triage services live inside that structure as new row-types/services, not as a parallel platform needing its own review lane.
  4. The DROP list (rewrite engine, standalone scaffolder, standalone MBUS bridge) isn’t just YAGNI — it avoids literally rebuilding things Zaruba has either already rejected or that duplicate his doctrine. Doing them anyway would be wasted delivery capacity and would fight the ‘legacy code is evidence, never ported’ rebuild doctrine at its root.
    • Evidence: [E4]: ‘no codemod/ast-grep/GritQL anywhere’ in the greenfield, and MBUS was ‘actively rejected… orders_mbus_client DROPPED, replaced by direct Pub/Sub and the Adyen webhook.’ [E1] states legacy code is ‘evidence, NEVER ported’ — a rewrite/codemod engine implies porting logic, which is the opposite bet from what the whole greenfield is organized around. Keeping MBUS only as a shadow-tap for the harness (not a standalone bridge) matches that: it’s used for comparison evidence, not as a live integration path.
  5. Collapsing the migration ledger, the claim-before-work queue, and the decommission ledger into one Postgres-backed Encore service (as row types, not three systems) is the simplicity-wins, Postgres-first move — one state machine (unit × state × attempts × cost × blocking question) instead of three services that all have to stay consistent with each other.
    • Evidence: [E10] (Robert’s constitution): Postgres-first, simplicity wins, boring tech, evolution path named. [E2]’s internal plane already writes to core only via proposal endpoints, and [E3b] gives durable execution (workflow-management/Temporal) for free — so the ledger service only needs to own state, not orchestration. Fewer services here directly reduces the CODEOWNERS partition surface that [E8] says must stay disciplined.
  6. Scoping the KG down to a legacy-audit evidence extractor (feeding HOT/COLD audits) rather than productizing it matches the audit-first doctrine exactly, and defers a component nobody — not Zaruba, not the market — has validated as needed at platform scale. This is the deliberate, named concession in the option, not an oversight.
    • Evidence: [E4] confirms ‘no knowledge graph’ exists anywhere in the greenfield today. [E1]’s doctrine is ‘AI measures legacy via production telemetry… business panel signs scope’ — an audit tool, not a platform. [E6]’s legacy analysis (26 repos, 11GB, 1.05M active LOC, two rotting half-finished strangler migrations, EOL runtimes) is exactly the kind of one-shot evidence-extraction problem a scoped-down KG solves, without committing to indefinite maintenance of a graph product nobody asked for.
  7. The fleet monitor is the lowest-risk, fastest-delivered piece of the whole option because it’s an adopt-plus-thin-layer on a verdict the market scan already settled, and Robert has already committed to it — this is where ‘delivery speed’ and ‘cost’ are strongest for Option C.
    • Evidence: [E7] (verified twice): ‘nothing off-the-shelf covers 50-100 sessions with task-level metrics’; verdict is to fork an existing OTel pipeline (ColeMurray/claude-code-otel + dashboard 25255) and add a thin layer for task success rate, rework rate, cost-per-merged-unit, queue depth — not a from-scratch build. [E8] notes Robert already committed to this piece, so it carries zero negotiation/collision overhead with Tomas.
  8. Net-new build surface across the whole nine-item portfolio is genuinely small — two true builds (ledger, question-triage) plus one flagship generalization (harness), with the rest adopted, scoped down, or dropped — which fits inside the fleet’s actual delivery capacity and the startup-mode timeline without competing with Tomas for review bandwidth.
    • Evidence: [E8]: ‘Startup-mode process until ~2027-01,’ 4-person Strike Unit cadence per [E1], and review capacity as the named scaling constraint. A portfolio where 6 of 9 line items are non-build (ADOPT/SCOPE-DOWN/DROP/MERGED) leaves far more of that scarce capacity for the two genuinely hard problems (triage, harness) instead of spreading thin across a rewrite engine, scaffolder, and standalone MBUS bridge that [E3]/[E4] show are either already covered or already rejected. Strongest point: Option C is intellectually honest about where the real work is: it builds exactly one genuinely unsolved component (agent-scale question triage), generalizes exactly one already-proven pattern as its flagship (Zaruba’s dual-run/3-oracle reconciliation), and for the remaining seven line items either reuses what’s already built, adopts a settled market verdict, scopes down to match the audit doctrine, or explicitly drops things Zaruba has already rejected or his own skills already cover. That’s what makes it ‘thin’ in substance and not just in name — and it’s exactly the shape that survives the collision constraint in [E8], because the net-new surface Tomas has to review and integrate against is small and additive to structure he already owns. Concessions: Three honest weak points, conceded rather than argued away: (1) The question-triage layer is explicitly the piece [E7] calls unsolved anywhere in public literature — Option C is taking on genuine R&D risk there, not a safe bet, and it could slip. (2) Making the dual-run/parity harness Robert’s flagship concentrates his execution risk on one hard, generalization-heavy component; if it doesn’t generalize cleanly past Orders’ 3-oracle pattern to messier domains (e.g. voucher-inventory, deal-catalog-jtier per [E6]’s hub list), the whole verification story for every other migrated domain stalls with it. (3) Merging decommission-ledger and claim-queue data into the migration ledger as row types is simple now, but if their state machines diverge significantly per-domain later, that single schema could get overloaded — the option bets that won’t happen before revisiting it. None of these are fatal; each is the kind of scoped, named risk the option’s own conservatism (drop-everything-not-load-bearing) is designed to leave room to absorb.

Prosecutor (strongest honest attack)

  1. The verification/dual-run harness is billed as one line item in a ‘thin’ factory but is actually the single largest, least-proven bet in the whole design: it must generalize Zaruba’s 3-oracle reconciliation pattern — proven, if at all, on exactly one domain that isn’t even live yet — to every migrated domain across a 1.05M-LOC legacy estate running EOL Ruby/JRuby, where even characterization work is ‘its own engineering project.’ Calling this ‘thin’ hides that it is the hardest unsolved technical problem Robert is taking on, harder in scope than question-triage.
    • Evidence: [E1] (dual-run only targeted ‘live by week 6’ for the Orders flagship, not yet proven, let alone generalized); [E6] (EOL runtimes Rails 3.2/Ruby 1.9.3-2.6/JRuby 1.7, ‘running legacy for characterization is itself an engineering project’, two half-finished strangler migrations already rotting); [E9] (nothing published validates even 1000 concurrent agents; the best comparable case, Bun migration, proved only 64 concurrent with 19 escaped regressions)
  2. The migration ledger duplicates state with Zaruba’s own workflow-management/Temporal substrate rather than merely using it — creating two overlapping sources of truth (ledger’s unit×state×attempts vs Temporal’s execution state) on exactly the money-chain domain where E1 demands ≥99.999% reconciliation. This is hidden coupling to a roadmap Robert doesn’t control, wearing the label ‘BUILD THIN.’
    • Evidence: E3 workflow-management already owns ‘definitions/executions/logs/schedules CRUD, worker pool, versioning discipline’; option text has the ledger use it ‘for durable execution’ — meaning ledger correctness is contingent on Temporal internals Robert doesn’t own; [E1] reconciliation bar of ≥99.999% is exactly the kind of guarantee a drifted secondary ledger breaks
  3. Question-triage bolts a new TaskType plus dedup/embedding-cluster/rate-limit/knowledge-write-back — the one capability E7 says is ‘genuinely unsolved in public literature’ — directly onto tasks service, a shared core-plane service that writes to core only via human-gated proposal endpoints. Robert is choosing to solve the hardest, least-proven problem in the pack as an extension of infrastructure someone else owns and gates, not as an isolated service he fully controls.
    • Evidence: [E7] (dedup/rate-limit/stakeholder-overload ‘genuinely unsolved in public literature’); [E2] (internal plane ‘writes to core ONLY via proposal endpoints’ — human-gated); E3 tasks service today has ‘NO agent-scale dedup/batch/rate-limit’ — Robert is extending shared semantics, not wrapping a clean boundary
  4. CODEOWNERS/OWNERSHIP.md/ADR-log partitioning solves file-level collision, not the semantic collision this design actually creates — whose parity tests are ground truth, whose TaskType schema is canonical, whose ledger reconciles against whose Temporal executions. E8 already names review capacity, not file conflicts, as the real scaling constraint, and Tomas is explicitly decision-bound (‘more agents won’t help me’). All four surviving builds (ledger, triage, harness, KG-extractor) touch Zaruba-owned substrate, multiplying the one resource E8 says is already the bottleneck instead of shrinking it.
    • Evidence: [E8] (review capacity is the scaling constraint — AI PRs wait 4.6× longer, 32.7% acceptance vs 84.4% human; Tomas: ‘více agentů mi nepomůže’); option’s own architecture — ledger uses workflow-management, triage extends tasks service, harness generalizes the core reconciliation pattern, KG feeds audits the business panel signs off on per [E1]
  5. ‘MBUS bridge dropped, shadow-tap only where harness needs legacy event comparison’ quietly re-imports the exact dependency Zaruba’s team already built and then ripped out — and MBUS is load-bearing in roughly half the legacy estate, on divergent EOL runtimes. ‘Shadow-tap only’ is not incidental scope, it’s a nontrivial integration surface disguised as a footnote on the harness line item.
    • Evidence: [E4] (MBUS actively rejected — ‘orders_mbus_client DROPPED, replaced by direct Pub/Sub and the Adyen webhook’); [E6] (MBUS load-bearing in 16/33 components; EOL runtimes make any legacy interaction its own engineering project)
  6. Scoping the KG down to a ‘legacy-audit evidence extractor’ undersells that reliably extracting facts from this specific legacy estate is close to the hardest problem in the pack, not a deferred nice-to-have — and a shaky extractor feeds directly into the HOT/COLD audits the business panel uses to sign scope, silently propagating extraction error into irreversible scope decisions.
    • Evidence: [E6] (EOL runtimes everywhere, ‘running legacy for characterization is itself an engineering project’; two half-finished strangler migrations rotting — VIS3 still calling legacy VIS, identity-service abandoned 2022; ~12% delete candidates even in a curated sample); [E1] (business panel signs scope from HOT/WARM/COLD/DARK telemetry — garbage-in propagates to garbage-scope)
  7. Both the fleet monitor and the flagship harness are implicitly being sized for ‘hundreds of agents,’ yet the actual ops foundation for that scale doesn’t exist: zero Grafana dashboards/alerting, Temporal scoped to a single Encore app connection, and the whole infra project sitting at 0% provisioned behind a human-only GCP billing gate. Meanwhile no published evidence validates fleets anywhere near that size — the best real case tops out at 64 concurrent agents with 19 escaped regressions.
    • Evidence: [E5] (0% provisioned, GCP billing gate human-only, Grafana zero dashboards/alerting, Temporal scoped to one Encore app connection); [E2] (‘hundreds of agents’ explicitly designed for in 11-environment.md); [E9] (nothing published validates 1000 concurrent; 64 concurrent proven with 19 escaped regressions) Strongest point: The verification/dual-run harness is labeled a modest ‘flagship’ add-on but is actually the largest unproven technical bet in the entire portfolio: generalizing a single-domain, not-yet-live reconciliation pattern across an EOL-riddled 1.05M-LOC legacy estate, under a ≥99.999% money-chain accuracy bar, with zero published precedent at anything like the implied fleet scale — calling that ‘thin’ is the load-bearing mislabel the whole plan depends on. Concessions: The design correctly avoids re-litigating things Zaruba already solved well — dropping the rewrite engine, scaffolder, standalone MBUS bridge, and KG productization is sound triage, not scope creep. CODEOWNERS + OWNERSHIP.md + shared ADR log is a real, evidence-grounded collision mitigation, strictly better than no protocol. Reusing Temporal for durable execution is the architecturally sane default in principle — the objection is to drift risk in practice, not to reuse itself. And someone genuinely has to solve question-triage dedup/rate-limiting since E7 confirms it’s unsolved everywhere; the fair criticism is where it gets built (grafted onto Tomas’s owned service), not that Robert attempts it at all.

Cross-examination

  • Best advocate point (builds exactly one unsolved component, generalizes exactly one proven pattern, drops the rest — thin in substance) → rebuttal (accepted with amendment): the prosecutor’s “thin is a mislabel” charge sticks to the harness. Amendment adopted into the recommendation: the harness is explicitly the flagship R&D bet with staged scope — Orders-domain adapter first, generalization only per-flagship at each gate, shared kernel kept minimal. It is not sold as thin.
  • Best prosecutor point (ledger duplicates Temporal state on a ≥99.999% reconciliation domain; triage grafts an unsolved problem onto a Tomas-gated service) → rebuttal: (1) State duplication is prevented by construction, not discipline: Temporal remains the only source of execution truth; the ledger is a one-way projection (Temporal events → ledger rows) plus business fields Temporal never owns (cost, blocking-question, disposition) — the exact pattern Zaruba himself uses in purchase-history projection [E3]. Business-unit state and execution state are different aggregates. (2) The triage graft is bounded: the dedup/rate-limit/write-back layer lives in Robert’s internal-plane service; Tomas’s tasks service receives ONE negotiated PR (a new TaskType enum value + optional metadata field) — a single bounded ask through the proposal-endpoint pattern his architecture was built for [E2], not a stream of core-plane changes. Verdict input: C wins if and only if assumption A1 (Tomas accepts the partitioned lane) holds; its graceful degradation is A-lite.

Option D — Defer-Most

Advocate (strongest honest case)

  1. The collision constraint itself argues for deferral: Tomas is decision-bound, not throughput-bound, and review capacity — not code volume — is the fleet’s binding constraint. AI PRs already wait 4.6x longer with 32.7% acceptance vs 84.4% for humans. Shipping more factory apps into an unstable, decision-pending environment adds review surface for the exact bottleneck the whole doctrine exists to relieve; Option D is the only option that doesn’t make Tomas’s queue worse while he’s still writing the rules.
    • Evidence: [E8]
  2. Building overlaps directly into occupied territory. Tasks, workflow-management, service-management, mcp, and docs services are already substantially built inside monorepo-development. Any factory app Robert ships for those domains today either duplicates Zaruba’s code or requires renegotiating boundaries later under the CODEOWNERS/claim-before-work collision protocol — work done twice, then reconciled, is slower than work done once after the boundary is named. Deferring is the cheapest way to honor ‘claim before work’ when the claimant hasn’t finished deciding what he’s claiming.
    • Evidence: [E3], [E8]
  3. The fleet monitor is the one factory app whose value is independent of how Tomas’s rulebook resolves. Task success rate, rework rate, cost-per-merged-unit, and queue depth are needed whether M4 proves the dual-run doctrine or kills it, and whether the knowledge-architecture ends up graph-shaped or something else — it observes the fleet, not the domain model. That’s exactly why it’s the one app Option D says ‘build now’ rather than ‘wait’: it’s decision-shape-agnostic infrastructure, not a bet on Tomas’s unresolved questions.
    • Evidence: [E7], [E2]
  4. The doctrine’s own methodology argues for sequencing generalization after validation. M4/M8/M12 are kill gates specifically because Orders-flagship is supposed to prove or disprove the rebuild-from-audit pattern before it generalizes. Building factory tooling for other domains before the first gate resolves inverts the doctrine’s own risk order — it treats an unvalidated pattern as validated infrastructure. Option D is simply applying the doctrine’s own discipline to Robert’s own roadmap.
    • Evidence: [E1]
  5. Doc-11 is pure decision support with zero build risk, and it attacks the actual bottleneck. Since Tomas’s constraint is decisions, not hands, the highest-leverage thing Robert can ship is a rigorous assessment (grounded in the 26-repo/1.05M-LOC legacy analysis already done) that helps Tomas resolve his three open questions faster — rather than a fourth factory app whose shape depends on answers that don’t exist yet.
    • Evidence: [E8], [E6]
  6. Reversibility is asymmetric in Option D’s favor. The rejected/absent categories — LiteLLM gateway, codemod/ast-grep tooling, knowledge graph — cost nothing to defer: not building is maximally reversible, while building something Tomas’s greenfield doctrine later rejects (as it already rejected MBUS and ported-legacy-code) creates sunk cost that itself needs a dual-run-style reconciliation to retire. Waiting preserves every future option; building forecloses some.
    • Evidence: [E4], [E1]
  7. Infra reality removes most of the opportunity cost people imagine Option D has. monorepo-infra is 0% provisioned behind a human-only GCP billing gate, with Grafana holding zero dashboards and Temporal scoped to one app. Any ‘factory app’ Robert ships today either runs against nothing real or against mocks that need redoing once the gate clears — so the wall-clock cost of deferring the non-monitoring apps is mostly illusory; the gate was already going to stall them.
    • Evidence: [E5]
  8. Legacy characterization is itself a multi-week engineering project (EOL runtimes, two rotting half-finished migrations, MBUS load-bearing in 16/33 components), meaning any factory app Robert builds for ‘porting’ or ‘migration assistance’ before Tomas names which domains are stable risks being aimed at a target that moves once real telemetry (HOT/WARM/COLD/DARK) comes in. Option D lets the audit work (already underway per doc-11) inform targeting instead of guessing.
    • Evidence: [E6], [E1] Strongest point: The collision-constraint argument is decisive: E8 establishes that Tomas’s human decision hours, not code throughput, are the system’s binding constraint, and that AI-authored PRs already sit in review 4.6x longer with less than half the acceptance rate of human PRs. Every factory app Robert ships into a still-unstable rulebook adds review load to the exact resource that’s scarce — so ‘ship less until the rules are set’ isn’t caution for its own sake, it’s the only stance that doesn’t actively worsen the fleet’s real bottleneck. Every other argument for Option D is really a corollary of this one: defer because the thing you’d be optimizing (throughput) isn’t the thing that’s actually constrained (decisions). Concessions: Option D concedes real costs. It looks like underutilizing Robert’s own fleet and cedes momentum/mindshare to Zaruba’s system-of-record if Robert isn’t visibly shipping. The fleet monitor is an ‘adopt+thin’ bet, not risk-free — task-level metrics tuned for hundreds of concurrent agents may need rework once real usage patterns on the two-plane architecture emerge, and nothing published validates monitoring at that scale (industry anchors max out around 64 concurrent agents). Doc-11’s shelf life is bounded by how fast the legacy estate actually changes underneath it. And ‘defer until Tomas answers three questions’ has no built-in timebox — without a forcing function or re-evaluation date, deferral can drift into indefinite idleness, which is a discipline failure Option D must guard against explicitly rather than assume away.

Prosecutor (strongest honest attack)

  1. Option D exempts fleet monitor from its own moratorium, but the monitor’s prerequisite infra sits behind the exact gate the moratorium invokes. The adopt+thin plan requires a working OTel→Prometheus→Grafana pipeline (fork ColeMurray/claude-code-otel + import dashboard 25255) [E7]. monorepo-infra recon shows the Grafana/Temporal Helm stack is ‘ready-not-applied’ behind a human-only GCP billing gate, with zero dashboards and zero alerting live today [E5]. That billing gate is literally one of the three conditions Option D names as blocking ‘every other app.’ You cannot coherently ship (3) ‘now’ while claiming everything else waits on the resource (3) itself depends on — either the gate is soft enough to ship through (so why does it block anything else?) or it’s hard enough to block (3) too.
    • Evidence: [E5], [E7]
  2. The plan makes the entire factory-app roadmap a single-point-of-failure bet on M4, with no hedge if it slips. E1’s own bar for that gate — dual-run live by week 6, write ramp to 100% with reconciliation ≥99.999% — is an aggressive target on a 75-commit, 2-day-old, solo-authored doctrine. Kill gates (M4/M8/M12) exist in the doctrine precisely because Zaruba anticipates failure is a live possibility [E1]. Option D commits Robert to zero interim value delivery — nothing between fleet monitor and doc-11 — until a gate everyone building it expects might fail actually resolves.
    • Evidence: [E1]
  3. ‘Wait for Tomas to answer 3 questions’ cedes unilateral pacing control over Robert’s entire portfolio to someone with no committed timeline in evidence, when the collision problem it’s ostensibly solving already has a dedicated solution. E2/E8 show real, already-built partition machinery — CODEOWNERS partition, claim-before-work queue, OWNERSHIP.md, MADR ADRs with DRI, ≤8-10 worktree cap, merge queue, services.json manifest — explicitly designed so hundreds of agents (including Robert’s) can work without colliding with Tomas’s plane. If that machinery works, Robert doesn’t need to freeze his roadmap to avoid collision; if it doesn’t work, Option D hasn’t tested the thing it’s relying on to eventually unfreeze. Either way, ‘defer to avoid collision’ is solving an already-solved problem by creating a new one: total dependency on Tomas’s personal bandwidth, which E8 itself flags as the scarce resource (‘více agentů mi nepomůže’).
    • Evidence: [E2], [E8]
  4. The fleet monitor ships with no real factory-app production load to observe, so its chosen metrics — task success rate, rework rate, cost-per-merged-unit, queue depth [E7] — go unvalidated against anything but Tomas’s single greenfield plane (a system Robert doesn’t operate and whose write path is human-gated proposal-only [E2]). A monitor calibrated against one team’s dashboard-free Temporal instance, scoped to one Encore app connection [E5], is likely to need rework once actual multi-app factory throughput exists to measure — meaning Option D’s ‘ship now’ item is itself at high risk of turning into a second build.
    • Evidence: [E7], [E5], [E2]
  5. Deferring means integrating later against a bigger, staler delta. Zaruba’s substrate — tasks service, full workflow-management/Temporal platform, service-management catalog, mcp OAuth+registry skeleton, docs service — is already built and overlapping several of Robert’s deferred candidates, and it is moving at 75 commits in 2 days under a solo author [E1][E3]. The longer Robert waits to build against it, the larger the reconciliation gap when he finally does (e.g., the tasks service’s TaskType.INFORMATION_REQUEST/APPROVAL machinery is directly relevant to E7’s flagged ‘unsolved’ question-triage/dedup problem, yet Option D leaves that integration undiscovered indefinitely). Early integration surfaces incompatibilities cheaply; late integration against someone else’s fast-moving ‘system of record’ [E8] does not.
    • Evidence: [E1], [E3], [E7], [E8]
  6. The legacy estate’s decay clock does not pause for Tomas’s decision clock. E6 documents EOL runtimes across the board (Rails 3.2, Ruby 1.9.3-2.6, JRuby 1.7), two half-finished strangler migrations already rotting in production code, and MBUS entangled in 16 of 33 components — all actively decaying regardless of whether Tomas answers his 3 questions this month or next quarter. Option D funds zero tooling investment against this compounding risk beyond a monitor and a static document; whatever the 34-agent characterization fleet is doing continues on its own steam, unaffected and unaccelerated by any Robert-built tooling, while the thing being characterized keeps rotting.
    • Evidence: [E6]
  7. Doc-11 written today risks becoming ‘analysis theater’ rather than a durable artifact. Its stated purpose is to inform decisions that, by Option D’s own design, cannot be acted on until Tomas’s rulebook stabilizes and M4 resolves [E1][E8] — but those same two events are exactly the inputs that would change the assessment’s conclusions. An assessment written against today’s snapshot (of a doctrine 2 days old and a legacy estate actively decaying per E6) is likely to need re-litigation once the facts it was waiting to not-need actually land, undercutting the claim that it’s low-risk, do-now work.
    • Evidence: [E1], [E8], [E6]
  8. Option D reduces an entire independent agent fleet’s output to two deliverables while every named unblocking condition — Tomas’s 3 questions, the M4 gate outcome, infra billing — carries no committed date anywhere in the evidence. There is no timebox, no partial-commitment fallback, and no named trigger for revisiting the freeze other than the gates themselves clearing on their own schedule. That is an open-ended commitment dressed as a scoped one.
    • Evidence: [E1], [E5], [E8] Strongest point: Option D’s own carve-out is internally inconsistent: shipping (3) fleet monitor ‘now’ requires the exact Prometheus/Grafana infra [E7] that E5 shows is unprovisioned behind the same GCP billing gate Option D names as a reason to defer ‘every other app.’ You cannot use one gate to justify freezing eight apps while quietly assuming it won’t block the ninth. Concessions: Fair credits to the option: Tomas genuinely is decision-bound not throughput-bound (E8’s own quote), so throwing more Robert-side tooling at him doesn’t obviously help and could add noise to a bandwidth-constrained reviewer (E8: AI PRs already wait 4.6x longer, 32.7% acceptance). The fleet-monitor carve-out is well-evidenced as a no-regrets move (E7’s market scan genuinely found nothing off-the-shelf, and Anthropic’s own Agent View validates the mental model). Building 8-9 factory apps against a 2-day-old, 75-commit doctrine before M4 proves the dual-run/parity pattern at all is a real and legitimate risk, not manufactured. And doc-11 in isolation, stripped of the ‘then wait’ framing, is cheap, reversible work. The prosecution’s case is that the deferral is unbounded and self-contradicting in its scope, not that caution about Tomas’s rulebook is unwarranted.

Cross-examination

  • Best advocate point (don’t worsen the decision bottleneck; sequence generalization after M4 per the doctrine’s own kill-gate logic) → rebuttal: the deferral freezes Robert’s own execution lane, which does not consume Tomas’s decision bandwidth — ledger, monitor, and triage serve Robert’s fleet operations, not Tomas’s rulebook. Deferring them idles the fleet without relieving the bottleneck the argument invokes. The M4-sequencing logic is adopted where it belongs: harness generalization staging (see C cross-exam).
  • Best prosecutor point (internal inconsistency — the monitor carve-out depends on the same gated infra used to justify freezing everything else; deferral is unbounded, no timebox) → rebuttal: the inconsistency is repairable (monitor runs local-first: docker-compose Prometheus+Grafana per the [E7] stack; the billing gate blocks cloud deployment only). The unbounded-deferral attack stands unrebutted. Verdict input: D contributes one discipline to the winner — every deferred item gets a named re-decision trigger — but fails as a portfolio.