# TRG-1 — the triage prompt mirror still names the OWNER as the gate-holder and omits the new dismissed/ sweep duty, four days before that sweep is the mechanism discharging three separate handovers

status: **dismissed** 2026-10-08 (panel run 37) · class: prompt rot (the class CLAUDE.md warns about by name) · effort ~0.1 pd but **not executable by anyone in the loop** · raised and killed in the same run

---

**Plain-language summary.** Each cloud routine has a prompt stored outside the
repository (on claude.ai), and the repository keeps a copy — a "mirror" — so
drift between the two is visible. On 2026-10-07 the owner delegated both of his
gates to a new agent, the steward, and rewrote the triage routine's procedure
file to match. The triage **prompt** was not rewritten. It still calls the
research-queue approval "THE OWNER'S", still describes the owner's gate as the
thing to keep cheap, and — the part that actually matters — its list of "the
work" does not mention the new duty to sweep the dismissed items for reopen
conditions. We looked hard at this and concluded it is not worth a queue slot.

## Why it is not a defect of substance

**The one dangerous leg is mitigated in CODE, not prose.** The stale prompt
still says *"Push `message.md` to branch `outbox/triage` — the relay mails it to
the operator"*, while the owner's instruction is that nothing but the Friday
digest is mailed. That cannot cause an unwanted email: the gate is in
`scripts/outbox_backlog.py:71-72,147-166` (`DEFAULT_EMAIL_POLICY =
"weekly_digest_only"`, withheld with a printed notice), and
`.github/workflows/routine-outbox.yml`'s header states the design intent
verbatim — the policy is *"loaded from origin/main at run time — so it governs
every outbox branch, including those still running an older copy of THIS
file."* That is defensive design working exactly as intended, and it is the
strongest reason this row dies.

**The prompt's own first instruction routes past its stale body.**
`ops/prompts/triage.md:25` reads *"Read `ops/QUEUE_TRIAGE.md` FIRST and follow
it exactly"*, and that file carries both the global redirect
(`ops/QUEUE_TRIAGE.md:9`: *"Wherever this file says the owner approves, merges
or decides a queue item, read the steward"*) and the new sweep itself
(`:94-102`). The prompt header also states *"If live and mirror disagree, the
MIRROR's rails win and the disagreement is a finding"* — so an obedient triage
reaches the current text regardless. The actor drift (owner → steward) is
therefore covered; **only the sweep is an omission rather than a
contradiction**, because a routine following an inlined enumeration has nothing
to redirect.

**And the fix is unreachable from inside the loop.** The live prompt lives in
the claude.ai control plane. `ops/STEWARD.md` §0 limit 9 forbids the steward
from creating, editing, running or deleting any routine, its own included;
`^ops/` is in `scripts/automerge_guard.py` DENY_PATTERNS, so the mirror edit
needs a human merge too. Only the owner or an interactive session can land
this. **Spending a queue slot (and, at 12/12, an eviction) on something nobody
in the loop can execute is implementation fantasy** — the adversarial
reviewer's wording, and it is right.

## What we are NOT claiming

That the omission is harmless in principle. The 14-day dismissed sweep added at
`ops/QUEUE_TRIAGE.md:94-102` is the mechanism that discharges three separate
run-36 handovers at once (gap-1 maturing 2026-10-19; `cut-1`'s legs (a)/(d) at
2026-10-16 and 10-19/20; and HIRE-1's previously actor-less auto-reopen). If
the one duty absent from the prompt is the duty that does all that work, the
mirror convention has failed in the exact way CLAUDE.md warns about — *"an
inlined prompt rots invisibly, and two already did."* We are claiming only that
the canonical file is read first by instruction, so the probability of the
omission biting is low, and the remedy is owner-side either way.

## Reopen condition (dated, and it is a real tripwire)

**Reopen if EITHER leg fires:**

- **(a)** any triage run from **2026-10-12** onward produces an outbox report
  (`outbox/triage` `message.md`) with **no `dismissed/` reopen-condition
  section** — i.e. the omission demonstrably propagated into behaviour; or
- **(b)** a dismissed item's written reopen condition fires and goes
  **unlisted** by the next triage run.

On either, mint the row and route the prompt edit to the owner as a
`NEEDS-OWNER:` line. **First evaluation is the 2026-10-12 report**, which must
list `hire-1` if frontier-cadence counter (c) fires on that date. **If the
2026-10-12 and 2026-10-19 reports both carry the sweep, this dismissal becomes
permanent** and prompt-vs-procedure omissions of this shape are closed as a
class.

*Prior art checked: no slug covering `ops/prompts/` rot exists anywhere in
`research/queue/{open,approved,built,dismissed}/`, and the frozen
`research/RESEARCH_QUEUE.md` has none. Spends no registry row and no trial
budget.*