@tencent-ai/agent-sdk 0.3.263-dev.90f0e98.202609190050 → 0.3.263

package/cli/dist-server/types/node/agent-task/categorize-failure.d.ts

@@ -1,65 +0,0 @@
-/**
- * Pure helpers for classifying and sanitizing teammate sub-agent failures.
- *
- * Part of Issue 5 (teammate auth failure propagation):
- *   docs/workbuddy/fix/task-status-sync/issue-5-teammate-auth-failure.md
- *
- * `categorizeFailure` is used by AgentTask.execute()'s failed branch to tag
- * the failure with a coarse category; `sanitizeErrorForPrompt` strips out
- * credentials / URL query strings before the reason is forwarded to UI or
- * injected into the team-lead system prompt.
- *
- * Both functions are pure, synchronous, and have no runtime dependencies so
- * they are straightforward to unit-test.
- */
-export type TeammateFailureCategory = 'auth' | 'network' | 'model' | 'unknown';
-/**
- * Canonical error message used throughout `agent-task.ts` when the user
- * actively cancels a running sub-agent (e.g. pressing Esc / Ctrl+C, or the
- * UI sending an interrupt). Exported as a constant so producers and the
- * `isUserInterruption` predicate stay in sync — drift here would silently
- * regress the "interrupted ≠ failed" classification (Issue 5 follow-up).
- */
-export declare const TASK_INTERRUPTED_BY_USER_MESSAGE = "Task was interrupted by user";
-/**
- * Identify whether a thrown error represents a **user-initiated**
- * interruption (Esc / Ctrl+C / UI cancel) as opposed to a real sub-agent
- * failure.
- *
- * Used by `AgentTask.execute()`'s catch branch to route interruptions to
- * `cancelled` (a benign terminal state) instead of `failed`. A failed
- * teammate would otherwise get its `lastFailure` recorded on the team
- * registry and surface as a `<teammate-failures>` block on the team-lead's
- * next turn — even though the teammate is healthy and will resume on the
- * next message.
- *
- * Detection is exact-match on `Error.message` because every producer in
- * `agent-task.ts` constructs the error via
- * `new Error(TASK_INTERRUPTED_BY_USER_MESSAGE)` (see the 5 reject sites in
- * `waitForAgentCompletion`). String-based fallback handles the rare case
- * where the same sentinel reaches us as a plain string.
- */
-export declare function isUserInterruption(error: unknown): boolean;
-/**
- * Classify a sub-agent failure into a coarse-grained category so the UI and
- * the team-lead prompt can adapt phrasing without needing to parse raw
- * model-provider errors.
- *
- * Detection is substring-based and case-insensitive; callers should treat
- * this as a best-effort hint rather than a contract.
- */
-export declare function categorizeFailure(error: unknown): TeammateFailureCategory;
-/**
- * Produce a version of the error message that is safe to embed into:
- *   - UI tooltips shown to the end user
- *   - `<teammate-failures>` system-reminder XML injected into team-lead prompts
- *
- * Responsibilities:
- *   1. Strip likely credentials (API keys, Bearer tokens, ?key=, etc.).
- *   2. Strip URL query strings entirely (they often carry auth / signatures).
- *   3. Collapse whitespace.
- *   4. Truncate to {@link ERROR_MESSAGE_MAX_LENGTH} characters.
- *
- * Never returns `undefined`. If the error is falsy, returns an empty string.
- */
-export declare function sanitizeErrorForPrompt(error: unknown): string;

package/cli/dist-server/types/node/agent-team/shutdown-coordinator.d.ts

