SystemSimulationApp/skills/system-simulation/references/repair-policy.md

安全文本规范化策略

目的

repair-format 只解决可解析 JSON v1/v2 或 XML v3 的文本层问题，使文件采用稳定的 UTF-8 和跨平台文本格式。它不是模型迁移器，也不是语义修复器。以下限制只用于此命令；用户请求的拓扑/参数修改按 建模流程 处理。

允许的修改

仅允许脚本已经证明不会改变解析后数据合同的规范化，例如：

• 将可安全解码的输入统一写为 UTF-8；
• 统一 BOM 和换行表现；
• 规范化文件末尾换行；
• 对可解析内容采用脚本规定的稳定文本序列化形式。

以脚本返回的预览、变更摘要和哈希为准；不要在脚本外另写正则替换或自制格式化器。若文件连语法都无法可靠解析，停止并报告诊断，不能尝试猜测闭合括号、XML 标签或截断内容。

禁止的修改

repair-format 不得执行下列动作：

• 新增、删除、更换或重命名组件和连接；
• 修改组件 ID、类型、端口、modelVersion 或 Schema 版本；
• 填猜缺失参数、改变数值、单位、离散选项或介质引用；
• 修改仿真起止时间、采样间隔、最大步长或求解算法；
• 把 XML v1/v2 或旧工程升级到当前版本；
• 根据报错放宽容差、删除失败组件或改变物理拓扑；
• 覆盖源文件，即使用户给出的输出路径通过大小写、相对路径或符号链接指向源文件也不行。

发现上述问题时，可以解释和给出人工处理建议，但不能借“修复格式”的名义实施。

强制确认流程

1. 对源文件运行 inspect，记录格式、诊断和 SHA-256。
2. 生成或读取 repair-format 的规范化预览，向用户说明只会改变哪些文本表现，并展示目标输出路径。
3. 等待用户针对该预览明确确认。笼统的“帮我看看”或先前对其他版本的确认不能复用。
4. 使用同一个源文件 SHA-256、预览返回的 confirmationToken、--confirmed 和预览中相同的 --output 路径执行写入。token 绑定源哈希、规范化输出哈希和目标绝对路径。
5. 如果哈希、规范化结果或目标路径已变化，停止并重新预览；不能绕过 --expected-sha256 或确认 token。
6. 对输出文件重新运行 inspect。只有重新校验通过且解析后的模型语义未改变时，才能报告完成。

示例命令形状见 workflows.md。

输出与交付

• 输出名称建议为原名加 .normalized，例如 plant.normalized.json 或 plant.normalized.xml。
• 保留源文件；清楚列出新文件、源 SHA-256、输出 SHA-256 和重新校验结果。
• 如果没有文本差异，说明文件无需规范化，不制造副本冒充修复结果。
• 如果写入失败或输出校验失败，不能把不完整文件当作成功结果交付。