@zhushanwen/subagent-core 0.6.0 → 0.7.1

package/src/execution/engine/engines/pi/pi-invocation.ts

@@ -1,120 +0,0 @@
-// src/execution/engine/engines/pi/pi-invocation.ts
-//
-// 定位 pi 二进制并组装 spawn 调用。Core 叶子原语（仅依赖 node 内置）。
-//
-// spawn 改造（in-process → spawn pi --mode json）的基座模块。
-// 被 runSpawn（session-runner）调用，决定子进程用哪个命令启动。
-//
-// 移植自 nicobailon subagent example 的 getPiInvocation，处理三种运行时：
-//   1. bun bundle（/$bunfs/root/ 虚拟脚本）→ 退化到 pi-in-PATH
-//   2. 有真实脚本路径（node + script）→ node <script> <args>
-//   3. node/bun generic runtime（无脚本）→ pi <args>（依赖 PATH）
-//
-// 注意：pi 在扩展进程内运行时 process.execPath 是 node/bun，process.argv[1]
-// 是 pi 的入口脚本。子进程需要复现同样的启动方式才能保证扩展/配置一致加载。
-
-import * as fs from "node:fs";
-import * as path from "node:path";
-
-import { isRelayActive, RELAY_ENV_NODE, RELAY_ENV_SCRIPT } from "../../../relay-env.ts";
-
-/** spawn 调用描述符：command + args（透传给 child_process.spawn）。 */
-export interface PiInvocation {
-  /** 可执行文件路径（node/bun/pi 二进制）。 */
-  command: string;
-  /** 命令行参数（可能含 [scriptPath, ...userArgs] 或直接 [...userArgs]）。 */
-  args: string[];
-}
-
-/** getPiInvocation 可选项。 */
-export interface PiInvocationOptions {
-  /**
-   * false = 强制直连 spawn 真实 pi（不经 relay 代理）。唯一现役消费点是 PiEngine.probe
-   * ——探针意图是 pi 本体可解析性，经 relay 探到的是 runtime 健康，语义错位（E 方案 §5.1）。
-   * 缺省（undefined / true）时按 relay env 激活判定走代理。
-   */
-  relay?: boolean;
-}
-
-/**
- * bun 虚拟文件系统前缀。bun bundle 模式下 process.argv[1] 形如
- * /$bunfs/root/pi——这不是磁盘上的真实文件，不能直接 spawn。
- */
-const BUN_VIRTUAL_PREFIX = "/$bunfs/root/";
-
-/**
- * 判断 execPath 的 basename 是否为通用运行时（node/bun）。
- * 通用运行时需要脚本路径才能启动 pi；非通用（如 pi 的 standalone binary）可直接执行。
- */
-function isGenericRuntime(execPath: string): boolean {
-  const execName = path.basename(execPath).toLowerCase();
-  return /^(node|bun)(\.exe)?$/.test(execName);
-}
-
-/**
- * 组装 pi 子进程的 spawn 调用。
- *
- * @param userArgs pi CLI 参数（如 ["--mode", "rpc", "--session-dir", "..."]）
- * @param opts 可选项（relay:false 强制直连——probe 用，见 PiInvocationOptions）
- * @returns spawn 描述符（command + 完整 args）
- *
- * 决策链（按优先级）：
- *   0. relay 激活（三 env 齐备且未显式禁用）→ <RELAY_NODE> <RELAY_SCRIPT> <userArgs>
- *      （E 方案 §5.1：xyz-agent runtime 存在时经代理 spawn，改的是进程拓扑不是 pi 语义）
- *   1. process.argv[1] 是真实磁盘文件且非 bun 虚拟路径 → <execPath> <argv[1]> <userArgs>
- *      （复现当前 pi 进程的启动方式，确保扩展/配置/版本一致）
- *   2. execPath 非通用运行时（pi standalone binary）→ <execPath> <userArgs>
- *   3. 通用运行时但无可用脚本路径 → "pi" <userArgs>（依赖 PATH 中可找到 pi）
- */
-// [perf] 决策链只依赖 process.argv[1] / process.execPath（进程内恒定），其中唯一的
-// 磁盘探测（existsSync）结果 memo 一次——每次 spawn 免重复 syscall。memo 键含
-// argv[1] 值：测试 mock 切换 argv[1] 模拟不同运行时时自动失效重算。
-let scriptExistsCache: { script: string | undefined; exists: boolean } | undefined;
-
-/** process.argv[1] 是真实磁盘脚本（非 bun 虚拟路径）且存在。 */
-function currentScriptExists(): boolean {
-  const currentScript = process.argv[1];
-  if (scriptExistsCache === undefined || scriptExistsCache.script !== currentScript) {
-    scriptExistsCache = {
-      script: currentScript,
-      exists:
-        currentScript !== undefined &&
-        !currentScript.startsWith(BUN_VIRTUAL_PREFIX) &&
-        fs.existsSync(currentScript),
-    };
-  }
-  return scriptExistsCache.exists;
-}
-
-export function getPiInvocation(userArgs: string[], opts?: PiInvocationOptions): PiInvocation {
-  const currentScript = process.argv[1];
-  const isBunVirtualScript = currentScript?.startsWith(BUN_VIRTUAL_PREFIX);
-
-  // 分支 0（前置）：relay 激活（E 方案 §5.1）——runtime 注入三 env 齐备且未显式禁用时，
-  // spawn 目标切换为 <RELAY_NODE> <RELAY_SCRIPT> <原 pi spawnArgs>，形态与分支 1「node +
-  // script」同构（command 是执行器、args[0] 是脚本）。ELECTRON_RUN_AS_NODE 不在此补：
-  // 打包态执行器为 Electron 时由 runtime 与三 env 同点注入主 pi 进程 env（E-2
-  // getRelaySpawnEnv），本进程 {...process.env} 继承即达代理进程，extension 不重复判定。
-  // isRelayActive 已保证三 env 非空，下方取局部变量仅为 TS 收窄（isRelayActive 的
-  // 收窄不跨函数边界传导）。
-  if (opts?.relay !== false && isRelayActive(process.env)) {
-    const relayNode = process.env[RELAY_ENV_NODE];
-    const relayScript = process.env[RELAY_ENV_SCRIPT];
-    if (relayNode !== undefined && relayScript !== undefined) {
-      return { command: relayNode, args: [relayScript, ...userArgs] };
-    }
-  }
-
-  // 分支 1：有真实脚本路径 → 复现启动方式（node <pi-script> <args>）
-  if (currentScript && !isBunVirtualScript && currentScriptExists()) {
-    return { command: process.execPath, args: [currentScript, ...userArgs] };
-  }
-
-  // 分支 2：非通用运行时（pi 自带 binary）→ 直接执行
-  if (!isGenericRuntime(process.execPath)) {
-    return { command: process.execPath, args: userArgs };
-  }
-
-  // 分支 3：通用运行时但脚本不可用 → 依赖 PATH
-  return { command: "pi", args: userArgs };
-}

