amadan
spec: phase 1 starts on the shared fleet, not a box Eleven owns
Paul, 2026-09-05: "Since Eleven is decentralised anyway, I think the first goal will be getting a running instance on https://console.carloku.com/a/eleven/ and then we go from here migrating the other apps." That reorders phase 1 rather than replacing it. The written phase 1 opens with infrastructure — port infra/dev-mesh into a new tofu root, stand up an EC2 box — and only then proves the product. But none of its five proofs need Eleven to own the box, and account eleven (bdr) has no fleet, so an app created in it lands on the shared Carloku fleet, which already runs. The tofu root, the AWS spend and the eleven/infrastructure repo all come off the critical path. Two findings recorded with the amendment, both from today: - The launch contract already matches exactly. CARLOS spawns an app as exec.Command(bin, "--socket", rt.Socket, "--db", dbPath) (backend_exec.go:691); Eleven spawns its instances with the identical line (messenger/activator.go:1218), because CARLOS's activator was ported from Eleven's. lchat needs no code change to be launched by a CARLOS box. - Verified by running it, not by reading it. lchat --socket X --db Y on an empty directory boots, creates its SQLite db, prints an admin link, and answers HTTP 200 with the app shell over the socket. No config, no environment. One mismatch found: carlos ship --target defaults to linux-arm64 and the shared fleet is Graviton, but the binary in Eleven's repo is lchat-linux-amd64. Phase 1 needs an arm64 build — a build-matrix line, not a design problem. Phase 1 is now step A (one instance on the shared fleet: proofs 1, 2, 3) and step B (the proving box, for the sidecar and hooks proofs that want a box Eleven controls).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NPZAr4Cvqr8enLymeNo2Qp
1 file changed,
+50
−0
docs/superpowers/specs/2026-08-29-eleven-carloku-migration-design.md+50 −0
diff --git a/docs/superpowers/specs/2026-08-29-eleven-carloku-migration-design.md b/docs/superpowers/specs/2026-08-29-eleven-carloku-migration-design.md| index f384c291a..700c8fce5 100644 |
| --- a/docs/superpowers/specs/2026-08-29-eleven-carloku-migration-design.md |
| +++ b/docs/superpowers/specs/2026-08-29-eleven-carloku-migration-design.md |
| @@ -130,6 +130,56 @@ A CARLOS-native Eleven, standing beside production and touching none of it. |
| Everything here is throwaway: a namespace nobody's keys are bound to, on a box |
| that can be destroyed and rebuilt. |
| +### Amended 2026-09-05 — phase 1 starts on the shared fleet, not a fresh box |
| + |
| +**Paul, 2026-09-05:** *"Since Eleven is decentralised anyway, I think the first |
| +goal will be getting a running instance on `https://console.carloku.com/a/eleven/` |
| +and then we go from here migrating the other apps."* |
| + |
| +This is a smaller and better first step than the box below, and it reorders |
| +phase 1 rather than replacing it. The original phase 1 opens with |
| +infrastructure — port `infra/dev-mesh` into a new tofu root, stand up an EC2 |
| +box, point it at `carlos agent` — and only then proves the product. But **none |
| +of phase 1's five proofs actually need Eleven to own the box.** Account |
| +`eleven` (`bdr`) has no fleet, so an app created in it lands on the **shared |
| +Carloku fleet**, which already exists and is already running. That defers the |
| +tofu root, the AWS spend and the `eleven/infrastructure` repo out of the |
| +critical path entirely. |
| + |
| +It also matches the product: Eleven is decentralised, one instance per space, |
| +so a single instance *is* a working Eleven — not a stub standing in for one. |
| +There is no all-at-once cutover to rehearse. |
| + |
| +**Two findings from 2026-09-05 that make this cheap:** |
| + |
| +1. **The launch contract already matches, exactly.** CARLOS spawns an app as |
| + `exec.Command(bin, "--socket", rt.Socket, "--db", dbPath)` |
| + (`internal/activator/backend_exec.go:691`). Eleven spawns its own instances |
| + as `exec.Command(bin, "--socket", rt.Socket, "--db", dbPath)` |
| + (`messenger/activator.go:1218`) — the same line, because CARLOS's activator |
| + was ported from Eleven's. `lchat` needs **no code change** to be launched by |
| + a CARLOS box. |
| + |
| +2. **Verified by running it.** `lchat --socket <path> --db <path>` on an empty |
| + directory boots, creates its SQLite database, prints an admin link, logs |
| + `lchat listening on unix:<path>`, and answers **HTTP 200** with the app |
| + shell over that socket. From nothing, with no config and no environment. |
| + |
| +**The one mismatch found: architecture.** `carlos ship --target` defaults to |
| +`linux-arm64` and the shared fleet is Graviton, but the binary committed to |
| +Eleven's repo is `lchat-linux-amd64`. Phase 1 needs an arm64 build. This is a |
| +build-matrix line, not a design problem. |
| + |
| +**So phase 1 now runs in two steps.** Step A — one instance on the shared |
| +fleet, which proves release delivery (proof 1), the manifest shape (proof 2) |
| +and that the product works on CARLOS (proof 3), with no infrastructure at all. |
| +Step B — the box below, which is still needed for the proofs step A cannot |
| +reach: sidecars (proof 4) and the disposition of `lchat router`'s hooks and |
| +links (proof 5), both of which want a box Eleven controls. Everything from |
| +"The infrastructure already exists in the right shape" onward is step B. |
| + |
| +### Step B — the proving box |
| + |
| **The infrastructure already exists in the right shape.** `infra/dev-mesh/` in |
| Eleven's repo is complete tofu for exactly this box — EC2 `t4g.small` arm64 |
| (commented as "the sizing floor for a node that runs a sidecar"), security |