记忆：技能仓根立「改包纪律」（0011050）——四条硬纪律 + 出事后标准修法

.workbuddy/memory/2026-10-08.md

@@ -991,3 +991,17 @@
 
 **④ 技能仓提交**：`8fc9a92`（已推 `46bee95..8fc9a92`）。
 ⇒ 我工作区那约 20 处修补随替换一并作废（它们本就是在被覆盖的基线上做的），属于预期。
+
+---
+
+## 第十四轮 · 立「改包纪律」（用户令「按照建议处理」）
+
+**产出**：`E:/ProgramData/.workbuddy/skills/改包纪律.md`（100 行），技能仓提交 **`0011050`**（已推）。
+
+**四块内容**：
+1、**为什么立** —— 把 2026-10-08 22:22 那次覆盖事故的 5 类损坏逐条写实（声明 5→1 ／ `## 供给` 块被换成三列表 ／ 供给口径翻转 ／ `runbook §7` 两条勾选项 ／ 9 条复述 ＋ 2 条废路径），并写明「提交信息写『合并』、实际是覆盖，不是恶意而是流程缺陷：新稿编写时点早于被覆盖文件的修改时点，不做三方比对就必然丢东西」。
+2、**四条硬纪律** —— ⛔ 不许整文件覆盖（新稿是「改动意图」，逐节落到当前内容上）｜落地前比对时点（`git log --oneline <新稿编写时点>..HEAD -- <目标路径>`，被改过就必须逐节比对）｜改完必跑闸门（`--ws` 必带、不许带 FAIL 提交，⛔ 但也别只看绿，它查不出结构被删）｜收到覆盖性提交先做结构体检（拿「唯一权威处」这类标记的计数与上次收口版比）。
+3、**出事后怎么修** —— 先定性（两版本各跑一次闸门的可复现对比）→ ⛔ 别在被覆盖的基线上逐项修补 → 先存档再回退 → 回退后立刻提交推送。
+4、**一句话** —— 新稿是意图，不是内容。
+
+⚠️ 另一半建议（让用户在那个会话里口头交代一句）是**用户侧动作**，我做不到，已在回复里点明。