@y9931666/dsh-plugin-crossfire 0.1.1 → 0.1.3

package/lib/types/engine.d.ts

@@ -1,172 +0,0 @@
-/**
- * 评审引擎：不依赖 `exec.agent` 的核心动作。
- *
- * ## 为什么需要它
- *
- * 工具（`tools.ts`）和浏览器 RPC（`rpc.ts`）必须能驱动**同一套**状态机 —— 这正是
- * O1 决策（卡片按钮直推 host，不等 AI 回合）的落点。工具拿到的是 `exec.agent`，
- * RPC 拿到的是 `sessionId`，两者唯一的公共面就是"一段纯逻辑 + 一个 ctx"。
- *
- * 所以这里放的是：**凡是两条入口都需要、且复制一份就会分叉的**逻辑。
- * - {@link planExperts}：按强度档与维度算阵容（决定谁去攻击）；
- * - {@link collectDefects}：拆分 + 噪音过滤 + 维度归一化 + 历史去重（决定用户看到
- *   什么）—— 这一块是整个插件里最容易分叉的地方，所以它是单点实现。
- *
- * 不放在这里的是：状态机门禁、写盘时序、专家拉起（那些短且各自语境不同）。
- *
- * @module dsh-plugin-crossfire/engine
- */
-import { type ReviewSplitConfig, type SplitLlmLike } from './split.ts';
-import type { CrossfireRecord, Defect, ExpertUtterance, RedTeamExpert } from './types.ts';
-/**
- * 一位专家的"人选来源"：把用户偏好里的角色 / 模型路由喂给阵容规划。
- *
- * ## 为什么需要它（这是红队评审抓出的真实缺陷）
- *
- * 设置页的角色预设与阵容预设此前是**只写不读**的：`preferences.ts` 存了它们，
- * `SettingsView` 能增删改，但 `planExperts` 从不消费 —— 于是"编辑专家提示词"这件事
- * 在数据上根本没有出口，`expert.provider`/`expert.model` 也永远缺席（快照里那个
- * 品牌块因此只能显示中性 `?`）。这里把它接上。
- */
-export interface ExpertRosterEntry {
-    /**
-     * 匹配键：与**维度名**比较。
-     *
-     * 用维度名而不是顺序匹配，是因为维度是用户直接输入的东西，而阵容成员的 `key`
-     * 本来就是自由文本（设置页提示了"专家 key"）—— 让 key 就是维度名是最省心的用法。
-     * 匹配不到时退回**顺序**兜底（见 {@link planExperts}），两种写法都能用。
-     */
-    key: string;
-    /** 用户补充的角色定位（进 persona 的「你的角色定位」段）。 */
-    role?: string;
-    provider?: string;
-    model?: string;
-    /**
-     * 预设名（只有角色预设带它）。
-     *
-     * 角色预设的主标识是 `name`，阵容成员的主标识是 `key`；这一层刻意**两种都收**，
-     * 于是调用方不必先做一次形状转换 —— 形状分歧是缺陷的温床（红队抓出的"预设只写
-     * 不读"就属于这类缝隙）。
-     */
-    name?: string;
-}
-/**
- * 按强度档与维度算出这一轮要拉起谁。
- *
- * 纯函数（可单测）：同样一份记录 + 同一份 roster 永远得到同一份阵容。规模上限按
- * `record.dimensions` 的顺序截断，所以**用户排在前面的维度优先** —— 这是可预期的，
- * 而不是随机丢人。
- *
- * 人选来源两条，按优先级：
- * 1. `roster` 里 `key` 等于维度名的那一条（精确指定，最符合直觉）；
- * 2. 否则按**顺序**取 roster 的第 i 条（i = 维度序号）—— 用户不必把 key 改名成
- *    维度名也能用上一份现成的阵容；
- * 3. 都取不到时只写维度与状态（专家继承主持人路由、无补充定位），与从前完全一致。
- *
- * @param roster - 可选人选来源；缺席或为空时行为与从前逐字一致。
- */
-export declare function planExperts(record: CrossfireRecord, maxExperts: number, roster?: readonly ExpertRosterEntry[]): RedTeamExpert[];
-/** 一次收集的结果。 */
-export interface CollectOutcome {
-    added: Defect[];
-    /** 因为"用户上一轮驳回过"而被丢弃的条数。 */
-    droppedDuplicates: number;
-    /** 被噪音规则拦下的发言条数。 */
-    skippedNoise: number;
-    /** 真正调用过 LLM 拆分的次数（0 表示全部走了本地兜底）。 */
-    splitAttempts: number;
-    /** 已收集过、本次跳过的发言条数（幂等键命中）。 */
-    alreadyCollected: number;
-    /** 解析失败的转录行数（原样带回，不许静默吞掉）。 */
-    malformedLines: number;
-}
-/** 收集所需的输入。 */
-export interface CollectInput {
-    record: CrossfireRecord;
-    /** 转录条目（已过滤掉非对象/空内容）。 */
-    transcript: readonly ExpertUtterance[];
-    /** 转录里被丢弃的坏行数。 */
-    malformed: number;
-    /** LLM 服务；缺席时全部走本地启发式兜底。 */
-    llm?: SplitLlmLike;
-    splitConfig: ReviewSplitConfig;
-    /**
-     * 拆分阶段向 LLM 发起的最大并发数。
-     *
-     * **通常不必传**：缺省时读 `splitConfig.llmConcurrency`（再缺省才用 4），于是两个
-     * 调用方（工具 / RPC 直推）天然一致。显式传入只用于测试与排障（`1` = 回到串行）。
-     */
-    llmConcurrency?: number;
-}
-/**
- * 有界并发的 `map`（零依赖）。
- *
- * 为什么需要它：拆分一条发言要打一次 LLM（`split.ts` 每次 60s 超时），而此前是
- * **串行** `await` —— 一场 7 位专家、每人报告 3 次的评审 = 21 次串行往返，收集动作
- * 的墙钟时间 ≈ 21 × 单次往返（十秒级），期间界面只有一个禁用的"收集"按钮，既没有
- * 进度也没有取消（红队评审抓出的性能缺陷）。
- *
- * 并发上限刻意**不高**：这些请求打的是同一个 provider，并发拉满只会撞速率限制、
- * 反而更慢，而且要留出余量给界面自己的请求。
- *
- * 结果顺序与输入**逐位对应**（按下标回填，而不是按完成先后），所以拆出来的缺陷顺序
- * 与串行版本完全一致 —— 这是可测的，见 `test/engine.test.mjs`。
- */
-export declare function collectWithConcurrency<T, R>(items: readonly T[], limit: number, worker: (item: T, index: number) => Promise<R>): Promise<R[]>;
-/**
- * 把本轮专家发言收成逐条可裁决的缺陷。
- *
- * 五道处理，顺序有意义：
- * 1. **只收本轮**（`utterance.pass === record.reviewPass`）；
- * 2. **幂等**（`utteranceId` 已收集过就跳过 —— 拆分后 defect.id 会变，不能用作去重键）；
- * 3. **噪音过滤**（`auto-capture` 与进度汇报；真实数据里前者曾被当成缺陷收进裁决面）；
- * 4. **拆分**（LLM 三道防线优先 → 本地标记切分兜底 → 整条兜底 `seq = 0`）；
- * 5. **维度归一化 + 历史去重**（落库维度必须 ∈ 本次采用维度；上轮被驳回的观点不再弹）。
- *
- * 复审轮（`reviewPass > 1` 且已有历史）**不新增缺陷**：那一轮唯一的任务是核对旧账。
- */
-export declare function collectDefects(input: CollectInput): Promise<CollectOutcome>;
-/** 把用户偏好里的阵容与角色预设合成一份 roster。 */
-export declare function rosterFrom(input: {
-    /** 阵容预设（每套是一份完整方案；由调用方按 id 挑出要用的那一套传入）。 */
-    squads?: readonly {
-        id: string;
-        members: readonly ExpertRosterEntry[];
-    }[];
-    /** 角色预设（阵容缺席时的平铺来源）。 */
-    rolePresets?: readonly ExpertRosterEntry[];
-    /**
-     * 选中的阵容 id（可选）。
-     *
-     * 只认显式指定的那一个：`squads` 是**多个互斥的整体方案**（设置页里每个都是一套
-     * 完整成员），把几套混在一起会得到一个用户从没设计过的阵容。
-     *
-     * **缺席时自动采用第一套**（而不是全部不用）：用户只需要维护一份阵容、不必再回
-     * 设置页"选中"它 —— 少一步配置就少一处"我明明配了却不生效"的困惑。指定 id 不存在
-     * 或该套成员为空时，同样退回第一套；再没有就退回角色预设。
-     */
-    squadId?: string;
-}): ExpertRosterEntry[];
-/**
- * 把收集结果并入记录（原地修改；调用方负责落盘）。
- *
- * ## 幂等（A2）
- *
- * 此前是纯拼接（`[...record.defects, ...added]`），于是**同一条发言被收集两次**
- * 就在裁决面上出现两条一模一样的缺陷：重试、双击、两个并发请求都能触发它。
- * 用户面对的是一个"必须点两次驳回、理由还得写两遍"的列表。
- *
- * 现在按 `defect.id` 去重（`id` 由 `collectDefects` 从 `utteranceId` + 序号生成，
- * 因此同一批输入两次得到同一批 id）：**保留先到的那一条**，后来的同 id 项直接丢弃。
- * 保留先到的而不是新的，是因为"用户已经开始表态"的那一条不能被后来的副本顶掉
- * （缺陷的三态与驳回理由挂在 id 上，换掉实例等于丢掉已做出的判断）。
- *
- * `collectDefects` 里的 `utteranceId` 幂等键是第一道闸，这里的是第二道：前者防的是
- * "转录又被读了一遍"，后者防的是"合并写回被施加了同一批结果" —— 两道都需要，
- * 因为并发请求可以在第一道闸之后、第二道闸之前交错。
- *
- * @returns **实际追加的条数**（被去重丢弃的不算）。调用方必须如实上报这个数字，
- *          而不是 `added.length` —— 那会把"请求成功了但什么都没新增"报成
- *          "新增了 N 条"，用户看到条数却对不上列表。
- */
-export declare function applyCollected(record: CrossfireRecord, added: readonly Defect[]): number;

