tumwater 0.4.2 → 0.4.3

package/dist/src/ui/progress-data.js

@@ -86,7 +86,7 @@ function freshProgress(quietMs, agent) {
 /** The event types feedLine acts on — everything else (streaming deltas, turn/agent
  * bookkeeping) is ignored. Also passed as parsePiEventLine's pre-filter to skip JSON.parse for
  * pi lines whose type is verifiably not one of these; a new case in the switch must be added
- * here too. `tumwater_run` is the harness's own marker (src/agent/run-spawn.ts), read for its
+ * here too. `tumwater_run` is the harness's own marker (src/agent/agent-spawn.ts), read for its
  * run kind: a kind-bearing marker flips the demux and starts that accumulator fresh before
  * its `session` event lands, and a legacy label-only marker ("review") still flips the demux
  * to gate. */
@@ -98,54 +98,67 @@ const PROGRESS_TYPES = new Set([
     "tool_execution_end",
     "message_end",
 ]);
+/** A new run starts: everything before it was a previous run — restore the at-time-zero state. */
+function applySessionEvent(progress) {
+    Object.assign(progress, freshProgress(progress.quietMs));
+}
+/** A tool execution starts: count the call, record its label as the last tool, and seed the
+ * open-call entry the stall flag reads. Track the open call for the stall flag — pi runs a
+ * message's tool calls concurrently by default, so several can be open at once and end in
+ * completion order. The state machine is shared with runPi's stall warning
+ * (src/pi/pi-watchdogs.ts); only the fallback label differs here. The full raw command rides
+ * along because the flag classifies the command's shape, and describeToolCall's label
+ * truncates at 32 chars — an operator past that point would be invisible there. */
+function applyToolStart(progress, event) {
+    progress.toolCalls += 1;
+    const label = event.toolName ? describeToolCall(event.toolName, event.args) : undefined;
+    if (label)
+        progress.lastTool = label;
+    applyToolExecutionEvent(progress.openToolCalls ??= [], event.type, event.toolCallId, event.partialResult, label ?? "tool", toolCallCommand(event.args));
+}
+/** A tool update or end folds through the same call: `applyToolExecutionEvent` reads `event.type`
+ * to decide what to do (a content-bearing update moves the activity clock; end closes the
+ * call), and both no-op when no call is tracked. Only content-bearing updates prove the
+ * command is alive — bash emits one empty-content update right after start, and a
+ * content-free keepalive must not mask a hang — a rule applyToolExecutionEvent owns. */
+function applyToolProgress(progress, event) {
+    if (progress.openToolCalls)
+        applyToolExecutionEvent(progress.openToolCalls, event.type, event.toolCallId, event.partialResult);
+}
+/** An assistant message ends: count the turn and fold usage/peak/context and the first work item.
+ * Guard each count like pi-stream's usageNumber does: a string-serialized or corrupt wire value
+ * would otherwise poison the live cell — `+=` would concatenate output into a string and
+ * Math.max would yield NaN. An unusable total keeps the previous context (this cell is "latest
+ * value"), while output and the peak floor treat it as absent. The first text the role speaks
+ * in this run is its work item ("I'll implement plan X"); later messages never replace it. */
+function applyAssistantTurn(progress, event) {
+    if (event.message?.role !== "assistant")
+        return;
+    progress.turns += 1;
+    const usage = event.message.usage;
+    if (usage) {
+        progress.contextTokens = nonNegativeNumber(usage.totalTokens, progress.contextTokens);
+        progress.outputTokens += nonNegativeNumber(usage.output, 0);
+        progress.peakContextTokens = Math.max(progress.peakContextTokens, nonNegativeNumber(usage.totalTokens, 0));
+    }
+    if (!progress.currentWork)
+        progress.currentWork = workItemFromContent(event.message.content);
+}
 /** Apply one parsed progress event to a progress object (mutates it). */
 function feedLine(progress, event) {
     switch (event.type) {
         case "session": // A new run starts: everything before it was a previous run — restore the at-time-zero state.
-            Object.assign(progress, freshProgress(progress.quietMs));
+            applySessionEvent(progress);
             break;
-        case "tool_execution_start": {
-            progress.toolCalls += 1;
-            const label = event.toolName ? describeToolCall(event.toolName, event.args) : undefined;
-            if (label)
-                progress.lastTool = label;
-            // Track the open call for the stall flag — pi runs a message's tool calls concurrently
-            // by default, so several can be open at once and end in completion order. The state
-            // machine is shared with runPi's stall warning (src/pi/pi-watchdogs.ts); only the
-            // fallback label differs here. The full raw command rides along because the flag
-            // classifies the command's shape, and describeToolCall's label truncates at 32 chars —
-            // an operator past that point would be invisible there.
-            applyToolExecutionEvent(progress.openToolCalls ??= [], event.type, event.toolCallId, event.partialResult, label ?? "tool", toolCallCommand(event.args));
+        case "tool_execution_start":
+            applyToolStart(progress, event);
             break;
-        }
-        // Updates and ends fold through the same call: `applyToolExecutionEvent` reads `event.type`
-        // to decide what to do (a content-bearing update moves the activity clock; end closes the
-        // call), and both no-op when no call is tracked. Only content-bearing updates prove the
-        // command is alive — bash emits one empty-content update right after start, and a
-        // content-free keepalive must not mask a hang — a rule applyToolExecutionEvent owns.
         case "tool_execution_update":
         case "tool_execution_end":
-            if (progress.openToolCalls)
-                applyToolExecutionEvent(progress.openToolCalls, event.type, event.toolCallId, event.partialResult);
+            applyToolProgress(progress, event);
             break;
         case "message_end":
-            if (event.message?.role === "assistant") {
-                progress.turns += 1;
-                const usage = event.message.usage;
-                if (usage) {
-                    // Guard each count like pi-stream's usageNumber does: a string-serialized or corrupt
-                    // wire value would otherwise poison the live cell — `+=` would concatenate output into
-                    // a string and Math.max would yield NaN. An unusable total keeps the previous context
-                    // (this cell is "latest value"), while output and the peak floor treat it as absent.
-                    progress.contextTokens = nonNegativeNumber(usage.totalTokens, progress.contextTokens);
-                    progress.outputTokens += nonNegativeNumber(usage.output, 0);
-                    progress.peakContextTokens = Math.max(progress.peakContextTokens, nonNegativeNumber(usage.totalTokens, 0));
-                }
-                // The first text the role speaks in this run is its work item ("I'll implement plan X");
-                // later messages never replace it.
-                if (!progress.currentWork)
-                    progress.currentWork = workItemFromContent(event.message.content);
-            }
+            applyAssistantTurn(progress, event);
             break;
     }
 }
@@ -251,7 +264,7 @@ function feedDemuxed(tail, line, gateCwd) {
  * run in the role's own worktree, the default; `gate` — the review gate's runs in a leased pool
  * slot, what the reviewing cell shows), or null when there is no log yet. The raw log is
  * append-only while pi runs and every run starts with a `tumwater_run` marker
- * (src/agent/run-spawn.ts), so after seeding from the tail window once we only read and parse
+ * (src/agent/agent-spawn.ts), so after seeding from the tail window once we only read and parse
  * bytes appended since the last poll — observers that call this every second (TUI, GUI) stop
  * rescanning up to TAIL_BYTES
  * of JSON per role per poll. */

package/dist/src/ui/run-progress-model.js

@@ -1,3 +1,4 @@
+import { callBuffersOutput } from "../pi/command-shape.js";
 import { readLiveProgress } from "./progress-data.js";
 import { compactTokens } from "../text/format.js";
 import { pad2 } from "../text/datetime.js";
@@ -83,8 +84,14 @@ export function inFlightDetail(head, p) {
     else if (p.lastTool)
         parts.push(p.lastTool);
     // Silence under five minutes is normal (slow local-model prefills, long tool calls);
-    // only flag a stall once at least five minutes have passed without any pi output.
-    if (p.quietMs >= 300_000)
+    // only flag a stall once at least five minutes have passed without any pi output. While a
+    // tool call that buffers its output (a redirect or pipe — the run prompt's prescribed
+    // `> check.log` verify shape) is open, that flat threshold would cry wolf inside the call's
+    // own generous wall-clock stall window: the silence is the prescribed shape, not a hang,
+    // and a real stall past that window has already named itself as `tool call stalled: <tool>`
+    // above. Defer to the call so a slow suite stops being read as a hang (BUGS.md 2026-10-28).
+    const hasOpenBuffered = p.openToolCalls?.some((call) => callBuffersOutput(p.agent, call.command || call.label)) ?? false;
+    if (p.quietMs >= 300_000 && !hasOpenBuffered)
         parts.push(`no agent output for ${duration(p.quietMs)}`);
     return parts.join(" · ");
 }

package/dist/src/ui/status-model.js

@@ -84,7 +84,7 @@ export function onErrorStreak(s) {
     return (errorStreakAtWarn(s) ||
         (s.lastResult === "quiet_killed" && (s.quietKillStreak ?? 0) >= QUIET_KILL_RESUME_LIMIT));
 }
-export function rolePhase(s, orchestratorRunning, root, budgetPaused = false, live, userPaused = false, merge, mainCheck, capPaused = false, quietHold, diskHeld = false, bootstrapHeld = false, maintenanceQuotaHold, permits, pausedUntilMs) {
+export function rolePhase(s, orchestratorRunning, root, budgetPaused = false, live, userPaused = false, merge, mainCheck, capPaused = false, quietHold, diskHeld = false, bootstrapHeld = false, maintenanceQuotaHold, pausedUntilMs) {
     if (!orchestratorRunning)
         return "stopped";
     // Merge queue 4/5 — the marker-driven merge label: only a role whose change record was
@@ -114,16 +114,6 @@ export function rolePhase(s, orchestratorRunning, root, budgetPaused = false, li
         // parked waiter visibly does not (BUGS.md 2026-09-24).
         if (s.parkedSince) {
             const parkedTime = duration(Date.now() - s.parkedSince);
-            // The parked waiter's provider key, named only while that key is the binding limit in
-            // the published permit snapshot (plans/provider-concurrency.md §8): the key is at its
-            // cap, so THIS waiter is queued on its provider, not on the team total — `awaiting
-            // omlx slot` tells the operator exactly which cap is full. A role parked on the total
-            // (no key, or an uncapped one) reads today's `awaiting slot` as before.
-            if (s.parkedOn !== undefined &&
-                permits !== undefined &&
-                isBindingLimit(permits, s.parkedOn)) {
-                return `waiting for ${s.parkedOn} ${parkedTime}`;
-            }
             return `waiting to start ${parkedTime}`;
         }
         // The director bypasses maxConcurrent (`usesSlot` is false for it), so its in-flight run
@@ -322,9 +312,6 @@ export function roleRowCells(snap, root, s) {
     snap.maintenanceQuota.held.includes(s.role)
         ? `waiting: maintenance allowance used ${snap.maintenanceQuota.used}/${snap.maintenanceQuota.allowance}`
         : undefined, 
-    // The permit pool's live state (plans/provider-concurrency.md §8): names the parked
-    // waiter's provider key in `awaiting <key> slot` when that key is at its cap.
-    snap.permits, 
     // A timed per-role pause's deadline — only when the role itself is individually paused
     // (in `pausedRoles`) and not under a team-wide pause, matching the GUI's phaseDetail
     // guard, so the team pause (whose countdown rides the header badge) never double-appends.
@@ -336,15 +323,6 @@ export function roleRowCells(snap, root, s) {
  * gui-client-model.ts interpolates ROLE_RANK_RULES, so the two dashboards cannot disagree
  * about which phases are in flight. */
 export const ACTIVE_PHASE_PREFIXES = ["working", "reviewing", "merging"];
-/** Whether `key` is the binding limit in the published permit snapshot: its cap is set and
- * its in-use already meets or exceeds it, so the pool is granting nothing more on that key and
- * a waiter carrying it is queued on the key, not on the team total. A key without a cap in
- * the snapshot (uncapped) is never binding. One home for the rule, shared by status-model's
- * `awaiting <key> slot` and the GUI chip's provider detail. */
-function isBindingLimit(permits, key) {
-    const entry = permits.byKey[key];
-    return entry?.limit !== undefined && entry.inUse >= entry.limit;
-}
 /** Is this phase one of the PERMIT-HOLDER in-flight states — the rows an operator counts
  * against maxConcurrent? The three labels come from rolePhase: `working …`, `reviewing …`,
  * and the marker-driven `merge …` (merge queue 4/5) — an approved change waiting for the merge
@@ -375,7 +353,7 @@ export function isActivePhase(phase) {
 export const ROLE_RANK_RULES = [
     { rank: -1, prefixes: ["director working"] },
     { rank: 0, active: true },
-    { rank: 1, prefixes: ["approved", "waiting to start", "waiting for "] },
+    { rank: 1, prefixes: ["approved", "waiting to start"] },
     { rank: 2, phases: ["failing", "main's check is failing"] },
     { rank: 3, phases: ["paused"] },
     { rank: 3, prefixes: ["paused", "waiting:"] },

package/dist/src/ui/status-payload.js

@@ -1,4 +1,4 @@
-import { answeredQuestionSummaries } from "../backlog/question-answer.js";
+import { answeredQuestionSummaries } from "../backlog/backlog-question-answer.js";
 import { completionDate, donePlanEntries, DONE_DATE_RE, FIXED_DATE_RE, fixedBugEntries, openBugs, openQuestions, plannedPlans } from "../backlog/backlog.js";
 import { backlogHolds, backlogInProgress, backlogMarks, refusedEntries, stalledEntries } from "../backlog/backlog-eligibility.js";
 import { finishedTitle, strandedPlanEntriesFor } from "../backlog/backlog-structure.js";
@@ -15,11 +15,10 @@ import { scopeSnapshotToRoles, snapshot } from "../status/status-data.js";
 import { bootstrapBadge, buildBadge, budgetBadge, diskBadge, mergeBadge, mainCheckBadge, mainCountsFragment, ciParityBadge, ciParityTone, permitsBadge, checksBadge, quietBadge, runWindowBadge, workspacesBadge } from "./badges.js";
 import { isActivePhase, roleRowCells, onErrorStreak } from "./status-model.js";
 import { yieldMultiplierFor } from "../scheduling/backoff.js";
-import { staleClaimEntries } from "../scheduling/claim-entries.js";
 import { teamAlerts } from "./team-alerts.js";
 import { duplicatedBacklogHeadings, liveFinishedEntriesFor } from "../doctor/doctor-backlog-plans.js";
 import { readPostReviews } from "../review/post-merge-review.js";
-import { capacityContention, instancePoolProblems, planDependencyAlert, providerCapProblems, regressedFixesAlert, staleOpenQuestions, staleWorkspacePins } from "./alert-feeds.js";
+import { getOrphanAlert, planDependencyAlert, staleOpenQuestions } from "./alert-feeds.js";
 /** How many recent events the payload carries — enough for the dashboard's activity feed to
  * still show a screenful of notable events (merges, failures, questions) after it filters
  * out the routine ones (run starts, wakes, passing checks). */
@@ -61,9 +60,6 @@ function roleRows(snap, root) {
             // the dashboard can mark a row whose model tumwater.json did not name. Same conditional
             // spread as `model`, present on exactly the rows that carry the flag.
             ...(s.modelFromPi ? { modelFromPi: true } : {}),
-            // Model failure fallback (PLANS.md "Model failure fallback, part 2/2"): present only
-            // while the role's runs use another model, so the common row shape is unchanged.
-            ...(s.fallback ? { fallback: s.fallback } : {}),
             ...(s.slot ? { slot: s.slot, slotPinned: s.slotPinned === true } : {}),
             // Parallel work instances (plans/parallel-work-instances.md "Observability", part
             // 6/7): the backlog entry this instance claimed, shown by the dashboards while it is
@@ -419,7 +415,7 @@ function alertFields(root, snap, questions, roles, now) {
     return {
         // What needs the operator (team-alerts.ts's teamAlerts): the dashboard's alert banners and
         // the TUI's attention lines, phrased once.
-        alerts: teamAlerts(snap, questions, roles, now, refusedEntries(root), planDependencyAlert(root), stalledEntries(root), strandedPlanEntriesFor(root), duplicatedBacklogHeadings(root), validationGapProblems(root), capacityContention(root, now), regressedFixesAlert(root, now), staleClaimEntries(root, roles.map((r) => r.role), now), staleOpenQuestions(root, now), fixClaimProblems(root), staleWorkspacePins(root, now), liveFinishedEntriesFor(root), instancePoolProblems(root), providerCapProblems(root)),
+        alerts: teamAlerts(snap, questions, roles, now, refusedEntries(root), planDependencyAlert(root), stalledEntries(root), strandedPlanEntriesFor(root), duplicatedBacklogHeadings(root), validationGapProblems(root), staleOpenQuestions(root, now), fixClaimProblems(root), liveFinishedEntriesFor(root), getOrphanAlert(root)),
     };
 }
 /** The one team-state document both observer surfaces carry: `GET /api/status` (gui/gui-server.ts)

package/dist/src/ui/status-render.js

@@ -9,12 +9,11 @@ import { runProgress } from "./run-progress-model.js";
 import { eventTypeLabel } from "../events/event-labels.js";
 import { roleLabel } from "../roles/role-labels.js";
 import { yieldMultiplierFor, yieldMultiplierSuffix } from "../scheduling/backoff.js";
-import { staleClaimEntries } from "../scheduling/claim-entries.js";
 import { phaseTone, resultTone } from "./tone.js";
 import { teamAlerts } from "./team-alerts.js";
 import { openQuestions } from "../backlog/backlog.js";
 import { refusedEntries, stalledEntries } from "../backlog/backlog-eligibility.js";
-import { capacityContention, instancePoolProblems, planDependencyAlert, providerCapProblems, regressedFixesAlert, staleOpenQuestions, staleWorkspacePins } from "./alert-feeds.js";
+import { getOrphanAlert, planDependencyAlert, staleOpenQuestions } from "./alert-feeds.js";
 import { strandedPlanEntriesFor } from "../backlog/backlog-structure.js";
 import { duplicatedBacklogHeadings, fixClaimProblems, liveFinishedEntriesFor, validationGapProblems } from "../doctor/doctor-backlog-plans.js";
 /** The status RENDER layer: time/token cell formatters and the width-aware table shared by
@@ -238,8 +237,8 @@ function statusHeaderLine(root, snap, now) {
         // comfortable or unmeasured state, so an unaffected header stays byte-identical.
         ...badgeSpans(diskBadge(snap.disk), snap.disk?.held ? "yellow" : "blue"),
         // The permit pool's live state (plans/provider-concurrency.md §8): the team line reads
-        // `slots 5/8 · omlx 3/3` only while the per-provider cap map is set (permitsBadge already
-        // omits the providers on a map-less team, so the header stays byte-identical).
+        // `running 5 of 8` — the team total's in-use/cap — for any team with a published permit
+        // snapshot; empty until one has been published.
         ...badgeSpans(permitsBadge(snap.permits), "blue"),
         // Checks running/waiting for a check permit; empty while the check pool is idle.
         ...badgeSpans(checksBadge(snap.checkPermits), snap.checkPermits && snap.checkPermits.waiting > 0 ? "yellow" : "blue"),
@@ -306,14 +305,11 @@ function statusRoleRows(root, snap, now, withMetrics, sharedModel) {
         // today's.
         const inner = roleModelLabel(s);
         const modelSuffix = inner && !sharedModel ? ` (${inner})` : "";
-        // Model failure fallback, part 2/2: while the role runs off-model its name cell says so,
-        // so the operator can see which roles the fallback pair is carrying without reading logs.
-        const fallbackSuffix = s.fallback ? " (over-cap model)" : "";
         // User-defined roles (snapshot's `custom` flag) get an asterisk beside their name — the
         // dashboards' at-a-glance marker. The name column (index 0) is not in FLEXIBLE_COLUMNS;
         // its width derives from row content and it shrinks only after those,
         // so the extra character widens it.
-        const name = (s.custom ? `${roleLabel(s.role)}*` : roleLabel(s.role)) + modelSuffix + fallbackSuffix;
+        const name = (s.custom ? `${roleLabel(s.role)}*` : roleLabel(s.role)) + modelSuffix;
         const state = stateCell(root, s, phase, live);
         const tone = phaseTone(phase);
         // The whole state cell carries the phase's tone: a work item leads the cell (so it
@@ -509,7 +505,7 @@ export function renderStatus(root, snap, maxWidth, scoped = false) {
     // Composed here, NOT inside renderStatusSpans: the TUI re-slices that function's shared
     // `lines` (lines[0], its own attention block, then lines.slice(1)), so a banner embedded
     // there would render twice in the TUI.
-    const alerts = teamAlerts(snap, openQuestions(root), roles, Date.now(), refusedEntries(root), planDependencyAlert(root), stalledEntries(root), strandedPlanEntriesFor(root), duplicatedBacklogHeadings(root), validationGapProblems(root), capacityContention(root), regressedFixesAlert(root, Date.now()), staleClaimEntries(root, roles.map((r) => r.role), Date.now()), staleOpenQuestions(root), fixClaimProblems(root), staleWorkspacePins(root, Date.now()), liveFinishedEntriesFor(root), instancePoolProblems(root), providerCapProblems(root)).filter((a) => a.key !== "stopped");
+    const alerts = teamAlerts(snap, openQuestions(root), roles, Date.now(), refusedEntries(root), planDependencyAlert(root), stalledEntries(root), strandedPlanEntriesFor(root), duplicatedBacklogHeadings(root), validationGapProblems(root), staleOpenQuestions(root), fixClaimProblems(root), liveFinishedEntriesFor(root), getOrphanAlert(root)).filter((a) => a.key !== "stopped");
     const banner = alertLines(alerts, maxWidth ?? Number.MAX_SAFE_INTEGER, alerts.length).map(plainText);
     const text = lines.map(plainText);
     return [...text.slice(0, 2), ...banner, ...text.slice(2)].join("\n");

package/dist/src/ui/team-alert-backlog.js

@@ -7,7 +7,7 @@ import { entryListDetail, firstAndMore, openBacklogAction } from "./team-alert-s
 import { entryKindLabel } from "../backlog/backlog-eligibility.js";
 import { missingSymbolNames } from "../verdict/fix-claim.js";
 import { joinWithMore } from "../text/text.js";
-import { plural } from "../text/phrases.js";
+import { agree, plural } from "../text/phrases.js";
 import { liveFinishedRowList } from "../backlog/backlog-archive.js";
 function pushQuestionsAlert(out, questions) {
     if (questions.length) {
@@ -112,7 +112,7 @@ function pushStrandedPlansAlert(out, strandedPlans) {
         out.push({
             key: "stranded-plans",
             tone: "amber",
-            title: `${strandedPlans.length === 1 ? "A plan sits" : "Plans sit"} under the wrong backlog section`,
+            title: `${agree(strandedPlans.length, "A plan sits", "Plans sit")} under the wrong backlog section`,
             detail: `${first.file ?? "PLANS.md"} has a plan stranded under ## ${first.section}: "${first.title}"${more} — move it under ## ${first.section === "Done" ? "Planned" : "Done"}${first.file === undefined || first.file === "PLANS.md" ? "" : " in PLANS.md"} (the clean role repairs these)`,
             // The fix is editing a backlog file, and a PLANS-DONE.md entry has no PLANS.md drawer index.
             actions: [],
@@ -140,10 +140,10 @@ function pushBacklogHeadingsAlert(out, duplicatedHeadings) {
 }
 // Finished history still in the live backlog files (the doctor's `backlog archive` rule,
 // checkLiveFinished, src/doctor/doctor-backlog-plans.ts, via the shared liveFinishedEntriesFor)
-// is the one backlog-hygiene rule the doctor warned but no always-on alert surfaced — every
-// other rule (stranded plans, duplicated headings, validation gaps, plan dependencies, stale
-// bugs and questions) has one, so an operator watching `tumwater status` or the dashboard never
-// sees the growing finished sections until they run `tumwater doctor`. It asks (amber) the way
+// is a backlog-hygiene rule the doctor warned but no always-on alert surfaced — stranded
+// plans, duplicated headings, validation gaps, plan dependencies and questions each have one,
+// so an operator watching `tumwater status` or the dashboard never sees the growing finished
+// sections until they run `tumwater doctor`. It asks (amber) the way
 // the duplicated-heading alert does, naming each live file, its finished section, its entry
 // count, and its size in KB; the fix is the `tumwater archive` command, so there are no actions.
 function pushBacklogArchiveAlert(out, liveFinished) {

package/dist/src/ui/team-alert-status.js

@@ -1,20 +1,16 @@
 /** The status/capacity and role-phase team alerts, in emission order: a spent budget
- * (chain/fallback/budget), per-role cap, disk, install, and main-red holds, roles failing run
- * after run or stuck, and a stale running build. One of the per-domain builders split out of
- * src/ui/team-alerts.ts; the shared types and wording helpers live in team-alert-shared.ts. */
-import { staleClaimDetail } from "../scheduling/claim-entries.js";
-import { openRoleActions, seeFailures, listRoles, listRoleIds, stuckDetail, localizeInstants, } from "./team-alert-shared.js";
+ * (chain/fallback/budget), disk, install, and main-red holds, roles failing run after run or
+ * stuck. One of the per-domain builders split out of src/ui/team-alerts.ts; the shared types
+ * and wording helpers live in team-alert-shared.ts. */
+import { openRoleActions, seeFailures, listRoles, listRoleIds, stuckDetail, } from "./team-alert-shared.js";
 import { chainFragments } from "./badges.js";
 import { fallbackTierEntries } from "../budget/budget.js";
 import { fallbackDisplayPair } from "../config/config-views.js";
 import { agree, plural } from "../text/phrases.js";
-import { BRIEF_TEXT_MAX_CHARS } from "../brief/brief.js";
 import { formatGB, shortSha, usd, usdCap } from "../text/format.js";
 import { joinWithMore, squash } from "../text/text.js";
 import { roleLabel } from "../roles/role-labels.js";
 import { STALL_RE } from "./run-progress-model.js";
-import { ROLE_NOTES_MAX_BYTES } from "../agent/role-notes-write.js";
-import { PRINCIPLES_MAX_CHARS } from "../prompt/principles.js";
 function pushChainAlert(out, snap) {
     const onFallback = chainFragments(snap.chain);
     if (onFallback) {
@@ -60,23 +56,6 @@ function pushSpentBudgetAlert(out, snap) {
             });
     }
 }
-// A role over its maxDailyCostUsdPerRole cap (status-model.ts "waiting: daily cap spent") is
-// a per-role hold — one role sits idle while the rest of the team keeps working — so the team
-// banner names it the way the budget, disk, and quiet banners name theirs, instead of leaving
-// an operator to read every row. An amber ask (it needs a raise to resume); clears on its own
-// at local midnight when the spend window rolls over.
-function pushRoleCapAlert(out, snap, roles) {
-    const capPausedRoles = roles.filter((l) => snap.capPaused.includes(l.role));
-    if (snap.capPaused.length > 0) {
-        out.push({
-            key: "role-cap",
-            tone: "amber",
-            title: `${listRoleIds(snap.capPaused)} ${agree(snap.capPaused.length, "is over its daily cap", "are over their daily caps")}`,
-            detail: `The daily cap (maxDailyCostUsdPerRole) holds ${listRoleIds(snap.capPaused)}: no new runs until local midnight. Raise the cap to resume ${agree(snap.capPaused.length, "it", "them")}.`,
-            actions: openRoleActions(capPausedRoles),
-        });
-    }
-}
 // The disk floor holding new work (plans/disk-floor.md, part 4/4): the header badge and the
 // role rows say what is happening, but the banner names the threshold and the way out, so an
 // operator hitting a full volume does not have to read events. An amber ask — the team is
@@ -109,86 +88,6 @@ function pushInstallDriftAlert(out, snap) {
         });
     }
 }
-// No deterministic build check is declared (detectBuildCheck returned null): the review
-// gate's build pre-check, the red-main baseline and redeploy's green check have nothing to
-// run, and the header badge renders nothing (mainCheckBadge needs a build_check event).
-// The same state the doctor `check` row warns on, raised as a standing alert on the always-on
-// surfaces. Independent of team state (running or stopped), like the install alert beside it.
-function pushNoCheckAlert(out, snap) {
-    if (snap.noDeclaredCheck) {
-        out.push({
-            key: "no-check",
-            tone: "amber",
-            title: "No project check is declared — the safety gates are off",
-            detail: "The review gate's build pre-check, the red-main baseline and redeploy's green check have nothing to run. The plan role will plan this project's check and the feature role declare it — a test/typecheck/build npm script, or check.command. To skip the wait, declare it yourself; a project with nothing to verify yet stays as it is.",
-            actions: [],
-        });
-    }
-}
-// A brief candidate exists but none resolves to a usable prompt block (briefBlockMissing):
-// every run reaches its model with no project prompt, so the team burns tokens producing
-// work unrelated to the project. The same marker-less/unreadable/empty-block state the doctor
-// `brief` row warns on, raised as a standing alert on the always-on surfaces (the bare
-// pre-init repo stays silent). Independent of team state, like the no-check alert beside it.
-function pushNoBriefAlert(out, snap) {
-    if (snap.noBrief) {
-        out.push({
-            key: "no-brief",
-            tone: "amber",
-            title: "The project brief's prompt block is missing or empty — every role runs without its project prompt",
-            detail: "A brief file exists but carries no usable tumwater:prompt block (no markers, or no text between them), so each run's prompt reaches the model with no project brief. Restore the block in the file the doctor `brief` row names, or re-run `tumwater init`.",
-            actions: [],
-        });
-    }
-}
-// A brief block past the read cap (briefBlockOverCap): every run's prompt silently carries
-// only the head plus a truncation marker, so each role plans and codes against a cut brief.
-// The same over-cap state the doctor `brief` row warns on, raised as a standing alert on the
-// always-on surfaces; mutually exclusive with `no-brief` (an over-cap block is non-empty).
-function pushBriefTruncatedAlert(out, snap) {
-    if (snap.briefTruncated) {
-        out.push({
-            key: "brief-truncated",
-            tone: "amber",
-            title: "The project brief is over its prompt cap — every role runs on a truncated brief",
-            detail: "The brief block exceeds the read cap, so each run's prompt carries only its head plus a truncation marker. Shorten the block to at most " + BRIEF_TEXT_MAX_CHARS + " characters in the file the doctor `brief` row names (a hand edit, or the dashboard's Brief card), then save it.",
-            actions: [],
-        });
-    }
-}
-// A role note past the read bound (collectRoleNotesOverCap's predicate, the doctor `role
-// notes` row's own): `readRoleNote` truncates that role's note on read, so the role's next
-// prompt carries only the note's head plus a truncation marker while the operator sees the
-// file whole — a silently degraded next run on a green-looking status. The standing twin of
-// the doctor `role notes` row's warn, raised as an amber alert on the always-on surfaces.
-// Independent of team state, like the no-brief alert beside it.
-function pushRoleNotesTruncatedAlert(out, snap) {
-    const notesOver = snap.roleNotesOverCap ?? [];
-    if (notesOver.length > 0) {
-        out.push({
-            key: "role-notes-truncated",
-            tone: "amber",
-            title: `${plural(notesOver.length, "role note is", "role notes are")} over the read bound — those roles run on truncated notes`,
-            detail: `${joinWithMore(notesOver.map((o) => `${o.role} (${o.chars})`), 3)} exceed the ${ROLE_NOTES_MAX_BYTES}-character read bound, so each of those roles' prompt carries only the note's head plus a truncation marker. Rewrite them under the cap (the run's \`tumwater-notes write\` shim, \`tumwater role <id> --notes-file <path>\`, the dashboard drawer, or the TUI notes editor).`,
-            actions: [],
-        });
-    }
-}
-// PRINCIPLES.md is over its prompt cap (principlesBlockOverCap): every role's <principles>
-// block carries only its head plus a truncation marker, so the team runs on truncated design
-// guidance. The same over-cap state the doctor `principles` row warns on, raised as a standing
-// alert on the always-on surfaces. Independent of team state, like the no-brief alert beside it.
-function pushPrinciplesTruncatedAlert(out, snap) {
-    if (snap.principlesTruncated) {
-        out.push({
-            key: "principles-truncated",
-            tone: "amber",
-            title: "PRINCIPLES.md is over its prompt cap — every role runs on truncated design guidance",
-            detail: "The file exceeds the " + PRINCIPLES_MAX_CHARS + "-character prompt cap, so every run's <principles> block carries only its head plus a truncation marker and only the leading bullets survive. Keep PRINCIPLES.md to its list bullets and move long-form rationale into docs/, which is not injected.",
-            actions: [],
-        });
-    }
-}
 function pushMainRedAlert(out, snap, roles) {
     const red = roles.filter((l) => l.phase === "main's check is failing");
     if (red.length) {
@@ -246,81 +145,21 @@ function pushStuckRoleAlert(out, roles) {
         });
     }
 }
-function pushBuildAlert(out, snap) {
-    if (snap.build?.stale) {
-        const behind = plural(snap.build.aheadCommits ?? 0, "commit");
-        // The cooldown scopes the deferral to the redeploy, not the team (PLANS.md 2026-10-23): a
-        // restart held by the cooldown leaves the roles running on the stale build, so its alert
-        // reads blue "work continues" with the deadline, while a genuinely blocked restart (red main,
-        // a failed build, a boot refusal) stays the amber "restart blocked", and the momentary drain
-        // of an in-flight restart — the one stale state that actually holds new runs and merges —
-        // keeps the plain wording.
-        const deferred = snap.build.restartBlocked?.startsWith("cooldown until ");
-        out.push(deferred
-            ? {
-                key: "build",
-                tone: "blue",
-                title: `Update available (${behind} behind) — restarts after cooldown; work continues`,
-                detail: `Work continues on the running build; the restart lands when the cooldown lapses or you force it (${localizeInstants(snap.build.restartBlocked ?? "")}).`,
-                actions: [],
-            }
-            : snap.build.restartBlocked
-                ? {
-                    key: "build",
-                    tone: "amber",
-                    title: `Update available (${behind} behind) — restart blocked`,
-                    detail: localizeInstants(snap.build.restartBlocked),
-                    actions: [],
-                }
-                : {
-                    key: "build",
-                    tone: "blue",
-                    title: `Update available (${behind} behind)${snap.build.restartPending ? " — restarts when idle" : ""}`,
-                    detail: snap.build.restartPending ? "The team restarts onto it once running work finishes." : "Restart tumwater start to pick it up.",
-                    actions: [],
-                });
-    }
-}
-// A work-instance claim the operator should act on without running `tumwater doctor`
-// (src/scheduling/claim-entries.ts, the doctor's `parallel instances` row): a stopped
-// instance holding an entry that left its role's section, or idle past the scheduler's
-// release window, is an amber ask. One detail line per claim, worded like the doctor row so
-// the two cannot drift; actions open the first three claimed roles. Nothing when empty.
-function pushStaleClaimsAlert(out, staleClaims) {
-    if (staleClaims.length > 0) {
-        out.push({
-            key: "stale-claims",
-            tone: "amber",
-            title: `${plural(staleClaims.length, "work-instance claim is", "work-instance claims are")} stale`,
-            detail: staleClaims.map(staleClaimDetail).join("; "),
-            actions: openRoleActions(staleClaims.map((c) => ({ role: c.id }))),
-        });
-    }
-}
 /** The status/capacity and role-phase alerts, in emission order: a spent budget
- * (chain/fallback/budget), per-role cap, disk, install, and main-red holds, roles
- * failing run after run or stuck, and a stale running build. Extracted from
- * teamAlerts (part 1/5 of the teamAlerts split) so the shared module stays small;
- * the input names exactly the fields this run reads. The caller pushes the returned
- * alerts at the position this run used to occupy, so the emitted key order is
+ * (chain/fallback/budget), disk, install, and main-red holds, roles failing run after run or
+ * stuck. Extracted from teamAlerts (part 1/5 of the teamAlerts split) so the shared module
+ * stays small; the input names exactly the fields this run reads. The caller pushes the
+ * returned alerts at the position this run used to occupy, so the emitted key order is
  * unchanged. */
 export function buildStatusAlerts(input) {
-    const { snap, roles, staleClaims } = input;
+    const { snap, roles } = input;
     const out = [];
     pushChainAlert(out, snap);
     pushSpentBudgetAlert(out, snap);
-    pushRoleCapAlert(out, snap, roles);
     pushDiskAlert(out, snap);
     pushInstallDriftAlert(out, snap);
-    pushNoCheckAlert(out, snap);
-    pushNoBriefAlert(out, snap);
-    pushBriefTruncatedAlert(out, snap);
-    pushRoleNotesTruncatedAlert(out, snap);
-    pushPrinciplesTruncatedAlert(out, snap);
     pushMainRedAlert(out, snap, roles);
     pushFailingStreakAlert(out, roles);
     pushStuckRoleAlert(out, roles);
-    pushBuildAlert(out, snap);
-    pushStaleClaimsAlert(out, staleClaims);
     return out;
 }