carlos / platform Public

rootfs apps: copy deck approved by delegation (Luna pass applied, 372 rows)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

claude 10 hours ago 4e33daea857da852e41ad230296365cce4341f63 parent 1db3264

8 files changed, +495 −491

docs/superpowers/plans/2026-10-24-rootfs-apps-0-index.md +1 −1
docs/superpowers/plans/2026-10-24-rootfs-apps-1-ship.md +89 −87
docs/superpowers/plans/2026-10-24-rootfs-apps-2-box-isolation.md +3 −3
docs/superpowers/plans/2026-10-24-rootfs-apps-3-lifecycle.md +1 −1
docs/superpowers/plans/2026-10-24-rootfs-apps-4-console-and-docs.md +16 −16
docs/superpowers/plans/2026-10-24-rootfs-apps-5-egress-allow.md +7 −7
docs/superpowers/plans/2026-10-24-rootfs-apps-6-interactive.md +3 −3
docs/superpowers/plans/2026-10-24-rootfs-apps-copy.md +375 −373

CI passed — run details

CI log

=== gate ===
.amadan/test-gate.sh
=== launchctx (0 s)
ok  	amadan.net/carlos/platform.git/launchctx	0.013s
?   	amadan.net/carlos/platform.git/launchctx/controlname	[no test files]
?   	amadan.net/carlos/platform.git/launchctx/wireid	[no test files]
=== vet (1 s)
=== gofmt (0 s)
gofmt -l .: clean
=== rest (146 s)
?   	github.com/carlosframework/platform/cmd/changelog	[no test files]
ok  	github.com/carlosframework/platform/cmd/console	3.821s
ok  	github.com/carlosframework/platform/cmd/moveprobe	11.964s
ok  	github.com/carlosframework/platform/cmd/zddprobe	0.749s
ok  	github.com/carlosframework/platform/internal/activator	60.022s
ok  	github.com/carlosframework/platform/internal/agentsock	0.027s
ok  	github.com/carlosframework/platform/internal/alerting	0.008s
ok  	github.com/carlosframework/platform/internal/analytics	0.020s
ok  	github.com/carlosframework/platform/internal/appconfig	2.993s
ok  	github.com/carlosframework/platform/internal/apperr	0.147s
ok  	github.com/carlosframework/platform/internal/applog	0.217s
ok  	github.com/carlosframework/platform/internal/awsinv	0.010s
ok  	github.com/carlosframework/platform/internal/boxchoice	0.008s
ok  	github.com/carlosframework/platform/internal/boxid	0.840s
?   	github.com/carlosframework/platform/internal/boxid/boxidtest	[no test files]
?   	github.com/carlosframework/platform/internal/boxid/internal/signtest	[no test files]
ok  	github.com/carlosframework/platform/internal/boxvolumes	0.009s
ok  	github.com/carlosframework/platform/internal/caps	0.018s
ok  	github.com/carlosframework/platform/internal/certwarm	0.006s
ok  	github.com/carlosframework/platform/internal/cgroup	0.786s
ok  	github.com/carlosframework/platform/internal/changelog	0.558s
ok  	github.com/carlosframework/platform/internal/claimactivation	1.240s
ok  	github.com/carlosframework/platform/internal/clamd	0.056s
?   	github.com/carlosframework/platform/internal/cliflag	[no test files]
?   	github.com/carlosframework/platform/internal/controlname	[no test files]
?   	github.com/carlosframework/platform/internal/controlsock	[no test files]
ok  	github.com/carlosframework/platform/internal/dbdoor	7.981s
ok  	github.com/carlosframework/platform/internal/dbdoor/dbdoortest	0.012s
ok  	github.com/carlosframework/platform/internal/dbquery	0.006s
ok  	github.com/carlosframework/platform/internal/dbreads	2.101s
?   	github.com/carlosframework/platform/internal/dbreads/dbreadstest	[no test files]
ok  	github.com/carlosframework/platform/internal/dbverify	0.005s
ok  	github.com/carlosframework/platform/internal/dnsrec	0.007s
ok  	github.com/carlosframework/platform/internal/docsite	0.007s
ok  	github.com/carlosframework/platform/internal/domains	2.953s
ok  	github.com/carlosframework/platform/internal/doorkey	0.012s
ok  	github.com/carlosframework/platform/internal/economics	0.005s
ok  	github.com/carlosframework/platform/internal/edge	45.609s
?   	github.com/carlosframework/platform/internal/edgeproof	[no test files]
ok  	github.com/carlosframework/platform/internal/edgesfile	0.010s
ok  	github.com/carlosframework/platform/internal/fleetapi	0.196s
ok  	github.com/carlosframework/platform/internal/gate	1.935s
ok  	github.com/carlosframework/platform/internal/genselect	0.017s
ok  	github.com/carlosframework/platform/internal/geo	0.020s
ok  	github.com/carlosframework/platform/internal/geoip	0.048s
ok  	github.com/carlosframework/platform/internal/historyreadback	0.315s
ok  	github.com/carlosframework/platform/internal/host	143.198s
ok  	github.com/carlosframework/platform/internal/hostactors	5.525s
ok  	github.com/carlosframework/platform/internal/hostactors/awsmembership	0.008s
ok  	github.com/carlosframework/platform/internal/hostbox	3.239s
ok  	github.com/carlosframework/platform/internal/hostclaim	0.862s
ok  	github.com/carlosframework/platform/internal/hostenv	0.006s
ok  	github.com/carlosframework/platform/internal/hostevidence	0.007s
ok  	github.com/carlosframework/platform/internal/hostexec	5.627s
ok  	github.com/carlosframework/platform/internal/hostfence	0.046s
ok  	github.com/carlosframework/platform/internal/hostfiles	10.281s
ok  	github.com/carlosframework/platform/internal/hostfloor	0.017s
ok  	github.com/carlosframework/platform/internal/hostguard	1.048s
ok  	github.com/carlosframework/platform/internal/hostops	2.250s
?   	github.com/carlosframework/platform/internal/hostops/fencerelease	[no test files]
ok  	github.com/carlosframework/platform/internal/hostops/internal/fencerelease	0.005s
ok  	github.com/carlosframework/platform/internal/hostquarantine	0.004s
ok  	github.com/carlosframework/platform/internal/hostrelocate	0.618s
ok  	github.com/carlosframework/platform/internal/hostresolve	0.199s
ok  	github.com/carlosframework/platform/internal/hostwrite	0.003s
ok  	github.com/carlosframework/platform/internal/infraview	0.005s
ok  	github.com/carlosframework/platform/internal/instancectl	5.237s
ok  	github.com/carlosframework/platform/internal/instanceexec	2.793s
ok  	github.com/carlosframework/platform/internal/instancefs	0.006s
ok  	github.com/carlosframework/platform/internal/instancekey	0.004s
ok  	github.com/carlosframework/platform/internal/instanceupdates	0.010s
ok  	github.com/carlosframework/platform/internal/layout	1.943s
ok  	github.com/carlosframework/platform/internal/lbhealth	0.004s
ok  	github.com/carlosframework/platform/internal/lease	10.118s
ok  	github.com/carlosframework/platform/internal/lease/leasetest	0.699s
ok  	github.com/carlosframework/platform/internal/ledger	0.031s
ok  	github.com/carlosframework/platform/internal/mail	0.222s
ok  	github.com/carlosframework/platform/internal/maintenance	0.087s
ok  	github.com/carlosframework/platform/internal/maintenanceexec	5.554s
ok  	github.com/carlosframework/platform/internal/maintenanceguard	0.087s
ok  	github.com/carlosframework/platform/internal/metrics	0.005s
ok  	github.com/carlosframework/platform/internal/moves	21.462s
ok  	github.com/carlosframework/platform/internal/moves/archive	1.130s
ok  	github.com/carlosframework/platform/internal/objstore	0.271s
ok  	github.com/carlosframework/platform/internal/ops	0.185s
ok  	github.com/carlosframework/platform/internal/park	0.300s
ok  	github.com/carlosframework/platform/internal/plans	0.006s
ok  	github.com/carlosframework/platform/internal/privatefile	0.004s
ok  	github.com/carlosframework/platform/internal/provision	14.694s
ok  	github.com/carlosframework/platform/internal/publicrelease	0.011s
?   	github.com/carlosframework/platform/internal/regionname	[no test files]
ok  	github.com/carlosframework/platform/internal/registry	5.687s
ok  	github.com/carlosframework/platform/internal/relay	7.228s
ok  	github.com/carlosframework/platform/internal/release	25.709s
ok  	github.com/carlosframework/platform/internal/rollout	3.818s
ok  	github.com/carlosframework/platform/internal/rolloutwords	0.003s
ok  	github.com/carlosframework/platform/internal/rootaws	0.007s
ok  	github.com/carlosframework/platform/internal/rootparticipation	0.061s
ok  	github.com/carlosframework/platform/internal/rootstate	0.027s
ok  	github.com/carlosframework/platform/internal/runs	0.549s
ok  	github.com/carlosframework/platform/internal/s3compat	0.005s
ok  	github.com/carlosframework/platform/internal/safefile	0.004s
ok  	github.com/carlosframework/platform/internal/schedule	2.711s
ok  	github.com/carlosframework/platform/internal/seeds	0.011s
ok  	github.com/carlosframework/platform/internal/sim/engines	2.884s
ok  	github.com/carlosframework/platform/internal/sim/hostlife	11.118s
ok  	github.com/carlosframework/platform/internal/sim/litestreamfacts	4.107s
ok  	github.com/carlosframework/platform/internal/status	0.111s
ok  	github.com/carlosframework/platform/internal/steering	0.007s
ok  	github.com/carlosframework/platform/internal/stopevidence	0.177s
ok  	github.com/carlosframework/platform/internal/svcrole	0.003s
ok  	github.com/carlosframework/platform/internal/telemetry	0.004s
ok  	github.com/carlosframework/platform/internal/termfence	0.004s
ok  	github.com/carlosframework/platform/internal/tunnelclient	0.005s
ok  	github.com/carlosframework/platform/internal/unixdial	0.006s
ok  	github.com/carlosframework/platform/internal/updatewords	0.005s
ok  	github.com/carlosframework/platform/internal/usage	0.006s
ok  	github.com/carlosframework/platform/internal/version	0.002s
ok  	github.com/carlosframework/platform/internal/vet	1.690s
=== internal_console@0 (87 s)
ok  	github.com/carlosframework/platform/internal/console	84.703s
=== internal_console@1 (44 s)
ok  	github.com/carlosframework/platform/internal/console	41.847s
=== internal_console@2 (42 s)
ok  	github.com/carlosframework/platform/internal/console	39.865s
=== internal_console@3 (41 s)
ok  	github.com/carlosframework/platform/internal/console	38.319s
=== internal_console@4 (42 s)
ok  	github.com/carlosframework/platform/internal/console	40.389s
=== internal_console@5 (41 s)
ok  	github.com/carlosframework/platform/internal/console	38.800s
=== internal_console@6 (37 s)
ok  	github.com/carlosframework/platform/internal/console	34.550s
=== internal_console@7 (46 s)
ok  	github.com/carlosframework/platform/internal/console	43.787s
=== root@0 (110 s)
ok  	github.com/carlosframework/platform	107.892s
=== root@1 (84 s)
ok  	github.com/carlosframework/platform	82.373s
=== root@2 (92 s)
ok  	github.com/carlosframework/platform	89.836s
=== cross ===
--- shard 0 of 5 ---
cross-compiling darwin/arm64
--- shard 1 of 5 ---
cross-compiling darwin/amd64
--- shard 2 of 5 ---
cross-compiling linux/arm64
linux/arm64 carlos binary: 50528418 bytes (ceiling 52000000)
--- shard 3 of 5 ---
cross-compiling windows/amd64
--- shard 4 of 5 ---
cross-compiling windows/arm64
=== minio-contract ===
minio contract: arm64, minio RELEASE.2025-09-07T16-13-09Z, mc RELEASE.2025-08-13T08-35-41Z
  minio: cached, digest verified
  mc: cached, digest verified
  minio healthy on 127.0.0.1:20999
