carlos / platform Public

| Finding | Disposition | |---|---| | A3-1 — CloudTrail fencing | Resolved. Only verified terminal state authorizes operator recovery; otherwise hosts remain awaiting-evidence. | | A3-2 — target durability barrier | Partly resolved. Final database and manifest positions are journaled, but the new sequence flushes before stopping existing writers. See A4-1. | | A3-3 — bind authentication and conditional policies | Resolved. Operator-only binds identify an immutable record version. Conditional headers are enforced in storage. A4-2 identifies a separate upload-policy gap. | | A3-4 — code citations | Resolved. The corrected paths and line anchors support their stated context. | | A2-5 residual — continuous publication | Resolved. Deadline publication and per-second polling replace the previously unbounded waits. | | A2-7 residual — failed-probe recovery | Partly resolved. Bounded recovery exists, but preserving the failed target’s final writes still requires A4-1. | | A1-1 residual — legacy identity | Resolved. The operator binding names the exact record version; replacement and deletion are denied. |

Reviewed spec rev 4 at ff92ca2e. H1–H6 remain fixed.

1. A4-1 — P1 — §5.8: the release sequence flushes before stopping existing writers. Location

Problem: Closing admission and draining spawn attempts does not stop an already-running process. Claim §6.1 lists an empty process tree separately. Steps 2–3 therefore record “final” positions while the application can still mutate its database and files.

Failing sequence: A publishes manifest sequence S in step 3. Its running app then writes a file before step 4 kills and drains the process tree. Stop evidence succeeds, and B installs the pinned manifest at S. The last write is lost during a live drain or failed-probe replacement.

Fix: Close admission, drain existing application processes and timer deliveries, then checkpoint and flush all state. Journal the resulting positions, close remaining replication work, and establish final stop evidence. Carry that ordering into K2 and K8.

1. A4-2 — P2 — §6: the conditional-write Deny also blocks multipart upload preparation. Location

Problem: The specified Deny has no s3:ObjectCreationOperation qualification. Multipart initiation and part uploads require s3:PutObject authorization but cannot supply these conditional headers. AWS explicitly requires exempting those operations while enforcing the condition at completion. AWS conditional-write enforcement.

Failing sequence: A files snapshot exceeds the single-PUT limit. Its multipart initiation is denied, so no new recoverable snapshot can be published and a release flush cannot complete. The spec defines no size bound that excludes this case. AWS upload limits.

Fix: Qualify the header Deny with s3:ObjectCreationOperation: true. Require the conditional header on CompleteMultipartUpload, and test successful multipart publication alongside refusal of unconditional completion.

1. A4-3 — P3 — dependency declaration: 29245f69 does not contain moves rev 7.6. Location

Problem: At that commit, the moves document declares rev 7.5 and contains no level-0 anchor contract. The supplied worktree contains rev 7.6 as an uncommitted modification.

Failing sequence: An implementer checks out the named dependency and follows §5.8’s references to rev 7.6 steps 2 and 7. Those referenced mechanisms are absent from that committed revision.

Fix: Pin the committed revision containing rev 7.6, or explicitly identify the dependency as an uncommitted draft until that revision exists. This is a reproducibility correction; the HA spec’s explicit anchor requirement remains intact.

All code file:line citations were checked against ff92ca2e. No files were changed or tests run.

Verdict: not ready.