carlos / platform Public

Clone
git clone https://amadan.net/carlos/platform

Plain git — no account needed to clone.

Download

Download this file

Review brief: moves-offline-fixes (harness Run 9 defects 6, 7, 8)

You are an independent reviewer (Astra). Review branch moves-offline-fixes against origin/main (git diff origin/main...HEAD). It fixes three defects the deployment harness found in the offline operator move (docs/superpowers/plans/2026-10-20-offline-operator-move.md is the design):

  • 6: config sync skipped writing <host>.config.env for a nested row whose instance dir did not exist yet and only retried hourly. It now skips the row and the 3 s config loop writes it on the first tick after the dir appears.
  • 7: the console doors trust box reports for 2 minutes but boxes rewrote them only every 5-6 minutes, so a stale report at flip was refused as "still runs a process". Now, while a move is between start and landed, source boxes and the sealer re-assert their reports every 15 s, and a stale report answers MV-O178.
  • 8: after open, the source's scheduler re-created the moved instance's env file with a fresh admin token. The scheduler now skips held rows and hosts whose move record names another region.

Check especially:

  • Dormant behaviour: with no offline move anywhere, nothing changes except defect 6's general config-sync fix. Is that fix safe for every non-move instance? Could skipping a row hide a real failure, or loop?
  • Re-assert in 7 must never re-run seal or landing, never re-take or extend the tombstone, and never make a stale or wrong claim fresh: a re-asserted report must reflect current box state, not copy old state forward with a new timestamp.
  • Could MV-O178 mask a real "process still running" case?
  • 8 must not stop timers for instances that are NOT moving, and must not drop a due timer that should fire on the target.
  • Every operator string is a recorded copy row, and no err.Error() reaches an operator.

Write findings by severity (BLOCKER/HIGH/MEDIUM/LOW), each with file:line, a failure scenario and a fix. Verify against the code. End with a verdict: MERGE, MERGE AFTER FIXES, or DO NOT MERGE.