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):
4
5
- 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.
6
- 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.
7
- 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.
8
9
Check especially:
10
- 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?
11
- 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.
12
- Could MV-O178 mask a real "process still running" case?
13
- 8 must not stop timers for instances that are NOT moving, and must not drop a due timer that should fire on the target.
14
- Every operator string is a recorded copy row, and no err.Error() reaches an operator.
15
16
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.
amadan