Astra stage B round 2 brief
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1 file changed,
+23
−0
docs/superpowers/plans/CODEX-PLAN-REGION-HA-STAGE-B-BRIEF-2.md+23 −0
CI failed — run details
diff --git a/docs/superpowers/plans/CODEX-PLAN-REGION-HA-STAGE-B-BRIEF-2.md b/docs/superpowers/plans/CODEX-PLAN-REGION-HA-STAGE-B-BRIEF-2.md| new file mode 100644 |
| index 000000000..51f6a8cd3 |
| --- /dev/null |
| +++ b/docs/superpowers/plans/CODEX-PLAN-REGION-HA-STAGE-B-BRIEF-2.md |
| @@ -0,0 +1,23 @@ |
| +# Astra round 2 brief: region HA stage B plan rev 2 |
| + |
| +**Review:** `docs/superpowers/plans/2026-10-10-region-ha-1b-next-stage-b.md` rev 2 (a73c430f). Its disposition table at the top answers your round 1 (`CODEX-PLAN-REGION-HA-STAGE-B-R1.md`): 10 accepted, 4 changed, 0 declined, with new rulings 42–54. Round 1's brief still applies (`CODEX-PLAN-REGION-HA-STAGE-B-BRIEF-1.md`). |
| + |
| +**Judge:** |
| +1. **Is each round 1 finding closed?** For each one, does the named test really prove the fix? Findings 2 and 8 are proved by one end-to-end test that starts from an empty target with the real flags and runs through a real probe to the serving wake. Is that test specified concretely enough to be built, and would it fail on rev 1's design? |
| +2. **The four changed dispositions.** |
| + - 4: every target uses the nested layout. |
| + - 8: an explicit stop, receipt and completion before serving. |
| + - 10: main's WorkSource with only its policy replaced. |
| + - 13: no reactivation of a stamp. The restore of a retired install is dropped. |
| + Are these sound? |
| +3. **New claim asks and fallbacks.** |
| + - C6: a narrower cleanup for a dropped target's unopened install. |
| + - C7: the first serving wake hands over from the stopped probe session. This is an activation gate. |
| + - C9: the claim policy admits install actions for a relocating target. |
| + - C8 + O1: moves' files provider publishes `<host>.env` before the app starts. |
| + Is each fallback safe? Is C7 really unavoidable, or can region HA close it within main's existing cold-handover contract? |
| +4. **Ruling 54 / O2.** The pinner now accepts `CARLOS_INSTANCE_KEY` in the pinned `<host>.env` as the instance key. Note that a separate review of the instance-key plan found that a platform key's presence does not prove the app uses it. An app may seal with its own `instance.key`. Does O2 reopen ruling 25's hazard? What evidence should it require? |
| +5. **Removed coverage.** Rev 2 deletes stage A's controller set and its 200-seed lifecycle property, in favour of main's participation owner. Is coverage lost that must be replaced? |
| +6. **Anything new.** Did any fix introduce a new defect? |
| + |
| +Give findings as P1/P2/P3 with file:line, then a verdict: ready to build, or not. |