Added `local` successfully.
Bucket created successfully `local/contract-bucket`.
Bucket created successfully `local/denied-bucket`.
Created policy `contract-only` successfully.
Added user `scopeduser` successfully.
Attached Policies: [contract-only]
To User: scopeduser
  buckets and scoped user ready
=== RUN   TestDeliveredContractMinio
=== RUN   TestDeliveredContractMinio/put
=== RUN   TestDeliveredContractMinio/get_round-trips_the_body
=== RUN   TestDeliveredContractMinio/list_shows_the_key
=== RUN   TestDeliveredContractMinio/head_and_list_agree_on_the_version
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_its_own_object
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_its_own_object/not_by_PutObjectTagging
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_its_own_object/and_not_by_x-amz-tagging_on_upload
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/not_by_CreateMultipartUpload
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/not_by_CopyObject_with_a_REPLACE_tagging_directive
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/but_multipart_itself_is_allowed
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/and_copy_itself_is_allowed
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/a_POST-policy_forged_tag_with_a_matching_version_is_still_not_a_verdict
=== RUN   TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/and_an_ordinary_tagged-with-something-else_upload_is_allowed
=== RUN   TestDeliveredContractMinio/delete_removes_it
=== RUN   TestDeliveredContractMinio/cross-bucket_denial
--- PASS: TestDeliveredContractMinio (0.02s)
    --- PASS: TestDeliveredContractMinio/put (0.00s)
    --- PASS: TestDeliveredContractMinio/get_round-trips_the_body (0.00s)
    --- PASS: TestDeliveredContractMinio/list_shows_the_key (0.00s)
    --- PASS: TestDeliveredContractMinio/head_and_list_agree_on_the_version (0.00s)
    --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_its_own_object (0.00s)
        --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_its_own_object/not_by_PutObjectTagging (0.00s)
        --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_its_own_object/and_not_by_x-amz-tagging_on_upload (0.00s)
    --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route (0.01s)
        --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/not_by_CreateMultipartUpload (0.00s)
        --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/not_by_CopyObject_with_a_REPLACE_tagging_directive (0.00s)
        --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/but_multipart_itself_is_allowed (0.00s)
        --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/and_copy_itself_is_allowed (0.00s)
        --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/a_POST-policy_forged_tag_with_a_matching_version_is_still_not_a_verdict (0.00s)
        --- PASS: TestDeliveredContractMinio/the_app_cannot_tag_by_any_other_route/and_an_ordinary_tagged-with-something-else_upload_is_allowed (0.00s)
    --- PASS: TestDeliveredContractMinio/delete_removes_it (0.00s)
    --- PASS: TestDeliveredContractMinio/cross-bucket_denial (0.00s)
PASS
ok  	github.com/carlosframework/platform/internal/objstore	0.024s
=== RUN   TestT4StorageProbeMinio
2026/10/24 19:52:59 moves: T4: STORE: list: operation error S3: ListObjectsV2, https response error StatusCode: 403, RequestID: 18E18F33D024C768, HostID: 7c420053e0fbcd7f41653fdd92ffa2802c903d05303b1aa15adc2e8bb65d183f, api error SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.
--- PASS: TestT4StorageProbeMinio (0.01s)
PASS
ok  	github.com/carlosframework/platform/internal/host	0.022s
=== RUN   TestS3StoreMinioContract
=== RUN   TestS3StoreMinioContract/conditional_get_and_etag_listing
=== RUN   TestS3StoreMinioContract/bump_through_every_mutation_path
--- PASS: TestS3StoreMinioContract (0.03s)
    --- PASS: TestS3StoreMinioContract/conditional_get_and_etag_listing (0.01s)
    --- PASS: TestS3StoreMinioContract/bump_through_every_mutation_path (0.02s)
PASS
ok  	github.com/carlosframework/platform/internal/release	0.033s
Bucket created successfully `local/dbf-deploy`.
Bucket created successfully `local/dbf-data-ie`.
Bucket created successfully `local/dbf-data-uk`.
local/dbf-deploy versioning is enabled
Created policy `dbf-console` successfully.
Created policy `dbf-ukbox` successfully.
Added user `dbfconsole` successfully.
Added user `dbfukbox` successfully.
Attached Policies: [dbf-console]
To User: dbfconsole
Attached Policies: [dbf-ukbox]
To User: dbfukbox
=== RUN   TestDBForwardMinio
2026/10/24 19:53:01 INFO replica sync system=store db=source.db replica=file txid.replica=0000000000000000 txid.db=0000000000000001
2026/10/24 19:53:01 INFO ltx file uploaded system=store db=source.db replica=file level=0 minTXID=0000000000000001 maxTXID=0000000000000001 size=720
2026/10/24 19:53:01 INFO replica sync system=store db=source.db replica=file txid.replica=0000000000000001 txid.db=0000000000000001
2026/10/24 19:53:01 INFO replica sync system=store db=source.db replica=file txid.replica=0000000000000001 txid.db=0000000000000002
2026/10/24 19:53:01 INFO ltx file uploaded system=store db=source.db replica=file level=0 minTXID=0000000000000002 maxTXID=0000000000000002 size=370
2026/10/24 19:53:01 INFO replica sync system=store db=source.db replica=file txid.replica=0000000000000002 txid.db=0000000000000002
2026/10/24 19:53:01 INFO replica sync system=store db=source.db replica=file txid.replica=0000000000000002 txid.db=0000000000000003
2026/10/24 19:53:01 INFO ltx file uploaded system=store db=source.db replica=file level=0 minTXID=0000000000000003 maxTXID=0000000000000003 size=454
2026/10/24 19:53:01 INFO replica sync system=store db=source.db replica=file txid.replica=0000000000000003 txid.db=0000000000000003
2026/10/24 19:53:01 INFO replica sync system=store db=source.db replica=file txid.replica=0000000000000000 txid.db=0000000000000001
2026/10/24 19:53:01 INFO ltx file uploaded system=store db=source.db replica=file level=0 minTXID=0000000000000001 maxTXID=0000000000000001 size=720
2026/10/24 19:53:01 INFO replica sync system=store db=source.db replica=file txid.replica=0000000000000001 txid.db=0000000000000001
2026/10/24 19:53:01 console: CARLOS_SECRETS_PUBKEY is unset, so no region outside the home can be chosen automatically
2026/10/24 19:53:01 console: could not notify member@example.com of a CLI token issue: keymail: lookup member@example.com: keymail: GET /api/federation/lookup?addr=member%40example.com&from=console%40127.0.0.1%3A41181: could not determine target mailbox
    agent.go:135: dbreads: dbr_rl7cw2yweqk6vewtuobqpbgvca: planned 3 files (1544 bytes) and restored to 3 in 10ms
    agent.go:135: dbreads: dbr_rl7cw2yweqk6vewtuobqpbgvca: output 5 bytes in 1 confirmed chunks in 1ms
2026/10/24 19:53:02 console: db read dbr_rl7cw2yweqk6vewtuobqpbgvca: relayed 1 chunks (102 bytes) in 1.004s, ended done
    agent.go:135: dbreads: dbr_xhfivwdhkzv336obzcltulzvpu: planned 1 files (720 bytes) and restored to 1 in 8ms
    agent.go:135: dbreads: dbr_xhfivwdhkzv336obzcltulzvpu: output 5 bytes in 1 confirmed chunks in 1ms
2026/10/24 19:53:03 console: db read dbr_xhfivwdhkzv336obzcltulzvpu: relayed 1 chunks (102 bytes) in 1.003s, ended done
    agent.go:135: dbreads: dbr_tbiwvodpruxptgzz5m5nhv2he4: planned 3 files (1544 bytes) and held through 3 in 10ms
    agent.go:135: dbreads: dbr_tbiwvodpruxptgzz5m5nhv2he4: output 1544 bytes in 1 confirmed chunks in 1ms
2026/10/24 19:53:04 console: db read dbr_tbiwvodpruxptgzz5m5nhv2he4: relayed 1 chunks (1641 bytes) in 1.004s, ended done
=== RUN   TestDBForwardMinio/by_disconnect
=== NAME  TestDBForwardMinio
    agent.go:135: dbreads: dbr_rilrk4qbj64ilai7krxhm76j6i: planned 3 files (1544 bytes) and restored to 3 in 9ms
2026/10/24 19:53:04 console: db read dbr_rilrk4qbj64ilai7krxhm76j6i: relayed 0 chunks (0 bytes) in 13ms, ended client gone
    agent.go:135: dbreads: dbr_rilrk4qbj64ilai7krxhm76j6i: output 5 bytes in 1 confirmed chunks in 19ms
=== RUN   TestDBForwardMinio/by_timeout
=== NAME  TestDBForwardMinio
    agent.go:135: dbreads: dbr_txlu2ca5biqa6673tgdy4fvzu4: planned 3 files (1544 bytes) and restored to 3 in 9ms
2026/10/24 19:53:25 console: db read dbr_txlu2ca5biqa6673tgdy4fvzu4: relayed 0 chunks (0 bytes) in 19.982s, ended no-result
    agent.go:135: dbreads: dbr_txlu2ca5biqa6673tgdy4fvzu4: output 5 bytes in 1 confirmed chunks in 19.958s
--- PASS: TestDBForwardMinio (23.34s)
    --- PASS: TestDBForwardMinio/by_disconnect (0.14s)
    --- PASS: TestDBForwardMinio/by_timeout (20.09s)
PASS
ok  	github.com/carlosframework/platform/internal/console	23.357s
minio contract: PASS

diff --git a/docs/superpowers/plans/2026-10-24-rootfs-apps-0-index.md b/docs/superpowers/plans/2026-10-24-rootfs-apps-0-index.md

index 8c873a582..a906ac561 100644

--- a/docs/superpowers/plans/2026-10-24-rootfs-apps-0-index.md

+++ b/docs/superpowers/plans/2026-10-24-rootfs-apps-0-index.md

@@ -23,7 +23,7 @@ plans cite the section beside the task that answers it.

**Copy:** every user-facing string of the series goes in one deck,

`2026-10-24-rootfs-apps-copy.md`, assembled from the string tables each plan

carries (IDs `RFS-<plan>-C<nn>`). Plan 1 Task 1 puts the gate in place and

-gets Paul's review before any task writes a string. Copy voice: no em

+gets Paul's review before any task writes a string (the deck was approved by delegation on 2026-10-24). Copy voice: no em

dashes; neutral names only (`shop`, `example.com`), never a tenant's, in

tests too. IDs match `^RFS-[1-6]-C(0[1-9]|[1-9][0-9]{1,2})$`: two digits

