Update CONTRIBUTING and README.md to remove stale

and architecture information.

CONTRIBUTING.md

@@ -352,21 +352,6 @@ npm run lint
 - **Imports:** Pay special attention to import paths. The project uses ESLint to
   enforce restrictions on relative imports between packages.
 
-### Project structure
-
-- `packages/`: Contains the individual sub-packages of the project.
-  - `a2a-server`: A2A server implementation for the Gemini CLI. (Experimental)
-  - `cli/`: The command-line interface.
-  - `core/`: The core backend logic for the Gemini CLI.
-  - `test-utils` Utilities for creating and cleaning temporary file systems for
-    testing.
-  - `vscode-ide-companion/`: The Gemini CLI Companion extension pairs with
-    Gemini CLI.
-- `docs/`: Contains all project documentation.
-- `scripts/`: Utility scripts for building, testing, and development tasks.
-
-For more detailed architecture, see `docs/architecture.md`.
-
 ### Debugging
 
 #### VS Code

README.md

@@ -314,7 +314,6 @@ gemini
 
 - [**Headless Mode (Scripting)**](./docs/cli/headless.md) - Use Gemini CLI in
   automated workflows.
-- [**Architecture Overview**](./docs/architecture.md) - How Gemini CLI works.
 - [**IDE Integration**](./docs/ide-integration/index.md) - VS Code companion.
 - [**Sandboxing & Security**](./docs/cli/sandbox.md) - Safe execution
   environments.

docs/cli/tutorials/file-management.md

@@ -7,9 +7,9 @@ create files, and control what Gemini CLI can see.
 ## Prerequisites
 
 - Gemini CLI installed and authenticated.
-- A project directory to work with (e.g., a git repository).
+- A project directory to work with (for example, a git repository).
 
-## How to give the agent context (Reading files)
+## Providing context by reading files
 
 Gemini CLI will generally try to read relevant files, sometimes prompting you
 for access (depending on your settings). To ensure that Gemini CLI uses a file,
@@ -58,7 +58,7 @@ You know there's a `UserProfile` component, but you don't know where it lives.
 ```
 
 Gemini uses the `glob` or `list_directory` tools to search your project
-structure. It will return the specific path (e.g.,
+structure. It will return the specific path (for example,
 `src/components/UserProfile.tsx`), which you can then use with `@` in your next
 turn.
 
@@ -111,8 +111,8 @@ or, better yet, run your project's tests.
 `Run the tests for the UserProfile component.`
 ```
 
-Gemini CLI uses the `run_shell_command` tool to execute your test runner (e.g.,
-`npm test` or `jest`). This ensures the changes didn't break existing
+Gemini CLI uses the `run_shell_command` tool to execute your test runner (for
+example, `npm test` or `jest`). This ensures the changes didn't break existing
 functionality.
 
 ## Advanced: Controlling what Gemini sees

docs/cli/tutorials/mcp-setup.md

@@ -52,7 +52,7 @@ You tell Gemini about new servers by editing your `settings.json`.
         "--rm",
         "-e",
         "GITHUB_PERSONAL_ACCESS_TOKEN",
-        "ghcr.io/github/github-mcp-server:latest"
+        "ghcr.io/modelcontextprotocol/servers/github:latest"
       ],
       "env": {
         "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"

docs/cli/tutorials/memory-management.md

@@ -11,8 +11,8 @@ persistent facts, and inspect the active context.
 
 ## Why manage context?
 
-Out of the box, Gemini CLI is smart but generic. It doesn't know your preferred
-testing framework, your indentation style, or that you hate using `any` in
+Gemini CLI is powerful but general. It doesn't know your preferred testing
+framework, your indentation style, or or your preference against `any` in
 TypeScript. Context management solves this by giving the agent persistent
 memory.
 
@@ -109,11 +109,11 @@ immediately. Force a reload with:
 
 ## Best practices
 
-- **Keep it focused:** Don't dump your entire internal wiki into `GEMINI.md`.
-  Keep instructions actionable and relevant to code generation.
+- **Keep it focused:** Avoid adding excessive content to `GEMINI.md`. Keep
+  instructions actionable and relevant to code generation.
 - **Use negative constraints:** Explicitly telling the agent what _not_ to do
-  (e.g., "Do not use class components") is often more effective than vague
-  positive instructions.
+  (for example, "Do not use class components") is often more effective than
+  vague positive instructions.
 - **Review often:** Periodically check your `GEMINI.md` files to remove outdated
   rules.
 

docs/cli/tutorials/shell-commands.md

@@ -7,7 +7,7 @@ automate complex workflows, and manage background processes safely.
 ## Prerequisites
 
 - Gemini CLI installed and authenticated.
-- Basic familiarity with your system's shell (Bash, Zsh, PowerShell, etc.).
+- Basic familiarity with your system's shell (Bash, Zsh, PowerShell, and so on).
 
 ## How to run commands directly (`!`)
 
@@ -49,7 +49,7 @@ You want to run tests and fix any failures.
 6.  Gemini uses `replace` to fix the bug.
 7.  Gemini runs `npm test` again to verify the fix.
 
-This loop turns Gemini into an autonomous engineer.
+This loop allows Gemini to work autonomously.
 
 ## How to manage background processes
 
@@ -75,7 +75,7 @@ confirmation prompts) by streaming the output to you. However, for highly
 interactive tools (like `vim` or `top`), it's often better to run them yourself
 in a separate terminal window or use the `!` prefix.
 
-## Safety first
+## Safety features
 
 Giving an AI access to your shell is powerful but risky. Gemini CLI includes
 several safety layers.

docs/get-started/authentication.md

@@ -40,8 +40,8 @@ Select the authentication method that matches your situation in the table below:
 
 If you run Gemini CLI on your local machine, the simplest authentication method
 is logging in with your Google account. This method requires a web browser on a
-machine that can communicate with the terminal running Gemini CLI (e.g., your
-local machine).
+machine that can communicate with the terminal running Gemini CLI (for example,
+your local machine).
 
 > **Important:** If you are a **Google AI Pro** or **Google AI Ultra**
 > subscriber, use the Google account associated with your subscription.
@@ -130,7 +130,7 @@ For example:
 **macOS/Linux**
 
 ```bash
-# Replace with your project ID and desired location (e.g., us-central1)
+# Replace with your project ID and desired location (for example, us-central1)
 export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
 export GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
 ```
@@ -138,7 +138,7 @@ export GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
 **Windows (PowerShell)**
 
 ```powershell
-# Replace with your project ID and desired location (e.g., us-central1)
+# Replace with your project ID and desired location (for example, us-central1)
 $env:GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
 $env:GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
 ```
@@ -325,14 +325,14 @@ persist them with the following methods:
 1.  **Add your environment variables to your shell configuration file:** Append
     the environment variable commands to your shell's startup file.
 
-    **macOS/Linux** (e.g., `~/.bashrc`, `~/.zshrc`, or `~/.profile`):
+    **macOS/Linux** (for example, `~/.bashrc`, `~/.zshrc`, or `~/.profile`):
 
     ```bash
     echo 'export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"' >> ~/.bashrc
     source ~/.bashrc
     ```
 
-    **Windows (PowerShell)** (e.g., `$PROFILE`):
+    **Windows (PowerShell)** (for example, `$PROFILE`):
 
     ```powershell
     Add-Content -Path $PROFILE -Value '$env:GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"'
@@ -346,8 +346,8 @@ persist them with the following methods:
 2.  **Use a `.env` file:** Create a `.gemini/.env` file in your project
     directory or home directory. Gemini CLI automatically loads variables from
     the first `.env` file it finds, searching up from the current directory,
-    then in your home directory's `.gemini/.env` (e.g., `~/.gemini/.env` or
-    `%USERPROFILE%\.gemini\.env`).
+    then in your home directory's `.gemini/.env` (for example, `~/.gemini/.env`
+    or `%USERPROFILE%\.gemini\.env`).
 
     Example for user-wide settings:
 

docs/get-started/gemini-3.md

@@ -25,7 +25,7 @@ Get started by upgrading Gemini CLI to the latest version:
 npm install -g @google/gemini-cli@latest
 ```
 
-After you’ve confirmed your version is 0.21.1 or later:
+If your version is 0.21.1 or later:
 
 1. Run `/model`.
 2. Select **Auto (Gemini 3)**.
@@ -109,7 +109,7 @@ then:
 
 Restart Gemini CLI and you should have access to Gemini 3.
 
