整站运行

新人第一站。本页讲 AidaWork 整站怎么跑（三仓归属 → 一轮用户话 → 本机/云端 → 产品包口径 → 信任门 → 失败落点）。图是辅读；结论以 NOTES + evidence 为准。 钉点：Agent 7f2e519936b5 · Desktop 4346d79eb364 · Plugins a33ce3733365。产品口径旁挂见 product-narrative（非 tip 源码事实）。

一句话

用户在 Desktop 说话 → Agent 受理并持有 Run / IX / 账本 → 模型与工具在执行切片里干活；要本机能力时跨回 Desktop Main（PluginHost / LF / LE）；Plugins 只供协议、SDK 与不可变包，不持有服务端任务状态。写有没有落地只看账本，不看聊天气泡。

谁拥有什么（三仓）

深挖地图：PANORAMA · 拓扑图主题 overview。

一轮用户话怎么走

1. Desktop Main prepareEnterpriseChatInput 组装输入（本机能力广告 / 可选插件投影 / LF 附件）→ Work IPC 提交 → POST /api/chat。
2. Gateway 校验与会话绑定 → ChatSubmissionStore.admit 持久受理 direct/routed（忙时进入原会话队列）→ RunExecutionWorker 按原 lease/epoch 领取。执行切片的准备与模型循环仍复用各自驱动，不由 HTTP 连接存活决定。
3. 工具经 ExecutionHostRouter 分到 Server / LF / Plugin / LE；要人确认时 InteractionKernel 挂起，settle 后 continuation 再跑。
4. Desktop Main 观察原 Work，并由原本机 owner 执行本机请求和交付回执；Renderer 只呈现。观察断线不取消或重放执行。

五阶段跨仓源码对照速查（Desktop ↔ Agent）

单条消息全链路 12 跳沙盘模拟（对应视图 message-trace）

以用户在 Desktop 输入 「帮我读取授权夹里的 10月考勤表.xlsx 并生成异常汇总表」 为例，单条消息跨进程与数据库的 12 跳精确状态演进如下：

人话六步（控制面 vs 执行面）→ enterprise-tour-narrative。密时序与 fail/ok → enterprise-task-e2e。

本机 / 桌面 vs 云端 Agent

交付顺序（产品口径，非 tip）：先稳住桌面尤其 Windows，再核 VMS / MSP 路径——见 product-narrative。机制侧桌面边界 → desktop-client · desktop-runtime。

VMS / MSP · Pack × Edition（产品口径）

• MSP ≠ 单纯多租户。 MSP = 原中台算薪运维等能力装进 AidaWork 交付（算薪运维、复杂考勤、多客户账单）。
• AidaWork = VMS / MSP 产品包（标准 Pack × 有界 Edition）。
• 多实例配额 / 租户公平（scaling-roles）是运行扩缩，不是 MSP 产品定义。
• 技术装配（目录仓库所有、租户订阅）→ agent-config-pipeline；非 VMS 零业务订购收窄 → enterprise-task-e2e ADR-0097 D1-2a。

完整会前口径 → product-narrative。

信任 / 鉴权门（进门就挡）

1. 身份：Aida JWT → TenantContext；Server session ≠ Desktop session（auth-tenant）。
2. Desktop 协议 v3：显式不匹配，或缺头却携带本机执行载荷时，返回 426 DESKTOP_UPGRADE_REQUIRED。无头、无本机载荷可进入后续受理；不能只凭过门就断言工具集合。另有 IX 协议门、Runtime Work 协议门。
3. Path-free LF：绝对路径只在 Main；Agent 只见 relativePath / saveDestinationId。
4. Plugin：不可变包 + 投影绑定 + 签名校验；Host 在 Desktop Main。安装即信任取代通用逐次确认，但仍检查当前身份、原请求、executor、包完整性和原任务；目录、电脑、连接与文件资源授权各自保留。

总览 → trust-boundaries。

失败落在哪

总索引 → FAILURE-CHAINS。

读完下一站

