A sentinel — an ops role that reads the fleet's own telemetry and flags what a human should see

[dan-claude-bot]

Moved from #128, minted by triage on 2026-07-28 as a "design record". It is carried verbatim below, unedited. It is here rather than on the board because triage minted it against its own contract, and because the epic label it carried was not true.

Why this is a thread and not an issue

Its own header, quoted exactly:

Do not claim this. It depends on telemetry that does not exist yet, and its central design question — what makes an agent's judgement about the fleet trustworthy — is unanswered.

An issue whose central design question is unanswered is not a work order; a builder handed it would guess, and guessing is the failure the triage door exists to prevent (TRIAGE.md, which names the move directly: "Mint an issue to 'discuss' something — that is a discussion").

The epic label was false, and it hid the problem

Under LABELS.md, epic means "organizes other issues via a dependency-ordered task list". This one organized zero issues across four days. It had no children, no checklist, and no dependency order — it was a design record wearing an organizer's label.

Worse, that label put it in a contradictory state on the board: epic exempts an issue from the work-queue invariant, so it carried no queue label at all, while its Dependencies section said in prose "Blocked by #123." The board said epic; the body said blocked. Both cannot be true, and a scanning agent reads the label.

This is the second instance found today of the same hole — #231 (ex-#109) was a stray that went four days without a needs-triage flag for exactly this reason, because the sweep's invariant exempts epic. An epic label is a place board state goes to hide. Worth its own fix; recorded here and on #231.

Struck by triage, 2026-08-01, against both issues' label events. Neither instance is what that paragraph claimed. #109 was flagged needs-triage thirteen seconds after it opened, and triage removed the flag itself 45 minutes later in the same edit that applied epic (the correction, on #231). And #128 was never a stray at all — triage minted it, at 2026-07-28T21:45:40Z, blocked three seconds later and epic ten minutes after that; no flag was ever owed on it. The paragraph above this one still stands: epic beside a prose "Blocked by #123" was a real contradiction on the board. What it was not is evidence of a defect in the sweep, and no fix is owed anywhere for it.

What survives, because it is the best thing in it

Two decided constraints, neither of which is an open question:

1. The sentinel flags. It never acts.

No label writes, no configuration changes, no stopping a box. It produces a claim, addressed to a human, with the evidence attached. Anything else makes a hallucinated finding into a fleet action.

That is the fleet's own spine — detection and judgment must live in different places — correctly re-stated for the case where the model is the detector. It is the single most important line in the record and it must survive into anything built.

2. danmt's ruling of 2026-07-28, which settles the architecture:

"I literally plan to do telemetry and use real programming to turn that into summaries with multiple indicators. The sentinel agent simply reads the summary and gives an assessment extra."

Most of the work is not an agent. It is the summariser — deterministic code over the ledger — and the agent is a thin, optional layer on top of it.

The outcome: ask — and the substrate comes first regardless

The honest position: there is nothing to summarise yet. #121's ledger (#122) and its aggregation (#123) do not exist, so a sentinel has no input, and the record's own awkward observation stands — "a sentinel costs tokens to tell you about token costs" — which must be measured against #121's numbers rather than assumed.

Two questions, for whenever the substrate lands:

1. What does the summariser emit? The ruling says deterministic code produces "summaries with multiple indicators." Which indicators, and what threshold makes one worth waking a human over? That is a specification a builder can execute; the agent layer on top of it is not, until it exists.
2. What makes the assessment trustworthy? The record's own central question, still open. A concrete sub-question that would move it: does the sentinel's claim carry the evidence rows it drew from, so a human can check the finding without re-deriving it?

@danmt — (1) is answerable before #122 lands and is the cheaper half by a wide margin. Answer it and triage can mint the summariser as a normal issue behind #123, with the agent deferred to a second one.

Board effects. PR #230 references this as Refs #128 for the ARGUS prototype; that reference now points here. The prototypes are design records too, and unaffected.

Nothing is waiting on this thread.

---

The design record, as filed on #128 — verbatim

📝 DRAFT — design record, not buildable work

Filed from the sherpa session at danmt's request: "take all the telemetry, summarize it, and every N time pass it to an ops agent of sorts that looks at it and if there are things to flag, it flags them. Like a sentinel."

Do not claim this. It depends on telemetry that does not exist yet, and its central design question — what makes an agent's judgement about the fleet trustworthy — is unanswered.

Why it is the right instinct

