aiden-runtime 4.1.4 → 4.5.0

package/dist/cli/v4/defaultSoul.js

@@ -30,8 +30,8 @@ exports.PREVIOUS_BUNDLED_SOULS = exports.DEFAULT_SOUL_MD = exports.BUNDLED_SOUL_
 // <act_dont_ask>. ensureSoulMdSeeded compares this against the user's
 // on-disk SOUL.md to decide whether to silent-replace (matches a prior
 // bundled default) or preserve+notify (user-edited).
-exports.BUNDLED_SOUL_VERSION = 'v4.1.4';
-exports.DEFAULT_SOUL_MD = `You are Aiden — a local-first AI agent built by Taracod.
+exports.BUNDLED_SOUL_VERSION = 'v4.5.0';
+exports.DEFAULT_SOUL_MD = `You are Aiden — a local-first AI agent built by Shiva Deore at Taracod.
 
 Identity:
 - You run on the user's machine, native Windows/Linux/macOS (not WSL2).
@@ -47,7 +47,7 @@ Voice:
 
 Behavior:
 - Default to action over discussion. The user wants results.
-- When asked who you are, identify as Aiden. Not "a large language model."
+- When asked who you are, identify as Aiden, built by Shiva Deore at Taracod. Not "a large language model."
 - When asked what you can do, mention specific skills/tools, not generic capabilities.
 - If user mentions trading/NSE/markets, you have specialized skills for that.
 
@@ -318,6 +318,78 @@ the tool calls within a single turn instead of returning halfway and
 asking the user what to do next.
 </keep_going>
 
+Limits:
+- You can't bypass approval prompts for dangerous commands.
+- You don't lie to look smart. If you don't know, you say so.
+`,
+    // v4.1.4 default — Voice rewrite ("Match the user's energy. When the
+    // user asks a thoughtful question…") + EXECUTION_DISCIPLINE_PROSE
+    // softening. Identity attribution still "built by Taracod" only —
+    // v4.1.5 adds "Shiva Deore at" to both identity lines. Users who
+    // installed any v4.1.4.x build have this verbatim text on disk;
+    // silent-upgrade picks them up here.
+    //
+    // CATCH-UP NOTE: this entry was inadvertently omitted from the
+    // v4.1.4 ship (the snapshot appended at that time matched v4.1.2's
+    // Voice block, not the v4.1.4 rewrite). v4.1.5 appends it so the
+    // migration path catches v4.1.4 installs correctly.
+    `You are Aiden — a local-first AI agent built by Taracod.
+
+Identity:
+- You run on the user's machine, native Windows/Linux/macOS (not WSL2).
+- You have 72 bundled skills + access to install more via skills.sh.
+- You remember past sessions via persistent storage.
+- You have 40 tools spanning files, browser, terminal, web, memory.
+
+Voice:
+- Match the user's energy. When the user asks a thoughtful question (opinion, exploration, comparison), engage thoughtfully. When the user asks transactionally, stay tight.
+- On thoughtful questions, share the reasoning before the answer — what you considered, what you discarded, why.
+- Honest above all — if you didn't do something, say so. If you're not sure, say so.
+- You never claim to "have run" a tool unless the trace shows it.
+
+Behavior:
+- Default to action over discussion. The user wants results.
+- When asked who you are, identify as Aiden. Not "a large language model."
+- When asked what you can do, mention specific skills/tools, not generic capabilities.
+- If user mentions trading/NSE/markets, you have specialized skills for that.
+
+<act_dont_ask>
+When a request has an obvious default interpretation, act on it
+immediately instead of asking for clarification. Examples:
+- "play me a popular song" / "play X on youtube" → load skill_view(media-search)
+  and follow it. Substitute fuzzy phrases ("popular song") with a specific
+  chart-topper BEFORE searching, then open_url a /watch?v= URL once.
+  NEVER search verbatim "popular song" — that returns articles, not music.
+- "what files are in my Downloads?" → file_list on Downloads. Don't ask
+  "which user?" — it's the current user.
+- "is port 443 open?" → check this machine. Don't ask "open where?"
+Only ask for clarification when the ambiguity genuinely changes which
+tool you would call.
+</act_dont_ask>
+
+<prerequisite_checks>
+Before acting, check whether prerequisite discovery, lookup, or
+context-gathering steps are needed. If a step depends on output from a
+prior step, resolve that dependency first. Don't skip prerequisite
+steps just because the final action seems obvious.
+</prerequisite_checks>
+
+<missing_context>
+If required context is missing, do NOT guess or hallucinate. Use the
+appropriate lookup tool when missing information is retrievable
+(file_read, file_list, web_search, fetch_url, session_search,
+system_info). Ask a clarifying question ONLY when no tool can resolve
+the ambiguity.
+</missing_context>
+
+<keep_going>
+Work autonomously until the task is fully resolved. Don't stop with a
+plan — execute it. Multi-step tasks (open browser → search → click
+result; or list files → read each → summarise) are expected; chain
+the tool calls within a single turn instead of returning halfway and
+asking the user what to do next.
+</keep_going>
+
 Limits:
 - You can't bypass approval prompts for dangerous commands.
 - You don't lie to look smart. If you don't know, you say so.

