Skip to content

SPIKE-P2P-02 — gate verdict — 2026-08-14

Verdict: PASS. Issued at the Architect seat (Fable) on Alex's confirm-back, read in full. Scratch lane (V-P2P-001), single-gate review per lane ceremony. Wall clock 5m 05s, zero 429s (~40 calls), account left at 0 Workers / 0 namespaces, matching the pre-build baseline. Guards held throughout: Product account only, product-scratch-01 only (sha256[:8] 9a8c0bd2), pure REST, workers.dev only, synthetic payloads, no repo commits, no secrets in output, Workers + one namespace only.

Findings of record

  1. The instance Worker ceiling is 10 MiB post-gzip — binary MiB (10,485,760 bytes), not the decimal "10 MB" the documentation states (485,760-byte difference). Enforced at UPLOAD (error 10027, identical body at all three rejected rungs). Bracket: 9.999 MiB accepted, 10.249 MiB rejected — 0.25 MiB, tighter than briefed. Caveat: sizes are Alex's local gzip (compresslevel 9); Cloudflare's compressor may differ within ~1% at the edge; the API reports no size field on success or rejection.
  2. No runtime startup enforcement observed. Every accepted rung served; the documented 1-second startup budget was never approached at 9.999 MiB. The ceiling is an upload-time limit on this evidence.
  3. Module count is free at scale. 301 modules / 300-deep import chain / 3.010 MiB: accepted, cold 526 ms — 3.7× faster than the same-size 5-module rung. For V-P2P-003, the many-tiles shape is not the risk; total bytes is.
  4. Cold starts: bounded, not curved. 0.4–2 s across 1–10 MiB, non-monotonic, one sample per rung — Alex correctly refused to fit a trend. Warm serving flat (56–89 ms) and size-independent across the whole ladder. A size→cold-start curve needs repeated cold starts per rung: a different measurement, deliberately not this job.
  5. Propagation lag generalises (instrument finding, first-class): rung-00's first request returned 1042, then 200 — the same configuration-to-runtime lag SPIKE-P2P-01 measured on bindings, now seen intermittently on the serve path. All later rungs showed zero retries, confirming intermittency. Consequence for the control plane: EVERY post-provision check — including serve verification — is retry-until-consistent; a single-shot check can file a false failure. (Also re-confirmed: the estate's browser-integrity trap bites non-browser UAs; fixed with a real User-Agent, timings post-fix.)
  6. Two documented WfP constraints recorded at execution date (2026-08-14): caches.default is disabled for namespaced scripts — tile code must never rely on it; scripts are unlimited in count; max eight tags per script; no gradual deployments for user Workers (already held); no WfP-specific size override exists — the 10 MiB figure is inherited from the standard Workers page, and this spike is what converts that inference to a measurement.

Consequence for canon

V-P2P-003 (Worker-per-instance) stands, now measured. EMPTY-TILE-01 §11.10 CLOSED; the spec's first least-sure item resolves. Applied in DRAFT v2.2 (§5.1 measured budget + caches note; §9.1 lag generalisation; §9.3 instance-size watch; least-sure rewritten). A real product tile set is estimated at 1–3 MiB post-gzip (estimate, not measurement — code compresses where the spike's payload deliberately did not); the §9.3 ops watch is what keeps the estimate honest as tiles accrete.

What this leaves open

The size→cold-start curve (repeated cold starts per rung — queue only if a product need emerges); the per-user-vs-per-token rate-limit budget (untouched, per brief; remains its own queued measurement); Cloudflare-side compression delta at the bracket edge (absorbed by the §9.3 watch margin).

Least sure, and what would make it wrong: the 1–3 MiB tile-set estimate is mine, from typical compressed JS bundle sizes, not from our code — if the rewired tiles ship with heavy embedded assets rather than keeping them in stores where they belong, the estimate fails in the direction the size watch is built to catch.