dsh_ai1net_server/.workbuddy/memory/2026-10-10.md

# 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 就清掉了**；`<Triggers/>` 为空 ⇒ **挂了 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 原三步带占位符（`<技能包>`／`<py>`／`<工作区根>`），第 ③ 步只有散文没有命令 ⇒ 每次都要现推。

### 改法
- `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` → `[email protected]:admin/workbuddy_skills.git`（**SSH 通**）；待提交 **5 个文件**（全是本轮改的）。
- **本工作区** `E:\ProgramData\AIProject\ai1net-dsh-server` → 现 origin＝`[email protected]: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` → 取走 `[email protected]:maogeigei/dsh_shenxian.git`、**推送走 `https://cnb.cool/maogeigei/dsh-shenxian.git`**（HTTPS，不受主机密钥影响）。待提交 **174**。
- 🔴 **用户点名的 `[email protected]: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，**已完成并双向验证**）

用户令（原话，纠正过我两次）：「先把 `[email protected]:admin/dsh_ai1net_server.git` 内容 **同步到** `[email protected]: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 "[email protected]: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` 通过，含完整历史）。

### 🔴 仓角色现状（本轮实测）
- `[email protected]:admin/dsh_ai1net_server.git`＝平台源码仓（59 提交，tip 09-24）；本机同一份历史也在 `D:\github\dsh_shenxian`（其 origin 指向旧地址 `[email protected]:maogeigei/dsh_shenxian.git`）。
- `[email protected]:admin/dsh_shenxian.git`＝新建空仓，**现已装入平台源码**（＝上一仓的镜像）。
- 本工作区 origin 仍是 `[email protected]: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/`**。