🤖 refactor: auto-cleanup

[mux-bot]

Summary

Rolling, low-risk cleanup batch. Each run adds one extremely small,
behavior-preserving refactor picked from changes that have landed on main
since the last checkpoint.
Auto-cleanup checkpoint: a84603b

Current diff against main:

• src/browser/utils/additionalSystemContextStore.ts — drop the
  unused __resetAdditionalSystemContextFocusForTests export and
  promote pendingFocusGeneration from let to const. The reset
  helper was added speculatively alongside the Instructions tab in
  🤖 feat: Instructions tab in right sidebar #3262, but ripgrep across src/ and tests/ finds zero importers —
  no test ever calls it. Removing it lets the only other reason the
  module needed a mutable binding (the pendingFocusGeneration = new Map() reassignment inside the helper) go away, so the binding can
  be a const Map that's still mutated in place via .set(). The
  requestAdditionalSystemContextFocus /
  getAdditionalSystemContextFocusGeneration callers continue to see
  the exact same Map identity and counter semantics — pure dead-code
  removal with no runtime behavior change.

• src/browser/features/Messages/Mermaid.tsx — hoist the URL-attribute
  set and blocked-scheme list out of sanitizeMermaidSvg into
  module-level constants (SANITIZER_URL_ATTRIBUTES,
  SANITIZER_BLOCKED_URL_SCHEMES). They are pure lookup data with no
  per-call dependency, so allocating them on every Mermaid render was
  wasted work; they now allocate once per module load. Identical
  contents and identical lookup semantics — pure cleanup with no
  behavior change.

• src/node/services/agentStatusService.ts — hoist the AI SDK v5
  tool-part state → lifecycle phase mapping out of summarizeToolPart
  into a module-level TOOL_PART_PHASE_BY_STATE record. The previous
  nested ternary obscured the actual mapping (output-available and
  output-redacted both fold to "done") and made adding new states a
  multi-line edit. The summarizer now does a single table lookup; the
  union-typed values document the two valid phases inline. States not
  in the table (e.g. input-streaming) still yield null and the bare
  [tool <name>] form, byte-for-byte identical to before.

• src/browser/utils/slashCommands/experimentVisibility.ts (+ two
  consumers) — add createSlashCommandExperimentResolver(snapshot)
  alongside resolveSlashCommandExperimentValue. Three slash-command
  discovery surfaces (suggestions in ChatInput, the ghost-hint call in
  ChatInput, and the CommandPalette palette query) had each inlined
  the same (experimentId) => resolveSlashCommandExperimentValue(experimentId, snapshot) lambda. The new helper returns the exact same closure each
  callsite previously built inline, so the isExperimentEnabled
  predicate handed to getSlashCommandSuggestions / getCommandGhostHint
  is behaviorally identical; only the wiring detail (that resolution
  is parameterized by experiment id) moves into the visibility module.
  Rebased through the goals GA removal — the snapshot now carries
  only workspaceHeartbeats but the resolver helper itself is
  unchanged.