1. enterprise-tour-narrative — 一条任务的控制面 / 权威读法
2. overview — 三仓全景地图
3. enterprise-task-e2e — 密时序与 fail/ok
4. 按需：trust / write-authority / local-file / scaling / observability

单条消息 12-Hop 代码与 SQL 状态微追踪（message-trace）

对应交互图 /topics/site-runtime/message-trace/（analyses/aidawork/site-runtime/message-lifecycle-trace.sequence.json），将一条携带本机 Excel 附件与技能调用的完整消息拆解为 12 个源码与数据库事务跳点：

证据与范围

本页为入口叙事，机制主张合成自已核主题；产品 Pack×Edition / MSP 定义来自会前口径（无 code evidence）。钉点源码锚点：

• aida-desktop · apps/desktop/electron/agent-loop/enterprise-adapter.ts · prepareEnterpriseChatInput · 4346d79eb364
• aida-agent · packages/agent/src/gateway/orchestrator-runtime.ts · resolveAndRun / prepareExecution · e2adc9a3c325
• aida-agent · packages/agent/src/execution-host/router.ts · ExecutionHostRouter · e2adc9a3c325
• aida-desktop · apps/desktop/electron/plugin-host/plugin-host.ts · PluginHost · 4346d79eb364
• aida-agent · packages/agent/src/session/run-store.ts · UPDATE agent_runs · e2adc9a3c325
• aida-agent · packages/agent/src/gateway/chat-routes.ts · DESKTOP_UPGRADE_REQUIRED · e2adc9a3c325

实现存在、默认开关、生产启用分别判断。不升 tip 钉；不新造边界几何，主图为理解型 workflow，深挖链到既有视图。

Mermaid 速读路线

责任图、Worker UML 与组件依赖、持久执行时序、条件产物、队列、IX 与 attempt 状态、邮箱分页 · Desktop UML、Stop 时序、artifact 输入、信任边界、提交状态、lease/inbox、产物回执与更新策略。图册随本文直接展示，源代码可展开核对。

按问题找答案

故障与恢复 · 跨仓协议 · 数据生命周期 · 开发改动导航 · 实现与验收。新指南保留已实现、计划、未验证边界，不将手工操作建议视为已执行。

服务端运行 Mermaid 图册

本图册补充原有 Archify 交互视图，按「谁负责 → 如何执行 → 如何结案 → 如何恢复」阅读。基于 2026-10-29 可访问的 GitHub 默认分支快照：Agent 7f2e519936b53035646a70f152e734298abed2fb，Desktop 4346d79eb364b502ef87c0869a494dfed7964419。GitHub 镜像不证明 GitLab 当前 tip 或线上部署；图不代替真实模型、数据库和原生平台验收。

配套：Desktop 实现图册 · 状态权威 · 完整失败链。

图索引

• M01 责任与事实归属
• M02 一次持久执行与断线观察
• M03 条件产物完成判定
• M04 会话队列的真实状态
• M05 Interaction 与提交尝试分开
• M06 Settlement attempt 的不确定结果
• M07 邮箱读取的范围与分页
• M08 UML：Worker、配置接口与观测快照
• M09 组件关系：Worker 的领取、维护与执行依赖

M01 责任与事实归属

这是一张概念责任图，不是部署拓扑。模型循环、持久控制、物理效应和界面展示各有主人。

flowchart TB
  accTitle: AidaWork 责任与事实归属
  accDescr: 用户经 Desktop Main 提交，Agent 持久受理与 Worker 执行；Main 拥有本机事实，界面仅呈现观察结果。
  UI["Renderer：输入与展示"] --> Main["Desktop Main：身份与持久提交"]
  Main --> Gateway["Agent Gateway：校验与受理"]
  Gateway --> PG["PostgreSQL：Root、carrier、claim、回执"]
  PG --> Worker["RunExecutionWorker：领取与驱动"]
  Worker --> Control["Work 共同控制：原身份与 fence"]
  Control --> Model["模型：建议下一步"]
  Model --> Control
  Control --> Server["服务端工具 owner"]
  Control --> Main
  Main --> Local["本机 effect owner：文件、Plugin、Skill"]
  Local -->|"绑定原请求的事实与回执"| PG
  PG -->|"观察水位，不是万能重放日志"| UI

