feat(registry-dash): persist AI tool-call entries in chat scrollback (SRE-1963) (#141)

* feat(registry-dash): persist AI tool-call entries in chat scrollback (SRE-1963)

Tool-call indicators previously vanished the moment a tool returned, leaving
the user with no record of which tools the assistant called or how each one
resolved. Make each tool call a persistent pill in the chat timeline so the
chat surface mirrors how Claude Code's CLI renders tool calls.

Frontend-only — the SSE stream from RegistryDashAiAction already carries
tool name, args, structured status (SRE-1958), and diagnostic. No backend
change required.

Data model
- New ToolMessage variant + ChatTimelineEntry union in ai-analysis.models.ts.
  ConversationMessage stays the wire shape; toWireHistory() strips tool
  entries before sending follow-up turns to the backend.
- Drop now-unused ToolInFlight / ToolCompleted types.

Service lifecycle (ai-analysis.service.ts)
- conversationHistory becomes the single source of truth for the timeline,
  typed ChatTimelineEntry[].
- On tool_use: flush any pending streamed text to an assistant entry first,
  then push an IN_FLIGHT tool entry. Preserves chronological order across
  text -> tool -> text streams.
- On tool_result: update the latest matching IN_FLIGHT entry in place.
- analyze() smart-merges incoming wire history (prefix-match append, falling
  back to wholesale replace) so prior turns' tool entries survive across
  follow-ups instead of being clobbered by the next request body.
- On cancel/abort/network drop: terminateInFlight() flips any leftover
  IN_FLIGHT entries to INTERNAL_ERROR with diagnostic "Cancelled" so
  pills stop pulsing.
- Drop toolsInFlight / toolsCompleted / toolsUsed signals — derivable
  from conversationHistory and no external consumers.

Modal (ai-analysis-modal.component.{ts,html,scss})
- New tool branch in the persistent chat loop renders a single .tool-pill.
  Variants: --in-flight (italic + pulsing dots), --ok (presence == success,
  no chip suffix), --warn / --error (chip suffix carries the SRE-1958
  status text + tooltip with the diagnostic).
- Streaming block trimmed to streamed text + progress bar; tool rendering
  moves into the persistent timeline.
- chipFor() updated for ToolMessage; new ariaLabelFor() composes the
  screen-reader description.
- runQueuedPrompt() filters via toWireHistory() before constructing the
  request body so tool entries never round-trip to the backend.

Tests
- ai-analysis.service.spec.ts: rewrites the two existing tool tests to
  assert on conversationHistory; adds 4 new SRE-1963 cases (multi-tool
  ordering, text-tool-text interleave, IN_FLIGHT-resolved-on-cancel,
  cross-turn preservation + wire-shape stripping).
- ai-analysis-modal.component.spec.ts: drops toolsInFlight from the stub
  (no longer on the service); adds a persistent tool pills describe block
  covering IN_FLIGHT/OK/non-OK rendering, multi-pill ordering, and the
  chipFor matrix.
- All 115 ai-analysis specs pass. Pre-existing ExploreComponent /
  RevenueBilling failures are unrelated (verified via stash).

Test plan (.claude/plugins/.../test-plan.md)
- Test 18 rewritten for persistence (pill stays visible through and past
  the response).
- Test 65 updated: OK = pill present, no chip suffix; non-OK = pill +
  chip suffix.
- New Test 68 covers multi-tool persistence, cross-turn survival, wire-
  payload stripping, and cancel cleanup.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* fix(registry-dash): FIFO match + accurate diagnostic for AI tool pills

Address two correctness issues in ai-analysis.service.ts surfaced during
review of #141 (SRE-1963):

1. updateLatestInFlight() iterated LIFO, so when the same tool was invoked
   twice in a single turn the first tool_result (which arrives first per
   the backend's FIFO ordering) would land on the second pill, swapping
   diagnostics. Iterate from the start instead so oldest IN_FLIGHT pill
   gets the first matching result.

2. terminateInFlight() unconditionally tagged leftover IN_FLIGHT entries
   with diagnostic "Cancelled". This misrepresents network drops / 5xx /
   unexpected stream ends as user-cancelled. Pass the diagnostic in from
   the caller — "Cancelled" only when controller.signal.aborted, else
   "Interrupted".

New tests:
- same-tool-twice → results match pills FIFO
- stream-end-without-result on a non-aborted controller → diagnostic
  "Interrupted", not "Cancelled"

117/117 ai-analysis specs pass.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

Author: UDtorrey

.claude/plugins/ud-registry-dash/skills/test-registry-dash/test-plan.md

@@ -418,24 +418,29 @@
 
 ---
 
-## Test 18: Tier 3 Tool Use — Indicator UX
+## Test 18: Tier 3 Tool Use — Persistent Tool Pill (SRE-1963)
 
-**Goal:** Verify the analysis modal shows transient tool indicators when Claude calls a tool.
+**Goal:** Verify the analysis modal shows a tool pill when Claude calls a tool, and the pill **stays visible in the chat scrollback after execution** so the user can see what tools ran.
 **Tier:** full
 
 ### Steps:
 1. Navigate to **Domain Activity** (or any page with sparkle).
 2. Click sparkle → open the analysis modal.
 3. Wait for the initial analysis to finish.
 4. In the follow-up box, type: `What specific domains transferred in the last 30 days for the example tld?` (substitute a TLD with seeded transfer data).
-5. Watch for an inline indicator below the streaming text: `🔍 Searching transfers…` (italic, slight pulse animation).
-6. The indicator should appear when the tool is in flight and disappear once the tool result arrives.
-7. The final assistant text should reference specific domain names that came from the tool.
+5. Watch for an inline tool pill: `🔍 Searching transfers…` (italic with pulsing dots while in flight).
+6. When the tool completes, the pill **must remain visible** — the dots and italic styling go away, but the pill itself stays in the timeline at the chronological position the tool fired.
+7. The final assistant text streams in **below** the pill (not above, not replacing it).
+8. After the response finishes, scroll up — the pill is still there.
+9. Send a follow-up question that triggers a different tool (e.g. `Look up registrar TheRegistrar`). The new pill appears below the prior turn; the old pill from turn 1 is still visible.
 
 ### Expected:
-- Indicator appears mid-stream and is replaced by the next text chunk.
-- Final answer contains specific domain names, not just chart-level summaries.
-- Modal does not crash or hang.
+- A tool pill appears for every `tool_use` event and persists through and past the response.
+- IN_FLIGHT pill: italic, pulsing `…` indicator.
+- OK terminal: solid pill, no chip suffix (the pill's mere presence confirms success).
+- Non-OK terminal: solid pill with a colored chip suffix (see Test 65 for status-specific coverage).
+- Final answer contains specific domain names from the tool result.
+- Modal does not crash or hang; no pills disappear or become orphaned.
 
 ---
 
@@ -1429,25 +1434,26 @@ Steps: open modal on Financials > Forecasting, ask "How many domains in tld exam
 
 ---
 
-## Test 65: Tier 3 Tool Use - Result-status chips (SRE-1958)
+## Test 65: Tier 3 Tool Use - Result-status chips (SRE-1958, updated for SRE-1963)
 
-**Goal:** Verify the modal renders disambiguated status chips next to tool-call indicators when a tool returns a non-OK status, with the diagnostic visible on hover.
+**Goal:** Verify the persistent tool pill (SRE-1963) carries a disambiguated status-chip suffix when a tool returns a non-OK status, with the diagnostic visible on hover.
 
 ### Steps:
 1. Navigate to **Domain Activity** and open the analysis modal (any prompt).
 2. Wait for the initial analysis to finish.
 3. Trigger an `EMPTY_FOR_RANGE` case: ask "Show transfers for tld example between 2025-01-01 and 2025-01-02." (adjust dates to a known-empty window in the target env).
-4. Watch the tool indicator - when it resolves, a yellow/muted chip should appear with text "No data". Hover the chip; the tooltip must contain a diagnostic naming the active filter and data extent.
-5. Trigger an `INVALID_ARGS` case: via DevTools issue an analyze request with `tld=""` or omit a required arg. The chip should be red, text "Invalid args", tooltip naming the offending arg.
-6. Trigger a `PERMISSION_DENIED` case: while logged in as a non-FTE user with limited scope, ask about a TLD outside the scope. The chip should be red, text "No access".
-
-### Expected:
-- For `OK`: no chip, current silent green-checkmark behavior preserved.
-- For `EMPTY_FOR_RANGE`: yellow/muted chip "No data" + diagnostic in `matTooltip`.
-- For `OUT_OF_RANGE`: yellow chip "Out of range" + diagnostic.
-- For `INVALID_ARGS`: red chip "Invalid args" + diagnostic.
-- For `PERMISSION_DENIED`: red chip "No access" + diagnostic.
-- For `INTERNAL_ERROR`: red chip "Tool error" + sanitized diagnostic.
+4. When the tool resolves, the pill stays in the scrollback with a yellow/muted **chip suffix** "No data". Hover the pill; the tooltip must contain a diagnostic naming the active filter and data extent.
+5. Trigger an `INVALID_ARGS` case: via DevTools issue an analyze request with `tld=""` or omit a required arg. The chip suffix should be red, text "Invalid args", tooltip naming the offending arg.
+6. Trigger a `PERMISSION_DENIED` case: while logged in as a non-FTE user with limited scope, ask about a TLD outside the scope. The chip suffix should be red, text "No access".
+
+### Expected:
+- For `OK`: pill stays in the scrollback with **no chip suffix** — its presence alone confirms the tool ran (SRE-1963).
+- For `EMPTY_FOR_RANGE`: pill with yellow/muted "No data" chip suffix + diagnostic in `matTooltip`.
+- For `OUT_OF_RANGE`: pill with yellow "Out of range" chip suffix + diagnostic.
+- For `INVALID_ARGS`: pill with red "Invalid args" chip suffix + diagnostic.
+- For `PERMISSION_DENIED`: pill with red "No access" chip suffix + diagnostic.
+- For `INTERNAL_ERROR`: pill with red "Tool error" chip suffix + sanitized diagnostic.
+- All pills persist in scrollback after the response completes.
 - The streamed `tool_result` frame in the network tab carries `{type: "tool_result", tool, status, diagnostic?, ok}`.
 
 ---
@@ -1591,3 +1597,28 @@ Steps: open modal on Financials > Forecasting, ask "How many domains in tld exam
 ### Expected:
 - The `description` text contains both `dates=required` (for sources like REVENUE, DOMAIN_ACTIVITY, RENEWAL_RATES, EXPIRATION_CURVE, TRANSACTIONS) and `dates=n/a` (for DOMAIN_COUNTS and PRICING_RULES).
 - The `input_schema.required` array does NOT contain `start_date` or `end_date`.
+
+---
+
+## Test 73: Tier 3 Tool Use - Multi-tool persistence + cross-turn survival (SRE-1963)
+
+**Goal:** Confirm every tool call gets its own persistent pill in chronological order, pills survive across follow-up turns, and tool entries are NOT replayed back to the backend on subsequent turns.
+
+### Steps:
+1. Navigate to **Domain Activity** and open the analysis modal.
+2. Wait for the initial analysis to finish.
+3. Ask a multi-tool prompt: `Do a quick test of each tool — check transfers, pricing rules, and registrar activity for tld example.`
+4. Watch the timeline: a separate pill should appear for **each** tool that fires, in the order it fires.
+5. After the response completes, scroll up — every pill is still there.
+6. Send a follow-up: `Now look up registrar TheRegistrar.` Watch the new pill appear in the new turn.
+7. Open DevTools → Network → click the second `/console-api/registry-dash/ai/analyze` request → Payload tab.
+8. Inspect the `conversationHistory` array in the request body.
+9. (Optional) Click Stop mid-response on a long multi-tool prompt. Verify any IN_FLIGHT pill resolves to a terminal state (no spinner stuck pulsing forever).
+
+### Expected:
+- Step 3-4: every `tool_use` event produces a distinct pill; multiple sequential pills render in chronological order interleaved correctly with assistant text chunks.
+- Step 5: prior turn's pills are still visible after the response completes.
+- Step 6: the new turn's pill appears below the prior turn's pills; the prior turn's pills survive.
+- Step 8: `conversationHistory` in the wire payload contains ONLY `{role: "user"|"assistant", content: ...}` entries — **no `role: "tool"` entries** are sent back to the backend.
+- Step 9: cancelled IN_FLIGHT pills resolve to a non-spinning terminal state (e.g., red "Tool error" chip with diagnostic "Cancelled" or "Interrupted" depending on whether the abort was user-initiated).
+- No regression on auto-scroll, queue, resize (PR #134) or stale-state-on-reopen (PR #127).

console-webapp/src/app/registry-dash/ai/ai-analysis-modal.component.html

@@ -51,29 +51,37 @@ <h2 mat-dialog-title>{{ data.title }}</h2>
           <mat-icon class="message-icon">auto_awesome</mat-icon>
           <div class="message-content markdown-body" [innerHTML]="msg.content | markdown"></div>
         </div>
+        <!-- Persistent tool pill (SRE-1963). Shows pulsing dots while
+             IN_FLIGHT, a status chip suffix on non-OK terminal statuses,
+             and just the label for OK — its mere presence confirms the
+             tool ran. Diagnostic, when present, is the matTooltip. -->
+        <div *ngIf="msg.role === 'tool'"
+             class="tool-pill"
+             [class.tool-pill--in-flight]="msg.status === 'IN_FLIGHT'"
+             [class.tool-pill--ok]="msg.status === 'OK'"
+             [class.tool-pill--warn]="chipFor(msg)?.tone === 'warn'"
+             [class.tool-pill--error]="chipFor(msg)?.tone === 'error'"
+             [matTooltip]="msg.diagnostic || ''"
+             [attr.data-tool]="msg.tool"
+             [attr.data-status]="msg.status"
+             tabindex="0"
+             role="status"
+             [attr.aria-label]="ariaLabelFor(msg)">
+          <span class="tool-pill-label">{{ msg.label }}</span>
+          <span *ngIf="msg.status === 'IN_FLIGHT'" class="tool-pill-dots">…</span>
+          <span *ngIf="chipFor(msg) as chip" class="tool-pill-chip"
+                [class.tool-pill-chip--warn]="chip.tone === 'warn'"
+                [class.tool-pill-chip--error]="chip.tone === 'error'">{{ chip.text }}</span>
+        </div>
       </ng-container>
 
-      <!-- Streaming response -->
+      <!-- Streaming response. Tool pills now render in the persistent
+           timeline above (SRE-1963), so this block carries only the
+           streamed text and progress bar. -->
       <div *ngIf="streaming()" class="message assistant-message streaming">
         <mat-icon class="message-icon">auto_awesome</mat-icon>
         <div class="message-content markdown-body">
           <div [innerHTML]="streamedText() | markdown"></div>
-          <ng-container *ngFor="let t of toolsCompleted()">
-            <div *ngIf="chipFor(t) as chip" class="tool-status-chip"
-                 [class.tool-status-chip--warn]="chip.tone === 'warn'"
-                 [class.tool-status-chip--error]="chip.tone === 'error'"
-                 [matTooltip]="t.diagnostic || ''"
-                 [attr.data-tool]="t.tool"
-                 [attr.data-status]="t.status"
-                 tabindex="0"
-                 role="status"
-                 [attr.aria-label]="t.label + ' — ' + chip.text + (t.diagnostic ? ': ' + t.diagnostic : '')">
-              {{ t.label }} — {{ chip.text }}
-            </div>
-          </ng-container>
-          <div *ngFor="let t of toolsInFlight()" class="tool-indicator">
-            {{ t.label }}<span class="tool-indicator-dots">…</span>
-          </div>
           <mat-progress-bar mode="indeterminate" class="stream-progress"></mat-progress-bar>
         </div>
       </div>

console-webapp/src/app/registry-dash/ai/ai-analysis-modal.component.scss

@@ -249,27 +249,52 @@ mat-dialog-actions {
   }
 }
 
-.tool-indicator {
+// Persistent tool pill (SRE-1963). Renders inline in the chat scrollback
+// for every tool that ran. Stays visible after completion so the user
+// can see what was called. State variants:
+//   - --in-flight: italic, pulsing dots while running
+//   - --ok: solid muted pill (presence == success)
+//   - --warn / --error: chip suffix carries status text + tooltip
+.tool-pill {
+  display: inline-flex;
+  align-items: center;
+  gap: 6px;
   margin: 8px 0;
   padding: 6px 10px;
   background: var(--ud-surface-2, #f5f5f5);
   border-left: 3px solid var(--ud-accent);
   border-radius: 4px;
   font-size: 13px;
   color: var(--ud-text-muted, #666);
-  font-style: italic;
+  cursor: help;
+
+  &--in-flight {
+    font-style: italic;
+  }
+
+  &--warn {
+    border-left-color: var(--ud-warn-border, #ffd54f);
+  }
+
+  &--error {
+    border-left-color: var(--ud-error-border, #f5b3ad);
+  }
 }
 
-.tool-status-chip {
+.tool-pill-dots {
+  display: inline-block;
+  animation: tool-pulse 1.2s ease-in-out infinite;
+}
+
+.tool-pill-chip {
   display: inline-flex;
   align-items: center;
-  margin: 4px 8px 4px 0;
-  padding: 4px 10px;
-  border-radius: 12px;
-  font-size: 12px;
+  padding: 2px 8px;
+  border-radius: 10px;
+  font-size: 11px;
   line-height: 1.4;
   font-weight: 500;
-  cursor: help;
+  font-style: normal;
 
   &--warn {
     background: var(--ud-warn-bg, #fff8e1);
@@ -284,12 +309,6 @@ mat-dialog-actions {
   }
 }
 
-.tool-indicator-dots {
-  display: inline-block;
-  margin-left: 2px;
-  animation: tool-pulse 1.2s ease-in-out infinite;
-}
-
 @keyframes tool-pulse {
   0%, 100% { opacity: 0.3; }
   50% { opacity: 1; }