2 Commits
Author SHA1 Message Date
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,不截断,含「一律用肯定表述」「决定对象要点名到具体」
  「新建、生成时同样适用」。
2026-10-09 10:45:00 +08:00
admin 00110500a7 立「改包纪律」:把 2026-10-08 整文件覆盖事故的防线写进仓根
用户令「按照建议处理」。背景:2026-10-08 22:22 那次「说人话新稿按合并落地」实际是整文件覆盖,
抹掉了晚于新稿编写时点的全部改动(单一可信源声明 5→1、`## 供给` 块与六行表、供给口径翻转、
runbook §7 两条勾选项),并让闸门多出 12 条 FAIL。

四条硬纪律:
1、⛔ 不许整文件覆盖 —— 新稿是「改动意图」,逐节比对当前内容再落,宁可分多次小提交
2、落地前先比对时点 —— 新稿编写时点 vs 目标文件的最新修改时点,被改过就必须逐节比对
3、改完必跑闸门 —— `--ws` 必带、不许带 FAIL 提交;⛔ 但也别只看闸门绿(它查不出结构被删)
4、收到覆盖性提交先做结构体检 —— 拿「唯一权威处」这类结构标记的计数与上次收口版比

另附出事后的标准修法:先定性(两版本各跑一次闸门的可复现对比)/⛔ 别在被覆盖的基线上逐项修补/
先存档再回退(对照 diff + 全文快照 + 说明)/回退后立刻提交推送。
2026-10-08 23:10:12 +08:00