Effect 管理进程内 fiber/Scope；PostgreSQL 与 Work 共同控制拥有领取、终态和恢复事实。runtime_events 不是完整 prompt 或通用恢复日志。Scheduler、Child、Summary、Memory、Title、Quality 也不能一律画成已迁移的统一 Command 路径。

证据：当前运行总则。

M02 一次持久执行与断线观察

sequenceDiagram
  accTitle: 持久执行与断线观察时序
  accDescr: Gateway 持久受理后 Worker 独立执行，断开观察流不取消或重放工作，本机结果依原请求结算。
  participant Main as Desktop Main
  participant API as Chat Gateway
  participant DB as 持久受理与 PG
  participant W as RunExecutionWorker
  participant C as Work 共同控制
  participant M as 模型
  participant H as 本机 effect owner
  Main->>API: clientRequestId 与当前身份、材料、能力
  API->>DB: admit 原请求或排队
  DB-->>API: Root binding 或 queued receipt
  API-->>Main: 持久受理结果
  W->>DB: 按 lease 与 epoch 领取 carrier
  W->>C: 核验原 Work 与冻结输入
  C->>DB: 预留原模型请求边界
  W->>M: 派发模型请求
  M-->>C: 绑定原 invocation 的结果
  C->>DB: 持久化本机请求并挂起
  DB-->>H: 经交付通道投递原请求
  H->>H: 当前身份、原任务与资源复核
  H->>DB: 经 API 结算原请求回执
  DB-->>W: 结算事实；仅符合原恢复门时可继续
  W->>C: 符合资格并重新领取后推进
  C->>DB: 终态 guard 与 fence 复核
  Main->>API: 重连查询原 Work
  API->>DB: 读取当前 Root 与效果事实
  API-->>Main: 当前观察结果
  Note over Main,DB: 断线不取消、不重发执行；传输协议不选择另一条执行通道

图中 DB→本机 owner 是持久请求经 API/inbox 的逻辑交付，不表示数据库直接连用户机器。带 runtime-work-v1 和不带 Runtime 头的生产 Chat 共用持久受理；旧协议显式拒绝。回执到达不等于必然恢复：Stop、unknown、证据冲突或缺失材料仍可能禁止推进；迟到事实可结算但不能重新激活已停止 Root。具体 lease/inbox 见 Desktop 图册。

证据：共同受理与传输。

M03 条件产物完成判定

下图是 owner 判定步骤，不是新增的 RunStatus。not_applicable 不能单独代表任务完成。

stateDiagram-v2
  accTitle: 条件产物完成的 owner 判定
  accDescr: 精确绑定原 producer 和 scope，基于真实回执核验产物与独立源文件读取，在原终态 fence 内复核。
  state "冻结 producer 与 scope" as Frozen
  state "重建原请求及回执事实" as Facts
  state "保留未完成或拒绝" as Blocked
  state "条件未满足且累计零产物" as NoOutput
  state "已有真实产物" as Produced
  state "验证产物读取" as ArtifactRead
  state "验证独立源材料读取" as SourceRead
  state "满足本条件的完成要求" as Ready
  state "原 claim fence 内再次复核" as Fence
  [*] --> Frozen
  Frozen --> Facts: 原 producer 回执已结算
  Facts --> Blocked: 错绑定、撤销、未结算或冲突
  Facts --> NoOutput: 最新 not_applicable 且累计零产物
  Facts --> Produced: 累计产物存在且最新 produced 或 not_applicable
  Produced --> ArtifactRead
  ArtifactRead --> SourceRead: 全部原 artifactRef 与 hash 已读
  NoOutput --> SourceRead
  SourceRead --> Ready: 不要求独立读取或证据齐全
  Ready --> Fence
  Fence --> Blocked: 当前条件已变化
  Fence --> [*]: 本条件通过，仍服从其他终态门

