# P4 文档审查轮反思:跨文档转述坐标系错、RJ 收口表目标侧冲突、外部依赖时间维度过期

- **日期**:2026-06-24
- **任务类型**:`/code-review v0.2.0-rc5` 重点审查 P4 文档质量
- **审查范围**:`v0.2.0-rc5..HEAD`(`f859896..f24684a`,2 commits / 33 文件 / +8256 -442),主体为 `docs/design/p4-method-jit/` 子目录扩展(单文件 360 行 → 10 文件 8143 行,2026-06-24 落 commit `f24684a`)
- **审查报告**:`.code-review/from-v0.2.0-rc5/from-v0.2.0-rc5-to-f24684a.md`(240 行,结论 ⚠️ REQUEST_CHANGES)
- **执行模式**:主助理派 4 个 `llmdoc:investigator` 子代理并行审查 10 篇 P4 文档(A/B/C/D 组各 2-3 文件)+ 主助理汇总收口
- **产出**:4 项阻塞 / 8 项重要建议 / 12 项小问题 / 26 条校验通过的正面发现

## 任务

用户用 `/code-review` 触发审查管线,审查范围 `v0.2.0-rc5..HEAD`,重点审查 P4 文档质量。本轮变更主体是 P4 设计文档集从单文件扩展为子目录(对齐 P2/P3 详细深度),其它变更仅是同步刷新(P1/P2/P3 子目录 + llmdoc 状态行 + README 等)。主助理需:

1. 派子代理并行审查 10 篇 P4 文档(子代理分组维度:`00 + implementation-progress` / `01 + 02 + 03` / `04 + 05 + 06` / `07 + 08`);
2. 子代理在组内各自验证内部一致性 + 跨文档引用真实性 + llmdoc 必读纪律对齐 + 外部依赖现状(其中 C 组核 wazero 实现、Go 版本);
3. 主助理汇总归类、做冲突裁决、输出审查报告。

## 预期 vs 实际

- **预期**:P4 单文件扩展子目录是 multi-doc-drafting 二轮验证后(P2 子目录扩展为先例)的一样的工作流第三轮,预期主体应稳健,审查结果以「机械化的小问题清单 + 个别坐标系/版本号过期」为主。
- **实际**:**1 处设计层根本矛盾**(03 §8 vs 04 §5 + RJ-8 三方互斥,P4 投机生命周期 tier 状态归属未定)+ **2 处影响外部读者的事实层错误**(wazero 采石场指针全卷过期 + macOS arm64 MAP_JIT 存在性证明失实)+ **1 处坐标系错误的核心叙事**(P3 现状 2.95x vs luajc 档 4.4x 直接比大小,已扩散至 `llmdoc/index.md` + `startup.md`)+ ~20 处子目录内部章节交叉引用错位。**真正的根因不是「文档没写好」**,而是大型文档扩展过程中,**跨文档转述时基线/事实层信息会持续过期或被压缩丢失**,且**多 RJ 同目标时收口协议没做事实层一致性二次审查**。

## 教训(每条首句为「下次什么场景会触发」)

### 1. 跨文档转述 perf 数字时基线信息丢失 = 隐蔽的坐标系错误

**触发场景**:大型文档集起草/扩展时,关键性能数字会从原始测点(子文档自证)被反复转述到 00 总览 / implementation-progress / llmdoc 索引 / startup 状态行——每一跳都可能因「为求简洁」省掉基线后缀,使下游读者看见两个本不在同一坐标系的数字直接比大小。

**实例**(本轮审查报告 §1 阻塞问题):
- `docs/design/p4-method-jit/00-overview.md:163` 与 `implementation-progress.md:32` 写「loop 2.95x ≪ luajc 档 4.4x」;
- `docs/design/p4-method-jit/01-launch-judgment.md:§3.3` 自证:loop 2.95x **over P1**,4.4x **over gopher-lua**——两个不同基线;
- 真实关系:loop **7.2x over gopher-lua > 4.4x luajc 档**(列内核 loop 形式 P3 已超 luajc 档);
- 错误已扩散至 `llmdoc/index.md` 与 `llmdoc/startup.md`,直接影响读者对 P4 立项动机的判断——会得到「P3 loop 远未达 luajc 档,所以要做 P4」的反向结论。

P4 立项动机的真相是「非 loop 形式(table 0.88x / call 0.52x / mixed 0.99x)仍 ≪ luajc 档,loop 形式已达标」,这与「loop 现状 2.95x ≪ luajc 档 4.4x」是完全相反的叙事。

