amadan
rootfs apps: step numbering
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 file changed,
+3
−3
docs/superpowers/specs/2026-10-24-rootfs-apps-design.md+3 −3
CI cancelled — superseded by a newer push — run details
diff --git a/docs/superpowers/specs/2026-10-24-rootfs-apps-design.md b/docs/superpowers/specs/2026-10-24-rootfs-apps-design.md| index 4c0e843e9..5c292a2d0 100644 |
| --- a/docs/superpowers/specs/2026-10-24-rootfs-apps-design.md |
| +++ b/docs/superpowers/specs/2026-10-24-rootfs-apps-design.md |
| @@ -650,7 +650,7 @@ resource IDs. Managed databases are the customer's choice of endpoint. |
| shorthand for a declared `console` process that `carlos ship` fills in |
| locally for Rails, Laravel and Django; off by default per app; needed |
| before step 4, not step 1 (§5.10). |
| -- The egress allow is in this design because step 3 cannot happen |
| +- The egress allow is in this design because step 4 cannot happen |
| without it, but it is not needed for step 1 and can land after it. |
| ## 12. Follow-ups (separate designs) |
| @@ -673,12 +673,12 @@ resource IDs. Managed databases are the customer's choice of endpoint. |
| Astra's builder check (round 1) raised six questions. B1-1 to B1-5 are |
| settled above as my calls. B1-6 is Q1. |
| -- **Q1.** For the Rails app moving off Kubernetes (step 3), is failover |
| +- **Q1.** For the Rails app moving off Kubernetes (step 4), is failover |
| within minutes acceptable at first, or must it run on several boxes |
| from day one? Paul (2026-10-24): stateless instances "make a ton of |
| sense", and some apps already keep all their state in S3 with |
| compare-and-swap. So the stateless-replicas design is wanted, for |
| - those apps as much as for rootfs ones. Its order relative to step 3 is |
| + those apps as much as for rootfs ones. Its order relative to step 4 was |
| still open. **Answered (Paul, 2026-10-24): yes, stateless replicas land |
| before the Kubernetes migration.** §6 now has it as step 3. |