Agent 从 continuation、interaction receipt、tool message、settlement 和原模型 tool call 重建事实；模型文本、空列表、Worker 自报 success 都不够。Main 还会校验声明、返回列表、实际 committed artifact ID 集合一致。既有 Work 不因升级自动补入新合同。

证据：owner 事实重建与完成公式；终态事务复核。

M04 会话队列的真实状态

以下使用 ConversationTurnQueueStatus 的实际状态值。admitted 只表示队列请求已受理为 Run，不等于业务完成。

stateDiagram-v2
  accTitle: 会话队列状态
  accDescr: 身份绑定的加密快照排队，可重试错误在次数预算内保留 queued；受理、取消和失败分别结案。
  [*] --> queued: 保存身份绑定的加密快照
  queued --> queued: 同错误码次数小于 3，持久 retryAfter
  queued --> admitted: 当前准入成功并绑定 runId
  queued --> cancelled: 取消此排队请求
  queued --> failed: 不可重试或同错误码第 3 次失败
  admitted --> [*]
  cancelled --> [*]
  failed --> [*]

可重试失败按错误码计数，前两次分别等待 10 秒、20 秒；第 3 次仍失败则进入 failed。出队会恢复并复核原身份、材料和能力，不能换账号或新建内容来掩盖原请求失败。后台 Root 不占用前台槽位，队列不等于任意后台任务总线。

证据：状态定义；原 queued 快照重试；受理及队列终态。

M05 Interaction 与提交尝试分开

这是 INTERACTION_TRANSITION_RULES 的 合同局部视图，不是把所有 producer 的生产迁移状态都声明完成。运行状态、IX 状态、attempt 状态、业务效应 outcome 不可互换。

stateDiagram-v2
  accTitle: Interaction 合同终态
  accDescr: pending 在权威接受后 resolved；普通到期、取消、损坏需无活跃 attempt，权威拒绝后已到期则 expired；刷新另建关联交互。
  [*] --> pending: 原 owner wait 与 outbox 原子建立
  pending --> resolved: authority accepted，同事务写 resume intent
  pending --> expired: 无活跃 attempt 且到期，或权威拒绝时已到期
  pending --> cancelled: 无活跃 attempt，turn cancelled
  pending --> failed: 无活跃 attempt，永久损坏
  pending --> pending: task_scope 且活跃 attempt 时，任务取消请求延后
  resolved --> [*]
  expired --> [*]
  cancelled --> [*]
  failed --> [*]

图中的取消延后仅对应 task_scope 的 task_cancellation_requested，不把任意取消都解释为延后。终态刷新建立 linked interaction，不把原 IX 改回 pending。accepted + resolved 才产生恢复意图；显示了“已发送”不代表恢复成功。

证据：IX 转换与 guard。

M06 Settlement attempt 的不确定结果

这仍是同一合同的局部状态图。checking 是 attempt 状态，IX 保持 pending；超时不表示权威拒绝。

stateDiagram-v2
  accTitle: 交互提交尝试的核对状态
  accDescr: 传输失败进入 reconciling，权威结果未知进入 checking；只有原权威回执能接受或拒绝，checking 超时保留原状态。
  [*] --> submitting: 通过 actor、version、deadline 门
  submitting --> reconciling: 可重试交付失败
  reconciling --> reconciling: 原交付仍未确认
  submitting --> checking: 权威结果未知
  reconciling --> checking: 权威结果未知
  checking --> checking: 检查超时，提供恢复入口
  submitting --> accepted: 原权威接受
  reconciling --> accepted: 原权威接受
  checking --> accepted: 原权威接受
  submitting --> rejected: 原权威拒绝
  reconciling --> rejected: 原权威拒绝
  checking --> rejected: 原权威拒绝
  accepted --> [*]
  rejected --> [*]

已拒绝且未过期时，IX 可以仍为 pending；后续重新提交必须是新的 attempt，并再次通过 guard，不能重写旧 attempt。不要用此图宣称 ADR-0098 的 parked-card 产品方案已经实现。

证据：attempt 与 IX 独立状态；提交、核对、接受与拒绝；超时不伪造终态。

M07 邮箱读取的范围与分页

