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):

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:

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/<date>.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/<date>.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.