admin/workbuddy_skills
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
71 Commits 1 Branch 0 Tags
fe22f4cebe20d14562d6d02852588abe05ab2470
Commit Graph
19 Commits
Author SHA1 Message Date
admin fe22f4cebe session-mechanism：两个看板定名（会话看板 / 项目看板）＋ 包内代码一律相对路径 
用户令（两句，同一轮）：
  ①「会话技能中 能用相对路径的都要用相对路径」
  ②「把会话的 项目目标看板 改成 项目看板，
     项目看板 和 会话技能的任务看板 都重新命名 会话看板、项目看板」

## 一、改名：项目管理界面 → 项目看板
* 目录：boards/项目管理界面/ → boards/项目看板/（会话看板不变）
* 包内引用：路径性（3 行）＋ 展示名（6 处，含 argparse description、启动横幅、
  错误日志前缀、模块 docstring、页面 <title> 与 .brand）
* HTML 标题：<title>项目管理 · 执行任务</title> → <title>项目看板 · 执行任务</title>

## 二、相对路径（新立第 11 条禁令）
判据＝「这个根能不能从『我自己的位置』推出来」：
* 能（本包自己的目录）⇒ 从 __file__ 上跳推导
* 不能（工作区根 / 配置目录 / 文档库根）⇒ 读本包 env/roots.env
* 推不出来 ⇒ 如实报错 ＋ 留痕（⛔ 不许静默扫空）

落点（共 4 处代码级硬编码，全部清掉）：
* boards/项目看板/project-board.py：新增 _sm_load_roots()；
  技能根改 HERE.parent.parent；WS_ROOTS 从 DSH_AIROOT 推导；
  推不出根时打警告 ＋ 写 logs/project-board.err.log（原为静默扫出 0 个项目）
* scripts/selftest.py：生产区定位改为扫 DSH_AIROOT 下兄弟区（⛔ 不写死区名）；
  两处测试假路径去掉盘符

⛔ 文档/注释里的绝对路径保持原样（举例、历史取证照写 —— 那是证据）。

## 验收
* 换机场景实测（技能包拷到 /tmp、不带 env/roots.env）：
  无任何配置 ⇒ 如实报错；只给 DSH_AIROOT ⇒ 正常扫到 4 个项目
* selftest --filter 看板：PASS 110 / FAIL 0（报告型 1 条不计入）
* 项目看板服务：pid 40776 · HTTP 200 · <title>项目看板 · 执行任务</title>
  · /api/projects 出数据 · /healthz ok
* py_compile 三份改动文件全过
 2026-10-14 16:33:28 +08:00
admin 52566c79f9 session-mechanism：两个看板整包搬进 boards/（页面与脚本同处一包） 
用户令：「把这两个看板都纳入会话技能中，分两个看板文件夹，开个 boards 文件夹放两个看板」
「1 boards 2 A」（文件夹名 boards；本区部署与计划任务本轮一起改）

## 分层（新增第三层）
  scripts/  ＝ 可执行程序（被计划任务／hook 调）
  assets/   ＝ 静态素材（样式、模板）
  boards/   ＝ 自带页面的看板程序（一个看板一个文件夹，页面＋脚本同处一包）

## 动了什么
* boards/会话看板/（6 文件）：board.py / board_ext.py / board-launch.py /
  board-launch.py.tpl / board.html / board-render-probe.js（从 scripts/ 与 assets/ 搬入）
* boards/项目管理界面/（3 文件）：project-board.py / project-board.html /
  project-board-launch.py（从工作区 交付物/项目管理界面/ 复制入）

## 搬迁带出的真缺陷（已修，非补丁）
* board.py：「与 collabd.py 同目录」这个前提搬走后不成立 ⇒ 原来会**静默**落到
  本地抄的那份判据（自测「两侧共用同一实现」判 FAIL，但看板照跑、肉眼看不出来）。
  改成候选表（同目录 → 包内 scripts/ → DSH_SKILL_ROOT/scripts/），并在兜底分支**写 stderr 留痕**。
* board.py：CFG_P 同样按 HERE 找配置 ⇒ 与 collabd.py::load_cfg() 对齐查找顺序。
* selftest.py：一个 H 指两处的假设（board.py 与 collabd.py 同目录）拆成 H/B 两参数；
  board.html / board.py 全部改走 BOARD_DIR / board_py()。

## 顺带修一条既有 FAIL（与搬迁无关）
* 判据锚点没跟文档改：supervise-persistence.md 措辞在 053a6a6 已改成
  「排期按点拉起主会话这条路不存在」，判据仍锚旧句 ⇒ 恒红。判据改成锚档内现存那句。

