← Financial Cloud Cloud Cloud Club · 构建文章

极点宏观|Financial Cloud Cloud · 构建文章

与 Kiro 同行:蚀刻工艺窗口风险测试自动化工作坊

系列: Kiro 工作坊

文章: 08

文章
Kiro 工作坊
01 使用 Kiro 构建:他加禄语学习 App 的提示优先产品设计工作坊
Kiro 工作坊
02 使用 Kiro 构建:他加禄语 学习 App 的教育优先开发技巧工作坊
Kiro 工作坊
03 使用 Kiro 构建:他加禄语 学习 App 的深入开发流程工作坊
Kiro 工作坊
04 使用 Kiro 构建:将 他加禄语 学习 App 本地化为中文变体工作坊
Kiro 工作坊
05 使用 Kiro 构建:他加禄语 卡片的语法与发音补强流水线工作坊
Kiro 工作坊
06 使用 Kiro 构建:他加禄语 学习 App 中可审查的独特额外例句工作坊
Kiro 工作坊
07 与 Kiro 同行:晶圆厂工程健康度 Hook 工作坊
Kiro 工作坊
08 与 Kiro 同行:蚀刻工艺窗口风险测试自动化工作坊
Kiro 工作坊
09 与 Kiro 同行:黄光微影漂移风险开发工作坊
Kiro 工作坊
10 工程团队入门 — 日常工厂值班使用 fab spc drift sync portal
Kiro 工作坊
11 工程团队附录 — fab spc drift sync portal 的日常工厂值班使用
Kiro 工作坊
12 Kiro:规格驱动工厂软件的现场工程工作坊
Kiro 工作坊
13 Kiro:实施 Lab — 从零构建具类型的 Factory Risk Portal
Kiro 工作坊
14 Kiro:工程开发人员的提示、代码和类型标准手册
Kiro 工作坊
15 Kiro:为什么强 React 提示可以防止类型宣告错误启动
Kiro 工作坊
17 与 Kiro 一起构建:建立工厂自动化门户 React UI
Kiro 工作坊
18 与 Kiro 一同构建:打造工厂自动化门户背后的自动化分析引擎
Kiro 工作坊
19 与 Kiro 一起实施:将 AI 工厂自动化辅助程序新增至工厂自动化门户
Kiro 工作坊
21 Kiro:2 小时专业开发人员工作坊指南
Kiro 工作坊
22 Kiro:从零建置 Fab SPC Drift Synchronization Portal
Kiro 工作坊
23 Kiro:提示词库与深度代码说明附录
Kiro 工作坊
30 与 Kiro 一起构建:建立工厂自动化门户 UI
Kiro 工作坊
31 与 Kiro 一起构建:打造工厂自动化门户背后的自动化分析引擎
Kiro 工作坊
32 与 Kiro 一起实施:为工厂自动化门户添加 AI 工厂自动化辅助程序
Kiro 工作坊
33 与 Kiro 一起开发:重建 CME Direct 风格的量化损益排行榜 UI
Kiro 工作坊
34 与 Kiro 一起开发:重建损益排行榜背后的量化分析引擎
Kiro 工作坊
35 与 Kiro 一起构建:适用于量化排行榜的 AWS AI 驱动交易台助理
Kiro 工作坊
36 单页交易平台 SOP
Kiro 工作坊
AgentCore
A1 使用 AgentCore 与 Strands 构建:Gateway MCP 工具织网开发者工作坊
AgentCore
A2 使用 AgentCore 与 Strands 构建:受治理的多 Agent 风险系统开发者工作坊
AgentCore
A3 使用 AgentCore 与 Strands 构建:运行时主权风险代理人开发者工作坊
AgentCore
模拟考场
E1 用 Vibe Coding 打造多语言 AWS 认证模拟题上线系统
模拟考场
E2 利用 Vibe Coding 开发技巧打造 AWS 认证模拟练习室
模拟考场
E3 打造静态 AWS 模拟考场背后的练习引擎
模拟考场
Amazon Q
Q1 Amazon Q:面向 ACM 证书自动续订的 CloudShell 优先开发人员工作坊
Amazon Q
Tagalog 练习室
T1 用提示词优先的产品设计,为 AWS Manila Community Day 构建 Tagalog 学习应用
Tagalog 练习室
T2 用教育优先的开发提示,为 AWS Manila Community Day 构建 Tagalog 学习应用
Tagalog 练习室
T3 面向 AWS Manila Community Day 的 Tagalog 学习应用深度开发流程
Tagalog 练习室
T4 为 AWS Manila Community Day 将 Tagalog 学习应用本地化为中文变体
Tagalog 练习室
T5 为 AWS Manila Community Day 的 Tagalog 卡片构建语法与发音增强流水线
Tagalog 练习室
T6 在 AWS Manila Community Day 的 Tagalog 学习应用中,让额外示例唯一且可审查
Tagalog 练习室
路线图
R1 企业级 Data Analytics Roadmap 一百个深度情境题
路线图
R2 前端开发路线图:真实企业场景
路线图
香港 Community Day
C1 与 AWS Community Day 共度香港周末:从云端议程到维港灯火
香港 Community Day
C2 演讲者的奢华周末:讲述你的 AWS 故事,再让香港登场
香港 Community Day
C3 在香港的七十二小时:AWS Community Day 演讲者的深度行程
香港 Community Day
马尼拉 Community Day
C4 AWS Community Day Manila:一场连接云技术、城市文化与真挚友谊的快乐周末
马尼拉 Community Day
C5 AWS Community Day Manila:云端建设者在菲律宾感受最幸福的精神
马尼拉 Community Day
C6 AWS Community Day Manila:在快乐之城构建、打破、重来,并找到归属
马尼拉 Community Day
C7 菲律宾马尼拉初次到访建议
马尼拉 Community Day
菲律宾 × 香港
C8 菲律宾香港资本市场升级
菲律宾 × 香港
回测
B1 使用 Bedrock AgentCore 和 Strands Agents 构建机构级 Amazon 只做多回测代理
只做多 AMZN 代理:AgentCore、Strands 与可审计的 Backtrader 台账。
B2 使用 Backtrader、AgentCore 和 Strands Agents 构建具备市场状态感知能力的 Amazon 头寸管理
把市场状态当成头寸控制,而不是图表注释。
B3 使用 Nasdaq、S&P 500、Dow、AgentCore 与 Strands 构建相对基准的 Amazon 择时系统
相对 Nasdaq、S&P 500 与道琼斯判断 AMZN 时机。
B4 使用 Bedrock AgentCore、Strands Agents 与 Backtrader 构建受治理的 Amazon 交易历史工厂
把回测做成可审计的交易历史工厂。
B5 使用 Bedrock AgentCore 与 Strands Agents 构建代理式 Amazon 回测运营模型 [Part 1]
先建立运营模型,再争论结果。
B6 为 Amazon 择时与头寸管理构建自定义 Cerebro 代码解读 [第 2 部分]
先讲 Cerebro 引擎,再讲图表。
B7 为 Amazon 策略结果与经验教训构建交易员复盘记录 [Part 3]
把策略排名写成交易员复盘记录。
B8 使用 AgentCore 和 Strands 构建受治理的 FSI Amazon 头寸管理手册 [第 4 部分]
受治理的 FSI Amazon 头寸管理手册。
B9 使用 Amazon Bedrock AgentCore 构建主权风险交易代理,分析收益率差、FX 对冲与债务重新定价
主权风险代理:收益率差、外汇对冲与债务重定价。
B11 构建现代波动率交易与合法泰国恢复规划智能体:内存驱动的 Strands 多智能体风险保护系统
记忆驱动的 Strands 智能体:波动率与泰国恢复规划。
B12 使用 Amazon Bedrock AgentCore Memory 构建做空跨式交易风险治理
做空跨式的交易风险治理。
B13 在 Amazon EKS 上构建生产环境就绪的信用与收益质押 AI 智能体
在 EKS 上跑生产级信用与收益质押智能体。
挑战
01 周末生产力挑战:Fab SPC 漂移同步门户
Fab SPC 漂移审查与建议门户。
02 周末生产力挑战:Quant P&L Commander — AWS 上由 AI 驱动的交易生产力门户
AWS 上由 AI 驱动的交易生产力门户。
03 周末烦人任务挑战:交易台在云端、链上、空中执行摘要
DeskPulse 日常交易执行摘要。
04 周末 Agent 挑战:早上 6 点交易风险审查
无人值守、以证据为基础的早间交易风险简报。
05 周末创意挑战:领导力卡牌游戏
浏览器版创意引导卡牌。
06 全栈挑战:社区日留言板应用程序
浏览器版活动通信空间。
领导力卡牌
01 Leadership Card Game: 云没有自动化的最后一项技能:像领导者一样说话
写给 构建者的一篇现场随笔:语言、勇气,以及 Leadership Card Game
02 领导力回合解剖:Leadership Card Game 究竟如何玩
写给 构建者的引导员实地指南:如何把演练嵌进真实会议
03 Leadership Card Game: 当机会不再属于组织者
写给 构建者的田野随笔:权力转移、多语言领导力练习夜,以及走完入口、资源与叙事的职业弧线
04 周末创意挑战:Leadership Card Game
一篇构建者手记:愿景、架构,以及周末创意挑战教会我的事
05 从周末挑战项目到 $1,386 众筹:改变你在职场现身方式的领导力练习
一个周末做出的作品,变成 600 张卡的在线领导力练习室,并筹到 $1,386。
06 从周末挑战项目到 $1,386 众筹:进入科技产业的第一天路径
一个周末挑战如何变成具备 600 张卡、由 AWS 驱动的多语产品,并筹到 $1,386?
07 从周末挑战项目到 $1,386 众筹:用转移机会建立专业品牌
一个周末挑战把领导想法做成能跑的多语产品,并筹到 $1,386。
08 Leadership Card Game — 众筹活动
筹款目标: HKD 5,000 已筹金额: HKD 1,386 距目标还差: HKD 3,614 进度: 28% 创作者: D.C. Dan · L.L. Diana · L.K. Lva 所在地: 日本、香港、新加坡 投资人权益: 即期价值、私密会员卡牌编辑器云(Private Membership Card…
09 PR/FAQ 01 — Leadership Card Game 面向社区构建者正式推出
「逆向工作法」文档 · 对外新闻稿 + FAQ 产品: Leadership Card Game 受众: 社区经理、志愿组织者、早期职业构建者
10 PR/FAQ 02 — 企业引导员采用 Leadership Card Game 开展现场领导力演练
「逆向工作法」文档 · 对外新闻稿 + FAQ 产品: Leadership Card Game 受众: 学习与发展负责人、人员管理者、敏捷教练、企业引导员
10 PR/FAQ 03 — 多语言 Leadership Card Game 为构建者归属开放全球练习室
「逆向工作法」文档 · 对外新闻稿 + FAQ 产品: Leadership Card Game 受众: 全球 构建者、双语社区、跨境产品团队、开源导师
AWS Builder Center
01 AWS Builder Center、社区精神与 AWS Builder Jacket
霓虹信号、共享创意,以及为构建者打造的外套。
02 走进 AWS Builder Center:一座能学习、贡献,也让人有归属感的全球技术平台
一段精彩旅程,不一定从机场开始。
03 AWS Community Builder 的巨大成功
当构建者公开分享,整个社区就会一起前进。
04 AWS Builder Center 的巨大成功
一座为好奇心打造、充满活力的全球街区。
05 周末走进 AWS Builder Center:从社区灵感到令人难忘的 AWS Builder Jacket
星期五晚上,开始于构建者熟悉的感觉:有一个点子,正卡在问题与可能性之间。

时长: 2 小时

目标受众: 负责构建半导体工艺控制服务与测试自动化的专业开发人员

主要 AWS AI 服务: Kiro

工作坊重点: 利用 Kiro 辅助测试设计、边缘情况生成,以及针对蚀刻工艺窗口风险代码的审查

独立成果: 开发人员将建立一个测试先行(Test-first)的工作流程,并使用 Kiro 来验证蚀刻腔体(chamber)风险映射、工艺窗口漂移事件、自动化控制滑移,以及确保既有晶圆厂事件的不退化(non-regression)。

仅限教育工程研讨会。这是一项软件架构练习,而非流程发布建议。


摘要

本工作坊将引导开发人员完成由 Kiro 辅助的蚀刻工艺窗口风险映射测试自动化。参与者将建立测试先行计划、实施 TypeScript 映射器(mapper)、强化生成出的薄弱测试,并涵盖遗漏字段、时间线语义、多因子数组与不退化行为,同时完整保留原始遥测数据。其余实验室将处理边界值审查与调试指引,在不增加生产环境持久化学习练习的计算或宽泛重构的前提下,安全地进行实施。


1. 工作坊目标

本工作坊提供了聚焦于 Kiro 辅助测试的实施开发实验室。开发人员不会建立一个完整的应用程序,而是使用 Kiro 来扩展围绕蚀刻工艺窗口风险映射器的测试。实验室将教导如何向 Kiro 要求有意义的测试、识别有缺陷的薄弱测试、提升覆盖率并保护事件语义。

此场景聚焦于电浆蚀刻腔体(plasma etch chamber),其中的压力、射频(RF)功率变异、终点信号稳定度(endpoint signal stability)、气体流量与腔体温度等可能会接近工艺控制边界。代码示例会将原始来源数值直接进行持久化(persistence),以便后续供工艺工程分析使用。


2. 学习目标

开发人员将学习如何:

● 在实施前使用 Kiro 生成测试计划。

● 为蚀刻工艺窗口风险事件建立 TypeScript 映射器。

● 为正常路径案例(positive cases)、异常路径案例(negative cases)、遗漏字段、时间线字段与多因子数组生成测试。

● 要求 Kiro 对薄弱的测试进行批判与评估。

● 为专业开发人员加入不依赖表格且具备高可读性的测试案例。

● 使用审查提示词使测试与制造风险保持一致。


3. 实验室议程

时间 实验室 开发人员产出
0:00-0:10 实验室 1:测试先行规格 来自 Kiro 的测试计划
0:10-0:25 实验室 2:蚀刻映射器 etchRiskMapper.ts
0:25-0:45 实验室 3:核心测试 正常与异常路径测试
0:45-1:05 实验室 4:弱测试审查 Kiro 审查输出结果
1:05-1:25 实验室 5:边缘情况测试 遗漏字段与空因子测试
1:25-1:40 实验室 6:时间线测试 事件、计算与因子时间
1:40-1:52 实验室 7:不退化测试 既有晶圆厂事件行为
1:52-2:00 实验室 8:最终覆盖率审查 通过/失败(PASS/FAIL)覆盖率报告

4. 实验室 1 — Kiro 测试先行提示词

提示词规则 1

提示词目标: 在实施之前要求 Kiro 提供测试覆盖范围。

提示词示例

建立一個用於蝕刻製程視窗風險映射器的測試計劃。該映射器應僅針對 ETCH_PROCESS_WINDOW_RISK 事件回傳紀錄集,並對無關的晶圓廠事件回傳 null。

AI 生成结果: Kiro 可能会生成一个简单的正常路径(happy-path)测试以及一个无关的事件测试。

说明: 这是一个合理的开始,但对于半导体工艺风险功能来说还不够。

为何结果不够好: 它可能会遗漏多因子数组处理、选填字段行为、时间语义以及原始遥测数值的保留。

提示词规则 2

为何规则 2 可以修复上述问题: 这将测试计划扩展到了包含工艺工程风险。

提示词示例

擴充測試計劃。包含兩個 risk_factors、遺漏 risk_factors、遺漏選填欄位、獨立彼此獨立的 event_time 與 risk_compute_time、獨立獨立的 factor_time,以及對 EQUIPMENT_ALARM 和 AUTOMATION_CONTROL_COMMAND 的拒絕。

AI 生成结果: Kiro 应该会产生一个更强大的测试计划,并包含覆盖率分类。

说明: 测试计划现在反映了真实事件流(event-stream)的边缘情况。

系统设计决策

● 测试先行(Test-first)开发可协助开发人员在接受自动生成的实施之前先定义行为。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时(save-time)、测试时(test-time)及审查时(review-time)的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式(operational failure mode)连结,避免增加不必要的平台复杂度。

● 晶圆厂事件通常是不完整或部分填写的,因此需要针对选填字段(optional-field)进行测试。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据(source evidence)与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性(traceability)、可重复性(reproducibility)及生产环境不退化(production non-regression)负责。这样一来,系统将更容易被审计,且演进时更具安全性。

● 必须对时间语义进行测试,因为事件顺序对于事件根因分析(incident analysis)至关重要。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务(engineering practice)。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构(refactors)或隐含的假设之中。


5. 实验室 2 — 生成蚀刻风险映射器

提示词示例

建立 src/etchRiskMapper.ts。除非 event_type 為 ETCH_PROCESS_WINDOW_RISK,否則回傳 null。對於符合資格的事件,每個 risk_factors 陣列項目各回傳一個 riskSummary 與一個 riskFactor。直接儲存原始來源數值或 null。請勿計算或轉換數值。

预期代码

export type EtchRiskRecordSet = {
  riskSummary: Record<string, string | null>;
  riskFactors: Record<string, string | null>[];
};

export function mapEtchRiskEvent(message: any): EtchRiskRecordSet | null {
  if (message?.event_type !== "ETCH_PROCESS_WINDOW_RISK") {
    return null;
  }

  const riskSummary = {
    risk_event_id: message.risk_event_id || null,
    fab_id: message.fab_id || null,
    tool_id: message.tool_id || null,
    chamber_id: message.chamber_id || null,
    wafer_lot_id: message.wafer_lot_id || null,
    recipe_version: message.recipe_version || null,
    process_step: message.process_step || null,
    process_window_risk_level: message.process_window_risk_level || null,
    etch_uniformity_risk: message.etch_uniformity_risk || null,
    drift_velocity: message.drift_velocity || null,
    yield_exposure_level: message.yield_exposure_level || null,
    automation_control_slip_probability: message.automation_control_slip_probability || null,
    event_time: message.event_time || null,
    risk_compute_time: message.risk_compute_time || null
  };

  const riskFactors = (message?.risk_factors || []).map((factor: any) => ({
    factor_id: factor.factor_id || null,
    risk_event_id: message.risk_event_id || null,
    sensor_name: factor.sensor_name || null,
    sensor_value: factor.sensor_value || null,
    control_boundary: factor.control_boundary || null,
    unit: factor.unit || null,
    risk_contribution: factor.risk_contribution || null,
    factor_time: factor.factor_time || null
  }));

  return { riskSummary, riskFactors };
}

业务逻辑说明: 映射器捕获蚀刻工艺窗口风险证据,以供后续工艺工程分析使用。

代码逻辑说明: 它使用精确的事件匹配、建立摘要、映射所有风险因子,并完整保留来源原始值。

预期结果: 符合资格的事件将返回记录集;无关的事件则返回 null。

系统设计决策

● 精确的事件匹配可规避处理无关的晶圆厂事件。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。

● 原始字符串存储使遥测数据得以与串流消息进行匹配。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。

● 仅限映射器(mapper-only)的实验室将测试与数据库考虑相互隔离。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。


6. 实验室 3 — 核心测试

提示词示例

為 mapEtchRiskEvent 生成 Vitest 測試。包含一個具有兩個 risk_factors 的合規事件,以及一個無關的設備警報。

预期测试代码

import { describe, expect, it } from "vitest";
import { mapEtchRiskEvent } from "../src/etchRiskMapper.js";

describe("mapEtchRiskEvent 核心行為", () => {
  it("映射具有兩個因子的蝕刻製程視窗風險事件", () => {
    const result = mapEtchRiskEvent({
      event_type: "ETCH_PROCESS_WINDOW_RISK",
      risk_event_id: "etch_risk_evt_001",
      fab_id: "FAB-HK-ADV-01",
      tool_id: "ETCH-CHAMBER-12",
      chamber_id: "CHAMBER-B",
      wafer_lot_id: "LOT-HPC-55210",
      recipe_version: "ETCH-7NM-R19",
      process_step: "PLASMA_ETCH",
      process_window_risk_level: "HIGH",
      etch_uniformity_risk: "ELEVATED",
      drift_velocity: "0.041",
      yield_exposure_level: "ELEVATED",
      automation_control_slip_probability: "0.67",
      event_time: "2026-06-26T10:20:00+08:00",
      risk_compute_time: "2026-06-26T10:20:02+08:00",
      risk_factors: [
        {
          factor_id: "etch_factor_pressure_001",
          sensor_name: "chamber_pressure",
          sensor_value: "14.8",
          control_boundary: "15.0",
          unit: "mTorr",
          risk_contribution: "HIGH",
          factor_time: "2026-06-26T10:19:58+08:00"
        },
        {
          factor_id: "etch_factor_rf_002",
          sensor_name: "rf_power_variation",
          sensor_value: "2.7",
          control_boundary: "3.0",
          unit: "percent",
          risk_contribution: "MEDIUM",
          factor_time: "2026-06-26T10:19:59+08:00"
        }
      ]
    });

    expect(result?.riskSummary.risk_event_id).toBe("etch_risk_evt_001");
    expect(result?.riskFactors).toHaveLength(2);
    expect(result?.riskFactors[0].risk_event_id).toBe("etch_risk_evt_001");
  });

  it("對設備警報事件回傳 null", () => {
    expect(mapEtchRiskEvent({ event_type: "EQUIPMENT_ALARM" })).toBeNull();
  });
});

业务逻辑说明: 这些测试涵盖了主要的正常路径,以及对无关事件的拒绝。

代码逻辑说明: 测试会直接调用映射器并查看返回的记录集。

预期结果: 测试通过。

系统设计决策

● 包含双因子的正常路径测试可验证数组处理。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。

● 警报异常路径测试保护了无关运营事件的语义。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及运营不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。

● 直接测试映射器具有快速且具备确定性(deterministic)的特点。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。


7. 实验室 4 — 弱测试审查

开发人员任务

要求 Kiro 审查一个薄弱的测试。

薄弱的测试

it("works", () => {
  const result = mapEtchRiskEvent({ event_type: "ETCH_PROCESS_WINDOW_RISK" });
  expect(result).toBeTruthy();
 });

提示词示例

審查這個用於蝕刻製程視窗風險映射器的測試。解釋它為何過於薄弱,並建議更好的斷言。

预期 Kiro 结果

此測試過於薄弱,因為它僅檢查結果是否存在,並未驗證摘要欄位、因子紀錄、父子關聯性、選填欄位行為或時間線語意。
更好的斷言應該要檢查 risk_event_id、因子數量、因子的 risk_event_id 關聯、event_time、risk_compute_time 以及選填欄位的 null 處理。

业务逻辑说明: 单纯的 truthy 断言无法证明工艺风险数据对于调查具有实质价值。

代码逻辑说明: 该测试未能确实检查映射的输出内容。

预期结果: 开发人员将薄弱的断言替换为字段级别的检查。

系统设计决策

● 测试质量比测试数量更重要。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。

● 字段级别的断言保护了持久化契约(persistence contract)。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。

● Kiro 审查能引导开发人员去改善自动生成的测试。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。


8. 实验室 5 — 遗漏字段与空因子测试

提示词示例

為遺漏選填欄位與遺漏 risk_factors 的情況新增測試。映射器應回傳一個包含 null 選填欄位且零個因子的摘要。

预期测试

it("當缺少選填的蝕刻摘要欄位時儲存 null", () => {
  const result = mapEtchRiskEvent({
    event_type: "ETCH_PROCESS_WINDOW_RISK",
    risk_event_id: "etch_missing_fields",
    risk_factors: []
  });

  expect(result?.riskSummary.fab_id).toBeNull();
  expect(result?.riskSummary.tool_id).toBeNull();
  expect(result?.riskSummary.chamber_id).toBeNull();
  expect(result?.riskFactors).toHaveLength(0);
});

it("將遺漏的 risk_factors 視為零個因子處理", () => {
  const result = mapEtchRiskEvent({
    event_type: "ETCH_PROCESS_WINDOW_RISK",
    risk_event_id: "etch_no_factors"
  });

  expect(result?.riskSummary.risk_event_id).toBe("etch_no_factors");
  expect(result?.riskFactors).toHaveLength(0);
});

业务逻辑说明: 实时制造事件(real-time manufacturing events)可能是不完整的,但符合资格的风险事件仍应具备可追溯性。

代码逻辑说明: 选填字段使用 null 作为备用值(fallback),而遗漏的数组则使用空数组作为备用值。

预期结果: 无须变更映射器代码即可通过测试。

系统设计决策

● 选填字段测试可防止意外引入过于严格的验证(strict validation)。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。

● 遗漏数组的测试保障了运行时的稳定度(runtime stability)。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。

● 存储 null 可使遗漏的原始数据保持显性(explicit)。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。


9. 实验室 6 — 时间线测试

提示词示例

新增一個測試以證明 event_time、risk_compute_time 與 factor_time 保持彼此獨立。請勿合併或重命名時間欄位。

预期测试

it("保持蝕刻風險時間線欄位彼此獨立", () => {
  const result = mapEtchRiskEvent({
    event_type: "ETCH_PROCESS_WINDOW_RISK",
    risk_event_id: "etch_timeline_001",
    event_time: "2026-06-26T10:20:00+08:00",
    risk_compute_time: "2026-06-26T10:20:02+08:00",
    risk_factors: [
      {
        factor_id: "factor_time_001",
        factor_time: "2026-06-26T10:19:58+08:00"
      }
    ]
  });

  expect(result?.riskSummary.event_time).toBe("2026-06-26T10:20:00+08:00");
  expect(result?.riskSummary.risk_compute_time).toBe("2026-06-26T10:20:02+08:00");
  expect(result?.riskFactors[0].factor_time).toBe("2026-06-26T10:19:58+08:00");
});

业务逻辑说明: 时间分离是必要的,这用以厘清传感器风险是在串流计算(stream computation)之前还是自动化响应(automation response)之前出现。

代码逻辑说明: 映射器分别独立保留每个时间字段。

预期结果: 测试通过。

系统设计决策

● 时间线精准度对于根因分析至关重要。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。

● 独立的时间字段可暴露串流处理延迟(stream-processing delay)。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。

● 测试可防止未来的重构将相异的时间概念合并(collapsing)。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。


10. 实验室 7 — 既有既有晶圆厂逻辑不退化

开发人员任务

建立一个小型的处理程序(handler)来调用映射器,并将无关事件委派给既有逻辑。

预期代码

import { mapEtchRiskEvent } from "./etchRiskMapper.js";

export async function runExistingFactoryLogic(message: any): Promise<string> {
  if (message?.event_type === "EQUIPMENT_ALARM") {
    return "equipment-alarm-processed";
  }

  if (message?.event_type === "AUTOMATION_CONTROL_COMMAND") {
    return "automation-command-processed";
  }

  return "ignored-by-existing-factory-logic";
}

export async function handleEtchRiskMessage(rawMessage: string): Promise<string> {
  const message = JSON.parse(rawMessage);
  const records = mapEtchRiskEvent(message);

  if (records) {
    return "etch-process-window-risk-mapped";
  }

  return runExistingFactoryLogic(message);
}

业务逻辑说明: 此处理程序在加入蚀刻风险映射的同时,保护了既有的事件行为。

代码逻辑说明: 映射器负责判定资格。不符资格的消息将会流向既有逻辑。

预期结果: 设备警报与自动化控制命令将保留其原本的响应行为。

不退化测试

it("保持自動化控制命令的行為不變", async () => {
  const result = await handleEtchRiskMessage(JSON.stringify({
    event_type: "AUTOMATION_CONTROL_COMMAND"
  }));

  expect(result).toBe("automation-command-processed");
});

系统设计决策

● 不退化测试保护了生产环境的事件路由(event routing)。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。

● 映射资格判定不应改变警报或控制命令的处理逻辑。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。

● 小型的处理程序可在不增加数据库复杂度的情况下展示整合。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。


11. 实验室 8 — 最终 Kiro 覆盖率审查

提示词示例

審查蝕刻製程視窗風險映射器、處理常式與測試。回傳 PASS 或 FAIL。檢查正常路徑事件、無關事件、遺漏欄位、遺漏 risk_factors、時間線欄位以及不退化行為。僅提供最小化修補建議。

预期 Kiro 结果

PASS
- 包含兩個因子的正常路徑事件已通過測試。
- 設備警報與自動化控制命令之行為已受到保護。
- 遺漏選填欄位與遺漏 risk_factors 的情況已通過測試。
- 時間線欄位保持彼此獨立。
- 無任何來源數值被轉換或計算。

12. 完成情况检核表

● 测试先行计划已建立。

● 蚀刻风险映射器已生成。

● 核心测试已加入。

● 弱测试审查已完成。

● 选填字段测试已加入。

● 时间线测试已加入。

● 既有既有晶圆厂逻辑不退化测试已加入。

● 最终 Kiro 覆盖率审查已完成。


13. 实验室 9 — 蚀刻传感器边界值审查

提示词示例

為接近製程控制邊界的蝕刻感測器數值建立一份附加的測試審查檢核表。請勿計算新的風險值。僅檢查來源數值與控制邊界是否仍儲存為字串。

预期 Kiro 结果

附加檢核表:
- chamber_pressure 來源數值已直接儲存。
- rf_power_variation 來源數值已直接儲存。
- control_boundary 已直接儲存。
- unit 已被保留。
- risk_contribution 已自來源事件直接儲存。
- 無任何數值被轉換為數字類型(Number)。
- 未建立任何派生的邊界距離欄位(derived distance-to-boundary field)。

业务逻辑说明: 蚀刻腔体传感器可能接近极限值,但持久化层不应重新诠释或重新计算这些数值。

代码逻辑说明: 映射器将传感器数值与边界存储为原始来源字符串。任何计算都应在独立的分析层中实施。

预期结果: Kiro 将类型转换或计算视为一项审查关切点(review concern)。

系统设计决策

● 边界分析(Boundary analysis)固然重要,但持久化与分析层应保持分离。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。

● 保留原始来源数值可让工艺工程师将存储的记录与串流事件进行对比。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。

● 避免使用派生字段(derived fields)可保持映射器的简洁度与可审查性。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。


14. 实验室 10 — 生成开发人员调试指引

提示词示例

為失敗的蝕刻風險映射器測試建立一份簡短的開發人員除錯指引。包含事件資格錯誤、遺漏因子關聯、合併時間欄位以及意外數值轉換等失效情境。

预期 Kiro 结果

除錯指引:
1. 若無關事件意外回傳紀錄集,請檢查 event_type 是否精確比對。
2. 若因子關聯(factor linkage)失敗,請檢查每個因子是否都使用了父層的 risk_event_id。
3. 若時間線測試失敗,請檢查 event_time、risk_compute_time 與 factor_time 的欄位名稱。
4. 若數值測試失敗,請移除 Number 類型轉換或正規化輔助函式(normalization helpers)。
5. 若遺漏 risk_factors 導致當機或崩潰,請改用 message?.risk_factors || []。

业务逻辑说明: 当自动生成的代码未能通过深具意义的工厂风险测试时,开发人员需要快速的疑难排解步骤。

代码逻辑说明: 每个调试步骤皆将特定的测试失败映射到最有可能的代码问题上。

预期结果: 开发人员无须进行宽泛重构即可修复映射器。


进阶开发人员额外实施实验室

这些额外实验室延伸蚀刻工艺窗口风险测试自动化工作坊,并避免重复前面的映射器、核心测试、弱测试批判、选填字段测试、时间线测试、不退化处理程序、边界审查与调试指引。新的重点是进阶开发人员使用的突变式测试审查、测试文件夹具设计、契约快照、解析器强化与 CI 质量报告。

15. 实验室 11 — 测试强度的突变式审查

开发人员任务

要求 Kiro 提出刻意的一行代码突变,并指出哪些测试应该失败。不要永久套用这些突变。

提示词示例

針對蝕刻製程視窗風險映射器測試提出突變式檢查。包含事件資格、因子父層連結、遺漏 risk_factors 處理、時間線欄位映射與意外 Number 轉換等突變。針對每個突變,指出應該失敗的測試名稱。

预期 Kiro 结果

# 突變式測試審查

## 突變 1 — 放寬事件資格比對
變更:
`message?.event_type !== "ETCH_PROCESS_WINDOW_RISK"`
改為:
`!message?.event_type?.includes("RISK")`

預期失敗的測試:
- 對設備警報或無關晶圓廠事件回傳 null

## 突變 2 — 破壞父層連結
變更:
`risk_event_id: message.risk_event_id || null`
改為:
`risk_event_id: factor.risk_event_id || null`

預期失敗的測試:
- 映射具有兩個因子的蝕刻製程視窗風險事件

## 突變 3 — 移除遺漏陣列的備用值
變更:
`message?.risk_factors || []`
改為:
`message.risk_factors`

預期失敗的測試:
- 將遺漏的 risk_factors 視為零個因子處理

## 突變 4 — 合併時間線欄位
變更:
`risk_compute_time: message.risk_compute_time || null`
改為:
`risk_compute_time: message.event_time || null`

預期失敗的測試:
- 保持蝕刻風險時間線欄位彼此獨立

## 突變 5 — 轉換來源值
變更:
`sensor_value: factor.sensor_value || null`
改為:
`sensor_value: Number(factor.sensor_value || 0)`

預期失敗的測試:
- 將蝕刻感測器來源值保留為字串

业务逻辑说明: 突变式审查能证明测试会检测危险变更,而不只是通过目前实施。 代码逻辑说明: 每个突变都对应到既有或新需要的断言。 预期结果: 开发人员能在生产代码变更之前找出测试软件包弱点。

系统设计决策

● 突变式审查可验证测试意图,而不需要在工作坊中引入突变测试框架。

● 每个突变都代表具备运营意义的失效模式。

● 实验室让变更保持暂时性,因此生产映射器仍然简单且可追溯。

16. 实验室 12 — 可重用的蚀刻事件测试数据建立器

开发人员任务

建立测试数据建立器,以减少复制贴上,同时让来源值保持明确。

提示词示例

為 ETCH_PROCESS_WINDOW_RISK 事件建立 Vitest 夾具輔助函式。它應回傳一個包含兩個 risk_factors 的完整事件,並允許覆寫摘要欄位與 risk_factors。不要用隨機資料隱藏重要來源值。

预期夹具辅助函数

export function buildEtchRiskEvent(overrides: Record<string, any> = {}) {
  return {
    event_type: "ETCH_PROCESS_WINDOW_RISK",
    risk_event_id: "etch_fixture_evt_001",
    fab_id: "FAB-HK-ADV-01",
    tool_id: "ETCH-CHAMBER-12",
    chamber_id: "CHAMBER-B",
    wafer_lot_id: "LOT-HPC-55210",
    recipe_version: "ETCH-7NM-R19",
    process_step: "PLASMA_ETCH",
    process_window_risk_level: "HIGH",
    etch_uniformity_risk: "ELEVATED",
    drift_velocity: "0.041",
    yield_exposure_level: "ELEVATED",
    automation_control_slip_probability: "0.67",
    event_time: "2026-06-26T10:20:00+08:00",
    risk_compute_time: "2026-06-26T10:20:02+08:00",
    risk_factors: [
      {
        factor_id: "etch_fixture_pressure_001",
        sensor_name: "chamber_pressure",
        sensor_value: "14.8",
        control_boundary: "15.0",
        unit: "mTorr",
        risk_contribution: "HIGH",
        factor_time: "2026-06-26T10:19:58+08:00"
      },
      {
        factor_id: "etch_fixture_rf_002",
        sensor_name: "rf_power_variation",
        sensor_value: "2.7",
        control_boundary: "3.0",
        unit: "percent",
        risk_contribution: "MEDIUM",
        factor_time: "2026-06-26T10:19:59+08:00"
      }
    ],
    ...overrides
  };
}

业务逻辑说明: 夹具建立器可降低测试维护成本,同时保留真实的蚀刻工艺背景。 代码逻辑说明: 辅助函数使用确定性值与明确覆写,而非生成式测试数据。 预期结果: 进阶测试变得更短,但不会失去来源字段可见性。

系统设计决策

● 确定性夹具可避免 flaky test,并让失败更容易审查。

● 明确来源值可让工艺工程背景保留在测试中。

● 浅层覆写已足以支持此映射器,因为巢状因子变更应在个别测试中保持清楚。

17. 实验室 13 — 不存储完整负载的契约快照

开发人员任务

建立输出字段名称的契约式断言。目标是在不快照或存储完整输入负载的情况下验证映射器输出形状。

提示词示例

為 mapEtchRiskEvent 生成合約測試,驗證 riskSummary 欄位名稱與 riskFactor 欄位名稱。不要快照完整來源事件,也不要儲存原始 payload。

预期测试

it("exposes the expected etch risk persistence contract", () => {
  const result = mapEtchRiskEvent({
    event_type: "ETCH_PROCESS_WINDOW_RISK",
    risk_event_id: "etch_contract_001",
    risk_factors: [{ factor_id: "factor_contract_001" }]
  });

  expect(Object.keys(result?.riskSummary || {}).sort()).toEqual([
    "automation_control_slip_probability",
    "chamber_id",
    "drift_velocity",
    "etch_uniformity_risk",
    "event_time",
    "fab_id",
    "process_step",
    "process_window_risk_level",
    "recipe_version",
    "risk_compute_time",
    "risk_event_id",
    "tool_id",
    "wafer_lot_id",
    "yield_exposure_level"
  ].sort());

  expect(Object.keys(result?.riskFactors[0] || {}).sort()).toEqual([
    "control_boundary",
    "factor_id",
    "factor_time",
    "risk_contribution",
    "risk_event_id",
    "sensor_name",
    "sensor_value",
    "unit"
  ].sort());
});

业务逻辑说明: 契约测试可保护下游持久化期待,而不鼓励存储原始负载。 代码逻辑说明: 测试只断言输出键,来源值则交由字段层级测试验证。 预期结果: 字段新增、移除或重新命名会在测试审查中变得可见。

系统设计决策

● 当下游存储需要稳定形状时,契约测试很有价值。

● 快照完整事件会与持久化教学目标冲突,并让审查变得吵杂。

● 字段名称断言补充值层级测试,而不是取代它们。

18. 实验室 14 — 格式错误 JSON 处理程序测试

开发人员任务

为格式错误的 JSON 输入新增小型处理程序层级测试。保持映射器不变。

提示词示例

為蝕刻風險訊息處理常式新增格式錯誤 JSON 的處理常式層級測試。處理常式應回傳受控的解析錯誤結果或拋出已文件化錯誤。不要修改映射器,也不要在欄位映射中加入寬泛錯誤處理。

预期 Kiro 结果

export async function handleEtchRiskMessage(rawMessage: string): Promise<string> {
  let message: any;
  try {
    message = JSON.parse(rawMessage);
  } catch {
    return "invalid-json-message";
  }

  const records = mapEtchRiskEvent(message);
  if (records) {
    return "etch-process-window-risk-mapped";
  }
  return runExistingFactoryLogic(message);
}
it("returns a controlled result for malformed JSON", async () => {
  await expect(handleEtchRiskMessage("{not-valid-json")).resolves.toBe("invalid-json-message");
});

业务逻辑说明: 事件串流消费者应能可预测地处理格式错误的传输数据,同时让有效事件映射规则保持简单。 代码逻辑说明: JSON 解析属于处理程序边界,而不是纯映射器内部。 预期结果: 无效传输输入会与工艺风险映射分开处理。

系统设计决策

● 解析器强化属于系统边界。

● 映射器应专注于合格事件映射与直接来源字段保留。

● 文件化错误结果可协助操作人员区分格式错误输入与无关晶圆厂事件。

19. 实验室 15 — CI 覆盖率 Gate 报告提示词

开发人员任务

要求 Kiro 将测试期待转换为 CI 可读的审查摘要。

提示词示例

為蝕刻製程視窗風險測試建立 CI 覆蓋率 Gate 報告範本。包含映射器合約、正向事件、負向晶圓廠事件、遺漏欄位、時間線欄位、格式錯誤 JSON 處理常式行為與值保留檢查。報告應精簡並使用 PASS/FAIL/N/A。

预期 Kiro 结果

# 蝕刻風險 CI 覆蓋率 Gate 報告

## 映射器合約
- 輸出欄位合約:PASS/FAIL/N/A
- 精確事件資格比對:PASS/FAIL/N/A

## 事件行為
- 符合資格的 ETCH_PROCESS_WINDOW_RISK 會映射一筆摘要:PASS/FAIL/N/A
- 多個 risk_factors 會映射多筆因子紀錄:PASS/FAIL/N/A
- EQUIPMENT_ALARM 回傳 null 或維持原委派行為:PASS/FAIL/N/A
- AUTOMATION_CONTROL_COMMAND 維持原委派行為:PASS/FAIL/N/A

## 邊緣情況
- 遺漏的選填摘要欄位會儲存為 null:PASS/FAIL/N/A
- 遺漏 risk_factors 會回傳零個因子:PASS/FAIL/N/A
- 格式錯誤 JSON 會在邊界處理:PASS/FAIL/N/A

## 語意
- event_time 與 risk_compute_time 保持分開:PASS/FAIL/N/A
- factor_time 保持在因子層級:PASS/FAIL/N/A
- 感測器值與控制邊界保持為字串:PASS/FAIL/N/A

## 決策
- 整體 Gate:PASS/FAIL
- 若為 FAIL,阻擋原因:

业务逻辑说明: CI 报告让测试覆盖率期待对审查者可见,而不要求他们手动检查每个测试档。 代码逻辑说明: 报告摘要测试结果,不引入新的映射器行为。 预期结果: Pull Request 能清楚传达蚀刻风险测试是否已准备就绪。

系统设计决策

● CI 摘要可提升进阶测试软件包的审查效率。

● PASS/FAIL/N/A 能避免自动化审查输出中的模糊叙述。

● 覆盖率 Gate 应回报证据,而人类审查者仍负责评估设计判断。

20. 进阶实验室完成情况检核表

● 突变式审查已完成并识别弱断言。

● 可重用的确定性夹具建立器已建立。

● 契约字段名称测试已加入,且未快照原始负载。

● 格式错误 JSON 行为已在处理程序边界测试。

● CI 覆盖率 Gate 报告范本已建立。