pi2dsh 0.12.3 → 0.13.0

package/README.md

@@ -170,7 +170,9 @@ it work. **This is the list to trust.**
 | Plugin | What was exercised | Where | Example |
 |---|---|---|---|
 | [`@kassing/pi-vision`](https://www.npmjs.com/package/@kassing/pi-vision) | Image analysis delegated to a vision model; image-admission companion route; analysis injected into a text-only model's turn | CLI + web | [`vision-bridge`](examples/vision-bridge/) |
+| [`@crazygit/pi-codex-image-gen`](https://www.npmjs.com/package/@crazygit/pi-codex-image-gen) | ChatGPT/Codex OAuth → `gpt-image-2` generation; local reference-image upload through DSH approval; image edit; native attachment storage and inline Web rendering | CLI + web | [`codex-image-gen`](examples/codex-image-gen/) |
 | [`pi-btw`](https://www.npmjs.com/package/pi-btw) | `/btw <question>` as a real child session in DSH's subagent UI; `/btw-inject`; `/btw --save`; main thread stays clean | CLI + web | [`side-conversation`](examples/side-conversation/) |
+| [`pi-powerline-footer`](https://www.npmjs.com/package/pi-powerline-footer) | A terminal status line — model, thinking level, project, context usage — drawn into DSH's widget dock, colour included | web | [`presentation-surfaces`](examples/presentation-surfaces/) |
 | [`pi-vision-tool`](https://www.npmjs.com/package/pi-vision-tool) | Tool registration through a JSON-Schema shape DSH had to convert (`anyOf` → `oneOf`) | CLI + web | — |
 | [`pi-approval-guardian`](https://www.npmjs.com/package/pi-approval-guardian) | Every tool call reviewed by a second model before execution; allow and deny both observed | CLI (bare env) | — |
 | [`pi-hermes-memory`](https://www.npmjs.com/package/pi-hermes-memory) | Cross-session memory: written in one process, read back in a second, fresh one | CLI | — |
@@ -266,20 +268,24 @@ rather than a behaviour lands there:
 ┌──────────── DSH server (cordis) ────────────┐  ┌──────── DSH browser shell ────────┐
 │ services · waterfalls · durable events      │  │ dsh.client + exports "./client"   │
 │                                             │  │ slot registry (ui-slots)          │
-│ pi2dsh engine                               │  │   shell.overlay  ← frame-wide     │
-│   tools · commands · models · sessions      │  │   conversation.* · details · …     │
-│   subagent bridge ─────────────┐            │  │                                   │
-│   side-panel registry          │            │  │ pi2dsh browser half               │
-│     GET /pi2dsh/side-panel ────┼── own route┼──┼─▶ side-conversation panel         │
+│ pi2dsh engine                               │  │   shell.overlay  ← panel, pills   │
+│   tools · commands · models · sessions      │  │   session.header.utilities ← hdr  │
+│   subagent bridge ─────────────┐            │  │   input.dock ← widgets            │
+│   browser-state registry       │            │  │   composer.dock ← working/footer  │
+│     GET /pi2dsh/browser-state ─┼── own route┼──┼─▶ all four seats, one poller      │
 └────────────────────────────────┴────────────┘  └───────────────────────────────────┘
 ```
 
-The panel's data rides **this package's own route**, not DSH's typed Remote
-system: that one is a first-party, code-generated contract, and an out-of-tree
-plugin talking to its own UI should carry its own channel. Two host rules make
-the browser half load at all — the package must export `./package.json` (the
-host resolves the manifest by subpath), and the `./client` bundle is a
-closure-factory artifact, not plain ESM.
+The browser half's data rides **this package's own route**, not DSH's typed
+Remote system: that one is a first-party, code-generated contract, and an
+out-of-tree plugin talking to its own UI should carry its own channel. One
+payload per session serves every seat — the side-conversation panel, plus the
+Pi presentation surfaces (status, widget, header, footer, title and the
+working/thinking chrome), which are drawn in the host's own slot seats rather
+than re-implemented. Two host rules make the browser half load at all — the
+package must export `./package.json` (the host resolves the manifest by
+subpath), and the `./client` bundle is a closure-factory artifact, not plain
+ESM.
 
 The rules that keep it honest:
 
@@ -301,23 +307,71 @@ The rules that keep it honest:
 - **Verified, not asserted.** Every capability has a public-API contract test,
   and ships only after running end to end on a real DSH loop — CLI *and* web.
 
+## What this is teaching us about DSH
+
+pi2dsh is also an executable stress test of DSH's plugin architecture. Pi gives
+that test a useful workload: a large, already-used public plugin ABI rather than
+a set of examples invented to fit the host.
+
+The result so far is specific, not a thumbs-up/thumbs-down verdict:
+
+- DSH's public seams successfully carry whole capabilities: tools, commands,
+  model adapters, user questions, native child sessions and browser slots.
+- The pressure points appear when an out-of-repo plugin needs to extend an
+  existing capability *from the inside*: add a durable session-event type,
+  intercept the real provider request/response, control compaction before it
+  happens, or participate in trust before project resources load.
+- A working pi2dsh sidecar or alternate adapter is useful product behaviour,
+  but it is **not** counted as proof that the native DSH seam is complete.
+
+For example, a `pi-btw` answer is a real DSH child session — visible, resumable
+and continuable by the host. Pi custom entries are different: they still need a
+pi2dsh sidecar because an out-of-repo plugin cannot safely add a new event type
+to DSH's durable log. Likewise, a transport-owning Pi provider can register a
+native DSH route with its full compatibility profile, while the hand-configured
+`llm-pi-ai` schema still drops some wire-compatibility fields.
+
+The project follows one **[Pi → DSH architecture mapping standard](docs/architecture-mapping-standard.md)**.
+All 111 Pi surfaces belong to capability contracts, all 45 DSH subsystems belong
+to carrying mechanisms, and each capability contract maps to concrete public
+DSH seams. Real plugin runs reference those mappings and record the five-layer
+trace and five-grade result. The structured source of truth is
+[`architecture-ledger.json`](docs/architecture-ledger.json); it produces the
+**[theoretical architecture matrix](docs/architecture-mapping-matrix.md)**,
+**[real-plugin validation matrix](docs/plugin-validation-matrix.md)** and
+**[current architecture conclusions](docs/dsh-architecture-conformance.md)**.
+That makes both top-down status and per-plugin drill-down answerable from the
+same ledger. The current five DSH gap IDs are confirmed findings, not a claim
+of complete coverage. Current
+upstream reports include
+[#2708 — durable events for out-of-repo plugins](https://github.com/deepseek-ai/deepseek-harness/discussions/2708)
+and
+[#3076 — provider compat fields dropped by `llm-pi-ai`](https://github.com/deepseek-ai/deepseek-harness/discussions/3076).
+
 ## Pi capabilities on DSH
 
 Every surface a Pi package can touch, and what it maps onto. These tables are
 generated from the rules the bridge consults at runtime, so they cannot drift
 from the code.
 
+For pinned Pi 0.84.1, the generated catalog has **111 upstream-shaped rule
+rows**. The bridge also keeps one
+documented compatibility extension, `unregisterTool`; it appears on the tools
+detail page but is deliberately outside that total. Nested objects such as the
+session manager can expose several methods behind one row; the architecture
+audit states this boundary explicitly.
+
 <!-- capability-table:start -->
 | Area | Pi surfaces | Status |
 |---|---|---|
-| [Tools](docs/capabilities/tools.md) | 12 | 3 same semantics · 9 mapped, difference stated |
-| [Commands, flags, editor input](docs/capabilities/commands.md) | 13 | 13 mapped, difference stated |
+| [Tools](docs/capabilities/tools.md) | 11 | 2 same semantics · 9 mapped, difference stated |
+| [Commands, flags, editor input](docs/capabilities/commands.md) | 6 | 6 mapped, difference stated |
 | [Messages, context, agent loop](docs/capabilities/conversation.md) | 20 | 9 same semantics · 11 mapped, difference stated |
-| [Sessions & side conversations](docs/capabilities/sessions.md) | 24 | 6 same semantics · 18 mapped, difference stated |
+| [Sessions & side conversations](docs/capabilities/sessions.md) | 23 | 5 same semantics · 18 mapped, difference stated |
 | [Models, providers, credentials](docs/capabilities/models.md) | 15 | 1 same semantics · 11 mapped, difference stated · 3 not available |
-| [Asking the user, rendering](docs/capabilities/interaction.md) | 24 | 4 same semantics · 20 mapped, difference stated |
+| [Asking the user, rendering](docs/capabilities/interaction.md) | 32 | 5 same semantics · 27 mapped, difference stated |
 | [Project environment & resources](docs/capabilities/environment.md) | 4 | 1 same semantics · 1 mapped, difference stated · 2 not available |
-| **Total** | **112** | **24 same semantics · 83 mapped, difference stated · 5 not available** |
+| **Total** | **111** | **23 same semantics · 83 mapped, difference stated · 5 not available** |
 <!-- capability-table:end -->
 
 Plus **202 imported symbols** from Pi's three runtime packages
@@ -325,9 +379,10 @@ Plus **202 imported symbols** from Pi's three runtime packages
 shims — so a plugin's own Pi version pins never load. They are listed in
 [Imported Pi runtime symbols](docs/capabilities/imports.md).
 
-Each area page states two things for every surface: what it does on DSH, and
-**how it is built** — the DSH seam, service or waterfall the mapping runs on,
-so a claim here can be checked against the harness instead of trusted.
+Each area page states the Pi capability contract, the theoretical DSH mechanism
+and public seam, and the current implementation for every surface. Adding a
+surface without a capability assignment or theoretical mapping fails the docs
+check.
 
 Start at the [capability index](docs/capabilities/README.md). Machine-readable:
 `pi2dsh matrix --json`.
@@ -352,8 +407,9 @@ project trust is a host decision. See
 **The one gap we own:** plugin-drawn cards. Pi plugins can ship their own
 renderers; today those registrations are accepted but not invoked, so such a
 note appears as a native context-injection row — the content reaches you and
-the model, without the plugin's styling. DSH has the machinery for this; we
-have not built our client half yet.
+the model, without the plugin's styling. The client half exists and takes four
+seats (side-conversation panel, header, widget dock, working chrome) — the card
+renderers are what it does not draw yet.
 
 ## Examples
 
@@ -363,8 +419,11 @@ in one has actually been executed against a real DSH loop before landing.
 | Example | What you get |
 |---|---|
 | [`vision-bridge`](examples/vision-bridge/) | A text-only model answers questions about images — CLI and web, probe images included |
+| [`codex-image-gen`](examples/codex-image-gen/) | Generate and edit images with a ChatGPT/Codex subscription; DSH approval and inline result included |
 | [`side-conversation`](examples/side-conversation/) | `/btw <question>` runs a side thread in DSH's native subagent UI; your main conversation stays clean |
-| [`gateway-compat`](examples/gateway-compat/) | Private / domestic / proxy gateways that reject the `developer` role: why reasoning 400s, and how a Pi provider plugin gets past it (fake-endpoint probe included) |
+| [`presentation-surfaces`](examples/presentation-surfaces/) | A real plugin's terminal chrome (`pi-powerline-footer`) in DSH's web seats, plus which of the top-50 Pi plugins draw at all |
+| [`subscription-login`](examples/subscription-login/) | Use a ChatGPT / Claude / Copilot / Kimi subscription as a DSH model: `/login`, then the route and credential appear on their own |
+| [`gateway-compat`](examples/gateway-compat/) | Private / domestic / proxy gateways that reject the `developer` role: why reasoning 400s, and how a Pi provider plugin gets past it (recording proxy included, so you can read the exact request body we send) |
 | [`custom-gateways`](examples/custom-gateways/) | Add any OpenAI-compatible gateway the official DSH way, and every Pi plugin sees it |
 
 ## Other tools
@@ -384,6 +443,7 @@ pnpm verify                 # typecheck + contract tests + packaging
 pnpm audit:community        # static screening over the top-50 corpus
 pnpm test:community         # deep runtime + official plugin-manager + e2e
 DEEPSEEK_API_KEY=… pnpm test:live    # real-model acceptance (key from env only)
+CODEX_AUTH_FILE=… pnpm test:codex-image # real OAuth generation + reference edit + Web pixels
 ```
 
 Acceptance evidence per capability: [docs/acceptance.md](docs/acceptance.md).

package/README.zh.md

@@ -152,7 +152,9 @@ Web 里**直接粘图**——哪怕你的主模型是纯文本的。DSH 正常
 | 插件 | 验证了什么 | 在哪验的 | 示例 |
 |---|---|---|---|
 | [`@kassing/pi-vision`](https://www.npmjs.com/package/@kassing/pi-vision) | 图片委托给视觉模型；贴图伴生路由；分析结果注入纯文本模型的这一轮 | CLI + Web | [`vision-bridge`](examples/vision-bridge/) |
+| [`@crazygit/pi-codex-image-gen`](https://www.npmjs.com/package/@crazygit/pi-codex-image-gen) | ChatGPT/Codex OAuth 调 `gpt-image-2` 生图；本地参考图走 DSH 审批后上传；编辑图片；原生附件存储并在 Web 内直接显示 | CLI + Web | [`codex-image-gen`](examples/codex-image-gen/) |
 | [`pi-btw`](https://www.npmjs.com/package/pi-btw) | `/btw <问题>` 跑成 DSH 子代理界面里的真子会话；`/btw-inject`；`/btw --save`；主会话保持干净 | CLI + Web | [`side-conversation`](examples/side-conversation/) |
+| [`pi-powerline-footer`](https://www.npmjs.com/package/pi-powerline-footer) | 终端状态条（模型、思考档位、项目、上下文用量）画进 DSH 的 widget dock，带颜色 | Web | [`presentation-surfaces`](examples/presentation-surfaces/) |
 | [`pi-vision-tool`](https://www.npmjs.com/package/pi-vision-tool) | 工具注册，且带一个 DSH 需要转换的 JSON Schema 形状（`anyOf` → `oneOf`） | CLI + Web | — |
 | [`pi-approval-guardian`](https://www.npmjs.com/package/pi-approval-guardian) | 每次工具调用先由第二个模型审批；放行与拒绝两条路都看到了 | CLI（裸环境） | — |
 | [`pi-hermes-memory`](https://www.npmjs.com/package/pi-hermes-memory) | 跨会话记忆：一个进程写入，另一个全新进程读回 | CLI | — |
@@ -234,18 +236,20 @@ DSH 有两半，桥也有两半。上面那根柱子是服务端；浏览器壳
 ┌──────────── DSH 服务端（cordis） ───────────┐  ┌──────── DSH 浏览器壳 ────────────┐
 │ 服务 · waterfall · durable 事件             │  │ dsh.client + exports "./client"   │
 │                                             │  │ slot 注册表（ui-slots）           │
-│ pi2dsh 引擎                                 │  │   shell.overlay  ← 跨框架浮层     │
-│   工具 · 命令 · 模型 · 会话                  │  │   conversation.* · details · …    │
-│   子代理桥 ───────────────────┐             │  │                                   │
-│   侧边浮层注册表               │             │  │ pi2dsh 浏览器半边                 │
-│     GET /pi2dsh/side-panel ───┼── 自有通路 ─┼──┼─▶ 侧边对话浮层                    │
+│ pi2dsh 引擎                                 │  │   shell.overlay  ← 浮层与 pill    │
+│   工具 · 命令 · 模型 · 会话                  │  │   header.utilities ← 头部文本     │
+│   子代理桥 ───────────────────┐             │  │   input.dock ← widget             │
+│   browser-state 注册表        │             │  │   composer.dock ← working/底部    │
+│     GET /pi2dsh/browser-state┼── 自有通路 ─┼──┼─▶ 四个座位，共用一个轮询           │
 └───────────────────────────────┴─────────────┘  └───────────────────────────────────┘
 ```
 
-浮层的数据走**本包自己的路由**，不走 DSH 的 typert Remote 体系——那是一等公民的
-代码生成契约，仓外插件跟自己的 UI 说话就该自带通道。另外两条宿主规则决定浏览器
-半边能不能被装载：包必须导出 `./package.json`（宿主按子路径解析清单），`./client`
-产物必须是闭包工厂格式而不是普通 ESM。
+浏览器半边用的数据走**本包自己的路由**，不走 DSH 的 typed Remote 体系——那是
+一等公民的代码生成契约，仓外插件跟自己的 UI 说话就该自带通道。一个会话一个
+payload，喂给所有座位：侧边对话浮层，以及 Pi 的呈现面（status、widget、header、
+footer、title、working/thinking 类），都画在宿主自己的 slot 座位里，而不是再造
+一套。另外两条宿主规则决定浏览器半边能不能被装载：包必须导出 `./package.json`
+（宿主按子路径解析清单），`./client` 产物必须是闭包工厂格式而不是普通 ESM。
 
 保证它靠谱的几条标准：
 
@@ -262,31 +266,70 @@ DSH 有两半，桥也有两半。上面那根柱子是服务端；浏览器壳
 - **验证过才算数。** 每项能力都有公开 API 契约测试，并且必须在真实 DSH loop 上
   端到端跑通——CLI **和** Web 双端——才会发布。
 
+## 这件事正在检验 DSH 什么
+
+pi2dsh 同时也是一套会执行的 DSH 插件架构压力测试。Pi 提供的不是为了迎合 DSH
+现编的几个 demo，而是一套已经被大量真实插件用过的公开 ABI，所以它很适合回答：
+DSH 所说的“能力由插件自由组合”，到底走到了哪一步。
+
+目前的结论不是简单的“好”或“不好”，而是边界已经很清楚：
+
+- DSH 对**替换一整项能力**的公开 seam 是成立的：工具、命令、模型 adapter、用户
+  提问、原生子会话和浏览器 slot 都已经承接住真实 Pi 能力。
+- 压力集中在**从内部扩展已有能力**：仓外插件新增一种持久会话事件、拦截真正发出的
+  provider 请求/响应、在压缩发生前改变决定、在项目资源加载前参与 trust。
+- pi2dsh 用 sidecar 或另一条 adapter 把功能绕通，对用户有价值，但**不能算 DSH
+  原生架构已经承接成功**。我们会把“功能可用”和“宿主 seam 完整”分开记。
+
+一个容易说错的例子：`pi-btw` 的回答已经是真正的 DSH child session，宿主能打开、
+续聊和恢复；sidecar 存的是 Pi 自定义 entry 等 DSH 仓外插件目前无法写进原生日志的
+事实，不是把整个子会话伪造了一遍。模型侧也一样：自带 transport 的 Pi provider
+可以注册成原生 DSH route，并保留完整 compat；但手写 `llm-pi-ai` 配置时，部分
+wire 兼容字段仍会被 schema 丢掉。
+
+项目采用一套统一的 **[Pi → DSH 架构映射标准](docs/architecture-mapping-standard.md)**：
+111 条 Pi 接口先归入能力契约，DSH 的 45 个模块归入承载机制，再建立到具体公开 seam
+的理论映射；真实插件只引用这些映射，记录五层流转和五级结果。结构化事实保存在
+[`architecture-ledger.json`](docs/architecture-ledger.json)，由同一份总账生成
+**[理论架构矩阵](docs/architecture-mapping-matrix.md)**、
+**[真实插件验证矩阵](docs/plugin-validation-matrix.md)** 和
+**[当前架构结论](docs/dsh-architecture-conformance.md)**。这样既能从总体看到已经适配的
+能力，也能从任一插件下钻到它用了哪些 Pi 能力、落到哪些 DSH 机制、实际达到哪一级。
+当前 5 个 DSH 缺口是已经坐实的发现，**不是已经完成全覆盖**。
+当前已向上游提交的实证包括
+[#2708：让仓外插件安全写持久事件](https://github.com/deepseek-ai/deepseek-harness/discussions/2708)
+和
+[#3076：`llm-pi-ai` 丢 provider compat 字段](https://github.com/deepseek-ai/deepseek-harness/discussions/3076)。
+
 ## Pi 的开放能力在 DSH 上怎么落
 
 Pi 包能碰到的每一个面，以及它落到 DSH 的什么位置。下面这些表是从桥在运行时真正
 查的那份规则生成的，所以不会和代码脱节。
 
+针对固定的 Pi 0.84.1，当前生成目录有 **111** 条上游形状的规则行。桥另外保留了一个
+兼容扩展 `unregisterTool`；它会出现在工具细表中，但明确不计入这个总数。
+`sessionManager` 等嵌套对象仍可能用一行代表多个方法，架构审计会明确写出这层边界。
+
 <!-- capability-table:start -->
 | 能力域 | Pi 面数 | 状态 |
 |---|---|---|
-| [工具](docs/capabilities/tools.md) | 12 | 3 语义一致 · 9 已映射并写明差异 |
-| [命令、flag、编辑器输入](docs/capabilities/commands.md) | 13 | 13 已映射并写明差异 |
+| [工具](docs/capabilities/tools.md) | 11 | 2 语义一致 · 9 已映射并写明差异 |
+| [命令、flag、编辑器输入](docs/capabilities/commands.md) | 6 | 6 已映射并写明差异 |
 | [消息、上下文、agent 循环](docs/capabilities/conversation.md) | 20 | 9 语义一致 · 11 已映射并写明差异 |
-| [会话与侧边对话](docs/capabilities/sessions.md) | 24 | 6 语义一致 · 18 已映射并写明差异 |
+| [会话与侧边对话](docs/capabilities/sessions.md) | 23 | 5 语义一致 · 18 已映射并写明差异 |
 | [模型、provider、凭证](docs/capabilities/models.md) | 15 | 1 语义一致 · 11 已映射并写明差异 · 3 不提供 |
-| [向用户提问与渲染](docs/capabilities/interaction.md) | 24 | 4 语义一致 · 20 已映射并写明差异 |
+| [向用户提问与渲染](docs/capabilities/interaction.md) | 32 | 5 语义一致 · 27 已映射并写明差异 |
 | [项目环境与资源](docs/capabilities/environment.md) | 4 | 1 语义一致 · 1 已映射并写明差异 · 2 不提供 |
-| **合计** | **112** | **24 语义一致 · 83 已映射并写明差异 · 5 不提供** |
+| **合计** | **111** | **23 语义一致 · 83 已映射并写明差异 · 5 不提供** |
 <!-- capability-table:end -->
 
 另外还有 Pi 三个运行时包（`pi-coding-agent`、`pi-tui`、`pi-ai`）的 **202 个
 导入符号**，由 vendored 或 headless shim 提供——所以插件自己钉的 Pi 版本永远不会
 被加载，清单见[导入的 Pi 运行时符号](docs/capabilities/imports.md)。
 
-每个能力域页面对每一个面都写两件事：它在 DSH 上做什么，以及**它是怎么实现的**
-——这条映射落在哪个 DSH seam、服务或 waterfall 上，好让读者能对着 harness 核实，
-而不是只能选择相信。
+每个能力域页面对每一个面都写清它属于哪个 Pi 能力契约、理论上应落到哪个 DSH 承载
+机制与公开 seam、当前代码实际上如何实现。新增接口如果没有能力归属或理论映射，文档
+检查会直接失败。
 
 从[能力索引](docs/capabilities/README.md)开始看。机器可读版：`pi2dsh matrix --json`。
 
@@ -304,7 +347,8 @@ Codex、Anthropic、GitHub Copilot、Kimi Code）内置。凭证按 Pi 的 `auth
 
 **我们自己欠的那一块**：插件自绘卡片。Pi 插件可以自带渲染器，目前这类注册我们接
 下来但不调用，所以这种笔记会显示成原生的上下文注入行——内容你和模型都拿得到，
-只是没有插件自己的样式。DSH 是提供这套机制的，我们的客户端半边还没做。
+只是没有插件自己的样式。客户端半边已经在并占着四个座位（侧边对话浮层、头部、
+widget 区、working 区）——卡片渲染器正是它还没画的那部分。
 
 ## 示例
 
@@ -314,8 +358,11 @@ loop 上实际跑过才会进来。
 | 示例 | 你能得到什么 |
 |---|---|
 | [`vision-bridge`](examples/vision-bridge/) | 纯文本模型回答图片问题——CLI 与 Web 双端，附探针图 |
+| [`codex-image-gen`](examples/codex-image-gen/) | 用 ChatGPT/Codex 订阅生图和改图，包含 DSH 上传审批与 Web 内直接显示结果 |
 | [`side-conversation`](examples/side-conversation/) | `/btw <问题>` 在 DSH 原生子代理界面里开一条侧边线程，主会话保持干净 |
-| [`gateway-compat`](examples/gateway-compat/) | 私有 / 国内 / 代理网关拒收 `developer` 角色：为什么一开推理就 400，以及用 Pi provider 插件怎么绕过去（附假端点探针） |
+| [`presentation-surfaces`](examples/presentation-surfaces/) | 真插件（`pi-powerline-footer`）的终端界面画进 DSH Web 座位，附 top50 里哪些 Pi 插件会画界面 |
+| [`subscription-login`](examples/subscription-login/) | 用 ChatGPT / Claude / Copilot / Kimi 订阅账号当 DSH 的模型：`/login`、登录后自动建路由与凭证 |
+| [`gateway-compat`](examples/gateway-compat/) | 私有 / 国内 / 代理网关拒收 `developer` 角色：为什么一开推理就 400，以及用 Pi provider 插件怎么绕过去（附透传录制代理，能看到我们真正发出去的请求体） |
 | [`custom-gateways`](examples/custom-gateways/) | 按 DSH 官方方式接任何 OpenAI 兼容网关，每个 Pi 插件都能看到它 |
 
 ## 其它工具
@@ -335,6 +382,7 @@ pnpm verify                 # 类型检查 + 契约测试 + 打包检查
 pnpm audit:community        # 前 50 静态筛查
 pnpm test:community         # 深度运行时 + 官方插件管理器 + e2e
 DEEPSEEK_API_KEY=… pnpm test:live    # 真实模型验收（key 只从环境读）
+CODEX_AUTH_FILE=… pnpm test:codex-image # 真 OAuth 生图 + 参考图编辑 + Web 像素显示
 ```
 
 逐项能力的验收证据：[docs/acceptance.md](docs/acceptance.md)。

package/dist/{analyzer-2Nx5XYOA.mjs → analyzer-CXNbeBAe.mjs}

@@ -1,5 +1,5 @@
 
-import { c as PI_AI_PACKAGES, f as ruleForApi, g as ruleForUiContextProperty, h as ruleForHostImport, l as PI_CODING_AGENT_PACKAGES, m as ruleForEvent, p as ruleForContextProperty, u as PI_TUI_PACKAGES } from "./mcp-config-Cjae0vot.mjs";
+import { c as PI_AI_PACKAGES, f as ruleForApi, g as ruleForUiContextProperty, h as ruleForHostImport, l as PI_CODING_AGENT_PACKAGES, m as ruleForEvent, p as ruleForContextProperty, u as PI_TUI_PACKAGES } from "./mcp-config-CZepacin.mjs";
 import { builtinModules } from "node:module";
 import { lstat, readFile, readdir, stat } from "node:fs/promises";
 import { basename, dirname, extname, join, relative, resolve } from "node:path";
@@ -623,4 +623,4 @@ async function analyzePackage(pkg) {
 //#endregion
 export { analyzePackage };
 
-//# sourceMappingURL=analyzer-2Nx5XYOA.mjs.map
+//# sourceMappingURL=analyzer-CXNbeBAe.mjs.map