Review brief: carlos db reads for instances in another region

You are an independent second reader of one design spec for the CARLOS platform (this repository). Read it cold and adversarially. Nothing is built yet; you are reviewing the design against the code on main.

Spec: docs/superpowers/specs/2026-10-22-db-region-forward-design.md, at the commit named in the prompt. Read AGENTS.md first.

Round 5

This is round 5. Rev 5 of the spec answers your round 4 findings, docs/superpowers/specs/CODEX-FINDINGS-DB-REGION-FORWARD-R4.md (reviewed at 010d29f6). Earlier rounds are in CODEX-FINDINGS-DB-REGION-FORWARD.md, -R2.md and -R3.md. Round 4 found the five invariants J1 to J5 (§5.3) fixed and the design converged. Rev 5 adds no mechanism; it makes four direct fixes, each marked (codex N):

| # | Finding | Round 4 said | Rev 5's answer | |---|---|---|---| | 7 | stored-ciphertext wording | partly, P3 | the 64 MiB plaintext limit and the stored ciphertext are now separate: raw sealed envelopes, under 100 bytes of overhead per 256 KiB chunk, base64 only on the wire, §5.7 | | 8 | restart recovery for disk reservations | partly, P2 | reconciliation by refusal against the units actually running, never a guessed size; and a worker that loses its connection exits by itself within 5 s, because litestream's file client and the LTX compactor ignore cancellation, §5.7, §8.3 | | 19 | progress writes not guaranteed to leave the console | new, P2 | every line flushed with ResponseController.Flush under its write deadline; admitted flushed with the headers; application/x-ndjson is not gzipped by the edge; work before the 200 bounded at 20 s for backhaul's 30 s header timeout, §5.5 step 6 | | 20 | the result can overtake the final chunk | new, P2 | result read before the listing, as the run's follow door does; the result line written only after every chunk through last_seq, §5.5 step 6 |

Findings 1 to 6 and 9 to 18 were fixed or declined-agreed in round 4 and are unchanged.

Your answer has two parts, in this order.

1. A disposition table for findings 1 to 20: fixed, declined with an acceptable reason, or not fixed. Check rev 5's four answers against the code, not against the spec's summary of it.
2. Only new findings of severity P0, P1 or P2. Leave out P3s this round. Do not repeat an earlier finding unless its fix is wrong or incomplete; then say so in the table and give the new evidence.

Fixed rulings: do not re-argue them

The product owner approved this direction:

• the console forwards a db read to a box in the region where the data lives;
• that box reads its own region's replica, runs the read-only operation there, and returns only the result;
• the console never reads another region's bucket;
• there is no console per region.

The carlos run spec's ruling also holds: the console never connects to a box, and output travels as objects in the deployment bucket.

Do not propose alternatives to these (a console per region, an IAM grant that lets the console read other regions, a direct console-to-box connection). Report only:

• a mechanism that fails to honour a ruling;
• a mechanism that breaks something else in the platform;
• a mechanism that cannot be built as described against main.

The spec's own decisions (§4, D1 to D8) are open to challenge. The provisional rulings in §16 are for the product owner; comment on them only where the spec's mechanism fails to honour one or is unsafe.

What to check

Check against the code, not the spec's description of it. Cite file:line for every claim about existing code. These are the places that matter.

The db door and the CLI:

• internal/console/apidb.go: resolveReplica, dbGate, resolveDBSource, dbClassRefusal, listReplicaLevel, the stream bounds;
• internal/console/apidbclaim.go: why the claim door stays refused;
• db.go: runQueryContext, checkQuerySQL, dbRestoreError, dbQueryStatus;
• internal/dbdoor/: plan.go (PlanRestore), restore.go (RestoreAsOf, the --at path), client.go;
• internal/lease/endpoint.go: ReadReplicaClient, the root-credential branch of newReplicaClientForUID.

The transport the spec copies:

• internal/runs/runs.go, store.go; internal/console/apiruns.go, apirunsfollow.go, runsweep.go; internal/host/runs.go;
• internal/release/rootenvelope.go and hostretry.go: the signed-request precedent;
• internal/appconfig/crypto.go: the sealing construction the spec reuses.