**根因**:大型文档集扩展时关键数字会被反复转述(子文档→00 总览→implementation-progress→llmdoc 索引→startup 提醒),**每经过一次转述,基线信息丢失风险递增**。原始数据带显式基线(`2.95x over P1` / `4.4x over gopher-lua`),转述时为求简洁省掉基线后,两个数字看起来「同一坐标系下可直接比大小」,坐标系错误就此潜伏。

**家族关系**:
- 与 [[perf-optimization-workflow]] §5「跨机器/跨参数基线对照」同家族但新维度——前者是**同一机器/参数下做实证(实测层)**,本条是**同一数字跨文档传递时基线丢失(叙事层)**;
- 与 [[2026-06-15-p3-pw10-zerocross-stage3-round]] 教训 3「写 perf 数字必标硬件/参数/日期」对偶——前者是「写时必标」(产出侧),本条是「引用/转述时必带」(消费侧)。

**反例**:本轮已纠正的正确写法在 `docs/design/p4-method-jit/01-launch-judgment.md` §3.3,把 2.95x 与 4.4x 分别带显式 baseline 给出——下游转述只要照抄这一行而非「简化」就不会出错。错例则是 `00-overview.md:163` 用「2.95x ≪ luajc 档 4.4x」一句话,**短到看上去像同坐标系下的大小关系**,这正是坐标系错误最易藏身的形式。

**纪律候选**:
- 大型文档转述 perf 数字时,**首次出现必带「X over baseline」形式**;
- 后续引用要么带完整 over baseline,要么显式注「同前 baseline」;
- **任意两个数字直接比大小前先问「同一 baseline 吗」**——若无法立刻回答就是高风险信号;
- 启动文档(`llmdoc/index.md` + `startup.md`)的状态行写 perf 数字时,**优先附「over X」后缀而非省略**,因为这两处会驱动每次会话的判断,坐标系错误代价最大。

**完成操作步骤**(发现坐标系错误时):
1. 找到原始测点(在哪个子文档首次出现 + 自证基线);
2. 列出所有转述点(grep 一样的数字);
3. 按上一步逐点修复 + 同步 `llmdoc/index.md` + `startup.md`(扩散最深的两处)。

**Promotion 候选**:**首次样本**(本轮第一次以「跨文档传递坐标系错误」形式明确出现),建议**暂留观察**。若 P4 实施期或 P5 文档扩展期再现,候选并入 [[perf-optimization-workflow]] §5 升级为「跨文档传递维度」补充节;或作为新独立小节「§8 转述时必带基线」。

### 2. multi-doc-drafting 收口表里同一目标的多条 RJ 可能事实指向冲突

**触发场景**:multi-doc-drafting 起草轮收尾,收口表已生成、单点收口检查已过——但同一**目标文档+目标章节**收到多条 RJ 时,若各 RJ 描述的事实互斥,单点收口只保「来源齐全」不保「来源一致」,这类冲突会潜入施工依据。

**实例**(本轮审查报告 §2 阻塞问题):
- `docs/design/p4-method-jit/03-speculation-ic.md:854-905`(§7.4 / §8.1 / §9.4)明文「P2 状态机仅有三态 TierInterp/TierGibbous/TierStuck,P4 投机 deopt 不改 tierState,P4 用自己的 `p4SpecState[proto]`」;
- `docs/design/p4-method-jit/03-speculation-ic.md` §4.2 状态机图却同时把 `TierGibbousJIT` / `TierStuckSpeculation` 画进 P2 状态机,与 §7.4/§8 内部自相矛盾;
- `docs/design/p4-method-jit/04-osr-deopt.md:526, 547, 608` §5.2 onOSRExit 伪码直接 `pd.tierState = TierInterp`,§5.3 直接 `pd.tierState = TierStuckSpeculation`;
- `docs/design/p4-method-jit/04-osr-deopt.md` §12 / RJ-8 要求扩 P2 04 §2.1 枚举加 `TierGibbousJIT / TierStuckSpeculation`;
- `docs/design/p4-method-jit/implementation-progress.md` §2.2 同表里 **RJ-7**(03 视角:P2 不感知投机)与 **RJ-8**(04 视角:P2 扩枚举感知投机)**事实指向冲突**,**目标文档同为 P2 04 §2.1**。

