carlos / platform Public

spec: T7 under host claims stages without publishing; configured publishes (amendment, 2026-10-12)

Paul's T7 ruling (Q2.1 of the moves pre-flight after claim Plan 12),
recorded in §7.3's T7 row and §9.2 in the style of the T13 amendment:
with host claims on, T7 stages and verifies the pinned release and leaves
live/<host> alone; the landing's configured step publishes it under the
held-release selection and renders under held-config. Claims off is
unchanged.

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

claude 1 week ago 0bcfb5a66541f114ce9c279167027318ca3d053b parent 11ed3bb

1 file changed, +16 −1

docs/superpowers/specs/2026-10-02-move-any-app-design.md +16 −1

diff --git a/docs/superpowers/specs/2026-10-02-move-any-app-design.md b/docs/superpowers/specs/2026-10-02-move-any-app-design.md

index 6e2c2cc59..60c7f61c8 100644

--- a/docs/superpowers/specs/2026-10-02-move-any-app-design.md

+++ b/docs/superpowers/specs/2026-10-02-move-any-app-design.md

@@ -2566,7 +2566,7 @@ placement, the target writes `moves/<acct>/<app>/<host>/<move id>/target.json`:

| T4 storage | for each store bound in that composed environment (`internal/objstore/objstore.go:214-218`), with its credentials: list one key, put, get and delete `.carlos-move-probe/<move id>` |

| T5 archive | the newest archive opens with this box's key, matches its manifest, has no special file, and is under the cap |

| T6 disk | free space (`readDiskFrac`, `internal/host/probes.go:209`) covers twice the replica, plus the archive, plus 2 GiB, and stays under 85% |

-| T7 release | the pinned release materializes for the held row (§9.2) |

+| T7 release (amendment, 2026-10-12) | the pinned release materializes for the held row (§9.2). With host claims on, T7 stages the pinned release into the shared version store and verifies it there (D3's admit, §4.1's authorization, the stage bound to its digest and D3's bind on the staged bytes) but does not publish `live/<host>`: a `moving` claim grants no held write, and the link is this host's file. The publication moves to the landing's `configured`, under its `held-release` selection (§9.2). With host claims off, T7 is unchanged. A target that cannot write its version store under the claim reports that the release is not staged yet, because there is no root stage pass to relay it to. Paul ruled it on 2026-10-12 (Q2.1 of the moves pre-flight after claim Plan 12), so that a move can become ready while host claims are on |

| T8 one owner | exactly one hosting box publishes the target placement |

| T9 claim | the claim is `moving` with this move id, its holder is the record's incarnation, and this region and box are in `touched` (added by CAS before the first staging write, claim spec §2) |

| T10 return lane | this box can put and delete `moves/_lane/<move id>` in the source's bucket (M17) |

@@ -3480,6 +3480,21 @@ race on one file.

(`internal/release/adopt.go:816-819`). New: `release.MaterializeHeld(rt, op,

version)` stages exactly the pinned release (`move.inputs.release`).

+**Amendment, 2026-10-12 (Paul's ruling on T7, Q2.1).** With host claims on,

+the stage and the publication are split. T7 (§7.3) stages the pinned

+release and verifies it without touching `live/<host>`

+(`release.StageHeldVerified`). The landing's `configured` step, and a dirty

+return's, publishes it under the claim's `held-release` selection, whose

+identity names exactly that version (`release.MaterializeHeldUnder`), and

+then reads it back as T7 does with claims off (`release.VerifyHeldLive`).

+The held render in the same step runs under a `held-config` selection

+(`appconfig.RenderHeldUnderBefore`, which keeps carry (c)'s journal before

+the write), and a merge that is not the pinned inputs is the "configuration

+changed" rollback before anything is selected or written. With host claims

+off, `MaterializeHeld` and `RenderHeld` run as before. The landing still

+refuses at `checking` under the claim (`RollbackClaimWired`, ruling G16)

+until this box's moves source is registered with the claim.

### 9.3 The activator

- `ProbeWake` (§7.7); `RetireExcept` keeps held entries.