Device-local Desktop onboarding
设备本地 Desktop 引导
Account users need an introduction to credit and display choices after native authentication. The native credential entry already has a separate startup responsibility; repeating browser onboarding or treating missing account data as a new user would couple presentation to authentication failures.
English
Problem
Account users need an introduction to credit and display choices after native authentication. The native credential entry already has a separate startup responsibility; repeating browser onboarding or treating missing account data as a new user would couple presentation to authentication failures.
Decision
The account UI mounts one shell overlay only when the Desktop preload marker exists, an account credential is stored, and the local introduction is unfinished. Host settings own versioned progress and completion for the installation, without a Platform completion flag or per-account history. Restart resumes the saved step; signing out hides the introduction without erasing it. A signed-out installation with configured model credentials records API-key completion after applying standard process, detailed usage, and enabled developer tools. Account sign-in discards a failed API-key completion write so retry cannot bypass the required welcome page.
Welcome requires an explicit start. The credit page always appears, including for positive balances. Only a ready balance with no positive wallet triggers the additional continue-without-credit confirmation; failed or pending queries never imply zero. Returning from native recharge retains the credit page while the account owner refreshes details. Closing the application during recharge retains the credit step.
Purpose and process selections persist as drafts. Office-only completion selects compact presentation. Development or both purposes require a process choice. Skipping any supported step selects standard process with compact usage and developer tools off. Completion applies Chat and shared developer-tool preferences before saving the done marker so a refused preference write cannot silently finish onboarding. Compact, standard, and detailed persist their corresponding ui-chat.transcriptView values.
The existing native welcome decision owns credential entry, IPC restrictions, and window material. Desktop suppresses automatic Web credential onboarding while retaining explicit API-key editing. Onboarding creates no workspace, demonstration task, or Session event. Static Figma illustrations use transparent, palette-compressed 3× PNG assets; welcome layers are merged with local sidebar blur; recharge uses a 70% opaque foreground window with local blur of the covered illustration. The account package owns the full-window overlay and its control styling; shared primitives retain generic behavior. Brand headings load a bundled, licensed Montserrat WOFF2 font through the Web entry. Choices retain focus during writes, reduced-motion preferences disable animation, and the application remains inert until the exit overlay unmounts. The confirmation dialog blurs its source page instead of sampling another backdrop in the translucent window.
Alternatives considered
Cloud or per-account completion. The current release requires device-local progress and has no account completion API. Reusing login state as completion would conflate successful authentication with finished setup.
Skipping credit for positive balances or waiting for recharge confirmation. The introduction explains billing independently of wallet state. Waiting for a balance query would turn return navigation into a network-dependent action without establishing whether a payment completed.
Duplicating preference controls. Onboarding writes work details, usage, and developer tools through their existing owners.
Consequences
An existing API-key installation without an onboarding completion marker also receives these defaults on its first upgraded launch, replacing any prior Chat display, usage, and developer-tools preferences. Installations already marked complete retain their preferences.
One installation's completion applies across account changes, and another installation runs its own introduction. Preference and completion writes are ordered but are not one transaction; retry can reapply the same preference after a failed completion write. Completed installations do not reapply preferences on subsequent launches. The controller tests and UI tests own state and interaction coverage; production authorization and payment behavior remain separate integration validation.
中文
问题
账号用户在完成原生认证后，需要了解额度并选择展示方式。原生凭证入口已经承担独立的启动职责；重复运行浏览器引导，或将缺失的账号数据当成新用户，会把展示流程与认证故障耦合。
决策
账号 UI仅在存在 Desktop preload 标记、已存储账号凭证且本地引导未完成时，挂载一个 shell 覆盖层。Host 设置持有当前安装的版本化进度与完成状态，不使用 Platform 完成标记或逐账号历史。重启恢复已保存的步骤；退出登录会隐藏引导，但不清除进度。未登录且已配置模型凭证的安装会记录 API Key 完成状态，并应用标准过程、详细用量和开启开发者工具的配置。账号登录时丢弃失败的 API Key 完成写入，避免重试绕过必需的欢迎页。
欢迎页必须显式开始。额度页始终出现，包括余额为正的情况。仅在余额已就绪且没有正余额钱包时，才额外确认是否继续而不充值；查询失败或等待中绝不表示余额为零。从原生充值页面返回后保留额度页，由账号属主在后台刷新资料。充值期间关闭应用会保留额度步骤。
用途和过程选择会作为草稿持久化。仅选办公用途时采用简洁展示并完成。选择开发或两种用途时必须选择过程详情。任意可跳过步骤均采用标准过程、简洁用量和关闭开发者工具。完成时先应用 Chat 和共享开发者工具偏好，再保存完成标记，避免偏好写入被拒绝后静默完成引导。compact、standard 和 detailed 各自持久化为对应的 ui-chat.transcriptView 值。
既有原生欢迎决策负责凭证入口、IPC 限制和窗口材质。Desktop 抑制自动 Web 凭证引导，保留显式 API Key 编辑。引导不创建工作区、示例任务或 Session 事件。静态 Figma 插图使用透明、调色板压缩的 3× PNG 资源；欢迎页图层合并并烘焙侧栏局部模糊；充值页前景窗口不透明度为 70%，仅烘焙其覆盖插图区域的模糊。账号包负责整窗覆盖层及其控件样式，共享基础组件保留通用行为。品牌标题通过 Web 入口加载附带许可的 Montserrat WOFF2 字体。保存选择时保留焦点，减少动态效果偏好会禁用动画，应用在退出覆盖层卸载前保持不可交互。确认弹窗模糊源页面，避免在半透明窗口内再次采样背景。
考虑过的替代方案
云端或逐账号完成状态。 当前版本要求设备本地进度，且没有账号完成 API。将登录状态用作完成标记，会混淆认证成功与设置完成。
正余额时跳过额度页，或等待充值确认。 引导独立于钱包状态说明计费。等待余额查询会使返回导航依赖网络，却无法确定是否完成支付。
重复实现偏好控制。 引导通过现有属主写入工作过程、用量与开发者工具配置。
后果
尚无引导完成标记的已有 API Key 安装，在升级后首次启动时也会应用这些默认值，覆盖之前的 Chat 展示、用量和开发者工具偏好；已经标记完成的安装保留原偏好。
同一安装的完成状态适用于切换后的账号，另一安装则运行自己的引导。偏好与完成状态按顺序写入，但不属于同一事务；完成标记写入失败后，重试可能再次应用同一偏好。已完成引导的安装不会在后续启动时重新应用偏好。控制器测试与 UI 测试负责状态和交互覆盖；生产授权与支付行为仍需独立的集成验证。