用途
tailor-guidelines 用于把某个指南文件真正变成“项目自己的”：做法是播种（seed）一份目标文件，再逐条与用户确认每个条款的去留与改写，使指南符合该项目的实际偏好与技术栈。支持的三种指南类型为 TEST（docs/TEST_GUIDELINES.md）、CODE（docs/CODE_GUIDELINES.md）和 ARCHITECTURE（docs/ARCHITECTURE_GUIDELINES.md）。
运行前提
- 处于变更工作树（worktree）中；指南文件本身也视为一次变更。
- 已知目标类型（TEST、CODE 或 ARCHITECTURE）。
- 当存在 .guardrails/units.yaml 时，需知道该文件面向根项目还是某个 unit；未告知时应询问。
- 指南文件承载项目偏好；标准或门禁所需的“底线”（floor）保留在技能中，任何条款都不得覆盖底线。
主要流程
- 定位或播种目标文件：目标为 docs/<KIND>_GUIDELINES.md，或某个 unit 的 <unit>/docs/<KIND>_GUIDELINES.md。unit 的文件会完全替代根文件，二者从不合并。文件不存在时，播种为完整副本（有根文件的 unit 复制根文件，否则复制已安装的默认模板 .guardrails/templates/<KIND>_GUIDELINES.md）。副本中不得写入对来源的引用。
- 逐条走查：每条消息只处理一个条款，展示条款及理由，询问“保留、修改或删除”，并给出推荐答案。修改时连同规则一起重写理由与示例，保证理由仍然成立。
- 让示例属于项目：TEST 类型针对 ## Seams 与 ## Doubles 下的每个条款；CODE 与 ARCHITECTURE 针对每个条款，要求给出项目自身技术栈（语言、测试运行器、依赖）的示例并替换通用示例。
- 若项目没有用户界面（仅 TEST），询问后删除 ## UI 一节；不得根据文件树自行推断。
- 拒绝与底线冲突的修改，并指出破坏了哪条底线。底线包括：每个测试携带 verifies:；每个新测试都曾被观察为红；测试在被验证行为破坏时失败（仅在“调用即需求”时，只断言某个 double 被调用才算满足）；class B 和 C 为每个 REQ 和 LLR 提供异常输入测试；class C 在每个被触及的 SDD 项接口处测试；每个 SDD 项追溯到 REQ；class C 项有 LLR；不同 class 的项之间声明隔离机制；每个第三方组件列入 soup.md；跨 unit 依赖在 depends_on: 中声明，class 不同时加 segregated_from:。条款可以收紧底线，绝不能放宽。
- 检查文件自洽：任何条款不得引用其他指南文件、安装默认值或项目不存在的文档。
- 在工作树中提交，由 merge-change 集成。
升级模式
当 ratchet 升级项目、且新模板即将覆盖安装默认值之前运行。若项目没有此类文件，则它遵循安装默认值，无需走查，直接停止。用 git diff --no-index 对比安装默认值（旧）与随附模板（新），逐条（每条消息）展示旧文本、新文本和新理由，询问“采纳、适配或拒绝”；每次采纳都应用底线的检查。绝不覆盖项目文件；被拒绝的条款保持项目原样。提交后，ratchet 再连同脚本复制新模板。
限制与注意
- 不得写入“其余见默认值”之类的引用，文件必须自洽。
- 不得整文件替换，只能逐条处理。
- 不得把底线当作可弯曲的偏好。
- 不得在一条消息里询问所有条款。
完成标准
目标文件存在且为完整副本、不含来源引用；每个条款都与用户确认过保留、修改或删除，且被修改的条款有契合的理由与示例；没有条款违反底线；升级模式下模板的每个变更条款都已采纳、适配或拒绝，且项目文件从未被覆盖；变更已提交到工作树供 merge-change 使用。