package/lib/types/etag.d.ts

@@ -1,40 +0,0 @@
-/**
- * 快照路由的条件请求支持（ETag / If-None-Match）。
- *
- * ## 要解决的问题
- *
- * 卡片每秒轮询快照，而一次快照的代价是"把工作区下所有评审的 `review.json` 读一遍并
- * **整包重发**"—— 其中绝大多数字节从未变化（红队评审抓出的性能缺陷）。
- *
- * 读盘那一半只能靠减少轮询次数缓解（已做：可见性感知 + 间隔放宽）。**传输**这一半
- * 可以用 ETag 解决：内容没变时返回 `304 Not Modified`，浏览器直接把已有响应交给
- * 调用方，省掉整个响应体的传输与解析。
- *
- * ## 为什么是弱校验
- *
- * 摘要只覆盖 `JSON.stringify(payload)` 的字节。同一份内容若换了键序就会算出不同的
- * ETag —— 那只会**少省一次**传输，不会给出错误数据（宁可多发，不可发错）。
- *
- * @module @y9931666/dsh-plugin-crossfire/etag
- */
-/** 计算一个内容摘要，用作 ETag 的取值（不带引号，由调用方按需包）。 */
-export declare function contentDigest(body: string): string;
-/** 最小化的响应面：只要能用任意状态码 + 响应头把 body 发出去。 */
-export interface ConditionalResponse {
-    writeHead(status: number, headers: Record<string, string>): unknown;
-    end(body?: string): unknown;
-}
-/**
- * 发送一个 JSON 响应，并在内容未变时改发 `304 Not Modified`。
- *
- * @param requestHeaders - 入站请求头（读 `if-none-match`）。
- * @returns `true` 表示请求已被处理（200 或 304 都已发出）；调用方**不要**再写响应。
- *
- * 两条边界：
- * - **没有 `if-none-match` 时行为与从前逐字相同**（只是多一个 ETag 头），所以这是
- *   可增量上线的改动；客户端不需要同时改。
- * - `cache-control` 用 `no-cache` 而不是 `no-store`：前者允许浏览器存副本但**每次
- *   都必须回源校验**（我们因此能收到 `if-none-match`），语义上依然是"不直接用陈旧
- *   数据"。`no-store` 会让浏览器根本不存，ETag 也就永远不会被回传。
- */
-export declare function sendJsonConditional(requestHeaders: Record<string, string | string[] | undefined>, res: ConditionalResponse, payload: unknown, status?: number): boolean;

