| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
docs(i1): 香港升到 main 之后的真浏览器复验（5/5）证据归档 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 8 天前 | |
fix(i2): 更正 M2 的一处事实 —— 社区版注册的是 6 个 MCP，不是 4 个 I2 定义 A 线（「HCA 只挂与社区版相同的 MCP」）时去核清单，发现对不上： M2 §4.3 写「三处交叉核对确认社区版只注册 4 个 MCP」，但 M2 自己的原始记录里 基线侧 q3 三次都调到了 screener_market_screen。 去容器里查：那三处看的都是同一份 /opt/opencode-workspace/.opencode/opencode.jsonc， 而**工作区根下还有一份 /opt/opencode-workspace/opencode.json** 又注册了 hunter_cap 与 screener。opencode 合并后的权威口径是 GET /config： ["hunter_cap","hunter_user","portfolio","screener","uzi","watchlist"] —— **6 个**。 （「交叉核对了三处」听起来很稳，但三处看的是同一类文件 —— 这就是 M5 总结的那条 「该失败的时候会不会假装成功」的另一个形状：核对的是同一个来源的三个副本。） 影响： · A 线的 MCP 子集改成只去掉 akshare,kronos,truesource（保留 screener、hunter_cap）， 否则 HCA 侧连 q3 都答不了，比的就不是引擎了。 · HCA 真正多出来的是 akshare / kronos / truesource 三个 —— 结论方向不变 （q2/q5 的步数差主要来自 akshare 三连），但「9 vs 4」这个对比要改成「9 vs 6」。 · 已更正 docs/对比-opencode版.md、M2-AB对比报告.md §7.2、M2-成果与测试报告.md 的表述并各自标明是 I2 更正；docs/eval/scores.json 里那份是当时生成的原始记录， 不改。取证 docs/evidence/I2/社区版MCP清单-实测更正.md。 另：总进度表补 I2 行与 I2 细项 12 行（含「I2 开工抢资源打坏 M5 浸泡 r017/r018」这条）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 9 天前 | |
feat(i4): 响应时间专项评测跑完 —— 400 次运行、七条同库判据全绿、报告与三份文档同步 四个批次（i4-b 200 次 / i4-a 120 次 / idle-b 40 / idle-a 40），每批开跑前七条判据 全绿、社区版 199 次会话归属登记全部 200、每次运行前恢复两边账本、交错换先手。 三个数： · **空载题 A 线 4.57 s / 4.52 s = 1.01** —— 工具清单拉平之后引擎本身不慢， 这是任务书要的「最干净的一组对照」； · **产品形态十题墙钟 217.9 / 282.4 = 0.77**、答案首字 0.74、工具段 0.45、 token 0.98。快在调得少（20 次 vs 40 次、27 轮 vs 38.5 轮），不是单次更快； · **A 线反过来 1.19** —— 没有组合工具时 HCA 退回 akshare 的三连， 工具段 54.8 s → 157.4 s。与 I1 A 线的 1.18 两轮独立复现。 还差多少：只剩 q3 / q5 的模型段（+1.54 s / +3.59 s）。q5 那个量与 I3 的 +3.84 s 对得上（P2-23 拿到第二份证据），已知杠杆 U-23 只够补五分之一。 出字段慢 1.52 倍不是可优化项 —— 写了 1.74 倍的字，每字耗时反而更快。 hook 单独直测：每次工具调用 32.8 ms、每个提示 16.5 ms，十题合计约 0.85 s（0.4%）。 连带更正三处既有结论：对比文档 §3 开头改写并新增 §3.-2、§3.-1 的墙钟与 token 两行打上注记、I1 报告开头补一段口径更正（四维分不受影响，两边是对称地没有 用户上下文；速度与成本偏乐观）。待办池加 P1-28 / P2-24 / P2-25 / P2-26， P2-23 与 U-23 补新证据。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 8 天前 | |
fix(m4): .gitignore 的裸 atomcode 把 M3 整个适配层吞掉了 —— 从零 clone 构建不出来 **从零安装测试撞出来的真缺陷**（M4 任务书第 3 条的价值就在这）： 在测试机上用 install.sh 从 GitHub clone feat/m4 装一遍，web 镜像构建直接失败： ./app/api/opencode/[...path]/route.ts Module not found: Can't resolve '../../../lib/atomcode' 根因：.gitignore 里有一行裸 atomcode（本意是别把下载的 AtomCode 二进制提交进来）， 而 gitignore 的裸名字**匹配任意层级的同名文件或目录** —— 于是 apps/web/app/lib/atomcode/（M3 写的整个转发适配层，daemon/events/history/live-hub/index 共 5 个文件 1400+ 行）从来没有进过仓库。开发机与测试机上是靠 rsync 有这份代码， 所以 M3 的 Playwright 10/10 是真过的，但**任何人 clone 这个仓库都构建不出来**。 修： · 改成 /atomcode（只忽略仓库根目录那一个文件；二进制只存在于 daemon 镜像里）； · 把适配层 5 个文件补进仓库； · 顺带修 *.log 把报告引用的**原始证据**也吞掉的问题：docs/evidence/ 与 docs/eval/ 下的 .log 是「数字能回溯到一次真实调用」的凭证（总控红线 1、5），必须在仓库里。 提交前逐个扫过明文密钥（hunt_tools_* / sk-* / Bearer …），零命中。 同时落地两条已拍板决策（总控规则 9、10，M3 U-10/U-11 的答复），都在适配层做、前端零改动： · 决策 9：agent 选择器保留但要让人看懂切的是**审批档**不是换助手 —— 适配层把它的 name 改成「投研助手 · 审批档 build」、description 说明全局生效与 guard 兜底； · 决策 10：接受同一时刻只跑一个回合，但**忙时必须有明确提示** —— 入队那一刻就把用户消息和一条排队说明推给他（共用同一个 assistant 消息 id， 否则界面上会出现两条助手消息），并把超时计时改成从真正开跑算起。 tsc 0 错，适配层单测 25 条全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 9 天前 | |
fix(m4): .gitignore 的裸 atomcode 把 M3 整个适配层吞掉了 —— 从零 clone 构建不出来 **从零安装测试撞出来的真缺陷**（M4 任务书第 3 条的价值就在这）： 在测试机上用 install.sh 从 GitHub clone feat/m4 装一遍，web 镜像构建直接失败： ./app/api/opencode/[...path]/route.ts Module not found: Can't resolve '../../../lib/atomcode' 根因：.gitignore 里有一行裸 atomcode（本意是别把下载的 AtomCode 二进制提交进来）， 而 gitignore 的裸名字**匹配任意层级的同名文件或目录** —— 于是 apps/web/app/lib/atomcode/（M3 写的整个转发适配层，daemon/events/history/live-hub/index 共 5 个文件 1400+ 行）从来没有进过仓库。开发机与测试机上是靠 rsync 有这份代码， 所以 M3 的 Playwright 10/10 是真过的，但**任何人 clone 这个仓库都构建不出来**。 修： · 改成 /atomcode（只忽略仓库根目录那一个文件；二进制只存在于 daemon 镜像里）； · 把适配层 5 个文件补进仓库； · 顺带修 *.log 把报告引用的**原始证据**也吞掉的问题：docs/evidence/ 与 docs/eval/ 下的 .log 是「数字能回溯到一次真实调用」的凭证（总控红线 1、5），必须在仓库里。 提交前逐个扫过明文密钥（hunt_tools_* / sk-* / Bearer …），零命中。 同时落地两条已拍板决策（总控规则 9、10，M3 U-10/U-11 的答复），都在适配层做、前端零改动： · 决策 9：agent 选择器保留但要让人看懂切的是**审批档**不是换助手 —— 适配层把它的 name 改成「投研助手 · 审批档 build」、description 说明全局生效与 guard 兜底； · 决策 10：接受同一时刻只跑一个回合，但**忙时必须有明确提示** —— 入队那一刻就把用户消息和一条排队说明推给他（共用同一个 assistant 消息 id， 否则界面上会出现两条助手消息），并把超时计时改成从真正开跑算起。 tsc 0 错，适配层单测 25 条全过。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 9 天前 | |
docs(m2): 报告补 §4.2（q5 试跑排除超时风险）与 §4.3（两边工具清单本来就不一样） §4.2 —— 用当天剩余额度跑了最吃工具的 q5（HCA 侧）：7 轮、13 次工具调用全成功、 9/9 MCP、墙钟 62.6 秒、199 152 token。正式批次的 900 秒上限有充分余量， 超时风险排除。按 q1 + q5 外推，30 次约 240 万 token。 §4.3 —— **读这份 A/B 之前必须知道的前提**，零 token 取证、三处交叉核对： 社区版 1.2.0 的 opencode.jsonc 只注册 4 个 MCP（watchlist / portfolio / uzi / hunter_user），HCA 注册 9 个。不是我们把基线配坏了：仓库里从 1.2.0 镜像取的 那份、测试机上另一条链路的真实部署、我们的评测基线，三份逐字一致。 所以总分是「agent 引擎 + 工具清单」的合成，**只有 C 维度与工具清单无关** —— 结论一节会把「总分比」与「只看 C 维度的比」分开列，并点明 fork 闸门 （总分 ≥ 80%）因此偏松。 顺带把 q3 的基准答案零 token 取好了（matched 313 / universe 5237， 前 10 只带 ROE 与 PE-TTM），A1/A2 对着它打分；正式批次跑完再取一次同口径对照。 另记一条：market_screen 的脚本语言没有 fundamental() 函数，要筛基本面得直接写 扫描源字段名 —— 模型能不能自己找到这条路正是 q3 要考的。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 10 天前 | |
feat(m3): Web 接入收口 —— 真部署真测，Playwright 10/10，修 5 个只有真跑才暴露的缺陷 对应计划 v0.2 TP-06 方案 B。测试机 http://34.133.8.3:3200 公网可用。 **在真实部署上抓到并修掉的 5 个（都不是写代码时能发现的）** 1. web 读不到 daemon token（EACCES），整个适配层是废的 —— 而容器一直 healthy（健康检查只看首页）。token 是 0640 hca:hca(gid 10001)，web 跑的是 nextjs(uid 1001/gid 65533)。修：compose 给 web 加 group_add ["10001"]， token 不放宽。更要紧的是 up.sh 的自检当时打 model=— 却照常报「完成」—— 改成 web→daemon 这一跳失败即部署失败。 2. 管理员账号从来没建成，而 admin.txt 里躺着一个口令。.local 是 RFC 6761/6762 的 special-use 域名，api 的 email_validator 直接 422； create_admin.py 又是先写文件后注册。改：默认邮箱换自有域名子域、 **建成之后才写文件**、建完登录回验、建不成即部署失败。 3. 幂等判据用错 HTTP 码：invite 模式下已存在的邮箱再注册返回 400 「需要邀请码」而不是 409，第二次部署报假失败。改成先用已存口令登一次。 4. chat_kpred.reports 表在开源迁移里根本没有 —— chat_kpred.py 一直在用它做 Kronos 报告的刷新恢复，写读都包在 try/except 里，所以不报错、只降级： 接口 200 返回空列表，用户看到「图刷新就没了」。补 0023 迁移，compose 把 仓库的 db/migrations 设成 api 的迁移源（0001–0022 与镜像里那份 sha256 逐文件一致，挂载不改变已有行为）。 5. 模型绕过 MCP 层直接跑 MCP server 的源码（待办池 P1-18，这次被真浏览器 拍到）：read_file /opt/hca/mcp/watchlist_mcp.py（guard 拒了）→ /opt/hca/venv-hunter/bin/python -c "sys.path.insert(...)"（放行了）→ 答出真实现价还标「数据来源: stock_quickview」。数字是真的，但拿不到 _hermes_user_id 注入、不进审计、前端收到的工具名是 bash，富卡片退化成 通用卡。老 guard 漏它是因为只查首词**之后**的 token，而那个解释器正是 首词、sys.path 那串又藏在引号里。修：guard.py 对整条命令原文硬拦 /opt/hca，补 3 条单测（含「别把正常的 python3 -c 一起拦了」）。 **测试** - 适配层单测 25 条（新增 4 条：permission_request 的自动 deny —— 它在 10 步 端到端里一次都没触发，只能靠单测钉住，包括「回 daemon 失败要如实写进提示」） - pytest tools/tests 130 条、tsc --noEmit 0 错 - Playwright 真浏览器 10/10，16 张截图 + 脚本写的 result.json - SSE 断线重连两套：HTTP 层（只断 SSE）实测重连后能继续收同一轮事件、 终态收到、**空窗期不补发**、刷新能完整拿回；浏览器层断网 6 秒同样通过 **如实记录：验收脚本自己写松过三处断言**（报告 §4.4）。「问一个会调 MCP 的 问题」原来断言 stock_quickview —— 那四个字在用户发的那句话里就有，于是把 上面第 5 条那次真实的绕过判成了过；「触发技能」同理；「工具卡片进 ArtifactPanel」原来是「点一下就算过」，前后两张截图 md5 一模一样（富卡片 根本没有展开态）。都已改成只认被测系统产出的东西。 **本轮不含 TP-08**（install.sh、升级回滚）—— 独立工作包，总进度表已单列。 关闭 P0-8（api/postgres/redis 纳入 compose）、P1-18；新增 P1-19（ user_input_request / policy_intervention 未在真实链路验证）、P1-20（guard 不拦 import akshare）、P2-11（SSE 空窗不补发）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 9 天前 | |
feat(i2): 瀑布表生成器 + 两阶段评测栈的起停脚本 · tools/eval/waterfall_report.py：把 <case>.json 的段落切分与 <case>.shim.jsonl 的上游请求拼成一张「时间都花在哪了」的表，缺数据写 —— 不推算。 **改正一处归因**：PreToolUse/PostToolUse 的耗时**不在工具段里** —— pilot 实测工具段 1157 ms、工具自报 1156 ms，差 1 ms，说明上游是在 tool_start 之前跑 Pre、tool_result 之后跑 Post，两跳都落进相邻的模型段。 所以 hook 只能用 hook_bench.py 单独量，表里那一行改叫「工具段余量」。 · deploy/docker-compose.yml 把 HCA_MCP_DISABLE / HCA_HOOKD 传进 daemon。 · deploy/eval/docker-compose.i2.yml 的模板目录可换：基线阶段挂 I2 之前那版 workspace-template，优化阶段挂当前的 —— 镜像只建一次，两阶段差异全在 挂进去的模板与几个开关上，比的是改动本身不是两次构建。 · sync-from-test.sh 支持 HCA_TEST_SRC。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 9 天前 | |
docs(m5): 报告 §3.14 + 待办池 P0-10 + 运维文档两条排查项（都来自实测） Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 9 天前 |