# DLV-1 — a steward record whose PR is unmerged when Friday's digest gathers loses its `NEEDS-OWNER:` lines from EVERY digest, permanently: the window is exactly one Friday wide and there is no restatement duty. #260 is unmerged today, and one of the two asks it carries is the mitigation for a trading-stopper status: open · raised panel run 42 (2026-10-21; queue-and-clocks lens candidate C1, verified independently by the chair against the live function) · class: **G2 loudness on the owner's only channel** + the producer/reader-disagreement class NOL-1 names · judgement: **YES** · effort ~0.25 pd (~0.05 pd for the loudness floor alone) · horizon: **decidable immediately; bites this Friday 2026-10-23 and every Friday the auto-merge gate is dark (~2026-11-01)** --- **Plain-language summary for an owner reading one paragraph.** Since 2026-10-07 you read one email a week, and the decisions only you can make reach you as `NEEDS-OWNER:` lines at the top of it. Those lines are collected from the steward's daily written records. The collector reads the records **off disk**, over a window exactly seven days wide, so each record is seen by **exactly one** Friday email. If a record is still sitting in an unmerged pull request when that one email is assembled, its asks are not late — **they are gone, from that email and from every future one.** Auto-merge has been dark since 2026-10-19 and records are being merged by hand, so this is live right now: the steward's 2026-10-20 record is unmerged as this is written, and one of its two asks is the instruction telling you which four files must change alongside the 2026-11-02 cron move — the mitigation for a defect that otherwise stops all three sleeves from trading. --- ## The mechanism, CONFIRMED-BY-EXECUTION `_gather_steward_week` (`src/thales/execution/fleet_digest.py:547`), called with the default `days=7` at its one call site (`:704`): ```python lo = today - timedelta(days=days) for p in sorted(Path(root).glob("*.md")): # reads main, on disk d = date.fromisoformat(p.stem[:10]) if not (lo <= d <= today): continue needs.extend(ln.strip() for ln in lines if ln.strip().startswith("NEEDS-OWNER:")) ``` The docstring states the design in its own words (`:565-574`): > *"The inclusive edge makes each report appear in **exactly one** Friday > digest: the previous Friday's lands in this week's, this Friday's lands in > next week's."* **"Exactly one" is what makes a miss permanent.** A record has one window and no second. The digest runs from a synced `main`, so a record in an unmerged PR is simply not on disk when the gather runs; by the next Friday its date is below `lo` and it can never be gathered again. Measured on the pinned `origin/main` snapshot using the real gather function, with #260's blob present and absent: | 2026-10-20 record | 10-23 window | 10-30 window | |---|---|---| | present (merged) | 3 reports, **7** `NEEDS-OWNER:` lines | — | | absent (unmerged — today's state) | 2 reports, **5** lines | 10-20 excluded (`lo` = 10-23) | Arithmetic check on the second column: `lo = 2026-10-30 − 7 = 2026-10-23`, and `2026-10-20 < 2026-10-23`, so the record is outside the window on the only other Friday that could have carried it. ## Why it is not merely "the blackout" The blackout is the trigger; **the one-Friday window is the defect.** The exposure is also not new in kind — `ops/STEWARD.md` §5 *assumes the problem away*: it instructs the steward to write the record and parenthesises *"records class: it auto-merges"*. Auto-merge has now been dark twice in a month (2026-09-21→09-30 and 2026-10-19→~11-01). There is **no restatement duty anywhere** in code or in `ops/STEWARD.md`. What exists is one steward's discretionary habit, visible verbatim at `research/steward/2026-10-19.md:118-120`: > *"I am not restating it as a NEEDS-OWNER today because there are four asks > already. **I will if it has not moved by Thursday.**"* That deferred item is the two 60-captured-session clocks with no evaluator and no `NORTHSTAR.md` §6 row — and the Thursday record that would carry it faces the same dark gate. The loss is silent in both directions: the digest never reports that a weekday in its window had no record, and nothing audits delivered-against-written. **Precedent, on this exact function.** Panel run 37 (#227) found and fixed a strict-`<` lower edge here whose effect the docstring now records: *"every Friday report and every `NEEDS-OWNER:` line in it reached no Friday digest, ever, in the one channel the delegation created."* The shop has already paid once for a one-window-only delivery defect in `_gather_steward_week`. This is the same failure reached by a different route — the record missing rather than the edge excluding it. ## The casualties are the items closest to lapsing Not hypothetical, and not chosen for effect — these are the three nearest entries on this run's own expiry watch: 1. **#260's DST ask** — names the four prose files that must change in the same commit as the 2026-11-02 cron move. Without it, the move reds the pre-trade gate and **all three sleeves submit nothing** (LAB-1 leg 3). 2. **The §6 / evaluator ask** — deferred to Thursday 10-22, into the same hole. Two clocks mature 2026-11-02 and 2026-11-05 with no evaluator, against `NORTHSTAR.md` §6's own requirement that every entry have one before maturity. 3. **RAD-1's ruling** — due before ~2026-11-02, owner-only. ## Remedy, cheapest first - **(a) Loudness floor, ~0.05 pd.** Have the steward section of the digest name any weekday inside its window with no `research/steward/.md` on `main` at gather time. A dropped record becomes visible instead of silent. This does not recover the asks; it stops the silence. - **(b) The real fix, ~0.25 pd.** Replace the fixed `lo = today - 7` with a persisted high-water mark (the last report date actually delivered) and gather `(hwm, today]`, so a late-merged record lands in the first digest after it merges rather than never. **(b) subsumes (a).** Observability tier only: no trading path, no config value, nothing pinned, no frozen text. ## Pre-registered kill criterion It dies if, over **two consecutive Friday windows in which at least one weekday in the window has no `research/steward/.md` on `main` at gather time**, the delivered digest already names the missing date(s) — i.e. the loss is already loud and only the recovery is missing. It **also** dies if the owner or the steward rules that an unmerged record's asks are correctly dropped because anything that matters gets restated. In that case the ruling carries a mandatory corollary: **the restatement duty must be written into `ops/STEWARD.md` §5**, because today it is one steward's discretionary habit rather than a rule, and §5's standing claim that records auto-merge must be struck in the same edit. Recorded here so that ruling cannot be made without its corollary. It does **not** die because auto-merge comes back on ~2026-11-01. That removes this instance of the trigger, not the window. ## Slot arithmetic Filed with `open/` at 12 of 12, so this is the 13th and triage's mechanical overflow rule applies at the 2026-10-26 sweep. It should not be the overflow: **NOL-1 fires its own criterion on Friday 2026-10-23 and frees a slot**, so the sweep re-ranks at 12 of 12 with nothing evicted. The pre-declared eviction (DGX-1) rests on a rationale run 41 showed was falsified by #249, so that ranking needs re-stating before the sweep regardless of this row. **The immediate action is not this row.** What prevents Friday's loss is **merging #260 before the 10-23 digest gathers**, which is the steward's own act tonight and needs no approval. This row is the structural fix so that the next dark gate does not cost the next set of asks. ## Prior art checked `grep -rniE "unmerged|not merged|merged after|hand-merg|auto-merge.*dark|exactly one Friday"` across all four `research/queue/` dirs → nothing. `AUDIT.md:243` is the nearest class (*"the last weekly audit's PR has never merged, so main has been carrying records it knew to be false"*) but concerns record **truth**, not the delivery window dropping asks. NOL-1 is truncation **inside** a rendered line — this is a record that never reaches the renderer. `dismissed/oad-1` is a **dark routine** versus a dated condition; here the steward ran and wrote the record, and it simply cannot reach `main`. `dismissed/fos-2-fleet-email-missing-streak-split` and `dismissed/f2-reopen-digest-count-parser` are different surfaces. No overlap. --- ## UPDATE 2026-10-21 ~23:30Z — this week's casualty was avoided; the defect is untouched **#260 merged** (`b550649`), so `research/steward/2026-10-20.md` is on `main` well before Friday's gather and its two `NEEDS-OWNER:` asks — including the four-file DST instruction — will reach the 10-23 digest. The *immediate* loss this row was filed to prevent did not happen. **Nothing about the row changes.** The window is still exactly one Friday wide, `ops/STEWARD.md` §5 still asserts that records auto-merge, auto-merge is still dark (every `auto-merge-records` run today failed in 4–5 s across five unrelated branches), and there is still no restatement duty and no loudness floor. What was avoided was avoided by a hand merge inside the window, which is the discretionary habit this row says is not a mechanism. The steward's deferred Thursday ask — the two 60-session clocks and their missing `NORTHSTAR.md` §6 rows — faces the same gate tomorrow, so the next test of this is 2026-10-22/23, not next month.