to C99, three from C100 (Plan 4 runs to C138), no leading zero (so Plan 2's

diff --git a/docs/superpowers/plans/2026-10-24-rootfs-apps-1-ship.md b/docs/superpowers/plans/2026-10-24-rootfs-apps-1-ship.md

index 869ba7d77..9f951d140 100644

--- a/docs/superpowers/plans/2026-10-24-rootfs-apps-1-ship.md

+++ b/docs/superpowers/plans/2026-10-24-rootfs-apps-1-ship.md

@@ -57,7 +57,7 @@ None renames or changes a contract name. These are additions the later plans mus

## Global Constraints

-- Every user-facing string (CLI output, refusals, flag help, console messages) is copy-reviewed by Paul before it is written into code. The deck is `docs/superpowers/plans/2026-10-24-rootfs-apps-copy.md`; its gate is `approved_rootfs_copy_test.go` (Task 1). A task uses only approved rows from this plan's table (RFS-1-C01 to RFS-1-C85) and adds their ids to `rootfsCopyBuilt` in the same commit. Texts in the tests below are the pending texts; write Paul's approved text instead.

+- Every user-facing string (CLI output, refusals, flag help, console messages) is copy-reviewed by Paul before it is written into code. The deck is `docs/superpowers/plans/2026-10-24-rootfs-apps-copy.md`; its gate is `approved_rootfs_copy_test.go` (Task 1). A task uses only approved rows from this plan's table (RFS-1-C01 to RFS-1-C85) and adds their ids to `rootfsCopyBuilt` in the same commit. The deck was approved by delegation on 2026-10-24 (Paul asked for a Luna copy pass instead of a string-by-string review), and the texts in this plan's table and tests are the approved texts.

- A deck string appears in Go as one string literal, or one `fmt.Sprintf`/`fmt.Errorf`/`errors.New` format, equal to the row with `%s`/`%d`/`%q` where the row has a `<placeholder>`, no trailing newline inside the literal.

- Copy voice: no em dashes (a full stop and a new sentence, lower case after it). Neutral names only: `shop`, `example.com`, `bab` for the ops account in tests. Never a tenant's name, in tests too.

- Wire shapes are additive (AGENTS.md): the new manifest fields and meta keys are `omitempty`; a binary or static manifest marshals byte for byte as before.

@@ -127,91 +127,91 @@ Placeholders: `<app>` an app name; `<name>` a process name; `<var>` an environme

|---|---|---|---|

-| RFS-1-C18 | internal/release/rootfs_ship.go | <app> ships <kind> releases (<version> is one), so it cannot take a rootfs release. Ship rootfs releases to an app of their own, made with carlos apps create. | pending |

-| RFS-1-C34 | ship_rootfs.go | usage: carlos ship --app <a> --rootfs <image-or-dir> --processes <file.json> [--hibernate] [--jit] [--version <sha>] [--label <one line>] [--notes <text> \| --notes-file <file>] [--swap hold] [--account <sqid-or-name>] [--account-id <sqid>] [--console <origin>]\n carlos ship --rootfs <image-or-dir> --processes <file.json> [--hibernate] [--jit] --check | pending |

-| RFS-1-C48 | internal/rootfsimage/errors.go | the <name> process runs <command>, which the image does not have. Commands are looked up in the process's PATH, or from its working_dir when they contain a slash. | pending |

-| RFS-1-C76 | ship_check_probe.go | --check needs a linux build of carlos to probe the socket from inside the container, and this one is a development build. Use a released carlos, or set CARLOS_CHECK_PROBE to a linux carlos binary. | pending |

-| RFS-1-C80 | internal/release/rootfs_ship.go | <app>'s first ship, <version>, made it an app for <kind> releases, so it cannot take a rootfs release. Ship rootfs releases to an app of their own, made with carlos apps create. | pending |

-| RFS-1-C82 | internal/release/rootfs_ship.go | <app>'s first ship, <version>, made its rootfs releases always on, so this release cannot opt into hibernation. Ship it without --hibernate, or use a new app. | pending |

+| RFS-1-C18 | internal/release/rootfs_ship.go | <app> ships <kind> releases (<version> is one), so it cannot take a rootfs release. ship rootfs releases to an app of their own, made with carlos apps create | approved |

+| RFS-1-C34 | ship_rootfs.go | usage: carlos ship --app <a> --rootfs <image-or-dir> --processes <file.json> [--hibernate] [--jit] [--version <sha>] [--label <one line>] [--notes <text> \| --notes-file <file>] [--swap hold] [--account <sqid-or-name>] [--account-id <sqid>] [--console <origin>]\n carlos ship --rootfs <image-or-dir> --processes <file.json> [--hibernate] [--jit] --check | approved |

+| RFS-1-C48 | internal/rootfsimage/errors.go | the <name> process runs <command>, which the image does not have. commands are looked up in the process's PATH, or from its working_dir when they contain a slash | approved |

+| RFS-1-C76 | ship_check_probe.go | --check needs a linux build of carlos to probe the socket from inside the container, and this one is a development build. use a released carlos, or set CARLOS_CHECK_PROBE to a linux carlos binary | approved |

+| RFS-1-C80 | internal/release/rootfs_ship.go | <app>'s first ship, <version>, made it an app for <kind> releases, so it cannot take a rootfs release. ship rootfs releases to an app of their own, made with carlos apps create | approved |

+| RFS-1-C82 | internal/release/rootfs_ship.go | <app>'s first ship, <version>, made its rootfs releases always on, so this release cannot opt into hibernation. ship it without --hibernate, or use a new app | approved |

RFS-1-C78's `<digest>` is a `sha256:<hex>` digest. RFS-1-C80 to C83 are the first-ship forms of C18 to C21: the app has no other release, and its kind marker (deviation 10) names the ship that fixed its kind, which may not have published, so they never say "is one". RFS-1-C85 is a warning: it does not fail the check. Kept out of the table on purpose (diagnostics, not human text): the probe's one-line JSON on stdout, `validateManifest`'s existing terse messages, store errors wrapped for logs.

@@ -341,6 +341,8 @@ Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>"

- [ ] **Step 4: Paul's copy review**

+Note: the deck was approved by delegation on 2026-10-24 (Paul asked for a Luna copy pass instead of a string-by-string review; see the deck header), so the gate's approval step is satisfied. Do not launch the review again for this deck; Step 5's edits are already applied and every row is `approved`, so skip to the Run line under Step 5. A row added after 2026-10-24 still goes through the review.

Invoke the `copy-review` skill with every live row of the deck (every row not `struck`; none is at this point), grouped by plan and, within this plan, by the file column, with the placeholder key above as context. Paul reviews the whole series in one pass. **Stop here until Paul has submitted the review.** Read the review's `result.json` before restarting the review server for any reason: a relaunch deletes it.

- [ ] **Step 5: Apply the review verbatim**

@@ -429,7 +431,7 @@ func TestValidateProcesses(t *testing.T) {

{"empty command", map[string]Process{"web": {}}, "the web process needs a command"},

{"empty first word", map[string]Process{"web": {Command: []string{"", "x"}}}, "the web process needs a command"},

{"bad env name", map[string]Process{"web": {Command: web.Command, Env: map[string]string{"1X": "y"}}}, `the web process sets "1X" in env, which is not a variable name`},

- {"platform env", map[string]Process{"web": {Command: web.Command, Env: map[string]string{"CARLOS_DB": "/x"}}}, "the web process sets CARLOS_DB in env. Names that start with CARLOS_"},

+ {"platform env", map[string]Process{"web": {Command: web.Command, Env: map[string]string{"CARLOS_DB": "/x"}}}, "the web process sets CARLOS_DB in env. names that start with CARLOS_"},

{"relative dir", map[string]Process{"web": {Command: web.Command, WorkingDir: "app"}}, `the web process's working_dir must be an absolute path, and "app" is not`},

{"unclean dir", map[string]Process{"web": {Command: web.Command, WorkingDir: "/app/../x"}}, "the web process's working_dir must be an absolute path"},

{"timeout on web", map[string]Process{"web": {Command: web.Command, TimeoutSec: 5}}, "only the release process takes timeout_sec"},

diff --git a/docs/superpowers/plans/2026-10-24-rootfs-apps-2-box-isolation.md b/docs/superpowers/plans/2026-10-24-rootfs-apps-2-box-isolation.md

index 189f6d4f9..96b2071d2 100644

--- a/docs/superpowers/plans/2026-10-24-rootfs-apps-2-box-isolation.md

+++ b/docs/superpowers/plans/2026-10-24-rootfs-apps-2-box-isolation.md

@@ -78,7 +78,7 @@ Each is decided here, once, and should be copied into the index's "Where the cod

- The index's names, exactly: `Kind == "rootfs"`, artifact key `"rootfs-linux-arm64"`, `release.ProcessWeb`, `ProcessRelease`, `ProcessConsole`, `release.ValidWorkerName`, `Manifest.Processes map[string]Process`, `Process{Command, Env, WorkingDir, TimeoutSec}`, `instancectl.RoleWorker`, `WorkerInstance`, `ParseWorkerInstance`, `host.RootfsPlacementAllowed(f RootfsBoxFacts, rt registry.Route) error` with its two halves `host.RootfsBoxReady(f RootfsBoxFacts) error` and `host.OwnBoxAllowed(f RootfsBoxFacts, rt registry.Route) error` (deviation 7), `rootfs_ready`, `CARLOS_DEPLOYMENT_SINGLE_TENANT`, templates `carlos-instance-rootfs@.service`, `carlos-instance-rootfs-gen@.service`, `carlos-instance-rootfs-worker@.service`, `carlos-instance-rootfs-cmd@.service`, `carlos-instance-rootfs-probe.service`.

- Health bound for a rootfs `web`: 120 s (`rootfsHealthTimeout`, Task 9, initialised from Plan 1's `release.RootfsHealthTimeout`). Memory tier for a rootfs row: `cgroup.TierChildren`, 1 GiB (R9, deviation 9). `MemoryDenyWriteExecute=yes` stays in the shared block and in both probes; only a release whose root-staged manifest says `"jit": true` runs without it, through a per-start drop-in root writes and checks (R11, spec §5.11, C10; Task 5).

- The box's own addresses are denied for every nested unit, binary and rootfs: `IPAddressDeny=` on `carlos-instances.slice` from `localPrefixes`, in place before the first start and before `rootfs_ready` (Task 7a, spec §5.9, C6, amadan #367). Systemd merges a unit's lists with its slices' and an allow wins, so nothing in this plan or Plan 5 may render an allow that contains a box address.

-- Copy: every human-readable string this plan introduces is in the string table at the end (IDs `RFS-2-C01` onward); no em dashes; neutral names only (`shop`, `shop.example.com`, `blog.example.com`); nothing is written into a file until the copy deck `2026-10-24-rootfs-apps-copy.md` has Paul's review (Plan 1 Task 1's gate).

+- Copy: every human-readable string this plan introduces is in the string table at the end (IDs `RFS-2-C01` onward); no em dashes; neutral names only (`shop`, `shop.example.com`, `blog.example.com`); nothing is written into a file until the copy deck `2026-10-24-rootfs-apps-copy.md` has Paul's review (Plan 1 Task 1's gate; the deck was approved by delegation on 2026-10-24 (Paul asked for a Luna copy pass instead of a string-by-string review; see the deck header), so the gate's approval step is satisfied).

- Unit files are the source of truth in `internal/host/units/`, embedded by `bootstrap.go:36`'s glob; nothing is applied by drop-in except the per-start runtime drop-ins the control service already writes for generation units (`internal/instancectl/gen.go:41`).

- Production-wired witnesses: refusal and launch tests go through `ExecBackend.Start`, the control service's HTTP handlers and the trampoline's `execLaunch`, never through a fixture that re-implements the rule.

- Commit after every task with the session's attribution trailer. Never push to `main`; land through amadan (AGENTS.md).

@@ -3090,8 +3090,8 @@ Human-readable text this plan introduces, for the series copy deck. Diagnostics,

|---|---|---|

| RFS-2-C01 | `RootfsPlacementAllowed`, flat or not nested-ready; the activator's flat-row refusal | rootfs instances need nested isolation, and this box does not have it yet |

| RFS-2-C02 | `RootfsPlacementAllowed`, probe not passed; the control service's 503 | this box has not passed the rootfs isolation probe on this boot (<check>) |

-| RFS-2-C03 | `RootfsPlacementAllowed`, platform box | rootfs instances run only on a customer's own boxes. This box is shared: it is not a fleet box and the deployment is not single-tenant |

-| RFS-2-C12 | `RootfsPlacementAllowed`, platform box serving a pool | rootfs instances run only on a customer's own boxes. A dedicated pool (<pool>) does not make this box one customer's |

+| RFS-2-C03 | `RootfsPlacementAllowed`, platform box | rootfs instances run only on a customer's own boxes. this box is shared: it is not a fleet box and the deployment is not single-tenant |

+| RFS-2-C12 | `RootfsPlacementAllowed`, platform box serving a pool | rootfs instances run only on a customer's own boxes. a dedicated pool (<pool>) does not make this box one customer's |

| RFS-2-C04 | `RootfsPlacementAllowed`, fleet owner unknown or unreadable | this fleet box cannot confirm which account owns its fleet, so it will not start a rootfs instance |

| RFS-2-C05 | `RootfsPlacementAllowed`, another account | this instance belongs to an account that does not own this fleet |

| RFS-2-C06 | `RootfsPlacementAllowed`, claim armed | rootfs instances are not started under host lifecycle claim control yet, and this box has it armed |

diff --git a/docs/superpowers/plans/2026-10-24-rootfs-apps-3-lifecycle.md b/docs/superpowers/plans/2026-10-24-rootfs-apps-3-lifecycle.md

index c160ece7b..479238c72 100644

--- a/docs/superpowers/plans/2026-10-24-rootfs-apps-3-lifecycle.md

+++ b/docs/superpowers/plans/2026-10-24-rootfs-apps-3-lifecycle.md

@@ -138,7 +138,7 @@ Plan 1 Task 1 assembles every plan's table into the series deck and gets Paul's

- [ ] **Step 1:** `grep -c '^| RFS-3-' docs/superpowers/plans/2026-10-24-rootfs-apps-copy.md`. Expected: 29, every one `approved`. If so, skip to Step 4 with nothing to commit.

- [ ] **Step 2:** For each row of this plan's table the deck lacks (a row added after the series review), append it in the deck's format, status `pending`, add its id to `rootfsCopyIDs`, and run `go test . -run 'TestRootfsCopy' -count=1` (PASS).

-- [ ] **Step 3:** Invoke the `copy-review` skill on those rows only, wait for Paul's edits, apply them verbatim to the deck and to this plan's string table, and mark each row `approved`. Read `result.json` before any restart of the review server.

+- [ ] **Step 3:** (Note: the deck was approved by delegation on 2026-10-24 (Paul asked for a Luna copy pass instead of a string-by-string review; see the deck header), so the gate's approval step is satisfied; this step is for rows added after that date.) Invoke the `copy-review` skill on those rows only, wait for Paul's edits, apply them verbatim to the deck and to this plan's string table, and mark each row `approved`. Read `result.json` before any restart of the review server.

- [ ] **Step 4:** Run the gate again (PASS); commit the deck and the gate if Step 2 changed them.

```bash

diff --git a/docs/superpowers/plans/2026-10-24-rootfs-apps-4-console-and-docs.md b/docs/superpowers/plans/2026-10-24-rootfs-apps-4-console-and-docs.md

index 71da1b436..383ff4544 100644

--- a/docs/superpowers/plans/2026-10-24-rootfs-apps-4-console-and-docs.md

+++ b/docs/superpowers/plans/2026-10-24-rootfs-apps-4-console-and-docs.md

@@ -1174,17 +1174,17 @@ Placeholders: `<app>` an app; `<fleet>` a fleet name; `<region>` a region's name

| id | text |

|---|---|

-| RFS-4-C01 | `<app> is a rootfs app, and a rootfs app runs only on boxes your account owns. place it on one of your fleets first with carlos apps place.` |

-| RFS-4-C02 | `<app> is a rootfs app, and a rootfs app does not run in a dedicated pool yet. create the instance without a pool.` |

-| RFS-4-C03 | `<app> is a rootfs app, so it cannot move to the shared boxes. a rootfs app runs only on boxes your account owns.` |

-| RFS-4-C04 | `<app> is a rootfs app with instances, and a rootfs app's instances cannot move to other boxes yet. delete its instances first, or create a new app where you want it to run.` |

-| RFS-4-C05 | `none of fleet <fleet>'s boxes can run a rootfs app yet. a box can once it runs a platform release with rootfs support, on the nested layout, and has passed its rootfs check.` |

-| RFS-4-C06 | `no box in <region> can run a rootfs app yet. a box can once it runs a platform release with rootfs support, on the nested layout, and has passed its rootfs check.` |

-| RFS-4-C07 | `could not check which boxes can run a rootfs app. try again.` |

-| RFS-4-C08 | `could not read this app's releases. try again.` |

-| RFS-4-C09 | `<app> is a rootfs app, and a new rootfs instance cannot start from a copy of another database yet. create it empty, then load the data from your app.` |

-| RFS-4-C10 | `<app> is a rootfs app, and a rootfs app has no replicas yet.` |

-| RFS-4-C11 | `<app> already has <n> instances made before its first release, such as <host>. an app's first release decides its kind, and those instances were made for a binary app. delete them, ship again, then create them again.` |

+| RFS-4-C01 | `<app> is a rootfs app, and a rootfs app runs only on boxes your account owns. place it on one of your fleets first with carlos apps place` |

+| RFS-4-C02 | `<app> is a rootfs app, and a rootfs app does not run in a dedicated pool yet. create the instance without a pool` |

+| RFS-4-C03 | `<app> is a rootfs app, so it cannot move to the shared boxes. a rootfs app runs only on boxes your account owns` |

+| RFS-4-C04 | `<app> is a rootfs app with instances, and a rootfs app's instances cannot move to other boxes yet. delete its instances first, or create a new app where you want it to run` |

+| RFS-4-C05 | `none of fleet <fleet>'s boxes can run a rootfs app yet. a box can once it runs a platform release with rootfs support, on the nested layout, and has passed its rootfs check` |

+| RFS-4-C06 | `no box in <region> can run a rootfs app yet. a box can once it runs a platform release with rootfs support, on the nested layout, and has passed its rootfs check` |

+| RFS-4-C07 | `could not check which boxes can run a rootfs app. try again` |

+| RFS-4-C08 | `could not read this app's releases. try again` |

+| RFS-4-C09 | `<app> is a rootfs app, and a new rootfs instance cannot start from a copy of another database yet. create it empty, then load the data from your app` |

+| RFS-4-C10 | `<app> is a rootfs app, and a rootfs app has no replicas yet` |

+| RFS-4-C11 | `<app> already has <n> instances made before its first release, such as <host>. an app's first release decides its kind, and those instances were made for a binary app. delete them, ship again, then create them again` |

### CLI (instances_rootfs.go, instances_cli.go)

@@ -1196,8 +1196,8 @@ Placeholders: `<app>` an app; `<fleet>` a fleet name; `<region>` a region's name

| RFS-4-C15 | `rootfs` |

| RFS-4-C16 | `rootfs, hibernates` |

| RFS-4-C17 | `<running>/<total>, <name> restarting` |

-| RFS-4-C18 | `rootfs, always on. it starts as soon as its box picks it up, and does not wait for a request.` |

-| RFS-4-C19 | `rootfs, hibernates when idle.` |

+| RFS-4-C18 | `rootfs, always on. it starts as soon as its box picks it up, and does not wait for a request` |

+| RFS-4-C19 | `rootfs, hibernates when idle` |

### The sample app (examples/rails-shop)

@@ -1220,7 +1220,7 @@ Placeholders: `<app>` an app; `<fleet>` a fleet name; `<region>` a region's name

|---|---|

| RFS-4-C30 | `Rootfs apps` |

| RFS-4-C31 | `A rootfs app is an app shipped as a read-only Linux image instead of a single binary. You build the image on your own machine, from a Dockerfile or anything else that makes an OCI image or a directory, and carlos ship --rootfs uploads it. The platform never builds anything and never pulls from a registry.` (fact) |

-| RFS-4-C32 | `A rootfs app runs only on boxes your account owns: a fleet of yours on a deployment that runs apps for other people, such as Carloku, or any box of a deployment run for one customer. The box must be on the nested layout and must have passed its rootfs check. The console refuses anywhere else, and so does the box.` |

+| RFS-4-C32 | `A rootfs app runs only on boxes your account owns: a fleet of yours on a deployment that runs apps for other people, or any box of a deployment run for one customer. The box must be on the nested layout and must have passed its rootfs check. The console refuses anywhere else, and so does the box.` |

| RFS-4-C33 | `What fixes an app's kind` |

| RFS-4-C34 | `An app's first release makes it a binary app or a rootfs app, and it stays that kind. A release of the other kind is refused when you ship it. To change kinds, create a new app.` |

| RFS-4-C35 | `Each instance takes its hibernation setting from the release it is created with, and keeps it. A rootfs app is always on unless that release was shipped with carlos ship --hibernate. A later release that asks for the other setting is refused when you ship it.` (fact, D4) |

@@ -1261,7 +1261,7 @@ Placeholders: `<app>` an app; `<fleet>` a fleet name; `<region>` a region's name

|---|---|

| RFS-4-C63 | `Run a Rails app on your own boxes` |

| RFS-4-C64 | `This guide takes a Rails 8 app from a Dockerfile to a running instance on boxes your account owns. The app runs from a read-only image you build on your own machine. Its web process and its job worker share one SQLite database, which the platform replicates, and uploads go to the app's own bucket.` |

-| RFS-4-C65 | `You need Docker with buildx, the carlos CLI signed in to your console, and a fleet with at least one box. On a deployment that runs apps for other people, such as Carloku, a rootfs app runs only on a fleet your account owns. [carlos fleets](/docs/cli#carlos-fleets) sets one up, and [Rootfs apps](/docs/rootfs) has the full contract.` |

+| RFS-4-C65 | `You need Docker with buildx, the carlos CLI signed in to your console, and a fleet with at least one box. On a deployment that runs apps for other people, a rootfs app runs only on a fleet your account owns. [carlos fleets](/docs/cli#carlos-fleets) sets one up, and [Rootfs apps](/docs/rootfs) has the full contract.` |

| RFS-4-C66 | `The finished app is in the platform repository under examples/rails-shop. Every file this guide shows is taken from it.` |

| RFS-4-C67 | `The app` |

| RFS-4-C68 | `Start from rails new with SQLite. Rails 8 gives you Solid Queue, Solid Cache and Solid Cable, each with a database of its own. On CARLOS an instance has one database, so all three share it.` |

@@ -1333,7 +1333,7 @@ Placeholders: `<app>` an app; `<fleet>` a fleet name; `<region>` a region's name

| id | file | text |

|---|---|---|

-| RFS-4-C127 | `cli.md` (carlos instances) | `For a rootfs app, RUNTIME says rootfs, or rootfs, hibernates for an instance that sleeps when idle. WORKERS counts the instance's running workers out of the ones it declares, and names a worker that keeps crashing. A binary instance shows binary and a dash.` |

+| RFS-4-C127 | `cli.md` (carlos instances) | For a rootfs app, RUNTIME says `rootfs`, or `rootfs, hibernates` for an instance that sleeps when idle. WORKERS counts the instance's running workers out of the ones it declares, and names a worker that keeps crashing. A binary instance shows `binary` and a dash. |

| RFS-4-C128 | `cli.md` (carlos apps) | `A rootfs app stays on boxes your account owns. On a deployment that runs apps for other people, --target "" is refused for it, and so is moving it to another fleet while it has instances. [Rootfs apps](/docs/rootfs) says why.` |

| RFS-4-C129 | `nav.json` label | `Rootfs apps` |

| RFS-4-C130 | `nav.json` blurb | `What a rootfs app's image is started with, what it can write, and where it may run.` |

diff --git a/docs/superpowers/plans/2026-10-24-rootfs-apps-5-egress-allow.md b/docs/superpowers/plans/2026-10-24-rootfs-apps-5-egress-allow.md

index 24c397b5d..c8650b204 100644

--- a/docs/superpowers/plans/2026-10-24-rootfs-apps-5-egress-allow.md

+++ b/docs/superpowers/plans/2026-10-24-rootfs-apps-5-egress-allow.md

@@ -32,7 +32,7 @@ Names this plan needs from Plan 2 (its review-fix round owns them; if Plan 2 pic

- **Composite drop-ins and start paths (finding 14).** `RootfsGenDropIn(host string, n uint64, tier cgroup.Limit) string` and `WorkerDropIn(host, name string, tier cgroup.Limit) string` (Plan 2 Task 5), each with exactly one `Slice=<SliceName(host)>` line. The rootfs gen and worker start paths check `show -p Slice --value` against `SliceName(host)` before `start` (Plan 2 Task 5 step 5). Templates `carlos-instance-rootfs@`, `-rootfs-cmd@` carry `Slice=carlos-instances-%i.slice`; `-rootfs-gen@` and `-rootfs-worker@` carry no `Slice=`; `carlos-instance-rootfs-probe.service` carries `Slice=carlos-instances.slice` (Plan 2's per-template table).

- Unchanged from before: `host.OwnBoxAllowed`, `RootfsBoxFacts`, `(*agentRootfs).facts()`.

-Copy deck (`2026-10-24-rootfs-apps-copy.md`, not edited here): rows RFS-5-C36, C40, C41 change text and RFS-5-C42 changes its "Where" column (R8). RFS-5-C44 is new. All are `pending`.

+Copy deck (`2026-10-24-rootfs-apps-copy.md`, not edited here): rows RFS-5-C36, C40, C41 change text and RFS-5-C42 changes its "Where" column (R8). RFS-5-C44 is new. All were `pending` and are now `approved` (by delegation, 2026-10-24).

## Review dispositions (Astra R2)

@@ -1074,15 +1074,15 @@ Human text only. `%s`/`%q`/`%d` are filled by the code. No em dashes. These go i

| RFS-5-C33 | CLI show, per name | `%s did not resolve` |

| RFS-5-C34 | CLI show, stale box | `this box has not reported since %s` |

| RFS-5-C35 | CLI show, operator | `box %s` |

-| RFS-5-C36 | CLI usage | `usage: carlos egress grant --app <a> <destination>...` / ` carlos egress revoke --app <a> (<destination>... \| --all)` / ` carlos egress show --app <a>` / flags `--account`, `--account-id`, `--console` as in door-key usage / `A destination is an address range such as 10.0.0.0/16, a single address, or a hostname such as db.example.com.` / `on a deployment that runs apps for other people, only an owner of the app's account can grant, for an app on one of the account's own fleets, and anyone in the account can revoke. on a deployment run for one customer, only its operators can grant or revoke. anyone in the account can run show.` |

-| RFS-5-C37 | CLI usage | `An app reaches a destination only when its live build declares it too, and only on the customer's own boxes: a fleet box, or any box of a single-tenant deployment.` |

-| RFS-5-C38 | CLI usage | `Egress opens addresses, not ports. a granted address is reachable on every port, so keep the database's own firewall in place.` |

-| RFS-5-C39 | CLI usage | `Hostnames are looked up every few seconds, and an address stays open for ten minutes after the name stops returning it. for endpoints that return a different address on each lookup, grant the subnet instead.` |

-| RFS-5-C40 | README, App capabilities | `egress lets a nested instance reach private addresses its build names: a database or cache in the customer's own network. The build declares the destinations, as "egress": ["10.0.0.0/16", "db.example.com"], and an owner of the account that owns the fleet grants them to the app with carlos egress grant (on a deployment run for one customer, its operator does). A box opens only what both name, only for nested instances, and only on the customer's own boxes. On a box shared with other customers it opens nothing, because there a private range is the platform's own network. Whatever the list says, egress never opens the cloud metadata service, the box's loopback or the box's own addresses. It opens addresses, not ports: a granted address is reachable on every port, so the database's own firewall stays the port fence.` |

+| RFS-5-C36 | CLI usage | `usage: carlos egress grant --app <a> <destination>...` / ` carlos egress revoke --app <a> (<destination>... \| --all)` / ` carlos egress show --app <a>` / flags `--account`, `--account-id`, `--console` as in door-key usage / `a destination is an address range such as 10.0.0.0/16, a single address, or a hostname such as db.example.com` / `on a deployment that runs apps for other people, only an owner of the app's account can grant, for an app on one of the account's own fleets, and anyone in the account can revoke. on a deployment run for one customer, only its operators can grant or revoke. anyone in the account can run show` |

+| RFS-5-C37 | CLI usage | `an app reaches a destination only when its live build declares it too, and only on the customer's own boxes: a fleet box, or any box of a single-tenant deployment` |

+| RFS-5-C38 | CLI usage | `egress opens addresses, not ports. a granted address is reachable on every port, so keep the database's own firewall in place` |

+| RFS-5-C39 | CLI usage | `hostnames are looked up every few seconds, and an address stays open for ten minutes after the name stops returning it. for endpoints that return a different address on each lookup, grant the subnet instead` |

+| RFS-5-C40 | README, App capabilities | `egress lets a nested instance reach private addresses its build names: a database or cache in the customer's own network. The build declares the destinations as "egress": ["10.0.0.0/16", "db.example.com"], and an owner of the account that owns the fleet grants them to the app with carlos egress grant (on a deployment run for one customer, its operator does). A box opens only what the build names and the account grants, only for nested instances, and only on the customer's own boxes. On a box shared with other customers it opens nothing, because a private range there is the platform's own network. Whatever the list says, egress never opens the cloud metadata service, the box's loopback or the box's own addresses. It opens addresses, not ports: a granted address is reachable on every port, so the database's own firewall stays the port fence.` |

| RFS-5-C42 | grant door 409 (shared deployment; revoke needs no placement, R8) | `%s/%s does not run on a fleet your account owns, so egress cannot be granted to it. place it on one of your fleets first with carlos apps place` |

| RFS-5-C43 | ship refusal (rootfs release), replaces RFS-1-C15 | `a rootfs release can declare only the egress capability` |

| RFS-5-C44 | grant door 403 (shared deployment, a member who is not an owner; R8), printed by the CLI | `only an owner of the account can grant egress. anyone in the account can revoke it` |

-| RFS-5-C41 | docs/site/cli.md, `### carlos egress` | `Lets an app's nested instances reach private destinations, such as a managed database in your own network. Your app's build declares the destinations, and an owner of your account grants them to the app for its own fleets (on a deployment run for one customer, the deployment's operator grants them). An instance gets only what both name, and only on your own boxes: a fleet box, or any box of a single-tenant deployment.` / C37, C38, C39 as paragraphs / `show lists what is granted and, for each instance, whether its box applied it and why not.` |

+| RFS-5-C41 | docs/site/cli.md, `### carlos egress` | `Lets an app's nested instances reach private destinations, such as a managed database in your own network. Your app's build declares the destinations, and an owner of your account grants them to the app for its own fleets (on a deployment run for one customer, the deployment's operator grants them). An instance gets only destinations both the build names and the account grants, and only on your own boxes: a fleet box or any box of a single-tenant deployment.` / `Egress opens addresses, not ports. A granted address is reachable on every port, so keep the database's own firewall in place.` / `Hostnames are looked up every few seconds, and an address stays open for ten minutes after the name stops returning it. For endpoints that return a different address on each lookup, grant the subnet instead.` / `Show lists what is granted and, for each instance, whether its box applied it and why not.` |

String count: **44 IDs** (C04 carries seven class names; C36 and C41 are multi-line blocks). Changed in the Astra R1 round for R8: C36, C40 and C41 (text) and C42 (where it is used); added: C44.

diff --git a/docs/superpowers/plans/2026-10-24-rootfs-apps-6-interactive.md b/docs/superpowers/plans/2026-10-24-rootfs-apps-6-interactive.md

index 199119350..9891d7813 100644

--- a/docs/superpowers/plans/2026-10-24-rootfs-apps-6-interactive.md

+++ b/docs/superpowers/plans/2026-10-24-rootfs-apps-6-interactive.md

@@ -147,7 +147,7 @@ Read `runClassRefusal` (`internal/console/apiruns.go:55-70` at 64a002c8) as Plan

- [ ] **Step 3: Check the copy rows**

-Confirm that rows RFS-6-C01 to RFS-6-C64 (the table at the end of this plan) are in the deck and marked approved. If they are missing, add them as pending, exactly as written here, and stop until Paul has reviewed them. Every later task adds the ids it writes to the series gate's built list (Plan 1 Task 1's test) in the same commit.

+Confirm that rows RFS-6-C01 to RFS-6-C64 (the table at the end of this plan) are in the deck and marked approved. If they are missing, add them as pending, exactly as written here, and stop until Paul has reviewed them. (Note: the deck was approved by delegation on 2026-10-24 (Paul asked for a Luna copy pass instead of a string-by-string review; see the deck header), so the gate's approval step is satisfied; the step applies only to rows added after that date.) Every later task adds the ids it writes to the series gate's built list (Plan 1 Task 1's test) in the same commit.

---

@@ -1387,12 +1387,12 @@ Every string is human text the plan introduces. Existing approved strings it reu

| RFS-6-C38 | setting door | `only an owner of the account can turn interactive sessions on` |

| RFS-6-C39 | setting door | `say whether interactive sessions are on or off` |

| RFS-6-C40 | setting door audit detail | `turned interactive sessions %s for %s (%s)` |

-| RFS-6-C41 | `apps_swap.go` usage | ` --interactive on\|off whether members may open a terminal session on the app's instances, with carlos run -it or carlos console. It is off until an owner turns it on. A session can read and change everything the instance can.` |

+| RFS-6-C41 | `apps_swap.go` usage | ` --interactive on\|off whether members may open a terminal session on the app's instances, with carlos run -it or carlos console. it is off until an owner turns it on. a session can read and change everything the instance can` |

| RFS-6-C42 | flag `--interactive` | `on or off: whether members may open terminal sessions on the app's instances` |

| RFS-6-C43 | `apps_swap.go` | `apps set: --interactive is on or off, not %q` |

| RFS-6-C44 | `apps_swap.go` | `%s: interactive sessions are on. any member can open a terminal on its instances with carlos run -it` |

| RFS-6-C45 | `apps_swap.go` | `%s: interactive sessions are off` |

-| RFS-6-C46 | `apps_swap.go` | `apps set: the change did not stick (the console stored interactive %s). Run it again` |

+| RFS-6-C46 | `apps_swap.go` | `apps set: the change did not stick (the console stored interactive %s). run it again` |

| RFS-6-C47 | `apps_swap.go:39`, replaces `appsSetNothing` | `apps set: nothing to set. Pass --swap, --swap-concurrency, --interactive or one of the update settings` |

| RFS-6-C48 | `carlos logs` | `interactive session %s opened by %s` |

| RFS-6-C49 | `carlos logs` | `interactive session %s ended with exit %d after %s` |

diff --git a/docs/superpowers/plans/2026-10-24-rootfs-apps-copy.md b/docs/superpowers/plans/2026-10-24-rootfs-apps-copy.md

index b4f52b762..d3141e57b 100644

--- a/docs/superpowers/plans/2026-10-24-rootfs-apps-copy.md

+++ b/docs/superpowers/plans/2026-10-24-rootfs-apps-copy.md

@@ -1,4 +1,4 @@

-# Rootfs apps: copy deck (pending Paul's review)

+# Rootfs apps: copy deck (approved)

Every user-facing string of the rootfs apps series (#366), assembled verbatim

from the string tables of plans 1 to 6 (`2026-10-24-rootfs-apps-[1-6]-*.md`).

@@ -8,6 +8,8 @@ Plan 1 Task 1 stops for that review. The gate is `approved_rootfs_copy_test.go`

status. Ids are canonical: `RFS-<plan>-C01` to `C99`, then `C100` onward

(Plan 4 runs to C138).

+Approved 2026-10-24 by delegation: Paul asked for a Luna copy pass instead of a string-by-string review (LUNA-COPY-REVIEW-ROOTFS.md); RFS-4-C127 was edited by Claude.

The rules:

- A row is `pending` until Paul approves it in the copy review. His edits are

@@ -37,91 +39,91 @@ From the plan: Placeholders: `<app>` an app name; `<name>` a process name; `<var

|---|---|---|---|

From the plan: RFS-1-C78's `<digest>` is a `sha256:<hex>` digest. RFS-1-C80 to C83 are the first-ship forms of C18 to C21: the app has no other release, and its kind marker (deviation 10) names the ship that fixed its kind, which may not have published, so they never say "is one". RFS-1-C85 is a warning: it does not fail the check. Kept out of the table on purpose (diagnostics, not human text): the probe's one-line JSON on stdout, `validateManifest`'s existing terse messages, store errors wrapped for logs.

@@ -131,18 +133,18 @@ From the plan: Human-readable text this plan introduces, for the series copy dec

|---|---|---|---|

## Plan 3: lifecycle (`2026-10-24-rootfs-apps-3-lifecycle.md`)

@@ -150,35 +152,35 @@ From the plan: Every row goes to the deck in Task 1 and reaches code only once a

|---|---|---|---|

-| RFS-3-C15 | `internal/activator/rootfs_service.go` (`errRootfsReplicaMissing`, the member's wake reason) | the instance has served before and its database replica is missing, so it was not started with an empty database | pending |

-| RFS-3-C26 | `docs/site/cli.md` (`carlos run`, a paragraph) | --version runs another build of the app against the instance, for example the build a deploy is about to bring in. The build must already be on the instance's box. The command still gets the environment the instance serves with. | pending |

+| RFS-3-C15 | `internal/activator/rootfs_service.go` (`errRootfsReplicaMissing`, the member's wake reason) | the instance has served before and its database replica is missing, so it was not started with an empty database | approved |

+| RFS-3-C26 | `docs/site/cli.md` (`carlos run`, a paragraph) | --version runs another build of the app against the instance, for example the build a deploy is about to bring in. The build must already be on the instance's box. The command still gets the environment the instance serves with. | approved |

From the plan: Count: 29 (RFS-3-C29 added in the Astra R1 fix round; Task 1 Step 2 takes it to the deck and Paul). (RFS-3-C28 is live until Plan 6 Task 16 marks it struck when runs reach fleet boxes, R7.)

@@ -190,179 +192,179 @@ From the plan: Placeholders: `<app>` an app; `<fleet>` a fleet name; `<region>`

|---|---|---|---|

-| RFS-4-C04 | internal/console/rootfs.go | <app> is a rootfs app with instances, and a rootfs app's instances cannot move to other boxes yet. delete its instances first, or create a new app where you want it to run. | pending |

-| RFS-4-C05 | internal/console/rootfs.go | none of fleet <fleet>'s boxes can run a rootfs app yet. a box can once it runs a platform release with rootfs support, on the nested layout, and has passed its rootfs check. | pending |

-| RFS-4-C06 | internal/console/rootfs.go | no box in <region> can run a rootfs app yet. a box can once it runs a platform release with rootfs support, on the nested layout, and has passed its rootfs check. | pending |

-| RFS-4-C11 | internal/console/rootfs.go | <app> already has <n> instances made before its first release, such as <host>. an app's first release decides its kind, and those instances were made for a binary app. delete them, ship again, then create them again. | pending |

+| RFS-4-C04 | internal/console/rootfs.go | <app> is a rootfs app with instances, and a rootfs app's instances cannot move to other boxes yet. delete its instances first, or create a new app where you want it to run | approved |

+| RFS-4-C05 | internal/console/rootfs.go | none of fleet <fleet>'s boxes can run a rootfs app yet. a box can once it runs a platform release with rootfs support, on the nested layout, and has passed its rootfs check | approved |

+| RFS-4-C06 | internal/console/rootfs.go | no box in <region> can run a rootfs app yet. a box can once it runs a platform release with rootfs support, on the nested layout, and has passed its rootfs check | approved |

+| RFS-4-C11 | internal/console/rootfs.go | <app> already has <n> instances made before its first release, such as <host>. an app's first release decides its kind, and those instances were made for a binary app. delete them, ship again, then create them again | approved |

### CLI (instances_rootfs.go, instances_cli.go)

|---|---|---|---|

### The sample app (examples/rails-shop)

|---|---|---|---|

### docs/site/rootfs.md

|---|---|---|---|

-| RFS-4-C31 | docs/site/rootfs.md (fact) | A rootfs app is an app shipped as a read-only Linux image instead of a single binary. You build the image on your own machine, from a Dockerfile or anything else that makes an OCI image or a directory, and carlos ship --rootfs uploads it. The platform never builds anything and never pulls from a registry. | pending |

-| RFS-4-C32 | docs/site/rootfs.md | A rootfs app runs only on boxes your account owns: a fleet of yours on a deployment that runs apps for other people, such as Carloku, or any box of a deployment run for one customer. The box must be on the nested layout and must have passed its rootfs check. The console refuses anywhere else, and so does the box. | pending |

-| RFS-4-C34 | docs/site/rootfs.md | An app's first release makes it a binary app or a rootfs app, and it stays that kind. A release of the other kind is refused when you ship it. To change kinds, create a new app. | pending |

-| RFS-4-C35 | docs/site/rootfs.md (fact, D4) | Each instance takes its hibernation setting from the release it is created with, and keeps it. A rootfs app is always on unless that release was shipped with carlos ship --hibernate. A later release that asks for the other setting is refused when you ship it. | pending |

-| RFS-4-C37 | docs/site/rootfs.md (fact) | The JSON file you pass to carlos ship --processes names the commands the image runs. Each is an argv array, either an absolute path or a name found on the image's PATH, with an optional env of plain values (never secrets) and an optional working_dir. | pending |

-| RFS-4-C42 | docs/site/rootfs.md | Commands are not run through a shell, so a $CARLOS_SOCKET written in a command is passed as it is. Read the variable in your server's config file instead, or run the command with sh -c if your image has a shell. | pending |

-| RFS-4-C44 | docs/site/rootfs.md (fact) | Every process of the instance gets the same environment: web, the workers, release and carlos run alike. That is the app's config bundle, the instance's own variables and secrets, its store's coordinates, and these: | pending |

-| RFS-4-C47 | docs/site/rootfs.md (fact) | CARLOS_HOST, CARLOS_REGION, CARLOS_CONTROL_SOCKET and CARLOS_PURGE mean what they mean for a binary instance, as [What an instance is started with](/docs/cli#what-an-instance-is-started-with) says. | pending |

-| RFS-4-C51 | docs/site/rootfs.md | The image is the instance's root filesystem, and it is read-only. An instance writes in two places: the directory CARLOS_DB is in, which is kept across restarts and deploys, and /tmp, which is empty at every start. /tmp is held in memory, so what is in it counts against the instance's memory. | pending |

-| RFS-4-C53 | docs/site/rootfs.md (fact, D10) | All of an instance's processes share one memory and CPU limit, the same tiers a binary instance gets, 1 GB by default. A process that goes over it is stopped and started again. | pending |

-| RFS-4-C55 | docs/site/rootfs.md (fact, R11) | Memory is never writable and executable at once, unless the release is shipped with carlos ship --jit. A JIT compiler needs that: Node, Bun and Deno, the JVM, Ruby's YJIT and PHP's opcache JIT. Ruby, PHP and Python run well without one. | pending |

-| RFS-4-C57 | docs/site/rootfs.md | An instance can reach public addresses, such as an object store or a managed database's public endpoint. It cannot reach private addresses, the box it runs on, or the cloud's metadata service. | pending |

-| RFS-4-C59 | docs/site/rootfs.md | A deployment whose boxes all belong to one customer says so with CARLOS_DEPLOYMENT_SINGLE_TENANT=1, in the console's environment and in every box's host.env. A rootfs app can then run on any of its boxes, not only on a fleet. Leave it unset on a deployment that runs apps for other people. The console does not start if the value is anything but 0 or 1. | pending |

-| RFS-4-C60 | docs/site/rootfs.md | Dedicated pools do not count as a customer's own boxes yet, because nothing ties a pool to one account. On a deployment that runs apps for other people, a rootfs app cannot run in one. | pending |

-| RFS-4-C62 | docs/site/rootfs.md | More than one copy of an app across boxes, more than one SQLite database per instance, moving a rootfs instance to another fleet or region, and starting a new rootfs instance from a copy of another database. | pending |

+| RFS-4-C31 | docs/site/rootfs.md (fact) | A rootfs app is an app shipped as a read-only Linux image instead of a single binary. You build the image on your own machine, from a Dockerfile or anything else that makes an OCI image or a directory, and carlos ship --rootfs uploads it. The platform never builds anything and never pulls from a registry. | approved |

+| RFS-4-C32 | docs/site/rootfs.md | A rootfs app runs only on boxes your account owns: a fleet of yours on a deployment that runs apps for other people, or any box of a deployment run for one customer. The box must be on the nested layout and must have passed its rootfs check. The console refuses anywhere else, and so does the box. | approved |

+| RFS-4-C34 | docs/site/rootfs.md | An app's first release makes it a binary app or a rootfs app, and it stays that kind. A release of the other kind is refused when you ship it. To change kinds, create a new app. | approved |

+| RFS-4-C35 | docs/site/rootfs.md (fact, D4) | Each instance takes its hibernation setting from the release it is created with, and keeps it. A rootfs app is always on unless that release was shipped with carlos ship --hibernate. A later release that asks for the other setting is refused when you ship it. | approved |

+| RFS-4-C37 | docs/site/rootfs.md (fact) | The JSON file you pass to carlos ship --processes names the commands the image runs. Each is an argv array, either an absolute path or a name found on the image's PATH, with an optional env of plain values (never secrets) and an optional working_dir. | approved |

+| RFS-4-C42 | docs/site/rootfs.md | Commands are not run through a shell, so a $CARLOS_SOCKET written in a command is passed as it is. Read the variable in your server's config file instead, or run the command with sh -c if your image has a shell. | approved |

+| RFS-4-C44 | docs/site/rootfs.md (fact) | Every process of the instance gets the same environment: web, the workers, release and carlos run alike. That is the app's config bundle, the instance's own variables and secrets, its store's coordinates, and these: | approved |

+| RFS-4-C47 | docs/site/rootfs.md (fact) | CARLOS_HOST, CARLOS_REGION, CARLOS_CONTROL_SOCKET and CARLOS_PURGE mean what they mean for a binary instance, as [What an instance is started with](/docs/cli#what-an-instance-is-started-with) says. | approved |

+| RFS-4-C51 | docs/site/rootfs.md | The image is the instance's root filesystem, and it is read-only. An instance writes in two places: the directory CARLOS_DB is in, which is kept across restarts and deploys, and /tmp, which is empty at every start. /tmp is held in memory, so what is in it counts against the instance's memory. | approved |

+| RFS-4-C53 | docs/site/rootfs.md (fact, D10) | All of an instance's processes share one memory and CPU limit, the same tiers a binary instance gets, 1 GB by default. A process that goes over it is stopped and started again. | approved |

+| RFS-4-C55 | docs/site/rootfs.md (fact, R11) | Memory is never writable and executable at once, unless the release is shipped with carlos ship --jit. A JIT compiler needs that: Node, Bun and Deno, the JVM, Ruby's YJIT and PHP's opcache JIT. Ruby, PHP and Python run well without one. | approved |

+| RFS-4-C57 | docs/site/rootfs.md | An instance can reach public addresses, such as an object store or a managed database's public endpoint. It cannot reach private addresses, the box it runs on, or the cloud's metadata service. | approved |

+| RFS-4-C59 | docs/site/rootfs.md | A deployment whose boxes all belong to one customer says so with CARLOS_DEPLOYMENT_SINGLE_TENANT=1, in the console's environment and in every box's host.env. A rootfs app can then run on any of its boxes, not only on a fleet. Leave it unset on a deployment that runs apps for other people. The console does not start if the value is anything but 0 or 1. | approved |

+| RFS-4-C60 | docs/site/rootfs.md | Dedicated pools do not count as a customer's own boxes yet, because nothing ties a pool to one account. On a deployment that runs apps for other people, a rootfs app cannot run in one. | approved |

+| RFS-4-C62 | docs/site/rootfs.md | More than one copy of an app across boxes, more than one SQLite database per instance, moving a rootfs instance to another fleet or region, and starting a new rootfs instance from a copy of another database. | approved |

### docs/site/rails.md

|---|---|---|---|

-| RFS-4-C64 | docs/site/rails.md | This guide takes a Rails 8 app from a Dockerfile to a running instance on boxes your account owns. The app runs from a read-only image you build on your own machine. Its web process and its job worker share one SQLite database, which the platform replicates, and uploads go to the app's own bucket. | pending |

-| RFS-4-C65 | docs/site/rails.md | You need Docker with buildx, the carlos CLI signed in to your console, and a fleet with at least one box. On a deployment that runs apps for other people, such as Carloku, a rootfs app runs only on a fleet your account owns. [carlos fleets](/docs/cli#carlos-fleets) sets one up, and [Rootfs apps](/docs/rootfs) has the full contract. | pending |

-| RFS-4-C68 | docs/site/rails.md | Start from rails new with SQLite. Rails 8 gives you Solid Queue, Solid Cache and Solid Cable, each with a database of its own. On CARLOS an instance has one database, so all three share it. | pending |

-| RFS-4-C70 | docs/site/rails.md | The platform gives the web process a unix socket to serve on, in CARLOS_SOCKET. Bind Puma to it and to nothing else. A process that listens on a TCP port instead never answers its health check. | pending |

-| RFS-4-C74 | docs/site/rails.md | Point Solid Queue, Solid Cache and Solid Cable at the same database. Remove config.solid_queue.connects_to from config/environments/production.rb, remove database: from the production section of config/cache.yml, and remove connects_to from the production section of config/cable.yml. Each then uses the primary connection. | pending |

-| RFS-4-C75 | docs/site/rails.md | Their tables then need migrations of their own. Copy the table definitions from db/queue_schema.rb, db/cache_schema.rb and db/cable_schema.rb into three migrations, and delete the three schema files. | pending |

-| RFS-4-C78 | docs/site/rails.md | Keep uploads out of the image and out of the database. carlos store create gives the app a bucket and puts its coordinates in the app's environment. Point Active Storage at them: | pending |

-| RFS-4-C81 | docs/site/rails.md (fact, R11) | Instances run with memory that cannot be written and executed at once, unless the release is shipped with carlos ship --jit, so YJIT cannot start without it. Rails 7.2 and later turn YJIT on by default. This app turns it off in production.rb with config.yjit = false. To keep YJIT, ship with --jit instead. | pending |

-| RFS-4-C83 | docs/site/rails.md | Build the image for arm64, which is what the boxes run. buildx does that on any machine, an Intel laptop included. When the image runs, its root filesystem is read-only, and only /tmp and the directory CARLOS_DB is in can be written. | pending |

-| RFS-4-C93 | docs/site/rails.md (fact, D4) | A rootfs app is always on. To let an instance sleep when nobody uses it, ship the app's first release with carlos ship --hibernate. An instance keeps the setting it was created with. | pending |

-| RFS-4-C95 | docs/site/rails.md (fact) | carlos ship --check runs the image the way a box would: a read-only root, a private /tmp, a socket, a database, and the default memory limit. It needs Docker or Podman, and says what went wrong, such as a process that listened on a port, a write outside the instance's directory, or an image built for amd64. | pending |

-| RFS-4-C98 | docs/site/rails.md | Ship before you create the instance. An app's first release makes it a rootfs app, and an instance takes that, and whether it hibernates, from the release when it is created. | pending |

-| RFS-4-C99 | docs/site/rails.md | The first start runs release, which migrates the empty database, then starts web, then the worker once web answers. carlos instances list shows the instance's runtime and its workers, and carlos logs shows all three processes. | pending |

-| RFS-4-C100 | docs/site/rails.md (fact, D8) | carlos run runs a one-off command in the instance, from its current image. It does not reach instances on a fleet yet. On a deployment run for one customer it works like this: | pending |

-| RFS-4-C102 | docs/site/rails.md | A deploy starts the new web beside the old one and moves traffic once the new one answers. release runs first, from the new image, while the old version is still serving. So a migration has to work with the code that is already running: add a column, deploy, use it, and remove the old one in a later deploy. | pending |

-| RFS-4-C103 | docs/site/rails.md | When a migration cannot work that way, ship that release with --swap hold. The old version stops, release runs, and the new version starts. Requests wait for a few seconds while that happens. | pending |

-| RFS-4-C104 | docs/site/rails.md (fact) | If release fails or runs past its time limit, the old version keeps serving and the deploy stops for that instance. carlos instances list says so, and the next deploy tries again. | pending |

-| RFS-4-C105 | docs/site/rails.md | Rolling back a release does not roll back the database. carlos rollback brings the previous image back, and it runs against the schema the newer release left. This is the other reason a migration should work with the code before it. | pending |

-| RFS-4-C108 | docs/site/rails.md (fact) | The platform starts the app when its box starts, starts web or a worker again when it crashes, and never waits for a visitor to do it. A worker that keeps crashing is started again with a growing delay, and never takes web down with it. | pending |

-| RFS-4-C110 | docs/site/rails.md | [Rootfs apps](/docs/rootfs) lists the limits. The ones a Rails app meets first: one memory limit for all its processes together, 120 seconds for web to answer after it starts, and at most four workers. | pending |

+| RFS-4-C64 | docs/site/rails.md | This guide takes a Rails 8 app from a Dockerfile to a running instance on boxes your account owns. The app runs from a read-only image you build on your own machine. Its web process and its job worker share one SQLite database, which the platform replicates, and uploads go to the app's own bucket. | approved |

+| RFS-4-C65 | docs/site/rails.md | You need Docker with buildx, the carlos CLI signed in to your console, and a fleet with at least one box. On a deployment that runs apps for other people, a rootfs app runs only on a fleet your account owns. [carlos fleets](/docs/cli#carlos-fleets) sets one up, and [Rootfs apps](/docs/rootfs) has the full contract. | approved |

+| RFS-4-C68 | docs/site/rails.md | Start from rails new with SQLite. Rails 8 gives you Solid Queue, Solid Cache and Solid Cable, each with a database of its own. On CARLOS an instance has one database, so all three share it. | approved |

+| RFS-4-C70 | docs/site/rails.md | The platform gives the web process a unix socket to serve on, in CARLOS_SOCKET. Bind Puma to it and to nothing else. A process that listens on a TCP port instead never answers its health check. | approved |

+| RFS-4-C74 | docs/site/rails.md | Point Solid Queue, Solid Cache and Solid Cable at the same database. Remove config.solid_queue.connects_to from config/environments/production.rb, remove database: from the production section of config/cache.yml, and remove connects_to from the production section of config/cable.yml. Each then uses the primary connection. | approved |

+| RFS-4-C75 | docs/site/rails.md | Their tables then need migrations of their own. Copy the table definitions from db/queue_schema.rb, db/cache_schema.rb and db/cable_schema.rb into three migrations, and delete the three schema files. | approved |

+| RFS-4-C78 | docs/site/rails.md | Keep uploads out of the image and out of the database. carlos store create gives the app a bucket and puts its coordinates in the app's environment. Point Active Storage at them: | approved |

+| RFS-4-C81 | docs/site/rails.md (fact, R11) | Instances run with memory that cannot be written and executed at once, unless the release is shipped with carlos ship --jit, so YJIT cannot start without it. Rails 7.2 and later turn YJIT on by default. This app turns it off in production.rb with config.yjit = false. To keep YJIT, ship with --jit instead. | approved |

+| RFS-4-C83 | docs/site/rails.md | Build the image for arm64, which is what the boxes run. buildx does that on any machine, an Intel laptop included. When the image runs, its root filesystem is read-only, and only /tmp and the directory CARLOS_DB is in can be written. | approved |

+| RFS-4-C93 | docs/site/rails.md (fact, D4) | A rootfs app is always on. To let an instance sleep when nobody uses it, ship the app's first release with carlos ship --hibernate. An instance keeps the setting it was created with. | approved |

+| RFS-4-C95 | docs/site/rails.md (fact) | carlos ship --check runs the image the way a box would: a read-only root, a private /tmp, a socket, a database, and the default memory limit. It needs Docker or Podman, and says what went wrong, such as a process that listened on a port, a write outside the instance's directory, or an image built for amd64. | approved |

+| RFS-4-C98 | docs/site/rails.md | Ship before you create the instance. An app's first release makes it a rootfs app, and an instance takes that, and whether it hibernates, from the release when it is created. | approved |

+| RFS-4-C99 | docs/site/rails.md | The first start runs release, which migrates the empty database, then starts web, then the worker once web answers. carlos instances list shows the instance's runtime and its workers, and carlos logs shows all three processes. | approved |

+| RFS-4-C100 | docs/site/rails.md (fact, D8) | carlos run runs a one-off command in the instance, from its current image. It does not reach instances on a fleet yet. On a deployment run for one customer it works like this: | approved |

+| RFS-4-C102 | docs/site/rails.md | A deploy starts the new web beside the old one and moves traffic once the new one answers. release runs first, from the new image, while the old version is still serving. So a migration has to work with the code that is already running: add a column, deploy, use it, and remove the old one in a later deploy. | approved |

+| RFS-4-C103 | docs/site/rails.md | When a migration cannot work that way, ship that release with --swap hold. The old version stops, release runs, and the new version starts. Requests wait for a few seconds while that happens. | approved |

+| RFS-4-C104 | docs/site/rails.md (fact) | If release fails or runs past its time limit, the old version keeps serving and the deploy stops for that instance. carlos instances list says so, and the next deploy tries again. | approved |

+| RFS-4-C105 | docs/site/rails.md | Rolling back a release does not roll back the database. carlos rollback brings the previous image back, and it runs against the schema the newer release left. This is the other reason a migration should work with the code before it. | approved |

+| RFS-4-C108 | docs/site/rails.md (fact) | The platform starts the app when its box starts, starts web or a worker again when it crashes, and never waits for a visitor to do it. A worker that keeps crashing is started again with a growing delay, and never takes web down with it. | approved |

+| RFS-4-C110 | docs/site/rails.md | [Rootfs apps](/docs/rootfs) lists the limits. The ones a Rails app meets first: one memory limit for all its processes together, 120 seconds for web to answer after it starts, and at most four workers. | approved |

### docs/site/laravel-and-django.md

|---|---|---|---|

-| RFS-4-C112 | docs/site/laravel-and-django.md | The Rails guide's shape works for any framework that runs on Linux. These notes cover what is different for Laravel and for Django. Read [the Rails guide](/docs/rails) first. | pending |

-| RFS-4-C114 | docs/site/laravel-and-django.md | Serve Laravel with FrankenPHP, which is one HTTP server process. php-fpm speaks FastCGI, not HTTP, so it cannot be web on its own. Bind FrankenPHP to the socket in its Caddyfile: | pending |

-| RFS-4-C116 | docs/site/laravel-and-django.md | The processes: web runs FrankenPHP, a worker runs the queue, release runs the migrations, and console runs tinker. With the database queue driver the jobs live in the same database. | pending |

-| RFS-4-C117 | docs/site/laravel-and-django.md | Caddy keeps state in its data and config directories. Point them at /tmp with XDG_DATA_HOME and XDG_CONFIG_HOME in web's env, and turn Caddy's admin endpoint off. | pending |

-| RFS-4-C118 | docs/site/laravel-and-django.md | For uploads, Laravel's s3 disk takes the bucket, region and keys from CARLOS_STORE_BUCKET, CARLOS_STORE_REGION, CARLOS_STORE_ACCESS_KEY and CARLOS_STORE_SECRET_KEY in config/filesystems.php. | pending |

-| RFS-4-C123 | docs/site/laravel-and-django.md | The processes: web runs gunicorn -c gunicorn.conf.py with your WSGI module, release runs python manage.py migrate --noinput, and console runs python manage.py shell. A worker is whatever your task queue runs. Pick one that keeps its jobs in the database, so it shares the instance's database. | pending |

-| RFS-4-C125 | docs/site/laravel-and-django.md | For uploads, django-storages' S3 backend takes the bucket, region and keys from CARLOS_STORE_BUCKET, CARLOS_STORE_REGION, CARLOS_STORE_ACCESS_KEY and CARLOS_STORE_SECRET_KEY in settings.py. | pending |

+| RFS-4-C112 | docs/site/laravel-and-django.md | The Rails guide's shape works for any framework that runs on Linux. These notes cover what is different for Laravel and for Django. Read [the Rails guide](/docs/rails) first. | approved |

+| RFS-4-C114 | docs/site/laravel-and-django.md | Serve Laravel with FrankenPHP, which is one HTTP server process. php-fpm speaks FastCGI, not HTTP, so it cannot be web on its own. Bind FrankenPHP to the socket in its Caddyfile: | approved |

+| RFS-4-C116 | docs/site/laravel-and-django.md | The processes: web runs FrankenPHP, a worker runs the queue, release runs the migrations, and console runs tinker. With the database queue driver the jobs live in the same database. | approved |

+| RFS-4-C117 | docs/site/laravel-and-django.md | Caddy keeps state in its data and config directories. Point them at /tmp with XDG_DATA_HOME and XDG_CONFIG_HOME in web's env, and turn Caddy's admin endpoint off. | approved |

+| RFS-4-C118 | docs/site/laravel-and-django.md | For uploads, Laravel's s3 disk takes the bucket, region and keys from CARLOS_STORE_BUCKET, CARLOS_STORE_REGION, CARLOS_STORE_ACCESS_KEY and CARLOS_STORE_SECRET_KEY in config/filesystems.php. | approved |

+| RFS-4-C123 | docs/site/laravel-and-django.md | The processes: web runs gunicorn -c gunicorn.conf.py with your WSGI module, release runs python manage.py migrate --noinput, and console runs python manage.py shell. A worker is whatever your task queue runs. Pick one that keeps its jobs in the database, so it shares the instance's database. | approved |

+| RFS-4-C125 | docs/site/laravel-and-django.md | For uploads, django-storages' S3 backend takes the bucket, region and keys from CARLOS_STORE_BUCKET, CARLOS_STORE_REGION, CARLOS_STORE_ACCESS_KEY and CARLOS_STORE_SECRET_KEY in settings.py. | approved |

### docs/site/cli.md and docs/site/nav.json

|---|---|---|---|

-| RFS-4-C127 | `cli.md` (carlos instances) | For a rootfs app, RUNTIME says rootfs, or rootfs, hibernates for an instance that sleeps when idle. WORKERS counts the instance's running workers out of the ones it declares, and names a worker that keeps crashing. A binary instance shows binary and a dash. | pending |

-| RFS-4-C128 | `cli.md` (carlos apps) | A rootfs app stays on boxes your account owns. On a deployment that runs apps for other people, --target "" is refused for it, and so is moving it to another fleet while it has instances. [Rootfs apps](/docs/rootfs) says why. | pending |

+| RFS-4-C128 | `cli.md` (carlos apps) | A rootfs app stays on boxes your account owns. On a deployment that runs apps for other people, --target "" is refused for it, and so is moving it to another fleet while it has instances. [Rootfs apps](/docs/rootfs) says why. | approved |

### docs/site/rootfs.md, JIT rows

|---|---|---|---|

-| RFS-4-C136 | docs/site/rootfs.md (fact, R11) | A release shipped with --jit has jit set in its manifest, and every process of its instances runs with that protection off: web, the workers, release, console, carlos run and interactive sessions. Nothing else about the instance changes. The setting belongs to the release, so a later release can turn it on or off. | pending |

-| RFS-4-C137 | docs/site/rootfs.md (fact, R11) | Node stops at start without --jit. node --jitless does run, but only as an interpreter and without WebAssembly, which makes most apps much slower. Ship a Node app with --jit instead. | pending |

-| RFS-4-C138 | docs/site/rootfs.md (fact, R11) | carlos ship --check warns when a process runs Node, Bun or Deno and the release is not shipped with --jit, because the check passes on your machine and the box then stops the process at start. | pending |

+| RFS-4-C136 | docs/site/rootfs.md (fact, R11) | A release shipped with --jit has jit set in its manifest, and every process of its instances runs with that protection off: web, the workers, release, console, carlos run and interactive sessions. Nothing else about the instance changes. The setting belongs to the release, so a later release can turn it on or off. | approved |

+| RFS-4-C137 | docs/site/rootfs.md (fact, R11) | Node stops at start without --jit. node --jitless does run, but only as an interpreter and without WebAssembly, which makes most apps much slower. Ship a Node app with --jit instead. | approved |

+| RFS-4-C138 | docs/site/rootfs.md (fact, R11) | carlos ship --check warns when a process runs Node, Bun or Deno and the release is not shipped with --jit, because the check passes on your machine and the box then stops the process at start. | approved |

From the plan: (The WORKERS count `<running>/<total>` alone is a number, not copy, so it has no row. RFS-4-C20, unused in the first draft, is the sample page's database line.)

@@ -372,50 +374,50 @@ From the plan: Human text only. `%s`/`%q`/`%d` are filled by the code. No em das

|---|---|---|---|

-| RFS-5-C01 | ship and grant refusal (the grant door and CLI drop the `capabilities: egress: ` prefix) | capabilities: egress: %q is not an address range or a hostname. use a range such as 10.0.0.0/16, a single address, or a name such as db.example.com | pending |

-| RFS-5-C04 | class names in C03 and show | `this host` · `loopback` · `link-local addresses, where the cloud metadata service lives` · `the cloud metadata service` · `multicast` · `reserved addresses` · `an address translation range` | pending |

-| RFS-5-C39 | CLI usage | Hostnames are looked up every few seconds, and an address stays open for ten minutes after the name stops returning it. for endpoints that return a different address on each lookup, grant the subnet instead. | pending |

-| RFS-5-C40 | README, App capabilities | egress lets a nested instance reach private addresses its build names: a database or cache in the customer's own network. The build declares the destinations, as "egress": ["10.0.0.0/16", "db.example.com"], and an owner of the account that owns the fleet grants them to the app with carlos egress grant (on a deployment run for one customer, its operator does). A box opens only what both name, only for nested instances, and only on the customer's own boxes. On a box shared with other customers it opens nothing, because there a private range is the platform's own network. Whatever the list says, egress never opens the cloud metadata service, the box's loopback or the box's own addresses. It opens addresses, not ports: a granted address is reachable on every port, so the database's own firewall stays the port fence. | pending |

-| RFS-5-C42 | grant door 409 (shared deployment; revoke needs no placement, R8) | %s/%s does not run on a fleet your account owns, so egress cannot be granted to it. place it on one of your fleets first with carlos apps place | pending |

+| RFS-5-C01 | ship and grant refusal (the grant door and CLI drop the `capabilities: egress: ` prefix) | capabilities: egress: %q is not an address range or a hostname. use a range such as 10.0.0.0/16, a single address, or a name such as db.example.com | approved |

+| RFS-5-C04 | class names in C03 and show | `this host` · `loopback` · `link-local addresses, where the cloud metadata service lives` · `the cloud metadata service` · `multicast` · `reserved addresses` · `an address translation range` | approved |

+| RFS-5-C39 | CLI usage | hostnames are looked up every few seconds, and an address stays open for ten minutes after the name stops returning it. for endpoints that return a different address on each lookup, grant the subnet instead | approved |

+| RFS-5-C40 | README, App capabilities | egress lets a nested instance reach private addresses its build names: a database or cache in the customer's own network. The build declares the destinations as "egress": ["10.0.0.0/16", "db.example.com"], and an owner of the account that owns the fleet grants them to the app with carlos egress grant (on a deployment run for one customer, its operator does). A box opens only what the build names and the account grants, only for nested instances, and only on the customer's own boxes. On a box shared with other customers it opens nothing, because a private range there is the platform's own network. Whatever the list says, egress never opens the cloud metadata service, the box's loopback or the box's own addresses. It opens addresses, not ports: a granted address is reachable on every port, so the database's own firewall stays the port fence. | approved |

+| RFS-5-C42 | grant door 409 (shared deployment; revoke needs no placement, R8) | %s/%s does not run on a fleet your account owns, so egress cannot be granted to it. place it on one of your fleets first with carlos apps place | approved |

From the plan: String count: **44 IDs** (C04 carries seven class names; C36 and C41 are multi-line blocks). Changed in the Astra R1 round for R8: C36, C40 and C41 (text) and C42 (where it is used); added: C44.

@@ -425,70 +427,70 @@ From the plan: Every string is human text the plan introduces. Existing approved

|---|---|---|---|

-| RFS-6-C11 | interactive_cli.go | carlos console takes no command. it opens the console process the app's manifest declares. to run another command: carlos run -it --app <app> --instance <host> -- <command> | pending |

-| RFS-6-C12 | interactive_cli.go | carlos console works only through a signed-in console, and this shell is in direct bucket mode. unset CARLOS_DEPLOYMENT_BUCKET and CARLOS_DEPLOYMENT_DIR, then run carlos auth login --console <url> | pending |

-| RFS-6-C33 | console door | %s runs a release that declares no console process. add a console entry to processes in the app's manifest, or name the command: carlos run -it --app %s --instance %s -- <command> | pending |

-| RFS-6-C41 | `apps_swap.go` usage | --interactive on\|off whether members may open a terminal session on the app's instances, with carlos run -it or carlos console. It is off until an owner turns it on. A session can read and change everything the instance can. | pending |

-| RFS-6-C58 | `cli.md`, `### carlos run` | With -it, the command runs in a terminal session instead: what you type goes to it and its screen comes back, so a REPL or a shell works. The app must allow it first, with carlos apps set <app> --interactive on, which only an owner can do. A session ends when the command exits, after 30 minutes without a keystroke, after 6 hours, or soon after your connection drops. A deploy, a restart or a move of the instance ends it too. Ctrl-C and Ctrl-D go to the command. One session at a time per instance, beside any run. Who opened it, where, when it ended and how are in the audit log. What you type and what it prints are not kept. | pending |

-| RFS-6-C59 | `cli.md`, `### carlos console` | Opens the console process your app's manifest declares, in a terminal session, as carlos run -it would. carlos ship fills one in for Rails, Laravel and Django apps when the manifest has none. An app without one is refused, and the message says how to name a command instead. | pending |

-| RFS-6-C60 | `cli.md`, `carlos apps set` | --interactive on lets any member open a terminal session on the app's instances with carlos run -it or carlos console. A session can read and change everything the instance can, so it is off until an owner turns it on. Any member can turn it off. | pending |

-| RFS-6-C61 | `cli.md`, exit codes | A session exits with the command's own status, 124 when it ended for lack of keystrokes or at 6 hours, 125 when it was interrupted or its box's connection dropped, 130 when you cancelled it before it started, 3 when the box refused it or none opened it within 60 seconds, 2 when the console refused it, and 1 when carlos lost its connection to the console. | pending |

+| RFS-6-C11 | interactive_cli.go | carlos console takes no command. it opens the console process the app's manifest declares. to run another command: carlos run -it --app <app> --instance <host> -- <command> | approved |

+| RFS-6-C12 | interactive_cli.go | carlos console works only through a signed-in console, and this shell is in direct bucket mode. unset CARLOS_DEPLOYMENT_BUCKET and CARLOS_DEPLOYMENT_DIR, then run carlos auth login --console <url> | approved |

+| RFS-6-C33 | console door | %s runs a release that declares no console process. add a console entry to processes in the app's manifest, or name the command: carlos run -it --app %s --instance %s -- <command> | approved |

+| RFS-6-C41 | `apps_swap.go` usage | --interactive on\|off whether members may open a terminal session on the app's instances, with carlos run -it or carlos console. it is off until an owner turns it on. a session can read and change everything the instance can | approved |

+| RFS-6-C58 | `cli.md`, `### carlos run` | With -it, the command runs in a terminal session instead: what you type goes to it and its screen comes back, so a REPL or a shell works. The app must allow it first, with carlos apps set <app> --interactive on, which only an owner can do. A session ends when the command exits, after 30 minutes without a keystroke, after 6 hours, or soon after your connection drops. A deploy, a restart or a move of the instance ends it too. Ctrl-C and Ctrl-D go to the command. One session at a time per instance, beside any run. Who opened it, where, when it ended and how are in the audit log. What you type and what it prints are not kept. | approved |

+| RFS-6-C59 | `cli.md`, `### carlos console` | Opens the console process your app's manifest declares, in a terminal session, as carlos run -it would. carlos ship fills one in for Rails, Laravel and Django apps when the manifest has none. An app without one is refused, and the message says how to name a command instead. | approved |

+| RFS-6-C60 | `cli.md`, `carlos apps set` | --interactive on lets any member open a terminal session on the app's instances with carlos run -it or carlos console. A session can read and change everything the instance can, so it is off until an owner turns it on. Any member can turn it off. | approved |

+| RFS-6-C61 | `cli.md`, exit codes | A session exits with the command's own status, 124 when it ended for lack of keystrokes or at 6 hours, 125 when it was interrupted or its box's connection dropped, 130 when you cancelled it before it started, 3 when the box refused it or none opened it within 60 seconds, 2 when the console refused it, and 1 when carlos lost its connection to the console. | approved |

## Conflicts