Merge branch 'feat/dashboard-agent-flows-watch' into feat/agent-storybook-gallery

Author: kathiekiwi

apps/webapp/app/components/dashboard-agent/ReportView.tsx

@@ -51,6 +51,7 @@ import {
   ReportSeverityIcon,
   type ReportFooterItem,
 } from "./report-sparkline";
+import { reportOffersRecoveryWatch } from "./view-actions";
 
 export type ResolvedUri = { label: string; url: string };
 
@@ -319,19 +320,18 @@ export function ReportView({
 
   // Only offered when there is something to recover from, and only for the health
   // report, which is the one with a recovery watch kind.
-  const recoveryWatch: AgentIntent | null =
-    vm.title === "health" && (severity === "warn" || severity === "crit")
-      ? {
-          kind: "watch",
-          spec: {
-            kind: "health_recovery",
-            report: "health",
-            fromSeverity: severity,
-            note: `${vm.scope} health back to normal`,
-            ...RECOVERY_WATCH,
-          },
-        }
-      : null;
+  const recoveryWatch: AgentIntent | null = reportOffersRecoveryWatch(vm)
+    ? {
+        kind: "watch",
+        spec: {
+          kind: "health_recovery",
+          report: "health",
+          fromSeverity: severity,
+          note: `${vm.scope} health back to normal`,
+          ...RECOVERY_WATCH,
+        },
+      }
+    : null;
 
   // Links a footer action already speaks for aren't repeated as reading matter.
   const footerLinkKeys = new Set(layout.footer.map((entry) => entry.link).filter(Boolean));

apps/webapp/app/components/dashboard-agent/view-actions.test.ts

@@ -102,6 +102,24 @@ describe("one watch button per answer", () => {
     expect(turnAlreadyOffersWatch([actionsCall, investigationCall])).toBe(true);
   });
 
+  // The report card grows its own "Watch…" button from the view model, so the block
+  // carries no watch action to match on.
+  const reportCard = (title: string, severity: string) =>
+    ({ type: "report", vm: { title, summary: { severity, statements: [] } } }) as never;
+
+  it("sees the health report card's recovery watch", () => {
+    expect(cardAlreadyOffersWatch([reportCard("health", "crit")])).toBe(true);
+    expect(cardAlreadyOffersWatch([reportCard("health", "warn")])).toBe(true);
+    const actionsCall = [{ type: "actions", actions: [watchAction] }] as never[];
+    expect(turnAlreadyOffersWatch([[reportCard("health", "crit")], actionsCall])).toBe(true);
+  });
+
+  it("leaves a report card with no watch button alone", () => {
+    // Green: nothing to recover from. And only the health report has a recovery watch.
+    expect(cardAlreadyOffersWatch([reportCard("health", "ok")])).toBe(false);
+    expect(cardAlreadyOffersWatch([reportCard("cost", "crit")])).toBe(false);
+  });
+
   it("says no when no call in the turn has a card offering one", () => {
     const plain = [card([{ label: "Keep digging", intent: { kind: "ask", prompt: "" } }])];
     expect(turnAlreadyOffersWatch([plain, []])).toBe(false);

apps/webapp/app/components/dashboard-agent/view-actions.ts

@@ -5,6 +5,7 @@ import {
   isTriggerUri,
   type ActionsBlockAction,
   type ChartAction,
+  type ReportViewModelPayload,
   type ViewBlock,
 } from "@internal/dashboard-agent-contracts";
 
@@ -23,10 +24,22 @@ export function renderableActions<T extends CardAction>(actions: T[]): T[] {
  * shows the same button twice. The card wins: it is the one with the pre-filled spec.
  */
 export function cardAlreadyOffersWatch(blocks: ViewBlock[]): boolean {
-  return blocks.some(
-    (block) =>
-      block.type === "investigation" &&
-      (block.capabilities?.actions ?? []).some((action) => action.intent.kind === "watch")
+  return blocks.some((block) => {
+    if (block.type === "investigation") {
+      return (block.capabilities?.actions ?? []).some((action) => action.intent.kind === "watch");
+    }
+    return block.type === "report" && reportOffersRecoveryWatch(block.vm);
+  });
+}
+
+/**
+ * The report card's watch button isn't in the block — `ReportView` grows it from the
+ * view model, for a health report with something to recover from. Same condition here,
+ * so the button the user will see is the one the guard counts.
+ */
+export function reportOffersRecoveryWatch(vm: ReportViewModelPayload): boolean {
+  return (
+    vm.title === "health" && (vm.summary.severity === "warn" || vm.summary.severity === "crit")
   );
 }
 

apps/webapp/app/presenters/v3/reports/report-layout.test.ts

@@ -29,6 +29,52 @@ const livenessFinding = {
   metricIds: ["liveness"],
 };
 
+function vmWithMetric(metric: LayoutViewModel["metrics"][number]): LayoutViewModel {
+  return {
+    title: "health",
+    scope: "prod",
+    period: "last 60 min",
+    windowMinutes: 60,
+    summary: { severity: "warn", statements: [] },
+    findings: [{ type: "queue", severity: "warn", reason: "backlog", metricIds: [metric.id] }],
+    metrics: [metric],
+    footer: [],
+  };
+}
+
+function heroDelta(metric: LayoutViewModel["metrics"][number]) {
+  const layout = buildReportLayout(vmWithMetric(metric), reportMessages("health"));
+  return layout.hero?.metrics.find((m) => m.id === metric.id)?.delta;
+}
+
+describe("buildReportLayout metric deltas", () => {
+  it("renders no delta when a metric collapsed to nothing", () => {
+    expect(
+      heroDelta({
+        id: "pending",
+        value: 0,
+        unit: "count",
+        severity: "warn",
+        normal: 40,
+        delta: { dir: "down", mult: 0 },
+      })
+    ).toBeUndefined();
+  });
+
+  it("still renders a multiplier for a genuine fall", () => {
+    expect(
+      heroDelta({
+        id: "pending",
+        value: 10,
+        unit: "count",
+        severity: "warn",
+        normal: 40,
+        delta: { dir: "down", mult: 0 },
+      })
+    ).toEqual({ text: "↓ 4×", dir: "down" });
+  });
+});
+
 describe("buildReportLayout self-evident findings", () => {
   it("drops the metric row of a non-hero finding whose only metric is its own line", () => {
     const layout = buildReportLayout(

apps/webapp/app/presenters/v3/reports/report-layout.ts

@@ -574,7 +574,8 @@ function metricDelta(metric: LayoutMetricInput): LayoutDelta | undefined {
   // A fall's own multiplier rounds to 0 or 1, so measure how far it fell instead.
   if (delta?.dir === "down") {
     const fall = fallMultiplier(metric);
-    if (fall === null) return { text: REPORT_GLYPH.down, dir: "down" };
+    // An arrow with no multiplier behind it says nothing the sparkline hasn't.
+    if (fall === null) return undefined;
     if (fall !== undefined) return { text: `${REPORT_GLYPH.down} ${fall}×`, dir: "down" };
   }
   if (delta && delta.mult !== undefined && delta.mult > 1 && delta.dir !== "flat") {

internal-packages/dashboard-agent/src/__snapshots__/prompt-prefix.test.ts.snap

@@ -88,7 +88,7 @@ describe("the head-start and agent prefixes are the same prefix", () => {
  * drift. The snapshot below is the itemised diff a reviewer reads.
  */
 const PREFIX_BUDGET = {
-  assistant: { chars: 77_000, estimatedTokens: 19_500, tools: 24, promptChars: 26_000 },
+  assistant: { chars: 77_000, estimatedTokens: 19_500, tools: 24, promptChars: 26_500 },
   code: { chars: 83_000, estimatedTokens: 21_000, tools: 28, promptChars: 29_000 },
 } as const;
 

internal-packages/dashboard-agent/src/prompt-prefix.test.ts

@@ -508,7 +508,7 @@ Guidelines:
 - "How do I check X?" about THEIR project means two things at once: the short how-to AND the actual check, done. Answer "how do I check queue health?" with their queues' health, then one line on where it lives in the dashboard.
 - The user does only what your tools genuinely cannot reach: their own infra, their code, external pages. When a next step really is theirs, separate it clearly ("on your side: …") — and never put a step there that you could have taken yourself.
 - For "what's broken" or "why is X failing" questions, start with list_errors to find the error groups, get_error for the detail, then list_runs with that error id to drill into the actual failing runs (and get_run_trace for one of them).
-- An answer whose headline is an UNRESOLVED, recurring error ENDS with the watch offer — one line, "Want me to set up a watch so you're told if it hits again?", plus the render_view "actions" block that makes it a button — not with generic advice alone. This is the rule from the Watches section applied to its most common case; it is not optional there, and neither is the button.
+- An answer whose headline is an UNRESOLVED, recurring error ENDS with the watch offer — one line, "Want me to set up a watch so you're told if it hits again?", then the render_view "actions" block that makes it a button — not with generic advice alone. This is the rule from the Watches section applied to its most common case; it is not optional there, and neither is the button.
 - Your tools are read-only and scoped to the current environment for run and task lookups. You can't change anything; for actions, point the user to where in the dashboard they can do it.
 - Never invent run IDs, task identifiers, metrics, or features. If a tool returns an error or nothing, say so plainly.
 - A truncated or paged result supports what you saw, never what you didn't. When a result is truncated or returns a nextCursor, you may not claim an absence — "only send-receipt failed", "nothing else is failing", "there are no others" are all out, even hedged with "in what I saw". Say what the page showed and that the list is incomplete, or read a source that can answer completeness (list_errors groups every error in the window) before you answer.
@@ -534,7 +534,7 @@ Is anything wrong?:
 
 Watches — telling the user later:
 - When the user wants to be told when something happens ("tell me when this run finishes", "let me know when the backlog drains", "tell me when it's back under 100", "tell me if that queue stops moving", "ping me if runs start waiting more than 5 minutes", "ping me if that error comes back", "tell me when prod is healthy again"), call schedule_watch. Never poll: repeating a read tool until the thing happens is not a watch, and you cannot wait inside a turn.
-- Offer a watch whenever your answer points at something worth monitoring that you can't resolve now: a recurring or unresolved error, a queue trending toward trouble, a condition the user would want to hear about the moment it changes. The offer is two things together: one short line ("Want me to set up a watch so you're told if it hits again?") AND a render_view "actions" block with one button — label it like "Set up a watch", intent {"kind":"watch","spec":{…}} carrying the same spec schedule_watch would compose. Clicking it opens the configuration card pre-filled, so the user answers with a click instead of typing "yeah". One offer per answer at most; skip it when the news is good, when the user is clearly just browsing, or when this answer's investigation card already carries a watch button — the card is the offer, and repeating it puts two watch buttons on one answer. schedule_watch is still how you answer a user who asks for a watch in their own words.
+- Offer a watch whenever your answer points at something worth monitoring that you can't resolve now: a recurring or unresolved error, a queue trending toward trouble, a condition the user would want to hear about the moment it changes. The offer is two things in this order: one short line ("Want me to set up a watch so you're told if it hits again?") as the LAST sentence of your answer, and THEN the render_view "actions" block with one button, emitted after that line as the final part of the turn with nothing after it — label it like "Set up a watch", intent {"kind":"watch","spec":{…}} carrying the same spec schedule_watch would compose. Clicking it opens the configuration card pre-filled, so the user answers with a click instead of typing "yeah". One offer per answer at most; skip it when the news is good, when the user is clearly just browsing, or when a card you just rendered already carries a watch button — an investigation card, or a health report card whose next steps offer "Watch recovery". That card is the offer, and repeating it puts two watch buttons on one answer. schedule_watch is still how you answer a user who asks for a watch in their own words.
 - schedule_watch does not start anything. It opens a configuration card pre-filled with what you composed, and the user confirming that card is what starts the watch. So say what you filled in — what is being watched, how often it checks, and when it gives up (the maxHours you set) — and that confirming starts it. Never say it's running, scheduled, or that you'll tell them later: "I've filled in a watch for you to review — confirm to start it", never "I'll let you know when it finishes". Pick the longest cadence that still answers in time — 1 minute only for a run's state, 5 minutes or more for backlog, error recurrence, and health.
 - The card settles everything after the user confirms: whether this chat can hold another watch, whether the same thing is already watched, and whether the condition is already true (in which case they get the answer instead of a watch). Never promise, predict, or pre-explain any of those.
 - A watch wake is a message you send unprompted, and it is narrated ONCE, briefly: what the outcome was, the numbers from the facts you were given, and one suggested next step. Nothing else — no new investigation, no fresh reads, no recap of the conversation.