# 2026-10-10 工作日志 ## browser-harness:把「Windows 起浏览器」的可抄三步写进正文,启动器随包(提交 `fe37c94`) **用户转述其他会话的反馈**: > 「技能里写了,但说得不完整 —— 这就是我反复踩坑的原因。正文只写了『起实例 = 丢进常驻后台任务』, > 没给能直接抄的命令,也没说 Windows 上该用哪个启动器;真正能跑的入口在技能外的另一个文件里; > 我照正文起,没做永不退出的循环 ⇒ 任务一结束 Chrome 被连坐。」 **真因(读代码才看清:两节自相矛盾)**: 1. `SKILL.md` §1 写「要丢进常驻后台任务、且一直不退出」,**§2 却直接给了一条同步的 `chrome.exe` 命令** ⇒ 照 §2 抄就是同步起 ⇒ 父进程一退 Chrome 立刻死(`WinError 10061`)。**"照正文起就踩坑"就是这么来的。** 2. 能跑的起法真正落在**工作区根**的 `bh_chrome_keepalive.py`(关键是 `while True` 守端口那段), 而那支脚本**不在技能包里** ⇒ 别的机器/别的会话无从拿到。 3. 顶部那颗子弹写着「细节见 §1,⛔ 本处不复述」—— 等于**只给叮嘱、不给命令**。 **改动**: - 🆕 `browser-harness/agent-workspace/bh_chrome_keepalive.py` —— 随包的可复制启动器(行为沿用已实测那支): 幂等(端口已在听 ⇒ 立刻退出)· `while True` 守子进程、退出就重起 · **僵死态只记日志、不自动重启**(保住现场)· 起 Chrome 前清代理 env · `DETACHED|NO_WINDOW|NEW_PROCESS_GROUP` · 参数化 `--port/--chrome/--profile/--log/--proxy`(默认值与线上一致;`--proxy` 对应文档里那条 socks5)。 - `SKILL.md` §1 改成**可直接抄的三步**:复制启动器 → `pythonw.exe` 起 → 计划任务兜 (动作也用 pythonw、5 分钟一次、`MultipleInstances=IgnoreNew`;`schtasks.exe` 在本机黑名单 ⇒ 走 PowerShell `ScheduledTasks`); 外加校验两条(`netstat` / `curl --noproxy`)。 - `SKILL.md` §2 加前置说明:那条 `chrome.exe` 是**启动器内部的那一步**,用途是看懂与排障;补 `--proxy` 用法。 - 顶部子弹从「本处不复述」改成「三步见 §1」—— **从"给叮嘱"改成"给命令"**。 - 表述按 2026-10-09 那条「一律用肯定表述」写:先写要什么,踩过的坑放括号当依据。 **验证**:`--help` 正常;`--chrome Z:/不存在` ⇒ rc=2 且不起浏览器(守卫);**真机幂等**:9223 正在听 ⇒ 跑它 rc=0、日志 `port 9223 already listening ⇒ exit (idempotent)`、端口数不变(确认没新起浏览器)。 **🔴 顺带收口一处我自己留下的破口**:上一轮改 `CODEBUDDY.md` 后,常驻规则**快照没重生成** ⇒ `state.py` 报 `[B] 快照与权威不一致`(fail 1)。已跑 `dsh-local-env/references/dsh-env-bootstrap/resident-rules.py --snapshot`(7976 字符 / 6 章节)⇒ **fail 0**。 📌 教训:**改 `CODEBUDDY.md` 之后要顺手重生成快照**,否则闸门一直红着。 ⚠️ **已知不一致(本次未动)**:`contentm_agent` 工作区根的部署副本与 `contentm_agent/tmp/bh_keep_chrome.py` 仍是旧的非参数化版本(三份并存:技能包=源、工作区根=部署副本、`tmp/`=更早变体)。本次只把**源**落进技能包。 **入库**:技能仓 `fe37c94` 已推送(`5004909..fe37c94`);`HEAD == origin/master`,工作区干净。 ## 核实:「session-mechanism/scripts/05-交接单 到底有没有用」(用户问) **结论:分两半 —— 锁那半是活的、天天在用;"交接单"那半基本停摆。** 1. ⛔ **用户问的那个路径不存在**:技能包里**没有** `05-交接单` 目录;全盘也搜不到 `session-mechanism/scripts/05-交接单` 这个写法。技能里的脚本一律按**文档库根** (`D:/github/dsh_shenxian/dsh-server-docs/05-交接单`)去找它,**没有一个按工作区找** ⇒ 那个组合看着像"技能脚本"与"05-交接单"两处拼到一起了。 2. ✅ **锁那半是硬依赖**:`.locks/`、`.exec-lock`、`.doing-<单号>`、`.me-lock` 全落在这个目录下。 10-09 那次的孤儿锁流水 `.locks/.orphan-release.log`(296 B)也还在里面。 技能脚本共 35 处引用它,**绝大多数是锁路径** ⇒ 动它会直接卡住所有会话的开工。 3. ⚠️ **"交接单"那半停摆**:台账 `README.md`(62 575 B)最后更新停在 **9-26**; 另有 22 个单子 md + `交接单-已完成/` 21 个文件,都是历史。 读它的 `lock/handoff-status.py` **没有任何入口在调用** —— 全盘只找到技能包内自引用 (manifest 登记 / 自己的 docstring / SKILL.md 的文件清单)+ 9-24、10-01 的历史日志。 ⇒ 不是"这个目录没用",是**目录里"交接单"那部分没在用了**。 4. 🔴 **实测确认的残留(0 引用、没人读)**: - 文档库 `05-交接单/` 下三个**旧命名锁目录**:`.lock-02`、`.lock-04`、`.lock-基础插件打包-01` (9-25/9-26 建;技能脚本里 grep **0 命中**)。 - `E:/ProgramData/AIProject/vibe-product/05-交接单/.locks`(**空目录**,10-05 建;脚本不按工作区找)。 ⇒ 锁的处置属 R9 管辖(只属用户本人)⇒ **未擅自动**,已列待拍板。 ## 用户令「需要清理」⇒ 已执行(删 5 个空目录)+ 追问「后续是否还会产生」 **清理(实测确认全是空目录,故用 `rmdir`:非空会失败 ⇒ 零误删风险)**: - 文档库 `05-交接单/` 下三个旧命名锁目录:`.lock-02`、`.lock-04`、`.lock-基础插件打包-01` —— `find` 实测**里面一个文件都没有**。 - `E:/ProgramData/AIProject/vibe-product/05-交接单/`(含其空 `.locks`)—— 同样空。 - ✅ 清后核验:锁根 `05-交接单/` 下**只剩 `.locks`**(`.exec-lock` 随我释放锁消失); `.locks` 里的 `.migrations` 与 10-09 那份 `.orphan-release.log` **都在**(没误删); 锁系统信息模式正常(无人占用 / 无全局锁)。 - 全程按规矩:先 `--claim-exec 清理-旧锁残留`(独占)→ 删 → `--release-exec`(已释放)。 **🔴 答「后续是否还会产生」:现有代码都不会再生成这两类。** | 对象 | 会不会再生 | 依据 | |---|---|---| | `.lock-02` 这类**旧命名锁目录** | ⛔ 不会 | 技能包 `grep -rn '\.lock-'`(排除 `.locks`)**0 命中** | | **工作区**下的 `05-交接单` | ⛔ 不会 | `init_workspace.py` 建的骨架只有 `.workbuddy/collab`/`tmp/supervise-inbox`/`交付物`/`.workbuddy/collab/logs`;lock 脚本一律按 `DSH_DOCS_ROOT` 定位,**没有一处用 `pwd`/工作区推它** | ⚠️ **唯一会自动建 `.locks` 的地方**:`handoff-guard.sh` 两处 `mkdir -p "$LOCKSROOT"` (`LOCKSROOT="$ROOT/05-交接单/.locks"`)—— 建在 **`$ROOT` = 文档库根**下,那是**正确位置**。 ⇒ 只有当 `DSH_DOCS_ROOT` 被配成工作区路径时,它才会在工作区下重建;那种情况要修的是**配置**。 ## 引用清单(答「是哪里引用」)——`05-交接单` 共 43 处,分三类 1. **锁路径(硬依赖 · 必须保留)**:`lock/handoff-guard.sh` 43/44/45/61/528/554 · `hooks/lock-guard-hook.py` 74/76 · `lock/preflight-lock.sh` 32 · `lock/orphan-lock.py` 201 · `collabd.py` 3919—3927。 2. **台账/交接单文档(半停摆)**:`lock/handoff-status.py` 35 · `lock/handoff-guard.sh` 459/461; 文档侧 `04-决策方法论.md` 52/60/366 · `作业规矩/03-多棒接力编排.md` 106 · `hooks/lock-guard-hook.py` 9(注释)。 3. **注释/对照说明(非功能)**:`collabd.py` 3841/3851 · `lock-guard-hook.py` 84 · `pitfalls.md` 756 —— 讲的是「旧仓目录名 `07-scripts/08-skills/05-交接单`」;域键锚点表实际用的是 `交接单`(**不带数字前缀**), 所以 **`05-交接单` 这个目录名本身不参与域键计算**(但它的后段 `交接单` 是锚点词 ⇒ ⛔ 别改这个目录名)。 --- ## 技能库「无效文件夹与内容」全库盘点(2026-10-10 晚 · 只读扫描,未动手) ### 一、运行期垃圾(已被 `.gitignore` 全挡 ⇒ 不影响仓库,只占本地盘) - `session-mechanism/tmp`(空)、`session-mechanism/logs`(32K,钩子日志)、`session-mechanism/install.log`(28K) - `__pycache__` ×3 + `*.pyc` ×6:`session-mechanism/scripts`(372K)、`.../scripts/hooks`(128K)、`product-planning/scripts`(24K) - `browser-harness/.browser-harness-dev`(7K:telemetry/version-cache/tmp 日志 + 一个空 `agent-workspace`) - `browser-harness/.venv`、`uv.lock`、`src/browser_harness.egg-info` - 顶层 4 个宿主迁移标记 `*.migration.json` + `_bm_skillid_migration.json`(**宿主写的,删了会重写**) ### 二、真缺陷:同内容两份(🔴 只有第 1 条会实际影响用户) 1. 🔴 **`humanizer` 技能名冲突**:`humanizer/SKILL.md` 与 `session-mechanism/references/humanizer-en/SKILL.md` **6 文件 md5 全同**、frontmatter 名都叫 `humanizer`、**都 `user-invocable: true`** ⇒ 技能选择列表里**出现两个同名项**。来源=2026-10-07「按用户令整包纳入本包」。 ⚠️ 动它有 3 处引用要跟:`session-mechanism/SKILL.md:980`、`references/作业规矩/04-去AI味与说话方式.md:264`、 `scripts/selftest.py:7449/7457`(按 `references/humanizer-en/SKILL.md` 路径断言存在)。 2. `draw-ui/scripts/credential-ui`(28 文件 174K)≡ `oil-motion/scripts/credential-ui`(27 文件 169K)md5 全同; 两边各自 `references/api-key-setup.md` 都按**自己包内路径**引用 ⇒ 有意自包含,但改一份另一份不跟。 (两个技能都不在推仓白名单 ⇒ 只在本地。) ### 三、⛔ 刻意保留、不是垃圾 - `product-planning/references/_留痕/`(4 份):`SKILL.md` / `stage-discovery` / `stage-requirements` 正文均指向它; `check_naming.py:292/339` 把 `_留痕` 列进**跳过白名单**。 - `stage-discovery/references/_superseded-competitor-analysis-英文商业版.md`:`competitor-analysis.md:288` 留痕指向; `check_naming.py:294` 专跳 `_superseded*`。 - `session-mechanism/references/` 的 `04-决策方法论.md`、`dsh-decision-method/`、`作业规矩/`:被 `02-功能优先协作协议.md` 与 `SKILL.md` 引用(**只是 `01-文档索引.md` 没登记** ⇒ 索引缺口,非垃圾)。 - `session-mechanism/references/manifest.md`、`roots.env`:`install.py` 本机生成,已 gitignore。 ### 四、代码瑕疵 - `session-mechanism/scripts/selftest.py`:`t_check_cooldown_no_pileup` **定义两次**(L871 与 L905,后者覆盖前者)。 ### 五、体量背景(非垃圾,供决策) `product-planning` 70M / 4454 跟踪文件,其中 `stage-delivery/assets/open-design` 独占 **64M / 4178 文件**(153 套设计系统 + 44 个版式模板,每个模板自带 SKILL.md)。 全库(排除 `.git`)107M。 --- ## 技能库清理 · 已执行(2026-10-10 晚 · 用户令「临时文件 不需要的文件都可以清理」) ### 一、删掉的运行期垃圾(全部已被 `.gitignore` 挡住 ⇒ ⛔ 不影响仓库) - `session-mechanism/scripts/__pycache__`(372K)、`scripts/hooks/__pycache__`(128K)、`product-planning/scripts/__pycache__`(24K) - `session-mechanism/logs`(32K:钩子日志 `_decision-rules-hook.log` + `_dr_probe.json`)、`session-mechanism/install.log`(28K) - `browser-harness/.browser-harness-dev`(7K:telemetry/version-cache/tmp 日志 + 一个空 `agent-workspace`) - `session-mechanism/tmp`(空目录,`rmdir`) - ⛔ **没动**:`browser-harness/.venv`(20M,本机要跑)、宿主 4 个 `.migration.json` + `_bm_skillid_migration.json`(宿主启动会重写)、 `_留痕`/`_superseded`/`dsh-decision-method`(都有正文引用)。 ### 二、代码瑕疵修复 - `session-mechanism/scripts/selftest.py`:`t_check_cooldown_no_pileup` **重复定义**(L871/L905,两段 `diff` 复核 IDENTICAL)⇒ 删线段。 改完 `py_compile` 通过 + 全套自测 **PASS 109 / FAIL 0**。 - `session-mechanism/references/humanizer-en/SKILL.md`:与顶层 `humanizer/` 技能 **6 文件 md5 全同**、名同为 `humanizer`、都 `user-invocable: true` ⇒ 技能选择面出现**两个同名项**。处置=**留内容、去注册**:改 `user-invocable: false` + 加 `disable-model-invocation: true`(引用路径与自测断言均不受影响)。 ⚠️ 效果要在**新会话**的技能列表里才看得到 —— 本会话的列表是开场注入的。 - 索引缺口(未动):`session-mechanism/references/01-文档索引.md` 未登记 `04-决策方法论.md`/`dsh-decision-method/`/`humanizer-en/`/`作业规矩/`; 而该档自己的第 1 条规则要求「新增文档必须登记」。 ## browser-harness「稳定开浏览器」改法(用户令:现在的写法没有准确的执行方式) ### 根因:机器侧两条并存 + 文档带占位符 1. `bh-chrome-9223`:动作走 `powershell.exe → tmp/_start_chrome.ps1`,而那支脚本 **10-05 就清掉了**;`` 为空 ⇒ **挂了 5 天的死任务**。⇒ **已删**(XML 备份在 `ai1net-dsh-server/tmp/bh-task-backup/`,可还原)。 2. `bh-chrome-keepalive`(唯一在跑的):动作指向 `contentm_agent/bh_chrome_keepalive.py` —— **旧硬编码副本**,与技能包那份**差 51 行**(70 vs 121 行)。 3. 技能 §1 原三步带占位符(`<技能包>`/``/`<工作区根>`),第 ③ 步只有散文没有命令 ⇒ 每次都要现推。 ### 改法 - `browser-harness/SKILL.md` §1 重写为**字面命令**:第 0 步先探测 → 第 1 步整段 PowerShell (本机实测 4 步全过:动作 ok/触发器 ok/设置 ok/注册 ok,XML 落成 `P99999999DT23H59M59S` + `ExecutionTimeLimit=PT0S` + `MultipleInstances=IgnoreNew` + `RestartCount=999`/`PT1M`) → 第 2 步校验 → 第 3 步**起不来对照表**(4 条:症状 → 病因 → 看哪里)。 - 启动器定位改到**技能包内那一份**(`skills/browser-harness/agent-workspace/bh_chrome_keepalive.py`),**⛔ 不再往工作区复制副本**(两份必漂移);脚本 docstring 同步改写。 - 删死任务 `bh-chrome-9223`。现状:只剩 `bh-chrome-keepalive`,State=Running。 ### 未做(待用户裁) `bh-chrome-keepalive` 的动作仍指向 `contentm_agent` 那份漂移副本 —— 改指向技能包那份需要**短暂重启浏览器**,属影响面决策。 ⚠️ `contentm_agent/.workbuddy/memory/MEMORY.md` 与 `MEMORY-压前-*.md` 里仍写着「脚本**放工作区根**」,与该技能新口径冲突。 ## 起法收敛 · 已执行(2026-10-10 22:33 · 用户选 A) ### 结果(进程级证据链完整) - `bh-chrome-keepalive` 已重建,动作 = `pythonw.exe "<技能包>/agent-workspace/bh_chrome_keepalive.py" --log "E:\ProgramData\.workbuddy\tmp\_bh_chrome.log"`; 读回 `Interval=PT5M`/`Duration=P3650D`/`ExecLimit=PT0S`/`Multi=IgnoreNew`;State=Running。 - 全机只剩**这一个** `bh-*` 任务(`bh-chrome-9223` 已删)。 - 新守卫 pid=49740(cmd 指向技能包那份);新 chrome pid=50436;端口 LISTENING + `CDP HTTP 200` + 日志 `[10-10 22:32:59] launched pid=50436` —— **三处 pid 对得上**。 - `contentm_agent/.workbuddy/memory/MEMORY.md` 那条浏览器规则已改为指向技能包那份(⛔ 不再写「脚本放工作区根」)。 ### 🔴🔴 本轮最值钱的教训:`Register-ScheduledTask` 的**非终止错误**会造**假绿** - 我先前的"四步实测全过"是**假的**:`-RepetitionDuration ([TimeSpan]::MaxValue)` 被计划任务判**超范围**(`Duration:P99999999DT23H59M59S`), `Register-ScheduledTask` 抛的是**非终止错误**,`try/catch` 抓不到、`$?` 也为真 ⇒ 打印了 "注册 ok" 而**任务根本没建**。 - 同一坑还有第二处:`-Force` 在任务 **Running** 时**不替换**,静默保留旧定义 ⇒ 读回才发现动作还是旧的。 - ✅ 判据(已写进技能):**注册完必须读回** —— `Get-ScheduledTask -TaskName …` 能查到 + `.Actions[0].Arguments` 与写入一致; 排错时给 `Register-ScheduledTask` 加 **`-ErrorAction Stop`** 才看得见真错误。 - ⚠️ 同族教训:**"命令没报错" ≠ "动作生效"** —— 凡 Windows 计划任务/注册表类写入,一律**读回取证**,不看回显。 ### 附带收口 - 动了 `session-mechanism` 包内两份文件 ⇒ 按包规跑了 `install.py --manifest --note "…"`:78 份文件、语法失败 0;两条登记的 size/md5 已与实际对齐(`humanizer-en/SKILL.md` 39523/`selftest.py` 505082)。 (`manifest.md` 本身 gitignore,只本机生成。) - 本轮所有临时件已清;只留 `ai1net-dsh-server/tmp/bh-task-backup/`(两个计划任务的原始 XML + 清单,可还原)。 - ⚠️ **仍未做**:`session-mechanism/references/01-文档索引.md` 未登记 `04-决策方法论.md`/`dsh-decision-method/`/`humanizer-en/`/`作业规矩/`(该档第 1 条规则要求「新增文档必须登记」)。 ## 🔴 保活的副作用:**手关的浏览器会被守卫拉回来**(2026-10-10 22:45 用户报障,待拍板) - 现象:用户关掉那个 9223 独立 Chrome 后,它 1 秒内又弹回来。 - 取证(`E:\ProgramData\.workbuddy\tmp\_bh_chrome.log`):`[22:45:06] chrome exited rc=0 ⇒ relaunch`、`[22:45:41] chrome exited rc=0 ⇒ relaunch` —— 35 秒内两次,`rc=0` =**正常关窗**(不是崩溃)。 - 机理**两层叠加**:① 守卫 `while True` 每 5 秒 `p.poll()`,Chrome 一退就重拉;② 计划任务本身每 5 分钟兜一次 ⇒ 就算守卫被杀,五分钟内也会再起一个。 - 🔴 **关键判据**:`rc=0`(手关窗)与 `rc≠0`(崩溃)**可区分** —— 这是"手关就别回来、崩了才拉回"能落地的依据。 - ⚠️ 单纯改脚本不够:**必须同时去掉任务那层每 5 分钟的重复**,否则新守卫会被 tick 再次拉起。 - 待用户拍板 A(保持现状)/B(关掉就是关掉,登录起一次 + 要用时 `Start-ScheduledTask`)/C(只在最近有人用过时才保活)。 ## 🔴 浏览器起法定案:**只允许会话后台任务这一种**(2026-10-10 22:50 用户令,已落地并实测) 用户原话:「只允许这一种方式,使用 browser harness 打开浏览器的时候也必须用这种方式打开浏览器,记录在 browser harness skill 中」 ### 改了什么 - **撤掉 Windows 计划任务**:`bh-chrome-keepalive` 整个 Unregister(含每 5 分钟的重复触发);更早撤掉的 `bh-chrome-9223` 保持不存在。现机 `bh*`/`chrome*` 计划任务 **0 条**。 - **脚本改守卫语义**(`browser-harness/agent-workspace/bh_chrome_keepalive.py`): Chrome **正常关窗**(`rc=0`)⇒ 守卫**停手退出**;**异常退出**(`rc≠0`)⇒ 立刻重拉。依据=实测「连关三次、每次 1 秒内弹回」。 - **`browser-harness/SKILL.md` §1 整段重写**为「起法:只允许这一种 —— 本会话的后台任务」,含:字面命令(`pythonw.exe` + 技能包内启动器 + `>> _bh_bg.out 2>&1`)、为什么只许这一种(同步调用/计划任务两条都列出实测依据)、守卫语义、🔴 **已知代价**(会话有后台任务 ⇒ 该会话 idle 钩子被静默压制)、校验两条、起不来对照表。 - 脚本 docstring 同步改写(原写的"计划任务每 5 分钟兜"已废)。 - 记忆:`contentm_agent/.workbuddy/memory/MEMORY.md` 两条改准(**净 −278 字符**,该档也已超预算)。本工作区状态层 `MEMORY.md` **未动** —— 它本来就写着「唯一可行起法=会话后台任务 + stdout 全重定向到文件」,浏览器保活正是照它做的,不需要加例外。 ### 端到端实测读数(本轮验收) - 起:后台任务跑那条命令 ⇒ `[22:50:32] launched pid=33968` = `netstat` 里的 LISTENING pid = CDP `HTTP 200`(**三处 pid 对得上**)。 - 关:走 CDP 关掉最后一个标签(等价人点关闭窗口)⇒ 日志 `[22:50:52] chrome closed cleanly (rc=0) ⇒ stop guarding, exit` ⇒ 后台任务 **22 秒后 completed**、端口无 LISTENING。 - 复核:再等 15 秒,端口仍空、无守卫进程、无 Chrome 进程、无计划任务 ⇒ **确实没有东西把它拉回来**。 - 流量:`_bh_bg.out` 为 **0 字节**(stdout 已全重定向,⛔ 不灌会话日志)。 ### ⚠️ 待处理 - `ai1net-dsh-server/.workbuddy/memory/MEMORY.md` **已超预算**:8,296 字符 / 上限 7,650 ⇒ 需要一次瘦身(本轮刻意不动它)。 ## 三个仓的归属核对(2026-10-10 22:55,用户提出「本工作区是这个仓库 `dsh_ai1net_server.git`」) 实测读数(只读探测,`git ls-remote` + `git fetch` 到 FETCH_HEAD,⛔ 未改任何配置): - **技能库** `E:\ProgramData\.workbuddy\skills` → `git@ssh.alotbuy.com:admin/workbuddy_skills.git`(**SSH 通**);待提交 **5 个文件**(全是本轮改的)。 - **本工作区** `E:\ProgramData\AIProject\ai1net-dsh-server` → 现 origin=`git@work.alotbuy.com:maogeigei/dsh_shenxian_workspace.git`(**该主机 SSH 主机密钥与本地记录不符 ⇒ 推不出去**);master `30b46db`(2026-10-06),32 提交,顶层=`CODEBUDDY.md`/`state.py`/`.workbuddy/`/`交付物/`/`归档/` ⇒ **运维工作区**。待提交 **512**(292 未跟踪/159 删除/61 修改)。 - **文档库** `D:\github\dsh_shenxian\dsh-server-docs` → 取走 `git@work.alotbuy.com:maogeigei/dsh_shenxian.git`、**推送走 `https://cnb.cool/maogeigei/dsh-shenxian.git`**(HTTPS,不受主机密钥影响)。待提交 **174**。 - 🔴 **用户点名的 `git@ssh.alotbuy.com:admin/dsh_ai1net_server.git`:可达**(master `e6207aa`,59 提交,tip **2026-09-24**),但顶层是 `src/`/`web/`/`package.json`/`Dockerfile`/`deploy/`/`config/`/`test/`/`LICENSE`/`COMMERCIAL-LICENSE.md` ⇒ **平台源码仓**,与本工作区**没有共同祖先**(`merge-base` 为空)。 ⇒ 「本工作区就是这个仓」按内容对不上,已作为待拍板项交用户确认(倾向:该仓归源码,工作区仍推原仓,另治 `work.alotbuy.com` 的主机密钥)。 🔴 **顺带记下的记忆硬伤**(已审计,待拍板后再改 `MEMORY.md`): ① 第 23 行「协作·会话类别(10-01)」整条**作废**(写「四类:主/协作/唤醒/跟进」,现行只三类=主/任务/检查,唤醒·跟进·队列上报**已整套退役**;证据=`session-mechanism/SKILL.md:3`、`:113`、`references/architecture.md:60`)—— 全篇唯一会**误导开工动作**的一条。 ② 第 54 行工作区路径 `E:/ProgramData/AIProject/aliyun-dsh-server` **不存在**(真身 `ai1net-dsh-server`)。 ③ 第 37 行死指针 `tmp/wb-phone/asar-peek.mjs`(文件不存在,且 tmp 必然被清)。 ④ 该档自相矛盾:第 25 行已是 10-05 新口径,第 23 行还停在 10-01 旧口径。 ## 仓搬迁第 1 步:平台源码 `dsh_ai1net_server.git` → 新空仓 `dsh_shenxian.git`(2026-10-10 23:05,**已完成并双向验证**) 用户令(原话,纠正过我两次):「先把 `git@ssh.alotbuy.com:admin/dsh_ai1net_server.git` 内容 **同步到** `git@ssh.alotbuy.com:admin/dsh_shenxian.git` 中别搞错了」。 - **方向核准**(用户第一次说错时我先做了取证,避免推错方向):源=`dsh_ai1net_server.git`(平台源码,顶层 `src/`/`web/`/`package.json`/`Dockerfile`,59 提交,tip `e6207aa`); 目标=`dsh_shenxian.git`(**空仓** —— `ls-remote` 无输出且无 error;不存在的仓会报 `Cannot find repository`,两者可区分)。 - **推法**:`git push "git@ssh.alotbuy.com:admin/dsh_shenxian.git" backup-dsh_ai1net_server-master:refs/heads/master` ⇒ `[new branch] → master`。 - **验证(从目标仓取回复核,不看推送回显)**:tip `e6207aa` / tree `5324f1fb8bb0dba436a30a13ca98f1b096b8db3e` / 提交数 59 / 顶层清单 `diff` 逐字一致 ⇒ **完全一致**。 - **安全网(保留)**:本仓本地 ref `backup-dsh_ai1net_server-master` + bundle `E:/ProgramData/AIProject/_repo-backups/dsh_ai1net_server-master-e6207aa.bundle`(4.5 MB,`git bundle verify` 通过,含完整历史)。 ### 🔴 仓角色现状(本轮实测) - `git@ssh.alotbuy.com:admin/dsh_ai1net_server.git`=平台源码仓(59 提交,tip 09-24);本机同一份历史也在 `D:\github\dsh_shenxian`(其 origin 指向旧地址 `git@work.alotbuy.com:maogeigei/dsh_shenxian.git`)。 - `git@ssh.alotbuy.com:admin/dsh_shenxian.git`=新建空仓,**现已装入平台源码**(=上一仓的镜像)。 - 本工作区 origin 仍是 `git@work.alotbuy.com:maogeigei/dsh_shenxian_workspace.git`(**主机密钥不符 ⇒ 推不通**)。 - 文档库 `D:\github\dsh_shenxian\dsh-server-docs` 推 `https://cnb.cool/maogeigei/dsh-shenxian.git`(HTTPS,通畅)。 ### 📋 第 2 步待办的真实规模(已摸清,未动) 本工作区待提交:**未跟踪 2,190 个文件(展开后)/删除 159/修改 61**。未跟踪大头: `归档/skills-git-旧线-20261007/dotgit-原样移出`(**1,037**,是 `.git` 内部对象**原样归档**)、`归档/skills-清理-20261007`(133)、`.workbuddy/memory`(126,按口径**该入库**)、`归档/技能包快照`(119)、 `.workbuddy/collab`(114,含 4.6 MB `logs/_collabd.log` + 一堆 `collabd.py.bak-*` ⇒ **运行态+部署副本,该忽略**)。 ⚠️ 现 `.gitignore` 覆盖了 `tmp/`/`待清理/`/`.workbuddy/{tmp,cache,backups}`/`*.db*`/`*.tar.gz`,**尚未覆盖 `.workbuddy/collab/`**。 ## 仓搬迁第 2 步:工作区推送 `dsh_ai1net_server.git`(2026-10-10 23:12,**已完成并双向验证**) 用户令:「挪过去之后,把当前工作区推送到 `git@ssh.alotbuy.com:admin/dsh_ai1net_server.git`,要排除临时文件之类无关紧要的文件夹和文件」。 ### 做了什么 - **origin 改指**:`git@work.alotbuy.com:maogeigei/dsh_shenxian_workspace.git`(旧,**主机密钥不符推不通**)→ `git@ssh.alotbuy.com:admin/dsh_ai1net_server.git`。 - **`.gitignore` 修 1 + 补 3 类**(未跟踪文件 **2,190 → 890**): ① 修 `归档/**/db-cwd归一-备份-*/` —— 原写绝对层级 `归档/db-cwd归一-备份-20260923/`,目录搬进 `归档/配置与备份/` 后**静默失效**,43 MB DB 备份又变未跟踪(**这类"路径写死 ⇒ 静默失效"值得单列成经验**); ② 嵌套 git 内部数据(`归档/内嵌git-20261008/`、`归档/skills-git-旧线-20261007/dotgit-原样移出/`); ③ 运行态与部署副本(`.workbuddy/collab/`、`.workbuddy/tools/`、`.workbuddy/.load-pending`、`.workbuddy/tmp-*`); ④ 备份件 `*.bak-*`。 - **提交** `c1b5e4d`:新增 514 / 修改 62 / 重命名 155 / 删除 4;提交后 `git status --porcelain` = **0**(工作区与仓库完全一致)。 - **推送**:`git push --force-with-lease=refs/heads/master:e6207aa… origin master` ⇒ `+ e6207aa...c1b5e4d master -> master (forced update)`(用 lease 锁住远端当时的值,避免盲推)。 ### 验证(从远端取回复核,⛔ 不看推送回显) 远端 tip=本地 tip=`c1b5e4d`|tree 双方均 `709427fa3634a5e2ab30b2c233601de1695bbe4e`|提交数均 33|顶层项均 15 且 `diff` 逐字一致。**源码仍完整保存在 `dsh_shenxian.git`(`e6207aa`,59 提交)。** ### 📊 体积盘点(工作区共 566 MB)—— 供"哪些能删"决策 - `tmp/` **419 MB**(15,464 文件;`probes/` 349 MB + `ws/` 62 MB + `out/` 4.4 MB + `bak/` 2.7 MB)—— **未入库 ⇒ 删了不能从 git 恢复**(但都是过程产物)。 - `归档/` 92 MB —— **大部分已入库**(技能包快照 43/skills-清理 133/迁移 51/文档整理 45 均已入 git)⇒ 删了可回滚;**未入库的三块删了不可回滚**:`配置与备份` 43 MB(DB 备份)、`内嵌git-20261008` 8.4 MB、`skills-git-旧线/dotgit-原样移出`。 - `.workbuddy/` 26 MB(`collab/` 16 MB,已忽略、可 redeploy)。 - `.git/` 21 MB|`交付物/` 3.8 MB|`待清理/` 3.4 MB(已忽略)|`docs/` 1.6 MB|`CODEBUDDY.md.bak-replycore-20261007-080319` 44 KB。 - 🔴 **安全网别删**:`E:/ProgramData/AIProject/_repo-backups/dsh_ai1net_server-master-e6207aa.bundle`(4.5 MB)+ 本地分支 `backup-dsh_ai1net_server-master`。 ## 🔴 浏览器又自动弹出 · 根因与处置(2026-10-10 23:16,已解决) ### 现象与真因 - 现场:9223 端口有 LISTENING;顺父链追到 `pythonw pid=37780`,命令行 = `"…pythonw.exe" "E:\ProgramData\AIProject\contentm_agent\bh_chrome_keepalive.py"`。 - 🔴 **直接证据(那份旧启动器自己的日志 `contentm_agent/tmp/_bh_chrome.log`)**: `[10-10 22:54:04] launched pid=43812` → `[23:01:36] chrome exited rc=0 ⇒ relaunch` → `[23:10:23] chrome exited rc=0 ⇒ relaunch` ⇒ 用户关了两次、被弹回两次。 - **两条叠加**:① 那份是**旧版**(没有 `rc=0 ⇒ 停手` 这条)⇒ Chrome 一退就**无条件重拉**; ② **脚本文件已被删、进程却还在** —— Python 启动时已把脚本读进内存,光删文件停不掉它。 - ⚠️ **父链读数不可作判据**:CIM 报父进程是 `svchost -k netsvcs -s Schedule`,看似任务计划程序, 但**pid 会复用**,且全量扫计划任务动作**没有一条**拉浏览器 ⇒ 该父链是误导(同 `pitfalls` 里"身份核验:pid 会复用"同族)。 ### 处置(已完成) - `Stop-Process` 结束 pid 37780(孤儿守卫)+ 结束 `bu-chatgpt-profile` 那个 chrome;**20 秒后复查:无残留守卫、无残留 chrome、9223 无 LISTENING**。 - 各工作区根**已无启动器副本**,只剩技能包里那份**新版**(带 `rc=0 ⇒ 停手`)。 ### 🔴 经验(值得进技能) 1. **「删掉脚本」≠「停掉进程」** —— 删文件后必须验进程还在不在(`Win32_Process` 查 cmdline)。 2. 查「谁在拉起 X」**认进程级证据**:cmdline + **它自己写的日志**(时间戳能直接对上关窗动作),⛔ 别拿 pid 父链当结论。 ## 两项执行收口(用户选 1A / 2B · 2026-10-10 23:26) ### 1A · 技能库提交并推送 - `E:\ProgramData\.workbuddy\skills` → 提交 `fd9c902`(5 个文件),推 `a04b2c0..fd9c902`;`git ls-remote` 复核远端已同步。 - **推前三件**:① 扫凭据(`neodata_token`/api-key/private key 等模式,5 个改动文件全绿);② `git fetch` 后比对(本地与远端同在 `a04b2c0`、**零删除**、已跟踪技能目录 **6 个**);③ `git ls-tree -d` 数目录(旧记忆写的"25 技能总仓"是 10-09 白名单收回之前的口径,现行 6 个)。 - ⚠️ 该仓 `core.autocrlf=true`(推送提示 `LF will be replaced by CRLF`)—— 与本工作区仓的 `false` 不同;仓库索引里存的是 LF,别的机器 checkout 会得 CRLF。 ### 2B · 清理(工作区 566 MB → **144 MB**) - **删**:`tmp/probes`(349M)/`tmp/ws`(62M)/`tmp/out`/`tmp/bak`/`tmp/shots`/`tmp/selftest`/`tmp/bak-replycore-20261006`/`tmp/bak-resident-rules-20261006`/ `tmp/_idle_hook_probe.jsonl`/`tmp/_pmb_shot.py`/`tmp/.session-log-guard.level.json`/`待清理/`/根下 `CODEBUDDY.md.bak-replycore-20261007-080319`。 - 🔴 **刻意保留(清理前先判"是不是运行中的进程在用")**:`tmp/supervise-inbox/` —— 常驻程序的**运行时 inbox**(`advance.md`/`board.json`/`check-agent.json`/`claims/`), 虽是 `init_workspace.py` 的骨架目录、但里面是**在跑的队列态**;`tmp/supervise-bg.log` + `tmp/board-serve.err.log` —— 正被运行中的进程写入。 ⇒ **经验:`tmp/` 里混着机制骨架目录,整目录一刀切会打断在跑的常驻。** - 另把已退出任务的 XML 备份留档在 `E:/ProgramData/AIProject/_repo-backups/bh-task-backup/`(原在 `tmp/`)。 - 收口:本工作区 `7cb3834` 已提交并推送,`git status` = 0(远端 `dsh_ai1net_server.git` 已同步)。 ## 状态层 MEMORY.md 瘦身(用户选 B · 2026-10-10 23:33) - **8,296 → 7,649 字符**(上限 7,650,达标);改前备份 `E:/ProgramData/AIProject/_repo-backups/MEMORY.md.bak-瘦身前-20261010-2332`(14,982 B)。 - **三处硬伤已修**: ① **会话类别**改成现行口径 —— **只有三类:主会话/任务会话/检查会话**(唤醒·跟进·队列上报**已整套退役**),并注明原写的「四类 + 开工建齐唤醒/协作/跟进」是**作废口径**(这是全篇唯一会让人**做错动作**的一条)。 ② **工作区行**:路径 `aliyun-dsh-server`(不存在)→ `ai1net-dsh-server`;origin 更新为 `ssh.alotbuy.com:admin/dsh_ai1net_server.git`(10-10 迁入,旧地址注明已弃用);另加一行记平台源码的两个安身处。 ③ **死指针**:`tmp/wb-phone/asar-peek.mjs` 删除(文件不存在、且指向必被清的 `tmp/`)。 - **另修**:技能总仓「25 个」→ 10-09 白名单 **6 个**;「四条小规矩」→ **五条**(名实相符);三条历史拍板行(承载两分/IM 线/D8)**合并成一行**并保留三条判据与指针。 - **压掉的细节全部改为指向** `MEMORY-全文-20261001.md`(活库四条做法/实例起不来修法/取数四坑的完整命令/常驻三件的依据)。 - **自检**:38 个判据关键词逐一比对**一个没丢**;改后整篇通读一遍、无明显断裂。 - ⚠️ **只剩 1 字符余量** —— 按「只减不增」,下次要加内容必须先减。