sequenceDiagram
  accTitle: 邮箱范围拒绝与 UIDNEXT 回退
  accDescr: 先核验原 connectionId，越界请求不派发；选定邮箱内校验 UIDVALIDITY，UIDNEXT 缺省时按原游标或末序号 UID 选择搜索窗口。
  participant Tool as 原 Work 工具调用
  participant Scope as Agent 范围门
  participant Conn as 邮箱连接器
  participant IMAP as 原邮箱服务器
  Tool->>Scope: connectionId 与原工具参数
  alt 连接或工具超出原 connectorRead
    Scope-->>Tool: SCOPE_VIOLATION，尚未派发
    Note over Tool,Scope: 不是查询失败，不允许换账号探测
  else 原范围内
    Scope->>Conn: 派发原连接调用
    Conn->>IMAP: readonly 打开 folder
    IMAP-->>Conn: UIDVALIDITY、exists、可选 UIDNEXT
    Conn->>Conn: 校验 mailbox identity 与字段
    alt 空邮箱
      Conn-->>Tool: 空页
    else UIDNEXT 缺省且没有 beforeUid
      Conn->>IMAP: 读取最后 sequence 的 UID
      IMAP-->>Conn: last UID
      Conn->>Conn: upperUid = last UID + 1
    else 有合法 UIDNEXT 或原 beforeUid
      Conn->>Conn: 使用原游标与合法上界
    end
    opt 非空且上界有效
      Conn->>IMAP: 有界 UID 窗口 search 与 fetch
      IMAP-->>Conn: 匹配邮件
      Conn-->>Tool: uidValidity、messages、nextBeforeUid
    end
  end

缺省不等于非法值：非空邮箱提供了错误 UIDNEXT 时仍失败（空邮箱在此检查前直接返回空页）；不能把坏数据当“省略了字段”继续。图只说明当前服务端读取路径，不证明 Desktop 未合并的本地邮件归档 PR 已落地或真实账号联调通过。

证据：派发前范围门；邮箱分页与缺省回退。

M08 UML：Worker、配置接口与观测快照

这是 Mermaid classDiagram 表达的 UML 类／接口局部视图，成员只摘录与运行控制有关的部分。RunExecutionWorker 是实际类；两个 Options 和 Snapshot 是 TypeScript interface，不是数据库实体。实线泛化只用于源码明确的 extends；虚线表示参数或返回值依赖，不暗示对象生命周期所有权。

classDiagram
  accTitle: Worker 类与配置接口的 UML 关系
  accDescr: Worker 接收扩展自 AttemptOptions 的 WorkerOptions，并返回观测 Snapshot；接口扩展不是 Worker 类继承。
  class RunExecutionWorker {
    +start() void
    +tick() Promise
    +snapshot() RunExecutionWorkerSnapshot
  }
  class RunExecutionWorkerOptions {
    <<interface>>
    +string workerId
    +string workerVersion
    +number maxConcurrency
    +number maxBackgroundConcurrency
    +number claimCooldownMs
  }
  class RunExecutionAttemptOptions {
    <<interface>>
    +ConfigDb db
    +OrchestratorRuntime runtime
    +number leaseTtlMs
    +number heartbeatMs
  }
  class RunExecutionWorkerSnapshot {
    <<interface>>
    +number active
    +number limit
    +number claimed
    +number watchdogFired
  }
  RunExecutionAttemptOptions <|-- RunExecutionWorkerOptions : extends
  RunExecutionWorker ..> RunExecutionWorkerOptions : constructor 参数
  RunExecutionWorker ..> RunExecutionWorkerSnapshot : snapshot 返回

WorkerOptions 图示的三个并发／间隔字段在源码中均可选；省略了其他配置和 Snapshot 的 nullable oldestActiveAgeMs。Snapshot 是进程内观测 DTO，不是持久队列、Run 状态或恢复权威。

证据：接口扩展与观测字段；实际类、构造器与 snapshot；start 与 tick；AttemptOptions 的依赖字段。

M09 组件关系：Worker 的领取、维护与执行依赖