@@ -1,98 +0,0 @@
-import type { TeamMember } from './team-member';
-/**
- * Shutdown Coordinator
- * ====================
- *
- * Block C of the "align CC Agent Teams three gaps" MR.
- *
- * Leader-side orchestration for graceful teammate shutdown with a
- * fail-safe force-kill. CC sends `shutdown_request` via mailbox and
- * *waits indefinitely* — if the teammate model never responds (hung,
- * crashed mid-turn, ignored the request), the pending request leaks.
- * cbc closes that gap by adding a timeout that force-kills the teammate
- * if no `shutdown_response` arrives within
- * `CODEBUDDY_TEAM_SHUTDOWN_GRACEFUL_TIMEOUT_MS` (default 15s).
- *
- * Public shape:
- *
- *   const coord = ContainerUtil.get<ShutdownCoordinator>(ShutdownCoordinator);
- *   const outcome = await coord.shutdown(member, { reason, timeoutMs });
- *   // outcome: 'approved' | 'rejected' | 'timeout' | 'forced' | 'not-alive'
- *
- * `fulfillResponse(requestId, approved, reason?)` is invoked from the
- * SendMessageTool's `handleShutdownResponse` path when a teammate replies
- * — it matches the requestId into the pending map and resolves.
- *
- * Integration with Block A:
- *   - Optional `waitForIdleFirst: true` — the coordinator waits up to a
- *     third of `timeoutMs` for the teammate to become idle before
- *     sending shutdown_request. Gives well-behaved teammates a chance
- *     to finish the current turn cleanly.
- *
- * env:
- *   - `CODEBUDDY_TEAM_SHUTDOWN_GRACEFUL_TIMEOUT_MS=15000` (default)
- *   - Set to `0` to disable fail-safe forceKill (CC parity — wait forever)
- */
-export declare const ShutdownCoordinator: unique symbol;
-export type ShutdownOutcome = 'approved' | 'rejected' | 'timeout' | 'forced' | 'not-alive';
-export interface ShutdownOptions {
-    /** Short reason string forwarded into the shutdown_request payload. */
-    reason?: string;
-    /**
-     * Wall-clock ms budget. `undefined` → read env default. `0` → disable
-     * fail-safe (wait indefinitely, resolve 'timeout' only if cancelAll
-     * fires).
-     */
-    timeoutMs?: number;
-    /**
-     * If true, coord.shutdown() first awaits `tracker.waitForIdle(..., timeoutMs/3)`
-     * so the teammate can drain the current turn. Relevant only if Block A
-     * tracker is enabled (otherwise no-op and continues immediately).
-     */
-    waitForIdleFirst?: boolean;
-}
-export interface ShutdownCoordinator {
-    /**
-     * Orchestrated shutdown for a single teammate. Never throws; always
-     * resolves an outcome string.
-     */
-    shutdown(member: TeamMember, opts?: ShutdownOptions): Promise<ShutdownOutcome>;
-    /**
-     * Called from `SendMessageTool.handleShutdownResponse` when a teammate
-     * writes a shutdown_response to the leader mailbox. Looks up the
-     * requestId and resolves the pending promise.
-     *
-     * Returns `true` if the requestId matched a pending shutdown, `false`
-     * if no match. Callers (e.g. the lead-inbox poller) use this to decide
-     * whether the response was an "internal" coordinator-driven shutdown
-     * (match → silently consume) or a "tool-driven" shutdown initiated by
-     * the LLM lead via SendMessage(type=shutdown_request) (no match → the
-     * lead has no pending promise to resolve, so the response should be
-     * surfaced into the lead session as a teammate message instead of
-     * being silently dropped).
-     *
-     * Unknown requestId → logged + return `false` (safe: the pending slot
-     * may have timed out already, or the request was tool-initiated).
-     */
-    fulfillResponse(requestId: string, approved: boolean, reason?: string): boolean;
-    /**
-     * Cancel every pending shutdown request (e.g. leader exit / team
-     * deletion). All pending promises resolve 'timeout' (NOT 'forced' —
-     * caller is responsible for subsequent forceKill).
-     */
-    cancelAll(reason: string): void;
-}
-export declare function resolveShutdownTimeoutMs(): number;
-export declare class ShutdownCoordinatorImpl implements ShutdownCoordinator {
-    private readonly logger;
-    private readonly pending;
-    constructor();
-    shutdown(member: TeamMember, opts?: ShutdownOptions): Promise<ShutdownOutcome>;
-    fulfillResponse(requestId: string, approved: boolean, reason?: string): boolean;
-    cancelAll(reason: string): void;
-    private onTimeout;
-    private resolvePending;
-    private waitIdleBestEffort;
-    private canReceiveShutdown;
-    private newRequestId;
-}

package/cli/dist-server/types/node/agent-team/team-runtime-adopter.d.ts

@@ -1,13 +0,0 @@
-import { type Session } from '../../vendor/cbc-core/node/index.js';
-import { type AgentInputItem } from '../../vendor/cbc-shared/node/index.js';
-import type { Logger } from '@genie/telemetry';
-import { type TeamConfig } from './team-protocol';
-import { type TeamRuntimeManifest } from './team-runtime-manifest';
-export interface TeamRuntimeAdoption {
-    manifest: TeamRuntimeManifest;
-    config: TeamConfig;
-    adoptedMembers: string[];
-    unresumableMembers: string[];
-}
-export declare function adoptTeamRuntimeForSession(session: Session, logger?: Logger): Promise<TeamRuntimeAdoption | undefined>;
-export declare function buildTeamRuntimeResumeInput(session: Session, adoption?: TeamRuntimeAdoption, logger?: Logger): AgentInputItem | undefined;