## 验收
* selftest：--filter 看板 PASS 110 / FAIL 0（报告型 1 条不计入）；
  全量 PASS 91 / FAIL 1（同一条报告型，实质 FAIL 0）。
* 会话看板 board.py --out ⇒ 50515 字节快照，无「回落本地判据」告警（证明真从 collabd.py 取）。
* 项目管理界面 --once ⇒ 4 个项目全列出；HTTP / 200 · 54102 字节（＝技能包真身那份）·
  /api/projects 出数据 · /healthz ok。
 2026-10-14 15:39:41 +08:00
admin 5d16c6df70 session-mechanism：SKILL.md 的 frontmatter 改成合法 YAML（内容一字不动） 
原写法：`last_change` 是一行超长标量，其后 12 行以 `·` 开头且无缩进，
顶层出现无键的行 —— 那不是合法 YAML；`agent_created` 前面还夹着一行
游离的 `· **本包自身**：…`，同样在顶层无键。

改法：改成块标量 `last_change: |-` ＋ 续行统一两格缩进（含那行游离内容）。
只改写法，内容一字不动。

验证（改前 vs 改后逐字比对）：
- 顶层无键行：12 → 0
- last_change 正文 12 行逐字一致
- 正文（第二个 --- 之后）逐字一致
- PyYAML 解析通过，字段＝name / description / version / updated_at /
  last_change / agent_created，last_change 3358 字符 / 36 行
 2026-10-14 11:25:39 +08:00
admin 053a6a6723 session-mechanism：主会话只能由用户开（撤掉"排期建主会话"那条路） 
用户报障：「技能中没有任何创建主会话的机制，除非是创建接续会话」。

病灶：supervise-persistence.md §〇 早期把「定时任务创建主会话」与「用户手动
创建主会话」并列成两种合法场景，SKILL.md §⑥ 顺着抄了一遍 ⇒ 读到的人会理解成
"这条路是允许的"，于是照做。

实测事故（mcn-aigc-ontology 2026-10-14 07:31）：init_workspace 装机制后建出
recurring 排期 [主]-super-i卡片采集-主会话（FREQ=DAILY;BYHOUR=09），prompt 里
写着「你是本工作区的主会话……要推进就直接建 [执行] 排期拉起任务会话」——
主会话的口径被套到了一条排期身上。排期开出来的会话恒是任务会话那一档
（is_background_automation=1）⇒ 台账里多一条"主会话"，用户那边没多窗口。

改动：
- SKILL.md §⑥：改成「形态只有一种：主会话由用户手动开」，⛔ 排期拉不出主会话
- supervise-persistence.md §〇：表格两列改一列 + 新增事故回放小节
- supervise-persistence.md §八：删掉「B · 定时任务创建主会话」整行
- architecture.md §1：新增《主会话怎么来：只能由用户手动开》段
- session-rules-check.py：新增判据 ⑬ main_sched（扫排期名以 [主] 开头或含
  "主会话" ⇒ ACTIVE 报 fail、非 ACTIVE 报 warn）；扫描面 recurring 与 once 全含
- SKILL.md 体检清单：十二项 → 十三项，补 ⑬ 变异对照记录

判据验收（非恒绿）：喂 mcn 区真数据三种输入 —— 原样 PAUSED ⇒ warn；
伪造成 ACTIVE ⇒ fail；无此类排期的区 ⇒ ok。

同批带上的既有改动：supervise-launch.py 路径相对化 + 三级取值（禁回落 ~）。
 2026-10-14 09:48:01 +08:00
admin 60a6e30ba2 session-mechanism：建任务的 RunLevel 改成按账户权限自适应（非管理员机不再被拒） 
现象：常驻每次尝试给自己装保活任务，日志都留一行「常驻自我供给（计划任务）：⛔ 登记失败：
Register-ScheduledTask : 拒绝访问」⇒ 非管理员账户的机器上常驻没有自愈载体（死了没人拉）。
真因（2026-10-12 实测坐实）：建任务时把运行权限写死成 `-RunLevel Highest`，而该机账户不是
管理员，Windows 直接拒绝注册；同一个任务去掉这个参数就建得成。

改法（一次性判定，⛔ 不用「先按 Highest 建、失败再重试」—— 那会让每次多一次失败注册）：
新增 `_admin_principal_flag()`：管理员（进程已提权）⇒ ` -RunLevel Highest`（原行为不变）；
非管理员 ⇒ 空串（整段去掉 `-RunLevel`）；判不出来 ⇒ 按普通权限走（宁可少一次提权，也要建得成）。
落点三处：`collabctl.py::ensure_keepalive_tasks()` 两处（保活任务 ＋ 看板任务）、
`collabd.py::_escalate_to_keeper()` 一处（自我供给旁路）。

