Research — brainstorm, problem discovery, evidence tiers, advisory board, steelman

Bottom line: The concept survives reframing as coordination, accounting, and memory problems — each backed by dated, structural evidence, not taste. It survives more weakly as a trust problem — the mechanism is sound but nobody has asked Tomas whether he will use it. Every non-service alternative (process-only, Temporal-native, beads, markdown-in-git) has a named, dated breakpoint; none covers the five-part scope. The evidence supports building the schema and claim primitive now — it does not yet support building it as a separately-branded, day-one standalone service; that packaging question is still open at the end of this pass (see §5.3, which does not average the advocate/prosecutor split — it takes a position).

Method: This document compiles brief §§3, 4, 13 (pm:brainstorm + pm:discovery + advisory board/steelman) from material already gathered: five research digests (competitive, oss, priorArt, temporalCase, repoRecon — all dated 2026-07-18), the five-advisor board, and the advocate/prosecutor cases. No new web research was run for this document; every claim below is cited to its source pass or to [E1]–[E10] in plans/001-factory-apps-validation/01-deep-dive.md. Sibling docs 05-competitive-analysis.md and 06-open-source-analysis.md carry the full landscape scan — this document’s job is discovery and adjudication, not a second full survey.

1. Brainstorm — problem reframings and solution shapes

1.1 Does the problem survive reframing?

The brief for pm:brainstorm asks whether this is fundamentally a coordination problem, an accounting problem, a trust problem, or a memory problem. If it only survives under one framing, that framing is probably wrong (over-fit to the frame that was in the room when someone decided to build). Tested against all four:

Reframe	Statement of the problem	Survives?	Evidence
Coordination	Stop two agents claiming the same unit of work	Yes — strongest	Quantified, dated: locks-only claim queues reproduce the highest redundant-rediscovery rate of any tested condition (180 instances); a claim collision “leaves no trace” in git history, invisible to PR-level telemetry (arXiv:2606.19616, priorArt digest). GitHub’s 2026 rate-limit crisis (5,000 req/hr budget, a 50-session batch triggering 42,000 calls/hr) is independent, dated evidence that routing a 64-concurrent claim through an external API is a documented anti-pattern (competitive digest).
Accounting	Attribute cost + durable disposition per unit, past the point Temporal purges it	Yes — structural	Confirmed fact: self-hosted Temporal retention is 72h; closed-workflow data is purged from both persistence and visibility within days; Archival is replay-only blobs, not a queryable table (temporalCase digest B1, `temporal-operate` SKILL). Kill gates M4/M8/M12 need the same unit readable months later. This is a mechanical incompatibility, not a preference.
Trust	Give Tomas defensible evidence at 3 gates over 12 months, at zero ongoing cost to him	Survives as intent, not as validated demand	The mechanism (an enum-constrained, evidence-linked table) is sound and Grafana/SQL is already his read habit (fleet monitor verdict). But every one of the five advisors below independently demanded the same missing fact: has Tomas been asked whether he will read a Postgres table instead of the ADR log he already trusts? He has not (unanimous finding, §4). Until answered, “trust” is a designed-for outcome, not an observed one.
Memory	Make sure a dead agent’s half-finished work leaves a trace instead of silently vanishing	Yes — the most concrete finding in this whole pass	priorArt digest, same preprint: “race-to-close is invisible in git history — the loser’s wasted work leaves no trace” under a lock-only or file-based-tracker regime. This is the one claim in the entire research corpus with a quantified before/after (180 redundant-rediscovery instances under leases-only vs. lower under a durable-record condition) rather than an inference.

Reading: the concept is genuinely robust under 3 of 4 reframings — it is not a single-framing artifact invented to justify a service. The trust framing is the honest weak point, and it is weak in the same place plan 001’s own open question #3 already flagged (“does anyone besides Robert’s fleet ever adopt it… prior: yes, untested”).

1.2 Fundamentally different solution shapes

Five shapes considered, each with a one-paragraph disposition. These are not incremental variants of one idea — they are structurally different bets about where the durable state should live.

Process-only (ADR/decision log, no new software). Component-tier dispositions (~dozens, across 26 repos [E6]) are decisions, and Groupon already has an append-only, supersede-never-edit decision log (reasons-and-decisions/07-decision-log.md) that Tomas already reads at gates — the temporalCase digest itself concedes ADRs beat a table at this tier. It breaks at unit-tier cardinality: ~1000 units, each needing an evidence link and a cost, is per-record bookkeeping, not architecture decision-making; hand-authoring an ADR per unit is exactly the “worse Linear” anti-pattern the initial recommendation already forbids. Disposition: adopt for component tier (already exists, free); reject for unit tier (breaks on volume).

Temporal-native (search attributes + workflow-id uniqueness + tasks INFORMATION_REQUEST, zero new services). Steelmanned to failure in the temporalCase digest: workflow-id uniqueness is a genuinely atomic claim, but only for a unit that is a Temporal workflow — v1’s fleet is external Claude sessions, not workflows. Search-attribute capacity (28 custom attrs/namespace, 2KB/255-char values) cannot hold state + disposition + cost + evidence + blocking-question-ref without exhausting the Keyword budget. Decisively: the 72h retention wall purges everything from both persistence and visibility within days, and kill gates need months. Blended coverage of the system-of-record mandate: ~30%, and the 70% gap (durability, queryable business schema) is structural, not tunable — bumping retention keeps history, not queryability, and racing a purge clock with a snapshot cron is more moving parts than one table. Disposition: reject as a standalone substitute; adopt its genuinely real parts (workflow-id claim for v2 workflow-modelled units, the existing workflow_executions projection) as inputs to the thin-service design, not as a replacement for it.

