acp-kernel 并入billion-context并保持相对独立

acp-kernel 并入billion-context并保持相对独立,现在跨仓库维护源码很吃力,
billion-context 作为主要发展方向, 有必要并acp-kernel进来.
内核下游影响可能并不大同时保证或许在本项目也可以发版内核版本.

但是要保证,内核代码相对稳定,不要总是去修改内核,如有必要再去修改.看有什么措施能做防范.

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 收到。先给结论:同意并入,推荐「子目录并入」方案(不是 workspaces monorepo)。已完成现状勘察,评估和防范措施如下,你确认方向后我开工。

一、评估(feature triage)

合理性:成立。 现状痛点在机制上确实存在:acp-kernel 是 devDependency 精确钉版(当前 0.0.101),tsup noExternal 构建期内联、零运行时依赖。每次内核改动都要走「acp-kernel 仓改码 → npm 发版 → 本仓 bump pin → npm install → rebuild」全链路,AGENTS.md §5 还硬性规定 "acp-kernel MUST ship first"——跨仓库摩擦是结构性的,不是效率问题。

下游影响:查证后确认不大。 npm 上依赖 acp-kernel 的只有两个包:本仓(0.0.101)和遗留独立包 billion-context-pi(钉在 0.0.98,README 里定位就是 "remains usable" 的旧通道);opencode-acp、omo-stable 均不直接依赖。你的判断正确。

设计契合:好。 内核事实上早已被当作「构建期内部件」对待(bundle inline、dist 自包含、发布物零运行时依赖),跨仓分离才是例外态。并入不改变任何对外面:dist 布局、self-updater、install lanes、客户端接口全部不动,发布物依旧自包含。

二、推荐方案:子目录 `kernel/` + file: 依赖

acp-kernel 整树搬入 kernel/(src/tests/bench/DESIGN.md/PROVENANCE.md 连同其自身 CI 约定一起),保留自己的 package.json(name 仍叫 acp-kernel,版本号独立维护)。
根 package.json 的 devDependency 改为 "acp-kernel": "file:./kernel"。关键收益:src 下 44 个文件 + 一百多个测试里的 from "acp-kernel" / acp-kernel/wire / acp-kernel/persist / acp-kernel/panel 导入一行都不用改,迁移 diff 收敛为「新增目录 + 改一条依赖声明 + 构建顺序微调」。
内核保留自己的构建链(tsup → dist + d.ts),根构建变为「先 build kernel 再 tsup」。消费语义与现在从 npm 装的状态完全一致:typecheck 看到同样的 d.ts,测试跑同样的 JS,tsup 内联同样的代码——行为中性可证明。
否决备选:npm workspaces(根 package.json 挪进 packages/billion-context)。那会连带 bin/files/publishConfig、pi·dsh manifest、self-updater、全部 CI 路径和 install lanes,native模式下自动更新问题需要解决 #991 单写者契约那些承重面全要重新过一遍,风险高且功能收益为零。

迁移证明锚点:切换前用 npm acp-kernel@0.0.101 和在树内核各构建一次 dist,要求 bundle 字节级一致(排除 sourcemap 路径)→ 证明拷贝忠实、接线行为中性;再走常规 typecheck + test + e2e 门禁。

三、防范措施(本 issue 核心诉求:防随手改内核)

并入后内核改动从「跨仓(天然摩擦)」变成「一个 commit(零摩擦)」,原有保护消失,需要重建等强度机制:

CI 路径硬门禁:任何触碰 kernel/** 的 PR,正文必须带标记(如 kernel-change: <理由>)或打 kernel label,否则 CI 直接 fail——把跨仓摩擦人为重建回来。
内核改动永久排除自动合并:AGENTS.md §7.4 增加条款——kernel/ 下一切改动 human-only review,与 src/update.ts/安全项同级(替换现有 "cross-repo dependencies" 条款)。
行为契约 golden(复用 [CI/testing] wire-contract anti-regression system: validation-parity fake upstreams + golden schema snapshots + constraint ledger + staged 4-protocol x 3-mode client smoke matrix #1304 wire-contract 机制):现有 tests/golden/wire-contract/kernel.json 只钉了工具 schema,扩展到覆盖行为常量:defaultConfig 形状、default prompts、nudge 常量(flat 50K step)、工具名表。这些值变化必须显式再生成并在 PR 说明理由,ledger 只增不减。
版本纪律(可审计性):CI 检查——改了 kernel/src/** 必须同时 bump kernel/package.json 版本并在 release notes 记一行 kernel: 旧→新;反之只 bump 版本不改源码也 fail。每次内核变动在 git 历史和发版说明里都有迹可循。
流程条款:内核改动需专门 issue 说明「为什么 host 侧解决不了」+ owner 批准后才动手;commit 用 kernel: 前缀便于 grep 审计。
双层测试:内核自带约 50 个单测文件随迁入 CI(unit 层);bili 全套 + e2e 继续做集成层。
内核独立发版(可选二期):本仓加 kernel-publish workflow,把 kernel/ 以 acp-kernel 原名发 npm——下游(billion-context-pi)零感知;不需要就不开。
旧仓处置:稳定后 archive ranxianglei/acp-kernel 或留 redirect stub——属外部操作,单独报批执行。

四、需要你拍板的三点

方案确认:子目录 kernel/ + file: 依赖(我的明确推荐)。
二期是否启用内核独立发 npm(决定要不要现在就把 publish workflow 一起建)。
旧仓处置时机(archive / 保持只读观察一段时间)。

确认后按此顺序实施:① 原样拷贝 + dist 字节级一致证明 → ② 接线切换 + 全量门禁 → ③ CI 路径门禁 + golden 扩展 + AGENTS.md 条款更新。分 1–2 个 PR,每个 PR 都带迁移证据证明行为中性。此属架构级变更,按 §7.4 合并权在你。

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 补充一条机制验证(等你拍板期间做的定向预检,未动仓库代码):在沙盒里按推荐方案搭了最小复刻(内核包含 . + ./wire 双入口 → 宿主 file:./kernel 依赖),五项全部通过:

npm file: 依赖正确建软链,lockfile 条目为标准格式("resolved": "kernel", "link": true),npm ci(CI 用的安装方式)兼容;
tsup + noExternal: ["acp-kernel"]:bundle 后残留引用为 0,主入口和子路径入口(acp-kernel/wire)都完整内联;
tsc --noEmit --strict --moduleResolution nodenext:类型经软链的 exports map 正常解析;
运行时输出正确;
tsx 动态导入(await import("acp-kernel"),即本仓测试套件的用法,如 proxy-basic.test.ts:209)正常。

唯一本地验证不了的是 ci.yml 矩阵里的 windows-latest(Windows 上 file: 依赖走 junction)——迁移 PR 推上去由 CI 实测兜底,风险低但会作为该 PR 的显式验收项。方案本身没有发现需要修正的点,继续等你确认。

确认,你的方案完全同意.

需要支持阶段性内核独立发版本号,需要提交特殊的发版pr专门发内核.

也就是说,平常改动内核依赖billion-context走进入内核,后续积累后可以单独发布内核版本.二者合作又保持独立.\

原项目暂时保留不动,等磨合好了再说

现在开始搞吧

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 收到,三点决策全部确认,现在开始实施:

子目录 kernel/ + file: 依赖——机制已预验证(软链/lockfile/tsup 内联/tsc/tsx 五项全过),所有现有导入零改动;
内核独立发版——kernel/package.json 保留自己的版本号(从 0.0.101 起);平常内核改动随 billion-context 发版走,积累后提交特殊发版 PR(分支 *_release-kernel-v*、commit release kernel vX.Y.Z、独立 tag 命名空间 kernel-v*)专门发 acp-kernel 到 npm,下游(billion-context-pi)零感知;
原仓库原样保留,不做任何归档操作。

分两个 PR 落地:PR1 迁移(源码拷贝 + 接线切换 + dist 字节级一致证明 + CI 路径门禁 + AGENTS.md 内核边界条款)→ PR2 内核发版流水线(release-kernel workflow)。PR1 就绪后第一时间在本线程报进度。

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 完成,PR 已开:#2098 (Closes #2092)

结构化结论(七问):

是什么问题:功能需求——acp-kernel 并入本仓库并保持相对独立,加稳定性防范措施,支持阶段性内核独立发版本号。
什么原因导致的:跨仓库维护摩擦——内核是外部 npm 依赖,每次内核改动都要走跨仓发版协调(旧规则「acp-kernel MUST ship first」的排序约束)。
怎么修复的:子目录 kernel/ + "acp-kernel": "file:./kernel" 依赖(44 个 src 文件 + 100+ 测试零 import 改动;内核保留自己的名字、版本号、单测套件、构建链)。迁移正确性用字节级一致证明:对 npm 0.0.101 与对内嵌 kernel 各构建一次 bili dist,完全相同(golden diff 纯增量 +87/-0)。六项防范措施:① CI 路径门禁(kernel-guard job:任何触碰 kernel/** 的 PR 必须在正文声明 kernel-change: 标记,否则失败)② 版本纪律 CI(kernel/src 改动必须 bump kernel/package.json 版本,反之空 bump 也失败)③ 内核改动一律人工审核(与 src/update.ts/安全同级,流程:专项 issue 说明宿主侧为何解决不了 + owner 事先批准,commit 前缀 kernel:)④ 行为常量钉进 wire-contract golden(defaultConfig(100_000) 含 flat-50K nudge 常量、defaultPrompts 四条承重规则、工具名表、wire 标记;再生成必须给理由,账本只增不减)⑤ 两层测试(kernel 单测套件跑 TS 源码 + bili 全套/e2e 集成层)⑥ 结构不变式文档化(AGENTS.md 新增 "Kernel Boundary" 节:零运行时依赖、平台无关、id 不可复用、wire 格式、无损往返、保护工具硬排除、管线节点序)。独立发版:新增 .github/workflows/release-kernel.yml——特殊发版 PR(*_release-kernel-v* 分支 + release kernel vX.Y.Z 提交,只改内核版本号)→ 全量 bili 门禁 + kernel 套件 → 从 kernel/ 发布 acp-kernel → tag kernel-v*(独立命名空间);分支/tag 模式与 bili 的发版流在每个匹配方向都互斥,两条流水线永不互相触发;下游(legacy billion-context-pi)照常升级,零感知。
是否有回归问题:无运行时回归(发布的 dist 与基线逐字节相同)。既有行为逐项清点过:build/typecheck/test 语义(pre-hooks 纯增量)、golden 文件纯增量、新 CI job 仅 PR 触发、发版模式互斥、配置面/wire 格式/持久化格式零变化。最终关卡 = CI 全矩阵(ubuntu+windows × node 22/24)。
是否破坏缓存:否——运行时字节完全不变(prefix cache/重试/去重键均不受影响);仅 lockfile 多一条 file: link 记录。
是否改了设计方向:是(即 issue 要求的方向)——内核从外部 registry 依赖变为受人工门禁边界约束的仓内一等模块;平常改动随 bili 发版走,积累后可随时单独发内核版本,二者合作又保持独立。
是否引入新配置:无用户侧配置/env/CLI flag。开发侧:pretest/pretypecheck hooks(构建 kernel 前置)、root 增加 prettier devDep、kernel-guard CI job、release-kernel.yml。

备注:

原仓库按你的指示未动(归档与否等磨合好了再定)。
原计划分两个 PR(迁移→发版流水线),因发版工作流在出现 release-kernel 分支前完全惰性,合并为一个 PR 可原子关闭 issue、避免文档描述不存在流程的空窗,审查也更集中。
一个显式验收项:windows-latest 上 file: 依赖的 junction 行为(机制已在本地 Linux 预验证 5/5,Windows 只能由真实 CI 验证)。
CI 正在跑,结果出来我会在本线程跟进报告。

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 CI 结果:全绿。

完整矩阵 test(typecheck + 全量测试 + build):ubuntu-latest / windows-latest × node 22 / 24,4/4 SUCCESS。此前显式标注的验收项——file: 依赖在 windows-latest 上的 junction 行为——已由真实 Windows CI 验证通过。
过程透明说明:本 PR 自身的 pull_request 事件在本环境未触发任何工作流(多次推送均零自动运行;同期其他 PR 与 master 的 push 触发均正常)。因此改用 ci.yml 中已文档化的 workflow_dispatch 后备通道(专用：发布新版本pr #772/one-click release fallback PRs are not immediately mergeable under current branch protection (#772 push-CI mechanism never fires) #1744 同款模式)在分支上手动触发 CI——check runs 落在 head SHA 上,可满足 required status checks。
连带影响:kernel-guard / version-guard 两个门禁 job(仅 pull_request 事件运行)在该次 dispatch 运行中显示 skipped;其判定逻辑已在本地对提交树 dry-run 通过(SRC_CHANGED=1 / BUMPED=1 → pass),待一次正常 PR 事件到达(例如你向分支推任意提交、或在 Actions 页 Re-run)即会真实执行。
结论:Migrate acp-kernel in-repo (kernel/) + stability guardrails + standalone kernel releases #2098 就绪,等你审查合并(合并动作按规则由人执行):Migrate acp-kernel in-repo (kernel/) + stability guardrails + standalone kernel releases #2098