package/lib/types/expert-events.d.ts

@@ -1,110 +0,0 @@
-/**
- * 专家子代理的生命周期接入。
- *
- * ## 为什么要这一层（来自圆桌的真实事故）
- *
- * 专家的产出**只在它主动提交的那一刻**才落盘。圆桌 v0-2-36 那场评审里，一位红队
- * 专家完成了大量取证，却在提交之前进程中断 —— 观点全丢，记录永久停在
- * `reviewing`、缺陷列表为空；9 条被拉起的路由里 4 条 0 产出，而插件只留下一个
- * `removed` 墓碑，没有任何失败原因，只能靠主持人用自然语言反复催办。
- *
- * 宿主其实把两件事递到手上：
- * - `subagent/end` 带 `lastAssistantMessage`，且可续聊子代理的**每一个 activation
- *   epoch** 都会发这个事件 —— 于是产出能在主动提交之外被自动捕获；
- * - 同一事件带 `stopReason`（`error` / `max-tokens` / `aborted` …），基础设施级
- *   失败时 `lastAssistantMessage` 为空；而 `agent/request-error` 进一步带
- *   `provider` 与 `failure: LlmFailure`（含 HTTP `status`），于是"为什么拉不起来"
- *   （额度、鉴权、模型名写错）可以被写成一条可读的专家备注。
- *
- * ## 与圆桌的关键差异
- *
- * 自动捕获的发言 kind 是 `auto-capture`，而 **`auto-capture` 绝不进入缺陷收集**
- * （见 noise.ts）：圆桌的真实数据里出现过 `[当前状态] 已收到主持人任务…`
- * 这类过程叙述被当成缺陷收进裁决列表，污染了用户的表态面。这里保留落盘（诊断
- * 价值真实存在），但收集阶段会把它过滤掉。
- *
- * 索引是**进程内**的：childId → (stateRoot, reviewId)。冷启动后的旧专家无法归属，
- * 这是刻意的 —— 宁可漏捕获，也不要把别的会话的文本写进评审记录。
- *
- * @module dsh-plugin-crossfire/expert-events
- */
-import type { Context } from '@deepseek-ai/cordis';
-import type { ContentBlock } from '@deepseek-ai/dsh-llm';
-/** 一位专家的评审在磁盘上的位置。 */
-export interface ExpertLocation {
-    stateRoot: string;
-    reviewId: string;
-}
-/** 记住一位刚被拉起的专家属于哪场评审。 */
-export declare function registerExpertChild(childId: string, location: ExpertLocation): void;
-/** 忘掉一位专家的索引条目（专家失败回滚，或评审已清理）。 */
-export declare function forgetExpertChild(childId: string): void;
-/** 按子会话 id 查一位专家的评审位置。 */
-export declare function locateExpertChild(childId: string): ExpertLocation | undefined;
-/**
- * 宽限查询：索引里没有就等一个极短窗口再查一次。
- *
- * ## 为什么需要它（红队在真实评审里抓到的竞态）
- *
- * 索引是在 `spawnExpert` **返回之后**才登记的，而宿主的 `startContinuable` 文档
- * 写明它"resolve at initial idle" —— 也就是说子代理可能在 `spawnExpert` 返回的
- * 那一瞬间就已经跑完第一轮并提交了发言。这几毫秒的窗口里：
- *
- * - `crossfire_report` 查不到归属 → 抛"你不在任何评审里"，专家的产出直接丢掉；
- * - `subagent/end` 查不到归属 → 被当作"不属于任何评审"丢弃，专家永远停在 running。
- *
- * 概率极低（需要专家在几毫秒内完成整轮），但代价是**丢掉一整位专家的工作**，而且
- * 它无法复现、无法从外部诊断。所以这里不是掩盖问题，而是把这个窗口等过去。
- *
- * @param childId - 子会话 id。
- * @param graceMs - 等待窗口（默认 400ms，仅在一次查不到时才付出这点时间）。
- */
-export declare function locateExpertChildWithGrace(childId: string, graceMs?: number): Promise<ExpertLocation | undefined>;
-/** 仅供测试：清空进程内索引。 */
-export declare function __resetExpertIndexForTests(): void;
-/** 把一条助手输出里的文本块拼起来（没有则返回空串）。 */
-export declare function blocksToText(blocks: readonly ContentBlock[] | undefined): string;
-/** 一次子代理结束对它的评审意味着什么。 */
-export interface ExpertEndOutcome {
-    /** 捕获到的输出；空串表示这一轮没有任何可用产出。 */
-    text: string;
-    /** 可读原因，在 `text` 为空时写进专家备注。 */
-    note: string;
-}
-/**
- * 判定一次结束的子代理运行给评审带来了什么。
- *
- * 一个 `completed` 但没有任何文本的运行**不是**硬故障（专家可能只回了一句确认），
- * 所以它有自己的一句措辞 —— 要点是绝不让用户去猜"还在跑"和"已经死了"。
- */
-export declare function describeExpertEnd(info: {
-    readonly stopReason?: string;
-    readonly lastAssistantMessage?: readonly ContentBlock[];
-}): ExpertEndOutcome;
-/** 一句可读的 provider 请求失败说明。 */
-export declare function describeRequestFailure(provider: string, failure: {
-    message?: string;
-    code?: string;
-    status?: number;
-} | undefined): string;
-/**
- * 订阅两个让专家产出与专家失败变得可见的宿主事件。
- *
- * 刻意非侵入：`subagent/end` 是普通 emit；`agent/request-error` 是 waterfall
- * 监听器，且**永远通过 `next()` 委托**，因此宿主自己的重试/恢复策略完全不受影响
- * —— 本插件只观察。
- */
-export declare function attachExpertEvents(ctx: Context): void;
-/** 专家活性（批 3 的卡片用它显示"还在跑 / 已就绪 / 已经没了"）。 */
-export type ExpertLiveness = 'running' | 'idle' | 'ready' | 'missing';
-/**
- * 把专家状态与宿主真实的子代理树对账。
- *
- * `ctx.agents.get(id)` 只知道**活着的**驱动，所以进程已经没了的专家看起来和只是
- * 在两轮之间的一样 —— 都报 `ready`，用户无法区分"待唤醒"和"已经没了"。问一次
- * 持久目录就能分开：宿主还列着的 id 是"冷但真实"的子会话，不再认识的 id 才是
- * `missing`。
- */
-export declare function reconcileExpertLiveness(ctx: Context, parentSessionId: string, experts: readonly {
-    childId?: string;
-}[]): Promise<Map<string, ExpertLiveness>>;

