Review brief: carlos run and seeded instances

You are an independent second reader of two design specs for the CARLOS platform (this repository). Read them cold and adversarially.

Specs: read both, at the commit named in the prompt:

• docs/superpowers/specs/2026-10-08-carlos-run-design.md (#259)
• docs/superpowers/specs/2026-10-08-seeded-instances-design.md (#260, #261)

Fixed rulings: do not re-argue them

§2 of each spec lists the rulings the product owner made on 2026-10-08. Do not propose alternatives to them. That includes:

• member-wide access;
• service credentials with the instance role on the seed doors;
• output as bucket chunks;
• uploads streaming through the console;
• the operator-account exception for the swap.

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 the code on main.

What to check

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

Instances and units:

• internal/host/units/carlos-instance-seed@.service and its two siblings;
• internal/instancectl/ (names.go, server.go /seed, client.go);
• internal/instanceexec/exec.go.

The activator:

• internal/activator/backend_exec.go: Restore, the staging fallback, seedUnit, seedVars, instanceEnv, nestedGate;
• prepare.go (writeLaunch);
• layout.go (Classify);
• claimwake.go;
• hibernation and the Quiesced and idle logic in activator.go.

The box:

• internal/host/restart.go: the serial and ETag pattern the run pickup copies;
• logship.go;
• agent.go: the serial poll.

The console:

• internal/console/apidb.go: dbGate, resolveReplica;
• internal/dbdoor/restore.go;
• apiinstances.go: handleAPIInstanceCreate;
• authcli.go: cliRoute;
• apicli.go: apiAccountApp, the ship size limits;
• server.go: audit helpers;
• apistatuslayout.go.

Provisioning, claims and storage:

• internal/provision/provision.go: Record, CreateRecord;
• reconcile.go: around lines 1140-1300, the "leave it alone" rule;
• the host claim: internal/hostclaim, internal/hostbox, internal/hostops/record.go;
• the moves protocol floor (moves_protocol);
• infra/modules/region-host/main.tf: what a box and the console may read and write;
• docs/superpowers/specs/2026-10-02-move-any-app-design.md: the claim and restore contract a new restore fallback must fit.

Questions worth your time

carlos run

1. Can a run reach anything beyond the instance's own reach? - Environment, files, the cmd unit's sandbox against the seed unit's. - The exe link the control service binds. - The output sockets. - .carlos-run/ inside the instance tree.
2. Data loss. Can the command's writes be lost, or can it write to a database nobody replicates? Look at: - hibernation during a run; - a move; - a host-claim handoff; - a restore that replaces the file under it; - the run hold as specified.
3. Pickup. Does "the box that owns the row" pick it up exactly once? Consider: - the claim on and off; - replica placements; - two boxes during a move; - a box restart mid-run; - the index ETag pattern against restart.go's seed-don't-replay rule.
4. Output. Ordering, the cap, cancel, timeout, ack and the sweep. Can a run be left open forever, or deleted while the CLI still follows it?

Seeded instances

1. The new restore fallback. Does it fit both the plain and the claim restore paths, as the move-any-app spec's generation and marker contract requires? Can a seeded instance ever come up empty, come up with the source's lineage, or replicate into the source's prefix?
2. The swap. Is a registry transaction plus a claim CAS, in that order, actually achievable in reconcile? Can it take a route that isn't the app's own? Does abort-after-swap restore the addr row exactly, and is "refused once it has served a non-verify request" observable by the platform at all?
3. Old boxes. Does the protocol-floor gate stop an old box minting a seeded record as an empty instance? Is there a window where it doesn't?
4. --from on the console. Disk, memory and time per restore; the claim read; residency; scratch cleanup on every exit path.
5. Missing pieces. Anything either spec relies on that doesn't exist, or exists in a different shape.

Output

A numbered list of findings. Each one gives:

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

Then a one-line verdict for each spec: accept, or revise. Don't rewrite the specs. No praise.

On a later round you'll be given your earlier findings files. Start with a disposition table (finding: fixed, declined with an acceptable reason, or not fixed), then give only new findings.