baseline: dsh 工作区基线快照（2026-09-10，全新历史起点）

本提交为 dsh_mcn_workshop 仓库的首个提交（旧仓 dsh_MCNProject 已停用），
完整固化 C:/Users/Administrator/.dsh 当前磁盘状态。

1) 临时数据清理：移出 sessions/(81M)、logs/、skill-backup-20260906/(14M)、
   scripts/__pycache__、storages/workspace.json.bak —— 合计 94M（.dsh 162M → 68M）
2) 凭据脱敏：.credentials.yaml（含明文 DEEPSEEK_API_KEY）移出 git 跟踪并加入
   .gitignore；mcn-data-insight/scripts/setup_redfox_key.py 中真实 key 示例改为占位符
3) .gitignore 增补 logs/、skill-backup-*/ 规则
4) 技能结构以当前磁盘状态为准：skills/ = mcn-short-video / impeccable / taste-skill /
   dsh-multi-user-migration；旧技能目录（mcn-dou-analysis、storyboard-prompt、
   short-video-script、browser-harness、mcn-data-insight）与
   profiles/web/node_modules/dsh-vision-router 本地已不存在，本提交记为删除

skills/mcn-short-video/subskills/browser-harness/docs/snap-linux-headless.md

@@ -0,0 +1,45 @@
+# Snap Chromium and browser-harness (Linux)
+
+## Why Snap browsers break CDP
+
+Ubuntu and several other distributions ship Chromium as a [Snap](https://snapcraft.io/) package. Snap runs apps in a confined environment. Chrome’s remote debugging endpoint must bind on the host network where the `browser-harness` daemon can reach it. Snap’s sandbox and filesystem layout commonly prevent that from working the way a normal `.deb` Chrome install does, so the harness may see no usable DevTools port even when Chromium appears to run.
+
+Symptoms: `browser-harness --doctor` shows Chrome running, but the daemon never attaches, or CDP handshake fails without an obvious cause. [Issue #191](https://github.com/browser-use/browser-harness/issues/191) discusses this class of setup problem.
+
+## Install Google Chrome natively (Ubuntu example)
+
+Use Google’s official package (AMD64), not the Snap:
+
+```bash
+wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb
+sudo apt install ./google-chrome-stable_current_amd64.deb
+```
+
+ARM or other architectures: download the matching package from [Google Chrome for Linux](https://www.google.com/chrome/linux/).
+
+## Point the harness at the native binary
+
+Put the non-Snap binary **first** in how you resolve “which Chrome,” so a Snap wrapper on `PATH` is not chosen by mistake.
+
+- **`BH_CHROME_PATH`** — preferred name in this project’s docs and `browser-harness --doctor` snap probe.
+- **`CHROME_PATH`** — honored the same way for compatibility with other tooling.
+
+Example for `~/.bashrc` or your environment:
+
+```bash
+export BH_CHROME_PATH=/usr/bin/google-chrome-stable
+```
+
+Then start Chrome from that path for Way 2 (`--remote-debugging-port=…`), or use Way 1 with a profile opened from the native install. Connection details are in [`install.md`](../install.md).
+
+## Verify
+
+```bash
+browser-harness --doctor
+```
+
+If a Snap binary is still the one detected on Linux, doctor prints a `[snap-detect]` warning. For a concise fix checklist:
+
+```bash
+browser-harness doctor --fix-snap
+```