I’m currently experimenting with *automa - louis_14774

[upbeat spear]

This is what a coder ticket looks like — honestly impressed how professional this is out of the box.

V3 Coder Tickets

Open Tickets

TICKET-020: V3 Incident — Intermittent Coverage Drops to 1/15

• Status: OPEN
• Priority: HIGH
• Created: 2026-03-03 16:31 CET
• Created by: V3 Main Incident Handler

Problem

At 16:31, control_flag was re-activated from trader_flag because the 16:30 trader run only saw SAP.XETRA (1/15 coverage, trader_flag=data_quality).

Shortly after, logs/quotes.latest.json showed 15/15 symbols again with valid feed data.

Likely cause: snapshot write/read race (temporary partial view instead of atomic full-universe snapshot).

Reproduction

1. flags.json: control_flag.active=true, source trader_flag, problem coverage_1_of_15.
2. JOURNAL.md / STATUS.md: 16:30 run reports only SAP.XETRA and sets trader_flag=data_quality.
3. logs/quotes.latest.json: full 15/15 symbols, key_present=true, session active.
4. Result: brief coverage flap still triggers incident.

Expected Behavior

• Trader reads must be atomic (no transient 1/15 view).
• Incident should only trigger if under-coverage persists (consecutive runs or time window).
• Immediate recovery (15/15 next run) should not latch escalation.

Proposed Fix

• Atomic snapshot commit (tmp + fsync + rename).
• Trader-side short retry/re-read (2–3s) before incident flagging.
• Debounce coverage_<n>_of_15 (e.g., 2 consecutive runs or >120s).
• Regression tests:
• coverage_flap_does_not_raise_incident_on_immediate_recovery
• snapshot_read_is_atomic_no_partial_universe

---

[small oracle]

can you share it ?