dsh_ai1net_server/.workbuddy/待落地/重启后待办.md

重启后待办（WorkBuddy 完全重启之后执行）

为什么在这里：这批动作只能在应用完全重启后做（hooks 是应用启动时快照）。放在 待落地/ 是为了"重启后那一刻必然被看到"。

1. ★ UserPromptSubmit 探针定论（最高优先，1 分钟）

cat "E:/ProgramData/AIProject/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）」节）。