The long request (round 4):

• internal/edge/edge.go: the public listeners (around lines 3188 and 3354) and unixProxy and tcpProxy (around line 2377);
• cmd/console/main.go: the console's http.Server (around line 586);
• internal/console/apiinstanceimport.go: the per-request read deadline (around line 479);
• auth.go (the CLI's 30 s console client) and apimode.go (shipTimeout);
• internal/console/apidb.go: handleAPIDBGet and dbStream, the streaming precedent.

Boxes, capability and sandbox:

• internal/host/edgesfile.go (capabilities), movesoffline.go and movesoffline_stage.go (how a capability is tied to an armed worker);
• internal/edgesfile/snapshot.go: ReadLiveSnapshot, Draining, Fresh;
• internal/host/claimunit_template.go, bootstrap.go (tmpfilesConf, socket ownership), and wherever ensureSystemUnits installs units;
• internal/activator/backend_unit.go: how carlos-app@ units and their sockets are started without root.

IAM and infrastructure:

• infra/modules/region-host/main.tf: host_buckets;
• carlosframework/carloku-infrastructure region-uk.tf and region-ie.tf (on GitHub): which bucket each box role reaches, and the module refs.

Census:

• internal/provision/plan14_root_reads_test.go, plan9_b8_census_test.go, moves_offline_census_test.go;
• docs/superpowers/notes/census-proposal-moves-offline-precopy.md for how an overlay is proposed and ruled.

Questions worth your time

1. Isolation. Can the member's SQL, or a crafted replica, reach anything but its own copy? Check the worker unit in §8.3 option by option against what DynamicUser, PrivateNetwork, TemporaryFileSystem, PrivateTmp and Accept=yes actually do. Check every SQLite path that opens a file (ATTACH, VACUUM INTO, extensions, temp files, immutable) with modernc.org/sqlite v1.55.0. Can the worker reach the metadata service, the box role, /data, /etc/carlos or another tenant's files?
2. The prefix. Is there any path where a request field, rather than the fresh record and the box's own config, picks the bucket, prefix, host or level? Is the incarnation check placed so a host recreated between request and read cannot be read under the old request?
3. Forgery and replay. Is the root envelope bound tightly enough (purpose, id, region, issued_at)? Can any other root-signed payload be read as a db-read request, or the reverse? Does the seen set plus the 60 s window close a second run of one request? Does sealing really make a replay harmless?
4. Election and expiry. Can two boxes both run one read? Can the console's expiry and a late box both believe they own picked? Can a result land before its last chunk, or a chunk after the result?
5. Cleanup and disk. On every exit path (done, failed, cancel, CLI gone, agent restart, kill -9, box reboot, console restart), what is left in the deployment bucket and on the box? Is the disk floor enough on a 60 GiB box that also stages versions? Can the unacked window deadlock?
6. Parity. Will the forwarded --at stop at the same transaction as the in-region door for the same replica and time, given the second truncation of LastModified? Will the forwarded output be byte-identical to the in-region output across CLI and box versions?
7. Mixed fleet. Walk §9.2 and §11.2. Can a box publish db-read-1 without an armed worker? What does a host-claim console, a console with a scoped key, or a console with CARLOS_DB_FORWARD unset answer?
8. Census and build. Are §13's classifications right for the root-read scan as it is actually written (it matches Open, Query, QueryContext and more across all production packages)? Does the worker code cross-compile for darwin and windows as described?
9. Provider boundary. Does anything in the design need AWS to work on a MinIO deployment with one store per region?
10. Missing pieces. Anything the spec relies on that does not exist, or exists in a different shape.

Output

A numbered list of findings. Each one gives:

• severity: P1 breaks a ruling, crosses a tenant, or exposes box credentials; P2 is wrong behaviour; P3 is clarity or a gap;
• the spec section;
• the code evidence, with file:line;
• a concrete fix.

Then a one-line verdict: accept, or revise. Do not rewrite the spec. No praise.

On every round after the first, follow the answer format in the round section at the top.