**反例**:本轮 26 条「校验通过的正面发现」(审查报告最后一节)有 13 条本身就是「**RJ 收口表完整 / 单点收口协议正确**」类——例如「回填请求 RB-1..RB-9 与 RJ-5..RJ-14/RJ-19/RJ-20/RJ-30..RJ-33 一一对应」、「luajc 档锚点 164μs / 4.4x 在三篇内自洽」、「校准测量 1 三档绝对值表在 01 §1.1 / 02 §3.2 / design-premises 三处完全一致」。这些都是「**来源齐全 + 各自自洽**」类的正面信号,**但与方案互斥性正交**——本轮的 RJ-7/RJ-8 冲突恰好就在「来源齐全 ✅ + 各自自洽 ✅ + 互相对话失败 ❌」这个组合里漏检了。

**根因**:[[multi-doc-drafting]] 的「回填请求收口表 + 单点收口」协议解决了「每个子文档不重复声明回填项」问题,但**未解决「同一目标文档收到多条 RJ 时,各 RJ 描述的事实可能互斥」**——单点收口检查的是「**来源是否齐全**」,不检查「**来源是否一致**」。本轮 03 / 04 两位起草人各自带一个对 P2 04 的修改方案(P4 自管 / P2 扩枚举),收口表把两条都登记,但没做事实层冲突检查。冲突要等到主助理审查侧把 B 组的 03/04 报告与 implementation-progress 报告交叉对账时才浮现。

**家族关系**:
- 与 [[multi-doc-drafting]] 单点收口协议是**直接补充**——单点收口是「来源齐全性」检查,本条提出「目标一致性」检查;
- 是该 guide 二轮零阻塞之后发现的**首个真实失败模式**(P2 扩展 + P4 扩展两轮过去之前未现);
- 与 [[2026-06-11-design-doc-completion.md]]「分散提出、集中收口」对偶——那条管「口径(待定值)收口」,本条管「方案(互斥承诺)收口」,前者收单值,后者收互斥项。

**纪律候选**:
- **收口表生成后增「目标侧一致性」二次审查步骤**——按目标文档+目标章节聚合 RJ,对同组 ≥2 条 RJ 做事实是否互斥的人工裁决;
- 子代理产出 RJ 时若发现可能冲突,**在 RJ 描述里注「与同表 RJ-X 在 P2 04 处方案对立,需主助理裁决」**;
- 审查侧的对偶招式:**按目标聚合再审**,不只按来源审。

**完成操作步骤**(主助理收口时):
1. 主助理产出收口表后,**额外做一遍按目标聚合的视图**——把 RJ 表按「目标文档:章节」分组而非「来源文档」;
2. 对同目标章节出现 ≥2 条 RJ 的组,**逐组判断各条 RJ 描述是否互斥**——本轮 P2 04 §2.1 落两条 RJ-7/RJ-8 即应触发;
3. 互斥即标「需主助理裁决方案 A/B」,**不裁决前文档集不应作为施工依据**;
4. 裁决后撤回失败方的 RJ + 同步删除该方的对应文档段(本轮即:若选方案 A 则撤 RJ-8/9/10 + 删 04 §5.2/§5.3 的 `tierState=...` 直接赋值)。

**Promotion 候选**:**首次样本**,建议**暂留观察**。若再现可入 [[multi-doc-drafting]] guide 作「§收口表目标侧一致性二次审查」新纪律。

### 3. 外部依赖项的「采石场参考 / 现状描述」易过期,文档扩展时需重核

**触发场景**:设计文档引用外部代码库(wazero / Go runtime / OS API / 第三方包)作为采石场或现状描述时,这些外部事实层信息**有时间维度衰变**;尤其大型子目录扩展由不同子代理并行起草,各自带着自己时点的快照——若收尾轮未做「文档发布前对外部依赖现状再核」,扩展完毕的文档可能引用已不复存在的代码位置。

**实例**(本轮审查报告 §3 / §4 阻塞问题 + §7 重要建议 + ~20 处小问题):

- **实例 1(wazero compiler 子包消失)**:`docs/design/p4-method-jit/05-system-pipeline.md` :108, :154, :191, :283, :328, :376, :444 与 `06-backends.md:118` 引用 wazero `internal/engine/compiler` 子包(callEngine、arch_amd64.s 等)作为采石场。实测 wazero v1.12.0 已切到 `internal/engine/wazevo`(SSA + per-ISA backend,位于 `internal/engine/wazevo/backend/isa/{amd64,arm64}/`),compiler 子包不存在——按文档查源会扑空。