Everything the fleet is about to start collecting — token cost per session and pool (#121), whatever telemetry #126 adds — has the same problem the Actions bill had: it is only useful if somebody looks. The 2026-07-25 Fable burn was diagnosed by hand, after the fact, because nothing was watching. Building the instrument and then relying on an operator to read it re-creates the gap one layer up.

A sentinel is the fleet doing to itself what it already does to repositories: sweep, notice, and wake a human.

The design constraint this fleet already settled

From a box's own self-assessment, and it is the spine of every duty module:

Detection and judgment must live in different places. Every time I've resisted letting a script flip a label when its test was confident, I've been glad — a parser bug becomes a false lead the session rejects, not a wrong board write.

A sentinel inverts the usual arrangement: here the model is the detector. So the rule has to be re-stated for it, and it is the strongest thing this record can contribute:

The sentinel flags. It never acts. No label writes, no configuration changes, no stopping a box. It produces a claim, addressed to a human, with the evidence attached. Anything else makes a hallucinated finding into a fleet action.

The awkward part, stated plainly

A sentinel costs tokens to tell you about token costs. That is not disqualifying — one summarising session per day against five boxes' worth of ledger is cheap next to what it watches — but it must be measured against #121's own numbers rather than assumed, and it is exactly the sort of thing #120 exists to be sceptical about.

Ruled by danmt, 2026-07-28, and it settles the architecture: "I literally plan to do telemetry and use real programming to turn that into summaries with multiple indicators. The sentinel agent simply reads the summary and gives an assessment extra."

That is the same shape #91 found, applied here: most of the work is not a model's. The engine can compute the deltas — this pool spent 3× its trailing average, this box has not ticked in two boundaries, this session ran to timeout four times today. The model's job is the last mile: reading a compact digest and saying which of those matters and why. Feeding it raw logs would be the expensive way to get a worse answer.

It is a new role, and that has a known cost

crew's roles are triage, builder, reviewer. A sentinel is a fourth, and #71 is explicit that a new role changes the engine and its duty lifecycle — a profile is configuration, a role is engine work. #71 also says not to build a plugin system in anticipation, and to generalise only after two more roles exist.

So this is expected to be somewhat messy to add, and that is accepted rather than a reason to defer. Worth knowing before someone estimates it as "another duty module".

The three layers

danmt: "it's a lot of work, probably spans multiple issues." It is, and they are not one deliverable — three layers with a real dependency order and different skills.

Follow-on issues should be cut from this epic after the boundaries are reviewed, the way #109 does it. A likely order:

1. Indicators — deterministic, no model. Take the ledger (run_session records no token or cost figure — capture the usage block and the pool identity #122/crew usage — aggregate the session ledger by credential pool, on the host #123) and whatever telemetry exists and compute signals: spend per pool against its trailing average, sessions ending in TIMEOUT, boxes silent past two boundaries, a duty whose cost per run is climbing. Real programming, testable with fixtures, correct or not correct. This is the substrate and the largest piece.
2. The assessment — the model's last mile. The sentinel reads the computed digest and says which signals matter and why. It sees indicators, never raw logs — feeding it logs would be the expensive way to get a worse answer. It flags; it never acts.
3. The sentinel page. The operator opens the console and sees the telemetry, the signals, and the assessment beside them. Without this the first two are a report nobody reads, which is the failure this epic exists to prevent.

Layer 1 is the critical path and is useful alone — indicators with no assessment are still a dashboard. Layer 2 without layer 1 is a model reading logs, which is the thing being avoided.

Open questions

• Which indicators? Layer 1's content is the design. Get it wrong and the sentinel is either blind or expensive — and unlike the model's half, this part is deterministic and therefore gettable-right.
• What is the cadence? Daily is probably right for cost; a wedged box wants faster, which suggests two different watches rather than one.
• How does it flag? notify.sh's Telegram channel already exists for operator escalation, and reuse beats a second path.
• How is a false flag handled? If it cries wolf twice it will be ignored, which is worse than not having it. Some notion of confidence, or a bounded number of flags per run, is probably required.
• Does it read the ledger only, or the board too? A sentinel that can see stalled PRs and unanswered rulings is more useful and much larger. Probably a later indicator rather than a different epic.

Dependencies

Blocked by #123 — there is nothing to summarise until the ledger exists and something aggregates it. #122 and #123 are the substrate.

Benefits from #109: trend detection needs history, and "this pool spent 3× its trailing average" is a projection over stored snapshots rather than a scan of log files. Benefits from #126 for the same reason if system telemetry lands.

Related to #71 (a role is engine work) and #120 (be sceptical of anything that spends tokens to save tokens).

[dan-claude-bot]

Correction — the "second instance of the same hole" was not an instance

Struck in the body above, against both issues' label events rather than their threads. The full working is on #231; the short version:

• fleet-floor gets a durable SQLite control plane — snapshots, actions, locks, and projections (epic) #109 was flagged, needs-triage at 2026-07-28T15:10:43Z — thirteen seconds after it opened. Triage removed the flag itself 45 minutes later, one second after applying epic.
• DRAFT: a sentinel — an ops role that reads the fleet's own telemetry and flags what a human should see #128 — this thread's own subject — was never a stray. Triage minted it at 2026-07-28T21:45:40Z; it carried blocked three seconds later and epic ten minutes after that. No needs-triage was ever owed, so none was missed.

So there is no defect in the sweep, and nothing is owed to heavy-duty/ceremony — I was about to open a thread there and the timeline is why I did not. epic genuinely is the one queue category the standing sweep cannot re-derive, but that is the design working as LABELS.md states it (intent is hand-set; the reconciler never guesses intent), and the opened-issue path already strips epic from a non-triage mint. The finding that survives is about triage's conduct, not the machine's: do not label a stray epic — it is the one label that makes clearing needs-triage irreversible by machine.

What still stands, unchanged: the paragraph above the struck one — epic beside a prose "Blocked by #123" was a real contradiction on the board — and everything below it. The two decided constraints (the sentinel flags and never acts; danmt's 2026-07-28 ruling that the summariser is deterministic code and the agent is a thin layer on it), the outcome, and the two questions to @danmt are untouched.

[dan-claude-bot]

Correction — this thread's header says #128 closed, and since 13:01Z today that is false. Q1's wake condition also moved, and it moved onto something a builder can start now.

Re-read from /repos/heavy-duty/crew/issues/128/timeline, not from this thread:

• 2026-08-01T13:31:34Z — closed by dan-claude-bot, the move this thread's header describes.
• 2026-08-02T13:01:40Z — reopened by dan-claude-bot; enhancement + blocked + scope:duty applied one second later.

#128 is back on the board as the sentinel chair's charter under #295 — sentinel detects, medic acts, leader rules — minted at danmt's direction beside #225 (leader) and #296 (medic), with the stated reason that "parked-closed made this charter invisible to planning." It declares Part of #295 and Blocked by #163, and its body still carries its own DRAFT — do not claim this header, so nothing here reads as buildable.

What that changes for the two questions

Q2 — what makes the assessment trustworthy — is partly answered, structurally. #295's chair table answers it not by qualifying the sentinel's judgement but by bounding what its judgement can cause:

"its own hard rule stands: the sentinel flags, it never acts — because its claims flow to the medic's ring-bounded authority, never straight to a fleet action"

That is the honest form of the answer and it vindicates the constraint this thread called the spine. The concrete sub-question is still open: does a sentinel claim carry the evidence rows it was drawn from, so a human can check the finding without re-deriving it? That one is a spec detail, answerable with Q1 rather than before it.

Q1's wake condition has moved, and this is the useful part. This thread held Q1 on a substrate that does not exist — #122's ledger and #123's aggregation, neither built. #295 routes it somewhere else entirely:

"the telemetry topic exists — #290 runs it by hand first and its report is the sentinel's job description rehearsed; the standing duty follows"

#290 is ready and unclaimed right now, and its phase 2 enumerates precisely what this thread asked for — sessions by kind, count, duration and outcome per box; the zero-action rate; every human hand-touch; round economics; the windows where the board misreported the ball. Doing that once by hand is the answer to "which indicators, and what threshold makes one worth waking a human over", derived from two real working days instead of guessed.

So Q1 is no longer waiting on @danmt or on #122. It is waiting on a report someone can start today, and the honest instruction to whoever writes it is: the indicator set you end up using is this thread's answer — record it as such, and triage mints the summariser from it.

Outcome unchanged: ask — but the ask is now aimed at #290's output rather than at a person, and its half-life is days rather than a gate. Q2's sub-question stays here for @danmt if it is not settled by the shape of that report.

Nothing is stalled. #128 is blocked behind #163 (0.2.0), #290 is ready and independent of both, and PR #230's Refs #128 now points at a live issue again.

Triage, 2026-08-02.

[dan-claude-bot]

The report that answers Q1 is claimed and in flight

Short update, from label events rather than from this thread. My comment above says #290 is ready and unclaimed right now and that a builder can start it today. One did: @andriujoseba claimed it at 2026-08-02T18:26:00Z and is writing the report on draft PR #311. The line is left standing as the record of when the instruction was issued, and a reader arriving here should not try to claim it.

Q1's wake condition is unchanged and is now days rather than a gate: the indicator set that report ends up using is this thread's answer to which indicators, and what threshold makes one worth waking a human over, derived from two real working days instead of guessed. Triage mints the summariser from it.

Q2's sub-question stays here for @danmt and is untouched by any of this: does a sentinel claim carry the evidence rows it was drawn from, so a human can check a finding without re-deriving it? The structural half — the sentinel flags, it never acts — is answered by #295's chair table and needs nothing further.

#128 remains blocked behind #163, so nothing here is buildable and nothing is stalled by the ask.

Triage, 2026-08-02.

[dan-claude-bot]

Q1 is answerable from data as of this morning — and the premise underneath it ("there is nothing to summarise yet") turns out to be false

This thread's outcome has stood on one sentence: "there is nothing to summarise yet — #121's ledger (#122) and its aggregation (#123) do not exist, so a sentinel has no input." Two working days of fleet telemetry became public this morning (dan-claude-bot/crew-corpus, commit 9442833, collected 2026-08-03T10:18:04Z), so triage tested that sentence against the data instead of repeating it. It does not survive, and Q1 gets a measured answer where it previously had only guesses.

What the fleet's own duty.log already contains — no ledger, no #122, no token figure

SESSION END carries kind, key, rc, dur, outcome, and the dispatch lines carry what each tick decided. Across seven duty boxes, 2026-08-01T12:54:39Z → 2026-08-03T09:57:14Z: 411 sessions, 60.02 hours of model wall-clock. Every indicator below is computed from that file alone — box-side, deterministic, no board access, no cost data.

Indicator 1 — a session that did not finish. Threshold: any single one.

Nine sessions ended TIMEOUT or FAILED: 2.2% of sessions, 8.5% of all fleet wall-clock (305.4 minutes), every one running to its cap and yielding nothing. One build at the full 3600 s, one hygiene at 3000 s, one review at 2700 s, two floor operator sessions at 1800 s each. This is the profile a sentinel indicator wants and it is rare to find: low volume, high cost, zero false-positive risk — the engine already knows the outcome, so there is nothing to infer. It needs no threshold tuning at all, which makes it the cheapest possible first indicator.

Indicator 2 — a duty that repeats at an unchanged head. Threshold: 3.

codex-builder dispatched 65 resume sessions against draft #311, 59 of them after the last commit — 61.7 minutes, mean 63 s, every one rc=0 outcome=ok. Note that: an exit-code health check sees nothing wrong, 59 times. It is 89% of all resume duty the fleet ran in two days. The resume duty (drafts: 311 ...) dispatch line is in duty.log on every one of those ticks, so the streak is computable box-side without ever reading GitHub. Filed as #314, ready this morning on the 0.1.1 cut, and its fix writes the tripped-breaker WARN to duty.log deliberately — so if this indicator is built, that defect hands it a first-class signal rather than a pattern to infer.

Indicator 3 — a duty kind running long against its own history. Threshold: per-kind, and the history now exists.

Medians and p90s per kind, from the same 411 rows: review 351 s / 902 s, build 1137 s / 2230 s, triage 779 s / 1128 s, hygiene 434 s / 742 s, resume 59 s / 86 s. Two days is a thin baseline and this is the indicator most likely to cry wolf, which is exactly what this thread's own open question anticipated ("if it cries wolf twice it will be ignored"). Recommended last of the three, not first.

Indicator 4 — the tick that never got to run. duty tick skipped: previous run still holds the lock (running 300s) appears in duty.log verbatim. A box whose ticks are being skipped is doing less work than the operator thinks, and nothing currently says so.

What this does to Q1, and the recommendation

Q1 asked "which indicators, and what threshold makes one worth waking a human over?" — and the thread's honest answer was that it could not be settled until the substrate landed. Indicators 1, 2 and 4 need no substrate. They are computable today, on every box, from a file the engine already writes, and the largest measured waste in two real days (8.5% of wall-clock, in nine sessions) is visible to the simplest of them.

Triage's recommendation, offered rather than decided: the first summariser is cost-blind and failure-aware — indicators 1, 2 and 4 over duty.log — and it does not wait on #122/#123. Cost indicators join it when the ledger lands; they are a second slice, not a precondition. This preserves both of the thread's decided constraints untouched: the summariser is deterministic code, and the sentinel that reads it flags without acting.

This remains @danmt's call and is not triage's to take. It changes what the sentinel is on its first day — a fleet-health watch rather than a spend watch — and that is a scope decision, not a spec detail. What has changed is only that it is now cheap to answer: the data to judge it by is a git clone away.

Q2 is untouched

Does a sentinel's claim carry the evidence rows it drew from, so a human can check a finding without re-deriving it? Unchanged and still open. Worth noting only that every indicator above is a row-level fact with a timestamp, a box and a duty kind — so carrying the evidence is cheap for this set, which is a small argument for answering Q2 "yes" before the expensive indicators arrive.

Outcome unchanged: ask, waiting on @danmt, and Q1 is still the cheap one

Nothing is stalled by the ask. #128 is blocked — re-read from its label events (2026-08-02T13:01:41Z, reopened as the sentinel charter under #295) and from its body, which declares both Blocked by #163 and, in the verbatim design record it carries, Blocked by #123. Both holds are real and both are accurate: no builder can reach this ambiguity, so no answer is urgent and no claim is parked on it.

Nothing is waiting on this thread, and it gates no issue.

Triage, 2026-08-03.

[dan-claude-bot]

Q1's wake condition fired — the report is on main, and it corrects one of the three indicators I recommended this morning

My comment two hours ago recommended a first summariser built on indicators 1, 2 and 4, and this thread has held Q1 on #290's report since 2026-08-02. That report merged at 2026-08-03T12:08:44Z and #290 closed at 12:23:07Z. The deliverable is public, on main, at postmortems/2026-08-01-to-2026-08-02-fleet-run.md (525a041), and its board half is reproducible without any corpus access.

So the instruction this thread issued — the indicator set that report ends up using is this thread's answer — has been executed. What follows is what it returned, including where it disagrees with me.

Indicator 1 survives, and the report hands it back to this charter by name

"The largest measured unproductive-session class was nine TIMEOUT or FAILED sessions / 18,325s (305m 25s): 2.2% of the 408 completed sessions but 8.5% of their 215,775s wall-clock. […] The residue is measured but not yet a specified defect; #128's layer-one indicators already name session timeouts as the instrument that should expose it."

Four reviewers re-derived that, and the report routes the finding to this thread's own subject rather than filing it as a defect. Indicator 1 is unchanged: low volume, high cost, no threshold to tune, no false-positive risk — the engine already knows the outcome.

Indicator 4 is the one I had too wide, and the report says so with numbers

I wrote: "a box whose ticks are being skipped is doing less work than the operator thinks, and nothing currently says so." The report measures that and declines to call it a signal:

"568 scheduled ticks found a prior run holding the lock, so busy ticks were 568 of 2,180 observed tick attempts (26.1%). […] The 78.7% zero-action rate and 26.1% busy-tick rate are baselines, not findings: […] a busy tick shows the non-blocking lock declining duplicate work. The corpus records no token or monetary cost per tick, so neither rate establishes loss on its own."

A count of skipped ticks is the lock working. What survives is the field beside it, which the report also extracted:

"The skipped line's running Ns field supplies hold age: observed holds ranged from 253s to 4,800s."

A 4,800-second hold is worth waking someone over; a skip count is not. Indicator 4 stands only in its hold-age form, and my framing of it this morning would have built the version that cries wolf 568 times in two days — which is the failure this thread's own open questions named first.

Indicator 2's engine defect is claimed, not ready

Re-read from #314's label events rather than carried forward from my comment: ready at 10:34:35Z, claimed @cndgrr at 11:20:49Z, PR #318 open and out of draft. My line calling it "ready this morning" was true for 46 minutes. The part that matters here is intact and now visible in the PR's worklog: _resume_breaker, keyed <repo>#<pr>@<head>, threshold 3, one warn on the trip — so if this indicator is built, that fix hands it a first-class duty.log signal rather than a pattern to infer.

The corpus citation in my comment above no longer resolves

dan-claude-bot/crew-corpus went private at 2026-08-03T12:10:11Z at @danmt's direction (recorded on #290), deliberately held until after the merge. Every figure I quoted this morning is either in the merged report above or derivable from its board half; the corpus itself is now access-by-request through @danmt. My sentence "the data to judge it by is a git clone away" is the one this falsifies — the conclusion it supported is stronger than before, because the numbers are now in a reviewed file on main instead of a repository a reader had to aggregate themselves.

Outcome unchanged: ask, waiting on @danmt — and Q1 is now a pick from a measured list

Triage's recommendation, revised against the report and still offered rather than taken: indicator 1 first (the report already names it as the instrument for its own largest unpriced class), indicator 2 second (its signal is being written into duty.log right now), indicator 4 third and only as hold age, indicator 3 last (two days is a thin baseline and it is the one most likely to cry wolf). Cost indicators join when #122 lands; they are a second slice, not a precondition.

It remains @danmt's call because it decides what the sentinel is on its first day — a fleet-health watch rather than a spend watch — and that is scope, not spec. Both of this thread's decided constraints are untouched: the summariser is deterministic code, and the sentinel that reads it flags without acting.

Q2 is untouched. Does a sentinel's claim carry the evidence rows it drew from? Still open, and the report is a small argument for "yes": every figure in it names its derivation and its window, which is why its disagreement with me above is checkable at all.

Nothing is stalled by the ask. #128 is blocked — re-read from its label events, applied 2026-08-02T13:01:41Z on the reopen and never lifted — so no builder can reach this ambiguity.

Triage, 2026-08-03.

[dan-claude-bot]

Both halves of the substrate left the board at 15:54Z — and the indicators this thread recommended came back as a release, two windows ahead of the chair that reads them

Read from the issues rather than from this thread, since my comment at 12:33Z closed on "#128 is blocked … so no builder can reach this ambiguity" and that sentence's subject is now closed.

What moved

#128 — the sentinel charter	closed 2026-08-03T15:54:24Z in the operator-directed board-hygiene pass (close comment), carried by epic #163 (0.2.0). blocked is still on it — a close does not move the queue label — so the label a scanner reads is stale and the close event is the fact. #295's checklist records it, with the same carrier.
#123 — the aggregation	closed 15:54:17Z, carried by #328 (0.1.4 — collector + database), where it is named as "the collector's first consumer".
#122 — the ledger	closed 15:54:15Z, carried by #327 (0.1.3 — telemetry).

So the sentence this thread's outcome rested on for four days — "there is nothing to summarise yet; #122 and #123 do not exist" — has changed shape twice this week. This morning the corpus falsified it as a fact (the fleet's own duty.log was already summarisable). This afternoon the two issues it named stopped being open work at all.

The indicators are scheduled, and they are scheduled before the chair

This is the part worth having on the record. #327 (0.1.3 — telemetry) carries, in its to-mint list:

"Tick-health surface: last-tick age, skip/hold counts, outcome streaks — the numbers the 2026-08-01/02 report mined by hand."

That is the raw material of three of the four indicators I recommended this morning — 1 (a session that did not finish → outcome streaks), 4 in its hold-age form, and 3's per-kind baseline — landing in 0.1.3, while the chair that reads them (#128, carried by #163) is 0.2.0. Indicator 2's signal already ships: #314 went out in 0.1.1 and writes "one WARN in duty.log naming the PR, the head and the count" on the trip.

That ordering is danmt's 2026-07-28 ruling coming true by the roadmap rather than by argument — "real programming to turn telemetry into summaries with multiple indicators; the sentinel agent simply reads the summary." The deterministic half is two arcs ahead of the model half, which is the shape this thread called load-bearing.

What is scheduled is the numbers, not the judgement. #327's bullet names surfaces; it names no threshold, no digest, and nothing about what is worth waking a human over. That is still Q1, and Q1 is still @danmt's.

One thing to carry into 0.1.3's init rather than discover in it, because it is this thread's own correction and the epic's wording does not have it: "skip counts" is the form the merged report declines to call a signal — 568 busy ticks in two days, 26.1%, which is "the non-blocking lock declining duplicate work" and a baseline rather than a finding. The signal is the field beside it: hold age, observed at 253 s to 4,800 s. An indicator built from the skip count cries wolf 568 times a fortnight; one built from hold age fires on the 4,800-second hold. Recorded on #327 as well, so a builder meets it where the work is.

Outcome unchanged: ask, waiting on @danmt

Q1 — which indicators, and what threshold makes one worth waking a human over — is now a pick from a measured list with a release window under it, and it decides what the sentinel is on its first day: a fleet-health watch rather than a spend watch. Cost indicators join when the ledger returns with #327's window; they are a second slice, not a precondition. Q2 — does a sentinel's claim carry the evidence rows it drew from — is untouched.

Both decided constraints are untouched: the summariser is deterministic code, and the sentinel flags, it never acts.

Nothing is stalled by the ask, and it is now stalled less than it was: #128 is closed, so nobody can pick it up at all, and re-opening it is triage's act at 0.2.0's init. Nothing is waiting on this thread — re-derived at this write with blockers.jq's clause parse over all 22 open blocked bodies: every one names #346, none names this thread.

Triage, 2026-08-03.

[dan-claude-bot]

The substrate window is now the next one — and the report's largest unpriced class got a measured instance, an engine detector, and a new SESSION END value, all in the last four days

First comment here since 2026-08-03 18:04Z. Re-measured at main's head f5bd61c rather than carried forward.

1. Q1's window is next, not eventual

My last comment placed the indicators in #327 (0.1.3) and the chair that reads them in #163 (0.2.0). 0.1.2 is now at its cut — #400 is claimed with PR #401 in draft, #346 open — and #327's gate is "opens when #346 closes", by hand, at a triage release-init.

So Q1 — which indicators, and what threshold makes one worth waking a human over — is due at the init of the window after the one being cut. That init mints the tick-health surface from #327's to-mint list. Unanswered, it mints numbers on a page; answered, it mints numbers with the thresholds that decide what the sentinel is on its first day. Both are legitimate outcomes and only one of them is a decision.

The hold-age correction did land where it was promised: #327's scope line now reads "busy-tick rate, hold ages, and vendor quota/spend", so the 568-busy-tick framing this thread ruled out cannot be minted by accident.

2. Indicator 1's case is now the strongest thing on this list, and it was made by a human reading logs

The merged report routed its largest unpriced class — nine TIMEOUT or FAILED sessions, 2.2% of sessions and 8.5% of wall-clock — to this charter's layer-one indicators by name. Since then that class produced a concrete, measured instance:

#388, filed 2026-08-06 from a live incident on kimi-reviewer: a mid-cycle quota exhaustion, and the engine retried it every five minutes for thirty-five minutes — eight ticks × two repos, sixteen sessions, each starting the CLI, minting a session id, being rejected, exiting. It would have continued indefinitely, and two PRs were unreviewable throughout.

It was found by @danmt reading raw session logs on a box. That is exactly the gap this thread's first paragraph names — "it is only useful if somebody looks" — arriving as an incident rather than as an argument, which is the fourth time this fleet has paid that way.

3. Half of the instrument shipped as a side effect, and it changes what an indicator would read

#393 closed #388 on 2026-08-07 with a per-lane breaker in shared/lib/common.sh. Three things in it are facts an indicator builder needs, and none of them is in this thread yet:

• A fourth SESSION END outcome exists. verdict=TERMINAL now sits beside ok, TIMEOUT and FAILED. The report's "TIMEOUT or FAILED" class splits three ways from here, and only the third has a detector.
• A second suppression line exists. SESSION SKIP kind= key= reason=terminal-breaker count= is written for a dispatch refused before the CLI starts — a first-class signal, like shared/lib/duty-builder.sh + shared/prompts/resume.txt — a doable-work gate on resume dispatch, so a parked draft costs no session #314's _resume_breaker warn, rather than a pattern to infer. Any indicator summing SESSION END alone will under-report what the fleet decided to do.
• TIMEOUT deliberately resets the breaker. _session_terminal_record clears the state on any success, timeout, transient or unclassified failure — fail-safe by construction. So the timeout half of the report's class is exactly as uninstrumented as it was, and indicator 1 stands, narrowed to it and sharpened.

And the coverage is one vendor deep. Measured across the profile set at f5bd61c: only kimi.conf defines bot_session_terminal. On claude, codex and grok boxes a quota exhaustion still reads FAILED and the breaker never trips — correct under the fail-safe design, and a hard limit on any indicator keyed to outcome=TERMINAL. Worth carrying into #327's init rather than discovering there.

4. What this does to the two decided constraints: it confirms them, and it is not a precedent

The breaker acts — it refuses a lane. That is not a counter-example to "the sentinel flags, it never acts", and it should not be cited as one. The breaker is deterministic code whose test is exact: a counted, vendor-classified terminal status. The constraint governs the model's half, and this is danmt's 2026-07-28 ruling working exactly as stated — real programming does the detecting and may act where its test is certain; the agent reads the summary and gives an assessment extra. Two days of incident have made the deterministic half more capable and moved the model half not at all.

5. The census in my last comment

Board at this write: 31 open — 19 epic, 6 post-merge, 3 blocked, 2 claimed, 1 ready (19+6+3+2+1 = 31), zero needs-triage, attention, stale and offsite, two open PRs (#401 draft at blocker:ci-red, #410 at state:needs-human). Blocker parse over every open blocked body: #406 → {#402, #403}, #408 → {#406}, #411 → {#408}; union {#402, #403, #406, #408}, none of them this thread. One needs-ruling stands on the board — on #400 since 2026-08-07T21:32:17Z, the release cut's drill-sequencing ask — naming nothing here. #128 is unchanged: closed 2026-08-03T15:54:24Z, still carrying a stale blocked, carried by #163.

Outcome unchanged: ask, waiting on @danmt

Q1 is a pick from a measured list with a window under it, and triage's ordering is revised by this week's evidence rather than restated: indicator 1 first, narrowed to timeouts — its terminal sibling now has a detector and its timeout half does not; indicator 2 second, now with two shipped signals to read rather than one; indicator 4 third and only as hold age; indicator 3 last. Q2 — does a sentinel's claim carry the evidence rows it drew from — is untouched.

Nothing is stalled by the ask, and no needs-ruling label is owed here, so no rung of the ruling ladder has a clock. The 7-day nudge applies: absent real activity triage returns on 2026-08-14, and in any case at #327's init, whichever is first.

Triage, 2026-08-07.

[dan-claude-bot]

Q1's first half got a taxonomy this morning; its second half is untouched — and the same session handed this chair two detection blind spots it should be built knowing about

One delta since my comment of 2026-08-07 21:45Z, which placed Q1 — which indicators, and what threshold makes one worth waking a human over — at the release-init of the window after the one being cut. That placement is unchanged: 0.1.2 is still at its cut, with three open members, and #327's gate is still opens when #346 closes, by hand.

1. What the design session did and did not answer

The reading taxonomy and the boundary annotation, both 2026-08-09, decide which readings exist, whose store holds them, and how long they are kept. #327's to-mint list carries the sentinel's own primary input verbatim: "Tick-health surface: last-tick age, skip/hold counts, outcome streaks."

No threshold was ruled anywhere in either note. So Q1 splits cleanly now: its which is largely answered by classification, and its what number wakes a human is exactly as open as it was, still due at the same init, and still the half that decides what this chair is on its first day rather than what it can see.

2. Two blind spots this chair inherits, both recorded as knowingly accepted

Neither is a defect and both are invisible from the sentinel's own side, which is why they belong on this thread rather than on the epic that accepted them.

• Undeclared credential sharing is undetectable, right up to the ceiling. Credential identity is ruled an operator-declared label defaulting to box identity; the derived alternative was declined as overbuilt for an interim, with the residual risk in writing — "undeclared sharing under-attributes, silently, right up to the ceiling, and a declared label cannot detect it." A sentinel watching spend against quota inherits that exactly: two boxes on one credential with distinct labels each read comfortably under, and the first true signal is the vendor rejection, not the approach. On this fleet that is shared/lib/common.sh — a session that cannot succeed is retried every tick forever: no terminal-vs-transient classification, no breaker, no operator signal #388's incident shape — sixteen sessions that could not succeed — arriving with no warning the sentinel could have raised.
• Interval sampling can see an ephemeral box zero times. #442 §4 carries "vitals sampled on duty lifecycle, not only on cadence — a reading at duty start and one at duty end", called out as "the one that looks fine right up until boxes stop outliving the interval." Inert at today's long-running shape; at 0.2.5 a cadence-only sentinel is blind to precisely the short duties most worth watching.

3. Outcome

Answered, still held. No question here is resolved and none is re-raised; Q1 goes to #327's init as before. What is new is that the which half arrives pre-classified, and that two things this chair will not be able to see are now written down before it is specified rather than discovered by it.

Triage 2026-08-09 12:3xZ.

[dan-claude-bot]

The init this thread's Q1 was placed at came and went, and the question was not put — recorded, and re-placed so it cannot go dark twice

Triage 2026-09-01, re-measured at main 70bd7d4.

This thread carries no return date, correctly — its wake is an event. The event fired and nobody was watching. No sweep, no nudge and not the returns on <date> scan reads a dateless thread, which is how an event-keyed wake becomes invisible; this is the third such thread served today for the same reason.

What was placed, and what happened to the placement

My comment of 2026-08-09 placed Q1 — which indicators, and what threshold makes one worth waking a human over — at "the release-init of the window after the one being cut", noting 0.1.2 was still at its cut and #327's gate was still opens when #346 closes, by hand.

Every step of that has since happened:

• 0.1.2 — polish: the clean gate (working surface; #162 is the ledger) #346 closed 2026-08-10T21:05:38Z; 0.1.2 published 2026-08-10T20:47:40Z.
• 0.1.3's window opened, and release-init step 1 ran 2026-08-24 — the init Q1 was placed at.
• The wave has largely landed since.

Q1 was not put at that init. It is not on #327, it is not on this page, and no needs-ruling was ever set for it. The placement was recorded here and nowhere the init would read.

The which half answered itself; the threshold half is exactly as open as it was

That comment had already split Q1: its which was largely settled by the reading taxonomy, and "what number wakes a human" was "still the half that decides what this chair is on its first day rather than what it can see."

The sentinel's primary input is now built, not specified. Measured at 70bd7d4:

• shared/lib/common/tick-health.sh exists — #484, "tick health as a surface: last-tick age, skip/hold counts, outcome streaks", CLOSED. That is 0.1.3 — telemetry: the box stops being a black box #327's to-mint entry quoted verbatim in my last comment as this chair's primary input.
• shared/bin/vitals.sh exists — #483, CLOSED.
• Session records now carry cost_usd= and sid= — #475, #485, #538, all CLOSED.

No threshold was ruled by any of it. I re-read the landed work rather than the annotations describing it: these ship readings and surfaces, and not one names a number at which a human is woken. So the split holds exactly as stated — the which is now answered by working code rather than by classification, and the what number is untouched, thirteen days after the init it was due at.

The 0.2.5 caveat also still stands and is now nearer. #442 §4's "vitals sampled on duty lifecycle, not only on cadence" remains inert at today's long-running box shape and blinds a cadence-only sentinel the moment boxes stop outliving the sampling interval. Nothing has changed that; it is recorded again only because the readings it qualifies now exist.

Outcome: ask, re-placed at 0.1.4's init — and this time the placement names a surface

I am not putting Q1 to @danmt as a live escalation in this comment, because the threshold is a design question the window's own init is the right forum for, and that is the judgement the original placement made. What went wrong was not the judgement — it was that a placement recorded only on a discussion page has nothing that reads it.

So: Q1 is re-placed at #328's (0.1.4) release-init, and triage owes putting it there as a written ask at that init rather than carrying it as prose here. #328 is open, epic + release, window not opened.

The wake condition, re-stated so it is checkable: this thread wakes when 0.1.4's window opens. If that init passes without Q1 being put a second time, the placement mechanism is the defect and not the question, and the right response then is a needs-ruling ask on the board rather than a third placement.

Nothing is minted by this comment and no label moves. No return date, still correctly.

Triage, 2026-09-01.