@ckanner/flywheel 0.28.1 → 0.28.3

package/CHANGELOG.md

@@ -1,6 +1,23 @@
 # Changelog
 
-## Unreleased
+## 0.28.3
+
+- 发行复核补齐 DSH 清理回执保护：worker 已启动但缺少可信终态时记录清理未确认，保留协议诊断并停止本次运行，避免自动重试重叠执行；启动前拒绝不误判为遗留进程。
+
+- 将 DeepSeek Flash 默认与显式 subscriptions 预设改为 DSH 已登录的 `deepseek-account`，复用同一 DSH home 的账号授权；保留用户明确配置的 `deepseek-official` API Key。已有配置不随升级改写，新增从已发布 0.28.2 API 预设预览、备份并迁移到账号的回归。
+- 将 DSH 账号未登录、token 失效及精确的账号退出取消事件归入既有 AUTH，账号额度不足保持 QUOTA，保留原始诊断并说明恢复方式；结构化码贯穿 Go 消费端，进程失败与清理未知优先，不把认证错误当成可重试服务器故障。默认预设没有 API 后备，保留用户显式配置的后备策略。
+- 桌面控制入口省略项目目录时读取 DSH `workingDirectory.get(session)` 的当前目录，跟随会话切换 worktree；显式目录优先，读取失败在 Go 派发前返回可确认错误，不回退到过时的 `session.header.cwd`。
+- 修正 DSH `/flywheel-*` 与 Kimi `/skill:flywheel-*` 的宿主语法区别，说明 Skill 主流程无需预填面板，以及任务资料目录和项目目录的作用。记录各模型实际支持的推理等级、high 基线依据和未做项目 A/B 的边界；不自动调整档位。
+
+统一六包版本为 0.28.3。升级保留用户配置；采用新的账号预设需要显式预览并应用迁移。发行完成以六包 registry 完整性、安装和 latest 复核为准。
+
+## 0.28.2
+
+- 修复 macOS 迁移故障测试的平台假设：使用路径解析 I/O 注入缝稳定验证无法解析相对全局路径时的无写入行为；生产路径解析仍使用 `filepath.Abs`，不跳过测试或放宽 100% 覆盖率门禁。
+
+- 新增显式 `config migrate --preset subscriptions`：预览并备份更新实际生效的旧模型配置，保留非模型设置，清理旧 Z.AI 后备路径，采用 ChatGPT／Kimi Code K3.1 Pro／DeepSeek Flash 与约定的 thinking；安装报告明确升级会保留旧配置。Kimi 缺省模型同步为 K3.1 Pro。
+- 新模板与显式迁移使用 `permissions.mode: full-access`，通过 DSH／Codex Pro 公开接口落实所有阶段完全权限和无需逐步确认；旧文件缺省保留 role-based。编排、预检、恢复身份与实际权限回执一致，保留冻结验收、候选身份和进程清理门禁。
+- 将 UI 路径和排障文案改为“任务资料目录”“项目目录（可选）”“检查安装与配置”“检查 DSH 接入”，说明任务由对话助手准备、项目目录可沿用会话、检查不发送模型消息，配置表展示可理解的权限名称。
 
 ## 0.28.1
 

package/README.en.md

@@ -4,7 +4,7 @@ English | [简体中文](README.md)
 
 Flywheel turns reviewed software requirements into bounded coding tasks with explicit acceptance criteria. A deterministic Go engine runs Plan, Execute, Review, and verification loops. Models propose plans, implement changes, and review candidates; the engine owns state, retries, budgets, workspaces, verification, local Git delivery, and stopping.
 
-This documentation describes the **0.28.1 implementation**. The desktop integration targets the interfaces checked against **DSH Mac 0.2.1-rc.5**. Source changes and GitHub releases do not establish npm availability: check the registry before installing a version. Offline test results also do not establish that a user's Mac, desktop permissions, account, or selected model works.
+This source targets **0.28.3**, including account defaults, account-error handling, and the current session directory. Check the npm registry before installing; merging source does not update an installed package. The desktop integration targets interfaces checked against **DSH Mac 0.2.1-rc.5**. Check the registry before installing a version. Offline tests do not establish a live user Mac, account, or model pass.
 
 ## Install
 
@@ -24,7 +24,7 @@ npx -y @ckanner/flywheel@latest install
 
 Add `--json` for a structured installation result. The installer selects one exact version for the CLI, platform binary, workers, and DSH plugin; installs the ten bundled skills; preserves existing configuration and modified skills; and records a managed desktop launcher. Binary packages cover macOS and Linux on arm64 and amd64.
 
-`ok:true` means installation succeeded. `ready:false` means local diagnostics still found a blocker; these values can occur together. The installer does not install or log in to Kimi/Codex, configure API credentials, or prove model access. Plain `npm install --global @ckanner/flywheel` only installs package files; run `flywheel setup --no-global` afterward to perform explicit user setup.
+`ok:true` means installation succeeded. `ready:false` means local diagnostics still found a blocker; these values can occur together. The installer does not install or log in to Kimi/Codex or prove model access. Current source defaults reuse the signed-in DeepSeek account in DSH; API-key credentials are needed only for an explicitly selected API provider. Plain `npm install --global @ckanner/flywheel` only installs package files; run `flywheel setup --no-global` afterward to perform explicit user setup.
 
 Follow [Getting started](docs/en/getting-started.md) for prerequisites, desktop versus SDK setup, a runnable first task, and recovery. Use `--prefix "$HOME/.local"` if you need a user-owned npm prefix.
 
@@ -35,18 +35,22 @@ These bindings are editable starting points, not a model ranking or a performanc
 | Stage or route | Harness | Provider or channel | Model | Requested thinking |
 |---|---|---|---|---|
 | Plan | Kimi CLI | `kimi-subscription` | `kimi-code/k3.1-pro` | `high` |
-| Execute: `default` | DSH SDK | `deepseek-official` | `deepseek-flash` | `high` |
+| Execute: `default` | DSH SDK | `deepseek-account` | `deepseek-flash` | `high` |
 | Execute: `frontend` | Kimi CLI | `kimi-subscription` | `kimi-code/k3.1-pro` | `high` |
 | Execute: `hard` | Codex Pro machine API | `chatgpt-subscription` | `gpt-6.1-sol` | `high` |
-| Review | DSH SDK | `chatgpt` | `gpt-6.1-sol` | `high`, read-only |
-| Judge | DSH SDK | `chatgpt` | `gpt-6-astra` | `high`, read-only |
-| Intake, optional | DSH SDK | `deepseek-official` | `deepseek-flash` | `low` |
+| Review | DSH SDK | `chatgpt` | `gpt-6.1-sol` | `high` |
+| Judge | DSH SDK | `chatgpt` | `gpt-6-astra` | `high` |
+| Intake, optional | DSH SDK | `deepseek-account` | `deepseek-flash` | `low` |
 | Garden, optional | Kimi CLI | `kimi-subscription` | `kimi-code/k3.1-pro` | `high` |
 
 Initial requirement preparation is separate: `flywheel-new` runs in the host's current conversation and uses its selected model. Changing `loops.plan` does not change that conversation. The [workflow guide](docs/en/workflow.md) explains preparation model choices and the later engine loops.
 
 The default configuration has no automatic paid fallback across channels and no second judge. Flash's checked DSH effort values are `off`, `low`, `high`, and `max`; there is no `medium` in that adapter baseline. There is no default multimodal route: the current bridge has a text contract, so a model's vision capability alone does not establish attachment support.
 
