carlos / platform Public

Clone
git clone https://amadan.net/carlos/platform

Plain git — no account needed to clone.

Download

Download this file

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.