同批退役（定案 A）：`scripts/keepalive.py` → `keepalive.py.retired-20261012`。
它零 importer、不在 `deploy_code.py` 分发清单，`references/deploy.md §4` 早已写明它是
「旧副本、职责已被本 skill 吸收」；留着就是第二份建任务实现，与「建任务只许一处」相抵。
⚠️ 它的 `-ExecutionTimeLimit (New-TimeSpan -Minutes 2)` 确实与另三处（无时限）不一致，
退役后该不一致一并消失；工作区侧无同名副本，无需清理。

文档订正（旧结论是误归因）：
  · `assets/board-launch.py.tpl` 那条「`Highest` 不是可选项：`Limited` 实测 `LastTaskResult=1`」
    ⇒ 订正为「`RunLevel` 按账户权限定」。看板 `LastResult=1` 的真因是单例守卫 ＋ `pythonw`
    无 stdout 把退出码顶成 1（`references/pitfalls.md` 已写明），与 `RunLevel` 无关；
    非管理员机上 `Limited` 实测建得成、也跑得起来。
  · `SKILL.md`、`references/supervise-persistence.md` 同步改口径。
  · `references/deploy.md` 包内脚本清单去掉 `keepalive.py`。

验证（本机实跑，⛔ 不真建任务：把脚本调用拦下来只看文本）
  · 两分支对照：管理员分支 6/6 段带 `-RunLevel Highest`；强制非管理员分支 6/6 段无 `RunLevel`。
  · 与改动前逐字对照：管理员分支生成的脚本归一化后完全一致（6/6 段）⇒ 原行为不变。
  · `selftest.py`：改前 110/0、改后 110/0（无回归）。
  · `install.py --manifest`：77 份文件、语法失败 0。
  · 副本已分发到本机 4 个工作区（md5 与源一致）。
⚠️ 非管理员分支本机验不到（本机是 Administrator）⇒ 该档验收需在非管理员账户的机器上跑。
 2026-10-12 11:07:02 +08:00
admin d81f75f173 技能包：配置与代码分家 —— 每包自建 env/ 放本机专属配置，scripts/ 不再写死本机路径 
用户 2026-10-11 原话：
· 19:22「这个环境都是针对一台机器的，同步到别的机器把环境都搞坏了」
· 19:28「不用挪出 用env文件夹区分就行，重点是 脚本是脚本 配置是配置」
· 19:29「每个技能 需要环境配置的 都有自己的 env文件夹」
· 19:30「修改完成后要仔细检查 避免调整后 各技能脚本运行失败」

改动：
1、session-mechanism 新增 env/（roots.env＝本机真身不入库 ＋ roots.env.example＝样例入库），
   install.py 的 ROOTS_ENV 改指 env/roots.env；全包脚本/hook 的配置定位统一为
   「向上 4 层 × env/roots.env 优先 → 包根 roots.env 兼容 → 技能库那份兜底」。