package/lib/types/export-md.d.ts

@@ -1,21 +0,0 @@
-/**
- * 把一场评审渲染成 Markdown 交付物。
- *
- * 与圆桌会议的 `export_review` 同一形态（带预填头的 Markdown，可直接贴进 issue
- * 或存档），但内容围绕 crossfire 的语义重组：**先给已认定缺陷**，因为那才是这
- * 场评审真正的产出；被驳回的观点另立一节，因为"哪些被否掉了"同样是结论，而且
- * 它是下一轮去重的依据。
- *
- * @module dsh-plugin-crossfire/export-md
- */
-import type { CrossfireRecord } from './types.ts';
-/** 渲染所需的统计（由 review.countDefects 提供）。 */
-export interface ExportCounts {
-    total: number;
-    pending: number;
-    endorsed: number;
-    rejected: number;
-    strikes: number;
-}
-/** 渲染整场评审。 */
-export declare function renderReviewMarkdown(record: CrossfireRecord, counts: ExportCounts): string;

package/lib/types/harness-compat.d.ts

@@ -1,104 +0,0 @@
-/**
- * 宿主兼容与能力边界（Host compatibility boundary）——「可选能力的懒探测层，绝不成为加载门禁」。
- *
- * **所有与 DSH 版本相关的形状都集中在这个文件里。**
- * 理由与做法直接借鉴社区项目 dsh-agent-teams 的 `src/harness-compat.ts`：
- *
- * > Keep version-specific shapes here: **API presence alone is not a promise of
- * > support for future versions.**
- *
- * 我们的宿主是 **rc 线**，API 尚未冻结，破坏性变更属于常态。所以在写任何
- * `ctx.get(...)` / `ctx.on(...)` / 服务方法调用之前，先问一句：**这个形状在别的
- * rc 上还成立吗？** 如果答案需要翻源码，那它就应该写进本文件，而不是散进业务代码。
- *
- * 两条铁律：
- *   1. **探测绝不成为新的加载门禁**。这里没有 `inject`、没有静态导入宿主包，
- *      缺失的能力一律降级（返回 `undefined`），进程照常起来 ——「整个界面消失」
- *      这类事故的根因就是可选能力被当成必需能力。本文件只做**懒探测**：
- *      调用方用到哪条路由、哪份工作区列表，才在那一步探测一次。
- *   2. **降级由调用方留痕**。这里刻意**不打日志、不维护审计表**（探测点常落在
- *      tick / 轮询路径上，见文末说明）：本层只负责把"能不能用"如实回答成
- *      `undefined` 或服务面，把"为什么没用上"交给拿到 `undefined` 的调用方
- *      记一条告警，让"某个功能为什么没生效"有一个能查的答案。
- *
- * @module @y9931666/dsh-plugin-crossfire/harness-compat
- */
-import type { Context } from '@deepseek-ai/cordis';
-/**
- * 读一个**可选**宿主服务。
- *
- * 统一走 `ctx.get`（cordis 核心、非严格：缺失返回 `undefined`）而不是属性访问
- * —— 后者在没有 `inject` 时会**直接抛错**：
- * `cannot get property "connection" without inject`。
- *
- * 三种失败一律折成 `undefined`，**本函数不产生任何副作用**：
- *   - 宿主 `Context` 上连 `get` 都没有（形状变化）；
- *   - `ctx.get(name)` 自己抛错；
- *   - 服务未挂载（返回 `null` / `undefined`）。
- * 调用方拿到 `undefined` 后自行决定降级行为与是否留下一条诊断。
- */
-export declare function optionalService<T>(ctx: Context, name: string): T | undefined;
-/** 可选服务键的结构式候选（宿主可能改名；按序取第一个可用的）。 */
-export declare const WEB_SERVER_KEYS: readonly ["webServer", "httpServer"];
-export declare const WORKSPACE_KEYS: readonly ["workspaceRegistry", "workspace"];
-/** webServer 服务面（只声明我们真正调用的部分）。
- *
- *  `register` 的返回值刻意只声明为 `() => void`：宿主不同 rc 上返回过
- *  disposer 与 `unknown`，而调用处一律以 `ctx.effect(() => webServer.register(…))`
- *  的形式**忽略返回值**——effect 自带卸载。声明成 `unknown` 会让
- *  `ctx.effect` 的重载解析失败（它要求回调返回具体 Effect，不接受 unknown），
- *  所以这里保留"当它是清理函数"的写法。 */
-export interface WebRouteHost {
-    register(route: {
-        kind: 'exact';
-        path: string;
-        handler: (req: import('node:http').IncomingMessage, res: import('node:http').ServerResponse) => Promise<void> | void;
-    }): () => void;
-}
-/** workspace 注册表面。 */
-export interface WorkspaceListHost {
-    list(): {
-        title: string;
-        path: string;
-    }[];
-}
-/**
- * 解析 webServer 服务面。
- *
- * 服务键是**结构式候选**而非固定名：宿主可能把 `webServer` 换成别的名字，
- * 所以按 `WEB_SERVER_KEYS` 顺序探测。headless profile 下取不到属预期，
- * 只降级不报错（返回 `undefined`，本函数不抛错也不打日志）。
- */
-export declare function webRouteHostOf(ctx: Context): WebRouteHost | undefined;
-/** 解析 workspace 注册表面（同上：结构式候选 + 静默降级为 `undefined`）。 */
-export declare function workspaceRegistryOf(ctx: Context): WorkspaceListHost | undefined;
-/**
- * 判定一个 `rpc.handle(...)` 返回值能不能当清理函数用。
- *
- * 宿主签名在 rc 线上变过：0.1.1 时代第三参 `{ authority }` 被移除，返回值在
- * 不同版本里出现过 `disposer` / `undefined` / Promise。这里只做**形状判定**，
- * 不 import 宿主类型：合法就交出去，不合法就交给调用方记一条降级。
- */
-export declare function asDisposer(value: unknown): (() => void) | undefined;
-/**
- * 在可选的清理函数存在时注册一个 effect。
- *
- * `connection.rpc.handle` 的返回值形状随版本变化，直接 `ctx.effect(() => () =>
- * release())` 会在返回值不是函数时静默留下一个永远不执行的清理器（通道泄漏）。
- *
- * @returns `true` 表示已注册 effect；`false` 表示返回值不是清理函数、**没有**注册
- * （调用方据此决定是否报告一次降级）。
- */
-export declare function effectWithOptionalDisposer(ctx: {
-    effect(callback: () => () => void, label?: string): unknown;
-}, disposer: unknown, label: string): boolean;
-/**
- * 圆桌插件曾在本文件维护一张进程级能力审计表（`capabilityAudit` /
- * `noteCapability` / `formatCapabilityAudit`），让 `status` 与 `doctor` 能打印
- * "每个探测点第一次被看到时是什么状态"。
- *
- * crossfire 不搬这套：本文件现在的定位是**纯粹的可选能力懒探测层** ——
- * 只回答"这个服务此刻能不能用"，不留全局状态、不写日志、不参与加载决策。
- * 诊断信息由**探测的调用方**在拿到 `undefined` 时按自己的上下文报告；
- * 这样探测层不持有跨调用状态，也不会在轮询路径上积累内存。
- */

