docs: fix typos in source code and documentation (#13577)

This commit is contained in:
fancivez
2025-11-21 22:59:42 +08:00
committed by GitHub
parent 8d082a904d
commit 0f0b463a2f
13 changed files with 14 additions and 14 deletions
@@ -153,7 +153,7 @@ syntax = "proto3";
import "google/protobuf/struct.proto";
// ToolCall is the central message represeting a tool's execution lifecycle.
// ToolCall is the central message representing a tool's execution lifecycle.
// The entire object is sent from the agent to client on every update.
message ToolCall {
// A unique identifier, assigned by the agent
@@ -197,7 +197,7 @@ enum ToolCallStatus {
CANCELLED = 5;
}
// ToolOuput represents the final, successful, output of a tool
// ToolOutput represents the final, successful, output of a tool
message ToolOutput {
oneof result {
string text = 1;
+1 -1
View File
@@ -460,7 +460,7 @@ export class Task {
): Message {
const messageParts: Part[] = [];
// Create a serializable version of the ToolCall (pick necesssary
// Create a serializable version of the ToolCall (pick necessary
// properties/avoid methods causing circular reference errors)
const serializableToolCall: Partial<ToolCall> = this._pickFields(
tc,
@@ -88,7 +88,7 @@ export const createMockCommandContext = (
const targetValue = output[key];
if (
// We only want to recursivlty merge plain objects
// We only want to recursively merge plain objects
Object.prototype.toString.call(sourceValue) === '[object Object]' &&
Object.prototype.toString.call(targetValue) === '[object Object]'
) {
@@ -185,7 +185,7 @@ export const DebugProfiler = () => {
return;
}
// Only update the UX infrequently as updating the UX itself will cause
// frames to run so can disturb what we are measuing.
// frames to run so can disturb what we are measuring.
const forceRefreshInterval = setInterval(() => {
setForceRefresh((f) => f + 1);
profiler.reportAction();
@@ -708,7 +708,7 @@ export const InputPrompt: React.FC<InputPromptProps> = ({
// newline that was part of the paste.
// This has the added benefit that in the worst case at least users
// get some feedback that their keypress was handled rather than
// wondering why it was completey ignored.
// wondering why it was completely ignored.
buffer.newline();
return;
}
@@ -293,7 +293,7 @@ describe('useSlashCompletion', () => {
const hook = renderHook(() =>
useTestHarnessForSlashCompletion(
true,
'/usag',
'/usage',
slashCommands,
mockCommandContext,
),
+1 -1
View File
@@ -19,7 +19,7 @@ import { type ReactNode } from 'react';
export type { ThoughtSummary };
export enum AuthState {
// Attemtping to authenticate or re-authenticate
// Attempting to authenticate or re-authenticate
Unauthenticated = 'unauthenticated',
// Auth dialog is open for user to select auth method
Updating = 'updating',
@@ -96,7 +96,7 @@ You are a sub-agent in a larger system. Your only responsibility is to provide d
- **DO:** Find the key modules, classes, and functions that are part of the problem and its solution.
- **DO:** Understand *why* the code is written the way it is. Question everything.
- **DO:** Foresee the ripple effects of a change. If \`function A\` is modified, you must check its callers. If a data structure is altered, you must identify where its type definitions need to be updated.
- **DO:** provide a conclusion and insights to the main agent that invoked you. If the agent is trying to solve a bug, you should provide the root cause of the bug, its impacts, how to fix it etc. If it's a new feature, you should provide insights on where to implement it, what chagnes are necessary etc.
- **DO:** provide a conclusion and insights to the main agent that invoked you. If the agent is trying to solve a bug, you should provide the root cause of the bug, its impacts, how to fix it etc. If it's a new feature, you should provide insights on where to implement it, what changes are necessary etc.
- **DO NOT:** Write the final implementation code yourself.
- **DO NOT:** Stop at the first relevant file. Your goal is a comprehensive understanding of the entire relevant subsystem.
You operate in a non-interactive loop and must reason based on the information provided and the output of your tools.
+1 -1
View File
@@ -109,7 +109,7 @@ export function toFinishReasons(candidates?: Candidate[]): OTelFinishReason[] {
export function toOutputType(requested_mime?: string): string | undefined {
switch (requested_mime) {
// explictly support the known good values of responseMimeType
// explicitly support the known good values of responseMimeType
case 'text/plain':
return OTelOutputType.TEXT;
case 'application/json':
+1 -1
View File
@@ -182,7 +182,7 @@ export class MockModifiableTool
extends BaseDeclarativeTool<Record<string, unknown>, ToolResult>
implements ModifiableDeclarativeTool<Record<string, unknown>>
{
// Should be overrided in test file. Functionality will be updated in follow
// Should be overridden in test file. Functionality will be updated in follow
// up PR which has MockModifiableTool expect MockTool
executeFn: (params: Record<string, unknown>) => ToolResult | undefined = () =>
undefined;
+1 -1
View File
@@ -30,7 +30,7 @@ addFormatsFunc(ajValidator);
*/
export class SchemaValidator {
/**
* Returns null if the data confroms to the schema described by schema (or if schema
* Returns null if the data conforms to the schema described by schema (or if schema
* is null). Otherwise, returns a string describing the error.
*/
static validate(schema: unknown | undefined, data: unknown): string | null {
@@ -453,7 +453,7 @@ const createMcpServer = (
'openDiff',
{
description:
'(IDE Tool) Open a diff view to create or modify a file. Returns a notification once the diff has been accepted or rejcted.',
'(IDE Tool) Open a diff view to create or modify a file. Returns a notification once the diff has been accepted or rejected.',
inputSchema: OpenDiffRequestSchema.shape,
},
async ({ filePath, newContent }: z.infer<typeof OpenDiffRequestSchema>) => {