carlos / platform Public

| Round 3 finding | Rev 4 sufficient? | Why | |---|---|---| | 10. Rollback affects unrelated processes | Yes | §2.3 now groups by the same non-empty upstream, with Socket taking precedence over Addr. | | 11. Shared-host stamps and refusal coverage | Yes | §2.3 restores links and registry stamps even for siblings advanced by an interrupted pass, and records refusals for every group host. | | 13. Re-promoting does not trigger retry | Yes | §2.5 introduces promote --retry through both interfaces, explicitly requiring a fresh PromotedAt. |

New findings at 924d2bf8:

1. P2 — Proof-waiting routes outside canary channels can wait until the hourly pass. §4.5 relies on the two-second fast loop to reconsider a missing proof after its 30-second cache expires. However, fastMembers excludes non-canary routes that already have a live version. A promotion’s serial bump can run the gate once, find no proof, and leave the old version live; subsequent ticks then exclude that route. §4.4 specifies uploading the proof but no wake-up mechanism for its consumer. Require pending-proof routes to remain eligible for bounded rechecks, or specify a proof-arrival trigger that reaches them.

1. P2 — Readiness probes can reject a healthy socket-backed unit. §2.4 always sends a configured health probe to rt.Addr, although Route.Socket takes precedence, and unitRail permits named units on socket-backed routes. With a configured probe and an empty Addr, a healthy unit serving its Unix socket never passes readiness: D1 rolls it back, the restored build fails the same check, and the refusal blocks further adoption. With both fields populated, D1 checks an upstream the route does not use. Make readiness follow the effective upstream, including Unix-socket HTTP probes.

Verdict: accept with fixes.