[jehanazad]

Summary

Switches the known lane on staging from shadow to binding, one step ahead of production, so staging-app.retina.fm draws the lane's solves and claimed ADS-B targets. Staging mirrors production's real nodes, so this is the rehearsal of production's own switch: the map there shows what app.retina.fm will show when docker-compose.prod.yml follows in a second PR.

Why now

Shadow was the measuring stage. On production (2026-10-01) the single-node arc placements the map draws instead sat a median 1.49 km (p95 31.5 km) from the aircraft, while the lane's withheld truth_match solves measured 0.49 km (p95 1.72 km). Since #671, a solve whose delay loci barely cross is withheld too, so the shallow co-sited pairs that produced ghosts on test no longer publish.

Changes

• docker-compose.staging.yml: KNOWN_LANE_MODE=binding, with the reasoning in the comment. ADSB_FALLBACK_ENABLED=1 unchanged.
• deploy/check-env-parity.py: a staging-scoped allowance for KNOWN_LANE_MODE only, marked temporary. The fallback flag stays compared, so staging remains production's rehearsal there.
• backend/tests/test_env_parity_scoping.py: staging may diverge on the mode, still may not on the fallback flag.
• docs/architecture.md: the flag table's staging column.

Test coverage

• deploy/check-env-parity.py passes locally (staging and test in parity with production).
• test_env_parity_scoping.py, test_deploy_workflows.py, test_env_example.py: 285 passed. Lint hooks clean.

Review notes

• Binding is lane-wide. The adsb-service fallback's claims, made for nodes that send no ADS-B of their own, are drawn at the service's fix (adsb_single_node / adsb_multi_node). Those icons are the transponder's position, not a radar estimate; the map labels them as such.
• What to look at on staging after the deploy: aircraft-live.json should carry multinode_solve entries with adsb_hex and adsb_single_node entries, and far fewer single_node_ellipse_arc; solver-stats known_lane.published > 0 with publish_weak_geometry counting the withheld shallow solves.
• Follow-up PR moves docker-compose.prod.yml to binding and deletes the parity allowance. Nothing else should touch that allowance.

🤖 Generated with Claude Code

[claude]

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

---

Review: Bind the known lane on staging (#684)

• Gather context (diff, CLAUDE.md, ONBOARDING.md)
• Review docker-compose.staging.yml changes
• Review deploy/check-env-parity.py changes
• Review backend/tests/test_env_parity_scoping.py changes
• Review backend/services/health.py changes
• Review docs/architecture.md changes
• Post final review

Summary: This is a clean, well-scoped flip of KNOWN_LANE_MODE from shadow to binding on staging, with the parity check and its tests updated in lockstep. The reasoning is documented inline exactly where CLAUDE.md/ONBOARDING ask for it (the compose comment, the allowlist comment, the docstring).

Findings:

1. Allowlist and tests are correctly scoped and symmetric. deploy/check-env-parity.py's new ("staging", r"...KNOWN_LANE_MODE$") entry only exempts the one key, leaving ADSB_FALLBACK_ENABLED compared — matches the PR's stated intent exactly. test_env_parity_scoping.py's test_staging_may_not_diverge_on_the_fallback / test_staging_binds_ahead_of_production assert both halves of that, replacing the old parametrized pair that asserted the opposite for KNOWN_LANE_MODE. Good — I didn't find a gap where a key could silently widen back to every environment.

2. Production and the new allowance line up. docker-compose.prod.yml:78 still sets KNOWN_LANE_MODE=shadow, consistent with the PR body's "one step ahead" framing and the "TEMPORARY" marker on the allowlist entry that the follow-up PR is supposed to remove.

3. Minor, out-of-scope nit — backend/services/health.py:16: this diff is just a blank line inserted between import os and the try: import resource block. It's unrelated to the staging/known-lane change and doesn't belong in this PR's diff (likely a stray formatter touch). Harmless, but worth dropping or splitting out if you want the PR to stay tightly scoped to what the title/body describe.

4. docs/architecture.md:135 — the Staging column for KNOWN_LANE_MODE now reads `binding` (production: `shadow`) since the table has no dedicated production column. That's a reasonable way to surface the divergence given the existing table shape, not a bug — just flagging it so the parenthetical doesn't get lost/forgotten when the follow-up PR lands and this should collapse back to a plain binding.

Not checked: I wasn't able to execute deploy/check-env-parity.py or the pytest suite in this sandbox (shell execution for test/validation commands isn't available to me here), so I verified the allowlist/test logic by reading rather than running it. The PR body already reports both green locally (285 passed, parity clean), which lines up with what the code reads as doing.

No functional issues found. The compose comment, allowlist comment, and test docstring all independently told the same story (binding on staging, shadow still on prod, fallback flag unaffected), which is exactly the kind of cross-file consistency this repo's parity check exists to protect.
· branch