这是 Mermaid flowchart 表达的组件关系视图，不是 UML componentDiagram 语法，也不是部署图。节点按源码模块聚合；箭头是函数调用依赖，而非不同服务间的网络请求。

flowchart TB
  accTitle: Worker 的模块级组件关系
  accDescr: Worker 通过 storage 领取与恢复，通过 work control 对账，通过 quota 结算，并把成功领取的 claim 和 snapshot 交给 attempt。
  W["run-execution-worker"]
  S["run-execution-storage"]
  C["run-work-control"]
  Q["run-execution-quota"]
  B["background-work-queue / run-background-work-control"]
  A["run-execution-attempt"]
  W -->|"领取 / 过期恢复 / 取消对账"| S
  W -->|"Work 回执核对 / 未启动租约归还"| C
  W -->|"配额结算"| Q
  W -->|"后台队列维护 / 过期收口"| B
  W -->|"执行已领取 claim 与 snapshot"| A

每次 poll 先处理取消、过期、quota 和 receipt，再经过后台维护与容量／cooldown 判断才尝试领取。Attempt 在 FiberSet 中执行，不让慢模型调用阻塞下一次 tick 的取消对账。领取后若已停止，Worker 交还尚未派发的 ownership，不进入 Attempt。图不将这些模块包装成新的类或微服务。

证据：poll 的维护与领取门；领取、停止后交还与 FiberSet 执行。

开发者改动导航：从需求到合同与验收

本页是 服务端图册 的改动入口，不新增运行主题。基线为 Agent 7f2e519936b53035646a70f152e734298abed2fb、Desktop 4346d79eb364b502ef87c0869a494dfed7964419。以下是源码定位与待执行验收建议，不是测试通过报告；先确认目标仓版本，再跟实际调用者，不从旧测试名猜目录。

场景 → 入口 → 合同 → 回归

不要将 Scheduler、Child、Summary、Memory、Title、Quality 一概改成“统一 Command 已迁移”；当前入口的例外与调用关系由 运行入口、观察与恢复合同 说明。

建议检查顺序

1. 写清改变的是输入、权威状态、物理效应、展示还是清理；指定唯一 owner。
2. 对照 Desktop 图册、状态权威、数据生命周期 标出受影响边界。
3. 先改合同与解析，再改写入 owner、读取投影及恢复入口；不能只让 UI 隐藏错误。
4. 同时查同名 type 的 Agent tool-client 与 Desktop 副本/消费者。字段兼容性、版本门、schema identity、发布顺序分别写清；若需要迁移，评审和执行授权另列，不在启动时偷跑。
5. 每个 happy path 配拒绝、重复、断线/重启、撤权、迟到事实案例。真实外部效应的验收用隔离材料与明确授权，不把 stub 通过叫作真机通过。

已有测试入口与命令来源

Agent 的 运行入口、观察与恢复合同 内列有真实导航入口：packages/agent/tests/unit/runtime/local-file-v4-tool.test.ts、packages/agent/tests/unit/session/local-file-transient-result.test.ts、packages/agent/tests/integration/runtime-v2-work-resume.test.ts、packages/agent/tests/integration/runtime-v2-work-stop.test.ts。它们是源码 README 指向的定位入口；本次缓存不完整，未运行，也未确认每个测试文件均已物化。完整 checkout 应先读 README 指向的 docs/agents/verification-matrix.md 再选执行命令；此处不臆造 Agent test script。

Desktop 的 package scripts 已读取，以下在完整 Desktop checkout 的 apps/desktop 目录执行，均为现有脚本，不代表本次已运行：

pnpm test
pnpm typecheck
pnpm assert:secret-hygiene

来源：Desktop scripts。test 为 vitest run；typecheck 还会执行 typecheck:e2e。E2E、平台能力和外部服务验收需要对应原生环境及授权；以上命令不替代这些验收。不要为本次文档变更安装依赖、运行共享库迁移或发布应用。

合并前可核对的交付清单