package/dist/cli/v4/display/capabilityCard.js

@@ -67,6 +67,32 @@ function renderCapabilityCard(data, colorize) {
     // Compose the inner rows that boxSharp will wrap. Each row is the
     // CONTENT (no border) — boxSharp adds the side borders + padding.
     const rows = [];
+    // v4.2 Phase 3 — optional "what happened" one-liner above the
+    // canStill section. Rendered as a muted-tone line so it reads as
+    // context, not action. Skipped cleanly when absent → v4.1.3
+    // capability-card behaviour preserved for non-Phase-3 callers.
+    if (data.whatHappened) {
+        rows.push('');
+        rows.push(colorize(truncToContent(data.whatHappened), 'muted'));
+    }
+    // v4.2 Phase 3 — optional failure-category pill row. Each entry
+    // renders as `<category>(<count>)` separated by " · " bullets.
+    // Pre-sorted by the generator (desc count then category priority);
+    // renderer just formats. Skipped cleanly when absent.
+    if (data.failuresByCategory && data.failuresByCategory.length > 0) {
+        const pills = data.failuresByCategory
+            .map((p) => `${p.category}(${p.count})`)
+            .join(' · ');
+        const label = colorize('Failures:', 'error');
+        rows.push(`${label} ${truncToContent(pills)}`);
+    }
+    // v4.3 Phase 5 — optional one-line browser context summary
+    // (active tab, blocker kind, other-tab count, stale-ref retries).
+    // Already pre-formatted by recoveryReport's `buildBrowserContextLine`.
+    // Rendered as a muted-tone line below the Failures: row when present.
+    if (data.browserContext) {
+        rows.push(colorize(truncToContent(data.browserContext), 'muted'));
+    }
     if (data.canStill.length > 0) {
         rows.push('');
         rows.push(heading('Can still:'));

package/dist/cli/v4/display/progressBar.js

@@ -52,8 +52,22 @@ const display_1 = require("../display");
  */
 const BAR_CELLS = 10;
 /** Glyphs. Chosen for clean visual weight at the standard mono font. */
-const FILLED = '▰';
-const EMPTY = '▱';
+// v4.1.5 Phase 1d (Q-P1) — glyph palette switch.
+//
+// Was `▰` (U+25B0 BLACK RECTANGLE) + `▱` (U+25B1 WHITE RECTANGLE),
+// from Unicode's "Geometric Shapes" block. NOT in CP437; Windows
+// legacy console fonts (Lucida Console / Consolas defaults) render
+// them as tofu boxes. User visual smoke confirmed the regression
+// on Windows Terminal + ConPTY combinations.
+//
+// New: `▓` (U+2593 DARK SHADE) + `░` (U+2591 LIGHT SHADE), from
+// Unicode's "Block Elements" block AND CP437 — universally
+// supported on every Windows console going back to DOS. Same shade
+// family the existing `statusFooter` (display.ts:773) has shipped
+// with since v3 without ever being garbled. Cleaner palette
+// coherence across all bar surfaces.
+const FILLED = '▓';
+const EMPTY = '░';
 /**
  * Create a progress-bar handle bound to a writable stream + skin.
  * The bar paints on the next `update` call — there's no initial
@@ -89,19 +103,38 @@ function createProgressBar(out, skin) {
         const gutter = (0, frame_1.getIndent)(0);
         return `${gutter}${bar}  ${label}`;
     };
+    // v4.1.5 Part 1a — Issue M (Windows ConPTY buffering fix).
+    //
+    // Mirrors the activityIndicator pattern: the bar OWNS one terminal
+    // row. Every paint ends with `\n` so the buffer flushes; the cursor
+    // sits on the row BELOW the bar while it's visible. Erase walks
+    // up + clears the bar's row, leaving the cursor at col 0 of the
+    // now-empty row for the caller's next write. See activityIndicator
+    // for the full rationale (Windows ConPTY buffers no-newline writes
+    // until a `\n` arrives — without this, long-running stream paints
+    // never visually appeared).
+    const ANSI_UP_ERASE = '\x1b[1A\x1b[2K';
     const paint = () => {
         if (!isTty || hidden)
             return;
-        // `\r\x1b[K` — carriage return + erase to end of line, then
-        // rewrite. Same single-line overwrite pattern as the activity
-        // indicator and tool-row live tick.
-        out.write(`\r\x1b[K${buildLine()}`);
-        printed = true;
+        if (printed) {
+            // Subsequent paint: walk up to the bar's row, clear it, rewrite,
+            // drop a newline so the cursor lands on the row BELOW the bar.
+            out.write(`${ANSI_UP_ERASE}${buildLine()}\n`);
+        }
+        else {
+            // First paint: just write the bar + `\n`. Cursor moves to the
+            // row below, ready for subsequent walk-up-and-erase ticks.
+            out.write(`${buildLine()}\n`);
+            printed = true;
+        }
         lastPaintTokens = outputTokens;
     };
     const erase = () => {
+        // Walk up to the bar's row and clear it. No trailing `\n` — the
+        // caller will write content here and include its own newline.
         if (isTty && printed)
-            out.write('\r\x1b[K');
+            out.write(ANSI_UP_ERASE);
     };
     return {
         update(n, max) {

package/dist/cli/v4/display.js

@@ -18,12 +18,13 @@
  *
  */
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.TOOL_ROW_ARG_CAP = exports.TOOL_ROW_NAME_PAD = exports.Display = exports.SPINNER_PHRASES = exports.TOOL_ICONS = void 0;
+exports.TRAIL_HIDE_TOOLS = exports.TOOL_ROW_ARG_CAP = exports.TOOL_ROW_NAME_PAD = exports.Display = exports.SPINNER_PHRASES = exports.TOOL_ICONS = void 0;
 exports.iconForTool = iconForTool;
 exports.detectConfiguredChannels = detectConfiguredChannels;
 exports.summarizeConfiguredChannels = summarizeConfiguredChannels;
 exports.summarizeChannelState = summarizeChannelState;
 exports.voiceIndicator = voiceIndicator;
+exports.makeNoOpToolRowHandle = makeNoOpToolRowHandle;
 exports.previewToolArgs = previewToolArgs;
 exports.verbForActivity = verbForActivity;
 exports.isPreFramedLine = isPreFramedLine;
@@ -522,14 +523,21 @@ class Display {
                 return (0, box_1.truncateVisible)(text, INTERIOR);
             return text + ' '.repeat(INTERIOR - v);
         };
+        // v4.5 TUI polish — add a leading + trailing blank line so the
+        // box has visual breathing room from the lines above/below, and
+        // a trailing interior blank so contact info doesn't crowd the
+        // bottom border.
         return [
+            '',
             lidIndent + lid,
             wallIndent + pipe + ' '.repeat(INTERIOR) + pipe,
             wallIndent + pipe + padInner(`   ${heart}  ${val('Built solo')}`) + pipe,
             wallIndent + pipe + padInner(`   ${lab('GitHub:')}  ${val('github.com/taracodlabs/aiden')}`) + pipe,
             wallIndent + pipe + padInner(`   ${lab('Web:')}     ${val('aiden.taracod.com')}`) + pipe,
             wallIndent + pipe + padInner(`   ${lab('Contact:')} ${val('contact@taracod.com')}`) + pipe,
+            wallIndent + pipe + ' '.repeat(INTERIOR) + pipe,
             wallIndent + pipe + lid + pipe,
+            '',
         ].join('\n');
     }
     /**
@@ -772,7 +780,21 @@ class Display {
      * content below MUST call `pause()` first; otherwise their content
      * lands on the indicator line and the next tick clobbers it.
      */
-    activityIndicator(initialVerb = 'thinking') {
+    /**
+     * v4.1.5 Issue K — wave-bar option.
+     *
+     * When `opts.waveBar === true` (DEFAULT), the indicator paints a
+     * second row BELOW the verb line — a 10-cell `▰▱` snake-scroll
+     * heartbeat that gives visible motion during long pre-first-token
+     * gaps even when the verb doesn't change. The bar is NOT progress:
+     * it's a constant-cadence heartbeat (250ms shared with the dot
+     * pulse), explicitly not a percentage indicator.
+     *
+     * Pass `{ waveBar: false }` for back-compat with v4.1.4 tests that
+     * assert single-row geometry. Production callers (chatSession) get
+     * the wave bar by default.
+     */
+    activityIndicator(initialVerb = 'thinking', opts = {}) {
         const sk = this.skin;
         const out = this.out;
         const isTty = !!out.isTTY;
@@ -799,6 +821,13 @@ class Display {
         // feedback; a separate bottom-of-screen footer can be added in
         // v4.1.5 if wanted, but it must NOT be glued to the indicator.
         const glyph = sk.applyColors('▲', 'brand');
+        // v4.1.5 Issue K — wave-bar state. Snake-scroll: a 3-cell `▰`
+        // block slides across 10 cells, wrapping at the right edge. Same
+        // 250ms tick as the verb dot pulse — one timer drives both rows.
+        const waveBarEnabled = opts.waveBar !== false; // default true
+        const WAVE_CELLS = 10;
+        const WAVE_BLOCK = 3;
+        let waveFrame = 0;
         const buildLine = () => {
             const dots = '.'.repeat(dotFrame); // 0..3 dots
             const elapsedSec = Math.floor((Date.now() - startTime) / 1000);
@@ -808,14 +837,92 @@ class Display {
             // `▲ {verb}{dots-padded-to-3}{elapsed?}`
             return `${glyph} ${verb}${dots.padEnd(3, ' ')}${elapsedStr}`;
         };
+        /**
+         * v4.1.5 Issue K — render the wave-bar row. A 3-cell `▰` block at
+         * positions `[waveFrame, waveFrame+1, waveFrame+2]` mod 10. The
+         * filled cells paint brand orange, empty cells paint warm-muted.
+         * Same width + glyph set as the token progress bar so the two
+         * rows feel like a coherent palette (one is heartbeat, the other
+         * is real progress).
+         *
+         * Heartbeat semantics: this is NOT progress. The wave moves at a
+         * constant 250ms cadence regardless of any backend metric. It
+         * exists purely so the user sees motion during the unobservable
+         * TTFT (time-to-first-token) wait. The verb row above carries
+         * any real lifecycle signal via `setVerb()`.
+         */
+        const buildWave = () => {
+            // v4.1.5 Phase 1d (Q-P1) — glyph palette switch. Was `▰`/`▱`
+            // (U+25B0/B1, Geometric Shapes) which legacy Windows console
+            // fonts render as tofu. Now `▓`/`░` (U+2593/91, Block Elements
+            // — in CP437, universally supported). Matches the existing
+            // statusFooter chrome that's shipped since v3 without ever
+            // being garbled.
+            const filled = new Set();
+            for (let i = 0; i < WAVE_BLOCK; i += 1) {
+                filled.add((waveFrame + i) % WAVE_CELLS);
+            }
+            // Render cells in order so the snake-scroll visually slides:
+            // we paint cell-by-cell with the right color, joined into one
+            // string. ANSI runs reset per cell — slight overhead but keeps
+            // glyph order true to position. Brand orange filled, warm-muted
+            // empty.
+            const cells = [];
+            for (let c = 0; c < WAVE_CELLS; c += 1) {
+                cells.push(filled.has(c)
+                    ? sk.applyColors('▓', 'brand')
+                    : sk.applyColors('░', 'muted'));
+            }
+            return cells.join('');
+        };
+        // v4.1.5 Part 1a — Issue M (Windows ConPTY buffering fix).
+        //
+        // Prior pattern wrote `\r\x1b[K{indicator}` with NO trailing
+        // newline. On Windows ConPTY, `process.stdout` buffers no-newline
+        // writes — none of the 60 indicator ticks during a 15s gap
+        // actually rendered. The final reply's `\n` chars eventually
+        // flushed the buffer, but by then the indicator's stop()-erase
+        // had also been buffered + flushed, so the user saw 15s of blank
+        // followed by the reply dumping all at once.
+        //
+        // Fix: indicator OWNS one terminal row. Every write that paints
+        // the indicator ends with `\n`, which forces a flush on every
+        // platform. The cursor sits on the LINE BELOW the indicator
+        // while it's running (one visible empty row gap). When the
+        // indicator stops/pauses, we walk back UP to the indicator's
+        // row and erase it — the cursor then sits at col 0 of that
+        // (now empty) row, ready for the caller to write whatever
+        // content follows (header, tool row, stream output).
+        //
+        // ANSI primitives:
+        //   `\x1b[1A` — cursor up 1 line
+        //   `\x1b[2K` — erase the whole current line
+        // Sequence on tick:    walk up → erase → paint → `\n` → cursor below.
+        // Sequence on erase:   walk up → erase (no newline). Cursor on the
+        //                      now-empty indicator row, ready for caller.
+        const ANSI_UP_ERASE = '\x1b[1A\x1b[2K';
         const renderTick = () => {
             if (stopped || paused || !isTty)
                 return;
             dotFrame = (dotFrame + 1) % 4;
-            // `\r\x1b[K` — carriage return + clear line — then write the
-            // fresh indicator. No newline at end: cursor stays at end of
-            // the indicator line, ready for the next overwrite.
-            out.write(`\r\x1b[K${buildLine()}`);
+            // v4.1.5 Issue K — wave snake-scroll advances 1 cell per tick.
+            // Same 250ms cadence as the dot pulse, so both rows move in
+            // visible lockstep. Modulo WAVE_CELLS wraps the leading block
+            // back to the left edge.
+            waveFrame = (waveFrame + 1) % WAVE_CELLS;
+            if (waveBarEnabled) {
+                // 2-row layout: walk up TWO rows (two separate up-1+erase
+                // sequences, which keeps the `\x1b[1A\x1b[2K` substring
+                // assertion-compatible), repaint both, drop newlines so the
+                // cursor lands on the row below the wave bar.
+                out.write(`${ANSI_UP_ERASE}${ANSI_UP_ERASE}` +
+                    `${buildLine()}\n` +
+                    `${buildWave()}\n`);
+            }
+            else {
+                // Single-row layout (back-compat with v4.1.4 tests).
+                out.write(`${ANSI_UP_ERASE}${buildLine()}\n`);
+            }
         };
         const startTick = () => {
             if (stopped || !isTty || tickTimer !== null)
@@ -829,12 +936,41 @@ class Display {
             }
         };
         const eraseLine = () => {
-            if (isTty && printed)
-                out.write('\r\x1b[K');
+            // Walk up to the indicator's row(s) + erase, then drop ONE
+            // newline so the cursor lands on a blank line BELOW the
+            // indicator's old footprint. v4.1.6 polish: previous behavior
+            // left the cursor at col 0 of the just-erased row so caller
+            // writes (agentHeader, tool row, etc.) sat tight against where
+            // the indicator had been. v4.1.5 visual smoke flagged the
+            // wave-bar→`┃ Aiden` proximity as feeling cramped. The
+            // trailing `\n` gains one visible blank row of breathing space
+            // AND adds another Windows ConPTY flush trigger (Issue M).
+            //
+            // v4.1.5 Issue K — with wave bar enabled, walk up 2 rows (two
+            // up-1+erase sequences). Without the bar, walk up 1 row.
+            if (!isTty || !printed)
+                return;
+            if (waveBarEnabled) {
+                out.write(`${ANSI_UP_ERASE}${ANSI_UP_ERASE}\n`);
+            }
+            else {
+                out.write(`${ANSI_UP_ERASE}\n`);
+            }
         };
-        // Initial paint — only on TTY.
+        // Initial paint — only on TTY. Indicator + `\n` so the buffer
+        // flushes and the cursor sits on the row below, ready for the
+        // first tick to walk back up.
+        //
+        // v4.1.5 Issue K — when wave bar is enabled, paint TWO rows:
+        // verb row + wave row, each with trailing `\n`. Cursor lands on
+        // the row below the wave bar. The first tick will walk up 2.
         if (isTty) {
-            out.write(buildLine());
+            if (waveBarEnabled) {
+                out.write(`${buildLine()}\n${buildWave()}\n`);
+            }
+            else {
+                out.write(`${buildLine()}\n`);
+            }
             printed = true;
             startTick();
         }
@@ -861,9 +997,18 @@ class Display {
                     return;
                 // Caller has just finished writing its own content (typically
                 // ending with `\n`), so the cursor is on a fresh line below
-                // whatever was there. Render the indicator there and arm the
-                // tick again.
-                out.write(buildLine());
+                // whatever was there. Paint the indicator + `\n` to claim the
+                // current row(s) and leave the cursor on the row below — same
+                // invariant the initial paint and tick maintain. Trailing `\n`
+                // also flushes Windows ConPTY buffering (Issue M).
+                //
+                // v4.1.5 Issue K — repaint BOTH rows when wave bar enabled.
+                if (waveBarEnabled) {
+                    out.write(`${buildLine()}\n${buildWave()}\n`);
+                }
+                else {
+                    out.write(`${buildLine()}\n`);
+                }
                 printed = true;
                 startTick();
             },
@@ -894,6 +1039,31 @@ class Display {
     // completion so each line in the log carries the final state — no
     // ANSI cursor games on a dumb sink.
     toolRow(name, args) {
+        // v4.1.5 Phase 1d (Q-Q2-a) — TRAIL_HIDE_TOOLS suppression.
+        //
+        // Some tools are pure agent plumbing — the model calls them to
+        // introspect its own registry, not to do user-visible work.
+        // `lookup_tool_schema` is the canonical case: during planning
+        // the agent may invoke it 30+ times to discover unfamiliar tool
+        // shapes. Each call is a sub-millisecond in-memory lookup, but
+        // they flood the visible trail with noise that obscures the
+        // actual user-relevant tool calls.
+        //
+        // Short-circuit: hidden tools get a NO-OP handle that satisfies
+        // the `ToolRowHandle` contract (ok/fail/degraded/retry/blocked/
+        // emptyRetry/emptyFail all defined but write nothing). The
+        // execution path itself is unaffected — the agent still calls
+        // the tool, the planner / skill-enforcement trackers still
+        // record it. Only the visual row is suppressed.
+        //
+        // CRITICAL invariant: `setBeforeFirstToolHook` is fired by
+        // callbacks.ts BEFORE `toolRow()` is called (see callbacks.ts
+        // onToolCall 'before' branch), so `turnHadTools` flips even for
+        // hidden tools. The separator logic stays correct regardless of
+        // whether ONLY hidden tools fired this turn.
+        if (exports.TRAIL_HIDE_TOOLS.has(name)) {
+            return makeNoOpToolRowHandle();
+        }
         const sk = this.skin;
         // ── Build the fixed left portion (icon + verb + detail) ────────────
         // v4.1.3-repl-polish: icons default ON; set AIDEN_UI_ICONS=0 to
@@ -995,8 +1165,31 @@ class Display {
                     writeFinal(`ok ${formatToolDuration(durationMs)} after ${retries} ${retries === 1 ? 'retry' : 'retries'}`, 'warn');
                 }
                 else {
-                    // Clean success — SILENT. Erase on TTY; emit nothing on non-TTY.
-                    eraseLast();
+                    // v4.1.5 Issue N — persistent tool trail in scrollback.
+                    //
+                    // Prior behaviour: silent erase on clean success (`eraseLast()`
+                    // with no replacement write). Tool rows for successful tools
+                    // vanished, leaving only the markdown reply visible afterward.
+                    // The user couldn't see WHAT actions Aiden took unless a tool
+                    // failed or degraded.
+                    //
+                    // Fix: replace the silent erase with a completed-state row
+                    // painted entirely in warm-muted (`#b8a89a` from v4.1.4). The
+                    // duration suffix replaces the live `running Ns…` chrome; the
+                    // whole row reads "done" via reduced visual weight. Failed /
+                    // degraded / retry outcomes keep their existing coloured paint
+                    // (error red, degraded yellow, warn amber) — only clean success
+                    // shifts from "silent" to "muted-persistent."
+                    //
+                    // The persistence mechanism is the existing `writeFinal` path:
+                    // it walks up + erases the running row, then writes the final
+                    // row with trailing `\n`. The row sits in scrollback because
+                    // `streamComplete` rerenders only the post-tool stream chunk
+                    // (via `streamLineCount` which was reset to 0 inside
+                    // `commitStreamChunk` before this row wrote). No additional
+                    // isolation machinery needed — already verified by 13/13
+                    // `smoke-stream-rerender.ts` regressions.
+                    writeFinal(formatToolDuration(durationMs), 'muted');
                 }
             },
             fail(durationMs, retries = 0) {
@@ -1698,6 +1891,56 @@ function renderRmsBar(rms) {
 exports.TOOL_ROW_NAME_PAD = toolTrail_1.TRAIL_VERB_PAD;
 /** @deprecated Use TRAIL_DETAIL_CAP. */
 exports.TOOL_ROW_ARG_CAP = toolTrail_1.TRAIL_DETAIL_CAP;
+/**
+ * v4.1.5 Phase 1d (Q-Q2-a) — names of tools that should be SUPPRESSED
+ * from the visible tool-trail row, even though they still execute
+ * normally through the agent loop.
+ *
+ * The canonical case is `lookup_tool_schema`: the agent calls it
+ * during planning to introspect tool registry entries (in-memory
+ * registry get, sub-millisecond per call). On complex prompts the
+ * model may fire it 30+ times in a row, flooding the visible trail
+ * with rows that don't represent user-meaningful work. Suppressing
+ * them keeps the trail focused on the tools that did real work
+ * (web_search, file_read, etc.).
+ *
+ * Suppression happens at `Display.toolRow()` entry — it returns a
+ * no-op handle that satisfies the `ToolRowHandle` contract but
+ * never writes to stdout. The agent's `callbacks.onToolCall`
+ * dispatch is unchanged: `setBeforeFirstToolHook` still fires (so
+ * `turnHadTools` flips for the separator-emission logic), and
+ * skill-enforcement / honesty-trace tracking still records the
+ * call. Only the visual row is hidden.
+ *
+ * Exported as a `Set` so callers can mutate at runtime if they
+ * need to hide additional tools (e.g. user customization, MCP
+ * plumbing tools). Mutation-of-shared-state is intentional — there's
+ * no per-session config plumbing for "trail hidden tools" yet, so
+ * the env-var pattern (`AIDEN_TRAIL_HIDE=tool1,tool2`) would be the
+ * v4.1.6 evolution.
+ */
+exports.TRAIL_HIDE_TOOLS = new Set([
+    'lookup_tool_schema',
+]);
+/**
+ * v4.1.5 Phase 1d helper — produces a `ToolRowHandle` that satisfies
+ * the contract but writes nothing. Used by hidden tools (see
+ * `TRAIL_HIDE_TOOLS`) and as a safe fallback. All methods are inert.
+ *
+ * Pure — no side effects, no closures over Display state. Safe to
+ * call from any thread / phase.
+ */
+function makeNoOpToolRowHandle() {
+    return {
+        ok: () => { },
+        fail: () => { },
+        degraded: () => { },
+        retry: () => { },
+        blocked: () => { },
+        emptyRetry: () => { },
+        emptyFail: () => { },
+    };
+}
 /**
  * Build a compact, single-line preview of the tool's arguments. Picks
  * the most informative scalar fields when the args are an object, then

package/dist/cli/v4/replyRenderer.js

@@ -43,32 +43,38 @@ function paint(kind) {
     return (text) => (0, skinEngine_1.getSkinEngine)().applyColors(text, kind);
 }
 /**
- * v4.1.3-essentials: bold (`**foo**`) markdown emphasis renders as
- * ANSI bold + underline. Previously painted 'brand' (orange) which
- * collided with the heading hierarchy. Briefly tried bold + bright-
- * white; landed on bold + underline because underline carries
- * emphasis without consuming a color slot — the palette stays
- * available for state semantics (yellow=degraded, red=error, etc.).
+ * v4.1.3-essentials → v4.5 TUI polish: bold (`**foo**`) markdown
+ * emphasis renders as plain ANSI bold. Earlier iterations tried
+ * 'brand' (orange, collided with heading hierarchy), bright-white
+ * (low contrast on dark themes), and bold+underline (made bulleted
+ * list items look like clickable hyperlinks — user feedback after
+ * v4.5 Phase 8 stabilisation).
  *
- * ANSI sequence: `\x1b[1m\x1b[4m{text}\x1b[24m\x1b[22m` — bold ON +
- * underline ON, then underline OFF + bold OFF. Reset order matters
- * (underline first, bold second) so the closing codes don't reorder
- * styles surprisingly on terminals that batch SGR updates.
+ * Landed on bold-only: weight carries emphasis, no color slot
+ * consumed, and no underline confusion with terminal URL/path
+ * auto-highlight features.
  *
- * Bypasses the skin system intentionally — bold-as-underline is an
- * opinionated default for this slice. Same caveat as the prior bold-
- * as-color iteration: nested markdown loses the outer style after
- * close (pre-existing limitation of the painter-stack architecture).
+ * ANSI sequence: `\x1b[1m{text}\x1b[22m` — bold ON, bold OFF.
+ *
+ * Bypasses the skin system intentionally — emphasis is an
+ * opinionated default for this slice. Same caveat as the prior
+ * bold-as-color iteration: nested markdown loses the outer style
+ * after close (pre-existing limitation of the painter-stack
+ * architecture).
  *
  * Honors `NO_COLOR=1` per the standard (skips the wrap entirely).
- * Strictly speaking `NO_COLOR` is about color and underline isn't
- * a color, but the wrap still emits ANSI escapes; honoring the env
- * var keeps output paste-safe in scripted contexts.
+ * Strictly speaking `NO_COLOR` is about color, but the wrap still
+ * emits ANSI escapes; honoring the env var keeps output paste-safe
+ * in scripted contexts.
+ *
+ * Function name: `paintEmphasis` rather than `paintBold` because
+ * the latter is already taken by a different (parameterised) helper
+ * below.
  */
-function paintBoldUnderline(text) {
+function paintEmphasis(text) {
     if (process.env.NO_COLOR && process.env.NO_COLOR !== '')
         return text;
-    return `\x1b[1m\x1b[4m${text}\x1b[24m\x1b[22m`;
+    return `\x1b[1m${text}\x1b[22m`;
 }
 /**
  * v4.1.3-essentials reply-polish: bold-on + skin paint + bold-off.
@@ -367,10 +373,12 @@ function getReplyRenderer() {
         hr: () => paint('muted')('─'.repeat((0, frame_1.getBodyWidth)())) + '\n',
         listitem: renderListItem,
         paragraph: (text) => `${text}\n\n`,
-        // v4.1.3-essentials: bold renders as ANSI bold + underline
-        // (was 'brand' / orange, then bright-white; landed on underline
-        // so the color palette stays available for state semantics).
-        strong: paintBoldUnderline,
+        // v4.1.3-essentials → v4.5 TUI polish: bold renders as plain ANSI
+        // bold. Earlier iterations tried orange (collision with headings),
+        // bright-white (low contrast), and bold+underline (made bulleted
+        // **labels** look like clickable links — user feedback after v4.5
+        // Phase 8 stabilisation). Weight alone carries emphasis.
+        strong: paintEmphasis,
         em: paint('muted'),
         // v4.1.3-essentials reply-polish: inline `` `code` `` — strip
         // the literal backticks (used to leak into the visible output)

package/dist/cli/v4/toolPreview.js

@@ -69,6 +69,16 @@ exports.TOOL_PRIMARY_ARG = {
     skill_view: 'name',
     skill_manage: 'action',
     skills_list: '',
+    // v4.1.5 Phase 1d (Q-Q1-a) — registry introspection tool. Args
+    // shape: `{ toolName: 'web_search' }`. The agent uses this to
+    // discover unfamiliar tool schemas during planning. Surface the
+    // target tool name so the trail row (when not suppressed via
+    // TRAIL_HIDE_TOOLS) reads as the introspected tool, not raw JSON.
+    // Note: most callers see this tool suppressed entirely from the
+    // visible trail via the TRAIL_HIDE_TOOLS set in display.ts; the
+    // extractor exists for code paths that DON'T suppress (verbose
+    // mode, log-file capture).
+    lookup_tool_schema: 'toolName',
     // ── sessions ─────────────────────────────────────────────────────────
     session_search: 'query',
     session_list: '',