跳到主要内容

主架构膨胀守门机制

1. 背景​

  • projects/finbayes/engineering/architecture.md 在 M0 启动时已达约 268K 字符 / 6052 行。
  • M0 不立刻拆主架构的理由：Claude 主控具备 1M context 容量，单文件可整体加载；Codex 不读主架构（走 engineering-packs / subsystems / topics 聚合包），无 Codex 侧上下文压力。
  • 若 M0 期间继续在主架构内累积，则 M1 / M2 拆分成本将随章节深度与交叉引用密度指数级增长。守门机制目标：把"膨胀"以硬约束方式拦在 M0 内。

2. 守门范式（M0 期间硬约束）​

情形处置
任何对主架构的新增内容 ≥ 80 行强制拆出，主架构只留指针段（1-3 行 cross-reference）
子系统级新增入 projects/finbayes/engineering/subsystems/<id>.md（已落地 4 份范式：eval-harness / consistency-middleware / knowledge-graph-service / mca-classifier）
里程碑级新增入 projects/finbayes/engineering/engineering-packs/m{N}-*.md
横切议题级新增入 for-agents/topics/<id>/（agent-pack.yaml 手写聚合声明）

判定时点：每次准备向 architecture.md 提交编辑前，先估算 diff 行数。≥ 80 行触发拆分判断，由当前编辑者写一份目标载体（subsystem / engineering-pack / topic），主架构只回写指针。

判据：正向能力扩展 vs 冗余膨胀（承接 2026-05-29 fresh review W3）

行数 / 字符阈值只度量"长了多少"，不度量"长的是不是该长的"。守门若只看增长度量，会反噬正向能力写厚（Build-Y 交付契约越完整、字数越多越触发拦截，与 ADR-013 Build-Y 优先 自相矛盾）。因此在行数阈值之外加一条性质判据：

内容性质计不计膨胀处置
正向能力定义 / Build-Y 交付契约（新字段 / 新任务类型 / 新机制的正向能力陈述、必含产出、条件式契约）不计入膨胀（豁免）仍按 §2 ≥ 80 行触发"拆分"判断（拆到 subsystem / engineering-pack），但不触发 §4 的"被动拆"惩罚式评审——它是该长的，只需归到对的载体
冗余 / 重复 / 废话（同一约束多处复述、已拆出内容回灌、可指针化却内联的交叉引用、与正向能力无关的注解堆叠）计入膨胀触发 §2 拆分 + §4 增长阈值评审；优先删重、转指针

判定顺序：先判性质（正向能力扩展 / 冗余），再判行数。先归类，再度量——正向能力扩展按"归到对的载体"处置（拆分而非压制），冗余膨胀按"删 / 转指针"处置。两者都可能 ≥ 80 行触发拆分，但只有冗余膨胀计入 §4 的增长阈值惩罚。

边界 case：当一段内容既含正向能力定义又含冗余复述时，按可分离原则拆开各自归类——正向部分豁免、冗余部分计膨胀；不允许"整段以正向能力名义豁免"来夹带冗余。

代码 vs ADR 微差异归口规则：当工程实施代码与 ADR 出现微差异时，先评估差异是「实施细节」（代码侧改）还是「契约调整」（ADR 侧改）。

  • 实施细节 → 直接 PR 改代码 + 在对应 ADR 末尾补 audit trail 段（≤ 3 行说明差异性质与回归保障）。
  • 契约调整 → 走 R1 修订流程（参见 变更协议）+ 反向 propagate 全仓引用（承接 Step 5 RCA R3 整改）。

3. 未来拆分路线图​

不立刻拆，但显式约定每章节的出口与触发条件。

当前章节触发拆分的 milestone拆到哪触发条件
§9 子系统组件（566 行 / ~28K 字符）M1architecture/chapters/9-subsystems.md子系统从 4 个扩到 6+ 时
§10 场景流转M2architecture/chapters/10-scenarios.md场景从 3 类扩到 5+ 时
§11 状态机M1architecture/chapters/11-state-machine.md状态对象 ≥ 8 个时
§20-21 测试评估M1architecture/chapters/20-21-test-eval.md11 维评测落地工程时
§25 里程碑映射M2architecture/chapters/25-milestone-map.md里程碑从 M0 扩到 M3+ 时

拆分动作走 governance/change-protocol.md 的章节级拆分流程，留 ADR 记录前后路径变化。

4. M0 收尾盘点节奏​

M0 结束时立刻对 architecture.md 跑一次度量基线对比：

wc -l projects/finbayes/engineering/architecture.md
wc -c projects/finbayes/engineering/architecture.md

M0 启动基线：6052 行 / 268534 字符（2026-05-28 测得）。

判定阈值（增长量按 §2 性质判据扣除正向能力扩展豁免部分后计——只对冗余 / 重复 / 废话造成的净增长计阈值）：

  • 增长 < 5%：放行。
  • 增长 5%-10%：触发主动复盘，复核 §2 守门是否被绕过、豁免是否被滥用夹带冗余。
  • 增长 > 10%：触发"被动拆"评审，至少 1 章拆出，并复核守门规则本身是否需要收紧。

注：正向能力扩展即便使总字符大幅增长，也按 §2 归到对的载体（subsystem / engineering-pack）即可，不触发本节惩罚式"被动拆"评审。

5. 关联资产​