用途：在实现前为 Lucid 集成选择最小且受支持的接口面，并记录信任、数据、故障与归属边界。
主要能力：比较 REST（服务端文档/账户工作流）、Standard Import（确定性文件驱动创建文档）、编辑器扩展（编辑器内 UI、文档内容与数据行为）以及数据连接器（仅在需要服务端源认证、定时刷新或官方连接器 webhook 时添加）。产出所选接口面、组件/信任边界/数据流/故障恢复视图、主体与作用域矩阵、数据契约、故障模型、备选方案、决策、假设、负责人与审批门。
使用方式：先收集功能需求、数据分类、用户、服务目标与容错要求，以及已知的 Lucid 产品、归属模型和套餐/账户约束；用 Read、Glob、Grep 检查系统与约束，用 WebFetch 获取当前官方契约，仅用 Write/Edit 在获批项目中写架构记录与图。为每条边界映射主体（人类/API 密钥、OAuth 用户、OAuth 账户、扩展、连接器运行时、上游源），定义作用域、密钥存储、轮换、撤销、同意与审计证据。每条边需指定 schema、身份、授权、校验、重试/幂等、保留与可观测性。至少比较两个可行方案在复杂度、可支持性、最小权限、故障隔离与可逆性上的差异。
适用场景：需要跨多种 Lucid 接口面做架构决策、边界与故障设计时。
限制：明确排除不受支持的通用文档 webhook、文档锁定、通用配额与未经验证的成本假设；能力缺乏官方支持时标记缺口并重新设计，不得臆造 API；数据归属未解决时在信任边界停止相关数据流；连接器不增加必要服务端职责时优先更简单的扩展或导入设计。架构设计阶段不得注册应用、开通托管、迁移数据、发布扩展或承诺商业条款。
示例：decision=editor-extension+connector; reason=source-oauth-and-scheduled-sync; generic-document-webhooks=excluded; review=2026-Q4。
后续：将获批决策转为威胁模型、契约测试、部署门与运维手册。