• 入口和每条跨仓合同附固定 commit / 路径 / 行范围；实现存在、默认开启、目标环境启用分开说明。
• 改状态：列真实 enum 与合法转换；概念图阶段不冒充 enum。
• 改副作用：记录幂等身份、claim/fence、超时未知状态及恢复 owner；断线不是取消。
• 改数据：列来源、读者、传输、清理条件与保留未知项；不得只写“加密所以安全”。
• 测试报告分为已通过、失败、未运行、被阻塞；包含命令、环境、证据与限制，不把候选用例当现有覆盖。
• UI/文档另做浏览器与视觉检查：文字不裁切、链接可达、Mermaid 可读、冷重开及旧状态不覆盖新状态。源码语义核验与视觉检查分别结论。

这份导航帮助确定改动范围，不授权部署、远端写入、数据库迁移或业务操作。

实现状态与验收清单

本页回答「代码里有什么、什么仍受门控、还缺哪种证明」，不是上线承诺。源码存在 ≠ 默认开启 ≠ 生产部署 ≠ 验收通过。 状态可以叠加：同一能力既已实现，又受身份/配置门控，原生验收仍未完成。

基线与证据读法

本页沿用 catalog 的固定源码版本，不把分支最新状态混入实现图：

主题 NOTES 中保留部分历史钉点与迁移说明；当前声明的完整 SHA、路径和行范围以对应 evidence 为准。GitHub 可访问快照不证明 GitLab 当前 tip，也不证明目标环境已经安装这些版本。方法见 增量复核记录。

• 已实现：在固定源码找到入口、调用与归属；不是产品端到端实测。
• 受门控：代码存在，但协议、身份、权限、能力或配置仍须满足；只有具体源码支持时才写「默认开/关」。
• 方案待实施：设计方向或 ADR 已存在，不代表状态、迁移和生产者已接入；ADR 的 Accepted/Proposed 标签不能独立判定代码状态。
• 未合并增量：具体 PR 的额外改动，独立于固定基线；PR 开放不能反推整个能力不存在。
• 未验证：缺少对应环境、执行或结果证据；不是「失败」，更不能按通过处理。

状态矩阵

本站验证不是产品验收

前次 UML 补充的收据对应文档 PR #8 基线 0b1d2888f34b564c287d45208ed07e20936e0763：18 张 Mermaid parser、98 张 Archify 静态 showcase、构建与 32 项测试通过。这是历史验证覆盖，不自动覆盖本页及之后的变更；本次整合者须对最终工作树重跑并记录结果。见 UML 验证记录。

浏览器 / 人工目检尚未通过。 前次具体阻塞：ARCHIFY_CHROME=/usr/bin/chromium node scripts/browser-mermaid.mjs 启动 Chromium 时被 socket 权限阻止；正常提权重试又在执行环境初始化阶段失败。完整 check:browser 因同一依赖未继续，没有真实渲染截图可供目检。JSDOM/parser、showcase 和构建均不能替代浏览器布局。目标、错误与未执行项见 验证记录。

有界验收清单

以下是待执行的验收合同，不是已通过打勾表。责任按代码/运行边界划分，不虚构人员。每项须记录目标 SHA、环境/平台、配置、实际输入、结果证据及 通过 / 失败 / 阻塞 / 未执行；达到所列结果才收口。仅在批准的测试环境使用隔离账号和无业务副作用材料。

执行与授权边界

• 本页允许规划验收，不授权创建/运行 GitHub Actions、合并 PR、启用 auto-merge、发布主站、上传安装包、改 feed、执行 DDL/迁移或改变生产配置。
• 不为补齐验收擅自安装浏览器/依赖、运行真实业务写、操作用户文件或切换发布渠道；所需权限/环境另行确认。
• 受阻时只记录具体动作、目标、原因、当前状态与最小所需条件。例如「本地 Mermaid Chromium 渲染：socket 权限阻止启动，未执行布局检查；需可启动 Chromium 的受支持环境」，而不是泛称整个实现失败。
• 新证据到来后，只升级它实际覆盖的维度。原生单平台通过不升级其他平台；测试 fixture 通过不升级生产部署；代码合入不自动升级任何运行验收。