• src/cli/run.ts — fold the Runtime type import into the existing
  import type { InitLogger, WorkspaceInitResult } from "../node/runtime/Runtime"
  line. The SSH-provisioning commit (🤖 perf: cut SSH workspace startup ~9× on the warm path via fused single-RTT materialization #3302) added a second import type { Runtime } from "../node/runtime/Runtime" directly below it; merging
  them is byte-identical semantics with one fewer line of boilerplate.
  No behavior change.

• src/node/services/agentSkills/agentSkillsService.test.ts — extract a
  shared BUILT_IN_SKILL_NAMES constant for the two toEqual([...])
  assertions that previously enumerated the same five built-in skill
  names (imagegen, init, mux-diagram, mux-docs, orchestrate)
  inline. The two call sites differ only in their project-skill prefix;
  spreading the shared constant at the end of each list preserves the
  exact sort order and assertion semantics. The next built-in skill
  added (e.g. when /orchestrate graduates to advertised, or a new
  hidden skill lands) only needs to update one list instead of two.
  Byte-equivalent assertion output; no runtime behavior change.

• src/browser/features/Settings/Sections/TasksSection.tsx — extract an
  AdvisorSwitch component for the per-agent advisor toggle. The
  Tooltip + Switch + optional Reset button block was duplicated
  between renderAgentDefaults and renderUnknownAgentDefaults (added
  in 🤖 fix: enable advisor for default subagents #3309 when the Advisor experiment gained default-on behavior for
  Exec and Plan). The two call sites differ only in the agent-id
  variable they close over and which setter/resetter to invoke, so the
  shared markup now lives in one place. Same aria-label, same
  tooltip text via getAdvisorSwitchState, same conditional Reset
  semantics — the TasksSection UI test (defaults advisor on for Exec and Plan when the experiment is enabled) still finds both switches
  by their unchanged role + name.

• src/common/utils/ai/streamChunks.ts (+ two consumers) — hoist the
  ["text", "delta", "textDelta"] field priority used to extract AI SDK
  v5 text-delta payloads into a shared TEXT_OUTPUT_DELTA_FIELDS
  constant. Both streamManager.ts (the fullStream text-delta part
  handler) and tools/advisor.ts (the advisor streamText onChunk
  text-delta handler, added in 🤖 feat: stream advisor output live #3310) had inlined the same array
  literal; centralizing it prevents drift if the AI SDK normalizes
  another alias and documents the intent in one place. The other two
  extractChunkDeltaText callsites in aiService.ts use deliberately
  different field orderings (["textDelta", "delta", "text"] for
  parent-step text-delta capture, ["text", "textDelta", "delta"] for
  reasoning-delta capture) and are intentionally left untouched.
  Byte-equivalent lookup semantics at every callsite — pure DRY.

• src/browser/features/RightSidebar/GoalTab.tsx — extract a small
  file-scoped StatTileHeader component for the duplicated <dt> +
  inline-Edit-button header row used by BudgetTile and TurnsTile
  (added in 🤖 feat(goals-tab): consolidate Cost/Budget/Remaining + always show Turn cap #3314 when the active-goal stat surface was consolidated).
  The two tiles previously inlined the same flex wrapper, the same
  text-muted text-xs <dt>, and the same text-xs underline Edit
  button — only the label string and aria-label differed. The shared
  helper preserves those two parameters as props and keeps every class
  name, type="button", and aria label byte-for-byte identical, so the
  inline budget/turn-cap editors in GoalTab.test.tsx (which locate
  their openers via getByLabelText("Edit goal budget") /
  getByLabelText("Edit goal turn cap")) still match. Pure DRY; no
  behavior change.

• src/common/orpc/types.ts (+ three consumers) — hoist the
  GoalInterventionPolicy = NonNullable<SendMessageOptions["goalInterventionPolicy"]>
  alias next to SendMessageOptions itself. After 🤖 feat: add goal intervention policy #3319 added the
  policy field, three independent files re-derived the same alias:
  the browser ChatInput/types.ts barrel, node/services/messageQueue.ts,
  and node/services/agentSession.ts. The canonical alias now lives
  beside its source schema; ChatInput/types.ts re-exports it so the
  feature-local import surface stays unchanged, and the two node-side
  files import directly. Identical type semantics at every callsite —
  pure relocation with no runtime behavior change.

• src/node/services/agentSession.ts — convert
  synthesizeSilentContinuationSummary from a private method on
  AgentSession to a module-level free function. The helper, added in
  🤖 fix(goals): treat text-only continuation turns as goal completion #3326 as part of the silent-continuation auto-complete hook, only
  depends on its input parts argument — it never touches this.
  Moving it alongside the existing free helpers
  (stripGoalInterventionPolicy, coerceGoalSyntheticMessageKind,
  extractAgentSkillRefs, etc.) makes the no-this contract obvious
  to readers and keeps the file's helper style consistent. The
  companion maybeAutoCompleteGoalFromSilentContinuation method stays
  on the class because it accesses this.workspaceGoalService,
  this.workspaceId, and the instance-scoped log. Byte-for-byte
  identical logic at the only callsite; the
  agentSession.goalAutoPause.test.ts suite (18/18 pass) continues to
  cover the silent-continuation, dynamic-tool-present, manual-user, and
  paused-goal branches.

• src/node/services/tools/review_pane.ts — switch the dedup seed loop
  in applyReviewPaneUpdate from for (const h of base) { seen.set(..., base.indexOf(h)) } to for (const [i, h] of base.entries()) { seen.set(..., i) }. The previous form ran an O(n²) reference scan on every seed
  iteration even though the loop already had the index in hand; the
  result is byte-equivalent for the realistic case where every entry in
  base is a unique reference (which is always true today — base is
  either [] or [...current] after the previous deduped call) and now
  correct-by-construction even if a future refactor ever introduced
  duplicate references. Same dedup map contents, same final hunk
  ordering — the 15 existing review_pane.test.ts tests (including the
  "dedupes by formatted path:range key when adding, preferring the
  latest comment" case) all pass unchanged. Picked from the
  review_pane_update tool feature landed in 🤖 feat: add review_pane_update tool + Assisted review toggle #3331.

• src/cli/run.ts — extract a CLI_DISABLED_TOOL_NAMES tuple and build
  the mux run toolPolicy array via .map(name => ({ regex_match: name, action: "disable" as const })). The five entries previously inlined
  in buildSendOptions (ask_user_question, status_set, todo_write,
  todo_read, notify) differed only by tool name and all shared the
  exact same action: "disable" shape. Picked from the
  ask_user_question disable that landed in 🤖 fix: disable ask_user_question in mux run #3336 — that commit added
  a fifth identical-shape entry, so the table form is now strictly
  tidier than five copy-pasted object literals, and the next disabled
  CLI tool drops to one string instead of duplicating the object
  shape. Byte-equivalent toolPolicy contents (same five entries,
  same order, same regex_match and action values), so no behavior
  change.

Validation

• make static-check — eslint, tsgo (×2 configs), and prettier all green
  locally; the only red step is fmt-shell-check failing because shfmt
  isn't installed in this environment (pre-existing env limitation, no
  shell files touched by these changes).
• bun test src/node/services/tools/review_pane.test.ts — 15/15 pass,
  covering replace/add/dedupe/reject/normalize/clear/persistence paths.

---

Generated with mux • Model: anthropic:claude-opus-4-7 • Thinking: xhigh

[mux-bot]

⚠️ Auto-fixup could not resolve CI failure: Windows-only flake in tests/ipc/runtime/backgroundBashDirect.test.ts > Foreground to Background Migration > should migrate foreground bash to background and continue running.

Failure:

expect(received).toContain(expected) // indexOf
Expected substring: "BEFORE_BG_fg_to_bg_1779223264672"
Received string:    "Process sent to background with ID: fg_to_bg_1779223264672
Output so far (0 lines):
"
    at tests/ipc/runtime/backgroundBashDirect.test.ts:410:27

Why this is a flake, not caused by the cleanup commit:

• This test is already known to be timing-sensitive on Windows. The file defines FOREGROUND_MIGRATION_READY_MS = process.platform === "win32" ? 900 : 300 and there's an existing commit titled "Harden fast-exit foreground migration assertion on Windows" targeting this exact file.
• The "Output so far (0 lines)" shape means the foreground bash hadn't flushed its first echo line before sendToBackground was called — a Git Bash startup / IO timing race on Windows CI.
• The auto-cleanup diff touches none of: background process manager, LocalRuntime, bash tool, runtime/, or this test. It only touches UI components, agent session/status/queue/stream services, image/advisor/review_pane tools, agentSkills test, experimentVisibility, cli/run, orpc/types, and streamChunks.

Action: No fix pushed. Recommend retrying the Windows job; if it persists, the Windows ready-wait may need to be bumped above 900ms or the assertion further hardened (separate from this cleanup PR).