package/cli/dist-server/types/node/agent-team/team-runtime-manifest.d.ts

@@ -1,66 +0,0 @@
-import type { TeammateBackendType } from './backends/teammate-backend-protocol';
-import type { TeamConfig, TeamMemberInfo } from './team-protocol';
-export declare const TEAM_RUNTIME_MANIFEST_VERSION = 1;
-export declare const TEAM_RUNTIME_MANIFEST_FILE = "runtime.json";
-export type TeamRuntimeStatus = 'active' | 'paused_after_cancel' | 'completed' | 'cancelled';
-export type TeamRuntimeMemberStatus = 'running' | 'idle' | 'paused' | 'completed' | 'failed' | 'cancelled' | 'killed' | 'unresumable';
-export type TeamRuntimeMemberLifecycle = 'alive' | 'terminated';
-export interface TeamRuntimeMember {
-    name: string;
-    agentId: string;
-    taskId?: string;
-    agentType: string;
-    backendType: TeammateBackendType;
-    model?: string;
-    prompt?: string;
-    cwd?: string;
-    color?: string;
-    permissionMode?: string;
-    planApproved?: boolean;
-    maxTurns?: number;
-    taskDescription?: string;
-    resumeSessionId?: string;
-    transcriptPath?: string;
-    status: TeamRuntimeMemberStatus;
-    /** Logical actor lifecycle. Missing in legacy v1 manifests means alive. */
-    lifecycle?: TeamRuntimeMemberLifecycle;
-    updatedAt: number;
-}
-export interface TeamRuntimeManifest {
-    version: typeof TEAM_RUNTIME_MANIFEST_VERSION;
-    teamName: string;
-    leadSessionId: string;
-    leadAgentId: string;
-    createdAt: number;
-    updatedAt: number;
-    status: TeamRuntimeStatus;
-    members: TeamRuntimeMember[];
-}
-export interface TeamRuntimeMemberRecordOptions {
-    taskId?: string;
-    status?: TeamRuntimeMemberStatus;
-    /** Permanent logical shutdown is monotonic for one durable member identity. */
-    lifecycle?: 'terminated';
-    permissionMode?: string;
-    planApproved?: boolean;
-    maxTurns?: number;
-    taskDescription?: string;
-}
-export interface TeamRuntimeLookupResult {
-    manifest: TeamRuntimeManifest;
-    member: TeamRuntimeMember;
-}
-export declare function getTeamRuntimeManifestPath(teamName: string): string;
-export declare function getTeamMemberTranscriptPath(leadSessionId: string, taskId: string): string;
-export declare function readTeamConfig(teamName: string): Promise<TeamConfig | undefined>;
-export declare function findTeamConfigByLeadSessionId(leadSessionId: string): Promise<TeamConfig | undefined>;
-export declare function readTeamRuntimeManifest(teamName: string): Promise<TeamRuntimeManifest | undefined>;
-export declare function writeTeamRuntimeManifest(manifest: TeamRuntimeManifest): Promise<void>;
-export declare function createTeamRuntimeManifest(config: TeamConfig, status?: TeamRuntimeStatus): TeamRuntimeManifest;
-export declare function ensureTeamRuntimeManifest(config: TeamConfig, status?: TeamRuntimeStatus): Promise<TeamRuntimeManifest>;
-export declare function recordTeamRuntimeMember(teamName: string, leadSessionId: string, leadAgentId: string, member: TeamMemberInfo, options?: TeamRuntimeMemberRecordOptions): Promise<TeamRuntimeManifest>;
-export declare function updateTeamRuntimeMemberStatus(teamName: string, memberName: string, status: TeamRuntimeMemberStatus): Promise<void>;
-export declare function markTeamRuntimePausedAfterCancel(teamName: string, leadSessionId?: string): Promise<void>;
-export declare function markTeamRuntimeActiveAfterHumanResume(teamName: string, leadSessionId?: string): Promise<void>;
-export declare function findTeamRuntimeManifestByLeadSessionId(leadSessionId: string): Promise<TeamRuntimeManifest | undefined>;
-export declare function findTeamRuntimeMemberByReference(reference: string, leadSessionId?: string): Promise<TeamRuntimeLookupResult | undefined>;

