# 安全文本规范化策略

## 目的

`repair-format` 只解决可解析 JSON v1 或 XML v3 的文本层问题，使文件采用稳定的 UTF-8 和跨平台文本格式。它不是模型迁移器，也不是语义修复器。

## 允许的修改

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

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

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

## 禁止的修改

本版不得自动执行下列动作：

- 新增、删除、更换或重命名组件和连接；
- 修改组件 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](workflows.md)。

## 输出与交付

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