本计划把已核对的 DesireCore 接口整理成公开站点中的“集成与 API”区域。用户应能根据文档取得正确的服务地址和授权凭据，完成一次调用，理解响应与运行结果，并处理实际错误。实施采用主 Agent 协调、多个 subAgent 按接口能力并行核查、编写和验证的方式；先交付一个完整可用的接入流程，再按各项能力的实际进度发布扩展参考和 OpenAPI 下载。
状态：P0—P6 选定范围实施与发布验收完成。源码 #4798 已合并；文档 #72 及场景入口修复 #73 已合并并完成网站自动部署；16个API页面、8个下载和全站716URL线上验收通过。站内搜索已重抓更新，16个API页面和两篇旧更新日志搜索验收通过；已在免费额度内改为每日抓取，记录超大错误清零。更新日期：2026-10-15。
- 公开文档明确说明接口用途、支持的运行形态、可执行的接入步骤、权限和兼容范围。
- 每个公开端点都能追溯到实际注册路由、请求/响应契约、固定代码版本和发行依据。
- 首批提供至少一个从配置、调用到结果观察的完整流程。Agent Webhook 为首选试点；其配置和结果观察出现缺口时，其它已经就绪的完整流程可先进入交付批次，Webhook 的已确认事实继续供后续实施使用。
- 中文与英文页面一起交付，接口路径、字段、权限、版本和错误处理一致。
- 文档、示例、导航、两种语言构建和发布后的线上链接验证通过。
- 后续机器可读参考只包含经过筛选、验证且已公开的端点，覆盖范围在下载页明确说明。
本轮规划覆盖公开站点、内部 API 文档的必要校准，以及确实阻碍公开接入的产品或代码契约补齐。代码补齐以具体失败场景为依据，独立于文档 PR 交付；不因编写文档而重写全量服务、统一所有错误壳或建立新的权限体系。
| 来源 | 固定基线 | 用途 |
|---|---|---|
desirecore |
origin/dev：6eb08c32676d477bff2844f4ac0d6fd40013e54f |
当前实现的核查基线；实施时通过 git show <SHA>:<path> 或隔离 checkout 读取 |
desirecore-docs |
main：40ea7809113dc66d35074c26e55c2d4bd7307d70 |
内部接口说明、模块合同和设计资料 |
公开 docs |
main：34fb4a7cbc8bd2f453ee79536981d22c7448373b |
现有文档、站点结构和发布流程 |
以上是初步核查基线，逐端点的完整盘点属于 P0。实施开始时刷新相关远端，并记录新基线及其相对上述基线的接口差异。dev 的代码事实、正式客户端的支持范围和一次调用的验证结果分别记录，不能互相替代。
已确认的事实与对应实施要求：
| 事实 | 实施要求 |
|---|---|
内部 技术/API/HTTP/索引.md 收录多模块端点、开发候选和内部协议 |
逐项筛选后再进入公开清单；保留内部总索引的工程用途 |
技术/API/对外接口设计.md 的 Companion /agents/{id}/run、SSE /stream 与当前对话入口不同 |
校准其设计状态和实际协议入口，公开示例使用已注册路径 |
对话提交使用 /api/query/start、/api/query/follow-up，运行消息经 Socket.IO 回流 |
对话文档必须覆盖 HTTP 提交与 Socket.IO 关联；202 仅表示接纳，不能等同持久提交或完成 |
| Agent Service、Workflow Service、Compat Proxy 的地址和认证合同不同 | 为各服务分别核对地址、凭据、权限和结果传输方式 |
| 桌面实例端口动态分配，主实例凭据可能只在内存中持有 | 示例不能猜固定端口、教用户读取不存在的 token 文件或截取 Renderer 内部凭据 |
/health 用于探活，/api/client-handshake 仍受实例认证 |
探活、认证验证、凭据签发和用户登录分别说明；握手不发放访问凭据 |
Agent Webhook 已注册，立即返回 200 和 {accepted:true, agentId, event} |
说明后台执行语义；响应不包含 Run ID，也不证明运行完成 |
Compat Proxy 注册 /v1/messages、/v1/chat/completions、/v1/models |
只承诺已注册且经验证的协议；供应商出站支持 Responses 等能力不代表代理提供同名入站端点 |
| Workflow Service 有独立认证，部分执行入口另要求执行授权 | service token 不自动等于所有运行操作的授权；逐端点核对现行准入 |
现有站点基于 Docusaurus 3.9.2，中文默认、英文 /en/ |
首批复用 Markdown/MDX 和独立 sidebar，按实际构建验证路由 |
static/api/ 是被忽略的更新日志 JSON 生成目录 |
后续 OpenAPI 文件放入 static/openapi/，不复用更新日志插件 |
本轮固定源码为 2bb7add4497c6068a977b248106e922f9dfb196b，内部文档更新到 0b84089da1f7c050ccdab6f2912b36a8fcdb8802；公开站点的变更前基线仍为上表记录。主 Agent负责共享入口和最终验证，三个 subAgent分别完成接入/排错、Webhook、定向源码验证与文档校验器，并交叉审阅。
本地已交付 4 组中英文页面、独立 sidebar、首页/更多/集成概览及导航入口、端点清单、维护说明与离线检查脚本。pnpm typecheck、双语 pnpm build、源码的 111 项定向测试、实际 JSON 示例 Schema 和本地页面/元信息检查通过。证据及未覆盖范围见 api/verification.md。
| 原任务 | 本轮结果 |
|---|---|
| T0.2—T0.4 | 首批路由/认证/Schema/配置与结果合同已核对；未做完整内部端点盘点，组合任务保持未勾选 |
| T0.5 | 代码基线与发行线索分别记录；没有证明首次发行版本，也没有新增客户端版本约束 |
| T0.6 | 公开页校准实际响应；内部原文仍有旧示例，后续单独校准 |
| T1.4 | 本批不交付桌面配对客户端参考，未将其宣传为最小权限或重启撤销 |
| T2.1、T2.4 | 表单缺少可信运行权限配置的生成流程，从零自助配置快速开始尚未完成；本批限定管理员预配置事件调用 |
| T2.5 | 接收反馈与主动交付合同已核对，真实模型和主动交付未验收；无通用请求级结果读取 |
| T2.7 | HTTP 认证/错误边界和模拟后台失败通过；查询/存储替身范围明确，不等于完整模型运行 |
| T5.7 | 已有轻量清单/双语/JSON/构建检查；OpenAPI 尚未交付，完整一致性任务保持待办 |
| T6.2—T6.7 | 尚未发布，不宣称自动部署或线上检查完成 |
这次收窄的是首批 Webhook 的公开承诺：已配置事件的调用参考可以完成，尚未开放的自助配置直接说明暂不可用。无需等待这一产品缺口来发布成立的接入和请求合同。
| 分组 | 候选内容 | 默认实施顺序 |
|---|---|---|
| 接入基础 | 服务地址、部署形态、授权、探活、认证握手、错误排查 | P1；只给有实际接入途径的示例 |
| 外部事件触发 | POST /api/webhook/:agent_id |
P2 首选试点，先验证配置、权限和结果观察 |
| 只读实例数据 | 已验证的 Agent 列表、Run 状态、历史/回执读取 | P3 按场景筛选，逐项说明数据归属和可见性 |
| 对话执行 | query start/follow-up 与必要 Socket.IO 事件 | P3；必须形成一次完整调用流程 |
| 模型协议代理 | Compat Proxy 的 Messages、Chat Completions、Models | P4；先验证外部调用方的地址与凭据获取流程 |
| 工作流集成 | Workflow Service 触发、执行、进度和结果 | P4；先核对独立凭据、执行授权和定义引用 |
| 管理与宿主内部协议 | 密钥读取/管理、支付、内部回调、实例控制、Renderer 专属操作等 | 维持内部参考；只有存在明确外部使用场景且通过发布条件时才单独评估 |
| 规划或退役接口 | 设计页中的目标端点、开发候选、返回 410 的旧入口 | 不生成可调用示例；仅在确有迁移需要时提供替代说明 |
已有 MCP、Skill、供应商配置指南继续承担 DesireCore 连接外部能力的说明。新 API 概览通过链接引导读者选择接入路线，避免重复维护这些指南。
一个端点进入公开参考前必须同时满足：
- 已确认方法、路径和实际注册的 listener；宿主/部署能力条件明确。
- 目标读者能通过文档中的操作取得地址与所需凭据，完成身份验证。
- 权限、资源归属、审批和额外治理要求可被调用方理解并遵守。
- 请求示例通过真实 Schema；响应、错误和异步语义来自对应代码分支。
- 示例有完成判定或明确的结果观察方法；有限能力按真实支持范围描述。
- 发行支持范围已核对。客户端有效版本、协议编号和握手兼容字段分别保留含义。
- 至少一个与公开支持形态一致的完整调用经过验证，结果可追溯。
- 中英文正文和维护清单一致，文档构建与链接验证通过。
若仅某个能力未通过条件，记录具体缺口并继续实施其余已成立内容。不得用隐藏的 Renderer 标记、复制内存凭据或修改敏感配置的临时方式，把失败的外部流程写成快速开始。
首批以独立 sidebar 承载“集成与 API”，从现有“更多”和“集成能力概览”进入。具备一个完整可用流程后再加入顶部导航和首页入口；同时检查现有导航在窄屏下的空间。
| 文件 | 稳定 URL | 内容与交付阶段 |
|---|---|---|
docs/07-api/index.md |
/api |
接入路线、已经公开的能力、适用对象；P1 |
docs/07-api/_category_.json |
— | 分类链接使用 api/index，避免与 index 页重复生成路由；P1 |
docs/07-api/01-connection-and-auth.md |
/api/connection-and-auth |
实例地址、部署形态、凭据来源、权限、验证连接；P1 |
docs/07-api/02-agent-webhook.md |
/api/agent-webhook |
配置到触发再到结果观察的指南和端点参考；P2 |
docs/07-api/03-errors-and-troubleshooting.md |
/api/errors-and-troubleshooting |
实际错误结构、接收/完成区别、用户可操作的排查步骤；P1/P2 |
docs/07-api/04-conversations-and-runs.md |
/api/conversations-and-runs |
HTTP + Socket.IO 调用闭环、身份、重试和恢复；P3 |
docs/07-api/05-model-proxy.md |
/api/model-proxy |
单列模型代理地址、凭据与协议子集；P4 |
docs/07-api/06-workflow-integration.md |
/api/workflow-integration |
独立服务接入、执行授权、进度和结果；P4 |
docs/07-api/07-openapi.md |
/api/openapi |
机器参考下载、覆盖范围与使用说明；P5 |
i18n/en/docusaurus-plugin-content-docs/current/07-api/ |
/en/api/... |
镜像已发布的中文页面，文件名与 slug 相同 |
api/endpoint-catalog.json、api/README.md |
不进入站点文档路由 | 公开端点清单和维护约定；P0 起维护 |
static/openapi/agent-service.json |
/openapi/agent-service.json |
经过筛选的 Agent Service OpenAPI 下载；P5 |
方法、地址、认证和参数合同确认后，即可在工作分支编写页面并验证示例；无需等待全量端点盘点或其它服务验收。依据尚未成立的草稿留在文档路由之外。尚未通过发布条件的内容不合入发布分支、不加入公开入口；主 Agent 在每个交付批次只集成已经就绪的页面。新页面使用显式 slug；文件编号和标题调整不改变 URL。页间链接优先使用 Markdown 文件链接，让 Docusaurus 检查目标。
配套修改落点：
sidebars.ts：增加apisidebar，目录为07-api。docs/05-more/index.md及英文镜像：增加 API 概览入口。docs/02-user-guide/09-capabilities/06-integrations-overview.md及英文镜像：增加从外部调用 DesireCore 的使用路线。docusaurus.config.ts：完整流程就绪后增加 navbar 与资源 footer 入口。docs/index.md及英文镜像：增加首页入口，沿用现有布局。i18n/en/docusaurus-theme-classic/navbar.json、footer.json、i18n/en/docusaurus-plugin-content-docs/current.json：按实际新增的导航翻译，审阅生成差异。README.md：添加 API 内容维护入口；沿用现有版本与用户写作规范。若修改规范本身，同步AGENTS.md。
公开文档网站的 /api 是阅读地址。所有调用示例另写实例 BASE_URL，不得让读者把 https://docs.desirecore.com/api/... 当成业务请求地址。
完整内部盘点建议放在 desirecore-docs/技术/API/公开接口核查台账.md，保留内部候选、退役项和未解决问题。公开仓库的 api/endpoint-catalog.json 只保留实际选中的端点和可公开的维护信息。
公开清单的最小字段：
| 字段 | 内容 |
|---|---|
operationId、service、method、path |
唯一操作名、所属服务、实际方法与路径 |
doc、slug |
中文来源文件与稳定文档 URL；英文镜像按约定定位 |
deploymentModes、authentication、permissions |
支持形态、所需凭据和额外权限 |
resultDelivery |
同步响应、异步观察、Socket.IO 或 SSE 等真实结果方式 |
source |
来源仓库、相对源码路径、符号和固定 commit SHA；行号仅辅助定位 |
schemaRefs |
已有请求/响应 Schema 引用；没有响应 Schema 时记录确认方式 |
effectiveVersion、versionEvidence |
确需版本约束时填写真实版本与依据；无必要时可为空 |
verifiedAt、verification |
核查时间、已验证形态和脱敏验证记录 |
spec |
已收录该端点的 OpenAPI 文件；尚未覆盖时为空 |
清单不承载新的业务合同，不复制全量内部路由。机器可读参数以已有 Schema 为来源，行为以实际处理器为来源，公开 prose 说明用户如何操作。发生来源冲突时先校准，不能通过互相复制把错误固定到多个文件中。
可在需要时增加无依赖的 scripts/check-api-docs.mjs 和 api:check 命令，核查清单唯一性、文档及英文镜像存在性、slug、版本约束和 OpenAPI 覆盖一致性。公开仓库 CI 不依赖私有代码 checkout；代码来源复核在内部工作流执行。避免用简单字符串匹配替代真实路由注册或权限检查。
前置条件：无。
- T0.1 刷新三个仓库的远端，记录主仓、文档仓库和目标发行版本的固定 SHA；查看接口相关差异。
- T0.2 读取
技术/API/HTTP/索引.md、各功能模块 API 文档、实时事件和实际路由注册，建立完整内部台账。 - T0.3 为候选端点记录 service/listener、运行形态、鉴权、额外治理、Schema、结果方式、副作用、版本及验证状态。
- T0.4 重点核对
http-server.ts、auth/instance-auth.ts、auth/governed-endpoint-auth.ts、配对认证、query 路由、Webhook、Compat Proxy 和 Workflow Service。 - T0.5 对照可安装的客户端/部署版本，确认已发行能力与候选能力。已有明确版本保留原值，无法确定但确需标注的已可用功能遵循仓库默认版本规则。
- T0.6 校准《对外接口设计》的设计状态，补充 Agent Webhook 的现行内部合同；记录其它影响首批公开内容的差异。
- T0.7 选定首批支持形态和端点，建立公开端点清单；优先核验“部署所有者调用自己的 standalone 实例”和配置了专用 secret 的外部 Webhook。把阻碍接入的产品/代码缺口写成具体任务，浏览器和第三方应用凭据另行核验。
产物：内部核查台账、公开端点清单、首批支持矩阵、差异修正任务。
验收：首批每个端点均有实际路由、认证和发行依据；所有缺口能对应到具体用户流程，不存在以“接口已注册”代替“外部可用”的判定。当前主仓存在用户本地修改，核查和实现均不得覆盖这些修改。若创建 worktree，必须初始化并拉取最新子模块代码，记录各子模块基线及其与主仓指针的差异。
前置条件：固定代码基线、清单格式和目标 slug 约定已确定。连接认证正文依赖对应认证合同确认；站点结构、维护模板和清单校验准备可同时开始。每页发布时满足第 3.2 节条件。
- T1.1 创建 API 概览、连接认证和错误排查页面及英文镜像。
- T1.2 用实际步骤说明如何获得实例地址、如何取得/保管/撤销对应凭据；按桌面、standalone 和浏览器调用分别说明支持条件。
- T1.3 明确供应商 API Key、实例访问凭据、配对客户端凭据、Webhook secret 和代理安全 token 的不同用途。
- T1.4 核对配对凭据的实际权限与生命周期，不将当前
interactive标记宣传为严格最小权限，也不宣称重启即撤销长期凭据。 - T1.5 提供通过发布条件的只读连接验证示例；说明
/health与已认证 handshake 的作用。无法取得有效凭据的调用形态不提供伪快速开始。 - T1.6 添加独立 sidebar，以及“更多”和集成概览入口；完整试点就绪后再添加首页、navbar 和 footer。
- T1.7 建立端点页面模板与
api/README.md维护约定。 - T1.8 构建两种语言并检查稳定路由、页面链接、语言切换和导航布局。
验收：读者能判断自己适用的接入方式；所有示例变量均有真实获取途径；不会混用认证头、服务地址或客户端版本。公开正文只出现用户可理解的条件，来源 SHA、内部 PR 和验收门控留在维护清单。
前置条件：代码基线已固定，即可并行核查配置、权限和结果观察。Webhook 合同确认后即可编写页面、验证示例；发布依赖 P1 对应的接入说明与已确认的发行支持范围，不等待 P1 全部任务或其它服务完成。
- T2.1 核对 Webhook 配置的实际入口，包括启用、secret、事件名、prompt 模板和执行权限。确认用户可以通过现有 UI/获准工具操作完成配置，且由可信入口生成执行权限快照；若只能依赖内部写入，先补齐受支持的配置流程，不让读者照抄内部权限对象。
- T2.2 核对请求
event、payload、模板替换规则、1 MiB 请求体上限、启用状态与目标 Agent 条件。说明第三方原生事件需映射为 DesireCore 的请求结构，不能宣传为直接支持 GitHub 原生 body 或签名认证；priority未参与实际调度时不承诺优先级效果。 - T2.3 说明外部调用使用的 secret 验证方式；桌面回环地址的访问范围和远程部署条件分别给出。
- T2.4 提供一组无真实外部副作用的完整配置与 curl 示例，使用专门测试 Agent 和隔离数据目录。
- T2.5 明确
200 accepted只表示触发已接收，响应没有运行结果标识；验证用户可见的后台结果和失败记录观察路径。 - T2.6 核对重复调用与超时的真实行为。当前合同没有公开幂等键时，禁止建议发送方无条件自动重试；说明重复触发可能产生多次执行。
- T2.7 验证关闭/不存在 Agent、错误 secret、非法 body、未知事件、超大 body 和后台失败的处理；只补充现有测试未覆盖且影响公开承诺的回归用例。
- T2.8 交付中英文 Webhook 指南与端点参考，更新清单和首页/顶部入口。
验收：按公开步骤完成配置、发起一次触发并看到实际结果；成功响应、执行失败和请求失败能被区分。若现有结果观察不足，列出需要补齐的最小合同，例如稳定执行引用及受鉴权结果读取；独立代码任务合入并核验后再发布相应能力。仅作为异步触发发布时，页面应直接说明其有限结果能力。
前置条件：固定基线后即可开始来源核查。只读端点在自身认证、归属和响应合同确认后独立编写与验证；对话执行在 HTTP 与 Socket.IO 合同确认后进入实现与验证。发布按各自条件推进，既不等待 P2，也不让只读参考等待完整 Socket.IO 流程。
- T3.1 按真实场景选择 Agent 列表、Run 状态、历史和回执等只读端点；验证可信用户与资源归属。
- T3.2 给出 Socket.IO 客户端认证、连接、订阅、HTTP 提交和请求关联的最小完整 Node 示例，选择已有客户端库作为验证对象；核对
/socket.io/、auth.token、稳定clientInstanceId和 HTTP/Socket 的同一认证主体条件。 - T3.3 核对
clientRequestId、originSocketId、conversation/session/Run 的实际含义，明确哪个 ID 对应一次提交，哪个可跨多轮复用。 - T3.4 覆盖
query:started、follow-up 接纳、消息增量和终态等实际需要的事件；事件名与字段取自共享 Schema 和处理器。 - T3.5 说明 HTTP 响应和 Socket 事件无固定到达顺序，以及接纳、持久提交、运行和完成的区别。
- T3.6 验证同请求 ID 重试、请求体变化冲突、接纳结果未知、断线重连和结果对账；不要把未来事件回流写成离线事件重放。
- T3.7 核对取消、审批等待和错误恢复的当前支持范围；只使用已经验证的入口。
- T3.8 将通过验收的只读参考与完整对话示例分别交付中英文页面，更新端点清单；可以同批集成，任一就绪内容也可独立交付。
验收：只读参考分别完成可执行接入、权限/归属检查和响应验证，即可独立交付；对话流程则要求外部测试客户端能从授权连接开始，提交任务并关联结果，处理一次断线或接纳未知情况。不得把对话流程写成简单 POST 后同步返回最终答案，也不得将历史日志描述为可以重放全部副作用。
前置条件：固定基线后即可分别核查模型代理与 Workflow。每项方法、地址、认证和参数合同确认后，编写页面、验证示例与必要代码补齐可按文件归属并行。发布时各自满足第 3.2 节条件，不依赖 P2/P3 或另一项 P4 能力完成。
- T4.1 验证通过现有
InspectModels/ComputeCredential等受支持工具取得 Compat Proxy 地址与desirecore_安全 token 的实际流程，判断该流程是否可作为长期外部接入合同。内部进程 capability 不作为外部凭据获取方法；管理端点不被误写成 token 签发端点。 - T4.2 核对安全 token 的 Provider 绑定、撤销、生命周期、模型列表范围和实际权限；不宣传尚未实现的预算/模型级限制。
- T4.3 分别验证 Messages、Chat Completions 和 Models；按实际 Provider/后端说明兼容子集、流中错误、用量与重试，不承诺完整供应商 API 覆盖。
- T4.4 保留用户可判断的供应商授权条件；代理接入不改变账户和订阅的使用资格。
- T4.5 核对 Workflow Service 的独立 origin、
X-Workflow-Service-Token、当前端点和额外执行授权。旧POST /api/workflows已退役，不能进入新示例。 - T4.6 验证工作流 webhook 与 run 入口各自的主体、定义引用、执行授权和结果可见性；
executionGrantId等授权字段必须通过受支持流程取得。 - T4.7 对通过核验的能力分别创建中英文指南；缺少实际获取流程的能力继续记录在内部台账。
验收：本批发布的每项能力各有可执行接入闭环、对应凭据和实际协议范围，支持条件与现行治理规则一致。尚未发布的能力继续记录在内部台账。
前置条件：清单格式和某个候选公开端点的请求/响应合同已确认，即可生成该端点 spec 草稿。清单校验器在格式与 slug 约定固定后开始，不等待全量页面或 spec。下载发布与相应页面的公开条件一起验收，不必等页面已经上线后才编写 spec。
- T5.1 从公开清单建立 Agent Service 的 OpenAPI 子集；保留原路径、字段、状态码、错误体和媒体类型。
- T5.2 尽量复用共享请求/响应 Schema；缺少响应 Schema 时先从处理器与验证结果确认合同，不凭模板补造响应壳。
- T5.3 描述静态 spec 的适用部署和权限限制；多个认证条件或额外治理不能被一个通用 Bearer 定义掩盖。
- T5.4 Socket.IO 契约继续单列事件文档，避免伪造普通 HTTP/SSE 端点。Workflow 和 Compat Proxy 若提供 spec，使用独立文件与服务器定义。
- T5.5 校验 OpenAPI 文法、operationId、paths、示例与 Schema，确认与该 spec 声明的服务及端点子集一致；清单记录对应 spec，下载页说明尚未覆盖的公开能力。记录规范版本，保留客户端版本的独立意义。
- T5.6 发布下载页与
static/openapi/文件，确认两种语言能访问同一份机器合同。 - T5.7 为公开页面/清单/spec 一致性加入适量自动检查，发现端点或版本差异时要求来源复核。
验收：下载文件只包含公开合同，声明的操作和示例通过检查。首批保持 Markdown/MDX 展示；只有端点数量和检索需求确实需要时，再评估 API 渲染组件或 SDK 生成。
每个端点或单一能力页按以下顺序组织：
- 能做什么、适合哪个场景、在哪里使用。
- 支持的客户端/部署形态、所需配置、权限与授权条件。
- 获取服务地址和凭据的操作步骤。
- 实际 Method、Path、Headers、参数表、可解析请求示例。
- 实际响应与完成判定，异步接口的结果观察方式。
- 端点自己的错误字段、HTTP 状态、触发条件和调用方动作。
- 已支持的重试、幂等、取消、分页或恢复行为及限制。
- 完整调用示例、用户可见的排查方法、相关指南。
按 AGENTS.md 与 README.md 执行生效版本规范。已有明确版本保留真实编号；确需标注且无法确定的已可用功能使用 v10.0.178+。中文标题“生效版本”、英文标题“Effective version”，版本号格式 vX.Y.Z+。只约束相关功能，不能把默认版本用作未发行功能已经可用的证据。协议修订、配置版本和示例版本保留原含义。
代码示例只使用测试数据和占位凭据；变量的来源要讲清楚。不能包含真实 token、用户内容、机器上的绝对私有目录，或无法复制执行的 JSON 注释。公共页面不放开发分支、源码配置快照、PR 合入或作者验收告诫；这些内容放进维护台账。
同时核对现有集成概览中的审计承诺。只描述实际记录的内容与可见入口，避免把“所有请求响应完整记录”或“满足企业合规”作为未经验证的通用保证。
| 验证层 | 必须检查的内容 |
|---|---|
| 来源核对 | 方法/路径、注册条件、认证、治理、Schema、状态码与结果合同 |
| 示例验证 | 请求可解析并通过 Schema；公开步骤在支持形态中成立；结果判定准确 |
| 行为验证 | 成功、无效凭据、无效输入和该端点关键异步/权限失败；复用已有测试 |
| 语言与版本 | 中文/英文契约一致；已有版本保留；有效版本与协议编号不混用 |
| 站点构建 | 两种语言构建、broken links、稳定 slug、HTML 元信息和 sitemap |
| 页面体验 | 语言切换保持同页、sidebar、入口、代码复制、长路径/表格窄屏阅读 |
首批不连接真实生产凭据、不执行有真实外部副作用的任务。运行验证使用固定版本、测试 Agent 和隔离数据根，记录支持的平台与部署形态；未覆盖形态不写成已验证支持。只针对具体未解决风险补充测试。
优先复用的现有验证入口（相对于 desirecore）：
| 范围 | 已有测试文件 |
|---|---|
| Webhook 权限与结果记录 | packages/agent-service/src/__tests__/webhook-permissions.test.ts、packages/agent-service/src/routes/__tests__/webhook-state.test.ts、webhook-prompt-manifest.test.ts |
| 实例与配对凭据 | packages/agent-service/src/__tests__/instance-auth.test.ts、instance-auth-attached-client.test.ts、standalone-config.test.ts |
| 对话来源与消息回流 | packages/agent-service/src/__tests__/query-routes-follow-up-origin.test.ts、renderer-delivery.test.ts |
| 代理安全 token | packages/agent-service/src/__tests__/compat-proxy/server-safe-token.test.ts、packages/agent-service/src/compute/__tests__/safe-token.test.ts |
| Workflow 授权与退役入口 | lib/workflow-service/__tests__/access-auth.test.ts、definition-write-retirement.test.ts、run-admission.test.ts、semantic-run-grant.integration.test.ts、http-run-smoke.integration.test.ts |
表中同一单元格的简写文件名沿用前一个完整目录；执行前核对当前测试脚本及其依赖。既有 smoke 也需确认适配当前合同，测试通过不代替公开示例的发行版本验证。
建议执行命令：
pnpm install --frozen-lockfile
pnpm typecheck
pnpm build
pnpm exec docusaurus serve --host 127.0.0.1 --port 3000新增清单校验器后执行 pnpm api:check。pnpm build 应构建中文和英文；现有配置 onBrokenLinks: 'throw' 必须保留。API 页面读取、语言切换与导航至少检查 1440、1280、1024 和 375 像素宽度；只针对溢出或阅读问题调整现有样式。
本地检查生成 HTML 的 canonical/hreflang，以及 build/sitemap.xml、build/en/sitemap.xml 的新增页面和暂缓页面范围。现有 scripts/check-sitemap-links.mjs 即使读本地 XML，也访问其中的生产 URL；部署前不能把它当本地预览验证。
- T6.1 审阅最终 diff、支持矩阵、脱敏验证记录和中英文页面。
- T6.2 按批次创建
codex/分支与 PR；涉及其它仓库的前置修正分别发布并记录依赖。 - T6.3 进入发布流程后，将已验证改动合并/推送到公开仓库
main，等待自动部署结果。按仓库规范无需手动执行 Vercel 部署命令。 - T6.4 核对线上
/api、/en/api、已公开叶子页面、语言切换及 OpenAPI 下载（若本批包含）。 - T6.5 部署成功后执行
pnpm sitemap:check，验证生产 URL、canonical、robots、跳转和软 404。 - T6.6 检查新增内容的搜索可发现性；区分搜索爬取延迟与页面部署失败。
- T6.7 回写本计划状态、公开端点清单与内部台账，记录最终代码/文档/发行基线。
发布后若发现错误的调用合同，先修正文档承诺与示例并重新走 Git 自动部署；必要时撤下有误的入口/下载项，保留合理迁移路径。仅回退公开文档提交不应修改客户端数据或权限配置。
当前执行环境共有 4 个并发槽，采用 1 个主 Agent + 最多 3 个活动 subAgent。主 Agent 持续负责基线、跨模块决定、共享文件集成和发布；subAgent 完成独占的接口能力任务。下表中的工作角色可多于 3 个，但按可用槽滚动调度，不要求所有角色同时运行，也不假设能获得更多槽位。
P0—P5 表示工作范围，不能作为全局串行阶段。主 Agent 先完成 T0.1 并固定共同输入；之后按具体依赖派工，任一能力完成核查就启动其下游任务。某个能力有产品缺口时，该能力保留待解决任务，释放可用槽去做其它就绪工作。
默认优先保障接入基础和 Webhook 首批交付。接入基础的契约确认后，空闲槽立即推进只读数据/对话、代理、Workflow 或机器参考。只要存在就绪任务和空闲槽就继续调度，不等整批 subAgent 一起结束。
每个工作包开始时明确唯一编辑者和完整文件清单；同一能力的中文、英文、示例和验证由同一个 subAgent 负责。需要另一 agent 校核翻译或协议时，校核者只返回修改意见，交由文件负责人应用。
| 工作包 | 对应任务 | 独占产物/编辑范围 | 输入依赖与交付方式 |
|---|---|---|---|
| 主 Agent：基线、发行和集成 | T0.1、T0.5、T0.7；各域 T0.6 的汇总；T1.6—T1.8；T6.1—T6.7 | PLAN.md、内部总台账、api/endpoint-catalog.json、api/README.md、API index.md/分类文件、sidebar、配置、所有入口页与全局翻译文件、根 README/AGENTS |
固定输入和文件归属；汇总领域记录，分批构建与发布 |
| subAgent 接入基础 | T0.2—T0.4 的 HTTP/认证/配对部分；T1.1—T1.5；T1.7 的模板建议 | 01-connection-and-auth.md、03-errors-and-troubleshooting.md 及各自英文镜像；独立认证验证记录 |
基线确定后立即开始；其它领域提交自身错误事实，由本负责人整合到公共排查页 |
| subAgent Webhook | T0.2—T0.4 的 Webhook 部分；T0.6 的 Webhook 合同补充；T2.1—T2.8 | 02-agent-webhook.md 与英文镜像；Webhook 配置/示例/测试；单独内部 Webhook 合同文件 |
与接入基础并行核查、编写；发布依赖对应认证/地址说明和实际配置/结果验证 |
| subAgent 只读数据与对话 | T0.2—T0.4 的 Agent/Run/Socket.IO 部分；T3.1—T3.8 | 04-conversations-and-runs.md 与英文镜像；独立示例客户端和领域验证记录 |
核查可从固定基线开始；先使用已确认认证合同推进只读参考，再推进完整对话流程 |
| subAgent 模型代理 | T0.2—T0.4 的 Compat Proxy 部分；T4.1—T4.4、T4.7 的代理部分 | 05-model-proxy.md 与英文镜像；代理示例/测试/验证记录 |
独立核查和验证地址、凭据、协议子集；向主 Agent 提交清单条目 |
| subAgent Workflow | T0.2—T0.4 的 Workflow 部分；T4.5—T4.7 的 Workflow 部分 | 06-workflow-integration.md 与英文镜像；Workflow 示例/测试/验证记录 |
独立核查执行授权与结果合同；与代理和对话无阶段依赖 |
| subAgent 其它模块盘点 | T0.2—T0.4 中未分配的功能 API 文件 | 按文件分片的内部核查附件；尚未选择的其它端点不生成公开页面 | 主 Agent从完整文件清单分配互不重叠的模块；可在任何空闲槽推进，不阻塞已选择能力的首批交付 |
| subAgent OpenAPI | T5.1—T5.6 | 按服务分配的 static/openapi/<service>.json、07-openapi.md 及英文镜像；spec 验证记录 |
每个端点合同确认即编写；接收领域负责人确认的 Schema/行为，按服务逐项完成 |
| subAgent 清单校验 | T5.7；第 5 节清单检查 | scripts/check-api-docs.mjs、独立校验输出 |
清单格式/slug 约定确定即可开始；package.json 命令由主 Agent统一接入 |
表中领域的 T0.2—T0.4 是同一盘点任务的互斥分片，不重复全仓研究。主 Agent维护完整文件清单和分配状态，保证剩余功能模块也被覆盖。T0.5 由主 Agent汇总发行证据，各领域只提交自己端点的依据。T0.7 的最终公开决定和清单写入由主 Agent负责。T1.1 的 API 概览由主 Agent汇总，接入基础 subAgent 负责其余两页；其交付并停止编辑后，共享接入/错误页的后续补充可正式转交主 Agent。
需要补齐主仓代码时，按实际模块把源文件和对应测试纳入领域负责人清单。公共 routes/index.ts、认证中间件、共享 Schema 聚合出口、根依赖文件和 docs 子模块指针只能由主 Agent 或其指定的唯一负责人编辑；领域负责人提交所需改动说明，不自行重复修改。代码/合同改变后，主 Agent只重新调度受影响页面、示例和 spec 的校核。
| 调度时段 | 主 Agent | 槽 1 | 槽 2 | 槽 3 | 启动下游的条件 |
|---|---|---|---|---|---|
| 起步 | 固定 T0.1、分片范围、清单/slug 约定与共同源码基线 | 等待共同输入 | 等待共同输入 | 等待共同输入 | 输入固定后立即派工 |
| 首轮 | 核对发行证据，准备维护约定、独立 sidebar 和入口改动 | 接入基础核查与页面 | Webhook 核查、配置验证与页面 | 模型代理核查，提交确认部分后接 Workflow | 各能力分别提交事实；不等待全 P0 |
| 持续推进 | 接受领域事实并更新清单；准备首批集成 | 基础完成后转只读数据/对话 | Webhook 完成或出现外部阻塞后转 OpenAPI/校验 | 代理与 Workflow 按各自条件推进 | 谁先释放槽，就派当前最高优先级的就绪工作包 |
| 首批集成 | 冻结本批共享文件，完成统一构建与页面预览 | 校核首批协议和版本，或继续对话工作 | 校核首批示例/双语，或推进 spec | 继续代理/Workflow 或执行独立验证 | 审阅本批固定快照；后续写作不进入同一构建快照 |
| 后续交付 | 接收新能力、分批验证和 Git 发布 | 对话/只读域的剩余任务 | OpenAPI 或清单检查 | 代理/Workflow 的剩余任务 | 每项满足发布条件就进入下一可发布批次 |
上述时段用于说明槽位复用，不设统一开始/结束屏障。主 Agent可以交换槽位任务；派工时只需保持文件唯一编辑者、明确依赖和共同输入。工作包已经完成的部分直接供下游使用，后续补充只通知受影响负责人。
| 依赖节点 | 放行的工作 | 必须等待的工作 |
|---|---|---|
| 固定代码及子模块基线 | 所有领域的路由、权限、Schema 和版本依据核查 | 不同基线内容不能直接合并为同一合同 |
| 清单字段、operationId 和 slug 约定 | 清单校验器、站点结构、页面模板；各领域分别提交条目 | 全量清单写入、全局翻译生成由主 Agent执行 |
| 某能力的方法/地址/认证/请求响应合同确认 | 该能力中英文编写、示例验证、OpenAPI 草稿可并行 | 该能力上线仍需发行依据与完整验证 |
| 公共认证/配对合同确认 | 接入页、已筛选只读端点验证、对话客户端认证部分 | 查询回流部分仍等待该领域的 Socket.IO 身份与事件确认 |
| Webhook 的配置和权限入口确认 | Webhook 示例与错误场景验证 | 结果观察缺口影响该能力发布，不阻塞其它能力 |
| 某批页面/示例/spec 通过领域验收 | 主 Agent合并本批清单、入口与翻译，形成固定构建快照 | 双语构建、最终跨页校核和发布按固定快照顺序执行 |
后续依赖按端点记录。例如一项只读端点的参考不依赖对话客户端实现；代理文档不依赖 Workflow；spec 可以与对应页面在同一个批次发布。04-conversations-and-runs.md 可先交付已经验证的只读章节，尚未成立的执行示例留在路由外草稿。读取源码、编辑独立文档和在隔离实例运行验证可以重叠执行。
主 Agent派工时向 subAgent 提供：目标与原任务编号、固定源码/子模块 SHA、独占文件清单、已经确认的认证/版本/slug 约定、所需输出和完成条件。subAgent 不重新 fetch 或切换公共 checkout；发现基线之后的相关改动时先报告，由主 Agent判断是否更新受影响输入。
每个领域交付一份简洁记录，包含实际方法/路径/注册条件、Schema 与认证/权限、发行依据、示例及验证结果、尚未成立的用户步骤、拟发布的中英文页面和清单条目。共同字段引用已有接入合同，不重复生成新的通用规则。成果可作为报告交接；需保存时按领域存放在内部台账的独立附件，主 Agent合并总表。
进度按“核查完成”“文档/示例完成”“验证完成”“本批已集成”“已部署”分别报告，避免把 subAgent 结束当作能力已发布。主 Agent负责更新本计划复选框；组合任务只有对应分片均完成时才勾选。存在待解决缺口的领域仍提交已确认事实，避免下游重复研究。
- 持续写作与集成构建需要重叠时，优先采用主 Agent集成 checkout 加各领域独立 docs worktree；主 Agent只接收已验收文件或提交。仅有独立文档编辑、暂不构建时，也可在同一实施 checkout 按独占文件并行。共享文件保留唯一写入权；原负责人停止编辑并交付后才能转交归属。
- 主仓代码补齐或运行实例验证按领域使用独立 checkout/工作目录、数据根、端口和测试进程；创建 worktree 时按仓库规范初始化并拉取最新子模块代码，记录基线后再派工。子模块与共同输入出现差异时由主 Agent统一处理。
- 中文和英文由同一能力负责人完成；全局
write-translations、根目录依赖安装、锁文件更新、Git 切分与子模块指针由主 Agent串行执行。 - 互不共享状态的领域验证可并行；先确认数据根重定向覆盖所有读写路径。Webhook 与对话需两套独立 Agent Service 实例；代理独占 token/算力配置和上游假服务；Workflow 独占定义 store、owner lock、运行历史与回调。使用同一 HOME、端口、进程级单例、环境配置或可写 fixture 的测试必须先隔离，无法隔离的测试串行执行。同一实例的 start/stop、token 轮换、状态重置与清理顺序执行。
- 需要操作真实桌面 UI 时只指定一个活动操作负责人；其它 subAgent继续源码核对、文档或隔离 HTTP 验证。
- 同一个 checkout 的 Docusaurus build、clear、dev/serve 和生成翻译操作由唯一负责人调度，避免竞争
.docusaurus、build和生成的static/api/输出；只指定不同 build 输出目录不足以隔离这些写入。构建时固定本批输入，同 checkout 的 agent暂停修改会影响构建的文档/翻译/静态资源和配置；其它 subAgent 可在别的 checkout 或路由外草稿继续后续批次。生成目录不进入提交。 - 独立源码审阅、双语校核和示例验证可同时进行；主 Agent收到结果后统一应用共享改动。每批只完成必要构建与验证，失败修正后重跑受影响检查。
必须由主 Agent协调的顺序是：共同输入固定 → 各领域确认所需合同 → 本批公开范围与共享文件合并 → 固定快照构建/预览 → Git 发布 → 等待自动部署 → 线上检查 → 回写状态。只有相关下游依赖这个顺序；其它领域的研究、编写和隔离验证继续并行。
最终集成前进行一次跨页核对：同一凭据、版本、端点和错误语义在基础页、能力页、清单和 spec 中一致；每个公开页面的中英文已齐备。解决接口解释冲突后再进入构建，不让多个 agent分别“修正”共享合同。
| 批次 | 交付内容 | 完成条件 |
|---|---|---|
| 批次 1 | P0 台账、来源差异修正、首批范围与公开清单 | 候选有可核验出处，接入缺口具体化 |
| 批次 2 | P1 接入基础 + P2 Webhook 完整试点 | 优先一起交付；就绪的只读参考或 spec 可同时纳入，读者可以完成实际调用 |
| 批次 3 | P3 只读数据或 HTTP + Socket.IO 对话流程 | 各域分别满足权限与响应、或提交/结果/重试恢复验收，不互相等待 |
| 批次 4 | P4 模型代理或工作流指南 | 每项各自满足地址、凭据、权限和结果合同条件 |
| 批次 5 | P5 OpenAPI 与维护检查 | spec 与所声明的公开端点子集一致，下载页说明覆盖范围 |
批次编号用于划分 review 与发布范围，不规定所有工作串行。首批通常由接入基础与 Webhook 构成；其它已经满足条件的能力或 spec 可提前纳入，尚未完成的领域继续并行。每批都完成第 8 节对应检查，不因提前集成而降低发布条件。
| 事项 | 默认处理方向 | 解决阶段 |
|---|---|---|
| 首批支持哪个运行形态 | 优先核验部署所有者的 standalone 调用与专用 secret Webhook；其它形态按地址和凭据获取流程逐项确认 | P0 |
| Webhook 配置和结果观察是否能由目标用户操作 | 核查已有入口；有缺口时提出最小产品/代码补齐任务 | P0/P2 |
| Webhook 是否需要程序化结果与幂等 | 当前先按真实异步触发能力描述；明确业务场景需要时补稳定执行引用/查询和幂等合同 | P2 |
| 是否公开对话执行入口 | 以外部凭据与 HTTP + Socket.IO 完整流程为条件 | P3 |
| 代理凭据与地址是否有支持的获取方式 | 验证现有 ComputeCredential/受支持配置流程；缺口明确后再决定补齐方式 | P4 |
| 是否加入顶栏 | 首个完整调用流程就绪后加入，验证现有导航折叠与窄屏布局 | P1/P2 |
| 是否引入 OpenAPI 渲染组件或 SDK | 首批维持现有工具；按端点规模、兼容需求和实际使用者再评估 | P5 后 |
这些事项是实施任务，当前计划可直接用于逐项核查。执行者应先完成能推进的任务，再针对确实依赖产品选择的缺口给出具体方案。
| 日期 | 修订 | 内容 |
|---|---|---|
| 2026-10-13 | 初版 | 固定初步代码基线，定义公开条件、站点落点、P0—P5 任务、分批交付和验证/自动部署流程 |
| 2026-10-13 | 并行实施修订 | 改为主 Agent + 3 subAgent 滚动调度，按能力确认合同后启动下游；明确独占文件、双语归属、工作目录隔离、共享集成节点和可重叠发布批次 |
| 2026-10-13 | 首批本地实施 | 完成双语接入基础与预配置 Webhook 参考、站点入口、维护清单与验证；记录自助配置和结果关联缺口，未执行发布 |
实施中更新任务复选框与验证依据；范围、协议或发布策略变化时，在本表记录理由与影响，保持正文为当前有效计划。
- 主 Agent：共享入口、24 个端点清单、79 份内部 API 文档盘点、旧设计/响应校准，源码最小接入缺口、统一验收与发布。
- subAgent 对话/审阅：可运行 Node.js 示例、12 个隔离合同用例和真实路由夹具；Webhook 指南与并发权限快照交叉审阅。
- subAgent 指南/运行：对话与 Run、模型代理、Workflow 双语指南，隔离代理/工作流链路验收。
- subAgent 规范/验证：三个 OpenAPI 子集、真实 owner Webhook 运行与用户交付验证、规范检查。
新增代码复用 owner 治理、工具注册表、文件范围求交、Agent 原子写入及既有审批。Webhook 新配置入口只在握手声明支持时使用；无请求级结果 ID、通用幂等与自动最终回答交付的限制保留。代理地址取实际成功监听端口。Workflow 的 grant 运行入口不进入公共示例。
刷新发现 origin/dev 已推进到 c09c3196ad3a5430aa4d4fc100769db0d6d0527b，包含 query 可选应用准入与后台工具过滤。源码 PR 将在该基线重新集成，并只重验受影响合同；最终来源 SHA 与证据回写维护文件。
接口代码固定 d3bac348db5f15ce6a59469ffef8f495c84ced59，最新rebase只合并docs指针，保留并行应用文档；接口代码与118项定向回归的代码树一致。内部文档固定 10b6007b7e46477ee4df2e15563f09c1ab7bd1fe，远程main可达。原80份固定快照另补并行新增的应用接口文件，81份API文档与855个字面量路由调用用于发现，公开24操作逐项验证，内部新应用参考保持内部分类。
发行线索核对 v10.0.180 tag 5537110f3b286736f12d5babff66eabf48d59368；存在旧query/Webhook/proxy/workflow路由不等于新管理能力已发行。新功能用实际握手能力条件，未反推首次发行号或追加默认版本。
三份规范0错误，51个Schema/34个media示例通过。双语构建、元信息与下载副本一致性通过，四种宽度六页无整页溢出，语言切换保持对话同页。代码复制仅确认按钮反馈，剪贴板内容未取得。
源码 #4798 与公开文档 #72 已创建。Vercel预览成功、CLA通过；源码剩余主门禁继续验收。CodeQL指出XML实体串联替换可能重复解码，校验器改为单次正则匹配，保留嵌套编码一层；该修复不改变页面或接口合同。尚未合并上线。
本次新增能力的2处元信息期望遗漏已修复（4个单文件用例通过）；另外16失败由固定CI基线的9文件16用例隔离实跑完整复现，证据见 api/ci-base-attribution.json。上游PR #4793已包含其对应修正，但新增application-object fixture暴露导航测试清单遗漏。独立PR #4801仅同步测试类型清单，并保持current pin、consumer错配及注入拒绝断言；11单文件用例和13受控类型边界通过。
发布依赖顺序为 #4801 → 上游 #4793 → API代码 #4798 → 公开文档 #72 → 自动部署和线上验收。代码与文档实施已完整，合并与上线仍须完整门禁成立；不把基线复现失败统计成成功验收。
#4801 已合并到 dev（c1cdd01bb15e1b9db9ec8c64ae5a4cf88fbaa3bb）。上游 #4793 最新 33926b9d243b4f2bd6ea36b2e7634e347ec33d6b 相比先前检查版本新增应用对象导航，但本轮24个公开端点及 query/Socket.IO/Run 合同无变化。
隔离工作树提前衔接该上游，得到本地快照 66ee3deb567a7bbcbe1bde2f48f352a129c39ec0，docs 采用已推送且保留双方变更的 f620bc410063301cb5828f2ad63f9a10ce61f086。限定11个API生产文件与已测 74058cea9 完全一致；单 worker 串行补验18项unit和1项真实Webhook管理integration全部通过，ADR/代码声明检查通过。该快照尚未推送，不替代当前PR的完整CI。
截至本次记录，#4793 的 Board Engine、资源测试和三平台native检查通过，static/unit仍运行；#72 的CodeQL、CLA与Vercel预览全部通过。部署后16个双语页面与8个下载地址的生产验收脚本已准备；尚未执行生产检查或宣称上线。
上游 #4793 的 static/unit/resource 与三平台检查全部通过，已合并为 27b5709681f3ede8f5bce8eae02e925fd3f38dd3。源码 #4798 最终 HEAD 3801f4d79cd4e578b8f3e006913a0c552e3763f3 的 CI、Standalone、Board Engine、三平台 native 检查全部通过，已合并为 e45f22902af2dc45b109cfa8f454795538aea2ed；不重复合并已完成的 PR。
来源清单与三个规范固定到最终源码，内部 docs 指针为远程可达的 9cc47fc9216db4a3803a982f00649f7af667c933。33个端点来源/Schema文件仅认证 gate 导入方式调整，调用顺序和24端点合同不变。外围用量消息增加可选模型字段、回执按实际响应归集模型身份；现有指南与客户端兼容，不追加新字段保证或客户端版本约束。原定向运行结果仍按各自固定基线记录。
公开分支已衔接最新 main，保留三个发行版的并行更新日志。部署前生产/API路径及规范下载返回404、sitemap尚无API条目，作为上线前快照；上线验收须等公开PR合并与自动部署成功后执行。
公开PR #72 在最终HEAD 8f808384d3cc8668998c2f097145cbeb0dc12f15 全部7项检查通过后合并。主分支提交 93fcbd26c64465e147b8c6532f48c1558a3c989a 的Production deployment 7088235715 于北京时间16:54:38成功；未手动执行Vercel部署。
严格生产验收16页、8下载全部200，canonical、语言/同页alternate、可索引性、两语言sitemap条目、robots及下载字节/规范来源全部通过，逐项报告见 api/production-verification.json。浏览器从中文对话指南切换英文，保持同页，英文正文和API导航渲染正常、无整页水平溢出。
全站718URL均200，但 /use-cases 与 /en/use-cases 的canonical被目录README隐式索引覆盖为尾斜杠地址。作者资产说明已重命名为默认排除的 _README.md，不改正常入口slug、不放宽验收器。待该修正自动部署后重跑全站检查，再完成T6.5。
场景入口修复 #73 已合并为 5d9cef1eac584ffa8c925636ac5d24ae174e5150，Production deployment 7088538260 于北京时间17:09:54成功。部署后 pnpm sitemap:check 716URL全部200，canonical/robots/跳转/软404检查全部通过。原718条中的两个作者README隐式索引别名已移除，正式页面保留。16个API页和8个下载的最终严格复验全部通过，所有下载字节仍与发布源码一致。
即时站内搜索返回19条已有Webhook结果，未返回新增API路径；新页均可通过导航访问且sitemap/robots允许抓取。已完成索引状态检查，但不把可抓取写成已经收录，也不把搜索未更新当作部署失败。
来源清单固定最终源码与对应内部docs指针；内部全量发现台账保留原核查快照，不将本次选定合同差异复核冒充全量重新扫描。最终发布链、部署编号、生产逐项结果及限制保存在 api/publication.json 与 api/production-verification.json。
管理端确认当前crawler每月23日运行，上次完整抓取为9月23日，本次API发布后尚未运行；下一次计划抓取为10月23日。前端索引 DesireCore Docs 与crawler写入索引一致，域名/路径规则覆盖中英文API，maxUrls无限制；页面HTML、robots、canonical及DocSearch元数据均满足抓取条件。根因是既有月度调度尚未执行本次更新。
沿现有配置手动抓取，于北京时间19:30:02开始、19:32:35结束，734个URL成功、2个内容类型忽略、2个旧v10.0.180中英文更新日志因记录过大失败。索引从19,324条更新至21,572条。未修改抓取周期，未发布编辑器草稿。中英文Webhook单页提取测试各生成110条记录。
正式搜索验收使用前端真实language/tag上下文过滤，16/16目标页面标题、4/4关键端点、2/2旧页对照全部命中，目标记录语言/current版本/标签均正确；中英文搜索弹窗均显示目标Webhook指南且点击可打开对应页面。首次命中排名1—19，不将索引覆盖误写成所有结果均排名第一。逐项证据见 api/search-verification.json，发布摘要已更新。
当前账单与现行DocSearch条款确认免费套餐每月包含5,000,000个抓取资源。按738URL每日一次、31天估算22,878，约0.46%，无需升级付费方案。已在既有crawler发布v5，将调度改为 every 1 day。
原v180中英文日志每页781条正文列表，其中同一修复标题下645条聚合导致单record约123KB，超过100,000字节限制。v5仅针对这两个精确路径，将每10条完整li在提取用DOM合成临时p，并关闭该页聚合；网页正文不变，标题/id、顺序及所有原文本保留，面包屑不参与分组。真实URLTester两页各89记录通过，英文API Webhook对照仍110记录。去密钥配置参考保存在 api/algolia-crawler.config.js。
v5正式抓取于北京时间20:43:47—20:46:35完成：736成功、2个内容类型忽略、0失败，索引21,572→21,750。两篇旧日志记录超大错误已清零。
30次搜索请求均HTTP200；API16标题、4端点、2旧页对照、2日志标题及4个日志中部/末尾正文目标通过。原2条带引号camelCase严格短语未命中保留为诊断；补查返回原始完整内容，未将负面诊断改写成通过。浏览器中文“存量明文”、英文“legacy sensitive results”均返回v180并可打开对应章节。完整费用、配置、文本保真与查询证据见 api/search-daily-verification.json。