admin
ce8e6ceed9
回收 411 MB（470 M → 58.8 M），全部经回收站，可恢复： - 待清理/（146.2 M，含 relay 分片 128 M 与 42 项过程目录） - tmp/（32.4 M，按接续棒命名的过程临时区） - .workbuddy/tmp/（39.5 M） - 4 份 workbuddy.db 冗余副本（101 M，09-23 事故的坏副本 / 抢救产物） - tmp/im16/gw/centrifugo 二进制（63.9 M，可重下）+ 缓存残留 入库范围：常驻规则（CODEBUDDY.md / README.md / state.py）、在途接续入口与 接续包、docs/、交付物/、交接单/、归档/、scripts/、.codebuddy/、 .workbuddy/memory/；共 398 件，其中 >60 KB 的 26 件全为文档。 排除（.gitignore）：tmp/、待清理/、运行态日志与缓存、*.db 与 DB 备份整目录、 打包二进制（*.tar.gz / *.tgz）、记忆修复前备份。
1.8 KiB
1.8 KiB
重启后待办（WorkBuddy 完全重启之后执行）
为什么在这里：这批动作只能在应用完全重启后做（hooks 是应用启动时快照）。放在
待落地/是为了"重启后那一刻必然被看到"。
1. ★ UserPromptSubmit 探针定论（最高优先，1 分钟）
cat "E:/ProgramData/AI技能/aliyun-dsh-server/.workbuddy/stop-dialog-guard.log"
| 观测 | 结论 | 动作 |
|---|---|---|
出现 invoked(user-prompt) 行 |
该面被调用 ✅ | 把模式切成 inject：echo inject > "<工作区>/.workbuddy/stop-guard-mode"（改文件即生效、无需再重启）；随后验证：我故意用征询句结尾 → 下一轮应看到注入的上下文 |
| 日志仍为空 | 该版本连 UserPromptSubmit 也不调用 | 卸载 hooks.UserPromptSubmit（删一个键），只保留「常驻规则 + 每轮自检」那一层，如实收口 |
⚠️ 区分清楚：日志空不能在"未重启"状态下判负 —— 判断前先看 last-launch.json 是否晚于 2026-09-15 08:26（UserPromptSubmit 的装载时刻）。
2. 顺手核对（各 10 秒）
python3 "<技能>/scripts/resident-rules.py" --check→ 关键常驻规则是否齐备（应全绿）- 同一脚本
--env-check→ 路径 / hooks 命令里的绝对路径是否仍有效 bash dsh-server-docs/scripts/docs-sync-check.sh→ 对账是否只剩别人的 lane
3. 背景（为什么有这张表）
2026-09-15 实测：WorkBuddy 5.5.6 不调用 Stop 钩子（已卸载、不留假安全感）⇒ 改走 UserPromptSubmit（第二方案，已装为 probe 模式）。
全过程见 dsh-server-docs/04-调整方案/99-会话自决失效根因与Stop钩子补强.md（含「修正（2026-09-15）」节）。