# DISMISSED — DSP-2 — PR #193's named cause for the VRP dispatch stall is falsified by its own table status: dismissed as an OPEN ROW by panel run 31 (2026-09-30) · kept as a correction of record, because the note it corrects self-merges unreviewed · sibling to `dsp-1-dispatch-liveness-attested-on-send.md`, which it EXTENDS with new evidence rather than relitigating --- ## Why this is a dismissal and not a row The defects below are real, reproduced, and were each verified twice this run (change-review lens, then the chair). They are nonetheless **not queue work**: - **Wrong latency class.** `research/**.md` is on the `auto-merge-records.yml` fast path, so **PR #193 self-merges with no human review the moment Actions returns** (~2026-10-01, when the allowance resets). A row in `open/` waits weeks. A file in `dismissed/` merges at the same latency as the note itself. - **Wrong shape.** This is a one-file prose edit (~0.4 person-days in total), not an experiment with a mechanism, a data plan and a kill criterion. - **The queue is over its cap.** True post-merge count is **13 items against a cap of 12** (main 12, minus FIN-4 via #190, plus LAB-1 via #188, plus FRZ-1 via #192). The eviction nominee is RWG-1, whose leg 3 is that a drawdown-kill-switch liquidation of the meanrev book would be blocked by the runaway guard as armed. Trading a live-path safety row for a markdown proofread is indefensible. Recorded here so that the note's own closing instruction — *"so the next session does not re-derive either"* — does not stop future routines investigating a cause that is dead. --- ## What #193 gets right, and it is the part that matters The measurement is sound. Every `workflow_dispatch` timestamp in the note's table reproduces to the second against the Actions API. The realised cost is real: `data/state/vrp/order_log.jsonl` carries a `manage:close` on a live SPY put credit spread on **2026-09-18**, roughly two hours down the tape from where the schedule intends. The *phenomenon* is not in question. Only the cause, the counts, and the claimed detector coverage are. ## Correction 1 — the "one structural difference" is not a difference The note (`:50-64`) says: *"VRP is the only one of the three workflows whose `workflow_dispatch:` carries an `inputs:` block… `paper-trading.yml`, `paper-trading-meanrev.yml` and `skew-snapshot.yml` all declare a bare `workflow_dispatch:` with no inputs."* `grep -rn "inputs:" .github/workflows/` returns three hits: `_alert.yml:29`, `paper-trading-vrp.yml:29`, and **`paper-trading-meanrev.yml:31`**. meanrev carries an identical `inputs: dry_run: {type: boolean, default: false}` block. **The note's own table is the negative control.** Its meanrev column shows meanrev dispatched within **2–4 seconds of momentum** on 09-16, 09-17, 09-18, 09-23, 09-24, 09-25 and 09-29 — every one a day it bolds VRP as late, including the largest lag in the whole table (09-17, **+301 min**). The workflow carrying the claimed cause is never late. A stdin-block mechanism would also have to bite meanrev *first*: it is second in the dispatcher's argv loop, VRP third. **Stated precisely, because the bound matters.** The meanrev block landed 2026-09-14 (`fbdf0dd`; its parent has zero `dry_run` hits), so the control covers **7 of the 9 bolded days** — 09-16 onward — including two of the three material stalls (09-17 and 09-18) but **not** 09-11 (+99), which predates it. Seven consecutive dispatch days of a workflow with the identical block and no lateness is sufficient to falsify the lead; claiming it covers all nine, or all three stalls, would be the same overclaim this file exists to correct. **The offered fourth data point does not hold either.** The note cites `skew-snapshot.yml` as a no-inputs control, *"punctual on all 14 of its dispatch days"*. On **09-14, 09-15, 09-21 and 09-23** that workflow received no `workflow_dispatch` at all (only the late `schedule` run). A no-inputs workflow, dispatched alone, silently got zero dispatch on at least four weekdays in the same window — so "no inputs ⇒ dispatched reliably" is false, and the note's own denominator (14 of 19) already concedes five missing days while the prose reads as a clean control. **A third mechanism the note does not rule out is already in this directory.** `dsp-1`:69-70 records that the **09-16 17:22:59Z re-dispatch was vrp-only, not the agent's three-workflow batch — a targeted human action**. That is the exact timestamp #193 tables as VRP's morning dispatch arriving 166 min late. If those late events are vrp-only make-up dispatches, the failure is "the batch dispatched no VRP at all" — identical to the four skew misses and to 09-14 — and the lag column is measuring human repair latency, not a hung call. The note's confound section asserts only two explanations exist. **Consequence if uncorrected.** The note asks the owner — the only person who may touch `scripts/dispatch_workflows.sh` — to add `-f dry_run=false` **at VRP's call site only**, an asymmetric change against a non-difference, and it demotes the argv-reorder experiment to *"if the log is inconclusive"* when that is now the only surviving hypothesis in its own hypothesis space. ## Correction 2 — it resurrects a gate number a merged record retired The note (`:48`) says the 09-18 close happened *"49 trading days into its 126-day forward gate."* The pinned evaluator disagrees. `thales --sleeve vrp forward-gate` prints `min_live_trading_days | 38 | >= 126`, "clean clock since 2026-07-27". `data/state/vrp/equity_history.jsonl` has exactly **49 lines**, first date **2026-07-13** — so 49 is the raw row count from activation, ignoring the pre-registered once-only clock reset whose entire purpose is that the pre-amendment days must not count. **That exact wrong number was retired eleven days earlier by a merged record on main**: `research/2026-09-18_two_forward_gate_numbers_were_wrong.md` (PR #178, commit `a325c3c`) pins `marks_since_activation 49 / marks_since_clean 39 / returns_since_clean 38`. #193's own PR body says 38/126, so the note contradicts both main and itself. **Consequence if uncorrected.** The next reader — the daily audit, which declares itself a standing re-reader of this PR, and the ~Jan-2027 forward-gate read — inherits a maturity figure 11 trading days ahead of the gate, on the one live sleeve whose activation that gate decides. The identical error already misled the 09-17 daily audit into printing "48/126"; #177 is open about it. ## Correction 3 — incidence and detector coverage are both overstated - The prose says VRP was late on *"7 of the 18 dispatch days"*. **The table bolds 9**: 09-04 +7, 09-11 +99, 09-16 +166, 09-17 +301, 09-18 +119, 09-23 +115, 09-24 +16, 09-25 +161, 09-29 +116. The PR body compounds it by listing 8 lag values against 9 dates. - The prose says open PR #174 *"would have raised all seven of these days"*. #174's `scripts/detect_dispatch_gap.py` sets `LATE_AFTER_MINUTES = 90` and puts `failure` in `NON_DECISIVE_CONCLUSIONS`. So 09-04 (+7) and 09-24 (+16) are under the bar, and 09-23 / 09-25 / 09-29 sit inside the billing refusal where every run concluded `failure` and is non-decisive by design. **#174 raises 4 of the 9** — 09-11, 09-16, 09-17, 09-18. - The table holds 18 rows; 2026-09-03 → 09-29 holds **19 weekdays**. The missing row is **09-14**, the one day the dispatcher created no VRP dispatch at all (`dsp-1`:20). The reliability denominator silently excludes its worst day. ## Correction 4 — four of the nine "late" days moved no decision at all Not caught by the lens; found at review. **Every sleeve's state stops at 2026-09-18** — `data/state/vrp/equity_history.jsonl`, `data/processed/equity_history.jsonl` and `data/state/meanrev/equity_history.jsonl` all end there, because Actions has refused every job since 09-21. So the table's rows for 09-23 (+115), 09-24 (+16), 09-25 (+161) and 09-29 (+116) are dispatch events for runs that **never executed**; they cost nothing. Netting this against corrections 1 and 3, the live-regime truth is **12 dispatch days, 5 lates, 3 material stalls** (09-11 +99, 09-17 +301, 09-18 +119) — with 09-16's +166 attributable to a human re-dispatch per `dsp-1`. Not "7 of 18". The note's numerator and denominator are both wrong, in opposite directions. ## What should replace the lead The **argv-position hypothesis is now the only survivor** in the note's own hypothesis space, and the cheapest resolution is unchanged and owner-side: read `logs/dispatch.log` on the Mac for the affected mornings and establish whether the call hung, failed, or was never made. That distinguishes a stalled loop from a batch that dispatched no VRP — which is the fork corrections 1 and 4 open, and no repo-side evidence can close it. Note also that the proposed ` 90 min while VRP's is on time, which would break the negative control this file rests on; - **(c)** #193 merges and the daily audit or any later memo quotes "49 trading days", "7 of 18", or "#174 covers all seven" as established fact — the correction has then failed to land and belongs in `open/` as a row; - **(d)** the `inputs:` block is removed from `paper-trading-vrp.yml` on the strength of #193's lead and the lateness persists, which is the note's own experiment run backwards and settles it; - **(e)** `dsp-1`'s clause (a) fires — a session trades after the 16:00 ET close with the dispatch layer having failed silently. It has **not**: the worst live-regime lag, 09-17 at 19:49:11Z, is 15:49 ET, inside the session. *Panel-Item: run 31 change-review lens (corrections 1–3) + adversarial review (correction 4); three candidates folded into one file by the reviewer's ruling that they are one edit to one unmerged document.* --- ## 2026-10-01 append — THE CORRECTION LANDED, and the symptom got worse Dated append rather than an edit above the line, so the sequence stays readable. **All four corrections are in #193, by its author's own hand.** Commit `d31afd0` on `audit/vrp-dispatch-stall-2026-09-29` (2026-09-30 ~22:10Z) retracts the named cause and credits this panel run: *"The mechanism proposed on 09-29 … is false. `paper-trading-meanrev.yml:30-35` carries an identical `dry_run` inputs block … Found by research panel run 31 (PR #194); re-verified here by reading both workflow files."* The PR title now carries the retraction too. Corrections 2 and 3 are folded in verbatim (38 not 49, late-day count 9 not 7, #174 covers 4 of 9 at its 90-minute bar), and the proposed remedy is narrowed to `timeout 60` plus `