用途
Hardware TDD 用于在嵌入式固件开发中规划测试，尤其针对 Arduino、ESP32、ESP32-S3、Pico 或 Pico W 等平台。它的核心主张是：在宣称某个功能完成之前，先构建完整的“测试阶梯”。纯行为通常可以在主机（off-target）上测试；而电压、引脚复用、负载下的时序以及物理装配仍然需要目标板（target）证据。
主要能力
该技能提供了一套从需求到证据的测试规划方法，包括：
- Intake（信息收集）：记录确切的板卡/版本、框架/工具链、硬件不变量、安全抑制项、模拟器模型、可用仪器、测试夹具以及用户要求的证明阶段。
- Process（流程）：将需求转化为可观测行为和安全不变量；为主机测试编写纯 C/C++ 逻辑测试，使用 fake 替代时间、串口、传感器和执行器，保持硬件适配层轻薄；仅在模拟器模型确实能表示外设和时序时使用 Wokwi 或其他模拟器，并记录模型局限；使用选定工具链进行精确板卡编译和静态检查；创建单次变更的目标板检查清单，包括断电连续性、受控上电、输入观察、输出抑制、复位/恢复和日志；要求物理门禁提供测量、照片或串口输出，不得从主机测试或编译日志推断目标板成功；将失败记录为证据，并保持下一个测试有界。
- Test matrix（测试矩阵）：分层说明每层测试能证明什么、不能证明什么。主机层（如去抖/状态/数据包解析）证明确定性逻辑，不证明引脚电压或接线；模拟层（如建模的传感器/LED/UART）证明建模的交互，不证明稳压器、克隆板、EMI、热行为；构建层（如精确 FQBN/环境）证明源码和依赖可编译，不证明上传或行为；目标层（如串口、万用表、示波器、照片）证明观察到的硬件行为，不证明现场可靠性（除非加载）；系统层（如集成负载/故障案例）证明场景下的需求，不证明未来部署安全。
- Anti-rationalization（反合理化）：针对常见捷径给出回应。例如“单元测试通过了”应保持所有物理和系统阶段开放；“Wokwi 与板卡匹配”应列出模型省略的内容并在硬件上验证；“草图编译通过”应要求上传身份和目标观察分开；“照片证明它能工作”应要求板卡身份、测量上下文和观察结果；“标记完成以后再测试”应保持循环项阻塞或待审查，直到有证据。
- Verification（验证）：每个需求映射到测试、证明阶段和产物路径；主机/模拟/构建/目标/系统结果分别标注；仅物理步骤发出 embedded-project-loop 中的具体 Physical gate 格式；失败和未验证用例在报告中保持可见。
使用方式
该技能以技能包形式提供，具体安装命令和调用方式暂未提供。其共享输出契约要求：陈述假设、所需工具和版本、实现步骤、按证明阶段划分的测试/证据、已知限制以及恢复/安全说明。
适用场景
适用于嵌入式固件开发中的测试规划，特别是需要在主机、模拟器、构建、目标板和系统等多个层面组织测试证据的项目。适合需要明确区分“逻辑正确”与“硬件正确”的团队，以及需要为物理验证设置门禁的流程。
限制
该技能本身不提供具体硬件、模拟器或工具链的安装与配置细节；模拟器（如 Wokwi）的模型局限需要用户自行记录和验证；物理门禁需要实际仪器、照片或串口输出，无法仅靠软件测试替代。具体支持的板卡型号、框架版本和工具链兼容性暂未提供。