dsh-ocgw — DSH 薄插件（OCGo Gateway 适配壳）

DSH 端极简薄插件：指向 ocgo-gateway、注入 gateway-key、注入对话标识、/ocgw 薄命令、精简自动推送、handoff。

纯业务核心（config/gatewayClient/handoff/sessionWorkspace/display）不做本地副本——统一复用 extensions/shared-ocgw/（与 pi-ocgw 共用同一份核心）。

详见 docs/：

• REQ.md — 实现要求
• FEATURES.md — 功能说明
• IMPLEMENT.md — 实现步骤

构建机制（重要：复制-构建-删除）

这是本插件的特殊之处，务必理解，否则会困惑为什么 src/core 时有时无。

DSH 插件（cordis）通过 main: lib/index.js 加载编译产物（不像 pi 能直跑 TS 源码）； 而 tsc 的 rootDir=src 要求源码在 src/ 内。但共享核心在 extensions/shared-ocgw/ （本插件目录之外），直接 import 会触发 TSc 的 rootDir 报错（文件不在 rootDir 下）。

解法——「复制-构建-删除」闭环（scripts/build.mjs）：

prepare  复制 shared-ocgw 的 6 个核心文件 → src/core/（写 .shared-core-copied 标记）
compile  tsc -p tsconfig.json → lib/（src 含复制进来的 core）
cleanup  编译后（无论成败）删除 src/core 复制体

cd extensions/dsh-ocgw
npm run build        # prepare → tsc → cleanup 完整闭环，产物在 lib/
npm run prepare-core # 仅复制（typecheck 用）

为什么一定要删复制体：保持共享核心单一来源。核心只存在 extensions/shared-ocgw/， dsh-ocgw 源码不含副本——避免两份核心漂移（改核心只改 shared-ocgw，两边插件同步生效）。 src/core 只是构建时的临时产物，构建完不存在。

⚠️ npm run typecheck 前需先 npm run prepare-core（否则 src/core 不存在，import 报错）。 或用 npm run build 一步到位。

与共享核心的关系

extensions/
├── shared-ocgw/        # 共享纯核心（单一来源，零宿主依赖）
│   ├── config.ts       # 参数化宿主路径(pi/dsh)
│   ├── gatewayClient.ts / handoff.ts / sessionWorkspace.ts / display.ts
│   └── index.ts
├── pi-ocgw/            # Pi 端（直接 re-export 共享核心 + pi 专属 cacheOptimizer/developerCompat）
└── dsh-ocgw/           # DSH 端（构建时复制共享核心进 src/core 参与编译，post 删除）

配置

// ~/.dsh/ocgo-gateway.json（权限 600；DSH 宿主路径，区别于 pi 的 ~/.pi/agent/ocgo-gateway.json）
{
  "gatewayBase": "http://127.0.0.1:8130/v1",
  "gatewayKey": "ocgo_xxx"
}

命令

/ocgw setup <url> <key>   设网关地址 + gateway-key
/ocgw whoami / status / quota / cost / bind / unbind / default
/ocgw notify <秒>         自动推送精简限额间隔（默认15s，0关闭）
/ocgw handoff / resume    上下文交接