Ingot 实施路线（光学镜片模压首站）

这是唯一需要照着做的文档。ADR-0002…0006 保留设计原因，遇到“为什么这么定”再去翻，日常不需要读。

长期能力阶段见分析能力阶梯。本路线只说明当前实施顺序。

一句话

把光学模压的一次完整周期，从数据进来到能回答"这批和上批有什么不同"，端到端跑通一遍。其余一切排在这条主线之后。

现在缺什么（代码走查结论）

五个核心设计决定

1. 全量数据参与计算，但不参与推理。 能下推到 SQL 的聚合一律下推，扫多少行都行；进入模型关联信息的必须是有界的统计量。判据：需要先把行拉到 C# 再 LINQ 聚合的，就是设计错了。 → AnalysisToolResult 拆成 Data（给模型，硬上限 32 KB）+ Details（给人，全量表/曲线/CSV，走 URL）。

2. 边缘报配方步序（记录），中心做阶段含义（配置）。 边缘上报 recipe_step=4，中心用映射表解释成 anneal。含义会变而记录不会 —— 改阶段划分只需改中心一张表，历史数据可重算。绝不让边缘上报 phase="anneal"。

3. 阶段是配置里的一等公民，特征绑定到阶段。 "整周期平均模温"没有工艺含义，"退火段降温斜率"才有。cycle_features 必须有 phase 维度 —— 这一维漏了，物化表落地后回填代价极高。

4. 推断出来的东西必须被标记（“记录方式”）。 最强理由是循环论证：用曲线形状推断阶段边界、再用该阶段的曲线特征分析质量，等于同一段数据既定边界又算特征。而推断规则在正常数据上最准、在异常数据上最不准 —— 异常数据恰恰是分析对象。

5. 代码只放通用机制，行业知识只放配置。 机制（step→phase 映射、聚合下推、附件链、护栏）通用；内容（阶段名、特征定义、质量特性）配置。可测量指标：新客户上线写了多少行代码，目标趋近于零。

实施清单

阶段 0 — 契约与规范（纯文档，零代码，最先做）

这一步不写任何代码，但决定后面所有事情能否成立。

• RFC 增加 context 保留键，适配器必须填：
  • 阶段归属：recipe_id、recipe_version、recipe_template、recipe_step、recipe_step_name
  • 分组维度：product_code、operation_code、mold_id、mold_shot_count、preform_lot、cavity_id
• 明确 InspectionRecord.operationRunId = 该次加工运行的 correlationId（或给出显式映射）
• 明确阶段事件命名 phase.{code}.started / .completed（复用现有 .started/.completed 配对逻辑）
• 给适配器实现方写一页《必须采什么》：recipe_step 要与过程数据同一次扫描周期读出，step 变化时额外发一条事件

mold_id + mold_shot_count 这一对的价值高于其余所有键之和 —— 它们让"模具寿命"从经验判断变成可计算曲线。

验收：拿着这份 RFC，一个不了解 Ingot 的适配器工程师能独立写出正确的上报。

阶段 1 — 数据能进来

• POST /api/v1/inspection-attachments（multipart）→ 返回 attachmentsId/storageRef/sha256/sizeBytes。sha256 由服务端算
• InspectionDefinition 注册表 + CRUD（特性、单位、上下限、输入类型）
• PhaseDefinition + PhaseMapping 注册表（与上者同一套主数据，不要另起炉灶）
• Platform Web 检测录入页 —— 表单由定义生成，不硬编码
• 一个参考适配器样例（含 recipe_step 采集）

验收：一个质检员能在浏览器里提交一条带照片的检测记录，且该记录能关联到具体的模压周期。

阶段 2 — 计算层（唯一有技术不确定性的部分）

• 先验证：slope / integral / dwell / range_across 能否干净地下推到 TimescaleDB
• cycle_phases 物化：步序变化点切区间 → 连续同 phase 合并 → 带 “记录方式” 和 source_event_id_start/end
• cycle_features 物化：含 phase_code 维度和 sample_count 列
• FeatureDefinition 注册表，含 BoundaryMode（slope/integral 默认 include_leading，min/max/mean 默认 strict）
• 周期封口与迟到事件重算（以 occurred_at 为准，重算幂等）

这四个聚合是整条链上唯一可能推翻架构的地方。做不下来就要重想第 1 条设计决定。其余任务都是"知道怎么做，只是要做"。

验收：给定一个周期，SQL 算出的 anneal.rate_c_per_min 与逐行 Python 参考实现结果一致，且扫全量时执行计划走索引。

阶段 3 — 分析能力

• AnalysisToolResult 拆 Data / Details，Data 字节上限由 AgentGuards 强制
• find_comparable_cycles —— 检索同类周期，并返回"凭什么判定同类"
• compare_cycles —— 分位数/分布/事件序列差异/合格率，带效应量而非只有 p 值
• AgentGuards 扫描预算、周期条数上限、超时降级
• check_data_quality 扩展阶段级检查（必需阶段缺失、顺序错乱、时长异常、unknown 归属、“系统估算” 降级）
• DefaultPlanValidator 的 surface 硬编码多值化（为阶段 4 铺路）

验收：能回答"MOLD-02 最近 200 模的面形 PV 趋势，和 MOLD-01 比怎么样"，答案里每个数字都有附件链接，用户能点开完整曲线。

阶段 4 — 放大（此前不要碰）

• MCP Server —— 工具注册表已是标准形状，工程量极小、杠杆最大
• 常驻监测代理（第二个 功能入口）—— 订阅 SSE，命中走 webhook。从极高阈值起步，每条通知带有用/没用反馈
• 录入后即时反馈（本次结果 vs 上下限 + 最近 20 次趋势与合格率）
• Excel / 拍照的多模态摄取，结果必须标 “录入方式：系统识别”

这个场景的四个目标问题

特征集设计得对不对，用能否回答这四个来检验：

1. 模具寿命漂移 —— 固定 mold_id，面形 PV 随 mold_shot_count 的趋势，预测何时下模修复镀层。这是最贵的单一问题
2. 退火速率一致性 → 内应力不良 —— 按 anneal.rate_deviation 分组对比
3. 上下模温差 → 偏心 —— mold.temp.uniformity_c，按 cavity_id 分层
4. 预制件批次 → 良率 —— 按 preform_lot 分组

四个的分组维度分别是 mold_id、recipe_version、cavity_id、preform_lot —— 都在阶段 0 的保留键里。

纪律

分两类。把所有条目都写成"绝对禁止"是一种偷懒 —— 注定会被打破的规则最后是被整体抛弃，而真正承重的那两条会跟着一起失效。

A. 真正不可违反（2 条）

B. 有明确边界，不是绝对禁止（5 条）

需要你确认的事

1. §阶段 2 的四个聚合：建议先做 SQL 原型验证，再定注册表契约
2. ADR-0005 §4 的特征集：基于通用工程认知给出，实际阶段划分、参数、限值需工艺工程师核定
3. 第二个客户故意换行业（注塑或热处理），第二家光学厂验证不了通用性

这样安排的原因