package/lib/types/index.d.ts

@@ -1,89 +0,0 @@
-/**
- * Crossfire（针锋）—— host 插件入口。
- *
- * 它是一个**只做对抗式评审**的 host 插件：把一个已定稿的成果摆上台，让红队
- * 专家从指定维度分头攻击，把攻击拆成逐条可裁决的缺陷，由人逐条认定或驳回。
- *
- * 与圆桌会议（`@y9931666/dsh-plugin-roundtable`）的关系：**零代码耦合**。针锋是从
- * 圆桌里长出来的一件东西，但它不 import 圆桌的任何模块、不读圆桌的状态目录、
- * 不改圆桌的任何文件。两者共存的唯一代价是各自维护一份内核。
- *
- * 批 1 交付：插件骨架（Config + 偏好存储 + 一条 RPC web 路由 + 系统提示段）。
- * 批 2 加数据模型与 `crossfire_*` 工具；批 3 加轨迹内卡片；批 4 加立场区与
- * 设置页全量。
- *
- * @module dsh-plugin-crossfire
- */
-import type { Context } from '@deepseek-ai/cordis';
-import z from '@deepseek-ai/schemastery';
-/** 插件名（cordis entry id / 日志前缀 / bundle patch 里的 id）。 */
-export declare const name = "crossfire";
-/**
- * REQUIRED services only —— 这份清单是**加载门禁**，所以它必须短。
- *
- * cordis 没有"可选注入"这种形式（`Inject` 只有 `string[] | Record`，而 record
- * 形式是拦截配置），因此写在这里的每个名字都会让整个插件 fiber 保持 PENDING
- * 直到该服务存在：没有工具、没有 `/plugins/dsh-plugin-crossfire/*` 路由、没有
- * 卡片、也没有设置页。而缺一个**可选**能力却写在这里，在用户眼里就是"针锋整个
- * 不见了"，且任何地方都不报错。
- *
- * 所以 `llm` / `webServer` / `workspaceRegistry` / `connection` 一律**不列**，
- * 全部经 `ctx.get(...)` 或 harness-compat 的探测层懒取：
- *   - `llm` 缺席时，观点拆分退到本地启发式兜底（零 token、确定性）；
- *   - `webServer` 缺席时，只有设置页与卡片失联，host 侧与工具照常工作；
- *   - `connection` 缺席时，RPC 只走插件自有路由。
- */
-export declare const inject: string[];
-/** 插件配置。 */
-export interface Config {
-    /** 评审状态目录名（相对会话工作区，默认 `.crossfire`）。 */
-    stateDir?: string;
-    /** `ctx.subagents` 里用于拉起红队专家的 provider（默认 `spawn`）。 */
-    memberProvider?: string;
-    /** 一场评审的专家数硬上限（默认 7，与固定维度池同宽）。 */
-    maxExperts?: number;
-    /** 默认攻击强度档（默认 `standard`）。 */
-    defaultIntensity?: 'quick' | 'standard' | 'deep';
-    /** 专家子代理的委派深度上限（默认 1：专家不得再招人）。 */
-    memberMaxDepth?: number;
-    /** 用法段在全局系统提示里的排序位（默认 117，避开圆桌的 116）。 */
-    promptSectionOrder?: number;
-    /**
-     * 专家**继承主持人**时实际生效的模型路由（provider / model）。
-     *
-     * 它只影响可观测性：开打时把这个生效值写回专家记录，卡片才能把"继承"画成真实
-     * 品牌（DeepSeek 的蓝色 DS 块），而不是一个中性灰 `?`。取不到时不写，界面会退化成
-     * `?` + `title="继承主持人"`，不会显示一个并非事实的路由。
-     */
-    defaultProvider?: string;
-    defaultModel?: string;
-}
-/**
- * 配置 schema（schemastery）。
- *
- * 刻意**不**写 `: z<Config>` 注解：schemastery 的 `.default()` 会把字段推导成
- * `T | Volatile<T>`（例如 `string | Volatile<string>`），而手写接口写的是
- * `string | undefined`，二者不兼容会让 `tsc --emitDeclarationOnly` 以 TS2322
- * 失败 —— 注意 `--noEmit` **不报**这个错，所以它只在生成声明时暴露。
- * schema 自己就是配置形状的权威来源；下面的 `Config` 接口只用于 `apply` 的签名。
- */
-export declare const Config: z<Schemastery.ObjectS<{
-    stateDir: z<string, string>;
-    memberProvider: z<string, string>;
-    maxExperts: z<number, number>;
-    defaultIntensity: z<"quick" | "standard" | "deep", "quick" | "standard" | "deep">;
-    memberMaxDepth: z<number, number>;
-    defaultProvider: z<string, string>;
-    defaultModel: z<string, string>;
-    promptSectionOrder: z<number, number>;
-}>, Schemastery.ObjectT<{
-    stateDir: z<string, string>;
-    memberProvider: z<string, string>;
-    maxExperts: z<number, number>;
-    defaultIntensity: z<"quick" | "standard" | "deep", "quick" | "standard" | "deep">;
-    memberMaxDepth: z<number, number>;
-    defaultProvider: z<string, string>;
-    defaultModel: z<string, string>;
-    promptSectionOrder: z<number, number>;
-}>>;
-export declare function apply(ctx: Context, config: Config): void;