- **实例 2(macOS MAP_JIT 实现失实)**:`docs/design/p4-method-jit/05-system-pipeline.md:328`、`06-backends.md:167 / :244` 称 wazero `internal/platform/mmap_darwin_arm64.go` 已实现 MAP_JIT + pthread_jit_write_protect_np。实测该文件不存在;wazero darwin/arm64 走普通 mmap + mprotect。**把不存在的实现当 PJ8 依据,会让 P4 立项的「四件套有可参照」前提失效**。

- **实例 3(Go 版本矩阵过保)**:`docs/design/p4-method-jit/00-overview.md:160`、`06-backends.md:876`、`08-testing-strategy.md:959` 写 CI 矩阵「Go 1.22 / 1.24 / tip」,本仓 `go.mod` 已 `go 1.26.2`(2026 年仓库实际配置),Go 1.22 已过保(超出官方支持窗口)。

- **实例 4(P4 子目录内部章节交叉引用错位 ~20 处)**:00 §6 引 `[04 §8.3]` 但 04 §8.3 是 status 编码而非协程规则;00 §10 多处引 `[04 §3.3 注]` 但该注不存在,真正位置是 §3.6 / §3.7;implementation-progress §3.1「编译执行线程模型」标 `[01 §0.4]` 但实际是 `[02 §1.4 / §5.2]`。这是子目录扩展过程中**文档相互引用「快照与目标版本错位」**——每篇子文档起草时引用兄弟子文档的章节号,起草完成后兄弟文档结构若再变动,引用没自动同步。

**根因**:扩展子目录时各子文档由不同子代理并行起草,**起草时引用的外部依赖现状(wazero / Go / 平台 API)和内部章节号是各自时点的快照**,但收尾轮未做「文档发布前对外部依赖现状再核 + 对内部章节号再扫」。子目录是 2026-06 月扩展,但 wazero 切 wazevo 是 v1.0+ 早期、Go 1.25/1.26 是 2025-08 / 2026-02 发布——这些事实层变化在扩展时没有被对照。

**家族关系**:
- 与 [[design-claims-vs-codebase-physics]] 是**对偶面**——前者「自家 codebase physics 重核」(空间维度,自家代码),本条「外部依赖 physics 重核」(时间维度,外部依赖,wazero / Go 版本 / 平台 API);
- 与 [[2026-06-14-p3-pw7-pw4b-closure-tforloop-round]] 教训 1「难点过期」+ [[2026-06-16-vs0e-varargs-stack-underflow-round]] 教训 1「调研先于实现」**同家族**——三个独立实例都指向「设计/文档撰写时引用的事实快照,可能已不再成立」,**已跨过 3 实例阈值**。

**纪律候选**:
- **大型文档发布前增「事实层重核 checklist」步骤**——逐条核 wazero/Go/平台 API 等外部引用是否仍然成立;
- **核内部章节号是否对位**——子目录拆分/扩展后,所有 `[XX §Y.Z]` 形式的引用应批量 grep + 对核当前实际位置;
- **收尾轮指定一个子代理专责「跨文档引用真实性 + 外部依赖现状」复查**,与起草子代理分工解耦(避免本人复核盲区)。

**完成操作步骤**(发布前):
1. **外部依赖核**:逐条列出文档中提到的外部库代号(wazero / Go runtime / OS API / 第三方包) + 对应文件路径/版本,**真去 `~/go/pkg/mod/...` 找一遍**,扑空就标过期;
2. **Go/工具版本核**:对照本仓 `go.mod` + `.github/workflows/` 实际 CI 矩阵 + 官方支持窗口,统一版本号;
3. **章节号对位核**:`grep -rn '\[0[0-9] §' docs/design/p4-method-jit/` 列所有跨子文档引用 → 对应目标章节实际标题逐条核;
4. **llmdoc 路径核**:子目录文档到 `llmdoc/` 的相对路径要核到层数(本轮 03/07 全卷 `../../llmdoc` 而应为 `../../../llmdoc`,各 ~10 处)。

**Promotion 候选**:**强烈建议提升**,可考虑两条路:
- (路径 A)落入 [[design-claims-vs-codebase-physics]] §5「时间维度」新章(承 PW7/VS0-e 两轮已留 promotion 钩),把「自家 physics 时间维度过期 + 外部依赖时间维度过期」作两小节并列;
- (路径 B)作新 guide 立项「外部依赖现状重核」(若 P5 文档扩展或公开 API issue 接入再现可独立);
- recorder 定夺。

