admin
5004909267
用户 10-09 三条令： ①「那两份 不说具体 我怎么知道，看看会话提问的规则是否有缺陷」 ②「A 方案」（撤出 session-mechanism/roots.env 与 references/manifest.md） ③「要用确定XXXX 这样的描述，避免 不要XXXXX 会导致上下文干扰的描述，除了经验沉淀和红线避坑外」 ＋「不只是修改 创建生成时也需要遵守」 一、提问规则审计（三条缺陷，全部修掉） 1、判据用错了维度：旧措辞「⛔ 提问正文不许出现的：包名·环境变量·文件路径·commit/sha·表名/字段名· 类名/函数名」是按**词性**一刀切，而同一段末尾又写「正文只留能决定下一步的内容」⇒ 两句自相矛盾。 我按前半句执行、把要撤的文件名删成了「那两份」⇒ 待拍板项不可答。 ✅ 改成按功能判：**少了这个标识，用户还能不能决定** —— 不能 ⇒ 写进正文；能 ⇒ 删、下沉技术附录。 2、同一判据散在 6 处、措辞各不同（违反本项目自己的「禁重复判定标准」）：已收敛到同一句判据， 并互相标注「改这里必须同批改」。 3、🔴 最隐蔽：**每轮注入的那份 ≠ 包内那份**。钩子 `_core()` 是三级回退，① **本工作区 CODEBUDDY.md 的 `REPLY-CORE` 段**才是每轮注入的（包内那份只是换机器的兜底）。 我先只改包内 ⇒ 注入的仍是旧条文，而"文件都改了、自测全绿"，看不出来。 ⇒ 两份都改 ＋ 新增防漂移自测 `t_reply_core_same_source`（两份实质内容必须逐字一致）。 二、撤出两份「本机生成」的契约（用户选 A） - `git rm --cached session-mechanism/roots.env` 与 `session-mechanism/references/manifest.md` —— **本地文件一律保留**（实测 624 B / 18 568 B 仍在）。 - 为什么必须撤：别的电脑取仓时「同名覆盖」会把它们换成**我们这台机器**的路径 ⇒ 那台机器的 机制脚本去找不存在的目录。 - 新增入库样例 `session-mechanism/roots.env.example`（占位符，无本机路径）。 - `.gitignore`：加这两份的忽略行（⛔ 防 `git add -A` 捎回），并改掉原「刻意入库」那段注释。 三、「一律用肯定表述」写进注入面（原来只在 rules.md，注入面看不到） - 口径：**写或改技能与规则文件时一律写"要什么、怎么做"；新建、生成时同样适用**； 例外＝**以「经验沉淀」或「红线／避坑」为目的**的技能与规则（写法＝正向目标 ＋ 括号里的踩坑依据）。 - 落点：injected `REPLY-CORE` 段（工作区 ＋ 包内，逐字一致）· `rules.md §9` · `改包纪律.md` 新增第 5 条硬纪律（「二、四条」→「五条」）· `01-文档索引.md` 指针同步 · 把我在注入块里加的那段负向表述改成**正向主导**。 四、🔴 顺带抓到并修掉一个我自己造成的净变差 - 注入块有 **1400 字上限、且从开头截** ⇒ 我加条文把它顶过上限（1274 → 1414+）⇒ 尾部三条（变相征询禁止 / 不用征询句收尾 / 本工作区另有定稿）**静默消失**、不再注入。 - 修：上限 1400 → **2000**；并在 `t_reply_core_same_source` 里加断言 **块长 ≤ 上限** —— 以后谁再顶破上限，自测直接报红，逼他"要么精简、要么显式抬上限"。 - 验证：`被截断=False`，尾部三条都回来了。 五、验证 - 全套自测 **PASS 109 / FAIL 0**；py 语法全绿；`install.py --manifest` 重算（78 份，语法失败 0）。 - 注入块实测：来源＝工作区 CODEBUDDY.md，不截断，含「一律用肯定表述」「决定对象要点名到具体」 「新建、生成时同样适用」。
113 lines
6.1 KiB
Markdown
113 lines
6.1 KiB
Markdown
# 改包纪律（多会话共写 · 2026-10-08 立）
|
||
|
||
> 本仓被多个会话同时写，推进以分钟计。这份文件是把 2026-10-08 那次真事故的防线写下来 —— 谁来这个仓干活，先读这一份。
|
||
|
||
## 一、为什么立这一份
|
||
|
||
2026-10-08 22:22，一个会话把「说人话新稿」落地到 `product-planning`，**整文件覆盖**了 7 个文件。那份新稿是**基于较早版本**写的，于是**晚于新稿编写时点的改动全被抹掉**：
|
||
|
||
1、**「单一可信源」类声明 5 处 → 1 处**。最重的一处是 `references/stage-delivery/SKILL.md` 的 `## 供给（唯一权威处 · 改供给只改这一块）` —— 整节标题连同六行供给表一起被换成了另一种三列表。
|
||
|
||
2、**供给口径被翻转**。用户定案是「默认主线 ＝ `oil-ui-pro`（基础层），`open-design` 只是随段携带的**可选件**、选了才用」；覆盖版写成了「`open-design` ＝ 本段默认主线」。
|
||
|
||
3、`references/stage-delivery/references/execution-runbook.md` §7 完成标准**丢了两条勾选项**（「供给能力边界已核对」、「页型已判…每条都要附取值记录」）。
|
||
|
||
4、`3c` 子步名被改成「会诊」，但**没同步** `scripts/check_naming.py` 的 `STAGES` 表 ⇒ 直接报 FAIL。
|
||
|
||
5、**9 条「复述」类 FAIL 与 2 条废路径（`strategy/`、`ux/`）重新长回来** —— 权威声明一被削弱，复述就不再被视为违规。
|
||
|
||
⚠️ 当时提交信息写的是「按**合并**落地」，实际效果是覆盖。这**不是恶意，是流程缺陷**：新稿的编写时点早于被覆盖文件的修改时点，落地时不做三方比对，就必然丢东西。
|
||
|
||
## 二、五条硬纪律
|
||
|
||
### 1、⛔ 不许整文件覆盖
|
||
|
||
落地「新稿 / 改版 / 批量替换」时，⛔ 不许把手上那份稿子直接盖到目标文件上。
|
||
|
||
✅ 正确做法：把新稿当**改动意图**，逐节与目标文件的**当前内容**比对，只把有意的改写落进去，其余保持原样。宁可分多次小提交，也不要一次整文件替换。
|
||
|
||
### 2、落地前先比对时点
|
||
|
||
先回答两个问题，答不出来就别落：
|
||
|
||
1、这份新稿是什么时候写的？依据的是哪个版本的包？
|
||
|
||
2、目标文件自那以后被改过吗？`git log --oneline <新稿编写时点>..HEAD -- <目标路径>`
|
||
|
||
只要第 2 问的答案是「改过」，就**必须逐节比对**，⛔ 不许直接覆盖。
|
||
|
||
### 3、改完必跑闸门
|
||
|
||
`product-planning` 包改完，必跑：
|
||
|
||
```
|
||
cd E:/ProgramData/.workbuddy/skills/product-planning
|
||
E:/ProgramData/.workbuddy/binaries/python/versions/3.13.12/python.exe scripts/check_naming.py --root . --ws "<工作区绝对路径>"
|
||
```
|
||
|
||
- ⚠️ `--ws` **必带**（不带则找不到含 `docs/pm` 的那一层，会整包 FAIL）
|
||
- 期望 `失败 0`；有 FAIL 就修完再提交，⛔ 不许带 FAIL 提交
|
||
- ⛔ 但也别只看闸门绿不绿 —— 闸门查的是**命名一致性**，查不出「结构被删」这类损失（见第 4 条）
|
||
|
||
### 4、收到「覆盖性」提交后，先做结构体检
|
||
|
||
闸门绿 ≠ 没丢东西。覆盖性提交的典型特征：要么报一堆复述类 FAIL，要么因为权威处被一起删而集体失效。
|
||
|
||
体检方法（**比看闸门更早跑**）：
|
||
|
||
```
|
||
cd E:/ProgramData/.workbuddy/skills
|
||
git grep -c "唯一权威处" <rev> -- product-planning
|
||
git log --oneline -3 -- product-planning
|
||
git diff --stat <上次收口提交> HEAD -- product-planning
|
||
```
|
||
|
||
拿「唯一权威处」这类**结构标记的计数**与上次收口版本比。计数掉了 ⇒ 先查结构，再看内容。
|
||
|
||
### 5、写 / 改规则文件：一律用肯定表述（2026-10-09 用户令）
|
||
|
||
**写或改**技能与规则的文字时，**写"要什么、怎么做"**，让读者照着就能做对；**新建、生成时同样适用**。
|
||
|
||
- ✅ 例：「要点名到具体是哪份文件」。
|
||
- ✅ **例外（按文件性质定）**：**以「经验沉淀」或「红线／避坑」为目的**的技能与规则（踩坑记录 ·
|
||
红线清单 · 反例库）可以写负向 —— 写法是「**先写正向目标，再把踩过的坑放括号里当依据**」。
|
||
- **为什么**：这类文字是**每轮注入面 / 自动匹配面**（技能描述、注入块、钩子文案都在其中）。
|
||
把「不要 X」喂进去 ⇒ **反而把 X 拉高命中**。实测形态：某技能描述里列了「不用于普通插画／海报／故事板」
|
||
⇒ 用户说"做个海报"时它更容易被选上；2026-10-09 我在注入块里写了一整段负向表述，同族。
|
||
- 规则正文（唯一权威）⇒ `session-mechanism/references/rules.md §9`。
|
||
|
||
## 三、出事后怎么修（照 2026-10-08 那次的流程）
|
||
|
||
1、**先定性，别急着改**。用可复现的方式坐实「是谁引入的」：
|
||
|
||
```
|
||
cd E:/ProgramData/.workbuddy/skills
|
||
for c in <上次收口提交> <可疑提交>; do
|
||
rm -rf /tmp/pp-$c && mkdir -p /tmp/pp-$c
|
||
git archive $c product-planning | tar -x -C /tmp/pp-$c
|
||
printf "=== %s ===\n" "$c"
|
||
(cd /tmp/pp-$c/product-planning && \
|
||
E:/ProgramData/.workbuddy/binaries/python/versions/3.13.12/python.exe \
|
||
scripts/check_naming.py --root . --ws "<工作区绝对路径>" 2>&1 | tail -2)
|
||
done
|
||
```
|
||
|
||
两个版本各跑一次，`全过 / 失败 N` 的对比就是铁证。
|
||
|
||
2、**⛔ 不要在当前（被覆盖的）版本上逐项修补**。基线本身是错的，补得越多越像在旧稿上刷漆。
|
||
|
||
3、**回退**：`git checkout <上次收口提交> -- product-planning/`（只重置该包，⛔ 不碰别人正在改的文件）
|
||
|
||
4、**先存档再回退**。覆盖版里若有值得保留的内容（措辞改写之类），⛔ 不许无痕丢掉：
|
||
|
||
- 导 `git diff <上次收口提交> <覆盖提交> -- product-planning` 作对照
|
||
- 导覆盖版的全文快照
|
||
- 写一份说明，讲清「哪些能采纳、哪些不能」，结构损坏项必须逐条列出
|
||
- 参考实例：工作区 `归档/技能包-说人话改写-被覆盖存档-20261008/`
|
||
|
||
5、**回退后立刻提交推送**，并把体检结果写进提交信息。⛔ 别攒着 —— 攒着就会被下一次覆盖顺手带走。
|
||
|
||
## 四、一句话
|
||
|
||
**新稿是意图，不是内容。落地 ＝ 把意图逐节落到当前版本上，⛔ 不是把文件换掉。**
|