用途：当 AI 智能体运行在 Windows 主机、且 shell 位于 WSL 之外（Bash 工具为 Git Bash/MSYS，uname -s 显示 MINGW64…/MSYS…，或处于 PowerShell/cmd）时，需要执行任何 docker / docker compose 命令，就应使用本技能。若 shell 已在 WSL 内（uname -s 显示 Linux、原生路径 /home/<user>/...），则不适用，可直接运行 docker。
问题根源：Windows 上 Docker Desktop 的守护进程运行在 WSL2 虚拟机中。因此所有 docker 命令（run、build、exec、pull、push、volume、network、inspect、compose 等）都应在 WSL 内、针对原生 Linux 路径执行，不要从 Windows shell 执行，尤其在映射的网络/SMB 盘（Z:、UNC \host\share）上。
为何重要：从 Windows shell 驱动 Docker 且当前目录位于网络共享时，Docker Desktop 需把 Windows bind 路径（如 Z:\proj\config）转换为虚拟机路径。在 SMB/UNC 盘上这不可靠：可能重复路径段（如 …/user/user/proj/config），导致 Docker 挂载错误、空目录，并把缺失的 bind 源自动创建为空目录。容器期望的文件（init.sql、配置文件）会变成目录，报错 could not read from input file: Is a directory。编辑器仍通过共享写入正确路径，于是主机与容器视图悄然不一致。这不是 Docker 缓存问题，也不是“单文件 bind 挂载脆弱”的问题（单文件 bind 从 WSL 使用正常），根因是从 Windows/SMB 而非 WSL 操控 Docker。
规则：通过 WSL 在原生 Linux 路径下运行任何 Docker 命令，例如： wsl.exe -e bash -lc "cd /home/<user>/<project> && docker compose up -d" wsl.exe -e bash -lc "docker ps" wsl.exe -e bash -lc "docker build -t myimg /home/<user>/<project>" 并把项目放在 WSL 发行版原生可见的 Linux 文件系统（/home/<user>/...），而不是通过 Windows 盘符访问。
诊断与修复：参考资料 references/diagnosis-and-fix.md 说明如何检查挂载路径、比较主机与容器视图、清理幽灵 bind 目录。其他细节暂未提供。