Compare commits

...

28 Commits

Author SHA1 Message Date
Mark McLaughlin c3d11e09e1 Merge branch 'main' into feat/card-component 2026-02-10 14:22:34 -08:00
gemini-cli-robot 8257ec447a chore(release): bump version to 0.30.0-nightly.20260210.a2174751d (#18772) 2026-02-10 17:13:00 -05:00
Shreya Keshive 9590a092ae Revert "fix(mcp): ensure MCP transport is closed to prevent memory leaks" (#18771) 2026-02-10 22:00:36 +00:00
Dev Randalpura 49533cd106 feat(ux): added text wrapping capabilities to markdown tables (#18240)
Co-authored-by: jacob314 <jacob314@gmail.com>
2026-02-10 21:12:53 +00:00
Kevin Ramdass a2174751de feat(telemetry): Ensure experiment IDs are included in OpenTelemetry logs (#18747) 2026-02-10 21:01:35 +00:00
Christian Gunderman 8b762111a8 Fix issue where Gemini CLI creates tests in a new file (#18409) 2026-02-10 20:53:29 +00:00
Adam Weidman c03d96b46c chore: cleanup unused and add unlisted dependencies in packages/cli (#18749) 2026-02-10 20:53:19 +00:00
Sehoon Shon ea1f19aa52 fix(cli): fix history navigation regression after prompt autocomplete (#18752) 2026-02-10 20:53:06 +00:00
Christian Gunderman 2eb1c92347 Fix issues with rip grep (#18756) 2026-02-10 20:48:56 +00:00
Mark McLaughlin 9ae8f7f3ac refactor: Update Card snapshots to improve formatting and add new card states 2026-02-10 12:00:30 -08:00
Mark McLaughlin 9c91f25d62 refactor: Update Card component to adjust colors for Executing status 2026-02-10 12:00:22 -08:00
Mark McLaughlin 85446fdfd3 refactor: Update Card tests to use renderWithProviders and add new card states 2026-02-10 12:00:13 -08:00
Mark McLaughlin 861a72906d refactor: Simplify CardDemo example by removing redundant cards and enhancing clarity 2026-02-10 12:00:05 -08:00
Mark McLaughlin 6f20f8a300 refactor: Update Card component snapshots to use showStatusIndicator and improve clarity 2026-02-10 11:36:23 -08:00
Mark McLaughlin 544ccdbe1e refactor: Replace prefix prop with showStatusIndicator in Card component tests for clarity 2026-02-10 11:36:01 -08:00
Mark McLaughlin 8d9f45efeb feat: Add CardDemo example showcasing various Card component states and configurations 2026-02-10 11:35:29 -08:00
Mark McLaughlin 47d51fb4bd refactor: Rename prefix prop to showStatusIndicator for clarity in Card component 2026-02-10 11:35:19 -08:00
Mark McLaughlin 6fd45b50f6 refactor: Integrate checkExhaustive function and ensure Card component width is configurable 2026-02-10 10:56:09 -08:00
Mark McLaughlin 4596ced82e test: Add fixed width card case and restore mocks after each test 2026-02-10 10:55:51 -08:00
Mark McLaughlin 1ecfcc963e refactor: Update Card component to use a status prop and integrate ToolStatusIndicator. 2026-02-05 15:37:24 -08:00
Mark McLaughlin cc78073add test: Remove width prop from Card component test case. 2026-02-05 11:18:14 -08:00
Mark McLaughlin 89b9c4fe63 refactor: export Card component directly and explicitly define styles for the information variant. 2026-02-05 11:17:13 -08:00
Mark McLaughlin a1ff30b6fe test: Remove debug console.log from Card test and add snapshot. 2026-02-05 11:09:08 -08:00
Mark McLaughlin 5dfcab609a refactor: remove width prop from Card component and add as const to test array. 2026-02-05 11:07:19 -08:00
Mark McLaughlin 254bdbc027 Merge branch 'main' into feat/card-component 2026-02-05 08:27:46 -08:00
Mark McLaughlin d3f328dc5b fix: removed unnecessary export 2026-02-04 22:30:05 -08:00
Mark McLaughlin 0a385dbf97 feat(card): implement Card component with rendering and glyph support 2026-02-04 22:29:26 -08:00
Mark McLaughlin 70c9975296 chore: added WARNING and INFORMATION glyphs 2026-02-04 16:29:00 -08:00
31 changed files with 1408 additions and 1144 deletions
+1 -1
View File
@@ -25,7 +25,7 @@ You are an expert at fixing behavioral evaluations.
the same scenario. We don't want to lose test fidelity by making the prompts too
direct (i.e.: easy).
- Your primary mechanism for improving the agent's behavior is to make changes to
tool instructions, prompt.ts, and/or modules that contribute to the prompt.
tool instructions, system prompt (snippets.ts), and/or modules that contribute to the prompt.
- If prompt and description changes are unsuccessful, use logs and debugging to
confirm that everything is working as expected.
- If unable to fix the test, you can make recommendations for architecture changes
+110
View File
@@ -0,0 +1,110 @@
/**
* @license
* Copyright 2026 Google LLC
* SPDX-License-Identifier: Apache-2.0
*/
import { describe, expect } from 'vitest';
import { evalTest } from './test-helper.js';
describe('Edits location eval', () => {
/**
* Ensure that Gemini CLI always updates existing test files, if present,
* instead of creating a new one.
*/
evalTest('USUALLY_PASSES', {
name: 'should update existing test file instead of creating a new one',
files: {
'package.json': JSON.stringify(
{
name: 'test-location-repro',
version: '1.0.0',
scripts: {
test: 'vitest run',
},
devDependencies: {
vitest: '^1.0.0',
typescript: '^5.0.0',
},
},
null,
2,
),
'src/math.ts': `
export function add(a: number, b: number): number {
return a + b;
}
export function subtract(a: number, b: number): number {
return a - b;
}
export function multiply(a: number, b: number): number {
return a + b;
}
`,
'src/math.test.ts': `
import { expect, test } from 'vitest';
import { add, subtract } from './math';
test('add adds two numbers', () => {
expect(add(2, 3)).toBe(5);
});
test('subtract subtracts two numbers', () => {
expect(subtract(5, 3)).toBe(2);
});
`,
'src/utils.ts': `
export function capitalize(s: string): string {
return s.charAt(0).toUpperCase() + s.slice(1);
}
`,
'src/utils.test.ts': `
import { expect, test } from 'vitest';
import { capitalize } from './utils';
test('capitalize capitalizes the first letter', () => {
expect(capitalize('hello')).toBe('Hello');
});
`,
},
prompt: 'Fix the bug in src/math.ts. Do not run the code.',
timeout: 180000,
assert: async (rig) => {
const toolLogs = rig.readToolLogs();
const replaceCalls = toolLogs.filter(
(t) => t.toolRequest.name === 'replace',
);
const writeFileCalls = toolLogs.filter(
(t) => t.toolRequest.name === 'write_file',
);
expect(replaceCalls.length).toBeGreaterThan(0);
expect(
writeFileCalls.some((file) =>
file.toolRequest.args.includes('.test.ts'),
),
).toBe(false);
const targetFiles = replaceCalls.map((t) => {
try {
return JSON.parse(t.toolRequest.args).file_path;
} catch {
return null;
}
});
console.log('DEBUG: targetFiles', targetFiles);
expect(
new Set(targetFiles).size,
'Expected only two files changed',
).greaterThanOrEqual(2);
expect(targetFiles.some((f) => f?.endsWith('src/math.ts'))).toBe(true);
expect(targetFiles.some((f) => f?.endsWith('src/math.test.ts'))).toBe(
true,
);
},
});
});
+22 -1
View File
@@ -11,6 +11,7 @@ import * as os from 'node:os';
import { RipGrepTool } from '../packages/core/src/tools/ripGrep.js';
import { Config } from '../packages/core/src/config/config.js';
import { WorkspaceContext } from '../packages/core/src/utils/workspaceContext.js';
import { createMockMessageBus } from '../packages/core/src/test-utils/mock-message-bus.js';
// Mock Config to provide necessary context
class MockConfig {
@@ -66,7 +67,7 @@ describe('ripgrep-real-direct', () => {
await fs.writeFile(path.join(tempDir, 'file3.txt'), 'goodbye moon\n');
const config = new MockConfig(tempDir) as unknown as Config;
tool = new RipGrepTool(config);
tool = new RipGrepTool(config, createMockMessageBus());
});
afterAll(async () => {
@@ -108,4 +109,24 @@ describe('ripgrep-real-direct', () => {
expect(result.llmContent).toContain('script.js');
expect(result.llmContent).not.toContain('file1.txt');
});
it('should support context parameters', async () => {
// Create a file with multiple lines
await fs.writeFile(
path.join(tempDir, 'context.txt'),
'line1\nline2\nline3 match\nline4\nline5\n',
);
const invocation = tool.build({
pattern: 'match',
context: 1,
});
const result = await invocation.execute(new AbortController().signal);
expect(result.llmContent).toContain('Found 1 match');
expect(result.llmContent).toContain('context.txt');
expect(result.llmContent).toContain('L2- line2');
expect(result.llmContent).toContain('L3: line3 match');
expect(result.llmContent).toContain('L4- line4');
});
});
+33 -873
View File
File diff suppressed because it is too large Load Diff
+4 -4
View File
@@ -1,6 +1,6 @@
{
"name": "@google/gemini-cli",
"version": "0.29.0-nightly.20260203.71f46f116",
"version": "0.30.0-nightly.20260210.a2174751d",
"engines": {
"node": ">=20.0.0"
},
@@ -14,7 +14,7 @@
"url": "git+https://github.com/google-gemini/gemini-cli.git"
},
"config": {
"sandboxImageUri": "us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:0.29.0-nightly.20260203.71f46f116"
"sandboxImageUri": "us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:0.30.0-nightly.20260210.a2174751d"
},
"scripts": {
"start": "cross-env NODE_ENV=development node scripts/start.js",
@@ -64,7 +64,7 @@
"pre-commit": "node scripts/pre-commit.js"
},
"overrides": {
"ink": "npm:@jrichman/ink@6.4.8",
"ink": "npm:@jrichman/ink@6.4.10",
"wrap-ansi": "9.0.2",
"cliui": {
"wrap-ansi": "7.0.0"
@@ -126,7 +126,7 @@
"yargs": "^17.7.2"
},
"dependencies": {
"ink": "npm:@jrichman/ink@6.4.8",
"ink": "npm:@jrichman/ink@6.4.10",
"latest-version": "^9.0.0",
"proper-lockfile": "^4.1.2",
"simple-git": "^3.28.0"
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "@google/gemini-cli-a2a-server",
"version": "0.29.0-nightly.20260203.71f46f116",
"version": "0.30.0-nightly.20260210.a2174751d",
"description": "Gemini CLI A2A Server",
"repository": {
"type": "git",
+86
View File
@@ -0,0 +1,86 @@
/**
* @license
* Copyright 2026 Google LLC
* SPDX-License-Identifier: Apache-2.0
*/
import { render, Box, Text } from 'ink';
import { Card } from '../src/ui/components/shared/Card.js';
import { ToolCallStatus, StreamingState } from '../src/ui/types.js';
import { StreamingContext } from '../src/ui/contexts/StreamingContext.js';
const CardDemo = () => {
return (
<StreamingContext.Provider value={StreamingState.Idle}>
<Box flexDirection="column" padding={1} gap={1}>
<Text bold>Card Component Demo</Text>
<Box flexDirection="column" gap={1}>
<Card
title="FindFiles"
suffix="**/*.ts"
status={ToolCallStatus.Success}
>
<Text>Found 37 files</Text>
</Card>
<Card
title="SearchText"
suffix="nano-banana"
status={ToolCallStatus.Canceled}
>
<Text>No matches found</Text>
</Card>
<Card
title="ReadFile"
suffix='{"file_path":"this_file_does_not_exist.txt"}'
status={ToolCallStatus.Error}
>
<Text>
{
'File not found:\n/users/root/src/gemini/this_file_does_not_exist.txt'
}
</Text>
</Card>
<Card
title="Shell"
suffix="npm test -w @google/gemini-cli"
status={ToolCallStatus.Confirming}
>
<Text>Apply this change?</Text>
</Card>
<Card
title="Executing"
suffix="Lorem ipsum dolor sit amet"
status={ToolCallStatus.Executing}
>
<Text>
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut
enim ad minim veniam, quis nostrud exercitation ullamco laboris
nisi ut aliquip ex ea commodo consequat.
</Text>
</Card>
<Card
title="Executing"
suffix="Lorem ipsum dolor sit amet"
status={ToolCallStatus.Executing}
width={60}
>
<Text>
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut
enim ad minim veniam, quis nostrud exercitation ullamco laboris
nisi ut aliquip ex ea commodo consequat.
</Text>
</Card>
</Box>
<Box marginTop={1}>
<Text color="dim">Press Ctrl+C to exit</Text>
</Box>
</Box>
</StreamingContext.Provider>
);
};
render(<CardDemo />);
+7 -15
View File
@@ -1,6 +1,6 @@
{
"name": "@google/gemini-cli",
"version": "0.29.0-nightly.20260203.71f46f116",
"version": "0.30.0-nightly.20260210.a2174751d",
"description": "Gemini CLI",
"license": "Apache-2.0",
"repository": {
@@ -26,7 +26,7 @@
"dist"
],
"config": {
"sandboxImageUri": "us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:0.29.0-nightly.20260203.71f46f116"
"sandboxImageUri": "us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:0.30.0-nightly.20260210.a2174751d"
},
"dependencies": {
"@agentclientprotocol/sdk": "^0.12.0",
@@ -34,10 +34,11 @@
"@google/genai": "1.30.0",
"@iarna/toml": "^2.2.5",
"@modelcontextprotocol/sdk": "^1.23.0",
"@types/update-notifier": "^6.0.8",
"ansi-escapes": "^7.3.0",
"ansi-regex": "^6.2.2",
"chalk": "^4.1.2",
"cli-spinners": "^2.9.2",
"clipboardy": "^5.0.0",
"color-convert": "^2.0.1",
"command-exists": "^1.2.9",
"comment-json": "^4.2.5",
"diff": "^8.0.3",
@@ -46,7 +47,7 @@
"fzf": "^0.5.2",
"glob": "^12.0.0",
"highlight.js": "^11.11.1",
"ink": "npm:@jrichman/ink@6.4.8",
"ink": "npm:@jrichman/ink@6.4.10",
"ink-gradient": "^3.0.0",
"ink-spinner": "^5.0.0",
"latest-version": "^9.0.0",
@@ -56,7 +57,6 @@
"prompts": "^2.4.2",
"proper-lockfile": "^4.1.2",
"react": "^19.2.0",
"read-package-up": "^11.0.0",
"shell-quote": "^1.8.3",
"simple-git": "^3.28.0",
"string-width": "^8.1.0",
@@ -65,29 +65,21 @@
"tar": "^7.5.2",
"tinygradient": "^1.1.5",
"undici": "^7.10.0",
"wrap-ansi": "9.0.2",
"ws": "^8.16.0",
"yargs": "^17.7.2",
"zod": "^3.23.8"
},
"devDependencies": {
"@babel/runtime": "^7.27.6",
"@google/gemini-cli-test-utils": "file:../test-utils",
"@types/archiver": "^6.0.3",
"@types/command-exists": "^1.2.3",
"@types/dotenv": "^6.1.1",
"@types/hast": "^3.0.4",
"@types/node": "^20.11.24",
"@types/react": "^19.2.0",
"@types/react-dom": "^19.2.0",
"@types/semver": "^7.7.0",
"@types/shell-quote": "^1.7.5",
"@types/tar": "^6.1.13",
"@types/ws": "^8.5.10",
"@types/yargs": "^17.0.32",
"archiver": "^7.0.1",
"ink-testing-library": "^4.0.0",
"pretty-format": "^30.0.2",
"react-dom": "^19.2.0",
"typescript": "^5.3.3",
"vitest": "^3.1.1"
},
@@ -281,7 +281,10 @@ describe('InputPrompt', () => {
navigateDown: vi.fn(),
handleSubmit: vi.fn(),
};
mockedUseInputHistory.mockReturnValue(mockInputHistory);
mockedUseInputHistory.mockImplementation(({ onSubmit }) => {
mockInputHistory.handleSubmit = vi.fn((val) => onSubmit(val));
return mockInputHistory;
});
mockReverseSearchCompletion = {
suggestions: [],
@@ -4093,7 +4096,7 @@ describe('InputPrompt', () => {
beforeEach(() => {
props.userMessages = ['first message', 'second message'];
// Mock useInputHistory to actually call onChange
mockedUseInputHistory.mockImplementation(({ onChange }) => ({
mockedUseInputHistory.mockImplementation(({ onChange, onSubmit }) => ({
navigateUp: () => {
onChange('second message', 'start');
return true;
@@ -4102,7 +4105,7 @@ describe('InputPrompt', () => {
onChange('first message', 'end');
return true;
},
handleSubmit: vi.fn(),
handleSubmit: vi.fn((val) => onSubmit(val)),
}));
});
+21 -27
View File
@@ -337,31 +337,6 @@ export const InputPrompt: React.FC<InputPromptProps> = ({
],
);
const handleSubmit = useCallback(
(submittedValue: string) => {
const trimmedMessage = submittedValue.trim();
const isSlash = isSlashCommand(trimmedMessage);
const isShell = shellModeActive;
if (
(isSlash || isShell) &&
streamingState === StreamingState.Responding
) {
setQueueErrorMessage(
`${isShell ? 'Shell' : 'Slash'} commands cannot be queued`,
);
return;
}
handleSubmitAndClear(trimmedMessage);
},
[
handleSubmitAndClear,
shellModeActive,
streamingState,
setQueueErrorMessage,
],
);
const customSetTextAndResetCompletionSignal = useCallback(
(newText: string, cursorPosition?: 'start' | 'end' | number) => {
buffer.setText(newText, cursorPosition);
@@ -381,6 +356,26 @@ export const InputPrompt: React.FC<InputPromptProps> = ({
onChange: customSetTextAndResetCompletionSignal,
});
const handleSubmit = useCallback(
(submittedValue: string) => {
const trimmedMessage = submittedValue.trim();
const isSlash = isSlashCommand(trimmedMessage);
const isShell = shellModeActive;
if (
(isSlash || isShell) &&
streamingState === StreamingState.Responding
) {
setQueueErrorMessage(
`${isShell ? 'Shell' : 'Slash'} commands cannot be queued`,
);
return;
}
inputHistory.handleSubmit(trimmedMessage);
},
[inputHistory, shellModeActive, streamingState, setQueueErrorMessage],
);
// Effect to reset completion if history navigation just occurred and set the text
useEffect(() => {
if (suppressCompletion) {
@@ -858,7 +853,7 @@ export const InputPrompt: React.FC<InputPromptProps> = ({
showSuggestions && activeSuggestionIndex > -1
? suggestions[activeSuggestionIndex].value
: buffer.text;
handleSubmitAndClear(textToSubmit);
handleSubmit(textToSubmit);
resetState();
setActive(false);
return true;
@@ -1155,7 +1150,6 @@ export const InputPrompt: React.FC<InputPromptProps> = ({
setShellModeActive,
onClearScreen,
inputHistory,
handleSubmitAndClear,
handleSubmit,
shellHistory,
reverseSearchCompletion,
@@ -0,0 +1,100 @@
/**
* @license
* Copyright 2026 Google LLC
* SPDX-License-Identifier: Apache-2.0
*/
import { renderWithProviders } from '../../../test-utils/render.js';
import { Card } from './Card.js';
import { Text } from 'ink';
import { describe, it, expect, afterEach, vi } from 'vitest';
import { ToolCallStatus, StreamingState } from '../../types.js';
describe('Card', () => {
afterEach(() => {
vi.restoreAllMocks();
});
it.each([
{
status: ToolCallStatus.Pending,
title: 'Gemini CLI update available',
suffix: '0.26.0 → 0.27.0',
showStatusIndicator: true,
body: 'Installed via Homebrew. Please update with "brew upgrade gemini-cli".',
},
{
status: ToolCallStatus.Canceled,
title: 'Delegate to agent',
suffix: "Delegating to agent 'cli_help'",
showStatusIndicator: true,
body: '🤖💭 Execution limit reached (ERROR_NO_COMPLETE_TASK_CALL). Attempting one final recovery turn with a grace period.',
},
{
status: ToolCallStatus.Error,
title: 'Error',
suffix: '429 You exceeded your current quota',
showStatusIndicator: true,
body: 'Go to https://aistudio.google.com/apikey to upgrade your quota tier, or submit a quota increase request in https://ai.google.dev/gemini-api/docs/rate-limits',
},
{
status: ToolCallStatus.Confirming,
title: 'Shell',
suffix: 'node -v && which gemini',
showStatusIndicator: true,
body: "ls /usr/local/bin | grep 'xattr'",
},
{
status: ToolCallStatus.Success,
title: 'ReadFolder',
suffix: '/usr/local/bin',
showStatusIndicator: true,
body: 'Listed 39 item(s).',
},
{
status: ToolCallStatus.Executing,
title: 'Searching',
suffix: 'ripgrep',
showStatusIndicator: true,
body: 'Searching for pattern in directory...',
},
{
status: ToolCallStatus.Pending,
title: 'No Status Indicator',
suffix: 'Hidden',
showStatusIndicator: false,
body: 'The status indicator should be hidden.',
},
{
status: ToolCallStatus.Pending,
title: 'Fixed Width Card',
suffix: undefined,
showStatusIndicator: true,
width: 40,
body: 'This card has a fixed width of 40 characters.',
},
] as const)(
"renders '$title' card with status=$status and showStatusIndicator=$showStatusIndicator",
({ status, title, suffix, showStatusIndicator, body, width }) => {
const { lastFrame } = renderWithProviders(
<Card
status={status}
title={title}
suffix={suffix}
showStatusIndicator={showStatusIndicator}
width={width}
>
<Text>{body}</Text>
</Card>,
{
uiState: {
streamingState: StreamingState.Responding,
},
},
);
const output = lastFrame();
expect(output).toMatchSnapshot();
},
);
});
@@ -0,0 +1,126 @@
/**
* @license
* Copyright 2026 Google LLC
* SPDX-License-Identifier: Apache-2.0
*/
import type React from 'react';
import { Box, Text } from 'ink';
import { theme } from '../../semantic-colors.js';
import { ToolStatusIndicator } from '../messages/ToolShared.js';
import { ToolCallStatus } from '../../types.js';
import { checkExhaustive } from '@google/gemini-cli-core';
/**
* Props for the Card component.
*/
export interface CardProps {
/** The main title of the card. */
title: string;
/** Optional text to display after the title (e.g., version, status). */
suffix?: string;
/** Optional indicator to display before the title. */
showStatusIndicator?: boolean;
/** The content to be displayed inside the card. */
children?: React.ReactNode;
/** The styling and intent of the card. */
status?: ToolCallStatus;
/** The width of the card. Defaults to 100%. */
width?: string | number;
}
export const Card: React.FC<CardProps> = ({
status = ToolCallStatus.Pending,
title,
showStatusIndicator = true,
suffix,
children,
width = '100%',
}) => {
const getColors = () => {
switch (status) {
case ToolCallStatus.Pending:
return { border: theme.border.default, text: theme.text.accent };
case ToolCallStatus.Confirming:
return { border: theme.border.focused, text: theme.text.link };
case ToolCallStatus.Error:
return { border: theme.status.error, text: theme.status.error };
case ToolCallStatus.Success:
return { border: theme.border.default, text: theme.status.success };
case ToolCallStatus.Canceled:
return { border: theme.status.warning, text: theme.status.warning };
case ToolCallStatus.Executing:
return { border: theme.border.default, text: theme.text.accent };
default:
checkExhaustive(status);
return { border: theme.border.default, text: theme.text.primary };
}
};
const colors = getColors();
return (
<Box flexDirection="column" width={width}>
<Box width="100%" flexDirection="row">
{/* Top border section */}
<Box
borderStyle="round"
borderBottom={false}
borderRight={false}
paddingLeft={0}
borderColor={colors.border}
/>
{/* Label */}
<Box flexGrow={1}>
<Box
paddingX={1}
flexDirection="row"
gap={1}
justifyContent="flex-start"
>
<Box marginRight={showStatusIndicator ? -2 : -1}>
{showStatusIndicator && (
<ToolStatusIndicator status={status} name={title} />
)}
</Box>
<Text bold color={colors.text}>
{title}
</Text>
{suffix && (
<Text color={colors.text} dimColor wrap="truncate-end">
{suffix}
</Text>
)}
</Box>
{/* Top border after text */}
<Box
borderStyle="single"
flexGrow={1}
borderBottom={false}
borderLeft={false}
borderRight={false}
borderColor={colors.border}
/>
</Box>
{/* Right border */}
<Box
borderStyle="round"
borderBottom={false}
borderLeft={false}
paddingRight={1}
borderColor={colors.border}
></Box>
</Box>
<Box
borderStyle="round"
borderTop={false}
flexDirection="column"
paddingX={1}
paddingY={0}
borderColor={colors.border}
>
{children}
</Box>
</Box>
);
};
@@ -0,0 +1,51 @@
// Vitest Snapshot v1, https://vitest.dev/guide/snapshot.html
exports[`Card > renders ''Delegate to agent'' card with status='Canceled' and showStatusIndicator=true 1`] = `
"╭ - Delegate to agent Delegating to agent 'cli_help' ──────────────────────────────────────────────────────────────────╮
│ 🤖💭 Execution limit reached (ERROR_NO_COMPLETE_TASK_CALL). Attempting one final recovery turn with a grace period. │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯"
`;
exports[`Card > renders ''Error'' card with status='Error' and showStatusIndicator=true 1`] = `
"╭ x Error 429 You exceeded your current quota ─────────────────────────────────────────────────────────────────────────╮
│ Go to https://aistudio.google.com/apikey to upgrade your quota tier, or submit a quota increase request in │
│ https://ai.google.dev/gemini-api/docs/rate-limits │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯"
`;
exports[`Card > renders ''Fixed Width Card'' card with status='Pending' and showStatusIndicator=true 1`] = `
"╭ o Fixed Width Card ──────────────────╮
│ This card has a fixed width of 40 │
│ characters. │
╰──────────────────────────────────────╯"
`;
exports[`Card > renders ''Gemini CLI update available'' card with status='Pending' and showStatusIndicator=true 1`] = `
"╭ o Gemini CLI update available 0.26.0 → 0.27.0 ───────────────────────────────────────────────────────────────────────╮
│ Installed via Homebrew. Please update with "brew upgrade gemini-cli". │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯"
`;
exports[`Card > renders ''No Status Indicator'' card with status='Pending' and showStatusIndicator=false 1`] = `
"╭ No Status Indicator Hidden ──────────────────────────────────────────────────────────────────────────────────────────╮
│ The status indicator should be hidden. │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯"
`;
exports[`Card > renders ''ReadFolder'' card with status='Success' and showStatusIndicator=true 1`] = `
"╭ ✓ ReadFolder /usr/local/bin ─────────────────────────────────────────────────────────────────────────────────────────╮
│ Listed 39 item(s). │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯"
`;
exports[`Card > renders ''Searching'' card with status='Executing' and showStatusIndicator=true 1`] = `
"╭ ⊶ Searching ripgrep ─────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Searching for pattern in directory... │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯"
`;
exports[`Card > renders ''Shell'' card with status='Confirming' and showStatusIndicator=true 1`] = `
"╭ ? Shell node -v && which gemini ─────────────────────────────────────────────────────────────────────────────────────╮
│ ls /usr/local/bin | grep 'xattr' │
╰──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯"
`;
+2
View File
@@ -24,6 +24,8 @@ export const TOOL_STATUS = {
CONFIRMING: '?',
CANCELED: '-',
ERROR: 'x',
WARNING: '⚠',
INFORMATION: '',
} as const;
// Maximum number of MCP resources to display per server before truncating
@@ -61,4 +61,257 @@ describe('TableRenderer', () => {
expect(output).toContain('Data 3.4');
expect(output).toMatchSnapshot();
});
it('wraps long cell content correctly', () => {
const headers = ['Col 1', 'Col 2', 'Col 3'];
const rows = [
[
'Short',
'This is a very long cell content that should wrap to multiple lines',
'Short',
],
];
const terminalWidth = 50;
const { lastFrame } = renderWithProviders(
<TableRenderer
headers={headers}
rows={rows}
terminalWidth={terminalWidth}
/>,
);
const output = lastFrame();
expect(output).toContain('This is a very');
expect(output).toContain('long cell');
expect(output).toMatchSnapshot();
});
it('wraps all long columns correctly', () => {
const headers = ['Col 1', 'Col 2', 'Col 3'];
const rows = [
[
'This is a very long text that needs wrapping in column 1',
'This is also a very long text that needs wrapping in column 2',
'And this is the third long text that needs wrapping in column 3',
],
];
const terminalWidth = 60;
const { lastFrame } = renderWithProviders(
<TableRenderer
headers={headers}
rows={rows}
terminalWidth={terminalWidth}
/>,
);
const output = lastFrame();
expect(output).toContain('wrapping in');
expect(output).toMatchSnapshot();
});
it('wraps mixed long and short columns correctly', () => {
const headers = ['Short', 'Long', 'Medium'];
const rows = [
[
'Tiny',
'This is a very long text that definitely needs to wrap to the next line',
'Not so long',
],
];
const terminalWidth = 50;
const { lastFrame } = renderWithProviders(
<TableRenderer
headers={headers}
rows={rows}
terminalWidth={terminalWidth}
/>,
);
const output = lastFrame();
expect(output).toContain('Tiny');
expect(output).toContain('definitely needs');
expect(output).toMatchSnapshot();
});
// The snapshot looks weird but checked on VS Code terminal and it looks fine
it('wraps columns with punctuation correctly', () => {
const headers = ['Punctuation 1', 'Punctuation 2', 'Punctuation 3'];
const rows = [
[
'Start. Stop. Comma, separated. Exclamation! Question? hyphen-ated',
'Semi; colon: Pipe| Slash/ Backslash\\',
'At@ Hash# Dollar$ Percent% Caret^ Ampersand& Asterisk*',
],
];
const terminalWidth = 60;
const { lastFrame } = renderWithProviders(
<TableRenderer
headers={headers}
rows={rows}
terminalWidth={terminalWidth}
/>,
);
const output = lastFrame();
expect(output).toContain('Start. Stop.');
expect(output).toMatchSnapshot();
});
it('strips bold markers from headers and renders them correctly', () => {
const headers = ['**Bold Header**', 'Normal Header', '**Another Bold**'];
const rows = [['Data 1', 'Data 2', 'Data 3']];
const terminalWidth = 50;
const { lastFrame } = renderWithProviders(
<TableRenderer
headers={headers}
rows={rows}
terminalWidth={terminalWidth}
/>,
);
const output = lastFrame();
// The output should NOT contain the literal '**'
expect(output).not.toContain('**Bold Header**');
expect(output).toContain('Bold Header');
expect(output).toMatchSnapshot();
});
it('handles wrapped bold headers without showing markers', () => {
const headers = [
'**Very Long Bold Header That Will Wrap**',
'Short',
'**Another Long Header**',
];
const rows = [['Data 1', 'Data 2', 'Data 3']];
const terminalWidth = 40;
const { lastFrame } = renderWithProviders(
<TableRenderer
headers={headers}
rows={rows}
terminalWidth={terminalWidth}
/>,
);
const output = lastFrame();
// Markers should be gone
expect(output).not.toContain('**');
expect(output).toContain('Very Long');
expect(output).toMatchSnapshot();
});
it('renders a complex table with mixed content lengths correctly', () => {
const headers = [
'Comprehensive Architectural Specification for the Distributed Infrastructure Layer',
'Implementation Details for the High-Throughput Asynchronous Message Processing Pipeline with Extended Scalability Features and Redundancy Protocols',
'Longitudinal Performance Analysis Across Multi-Regional Cloud Deployment Clusters',
'Strategic Security Framework for Mitigating Sophisticated Cross-Site Scripting Vulnerabilities',
'Key',
'Status',
'Version',
'Owner',
];
const rows = [
[
'The primary architecture utilizes a decoupled microservices approach, leveraging container orchestration for scalability and fault tolerance in high-load scenarios.\n\nThis layer provides the fundamental building blocks for service discovery, load balancing, and inter-service communication via highly efficient protocol buffers.\n\nAdvanced telemetry and logging integrations allow for real-time monitoring of system health and rapid identification of bottlenecks within the service mesh.',
'Each message is processed through a series of specialized workers that handle data transformation, validation, and persistent storage using a persistent queue.\n\nThe pipeline features built-in retry mechanisms with exponential backoff to ensure message delivery integrity even during transient network or service failures.\n\nHorizontal autoscaling is triggered automatically based on the depth of the processing queue, ensuring consistent performance during unexpected traffic spikes.',
'Historical data indicates a significant reduction in tail latency when utilizing edge computing nodes closer to the geographic location of the end-user base.\n\nMonitoring tools have captured a steady increase in throughput efficiency since the introduction of the vectorized query engine in the primary data warehouse.\n\nResource utilization metrics demonstrate that the transition to serverless compute for intermittent tasks has resulted in a thirty percent cost optimization.',
'A multi-layered defense strategy incorporates content security policies, input sanitization libraries, and regular automated penetration testing routines.\n\nDevelopers are required to undergo mandatory security training focusing on the OWASP Top Ten to ensure that security is integrated into the initial design phase.\n\nThe implementation of a robust Identity and Access Management system ensures that the principle of least privilege is strictly enforced across all environments.',
'INF',
'Active',
'v2.4',
'J. Doe',
],
];
const terminalWidth = 160;
const { lastFrame } = renderWithProviders(
<TableRenderer
headers={headers}
rows={rows}
terminalWidth={terminalWidth}
/>,
{ width: terminalWidth },
);
const output = lastFrame();
expect(output).toContain('Comprehensive Architectural');
expect(output).toContain('protocol buffers');
expect(output).toContain('exponential backoff');
expect(output).toContain('vectorized query engine');
expect(output).toContain('OWASP Top Ten');
expect(output).toContain('INF');
expect(output).toContain('Active');
expect(output).toContain('v2.4');
// "J. Doe" might wrap due to column width constraints
expect(output).toContain('J.');
expect(output).toContain('Doe');
expect(output).toMatchSnapshot();
});
it.each([
{
name: 'handles non-ASCII characters (emojis and Asian scripts) correctly',
headers: ['Emoji 😃', 'Asian 汉字', 'Mixed 🚀 Text'],
rows: [
['Start 🌟 End', '你好世界', 'Rocket 🚀 Man'],
['Thumbs 👍 Up', 'こんにちは', 'Fire 🔥'],
],
terminalWidth: 60,
expected: ['Emoji 😃', 'Asian 汉字', '你好世界'],
},
{
name: 'renders a table with only emojis and text correctly',
headers: ['Happy 😀', 'Rocket 🚀', 'Heart ❤️'],
rows: [
['Smile 😃', 'Fire 🔥', 'Love 💖'],
['Cool 😎', 'Star ⭐', 'Blue 💙'],
],
terminalWidth: 60,
expected: ['Happy 😀', 'Smile 😃', 'Fire 🔥'],
},
{
name: 'renders a table with only Asian characters and text correctly',
headers: ['Chinese 中文', 'Japanese 日本語', 'Korean 한국어'],
rows: [
['你好', 'こんにちは', '안녕하세요'],
['世界', '世界', '세계'],
],
terminalWidth: 60,
expected: ['Chinese 中文', '你好', 'こんにちは'],
},
{
name: 'renders a table with mixed emojis, Asian characters, and text correctly',
headers: ['Mixed 😃 中文', 'Complex 🚀 日本語', 'Text 📝 한국어'],
rows: [
['你好 😃', 'こんにちは 🚀', '안녕하세요 📝'],
['World 🌍', 'Code 💻', 'Pizza 🍕'],
],
terminalWidth: 80,
expected: ['Mixed 😃 中文', '你好 😃', 'こんにちは 🚀'],
},
])('$name', ({ headers, rows, terminalWidth, expected }) => {
const { lastFrame } = renderWithProviders(
<TableRenderer
headers={headers}
rows={rows}
terminalWidth={terminalWidth}
/>,
{ width: terminalWidth },
);
const output = lastFrame();
expected.forEach((text) => {
expect(output).toContain(text);
});
expect(output).toMatchSnapshot();
});
});
+190 -76
View File
@@ -4,10 +4,19 @@
* SPDX-License-Identifier: Apache-2.0
*/
import React from 'react';
import React, { useMemo } from 'react';
import { Text, Box } from 'ink';
import {
type StyledChar,
toStyledCharacters,
styledCharsToString,
styledCharsWidth,
wordBreakStyledChars,
wrapStyledChars,
widestLineFromStyledChars,
} from 'ink';
import { theme } from '../semantic-colors.js';
import { RenderInline, getPlainTextLength } from './InlineMarkdownRenderer.js';
import { RenderInline } from './InlineMarkdownRenderer.js';
interface TableRendererProps {
headers: string[];
@@ -15,6 +24,26 @@ interface TableRendererProps {
terminalWidth: number;
}
const MIN_COLUMN_WIDTH = 5;
const COLUMN_PADDING = 2;
const TABLE_MARGIN = 2;
const calculateWidths = (text: string) => {
const styledChars = toStyledCharacters(text);
const contentWidth = styledCharsWidth(styledChars);
const words: StyledChar[][] = wordBreakStyledChars(styledChars);
const maxWordWidth = widestLineFromStyledChars(words);
return { contentWidth, maxWordWidth };
};
// Used to reduce redundant parsing and cache the widths for each line
interface ProcessedLine {
text: string;
width: number;
}
/**
* Custom table renderer for markdown tables
* We implement our own instead of using ink-table due to module compatibility issues
@@ -24,89 +53,146 @@ export const TableRenderer: React.FC<TableRendererProps> = ({
rows,
terminalWidth,
}) => {
// Calculate column widths using actual display width after markdown processing
const columnWidths = headers.map((header, index) => {
const headerWidth = getPlainTextLength(header);
const maxRowWidth = Math.max(
...rows.map((row) => getPlainTextLength(row[index] || '')),
// Clean headers: remove bold markers since we already render headers as bold
// and having them can break wrapping when the markers are split across lines.
const cleanedHeaders = useMemo(
() => headers.map((header) => header.replace(/\*\*(.*?)\*\*/g, '$1')),
[headers],
);
const { wrappedHeaders, wrappedRows, adjustedWidths } = useMemo(() => {
// --- Define Constraints per Column ---
const constraints = cleanedHeaders.map((header, colIndex) => {
let { contentWidth: maxContentWidth, maxWordWidth } =
calculateWidths(header);
rows.forEach((row) => {
const cell = row[colIndex] || '';
const { contentWidth: cellWidth, maxWordWidth: cellWordWidth } =
calculateWidths(cell);
maxContentWidth = Math.max(maxContentWidth, cellWidth);
maxWordWidth = Math.max(maxWordWidth, cellWordWidth);
});
const minWidth = maxWordWidth;
const maxWidth = Math.max(minWidth, maxContentWidth);
return { minWidth, maxWidth };
});
// --- Calculate Available Space ---
// Fixed overhead: borders (n+1) + padding (2n)
const fixedOverhead =
cleanedHeaders.length + 1 + cleanedHeaders.length * COLUMN_PADDING;
const availableWidth = Math.max(
0,
terminalWidth - fixedOverhead - TABLE_MARGIN,
);
return Math.max(headerWidth, maxRowWidth) + 2; // Add padding
});
// Ensure table fits within terminal width
// We calculate scale based on content width vs available width (terminal - borders)
// First, extract content widths by removing the 2-char padding.
const contentWidths = columnWidths.map((width) => Math.max(0, width - 2));
const totalContentWidth = contentWidths.reduce(
(sum, width) => sum + width,
0,
);
// --- Allocation Algorithm ---
const totalMinWidth = constraints.reduce((sum, c) => sum + c.minWidth, 0);
let finalContentWidths: number[];
// Fixed overhead includes padding (2 per column) and separators (1 per column + 1 final).
const fixedOverhead = headers.length * 2 + (headers.length + 1);
if (totalMinWidth > availableWidth) {
// We must scale all the columns except the ones that are very short(<=5 characters)
const shortColumns = constraints.filter(
(c) => c.maxWidth <= MIN_COLUMN_WIDTH,
);
const totalShortColumnWidth = shortColumns.reduce(
(sum, c) => sum + c.minWidth,
0,
);
// Subtract 1 from available width to avoid edge-case wrapping on some terminals
const availableWidth = Math.max(0, terminalWidth - fixedOverhead - 1);
const finalTotalShortColumnWidth =
totalShortColumnWidth >= availableWidth ? 0 : totalShortColumnWidth;
const scaleFactor =
totalContentWidth > availableWidth ? availableWidth / totalContentWidth : 1;
const adjustedWidths = contentWidths.map(
(width) => Math.floor(width * scaleFactor) + 2,
);
// Helper function to render a cell with proper width
const renderCell = (
content: string,
width: number,
isHeader = false,
): React.ReactNode => {
const contentWidth = Math.max(0, width - 2);
const displayWidth = getPlainTextLength(content);
let cellContent = content;
if (displayWidth > contentWidth) {
if (contentWidth <= 3) {
// Just truncate by character count
cellContent = content.substring(
0,
Math.min(content.length, contentWidth),
);
} else {
// Truncate preserving markdown formatting using binary search
let left = 0;
let right = content.length;
let bestTruncated = content;
// Binary search to find the optimal truncation point
while (left <= right) {
const mid = Math.floor((left + right) / 2);
const candidate = content.substring(0, mid);
const candidateWidth = getPlainTextLength(candidate);
if (candidateWidth <= contentWidth - 1) {
bestTruncated = candidate;
left = mid + 1;
} else {
right = mid - 1;
}
const scale =
(availableWidth - finalTotalShortColumnWidth) /
(totalMinWidth - finalTotalShortColumnWidth);
finalContentWidths = constraints.map((c) => {
if (c.maxWidth <= MIN_COLUMN_WIDTH && finalTotalShortColumnWidth > 0) {
return c.minWidth;
}
return Math.floor(c.minWidth * scale);
});
} else {
const surplus = availableWidth - totalMinWidth;
const totalGrowthNeed = constraints.reduce(
(sum, c) => sum + (c.maxWidth - c.minWidth),
0,
);
cellContent = bestTruncated + '…';
if (totalGrowthNeed === 0) {
finalContentWidths = constraints.map((c) => c.minWidth);
} else {
finalContentWidths = constraints.map((c) => {
const growthNeed = c.maxWidth - c.minWidth;
const share = growthNeed / totalGrowthNeed;
const extra = Math.floor(surplus * share);
return Math.min(c.maxWidth, c.minWidth + extra);
});
}
}
// Calculate exact padding needed
const actualDisplayWidth = getPlainTextLength(cellContent);
const paddingNeeded = Math.max(0, contentWidth - actualDisplayWidth);
// --- Pre-wrap and Optimize Widths ---
const actualColumnWidths = new Array(cleanedHeaders.length).fill(0);
const wrapAndProcessRow = (row: string[]) => {
const rowResult: ProcessedLine[][] = [];
row.forEach((cell, colIndex) => {
const allocatedWidth = finalContentWidths[colIndex];
const contentWidth = Math.max(1, allocatedWidth);
const contentStyledChars = toStyledCharacters(cell);
const wrappedStyledLines = wrapStyledChars(
contentStyledChars,
contentWidth,
);
const maxLineWidth = widestLineFromStyledChars(wrappedStyledLines);
actualColumnWidths[colIndex] = Math.max(
actualColumnWidths[colIndex],
maxLineWidth,
);
const lines = wrappedStyledLines.map((line) => ({
text: styledCharsToString(line),
width: styledCharsWidth(line),
}));
rowResult.push(lines);
});
return rowResult;
};
const wrappedHeaders = wrapAndProcessRow(cleanedHeaders);
const wrappedRows = rows.map((row) => wrapAndProcessRow(row));
// Use the TIGHTEST widths that fit the wrapped content + padding
const adjustedWidths = actualColumnWidths.map((w) => w + COLUMN_PADDING);
return { wrappedHeaders, wrappedRows, adjustedWidths };
}, [cleanedHeaders, rows, terminalWidth]);
// Helper function to render a cell with proper width
const renderCell = (
content: ProcessedLine,
width: number,
isHeader = false,
): React.ReactNode => {
const contentWidth = Math.max(0, width - COLUMN_PADDING);
// Use pre-calculated width to avoid re-parsing
const displayWidth = content.width;
const paddingNeeded = Math.max(0, contentWidth - displayWidth);
return (
<Text>
{isHeader ? (
<Text bold color={theme.text.link}>
<RenderInline text={cellContent} />
<RenderInline text={content.text} />
</Text>
) : (
<RenderInline text={cellContent} />
<RenderInline text={content.text} />
)}
{' '.repeat(paddingNeeded)}
</Text>
@@ -128,11 +214,14 @@ export const TableRenderer: React.FC<TableRendererProps> = ({
return <Text color={theme.border.default}>{border}</Text>;
};
// Helper function to render a table row
const renderRow = (cells: string[], isHeader = false): React.ReactNode => {
// Helper function to render a single visual line of a row
const renderVisualRow = (
cells: ProcessedLine[],
isHeader = false,
): React.ReactNode => {
const renderedCells = cells.map((cell, index) => {
const width = adjustedWidths[index] || 0;
return renderCell(cell || '', width, isHeader);
return renderCell(cell, width, isHeader);
});
return (
@@ -151,21 +240,46 @@ export const TableRenderer: React.FC<TableRendererProps> = ({
);
};
// Handles the wrapping logic for a logical data row
const renderDataRow = (
wrappedCells: ProcessedLine[][],
rowIndex?: number,
isHeader = false,
): React.ReactNode => {
const key = isHeader ? 'header' : `${rowIndex}`;
const maxHeight = Math.max(...wrappedCells.map((lines) => lines.length), 1);
const visualRows: React.ReactNode[] = [];
for (let i = 0; i < maxHeight; i++) {
const visualRowCells = wrappedCells.map(
(lines) => lines[i] || { text: '', width: 0 },
);
visualRows.push(
<React.Fragment key={`${key}-${i}`}>
{renderVisualRow(visualRowCells, isHeader)}
</React.Fragment>,
);
}
return <React.Fragment key={rowIndex}>{visualRows}</React.Fragment>;
};
return (
<Box flexDirection="column" marginY={1}>
{/* Top border */}
{renderBorder('top')}
{/* Header row */}
{renderRow(headers, true)}
{/*
Header row
Keep the rowIndex as -1 to differentiate from data rows
*/}
{renderDataRow(wrappedHeaders, -1, true)}
{/* Middle border */}
{renderBorder('middle')}
{/* Data rows */}
{rows.map((row, index) => (
<React.Fragment key={index}>{renderRow(row)}</React.Fragment>
))}
{wrappedRows.map((row, index) => renderDataRow(row, index))}
{/* Bottom border */}
{renderBorder('bottom')}
@@ -1,5 +1,63 @@
// Vitest Snapshot v1, https://vitest.dev/guide/snapshot.html
exports[`TableRenderer > 'handles non-ASCII characters (emojis …' 1`] = `
"
┌──────────────┬────────────┬───────────────┐
│ Emoji 😃 │ Asian 汉字 │ Mixed 🚀 Text │
├──────────────┼────────────┼───────────────┤
│ Start 🌟 End │ 你好世界 │ Rocket 🚀 Man │
│ Thumbs 👍 Up │ こんにちは │ Fire 🔥 │
└──────────────┴────────────┴───────────────┘
"
`;
exports[`TableRenderer > 'renders a table with mixed emojis, As…' 1`] = `
"
┌───────────────┬───────────────────┬────────────────┐
│ Mixed 😃 中文 │ Complex 🚀 日本語 │ Text 📝 한국어 │
├───────────────┼───────────────────┼────────────────┤
│ 你好 😃 │ こんにちは 🚀 │ 안녕하세요 📝 │
│ World 🌍 │ Code 💻 │ Pizza 🍕 │
└───────────────┴───────────────────┴────────────────┘
"
`;
exports[`TableRenderer > 'renders a table with only Asian chara…' 1`] = `
"
┌──────────────┬─────────────────┬───────────────┐
│ Chinese 中文 │ Japanese 日本語 │ Korean 한국어 │
├──────────────┼─────────────────┼───────────────┤
│ 你好 │ こんにちは │ 안녕하세요 │
│ 世界 │ 世界 │ 세계 │
└──────────────┴─────────────────┴───────────────┘
"
`;
exports[`TableRenderer > 'renders a table with only emojis and …' 1`] = `
"
┌──────────┬───────────┬──────────┐
│ Happy 😀 │ Rocket 🚀 │ Heart ❤️ │
├──────────┼───────────┼──────────┤
│ Smile 😃 │ Fire 🔥 │ Love 💖 │
│ Cool 😎 │ Star ⭐ │ Blue 💙 │
└──────────┴───────────┴──────────┘
"
`;
exports[`TableRenderer > handles wrapped bold headers without showing markers 1`] = `
"
┌─────────────┬───────┬─────────┐
│ Very Long │ Short │ Another │
│ Bold Header │ │ Long │
│ That Will │ │ Header │
│ Wrap │ │ │
├─────────────┼───────┼─────────┤
│ Data 1 │ Data │ Data 3 │
│ │ 2 │ │
└─────────────┴───────┴─────────┘
"
`;
exports[`TableRenderer > renders a 3x3 table correctly 1`] = `
"
┌──────────────┬──────────────┬──────────────┐
@@ -12,14 +70,117 @@ exports[`TableRenderer > renders a 3x3 table correctly 1`] = `
"
`;
exports[`TableRenderer > renders a table with long headers and 4 columns correctly 1`] = `
exports[`TableRenderer > renders a complex table with mixed content lengths correctly 1`] = `
"
┌───────────────────────────────────────────────────────┬──────────────────┐
Very Long Colum… │ Very Long Colum… │ Very Long Column… │ Very Long Colum…
├──────────────────┼──────────────────┼───────────────────┼──────────────────┤
│ Data 1.1 │ Data 1.2 │ Data 1.3Data 1.4
Data 2.1 │ Data 2.2 │ Data 2.3 │ Data 2.4
Data 3.1 │ Data 3.2 │ Data 3.3 │ Data 3.4
└──────────────────┴──────────────────┴───────────────────┴──────────────────┘
┌─────────────────────────────┬──────────────────────────────┬─────────────────────────────┬──────────────────────────────┬─────┬────────┬─────────┬───────┐
Comprehensive Architectural │ Implementation Details for │ Longitudinal Performance │ Strategic Security Framework │ Key │ Status │ Version │ Owner
│ Specification for the │ the High-Throughput │ Analysis Across │ for Mitigating Sophisticated │ │ │ │ │
│ Distributed Infrastructure │ Asynchronous Message │ Multi-Regional Cloud │ Cross-Site Scripting
Layer │ Processing Pipeline with │ Deployment Clusters │ Vulnerabilities │ │ │
│ Extended Scalability │ │ │ │ │
│ │ Features and Redundancy │ │ │ │ │ │ │
│ │ Protocols │ │ │ │ │ │ │
├─────────────────────────────┼──────────────────────────────┼─────────────────────────────┼──────────────────────────────┼─────┼────────┼─────────┼───────┤
│ The primary architecture │ Each message is processed │ Historical data indicates a │ A multi-layered defense │ INF │ Active │ v2.4 │ J. │
│ utilizes a decoupled │ through a series of │ significant reduction in │ strategy incorporates │ │ │ │ Doe │
│ microservices approach, │ specialized workers that │ tail latency when utilizing │ content security policies, │ │ │ │ │
│ leveraging container │ handle data transformation, │ edge computing nodes closer │ input sanitization │ │ │ │ │
│ orchestration for │ validation, and persistent │ to the geographic location │ libraries, and regular │ │ │ │ │
│ scalability and fault │ storage using a persistent │ of the end-user base. │ automated penetration │ │ │ │ │
│ tolerance in high-load │ queue. │ │ testing routines. │ │ │ │ │
│ scenarios. │ │ Monitoring tools have │ │ │ │ │ │
│ │ The pipeline features │ captured a steady increase │ Developers are required to │ │ │ │ │
│ This layer provides the │ built-in retry mechanisms │ in throughput efficiency │ undergo mandatory security │ │ │ │ │
│ fundamental building blocks │ with exponential backoff to │ since the introduction of │ training focusing on the │ │ │ │ │
│ for service discovery, load │ ensure message delivery │ the vectorized query engine │ OWASP Top Ten to ensure that │ │ │ │ │
│ balancing, and │ integrity even during │ in the primary data │ security is integrated into │ │ │ │ │
│ inter-service communication │ transient network or service │ warehouse. │ the initial design phase. │ │ │ │ │
│ via highly efficient │ failures. │ │ │ │ │ │ │
│ protocol buffers. │ │ Resource utilization │ The implementation of a │ │ │ │ │
│ │ Horizontal autoscaling is │ metrics demonstrate that │ robust Identity and Access │ │ │ │ │
│ Advanced telemetry and │ triggered automatically │ the transition to │ Management system ensures │ │ │ │ │
│ logging integrations allow │ based on the depth of the │ serverless compute for │ that the principle of least │ │ │ │ │
│ for real-time monitoring of │ processing queue, ensuring │ intermittent tasks has │ privilege is strictly │ │ │ │ │
│ system health and rapid │ consistent performance │ resulted in a thirty │ enforced across all │ │ │ │ │
│ identification of │ during unexpected traffic │ percent cost optimization. │ environments. │ │ │ │ │
│ bottlenecks within the │ spikes. │ │ │ │ │ │ │
│ service mesh. │ │ │ │ │ │ │ │
└─────────────────────────────┴──────────────────────────────┴─────────────────────────────┴──────────────────────────────┴─────┴────────┴─────────┴───────┘
"
`;
exports[`TableRenderer > renders a table with long headers and 4 columns correctly 1`] = `
"
┌───────────────┬───────────────┬──────────────────┬──────────────────┐
│ Very Long │ Very Long │ Very Long Column │ Very Long Column │
│ Column Header │ Column Header │ Header Three │ Header Four │
│ One │ Two │ │ │
├───────────────┼───────────────┼──────────────────┼──────────────────┤
│ Data 1.1 │ Data 1.2 │ Data 1.3 │ Data 1.4 │
│ Data 2.1 │ Data 2.2 │ Data 2.3 │ Data 2.4 │
│ Data 3.1 │ Data 3.2 │ Data 3.3 │ Data 3.4 │
└───────────────┴───────────────┴──────────────────┴──────────────────┘
"
`;
exports[`TableRenderer > strips bold markers from headers and renders them correctly 1`] = `
"
┌─────────────┬───────────────┬──────────────┐
│ Bold Header │ Normal Header │ Another Bold │
├─────────────┼───────────────┼──────────────┤
│ Data 1 │ Data 2 │ Data 3 │
└─────────────┴───────────────┴──────────────┘
"
`;
exports[`TableRenderer > wraps all long columns correctly 1`] = `
"
┌────────────────┬────────────────┬─────────────────┐
│ Col 1 │ Col 2 │ Col 3 │
├────────────────┼────────────────┼─────────────────┤
│ This is a very │ This is also a │ And this is the │
│ long text that │ very long text │ third long text │
│ needs wrapping │ that needs │ that needs │
│ in column 1 │ wrapping in │ wrapping in │
│ │ column 2 │ column 3 │
└────────────────┴────────────────┴─────────────────┘
"
`;
exports[`TableRenderer > wraps columns with punctuation correctly 1`] = `
"
┌───────────────────┬───────────────┬─────────────────┐
│ Punctuation 1 │ Punctuation 2 │ Punctuation 3 │
├───────────────────┼───────────────┼─────────────────┤
│ Start. Stop. │ Semi; colon: │ At@ Hash# │
│ Comma, separated. │ Pipe| Slash/ │ Dollar$ │
│ Exclamation! │ Backslash\\ │ Percent% Caret^ │
│ Question? │ │ Ampersand& │
│ hyphen-ated │ │ Asterisk* │
└───────────────────┴───────────────┴─────────────────┘
"
`;
exports[`TableRenderer > wraps long cell content correctly 1`] = `
"
┌───────┬─────────────────────────────┬───────┐
│ Col 1 │ Col 2 │ Col 3 │
├───────┼─────────────────────────────┼───────┤
│ Short │ This is a very long cell │ Short │
│ │ content that should wrap to │ │
│ │ multiple lines │ │
└───────┴─────────────────────────────┴───────┘
"
`;
exports[`TableRenderer > wraps mixed long and short columns correctly 1`] = `
"
┌───────┬──────────────────────────┬────────┐
│ Short │ Long │ Medium │
├───────┼──────────────────────────┼────────┤
│ Tiny │ This is a very long text │ Not so │
│ │ that definitely needs to │ long │
│ │ wrap to the next line │ │
└───────┴──────────────────────────┴────────┘
"
`;
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "@google/gemini-cli-core",
"version": "0.29.0-nightly.20260203.71f46f116",
"version": "0.30.0-nightly.20260210.a2174751d",
"description": "Gemini CLI Core",
"license": "Apache-2.0",
"repository": {
@@ -526,6 +526,7 @@ exports[`Core System Prompt (prompts.ts) > should append userMemory with separat
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -652,6 +653,7 @@ exports[`Core System Prompt (prompts.ts) > should handle CodebaseInvestigator wi
- **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.
- **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.
- **Handle Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, do not perform it automatically.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -743,6 +745,7 @@ exports[`Core System Prompt (prompts.ts) > should handle CodebaseInvestigator wi
- **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.
- **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.
- **Handle Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, do not perform it automatically.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -1303,6 +1306,7 @@ exports[`Core System Prompt (prompts.ts) > should include correct sandbox instru
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -1416,6 +1420,7 @@ exports[`Core System Prompt (prompts.ts) > should include correct sandbox instru
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -1529,6 +1534,7 @@ exports[`Core System Prompt (prompts.ts) > should include correct sandbox instru
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -1638,6 +1644,7 @@ exports[`Core System Prompt (prompts.ts) > should include planning phase suggest
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -1747,6 +1754,7 @@ exports[`Core System Prompt (prompts.ts) > should include sub-agents in XML for
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -2095,6 +2103,7 @@ exports[`Core System Prompt (prompts.ts) > should return the base prompt when us
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -2204,6 +2213,7 @@ exports[`Core System Prompt (prompts.ts) > should return the base prompt when us
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -2424,6 +2434,7 @@ exports[`Core System Prompt (prompts.ts) > should use chatty system prompt for p
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
@@ -2533,6 +2544,7 @@ exports[`Core System Prompt (prompts.ts) > should use chatty system prompt for p
- **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.
- **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.
- **Confirm Ambiguity/Expansion:** Do not take significant actions beyond the clear scope of the request without confirming with the user. If the user implies a change (e.g., reports a bug) without explicitly asking for a fix, **ask for confirmation first**. If asked *how* to do something, explain first, don't just do it.
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.
+2 -1
View File
@@ -170,7 +170,8 @@ export function renderCoreMandates(options?: CoreMandatesOptions): string {
- **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.
- **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.${mandateConflictResolution(options.hasHierarchicalMemory)}
- **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)}
- ${mandateConfirm(options.interactive)}
- **Explaining Changes:** After completing a code modification or file operation *do not* provide summaries unless asked.
- **Do Not revert changes:** Do not revert changes to the codebase unless asked to do so by the user. Only revert changes made by you if they have resulted in an error or if the user has explicitly asked you to revert the changes.${mandateSkillGuidance(options.hasSkills)}
+51 -2
View File
@@ -187,7 +187,7 @@ describe('loggers', () => {
});
describe('logCliConfiguration', () => {
it('should log the cli configuration', () => {
it('should log the cli configuration', async () => {
const mockConfig = {
getSessionId: () => 'test-session-id',
getModel: () => 'test-model',
@@ -226,11 +226,14 @@ describe('loggers', () => {
}),
}),
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
const startSessionEvent = new StartSessionEvent(mockConfig);
logCliConfiguration(mockConfig, startSessionEvent);
await new Promise(process.nextTick);
expect(mockLogger.emit).toHaveBeenCalledWith({
body: 'CLI configuration loaded.',
attributes: {
@@ -271,6 +274,8 @@ describe('loggers', () => {
getTelemetryLogPromptsEnabled: () => true,
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
it('should log a user prompt', () => {
@@ -308,6 +313,8 @@ describe('loggers', () => {
getTargetDir: () => 'target-dir',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
const event = new UserPromptEvent(
11,
@@ -343,6 +350,8 @@ describe('loggers', () => {
getTelemetryEnabled: () => true,
getTelemetryLogPromptsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as Config;
const mockMetrics = {
@@ -519,6 +528,8 @@ describe('loggers', () => {
getTelemetryEnabled: () => true,
getTelemetryLogPromptsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as Config;
const mockMetrics = {
@@ -651,6 +662,8 @@ describe('loggers', () => {
getTelemetryEnabled: () => true,
getTelemetryLogPromptsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
getContentGeneratorConfig: () => ({
authType: AuthType.LOGIN_WITH_GOOGLE,
}),
@@ -727,6 +740,8 @@ describe('loggers', () => {
getTelemetryEnabled: () => true,
getTelemetryLogPromptsEnabled: () => true, // Enabled
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
getContentGeneratorConfig: () => ({
authType: AuthType.USE_GEMINI,
}),
@@ -814,6 +829,8 @@ describe('loggers', () => {
getTelemetryEnabled: () => true,
getTelemetryLogPromptsEnabled: () => false, // Disabled
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
getContentGeneratorConfig: () => ({
authType: AuthType.USE_VERTEX_AI,
}),
@@ -867,6 +884,8 @@ describe('loggers', () => {
getTelemetryEnabled: () => true,
getTelemetryLogPromptsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
getUsageStatisticsEnabled: () => true,
getContentGeneratorConfig: () => ({
authType: AuthType.USE_GEMINI,
@@ -903,6 +922,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
it('should log flash fallback event', () => {
@@ -930,6 +951,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -1024,6 +1047,8 @@ describe('loggers', () => {
getTelemetryEnabled: () => true,
getTelemetryLogPromptsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as Config;
const mockMetrics = {
@@ -1595,6 +1620,8 @@ describe('loggers', () => {
getTelemetryEnabled: () => true,
getTelemetryLogPromptsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as Config;
const mockMetrics = {
@@ -1655,6 +1682,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
it('should log a tool output truncated event', () => {
@@ -1692,6 +1721,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -1792,6 +1823,8 @@ describe('loggers', () => {
getUsageStatisticsEnabled: () => true,
getContentGeneratorConfig: () => null,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -1842,6 +1875,8 @@ describe('loggers', () => {
getUsageStatisticsEnabled: () => true,
getContentGeneratorConfig: () => null,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -1894,6 +1929,8 @@ describe('loggers', () => {
getUsageStatisticsEnabled: () => true,
getContentGeneratorConfig: () => null,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -1938,6 +1975,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -1983,6 +2022,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -2028,6 +2069,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -2064,6 +2107,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -2115,6 +2160,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
beforeEach(() => {
@@ -2150,6 +2197,8 @@ describe('loggers', () => {
getSessionId: () => 'test-session-id',
getUsageStatisticsEnabled: () => true,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
getTelemetryLogPromptsEnabled: () => false,
} as unknown as Config;
@@ -2205,7 +2254,7 @@ describe('loggers', () => {
});
describe('Telemetry Buffering', () => {
it('should buffer events when SDK is not initialized', () => {
it('should buffer events when SDK is not initialized', async () => {
vi.spyOn(sdk, 'isTelemetrySdkInitialized').mockReturnValue(false);
const bufferSpy = vi
.spyOn(sdk, 'bufferTelemetryEvent')
+29 -12
View File
@@ -81,6 +81,7 @@ import { bufferTelemetryEvent } from './sdk.js';
import type { UiEvent } from './uiTelemetry.js';
import { uiTelemetryService } from './uiTelemetry.js';
import { ClearcutLogger } from './clearcut-logger/clearcut-logger.js';
import { debugLogger } from '../utils/debugLogger.js';
export function logCliConfiguration(
config: Config,
@@ -88,12 +89,20 @@ export function logCliConfiguration(
): void {
void ClearcutLogger.getInstance(config)?.logStartSessionEvent(event);
bufferTelemetryEvent(() => {
const logger = logs.getLogger(SERVICE_NAME);
const logRecord: LogRecord = {
body: event.toLogBody(),
attributes: event.toOpenTelemetryAttributes(config),
};
logger.emit(logRecord);
// Wait for experiments to load before emitting so we capture experimentIds
void config
.getExperimentsAsync()
.then(() => {
const logger = logs.getLogger(SERVICE_NAME);
const logRecord: LogRecord = {
body: event.toLogBody(),
attributes: event.toOpenTelemetryAttributes(config),
};
logger.emit(logRecord);
})
.catch((e: unknown) => {
debugLogger.error('Failed to log telemetry event', e);
});
});
}
@@ -780,11 +789,19 @@ export function logStartupStats(
event: StartupStatsEvent,
): void {
bufferTelemetryEvent(() => {
const logger = logs.getLogger(SERVICE_NAME);
const logRecord: LogRecord = {
body: event.toLogBody(),
attributes: event.toOpenTelemetryAttributes(config),
};
logger.emit(logRecord);
// Wait for experiments to load before emitting so we capture experimentIds
void config
.getExperimentsAsync()
.then(() => {
const logger = logs.getLogger(SERVICE_NAME);
const logRecord: LogRecord = {
body: event.toLogBody(),
attributes: event.toOpenTelemetryAttributes(config),
};
logger.emit(logRecord);
})
.catch((e: unknown) => {
debugLogger.error('Failed to log telemetry event', e);
});
});
}
@@ -26,6 +26,8 @@ function createMockConfig(logPromptsEnabled: boolean): Config {
return {
getTelemetryLogPromptsEnabled: () => logPromptsEnabled,
getSessionId: () => 'test-session-id',
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
getModel: () => 'gemini-1.5-flash',
isInteractive: () => true,
getUserEmail: () => undefined,
+3
View File
@@ -75,6 +75,8 @@ describe('Telemetry SDK', () => {
getSessionId: () => 'test-session',
getTelemetryUseCliAuth: () => false,
isInteractive: () => false,
getExperiments: () => undefined,
getExperimentsAsync: async () => undefined,
} as unknown as Config;
});
@@ -353,6 +355,7 @@ describe('Telemetry SDK', () => {
expect(callback).not.toHaveBeenCalled();
await initializeTelemetry(mockConfig);
await new Promise((resolve) => setTimeout(resolve, 10));
expect(callback).toHaveBeenCalled();
});
});
@@ -14,10 +14,15 @@ const installationManager = new InstallationManager();
export function getCommonAttributes(config: Config): Attributes {
const email = userAccountManager.getCachedGoogleAccount();
const experiments = config.getExperiments();
return {
'session.id': config.getSessionId(),
'installation.id': installationManager.getInstallationId(),
interactive: config.isInteractive(),
...(email && { 'user.email': email }),
...(experiments &&
experiments.experimentIds.length > 0 && {
'experiments.ids': experiments.experimentIds,
}),
};
}
+8 -8
View File
@@ -901,9 +901,9 @@ describe('mcp-client', () => {
vi.mocked(ClientLib.Client).mockReturnValue(
mockedClient as unknown as ClientLib.Client,
);
vi.spyOn(SdkClientStdioLib, 'StdioClientTransport').mockReturnValue({
close: vi.fn(),
} as unknown as SdkClientStdioLib.StdioClientTransport);
vi.spyOn(SdkClientStdioLib, 'StdioClientTransport').mockReturnValue(
{} as SdkClientStdioLib.StdioClientTransport,
);
const mockedToolRegistry = {
registerTool: vi.fn(),
unregisterTool: vi.fn(),
@@ -2040,7 +2040,7 @@ describe('connectToMcpServer with OAuth', () => {
EMPTY_CONFIG,
);
expect(client.client).toBe(mockedClient);
expect(client).toBe(mockedClient);
expect(mockedClient.connect).toHaveBeenCalledTimes(2);
expect(mockAuthProvider.authenticate).toHaveBeenCalledOnce();
@@ -2086,7 +2086,7 @@ describe('connectToMcpServer with OAuth', () => {
EMPTY_CONFIG,
);
expect(client.client).toBe(mockedClient);
expect(client).toBe(mockedClient);
expect(mockedClient.connect).toHaveBeenCalledTimes(2);
expect(mockAuthProvider.authenticate).toHaveBeenCalledOnce();
expect(OAuthUtils.discoverOAuthConfig).toHaveBeenCalledWith(serverUrl);
@@ -2181,7 +2181,7 @@ describe('connectToMcpServer - HTTP→SSE fallback', () => {
EMPTY_CONFIG,
);
expect(client.client).toBe(mockedClient);
expect(client).toBe(mockedClient);
// First HTTP attempt fails, second SSE attempt succeeds
expect(mockedClient.connect).toHaveBeenCalledTimes(2);
});
@@ -2222,7 +2222,7 @@ describe('connectToMcpServer - HTTP→SSE fallback', () => {
EMPTY_CONFIG,
);
expect(client.client).toBe(mockedClient);
expect(client).toBe(mockedClient);
expect(mockedClient.connect).toHaveBeenCalledTimes(2);
});
});
@@ -2307,7 +2307,7 @@ describe('connectToMcpServer - OAuth with transport fallback', () => {
EMPTY_CONFIG,
);
expect(client.client).toBe(mockedClient);
expect(client).toBe(mockedClient);
expect(mockedClient.connect).toHaveBeenCalledTimes(3);
expect(mockAuthProvider.authenticate).toHaveBeenCalledOnce();
});
+17 -51
View File
@@ -146,7 +146,7 @@ export class McpClient {
}
this.updateStatus(MCPServerStatus.CONNECTING);
try {
const { client, transport } = await connectToMcpServer(
this.client = await connectToMcpServer(
this.clientVersion,
this.serverName,
this.serverConfig,
@@ -154,13 +154,11 @@ export class McpClient {
this.workspaceContext,
this.cliConfig.sanitizationConfig,
);
this.client = client;
this.transport = transport;
this.registerNotificationHandlers();
const originalOnError = this.client.onerror;
this.client.onerror = async (error) => {
this.client.onerror = (error) => {
if (this.status !== MCPServerStatus.CONNECTED) {
return;
}
@@ -171,14 +169,6 @@ export class McpClient {
error,
);
this.updateStatus(MCPServerStatus.DISCONNECTED);
// Close transport to prevent memory leaks
if (this.transport) {
try {
await this.transport.close();
} catch {
// Ignore errors when closing transport on error
}
}
};
this.updateStatus(MCPServerStatus.CONNECTED);
} catch (error) {
@@ -927,9 +917,8 @@ export async function connectAndDiscover(
updateMCPServerStatus(mcpServerName, MCPServerStatus.CONNECTING);
let mcpClient: Client | undefined;
let transport: Transport | undefined;
try {
const result = await connectToMcpServer(
mcpClient = await connectToMcpServer(
clientVersion,
mcpServerName,
mcpServerConfig,
@@ -937,20 +926,10 @@ export async function connectAndDiscover(
workspaceContext,
cliConfig.sanitizationConfig,
);
mcpClient = result.client;
transport = result.transport;
mcpClient.onerror = async (error) => {
mcpClient.onerror = (error) => {
coreEvents.emitFeedback('error', `MCP ERROR (${mcpServerName}):`, error);
updateMCPServerStatus(mcpServerName, MCPServerStatus.DISCONNECTED);
// Close transport to prevent memory leaks
if (transport) {
try {
await transport.close();
} catch {
// Ignore errors when closing transport on error
}
}
};
// Attempt to discover both prompts and tools
@@ -1348,18 +1327,16 @@ function createSSETransportWithAuth(
* @param client The MCP client to connect
* @param config The MCP server configuration
* @param accessToken Optional OAuth access token for authentication
* @returns The transport used for connection
*/
async function connectWithSSETransport(
client: Client,
config: MCPServerConfig,
accessToken?: string | null,
): Promise<Transport> {
): Promise<void> {
const transport = createSSETransportWithAuth(config, accessToken);
await client.connect(transport, {
timeout: config.timeout ?? MCP_DEFAULT_TIMEOUT_MSEC,
});
return transport;
}
/**
@@ -1389,7 +1366,6 @@ async function showAuthRequiredMessage(serverName: string): Promise<never> {
* @param config The MCP server configuration
* @param accessToken The OAuth access token to use
* @param httpReturned404 Whether the HTTP transport returned 404 (indicating SSE-only server)
* @returns The transport used for connection
*/
async function retryWithOAuth(
client: Client,
@@ -1397,21 +1373,17 @@ async function retryWithOAuth(
config: MCPServerConfig,
accessToken: string,
httpReturned404: boolean,
): Promise<Transport> {
): Promise<void> {
if (httpReturned404) {
// HTTP returned 404, only try SSE
debugLogger.log(
`Retrying SSE connection to '${serverName}' with OAuth token...`,
);
const transport = await connectWithSSETransport(
client,
config,
accessToken,
);
await connectWithSSETransport(client, config, accessToken);
debugLogger.log(
`Successfully connected to '${serverName}' using SSE with OAuth.`,
);
return transport;
return;
}
// HTTP returned 401, try HTTP with OAuth first
@@ -1435,7 +1407,6 @@ async function retryWithOAuth(
debugLogger.log(
`Successfully connected to '${serverName}' using HTTP with OAuth.`,
);
return httpTransport;
} catch (httpError) {
await httpTransport.close();
@@ -1447,15 +1418,10 @@ async function retryWithOAuth(
!config.httpUrl
) {
debugLogger.log(`HTTP with OAuth returned 404, trying SSE with OAuth...`);
const sseTransport = await connectWithSSETransport(
client,
config,
accessToken,
);
await connectWithSSETransport(client, config, accessToken);
debugLogger.log(
`Successfully connected to '${serverName}' using SSE with OAuth.`,
);
return sseTransport;
} else {
throw httpError;
}
@@ -1469,7 +1435,7 @@ async function retryWithOAuth(
*
* @param mcpServerName The name of the MCP server, used for logging and identification.
* @param mcpServerConfig The configuration specifying how to connect to the server.
* @returns A promise that resolves to a connected MCP `Client` instance and its transport.
* @returns A promise that resolves to a connected MCP `Client` instance.
* @throws An error if the connection fails or the configuration is invalid.
*/
export async function connectToMcpServer(
@@ -1479,7 +1445,7 @@ export async function connectToMcpServer(
debugMode: boolean,
workspaceContext: WorkspaceContext,
sanitizationConfig: EnvironmentSanitizationConfig,
): Promise<{ client: Client; transport: Transport }> {
): Promise<Client> {
const mcpClient = new Client(
{
name: 'gemini-cli-mcp-client',
@@ -1551,7 +1517,7 @@ export async function connectToMcpServer(
await mcpClient.connect(transport, {
timeout: mcpServerConfig.timeout ?? MCP_DEFAULT_TIMEOUT_MSEC,
});
return { client: mcpClient, transport };
return mcpClient;
} catch (error) {
await transport.close();
// eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion
@@ -1583,7 +1549,7 @@ export async function connectToMcpServer(
try {
// Try SSE with stored OAuth token if available
// This ensures that SSE fallback works for authenticated servers
const sseTransport = await connectWithSSETransport(
await connectWithSSETransport(
mcpClient,
mcpServerConfig,
await getStoredOAuthToken(mcpServerName),
@@ -1592,7 +1558,7 @@ export async function connectToMcpServer(
debugLogger.log(
`MCP server '${mcpServerName}': Successfully connected using SSE transport.`,
);
return { client: mcpClient, transport: sseTransport };
return mcpClient;
} catch (sseFallbackError) {
// eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion
sseError = sseFallbackError as Error;
@@ -1700,14 +1666,14 @@ export async function connectToMcpServer(
);
}
const oauthTransport = await retryWithOAuth(
await retryWithOAuth(
mcpClient,
mcpServerName,
mcpServerConfig,
accessToken,
httpReturned404,
);
return { client: mcpClient, transport: oauthTransport };
return mcpClient;
} else {
throw new Error(
`Failed to handle automatic OAuth for server '${mcpServerName}'`,
@@ -1788,7 +1754,7 @@ export async function connectToMcpServer(
timeout: mcpServerConfig.timeout ?? MCP_DEFAULT_TIMEOUT_MSEC,
});
// Connection successful with OAuth
return { client: mcpClient, transport: oauthTransport };
return mcpClient;
} else {
throw new Error(
`OAuth configuration failed for '${mcpServerName}'. Please authenticate manually with /mcp auth ${mcpServerName}`,
+69 -42
View File
@@ -1408,42 +1408,45 @@ describe('RipGrepTool', () => {
expect(result.llmContent).toContain('L1: HELLO world');
});
it.each([
{
name: 'fixed_strings parameter',
params: { pattern: 'hello.world', fixed_strings: true },
mockOutput: {
path: { text: 'fileA.txt' },
line_number: 1,
lines: { text: 'hello.world\n' },
},
expectedArgs: ['--fixed-strings'],
expectedPattern: 'hello.world',
},
])(
'should handle $name',
async ({ params, mockOutput, expectedArgs, expectedPattern }) => {
mockSpawn.mockImplementationOnce(
createMockSpawn({
outputData:
JSON.stringify({ type: 'match', data: mockOutput }) + '\n',
exitCode: 0,
}),
);
it('should handle fixed_strings parameter', async () => {
mockSpawn.mockImplementationOnce(
createMockSpawn({
outputData:
JSON.stringify({
type: 'match',
data: {
path: { text: 'fileA.txt' },
line_number: 1,
lines: { text: 'hello.world\n' },
},
}) + '\n',
exitCode: 0,
}),
);
const invocation = grepTool.build(params);
const result = await invocation.execute(abortSignal);
const invocation = grepTool.build({
pattern: 'hello.world',
fixed_strings: true,
});
const result = await invocation.execute(abortSignal);
expect(mockSpawn).toHaveBeenLastCalledWith(
expect.anything(),
expect.arrayContaining(expectedArgs),
expect.anything(),
);
expect(result.llmContent).toContain(
`Found 1 match for pattern "${expectedPattern}"`,
);
},
);
expect(mockSpawn).toHaveBeenLastCalledWith(
expect.anything(),
expect.arrayContaining(['--fixed-strings']),
expect.anything(),
);
expect(result.llmContent).toContain(
'Found 1 match for pattern "hello.world"',
);
});
it('should allow invalid regex patterns when fixed_strings is true', () => {
const params: RipGrepToolParams = {
pattern: '[[',
fixed_strings: true,
};
expect(grepTool.validateToolParams(params)).toBeNull();
});
it('should handle no_ignore parameter', async () => {
mockSpawn.mockImplementationOnce(
@@ -1681,19 +1684,42 @@ describe('RipGrepTool', () => {
mockSpawn.mockImplementationOnce(
createMockSpawn({
outputData:
JSON.stringify({
type: 'context',
data: {
path: { text: 'fileA.txt' },
line_number: 1,
lines: { text: 'hello world\n' },
},
}) +
'\n' +
JSON.stringify({
type: 'match',
data: {
path: { text: 'fileA.txt' },
line_number: 2,
lines: { text: 'second line with world\n' },
lines_before: [{ text: 'hello world\n' }],
lines_after: [
{ text: 'third line\n' },
{ text: 'fourth line\n' },
],
},
}) + '\n',
}) +
'\n' +
JSON.stringify({
type: 'context',
data: {
path: { text: 'fileA.txt' },
line_number: 3,
lines: { text: 'third line\n' },
},
}) +
'\n' +
JSON.stringify({
type: 'context',
data: {
path: { text: 'fileA.txt' },
line_number: 4,
lines: { text: 'fourth line\n' },
},
}) +
'\n',
exitCode: 0,
}),
);
@@ -1721,9 +1747,10 @@ describe('RipGrepTool', () => {
);
expect(result.llmContent).toContain('Found 1 match for pattern "world"');
expect(result.llmContent).toContain('File: fileA.txt');
expect(result.llmContent).toContain('L1- hello world');
expect(result.llmContent).toContain('L2: second line with world');
// Note: Ripgrep JSON output for context lines doesn't include line numbers for context lines directly
// The current parsing only extracts the matched line, so we only assert on that.
expect(result.llmContent).toContain('L3- third line');
expect(result.llmContent).toContain('L4- fourth line');
});
});
+25 -16
View File
@@ -140,6 +140,7 @@ interface GrepMatch {
filePath: string;
lineNumber: number;
line: string;
isContext?: boolean;
}
class GrepToolInvocation extends BaseToolInvocation<
@@ -267,8 +268,6 @@ class GrepToolInvocation extends BaseToolInvocation<
return { llmContent: noMatchMsg, returnDisplay: `No matches found` };
}
const wasTruncated = allMatches.length >= totalMaxMatches;
const matchesByFile = allMatches.reduce(
(acc, match) => {
const fileKey = match.filePath;
@@ -282,16 +281,19 @@ class GrepToolInvocation extends BaseToolInvocation<
{} as Record<string, GrepMatch[]>,
);
const matchCount = allMatches.length;
const matchesOnly = allMatches.filter((m) => !m.isContext);
const matchCount = matchesOnly.length;
const matchTerm = matchCount === 1 ? 'match' : 'matches';
const wasTruncated = matchCount >= totalMaxMatches;
let llmContent = `Found ${matchCount} ${matchTerm} for pattern "${this.params.pattern}" ${searchLocationDescription}${this.params.include ? ` (filter: "${this.params.include}")` : ''}${wasTruncated ? ` (results limited to ${totalMaxMatches} matches for performance)` : ''}:\n---\n`;
for (const filePath in matchesByFile) {
llmContent += `File: ${filePath}\n`;
matchesByFile[filePath].forEach((match) => {
const trimmedLine = match.line.trim();
llmContent += `L${match.lineNumber}: ${trimmedLine}\n`;
const separator = match.isContext ? '-' : ':';
llmContent += `L${match.lineNumber}${separator} ${match.line}\n`;
});
llmContent += '---\n';
}
@@ -402,11 +404,15 @@ class GrepToolInvocation extends BaseToolInvocation<
allowedExitCodes: [0, 1],
});
let matchesFound = 0;
for await (const line of generator) {
const match = this.parseRipgrepJsonLine(line, absolutePath);
if (match) {
results.push(match);
if (results.length >= maxMatches) {
if (!match.isContext) {
matchesFound++;
}
if (matchesFound >= maxMatches) {
break;
}
}
@@ -425,11 +431,11 @@ class GrepToolInvocation extends BaseToolInvocation<
): GrepMatch | null {
try {
const json = JSON.parse(line);
if (json.type === 'match') {
const match = json.data;
if (json.type === 'match' || json.type === 'context') {
const data = json.data;
// Defensive check: ensure text properties exist (skips binary/invalid encoding)
if (match.path?.text && match.lines?.text) {
const absoluteFilePath = path.resolve(basePath, match.path.text);
if (data.path?.text && data.lines?.text) {
const absoluteFilePath = path.resolve(basePath, data.path.text);
const relativeCheck = path.relative(basePath, absoluteFilePath);
if (
relativeCheck === '..' ||
@@ -443,8 +449,9 @@ class GrepToolInvocation extends BaseToolInvocation<
return {
filePath: relativeFilePath || path.basename(absoluteFilePath),
lineNumber: match.line_number,
line: match.lines.text.trimEnd(),
lineNumber: data.line_number,
line: data.lines.text.trimEnd(),
isContext: json.type === 'context',
};
}
}
@@ -573,10 +580,12 @@ export class RipGrepTool extends BaseDeclarativeTool<
protected override validateToolParamValues(
params: RipGrepToolParams,
): string | null {
try {
new RegExp(params.pattern);
} catch (error) {
return `Invalid regular expression pattern provided: ${params.pattern}. Error: ${getErrorMessage(error)}`;
if (!params.fixed_strings) {
try {
new RegExp(params.pattern);
} catch (error) {
return `Invalid regular expression pattern provided: ${params.pattern}. Error: ${getErrorMessage(error)}`;
}
}
// Only validate path if one is provided
+1 -1
View File
@@ -1,6 +1,6 @@
{
"name": "@google/gemini-cli-test-utils",
"version": "0.29.0-nightly.20260203.71f46f116",
"version": "0.30.0-nightly.20260210.a2174751d",
"private": true,
"main": "src/index.ts",
"license": "Apache-2.0",
+1 -1
View File
@@ -2,7 +2,7 @@
"name": "gemini-cli-vscode-ide-companion",
"displayName": "Gemini CLI Companion",
"description": "Enable Gemini CLI with direct access to your IDE workspace.",
"version": "0.29.0-nightly.20260203.71f46f116",
"version": "0.30.0-nightly.20260210.a2174751d",
"publisher": "google",
"icon": "assets/icon.png",
"repository": {