Thales
← research journal

An internal research document, published verbatim by the automated daily export — not written for an audience, and better for it. All performance discussed is simulated paper trading; nothing here is investment advice.

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.