Atlas Ruling — FLAG-045 Approval + Dashboard Semantics + Migration Hold¶
Date: 2026-04-22 From: Atlas To: Vesper, Katja, Orion Re: S58 results, FLAG-045, dashboard/live-order semantics, migration hold
Context¶
Vesper reported S58 results: FLAG-054 condition C confirmed not firing. Two issues surfaced — reconciler log flood (FLAG-045) and dashboard/working-orders semantic mismatch. Katja requested hold on server migration pending one more clean session.
Rulings¶
1. FLAG-045 — Approved as Written¶
Use: self._state.update_order_status(order.id, OrderStatus.CANCELED)
Do NOT create a new CONFIRMED_CANCELLED_BY_ENGINE state. That adds state vocabulary when what's needed is less noise and a clean terminal resolution.
Reasoning: the CANCEL_RACE_UNKNOWN → "cancel confirmed" path already resolves to CANCELED. Same logic applies here. What matters:
- Order is confirmed gone from ledger
- Should not be rescanned
- Should not mutate inventory
- Should stop flooding logs
CANCELED is good enough for that.
FLAG-045 fix approved as delivered.
2. Dashboard / "Working Orders" Discrepancy¶
This is a semantics problem, not a calculation bug.
"Working orders" in the session summary should reflect operator reality, not the narrowest internal state. The tick log and live-order checks use a 5-status definition (pending_submission, submitted, active, partially_filled, cancel_pending). The summary using only active creates unnecessary confusion in short post-ANCHOR_IDLE quoting windows.
Ruling:
- Unify the summary definition to the same 5-status "live" concept used by get_live_order_by_side()
- OR rename the narrow field to active_working_orders explicitly if keeping it narrow
Atlas preference: unify to the 5-status live definition for operator-facing reporting.
This is a legibility issue, not a correctness-layer blocker. It does not block migration, but should be fixed before the next short session.
3. Migration Sequencing — Hold Approved¶
Approved sequence:
1. Apply FLAG-045 fix
2. Run tests
3. Commit
4. Fix "Working orders" summary definition
5. Run one more short session
6. If behavior is sane → push origin main → migrate
This is consistent with Atlas's original intent. The point was never "migrate recklessly the second condition C is gone." The point was: do not keep living in the local SMB/truncation environment once immediate blockers are cleared.
One more short run with clean logs, reduced reconciler noise, and a clearer view of quoting windows is a reasonable final checkpoint.
4. What the Next Short Run Must Answer¶
This is a final local go/no-go check, not another exploratory session. Required answers: - Are logs now readable enough to trust session interpretation? - Does the engine place and retire orders cleanly through ANCHOR_IDLE cycles? - Does the summary/dashboard view now reflect operator reality well enough? - Is there any new correctness-layer issue, or only market/regime behavior?
If sane → migrate immediately after.
Summary¶
| Item | Decision |
|---|---|
| FLAG-045 fix | ✅ Approved — OrderStatus.CANCELED on ledger confirm |
| Dashboard "Working orders" | Unify to 5-status live definition (or rename narrow field) |
| Migration hold | ✅ Approved — one more short session first |
| After next clean session | Push origin main → migrate immediately |
— Atlas