package/src/execution/engine/engines/pi/reader.ts

@@ -1,59 +0,0 @@
-// src/execution/engine/engines/pi/reader.ts
-//
-// PiEngine reader（P5）：pi subagent session JSONL → SessionView（设计 D6 read
-// 降级链第①级的 pi 侧实现）。
-//
-// 双端复用约束（设计 §3.3.7，与 zcode/reader.ts 同款）：本模块必须保持无状态
-// 纯函数、无 spawn/进程依赖、不 import 同包 launcher/preparer/parser。因此
-// PI_ENGINE_ID 在此本地锚定（pi-engine.ts 的同名常量会连带运行时件 import，
-// 破坏「共享 reader 是唯一允许被 xyz-agent runtime import 的引擎模块」约束）。
-//
-// 下沉说明（A1 守护）：turns 重建逻辑本体 = session-reconstructor.reconstructFromFile
-// （pi JSONL → ReconstructedRecord，extension 侧唯一 source of truth）。本模块只做
-// ReconstructedRecord → SessionView 的投影（投影原语 toReplayedTurn / aggregateUsage
-// 收敛在 common/session-view-projection.ts 单一实现），不改 reconstructor 本体——
-// pi 现有直读行为零变化。
-//
-// xyz-agent runtime 侧的 pi 历史读取链（getHistoryFromFilePath）是独立实现（shared
-// Message 投影），不消费本模块——两链各自保持现状（P5 只对非 pi 引擎引入共享
-// reader；pi 的 runtime 链路回归由现有测试守护）。
-//
-// [D2 实施期门②裁决：保留（2026-09-02，u-2a）] 现状 readPiSessionView 仅被
-// PiEngine.read（①级原生层）消费、read 面生产零调用（pi 历史走 runtime 自有 JSONL
-// 直读链）——但 EnginePort.read 是四能力面的非可选成员（port.ts），pi 的
-// capabilities.sessionRead='full' 与 conformance read 降级契约（contract.read-
-// degradation）以此为①级实现；删除本模块会使 pi 的 read 面空心化（②③级兜底直通），
-// 与终态图（dual-track-convergence §3.5：engines/pi/ 四件套含 reader）矛盾。保留
-// 不构成第三个 SessionView 装配实现：u-1a 的 session-view-service（GUI 生产链）对
-// pi 分支维持防御性空返回（A1 守护，不 import 本模块），两链零交叠；read 面的
-// 生产调用方归属终态「extension 内 EnginePort.read() 复用同一 module」接线
-// （§3.5 GUI 读取路径），不在 u-2a 范围。
-
-import { reconstructFromFile } from "../../../session-reconstructor.ts";
-import type { SessionView } from "../../types.ts";
-import { aggregateUsage, toReplayedTurn } from "../../common/session-view-projection.ts";
-
-/** pi 引擎的 registry key（与 engines/pi/pi-engine.ts 的 PI_ENGINE_ID 同值锚定）。 */
-export const PI_ENGINE_ID = "pi";
-
-/**
- * 读取 pi subagent session 的引擎中立视图（read 第①级）。
- *
- * @param sessionFile pi session JSONL 绝对路径
- * @returns undefined = 文件缺失/损坏/缺 identity entry/无 assistant message
- *          （reconstructFromFile 的降级语义，不 throw——降级链由宿主编排）。
- */
-export async function readPiSessionView(sessionFile: string): Promise<SessionView | undefined> {
-  const recon = reconstructFromFile(sessionFile);
-  if (recon === undefined) return undefined;
-  const usage = aggregateUsage(recon.turns);
-  return {
-    engineId: PI_ENGINE_ID,
-    // recon.id 是 subagent record id——pi 链路的 sessionId 约定即 header id 兜底
-    // record.id（collectResult 同源，与 pi-engine read 的既有约定一致）
-    sessionId: recon.id,
-    turns: recon.turns.map(toReplayedTurn),
-    ...(usage !== undefined ? { usage } : {}),
-    source: "native",
-  };
-}

