# Review brief: fleet-internal engines (#335)

You are an independent second reader of a design spec for the CARLOS
platform (this repository). Read it cold and adversarially.

**Spec:** `docs/superpowers/specs/2026-10-21-fleet-internal-engines-design.md`,
at the commit named in the prompt.

## What it claims

A registered doc engine's hostname is refused to every public request on
every box, and granted apps reach it through a per-instance unix socket (or
the edge-local door), relayed over the existing backhaul hop, which now
signs the caller. Read §2's anti-goals first: the spec fails if an engine
can become public again by accident, if a tenant can forge a caller, or if
an isolated instance's fence opens.

## What to check

Check against the code on `main`, not the spec's description of it. Cite
`file:line` for every claim about existing code.

- **The edge:** `internal/edge/edge.go` (`ServeHTTP`, `backhaul`,
  `backhaulTo`, `httpFallbackHandler`, `Allowed`, `unknownHost`, the
  cache path), `homemap.go` (`acceptHop`, `dialAddress`, `Owner`,
  `ExactHome`), `mesh.go` (hop MAC), `door.go`, `doorkeys.go`,
  `purge.go` / `purge_listen_unix.go` (`ListenControl`).
- **Instances:** `internal/activator/backend_exec.go` (launch env,
  `CARLOS_CONTROL_SOCKET`), `provision.go`, `prepare.go`,
  `generations.go`, `cmdunit.go`, `internal/host/units/carlos-instance*@.service`,
  `internal/instancectl/gen.go`, `internal/layout/preflight.go`.
- **Grants and records:** `internal/doorkey`, `internal/caps`,
  `internal/console/apistore.go` (store grant), `apisystemupdate.go`
  (`systemOperator`).

## Questions to answer

1. Can a public request reach a registered engine by any path: a spelling
   of the host, a wildcard route, the :80 handler, a door caller, a
   backhaul from an old box, the login re-resolution, an upgrade, the
   cache, a hibernating wake?
2. Can a tenant forge or borrow a caller identity: through headers, through
   another instance's socket, across generations, in the flat layout, via
   the door?
3. Does §6.3's "never reopens" hold across restarts, stale mirrors, revision
   rollback by a bucket writer, and `engines remove`?
4. Can the per-instance socket be built as described for every unit kind,
   within the 107-byte socket path limit, and is the "one socket per
   instance" claim true of the binds?
5. Does the hop extension stay compatible with boxes on the old build in
   both directions?
6. Anything §5.5's limits break (streaming, upgrades, long conversions).

## Output

Findings ranked P1 (spec fails a goal or anti-goal, or cannot be built), P2
(a real gap a builder would hit), P3 (worth fixing). For each: the section,
the failure scenario as concrete steps, the code citation, and a suggested
fix. End with an overall verdict: accept, accept with fixes, or reject.
Do not report wording or style.

## Round 2 and later

Read your previous findings (`CODEX-FINDINGS-ENGINES-R<n-1>.md`) and the
spec's §12 disposition table first. Start your answer with a table: each
previous finding, and whether the new revision actually fixes it (cite the
section). Then report only NEW findings.

§2.1's rulings are fixed: do not argue for registration-based internal
marking or for unit-backed callers. Report only a mechanism that fails to
honour a ruling, fails a goal or anti-goal, breaks something else in the
platform, or cannot be built against `main`. A mechanism the spec names,
bounds and assigns is complete at spec level; do not ask for plan-level
detail.