# 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.