package/cli/dist-server/types/node/agent-team/team-runtime-status.d.ts

@@ -1,34 +0,0 @@
-import type { Session } from '../../vendor/cbc-core/node/index.js';
-import { type TeamRuntimeLookupResult, type TeamRuntimeManifest, type TeamRuntimeMember, type TeamRuntimeMemberLifecycle, type TeamRuntimeMemberStatus, type TeamRuntimeStatus } from './team-runtime-manifest';
-export interface TeamRuntimeMemberStatusView {
-    name: string;
-    agentId: string;
-    taskId?: string;
-    agentType: string;
-    backendType: TeamRuntimeMember['backendType'];
-    status: TeamRuntimeMemberStatus;
-    lifecycle: TeamRuntimeMemberLifecycle;
-    taskDescription?: string;
-    updatedAt: number;
-    canResume: boolean;
-    pausedAfterCancel: boolean;
-}
-export interface TeamRuntimeStatusView {
-    teamName: string;
-    leadSessionId: string;
-    leadAgentId: string;
-    status: TeamRuntimeStatus;
-    updatedAt: number;
-    pausedAfterCancel: boolean;
-    hasPausedMembers: boolean;
-    hasResumablePausedMembers: boolean;
-    members: TeamRuntimeMemberStatusView[];
-}
-export interface TeamRuntimeMemberLookupStatus extends TeamRuntimeLookupResult {
-    runtime: TeamRuntimeStatusView;
-    memberStatus: TeamRuntimeMemberStatusView;
-}
-export declare function toTeamRuntimeMemberStatus(member: TeamRuntimeMember, manifest: TeamRuntimeManifest): TeamRuntimeMemberStatusView;
-export declare function toTeamRuntimeStatus(manifest: TeamRuntimeManifest): TeamRuntimeStatusView;
-export declare function readTeamRuntimeStatus(teamName: string, session?: Session): Promise<TeamRuntimeStatusView | undefined>;
-export declare function findTeamRuntimeMemberStatus(reference: string, leadSessionId?: string): Promise<TeamRuntimeMemberLookupStatus | undefined>;

package/cli/dist-server/types/node/agent-view/agent-view-actions.d.ts

