本文件为仓库全部 50 个 issue 的验收操作说明。每条给出：验收方式（命令 / 测试 / computer-use 交互）、操作步骤、通过标准。
npm install
npm run typecheck # 任何实施类 issue 验收前先跑
npm test # 全量测试必须绿真实 LLM 验收需二选一：
KIMI_API_KEY=<key>环境变量；- 或先跑一次
kimi让~/.kimi-code/credentials/kimi-code.json里有未过期 OAuth token。
无 key 环境用 FAKE_LLM=1（FakeLLM 预置脚本流）做功能性验收。
TUI 类 issue 的交互验收用 kimi-cu 工具，标准流程：
- 在一个可见终端窗口（Windows Terminal / conhost）里启动 TUI：
npm run dev（或FAKE_LLM=1 npm run dev）。 list_apps/list_windows找到终端窗口，activate_window置前。get_app_state（含截图）确认渲染内容。- 用
type_text/press_key模拟输入与键位，click仅在确有需要时用。 - 每个关键动作后重新
get_app_state截图，对照通过标准逐项核对。 - 验收结束
turn_ended收尾。
注意：CU 截图验证的是「真实终端里的最终表现」，VirtualTerminal 测试验证的是「渲染逻辑」。两者不互相替代——实施票要求两者都过。
这三类不写产品代码，验收标准是「产出物存在且能指导下游」：
- 决策票：结论以评论或 ADR 落盘，明确回答 issue 里列的每个待定点；被它 block 的下游 issue 能引用结论开工。
- 调研票：回答 issue 的 Question，附证据（源码行号 / 实测记录），不泄露 token。
- 原型票：有可运行的原型 + 真人试用反应记录链接到 issue。
方式：命令 + 测试。
# 真实链路（有 key）
npm run agent -- -p "在当前目录写一个 helloworld 程序并告诉我文件路径"
# 无 key
FAKE_LLM=1 npm run agent -- -p "写一个 helloworld"通过标准：
- agent 真实调用
write_file写出 helloworld 文件，stdout 打印最终回复； wire.jsonl追加全程事件，seq 单调递增；npm test中 loop / toolExecutor / wire 三组接缝测试全绿；- 引擎目录（
src/engine/）无任何 TUI 依赖。
方式：文档复核。issue 评论中有请求/响应格式、认证方式（POST + Bearer 复用 OAuth）、封装建议（超时/截断/错误归类），且 #35 #36 能直接按它实现。复核时用一次真实调用抽验：
curl -s -X POST https://api.kimi.com/coding/v1/search \
-H "Authorization: Bearer $KIMI_API_KEY" -H "Content-Type: application/json" \
-d '{"text_query":"test"}' | head -c 500返回 JSON 结果数组即通过（不要在任何地方记录完整 token）。
方式：文档复核。issue 评论包含：依赖方式结论（vendor 拷贝）及 file: 协议的坑、关键 API（TUI/Container/Editor/Markdown/Loader/CombinedAutocompleteProvider/VirtualTerminal）带源码行号的用法约束、最小骨架在 node type-stripping / tsx / vitest 三路跑通的记录。#10 能直接引用它做决策即通过。
方式：流程复核。这是地图票，验收 = 收图条件满足：
- Destination 产物存在：#13 的 spec v2 已落地；
- 地图内所有决策票（#5–#11）关闭，「Not yet specified」清空或转为新地图；
- 最终验收挂钩 #50（一周 ≥3 真实任务）达标。
方式：产出物复核（按 0.3 通则）。结论必须逐项回答：approval 事件怎么表达、loop 如何暂停等 UI 回答、规则引擎放哪层、规则与会话记忆存哪、-p 默认策略。验收动作：拿着结论去审 #25–#28 的实现是否与其一致——对得上即通过。
方式：产出物复核。结论明确：重建消息是否进 LLM 上下文、tool_call_id / toolCalls 如何还原、会话边界与重启行为。#29 #30 的实现与之对照一致即通过。
方式：产出物复核。结论明确：截断策略选型、token 估算方式，并回答「玩具场景多久撞到 256K」。#31 #32 据此实现即通过。
方式：产出物复核。清单定稿（含 list_files / grep / glob / web_search / web_fetch 取舍），每个工具有参数 schema、截断、超时定义。#33–#37 按清单逐项落地即通过。
方式：产出物复核。结论明确：文件位置、格式、字段、与 env / OAuth 的三级优先级。#38 按结论实现即通过。
方式：产出物复核 + 实证。结论选定三选一方案后，仓库里能实际安装/构建通过（npm install && npm run typecheck），即决策已落地。
方式：产出物复核。切分方案存在且 #14–#18 的边界、测试接缝、装配顺序与之对应；每批验收点可执行（指向具体测试或 CU 步骤）。
方式：CU 交互验收（原型本身）+ 反应记录。
- 运行原型（按原型票内说明启动）。
- CU 截图确认审批帧形态（内联或 overlay）。
- 用
press_key分别按y/n/a/esc，逐次截图确认各自行为符合原型约定。 - issue 内有真人试用反应记录。
方式：文档复核。根目录 spec v2（或新 spec 文件）包含：A 阶段 TUI 切分、B 阶段最小集（审批/会话恢复/工具链/配置/溢出策略）、验收标准「一周 ≥3 真实任务」。前置 #5–#12 全关闭后才可验收。读一遍 v2，能据此回答「下一步做什么」即通过。
方式：测试 + 代码检查。
npm test中 theme 接缝测试绿：token 完整性、pi-tui theme 映射形状；- 检查
src/tui/theme/（或对应目录）为颜色唯一来源：grep -r "chalk\." src/tui/components src/tui/controllers应无直接命名色使用。
方式：测试。
- VirtualTerminal（@xterm/headless）行为测试绿：渲染 user / assistant / tool-call 三种块，断言视口内容；
- 抽查：组件取色只经 theme（同 #14 的 grep）。
方式：测试。
- 喂
assistant.delta事件序列，断言 Markdown 块增量更新、loader 启停时序； - footer / loader / welcome 组件各自有渲染断言。
方式：测试 + CU。
- 测试：slash 命令声明/解析/执行分离的单元测试绿；
- CU：启动 TUI，输入
/clear截图确认消息区清空；输入/delete确认行为符合定义；press_key发送Ctrl+C两次（或按实现约定），确认干净退出、终端 raw mode 恢复（退出后终端能正常输入）。
方式：CU + 测试，A 阶段总验收口。
- VirtualTerminal 冒烟测试绿：提交一条消息 → 视口出现用户块 + 回复块；
- CU（fake）：
FAKE_LLM=1 npm run dev，输入一句话提交，截图确认完整 turn：用户块、loader、assistant 回复、工具帧依次出现； - CU（真实）：无
FAKE_LLM用订阅凭证重复上面流程，确认真实 LLM 路径通； npm run dev一键启动，无需额外手工步骤。
方式：CU。启动 TUI，首屏截图确认欢迎块含：工具名、模型名、工作区路径、提示语；颜色走 theme（无硬编码色）。
方式：测试 + CU。
- 测试：喂
assistant.think事件断言折叠渲染、不混入正式回复； - CU：用真实模型问一个触发 reasoning 的问题，截图确认思考流折叠/淡化展示，展开后与回复正文分离。
方式：CU。editor 输入 /，截图确认补全列表出现（至少含 /clear /delete）；继续输入 /cl 列表收窄；选中执行生效。
方式：CU。
- 输入一行文字，
press_key发送 Shift+Enter（或 Alt+Enter，以 #4 调研结论为准），截图确认换行未提交； press_key发送 Enter，确认提交；- 粘贴一段多行文本，确认未误提交、再按 Enter 才提交。
方式：CU + 测试。
- 测试：检测失败时安全降级到暗色的单测绿；
- CU：分别在暗色、亮色终端主题下启动，各截图一张，确认两套 token 生效且可读。
方式：CU + 测试。
- 测试：超长工具输出截断断言；
- CU：让 agent 跑一条长输出命令（如
dir /s或读大文件），截图确认默认折叠为摘要；执行展开操作（按键/点击以实现为准），确认全文可见；超长部分有截断标记。
方式：测试为主。
- 规则表驱动测试绿：只读 pattern（
ls、git status、npm test）自动放行无审批事件；危险 pattern（rm -rf、git push、写工作区外）强制确认或拒绝；其余触发一次询问； - 抽查实现分层与 #5 结论一致。
方式：测试 + CU。
- 测试：答 always 后同 pattern 不再产生审批事件；
- CU：触发一条非白名单命令 → 审批帧按
a→ 再触发同 pattern 命令，截图确认直接执行无审批帧；新开会话后记忆不残留（或按 #5 结论的行为）。
方式：命令。
# 无 --yes：写/执行类请求应被拒绝或跳过，只读工具正常
npm run agent -- -p "写一个文件 x.txt" # 预期：不放行写操作
npm run agent -- -p --yes "写一个文件 x.txt" # 预期：放行
npm run agent -- -p --yes "删除系统目录" # 预期：危险 pattern 仍被规则引擎拦截三种行为均符合 #5 结论即通过。
方式：CU（按 #12 原型形态）。
- TUI 里让 agent 执行需确认的工具调用（如写文件）；
- 截图确认审批帧出现在消息区，loop 暂停（后续事件不再推进）；
- 按
y→ 确认执行继续；重做一次按n→ 确认工具被拒绝且结果回灌给 LLM；esc行为按 #5 契约核对。
方式：命令 + 测试。
- 测试：含 tool 消息的 wire 重建后协议形状正确（tool_call_id 配对还原，若 #6 决定进上下文）；
- 实操：跑一轮对话退出 → 重启继续上次会话 → 问一个依赖上文的问题（如「刚才那个文件叫什么」），确认模型能答对——证明上下文真恢复了，不只是 UI 展示。
方式：命令 + 文件检查。
- 在不同目录各跑一次会话，确认会话文件按工作区分目录存放，不再固定
wire.jsonl； - 同一工作区跑两次，确认支持「继续上次」与「新建」两种路径；
- 跨工作区互不串扰。
方式：CU。
- 在有历史会话的工作区启动 TUI；
- 截图确认会话列表出现（时间/摘要可辨）；
- 选中一条旧会话继续，确认历史消息加载；再验证「新建」入口可用。
方式：测试为主。
- 构造超长 messages 的接缝测试绿：截断后形状符合 #7 结论（滑动窗口 / system+最近 N 轮 / 报错引导）；
- 边界断言：不切断 tool_call 与 tool 结果配对；
- 可用脚本实测：连续多轮灌长文本逼近上限，观察触发行为与 #7 一致。
方式：测试 + CU。
- 测试：估算函数单测（字符数/4 或 usage 取值，以 #7 为准）；
- CU：对话若干轮后截图 footer，确认占用数值随对话增长；灌长文逼近上限时截图确认视觉警示出现。
方式：测试 + 命令。
- 测试：临时目录构造断言输出（树形/扁平、深度与条数限制）；
- 命令：
-p模式让 agent「列出当前目录结构」，确认模型收到紧凑格式并正确使用。
方式：测试。
- 正则内容搜索与文件名匹配各自的测试绿：结果上限截断、默认尊重 .gitignore；
- 确认纯 Node 实现（
package.json无新增运行时依赖）。
方式：测试 + 真实调用。
- 测试：mock fetch 断言请求形状（POST
{text_query}+ Bearer）、title/url/snippet 映射、输出硬截断、15s 超时、401/402/403 归类不重试； - 真实：
-p "搜一下 xxx 并总结"，确认返回真实搜索结果（需有效凭证）。
方式：测试 + 真实调用。
- 测试：mock 断言 POST
{url}+Accept: text/markdown、非法 URL 拒绝、30s 超时、50KB 截断； - 真实：
-p "抓取 https://example.com 并概括"，确认拿到正文。
方式：测试 + 代码检查。
- 测试：每个内置工具喂超限输出，断言统一上限（如 50KB）、
[...truncated]标记、行数/字节双阈值； - 检查收口在 ToolExecutor 一层，而非各工具自行其是（grep 截断逻辑应只出现一次）。
方式：命令矩阵。按 #9 的三级优先级逐级覆盖验证：
# 1. 仅配置文件 → 生效
# 2. 配置文件 + env → env 胜出
# 3. 全缺省 → 回落订阅 OAuth
KIMI_API_KEY=xxx npm run agent -- -p "hi" # 等组合逐一试每次启动打印生效来源（脱敏，不出现完整 key），来源标注与实际优先级一致即通过。
方式：命令 + 测试。
- 在项目级文件（AGENTS.md / .agent.md，以 #9/#38 为准）写入自定义指令，跑
-p提问，从回答确认指令生效； - 删掉该文件，确认默认 prompt 行为回退；
- 测试：配置加载单测覆盖「有覆盖 / 无覆盖」两路径。
方式：测试 + 命令。
- 测试：mock fetch 分别返回 401/403、429、5xx、网络错误，断言各自错误消息含可操作建议（401/403 提示刷新凭证或设
KIMI_API_KEY）； - 命令：故意设一个错误 key 跑一次，确认报错是人话而非原始 HTTP 堆栈。
方式：测试。
- mock fetch：网络错误/5xx → 断言指数退避重试且上限 2–3 次；4xx → 断言不重试立即报错；
- 确认无 OAuth 自动刷新逻辑（保持玩具诚实）。
方式：测试 + 命令。
- 测试：预写含坏 JSON 行的 wire 文件，断言跳过坏行、告警带行号、其余事件正常读出；
- 命令：手工往
wire.jsonl塞一行乱码后重启/重建，确认不崩、stderr 有告警。
方式：GitHub 实证。
- push 一个分支或开 PR，在 Actions 页确认 Windows + Linux 双平台矩阵触发；
- 两个平台均跑
typecheck + vitest且绿； - 故意推一个破测试验证 CI 会变红（可选但推荐）。
方式：矩阵验证 + 文档。
- 借 #43 的 CI 矩阵跑自动化部分；
- 在 win / mac / linux 各手工跑一次
run_command相关场景：shell 分叉（cmd/sh）、含空格路径、超时后进程树清理（win 上 taskkill）； - issue 内落一份平台差异表。
方式：命令（在任意目录）。
按 #13 选定的形态验收，例如 npm link 路线：
npm link
cd /tmp/some-random-dir # 或任意其他目录
mini-agent -p "写一个 helloworld"在任意目录 agent 命令可用且功能完整即通过；若选 bundle 路线则验证单文件可执行、无 node_modules 依赖。
方式：命令 + 管道消费。
npm run agent -- -p --output-format stream-json "hi" | head -20
npm run agent -- -p --output-format stream-json "hi" | node -e "/* 逐行 JSON.parse 全成功 */"通过标准：每行是一个合法 JSON 的引擎事件；默认（不带参数）仍为 text 输出；可被 jq / 脚本管道消费。
方式：CU。启动 TUI 截图 footer，逐项确认显示：模型名、工作区、上下文占用（#32）、审批模式状态（--yes / 交互）。信息源检查：数据由 bootstrap 装配注入，组件不各自打探。
方式：文档复核 + 抽查。
- README 的 TUI 篇：按文档列的键位、slash 命令、审批交互逐项在 TUI 里 CU 实操一遍，文档与行为一致；
- 「玩具 ↔ kimi-code」目录对照表：抽查 3–5 行，对照
D:/找工作/kimi-code真实目录确认映射正确。
方式：真实使用记录，全项目最终验收口。
- 用本周落地的工具（#18 之后的形态）完成 ≥3 个真实小任务（非 demo 语料）；
- 每个任务记录：prompt、卡点、体感，链接到本 issue；
- 3 条记录齐全 → #50 关闭 → 回看 #2 地图收图。
| 方式 | 适用 issue |
|---|---|
npm test / typecheck 为主 |
#14 #15 #16 #25 #31 #33 #34 #37 #40 #41 #42 |
| CLI 命令实测 | #1 #27 #29 #30 #35 #36 #38 #39 #45 #46 |
| computer-use 交互截图 | #12 #17 #18 #19 #20 #21 #22 #23 #24 #26 #28 #32 #47 #48 #49 |
| 产出物/文档复核 | #2 #3 #4 #5–#13 #49 |
| GitHub / 多平台实证 | #43 #44 |
| 真实使用记录 | #50 |