2、去硬编码：collabctl / keepalive / supervise-launch / board-launch 里的本机路径与本机工作区
   清单全清，改为 DSH_AIROOT（兜底 dirname(DSH_WS_ROOT)）＋ 扫 <AIROOT>/*/.workbuddy/collab/
   自动发现；保活任务名按 collabd-keepalive-<工作区名> 现推；启动器默认值改 ~/.workbuddy 形态。
3、browser-harness：bh_chrome_keepalive.py 默认值全部改 env 驱动，新增 env/bh.env.example。
4、.gitignore：env/ 下只放行 *.example（三行三种层级）＋ 兜住旧位置的包根 roots.env。
5、改包纪律.md 新增「四、包结构：脚本是脚本，配置是配置」，立为全仓通用规矩。
6、文档同步：SKILL.md / deploy.md（新增 §3b 配置层级、§6 换机器必查 6 件事）/ rules.md /
   pitfalls.md / supervise-persistence.md。

验收（本机）：py_compile 34 个 py 全过；selftest PASS 109 / FAIL 0；
逐文件实证 8 个 loader 命中 env/roots.env；preflight-lock.sh 同目录实测解出两个根；
install.py --manifest 77 份、语法失败 0。

异机验证（包拷成「新克隆」（只有 *.example）＋ 另造假工作区 ws-alpha/ws-beta）：
install.py --apply 自生成该机 env/roots.env；collabctl/keepalive 自动发现的确实是
ws-alpha/ws-beta、任务名现推（写死清单确已消除）；部署副本本地无 roots.env 时靠
CODEBUDDY_CONFIG_DIR 兜底读到技能库那份；整套 selftest 有宿主库时 PASS 108 / FAIL 1
（唯一 FAIL＝该区没有常驻心跳，环境所致；本机常驻在跑时同一套为 PASS 109 / FAIL 0）。
 2026-10-11 21:49:28 +08:00
admin c76f5be36c session-mechanism：接上「遇阻碍 ⇒ 置阻碍 ⇒ 机制暂停」＋ 授权检查会话自解除孤儿锁 
用户 10-09 两条令：
①「如果 工作区 项目机制 对应的会话异常 导致未解锁的情况下，可以授权 检查会话自解除孤儿锁」
②「其他类型 阻碍 遇到阻碍修改目标状态 暂停机制 让用户决策，不是有这个规则吗」

起因（contentm_agent 实测）：一把域锁的持有者会话被 terminated、锁遗留未释放 ⇒ 目标第 4 步 blocked；
R9 一律禁删锁 ⇒ 检查会话连开 11 棒（约 5 小时）每棒都撞同一面墙、零派活，每 30 分钟一棒。
拆开看是三条腿互相锁死：闸③「队列非空」对一条 blocked 恒真；闸① 2026-10-04 收窄时把
sessions-ended 整条腿摘了出去（置了「阻碍」也照样建）；结果检查 prompt 又明写「你没有改目标状态的出口」
⇒ 看得见的没权、有权的（目标检查要队列为空）看不见。

改动
- 新增 scripts/lock/orphan-lock.py：孤儿锁「判定 ＋ 解除」的唯一执行面。
  判据查宿主库 sessions.status（只读 SQL）：working 一律不动；terminated/error/archived 可解除；
  completed 须静默 >=30 分钟；查不到 sid / 库读不到一律不动（fail-closed）。
- collabd.py
  · 结果检查 prompt 开「一个」状态出口：--set-life 阻碍 --by "<会话名>" --check-why "<一句现状>"
    （"为什么"的旗标是 --check-why，不是 --why —— 后者是 --retire 的，写错会被静默忽略）；
    同时把「写明阻碍」的两个出口钉死：台账 --report ... --state blocked --reason ＋
    NEED-USER.md 里明确喊「需用户介入」。
  · 闸① 改两档：queue-empty 原样（非「进行中」不建）；sessions-ended「只拦『阻碍』」，
    「已完成」仍放行（不把 2026-10-04 修好的病搬回来）。docstring 五道闸 -> 六道闸。
  · 两条检查 prompt 都加了孤儿锁判定钩子（判「持有者已退出」才可自解除；判「活着」一律不动）。
- R9 条文加「唯一例外」：工作区 CODEBUDDY.md §3（定义处）、references/rules.md 新增 §10、SKILL.md，
  以及技能包与文档库两份 handoff-guard.sh 的「抢域锁失败」提示。
- selftest.py：新增两个用例（孤儿锁 16 项，含「working 不许动」的变异对照；阻碍档 6 项，
  含「已完成仍要建」的变异对照），并把写在两处的同一判据收成一处（改一处漏一处的实测教训）。
  全套 PASS 108 / FAIL 0。
- references/manifest.md：按「改完包必跑」重算（77 份文件，语法失败 0）。

不在本仓（各自仓内提交）：工作区 CODEBUDDY.md、文档库 CODEBUDDY.md 与 07-scripts/handoff-guard.sh。
 2026-10-09 07:24:14 +08:00
admin 805f1ba2d7 对外叫法落定：机制叫「项目机制」，用法「使用项目机制完成目标：XXXX」；角色名不变 
一、用户令（逐字）
`后续说 使用项目机制完成目标：XXXX，创建会话还是叫做 执行会话 和 检查会话`
⇒ 口径终于对齐：**「项目机制」＝ 这套机制的名字**（不是会话名），
  而它建出来的会话**仍叫「执行会话」「检查会话」**（连同「主会话」）—— **⛔ 角色名一律不改**。

二、改法（4 处）
· `SKILL.md` H1 后新增「**对外叫法**」块，逐字记下用户原话，并写清：
  **项目机制 ＝ 机制的名字；执行会话／检查会话 ＝ 会话的名字**，两者⛔ 别混。
· 第 0 步触发句置顶加 **`使用项目机制完成目标：XXXX`**（标注 2026-10-08 用户令的现行写法）。
· `skill-load-guard.py` 词表加「项目机制」族（`使用项目机制`／`项目机制完成`／`项目机制`），
  ⛔ **旧词一个不删**、⛔ **角色名不加进词表**（它不变）。
  复核：`使用项目机制完成目标：XXXX` 命中 `['使用项目机制','项目机制完成','项目机制']` ✓；
  旧写法 `使用执行会话完成 X 目标` 仍命中 ✓；`按决策方法处理` 仍命中 ✓。

三、与上一轮的关系
上一轮我按「执行会话（协作会话）改为 项目会话」把目标词改错了（已全量撤回，见 `90e892e`）；
本轮按用户更正后的**正确目标词「项目机制」**落地，且**不再动角色名**。

四、验收
selftest.py rc=0 PASS 106 / FAIL 0；manifest 76 份、语法失败 0。
 2026-10-08 22:24:30 +08:00
admin 1d7d31a529 撤销误用的「项目会话」更名 ＋ 说人话新稿按**合并**落地（141 处措辞替换） 
一、用户令（逐字）
1. `1、A方案`
2. `执行会话没问题 。是之前的说法有问题：应该叫 项目机制 不叫 项目会话`

二、🔴 先撤回上一轮的错误更名（用户更正了目标词）
上一轮我按「执行会话（协作会话）改为 项目会话」把术语改成了**项目会话** ⇒ 本轮用户明确：
**「执行会话没问题」**、要叫的是「**项目机制**」、**⛔ 不是「项目会话」**。
⇒ 已**全量撤回**（6 处）：`SKILL.md` 的术语更名口径块／三类会话表那行／第 0 步触发句插入，
以及 `skill-load-guard.py` 词表里新增的"项目会话族"。
⚠️ 复核时看到的另外 4 处「项目会话」是**巧合的普通词组**（「本项目会话共 N 个」「不算本项目会话」），
   ⛔ 不是更名产物 ⇒ 未动。
🔴 **教训**：改名属"影响面变更"的**目标词**，一次说错就要全量撤回 —— 所以我这轮**没有再自行猜**（见待拍板项）。

三、A 方案：7 份按「**合并**」落地（不是覆盖）
· 规则（保守）：只应用**两侧都 ≤8 行、且在现文件里唯一**的"措辞替换"；**更大的块一律保留现文件原样**
  （那些块是别的会话今天加的新内容，例如 `stage-delivery/SKILL.md` 里 106 行的增量）。
· 结果：7 份共应用 **141 处**措辞替换（9／6／17／12／27／10／60），逐份有残留大块未动（已列出）。
· **改前备份** ⇒ `待清理/技能包-说人话合并前备份-20261008/`（7 份，可回退）。
· ⚠️ 加上上一轮直落的 9 份，A 方案的 16 份**全部处理完毕**：9 份直落（差异只在措辞）＋ 7 份按合并（保留新内容）。

四、验收
selftest.py rc=0 PASS 106 / FAIL 0；manifest 76 份、语法失败 0。
 2026-10-08 22:22:38 +08:00
admin 1ca0a637a6 术语更名第一步：执行会话／任务会话 ⇒ 项目会话（口径块 ＋ 触发词表）＋ 落地 9 份"说人话"新稿 
一、用户令（逐字）
1. `1、A 方案`
2. `把会话技能中 执行会话（协作会话）改为 项目会话 # 用法改为输入 使用项目会话完成目标：XXXXX`

二、A 方案：只落"说人话"新稿 —— ⚠️ 实测**只能落 9 份**，7 份必须合并
· 16 份新稿（`contentm_agent` 那条目标产出）逐份比对现文件：**9 份差异只在措辞**（0~2 行）⇒ ✅ 已落地，
  逐份 md5 与稿子一致；**原件已备份**到 `待清理/技能包-说人话落地前备份-20261008/`。
· 🔴 **7 份现文件含稿子里没有的内容**（最多的少 106 行！）—— 且 `stage-delivery/SKILL.md`、
  `execution-runbook.md`、`SKILL.md` 是**今天 15:28/15:29 刚被别的会话改过** ⇒ 直接覆盖会**丢掉今天的新内容**。
  ⇒ 按「改技能包前先看别人在途改动、⛔ 别硬覆盖」的规定**没动这 7 份**，留待合并（见回复待拍板项）。

三、术语更名（先落低风险那一半，让新用法今天可用）
· `SKILL.md` 第一屏加**术语更名口径块**：**项目会话（现行）＝ 任务会话（旧称）＝ 执行会话／协作会话（更旧称）**，
  新文字一律用「项目会话」；⛔ 三个词的旧正文**按本块读**（同 10-02 那次的做法）。
· 三类会话表里那一行改为「**项目会话**（旧称任务会话／执行会话）」。
· 第 0 步触发句加 **`使用项目会话完成目标：XXXXX`**（用户口径的现行写法）。
· `skill-load-guard.py` 的词表**加**项目会话族（`使用项目会话`／`项目会话完成`／`项目会话`／`创建项目会话`／`派项目会话`），
  ⛔ **旧词一个不删**（用户与新会话都可能用旧词，收窄词表＝把已授权的触发句漏掉，本项目栽过）。
  复核：`使用项目会话完成目标：XXXXX` 命中 `['使用项目会话','项目会话完成']` ✓；`用执行会话完成 X` 仍命中 ✓。
· 🔴 **机器前缀 `[执行]` 暂不变** —— 它是角色解析与看板的键（`parse_session_name`／`board.py::_role_of_title`／
  在跑的排期名），属影响面变更，**等用户拍板**。
· ⚠️ **全量更名尚未做完**：实测 **416 处 / 22 个文件**（`collabd.py` 71 ／ `selftest.py` 63 ／ `SKILL.md` 50 ／
  `board.html` 46 ／ `pitfalls.md` 36 ／ `board.py` 33 …）⇒ 按机制自己的三类规矩（注释文档 / `@case` 标题 / 看板文案）逐步收尾。

四、验收
selftest.py rc=0 PASS 106 / FAIL 0；manifest 76 份、语法失败 0。
 2026-10-08 22:10:12 +08:00
admin 2ed7766007 说人话落地：加每轮注入 ＋ 英文硬核版整包纳入 ＋ 第①段补写作口径 
一、用户令（逐字）
「humanizer（英文那份） 也要纳入」「重点就是做到说人话就行了」「但是 content_marketing_agent 的会话生成的文档并没有说人话，还是我手动要求的」

二、根因（两处，都不是"没整合"）
· **语气那一档只有指针、没有注入** ⇒ 实测没被读到（`SKILL.md` 必读表标题原写「三篇」而表里有 4 行，
  第 4 项＝作业规矩整包，被顶在"必读"之外；已订正为「四类」）。
· **写文档的执行会话那条链上一句写作口径都没有** —— 产品规划技能里「反 AI 味」只出现在**第③段界面**
  （且指的是界面不是文字），**第①段出文档那节零口径** ⇒ 产物自然是 AI 味。

三、改法
1. **每轮注入**（照排版那条现成机制，⛔ 不改 `main()`）：
   · `04-去AI味与说话方式.md` 顶部加 `<!-- VOICE-CORE -->` 紧凑块（≈450 字符：核心原则/四种高频 AI 味/交付前三问）；
   · `reply-style-guard.py` 里**原地重定义** `_core`（`_core_reply = _core` 后用新 `_core` 包住它并追加语气块）
     ⇒ 注入正文自动多一段，排版那条**不受影响**。
2. **产出侧补口径**：`product-planning` 第①段（stage-discovery）在 1b 表后新增「写作口径」块 ——
   落笔前读 `humanizer-zh` 或本包 04，**定稿前过「交付前快速清单」**，并列出六种禁用 AI 味；**适用本段全部五份产出**。
3. **英文硬核版整包纳入**：原独立技能 `humanizer` **逐字**搬入本包 `references/humanizer-en/`（6 文件、
   md5 逐个一致）：55 个模式 ＋ 5 种语气档 ＋ 0–100 AI 痕迹打分 ＋ `--file` 就地改；
   在 `04 §9` 关系表与 `SKILL.md` 对应物段登记（冲突以本包会话场景版为先）。

四、验收
· 新增 `selftest.py::t_voice_core`（4 项）；全量 **PASS 106 / FAIL 0**；manifest 70 → **76** 份、语法失败 0。
· 端到端喂真钩子：注入正文已含说人话块、排版块仍在。
· ⛔ 改的是钩子与技能目录（宿主直读）⇒ **不需要分发/重启**。
 2026-10-07 22:00:13 +08:00
admin 537f15f119 必读表标题订正：「先看这三篇」→「先看这四类」（第 4 项被顶在"三篇"之外、常被跳过） 
起因（用户问「说人话技能 加载会话基础规则中了吗」）⇒ 查证发现：
`SKILL.md` 第一屏那张必读表**标题写着「先看这三篇」，而表里实际有 4 行** ——
第 4 项就是 `references/作业规矩/`（一整包，`04-去AI味与说话方式.md` 说话方式/语气就在里面）
⇒ 标题把读者框在"前三篇"里，**第 4 项等于被跳过** ⇒ 语气那一档自然进不了上下文。

改法：
· 标题 → 「先看这**四类**」；
· 表后补一句点明：**第 4 项是一整包（四份）**，其中 `04-去AI味与说话方式.md` 管**语气**、
  `03-回复排版-核心块.md` 管**结构**（那一份的核心块由排版钩子**每轮自动注入**）；
· 留痕写上这次是哪个问题查出来的。

⚠️ 本轮**只订正"读得到"这一层**：说话方式目前仍属**按需读**（04 里没有任何注入标记，钩子也不读它）
—— 要不要照 `03` 的现成机制把它也做成**每轮注入**，是另一件事（涉上下文成本），已列为待拍板项。

验收：selftest.py rc=0 PASS 105 / FAIL 0；manifest 70 份、语法失败 0。
 2026-10-07 21:33:44 +08:00
admin 976abbd71a 订正两处陈旧表述：agent-operating-rules 已并入删除；补记 humanizer-zh 为可选增强 
起因（用户问「说人话技能 有整合到技能中吗」）⇒ 查证时发现会话技能里两处**现行表述**仍指着已删除的东西。

一、`SKILL.md`：「⛔ 已无必需外部依赖」那段的末句写着
   「📌 **那个技能**若同时装着，属可选增强（多了跨项目排版/去 AI 味的完整版），⛔ 不装也能跑」——
   而那个技能（`agent-operating-rules`）**已于 2026-10-06 整包并入本包并删除** ⇒ 照旧句去找必然扑空。
   已订正为：明确指出它已并入删除，并列出本包自带的对应物
   （排版 → `references/03-回复排版-核心块.md`；语气/去 AI 味 → `references/作业规矩/04-去AI味与说话方式.md`）。

二、`references/作业规矩/04-去AI味与说话方式.md` §9「与其他规则的关系」：原来只列了
   「入口 §2 排版契约」「本参考」「协作与提报判据」三项，**没提独立技能 `humanizer-zh`**。
   已补一行：通用版在 `humanizer-zh`（示例更全，19 KB），本包那份是**会话场景加固版**（多 4 节：
   中文会话专属加固 / 交付前清单 / 质量评分 / 完整示例）⇒ 两处同时装着时**以本包为先**；⛔ 不装也能跑。

验收：selftest.py rc=0 PASS 104 / FAIL 0；manifest 70 份、语法失败 0。
 2026-10-07 21:04:07 +08:00
admin e5dfb6e4ef 发布：常驻文档按现行形态重写 ＋ 作业规矩/01 先并后删 
一、常驻机制文档 references/supervise-persistence.md（整份重写 410→469 行）
- 照抄段由废弃的 start-supervise.ps1 形态，改为现行形态：
  计划任务 collabd-keepalive-<区>（每 5 分钟）→ pythonw.exe → supervise-launch.py → collabd.py --supervise
- 旧 ps1 形态整体降级为「§四 旧形态留痕」（逐条标 🟠，内容一字未删，供读老日志/老进程用）
- 判据订正：LastTaskResult 在长驻运行中是 267009（旧口径「必须 0」属"跑一次就退"时代，已作废）；
  BOM 那条随 ps1 形态一并降为历史；另两条仍有效（CODEBUDDY_CONFIG_DIR 空库 / WorkingDirectory 必须是工作区根）
- 删除 assets/start-supervise.ps1.tpl —— SKILL.md、manifest.md、collabd.py、selftest.py 四处早已按「该模板已删除」口径，本次把磁盘与文档对齐

二、references/作业规矩/01 先并后删（用户选定 A 方案：不丢内容 ＋ 只剩一处）
- 判据类并入 references/02-功能优先协作协议.md：
  §3.2 补「规则冲突裁决顺序」「冲突 ≠ 门禁」；§3.3 补回完整语言转换表（原处"已收敛到通用技能"在并包后成了悬空指针）；
  §5.3 铁律由五条补到六条 ＋ 接上配套硬红线「只做正向迭代」；新增 §5.5「提报前必答三问 ＋ 回话前自检」
- 排版类并入 references/03-回复排版-核心块.md 的「完整版」段（十四条反模式 / 骨架路由表 / 文案点名主体 / 文档直入主题）
  该段放在 REPLY-CORE 标记之外 ⇒ 每轮注入块逐字未变（实测仍 1172 字符）
- 删除 references/作业规矩/01-协作与提报用户判据.md，并跟改 6 处引用（SKILL.md 第一屏表、作业规矩/00 索引表与两处指针、
  作业规矩/03-多棒接力编排、00 的 frontmatter 变更记录）——含一处二级指针「见 §6 第 0 条」，已改指 03 完整版段

三、判据与卫生
- pitfalls.md：P0-74 去冗余（7107 → 5982 B，重复叙述合并），「沉淀纪律」由 FAIL 1 转绿
- install.py：manifest_files() 补排 logs/ —— 与它自己「运行日志不入表」的口径一致，否则跑一次钩子表就过期
- .gitignore：补 logs/；撤跟踪 logs/_dr_probe.json（钩子输出转储，全包零引用）
- references/manifest.md 用生成器重算：66 份文件，语法失败 0

验收读数：selftest.py rc=0 PASS 99 / FAIL 0（另 1 条报告型不计入）；
session-rules-check.py fail 0 / warn 1（"此刻无活会话"，正常态）/ ok 13；改动文件行尾全 LF。
 2026-10-07 00:32:47 +08:00
admin 9fd120f40b 整合作业规矩：agent-operating-rules 整包并入本技能 references/作业规矩/ 2026-10-06 23:44:16 +08:00
admin ea4e6d6d58 权威统一：提问/排版格式与自决策判据都归位到会话机制包内 
起因（用户）：「提问拍板格式不应该在会话机制中吗，怎么跑到别的技能中去了」
病根＝**权威声明分裂**：
  · SKILL.md:963 说 03 号是「内联副本」⇒ 隐指权威在 agent-operating-rules；
  · 而 03 号自己头部写着「**这份是权威源**」，且把它说的第②个消费者
    `scripts/apply-reply-rules.py` 写成了**不在本包**的路径。
  ⇒ 同一件事两处说法打架 ⇒ 改的人（我）会把改动做错地方。

处置（统一为「会话机制包内即权威」，与 02/04 两份的既有处置一致）：
  ① 注入器归位：新增 `session-mechanism/scripts/apply-reply-rules.py`，默认读**包内** 03 号；
  ② 03 号头部改写：权威＝本文件，两个消费者都在本包内；
  ③ `reply-style-guard.py` 第③级兜底从**别的技能**改回包内路径；
  ④ `agent-operating-rules/references/回复排版-核心块.md` 标注「副本·权威在会话机制」；
  ⑤ `dsh-decision/references/00-决策方法论.md` 标注「来源·权威在会话机制」；
  ⑥ SKILL.md:963 措辞由「内联副本」校正为「收进本包并定为权威」。

验收：注入器 `--check` 报权威源＝包内 03 号且与 CODEBUDDY.md 一致；
      每轮注入 1183 字符（含「竖排」「变相征询」）；
      **无 CODEBUDDY.md 的干净工作区也能取到**（1185 字符）⇒ 自包含成立。
 2026-10-06 22:45:43 +08:00
admin 433d43af54 decision-rules-hook: 注入补「两个停止点」＋「技术方案排序轴」 
起因（2026-10-06 用户问）：能自决的问题为什么还要问。
复盘发现注入的判据里**缺动作**：
- 缺「十步」的两个停止点 → ① 判类型（方案请求 vs 直接执行）② 判方向（扩大/收窄/中性）；
- 缺「自主裁决顺序」的排序轴 → 更小改动 → 更少新增形态 → **不扩大可见面**。
⇒ 前者导致「会扩大可见面」时不停手；后者导致排完仍把已定项混进待拍板清单（＝变相征询）。
本次只补这两条动作骨架（1459 → 1906 字符），⛔ 不塞十步全文（避免稀释）。
 2026-10-06 22:39:51 +08:00
admin 64dd82073b session-mechanism: 修复钩子静默失效 + 3 处判据缺陷；禁「变相征询」 
1) stop-dialog-guard: session_budget() 早退路径返回 2 值、末尾返回 3 值，调用方按 3 值解包
   ⇒ transcript > 64 MiB 时每轮 ValueError。因 fail-open（异常仍 exit 0），
   宿主零报错、install.py --verify 只判 rc=0 ⇒ 假绿；实测 86 条 EXCEPTION，
   死掉的是整条（水位/收口、接续机制起点、预算告警、门禁自检、路径自检）。

2) session-rules-check 三处判据：
   · hook_reg  按旧文件名找 ⇒ 合并成 prompt-guards.py 后每轮假红 ⇒ 改为一组可接受名
   · snap_sync 拿 mtime 当内容判据 ⇒ 连续 4 天假红 ⇒ 改为复用抽取器本体比对内容
               （变异对照：截断快照能报 fail，非恒绿）
   · mem_ptr   只查全局技能根 ⇒ 工作区自带技能被判悬空 ⇒ 改查「全局 ∪ 工作区」

3) pitfalls 新增 P0-95（改判据必须重跑变异对照；fail-open + 只看 rc=0 = 假绿温床）

4) 回复排版核心块新增「变相征询同样禁止」（先只报不动／等你发话／我倾向X你看呢
   这类不带选项的待定清单，一律按待拍板项写：问题＋说明＋各候选优缺点＋倾向）
 2026-10-06 22:27:03 +08:00
admin 19101acd65 init: workbuddy_skills 重建，仅收录 session-mechanism 
- 按用户指示清空原有 25 技能内容，只提交 session-mechanism（57 文件）
- 附 .gitignore（产物 + 本机凭据）
- 令牌明文已脱敏（历史 .neodata_token 与 pitfalls 引用均不入库）
- 本提交为孤儿提交（父提交为空），历史自此重新开始
 2026-10-05 14:13:24 +08:00