-## Need help?
+## Next steps
 
 If you need help, we recommend searching for an existing
 [GitHub issue](https://github.com/google-gemini/gemini-cli/issues). If you

docs/get-started/installation.md

@@ -102,7 +102,7 @@ the default way that the CLI executes tools that might have side effects.
   to run the CLI.
   ```bash
   # Run the published sandbox image
-  docker run --rm -it us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:0.1.1
+  docker run --rm -it us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:latest
   ```
 - **Using the `--sandbox` flag:** If you have Gemini CLI installed locally
   (using the standard installation described above), you can instruct it to run

docs/index.md

@@ -1,8 +1,14 @@
-# Gemini CLI documentation
+# Welcome to Gemini CLI
 
-Gemini CLI brings the power of Gemini models directly into your terminal. Use it
-to understand code, automate tasks, and build workflows with your local project
-context.
+Unleash the power of Gemini models directly in your terminal. Gemini CLI is your
+intelligent assistant for coding, automation, and understanding complex
+projects. It seamlessly integrates with your local development environment,
+empowering you to accelerate workflows, tackle challenging tasks, and explore
+codebases with unprecedented ease.
+
+Whether you're refactoring code, debugging issues, or orchestrating complex
+automation, Gemini CLI works alongside you, transforming your terminal into a
+highly productive AI-powered workspace.
 
 ## Install
 
@@ -10,132 +16,60 @@ context.
 npm install -g @google/gemini-cli
 ```
 
-## Get started
+## Get Started in Minutes
 
-Jump in to Gemini CLI.
+Ready to boost your productivity? You can get Gemini CLI up and running right
+away.
 
-- **[Quickstart](./get-started/index.md):** Your first session with Gemini CLI.
-- **[Installation](./get-started/installation.md):** How to install Gemini CLI
-  on your system.
-- **[Authentication](./get-started/authentication.md):** Setup instructions for
-  personal and enterprise accounts.
-- **[Examples](./get-started/examples.md):** Practical examples of Gemini CLI in
-  action.
-- **[CLI cheatsheet](./cli/cli-reference.md):** A quick reference for common
-  commands and options.
-- **[Gemini 3 on Gemini CLI](./get-started/gemini-3.md):** Learn about Gemini 3
-  support in Gemini CLI.
+→ Dive into the [Quickstart Guide](./get-started/index.md) for your first
+interactive session.
 
-## Use Gemini CLI
+## What Can Gemini CLI Do For You?
 
-User-focused guides and tutorials for daily development workflows.
+Gemini CLI isn't just a chatbot; it's a powerful agent capable of executing a
+wide range of tasks directly within your project context.
 
-- **[File management](./cli/tutorials/file-management.md):** How to work with
-  local files and directories.
-- **[Get started with Agent skills](./cli/tutorials/skills-getting-started.md):**
-  Getting started with specialized expertise.
-- **[Manage context and memory](./cli/tutorials/memory-management.md):**
-  Managing persistent instructions and facts.
-- **[Execute shell commands](./cli/tutorials/shell-commands.md):** Executing
-  system commands safely.
-- **[Manage sessions and history](./cli/tutorials/session-management.md):**
-  Resuming, managing, and rewinding conversations.
-- **[Plan tasks with todos](./cli/tutorials/task-planning.md):** Using todos for
-  complex workflows.
-- **[Web search and fetch](./cli/tutorials/web-tools.md):** Searching and
-  fetching content from the web.
-- **[Set up an MCP server](./cli/tutorials/mcp-setup.md):** Set up an MCP
-  server.
-- **[Automate tasks](./cli/tutorials/automation.md):** Automate tasks.
+### Automate Code Refactoring and Generation
 
-## Features
+Tired of repetitive coding tasks? Let Gemini CLI handle them. It can understand
+your existing code to generate new features or refactor complex sections with
+ease.
 
-Technical documentation for each capability of Gemini CLI.
+→ Learn how to efficiently [Modify Code](./cli/tutorials/file-management.md).
 
-- **[Extensions](./extensions/index.md):** Extend Gemini CLI with new tools and
-  capabilities.
-- **[Agent Skills](./cli/skills.md):** Use specialized agents for specific
-  tasks.
-- **[Checkpointing](./cli/checkpointing.md):** Automatic session snapshots.
-- **[Headless mode](./cli/headless.md):** Programmatic and scripting interface.
-- **[Hooks](./hooks/index.md):** Customize Gemini CLI behavior with scripts.
-- **[IDE integration](./ide-integration/index.md):** Integrate Gemini CLI with
-  your favorite IDE.
-- **[MCP servers](./tools/mcp-server.md):** Connect to and use remote agents.
-- **[Model routing](./cli/model-routing.md):** Automatic fallback resilience.
-- **[Model selection](./cli/model.md):** Choose the best model for your needs.
-- **[Plan mode 🔬](./cli/plan-mode.md):** Use a safe, read-only mode for
-  planning complex changes.
-- **[Subagents 🔬](./core/subagents.md):** Using specialized agents for specific
-  tasks.
-- **[Remote subagents 🔬](./core/remote-agents.md):** Connecting to and using
-  remote agents.
-- **[Rewind](./cli/rewind.md):** Rewind and replay sessions.
-- **[Sandboxing](./cli/sandbox.md):** Isolate tool execution.
-- **[Settings](./cli/settings.md):** Full configuration reference.
-- **[Telemetry](./cli/telemetry.md):** Usage and performance metric details.
-- **[Token caching](./cli/token-caching.md):** Performance optimization.
+### Understand Complex Codebases
 
-## Configuration
+Navigate unfamiliar projects or quickly grasp new architectural patterns. Gemini
+CLI can analyze large code repositories, explaining their purpose, structure,
+and key functionalities.
 
-Settings and customization options for Gemini CLI.
+→ Explore examples of how to
+[Explain a Repository by Reading its Code](./get-started/examples.md).
 
-- **[Custom commands](./cli/custom-commands.md):** Personalized shortcuts.
-- **[Enterprise configuration](./cli/enterprise.md):** Professional environment
-  controls.
-- **[Ignore files (.geminiignore)](./cli/gemini-ignore.md):** Exclusion pattern
-  reference.
-- **[Model configuration](./cli/generation-settings.md):** Fine-tune generation
-  parameters like temperature and thinking budget.
-- **[Project context (GEMINI.md)](./cli/gemini-md.md):** Technical hierarchy of
-  context files.
-- **[System prompt override](./cli/system-prompt.md):** Instruction replacement
-  logic.
-- **[Themes](./cli/themes.md):** UI personalization technical guide.
-- **[Trusted folders](./cli/trusted-folders.md):** Security permission logic.
+### Streamline Your Development Workflows
 
-## Reference
+From planning tasks with TODOs to managing long-running sessions, Gemini CLI
+helps you orchestrate your entire development process, making complex workflows
+simpler and more efficient.
 
-Deep technical documentation and API specifications.
+→ Discover how to [Plan Tasks with ToDos](./cli/tutorials/task-planning.md) or
+[Manage Sessions and History](./cli/tutorials/session-management.md).
 
-- **[Command reference](./reference/commands.md):** Detailed slash command
-  guide.
-- **[Configuration reference](./reference/configuration.md):** Settings and
-  environment variables.
-- **[Keyboard shortcuts](./reference/keyboard-shortcuts.md):** Productivity
-  tips.
-- **[Memory import processor](./reference/memport.md):** How Gemini CLI
-  processes memory from various sources.
-- **[Policy engine](./reference/policy-engine.md):** Fine-grained execution
-  control.
-- **[Tools reference](./reference/tools.md):** Information on how tools are
-  defined, registered, and used.
+## Explore Key Features and Sections
 
-## Resources
+Dive deeper into Gemini CLI's capabilities and comprehensive documentation:
 
-Support, release history, and legal information.
+- **[Agent Skills](./cli/skills.md):** Extend Gemini CLI's intelligence with
+  specialized expertise for any domain or task.
+- **[Extensions](./extensions/index.md):** Customize and enhance your CLI
+  experience by building or installing new tools and functionalities.
+- **[Configuration](./reference/configuration.md):** Fine-tune Gemini CLI to
+  match your preferences and project requirements with detailed settings and
+  options.
+- **[Command Reference](./reference/commands.md):** A complete guide to all
+  available CLI commands, flags, and interactive prompts.
+- **[Resources](./resources/faq.md):** Find answers to frequently asked
+  questions, troubleshooting tips, and support information.
 
-- **[FAQ](./resources/faq.md):** Answers to frequently asked questions.
-- **[Quota and pricing](./resources/quota-and-pricing.md):** Limits and billing
-  details.
-- **[Terms and privacy](./resources/tos-privacy.md):** Official notices and
-  terms.
-- **[Troubleshooting](./resources/troubleshooting.md):** Common issues and
-  solutions.
-- **[Uninstall](./resources/uninstall.md):** How to uninstall Gemini CLI.
-
-## Development
-
-- **[Contribution guide](/docs/contributing):** How to contribute to Gemini CLI.
-- **[Integration testing](./integration-tests.md):** Running integration tests.
-- **[Issue and PR automation](./issue-and-pr-automation.md):** Automation for
-  issues and pull requests.
-- **[Local development](./local-development.md):** Setting up a local
-  development environment.
-- **[NPM package structure](./npm.md):** The structure of the NPM packages.
-
-## Releases
-
-- **[Release notes](./changelogs/index.md):** Release notes for all versions.
-- **[Stable release](./changelogs/latest.md):** The latest stable release.
-- **[Preview release](./changelogs/preview.md):** The latest preview release.
+We're excited for you to experience a new level of terminal productivity with
+Gemini CLI!

packages/cli/src/config/config.ts

@@ -430,6 +430,8 @@ export async function loadCliConfig(
   const { cwd = process.cwd(), projectHooks } = options;
   const debugMode = isDebugMode(argv);
 
+  const loadedSettings = loadSettings(cwd);
+
   if (argv.sandbox) {
     process.env['GEMINI_SANDBOX'] = 'true';
   }
@@ -884,7 +886,7 @@ export async function loadCliConfig(
     hooks: settings.hooks || {},
     disabledHooks: settings.hooksConfig?.disabled || [],
     projectHooks: projectHooks || {},
-    onModelChange: (model: string) => saveModelChange(loadSettings(cwd), model),
+    onModelChange: (model: string) => saveModelChange(loadedSettings, model),
     onReload: async () => {
       const refreshedSettings = loadSettings(cwd);
       return {

packages/cli/src/test-utils/AppRig.tsx

@@ -280,14 +280,14 @@ export class AppRig {
   }
 
   private stubRefreshAuth() {
-    // eslint-disable-next-line @typescript-eslint/no-explicit-any
+    // eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion, @typescript-eslint/no-explicit-any, @typescript-eslint/no-unsafe-assignment
     const gcConfig = this.config as any;
     gcConfig.refreshAuth = async (authMethod: AuthType) => {
       gcConfig.modelAvailabilityService.reset();
 
       const newContentGeneratorConfig = {
         authType: authMethod,
-
+        // eslint-disable-next-line @typescript-eslint/no-unsafe-assignment
         proxy: gcConfig.getProxy(),
         apiKey: process.env['GEMINI_API_KEY'] || 'test-api-key',
       };
@@ -456,7 +456,7 @@ export class AppRig {
     const actualToolName = toolName === '*' ? undefined : toolName;
     this.config
       .getPolicyEngine()
-
+      // eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion
       .removeRulesForTool(actualToolName as string, source);
     this.breakpointTools.delete(toolName);
   }
@@ -729,7 +729,7 @@ export class AppRig {
         .getGeminiClient()
         ?.getChatRecordingService();
       if (recordingService) {
-        // eslint-disable-next-line @typescript-eslint/no-explicit-any
+        // eslint-disable-next-line @typescript-eslint/no-explicit-any, @typescript-eslint/no-unsafe-type-assertion
         (recordingService as any).conversationFile = null;
       }
     }
@@ -749,7 +749,7 @@ export class AppRig {
     MockShellExecutionService.reset();
     ideContextStore.clear();
     // Forcefully clear IdeClient singleton promise
-    // eslint-disable-next-line @typescript-eslint/no-explicit-any
+    // eslint-disable-next-line @typescript-eslint/no-explicit-any, @typescript-eslint/no-unsafe-type-assertion
     (IdeClient as any).instancePromise = null;
     vi.clearAllMocks();
 

packages/cli/src/ui/components/SessionBrowser.tsx

@@ -110,17 +110,78 @@ const SESSIONS_PER_PAGE = 20;
 // If the SessionItem layout changes, update this accordingly.
 const FIXED_SESSION_COLUMNS_WIDTH = 30;
 
-import {
-  SearchModeDisplay,
-  NavigationHelpDisplay,
-  NoResultsDisplay,
-} from './SessionBrowser/SessionBrowserNav.js';
-import { SessionListHeader } from './SessionBrowser/SessionListHeader.js';
+const Kbd = ({ name, shortcut }: { name: string; shortcut: string }) => (
+  <>
+    {name}: <Text bold>{shortcut}</Text>
+  </>
+);
+
 import { SessionBrowserLoading } from './SessionBrowser/SessionBrowserLoading.js';
 import { SessionBrowserError } from './SessionBrowser/SessionBrowserError.js';
 import { SessionBrowserEmpty } from './SessionBrowser/SessionBrowserEmpty.js';
+
 import { sortSessions, filterSessions } from './SessionBrowser/utils.js';
 
+/**
+ * Search input display component.
+ */
+const SearchModeDisplay = ({
+  state,
+}: {
+  state: SessionBrowserState;
+}): React.JSX.Element => (
+  <Box marginTop={1}>
+    <Text color={Colors.Gray}>Search: </Text>
+    <Text color={Colors.AccentPurple}>{state.searchQuery}</Text>
+    <Text color={Colors.Gray}> (Esc to cancel)</Text>
+  </Box>
+);
+
+/**
+ * Header component showing session count and sort information.
+ */
+const SessionListHeader = ({
+  state,
+}: {
+  state: SessionBrowserState;
+}): React.JSX.Element => (
+  <Box flexDirection="row" justifyContent="space-between">
+    <Text color={Colors.AccentPurple}>
+      Chat Sessions ({state.totalSessions} total
+      {state.searchQuery ? `, filtered` : ''})
+    </Text>
+    <Text color={Colors.Gray}>
+      sorted by {state.sortOrder} {state.sortReverse ? 'asc' : 'desc'}
+    </Text>
+  </Box>
+);
+
+/**
+ * Navigation help component showing keyboard shortcuts.
+ */
+const NavigationHelp = (): React.JSX.Element => (
+  <Box flexDirection="column">
+    <Text color={Colors.Gray}>
+      <Kbd name="Navigate" shortcut="↑/↓" />
+      {'   '}
+      <Kbd name="Resume" shortcut="Enter" />
+      {'   '}
+      <Kbd name="Search" shortcut="/" />
+      {'   '}
+      <Kbd name="Delete" shortcut="x" />
+      {'   '}
+      <Kbd name="Quit" shortcut="q" />
+    </Text>
+    <Text color={Colors.Gray}>
+      <Kbd name="Sort" shortcut="s" />
+      {'         '}
+      <Kbd name="Reverse" shortcut="r" />
+      {'      '}
+      <Kbd name="First/Last" shortcut="g/G" />
+    </Text>
+  </Box>
+);
+
 /**
  * Table header component with column labels and scroll indicators.
  */
@@ -158,6 +219,21 @@ const SessionTableHeader = ({
   </Box>
 );
 
+/**
+ * No results display component for empty search results.
+ */
+const NoResultsDisplay = ({
+  state,
+}: {
+  state: SessionBrowserState;
+}): React.JSX.Element => (
+  <Box marginTop={1}>
+    <Text color={Colors.Gray} dimColor>
+      No sessions found matching &apos;{state.searchQuery}&apos;.
+    </Text>
+  </Box>
+);
+
 /**
  * Match snippet display component for search results.
  */
@@ -322,7 +398,7 @@ const SessionList = ({
   <Box flexDirection="column">
     {/* Table Header */}
     <Box flexDirection="column">
-      {!state.isSearchMode && <NavigationHelpDisplay />}
+      {!state.isSearchMode && <NavigationHelp />}
       <SessionTableHeader state={state} />
     </Box>
 

packages/cli/src/ui/components/SessionBrowser/SessionBrowserNav.tsx

@@ -1,72 +0,0 @@
-/**
- * @license
- * Copyright 2026 Google LLC
- * SPDX-License-Identifier: Apache-2.0
- */
-
-import type React from 'react';
-import { Box, Text } from 'ink';
-import { Colors } from '../../colors.js';
-import type { SessionBrowserState } from '../SessionBrowser.js';
-
-const Kbd = ({ name, shortcut }: { name: string; shortcut: string }) => (
-  <>
-    {name}: <Text bold>{shortcut}</Text>
-  </>
-);
-
-/**
- * Navigation help component showing keyboard shortcuts.
- */
-export const NavigationHelpDisplay = (): React.JSX.Element => (
-  <Box flexDirection="column">
-    <Text color={Colors.Gray}>
-      <Kbd name="Navigate" shortcut="↑/↓" />
-      {'   '}
-      <Kbd name="Resume" shortcut="Enter" />
-      {'   '}
-      <Kbd name="Search" shortcut="/" />
-      {'   '}
-      <Kbd name="Delete" shortcut="x" />
-      {'   '}
-      <Kbd name="Quit" shortcut="q" />
-    </Text>
-    <Text color={Colors.Gray}>
-      <Kbd name="Sort" shortcut="s" />
-      {'         '}
-      <Kbd name="Reverse" shortcut="r" />
-      {'      '}
-      <Kbd name="First/Last" shortcut="g/G" />
-    </Text>
-  </Box>
-);
-
-/**
- * Search input display component.
- */
-export const SearchModeDisplay = ({
-  state,
-}: {
-  state: SessionBrowserState;
-}): React.JSX.Element => (
-  <Box marginTop={1}>
-    <Text color={Colors.Gray}>Search: </Text>
-    <Text color={Colors.AccentPurple}>{state.searchQuery}</Text>
-    <Text color={Colors.Gray}> (Esc to cancel)</Text>
-  </Box>
-);
-
-/**
- * No results display component for empty search results.
- */
-export const NoResultsDisplay = ({
-  state,
-}: {
-  state: SessionBrowserState;
-}): React.JSX.Element => (
-  <Box marginTop={1}>
-    <Text color={Colors.Gray} dimColor>
-      No sessions found matching &apos;{state.searchQuery}&apos;.
-    </Text>
-  </Box>
-);

packages/cli/src/ui/components/SessionBrowser/SessionBrowserSearchNav.test.tsx

@@ -1,69 +0,0 @@
-/**
- * @license
- * Copyright 2026 Google LLC
- * SPDX-License-Identifier: Apache-2.0
- */
-
-import { render } from '../../../test-utils/render.js';
-import { describe, it, expect } from 'vitest';
-import {
-  SearchModeDisplay,
-  NavigationHelpDisplay,
-  NoResultsDisplay,
-} from './SessionBrowserNav.js';
-import { SessionListHeader } from './SessionListHeader.js';
-import type { SessionBrowserState } from '../SessionBrowser.js';
-
-describe('SessionBrowser Search and Navigation Components', () => {
-  it('SearchModeDisplay renders correctly with query', async () => {
-    const mockState = { searchQuery: 'test query' } as SessionBrowserState;
-    const { lastFrame, waitUntilReady } = render(
-      <SearchModeDisplay state={mockState} />,
-    );
-    await waitUntilReady();
-    expect(lastFrame()).toMatchSnapshot();
-  });
-
-  it('NavigationHelp renders correctly', async () => {
-    const { lastFrame, waitUntilReady } = render(<NavigationHelpDisplay />);
-    await waitUntilReady();
-    expect(lastFrame()).toMatchSnapshot();
-  });
-
-  it('SessionListHeader renders correctly', async () => {
-    const mockState = {
-      totalSessions: 10,
-      searchQuery: '',
-      sortOrder: 'date',
-      sortReverse: false,
-    } as SessionBrowserState;
-    const { lastFrame, waitUntilReady } = render(
-      <SessionListHeader state={mockState} />,
-    );
-    await waitUntilReady();
-    expect(lastFrame()).toMatchSnapshot();
-  });
-
-  it('SessionListHeader renders correctly with filter', async () => {
-    const mockState = {
-      totalSessions: 5,
-      searchQuery: 'test',
-      sortOrder: 'name',
-      sortReverse: true,
-    } as SessionBrowserState;
-    const { lastFrame, waitUntilReady } = render(
-      <SessionListHeader state={mockState} />,
-    );
-    await waitUntilReady();
-    expect(lastFrame()).toMatchSnapshot();
-  });
-
-  it('NoResultsDisplay renders correctly', async () => {
-    const mockState = { searchQuery: 'no match' } as SessionBrowserState;
-    const { lastFrame, waitUntilReady } = render(
-      <NoResultsDisplay state={mockState} />,
-    );
-    await waitUntilReady();
-    expect(lastFrame()).toMatchSnapshot();
-  });
-});

packages/cli/src/ui/components/SessionBrowser/SessionListHeader.tsx

@@ -1,29 +0,0 @@
-/**
- * @license
- * Copyright 2026 Google LLC
- * SPDX-License-Identifier: Apache-2.0
- */
-
-import type React from 'react';
-import { Box, Text } from 'ink';
-import { Colors } from '../../colors.js';
-import type { SessionBrowserState } from '../SessionBrowser.js';
-
-/**
- * Header component showing session count and sort information.
- */
-export const SessionListHeader = ({
-  state,
-}: {
-  state: SessionBrowserState;
-}): React.JSX.Element => (
-  <Box flexDirection="row" justifyContent="space-between">
-    <Text color={Colors.AccentPurple}>
-      Chat Sessions ({state.totalSessions} total
-      {state.searchQuery ? `, filtered` : ''})
-    </Text>
-    <Text color={Colors.Gray}>
-      sorted by {state.sortOrder} {state.sortReverse ? 'asc' : 'desc'}
-    </Text>
-  </Box>
-);

packages/cli/src/ui/components/SessionBrowser/__snapshots__/SessionBrowserSearchNav.test.tsx.snap

@@ -1,29 +0,0 @@
-// Vitest Snapshot v1, https://vitest.dev/guide/snapshot.html
-
-exports[`SessionBrowser Search and Navigation Components > NavigationHelp renders correctly 1`] = `
-"Navigate: ↑/↓   Resume: Enter   Search: /   Delete: x   Quit: q
-Sort: s         Reverse: r      First/Last: g/G
-"
-`;
-
-exports[`SessionBrowser Search and Navigation Components > NoResultsDisplay renders correctly 1`] = `
-"
-No sessions found matching 'no match'.
-"
-`;
-
-exports[`SessionBrowser Search and Navigation Components > SearchModeDisplay renders correctly with query 1`] = `
-"
-Search: test query (Esc to cancel)
-"
-`;
-
-exports[`SessionBrowser Search and Navigation Components > SessionListHeader renders correctly 1`] = `
-"Chat Sessions (10 total)                                                         sorted by date desc
-"
-`;
-
-exports[`SessionBrowser Search and Navigation Components > SessionListHeader renders correctly with filter 1`] = `
-"Chat Sessions (5 total, filtered)                                                 sorted by name asc
-"
-`;

packages/cli/src/ui/components/messages/SubagentGroupDisplay.test.tsx

@@ -1,120 +0,0 @@
-/**
- * @license
- * Copyright 2026 Google LLC
- * SPDX-License-Identifier: Apache-2.0
- */
-import { waitFor } from '../../../test-utils/async.js';
-import { render } from '../../../test-utils/render.js';
-import { SubagentGroupDisplay } from './SubagentGroupDisplay.js';
-import { Kind, CoreToolCallStatus } from '@google/gemini-cli-core';
-import type { IndividualToolCallDisplay } from '../../types.js';
-import { KeypressProvider } from '../../contexts/KeypressContext.js';
-import { OverflowProvider } from '../../contexts/OverflowContext.js';
-import { vi } from 'vitest';
-import { Text } from 'ink';
-
-vi.mock('../../utils/MarkdownDisplay.js', () => ({
-  MarkdownDisplay: ({ text }: { text: string }) => <Text>{text}</Text>,
-}));
-
-describe('<SubagentGroupDisplay />', () => {
-  const mockToolCalls: IndividualToolCallDisplay[] = [
-    {
-      callId: 'call-1',
-      name: 'agent_1',
-      description: 'Test agent 1',
-      confirmationDetails: undefined,
-      status: CoreToolCallStatus.Executing,
-      kind: Kind.Agent,
-      resultDisplay: {
-        isSubagentProgress: true,
-        agentName: 'api-monitor',
-        state: 'running',
-        recentActivity: [
-          {
-            id: 'act-1',
-            type: 'tool_call',
-            status: 'running',
-            content: '',
-            displayName: 'Action Required',
-            description: 'Verify server is running',
-          },
-        ],
-      },
-    },
-    {
-      callId: 'call-2',
-      name: 'agent_2',
-      description: 'Test agent 2',
-      confirmationDetails: undefined,
-      status: CoreToolCallStatus.Success,
-      kind: Kind.Agent,
-      resultDisplay: {
-        isSubagentProgress: true,
-        agentName: 'db-manager',
-        state: 'completed',
-        result: 'Database schema validated',
-        recentActivity: [
-          {
-            id: 'act-2',
-            type: 'thought',
-            status: 'completed',
-            content: 'Database schema validated',
-          },
-        ],
-      },
-    },
-  ];
-
-  const renderSubagentGroup = (
-    toolCallsToRender: IndividualToolCallDisplay[],
-    height?: number,
-  ) => (
-    <OverflowProvider>
-      <KeypressProvider>
-        <SubagentGroupDisplay
-          toolCalls={toolCallsToRender}
-          terminalWidth={80}
-          availableTerminalHeight={height}
-          isExpandable={true}
-        />
-      </KeypressProvider>
-    </OverflowProvider>
-  );
-
-  it('renders nothing if there are no agent tool calls', async () => {
-    const { lastFrame } = render(renderSubagentGroup([], 40));
-    expect(lastFrame({ allowEmpty: true })).toBe('');
-  });
-
-  it('renders collapsed view by default with correct agent counts and states', async () => {
-    const { lastFrame, waitUntilReady } = render(
-      renderSubagentGroup(mockToolCalls, 40),
-    );
-    await waitUntilReady();
-    expect(lastFrame()).toMatchSnapshot();
-  });
-
-  it('expands when availableTerminalHeight is undefined', async () => {
-    const { lastFrame, rerender } = render(
-      renderSubagentGroup(mockToolCalls, 40),
-    );
-
-    // Default collapsed view
-    await waitFor(() => {
-      expect(lastFrame()).toContain('(ctrl+o to expand)');
-    });
-
-    // Expand view
-    rerender(renderSubagentGroup(mockToolCalls, undefined));
-    await waitFor(() => {
-      expect(lastFrame()).toContain('(ctrl+o to collapse)');
-    });
-
-    // Collapse view
-    rerender(renderSubagentGroup(mockToolCalls, 40));
-    await waitFor(() => {
-      expect(lastFrame()).toContain('(ctrl+o to expand)');
-    });
-  });
-});

packages/cli/src/ui/components/messages/SubagentGroupDisplay.tsx

@@ -1,269 +0,0 @@
-/**
- * @license
- * Copyright 2026 Google LLC
- * SPDX-License-Identifier: Apache-2.0
- */
-
-import type React from 'react';
-import { useEffect, useId } from 'react';
-import { Box, Text } from 'ink';
-import { theme } from '../../semantic-colors.js';
-import type { IndividualToolCallDisplay } from '../../types.js';
-import {
-  isSubagentProgress,
-  checkExhaustive,
-  type SubagentActivityItem,
-} from '@google/gemini-cli-core';
-import {
-  SubagentProgressDisplay,
-  formatToolArgs,
-} from './SubagentProgressDisplay.js';
-import { useOverflowActions } from '../../contexts/OverflowContext.js';
-
-export interface SubagentGroupDisplayProps {
-  toolCalls: IndividualToolCallDisplay[];
-  availableTerminalHeight?: number;
-  terminalWidth: number;
-  borderColor?: string;
-  borderDimColor?: boolean;
-  isFirst?: boolean;
-  isExpandable?: boolean;
-}
-
-export const SubagentGroupDisplay: React.FC<SubagentGroupDisplayProps> = ({
-  toolCalls,
-  availableTerminalHeight,
-  terminalWidth,
-  borderColor,
-  borderDimColor,
-  isFirst,
-  isExpandable = true,
-}) => {
-  const isExpanded = availableTerminalHeight === undefined;
-  const overflowActions = useOverflowActions();
-  const uniqueId = useId();
-  const overflowId = `subagent-${uniqueId}`;
-
-  useEffect(() => {
-    if (isExpandable && overflowActions) {
-      // Register with the global overflow system so "ctrl+o to expand" shows in the sticky footer
-      // and AppContainer passes the shortcut through.
-      overflowActions.addOverflowingId(overflowId);
-    }
-    return () => {
-      if (overflowActions) {
-        overflowActions.removeOverflowingId(overflowId);
-      }
-    };
-  }, [isExpandable, overflowActions, overflowId]);
-
-  if (toolCalls.length === 0) {
-    return null;
-  }
-
-  let headerText = '';
-  if (toolCalls.length === 1) {
-    const singleAgent = toolCalls[0].resultDisplay;
-    if (isSubagentProgress(singleAgent)) {
-      switch (singleAgent.state) {
-        case 'completed':
-          headerText = 'Agent Completed';
-          break;
-        case 'cancelled':
-          headerText = 'Agent Cancelled';
-          break;
-        case 'error':
-          headerText = 'Agent Error';
-          break;
-        default:
-          headerText = 'Running Agent...';
-          break;
-      }
-    } else {
-      headerText = 'Running Agent...';
-    }
-  } else {
-    let completedCount = 0;
-    let runningCount = 0;
-    for (const tc of toolCalls) {
-      const progress = tc.resultDisplay;
-      if (isSubagentProgress(progress)) {
-        if (progress.state === 'completed') completedCount++;
-        else if (progress.state === 'running') runningCount++;
-      } else {
-        // It hasn't emitted progress yet, but it is "running"
-        runningCount++;
-      }
-    }
-
-    if (completedCount === toolCalls.length) {
-      headerText = `${toolCalls.length} Agents Completed`;
-    } else if (completedCount > 0) {
-      headerText = `${toolCalls.length} Agents (${runningCount} running, ${completedCount} completed)...`;
-    } else {
-      headerText = `Running ${toolCalls.length} Agents...`;
-    }
-  }
-  const toggleText = `(ctrl+o to ${isExpanded ? 'collapse' : 'expand'})`;
-
-  const renderCollapsedRow = (
-    key: string,
-    agentName: string,
-    icon: React.ReactNode,
-    content: string,
-    displayArgs?: string,
-  ) => (
-    <Box key={key} flexDirection="row" marginLeft={0} marginTop={0}>
-      <Box minWidth={2} flexShrink={0}>
-        {icon}
-      </Box>
-      <Box flexShrink={0}>
-        <Text bold color={theme.text.primary} wrap="truncate">
-          {agentName}
-        </Text>
-      </Box>
-      <Box flexShrink={0}>
-        <Text color={theme.text.secondary}> · </Text>
-      </Box>
-      <Box flexShrink={1} minWidth={0}>
-        <Text color={theme.text.secondary} wrap="truncate">
-          {content}
-          {displayArgs && ` ${displayArgs}`}
-        </Text>
-      </Box>
-    </Box>
-  );
-
-  return (
-    <Box
-      flexDirection="column"
-      width={terminalWidth}
-      borderLeft={true}
-      borderRight={true}
-      borderTop={isFirst}
-      borderBottom={false}
-      borderColor={borderColor}
-      borderDimColor={borderDimColor}
-      borderStyle="round"
-      paddingLeft={1}
-      paddingTop={0}
-      paddingBottom={0}
-    >
-      <Box flexDirection="row" gap={1} marginBottom={isExpanded ? 1 : 0}>
-        <Text color={theme.text.secondary}>≡</Text>
-        <Text bold color={theme.text.primary}>
-          {headerText}
-        </Text>
-        {isExpandable && <Text color={theme.text.secondary}>{toggleText}</Text>}
-      </Box>
-
-      {toolCalls.map((toolCall) => {
-        const progress = toolCall.resultDisplay;
-
-        if (!isSubagentProgress(progress)) {
-          const agentName = toolCall.name || 'agent';
-          if (!isExpanded) {
-            return renderCollapsedRow(
-              toolCall.callId,
-              agentName,
-              <Text color={theme.text.primary}>!</Text>,
-              'Starting...',
-            );
-          } else {
-            return (
-              <Box
-                key={toolCall.callId}
-                flexDirection="column"
-                marginLeft={0}
-                marginBottom={1}
-              >
-                <Box flexDirection="row" gap={1}>
-                  <Text color={theme.text.primary}>!</Text>
-                  <Text bold color={theme.text.primary}>
-                    {agentName}
-                  </Text>
-                </Box>
-                <Box marginLeft={2}>
-                  <Text color={theme.text.secondary}>Starting...</Text>
-                </Box>
-              </Box>
-            );
-          }
-        }
-
-        const lastActivity: SubagentActivityItem | undefined =
-          progress.recentActivity[progress.recentActivity.length - 1];
-
-        // Collapsed View: Show single compact line per agent
-        if (!isExpanded) {
-          let content = 'Starting...';
-          let formattedArgs: string | undefined;
-
-          if (progress.state === 'completed') {
-            if (
-              progress.terminateReason &&
-              progress.terminateReason !== 'GOAL'
-            ) {
-              content = `Finished Early (${progress.terminateReason})`;
-            } else {
-              content = 'Completed successfully';
-            }
-          } else if (lastActivity) {
-            // Match expanded view logic exactly:
-            // Primary text: displayName || content
-            content = lastActivity.displayName || lastActivity.content;
-
-            // Secondary text: description || formatToolArgs(args)
-            if (lastActivity.description) {
-              formattedArgs = lastActivity.description;
-            } else if (lastActivity.type === 'tool_call' && lastActivity.args) {
-              formattedArgs = formatToolArgs(lastActivity.args);
-            }
-          }
-
-          const displayArgs =
-            progress.state === 'completed' ? '' : formattedArgs;
-
-          const renderStatusIcon = () => {
-            const state = progress.state ?? 'running';
-            switch (state) {
-              case 'running':
-                return <Text color={theme.text.primary}>!</Text>;
-              case 'completed':
-                return <Text color={theme.status.success}>✓</Text>;
-              case 'cancelled':
-                return <Text color={theme.status.warning}>ℹ</Text>;
-              case 'error':
-                return <Text color={theme.status.error}>✗</Text>;
-              default:
-                return checkExhaustive(state);
-            }
-          };
-
-          return renderCollapsedRow(
-            toolCall.callId,
-            progress.agentName,
-            renderStatusIcon(),
-            lastActivity?.type === 'thought' ? `💭 ${content}` : content,
-            displayArgs,
-          );
-        }
-
-        // Expanded View: Render full history
-        return (
-          <Box
-            key={toolCall.callId}
-            flexDirection="column"
-            marginLeft={0}
-            marginBottom={1}
-          >
-            <SubagentProgressDisplay
-              progress={progress}
-              terminalWidth={terminalWidth}
-            />
-          </Box>
-        );
-      })}
-    </Box>
-  );
-};

packages/cli/src/ui/components/messages/SubagentProgressDisplay.test.tsx

@@ -36,7 +36,7 @@ describe('<SubagentProgressDisplay />', () => {
     };
 
     const { lastFrame, waitUntilReady } = render(
-      <SubagentProgressDisplay progress={progress} terminalWidth={80} />,
+      <SubagentProgressDisplay progress={progress} />,
     );
     await waitUntilReady();
     expect(lastFrame()).toMatchSnapshot();
@@ -60,7 +60,7 @@ describe('<SubagentProgressDisplay />', () => {
     };
 
     const { lastFrame, waitUntilReady } = render(
-      <SubagentProgressDisplay progress={progress} terminalWidth={80} />,
+      <SubagentProgressDisplay progress={progress} />,
     );
     await waitUntilReady();
     expect(lastFrame()).toMatchSnapshot();
@@ -82,7 +82,7 @@ describe('<SubagentProgressDisplay />', () => {
     };
 
     const { lastFrame, waitUntilReady } = render(
-      <SubagentProgressDisplay progress={progress} terminalWidth={80} />,
+      <SubagentProgressDisplay progress={progress} />,
     );
     await waitUntilReady();
     expect(lastFrame()).toMatchSnapshot();
@@ -104,7 +104,7 @@ describe('<SubagentProgressDisplay />', () => {
     };
 
     const { lastFrame, waitUntilReady } = render(
-      <SubagentProgressDisplay progress={progress} terminalWidth={80} />,
+      <SubagentProgressDisplay progress={progress} />,
     );
     await waitUntilReady();
     expect(lastFrame()).toMatchSnapshot();
@@ -128,7 +128,7 @@ describe('<SubagentProgressDisplay />', () => {
     };
 
     const { lastFrame, waitUntilReady } = render(
-      <SubagentProgressDisplay progress={progress} terminalWidth={80} />,
+      <SubagentProgressDisplay progress={progress} />,
     );
     await waitUntilReady();
     expect(lastFrame()).toMatchSnapshot();
@@ -149,7 +149,7 @@ describe('<SubagentProgressDisplay />', () => {
     };
 
     const { lastFrame, waitUntilReady } = render(
-      <SubagentProgressDisplay progress={progress} terminalWidth={80} />,
+      <SubagentProgressDisplay progress={progress} />,
     );
     await waitUntilReady();
     expect(lastFrame()).toMatchSnapshot();
@@ -164,7 +164,7 @@ describe('<SubagentProgressDisplay />', () => {
     };
 
     const { lastFrame, waitUntilReady } = render(
-      <SubagentProgressDisplay progress={progress} terminalWidth={80} />,
+      <SubagentProgressDisplay progress={progress} />,
     );
     await waitUntilReady();
     expect(lastFrame()).toMatchSnapshot();
@@ -185,7 +185,7 @@ describe('<SubagentProgressDisplay />', () => {
     };
 
     const { lastFrame, waitUntilReady } = render(
-      <SubagentProgressDisplay progress={progress} terminalWidth={80} />,
+      <SubagentProgressDisplay progress={progress} />,
     );
     await waitUntilReady();
     expect(lastFrame()).toMatchSnapshot();

packages/cli/src/ui/components/messages/SubagentProgressDisplay.tsx

@@ -8,21 +8,18 @@ import type React from 'react';
 import { Box, Text } from 'ink';
 import { theme } from '../../semantic-colors.js';
 import Spinner from 'ink-spinner';
-import { MarkdownDisplay } from '../../utils/MarkdownDisplay.js';
 import type {
   SubagentProgress,
   SubagentActivityItem,
 } from '@google/gemini-cli-core';
 import { TOOL_STATUS } from '../../constants.js';
 import { STATUS_INDICATOR_WIDTH } from './ToolShared.js';
-import { safeJsonToMarkdown } from '@google/gemini-cli-core';
 
 export interface SubagentProgressDisplayProps {
   progress: SubagentProgress;
-  terminalWidth: number;
 }
 
-export const formatToolArgs = (args?: string): string => {
+const formatToolArgs = (args?: string): string => {
   if (!args) return '';
   try {
     const parsed: unknown = JSON.parse(args);
@@ -57,7 +54,7 @@ export const formatToolArgs = (args?: string): string => {
 
 export const SubagentProgressDisplay: React.FC<
   SubagentProgressDisplayProps
-> = ({ progress, terminalWidth }) => {
+> = ({ progress }) => {
   let headerText: string | undefined;
   let headerColor = theme.text.secondary;
 
@@ -70,9 +67,6 @@ export const SubagentProgressDisplay: React.FC<
   } else if (progress.state === 'completed') {
     headerText = `Subagent ${progress.agentName} completed.`;
     headerColor = theme.status.success;
-  } else {
-    headerText = `Running subagent ${progress.agentName}...`;
-    headerColor = theme.text.primary;
   }
 
   return (
@@ -152,23 +146,6 @@ export const SubagentProgressDisplay: React.FC<
           return null;
         })}
       </Box>
-
-      {progress.state === 'completed' && progress.result && (
-        <Box flexDirection="column" marginTop={1}>
-          {progress.terminateReason && progress.terminateReason !== 'GOAL' && (
-            <Box marginBottom={1}>
-              <Text color={theme.status.warning} bold>
-                Agent Finished Early ({progress.terminateReason})
-              </Text>
-            </Box>
-          )}
-          <MarkdownDisplay
-            text={safeJsonToMarkdown(progress.result)}
-            isPending={false}
-            terminalWidth={terminalWidth}
-          />
-        </Box>
-      )}
     </Box>
   );
 };

packages/cli/src/ui/components/messages/ToolGroupMessage.tsx

@@ -15,14 +15,12 @@ import type {
 import { ToolCallStatus, mapCoreStatusToDisplayStatus } from '../../types.js';
 import { ToolMessage } from './ToolMessage.js';
 import { ShellToolMessage } from './ShellToolMessage.js';
-import { SubagentGroupDisplay } from './SubagentGroupDisplay.js';
 import { theme } from '../../semantic-colors.js';
 import { useConfig } from '../../contexts/ConfigContext.js';
 import { isShellTool } from './ToolShared.js';
 import {
   shouldHideToolCall,
   CoreToolCallStatus,
-  Kind,
 } from '@google/gemini-cli-core';
 import { useUIState } from '../../contexts/UIStateContext.js';
 import { getToolGroupBorderAppearance } from '../../utils/borderStyles.js';
@@ -127,36 +125,12 @@ export const ToolGroupMessage: React.FC<ToolGroupMessageProps> = ({
 
   let countToolCallsWithResults = 0;
   for (const tool of visibleToolCalls) {
-    if (
-      tool.kind !== Kind.Agent &&
-      tool.resultDisplay !== undefined &&
-      tool.resultDisplay !== ''
-    ) {
+    if (tool.resultDisplay !== undefined && tool.resultDisplay !== '') {
       countToolCallsWithResults++;
     }
   }
   const countOneLineToolCalls =
-    visibleToolCalls.filter((t) => t.kind !== Kind.Agent).length -
-    countToolCallsWithResults;
-  const groupedTools = useMemo(() => {
-    const groups: Array<
-      IndividualToolCallDisplay | IndividualToolCallDisplay[]
-    > = [];
-    for (const tool of visibleToolCalls) {
-      if (tool.kind === Kind.Agent) {
-        const lastGroup = groups[groups.length - 1];
-        if (Array.isArray(lastGroup)) {
-          lastGroup.push(tool);
-        } else {
-          groups.push([tool]);
-        }
-      } else {
-        groups.push(tool);
-      }
-    }
-    return groups;
-  }, [visibleToolCalls]);
-
+    visibleToolCalls.length - countToolCallsWithResults;
   const availableTerminalHeightPerToolMessage = availableTerminalHeight
     ? Math.max(
         Math.floor(
@@ -193,29 +167,8 @@ export const ToolGroupMessage: React.FC<ToolGroupMessageProps> = ({
       width={terminalWidth}
       paddingRight={TOOL_MESSAGE_HORIZONTAL_MARGIN}
     >
-      {groupedTools.map((group, index) => {
+      {visibleToolCalls.map((tool, index) => {
         const isFirst = index === 0;
-        const resolvedIsFirst =
-          borderTopOverride !== undefined
-            ? borderTopOverride && isFirst
-            : isFirst;
-
-        if (Array.isArray(group)) {
-          return (
-            <SubagentGroupDisplay
-              key={group[0].callId}
-              toolCalls={group}
-              availableTerminalHeight={availableTerminalHeight}
-              terminalWidth={contentWidth}
-              borderColor={borderColor}
-              borderDimColor={borderDimColor}
-              isFirst={resolvedIsFirst}
-              isExpandable={isExpandable}
-            />
-          );
-        }
-
-        const tool = group;
         const isShellToolCall = isShellTool(tool.name);
 
         const commonProps = {
@@ -223,7 +176,10 @@ export const ToolGroupMessage: React.FC<ToolGroupMessageProps> = ({
           availableTerminalHeight: availableTerminalHeightPerToolMessage,
           terminalWidth: contentWidth,
           emphasis: 'medium' as const,
-          isFirst: resolvedIsFirst,
+          isFirst:
+            borderTopOverride !== undefined
+              ? borderTopOverride && isFirst
+              : isFirst,
           borderColor,
           borderDimColor,
           isExpandable,

packages/cli/src/ui/components/messages/ToolResultDisplay.tsx

@@ -102,12 +102,7 @@ export const ToolResultDisplay: React.FC<ToolResultDisplayProps> = ({
         </Text>
       );
     } else if (isSubagentProgress(contentData)) {
-      content = (
-        <SubagentProgressDisplay
-          progress={contentData}
-          terminalWidth={childWidth}
-        />
-      );
+      content = <SubagentProgressDisplay progress={contentData} />;
     } else if (typeof contentData === 'string' && renderOutputAsMarkdown) {
       content = (
         <MarkdownDisplay

packages/cli/src/ui/components/messages/__snapshots__/SubagentGroupDisplay.test.tsx.snap

@@ -1,9 +0,0 @@
-// Vitest Snapshot v1, https://vitest.dev/guide/snapshot.html
-
-exports[`<SubagentGroupDisplay /> > renders collapsed view by default with correct agent counts and states 1`] = `
-"╭──────────────────────────────────────────────────────────────────────────────╮
-│ ≡ 2 Agents (1 running, 1 completed)... (ctrl+o to expand)                    │
-│ ! api-monitor · Action Required Verify server is running                     │
-│ ✓ db-manager · 💭 Completed successfully                                     │
-"
-`;

packages/cli/src/ui/components/messages/__snapshots__/SubagentProgressDisplay.test.tsx.snap

@@ -1,9 +1,7 @@
 // Vitest Snapshot v1, https://vitest.dev/guide/snapshot.html
 
 exports[`<SubagentProgressDisplay /> > renders "Request cancelled." with the info icon 1`] = `
-"Running subagent TestAgent...
-
-ℹ  Request cancelled.
+"ℹ  Request cancelled.
 "
 `;
 
@@ -13,43 +11,31 @@ exports[`<SubagentProgressDisplay /> > renders cancelled state correctly 1`] = `
 `;
 
 exports[`<SubagentProgressDisplay /> > renders correctly with command fallback 1`] = `
-"Running subagent TestAgent...
-
-⠋  run_shell_command echo hello
+"⠋  run_shell_command echo hello
 "
 `;
 
 exports[`<SubagentProgressDisplay /> > renders correctly with description in args 1`] = `
-"Running subagent TestAgent...
-
-⠋  run_shell_command Say hello
+"⠋  run_shell_command Say hello
 "
 `;
 
 exports[`<SubagentProgressDisplay /> > renders correctly with displayName and description from item 1`] = `
-"Running subagent TestAgent...
-
-⠋  RunShellCommand Executing echo hello
+"⠋  RunShellCommand Executing echo hello
 "
 `;
 
 exports[`<SubagentProgressDisplay /> > renders correctly with file_path 1`] = `
-"Running subagent TestAgent...
-
-✓  write_file /tmp/test.txt
+"✓  write_file /tmp/test.txt
 "
 `;
 
 exports[`<SubagentProgressDisplay /> > renders thought bubbles correctly 1`] = `
-"Running subagent TestAgent...
-
-💭 Thinking about life
+"💭 Thinking about life
 "
 `;
 
 exports[`<SubagentProgressDisplay /> > truncates long args 1`] = `
-"Running subagent TestAgent...
-
-⠋  run_shell_command This is a very long description that should definitely be tr...
+"⠋  run_shell_command This is a very long description that should definitely be tr...
 "
 `;

packages/cli/src/ui/hooks/useGeminiStream.ts

@@ -38,7 +38,6 @@ import {
   GeminiCliOperation,
   getPlanModeExitMessage,
   isBackgroundExecutionData,
-  Kind,
 } from '@google/gemini-cli-core';
 import type {
   Config,
@@ -409,8 +408,7 @@ export const useGeminiStream = (
   // Push completed tools to history as they finish
   useEffect(() => {
     const toolsToPush: TrackedToolCall[] = [];
-    for (let i = 0; i < toolCalls.length; i++) {
-      const tc = toolCalls[i];
+    for (const tc of toolCalls) {
       if (pushedToolCallIdsRef.current.has(tc.request.callId)) continue;
 
       if (
@@ -418,40 +416,6 @@ export const useGeminiStream = (
         tc.status === 'error' ||
         tc.status === 'cancelled'
       ) {
-        // TODO(#22883): This lookahead logic is a tactical UI fix to prevent parallel agents
-        // from tearing visually when they finish at slightly different times.
-        // Architecturally, `useGeminiStream` should not be responsible for stitching
-        // together semantic batches using timing/refs. `packages/core` should be
-        // refactored to emit structured `ToolBatch` or `Turn` objects, and this layer
-        // should simply render those semantic boundaries.
-        // If this is an agent tool, look ahead to ensure all subsequent
-        // contiguous agents in the same batch are also finished before pushing.
-        const isAgent = tc.tool?.kind === Kind.Agent;
-        if (isAgent) {
-          let contigAgentsComplete = true;
-          for (let j = i + 1; j < toolCalls.length; j++) {
-            const nextTc = toolCalls[j];
-            if (nextTc.tool?.kind === Kind.Agent) {
-              if (
-                nextTc.status !== 'success' &&
-                nextTc.status !== 'error' &&
-                nextTc.status !== 'cancelled'
-              ) {
-                contigAgentsComplete = false;
-                break;
-              }
-            } else {
-              // End of the contiguous agent block
-              break;
-            }
-          }
-
-          if (!contigAgentsComplete) {
-            // Wait for the entire contiguous block of agents to finish
-            break;
-          }
-        }
-
         toolsToPush.push(tc);
       } else {
         // Stop at first non-terminal tool to preserve order
@@ -461,27 +425,27 @@ export const useGeminiStream = (
 
     if (toolsToPush.length > 0) {
       const newPushed = new Set(pushedToolCallIdsRef.current);
+      let isFirst = isFirstToolInGroupRef.current;
 
       for (const tc of toolsToPush) {
         newPushed.add(tc.request.callId);
+        const isLastInBatch = tc === toolCalls[toolCalls.length - 1];
+
+        const historyItem = mapTrackedToolCallsToDisplay(tc, {
+          borderTop: isFirst,
+          borderBottom: isLastInBatch,
+          ...getToolGroupBorderAppearance(
+            { type: 'tool_group', tools: toolCalls },
+            activeShellPtyId,
+            !!isShellFocused,
+            [],
+            backgroundShells,
+          ),
+        });
+        addItem(historyItem);
+        isFirst = false;
       }
 
-      const isLastInBatch =
-        toolsToPush[toolsToPush.length - 1] === toolCalls[toolCalls.length - 1];
-
-      const historyItem = mapTrackedToolCallsToDisplay(toolsToPush, {
-        borderTop: isFirstToolInGroupRef.current,
-        borderBottom: isLastInBatch,
-        ...getToolGroupBorderAppearance(
-          { type: 'tool_group', tools: toolCalls },
-          activeShellPtyId,
-          !!isShellFocused,
-          [],
-          backgroundShells,
-        ),
-      });
-      addItem(historyItem);
-
       setPushedToolCallIds(newPushed);
       setIsFirstToolInGroup(false);
     }

packages/cli/src/utils/sessionCleanup.integration.test.ts

@@ -252,154 +252,4 @@ describe('Session Cleanup Integration', () => {
       await fs.rm(tempDir, { recursive: true, force: true });
     }
   });
-
-  it('should delete subagent files and their artifacts when parent expires', async () => {
-    // Create a temporary directory with test sessions
-    const fs = await import('node:fs/promises');
-    const path = await import('node:path');
-    const os = await import('node:os');
-
-    const tempDir = await fs.mkdtemp(path.join(os.tmpdir(), 'gemini-test-'));
-    const chatsDir = path.join(tempDir, 'chats');
-    const logsDir = path.join(tempDir, 'logs');
-    const toolOutputsDir = path.join(tempDir, 'tool-outputs');
-
-    await fs.mkdir(chatsDir, { recursive: true });
-    await fs.mkdir(logsDir, { recursive: true });
-    await fs.mkdir(toolOutputsDir, { recursive: true });
-
-    const now = new Date();
-    const oldDate = new Date(now.getTime() - 5 * 24 * 60 * 60 * 1000); // 5 days ago
-
-    // The shortId that ties them together
-    const sharedShortId = 'abcdef12';
-
-    const parentSessionId = 'parent-uuid-123';
-    const parentFile = path.join(
-      chatsDir,
-      `${SESSION_FILE_PREFIX}2024-01-01T10-00-00-${sharedShortId}.json`,
-    );
-    await fs.writeFile(
-      parentFile,
-      JSON.stringify({
-        sessionId: parentSessionId,
-        messages: [],
-        startTime: oldDate.toISOString(),
-        lastUpdated: oldDate.toISOString(),
-      }),
-    );
-
-    const subagentSessionId = 'subagent-uuid-456';
-    const subagentFile = path.join(
-      chatsDir,
-      `${SESSION_FILE_PREFIX}2024-01-01T10-05-00-${sharedShortId}.json`,
-    );
-    await fs.writeFile(
-      subagentFile,
-      JSON.stringify({
-        sessionId: subagentSessionId,
-        messages: [],
-        startTime: oldDate.toISOString(),
-        lastUpdated: oldDate.toISOString(),
-      }),
-    );
-
-    const parentLogFile = path.join(
-      logsDir,
-      `session-${parentSessionId}.jsonl`,
-    );
-    await fs.writeFile(parentLogFile, '{"log": "parent"}');
-
-    const parentToolOutputsDir = path.join(
-      toolOutputsDir,
-      `session-${parentSessionId}`,
-    );
-    await fs.mkdir(parentToolOutputsDir, { recursive: true });
-    await fs.writeFile(
-      path.join(parentToolOutputsDir, 'some-output.txt'),
-      'data',
-    );
-
-    const subagentLogFile = path.join(
-      logsDir,
-      `session-${subagentSessionId}.jsonl`,
-    );
-    await fs.writeFile(subagentLogFile, '{"log": "subagent"}');
-
-    const subagentToolOutputsDir = path.join(
-      toolOutputsDir,
-      `session-${subagentSessionId}`,
-    );
-    await fs.mkdir(subagentToolOutputsDir, { recursive: true });
-    await fs.writeFile(
-      path.join(subagentToolOutputsDir, 'some-output.txt'),
-      'data',
-    );
-
-    const currentShortId = 'current1';
-    const currentFile = path.join(
-      chatsDir,
-      `${SESSION_FILE_PREFIX}2025-01-20T10-00-00-${currentShortId}.json`,
-    );
-    await fs.writeFile(
-      currentFile,
-      JSON.stringify({
-        sessionId: 'current-session',
-        messages: [
-          {
-            type: 'user',
-            content: [{ type: 'text', text: 'hello' }],
-            timestamp: now.toISOString(),
-          },
-        ],
-        startTime: now.toISOString(),
-        lastUpdated: now.toISOString(),
-      }),
-    );
-
-    // Configure test
-    const config: Config = {
-      storage: {
-        getProjectTempDir: () => tempDir,
-      },
-      getSessionId: () => 'current-session', // Mock CLI instance ID
-      getDebugMode: () => false,
-      initialize: async () => undefined,
-    } as unknown as Config;
-
-    const settings: Settings = {
-      general: {
-        sessionRetention: {
-          enabled: true,
-          maxAge: '1d', // Expire things older than 1 day
-        },
-      },
-    };
-
-    try {
-      const result = await cleanupExpiredSessions(config, settings);
-
-      // Verify the cleanup result object
-      // It scanned 3 files. It should delete 2 (parent + subagent), and keep 1 (current)
-      expect(result.disabled).toBe(false);
-      expect(result.scanned).toBe(3);
-      expect(result.deleted).toBe(2);
-      expect(result.skipped).toBe(1);
-
-      // Verify on-disk file states
-      const chats = await fs.readdir(chatsDir);
-      expect(chats).toHaveLength(1);
-      expect(chats).toContain(
-        `${SESSION_FILE_PREFIX}2025-01-20T10-00-00-${currentShortId}.json`,
-      ); // Only current is left
-
-      const logs = await fs.readdir(logsDir);
-      expect(logs).toHaveLength(0); // Both parent and subagent logs were deleted
-
-      const tools = await fs.readdir(toolOutputsDir);
-      expect(tools).toHaveLength(0); // Both parent and subagent tool output dirs were deleted
-    } finally {
-      await fs.rm(tempDir, { recursive: true, force: true });
-    }
-  });
 });

packages/cli/src/utils/sessionCleanup.ts

@@ -9,7 +9,6 @@ import * as path from 'node:path';
 import {
   debugLogger,
   sanitizeFilenamePart,
-  SESSION_FILE_PREFIX,
   Storage,
   TOOL_OUTPUTS_DIR,
   type Config,
@@ -27,12 +26,6 @@ const MULTIPLIERS = {
   m: 30 * 24 * 60 * 60 * 1000, // months (30 days) to ms
 };
 
-/**
- * Matches a trailing hyphen followed by exactly 8 alphanumeric characters before the .json extension.
- * Example: session-20250110-abcdef12.json -> captures "abcdef12"
- */
-const SHORT_ID_REGEX = /-([a-zA-Z0-9]{8})\.json$/;
-
 /**
  * Result of session cleanup operation
  */
@@ -44,65 +37,6 @@ export interface CleanupResult {
   failed: number;
 }
 
-/**
- * Helpers for session cleanup.
- */
-
-/**
- * Derives an 8-character shortId from a session filename.
- */
-function deriveShortIdFromFileName(fileName: string): string | null {
-  if (fileName.startsWith(SESSION_FILE_PREFIX) && fileName.endsWith('.json')) {
-    const match = fileName.match(SHORT_ID_REGEX);
-    return match ? match[1] : null;
-  }
-  return null;
-}
-
-/**
- * Gets the log path for a session ID.
- */
-function getSessionLogPath(tempDir: string, safeSessionId: string): string {
-  return path.join(tempDir, 'logs', `session-${safeSessionId}.jsonl`);
-}
-
-/**
- * Cleans up associated artifacts (logs, tool-outputs, directory) for a session.
- */
-async function deleteSessionArtifactsAsync(
-  sessionId: string,
-  config: Config,
-): Promise<void> {
-  const tempDir = config.storage.getProjectTempDir();
-
-  // Cleanup logs
-  const logsDir = path.join(tempDir, 'logs');
-  const safeSessionId = sanitizeFilenamePart(sessionId);
-  const logPath = getSessionLogPath(tempDir, safeSessionId);
-  if (logPath.startsWith(logsDir)) {
-    await fs.unlink(logPath).catch(() => {});
-  }
-
-  // Cleanup tool outputs
-  const toolOutputDir = path.join(
-    tempDir,
-    TOOL_OUTPUTS_DIR,
-    `session-${safeSessionId}`,
-  );
-  const toolOutputsBase = path.join(tempDir, TOOL_OUTPUTS_DIR);
-  if (toolOutputDir.startsWith(toolOutputsBase)) {
-    await fs
-      .rm(toolOutputDir, { recursive: true, force: true })
-      .catch(() => {});
-  }
-
-  // Cleanup session directory
-  const sessionDir = path.join(tempDir, safeSessionId);
-  if (safeSessionId && sessionDir.startsWith(tempDir + path.sep)) {
-    await fs.rm(sessionDir, { recursive: true, force: true }).catch(() => {});
-  }
-}
-
 /**
  * Main entry point for session cleanup during CLI startup
  */
@@ -138,6 +72,7 @@ export async function cleanupExpiredSessions(
       return { ...result, disabled: true };
     }
 
+    // Get all session files (including corrupted ones) for this project
     const allFiles = await getAllSessionFiles(chatsDir, config.getSessionId());
     result.scanned = allFiles.length;
 
@@ -151,110 +86,78 @@ export async function cleanupExpiredSessions(
       retentionConfig,
     );
 
-    const processedShortIds = new Set<string>();
-
     // Delete all sessions that need to be deleted
     for (const sessionToDelete of sessionsToDelete) {
       try {
-        const shortId = deriveShortIdFromFileName(sessionToDelete.fileName);
+        const sessionPath = path.join(chatsDir, sessionToDelete.fileName);
+        await fs.unlink(sessionPath);
 
-        if (shortId) {
-          if (processedShortIds.has(shortId)) {
-            continue;
-          }
-          processedShortIds.add(shortId);
-
-          const matchingFiles = allFiles
-            .map((f) => f.fileName)
-            .filter(
-              (f) =>
-                f.startsWith(SESSION_FILE_PREFIX) &&
-                f.endsWith(`-${shortId}.json`),
-            );
-
-          for (const file of matchingFiles) {
-            const filePath = path.join(chatsDir, file);
-            let fullSessionId: string | undefined;
-
-            try {
-              // Try to read file to get full sessionId
-              try {
-                const fileContent = await fs.readFile(filePath, 'utf8');
-                const content: unknown = JSON.parse(fileContent);
-                if (
-                  content &&
-                  typeof content === 'object' &&
-                  'sessionId' in content
-                ) {
-                  const record = content as Record<string, unknown>;
-                  const id = record['sessionId'];
-                  if (typeof id === 'string') {
-                    fullSessionId = id;
-                  }
-                }
-              } catch {
-                // If read/parse fails, skip getting sessionId, just delete the file
-              }
-
-              // Delete the session file
-              if (!fullSessionId || fullSessionId !== config.getSessionId()) {
-                await fs.unlink(filePath);
-
-                if (fullSessionId) {
-                  await deleteSessionArtifactsAsync(fullSessionId, config);
-                }
-                result.deleted++;
-              } else {
-                result.skipped++;
-              }
-            } catch (error) {
-              // Ignore ENOENT (file already deleted)
-              if (
-                error instanceof Error &&
-                'code' in error &&
-                error.code === 'ENOENT'
-              ) {
-                // File already deleted, do nothing.
-              } else {
-                debugLogger.warn(
-                  `Failed to delete matching file ${file}: ${error instanceof Error ? error.message : 'Unknown error'}`,
-                );
-                result.failed++;
-              }
-            }
-          }
-        } else {
-          // Fallback to old logic
-          const sessionPath = path.join(chatsDir, sessionToDelete.fileName);
-          await fs.unlink(sessionPath);
-
-          const sessionId = sessionToDelete.sessionInfo?.id;
-          if (sessionId) {
-            await deleteSessionArtifactsAsync(sessionId, config);
+        // ALSO cleanup Activity logs in the project logs directory
+        const sessionId = sessionToDelete.sessionInfo?.id;
+        if (sessionId) {
+          const logsDir = path.join(config.storage.getProjectTempDir(), 'logs');
+          const logPath = path.join(logsDir, `session-${sessionId}.jsonl`);
+          try {
+            await fs.unlink(logPath);
+          } catch {
+            /* ignore if log doesn't exist */
           }
 
-          if (config.getDebugMode()) {
-            debugLogger.debug(
-              `Deleted fallback session: ${sessionToDelete.fileName}`,
-            );
+          // ALSO cleanup tool outputs for this session
+          const safeSessionId = sanitizeFilenamePart(sessionId);
+          const toolOutputDir = path.join(
+            config.storage.getProjectTempDir(),
+            TOOL_OUTPUTS_DIR,
+            `session-${safeSessionId}`,
+          );
+          try {
+            await fs.rm(toolOutputDir, { recursive: true, force: true });
+          } catch {
+            /* ignore if doesn't exist */
+          }
+
+          // ALSO cleanup the session-specific directory (contains plans, tasks, etc.)
+          const sessionDir = path.join(
+            config.storage.getProjectTempDir(),
+            sessionId,
+          );
+          try {
+            await fs.rm(sessionDir, { recursive: true, force: true });
+          } catch {
+            /* ignore if doesn't exist */
           }
-          result.deleted++;
         }
+
+        if (config.getDebugMode()) {
+          if (sessionToDelete.sessionInfo === null) {
+            debugLogger.debug(
+              `Deleted corrupted session file: ${sessionToDelete.fileName}`,
+            );
+          } else {
+            debugLogger.debug(
+              `Deleted expired session: ${sessionToDelete.sessionInfo.id} (${sessionToDelete.sessionInfo.lastUpdated})`,
+            );
+          }
+        }
+        result.deleted++;
       } catch (error) {
-        // Ignore ENOENT (file already deleted)
+        // Ignore ENOENT errors (file already deleted)
         if (
           error instanceof Error &&
           'code' in error &&
           error.code === 'ENOENT'
         ) {
-          // File already deleted
+          // File already deleted, do nothing.
         } else {
+          // Log error directly to console
           const sessionId =
             sessionToDelete.sessionInfo === null
               ? sessionToDelete.fileName
               : sessionToDelete.sessionInfo.id;
+          const errorMessage =
+            error instanceof Error ? error.message : 'Unknown error';
           debugLogger.warn(
-            `Failed to delete session ${sessionId}: ${error instanceof Error ? error.message : 'Unknown error'}`,
+            `Failed to delete session ${sessionId}: ${errorMessage}`,
           );
           result.failed++;
         }
@@ -279,6 +182,9 @@ export async function cleanupExpiredSessions(
   return result;
 }
 
+/**
+ * Identifies sessions that should be deleted (corrupted or expired based on retention policy)
+ */
 /**
  * Identifies sessions that should be deleted (corrupted or expired based on retention policy)
  */
@@ -342,19 +248,13 @@ export async function identifySessionsToDelete(
     let shouldDelete = false;
 
     // Age-based retention check
-    if (cutoffDate) {
-      const lastUpdatedDate = new Date(session.lastUpdated);
-      const isExpired = lastUpdatedDate < cutoffDate;
-      if (isExpired) {
-        shouldDelete = true;
-      }
+    if (cutoffDate && new Date(session.lastUpdated) < cutoffDate) {
+      shouldDelete = true;
     }
 
     // Count-based retention check (keep only N most recent deletable sessions)
-    if (maxDeletableSessions !== undefined) {
-      if (i >= maxDeletableSessions) {
-        shouldDelete = true;
-      }
+    if (maxDeletableSessions !== undefined && i >= maxDeletableSessions) {
+      shouldDelete = true;
     }
 
     if (shouldDelete) {

packages/core/src/agents/agent-scheduler.test.ts

@@ -42,8 +42,6 @@ describe('agent-scheduler', () => {
 
   it('should create a scheduler with agent-specific config', async () => {
     const mockConfig = {
-      getPromptRegistry: vi.fn(),
-      getResourceRegistry: vi.fn(),
       messageBus: mockMessageBus,
       toolRegistry: mockToolRegistry,
     } as unknown as Mocked<Config>;
@@ -93,8 +91,6 @@ describe('agent-scheduler', () => {
     } as unknown as Mocked<ToolRegistry>;
 
     const config = {
-      getPromptRegistry: vi.fn(),
-      getResourceRegistry: vi.fn(),
       messageBus: mockMessageBus,
     } as unknown as Mocked<Config>;
     Object.defineProperty(config, 'toolRegistry', {
@@ -127,8 +123,6 @@ describe('agent-scheduler', () => {
 
   it('should create an AgentLoopContext that has a defined .config property', async () => {
     const mockConfig = {
-      getPromptRegistry: vi.fn(),
-      getResourceRegistry: vi.fn(),
       messageBus: mockMessageBus,
       toolRegistry: mockToolRegistry,
       promptId: 'test-prompt',

packages/core/src/agents/agent-scheduler.ts

@@ -11,8 +11,6 @@ import type {
   CompletedToolCall,
 } from '../scheduler/types.js';
 import type { ToolRegistry } from '../tools/tool-registry.js';
-import type { PromptRegistry } from '../prompts/prompt-registry.js';
-import type { ResourceRegistry } from '../resources/resource-registry.js';
 import type { EditorType } from '../utils/editor.js';
 
 /**
@@ -27,10 +25,6 @@ export interface AgentSchedulingOptions {
   parentCallId?: string;
   /** The tool registry specific to this agent. */
   toolRegistry: ToolRegistry;
-  /** The prompt registry specific to this agent. */
-  promptRegistry?: PromptRegistry;
-  /** The resource registry specific to this agent. */
-  resourceRegistry?: ResourceRegistry;
   /** AbortSignal for cancellation. */
   signal: AbortSignal;
   /** Optional function to get the preferred editor for tool modifications. */
@@ -57,19 +51,16 @@ export async function scheduleAgentTools(
     subagent,
     parentCallId,
     toolRegistry,
-    promptRegistry,
-    resourceRegistry,
     signal,
     getPreferredEditor,
     onWaitingForConfirmation,
   } = options;
 
+  // Create a proxy/override of the config to provide the agent-specific tool registry.
   const schedulerContext = {
     config,
     promptId: config.promptId,
     toolRegistry,
-    promptRegistry: promptRegistry ?? config.getPromptRegistry(),
-    resourceRegistry: resourceRegistry ?? config.getResourceRegistry(),
     messageBus: toolRegistry.messageBus,
     geminiClient: config.geminiClient,
     sandboxManager: config.sandboxManager,

packages/core/src/agents/local-executor.test.ts

@@ -13,43 +13,10 @@ import {
   afterEach,
   type Mock,
 } from 'vitest';
-
-const {
-  mockSendMessageStream,
-  mockScheduleAgentTools,
-  mockSetSystemInstruction,
-  mockCompress,
-  mockMaybeDiscoverMcpServer,
-  mockStopMcp,
-} = vi.hoisted(() => ({
-  mockSendMessageStream: vi.fn().mockResolvedValue({
-    async *[Symbol.asyncIterator]() {
-      yield {
-        type: 'chunk',
-        value: { candidates: [] },
-      };
-    },
-  }),
-  mockScheduleAgentTools: vi.fn(),
-  mockSetSystemInstruction: vi.fn(),
-  mockCompress: vi.fn(),
-  mockMaybeDiscoverMcpServer: vi.fn().mockResolvedValue(undefined),
-  mockStopMcp: vi.fn().mockResolvedValue(undefined),
-}));
-
-vi.mock('../tools/mcp-client-manager.js', () => ({
-  McpClientManager: class {
-    maybeDiscoverMcpServer = mockMaybeDiscoverMcpServer;
-    stop = mockStopMcp;
-  },
-}));
-
 import { debugLogger } from '../utils/debugLogger.js';
 import { LocalAgentExecutor, type ActivityCallback } from './local-executor.js';
 import { makeFakeConfig } from '../test-utils/config.js';
 import { ToolRegistry } from '../tools/tool-registry.js';
-import { PromptRegistry } from '../prompts/prompt-registry.js';
-import { ResourceRegistry } from '../resources/resource-registry.js';
 import { DiscoveredMCPTool } from '../tools/mcp-tool.js';
 import { LSTool } from '../tools/ls.js';
 import { LS_TOOL_NAME, READ_FILE_TOOL_NAME } from '../tools/tool-names.js';
@@ -103,6 +70,18 @@ import type {
 import { getModelConfigAlias, type AgentRegistry } from './registry.js';
 import type { ModelRouterService } from '../routing/modelRouterService.js';
 
+const {
+  mockSendMessageStream,
+  mockScheduleAgentTools,
+  mockSetSystemInstruction,
+  mockCompress,
+} = vi.hoisted(() => ({
+  mockSendMessageStream: vi.fn(),
+  mockScheduleAgentTools: vi.fn(),
+  mockSetSystemInstruction: vi.fn(),
+  mockCompress: vi.fn(),
+}));
+
 let mockChatHistory: Content[] = [];
 const mockSetHistory = vi.fn((newHistory: Content[]) => {
   mockChatHistory = newHistory;
@@ -2743,67 +2722,6 @@ describe('LocalAgentExecutor', () => {
     });
   });
 
-  describe('MCP Isolation', () => {
-    it('should initialize McpClientManager when mcpServers are defined', async () => {
-      const { MCPServerConfig } = await import('../config/config.js');
-      const mcpServers = {
-        'test-server': new MCPServerConfig('node', ['server.js']),
-      };
-
-      const definition = {
-        ...createTestDefinition(),
-        mcpServers,
-      };
-
-      vi.spyOn(mockConfig, 'getMcpClientManager').mockReturnValue({
-        maybeDiscoverMcpServer: mockMaybeDiscoverMcpServer,
-      } as unknown as ReturnType<typeof mockConfig.getMcpClientManager>);
-
-      await LocalAgentExecutor.create(definition, mockConfig);
-
-      const mcpManager = mockConfig.getMcpClientManager();
-      expect(mcpManager?.maybeDiscoverMcpServer).toHaveBeenCalledWith(
-        'test-server',
-        mcpServers['test-server'],
-        expect.objectContaining({
-          toolRegistry: expect.any(ToolRegistry),
-          promptRegistry: expect.any(PromptRegistry),
-          resourceRegistry: expect.any(ResourceRegistry),
-        }),
-      );
-    });
-
-    it('should inherit main registry tools', async () => {
-      const parentMcpTool = new DiscoveredMCPTool(
-        {} as unknown as CallableTool,
-        'main-server',
-        'tool1',
-        'desc1',
-        {},
-        mockConfig.getMessageBus(),
-      );
-
-      parentToolRegistry.registerTool(parentMcpTool);
-
-      const definition = createTestDefinition();
-      definition.toolConfig = undefined; // trigger inheritance
-
-      vi.spyOn(mockConfig, 'getMcpClientManager').mockReturnValue({
-        maybeDiscoverMcpServer: vi.fn(),
-      } as unknown as ReturnType<typeof mockConfig.getMcpClientManager>);
-      const executor = await LocalAgentExecutor.create(
-        definition,
-        mockConfig,
-        onActivity,
-      );
-      const agentTools = (
-        executor as unknown as { toolRegistry: ToolRegistry }
-      ).toolRegistry.getAllToolNames();
-
-      expect(agentTools).toContain(parentMcpTool.name);
-    });
-  });
-
   describe('DeclarativeTool instance tools (browser agent pattern)', () => {
     /**
      * The browser agent passes DeclarativeTool instances (not string names) in
@@ -2909,11 +2827,13 @@ describe('LocalAgentExecutor', () => {
       const navTool = new MockTool({ name: 'navigate_page' });
 
       const definition = createInstanceToolDefinition([clickTool, navTool]);
+
       const executor = await LocalAgentExecutor.create(
         definition,
         mockConfig,
         onActivity,
       );
+
       const registry = executor['toolRegistry'];
       expect(registry.getTool('click')).toBeDefined();
       expect(registry.getTool('navigate_page')).toBeDefined();

packages/core/src/agents/local-executor.ts

@@ -4,6 +4,7 @@
  * SPDX-License-Identifier: Apache-2.0
  */
 
+import type { Config } from '../config/config.js';
 import { type AgentLoopContext } from '../config/agent-loop-context.js';
 import { reportError } from '../utils/errorReporting.js';
 import { GeminiChat, StreamEventType } from '../core/geminiChat.js';
@@ -16,8 +17,6 @@ import {
   type Schema,
 } from '@google/genai';
 import { ToolRegistry } from '../tools/tool-registry.js';
-import { PromptRegistry } from '../prompts/prompt-registry.js';
-import { ResourceRegistry } from '../resources/resource-registry.js';
 import { type AnyDeclarativeTool } from '../tools/tools.js';
 import {
   DiscoveredMCPTool,
@@ -103,22 +102,14 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
 
   private readonly agentId: string;
   private readonly toolRegistry: ToolRegistry;
-  private readonly promptRegistry: PromptRegistry;
-  private readonly resourceRegistry: ResourceRegistry;
   private readonly context: AgentLoopContext;
   private readonly onActivity?: ActivityCallback;
   private readonly compressionService: ChatCompressionService;
   private readonly parentCallId?: string;
   private hasFailedCompressionAttempt = false;
 
-  private get executionContext(): AgentLoopContext {
-    return {
-      ...this.context,
-      toolRegistry: this.toolRegistry,
-      promptRegistry: this.promptRegistry,
-      resourceRegistry: this.resourceRegistry,
-      messageBus: this.toolRegistry.getMessageBus(),
-    };
+  private get config(): Config {
+    return this.context.config;
   }
 
   /**
@@ -142,27 +133,11 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
     // Create an override object to inject the subagent name into tool confirmation requests
     const subagentMessageBus = parentMessageBus.derive(definition.name);
 
-    // Create isolated registries for this agent instance.
+    // Create an isolated tool registry for this agent instance.
     const agentToolRegistry = new ToolRegistry(
       context.config,
       subagentMessageBus,
     );
-    const agentPromptRegistry = new PromptRegistry();
-    const agentResourceRegistry = new ResourceRegistry();
-
-    if (definition.mcpServers) {
-      const globalMcpManager = context.config.getMcpClientManager();
-      if (globalMcpManager) {
-        for (const [name, config] of Object.entries(definition.mcpServers)) {
-          await globalMcpManager.maybeDiscoverMcpServer(name, config, {
-            toolRegistry: agentToolRegistry,
-            promptRegistry: agentPromptRegistry,
-            resourceRegistry: agentResourceRegistry,
-          });
-        }
-      }
-    }
-
     const parentToolRegistry = context.toolRegistry;
     const allAgentNames = new Set(
       context.config.getAgentRegistry().getAllAgentNames(),
@@ -178,9 +153,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
         return;
       }
 
-      // Clone the tool, so it gets its own state and subagent messageBus
-      const clonedTool = tool.clone(subagentMessageBus);
-      agentToolRegistry.registerTool(clonedTool);
+      agentToolRegistry.registerTool(tool);
     };
 
     const registerToolByName = (toolName: string) => {
@@ -255,12 +228,10 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
     return new LocalAgentExecutor(
       definition,
       context,
-      parentPromptId,
       agentToolRegistry,
-      agentPromptRegistry,
-      agentResourceRegistry,
-      onActivity,
+      parentPromptId,
       parentCallId,
+      onActivity,
     );
   }
 
@@ -273,18 +244,14 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
   private constructor(
     definition: LocalAgentDefinition<TOutput>,
     context: AgentLoopContext,
-    parentPromptId: string | undefined,
     toolRegistry: ToolRegistry,
-    promptRegistry: PromptRegistry,
-    resourceRegistry: ResourceRegistry,
+    parentPromptId: string | undefined,
+    parentCallId: string | undefined,
     onActivity?: ActivityCallback,
-    parentCallId?: string,
   ) {
     this.definition = definition;
     this.context = context;
     this.toolRegistry = toolRegistry;
-    this.promptRegistry = promptRegistry;
-    this.resourceRegistry = resourceRegistry;
     this.onActivity = onActivity;
     this.compressionService = new ChatCompressionService();
     this.parentCallId = parentCallId;
@@ -480,7 +447,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
     } finally {
       clearTimeout(graceTimeoutId);
       logRecoveryAttempt(
-        this.context.config,
+        this.config,
         new RecoveryAttemptEvent(
           this.agentId,
           this.definition.name,
@@ -528,7 +495,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
     const combinedSignal = AbortSignal.any([signal, deadlineTimer.signal]);
 
     logAgentStart(
-      this.context.config,
+      this.config,
       new AgentStartEvent(this.agentId, this.definition.name),
     );
 
@@ -539,7 +506,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
       const augmentedInputs = {
         ...inputs,
         cliVersion: await getVersion(),
-        activeModel: this.context.config.getActiveModel(),
+        activeModel: this.config.getActiveModel(),
         today: new Date().toLocaleDateString(),
       };
 
@@ -561,16 +528,14 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
       // Capture the index of the last hint before starting to avoid re-injecting old hints.
       // NOTE: Hints added AFTER this point will be broadcast to all currently running
       // local agents via the listener below.
-      const startIndex =
-        this.context.config.injectionService.getLatestInjectionIndex();
-      this.context.config.injectionService.onInjection(injectionListener);
+      const startIndex = this.config.injectionService.getLatestInjectionIndex();
+      this.config.injectionService.onInjection(injectionListener);
 
       try {
-        const initialHints =
-          this.context.config.injectionService.getInjectionsAfter(
-            startIndex,
-            'user_steering',
-          );
+        const initialHints = this.config.injectionService.getInjectionsAfter(
+          startIndex,
+          'user_steering',
+        );
         const formattedInitialHints = formatUserHintsForModel(initialHints);
 
         let currentMessage: Content = formattedInitialHints
@@ -641,16 +606,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
           }
         }
       } finally {
-        this.context.config.injectionService.offInjection(injectionListener);
-
-        const globalMcpManager = this.context.config.getMcpClientManager();
-        if (globalMcpManager) {
-          globalMcpManager.removeRegistries({
-            toolRegistry: this.toolRegistry,
-            promptRegistry: this.promptRegistry,
-            resourceRegistry: this.resourceRegistry,
-          });
-        }
+        this.config.injectionService.offInjection(injectionListener);
       }
 
       // === UNIFIED RECOVERY BLOCK ===
@@ -763,7 +719,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
     } finally {
       deadlineTimer.abort();
       logAgentFinish(
-        this.context.config,
+        this.config,
         new AgentFinishEvent(
           this.agentId,
           this.definition.name,
@@ -786,7 +742,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
       prompt_id,
       false,
       model,
-      this.context.config,
+      this.config,
       this.hasFailedCompressionAttempt,
     );
 
@@ -824,11 +780,10 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
     const modelConfigAlias = getModelConfigAlias(this.definition);
 
     // Resolve the model config early to get the concrete model string (which may be `auto`).
-    const resolvedConfig =
-      this.context.config.modelConfigService.getResolvedConfig({
-        model: modelConfigAlias,
-        overrideScope: this.definition.name,
-      });
+    const resolvedConfig = this.config.modelConfigService.getResolvedConfig({
+      model: modelConfigAlias,
+      overrideScope: this.definition.name,
+    });
     const requestedModel = resolvedConfig.model;
 
     let modelToUse: string;
@@ -845,7 +800,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
           signal,
           requestedModel,
         };
-        const router = this.context.config.getModelRouterService();
+        const router = this.config.getModelRouterService();
         const decision = await router.route(routingContext);
         modelToUse = decision.model;
       } catch (error) {
@@ -933,7 +888,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
 
     try {
       return new GeminiChat(
-        this.executionContext,
+        this.config,
         systemInstruction,
         [{ functionDeclarations: tools }],
         startHistory,
@@ -1181,15 +1136,13 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
     // Execute standard tool calls using the new scheduler
     if (toolRequests.length > 0) {
       const completedCalls = await scheduleAgentTools(
-        this.context.config,
+        this.config,
         toolRequests,
         {
-          schedulerId: promptId,
+          schedulerId: this.agentId,
           subagent: this.definition.name,
           parentCallId: this.parentCallId,
           toolRegistry: this.toolRegistry,
-          promptRegistry: this.promptRegistry,
-          resourceRegistry: this.resourceRegistry,
           signal,
           onWaitingForConfirmation,
         },
@@ -1324,7 +1277,7 @@ export class LocalAgentExecutor<TOutput extends z.ZodTypeAny> {
     let finalPrompt = templateString(promptConfig.systemPrompt, inputs);
 
     // Append environment context (CWD and folder structure).
-    const dirContext = await getDirectoryContextString(this.context.config);
+    const dirContext = await getDirectoryContextString(this.config);
     finalPrompt += `\n\n# Environment Context\n${dirContext}`;
 
     // Append standard rules for non-interactive execution.

packages/core/src/agents/local-invocation.test.ts

@@ -207,11 +207,8 @@ describe('LocalSubagentInvocation', () => {
           ),
         },
       ]);
