amadan
docs: rule on the multi-box shared-bucket pin blind spot
§5's explicit rulings gain one more: box A's alsoProtected set is its own registry only, so it cannot see box B's pins on a shared bucket. Bounded today by local staging of running binaries, bucket-side pointer protection, and one-box-per-bucket deployments; revisit before a second box shares a bucket.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
1 file changed,
+9
−0
docs/superpowers/specs/2026-08-10-releases-retention-design.md+9 −0
diff --git a/docs/superpowers/specs/2026-08-10-releases-retention-design.md b/docs/superpowers/specs/2026-08-10-releases-retention-design.md| index 3f13db1cb..b08b2168c 100644 |
| --- a/docs/superpowers/specs/2026-08-10-releases-retention-design.md |
| +++ b/docs/superpowers/specs/2026-08-10-releases-retention-design.md |
| @@ -136,6 +136,15 @@ before it is ever turned into a delete key. |
| - **Enforcement scope is hosted-apps-only per box** (§6). An app with |
| routes on no box never prunes; nothing is at stake there and |
| trash→purge owns end of life. |
| +- **Multi-box shared-bucket deployments have a pin blind spot.** Box A's |
| + `alsoProtected` set is its own registry only — it cannot see box B's |
| + pins, so a version box B has adopted or is rolling back to could, in |
| + principle, be pruned by box A. Bounded today because a running |
| + process's binary is staged locally (a prune of the bucket object does |
| + not touch what is already on disk) and because channel pointer |
| + `Version` + `History` are protected bucket-side regardless of which box |
| + reads them; also because today's deployments are one box per bucket. |
| + Revisit before a second box shares a bucket. |
| ## 6. Box enforcement leg |