@@ -1,205 +0,0 @@
-import { type AgentJobState, type AgentJobView, type IJobStore } from './agent-view-protocol';
-export interface AgentViewActionDeps {
-    store: IJobStore;
-    /** 复用 DaemonProcessManager 的 detached fork 与信号能力 */
-    processManager: {
-        forkBgSession(args: string[], options: {
-            name?: string;
-            cwd?: string;
-            extraEnv?: Record<string, string>;
-            skipPrintMode?: boolean;
-            jobWorker?: boolean;
-        }): Promise<{
-            pid: number;
-            logPath: string;
-        }>;
-        sendSignal(pid: number, signal: NodeJS.Signals): boolean;
-        isProcessRunning(pid: number): boolean;
-        waitForExit(pid: number, timeoutMs?: number): Promise<boolean>;
-    };
-    /** 日志目录，shell job 的输出落在这里 */
-    logDir: string;
-    /**
-     * Optional override for tests. Default: kill(0) + process-start identity.
-     * Identity mismatch ⇒ not alive (do not signal).
-     */
-    isJobProcessAlive?(pid: number | undefined, identity: {
-        procStart?: string | null;
-        procStartFt?: string | null;
-    } | undefined): Promise<boolean>;
-}
-export interface DispatchOptions {
-    prompt: string;
-    cwd: string;
-    /** 指定主 agent */
-    agent?: string;
-    /** 覆盖模型 */
-    model?: string;
-    /** 覆盖权限模式 */
-    permissionMode?: string;
-    /** 覆盖推理投入档位 */
-    effort?: string;
-    /** 用户显式命名 */
-    name?: string;
-    /** 后台首次写文件时是否自动进入隔离 worktree；缺省继续跟随 TUI/全局设置。 */
-    bgIsolation?: 'none' | 'worktree';
-    /**
-     * 注入到首条 prompt 之前的隐藏上下文（如主会话受限预览）。
-     * 只进入 spawn 的位置参数；intent/initialPrompt 保持干净 prompt，
-     * 标题与列表不受污染。
-     */
-    contextPrefix?: string;
-    /**
-     * 打开 agent view 时给的配置 flag（`--effort` / `--settings` / `--add-dir`
-     * / `--plugin-dir` / `--mcp-config` / `--strict-mcp-config` 等）。
-     * 文档要求这些 flag 既作用于视图自身也透传给它派发的每个会话。
-     */
-    extraFlags?: readonly string[];
-}
-export interface DispatchResult {
-    id: string;
-    pid: number;
-    logPath: string;
-}
-export interface DispatchLifecycle {
-    /**
-     * The durable job record now exists and can be selected by clients. Process
-     * startup intentionally happens afterwards so HTTP callers do not wait for
-     * the worker to finish booting before entering the agent view.
-     */
-    onJobCreated?: (job: {
-        id: string;
-        sessionId: string;
-    }) => void | Promise<void>;
-    /** Keep an already-visible row restartable when worker startup fails. */
-    keepJobOnStartupFailure?: boolean;
-}
-/**
- * 派发一个新的后台会话。
- *
- * 顺序很关键：先生成 sessionId 并建好 job 目录，再 fork。
- * 反过来的话子进程可能在 job 目录存在之前就开始汇报状态，
- * 那些汇报会静默丢掉，行上就会一直停在 "starting…"。
- */
-export declare function dispatchBackgroundSession(deps: AgentViewActionDeps, options: DispatchOptions, lifecycle?: DispatchLifecycle): Promise<DispatchResult>;
-/**
- * 把一个历史会话作为后台 job 重新挂回列表（agent view 里的 `/resume` picker）。
- *
- * 靠 `--resume <sessionId>` 拉起常驻 worker：只恢复历史、不重放任何 prompt，
- * 回来后停在 idle 等你下一句话（与 respawn 同构，但这里 job 记录是新建的
- * —— 之前它可能已从列表删除，只剩磁盘上的 transcript）。
- */
-export declare function resumeSessionAsJob(deps: AgentViewActionDeps, options: {
-    sessionId: string;
-    cwd: string;
-    name?: string;
-    extraFlags?: readonly string[];
-}): Promise<DispatchResult>;
-/**
- * 还没开过 1:1 的同事：起一个空会话 job，停在 idle 等收件箱。
- * 不把频道信封当位置参数（那会画成用户气泡）。
- */
-export declare function spawnIdleBackgroundSession(deps: AgentViewActionDeps, options: {
-    cwd: string;
-    name?: string;
-    agent?: string;
-    /** 这个同事固定跑哪个模型 / 权限模式（建人时定，随 respawnArgs 一起持久化）。 */
-    model?: string;
-    permissionMode?: string;
-}): Promise<DispatchResult>;
-/**
- * 派发一个 shell job（输入框 `!` 前缀）。
- *
- * 不调用模型，输出也不进任何会话——就是把一条命令挂在后台跑，
- * 行上显示它最近一行输出。
- */
-export declare function dispatchShellJob(deps: AgentViewActionDeps, options: {
-    command: string;
-    cwd: string;
-}): Promise<DispatchResult>;
-/**
- * 读取日志尾部的若干非空行。
- *
- * 后台会话跑在 `-p` 模式下，模型的最终回答就是它写到日志里的内容，
- * 所以这是"不发起额外模型请求就能拿到结果摘要"的唯一来源
- * （对齐 Claude 的 15 秒无请求刷新路径）。
- */
-export declare function readLogTailLines(logPath: string, maxLines?: number): Promise<string[]>;
-/** 读取日志最后一行，作为 shell job 的行内摘要 */
-export declare function readLogTailLine(logPath: string): Promise<string | undefined>;
-/** 停止会话进程并把状态标记为 stopped */
-export declare function stopJob(deps: AgentViewActionDeps, job: AgentJobView): Promise<void>;
-export interface DeleteJobResult {
-    deleted: boolean;
-    /** 未删除时的原因，会渲染成行内 `not deleted` 提示 */
-    reason?: string;
-    /** 会话已删但 worktree 目录被保留在盘上时，报出它的路径 */
-    keptWorktreePath?: string;
-}
-/** 判断 worktree 能否安全移除。返回 undefined 表示可以删 */
-export type WorktreeGuard = (job: AgentJobView) => Promise<string | undefined>;
-export interface DeleteJobOptions {
-    worktreeGuard?: WorktreeGuard;
-    /**
-     * 守卫放行后移除会话代管的 worktree（含未提交更改）。
-     * 抛错表示目录被保留 —— 会话照删，路径途经 keptWorktreePath 报出。
-     */
-    removeWorktree?: (worktreePath: string) => Promise<void>;
-}
-/**
- * 删除会话。
- *
- * 会话与它的 worktree 是绑定的：守卫拒绝（未推送 commit / 他会话占用）时
- * 会话也必须留下，否则用户就再也找不到那些提交在哪了（行上会显示
- * `not deleted` + 原因）。守卫放行后删会话，再尽力移除代管 worktree；
- * 移除失败（如 git 已不认识它）不回滚删除，只报出被保留的路径。
- */
-export declare function deleteJob(deps: AgentViewActionDeps, job: AgentJobView, options?: DeleteJobOptions | WorktreeGuard): Promise<DeleteJobResult>;
-/**
- * 重启会话，保留对话。
- *
- * 靠 `--resume <sessionId>` 让新进程接上原来的 transcript；
- * respawnArgs 里的模型/权限/agent 参数原样回放，避免重启后行为漂移。
- */
-export declare function respawnJob(deps: AgentViewActionDeps, job: AgentJobView): Promise<DispatchResult>;
-/** 去掉位置参数，只留 `--flag` 与它们的值 */
-export declare function stripPositionalArgs(args: readonly string[]): string[];
-export interface SendReplyResult {
-    /** 已写入收件箱，运行中的会话会消费 */
-    delivered: boolean;
-    /** 进程不在，已存为下次启动的首个 prompt */
-    saved: boolean;
-    /** 给用户看的提示 */
-    notice: string;
-}
-/**
- * 把回复送给一个会话。
- *
- * 进程活着就进收件箱，由会话进程内的 `JobInboxConsumer` 走**逻辑消息通道**
- * 送进对话（不是往 PTY 里模拟按键——那会在权限框、AskUserQuestion 之类的
- * 对话框上变成误操作）。进程已退出则存成 pending，会话下次启动时补发。
- *
- * `!` 开头的 Bash 回复两条路都走不了：会话层没有 `!` 这个概念，
- * 送过去只会以纯文本抵达，"执行命令"就变成了"说了句话"，属于静默错误。
- * 所以明确拒绝，并告诉用户去哪儿才能执行。
- */
-export declare function sendReply(deps: AgentViewActionDeps, job: AgentJobView, reply: {
-    text: string;
-    bash?: boolean;
-}): Promise<SendReplyResult>;
-export interface AttachHandoff {
-    /** 要执行的 CLI 入口 */
-    entry: string;
-    /** 传给入口的参数 */
-    args: string[];
-    /** 子进程工作目录 */
-    cwd: string;
-}
-/**
- * 构造"接管一个会话"的启动参数。
- *
- * agent view 与后台会话是两个进程，接管的实现是在当前终端里用
- * `--resume <sessionId>` 拉起完整交互会话——transcript 已经在盘上，
- * 所以对话历史是完整的，不是只看日志。
- */
-export declare function buildAttachHandoff(job: AgentJobState, entry: string): AttachHandoff;

