一次审计带来的计划
PCBA 平台做到 M 阶段时，我对完整源码快照做了一次审计。结果不复杂，但很有分量：
- 核心数据库：62 个实体，102 条关系，Formal V1 migration 已接受
- Phase 1 的最终终点定在 InquiryEligibility（询价资格）
但审计也暴露了一个问题：之前的开发方式是"想到一个功能 → 开 worktree → 自己设计 → 自己建模型 → 自己接数据库"。功能在长，架构在散。62 个实体里面有多少是计划外的？于是有了这份主计划——先定原则，再定路径，再谈功能。
执行原则
优先级排死了，不许商量：
正确性 > 架构一致性 > 完整闭环 > 功能数量 > 开发速度
对应的流程模板也换了：
Architecture Decision → Contract Freeze → Small PR → Tests → Architecture Review → Merge
不是"先写了再说"，是"先冻结契约，再动代码"。契约线（Contract Line）是这条流水线的骨架。
Canonical Product Path
未来所有 Phase 1 开发只允许围绕一条路径：
Material Master
↓
BOM Source
↓
Deterministic Parse（确定性解析）
↓
CandidateBundle
↓
Catalog Snapshot
↓
MatchRun（匹配运行）
↓
MatchCandidate + Evidence
↓
Human MatchDecision（人工决策）
↓
ConfirmedBOMVersion
↓
PCBA Engineering
这条链的每个节点都有明确的实体和状态。亮点在中间几段：
确定性解析：BOM 源文件不是人类可读文本就行的——解析必须是确定性的，同一个文件永远解析出同一个 CandidateBundle，不允许"这次能跑下次不能"。错误分类（skip/none/ambiguous/auto）来自同一个 triage 管线，v1.1 用 LLM 做的 triage 全量实测零改善——18 行全 kept 基线，v1.1 的 +2 是 LLM 随机增益不可复现，于是固化成确定性基线。
Catalog Snapshot：匹配不能对着会变动的目录做。每次 MatchRun 冻结一份快照，快照是匹配的输入基准，也是事后审计的依据。snapshot supersede 机制保证只有最新快照生效——旧快照被 supersede 后立即失效。4,080 → 4,121 ACTIVE 的 master 重建就是走这条链：新快照 7b30c1b5 supersede 旧快照 350d8e77（→ SUPERSEDED），交集 0→41/41。
MatchRun → 人工决策：机器匹配产出候选和证据（匹配到什么、依据什么字段、置信度多少），但最终决策永远是人。真实 MatchRun 已经跑过：DETERMINISTIC 2 runs（BOM-REIMPORT-PCBA 62/63 + Ctr3Pan 43/51），105 条 matched，map-back 0 失败。决策队列（114 行 / 105 候选带 bindingId）在 web 面板里浏览，Owner 逐个记录决策，导出意图 JSON，经 PCBA_D1_INTENTS_JSON 执行——append_match_decision 是 frozen 函数，GUC 必须，decision_set_version 是 run 级逐决策 +1，拒绝条件内置 STALE_VERSION / STALE_PREDECESSOR / BINDING_NOT_CURRENT。
ConfirmedBOMVersion：确认的 BOM 是带身份的——DRAFT 状态 + decision-set/snapshot 身份，发布要过 publish gate（四眼确认）。一份 BOM 从候选到确认，每一步都可回放。
能力极限：一个诚实的数字
给匹配引擎定目标时，最初是 90%→95%。跑完诊断后，结论比数字本身更有意思：
- 引擎对 ground truth 100% 正确——29 个非 auto 行全部与期望一致。引擎没有错。
- 剩余构成：11 个 skip 全是非元件行（PCB/屏蔽罩/散热片/铜柱——用户明确这些以后也要做，元器件是当前主线）；5 个 none 是 catalog 无货的专用芯片（LCSC 大概率没有）；13 个 ambiguous 是 LLM triage 全量实测零改善。
- 能力极限 ≈ 89–89.7%（234–236/263），破局只剩数据侧（扩充 catalog）或评分语义重构（大手术）。
用户定调：**"非硬标准，能力极限即可。"**89.7% 不是"没做到 95%"，而是"在现有数据下，这就是机器的诚实上限"。剩下的差距属于数据，不属于引擎——把数据喂进去，上限自己会动。这就是数据飞轮的哲学。
数据飞轮与契约线
数据分三个集合管理：正式集（formal，入库）、Dev 集（材料域演练）、评测集（ground truth 对照）。M1 数据正式入库时，dev 集的 5 个 bundle 因为契约不兼容被判定不可重放——没有硬塞，直接走正式链重导入。数据集的"身份"（哪个集合、什么契约版本生成）比数据本身更重要。
真实数据导入的纪律也定死了：物料主数据 4,121 ACTIVE 走快照重建；审计总量 material 50,224 / catalog 8,208 / BOM ~8,210；数据质量债务（MEXT-F9E722C7、MEXT-DC1D97E1）进 CB 退役队列，不悄悄抹掉。
契约线的推进方式：每条线一个阶段、一个验收——D1（决策命令）、CB1（GUC 审计 + 正式退役）、CB2（Confirmed BOM 契约：publish gate 四眼 + ACCEPT/DNP 映射 + savepoint 幂等）、PE1（工程契约：issue 命令 OPEN/RESOLVE/WAIVE + PCB specification + 文件可用性三态）、M2（契约收敛：candidate-key triple、score 0..1、D3 歧义三态）。commit 带计划线编号（PCBA-D1-COMMAND-01 这种）。
STOP LIST：暂停清单也是计划的一部分
计划里有一条 STOP LIST，现在开始暂停的事写得很具体：
supplier-matching S2 direct DB implementation
Agent SET ROLE pcba_migrator
Agent direct INSERT/UPDATE Core business state
Agent formal Part / ManufacturerPart model
新的数据库 migration
whole-worktree merge
Inventory implementation
Supplier Order / Procurement implementation
formal Quotation
Sales Order
每一条都是"将来要做但现在碰会破坏收敛"的事。暂停不是放弃，是给正确性让路——尤其是 Agent 直接写核心业务状态（Agent SET ROLE / direct INSERT），在主计划落地后是红线。
现在的坐标
主计划落盘于 2026-08-07，C0 收敛 gate + STOP LIST 铁律生效：唯一 canonical 分支、worktree Salvage Matrix、文档权威链修正、Migration 分叉清理、Architecture Authority Matrix、C0 EXIT GATE。
契约线 D1/CB1/CB2/PE1/M2 全部有提交落库，真实 MatchRun 105 条已跑，决策队列在面板里等着 Owner。工程链（PE1 assembly）刚起步。
路还长，但方向不会歪了——因为方向是审计出来的，不是拍脑袋想出来的。