midea-ai/semaplc/plc-spec-review

需求 → 逻辑契约自检（写出前必做）

本 skill 的核心清单已内联到 plc-build-and-verify 的"写 plan 前自查"——常规任务跟着那 5 行走即可,不必单独激活本 skill。复杂需求(多互斥条件/长状态机/多优先级抢占)仍建议完整走一遍下面的清单。

编译通过 ≠ 逻辑正确。matiec/rusty 能把逻辑错误愉快编译过去。本 skill 在你写出最终 FUNCTION_BLOCK 之前，强制你把代码逐条对回需求，拦下最高频的逻辑缺陷。

输入

• 任务的自然语言需求（instruction / 用户描述）
• 你刚实现的 ST FUNCTION_BLOCK 草稿

重要边界

• 本指南面向交互式 app(`PROGRAM` + `AT %…` located 变量);Agents4PLC benchmark 的"裸 FUNCTION_BLOCK + VAR_INPUT/VAR_OUTPUT"口径见 benchmark 各自工作区,勿混用。
• 只针对你自己对需求的理解做复核，用的是通用工程纪律。
• 不要去找、读、或猜测任何隐藏的"待验证性质 / properties / 测试断言"——基准测试场景下那是作弊。你只对照需求散文本身。

自检清单（逐条核对，每条给出"通过 / 已修订"）

1. 提取契约

从需求列出，写成一个短清单：

• 全部输入变量
• 全部输出变量
• 需求点名的每个分支 / 模式 / 路线 / 状态
• 每个数值阈值 / 区间

2. 覆盖性（拦"实现不完整"）

• 第 1 步列的每个输入都在逻辑里被用到了吗？声明了却没用 = 漏实现。
• 每个被点名的分支 / 路线 / 状态都实现了吗？（如需求列了 Route 1/2/3，三个都要有对应逻辑）
• 每个声明的 `%Q*` located 输出，逻辑体里都有给它赋值的驱动来源吗？（"每个输入都被用到"的对偶）这包括你自己新增的执行器输出——传送带 conveyor_run、电机 motor_on 之类常被声明出来却没人置位它（程序体内从无 conveyor_run := …）。声明了却没有任何赋值 = 死输出：编译能过、运行恒为初值、行为验证时才发现"传送带从不转"。逐个输出问：谁、在什么条件下，把它置 TRUE/赋值？答不上来就是漏了驱动逻辑。

3. 边界纪律（拦最高频的边界错）

• 对每个阈值，显式确定用 < 还是 ≤、> 还是 ≥，以及相等（=）时归哪一侧。
• 显式确认负数、0、上界各落到哪个分支——别想当然。
• 需求出现 "otherwise / 否则 / 其余情况 → X" 时：把所有未被前面分支覆盖的区间（含负数、超大值）都导向 X。最典型错误：把 "i=0→0，否则→-1" 写成 IF i<=0 THEN o:=0，于是负数错误地变成 0。
• 每个 `CASE` 语句是否都有 `ELSE` 分支？ 缺 ELSE 等价于边界遗漏——意外状态值会静默跳过，不执行任何分支，输出保持上周期残值。

4. 全局不变式（拦丢互斥 / 丢优先级）

• 需求要求互斥 / 独热（同一时刻只有一个输出有效）时：代码是否强制了？多输入同时为真时会不会多个输出一起置位？
• 需求有优先级 / 覆盖关系（急停、停止、安全信号优先）时：高优先级信号是否最先判断、压倒后续逻辑？别把 StopButton 放进 ELSIF 链尾导致 Start 同时按下时不停。

5. 行为模型忠实（拦乱加状态 / 信号声明错）

• 别加需求没要求的内部状态：锁存（首周期latch）、边沿检测（R_TRIG）、状态机——如果需求描述的是"输出随当前输入即时变化"的组合逻辑，就保持组合逻辑，不要引入跨扫描周期的记忆。
• 信号声明(app 口径)：输入用 AT %IX/%IW、输出用 AT %QX/%QW,located 变量独占一个 VAR 段(见 AGENTS.md §VAR 段组织)。需求点名的输出必须真的赋值到对应的 `%Q*` located 变量,别只算在内部临时变量里让输出保持初值。

6. 周期 / 时序语义（最高频缺陷区）

• 持久状态复位（最常踩）：FB 的 VAR / VAR_OUTPUT 是跨扫描周期保留的实例变量——声明里的初值（如 CNT : DINT := 2;）只在实例创建时赋一次，不会每个扫描周期自动恢复。逐个变量问：它该跨周期累计 / 记忆（计数器、定时器、锁存、状态机、边沿 last 值），还是该每周期从当前输入重新算（循环计数器、本周期工作量、“本次是否命中”标志）？
• 后者必须在代码体开头显式赋初值复位（CNT := 2; 写进逻辑里，而非只在声明处 := 2），否则上周期残留值会漏进本周期，造成“第一次调用对、之后调用错”，并常违反末态不变式（如 WHILE CNT < N 的 CNT 未复位 → 下个周期 N 变小时 CNT > N）。
• 前者要确认有正确的清零 / 复位条件（如标志位置位后，在该清的分支里清掉，别永远卡 TRUE）。
• 定时器的累加与判断顺序对吗？（先判到点再累加 vs 先累加再判，会差一个周期）
• 每个扫描周期执行一次的语义下，输出是否按需求在正确的周期更新？

7. 工程规范（非阻塞建议）

以下不阻塞交付，但建议遵循：

• 状态机规模：单个 CASE 状态数建议 ≤8；超过时拆子 FB。每分支代码 ≤10 行。
• 变量初始值：所有变量建议给默认值（:= 0 / := FALSE）。
• 错误输出（app 口径）：涉及定时器/传感器/执行器的 FB，建议暴露 error : BOOL + error_code : INT，超时操作配 TON 检测。

输出

逐条过完清单：

• 全部通过 → 写出最终 ST(`PROGRAM` + `AT %…` located 变量,见 AGENTS.md §必备结构)。
• 有不通过 → 就地修订草稿，再从第 1 步快速复核一遍，直到全过再写出。
• 用一句话说明你改了哪几条（便于追溯），不需要用户介入。

不允许的行为

• 不要为了过清单去读 / 猜隐藏的验证性质——只对照需求散文。
• 不要在清单未过时就写出最终文件。
• 不要借自检之名做需求没要求的"增强"（多加功能/状态/删需求要求的分支）——那恰恰是 (5) 要拦的。