env parity: record the test droplet's dark-solver overlay as a test-only divergence

[jehanazad]

Main's CI run for c88e8a6 (#306 merged) fails at Staging/production parity: the five dark-solver values #306 set in docker-compose.test.yml are absent from the production overlay, and the check refuses an unexplained difference. That also blocks the staging and production deploys behind it, so nothing from #291–#302 has deployed yet.

This records the divergence the way the check asks for: a ("test", …)-scoped ALLOWED_DIVERGENCE entry for SOLVER_ALT_MODE, NODE_FRAME_MIN_INTERVAL_S, TRACK_MAX_STALE_S, DARK_FOLLOW_MODE, DARK_FOLLOW_MIN_SOLVES, with the reasoning in the comment. Staging and production keep the code defaults; moving those is a separate code change once the test droplet's numbers justify it.

python3 deploy/check-env-parity.py locally: in parity with production (compose + nginx): staging, test.

🤖 Generated with Claude Code

[claude]

Claude finished @jehanazad's task in 1m 14s —— View job

---

Code review: PR #307

• Gather context (diff, related files, CLAUDE.md)
• Understand the request (custom instruction: code review this PR)
• Review changed file(s) for correctness
• Post review feedback

Change: adds one ("test", ...)-scoped ALLOWED_DIVERGENCE entry in deploy/check-env-parity.py covering SOLVER_ALT_MODE, NODE_FRAME_MIN_INTERVAL_S, TRACK_MAX_STALE_S, DARK_FOLLOW_MODE, DARK_FOLLOW_MIN_SOLVES.

Verification performed:

• Confirmed these five keys are set only in docker-compose.test.yml (SOLVER_ALT_MODE=free, NODE_FRAME_MIN_INTERVAL_S=0.5, TRACK_MAX_STALE_S=8, DARK_FOLLOW_MODE=binding, DARK_FOLLOW_MIN_SOLVES=2) — staging and production don't touch them, matching the scope.
• Confirmed the code defaults cited in the new comment are accurate: SOLVER_ALT_MODE → sweep (backend/core/state.py:94), NODE_FRAME_MIN_INTERVAL_S → 1.0 (backend/services/tcp_handler.py:496), TRACK_MAX_STALE_S → 3.0 (backend/config/constants.py:98), DARK_FOLLOW_MODE → shadow (backend/core/state.py:138), DARK_FOLLOW_MIN_SOLVES → 3 (backend/services/dark_follow.py:78).
• The regex concatenation across the two raw-string lines is correct (^services\.server\.environment\.(SOLVER_ALT_MODE|NODE_FRAME_MIN_INTERVAL_S|TRACK_MAX_STALE_S|DARK_FOLLOW_MODE|DARK_FOLLOW_MIN_SOLVES)$), anchored so no unintended partial matches between the two DARK_FOLLOW_* names.
• "test" is a valid, non-REFERENCE scope, so _compile_allowed won't reject it, and it isn't a no-op.
• Follows the file's own convention: (scope, pattern) tuple, comment explaining why the divergence exists and what would need to change (in code, not the overlay) to remove it — consistent with the neighboring NODE_FORCE_RETIRE_PREFIXES entry's style.

I wasn't able to execute docker compose / python3 deploy/check-env-parity.py myself in this sandbox (no permission for subprocess/docker invocation), so I relied on static verification of the regex, the overlay contents, and the code defaults above rather than re-running the script; the PR description states it was run locally with a passing result, which lines up with what I found by inspection.

Assessment: narrowly scoped, matches the pattern the file already establishes, and the reasoning in the comment checks out against the actual code defaults and overlay values. No issues found — this looks correct and safe to merge as a test-only recorded divergence, with the actual constant-tuning left as a separate follow-up as the PR states.