Skip to content

SPIKE-P2P-03 — ARCHITECT VERDICT

Seat: Architect (Fable). Date: 2026-08-14. Job: fleet migration runner — shape, resumability, partial failure. Alex (bridge seat), directed by Tim, scratch lane, RTOpacks Product account, product-scratch-01. Verdict: PASS. 20/20 provisioned in OC · runner verified independently of its own report · resume demonstrated · quarantine demonstrated · 522 calls, zero 429 · teardown measured against the 0c baseline: D1 0/0, namespaces 0/0, Workers 0. Guards held in full. Basis of this verdict: Alex's full report as relayed by Tim in-session. This is a scratch-lane verdict, not a gate verdict; the findings JSON and the report file at the filing pass, and this verdict files with them. (Answering Alex's closing question: yes — filed artefact. Findings are the record; the record lives in the repo.)

Process note — recorded once, without drama

The draft's own standing was NOT FOR EXECUTION — DRAFT FOR ARCHITECT REVIEW, with two named review items: the ledger-shape question (§2) and the hand-picked step-6 failure. Execution preceded review, on Tim's direction. The lane covers it — scratch is minimal ceremony by V-P2P-001, and the blast radius was genuinely zero — and no harm landed: the ledger shape had not been settled centrally (no anchor-two design exists), so steps 3–6 tested the right shape by luck rather than by check. Recorded so the record shows a decision, not drift: scratch-lane jobs may run on Tim's direction without waiting on the Architect. Where a draft itself names open review items, the cheap discipline is a one-line check on those items first — this one risked a wasted window, not a breach. Alex's framing correction in §0 (throughput was the wrong question; lockstep change is the real one) is endorsed without reservation — Tim's rejection of the obvious spike was right.

F1 — THE HEADLINE, and it was an accident: an unreadable ledger must fail closed

mig-tenant-06, migrated successfully in run 1, was not skipped in run 2: the ledger read failed transiently, the runner treated "couldn't read the version" as "not migrated yet," re-applied, and was saved only because ALTER TABLE ADD COLUMN fails loudly on a repeat. Had migration 003 been an INSERT or UPDATE it would have silently applied twice to a live tenant and nothing would have reported a problem. The bounded probe (5 tenants × 8 write-then-read cycles, 40/40 consistent) rules out a D1 read-after-write anomaly at this volume; the cause is carried as an unexplained 1-in-20 transient, which is the correct posture — a real runner must survive it whatever it was, so chasing it has no payoff.

Minted as standing design law for every runner this programme builds:

LEDGER-FAILS-CLOSED-01. A skip/apply decision rides only on a successful ledger read. An unreadable ledger is a quarantine state, never a default to "not yet done." Corollary: no migration statement is ever assumed idempotent — a runner is designed as though any step may be attempted twice, because one day it will be.

Applies immediately to: the fleet migration runner (anchor two, when designed); the anchor-one ingestion runner's fetch ledger (design amended to v1.1, §4.3 — cheap there since re-fetch is idempotent by sha256, but the rule is stated so the discipline is uniform); and any future queue-driven worker with a done-ledger.

F2 — Quarantine falls out naturally; the ledger-shape question now has a measured answer's first half

The runner quarantined the poisoned tenant and completed the other 19 — the desirable behaviour, and it emerged from the simple shape rather than being engineered. The stranded tenant is identifiable from the per-tenant ledger alone, at a cost of one read per tenant — 4,000 reads at fleet scale to answer "who is behind." That converts §2's hypothesis into measurement: shape (a) per-tenant ledger is sound as truth (self-describing, travels on export/offboard — which also serves V-P2P-007's artefact chain), and the fleet-status question is the concrete case for a central index in the control plane. Working position carried into anchor-two design, not decided here: (a) as truth, (b) as index, the index rebuildable from the truth at any time. Alex predicted exactly this in §2; the spike upgraded it from likely to measured.

F3 — The fleet-migration arithmetic, and a promotion

Measured: 3.0 calls per tenant per migration, 0.85 s per tenant, 95 calls/min achieved, zero 429. Extrapolated (from 20, arithmetic, not measured at 4,000): 12,000 calls; ~57 min serial; the 1,200/5-min ceiling floors a concurrent run at ~50 min — per statement-round. A three-statement migration floors at ~2.5 h. Consequences adopted:

  1. The ops plane treats a full-fleet migration as a scheduled window with a call budget, never an instant — this goes into the anchor-two inputs alongside the fleet-study's migration-runner findings.
  2. The rate-limit per-user-vs-per-token measurement is PROMOTED from queued-in-no-order to the next scratch window. If the budget is per user, a dashboard session during a fleet migration eats the migration's budget — that changes the runner's design, not just its schedule.

F4 — Provisioning is settled without its own spike

~1.0 s per D1 create (bracket 0.90–1.17 s, n=20), OC honoured 20/20 at create. With SPIKE-P2P-01's Worker-upload timings, full tenant stand-up sits in the 5–10 s band: signup is synchronous. Alex's §0 judgement — that throughput deserved no spike — stands confirmed at zero marginal cost.

F5 — The instrument lesson, earned a second time

Alex's current_version swallowed every failure mode into None — the instrument reported execution, not outcome, which is the exact defect class doctrine 5 names. Self-caught mid-job, rebuilt to record read failures explicitly before step 6 (read_failures = 0, now a measured zero rather than a silence). No new rule needed; the existing one is re-earned and cited.

Dispositions

  • Report + findings JSON + this verdict: file at the filing pass (the spike-03 set joins the queue: empty-tile set, spike-02 verdict, anchor-one set, glossary touchpoints, consumed TMs).
  • product-scratch-01 survives — the account was returned to zero durable substrate; the retirement trigger has not fired.
  • The unexplained transient is carried as unexplained, by design. No further measurement.
  • Anchor-one design bumped to v1.1 (LEDGER-FAILS-CLOSED-01 folded into §4.3) before the Driver's adversarial pass, so the Driver reviews current bytes.

Least sure, and what would make it wrong: the extrapolation's shape, not its arithmetic — it assumes migrations run fleet-lockstep in one window. If the anchor-two design migrates in rolling waves (schema-version heterogeneity tolerated between waves), the 50-minute floor is a per-wave figure and the pressure moves from the rate ceiling to version-skew handling in the tiles. That is a real design fork for anchor two, and nothing in this spike forecloses it.

— Architect seat (Fable), 2026-08-14.