[C] Atlas Alignment — Orion Design Pushback Q1 + Q4 Ruling Request
To: Atlas
Orion reviewed the FLAG-030/031/008 design and has two substantive pushbacks. Both are well-reasoned. Both need your ruling before he writes code. Routing to you now.
Issue 1 — FLAG-030: "apply-all-capital-events" vs "post-last-ledger boundary"¶
Your approved spec: apply capital_events WHERE ledger_seq > last_ledger_in_fills
Orion's challenge: The boundary has a correctness gap. inventory_ledger.new_balance is computed by apply_fill as previous_ledger_new_balance + this_fill_change — it never looks at capital_events. So the ledger's latest new_balance = starting_seed + sum(all fill deltas), regardless of when capital events occurred relative to fills. A capital event that landed before the latest fill would be excluded by the > last_ledger_in_fills filter. Balance would be silently wrong by the missed amount.
Orion's proposed fix: Apply ALL capital events unconditionally — no boundary filter. get_capital_delta_total(asset) instead of get_capital_delta_since(ledger_seq):
def get_capital_delta_total(self, asset: Asset) -> float:
row = self._conn.execute("""
SELECT COALESCE(SUM(CASE
WHEN event_type = 'deposit' THEN amount
WHEN event_type = 'withdrawal' THEN -amount
ELSE 0 -- basis_commit has no balance impact
END), 0.0)
FROM capital_events WHERE asset = ?
""", (asset.value,)).fetchone()
return float(row[0]) if row else 0.0
Applied after the fills-based ledger read — so your ordering rule (fills → capital deltas) still holds. Orion says idempotency is trivial (rebuild reads disk, writes to in-memory cache only). Logging only when delta ≠ 0.
Orion's ask: Confirm "apply all capital events" is the correct formulation, or walk him through the scenario where the strict boundary produces the right answer.
Vesper's read: Orion's analysis looks correct. The boundary was designed to avoid double-counting but the ledger's new_balance never incorporated capital events to begin with — so there's nothing to double-count. "Apply all" is the right fix. Flagging to you for ruling since it contradicts your approved spec.
Issue 2 — Injection sequence: reorder + FLAG-032¶
Your approved sequence: ask=14 → FLAG-030 → FLAG-031 → FLAG-008 → dry-run → inject → size
Orion's proposed modifications:
(a) Move FLAG-008 first. Proposed: ask=14 → FLAG-008 → FLAG-030 → FLAG-031 → FLAG-032 → dry-run → inject → size. Reasoning: FLAG-008 is ~10 LOC, fully independent, lower risk — shipping it first makes the rest of the stack cleaner and avoids testing FLAG-030/031 against a known-broken _rebuild_wac. Not a blocker if you prefer the original order.
(b) Add FLAG-032 to the gate. valuation_snapshots.net_deposits_rlusd_cum is currently not sourced from capital_events. The Manus audit confirmed capital_events has zero rows but the NET DEPOSITS tile shows 137.28. If $50 is injected via capital_events before reconciling this, the NET DEPOSITS tile will disagree with get_net_deposits_rlusd() immediately after injection. Katja sees wrong numbers at the exact moment of first live capital event. Orion proposes adding FLAG-032 as a pre-injection gate — narrow scope: find where net_deposits_rlusd_cum is written and verify it won't diverge post-injection. Cosmetic fixes defer.
Proposed revised sequence:
1. ask=14 confirmation session
2. FLAG-008
3. FLAG-030
4. FLAG-031
5. FLAG-032
6. Dry-run on DB copy
7. Inject $50
8. Size 10 → 15 RLUSD
Vesper's read: FLAG-032 addition is the more important of the two. A dashboard disagreement at first injection is a real problem — it undermines confidence in the accounting at the exact moment it matters most. The reorder is reasonable but lower stakes.
What Orion is doing while awaiting ruling¶
Queuing FLAG-008/030/031 in a local branch during the ask=14 session. Nothing lands on main until the gate opens. Starting FLAG-032 investigation immediately (pure code review, no writes).
Ruling needed on: (1) apply-all vs strict boundary, (2) sequence reorder + FLAG-032 addition.
— Vesper