文档侧补救立刻可做:大型文档发布前增「事实层重核 checklist」步骤(逐条核 wazero/Go/平台 API 等外部引用是否仍然成立 + 内部章节号对位扫)。

### 4. 工作流确认:并行 investigator 子代理 + 主助理收口写最终报告 = 大文档审查的有效模式

**触发场景**:任务是「审查 N 篇互相引用的大型文档,且其中含跨文档冲突 + 外部依赖现状核 + 内部章节引用核」时(本轮 8143 行 + 33 文件变更),需要避免主助理 context 被原文撑爆。

**实例**(本轮主助理派的子代理分组与产出):
- A 组(`00-overview.md` + `implementation-progress.md`):审顶层文档自洽性 + RJ 收口表完整性;
- B 组(`01-launch-judgment.md` + `02-template-direction.md` + `03-speculation-ic.md`):审立项判定数据链 + 方向裁决 + 投机 IC 设计;
- C 组(`04-osr-deopt.md` + `05-system-pipeline.md` + `06-backends.md`):审 OSR 协议 + 四项税自付 + 双后端骨架,**重点核外部依赖现状**(wazero 实现 / Go 版本);
- D 组(`07-p3-retirement.md` + `08-testing-strategy.md`):审 P3 去留决策 + V1-V22 验收口径。

每组各自验证:内部一致性 + 跨文档引用真实性 + llmdoc 必读纪律对齐 + 外部依赖现状。返回报告均带**具体 line 号 + 校验通过的反向证据**(26 条正面发现),主助理只做汇总归类与冲突裁决(发现 03 §8 vs 04 §5 + RJ-8 三方矛盾 = 主助理在合并 B 组 + C 组 + A 组报告时**跨子代理证据链**才发现的设计层冲突)。

24 项问题分类分级 + 决策依据完整,主助理 context 没被 8143 行原文撑爆。

**根因**:[[multi-doc-drafting]] 三协议(并行/单点收口/回填请求)在审查侧的镜像——
- 起草侧:子代理写、主助理整合;
- 审查侧:子代理审、主助理整合;
- 同一三协议套用,职责对调即可。

**家族关系**:
- 与 [[multi-doc-drafting]] 是镜像关系——起草侧二轮验证(P1 19 篇 + P2 子目录扩展)+ 本轮审查侧第一次验证,合计**三次零阻塞**;
- 与 [[2026-06-13-p2-doc-expansion-round]] 同轴线——P2 单文件 → 子目录起草侧,本轮 P4 子目录审查侧,**起草/审查对偶面一样的协议**。

**纪律候选**:
- 大型文档审查任务(N 篇 + 跨文档冲突可能)优先派 N 个 investigator 子代理并行分组,主助理只做收口与裁决;
- 子代理 prompt 模板:**返回必须带 line 号 + 反向证据(校验通过的引用也要列)**——只列问题不列「没问题项」会让主助理无法判断是「确认无误」还是「子代理漏看」;
- 分组维度按「目标文档逻辑簇」而非「按 N 等分」——A/B/C/D 组各自有自然主题。

**完成操作步骤**(派 investigator 子代理审查时):
1. **分组维度优先按文档逻辑簇**——本轮按「顶层 + progress / 立项相关 / 实现相关 / 测试与退役」分簇,每组内部主题强耦合,跨组弱耦合;
2. **prompt 必含返回格式**——「问题 + line 号 + 引用证据」+「正面发现 + line 号」并列,**绝不允许只列问题**;
3. **冲突裁决留给主助理**——子代理只产证据 + 标「可能与 X 冲突」,**不替主助理定下来**;
4. **跨组冲突主助理在收口时浮现**——本轮 RJ-7/RJ-8 冲突是 A 组(progress)+ B 组(03)+ C 组(04)三方证据交叉对账才看见的,**没有任何单一子代理能独立发现**——这是「分散探测、集中裁决」工作流的强信号红利。

**Promotion 候选**:**首次审查侧样本,暂留观察**。建议在 [[multi-doc-drafting]] guide 实践证据节加一行:「本协议适用于审查任务,子代理职责对调即可」。下次审查侧再现(P5 文档扩展审查 / 大型 changelog 审查类)可正式入 guide 作镜像段。

