meaning-preserving-rewrite

保留原意的重写

结果

用清晰的文字重写政策、计划、标准、笔记、报告和模板，不遗漏、弱化、扩大或隐藏任何规则或决定。

触发条件与边界

当用户要求简化政策或计划的措辞、受治理的文档需要明确的文风、缩短内容时必须保留每个条款，或某个软件包需要基线、台账、重写和证明时使用。

不要用于普通代码重构、允许省略细节的常规摘要，或一次性的创意文案。

必需的组成部分

资源门槛：使用此处命名的软件包文件前，先运行 mise run validate。

对于同时会更改某个技能软件包或依赖宿主写作政策的工作，请先阅读 依赖协调。此技能负责条款级的含义和文风。如果已安装软件包简化配套工具，则由该工具负责软件包模式和分解。

如果不存在同等职责的负责人，请保持软件包边界不变。不要虚构缺失的依赖，也不要为了绕开依赖而弱化某个分支。

写作标准

资源门槛：使用此处命名的软件包文件前，先运行 mise run validate。

• 开篇说明结果或规则。
• 使用常见词语、主动语态和自然的缩略表达。
• 尽可能让每个项目符号只包含一条规则。
• 明确指出负责人、文件、命令、数量或检查项。
• 首次出现时定义技术术语。
• 保留准确的路径、命令、哈希值、设置名称、源文引语、备份和原始输出。
• 使用 must、must not、may 或 prefer 明确表达要求强度。
• 异常范围不得宽于其来源中的范围。
• 不得依赖此前对话的上下文。
• 避免使用 em dash 和 en dash 字符、填充语、模棱两可的措辞和刻意润色的收尾语。
• 在标题、段落和列表之间保留清晰易读的间距。
• 将始终适用的规则放在父文件中。仅将分支细节移至适合其职责、且带有反向链接的文件。
• 每个受治理的 Markdown 文件都必须低于宿主的限制。不得仅为满足大小限制而删除易读的间距。

最终检查文字前，请阅读 文风检查。

流程

1. 捕获基线

资源门槛：使用此处命名的软件包文件前，先运行 mise run validate。

1. 阅读当前源文件，不要凭记忆还原。
2. 记录每个现存源文件的路径、哈希值、字节数、行数、标题和模式。
3. 将未来路径标记为不存在，不要虚构其哈希值。
4. 将每个当前目标复制到仅供负责人使用的备份中，并证明字节完全一致。
5. 如果源文件状态和仓库状态会影响重写，记录两者。
6. 遇到无法解释的源文件变化时，停止操作。

字段和检查项请参阅基线与台账规范。

2. 建立含义台账

为每个源条款分配稳定 ID。段落包含多条规则时，将其拆分。

对于每个条款，记录来源、准确文本、含义、要求强度、目标位置、替换文本、操作和审核状态。允许的操作为 keep、split、move 和 clarify。绝不要使用 drop。

添加每条新的文风规则，以及适用于所有计划文档的统一文风规则。生成的台账中，映射和元组的结构必须保持一致。

3. 检查当前源文件

资源门槛：使用此处命名的软件包文件前，先运行 mise run validate。

如果重写声称涵盖完整的官方文档或全部原语，请在撰写前清点当前的官方源集合。不要依赖过时的快照，也不要虚构页面。请遵循文档清点规范。

4. 重写

1. 保留所有已接受的含义及其要求强度。
2. 将始终适用的规则保留在父文档中。
3. 仅将特定分支的细节移至适合其职责的链接文件。
4. 每项流程只保留一个权威负责人。
5. 每次更改措辞或章节后，都要更新台账中的目标位置。
6. 将当前文件与备份进行差异比较，并将每个实质性内容块关联到台账 ID。

5. 验证

资源门禁：使用此处列出的软件包文件前，先运行 mise run validate。

检查以下所有内容：

• 台账覆盖完整、ID 唯一、操作获准、审核状态已批准，且目标内容确切存在。
• 行数和字符数限制、链接、上下文加载、哈希、模式和机密安全。
• 仅检查散文中的语气。跳过必须保持原样的精确引文、备份、原始输出、行内代码和代码围栏。
• 通读后语法清晰。
• 人工报告与机器报告一致。
• 分别给出组件结果和整体变更状态。

绝不要对混合了散文和代码的内容执行全局缩写替换或标点替换。精确修补对应的散文内容，然后重新检查邻近代码和语法。

临时验证器应放在操作系统的临时目录中，并在使用后删除。将针对性探测标注为临时检查，不要标注为套件通过。

审核包和收尾请使用验证契约。如果等待独立审核会阻碍已授权的主要工作，且没有外部规则要求独立审核，则在主执行者中运行相同检查，并将结果标注为非独立。

通过标准

仅在以下条件全部满足时返回 PASS：

• 每个源条款都有获批的映射，且没有任何操作为 drop。
• 每项替换都保留源内容的含义、范围、例外和强度。
• 基线和备份哈希仍然匹配。
• 每个链接目标都存在，且与台账一致。
• 语气、语法、安全和软件包检查均通过。
• 组件结果未被当作整体变更的证明。
• 临时验证文件已删除。

当有界组件证明通过但未达到整体标准时，使用 PARTIAL。当源内容已变更、缺少授权、证据无法访问或存在未解决的依赖，导致无法安全改写时，使用 BLOCKED。

常见失败

• 对尚不存在的路径计算哈希。
• 遗漏源内容中的条目或范围狭窄的例外。
• 用含糊的摘要替代精确规则。
• 修正措辞后仍留下过时的台账文本。
• 将检查器数据或行内代码作为散文扫描。
• 通过全文件清理破坏代码示例。
• 将组件级 PASS 报告为整体变更 PASS。
• 实际由主执行者完成审核，却声称审核是独立的。
• 留下临时构建器或过时的审核包。

软件包资源

使用 assets/meaning-ledger-template.json 作为字段模板。查看 examples/policy-rewrite.md、examples/blocked-drift.md 或 examples/package-reconciliation.md 中的操作示例。软件包维护者使用 references/、mise run test 和 evals/，然后运行 mise run ci；常规改写无需加载这些路径。

工厂执行契约

合格的结果是：以通俗语言改写文本，同时保留每一项已命名的含义不变量，并记录语义损失检查。保留当前含义不变量的行为，同时只更改其最小所属单元。

1. 使用 mise run ci 冻结当前软件包，并记录其摘要。
2. 运行 mise run domain-research-policy，然后判断当前含义不变量的来源和反证。
3. 针对已命名的含义不变量操作运行 mise run agentic-request。将语义选择交由模型处理。
4. 运行 mise run decision-policy、mise run ci 和行为评估。返回到失败层级最低的所属单元。
5. 运行 mise run invocation-policy -- <receipt>，并说明每项任务的情况，或说明其为何不适用于特定领域。
6. 可选运行 mise run improvement-policy。只有在没有受保护维度退化时，才保留一个已变更维度。

仅当需要相应契约时，才通过 mise run use-case-policy 加载 assets/use-case-contract.json，并通过 mise run evals 加载 evals/evals.json。

Mise 负责可重复的机制、排序、回执和检查。模型负责解读、因果判断、创造性工作，以及代码无法提供的直接感知。遇到缺少授权、证据过时或门禁未通过时，应停止。