package/src/execution/engine/engines/pi/registration.ts

@@ -1,37 +0,0 @@
-// src/execution/engine/engines/pi/registration.ts
-//
-// pi 引擎注册入口（P1 接线）。设计权威源：§3.3.1（注册表 id → factory）+ D9（缺省
-// 引擎 = 'pi'）。组合根（src/index.ts 扩展初始化）调用 registerPiEngine()，把进程级
-// SubagentService 单例登记为 registry 里的 'pi' 引擎——此后引擎获取统一经
-// getEngine('pi') / getEngine(DEFAULT_ENGINE_ID)，上层不再硬编码「spawn pi」这一选择。
-//
-// 为什么独立文件：pi-engine.ts 保持零注册副作用（被 SAR 等 DI 场景 import 时只拿类），
-// 注册是组合根的职责——依赖方向 registry ← registration ← pi-engine 单向，无循环。
-
-import { getSubagentService } from "../../../subagent-service.ts";
-import { registerEngine } from "../../registry.ts";
-import { PI_ENGINE_ID, PiEngine } from "./pi-engine.ts";
-import type { PiEngineService } from "./pi-engine.ts";
-
-export { PI_ADAPTER_VERSION, PI_ENGINE_ID, PiEngine } from "./pi-engine.ts";
-export type { PiEngineDeps, PiEngineService } from "./pi-engine.ts";
-
-/**
- * 构造绑定到指定服务定位器的 PiEngine（DI 工厂）。
- * SAR（per-session DI 构造，注入 mock 的测试场景）用本工厂绑定自身持有的服务引用；
- * registry 全局单例绑定的是进程级 getSubagentService()——生产环境两者是同一对象。
- */
-export function createPiEngine(getService: () => PiEngineService | null): PiEngine {
-  return new PiEngine({ getService });
-}
-
-/**
- * 把 'pi' 引擎登记进 registry（幂等——组合根可能多次执行，如每次 session_start）。
- * 工厂绑进程单例 getSubagentService：惰性求值，session_start 注入前调用 getEngine
- * 只会拿到引擎实例，真正 run 时才解析服务。
- */
-export function registerPiEngine(): void {
-  // [D4 聚合连带] 查询/交互面聚合后 Service 不再整体结构化兼容 PiEngineService——
-  // 经 asEngineService 显式视图适配（成员集合与原直绑等价）。
-  registerEngine(PI_ENGINE_ID, () => createPiEngine(() => getSubagentService()?.asEngineService ?? null));
-}