beads (Dolt-backed claim/dependency queue, Steve Yegge). Purpose-built for exactly this job class, and still fails at the layer work-ledger most needs to be bulletproof: its own Postgres backend merged 2026-07-10 (PR #4601), rolled back 2026-07-16 (PR #4847, two days before this research), final Dolt-only consolidation 2026-07-18 (PR #4881, the morning of this research) — and it carries open, unresolved multi-machine merge conflicts on its own metadata table plus zero chaos-test coverage on the Dolt path (gastownhall/beads issues #2466, #2765; oss digest). Disposition: reject as work-ledger’s substrate. It remains viable only for the separate, originally-scoped role research/12 §1.2 gave it — a cross-fleet claim-before-work queue between Robert’s and Tomas’s fleets — a different problem from durable unit-level bookkeeping.

markdown-in-git (Backlog.md-style file board — same files are the human and agent API). The single most direct piece of negative evidence in this whole research pass: under 2 agents each writing a different field to the same record, a file-based last-writer-wins tracker keeps one agent’s write and silently discards the other’s entirely (arXiv:2606.19616, priorArt digest). This is not a theoretical race; it is the exact failure mode work-ledger exists to prevent, reproduced and quantified in a system of the same shape. Disposition: reject — proven unsafe at the concurrency work-ledger targets, not merely unproven-safe.

Thin Encore service — Postgres SSOT, SKIP LOCKED claim, enum-constrained state machine, one-way Temporal projection. The only shape that covers the full five-part scope (claim, state, disposition, cost, projection) without inheriting one of the breakpoints above. Its cheapest slice — atomic claim — is a single FOR UPDATE SKIP LOCKED clause, “cheaper to write than to integrate a dependency for” (oss digest); its most defensible slice — durable disposition/cost/evidence past 72h retention — has no substitute in the 2026 market at any coverage level (competitive + priorArt digests, independently). Disposition: build, thinner than plan 001 scoped it (own only the business columns Temporal purges, not a mirrored lifecycle engine — temporalCase digest P6, already adopted into 10-architecture.md). The open question this brainstorm pass does not resolve — deliberately left to §5.3 — is whether “thin service” must mean a new, separately named, separately deployed Encore service on day one, or whether it means the same four tables living inside the fleet monitor’s already-committed schema. Every non-service alternative is disqualified; the service-vs-monitor-schema question is not.

2. Problem discovery (brief §4)

Core problem

At fleet scale, unclaimed-and-untracked work destroys trust in the whole program. Two agents claiming the same unit burn double tokens and produce merge collisions; an agent dying mid-unit leaves work silently half-done; cost accrues with no per-unit attribution; abandoned migrations become invisible. The legacy estate already shows what this looks like at 1-developer scale, uncorrected: two half-finished strangler migrations rotting in code — VIS3 still calls legacy VIS; identity-service was abandoned in 2022 [E6]. Work-ledger’s stated purpose is that no unit of work can be in an ambiguous state — an accounting invariant, not a feature.

Who / when / how often / how expensive

Dimension	Finding	Source
Who	Write path: Robert’s fleet agents, exclusively (10→64 concurrent Claude sessions). Read path: Robert (operator, continuous — queue/stall/cost) and Tomas (stakeholder, low-frequency/high-stakes — disposition table at kill gates).	`01-initial-recommendation.md` §“who it serves”
When	Agent-facing: constant, every claim/transition/block call, potentially thousands/day at full ramp. Tomas-facing: 3 times over 12 months (M4/M8/M12 kill gates) — an order-of-magnitude-different frequency from the agent-facing load, which several advisors (Christensen, Torres) argue should not automatically share one build timeline.	`00-SYNTHESIS.md` kill gates; temporalCase digest §crossover
How often	Component-tier disposition events: ~dozens, bounded by 26 sampled repos [E6]. Unit-tier: an estimated ~1000 units total, queued, never concurrently edited — 1000 is a backlog depth, not a concurrency figure; concurrent editors cap at 10→64 [E9].	`00-SYNTHESIS.md` “program hardness re-score”
How expensive — token cost anchor	Best-documented real-world case at this shape: Bun’s 1M-LOC JS→native migration, 64 concurrent agents, <2 weeks, $165k, but 19 escaped regressions and a 53.9% agent-tangling base rate — “nothing published validates >64 concurrent, let alone 1000” [E9, `02-case-studies.md`]. This is the anchor for what a correctly run fleet at this scale costs; it is also evidence that verification, not generation, is the bottleneck even when claim-safety isn’t the failure mode being measured.
How expensive — review capacity	Independent of work-ledger’s existence: AI-authored PRs wait 4.6× longer for review and land at 32.7% acceptance vs. 84.4% for human-authored PRs [E8, research/12 §1.7]. This means even a perfectly claim-safe fleet is bottlenecked downstream of the ledger — a fact several advisors (Jobs, via the competitive digest’s Symphony finding) use to argue the ledger cannot by itself fix the program’s real throughput ceiling, only prevent a worse failure (silent duplication) on top of it.

How it’s solved today

It isn’t — there is nothing to displace. The greenfield repo is confirmed 2 days old at the time of this research (81 commits, sole author Tomas Zaruba, HEAD 92d2ea0, 2026-07-18 — repoRecon §1). An exhaustive grep across the full repo at HEAD for work[-_]?ledger, disposition, claimUnit, SKIP LOCKED, pg_advisory, beads, pgmq, and related terms returns zero relevant hits (repoRecon §8). Robert’s fleet has not yet run at the 64-concurrent ceiling the plan is designed for — the current actual concurrency is not established in any source pass, a gap named explicitly by three of five advisors (Cagan, Torres, Christensen) as the single most important unanswered question. No claim collision, duplicate-work incident, or lost-update event has been documented as having actually happened in Robert’s fleet. The entire justification is evidenced by a different system (the arXiv preprint’s tested conditions), a different company’s tool (OpenAI Symphony), and Groupon’s own pre-existing evidence of what ungoverned work looks like without any concurrent-agent involvement at all (the two rotting stranglers, [E6], which predate the fleet entirely and are a headcount/process failure, not a concurrency failure).

Why existing solutions insufficient

Summarized from 05-competitive-analysis.md and 06-open-source-analysis.md (full treatment there; this is the discovery-level finding, not a re-survey):

No 2026 commercial or OSS product covers the five-part bundle (atomic claim + 4-way disposition + per-unit cost + one-way Temporal projection). The closest real analog, OpenAI’s own Symphony (open-sourced Apache 2.0, Apr 27 2026), explicitly lacks all three of claim-safety, cost, and disposition, and OpenAI declined to productize it — a well-resourced team’s revealed preference that the durable value is a data model, not a product (competitive digest).
Every purpose-built agent-work tracker examined has a live, structural gap: beads’ own Postgres backend was built and rolled back inside a 9-day window; Backlog.md-style git-native boards are proven, quantified, unsafe under the exact concurrent-write pattern work-ledger targets (oss + priorArt digests).
Every company that shipped the fuller “AI work board” product shape is now defunct as a business (Vibe Kanban/Bloop, Apr 2026; Terragon, Feb 2026) — for business-model reasons (free users, no moat), not because the underlying technical problem was unsolved. This is weak evidence against a commercial product and near-zero evidence against a thin internal schema (competitive digest, explicitly flagged as not transferable).

Is software the right solution at all?

Split verdict, and the split is load-bearing for §5.3.

For the claim + durable-attempt-record slice: yes, and the evidence is unusually strong for an internal tool. The one quantified failure-mode study found (arXiv:2606.19616) shows that neither the non-software answer (locks/leases as a pure convention) nor the lighter-software answer (a git-native file tracker) solves this — locks-only reproduces the highest rediscovery rate of any tested condition, and file trackers silently drop writes. A DB-enforced, enum-constrained, durably-logged claim is the one condition class not shown to fail. This is about as close to “software is the correct response, demonstrated against alternatives” as an internal-tooling decision gets.
For disposition bookkeeping: it depends on the tier, and this is the point every advisor and the prosecutor case converge on. Component-tier disposition (~dozens of decisions across 26 repos) is already solved by existing, free, already-trusted software — the append-only ADR/decision log — and adding a second recording mechanism for the same fact is redundant, not additive. Unit-tier disposition (~1000 records, needing an evidence link and a cost per record) is genuinely bookkeeping-shaped, not decision-shaped, and the ADR log does not fit that cardinality. Software is the right answer only for the unit tier — a four-table addition, not a new lifecycle engine.
For the packaging question (is it a “product”?): no — this is the one place the research corrects the framing rather than confirms it. Two independent sources converge on “schema + invariants, not a product”: the plan’s own initial recommendation and, external to Groupon entirely, Paul Gross’s “ledgers as the missing primitive” essay (pgrs.net, 2025-06-17) — arrived at independently, before this research existed. The 2026 market sells nothing called “an AI-fleet work ledger” for the same reason: the durable value in every adjacent success story (Symphony, GitHub Agent HQ’s audit trail) is the data model, wrapped in the thinnest glue that gets it in front of agents, “never a screen, rarely even a dedicated service” (competitive digest).

3. Evidence tiers

Per brief: every material claim used anywhere in this plan is classified into exactly one of five tiers. This table is the doc’s spine — strict by design. “Agents will actually rework less with a ledger” is an assumption, not a fact, and is labeled as such below alongside everything else that would be convenient to treat as settled.

Confirmed facts (directly read from a primary source, dated)

Claim	Source
`monorepo-development` is 2 days old at research time: 81 commits, sole author Tomas Zaruba, HEAD `92d2ea0`, 2026-07-18 21:39	repoRecon §1
Zero work-ledger-shaped artifact exists anywhere in the repo (exhaustive grep, zero relevant hits)	repoRecon §8
Only one toy internal Temporal workflow exists repo-wide (`example-internal-workflow`) — no real fleet-unit workflow runs on the substrate today	repoRecon §3
72h is the `temporal-operate` skill’s namespace-create example value; nothing provisioned yet, retention is a tuning knob — the structural purge argument (closed-workflow data purged from both persistence and visibility within days; Archival preserves replay-only blobs, not a queryable table) is the confirmed part	temporalCase digest B1; `temporal-operate` SKILL.md
Self-hosted search-attribute cap = 28 custom attributes/namespace, 2KB/40KB total, 255 chars per value	temporalCase digest B2; Temporal docs
`assigneeGroupSlug` on `tasks` is a plain free-form `varchar(128)`, not an enum — an “agent-questions” group needs zero schema change	repoRecon §2
Same-day commit `eada68c` (“One credential header”) collapsed auth to one `Authorization` header; `grpn_`-prefixed Bearer tokens validate identically on both planes; `g-api-key`/`X-Skip-Encore-Auth` removed	repoRecon §6
No vitest+Docker-PG integration test pattern exists anywhere in the repo; every service-layer test mocks its repository via `vi.hoisted()`	repoRecon §5
beads’ Postgres backend merged 2026-07-10 (PR #4601), rolled back 2026-07-16 (PR #4847, two days before this research), final Dolt-only consolidation 2026-07-18 (PR #4881, the morning of this research)	oss digest, independently re-verified via `gh api`
beads has open, unresolved multi-machine merge conflicts on its own metadata table and zero chaos-test coverage on its Dolt backend (issues #2466, #2765)	priorArt digest
Locks-only claim queues reproduce the highest redundant-rediscovery rate of any tested condition (180 instances); under 2 agents writing different fields to the same record, a file-based last-writer-wins tracker keeps one write and silently discards the other	arXiv:2606.19616 (priorArt digest) — confirmed source, hypothesis-grade finding (preprint, different system); single preprint, see hypothesis-tier note below on how strongly to weight it
Legacy estate sample: 26 repos, 1.05M active backend LOC, MBUS load-bearing in 16/33 components, two half-finished strangler migrations (VIS3, identity-service abandoned 2022)	[E6]
Bun case study: 1M LOC JS→native, 64 concurrent agents, <2 weeks, $165k, 19 escaped regressions, 53.9% agent-tangling base rate; nothing published validates beyond 64 concurrent	[E9], `02-case-studies.md`
AI-authored PRs wait 4.6× longer for review, land at 32.7% acceptance vs. 84.4% for human-authored PRs	[E8], research/12 §1.7
OpenAI Symphony: open-sourced Apache 2.0 2026-04-27, polls Linear every 30s, 500% landed-PR increase in 3 weeks on some internal teams, no per-issue cost field, no disposition taxonomy documented, OpenAI declined to maintain it as a product	competitive digest, dated citations (mindstudio.ai, helpnetsecurity.com, 2026-04/05)
GitHub 2026: 5,000 REST req/hr budget; a 50-session batch triggers 42,000 calls/hr (8.4× budget); PR caps added specifically to throttle AI-driven volume	competitive digest, dated citations (techlogstack.com, quasa.io, coderabbit.ai, 2026) — secondary sources only (techlogstack/lunar.dev); not verified against a GitHub primary source
Terragon Labs shut down 2026-02-09; Vibe Kanban/Bloop shut down 2026-04-10, relicensed Apache 2.0	competitive + priorArt digests
`monorepo-infra` is 0% provisioned; Temporal + Grafana Helm scripted but not applied; blocked on human-only GCP billing gate	[E5]

Strongly supported interpretations (reasoned from confirmed facts, not themselves directly observed)

Claim	Basis
The durable per-unit table (disposition, cost, attempts, evidence, blocking-question ref) is needed regardless of packaging — the fleet monitor (already committed, first-to-ship) needs the identical table for cost/merged-unit, rework rate, queue depth, and stall detection. This is the single most load-bearing interpretation in this research pass — both the prosecutor’s Count 1 and the temporalCase digest’s own honest verdict hang on it.	temporalCase digest §crossover, §honest-verdict; research/12 §2
Work-ledger is closer to a schema + thin workflow than a “product”	Two independently-arrived-at sources converge: the plan’s own `01-initial-recommendation.md` §1 and Paul Gross’s ledger-as-primitive essay (external, predates this research) — competitive digest
The one-way-projection architecture (Temporal = execution truth, ledger = business fields only) is industry-validated, not merely internally reasoned	Matches Netflix Conductor’s worker-listener pattern and Vitess’s topology-aggregation-not-duplication pattern; dual-write literature confirms the alternative is a known anti-pattern — priorArt digest
A DB-enforced, enum-constrained claim beats both a bare lock and a file-based tracker at the concurrency work-ledger targets	Direct implication of the confirmed arXiv finding above, generalized one step (the preprint tested a different system, but the failure mechanism — mutex without durable record — is system-agnostic)
Routing a 64-concurrent atomic-claim primitive through an external SaaS API (GitHub, Linear) is contraindicated	Confirmed GitHub rate-limit facts above, generalized to “any comparable external tracker API,” which is an interpretive step, not itself observed for Linear specifically

Reasonable hypotheses (plausible, consistent with evidence, but untested)

Claim	Why it’s a hypothesis, not more
Robert’s fleet will actually experience the kind of claim collision the arXiv preprint describes, at 10→64 concurrent	Extrapolated from a different system’s tested conditions; never observed in Groupon’s fleet (unanimous advisory-board gap)
Tomas will read a Postgres disposition table at kill gates, in addition to or instead of the ADR log he already uses	Consistent with the plan’s design intent; zero direct confirmation from Tomas exists in any source pass
A second fleet (Tomas’s) will eventually claim through work-ledger	Named as an open question in `01-initial-recommendation.md` #3 since before this research began; nothing in this pass resolves it either way
The claim-safety failure mode is present at the fleet’s current concurrency, not only at the future 64-agent ceiling	No source pass establishes what the fleet’s current concurrency actually is
Free-text fields (`question`, `evidence_url`) will stay disciplined rather than drift into kanban-style comment creep	Consistent with the schema’s design (only 3 free-text columns) but unproven under real LLM-agent usage

Unsupported assumptions (currently asserted as fact somewhere in the plan set, without evidence)

Claim	Where it’s asserted as more certain than it is
“Agents will actually rework less with a ledger”	Implicit premise of the whole build; no controlled before/after comparison exists anywhere in this research corpus
The four-way disposition taxonomy (MIGRATED/DROPPED/DEFERRED/DEAD) is the right cardinality at unit tier	Inherited wholesale from the decommission-ledger merge (`00-SYNTHESIS.md` verdict #8), never independently re-derived from work-ledger’s own evidence (Ive’s challenge, §4.2)
A1 (Tomas grants a CODEOWNERS-partitioned lane) will resolve favorably	Flagged Medium likelihood in `00-SYNTHESIS.md`’s own risk register; as of 2026-07-18 the conversation with Tomas (research/14) is drafted but unsent
The two SQL views for cost-per-unit / cost-per-merged-unit are needed in v1	No document names the specific decision Robert makes differently because these views exist, versus reading the raw OTel cost stream the monitor already collects (Cagan’s and Torres’s shared challenge, §4)

Unknowns requiring validation (neither confirmed nor reasonably inferable from what was gathered)

Claim	Status
Whether Linear’s `assignee` write path has any optimistic-concurrency guard	Not found in available docs — treat as unknown, not “definitely unsafe” (competitive digest)
Whether `claude-task-master` covers any part of the requirement bundle	Zero mentions in any of the three supplied research digests; flagged unknown rather than guessed at (`05-competitive-analysis.md`)
Whether AWS Transform / Google Migration Center have an undocumented internal cost+disposition bookkeeping layer	Public silence on the topic could mean “doesn’t exist” or “exists, undocumented” — genuinely indistinguishable from outside (priorArt digest)
Base rate at which internal (non-commercial) engineering tools get abandoned	No clean number exists in public literature; Gartner/McKinsey shadow-IT stats describe SaaS sprawl, not single-purpose internal tools — directional atmosphere only, not a citable figure (priorArt digest)
Josef Sima’s role in groupon2 (assumption A5, `01-deep-dive.md`)	Unknown as of this research; affects the collision/review-capacity math if he turns out to be a third active party

4. Advisory board

Disclaimer: the five outputs below are principle-based simulations — an analytical exercise applying each named figure’s publicly documented philosophy to this specific plan. They are not quotations, not endorsements, and no claim is made that any of these people reviewed this document. Reproduced here in full per brief §13, reformatted for readability; content is unabridged from the source pass.

4.1 Steve Jobs — focus, integrated ownership, ruthless subtraction, immediate comprehensibility

For. Ambiguous state is a defect Jobs would not tolerate anywhere in a pipeline he controlled, visible or not. The evidence is mechanical, not aesthetic: a June-2026 preprint quantifies that locks-only claim queues reproduce the highest redundant-rework rate of any tested condition, and that git-native file trackers silently drop concurrent field writes — a bare claim queue without a durable disposition record does not solve claim-before-work. GitHub’s own 2026 rate-limit crisis is concrete evidence against routing a 64-concurrent claim primitive through any external tracker API. Google Rosie/LSC and Vitess both prove the pattern that works at scale: one execution-truth engine, one-way projection to business state, no dual-write — exactly work-ledger’s shape, converging with outside evidence rather than invented internally. Jobs backed unglamorous infrastructure when it stood between chaos and a shippable result; this is that category, not a screen nobody asked for.

Against. The plan has become a product-shaped bureaucracy around a thing its own research calls “closer to a schema than a product.” 14 documents — a PRD, a pre-mortem, a North Star Metric doc, a Made to Stick pass, a validation plan — for a 3-endpoint internal service read by one operator and one stakeholder at a handful of kill gates over a year. A North Star Metric implies a growth trajectory and an adoption funnel; this thing has two fixed human readers and a fleet size explicitly capped by policy, not ambition. Worse: the temporalCase digest’s own honest conclusion is that the durable table “gets built regardless,” and the only real open question is whether it lives as a standalone service or the fleet monitor’s schema — an org-boundary call, not a build/no-build one. The entire “work-ledger as its own named product” framing may be a self-inflicted fourth service where a shared schema inside the already-committed monitor would do.

Challenged.

Standalone work-ledger service as a fourth deployable — the digest itself concedes the table is needed regardless; default to the monitor’s schema instead of naming and versioning a separate service for two human readers.
Four-way disposition enum — DEFERRED vs DROPPED is a distinction without an operational difference at the moment Tomas actually reads the table; collapse to the one question the gate answers unless a concrete M4/M8 use of the split can be shown.
Attempt-level cost column — speculative granularity nobody has asked for yet; ship unit-level summed cost first.
North Star Metric doc and full SUCCESS-pass doc — process built for a product with an adoption curve, applied to infrastructure with two fixed human readers and a capped fleet.
External-claim endpoint treated as permanent architecture rather than a flagged, temporary v1 shim — the plan already knows this only exists because units aren’t Temporal workflows yet.

Demanded questions.

What actually breaks tomorrow, in dollars or agent-hours, if this doesn’t exist — a real incident, not the pre-mortem’s hypothetical collision?
Has a collision or duplicate-claim actually happened yet at any concurrency Robert has run, or is the 64-concurrent failure mode entirely modeled and never measured?
Why does this need to be a fourth named, versioned service instead of four columns and a claim function added to the fleet monitor’s schema, which ships first regardless?
Does Tomas actually commit, today, to reading the disposition table at M4 — or is that still the untested open question #3?
Could the whole thing ship this week as one migration file plus two SQL functions, with the PRD/pre-mortem/validation plan written after real agents have used it for a week?

Changes. Collapse the 14-document apparatus into the schema, the two invariants, and one page of rationale — write the PRD/pre-mortem/validation-plan after a week of real fleet use, not before code exists. Default to merging work-ledger’s table into the fleet monitor’s Postgres schema rather than standing up a separate named Encore service. Cut the disposition enum to the one distinction the kill gate actually decides on. Defer attempt-level cost; ship a per-unit sum first. Kill the North Star Metric doc outright; shrink the Made to Stick pass to a paragraph inside the README.

MVP principle. Ship the one constraint that prevents the worst failure, then stop. One table, one atomic claim function, one enum a new agent can understand in a single sentence. If explaining a field takes more than a sentence, or justifying the service takes more than a paragraph, the plan has outgrown the problem.

Evidence required. One real collision or duplicate-work incident with a measured token cost from an actual fleet run; Tomas’s explicit, dated confirmation that he will read the disposition table at a kill gate; a concrete reason the fleet monitor’s own schema cannot carry these four business columns, before a fourth named service gets built, versioned, and roadmapped around them.

4.2 Jony Ive — design-philosophy lens

For. The refusal to build a UI is the design’s most coherent move: work-ledger commits to one honest material — Postgres schema constraints — and lets that material do the enforcing work itself (DB-rejected illegal transitions, SKIP LOCKED atomicity) rather than layering trust or a screen on top of a weaker foundation. Two independent external sources converge on the same reduction the team reached alone — Paul Gross’s “ledger as primitive, not a product” essay, and the 2026 market’s total absence of any competing “AI-fleet ledger” product — evidence the reduction is correct, not merely convenient.

Against. Every unit of documented design attention has gone into the part of the object the team enjoys designing — schema normal form, enum CHECK constraints, one-way projection — while the API’s actual failure-mode surface (the exact JSON an agent sees on a lost claim race or an illegal transition) is asserted but nowhere designed. 01-initial-recommendation.md claims “errors that name the violated invariant… the error message is prompt engineering,” then nothing in the plan set shows one. For work-ledger the user’s hands are on the API, thousands of times a day, at 64-concurrent, and that surface has had zero documented craft pass — exactly the internal-tool trap of treating a low-visibility surface as exempt from the care given a customer-facing one.

Challenged.

Four-state disposition taxonomy carried forward wholesale from the decommission-ledger merge rather than re-derived from work-ledger’s own evidence — does DROPPED earn a state distinct from DEAD once an evidence link is present on both?
The two SQL views named in the MVP duplicate the fleet monitor’s own stated ownership of dashboards and cost views — one honest purpose should not also carry a sibling service’s presentation layer.
Free-text question and evidence_url fields are the one deliberate escape from the enum-everything discipline — worth challenging as the seam where kanban-style creep re-enters.
Dual claim paths — Temporal workflow-id uniqueness vs. a separate SKIP LOCKED external-claim endpoint — is this one coherent claim primitive wearing two names, or two designs stitched under one word?

Demanded questions.

Show the literal JSON body an agent receives when it loses a claim race or attempts an illegal transition — has this been designed at all, or only asserted as a principle?
Has any agent been given only the OpenAPI/tool schema, zero prose docs, and asked to claim/transition/block correctly on the first attempt?
Where did the number four (dispositions) come from — evidence from the legacy sample, or unexamined inheritance from the decommission-ledger merge?
Has Tomas’s actual read path (raw SQL or a Grafana panel) been built and shown to him even once, or does “Grafana + SQL” stand in as a placeholder nobody has designed?
If the durable value is the data model + invariants — the plan’s own research concludes exactly this — why does this plan set still carry product-shaped artifacts (personas, journey maps, a SUCCESs pass) for an object with two human readers?

Changes. Write and review the API error taxonomy with the same rigor spent on the schema, before the schema migration ships. Re-derive the disposition enum from evidence; audit whether DROPPED and DEAD are ever distinguished by anything other than the evidence link, and collapse if not. Remove the two SQL views from work-ledger’s own scope; let the fleet monitor read work-ledger’s tables directly. Run one real end-to-end demonstration of Tomas’s kill-gate read before calling the human read path designed. Name the dual claim path explicitly as a temporary seam with a stated collapse condition.

MVP principle. Not the full five-part scope shipped at once — the single smallest pair of calls, claim and transition, built to a standard where their failure-mode feedback is indistinguishable in quality from a perfectly crafted single-user tool even under 64 concurrent callers, before disposition, cost, and blocking-question are layered on.

Evidence required. A zero-shot usability proof (an agent given only the tool/OpenAPI schema correctly claims/transitions/handles a conflict on first attempt); real fleet-load evidence (not a 2-claimer test) showing lost-race error bodies are actionable without a human debugging session; one live demonstration of Tomas reading the disposition table at a real or rehearsed kill gate.

4.3 Marty Cagan — product-risk lens

For. The riskiest assumption — that concurrent-agent work silently duplicates effort, loses work, and produces untrustworthy disposition records — is unusually well de-risked for an internal tool, and from outside the building: the June-2026 preprint’s quantified findings, and the closest real analog (OpenAI’s own Symphony) explicitly shipping without claim safety, cost attribution, or disposition tracking, its authors declining to productize it. The team also resisted its own worst instinct — no UI, no kanban, no priorities, no notifications were deliberately cut — leaving an MVP whose size actually matches the size of the validated problem.

Against. Every research digest de-risks feasibility (can it be built, does prior art exist) and none de-risks value for the two humans who must actually trust and use it. Tomas — the one stakeholder whose adoption decides whether a disposition table means anything at a kill gate — has not been asked a single question in this entire pass; assumption A1 (whether Robert even gets a lane) is unresolved and flagged as the top pre-mortem risk, yet the plan proceeds straight to architecture and endpoint contracts as if the lane and Tomas’s trust are already secured. This is solution-first: the shape was decided before running the cheapest possible test of the riskiest human assumption — a ten-minute conversation with Tomas about whether a disposition table beats the ADR log he already trusts. It is also being sized for 64-concurrent contention that has not yet been observed happening at the fleet’s actual current scale.

Challenged.

Disposition taxonomy as a standing table at unit tier, shipped before any kill gate has forced the question — component-tier dispositions map cleanly onto the existing ADR log; unit-tier need is asserted, not demonstrated.
Per-attempt cost column — overlaps with the fleet monitor’s already-planned OTel cost tagging; no evidence gathered that aggregate OTel cost is insufficient.
External-claim endpoint — a workaround for the fleet not running on Temporal yet, written into the plan as permanent product surface with no stated removal trigger.
Two SQL views + a Grafana panel shipped in v1 — output built for a reader (Tomas) who has not confirmed he will look at it.
“Absorb the decommission ledger as row types” — bundling two different problems into one schema before either is independently validated.

Demanded questions.

Has a real claim-collision or duplicate-work incident actually happened in the fleet yet, or is the entire justification anticipatory?
What is the fleet’s actual current concurrency, and how does it compare to the load at which the cited failure modes start to bite?
Has Tomas been asked directly whether a disposition table beats the ADR log he already trusts — and what did he say? If unasked, why does an architecture doc exist before that conversation happened?
Is assumption A1 resolved? If not, what is architecture and endpoint design worth for a service that may have no repo to live in?
Why is the external-claim endpoint scoped as permanent rather than a dated bridge tied to the trigger “fleet units run as internal-plane Temporal workflows”?

Changes. Cut v1 to claim() plus a single state enum only; hold disposition, cost, evidence-link, and both Grafana views until the bare claim primitive has run against real fleet traffic for 1-2 weeks and shown a measurable drop in rework. Get Tomas’s explicit, written answer on whether he wants a disposition table before the disposition schema is built. Resolve A1 before finalizing the architecture doc. Put an explicit graduation/removal trigger on the external-claim endpoint. Point cost attribution at the fleet monitor’s existing OTel tags first; add a ledger-owned cost column only if a concrete gap is found in practice.

MVP principle. An MVP exists to test the riskiest assumption as cheaply as possible, not to be a scaled-down version of the final feature list. Here that means shipping claim() alone against real fleet contention and watching what actually happens, before building the disposition/cost/evidence accounting layer around a collision-and-trust problem the plan has not yet observed occurring at the fleet’s real, current scale.

Evidence required. One real observed collision or duplicate-work incident in the current fleet; Tomas’s written confirmation that he will use a disposition table, not the ADR log, as kill-gate evidence; assumption A1 resolved; a 1-2 week claim()-only spike showing measurable rework reduction before disposition, cost, and evidence-link scope is added.

4.4 Teresa Torres — continuous discovery / opportunity-solution-tree lens

For. The one piece of genuine discovery evidence in this pile is arXiv:2606.19616: locks-only claim queues reproduce the highest redundant-rediscovery rate of any tested condition, and git-native file trackers silently drop concurrent field writes — actual, documented, quantified pain, not an invented want. It grounds the stated outcome (“no unit of work can be in an ambiguous state”) in evidence rather than taste, and the market scan independently confirms nobody else has solved the bundle, so this isn’t reinventing an available wheel.

Against. The whole 002 process inverts the discovery sequence. 01-initial-recommendation.md opens with the solution before any outcome metric is named — a target doesn’t appear until doc 09, downstream of solutioning. Worse: 14 research docs plus five digests were produced before a single agent touched a live claim() call, to decide something serving two named humans who could be asked directly this afternoon. Effort is lopsided: feasibility is exhaustively de-risked across five digests; desirability — will Tomas ever open the disposition table, will agents use the claim API correctly without hand-holding, will Tomas’s fleet adopt at all — is asserted as prior and never tested. For a 2-user internal tool, adoption risk should have been the first thing tested, not the last thing assumed.

Challenged.

Disposition table as queryable rows for component-tier dispositions — the ADR log already covers this tier well; has anyone confirmed Tomas will query a table instead?
Cost-per-unit / cost-per-merged-unit views — no doc names the decision Robert makes differently once this exists.
Cross-fleet visibility / “does anyone besides Robert’s fleet adopt it” — sized and pitched as a two-fleet system of record on an explicitly-stated prior, not evidence.
“Absorbs decommission ledger as row types” on day one — folds a second data concern into the schema before the first has any live usage to learn from.
External-claim endpoint — legitimate v1 bridge, but should be kept minimal and temporary, not invested with polish, since it’s architectural debt paying for a transition.

Demanded questions.

What single outcome metric is this meant to move, measured on the real fleet, not inferred from literature or competitor pricing pages?
Has Robert observed an actual collision in current practice, or is the entire threat model extrapolated from an unreviewed preprint about a different system?
Will Tomas actually open the disposition table at M4/M8/M12? Has he been asked that literal question?
Has any agent been pointed at a stub claim()/transition()/block() and observed using it correctly unprompted — proof the affordances are legible to an LLM, not just well-argued?
If Tomas’s fleet never claims through work-ledger, what does the “right-sized” version look like — does cross-fleet framing collapse to a Robert-only tracker, and at what unit/agent count does even that earn a service instead of a script?

Changes. State the outcome metric before finalizing scope — one number, not a North Star doc arriving after the architecture is set. Ship the walking skeleton to the real fleet this week and instrument every claim/transition/block call — let 5-10 units of real usage inform the disposition enum and cost schema instead of speculating both upfront. Get Tomas’s explicit yes/no on whether he will read the disposition table at the M4 gate — one message, not a doc. Cut the cost-rollup views from v1 scope until a decision they inform is named; keep only the raw per-attempt cost column. Treat the disposition enum and schema as provisional/mutable for the first 2 weeks of live fleet use rather than a finished spec.

MVP principle. Not “smallest complete feature” but “smallest live test of the riskiest assumption.” Ship claim/transition/block against real units this week, instrument actual agent and human read behavior, and let disposition taxonomy, cost views, and cross-fleet scope emerge from 1-2 weeks of observed use rather than from five research digests written before anyone touched the thing.

Evidence required. One observed or near-miss collision from the actual fleet; Robert’s stated outcome metric; Tomas’s explicit commitment to read the disposition table at a gate; at least one unprompted successful agent interaction with the live claim/transition/block API; one week of real usage data before the disposition enum and cost schema are treated as final. (The claim-safety mechanism itself needs no further evidence — feasibility is already over-proven across five digests.)

4.5 Clayton Christensen — jobs-to-be-done / disruptive-innovation lens

For. Non-consumption is the real competitor, and it’s confirmed, not assumed: every research pass converges on the same negative result — no product, OSS or commercial, does claim-safety + cost-per-unit + disposition together. The struggle Robert’s fleet is hired to solve today is tribal-memory coordination across a scaling agent count, and the failure literature says that struggle is not hypothetical past a few concurrent workers — lock-only claim queues reproduce the highest redundant-rediscovery rate of any tested condition, and git-native file trackers silently drop one agent’s concurrent field write entirely. There’s also a real, under-named social/emotional job: in the two-lead relationship where collision risk is named the top political risk, a working ledger is Robert’s credibility that his fleet doesn’t collide with Tomas’s — worth more to the relationship than its technical elegance.

Against. The plan bundles two different jobs into one service before either is validated at current scale. Job 1 (agents): “stop me from claiming what’s already claimed” — high-frequency, felt now, technical. Job 2 (Tomas): “show me, three times over twelve months, what happened to each unit, defensibly” — low-frequency, evidentiary, social. Forcing both into one Postgres schema on day one is the classic error of solving two jobs with one product and optimizing for neither, while competing for the same scarce engineering hours as Robert’s already-committed, higher-priority deliverable — the fleet monitor, which independently needs the identical durable table. As scoped, work-ledger risks becoming the same infrastructure built twice under two names on two timelines. And the struggle itself is still a hypothesis at the fleet’s current ~10-agent scale — every collision-cost number cited is extrapolated toward 64, not observed at 10.

Challenged.

Cost-per-unit as a column the ledger owns and writes, rather than a value it reads by joining the OTel/Grafana per-worktree cost data the monitor already collects — a second source of cost truth serves no job the first doesn’t already serve.
Disposition taxonomy as a Postgres table from day one at unit-tier cardinality, when the existing ADR log already carries component-tier dispositions durably and is the medium Tomas already reads.
Bundling claim/attempts/blocking-question and disposition/cost/evidence into one service and one ship date — two jobs on two frequencies should be allowed to ship on two timelines.
Building work-ledger as a standalone service in parallel with, rather than as literally the schema of, the fleet monitor that’s already committed and already needs the same table.
Any residual appetite to eventually project live execution state from Temporal into the ledger — the job never asked for a live mirror of Temporal, only a durable record of what Temporal purges.

Demanded questions.

What specific, dated collision or lost-work incident has actually happened at the fleet’s current ~10-agent scale — or is the claim-safety job entirely anticipatory?
What does Tomas currently do, today, without any ledger, to track a component’s disposition — and would he actually open Grafana/SQL to read a table at the M4 gate, or does the job only get hired if the answer shows up in a medium he already checks?
Is the claim-safety job genuinely inseparable from the evidentiary job — or can they ship on different substrates and different timelines without loss?
Given the fleet monitor is Robert’s already-committed, higher-priority deliverable and needs the same durable table, why isn’t work-ledger’s v1 literally the monitor’s schema, with a standalone service as a later step only once a second consumer actually claims through it?
What would concretely break in the program if units were tracked instead in the existing tasks service plus the decision log plus a flat claim file, and has that failure been observed at current scale or only assumed from the 64-concurrent projection?
At what agent-count or unit-count does a dumb flat-file/markdown claim convention actually stop being “good enough” — has that threshold been tested, or is Postgres being reached for on day one because 64 is the eventual target, not because 10 has already broken something?

Changes. Unbundle the two jobs explicitly: ship the claim primitive as the first slice on its own, decoupled from disposition/cost/evidence columns. Fold the ledger’s schema into the fleet monitor’s Postgres store instead of standing up a second service, until Tomas’s fleet actually writes to it. Route component-tier dispositions through the existing ADR/decision-log; reserve any Postgres disposition table strictly for unit-tier cardinality the ADR log can’t carry. Before writing schema, run a 1-2 week trial of a dumb flat-file or spreadsheet claim convention at the fleet’s current scale to see whether the collision/rework struggle is actually felt yet. Make cost-per-unit a read (a view joining OTel/Grafana’s existing cost stream) rather than a field the ledger writes and owns.

MVP principle. Build only the job that’s already being felt at today’s scale — atomic claim, because collision risk is structural and the failure literature says locks-only still reproduces it — and let the job that’s still hypothetical at today’s scale — kill-gate evidentiary bookkeeping — wait until it’s weeks, not months, from being hired for real. Don’t build the low-frequency job’s machinery on the high-frequency job’s day-one timeline just because they’ll eventually share a table.

Evidence required. A dated, named account of at least one actual claim-collision, duplicate-work, or lost-update incident under the fleet’s current (~10-agent) operation — or, absent that, a controlled 1-2 week trial with a deliberately dumb flat-file claim convention that reproduces the struggle at current scale — before Postgres/SKIP LOCKED is justified as more than insurance against a future that hasn’t arrived. Separately, one direct confirmation from Tomas that at the M4 gate he will actually query a Postgres disposition table rather than read the existing ADR/decision-log.

4.6 Cross-advisor convergence

Five advisors, five different lenses, and near-unanimous agreement on a small set of concrete gaps — worth surfacing separately because independent convergence from different philosophies is stronger evidence than any one advisor’s opinion:

Convergent finding	Who raised it
Nobody has asked Tomas if he’ll read a Postgres table instead of / alongside the ADR log	Jobs, Ive, Cagan, Torres, Christensen — all five
No real collision has been observed at the fleet’s current concurrency; the entire threat model is extrapolated from a different system’s preprint	Jobs, Cagan, Torres, Christensen
The standalone-service-vs-monitor-schema question is unresolved and probably decided wrong by default (as a new service)	Jobs, Christensen explicitly; Cagan and Torres implicitly via scope-cutting
Cost-per-unit views duplicate the monitor’s OTel cost stream with no named decision that requires the duplication	Cagan, Torres, Christensen
The four-way disposition enum is inherited, not re-derived from evidence	Ive explicitly; Jobs implicitly (“distinction without an operational difference”)
The API error-message/failure-mode surface is asserted as designed but never actually shown	Ive uniquely, but not contradicted by any other advisor

No advisor challenges the core claim mechanism (atomic SKIP LOCKED + durable attempt record) itself — every challenge targets scope, sequencing, packaging, or unvalidated adoption, never the primitive. That is itself a finding: the disagreement in this research pass is not “should collision-safety exist,” it is “how much should be built around it, when, and as what kind of deployable.”

5. Steelman — advocate, prosecutor, independent verdict

5.1 The case FOR building work-ledger (advocate)

Reproduced in full per brief §13. Every external claim dated; evidence tiers marked in the original. Verdict argued: BUILD, thin.

1. The problem is real, present, and gets fatal exactly at Groupon’s scale. The failure mode is not hypothetical — it is already in the estate: two half-finished strangler migrations rotting in code (VIS3 still calls legacy VIS; identity-service abandoned 2022) [E6]. That is what untracked disposition looks like at 1-developer scale. Robert’s fleet ramps 10→64 concurrent Claude agents; the same ambiguity that costs one dev a stale branch costs a 64-agent fleet double-spent tokens, merge collisions, and silently half-done work. This is now quantified, not asserted: arXiv:2606.19616 (June 2026) measured that an advisory-lease-only design produced the highest redundant-rediscovery count of any tested condition (180 instances), and that git-native file trackers silently discard one of two concurrent field writes under last-writer-wins. The race-to-close leaves no trace in git history. This closes open question #1 from 01-initial-recommendation with evidence: yes for the naive versions, no for what work-ledger specs.

2. Timing: the durable table is needed on day one, not at a future gate. Three clocks force the build now: fleet ramp (10→64 is the committed trajectory, collision-safety must exist before the ramp); kill gates M4/M8/M12 (Tomas’s disposition read must be readable months after a unit closes); the Temporal retention wall (72h, confirmed, purging both persistence and visibility). The decisive timing argument: the durable per-unit table gets built regardless. The fleet monitor — Robert’s committed first deliverable — needs cost/merged-unit, rework rate, queue depth, and stall detection in Grafana, which requires a durable per-unit store on day one. The only open question is org-boundary (standalone service vs. the monitor’s schema), not build/no-build.

3. Adoption is structurally near-frictionless. Two human users (Robert operates, Tomas reads at gates) and an agent fleet on the write path. Agents adopt by API — the claim call is the way to get work. Humans never learn a UI — Grafana + SQL is the entire read surface, already mandated. Zero new vocabulary imposed on Tomas — triage v1 needs zero PRs against core. Convergent external validation: GitHub’s own Agent HQ adopted the “unified audit trail” principle in 2026 — evidence-bearing systems of record for agent work are baseline good practice now, not idiosyncratic.

4. Nothing off-the-shelf covers the requirement bundle — structural, not a maturity lag. OpenAI Symphony — the closest real analog — explicitly lacks claim safety, cost field, and disposition taxonomy, and OpenAI declined to productize it. GitHub Issues/Projects as the claim substrate is a documented 2026 anti-pattern (rate limits, PR caps added specifically to throttle AI volume). beads’ Postgres backend was built then rolled back 2 days before this research; Temporal’s visibility caps make it mechanically incapable of holding disposition+cost+evidence. Temporal-native and hatchet cover ≤~30% of the five-part scope; every other named candidate covers ≤25%. No 2025-2026 agentic-migration tool publishes a cost+disposition bookkeeping layer — there is nothing to buy or adopt.

5. Unique advantage: it rides substrate that already exists, with an industry-validated architecture. Work-ledger composes already-vetted parts: Temporal execution truth, the existing workflow_executions projection, tasks INFORMATION_REQUEST, workflow-id-uniqueness for claim, Postgres, Grafana. The one-way-projection design matches Netflix Conductor’s worker-listener pattern and Vitess’s topology-aggregation pattern almost exactly. Paul Gross’s “ledgers as the missing primitive” essay independently arrives at the same framing as the plan’s own §1.

6. What must be true for this bet to pay off.

Must be true	Status	If false
Tomas grants a CODEOWNERS-partitioned lane (A1)	Assumption, untested	A-lite fallback: Robert-owned repo, API-only — portfolio unchanged
Scope stays a schema + claim guard + views	Enforceable by decision, not preference	Scope creep to “worse Linear” — every company that shipped that shape is defunct
Projection stays one-way	Structural invariant, code-review-enforced	Two-sources-of-truth incident kills trust in both
Concurrency ramps on ledger metrics	Committed ramp plan	64-ceiling breached blind, rework explodes

Net (advocate): build. The problem is present and quantified, the durable table is a day-one need the monitor forces anyway, adoption is near-frictionless, the market covers none of the requirement bundle, and the architecture is industry-validated on substrate that already exists. The only correction the evidence demands is downward on scope — schema + claim guard + two views, no screens — which sharpens the BUILD THIN verdict rather than threatening it.

5.2 The case AGAINST building it (prosecutor)

Reproduced in full per brief §13. Prosecution demand: do not build work-ledger as a standalone service or “product.” The irreducible durable core is ~1 table + ~150 LOC + 2 views that the committed fleet-monitor deliverable needs on day one regardless. Standing up a second internal Encore service — with its own registration, auth, migrations, tests, ops surface, and decision-log footprint — to wrap that table for 2 human readers is redundant packaging, not a build decision. Every research digest ostensibly “confirms BUILD THIN.” Read adversarially, they confirm something narrower: a schema, not a service; a byproduct, not a portfolio item.

Charge sheet.

#	Count	Evidence
1	It’s a feature of the fleet monitor, not a product. The one durable table is “the same table the fleet monitor needs anyway”; whether it ships as “work-ledger service” or “monitor’s schema” is an org-boundary call, not build/no-build.	temporalCase digest verdict
2	The market’s own verdict is “no service.” Symphony got a 500% landed-PR increase with a thin poller on Linear and zero new service; OpenAI declined to productize it.	competitive digest; helpnetsecurity 2026-04-28
3	“Product” is a category error. No vendor/OSS sells “AI-fleet work ledger” — the durable value is a data model + invariants, “never a screen, rarely even a dedicated service.” Every firm that shipped the fuller shape is defunct.	competitive digest
4	The claim primitive is one SQL clause. Atomic claim = a single `FOR UPDATE SKIP LOCKED` — “cheaper to write than to integrate a dependency for.” ~150 LOC, not a service worth naming.	oss digest
5	Half the architecture is vaporware today. “Projection from the internal-plane workflow stream” has no stream to project from — one toy example workflow exists; wiring it means editing Tomas’s hardcoded, single-path interceptor file. The “vitest+Docker-PG house pattern” cited as TDD precedent does not exist anywhere in the repo.	repoRecon §3, §5
6	Platform-absorption risk is live, not theoretical. Zaruba built the two-plane arch, `tasks`, full `workflow-management`, the `workflow_executions` projection, and a same-day auth rewrite — 81 commits, sole author, in days. He can absorb this faster than the A1 lane negotiation resolves.	repoRecon §1; `00-SYNTHESIS.md` risk A1
7	Single-fleet irrelevance. Open question #3 is untested: Tomas’s fleet runs Core domain-migration workflows, never claims through work-ledger. A “cross-fleet ledger” that exactly one fleet writes to.	`01-initial-rec` §Q3; temporalCase B3/B5
8	Opportunity cost inverts committed sequencing. Fleet monitor is Robert’s committed deliverable, “first to ship.” Every day spent standing up a ledger service is a day the monitor — which needs the same table — slips.	`00-SYNTHESIS.md`; research/12 §2
9	Ops overhead for 2 humans. A new internal service means registration, generated migrations, service-account tokens, serial vitest, `pnpm validate` on every commit, and decision-log entries — standing cost, forever, for a disposition table two people read at three gates.	repoRecon §4-7

The two counts that alone should stop it. Count 1 is dispositive: the most pro-build digest, steelmanned to failure, still lands on “the durable per-unit table gets built regardless; the only open question is whether it lives as a standalone work-ledger service or as the fleet monitor’s schema.” That is a concession there is no independent build decision here. Counts 2+3 kill the “product”: the single best real-world analog spent zero services and won big; its authors — a well-resourced team — revealed-preference against productizing.

Preempting the defense.

Defense will say	Why it doesn’t save “build the service”
“Temporal’s 72h retention purges dispositions — we need a durable store”	Concedes only that columns must be durable — put them on the monitor’s schema. A retention wall argues for a table, never for a service.
“beads/pgmq/Temporal-native cover <25% of scope”	True and irrelevant: the 75% they miss is disposition+cost, five columns, not a system. Coverage-gap ≠ product-justification.
“Locks-only reproduces the highest redundant-work rate — need the full state machine”	Single unreviewed June-2026 preprint, hypothesis-grade. The state machine already exists in Temporal + `workflow_executions`; duplicating it is pre-mortem #3 (two sources of truth) by construction.
“Component dispositions justify it”	~dozens of component-tier dispositions are decisions — they belong in the existing append-only ADR/decision log, which Tomas already reads. temporalCase concedes ADRs beat a table at that tier.

What to do instead. Ship the fleet monitor (committed, first) with a durable per-unit Postgres table as its schema — claim via SKIP LOCKED, disposition enum, cost column, evidence link (~150 LOC, days). Route component-tier dispositions through the existing decision log. Give the non-Temporal v1 fleet a claim endpoint on that same table — no second service, no service registration, no A1 negotiation, no design-lens README. Revisit a standalone service only if a second fleet actually claims through it (Count 7 flips).

Confidence & what would flip the prosecution. Supported interpretation (high): the standalone-service framing is redundant; the table gets built inside the monitor regardless — sourced from the pro-build digests’ own concessions, not prosecution invention. What flips it: Tomas’s fleet commits to claiming through the ledger (Count 7 dies), or fleet units become real internal-plane Temporal workflows and a projection consumer is needed (Count 5’s vaporware becomes real). Neither is true on 2026-07-18. Weak/atmospheric only: internal-tool abandonment base rates — flagged as directional, not leaned on.

Net (prosecutor): there is a table to build and no product to build. Build the table where it already has to live.

5.3 Independent verdict — does not average the advocate and prosecutor

Both cases are argued from the same evidence corpus and both are internally disciplined — neither is a straw man. Averaging them (“build something medium-sized”) would be a cop-out; the evidence actually supports taking sides on different sub-questions rather than splitting the difference on all of them.

On whether the schema and claim mechanism should be built: side with the advocate, without qualification. The evidence here is the strongest in the entire research pass and none of it is contested by the prosecutor either — Count-by-count, the prosecutor never disputes that atomic claim + durable attempt record is the correct mechanism; it disputes only what wraps it. The retention wall (confirmed fact, not interpretation), the quantified lock-only failure mode, the total absence of a market substitute, and the industry-validated one-way-projection pattern are four independent lines of evidence pointing the same direction. There is no credible “wait and see” here: the retention wall alone means any unit closed before the schema exists is unrecoverable evidence at M4, and that cost is asymmetric — cheap to build now, expensive to have needed and not had.

On whether it should ship as a new, separately-named, separately-deployed Encore service on day one: side with the prosecutor. This is the point on which the pro-build case has no real answer, only a restatement of the problem. Advocate §2’s own timing argument — “the durable per-unit table gets built regardless… the only open question is org-boundary, not build/no-build” — is not an argument for a standalone service; it is a direct quote of the prosecutor’s Count 1, borrowed as if it supported the opposite conclusion. It doesn’t. If the fleet monitor structurally needs the identical table on day one (confirmed: it is Robert’s already-committed, first-to-ship deliverable, and its planned metrics — cost/merged-unit, rework rate, queue depth, stall detection — are computable only from a durable per-unit row), then the lazy-correct placement is the monitor’s own schema, and a standalone work-ledger service is additional packaging (a new deployable, a new CODEOWNERS ask, a new A1 negotiation surface, a new decision-log footprint) that buys nothing the monitor’s schema doesn’t already deliver. Every advisor except the advocate-case’s own framing converges here (§4.6): Jobs and Christensen say it explicitly, Cagan and Torres say it by implication in their scope cuts.

On the disposition tier split: side with neither case as stated — both under-specify it. Neither the advocate nor the prosecutor draws the tier line precisely enough. The correct scope, on the evidence: component-tier disposition (~dozens, [E6]) stays entirely on the existing ADR/decision log — zero new schema, because it already works and Tomas already reads it. Unit-tier disposition (~1000 rows) is the only part that needs a table, and it needs exactly the four columns already specified in 10-architecture.md (disposition, cost, evidence link, blocking-question ref) — not a mirrored state machine, not attempt-level granularity beyond what a rework-rate view needs, and not a fourth deployable to hold it.

On the two SQL views and the four-way enum: side with the skeptics (Ive, Cagan, Torres, Christensen). No document in this plan set names the decision Robert makes differently because v_cost_per_unit exists as a work-ledger view rather than a read against the monitor’s own OTel stream — this is genuinely unvalidated scope, not merely under-argued scope, and should ship only once a concrete gap in the OTel-derived number is found in practice. The four-way disposition enum is inherited wholesale from the decommission-ledger merge (00-SYNTHESIS.md verdict #8) and never independently re-derived from work-ledger’s own evidence; it should ship as specified (breaking it apart now is itself unvalidated), but it is flagged here as provisional, not settled, pending the first real M4-adjacent read.

On the adoption/validation gap: this is the actual finding of this research pass, and it is a real gap, not a formality. Every one of the five advisors — five different philosophies, zero coordination between them — independently demanded the same fact: has Tomas been asked whether he will read a Postgres table instead of the ADR log he already trusts? He has not. Plan 001 scored BUILD THIN “high confidence” on the portfolio shape and drops; this research pass does not lower that confidence on the mechanism, but it should lower it specifically on packaging and timing — the mechanism is over-proven, the placement and the human-adoption assumption are under-proven, and those are different axes of confidence that the “high confidence” framing in plan 001 does not currently distinguish.

Verdict, stated as a decision, not a survey:

Build the schema now — 4 tables, SKIP LOCKED claim, enum-constrained state machine, one-way Temporal projection contract (as already specified in 10-architecture.md, decision D1-D8) — on the evidence in §3’s “confirmed facts” and “strongly supported interpretations” tiers, which is unusually strong for an internal-tooling decision.
Do not stand it up as a separately-named, separately-deployed Encore service by default. The service-vs-monitor-schema choice is tracked in 12-prd.md §20 Q1 and resolved by 11-build-vs-buy.md’s packaging verdict — ships as the fleet-monitor deliverable’s data layer, standalone-product framing only on a promotion trigger — with 10-architecture.md decision D5 carrying the placement note (internal-plane Encore service in monorepo-development vs. a standalone Robert-owned repo, not service-vs-monitor-schema); the default should be the fleet monitor’s schema, with promotion to a standalone service gated on a named, falsifiable trigger (a second fleet actually claims through it, or the ownership/ops case for a separate deploy boundary becomes concrete — not merely conceivable).
Split disposition by tier, not by convenience — component stays on the ADR log; only unit-tier gets the table.
Do not ship the cost-rollup SQL views until a named decision depends on them — ship the raw per-attempt cost column (justified independently by the retention wall) and let the monitor’s existing OTel stream answer cost-per-unit until a concrete gap appears.
Treat “high confidence” as two separate numbers going forward, not one: high confidence on the claim/durability mechanism; medium confidence on service-vs-schema placement and on Tomas’s actual adoption, both of which remain untested inputs as of 2026-07-18 and are cheap to close (one conversation, one week of real fleet use) before more documents get written about them.