browser parity e2e suite — the cutover gate from twitter-debug's bespoke Brave to the leased pool

[amiller]

Strategy (operator, 2026-07-06): dual-run twitter-debug's bespoke Brave AND the RFC 0028 leased pool (#68), and retire the bespoke path ONLY when this parity suite is all-green. Parity is the gate — not a date.

Build an e2e suite that runs each capability against BOTH engines and asserts equivalent results. Publish a parity board (same pattern as /journeys) so red rows show the remaining work.

Capability	twitter-debug (bespoke)	pool-lease equivalent	Parity assertion
inject jar	/twitter/setjar	lease + broker jar-inject (RFC 0018)	a known jar renders logged-in on both
logged-in screenshot	/twitter/shot	lease → navigate → capture	x.com/home shows the account (a known @handle visible), non-blank
DOM reconstruct (reify)	/twitter/reify	lease → eval/reify	≥N timeline entries with text, same order-of-magnitude
driven browser actions	/twitter/engine	lease → driven task	a scripted task reaches the same end state
write / post	/post	lease + write cap	a post (or dry-run) lands, asserted present
egress binding	/twitter/ip	per-lease egress locked to domain	VPN egress IP (not a datacenter IP) on both
liveness	/twitter/health	pool/lease health	green
isolation (parity-PLUS)	single browser — cannot pass	two concurrent leases (twitter + youtube)	no cross-session bleed — each read returns only its own account

The last row is the migration's whole justification: the bespoke single browser fails it (one global session — see RFC 0028 Problem), the pool must pass it. It stays in the gate.

Sequencing: (1) pool lands (#68) ephemeral-per-lease + broker inject + lease-time accounting; (2) point browserFeed/browserScreenshot at a lease behind a flag, old SPI still selectable; (3) this suite runs against both, board published; (4) all-green → flip the flag, move twitter-debug's reify/engine onto a lease, retire the bespoke Brave. One browser on the pod.

Verify honestly per box-inventory/scope-down: build the suite + run what's runnable now (isolation test, screenshot, reify against a seeded jar); rows needing a live logged-in jar or the broker (RFC 0018, impl pending) are marked NOT-YET with the exact reason, not faked green. Depends on #68 + the RFC-0028-decisions issue.

[amiller]

Blocked: baseline (pool #68) is absent from staging — zero verifiable parity on this branch

Investigated per box-inventory/scope-down before blocking. The verifiable-now subset is empty on origin/staging, because every runnable-now row needs the pool, and the pool is not merged.

Evidence (this iteration, origin/staging):

• git ls-tree origin/staging proxy/ → no browser_pool.py; grep -ni "lease|pool|browser|render" proxy/runtimes.py → nothing. No pool on staging.
• The pool lives in RFC 0028: browser render pool (isolated/fair/reset leases) #68. gh pr view 68 → state: OPEN, mergeStateStatus: DIRTY, mergeable: CONFLICTING. It can't reach staging without a rebase.
• This issue's own body: "Depends on RFC 0028: browser render pool (isolated/fair/reset leases) #68 + the RFC-0028-decisions issue." RFC 0028: record the two operator decisions — ephemeral-per-lease container + metering hook #76 (ephemeral-per-lease container + metering hook) is OPEN/unsettled — and those two decisions reshape the pool's isolation contract and the metering seams this suite would assert against.
• The bespoke engine is not in this repo: grep -rn "setjar|/twitter/shot|/twitter/reify|/twitter/engine|/twitter/ip" in tee-daemon → no matches. It's the external login-with-everything CVM; its acceptance already lives in oauth3-apps/harness/acceptance-login-with-everything.sh (+ browser-pool acceptance + a report/index.html board there).

Why the runnable-now subset is empty on this branch: every row the issue says to run now depends on the pool endpoint (POST /_api/browser/render, GET /_api/browser/pool, defined by #68):

• isolation (parity-PLUS) — pool-only by definition (the bespoke single browser cannot pass it — that's the migration's justification);
• screenshot / reify-against-seeded-jar — "lease → navigate → capture", i.e. the pool path.

So without #68 in staging, no parity row can be exercised green in test_daemon.py. I did not ship an all-NOT-YET suite: with the pool missing that's vacuously green (faked-green, which this issue forbids) and it would encode #68's unmerged, decision-pending contract — a stopgap, not root cause.

Unblock (in order):

1. Rebase + merge RFC 0028: browser render pool (isolated/fair/reset leases) #68 to staging (it's currently CONFLICTING).
2. Settle RFC 0028: record the two operator decisions — ephemeral-per-lease container + metering hook #76 (ephemeral-per-lease + metering) so the isolation/reset assertions this suite pins have a stable contract.
3. Re-add ready; this suite then runs against a real pool. The bespoke-side rows already have a harness seam in oauth3-apps/harness (acceptance-{login-with-everything,browser-pool}.sh, report/index.html) — point the parity board generator at both and assert equivalence, red rows = remaining work.

Marking blocked so the loop stops re-picking this tick. No PR this iteration.

[amiller]

PR #68 (browser render pool) is now merged to staging — parity work is unblocked. (Operator-approved merge, 2026-07-09.)