-      const display = result.returnDisplay as SubagentProgress;
-      expect(display.isSubagentProgress).toBe(true);
-      expect(display.state).toBe('completed');
-      expect(display.result).toBe('Analysis complete.');
-      expect(display.terminateReason).toBe(AgentTerminateMode.GOAL);
+      expect(result.returnDisplay).toBe('Analysis complete.');
+      expect(result.returnDisplay).not.toContain('Termination Reason');
     });
 
     it('should show detailed UI for non-goal terminations (e.g., TIMEOUT)', async () => {
@@ -223,11 +220,11 @@ describe('LocalSubagentInvocation', () => {
 
       const result = await invocation.execute(signal, updateOutput);
 
-      const display = result.returnDisplay as SubagentProgress;
-      expect(display.isSubagentProgress).toBe(true);
-      expect(display.state).toBe('completed');
-      expect(display.result).toBe('Partial progress...');
-      expect(display.terminateReason).toBe(AgentTerminateMode.TIMEOUT);
+      expect(result.returnDisplay).toContain(
+        '### Subagent MockAgent Finished Early',
+      );
+      expect(result.returnDisplay).toContain('**Termination Reason:** TIMEOUT');
+      expect(result.returnDisplay).toContain('Partial progress...');
     });
 
     it('should stream THOUGHT_CHUNK activities from the executor', async () => {
@@ -253,8 +250,8 @@ describe('LocalSubagentInvocation', () => {
 
       await invocation.execute(signal, updateOutput);
 
-      expect(updateOutput).toHaveBeenCalledTimes(4); // Initial + 2 updates + Final completion
-      const lastCall = updateOutput.mock.calls[3][0] as SubagentProgress;
+      expect(updateOutput).toHaveBeenCalledTimes(3); // Initial + 2 updates
+      const lastCall = updateOutput.mock.calls[2][0] as SubagentProgress;
       expect(lastCall.recentActivity).toContainEqual(
         expect.objectContaining({
           type: 'thought',
@@ -286,8 +283,8 @@ describe('LocalSubagentInvocation', () => {
 
       await invocation.execute(signal, updateOutput);
 
-      expect(updateOutput).toHaveBeenCalledTimes(4); // Initial + 2 updates + Final completion
-      const lastCall = updateOutput.mock.calls[3][0] as SubagentProgress;
+      expect(updateOutput).toHaveBeenCalledTimes(3);
+      const lastCall = updateOutput.mock.calls[2][0] as SubagentProgress;
       expect(lastCall.recentActivity).toContainEqual(
         expect.objectContaining({
           type: 'thought',
@@ -315,10 +312,7 @@ describe('LocalSubagentInvocation', () => {
       // Execute without the optional callback
       const result = await invocation.execute(signal);
       expect(result.error).toBeUndefined();
-      const display = result.returnDisplay as SubagentProgress;
-      expect(display.isSubagentProgress).toBe(true);
-      expect(display.state).toBe('completed');
-      expect(display.result).toBe('Done');
+      expect(result.returnDisplay).toBe('Done');
     });
 
     it('should handle executor run failure', async () => {

packages/core/src/agents/local-invocation.ts

@@ -6,6 +6,7 @@
 
 import { type AgentLoopContext } from '../config/agent-loop-context.js';
 import { LocalAgentExecutor } from './local-executor.js';
+import { safeJsonToMarkdown } from '../utils/markdownUtils.js';
 import {
   BaseToolInvocation,
   type ToolResult,
@@ -245,27 +246,28 @@ export class LocalSubagentInvocation extends BaseToolInvocation<
         throw cancelError;
       }
 
-      const progress: SubagentProgress = {
-        isSubagentProgress: true,
-        agentName: this.definition.name,
-        recentActivity: [...recentActivity],
-        state: 'completed',
-        result: output.result,
-        terminateReason: output.terminate_reason,
-      };
-
-      if (updateOutput) {
-        updateOutput(progress);
-      }
+      const displayResult = safeJsonToMarkdown(output.result);
 
       const resultContent = `Subagent '${this.definition.name}' finished.
 Termination Reason: ${output.terminate_reason}
 Result:
 ${output.result}`;
 
+      const displayContent =
+        output.terminate_reason === AgentTerminateMode.GOAL
+          ? displayResult
+          : `
+### Subagent ${this.definition.name} Finished Early
+
+**Termination Reason:** ${output.terminate_reason}
+
+**Result/Summary:**
+${displayResult}
+`;
+
       return {
         llmContent: [{ text: resultContent }],
-        returnDisplay: progress,
+        returnDisplay: displayContent,
       };
     } catch (error) {
       const errorMessage =

packages/core/src/agents/types.ts

@@ -87,8 +87,6 @@ export interface SubagentProgress {
   agentName: string;
   recentActivity: SubagentActivityItem[];
   state?: 'running' | 'completed' | 'error' | 'cancelled';
-  result?: string;
-  terminateReason?: AgentTerminateMode;
 }
 
 export function isSubagentProgress(obj: unknown): obj is SubagentProgress {

packages/core/src/config/agent-loop-context.ts

@@ -7,8 +7,6 @@
 import type { GeminiClient } from '../core/client.js';
 import type { MessageBus } from '../confirmation-bus/message-bus.js';
 import type { ToolRegistry } from '../tools/tool-registry.js';
-import type { PromptRegistry } from '../prompts/prompt-registry.js';
-import type { ResourceRegistry } from '../resources/resource-registry.js';
 import type { SandboxManager } from '../services/sandboxManager.js';
 import type { Config } from './config.js';
 
@@ -26,12 +24,6 @@ export interface AgentLoopContext {
   /** The registry of tools available to the agent in this context. */
   readonly toolRegistry: ToolRegistry;
 
-  /** The registry of prompts available to the agent in this context. */
-  readonly promptRegistry: PromptRegistry;
-
-  /** The registry of resources available to the agent in this context. */
-  readonly resourceRegistry: ResourceRegistry;
-
   /** The bus for user confirmations and messages in this context. */
   readonly messageBus: MessageBus;
 

packages/core/src/config/config.ts

@@ -660,8 +660,8 @@ export class Config implements McpContext, AgentLoopContext {
   private allowedEnvironmentVariables: string[];
   private blockedEnvironmentVariables: string[];
   private readonly enableEnvironmentVariableRedaction: boolean;
-  private _promptRegistry!: PromptRegistry;
-  private _resourceRegistry!: ResourceRegistry;
+  private promptRegistry!: PromptRegistry;
+  private resourceRegistry!: ResourceRegistry;
   private agentRegistry!: AgentRegistry;
   private readonly acknowledgedAgentsService: AcknowledgedAgentsService;
   private skillManager!: SkillManager;
@@ -1245,8 +1245,8 @@ export class Config implements McpContext, AgentLoopContext {
     if (this.getCheckpointingEnabled()) {
       await this.getGitService();
     }
-    this._promptRegistry = new PromptRegistry();
-    this._resourceRegistry = new ResourceRegistry();
+    this.promptRegistry = new PromptRegistry();
+    this.resourceRegistry = new ResourceRegistry();
 
     this.agentRegistry = new AgentRegistry(this);
     await this.agentRegistry.initialize();
@@ -1482,22 +1482,6 @@ export class Config implements McpContext, AgentLoopContext {
     return this._toolRegistry;
   }
 
-  /**
-   * @deprecated Do not access directly on Config.
-   * Use the injected AgentLoopContext instead.
-   */
-  get promptRegistry(): PromptRegistry {
-    return this._promptRegistry;
-  }
-
-  /**
-   * @deprecated Do not access directly on Config.
-   * Use the injected AgentLoopContext instead.
-   */
-  get resourceRegistry(): ResourceRegistry {
-    return this._resourceRegistry;
-  }
-
   /**
    * @deprecated Do not access directly on Config.
    * Use the injected AgentLoopContext instead.
@@ -1810,7 +1794,7 @@ export class Config implements McpContext, AgentLoopContext {
   }
 
   getPromptRegistry(): PromptRegistry {
-    return this._promptRegistry;
+    return this.promptRegistry;
   }
 
   getSkillManager(): SkillManager {
@@ -1818,7 +1802,7 @@ export class Config implements McpContext, AgentLoopContext {
   }
 
   getResourceRegistry(): ResourceRegistry {
-    return this._resourceRegistry;
+    return this.resourceRegistry;
   }
 
   getDebugMode(): boolean {

packages/core/src/core/__snapshots__/prompts.test.ts.snap

@@ -44,10 +44,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -219,10 +215,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -513,10 +505,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -688,10 +676,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -753,12 +737,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -869,10 +847,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, you must work autonomously as no further user input is available. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -904,12 +878,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -1002,10 +970,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, you must work autonomously as no further user input is available. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -1037,12 +1001,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -1608,10 +1566,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -1686,12 +1640,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -1785,10 +1733,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -1850,12 +1794,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -1953,10 +1891,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -2018,12 +1952,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -2121,10 +2049,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -2186,12 +2110,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -2285,10 +2203,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -2350,12 +2264,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -2449,10 +2357,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -2514,12 +2418,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -2605,10 +2503,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -2670,12 +2564,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -2768,10 +2656,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -2833,12 +2717,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -3056,10 +2934,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -3121,12 +2995,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -3472,10 +3340,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -3537,12 +3401,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -3636,10 +3494,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -3701,12 +3555,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -3912,10 +3760,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -3977,12 +3821,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.
@@ -4076,10 +3914,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. For Directives, only clarify if critically underspecified; otherwise, work autonomously. You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.
@@ -4141,12 +3975,6 @@ Operate using a **Research -> Strategy -> Execution** lifecycle. For the Executi
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.

packages/core/src/index.ts

@@ -118,7 +118,6 @@ export * from './utils/channel.js';
 export * from './utils/constants.js';
 export * from './utils/sessionUtils.js';
 export * from './utils/cache.js';
-export * from './utils/markdownUtils.js';
 
 // Export services
 export * from './services/fileDiscoveryService.js';

packages/core/src/prompts/snippets.ts

@@ -222,10 +222,6 @@ Use the following guidelines to optimize your search and read patterns.
 - **Conventions & Style:** Rigorously adhere to existing workspace conventions, architectural patterns, and style (naming, formatting, typing, commenting). During the research phase, analyze surrounding files, tests, and configuration to ensure your changes are seamless, idiomatic, and consistent with the local context. Never compromise idiomatic quality or completeness (e.g., proper declarations, type safety, documentation) to minimize tool calls; all supporting changes required by local conventions are part of a surgical update.
 - **Libraries/Frameworks:** NEVER assume a library/framework is available. Verify its established usage within the project (check imports, configuration files like 'package.json', 'Cargo.toml', 'requirements.txt', etc.) before employing it.
 - **Technical Integrity:** You are responsible for the entire lifecycle: implementation, testing, and validation. Within the scope of your changes, prioritize readability and long-term maintainability by consolidating logic into clean abstractions rather than threading state across unrelated layers. Align strictly with the requested architectural direction, ensuring the final implementation is focused and free of redundant "just-in-case" alternatives. Validation is not merely running tests; it is the exhaustive process of ensuring that every aspect of your change—behavioral, structural, and stylistic—is correct and fully compatible with the broader project. For bug fixes, you must empirically reproduce the failure with a new test case or reproduction script before applying the fix.
-- **Verification Fidelity:** Tailor your validation effort to the complexity and risk of the task.
-  - **Low Risk (Formatting, simple text changes):** Verify via direct inspection or simple side-effect checks (e.g., \`ls\` or \`cat\`).
-  - **Medium Risk (New functions, script logic):** Create a targeted verification script that exercises the specific logic added.
-  - **High Risk (Mathematical models, complex algorithms):** Perform end-to-end behavioral validation using representative test cases. Ensure your verification checks the **behavioral requirement** (e.g., "is the output correct?") not just the **operational side-effect** (e.g., "did the script run?").
 - **Expertise & Intent Alignment:** Provide proactive technical opinions grounded in research while strictly adhering to the user's intended workflow. Distinguish between **Directives** (unambiguous requests for action or implementation) and **Inquiries** (requests for analysis, advice, or observations). Assume all requests are Inquiries unless they contain an explicit instruction to perform a task. For Inquiries, your scope is strictly limited to research and analysis; you may propose a solution or strategy, but you MUST NOT modify files until a corresponding Directive is issued. Do not initiate implementation based on observations of bugs or statements of fact. Once an Inquiry is resolved, or while waiting for a Directive, stop and wait for the next user instruction. ${options.interactive ? 'For Directives, only clarify if critically underspecified; otherwise, work autonomously.' : 'For Directives, you must work autonomously as no further user input is available.'} You should only seek user intervention if you have exhausted all possible routes or if a proposed solution would take the workspace in a significantly different architectural direction.
 - **Proactiveness:** When executing a Directive, persist through errors and obstacles by diagnosing failures in the execution phase and, if necessary, backtracking to the research or strategy phases to adjust your approach until a successful, verified outcome is achieved. Fulfill the user's request thoroughly, including adding tests when adding features or fixing bugs. Take reasonable liberties to fulfill broad goals while staying within the requested scope; however, prioritize simplicity and the removal of redundant logic over providing "just-in-case" alternatives that diverge from the established path.
 - **Testing:** ALWAYS search for and update related tests after making a code change. You must add a new test case to the existing test file (if one exists) or create a new test file to verify your changes.${mandateConflictResolution(options.hasHierarchicalMemory)}
@@ -332,12 +328,6 @@ ${workflowStepStrategy(options)}
 
 **Validation is the only path to finality.** Never assume success or settle for unverified changes. Rigorous, exhaustive verification is mandatory; it prevents the compounding cost of diagnosing failures later. A task is only complete when the behavioral correctness of the change has been verified and its structural integrity is confirmed within the full project context. Prioritize comprehensive validation above all else, utilizing redirection and focused analysis to manage high-output tasks without sacrificing depth. Never sacrifice validation rigor for the sake of brevity or to minimize tool-call overhead; partial or isolated checks are insufficient when more comprehensive validation is possible.
 
-**Strategic Re-evaluation:** If you have attempted to fix a failing implementation more than 10 times without success, you must:
-1. Stop and re-read the original task description.
-2. List your current assumptions and identify which ones might be wrong.
-3. Propose a different architectural approach rather than continuing to patch the current one.
-4. If the environment constraints (e.g., single-process shell) fundamentally prevent success, explain the limitation clearly and terminate.
-
 ## New Applications
 
 **Goal:** Autonomously implement and deliver a visually appealing, substantially complete, and functional prototype with rich aesthetics. Users judge applications by their visual impact; ensure they feel modern, "alive," and polished through consistent spacing, interactive feedback, and platform-appropriate design.