| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
docs(i3): 两台部署升级到 v0.2.1 并各跑一次真浏览器（5/5）+ 升级撞出的密钥缺陷归档 测试机（rsync + 只重建 daemon 镜像 + 重叠 fork 层）与香港（install.sh --upgrade --ref v0.2.1 + 重叠 fork 层）都在 v0.2.1、MCP 10/10、网页 200； 两台都核过容器里 persona.md 与 .atomcode.md 真的换成了改对版。 真浏览器各发一轮真实对话：测试机评分 78、香港评分 76，末尾免责三句齐全，5/5。 顺带记下：升级会重建 daemon 基础镜像，**fork 那一层就旧了**，up.sh 会警告 但不会自动重叠 —— 不补跑 switch-to-fork.sh 的表现是「代码更新了模型行为没变」。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(i3): up.sh 的密钥加固只看目录不看文件 —— 后放进去的 key 永远改不对组 **真部署撞出来的，不是想出来的。** I3 在测试机上重建 daemon 之后， 第一轮真实对话被网关回 401（ invalid_api_key/hunter_key_required）。 查下去：~/hca/deploy-secrets/llm-key 的**组**是宿主用户的组、不是容器的 10001， daemon（uid 10001）读不到 → [hca-init] … key=（空）。 根因在 harden_secrets 的早退判据**只 stat 了目录**：目录之前 chgrp 过一次， 于是「目录已经对了 → return」，**后来放进去的那把 key 永远改不过来**。 （cp、编辑器写出来的新文件带的是当前用户的组。） **这个缺陷最难发现的地方是它不报错**：up.sh 的自检全绿、六个容器全 healthy —— 自检那一跳（web→daemon 读模型清单）根本不需要模型 key。只有真发一句话才炸。 hca-init 本身的诊断是好的（明写「存在但读不到」以及两条修法）， 但那行日志躺在 docker logs 里，没人会在自检全过之后去翻它。 修法：早退判据连 -maxdepth 1 -type f 的文件一起看（组不是 10001、 或者组读位没开，任一命中就继续往下走），并把坏文件名打出来。 +4 条单测（tools/tests/test_harden_secrets.py）—— 把那个 shell 函数从 up.sh 里 摘出来真跑，堵死 sudo 与 docker 逼它走兜底分支；反向用例把判据里的 10001 换成用例自己的组，这样「三条都对就早退」那条路也能真的走到。 另外补一套 I3 的真浏览器回归 tools/e2e/i3-persona.mjs： 改的是人设，而 I2 §2.9.4 回退的两处里**有一处评测脚本看不见** （C1～C5 里没有「末尾风险提示在不在」这一项）。所以在真部署上再发一轮真实对话， 判四条：评分给了 / 风险项在 / **末尾那段 AI 生成标识与风险提示在** / 数字带来源。 测试机实测 **5/5**（烧 51 530 token，截图 + facts.json 在 docs/screenshots/I3/）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(i3): up.sh 的密钥加固只看目录不看文件 —— 后放进去的 key 永远改不对组 **真部署撞出来的，不是想出来的。** I3 在测试机上重建 daemon 之后， 第一轮真实对话被网关回 401（ invalid_api_key/hunter_key_required）。 查下去：~/hca/deploy-secrets/llm-key 的**组**是宿主用户的组、不是容器的 10001， daemon（uid 10001）读不到 → [hca-init] … key=（空）。 根因在 harden_secrets 的早退判据**只 stat 了目录**：目录之前 chgrp 过一次， 于是「目录已经对了 → return」，**后来放进去的那把 key 永远改不过来**。 （cp、编辑器写出来的新文件带的是当前用户的组。） **这个缺陷最难发现的地方是它不报错**：up.sh 的自检全绿、六个容器全 healthy —— 自检那一跳（web→daemon 读模型清单）根本不需要模型 key。只有真发一句话才炸。 hca-init 本身的诊断是好的（明写「存在但读不到」以及两条修法）， 但那行日志躺在 docker logs 里，没人会在自检全过之后去翻它。 修法：早退判据连 -maxdepth 1 -type f 的文件一起看（组不是 10001、 或者组读位没开，任一命中就继续往下走），并把坏文件名打出来。 +4 条单测（tools/tests/test_harden_secrets.py）—— 把那个 shell 函数从 up.sh 里 摘出来真跑，堵死 sudo 与 docker 逼它走兜底分支；反向用例把判据里的 10001 换成用例自己的组，这样「三条都对就早退」那条路也能真的走到。 另外补一套 I3 的真浏览器回归 tools/e2e/i3-persona.mjs： 改的是人设，而 I2 §2.9.4 回退的两处里**有一处评测脚本看不见** （C1～C5 里没有「末尾风险提示在不在」这一项）。所以在真部署上再发一轮真实对话， 判四条：评分给了 / 风险项在 / **末尾那段 AI 生成标识与风险提示在** / 数字带来源。 测试机实测 **5/5**（烧 51 530 token，截图 + facts.json 在 docs/screenshots/I3/）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 | |
fix(i3): up.sh 的密钥加固只看目录不看文件 —— 后放进去的 key 永远改不对组 **真部署撞出来的，不是想出来的。** I3 在测试机上重建 daemon 之后， 第一轮真实对话被网关回 401（ invalid_api_key/hunter_key_required）。 查下去：~/hca/deploy-secrets/llm-key 的**组**是宿主用户的组、不是容器的 10001， daemon（uid 10001）读不到 → [hca-init] … key=（空）。 根因在 harden_secrets 的早退判据**只 stat 了目录**：目录之前 chgrp 过一次， 于是「目录已经对了 → return」，**后来放进去的那把 key 永远改不过来**。 （cp、编辑器写出来的新文件带的是当前用户的组。） **这个缺陷最难发现的地方是它不报错**：up.sh 的自检全绿、六个容器全 healthy —— 自检那一跳（web→daemon 读模型清单）根本不需要模型 key。只有真发一句话才炸。 hca-init 本身的诊断是好的（明写「存在但读不到」以及两条修法）， 但那行日志躺在 docker logs 里，没人会在自检全过之后去翻它。 修法：早退判据连 -maxdepth 1 -type f 的文件一起看（组不是 10001、 或者组读位没开，任一命中就继续往下走），并把坏文件名打出来。 +4 条单测（tools/tests/test_harden_secrets.py）—— 把那个 shell 函数从 up.sh 里 摘出来真跑，堵死 sudo 与 docker 逼它走兜底分支；反向用例把判据里的 10001 换成用例自己的组，这样「三条都对就早退」那条路也能真的走到。 另外补一套 I3 的真浏览器回归 tools/e2e/i3-persona.mjs： 改的是人设，而 I2 §2.9.4 回退的两处里**有一处评测脚本看不见** （C1～C5 里没有「末尾风险提示在不在」这一项）。所以在真部署上再发一轮真实对话， 判四条：评分给了 / 风险项在 / **末尾那段 AI 生成标识与风险提示在** / 数字带来源。 测试机实测 **5/5**（烧 51 530 token，截图 + facts.json 在 docs/screenshots/I3/）。 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 个月前 |