package/cli/dist-server/types/node/agent-view/job-reclaim-gate.d.ts

@@ -1,13 +0,0 @@
-export declare class JobReclaimGate {
-    private active;
-    private revision;
-    private draining;
-    private committed;
-    enter(): () => void;
-    prepare(): number | undefined;
-    isPrepared(revision: number): boolean;
-    commit(revision: number): boolean;
-    cancel(revision: number): void;
-}
-export declare const jobReclaimGate: JobReclaimGate;
-export declare function enterJobActivity(): () => void;

package/cli/dist-server/types/node/ask/index.d.ts

@@ -1,3 +0,0 @@
-export * from './ask-protoctol';
-export * from './ask-service';
-export * from './session-ask-user-question-handler';

package/cli/dist-server/types/node/bash-sandbox/index.d.ts

@@ -1,4 +0,0 @@
-export * from './bash-sandbox-protocol';
-export * from './bash-sandbox-manager';
-export * from './legacy-sandbox-shell-protocol';
-export * from './legacy-sandbox-shell-service';

package/cli/dist-server/types/node/code-ratio/cli-git-commit-watcher.d.ts

@@ -1,159 +0,0 @@
-import { Application, ApplicationLifecycle } from '@celljs/core';
-import { type ICwdService } from '@genie/cbc-worktree';
-import { ProductManager } from '@genie/product';
-/**
- * CLI 端的 git commit 监听 + 上报。
- *
- * 设计要点（对齐 plugin-core 但只做 CLI 必要的部分）：
- *
- *   - **多仓**：从 `process.cwd()` 出发发现「全部」git 仓库——
- *     既兼容「直接打开仓库（或其子目录）」（沿父链向上找 `.git`），
- *     也兼容「打开一个父目录、其下挂多个独立仓库」（向下有限层扫描）。
- *     每个仓库各自监听 `.git/logs/HEAD`、各自维护 lastHead、各自上报。
- *   - 监听 `.git/logs/HEAD`（reflog）：覆盖手动 `git commit` / agent Bash 工具
- *     发起的 commit / `git commit --amend` / rebase 等所有动 HEAD 的操作。
- *   - 进程退出前再 flush 一次：CLI 是短命进程，最后一次 commit 完成到 fs.watch
- *     回调真正触发之间可能有几十 ms 间隙，由 watcher.flushOnExit() 兜底。
- *   - lastHead 持久化到 `~/.codebuddy/code-ratio/cli-watcher-lastHead-<hash>`（按 repoRoot 区分）：
- *     CLI 重启后能识别"上次跑完之后又有新 commit"并补上报，避免漏；同时也避免
- *     启动瞬间把当前 HEAD 当成新 commit 重复报。
- *   - feature gate 不在 watcher 里判：`reporter.observeCommit()` 已经做过
- *     `isCodeAdoptionRateEnabled` 检查，运行时切换开关也能立即生效。
- */
-export declare class CliGitCommitWatcher implements ApplicationLifecycle<Application> {
-    protected readonly productManager?: ProductManager;
-    protected readonly cwdService?: ICwdService;
-    private logger?;
-    private readonly repos;
-    /** feature gate 是否已判定 enabled 并触发过挂载，保证只挂一次（幂等）。 */
-    private gateResolved;
-    /** 等待 late-enable 的配置订阅（未启用时挂，enabled 后退订）。 */
-    private gateSubscription?;
-    /** cwd 变更订阅（首轮种子值 attach、之后变更重绑）。 */
-    private cwdChangeSubscription?;
-    /** 标记是否已完成首轮 attach，区分种子值与后续 cwd 变更。 */
-    private attachedOnce;
-    initialize(): void;
-    /**
-     * 入库率 feature gate + late-enable 订阅（对齐 plugin-core GitCommitWatcher）。
-     *
-     * 仓库发现扫描（readdirSync 递归）、watcher attach、startup 扫描的开销都在
-     * feature gate 之后才发生——未启用入库率能力时，进程**完全不做**仓库发现，
-     * 避免预热池默认开启后对错误继承的 home 目录做大量无意义扫描。
-     *
-     * ProductManager 未注册（headless / 单测）时保守退回：直接走 cwd 订阅，
-     * 不阻断原有采集路径。
-     */
-    private mountWhenEnabled;
-    /**
-     * 订阅 cwd 变更，把 attach 绑到最新 cwd（对齐 ConfigWatchService）。
-     *
-     * BehaviorSubject 语义：订阅瞬间即收到「当前 cwd」种子值 → 首轮 attach；
-     * 之后任何 setCwdState（预热 activate 后 chdir、worktree 切换）都会再次推送
-     * → 先 dispose 旧 watcher 再按新 cwd 重新 attach。
-     *
-     * **预热待机特判**：预热进程容器装配阶段 initialize 时，cwd 还是错误继承的
-     * home，种子值此刻不能 attach。用 {@link isPrewarmStandby} 判定「仍在待机」
-     * （argv 含 `--prewarm` 且 PrewarmServer 状态为 idle），是则跳过本次种子值、
-     * 不置 attachedOnce；等 activate 到达后 dispatcher 的 `setCwdState(cwd, true)`
-     * 广播（此刻状态已转为 activating，不再判为待机）再走首轮 attach，天然绑定
-     * 到正确的 workspace cwd。
-     *
-     * CwdService 未注册（单测）时退回：直接 attach 一次。
-     */
-    private subscribeCwd;
-    /**
-     * 是否仍处于预热（prewarm）待机态：argv 含 `--prewarm` 且 PrewarmServer 状态
-     * 为 `idle`（尚未收到 activate）。
-     *
-     * 组合两个条件而非单看其一：
-     * - 只看 argv：普通冷启动本就无 `--prewarm`，天然不受影响；但预热 activate 后
-     *   dispatcher 在广播 cwd（`setCwdState`）之后才剔除 argv 里的 `--prewarm`，
-     *   若只看 argv 会把 activate 的首个广播也误判为待机。
-     * - 只看状态：非预热进程容器里 PrewarmServer 的初始状态也是 `idle`，只看状态
-     *   会把普通启动误判为待机 → 永不 attach。
-     * 因此以 argv 圈定「这是预热进程」，再用状态 `idle` 精确圈定「尚未 activate」。
-     * activate 一到，PrewarmServer 立即置 `activating`（早于 cwd 广播），故广播时
-     * 本方法返回 false，首轮 attach 正常发生并绑定到正确 cwd。
-     *
-     * PrewarmServer 未注册（headless / 单测）时按「非待机」处理，不影响普通路径。
-     */
-    private isPrewarmStandby;
-    /**
-     * 暴露给 process.ts 的 exit 钩子调用，确保最后一个 commit 不会被丢。
-     * 永不抛错。
-     */
-    flushOnExit(): Promise<void>;
-    /**
-     * 让 Bash 工具的 post-exec hook 在跑完 `git commit` 后立即调一下，
-     * 不必等 reflog 事件。永不抛错。
-     */
-    notifyExternalGitCommit(): Promise<void>;
-    /** 关闭 watcher（测试 / 后续若引入显式 deactivate 时使用）。 */
-    dispose(): void;
-    /**
-     * 关闭并清空所有仓库 watcher/timer，但**不**退订 gate/cwd。
-     * 供 cwd 变更重绑复用（先 disposeWatchers 再 attachAll），dispose() 也调用它。
-     */
-    private disposeWatchers;
-    private attachAll;
-    private attachRepo;
-    private scheduleScan;
-    /**
-     * 读 HEAD → 跟 lastHead 比 → 如果是新 commit 就走 `loadCommit` 上报。
-     *
-     * 若 HEAD↔lastHead 之间相差多个 commit（比如启动时补差量、rebase 后），
-     * 用 `git rev-list lastHead..HEAD` 列出来按时间正序逐个上报，每个都加内存
-     * 去重 + 持久化。失败时不更新 lastHead，下次再尝试。
-     */
-    private checkAndReport;
-    /**
-     * 计算需要上报的 commit 序列，时间正序。
-     *
-     *   - lastHead 缺失：只取 HEAD 一个。
-     *   - lastHead 存在但 git rev-list 失败（被 git gc / rebase 抹掉）：fallback 也只取 HEAD。
-     */
-    private listNewCommits;
-    /**
-     * 上报单个 commit。
-     *
-     * 返回值语义：
-     *   - `true`：成功上报
-     *   - `false`：明确不可归因（merge、initial、无文件、无 repoUrl 等），可安全跳过
-     *   - `'failed'`：上报失败（网络/内部错误），需要保留游标重试
-     */
-    private reportOne;
-    /** 懒加载并缓存某仓库本地 `git config user.email`（归一化后）。读不到返回空串。 */
-    private resolveLocalGitEmail;
-    private trimReportedCache;
-}
-/**
- * 从 `cwd` 发现需要监听的全部 git 仓库根：
- *
- *   1. 先沿父链向上找：若 `cwd` 本身或其某个祖先是 git 仓库，则视为「打开了仓库
- *      （或其子目录）」，直接返回该唯一根。
- *   2. 否则向下有限层扫描子目录，把每个 git 仓库根收集出来，命中后剪枝不再深入。
- *
- * 实际扫描逻辑复用 `discoverVcsRoots`（git/svn 通用），这里只注入 git 专属判定。
- */
-export declare function discoverGitRepos(cwd: string, deps?: GitRepoDiscoveryDeps): string[];
-export interface GitRepoDiscoveryDeps {
-    /** 沿父链向上找仓库根；默认用 `findRepoRootFromCwd`。 */
-    findUpRoot?: (startPath: string) => string | undefined;
-    /** 判断某目录是否是 git 仓库根；默认用 `GitInfoExtractor.isGitRepository`。 */
-    isRepo?: (dir: string) => boolean;
-    /** 列出某目录下的直接「子目录绝对路径」；默认走 fs.readdirSync。 */
-    listSubdirectories?: (dir: string) => string[];
-    /** 向下扫描最大深度。 */
-    maxDepth?: number;
-    /** 发现的仓库数量上限。 */
-    maxRepos?: number;
-    /** 诊断回调：把扫描过程打到日志。 */
-    onTrace?: (msg: string) => void;
-}
-/**
- * 从 cwd 起向上找最近的 git 仓库根。复用 GitInfoExtractor 已有的判定，与
- * `CwdRepoResolver.findRepoRoot` 行为一致；这里不直接 import 后者，避免
- * 把 watcher 的可测试性绑死在带状态的 resolver 上。
- */
-export declare function findRepoRootFromCwd(startPath: string): string | undefined;