## 总览观察:三条教训共享同一深层模式

三条教训(跨文档转述基线丢失 / 多 RJ 同目标事实互斥 / 外部依赖现状过期)表面分属不同维度,但**共享同一深层模式**——**「展开式文档(N 个起草节点并行)+ 单点收口协议(查齐全性而非一致性)」在三个独立切面同时失效**:

- 切面 1(教训 1,数字转述):起草子代理 A 把数字带基线写在子文档,起草子代理 B 把数字「简化」写在 00 总览,**单点收口只查「数字一致」不查「基线一致」**;
- 切面 2(教训 2,RJ 收口):起草子代理 A 提 RJ-7,起草子代理 B 提 RJ-8,**单点收口只查「都登记了」不查「方案是否互斥」**;
- 切面 3(教训 3,外部依赖):起草子代理 A 用 2024 年知识写 wazero compiler,起草子代理 B 用 2024 年知识写 macOS MAP_JIT,**单点收口只查「子文档自洽」不查「外部世界是否仍这样」**。

[[multi-doc-drafting]] 协议的现行版「单点收口 = 检查来源齐全 + 各自自洽」是**不充分的**,需要补**第二轮一致性审查**——三个维度(数字基线 / RJ 目标互斥 / 外部依赖现状)逐条核。这第二轮审查若由起草子代理本人做,会有盲区(同人写同人核);**应由专责审查子代理或主助理在收口时单独走一遍**。

**这条总览观察本身是否值得 promotion?** 三条独立教训聚合 + 同一深层模式 + 直接补 multi-doc-drafting 现行协议短板,**已具备 first-class 提升潜力**;但单条提示与三条教训分立的实际完成区分微弱,建议**先按三条独立教训各自 promotion,待下次大型文档扩展再现时再聚合判定**——避免一次性把 guide 改得过大失焦。



- **要做大型设计文档集扩展/审查时**——尤其单文件→子目录拆分类(教训 1/2/3 同时适用),收尾轮务必跑「跨文档转述基线核 / 收口表目标侧聚合核 / 外部依赖现状核 / 内部章节号对位核」四件套;
- **跨文档转述 perf 数字 / 性能指标比对时**(教训 1)——任意两个数字直接比大小前先问「同一 baseline 吗」;
- **multi-doc-drafting 收口表生成后审查时**(教训 2)——按目标文档+章节聚合 RJ,对同组 ≥2 条 RJ 做事实层冲突裁决;
- **文档引用外部代码库 / 第三方实现 / 工具版本时**(教训 3)——大型文档发布前增「事实层重核 checklist」,逐条核外部引用是否仍然成立;
- **审查任务规模超过单 context 容量时**(工作流确认 4)——派 N 个 investigator 子代理并行分组,主助理只做收口与裁决,子代理返回必须带 line 号 + 反向证据。

## 关联

- [[multi-doc-drafting]](本轮教训 2 + 工作流确认 4 直接补充——目标侧一致性二次审查 + 审查侧镜像协议)
- [[design-claims-vs-codebase-physics]](本轮教训 3 强 promotion 候选——「时间维度」新章,自家 + 外部依赖两小节并列)
- [[perf-optimization-workflow]] §5(本轮教训 1 暂留观察候选——跨文档传递维度补充)
- [[2026-06-15-p3-pw10-zerocross-stage3-round]] 教训 3(写 perf 数字必标硬件/参数/日期 = 产出侧;本轮教训 1 = 消费侧对偶)
- [[2026-06-14-p3-pw7-pw4b-closure-tforloop-round]] 教训 1(难点过期家族第 1 实例)
- [[2026-06-16-vs0e-varargs-stack-underflow-round]] 教训 1(调研先于实现家族第 2 实例;本轮教训 3 是第 3 实例已跨阈值)
- [[2026-06-13-p2-doc-expansion-round]](P2 单文件→子目录起草侧;本轮 P4 子目录审查侧——起草/审查对偶面)
- 审查报告:`.code-review/from-v0.2.0-rc5/from-v0.2.0-rc5-to-f24684a.md`
- 阻塞问题 1 扩散点:`llmdoc/index.md` + `llmdoc/startup.md`(同步修复优先级最高,影响每次会话启动判断)
- 阻塞问题 2 待用户裁决:方案 A(P4 自管,与 03 §7.4/§8/§9.4 一致)vs 方案 B(P2 扩枚举,撤回 03 视角)