+Seven high bindings and Intake low are an engineering baseline, without a project high/xhigh/max comparison. GPT supports xhigh/max; Kimi K3.1 Pro natively supports low/high/max. Hard execution and high-impact Judge are useful first xhigh evaluation candidates. See [Reasoning effort](docs/en/model-policy.md) for evidence and limits.
+
+The standard SDK already includes the DeepSeek account provider and account service. Under the same `DSH_HOME`, it shares the standard desktop account credential store without copying tokens or adding an API key. Desktop default-model selection does not control an independent SDK session, so Flywheel explicitly requests `deepseek-account` and `deepseek-flash`. Version 0.28.2 still selects the API provider; upgrade to 0.28.3 or later and use [explicit migration](docs/en/configuration.md#apply-the-subscription-preset-to-existing-configuration) to adopt the account default. Custom API-key configuration remains supported.
+
 ## Codex Pro uses the actual plugin runtime
 
 The hard route uses `harness: "codex-pro"`. Its worker directly imports the public `dsh-subagent-codex-pro/machine` API from the exact dependency **`dsh-subagent-codex-pro@0.8.0`**, using protocol 1. The plugin runs Codex app-server with the user's existing Codex installation and login. No parent DSH model is required to delegate the task again.
@@ -59,6 +63,8 @@ Existing configuration is preserved during upgrades. To adopt the new route, ins
 
 Use one task integration branch and worktree for a deliverable. Create it **before** preparing contracts with `flywheel-new`; keep the task directory inside that same worktree. The host or user creates this outer worktree. Flywheel then manages the inner packet workspaces.
 
+In DSH's composer, `/flywheel-new` invokes preparation and `/flywheel-run` invokes the run Skill after review. Kimi CLI uses `/skill:flywheel-new` and `/skill:flywheel-run`. The host loads these Skills and the assistant follows their CLI workflow. No panel fields need filling first.
+
 A normal workflow is:
 
 1. Prepare and review the Spec, task packets, frozen acceptance tests, and actual dry-run evidence in the task worktree.
@@ -80,7 +86,7 @@ Packet delivery is a **local Git operation**. After evidence matches the current
 
 ### Desktop task controls
 
-From `0.28.1`, the native **Flywheel** conversation view appears alongside Chat and Trajectory, preserving DSH's composer, model selector, and right sidebar. Version `0.28.0` uses the old composer popup; upgrade the CLI and desktop plugin to the same new version. Select a prepared task directory and its repository to inspect progress, intervention, effective models, and diagnostics, or explicitly start, refresh, or stop it.
+From `0.28.1`, the native **Flywheel** conversation view appears alongside Chat and Trajectory, preserving DSH's composer, model selector, and right sidebar. Version `0.28.0` uses the old composer popup; upgrade the CLI and desktop plugin together. **Task files directory** selects the prepared `docs/<slug>/`; **Project directory** is its project/integration worktree and may stay blank. From 0.28.3, Flywheel reads DSH's `workingDirectory.get(session)`, following session directory changes. Version 0.28.2 still uses the original header directory: explicitly fill the project path after switching worktrees. Configuration and diagnostics can omit the task; start, refresh, and stop require an existing task directory.
 
 The view retains session-scoped drafts while the host retains the session binding and shows snapshots with their refresh time. It does not discover tasks or poll automatically. An unconfirmed start/stop outcome requires a successful refresh of the same task before further mutations; closing or switching the view does not stop the independent engine. DSH's trajectory keeps its parent-session records, without automatically merging independent worker history. Desktop capabilities and SDK worker policy have separate scopes; see the [plugin guide](https://github.com/ckanner/flywheel/blob/main/plugins/dsh/README.en.md#use-the-desktop-controls).
 
@@ -91,7 +97,7 @@ L1 validates a packet; L2/L3 validate integration and user paths at milestone sc
 Keep these boundaries in mind:
 
 - **Worktrees isolate Git work, not process permissions.** Packet worktree creation can currently fall back to in-place execution. There is no engine option requiring isolation in every case. Skills check the recommended task location; direct CLI/GUI use does not execute those skill checks.
-- **Permissions depend on the harness.** DSH and Codex paths request explicit permissions. Kimi's current CLI integration does not provide an OS-level read-only or workspace sandbox guarantee.
+- **Permissions are explicit.** New templates and the subscription migration select `permissions.mode:full-access` for every stage, using DSH/Codex full access with approval never and native Kimi print auto. Existing configurations without this field retain role-based permissions. Kimi does not provide an OS confinement guarantee; task and acceptance identity checks remain enforced.
 - **Codex Pro's complete policy check is after the run.** The plugin checks model, directory, approval, and sandbox mode before a turn. Flywheel validates the full returned policy afterward, allowing the workspace and standard Codex temporary directories. Additional external write roots, enabled network access, or unconfirmed policy prevent acceptance. This check cannot prevent access already allowed by custom Codex configuration.
 - **Cleanup needs evidence.** A worker exiting does not prove that the plugin's separate app-server or guardian processes stopped. An unconfirmed cleanup result escalates and stops the run; inspect and resolve it before resuming.
 - **Unknown usage remains unknown.** Missing usage or monetary cost is not zero. Soft budgets report uncertainty; hard budgets stop when unknown usage makes the limit unverifiable.
@@ -106,6 +112,7 @@ The engine alone writes `state.json`, atomically with revision checks. Do not ed
 | [Getting started](docs/en/getting-started.md) | Install, configure, diagnose, run a small task, stop, and recover |
 | [Workflow](docs/en/workflow.md) | Preparation models, task and packet worktrees, Draft PRs, completion, and merge policy |
 | [Configuration](docs/en/configuration.md) | File precedence, profiles, providers, channels, Codex Pro, and diagnostics |
+| [Reasoning effort](docs/en/model-policy.md) | Supported levels, high baseline, evaluation candidates, and account-provider choice |
 | [Chinese documentation](README.md) | Default language and additional implementation detail |
 | [System design](https://github.com/ckanner/flywheel/blob/main/docs/design.md) (Chinese) | Authoritative design and invariants |
 | [DSH plugin](https://github.com/ckanner/flywheel/blob/main/plugins/dsh/README.en.md) / [protocol](https://github.com/ckanner/flywheel/blob/main/plugins/dsh/PROTOCOL.md) (protocol in Chinese) | Desktop control surface, workers, permissions, and lifecycle |

package/README.md

@@ -4,7 +4,7 @@
 
 Flywheel 用确定性 Go 引擎驱动 Plan、Execute、Review 和分层验收，把已经明确的需求变成有边界、可验证、可持久化的软件交付。模型负责规划、实现和评审；引擎负责状态、重试、预算、工作区、验收、提交与停止。
 
-当前 **v0.28.1 实施版**以 DSH Mac 桌面为入口：Kimi CLI 规划，DSH 原生 DeepSeek Flash 执行，DSH 原生 GPT 评审，较难的执行任务默认走 Codex Pro 插件的公开 machine API。DSH 插件提供控制面板、配置查看和安装预检；具名 model profiles 可复用于不同阶段，Go 仍是唯一状态所有者。设计依据见 [docs/design.md](docs/design.md)，仓库约束见 [AGENTS.md](AGENTS.md)。
+当前源码的统一发行目标为 **v0.28.3**，使用 DSH Mac 桌面为入口：Kimi CLI 规划，DSH 原生 DeepSeek Flash 执行，DSH 原生 GPT 评审，较难的执行任务默认走 Codex Pro 插件的公开 machine API。0.28.3 包含 DeepSeek 账号默认、账号错误分类与会话当前目录修复；安装前核对 npm registry，源码合并不会更新已安装的包。DSH 插件提供控制面板、配置查看和安装预检；具名 model profiles 可复用于不同阶段，Go 仍是唯一状态所有者。设计依据见 [docs/design.md](docs/design.md)，仓库约束见 [AGENTS.md](AGENTS.md)。
 
 **本教程适用于 0.28.0 及以后的完整 npm 发行版。** 安装前用 `npm view @ckanner/flywheel version` 确认 registry 的 latest 已更新到所需版本；源码合并或 GitHub Release 不代表 npm 已发行。旧 0.22.1 没有本教程使用的安装与 DSH 接口，当前发行状态见[发行记录](docs/releasing.md#3-失败恢复)。
 
@@ -22,7 +22,7 @@ npx -y @ckanner/flywheel@latest install
 
 Agent 可在同一命令后加 `--json`，读取一个结构化结果。安装器把本次解析到的**精确版本**的 CLI、对应平台 Go 二进制、DSH worker 和 Codex Pro worker（含精确版本的插件依赖）装到 npm 全局目录，安装 10 个内嵌 skills，再将同版本 DSH 插件注册到桌面 profile 并核对版本。无需下载压缩包、克隆源码或自行编译 Go。
 
-安装完成会显示每个步骤和本地预检结果。`ok:true` 表示软件安装成功；`ready:false` 表示当前配置仍有运行阻断项，例如缺少 Kimi／Codex CLI，二者可以同时出现。安装器不替换现有 DSH，也不安装或代登录 Kimi／Codex，不代配 DeepSeek API 凭证。运行真实任务前需完成所选渠道的准备。
+安装完成会显示每个步骤和本地预检结果。`ok:true` 表示软件安装成功；`ready:false` 表示当前配置仍有运行阻断项，例如缺少 Kimi／Codex CLI，二者可以同时出现。安装器不替换现有 DSH，也不安装或代登录 Kimi／Codex。当前源码的 DeepSeek 默认复用 DSH 已登录账号；用户明确选择 API Key 时仍自行配置该凭证。运行真实任务前需完成所选渠道的准备。
 
 默认使用 npm 的全局 prefix 和用户级 skills 目录。没有全局目录写权限时，可显式选择用户目录：
 
@@ -40,13 +40,13 @@ npx -y @ckanner/flywheel@latest install --prefix "$HOME/.local"
 
 上一节的安装器使用**桌面安装的 `dsh` 命令**执行正式插件管理接口：`dsh plugin --profile desktop add --save-exact --ignore-scripts @ckanner/dsh-plugin-flywheel@<本次版本>`，然后通过 `plugin list` 核对版本。普通 npm DSH CLI 不能管理保留的 `desktop` profile；命令不在 PATH 时用 `--dsh-bin` 指定已核对的桌面命令入口。安装后按宿主提示重新载入。不要猜测 `.app` 内部可执行文件路径。
 
-原生 worker 使用独立的 SDK profile。桌面装有某个 provider，不代表 SDK profile 已经加载或授权。DeepSeek 使用实际 provider `deepseek-official`；GPT 原生路由要求在 SDK profile 中配置对应的 ChatGPT adapter，例如本轮核对的版本：
+原生 worker 使用独立的 SDK profile。标准 SDK 已包含 `deepseek-account` provider 和账号服务；标准桌面与 SDK 使用同一 `DSH_HOME` 时默认共用账号授权，无需为账号路径额外配置 API Key 或复制 token。`deepseek-official` 是单独的 API-key provider，仅作为显式选择保留。第三方 provider 则须核对 SDK 实际加载与授权，例如 GPT 原生路由使用本轮核对的 ChatGPT adapter：
 
 ```sh
 dsh plugin --profile sdk add dsh-plugin-chatgpt@0.1.17
 ```
 
-这是已核对的 adapter 版本示例；采用其他版本前按其文档检查兼容性。按 provider 自身的正常流程完成授权，保持所选 `DSH_HOME` 与配置来源一致。安装 adapter 不会自动迁移桌面凭证，也不证明账号可以调用默认表里的所有模型。`subagent_codex_pro` 是外部 agent 工具，不是这个 SDK 入口的 LLM provider。Flywheel 的 `hard` 路由通过独立 worker 直接导入 `dsh-subagent-codex-pro@0.8.0` 的公开 `./machine` 入口，复用插件运行时；它不创建 DSH 父模型再次委派。插件内部仍运行 Codex app-server，并使用用户已有的 Codex 登录。
+这是已核对的 adapter 版本示例；采用其他版本前按其文档检查兼容性。按 provider 自身的正常流程完成授权，保持所选 `DSH_HOME` 与配置来源一致。安装 adapter 不会复制凭证，也不证明账号可以调用默认表里的所有模型。DSH 桌面能在登录后选择账号默认模型，但该选择不控制独立 SDK 会话；Flywheel 显式请求 `deepseek-account`／`deepseek-flash`，详见[账号与 API 的区别](docs/configuration.md#deepseek-账号与-api-key-是两个-provider)。`subagent_codex_pro` 是外部 agent 工具，不是这个 SDK 入口的 LLM provider。Flywheel 的 `hard` 路由通过独立 worker 直接导入 `dsh-subagent-codex-pro@0.8.0` 的公开 `./machine` 入口，复用插件运行时；它不创建 DSH 父模型再次委派。插件内部仍运行 Codex app-server，并使用用户已有的 Codex 登录。
 
 ### worker 入口配置
 
@@ -90,17 +90,19 @@ flywheel doctor --cwd "$PWD" --probe --json
 | 阶段或执行路由 | Harness | Provider／渠道 | 模型 | Thinking |
 |---|---|---|---|---|
 | Plan | Kimi CLI | `kimi-subscription` | `kimi-code/k3.1-pro` | `high`，匹配身份后可恢复会话 |
-| Execute `default` | DSH SDK | `deepseek-official` | `deepseek-flash` | `high` |
+| Execute `default` | DSH SDK | `deepseek-account` | `deepseek-flash` | `high` |
 | Execute `frontend` | Kimi CLI | `kimi-subscription` | `kimi-code/k3.1-pro` | `high` |
 | Execute `hard` | Codex Pro machine API | `chatgpt-subscription` | `gpt-6.1-sol` | `high` |
-| Review | DSH SDK | `chatgpt` | `gpt-6.1-sol` | `high`，只读 |
+| Review | DSH SDK | `chatgpt` | `gpt-6.1-sol` | `high` |
 | Judge | DSH SDK | `chatgpt` | `gpt-6-astra` | `high`，里程碑终验 |
-| Intake | DSH SDK | `deepseek-official` | `deepseek-flash` | `low` |
+| Intake | DSH SDK | `deepseek-account` | `deepseek-flash` | `low` |
 | Garden | Kimi CLI | `kimi-subscription` | `kimi-code/k3.1-pro` | `high` |
 
 这些是可编辑的初始绑定，并非模型排名或性能承诺。DeepSeek 只用 Flash；当前 Mac rc.5 的合法 effort 为 `off/low/high/max`，没有 `medium`。双 judge 默认关闭，也不默认跨渠道付费降级。`multimodal` 暂无默认绑定：当前 bridge 只有文本契约，模型名称或目录里的 vision 标记不能证明附件已正确传递。
 
-Kimi 使用原生 CLI print/stream-json，不使用 ACP；恢复的是会话历史，不是常驻后台进程。该模式不提供本适配器可宣称的 OS 级只读／工作区沙箱，worktree 只是代码隔离。DSH/Codex 使用明确的 workspace-write 或 read-only 与 never 审批策略。Codex Pro 在运行前核对模型、目录和沙箱模式，Flywheel 在结果返回后检查完整策略；工作区写入允许 Codex 标准临时目录，额外工作区外 roots 或启用网络的策略不能通过交付资格检查。这是事后校验，不能阻止自定义 Codex 配置已允许的访问；要求运行前完整策略阻止的环境需等待上游公开 guard。具体账号的可用模型、额度和使用授权需要由所选服务确认。
+七个 high 与 Intake low 是工程基线，尚未做本项目的 high／xhigh／max 对照评估。GPT 支持 xhigh/max，Kimi K3.1 Pro 原生支持 low/high/max；hard 与高影响 Judge 可优先比较 xhigh，不把所有后端的档位名当作同一尺度。官方依据、适配器限制和建议见[推理等级说明](docs/model-policy.md)。0.28.2 默认仍使用 DeepSeek API；采用上表账号默认须升级至 0.28.3 或以后版本，并[显式迁移配置](docs/configuration.md#将旧配置切换到已有的三种资源)。
+
+Kimi 使用原生 CLI print/stream-json，不使用 ACP；恢复的是会话历史，不是常驻后台进程。该模式不提供本适配器可宣称的 OS 级只读／工作区沙箱，worktree 只是代码隔离。新模板及显式 subscriptions 迁移使用 `permissions.mode:full-access`，DSH/Codex 全阶段 danger-full-access＋never，Kimi print 为 auto；已有文件未声明时保持 role-based 的 workspace-write／read-only。Codex Pro 在运行前核对模型、目录和沙箱模式，Flywheel 在结果返回后检查完整策略；在受限模式，工作区写入允许 Codex 标准临时目录，额外工作区外 roots 或启用网络的策略不能通过交付资格检查；明确 full-access 则核对完全权限回执，不声称 OS 隔离。这是事后校验，不能阻止自定义 Codex 配置已允许的访问；要求运行前完整策略阻止的环境需等待上游公开 guard。具体账号的可用模型、额度和使用授权需要由所选服务确认。
 
 usage 或美元成本未上报时保留 unknown，不能把订阅调用记成免费。默认 soft token budget 会报告未知量；hard budget 无法证明未知用量未超额时停止。汇总数字是已知量下限。
 
@@ -126,9 +128,9 @@ flywheel config inspect --cwd /repo --task-dir /repo/docs/my-task --json
 
 准备阶段由当前 DSH 对话模型生成需求契约，`loops.plan` 只控制引擎启动后的规划／修订。复杂需求建议先用已授权的 `gpt-6-astra`、`high` 生成可审阅草稿；简单明确的任务可沿用 Flash，避免每个 packet 都重复调用昂贵规划模型。
 
-先在目标 Git 仓库准备并审阅 `docs/<slug>/` 中的 Spec、packet 与配置：需求编号、L1/L2/L3 命令、禁止修改的验收路径和失败出口都应明确。模板可通过 `flywheel template` 查看；可选的 `flywheel-new` skill 用于辅助生成，最终仍由人确认契约。不要把 DSH 面板当成需求生成器。
+先在目标 Git 仓库准备并审阅 `docs/<slug>/` 中的 Spec、packet 与配置：需求编号、L1/L2/L3 命令、禁止修改的验收路径和失败出口都应明确。DSH 输入框用 `/flywheel-new` 调用准备 Skill，审阅后用 `/flywheel-run`；Kimi CLI 的对应语法是 `/skill:flywheel-new`、`/skill:flywheel-run`。两者都是宿主加载 Skill 后让助手按流程调用 CLI，不是另一个引擎。完整步骤见[工作流](docs/workflow.md)，无需先填面板。
 
-从 `0.28.1` 开始，桌面控制面接入顶部“对话／轨迹”旁的原生 **Flywheel** 会话视图，保留 DSH 输入区、模型选择器和右侧栏。`0.28.0` 仍是旧底部弹层，需把 CLI 与桌面插件同版升级。输入仓库路径后可查看配置、检查环境或执行 SDK 无推理探测；启动、刷新和停止还需绝对任务路径。视图展示最近刷新的任务结果、完整 packet 列表与未知用量，模型配置和诊断按需查看，原始 JSON 默认折叠。也可使用人工命令：
+从 `0.28.1` 开始，桌面控制面接入顶部“对话／轨迹”旁的原生 **Flywheel** 会话视图，保留 DSH 输入区、模型选择器和右侧栏。`0.28.0` 仍是旧底部弹层，需把 CLI 与桌面插件同版升级。“任务资料目录”选择已准备的 `docs/<slug>/`；“项目目录”是任务所在项目／集成 worktree，可留空。从 0.28.3 开始通过 DSH `workingDirectory.get(session)` 读取会话实际目录，跟随目录切换；0.28.2 仍取最初的 header 目录，切换 worktree 后需显式填写项目路径。查看配置或检查接入可不填任务目录；启动、刷新和停止必须选择已有任务。视图展示最近刷新的结果、完整 packet 列表与未知用量，模型配置和诊断按需查看，原始 JSON 默认折叠。也可使用人工命令：
 
 ```text
 /flywheel {"action":"status","taskDir":"/repo/docs/my-task","cwd":"/repo"}

package/docs/configuration.md

@@ -18,19 +18,66 @@ flywheel config inspect --cwd /repo --task-dir /repo/docs/task --json
 
 展示值包含 Flywheel 已确定的 driver 默认：DSH／Codex／Kimi 的空 thinking 为 high，pi／omp／zcode 为 max；Kimi／Codex／Zcode 的空 model 使用各自 driver 常量。pi／omp 未指定模型时仍留空，表示 Flywheel 不能从配置确定它。`residentSession` 只有 Plan＋Kimi＋明确启用时为 true，不把其他阶段忽略的请求显示为已生效。
 
+### 将旧配置切换到已有的三种资源
+
+当前源码的 `subscriptions` 预设只使用 ChatGPT 订阅、Kimi Code 订阅和 DSH 已登录并充值的 DeepSeek 账号（仅 Flash，`provider:deepseek-account`）。普通安装／升级仍保留已有配置；所以旧文件里的 Z.AI／GLM、Kimi K3、API provider 和旧 thinking 不会因升级 UI 自动消失。
+
+**发行边界：**迁移命令与 `permissions.mode` 已在 0.28.2 发行，但该版内嵌预设仍选择 `deepseek-official` API Key。账号默认修复从 0.28.3 开始提供。安装前核对 registry 版本。先通过 `flywheel template flywheel.config.example.json` 核对所用二进制包含 `deepseek-account`，再用下面的迁移命令；在旧 0.28.2 上重跑迁移不会得到账号默认。
+
+在实际项目目录运行以下命令；若任务目录有单独配置，再加 `--task-dir /repo/docs/my-task`：
+
+```sh
+flywheel config migrate --preset subscriptions --cwd /repo --json
+flywheel config migrate --preset subscriptions --cwd /repo --apply --json
+flywheel config inspect --cwd /repo --json
+```
+
+第一条只预览。`--apply` 明确应用到当前实际命中的任务／项目／全局文件，并先备份原始字节。没有文件时写全局配置，不创建意外的项目覆盖。可以用 `--expect-sha256` 绑定之前预览的摘要；文件已经变化时拒绝陈旧应用。预算、worktree、验证、重试、价格和用户说明等非模型设置保留，Plan 明确设置的 `resident-session:false` 也保留。配置损坏、额外自定义路由／阶段或不支持的文件身份会明确阻断，不猜测替代。
+
+迁移写入完整的阶段模型、thinking 和渠道，去掉被替换绑定的旧 profile 引用，清除所选渠道的旧 fallback／模型映射，使旧付费渠道不再自动可达；未引用的自定义 profiles／channels 仍保留。包括 0.28.2 留下的 API channel，也可以作为未引用配置保留，但不会成为账号路由的自动后备。默认关闭第二意见，并明确报告旧多模态路由被停用。默认分配仍是 Kimi K3.1 Pro high 负责 Plan／frontend／Garden，DeepSeek Flash high 负责普通执行、low 负责 Intake，GPT-6.1 Sol high 负责 hard／Review，GPT-6 Astra high 负责 Judge。hard 通过 Codex Pro 插件，Review／Judge 通过 DSH ChatGPT provider。Kimi 缺省模型为 `kimi-code/k3.1-pro`；显式写入的自选模型不会被仅修改 driver 缺省值覆盖。档位依据与尚未完成的对照评估见[推理等级与账号选择](model-policy.md)。
+
+迁移不登录账号，也不发模型请求。当前运行中的任务继续使用启动时已加载的配置；新配置在下一次启动生效。检查迁移后的 source／scope／bindings，再按需要停止和恢复任务。
+
+迁移期间不要同时编辑目标文件。迁移锁协调 Flywheel 迁移进程；写入前再次检查文件，再原子替换完整文件，不提供对任意外部编辑器的原子 CAS。报告以 `configurationStatus` 区分拟议配置 `proposed`、重读确认的实际配置 `effective` 和写入后尚未确认的 `unconfirmed`；备份／写入失败不能把新模型显示成已生效。
+
+### 完全权限与无需逐步确认
+
+```json
+{"permissions":{"mode":"full-access"}}
+```
+
+新安装模板和显式 `subscriptions` 迁移都写入这一设置。全部阶段使用完全权限：DSH／Codex 请求 `danger-full-access` 与 `approval=never`，Codex Pro 通过其公开 machine API 映射，Kimi print 沿用原生 auto。它表示这些 worker 可以访问当前操作系统用户本来能够访问的文件和命令，并不从 DSH 对话框的权限下拉菜单继承。
+
+旧文件没有 `permissions` 时保持 `role-based`：Plan／Execute 为项目内写入，Review／Judge 为只读。两种策略都不等待交互审批；只读／项目限制下的 `never` 可能直接拒绝动作，不能把它等同于完全权限。`permissions.mode` 的拼写、类型和枚举都会在启动前校验。
+
+完全权限不会关闭 Flywheel 的任务边界、冻结验收、验证和候选身份检查。评审职责仍是评价已有候选，修改候选或验收条件不能取得有效通过。需要受限权限时显式使用 `role-based`；工作区隔离本身不是 OS 沙箱。
+
 ## 2. 四个概念各负责什么
 
 | 字段 | 含义 | 示例 |
 |---|---|---|
 | `harness` | 实际工具循环与进程后端 | `dsh`、`kimi`、`codex-pro`；`codex` 为显式旧 CLI 路径 |
-| `provider` | DSH SDK 已注册的 LLM adapter ID；仅 DSH 使用 | `deepseek-official`、`chatgpt` |
-| `channel` | 配置中的凭证／后备／计量渠道名称 | `deepseek-sdk`、`chatgpt-sdk`、`kimi-subscription` |
+| `provider` | DSH SDK 已注册的 LLM adapter ID；仅 DSH 使用 | `deepseek-account`、`chatgpt` |
+| `channel` | 配置中的凭证／后备／计量渠道名称 | `deepseek-account-sdk`、`chatgpt-sdk`、`kimi-subscription` |
 | `profile` | 当前 Flywheel 配置内的一组模型字段引用 | `flash`、`gpt-review`、`kimi` |
 
 Flywheel 的 model profile 与 DSH 的 `sdk`／`desktop` profile 是两件事。前者复用模型定义，后者决定宿主实际加载的插件和授权配置。channel 别名本身不会切换 DSH 账号；给同一个 provider 起两个 channel 名称不等于拥有两份独立订阅或额度。
 
 DSH 的实际 provider 按 `binding.provider` → `channels[channel].provider` → 旧 `channel` 名解析。前两者都明确配置而不相等时拒绝加载。兼容旧内联配置的最后一项只适用于 DSH；Codex Pro／旧 Codex CLI 和 Kimi 使用自己的登录状态，不接受一个会被静默忽略的 provider。
 
+### DeepSeek 账号与 API Key 是两个 provider
+
+| 方式 | Provider | 凭证来源 | 选择方式 |
+|---|---|---|---|
+| DSH 已登录、已充值的 DeepSeek 账号 | `deepseek-account` | DSH 的 `deepseekAccount` 服务 | 当前源码默认；不要求 `DEEPSEEK_API_KEY` |
+| DeepSeek API Key | `deepseek-official` | DSH credentials／启动环境中的 API key，默认引用 `DEEPSEEK_API_KEY` | 仅在用户明确选择 API 路径时配置 |
+
+标准 SDK profile 叠加的 [base](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/bundle/base/cordis.patch.yml) 包含账号服务和这两种 adapter。标准桌面与 SDK 使用同一 `DSH_HOME` 时，默认共享该 home 下的[账号授权存储](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/credentials/credentials-local/src/index.ts)；profile 隔离插件配置，不要求把 token 复制到 `sdk` 或改用 `desktop` profile。自定义 home、凭证存储或 SDK 插件集时，须核对它们指向同一授权来源。这里不读取或展示凭证值。
+
+DSH 桌面在登录后且没有任何 provider API key 时，可以自动选择账号目录里的第一个模型。该桌面默认不决定独立 SDK 会话的 provider/model，且“第一个模型”不保证是 Flash。Flywheel 因此明确传入 `deepseek-account`／`deepseek-flash`；账号未登录、授权失效或额度不足时保留失败。默认预设没有 API Key 后备；用户显式配置的后备链仍按既有规则处理。已核对的[官方账号 adapter](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/llm/llm-deepseek-account/src/index.ts)、[API adapter](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/llm/llm-deepseek-api-key/src/index.ts)及[默认选择逻辑](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/api/session-controller/src/index.ts)是这一边界的依据。
+
+需要继续用 API Key 的自定义配置仍受支持：在完整配置的相关绑定及其 channel 中一致选择 `deepseek-official`，按 DSH API provider 的正常方式配置凭证。不要仅改 channel 名却保留冲突的显式 provider；也不必为账号路径额外添加 API key。
+
 ### Codex Pro 默认与旧配置迁移
 
 0.28.0 的内嵌 hard 路由使用插件路径。下面是需放入自己完整配置的绑定片段，不是可替换全部配置的文件：
@@ -54,7 +101,7 @@ DSH 的实际 provider 按 `binding.provider` → `channels[channel].provider`
 
 `FLYWHEEL_CODEX_PRO_WORKER` 可显式指定 worker；通常由 npm 启动器解析同版本依赖。`FLYWHEEL_CODEX_BIN` 指定插件内部的 Codex 程序，默认 PATH 中的 `codex`；`CODEX_HOME` 可选择既有配置与登录目录。自定义环境需对启动引擎的进程可见，安装器不会复制凭证。
 
-插件在运行前确认模型、cwd、approval 和沙箱模式；Flywheel 在完整结果返回后检查实际策略及进程终态。workspace-write 允许工作区及 Codex 标准临时目录；额外的工作区外 writable roots、网络启用或不能确认的策略不能进入成功验收。**该完整策略检查发生在运行后，不能阻止自定义 Codex 配置已允许的访问。** 要求完整策略在任务前被拒绝的环境，应等待上游公开 pre-turn guard；doctor 会持续提示这一边界。
+插件在运行前确认模型、cwd、approval 和沙箱模式；Flywheel 在完整结果返回后检查实际策略及进程终态。在 role-based 的 workspace-write 模式，允许工作区及 Codex 标准临时目录；额外的工作区外 writable roots、网络启用或不能确认的策略不能进入成功验收。显式 full-access 则核对 `danger-full-access`／`dangerFullAccess` 完全权限回执，不将其误报为受限沙箱。**该完整策略检查发生在运行后，不能阻止自定义 Codex 配置已允许的访问。** 要求完整策略在任务前被拒绝的环境，应等待上游公开 pre-turn guard；doctor 会持续提示这一边界。
 
 指标的 `codex-pro-receipt` 保存完整 machine receipt，包含请求、实际配置、thread/turn、进程、清理、usage 和失败事实。effort 的 `accepted: true` 不等于服务器证明了实际推理强度，`effectiveEffort` 保留 null。仅 `usage.status: "complete"` 的本次增量进入已知预算；partial/unknown 原样留在回执并计入未知调用。插件不提供实际美元成本，原始 cost 保持 unknown；Flywheel 只有在用户显式配置 pricing 且 usage 完整时才能另行估算，估算不等于订阅账单。
 
@@ -74,8 +121,8 @@ flywheel template flywheel.profiles.example.json
   "profiles": {
     "flash": {
       "harness": "dsh",
-      "provider": "deepseek-official",
-      "channel": "deepseek-sdk",
+      "provider": "deepseek-account",
+      "channel": "deepseek-account-sdk",
       "model": "deepseek-flash",
       "thinking": "high"
     },
@@ -96,7 +143,7 @@ flywheel template flywheel.profiles.example.json
     "default": { "profile": "flash" }
   },
   "channels": {
-    "deepseek-sdk": { "harness": "dsh", "provider": "deepseek-official", "env-key": null },
+    "deepseek-account-sdk": { "harness": "dsh", "provider": "deepseek-account", "env-key": null },
     "chatgpt-sdk": { "harness": "dsh", "provider": "chatgpt", "env-key": null }
   }
 }
@@ -118,7 +165,7 @@ flywheel template flywheel.profiles.example.json
 | profile 再引用另一个 profile | 不支持继承链；加载失败 |
 | `_note`、`_note_*` | 允许配置对象中的说明文字，不进入执行绑定 |
 
-`resident-session` 是阶段策略，不能放进 profile。当前只有 Kimi 的 Plan 可恢复历史，且必须匹配实际 harness/model/channel/cwd/thinking；profile 名改了而实际值没变，不影响身份。其他执行、评审和 SDK 调用仍是新会话。
+`resident-session` 是阶段策略，不能放进 profile。当前只有 Kimi 的 Plan 可恢复历史，且必须匹配实际 harness/model/channel/cwd/thinking/permissionMode；profile 名改了而实际值没变，不影响身份。其他执行、评审和 SDK 调用仍是新会话。
 
 旧内联绑定保留原有缺省行为，不强制迁移。`env-key: null`、`retry.jitter: 0`、`worktree.enabled: false` 等已有合法零值继续支持。显式切换 harness 或 channel 时，要一起核对继承的 provider；必要时用 `provider: ""` 清除显式值，再按新 channel 解析，不能保留另一个 adapter 的 ID。
 
@@ -142,6 +189,8 @@ flywheel doctor --cwd /repo --task-dir /repo/docs/task --probe --json
 
 本地检查确认命令可用、版本响应可靠，以及声明的环境变量存在且非空，不显示变量值。`--probe` 才启动 DSH worker 验证 adapter 接受配置、cwd、完整沙箱、approval policy 和 SDK 正常关闭。相同 provider、channel、model、effort、cwd 和权限的探测去重；不同账号别名或读写权限不能相互代替。整体验证预算 40 秒，另留进程清理窗口。
 
+DSH 的 `ready.reasoningEffort` 是 SDK 接受配置之后的 worker 回显，不是模型服务独立证明的实际推理强度。没有模型请求的检查不能证明更高档位提高质量；GPT、Kimi 和 Flash 也不共用同一套档位枚举，详见[推理等级说明](model-policy.md)。
+
 Codex Pro 本地检查额外实际导入公开 machine API，核对精确 0.8.0／协议 1、Node >=22.18.0 以及 Codex 命令版本；同一 worker 只查一次。`--probe` 不为此路径发送任务，实际模型、effort 与完整权限保持 unknown；它不会把成功导入插件当成账号、沙箱或推理能力已经验证。
 
 | 状态 | 解释 |

package/docs/en/configuration.md

@@ -2,7 +2,7 @@
 
 [English README](../../README.en.md) · [中文](../configuration.md) · [Workflow](workflow.md)
 
-Flywheel loads one complete configuration, expands its model profiles, and resolves each stage's binding before starting. Model selection is explicit configuration. Restart the engine after changing it. This guide describes the 0.28.0 implementation; existing user configuration is not automatically migrated during installation.
+Flywheel loads one complete configuration, expands its model profiles, and resolves each stage's binding before starting. Model selection is explicit configuration. Restart the engine after changing it. This guide follows the current source; existing user configuration is not automatically migrated during installation. The account-provider correction below is separate from the published 0.28.2 release.
 
 ## Configuration precedence
 
@@ -23,13 +23,47 @@ flywheel config inspect --cwd /absolute/path/to/repo --task-dir /absolute/path/t
 
 The result includes `source`, `scope`, resolved physical paths, and stage `bindings`. Without `--task-dir`, discovery starts at the selected project and lower levels. Inspection does not create global configuration or task state, read account tokens, or invoke a model.
 
+## Apply the subscription preset to existing configuration
+
+The current source-level `subscriptions` preset uses ChatGPT subscriptions, Kimi Code subscriptions, and the signed-in, funded DeepSeek account in DSH, with Flash and `provider:deepseek-account`. Normal installation and upgrades preserve existing configuration, including old Z.AI/GLM routes, Kimi K3 bindings, API providers, and effort choices.
+
+**Release boundary:** migration and `permissions.mode` shipped in 0.28.2, but that published preset still selects the `deepseek-official` API-key route. The account-default correction is available from 0.28.3. Check the registry version before installing. First check that `flywheel template flywheel.config.example.json` from your binary contains `deepseek-account`; rerunning migration with the published 0.28.2 binary does not select the new account default.
+
+From the actual project, preview and apply the selected configuration. Add `--task-dir /repo/docs/my-task` when the task has its own configuration:
+
+```sh
+flywheel config migrate --preset subscriptions --cwd /repo --json
+flywheel config migrate --preset subscriptions --cwd /repo --apply --json
+flywheel config inspect --cwd /repo --json
+```
+
+The first command only previews. `--apply` backs up the original bytes and updates the effective task/project/global file; with no file, it creates global configuration. Optional `--expect-sha256` binds application to a preview. Changed source files, invalid input, unsupported file identities, and extra custom routes/stages are rejected. Budgets, verification, worktrees, retries, pricing, notes, and an explicit Plan `resident-session:false` are preserved.
+
+The preset replaces the model bindings, removes their old profile references, and clears fallback/model mappings on the selected channels so that old paid routes are no longer automatically reachable. Unreferenced custom profiles and channels remain intact, including the old 0.28.2 API channel; it is not an automatic fallback for the account route. The preset disables the optional second opinion and reports removal of the old unverified multimodal route. Kimi K3.1 Pro/high handles Plan, frontend execution, and Garden; DeepSeek Flash/high handles ordinary execution and Flash/low handles Intake; GPT-6.1 Sol/high handles hard execution and Review; GPT-6 Astra/high handles Judge. Hard execution uses Codex Pro; Review/Judge use the DSH ChatGPT provider. Kimi's omitted-model default is `kimi-code/k3.1-pro`, without overriding an explicitly selected model. See [Reasoning effort and account selection](model-policy.md) for the rationale and the project comparison that remains unperformed.
+
+Do not edit the target file while migrating. The lock coordinates Flywheel migration processes; the source is checked again before a complete file is atomically replaced. This is not an atomic compare-and-set against arbitrary external editors. Reports distinguish proposed configuration (`configurationStatus: proposed`), re-read effective configuration (`effective`), and an unconfirmed post-write result (`unconfirmed`). A failed backup or write must not present the proposed models as already effective.
+
+Migration does not sign in or invoke models. Running tasks retain their startup configuration; the next engine start uses the migrated file. Review the resulting source, scope, and bindings before stopping/resuming an existing task as needed.
+
+## Full access without per-action approval
+
+```json
+{"permissions":{"mode":"full-access"}}
+```
+
+New installation templates and the explicit subscription migration select this mode for every stage. DSH/Codex request `danger-full-access` and `approval=never`; Codex Pro maps through its public machine API; Kimi print retains native auto behavior. This grants worker access within the current operating-system user's permissions. It is independent of the desktop conversation's permission dropdown.
+
+Existing files without this setting retain `role-based`: Plan/Execute request workspace-write, and Review/Judge request read-only. Neither policy waits for interactive approval. In restricted modes, `never` can reject an action; it does not itself grant full access. Invalid policy names and types fail before execution.
+
+Full access preserves task boundaries, frozen acceptance, verification, and candidate identity checks. A reviewer still cannot change the candidate or acceptance criteria and obtain a valid verdict. Select `role-based` explicitly when confinement is intended; a worktree is not an OS sandbox.
+
 ## Fields and identities
 
 | Field | Meaning | Example |
 |---|---|---|
 | `harness` | Process and tool-loop backend | `dsh`, `kimi`, `codex-pro`; `codex` is the explicit older CLI path |
-| `provider` | Registered DSH SDK LLM adapter ID; applies to DSH bindings | `deepseek-official`, `chatgpt` |
-| `channel` | A configuration label used for credentials, fallback, and accounting | `deepseek-sdk`, `chatgpt-sdk`, `kimi-subscription` |
+| `provider` | Registered DSH SDK LLM adapter ID; applies to DSH bindings | `deepseek-account`, `chatgpt` |
+| `channel` | A configuration label used for credentials, fallback, and accounting | `deepseek-account-sdk`, `chatgpt-sdk`, `kimi-subscription` |
 | `model` | Exact model identifier passed to the selected backend | `deepseek-flash`, `kimi-code/k3.1-pro`, `gpt-6.1-sol` |
 | `thinking` | Requested reasoning effort | `high` |
 | `profile` | Reusable model fields inside this Flywheel configuration | `flash`, `gpt-review`, `codex-pro` |
@@ -40,6 +74,19 @@ For DSH, the provider resolves from `binding.provider`, then `channels[channel].
 
 Only supported effort values should be used. The checked DSH Flash adapter accepts `off/low/high/max`; it has no `medium`. A configuration value names an intended binding, not evidence of account entitlement or measured model performance.
 
+### DeepSeek account and API-key providers
+
+| Access method | Provider | Credentials | Selection |
+|---|---|---|---|
+| Signed-in, funded DeepSeek account in DSH | `deepseek-account` | DSH's `deepseekAccount` service | Current source default; no `DEEPSEEK_API_KEY` required |
+| DeepSeek API key | `deepseek-official` | DSH credentials or launch environment; default reference `DEEPSEEK_API_KEY` | An explicitly selected alternative |
+
+The standard SDK profile layers over a [base](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/bundle/base/cordis.patch.yml) that includes the account service and both adapters. The standard desktop and SDK share the [account credential store](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/credentials/credentials-local/src/index.ts) when they use the same `DSH_HOME`. Profiles isolate plugin configuration; no token copy or switch to the reserved `desktop` profile is needed. Custom homes, credential stores, or SDK plugin sets must resolve the intended authorization source.
+
+After login, the desktop can choose the first account model when no provider API key exists. That host selection neither controls an independent SDK session nor guarantees Flash is the first model. Flywheel explicitly sends `deepseek-account` and `deepseek-flash`; the default preset has no API-key fallback for sign-in failures, invalid tokens, or insufficient quota. Explicit user-defined fallback chains retain their existing policy. The checked sources are the [account adapter](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/llm/llm-deepseek-account/src/index.ts), [API adapter](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/llm/llm-deepseek-api-key/src/index.ts), and [host default selection](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/api/session-controller/src/index.ts).
+
+Explicit API-key configurations remain supported. Select `deepseek-official` consistently in the relevant binding and its channel, and configure credentials through DSH's API-provider flow. Renaming a channel does not override a conflicting explicit provider. Account access does not need an additional API key.
+
 ## Start from a complete template
 
 Inspect either bundled example:
@@ -62,8 +109,8 @@ Do not create a task file containing only a few profiles and expect it to inheri
   "profiles": {
     "flash": {
       "harness": "dsh",
-      "provider": "deepseek-official",
-      "channel": "deepseek-sdk",
+      "provider": "deepseek-account",
+      "channel": "deepseek-account-sdk",
       "model": "deepseek-flash",
       "thinking": "high"
     }
@@ -75,9 +122,9 @@ Do not create a task file containing only a few profiles and expect it to inheri
     "intake": { "profile": "flash", "thinking": "low" }
   },
   "channels": {
-    "deepseek-sdk": {
+    "deepseek-account-sdk": {
       "harness": "dsh",
-      "provider": "deepseek-official",
+      "provider": "deepseek-account",
       "env-key": null
     }
   }
@@ -100,7 +147,7 @@ Do not create a task file containing only a few profiles and expect it to inheri
 | A profile references another profile | Unsupported; configuration error |
 | `_note` or `_note_*` | Permitted explanatory metadata, excluded from execution bindings |
 
-`resident-session` belongs on a stage, not in a profile. Currently only Kimi Plan can resume, and only when harness, model, channel, working directory, and thinking match. This restores session history, not a permanently running process. Execution and review calls start fresh sessions.
+`resident-session` belongs on a stage, not in a profile. Currently only Kimi Plan can resume, and only when harness, model, channel, working directory, thinking, and permission mode match. This restores session history, not a permanently running process. Execution and review calls start fresh sessions.
 
 Legal existing zero values, including `env-key: null`, `retry.jitter: 0`, and `worktree.enabled: false`, remain meaningful. When changing a harness or channel, also inspect any inherited provider. Use `provider: ""` when necessary to clear an explicit value before resolving the newly selected DSH channel.
 
@@ -146,7 +193,7 @@ These settings must be visible to the process starting the engine. The installer
 
 ### Permissions, receipts, and cleanup
 
-The plugin checks the requested model, working directory, approval policy, and sandbox mode before a turn. Flywheel examines the complete returned policy afterward. Workspace-write permits the workspace and standard Codex temporary directories; extra external write roots, enabled network, or unconfirmed policy make the result ineligible for successful delivery.
+The plugin checks the requested model, working directory, approval policy, and sandbox mode before a turn. Flywheel examines the complete returned policy afterward. In role-based mode, workspace-write permits the workspace and standard Codex temporary directories; extra external write roots, enabled network, or unconfirmed policy make the result ineligible for successful delivery. Explicit full access verifies the matching `danger-full-access` sandbox and `dangerFullAccess` policy without claiming confinement.
 
 **The complete policy check happens after execution. It cannot prevent access already allowed by custom Codex configuration.** An environment requiring a full policy rejection before any turn needs an upstream public pre-turn guard. Kimi's current CLI integration also provides no OS-level sandbox guarantee; a configured permission requirement should not be read as proof of its enforcement.
 
@@ -178,6 +225,8 @@ Without a task, doctor checks all configured bindings. With a task, it validates
 
 Local checks cover commands, versions, directories, configuration, and declared nonempty environment variables, without showing their values. `--probe` additionally initializes DSH SDK sessions, verifies accepted configuration, working directory, permissions, and normal shutdown. Identical probes are deduplicated only when their relevant identity and permissions match. The probe budget is 40 seconds plus bounded process cleanup time.
 
+DSH's `ready.reasoningEffort` echoes the requested value after SDK configuration acceptance; it is not an independent server attestation of effective reasoning effort. A no-inference probe cannot demonstrate quality gains from a higher effort. GPT, Kimi, and Flash also have different native effort enums; see [Reasoning effort](model-policy.md).
+
 Codex Pro checks actually import the public API and verify exact version 0.8.0/protocol 1, Node compatibility, and the Codex executable. `--probe` does not send a task through this path: account/model/effort and full runtime policy remain unverified. A successful import is not a successful model call.
 
 | Status | Meaning |

package/docs/en/getting-started.md

@@ -2,12 +2,16 @@
 
 [English README](../../README.en.md) · [中文](../getting-started.md) · [Workflow](workflow.md) · [Configuration](configuration.md)
 
-This guide covers **Flywheel 0.28.1**: npm installation, the DSH desktop and workers, configuration, preflight, a small task, and recovery. The checked desktop interface baseline is **DSH Mac 0.2.1-rc.5**. Real desktop UI, macOS permissions, authentication, and model inference still need testing on the intended machine.
+This guide covers **Flywheel 0.28.3**: npm installation, the DSH desktop and workers, configuration, preflight, a small task, and recovery. The checked desktop interface baseline is **DSH Mac 0.2.1-rc.5**. Real desktop UI, macOS permissions, authentication, and model inference still need testing on the intended machine.
 
 Before installing, check `npm view @ckanner/flywheel version`. Continue with these instructions once the registry has the version you intend to use. A merged source change or GitHub Release does not establish npm publication, and an older installed release may not include these interfaces.
 
 The top-level **Flywheel conversation view** below is available from `0.28.1`. Version `0.28.0` uses the composer popup; upgrade the CLI and desktop plugin to the same new version. Merging source or reloading the old version does not change that layout. CLI and task-directory interfaces remain the same.
 
+Subscription preset migration and `permissions.mode` are available from **0.28.2**. Upgrades preserve existing configuration; preview `flywheel config migrate --preset subscriptions`, review the model bindings and full-access policy, then explicitly apply it with `--apply` and a backup.
+
+**Fixes in 0.28.3:** the `deepseek-account` default and the current session directory when the project path is omitted. Version 0.28.2 still uses `deepseek-official` and the original directory. Check the registry version before installing. Upgrades preserve configuration; adopting the account preset requires explicit migration.
+
 ## 1. Prepare the environment
 
 | Requirement | Why it is needed |
@@ -22,7 +26,7 @@ The top-level **Flywheel conversation view** below is available from `0.28.1`. V
 
 Check command locations and versions with `git --version`, `node --version`, `npm --version`, `command -v dsh`, `dsh --version`, `kimi --version`, and `codex --version`. Check the desktop version in About as well. Use the respective tools' documented installation and login flows.
 
-Kimi subscription, ChatGPT subscription, and DeepSeek API access are separate channels. Flywheel does not log in, copy credentials, or replace the desktop application. A task using only the default execution route can skip the hard route at runtime, but it still needs its configured Plan, Execute, Review, and Judge backends.
+The defaults reuse the Kimi subscription, ChatGPT subscription, and existing signed-in, funded DeepSeek account. DeepSeek API access is an explicitly configured alternative. Flywheel does not log in, copy credentials, or replace the desktop application. A task using only the default execution route can skip the hard route at runtime, but it still needs its configured Plan, Execute, Review, and Judge backends.
 
 ## 2. Install
 
@@ -79,7 +83,9 @@ This is the command shape used internally, not a placeholder to paste literally.
 
 This view controls and observes an already prepared task: progress, intervention, effective models, environment checks, and explicit start/refresh/stop. DSH keeps its chat, trajectory, composer, model selector, and right sidebar. Discuss requirements and prepare contracts through the original chat and skills. The view does not discover tasks started elsewhere; select the same task directory to observe one.
 
-The worker defaults to a separate **`sdk` profile**. A desktop provider installation or login does not prove that the SDK profile has the same configuration or authorization. DeepSeek uses `deepseek-official`; native GPT routing uses the ChatGPT adapter. The checked adapter baseline can be installed with:
+The worker defaults to a separate **`sdk` profile**. The standard SDK layers on `base`, which already includes DeepSeek's account and API adapters. Current source explicitly selects `provider: "deepseek-account"` and `model: "deepseek-flash"` to reuse the signed-in, funded account. `deepseek-official` is only for an explicitly chosen API-key configuration; there is no automatic paid-channel fallback.
+
+With the same `DSH_HOME`, the standard desktop and SDK can share the existing login in the default `<DSH_HOME>/.credentials.yaml`, independently of the profile. No token copying or switch to the `desktop` profile is needed. Check custom home, profile, or credential-store choices separately. The SDK does not inherit the desktop's selected conversation model; Flywheel uses its own effective bindings, visible through `config inspect` or the view's model-configuration action. Native GPT routing needs the ChatGPT adapter in the SDK profile. The checked adapter baseline can be installed with:
 
 ```sh
 dsh plugin --profile sdk add dsh-plugin-chatgpt@0.1.17
@@ -99,6 +105,8 @@ After moving Node or the npm prefix, or installing previously missing tools, run
 
 ## 4. Select configuration and skills
 
+If the view still shows Z.AI/GLM or Kimi K3, inspect its configuration source: upgrades preserve that file. A version containing this change can back up and migrate it with `flywheel config migrate --preset subscriptions --cwd /repo --apply --json`; omit `--apply` to preview, and add `--task-dir` for task overrides. This selects ChatGPT/Kimi Code/DeepSeek Flash, the agreed efforts, and full access for every stage. See [migration and permissions](configuration.md#apply-the-subscription-preset-to-existing-configuration). Published 0.28.1 does not contain this command.
+
 Configuration precedence is task directory, project root, global file, then embedded defaults. The first complete file wins; files do not merge. Existing configuration is preserved during upgrades. Inspect the actual source:
 
 ```sh
@@ -119,6 +127,8 @@ flywheel install-skills --project /absolute/path/to/repo --json
 
 Follow the host's skill-discovery rules. Copying files does not prove the host loaded them. Installer-owned unchanged snapshots can update; modified files, unowned directories, and invalid manifests are preserved and reported as conflicts.
 
+In DSH Chat, use `/flywheel-new`, `/flywheel-run`, and `/flywheel-status`, or select them from the `/` menu. Kimi instead uses `/skill:flywheel-new` and corresponding prefixed names. Preparation, start, and status can all happen in the conversation: **no initial Flywheel-view form is required.** The view is an alternative way to open an already prepared task. See the [copyable workflow](workflow.md#3-prepare-and-review-the-contracts).
+
 ## 5. Run preflight without inference
 
 From the target repository:
@@ -142,12 +152,16 @@ flywheel doctor --cwd "$PWD" --task-dir "$PWD/docs/my-feature" --probe --json
 
 A task without packets can be inspected during preparation, but a real start still needs at least one reviewed legal packet. Fix schema, directory, provider, or permission failures at their source.
 
+The view's optional configuration and troubleshooting section offers “Inspect model configuration,” “Check installation and configuration,” and “Check DSH integration.” Use these for setup, configuration changes, or troubleshooting; they are not buttons that must be pressed for every task. Neither diagnostic performs model inference.
+
 ## 6. Prepare a task
 
 ### Existing repository
 
 Create or deliberately reuse a task integration branch and independent worktree **before** running `flywheel-new`. Prepare contracts and launch the engine from that same root, using a task path inside it. The [workflow guide](workflow.md) gives the branch commands, model recommendations, draft-PR timing, and exact working directory for each loop.
 
+The normal DSH entry is `/flywheel-new` followed by the actual requirement. The assistant creates or reuses the task worktree, prepares `docs/<slug>/spec.md` and task packets, and reports two actual absolute paths: the **project directory** is the code worktree; the **task files directory** is its `docs/<slug>` holding this task's contracts and later state/reports. You do not need to invent an empty directory or fill in the UI first. Review the contracts, then reuse the supplied task path.
+
 Use the bundled templates to prepare a real Spec and packets with actual acceptance commands, protected oracles, and recorded dry-run results. Commit the reviewed contracts before starting so packet worktrees can read them from Git. Do not create `state.json` manually.
 
 ### Disposable first-run example
@@ -195,7 +209,9 @@ flywheel control start --cwd "$PWD" --task-dir "$PWD/docs/add"
 flywheel control status --cwd "$PWD" --task-dir "$PWD/docs/add"
 ```
 
-The top **Flywheel** view accepts the same two absolute paths. Expand its model-configuration and environment-check section when needed, then use the explicit start, refresh, or stop action. A control response's `ok` means the operation succeeded; task completion is determined by `state.status`. The view displays the last refresh time and does not poll automatically.
+In DSH Chat, the equivalent entries are `/flywheel-run <absolute-task-path>` and `/flywheel-status <same-path>`, with `/flywheel-stop <same-path>` when stopping is needed. Replace the placeholders with the real path returned during preparation. These skills resolve the project root without requiring an initial view selection.
+
+To use the top **Flywheel** view instead, enter that same `task_dir` in “Task files directory.” Leave “Project directory” blank only when the DSH session's current working directory is already the task's `repo_dir`; otherwise enter the project path supplied by the assistant. A shell `cd` alone does not change the DSH session directory, and skill calls do not automatically select the view's task. Expand configuration and troubleshooting when needed, then use start, refresh, or stop. A control response's `ok` means the operation succeeded; task completion is determined by `state.status`. The view displays the last refresh time and does not poll automatically.
 
 Draft paths and fetched snapshots are retained separately for each session across view switches while the host retains that session binding; a plugin reload or desktop restart may require selecting the paths again. Path edits discard old results and reject late replies without stopping the old task. Only one control request is pending per session, and a start or stop locks directory inputs while waiting.
 

package/docs/en/model-policy.md

@@ -0,0 +1,59 @@
+# Reasoning effort and account selection
+
+[中文](../model-policy.md) · English
+
+Checked on 2026-11-05. This note separates documented capabilities, adapter behavior, engineering recommendations, and measurements. Official model documentation and request paths have been reviewed. **No representative Flywheel comparison of high, xhigh, and max has been run**, and no live user-account inference or quota check was performed. The defaults are editable starting points, not a measured optimum.
+
+## Why most bindings use high
+
+Seven of the eight stage/route bindings use `high`; Intake uses `low`. High matches the documented defaults for Kimi K3.1 Pro and DeepSeek Flash. GPT-6.1 Sol's API default is medium, so Flywheel explicitly requests a higher level. Astra's model page lists five levels without stating a universal API default. Sources: [Kimi models](https://www.kimi.com/code/docs/en/kimi-code/models), [DeepSeek thinking](https://api-docs.deepseek.com/guides/thinking_mode/), [Sol](https://developers.openai.com/api/docs/models/gpt-6.1-sol), and [Astra](https://developers.openai.com/api/docs/models/gpt-6-astra).
+
+High provides an initial comparison baseline without starting every loop at maximum effort. More reasoning can help difficult tasks while adding latency and usage; it does not guarantee a better delivery on every task. OpenAI's [deployment checklist](https://developers.openai.com/api/docs/guides/deployment-checklist) recommends representative evaluation before adopting xhigh/max for their additional cost and latency. That supports the evaluation method, not a claim that this project's defaults have already been benchmarked.
+
+## Effort values differ by backend
+
+| Current path | Checked capability | Flywheel request |
+|---|---|---|
+| GPT-6.1 Sol / Codex Pro 0.8.0 | Model supports `low/medium/high/xhigh/max`; machine API forwards effort | hard: high |
+| Sol and Astra / DSH ChatGPT provider | Models and checked provider catalog support `low/medium/high/xhigh/max`; serialized as `reasoning.effort` | Review and Judge: high |
+| Kimi K3.1 Pro / Kimi CLI | Native `low/high/max`, default high; thinking cannot be disabled | Plan, frontend, Garden: high |
+| DeepSeek Flash / DSH rc.5 | DSH accepts `off/low/high/max`, default high | ordinary execution: high; Intake: low |
+
+GPT supports xhigh and max; their absence from the defaults is a policy choice, not an interface limitation. These names are not a shared scale across providers. Kimi compatibility aliases xhigh/max/ultra resolve to native max. DeepSeek's generic API maps xhigh to high, while the DSH adapter used here rejects xhigh before that mapping because it accepts only the four listed values. Use max when explicitly selecting Flash's higher supported level. See the native model documentation above and DSH's [configuration](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/llm/llm-deepseek/src/config.ts) and [serialization](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/llm/llm-deepseek/src/serialize.ts).
+
+The ChatGPT provider snapshot is `388868f91bcdc05795fb94d21b868ded6d7219c9` (0.1.17): [dated model measurements](https://github.com/ckanner/dsh-plugin-chatgpt/blob/388868f91bcdc05795fb94d21b868ded6d7219c9/src/models/served.ts) and [request serialization](https://github.com/ckanner/dsh-plugin-chatgpt/blob/388868f91bcdc05795fb94d21b868ded6d7219c9/src/convert/request.ts). A catalog is not a live entitlement check for the user's account. The Codex Pro plugin name does not establish a separate server reasoning mode.
+
+## Stages worth comparing first
+
+These are **engineering recommendations inferred from stage responsibilities**, not measured performance results. This correction preserves effort choices; it adds no automatic escalation, effort-changing retry, or budget policy.
+
+| Stage | Baseline | Candidate comparison |
+|---|---|---|
+| Intake | Flash low | high for ambiguous input or difficult merging/classification |
+| Plan | Kimi high | max for architecture, dependency, or acceptance-design problems |
+| Execute default | Flash high | max for difficult implementation or root-cause analysis; not xhigh |
+| Execute frontend | Kimi high | max for complex interaction state or cross-component consistency |
+| Execute hard | Sol high | prioritize xhigh comparisons; max for the hardest tasks |
+| Review | Sol high | xhigh for high-impact concurrency, consistency, or permission reviews |
+| Judge | Astra high | prioritize xhigh for high-impact milestone acceptance; max for the hardest cases |
+| Garden | Kimi high | low for routine organization; max for difficult cross-task synthesis |
+
+Hard execution tackles difficult implementation. Judge independently examines a whole milestone after L2/L3, making these two stages useful first comparisons. Changing every stage together makes the cause of any improvement harder to identify. OpenAI's [reasoning guide](https://developers.openai.com/api/docs/guides/reasoning) describes effort by task difficulty; applying that guidance to Flywheel's stages remains an inference.
+
+Change `thinking` in the effective complete configuration, inspect it, and restart the engine. Use `routes.hard.thinking` for hard only and `loops.judge.thinking` for Judge only. Stage overrides avoid changing every consumer of a shared profile. A task file with only those two fields is not a complete configuration and does not inherit the rest of the project file.
+
+For an actual comparison, hold the model, backend, context, task, and acceptance conditions fixed. Measure delivery success, first-pass acceptance, missed defects and false alarms, total time including rework, and input/output/reasoning/cache usage. Record observable subscription quota separately; unknown values remain unknown. API prices do not directly determine subscription task capacity.
+
+## Request evidence is not quality evidence
+
+Source and offline protocol tests establish field transmission and error behavior. SDK configuration acceptance or a successful machine-API request establishes acceptance at that interface. Independent effective-effort evidence and improved delivery quality require server evidence or actual task measurements.
+
+DSH `initialize` validates configuration but returns only serverInfo. Flywheel's `ready.reasoningEffort` echoes the request after initialization; it is not independent model-server attestation. Codex Pro separates `requestedEffort`, `accepted`, and unknown `effectiveEffort:null`. See the [DSH SDK server](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/sdk/server/src/server.ts) and [Codex Pro 0.8.0 protocol](https://github.com/ckanner/dsh-subagent-codex-pro/blob/04ecdb677735d84f3a0f5dba01a9d9b28c324c0e/docs/machine.md). A no-inference doctor cannot establish account balance, real inference, or higher-effort benefits.
+
+## The funded DeepSeek account is the intended default
+
+Current source selects `deepseek-account` for Flash in defaults and the subscription preset. Standard desktop and SDK profiles can reuse account authorization under the same DSH home; an additional API key is unnecessary. `deepseek-official` remains a separate, explicitly chosen API-key provider, not an automatic fallback.
+
+Desktop login can initialize an account-model default, but independent SDK calls still need explicit provider/model values. Flywheel requests `deepseek-account` and `deepseek-flash`, preserving both the selected access method and the Flash-only choice. Authentication or quota failures are reported. The default preset has no cross-channel fallback; explicit user-defined fallback chains retain their existing policy.
+
+**Release and migration are separate:** 0.28.3 changes the embedded default to account access; 0.28.2 still embeds the API default. Upgrades preserve user configuration, so adoption requires 0.28.3 or later followed by explicit migration. See [Configuration](configuration.md#deepseek-account-and-api-key-providers) for credential-sharing conditions and the preview/apply workflow. No user credentials or running tasks were modified by this source change.

package/docs/en/workflow.md

@@ -2,7 +2,7 @@
 
 [English README](../../README.en.md) · [中文](../workflow.md) · [Getting started](getting-started.md)
 
-This guide describes the **0.28.0 implementation** and a recommended operating workflow. It does not assert that a particular npm version has been published. Check the registry when installing. The engine's local delivery and the host's GitHub operations are separate responsibilities.
+This guide describes the **current source implementation** and a recommended operating workflow. It does not assert that a particular npm version has been published. Check the registry when installing. The engine's local delivery and the host's GitHub operations are separate responsibilities.
 
 ## 1. Choose a model for preparation
 
@@ -14,10 +14,12 @@ For accounts that expose the named models, these are practical starting points:
 |---|---|---|
 | Ambiguous requirements, architecture, protocol, or process lifecycle changes | `chatgpt/gpt-6-astra`, `high` | Spend more reasoning on constraints, failure cases, and testable acceptance before execution |
 | A clear repository feature with known boundaries | `chatgpt/gpt-6.1-sol`, `high` | A practical default for making a concrete implementation plan |
-| A small, explicit fix or documentation update | `deepseek-official/deepseek-flash`, `high` | Keep preparation proportional to a narrow task |
+| A small, explicit fix or documentation update | `deepseek-account/deepseek-flash`, `high` | Keep preparation proportional to a narrow task |
 
 These are engineering recommendations, not benchmark results or evidence that one setting is universally best. Confirm the exact model ID and supported effort in the selected account and adapter. The checked DSH Flash adapter accepts `off/low/high/max`, not `medium`. A catalog entry or accepted configuration does not prove that real inference has succeeded.
 
+DeepSeek uses the existing signed-in, funded DSH account. `deepseek-official` API access is an explicit alternative; the default preset has no fallback to it. User-defined fallback policies remain explicitly configured. `high` remains an engineering baseline without project A/B evidence; do not automatically raise every stage to `xhigh` or `max`.
+
 Use the preparation model to identify risks and improve the contract. Increasing effort cannot repair missing requirements, an invalid test oracle, or an incorrectly chosen working directory. Later execution routes and the independent Review/Judge stages remain explicit configuration; see [Configuration](configuration.md).
 
 ## 2. Create the task integration worktree first
@@ -34,7 +36,7 @@ git branch --show-current
 
 Inspect the initial status before proceeding. These commands create a new task branch without moving the original checkout's `main`. Do not use forced branch replacement to resolve a naming collision. If a task branch/worktree already exists, inspect its state and reuse it deliberately.
 
-Keep the task at `docs/my-feature` **inside this worktree**. Run preparation and later CLI commands from this root; enter these same absolute paths in the desktop panel. Do not pair the original checkout's task directory with the new worktree's `cwd`, or change the task worktree's branch during a run.
+Keep the task at `docs/my-feature` **inside this worktree**. Run preparation and later CLI commands from this root. If using the desktop view, choose this task directory; leave its optional project directory blank only when the DSH session's current directory is already this worktree. Do not pair the original checkout's task directory with the new worktree's `cwd`, or change the task worktree's branch during a run.
 
 The engine's integration checkout is the supplied `cwd`, not a hardcoded `main` branch. Its packet branches normally use `flywheel/<slug>/<packet-id>` and start from that checkout's HEAD. Successful packet delivery fast-forwards into the branch currently checked out there. This is why choosing a task branch before starting matters.
 
@@ -53,6 +55,16 @@ flywheel template --list
 flywheel skills read flywheel-new
 ```
 
+In DSH's conversation input, select the skill from the `/` menu or send:
+
+```text
+/flywheel-new Prepare docs/my-feature for this requirement. Research the actual code, define packets, routes, boundaries and executable acceptance checks, run L1 to record the baseline, then present the contracts for review.
+```
+
+**No initial Flywheel-view form is required.** The assistant creates or reuses the task worktree, prepares `spec.md` and task packets, and reports two absolute paths: `repo_dir` for the project worktree and `task_dir` for its `docs/my-feature` task files. A project can contain several task directories; its root alone does not identify a Flywheel task.
+
+DSH uses `/flywheel-new`. Kimi uses `/skill:flywheel-new`; the prefixes are host-specific. See the pinned [DSH skill entry contract](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/client/ui-skill/README.md) and [Kimi slash-command reference](https://moonshotai.github.io/kimi-code/en/reference/slash-commands.html).
+
 A runnable task needs a reviewed `spec.md` and at least one legal `task-packet-*.md`, using the bundled schemas. The preparation should establish:
 
 - Requirement IDs, expected behavior, and scope exclusions.
@@ -90,7 +102,15 @@ Keep the PR in draft while implementation and acceptance are still changing. Ope
 
 ## 5. Run from the same task worktree
 
-With the current directory still at the task worktree root:
+After reviewing and saving the contracts, send these skill invocations separately in DSH Chat, substituting the actual `task_dir` returned during preparation. Query after starting; use the last entry when stopping is needed:
+
+```text
+/flywheel-run /absolute/path/to/repo-my-feature/docs/my-feature
+/flywheel-status /absolute/path/to/repo-my-feature/docs/my-feature
+/flywheel-stop /absolute/path/to/repo-my-feature/docs/my-feature
+```
+
+The skills resolve the project root from that existing task directory and invoke the CLI. They do not require opening or filling in the view. For direct terminal use, keep the current directory at the same task worktree root:
 
 ```sh
 flywheel config inspect --cwd "$PWD" --task-dir "$PWD/docs/my-feature" --json
@@ -101,6 +121,8 @@ flywheel control status --cwd "$PWD" --task-dir "$PWD/docs/my-feature"
 
 Preflight does not infer with a model or execute acceptance commands. Its unknown and warning results still need interpretation. Starting the real task invokes the configured models. A control response's `ok` describes the operation; final task completion is in `state.status`.
 
+To inspect the task in the Flywheel view, enter the supplied `task_dir`. Its optional project directory can stay blank only when the DSH session's current working directory is the same `repo_dir`. Current source reads it through public `workingDirectory.get(session)`; an explicit path takes precedence. A shell `cd` alone does not change the DSH session directory, so enter `repo_dir` if the session still points elsewhere. Skill calls do not automatically select the view's task, and the view does not infer, discover, or start a task automatically.
+
 ### Working directory by stage
 
 | Stage or entry | Working directory | Responsibility |
@@ -109,9 +131,11 @@ Preflight does not infer with a model or execute acceptance commands. Its unknow
 | Plan | Task integration worktree | Engine uses the startup root to revise the task contracts |
 | Execute, L1, Review | Current packet candidate workspace, normally its packet worktree | Engine creates, records, and reuses that workspace |
 | L2/L3, Judge | Task integration worktree | Engine checks the integrated milestone |
-| Intake, Garden | Selected task's worktree | Host selects the root; Go writes proposals. DSH/Codex request read-only; default Kimi has no OS-level read-only guarantee |
+| Intake, Garden | Selected task's worktree | Host selects the root; Go writes proposals |
 | Status, Stop | Original task directory and execution root | Query or stop the existing task without requiring a new worktree, branch switch, or commit |
 
+Model-call permissions follow `permissions.mode`. Under `role-based`, the default for existing files that omit this setting, Plan/Execute request `workspace-write`; Review/Judge and DSH/Codex (including Codex Pro) Intake/Garden request `read-only`. Under `full-access`, every stage requests full access through the selected backend's public interface. Kimi print retains native auto behavior and provides no claimed OS-level read-only or workspace confinement. Stage duties remain unchanged: reviewers evaluate candidates, auxiliary modules produce advice, and candidate identity checks still run before and after review. See [Configuration](configuration.md) for configuration and migration details.
+
 Every loop does not create its own worktree. The outer task worktree spans the deliverable; a packet workspace spans its execution, acceptance, review, and delivery. Plan commits valid contract revisions in the integration worktree and attempts to fast-forward existing packet worktrees to that checkpoint while preserving implementation work. Conflicts stop for resolution.
 
 `flywheel-verify` runs deterministic acceptance only. With `--packet`, it runs that packet's L1. Without a packet, it checks unfinished packets' L1 and the current milestone's L2/L3. It does **not** call Review or Judge, create worktrees, or perform local delivery. It uses the available candidate workspace and may use the integration checkout when no packet worktree is available.

package/docs/getting-started.md

@@ -8,6 +8,10 @@
 
 安装前用 `npm view @ckanner/flywheel version` 确认 registry 的 latest 已更新到所需版本；源码合并或 GitHub Release 不代表 npm 已发行。旧 0.22.1 没有本教程使用的安装与 DSH 接口，当前发行状态见[发行记录](releasing.md#3-失败恢复)。
 
+订阅预设迁移命令与 `permissions.mode` 从 **0.28.2** 开始提供。升级不会自动替换已有配置；先预览 `flywheel config migrate --preset subscriptions`，确认模型和完全权限后再以 `--apply` 应用并备份。
+
+**0.28.3 修复**：下文的 `deepseek-account` 默认和留空目录读取会话当前工作目录从 0.28.3 开始提供。0.28.2 仍使用 `deepseek-official` 与最初目录。安装前核对 registry 版本；升级保留已有配置，采用账号预设需要显式迁移。
+
 ## 目录
 
 1. [准备运行环境](#1-准备运行环境)
@@ -34,7 +38,7 @@
 | SDK profile 的 DeepSeek 和 ChatGPT provider | 默认实现／评审使用；配置与授权见下一节 |
 | Go 1.27 或更高 | 仅本文的 Go 示例和源码构建需要；npm 安装 Flywheel 不需要 Go 工具链 |
 
-安装器的前提是已有 Node／npm 和桌面 DSH；模型渠道可在安装后补齐。CLI 的登录和安装使用各自正式流程。Kimi 订阅、ChatGPT 订阅和 DeepSeek API 是三条独立渠道；安装 Flywheel 不会替这些工具登录、复制凭证或替换桌面程序。只运行默认小任务时不会使用 `hard` 路由，但所选 Plan、Execute、Review、Judge 均需要可用。
+安装器的前提是已有 Node／npm 和桌面 DSH；模型渠道可在安装后补齐。CLI 的登录和安装使用各自正式流程。默认复用 Kimi 订阅、ChatGPT 订阅和已登录、已充值的 DeepSeek 账号；DeepSeek API 是需要显式配置的可选渠道。安装 Flywheel 不会替这些工具登录、复制凭证或替换桌面程序。只运行默认小任务时不会使用 `hard` 路由，但所选 Plan、Execute、Review、Judge 均需要可用。
 
 ## 2. 一条命令安装
 
@@ -101,7 +105,9 @@ flywheel setup --no-global
 
 ### 原生 SDK profile
 
-worker 默认使用独立的 `sdk` profile。桌面已安装 provider，不代表 SDK profile 也已加载或授权。DeepSeek 使用 `deepseek-official` provider；GPT 原生路径需在 SDK profile 中配置 ChatGPT adapter，例如本轮核对的版本：
+worker 默认使用独立的 `sdk` profile。标准 SDK 叠加 `base`，已包含 DeepSeek 的账号和 API adapter。当前源码为 Flash 明确选择 `provider: "deepseek-account"`、`model: "deepseek-flash"`，复用已登录、已充值的账号；`deepseek-official` 仅用于显式选择 API key 的配置，没有自动切换付费渠道的后备路径。
+
+标准桌面和 SDK 使用同一个 `DSH_HOME` 时，可共享默认 `<DSH_HOME>/.credentials.yaml` 中的既有账号登录，不必复制 token 或把 worker 切到 `desktop` profile。自定义 home、profile 或凭证存储仍需核对。桌面当前选中的模型不会传给 SDK；Flywheel 使用自己的实际模型绑定，查看 `config inspect` 或视图的“查看模型配置”。GPT 原生路径需在 SDK profile 中配置 ChatGPT adapter，例如本轮核对的版本：
 
 ```sh
 dsh plugin --profile sdk add dsh-plugin-chatgpt@0.1.17
@@ -121,6 +127,8 @@ SDK worker 的临时权限与工具策略只用于其子进程，不改写桌面
 
 ## 4. 配置模型与 skills
 
+如果界面仍显示旧 Z.AI／GLM 或 Kimi K3，先看“配置来源”：升级会保留那份文件。包含本轮修复的新版本可用 `flywheel config migrate --preset subscriptions --cwd /repo --apply --json` 备份并迁移实际生效配置；需预览时去掉 `--apply`。任务有独立配置时加 `--task-dir`。该预设使用 ChatGPT／Kimi Code／DeepSeek Flash、约定的 thinking 和所有阶段完全权限；[迁移与权限说明](configuration.md#将旧配置切换到已有的三种资源)。已发布 0.28.1 尚无此命令。
+
 配置优先级是：**任务目录 → 项目根 → 全局 → 二进制内嵌模板**，选择第一个完整文件，不逐字段合并。默认全局路径是 `~/.config/flywheel/flywheel.config.json`；`FLYWHEEL_CONFIG` 只替换全局路径，不能越过已有任务／项目文件。
 
 查看当前二进制的配置：
@@ -165,6 +173,8 @@ flywheel skills read flywheel-run
 
 安装输出会给出 `.agents/skills` 的准确位置。按宿主支持的发现规则启用目录，不能从文件已复制推断 DSH／Kimi 已自动发现。也可直接使用 Go CLI。
 
+DSH 在对话输入框用 `/flywheel-new`、`/flywheel-run`、`/flywheel-status`，也可从 `/` 菜单选择；Kimi 对应使用 `/skill:flywheel-new` 等语法。技能名相同，调用前缀随宿主不同。正常准备、启动和查状态可以全部在对话里完成，**不必先填写 Flywheel 视图**；视图用于另外打开已经准备好的任务。可复制的完整流程见[工作流](workflow.md#3-在任务-worktree-中准备并审阅契约)。
+
 快照的 `.flywheel-snapshot` 清单记录文件内容 hash、类型与模式。重跑会跳过相同内容，更新未被修改的自有快照；用户修改、新增／删除文件、链接、未标记目录或损坏清单会保留并报告冲突。每个 skill 独立采用暂存、rename 和失败回滚，不会覆盖手工修改。旧纯文本标记只有在整个目录与当前内嵌内容相同时才能安全迁移。`--force` 只用于 `--link` 开发模式，不能绕过默认保护。安装会在全局配置缺失时创建它，但不会改写已有配置。
 
 ## 5. 运行无推理检查
@@ -188,7 +198,7 @@ flywheel doctor --cwd "$PWD" --probe --json
 flywheel doctor --cwd "$PWD" --task-dir docs/add --probe --json
 ```
 
-尚无 packet 时按规划前状态预检默认执行路由，规划后应再检查。坏契约会报告阻断项，不能用探测通过代替 schema 校验。若 cwd、权限、provider 或沙箱检查失败，先修正相应配置，不把权限改成 full access 绕过。桌面面板也提供“查看配置／检查环境／SDK 无推理探测”，使用同一个 CLI 后端；GUI 与终端环境不同的问题应在面板内复验。
+尚无 packet 时按规划前状态预检默认执行路由，规划后应再检查。坏契约会报告阻断项，不能用探测通过代替 schema 校验。若 cwd、权限、provider 或沙箱检查失败，先修正相应配置，不把权限改成 full access 绕过。桌面视图的“配置与排查（按需）”提供“查看模型配置／检查安装与配置／检查 DSH 接入”，使用同一个 CLI 后端；安装、改配置或排错时按需使用，不是每次任务都必须手点的步骤。GUI 与终端环境不同的问题应在视图内复验。
 
 这允许在准备契约时提前排查安装，但正式启动仍需至少一个已审阅的合法 packet。完成下一节的小任务准备后，再运行带 `--task-dir` 的检查。
 
@@ -196,6 +206,8 @@ flywheel doctor --cwd "$PWD" --task-dir docs/add --probe --json
 
 已有业务仓库应先建立任务集成分支和独立 worktree，再生成契约；启动时的 `cwd` 指向该 worktree。完整步骤见[从需求准备到 PR 合并](workflow.md)，下面的小仓库示例用于首次运行验收。
 
+正常在 DSH 对话中发送 `/flywheel-new` 加上实际需求，助手按 skill 创建或复用任务 worktree，准备 `docs/<slug>/spec.md` 与 task packets，然后给出两个真实绝对路径：**项目目录**是代码所在 worktree，**任务资料目录**是其中保存本任务契约和后续状态／报告的 `docs/<slug>`。无需自己预先创建空目录或填写 UI；先审阅契约，再用这份真实路径启动。
+
 首次建议使用单独的小仓库，便于分清安装问题和业务代码问题。npm 包附带的准备脚本会创建一个 Go 加法函数任务：初始实现故意错误，执行者需修复实现并补普通单测；独立 acceptance 测试不可修改。本示例需要 Go 1.27 或更高。
 
 ```sh
@@ -249,7 +261,9 @@ flywheel control start --task-dir "$PWD/docs/add" --cwd "$PWD"
 flywheel control status --task-dir "$PWD/docs/add" --cwd "$PWD"
 ```
 
-`ok: true` 只表示控制操作成功；`running` 表示引擎运行状态，最终任务结果看 `state.status`。也可以在顶部 **Flywheel** 视图填入同样两个绝对路径，按需展开“模型配置与环境检查”，再点击“启动／刷新状态／停止”。视图区分未初始化、运行、已完成、暂停、停止和升级，标明最近刷新时间；它不会自动轮询。
+在 DSH 对话中也可使用 `/flywheel-run <任务资料绝对路径>`、`/flywheel-status <同一路径>`，需要停止时用 `/flywheel-stop <同一路径>`。把占位内容替换成准备阶段给出的真实路径；这些技能会解析正确的项目根，不依赖先填写视图。
+
+`ok: true` 只表示控制操作成功；`running` 表示引擎运行状态，最终任务结果看 `state.status`。另选顶部 **Flywheel** 视图时，在“任务资料目录”填写同一个 `task_dir`。“项目目录”可留空，前提是 DSH 会话的当前工作目录已经是该任务的 `repo_dir`；任务在其他 worktree 时填写助手给出的项目路径。仅在 shell 中 `cd` 不会改变 DSH 的会话目录，技能也不会自动选择视图中的任务。按需展开“配置与排查（按需）”，再点击“启动／刷新状态／停止”。视图区分未初始化、运行、已完成、暂停、停止和升级，标明最近刷新时间；它不会自动轮询。
 
 宿主保留会话绑定期间，路径草稿与快照会按会话保留，切换“对话／轨迹／Flywheel”不丢失；重新载入插件或桌面后可能需要重新选择路径。修改路径清除旧结果并忽略迟到响应，不会停止旧任务。每个会话只等待一个控制请求；启动或停止等待期间锁定目录输入。
 

package/docs/model-policy.md

@@ -0,0 +1,61 @@
+# 推理等级与账号选择
+
+[English](en/model-policy.md) · 简体中文
+
+2026-11-05 核对。本文区分官方能力、适配器实现、工程建议和实际测量。已查模型文档与请求链路，**尚未对 Flywheel 的代表性任务做 high／xhigh／max 对照评估**，也没有在用户账号上验证额度或真实推理。因此当前默认表是可编辑的初始基线，不是测得的最优组合。
+
+## 1. 为什么当前大多使用 high
+
+现有八个阶段／路由绑定中，七个使用 `high`，Intake 使用 `low`。Kimi K3.1 Pro 和 DeepSeek Flash 的官方默认都是 high；GPT-6.1 Sol 的 API 默认是 medium，Flywheel 显式选择的 high 已高于该默认。GPT-6 Astra 的模型参考列出了五档能力，但没有声明统一的 API 默认。依据见 [Kimi 模型文档](https://www.kimi.com/code/docs/en/kimi-code/models)、[DeepSeek thinking](https://api-docs.deepseek.com/guides/thinking_mode/)、[Sol 模型参考](https://developers.openai.com/api/docs/models/gpt-6.1-sol)及 [Astra 模型参考](https://developers.openai.com/api/docs/models/gpt-6-astra)。
+
+以 high 开始是为了建立容易比较的基线，同时避免所有循环一开始都采用最高档。更高 effort 为复杂任务提供更多推理空间，也可能增加耗时与用量；并不保证每个任务都得到更好的交付。OpenAI 的[部署指南](https://developers.openai.com/api/docs/guides/deployment-checklist)建议用代表性评估判断 xhigh／max 的收益是否值得额外延迟和成本。这个方法支持先建立基线，但不能替代本项目尚未做的实验。
+
+## 2. 不同后端的档位不能直接互换
+
+| 当前调用路径 | 已核对的能力 | Flywheel 当前请求 |
+|---|---|---|
+| GPT-6.1 Sol／Codex Pro 0.8.0 | 模型支持 `low/medium/high/xhigh/max`；machine API 原样传递 effort | hard 为 high |
+| GPT-6.1 Sol、GPT-6 Astra／DSH ChatGPT provider | 模型及已核对的 provider 表均列 `low/medium/high/xhigh/max`；请求写入 `reasoning.effort` | Review、Judge 为 high |
+| Kimi K3.1 Pro／Kimi CLI | 模型原生 `low/high/max`，默认 high，不能关闭 thinking | Plan、frontend、Garden 为 high |
+| DeepSeek Flash／DSH rc.5 | DSH 接受 `off/low/high/max`，默认 high | 普通执行 high，Intake low |
+
+GPT 的 xhigh 和 max 已有支持，不能以“不支持更高档”解释选择 high。反过来，不能把 GPT 的五档照搬到每个 provider：Kimi 的兼容别名 xhigh／max／ultra 映射到同一原生 max；DeepSeek 通用 API 的 xhigh 兼容映射是 high，而本项目的 DSH adapter 会先拒绝 xhigh，因为它只接受表中四值。DeepSeek 的 max 才是这条路径可明确选择的更高档。相关原生别名以两家的模型文档为准，DSH 的限制见[参数配置](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/llm/llm-deepseek/src/config.ts)与[序列化校验](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/llm/llm-deepseek/src/serialize.ts)。
+
+ChatGPT provider 的核对快照为 `388868f91bcdc05795fb94d21b868ded6d7219c9`（0.1.17）：[有日期的模型表](https://github.com/ckanner/dsh-plugin-chatgpt/blob/388868f91bcdc05795fb94d21b868ded6d7219c9/src/models/served.ts)、[请求序列化](https://github.com/ckanner/dsh-plugin-chatgpt/blob/388868f91bcdc05795fb94d21b868ded6d7219c9/src/convert/request.ts)。它描述可请求能力，不替代当前账号的实际可用模型目录。Codex Pro 是插件名称，不能由此推导已经启用另一种服务端推理模式。
+
+## 3. 哪些阶段值得先比较更高档
+
+以下是根据阶段职责提出的工程建议，**不是已实测的性能结论**。当前修复保留原有 effort，不自动升级、重试换档或改变预算策略。
+
+| 阶段 | 保留的基线 | 更高档的评估场景 |
+|---|---|---|
+| Intake | Flash low | 输入含复杂歧义、合并或分类要求时比较 high |
+| Plan | Kimi high | 跨模块架构、依赖关系或冻结验收难以明确时比较 max |
+| Execute default | Flash high | 复杂根因分析或困难实现时比较 max；不填 xhigh |
+| Execute frontend | Kimi high | 复杂交互状态、跨组件一致性问题时比较 max |
+| Execute hard | Sol high | 优先比较 xhigh；极难实现再考虑 max |
+| Review | Sol high | 并发、数据一致性、权限边界等高影响审查可比较 xhigh |
+| Judge | Astra high | 高影响里程碑终验优先比较 xhigh；最难终验再考虑 max |
+| Garden | Kimi high | 普通整理可比较 low，复杂跨任务归纳再比较 max |
+
+hard 承担难实现，Judge 在 L2/L3 后独立核对整个里程碑；它们是较清晰的首批比较对象。对一切阶段一起提高档位，会更难知道改进来自哪里。OpenAI 的[推理指南](https://developers.openai.com/api/docs/guides/reasoning)也按任务难度区分 high、xhigh 和 max，但本表对 Flywheel 阶段的映射是工程判断。
+
+要采用其他档位，在实际生效的完整配置里修改相应绑定的 `thinking`，然后 inspect 并重启引擎。只有 hard 改档时修改 `routes.hard.thinking`；只有 Judge 改档时修改 `loops.judge.thinking`。使用共享 profile 时，阶段级覆盖可以避免无意改变所有引用者。不要创建只有这两项的不完整任务配置来覆盖整个项目配置。
+
+真正的比较应固定模型、后端、上下文、任务和验收条件，记录成功交付率、首轮通过、漏检与误报、返工后的总耗时，以及输入／输出／reasoning／缓存用量。能观察到的订阅额度变化另行记录，未知保持 unknown。API 单价不能直接换算成订阅可完成的任务数。
+
+## 4. “参数传到了”与“模型表现更好”是两种证据
+
+- 源码与离线协议测试能证明请求字段、环境变量和错误路径按契约传递。
+- SDK 接受配置或 machine API 接受请求，只证明对应接口接纳，不是效果评测。
+- 服务端实际采用的强度和质量收益，需要独立回执或实际任务测量；当前证据不能补造这些事实。
+
+DSH `initialize` 调用配置校验，但回复只含 serverInfo。Flywheel 的 `ready.reasoningEffort` 是初始化成功后的请求回显，不是模型服务独立返回的 effort 证明。Codex Pro 回执明确区分 `requestedEffort`、`accepted` 和未知的 `effectiveEffort:null`。依据见 [DSH SDK server](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/sdk/server/src/server.ts)及 [Codex Pro 0.8.0 协议](https://github.com/ckanner/dsh-subagent-codex-pro/blob/04ecdb677735d84f3a0f5dba01a9d9b28c324c0e/docs/machine.md)。无推理 doctor 也不能证明账号余额、真实调用或更高档位的收益。
+
+## 5. DeepSeek 默认应使用已充值账号
+
+当前源码已把 Flash 的默认与 subscriptions 预设改成 `deepseek-account`。它调用 DSH 账号服务，标准桌面与 SDK 在相同 DSH home 下可以复用已登录授权，不要求额外 API key。`deepseek-official` 是单独的 API-key provider，仅作为用户明确选择的配置保留，不作默认后备。
+
+桌面能在登录后初始化账号默认模型，但独立 SDK 调用仍需明确 provider/model。Flywheel 固定请求 `deepseek-account`／`deepseek-flash`，既采用指定账号通路，也保持“只用 Flash”的选择。认证失败或额度不足会报告；默认预设没有跨渠道后备。用户显式配置的后备链仍按原有规则执行，本轮不新增后备路径。
+
+**发布与迁移要分开：**0.28.3 将内嵌默认改为账号，0.28.2 仍内嵌 API 默认。安装升级保留已有用户配置，采用新账号预设需升级至 0.28.3 或以后版本，再预览并显式应用迁移。完整账号/API 区别、共享登录条件和迁移步骤见[配置指南](configuration.md#deepseek-账号与-api-key-是两个-provider)。本轮没有修改用户机器上的凭证或正在运行的任务。

package/docs/workflow.md

@@ -2,7 +2,7 @@
 
 [English](en/workflow.md) · 简体中文
 
-本文描述 **Flywheel 0.28.0**的推荐工作流。新默认 `hard` 路由使用
+本文描述 **Flywheel 当前源码**的推荐工作流。默认 `hard` 路由使用
 Codex Pro 插件 machine API；源码存在不代表 npm `latest` 已更新，安装状态见
 [发行指南](releasing.md)。下列命令是操作示例，不会因阅读本文自动执行。
 
@@ -19,7 +19,7 @@ Flywheel 将通过验收的 packet 合入任务分支；整个需求通过终验
 |---|---|---|
 | 跨模块设计、协议与生命周期、复杂边界和验收设计 | `chatgpt` / `gpt-6-astra` | `high` |
 | 范围清楚、已有代码与模式可参考的普通功能 | `chatgpt` / `gpt-6.1-sol` | `high` |
-| 很明确的小修复、文档或重复模式的补充 | `deepseek-official` / `deepseek-flash` | `high` |
+| 很明确的小修复、文档或重复模式的补充 | `deepseek-account` / `deepseek-flash` | `high` |
 
 这是工程起点，不是本项目完成的模型 benchmark。准备错误可能影响多个 packet，
 所以复杂需求值得在冻结契约前多检查一次；不必为每个小单元重复进行完整架构规划。
@@ -29,6 +29,9 @@ Flywheel 将通过验收的 packet 合入任务分支；整个需求通过终验
 
 开始前在 DSH 当前账号的模型目录核对 provider、精确模型 ID 和可选 effort。
 目录与实际请求支持也可能有差异，不能把配置示例当成账号可用性证明。
+这里的 DeepSeek 选择复用已登录、已充值的 DSH 账号；`deepseek-official` API
+是另行显式配置的可选渠道，默认预设没有通往它的后备链。用户自定义后备策略仍需显式配置。`high` 是尚未经本项目 A/B
+验证的工程基线；不要自动把所有阶段提高到 `xhigh` 或 `max`。
 `Codex Pro` 是插件名，不会自动选择 Pro 模型或最高思考档。
 默认的运行期 Plan 仍为 Kimi CLI `kimi-code/k3.1-pro / high`，详见
 [默认配置](../templates/flywheel.config.example.json)；Kimi 别名也须在本机可用。
@@ -72,10 +75,20 @@ worktree，但创建失败时会记录原因并回退 `in-place`；它没有“
 flywheel skills read flywheel-new
 ```
 
-可向当前 DSH Agent 提出：
+在 DSH 对话输入框发送（也可从 `/` 菜单选择技能）：
 
-> 按 flywheel-new 为本需求建立 docs/my-feature。先查真实代码，写清需求、
-> packet、路由、修改边界和可执行验收；试跑 L1 并记录结果，完成后供我审阅。
+```text
+/flywheel-new 为本需求建立 docs/my-feature。先查真实代码，写清需求、packet、路由、修改边界和可执行验收；试跑 L1 并记录结果，完成后供我审阅。
+```
+
+**无需先填写 Flywheel 视图。** 助手按 skill 创建或复用任务 worktree，生成
+`docs/my-feature/spec.md` 和 task packets，并报告项目根 `repo_dir` 与任务资料
+目录 `task_dir` 的真实绝对路径。前者是代码与工作区，后者保存本任务的契约、
+状态和报告；一个项目可以包含多个任务资料目录，不能把项目根直接当成任务目录。
+
+DSH 的正式技能语法是 `/flywheel-new`，不是 `/skill:flywheel-new`；后者是
+Kimi 的语法。依据见 [DSH 技能入口](https://github.com/deepseek-ai/deepseek-harness/blob/b830ec950faba0a46dda564be3e2d854afed94f1/packages/client/ui-skill/README.md)
+和 [Kimi slash commands](https://moonshotai.github.io/kimi-code/en/reference/slash-commands.html)。
 
 审阅至少覆盖：需求与 packet 的对应、L1/L2/L3 命令、失败出口、冻结验收路径，
 以及模型和权限配置。100% 覆盖率如为任务要求，应有实际可执行的门禁命令。
@@ -112,7 +125,17 @@ gh pr create --draft --base main --head task/my-feature
 
 ## 5. 从同一个任务 worktree 启动
 
-当前目录必须仍是 `repo-my-feature`，任务目录也应位于这个 worktree 中：
+契约审阅并保存后，可继续在 DSH 对话逐条发送以下技能调用，将示例路径替换为
+准备阶段报告的真实 `task_dir`。启动后再查询，需要停止时调用最后一项：
+
+```text
+/flywheel-run /absolute/path/to/repo-my-feature/docs/my-feature
+/flywheel-status /absolute/path/to/repo-my-feature/docs/my-feature
+/flywheel-stop /absolute/path/to/repo-my-feature/docs/my-feature
+```
+
+这些技能从实际任务目录解析项目根并调用 CLI，无需先打开或填写视图。
+如果直接使用终端，当前目录必须仍是 `repo-my-feature`，任务目录也在这个 worktree 中：
 
 ```sh
 flywheel config inspect --cwd "$PWD" --task-dir "$PWD/docs/my-feature" --json
@@ -122,8 +145,12 @@ flywheel control status --cwd "$PWD" --task-dir "$PWD/docs/my-feature"
 ```
 
 预检不发送模型推理，不能证明账号额度或真实模型调用已经通过。启动会实际调用
-所选模型。在 DSH 面板操作时，也填写任务 worktree 的绝对路径及其内部任务路径，
-不要把原 checkout 的 `docs/my-feature` 与新 worktree 的 `cwd` 混用。
+所选模型。另选 DSH 的 Flywheel 视图时，把准备阶段给出的 `task_dir` 填入
+“任务资料目录”；“项目目录”可留空，前提是 DSH 当前工作目录已经是同一个
+`repo_dir`。当前源码通过公开 `workingDirectory.get(session)` 读取它；显式路径
+优先，不从任务名或历史对话猜路径。仅在 shell 中 `cd` 不会改变 DSH 的会话目录，
+未切换会话工作目录时应填入真实 `repo_dir`。不要混用原 checkout 的账本和新 worktree。
+技能调用不会自动选择视图中的任务，视图也不自动发现或启动任务。
 
 每个 packet 的实现、L1 与独立 Review 通过后，引擎提交并快进合入任务分支。
 所有 packet 完成后仍需里程碑 L2/L3 与 Judge；单元合并不代表整个需求已通过。
@@ -149,10 +176,17 @@ skills 从实际任务目录解析同一 worktree 根，再调用 CLI。默认
 | Plan | 任务集成 worktree，修订任务契约 | 引擎使用启动时的根目录 |
 | Execute、L1、Review | 当前 packet 候选工作区；正常模式为 packet worktree | 引擎创建、记录并复用 packet worktree |
 | L2/L3、Judge | 任务集成 worktree | 引擎验证已集成的需求与里程碑 |
-| Intake、Garden | 所选任务所属 worktree | 入口解析目录，Go 写建议结果；DSH／Codex 后端请求只读，默认 Kimi 无 OS 级只读保证 |
+| Intake、Garden | 所选任务所属 worktree | 入口解析目录，Go 写建议结果 |
 | Status、Stop | 对应原任务路径与根目录 | 直接查询或停止，不要求为此新建 worktree、切分支或提交 |
 
-因此，每个 Loop 不会各自新建一份 worktree。任务 worktree 贯穿整个需求，
+模型调用的权限由 `permissions.mode` 决定：`role-based`（已有文件缺省）下，
+Plan／Execute 请求 `workspace-write`，Review／Judge 以及 DSH／Codex（含 Codex Pro）
+的 Intake／Garden 请求 `read-only`；`full-access` 下全部阶段通过所选后端正式接口
+请求完全权限。Kimi print 保持原生 auto，不提供可宣称的 OS 级只读或工作区沙箱。
+权限不改变阶段职责：评审只评价候选，辅助模块只产建议；评审前后的候选身份检查
+仍然执行。完整配置和迁移说明见[配置指南](configuration.md)。
+
+各 Loop 不会各自新建一份 worktree。任务 worktree 贯穿整个需求，
 packet worktree 贯穿该单元的执行、验收与评审；完成交付才由引擎处理本地合并
 与清理。恢复入口仍是 `flywheel-run`，没有另一个独立的 resume skill。
 `flywheel-verify` 只运行确定性验收：指定 packet 时只检查该单元 L1；未指定时
@@ -160,7 +194,8 @@ packet worktree 贯穿该单元的执行、验收与评审；完成交付才由
 
 Skill 的启动检查由宿主 Agent 遵守，CLI／GUI 直接调用不会自动执行这些 skill
 正文，也不会自动创建外层任务分支。直接使用控制接口时仍须显式选择正确的
-`cwd`／`taskDir`；引擎现有的 `in-place` 回退边界见第 2 节。只读查询和停止
+`taskDir` 与正确的 `cwd`（或经核实的当前会话目录默认值）；引擎现有的
+`in-place` 回退边界见第 2 节。只读查询和停止
 不受开发分支检查阻碍，便于处理异常任务。
 
 ## 6. 完整终验后再合并 PR

package/npm/install.js

@@ -335,6 +335,21 @@ async function install(options, { environment = process.env, cwd = process.cwd()
       const summary = parseDocument(result, "skills installation");
       item.summary = summary;
       if (summary.protocol !== 1 || !Array.isArray(summary.results) || summary.results.length === 0) throw new Error("invalid skills installation result");
+      if (!['created', 'existing', 'error'].includes(summary.config?.action) || typeof summary.config?.path !== 'string') {
+        throw new Error('skills installation did not report whether the model configuration was created or preserved');
+      }
+      report.configuration = {
+        path: summary.config.path,
+        action: summary.config.action,
+        preserved: summary.config.action === 'existing',
+        automaticMigration: false,
+        message: summary.config.action === 'existing'
+          ? '已有配置原样保留；升级不会替换旧模型、渠道或思考等级。'
+          : summary.config.action === 'created'
+            ? '新建全局默认配置；已有任务或项目配置仍优先。'
+            : '配置初始化失败；已有文件未被迁移。',
+        migration: { command: 'flywheel', args: ['config', 'migrate', '--preset', 'subscriptions', '--cwd', options.project || cwd] },
+      };
       requireSuccess(result, "skills installation");
       if (summary.ok !== true || summary.results.some(skill => ["error", "stale", "conflict"].includes(skill.action))) throw new Error("some skills were preserved due to conflicts; inspect the results and retry");
       report.skills = { count: summary.results.length, directory: summary.targetBase };
@@ -365,6 +380,7 @@ async function install(options, { environment = process.env, cwd = process.cwd()
       if (result.error || result.signal || ![0, 1].includes(result.code) || typeof diagnostic.ok !== "boolean" || !Array.isArray(diagnostic.checks)
         || diagnostic.ok !== (result.code === 0)) throw new Error("installed CLI returned an invalid preflight result");
       report.diagnostic = diagnostic;
+      if (diagnostic.configuration?.source) report.configuration.effectiveSource = diagnostic.configuration.source;
       report.ready = diagnostic.ok;
       if (!diagnostic.ok) { item.status = "warning"; item.reason = "components installed; resolve the reported harness/configuration prerequisites before running a task"; }
     });
@@ -407,6 +423,11 @@ async function main(args) {
     for (const item of report.steps) console.log(`  ${item.status.padEnd(7)} ${item.name}${item.error ? ": " + item.error : ""}`);
     if (report.paths?.launcher) console.log(`桌面启动入口: ${report.paths.launcher}`);
     if (report.skills) console.log(`Skills: ${report.skills.count} 个 → ${report.skills.directory}`);
+    if (report.configuration) {
+      console.log(`模型配置: ${report.configuration.path} — ${report.configuration.message}`);
+      const migration = report.configuration.migration;
+      console.log(`迁移预览: ${[migration.command, ...migration.args].map(shellQuote).join(' ')}（默认不写入；添加 --apply 明确应用并备份）`);
+    }
     if (report.ok && report.steps.some(step => step.name === 'dsh-plugin' && step.status === 'ok')) console.log("请按 DSH 提示重载插件。");
     if (report.ok) console.log("账号授权与真实模型任务尚未验证；先查看 doctor 的检查项。");
     if (report.diagnostic?.checks) for (const check of report.diagnostic.checks.filter(value => value.status === "fail")) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ckanner/flywheel",
-  "version": "0.28.1",
+  "version": "0.28.3",
   "description": "A deterministic Go orchestrator for coding-agent loops, with task contracts, verification gates, Git worktrees, and DSH desktop integration.",
   "bin": {
     "flywheel": "bin/flywheel.js",
@@ -31,17 +31,19 @@
     "CHANGELOG.md",
     "docs/getting-started.md",
     "docs/configuration.md",
+    "docs/model-policy.md",
     "docs/workflow.md",
     "docs/en/getting-started.md",
     "docs/en/configuration.md",
+    "docs/en/model-policy.md",
     "docs/en/workflow.md",
     "docs/examples/create-first-task.sh"
   ],
   "optionalDependencies": {
-    "@ckanner/flywheel-darwin-arm64": "0.28.1",
-    "@ckanner/flywheel-darwin-amd64": "0.28.1",
-    "@ckanner/flywheel-linux-arm64": "0.28.1",
-    "@ckanner/flywheel-linux-amd64": "0.28.1"
+    "@ckanner/flywheel-darwin-arm64": "0.28.3",
+    "@ckanner/flywheel-darwin-amd64": "0.28.3",
+    "@ckanner/flywheel-linux-arm64": "0.28.3",
+    "@ckanner/flywheel-linux-amd64": "0.28.3"
   },
   "scripts": {
     "release:check": "node scripts/release-preflight.js",
@@ -49,9 +51,9 @@
     "test": "node --test npm/test/*.test.js",
     "test:install": "node --test npm/test/install.integration.js",
     "test:registry": "node npm/test/registry-smoke.js",
-    "build:npm": "bash scripts/build-npm.sh 0.28.1 dist-npm"
+    "build:npm": "bash scripts/build-npm.sh 0.28.3 dist-npm"
   },
   "dependencies": {
-    "@ckanner/dsh-plugin-flywheel": "0.28.1"
+    "@ckanner/dsh-plugin-flywheel": "0.28.3"
   }
 }