iomgaa
20fca73847
- 结构.md：vocab 上限 1100；依赖图重画，使同一行确实互不依赖（flow 依赖 config，原图把它们放在同一行）。
- 方法.md 第五部分：入口编号由程序分配；实现与消融实现不设代码字段。4.3 ⑨ 补回设计-16 原文：因子与保障同行时核验员只写一句提醒、不判越界。
用户同意执行者的第 1、3–7 条（"同意 A，vocab 上限改为 1100 行"等，见 97a4359 说明）。
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
64 lines
5.3 KiB
Markdown
64 lines
5.3 KiB
Markdown
# 工作记录
|
||
|
||
只记当前状态。一个阶段完成后压缩成几行，细节看提交说明。
|
||
|
||
## 当前目标
|
||
|
||
搭好项目框架：CLAUDE.md、方法、结构都定下来以后，按模块从参考项目搬代码。
|
||
|
||
## 已完成
|
||
|
||
- CLAUDE.md：按官方写法写成（提交 3861fd8 及之后）。
|
||
- `docs/方法.md`：由参考项目的研究方案 v3、设计-15、设计-16 合成（f32c0bd）。之后按用户决定改过：消融只测信息价值选中的格（5e4f8c2）；保障的定义借用"控制变量"和"重构"来说明（141494f）。
|
||
- `docs/结构.md`：13 个模块加 vocab、步骤清单、账本 12 种记录、可替换点、检查规则、粗估规模（6cf9f0c）。
|
||
- 任务书 01（工具链 + vocab）：npm 包、TypeScript、`node --test`、dependency-cruiser 规则全写，临时违规实测 14 条都报错；vocab 1030 行，`npm run check` 通过，`npm test` 24 条通过。结构.md 第八部分补了 vocab 对外内容。
|
||
|
||
## 关键决定（用户原话见各提交说明）
|
||
|
||
- 项目改名 InfoRSI。参考项目 RivalBits 只读。
|
||
- "点"改称"因子"，"保障"保留。
|
||
- 不设轮数上限，只限运行次数。
|
||
- 第一次预测放在挑刺之前、看原始提案；第二次预测在冻结之后、看冻结协议。
|
||
- 子 Agent 调研时不写 md 文件，结论直接回报。
|
||
- 提交的字段定义放 vocab，submissions 只判收不收；vocab 只放两个函数（规范序列化、哈希）。用户原话："我都同意"。
|
||
- vocab 上限改为 1100 行（多出来的主要是发给模型的字段说明）。用户原话："同意 A，vocab 上限改为 1100 行。结构.md 由监督者改，你不用动。"
|
||
- 每份预测只对一个候选、每份挑刺只针对一个目标；入口、因子、实现条款的编号由程序按位置分配；实现提交不设代码字段（程序从工作目录冻结）；运行结果用"没启动 / 正常退出 / 超时 / 被取消"一个字段表示启动与结束；四种 token 数都可记测不到。用户原话："3、4、5、6：同意保留你的写法。方法.md 第五部分的表（入口编号、实现的代码字段）由监督者改。"
|
||
- 解释的每格三个数改为可选，关掉消融时不交。用户原话："同意 A：解释的 cells 去掉 minItems，改为可选"。
|
||
- 答案路径、保障动手次数只记读到的原始内容或读不到的原因；在不在位置表里，由以后拿得到位置表的模块现算，不存。用户原话："按'能现算的不存'，tasks 只记读到的原始内容……对表由以后有位置表的模块现算，把这条记进 WORK_LOG。"
|
||
|
||
## 未完成
|
||
|
||
- `inbox/调研.md`：要迁进 `docs/调研/` 的调研结论。
|
||
- `docs/方法.md` 里还有 7 条标〔自定〕的规则，待用户过目。
|
||
- 留给 submissions 的跨字段规则（vocab 字段定义不管）：
|
||
1. q1 ≤ q5 ≤ q9：作者自评、两次预测、解释的每一格。
|
||
2. 因子数不超过上限，回应改过的因子清单同样适用。
|
||
3. 同一提案里两个因子不能延续同一个因子；延续的编号要在信念本里看得到。
|
||
4. 保障短名不能是 `main`，不能写成 `p<数字>`，同一清单里不重复。
|
||
5. 开着消融时每条解释必须交 `cells`，并恰好覆盖材料列出的格；关掉消融时不交。
|
||
6. 解释最多 M 条。
|
||
7. 志愿至少 min(N, 入口总数) 个、不重复、编号都在入口清单里。
|
||
8. 挑刺针对的因子编号在被挑提案的因子范围内。
|
||
9. 回应的逐条答复恰好覆盖针对本候选的全部挑刺；统一的 `sources` 恰好覆盖被合并的原提案。
|
||
10. `reused` 引用的指标存在且是假设专用指标；新登记的指标短名不重复。
|
||
11. 实现和修复：位置表覆盖每个因子和每条保障；代码位置起始行不大于结束行。
|
||
12. 核验：条款、因子、保障逐项全覆盖；没有归属的改动与材料列出的逐条对应。
|
||
13. 消融实现：写了 `cannotRun` 时 `alsoOff` 为空；`alsoOff` 不含本格要关的因子，且都在因子清单里。
|
||
14. 消融核验覆盖每个因子。
|
||
- 答案路径、保障名字"在不在位置表里"的对表，由以后拿得到位置表的模块现算（多半是 materials 或 flow）。
|
||
- 核验提交 `body` 的字段说明要补一句：同一行同时出现在因子和保障里时，在说明里写一句提醒（方法.md 4.3 ⑨）。写 submissions 时一并改。
|
||
- 写 plugin 时实测：源码导入路径带 `.ts` 扩展名，Pi 加载插件能否接受。
|
||
|
||
## 工作方式（用户 2026-10-01 定）
|
||
|
||
每个模块分三步：
|
||
1. 参考项目的会话（监督者）先把这个模块讲给用户：放哪些东西、对外提供哪些函数、预期多少行、参考项目里对应的代码哪些保留哪些删掉。用户和监督者一起确定。
|
||
2. 监督者把确定的内容写成一份任务书，放在 `任务书/` 下，一个模块一份。
|
||
3. 用户在 InfoRSI 目录里另开一个新的 Agent 执行任务书；监督者只监督、核对，不直接写代码。
|
||
|
||
这样做有两个目的：一是检验 CLAUDE.md 和 docs 里的规则对一个全新的 Agent 是否真的起作用；二是让监督者和执行者的思路保持独立，方便发现跑偏。
|
||
|
||
## 下一步
|
||
|
||
任务书 01 已核对通过（97a4359）。下一个是 rules，之后 ledger → …。
|