@deployxai/dxc 0.1.0

package/docs/decisions/0005-official-skill-orchestration-and-local-content-memory.md

@@ -0,0 +1,97 @@
+# ADR-0005：官方 Skill 编排与本地内容记忆
+
+日期：2026-07-26
+更新：2026-07-30
+
+状态：Accepted（已接受）
+
+## 背景
+
+DxC 的发布尾端已经验证微信公众号扫码授权和受控草稿创建。要向上扩展研究、Brief、大纲、正文、标题、视觉和审校，需要一个不会把状态只留在 Agent 对话里的稳定框架。目标用户还明确需要从自己的历史文章中召回案例、金句和观点；只有关键词匹配会漏掉“创业低谷”与“现金流快断了”这类没有共同字面的相关内容。
+
+该扩展不能改变当前商业 MVP 的微信公众号草稿边界，也不能引入通用 Agent 框架、云端抓取平台或复杂工作流引擎。
+
+## 决策
+
+### 1. 单一公开入口
+
+1. 官方总控 Skill 固定为 `dxc-content-workflow`，同时承担首次初始化和后续恢复编排；
+   它允许被宿主隐式调用，下游步骤 Skill 默认不允许隐式调用。
+2. v1 不发布单独的“安装 Skill”。总控 Skill 先检查 CLI、画像、知识库和项目状态；缺少 CLI 或可选第三方 Skill 时，只提供固定版本和来源说明，由用户或宿主明确安装。
+3. 每个内容步骤由独立 `dxc-*` Skill 承担。当前八个步骤都可调用并在总控自带的
+   `references/catalog.json` 中标记为 `available`；catalog 另用
+   `implementationLevel`、`verificationLevel` 和 `knownGaps` 区分真实实现深度。
+   只有总控允许隐式触发，下游专家只能由总控或用户明确调用。
+4. 微信交付 Skill 仍为 `dxc-wechat-publisher`；它是最后一步，不再充当整个内容系统的入口。
+
+### 2. 本地画像与线性项目
+
+1. 首次选择题回答保存为 `~/.dxc/content-profile.json`，使用版本化问卷和运行时校验；不保存凭据。
+2. 每篇文章使用一个可见的 `dxc.project.json`，固定八类产物路径：
+   `research → brief → outline → article → titles → visual-plan → quality-review → delivery`。
+3. `~/.dxc/content-projects.json` 只登记由用户明确初始化过的项目标题、ID、本地目录和
+   更新时间，用于新会话按标题恢复；不得保存文章正文，也不得借此扫描主目录、
+   Obsidian 仓库或云盘。重名结果必须交给用户选择。
+4. 所有步骤复用一个 checkpoint（检查点）结构。v2 在原有 `stage`、`status`、
+   Skill/版本、确认状态、`executionLocation`、`dataTransit`、时间和稳定错误码之外，
+   增加实际 `inputs`、声明或已生成的 `outputs`、`metadata.summary` 和
+   `waitingFor`。
+5. 检查点写入 `.dxc/checkpoints/`。输出产物缺失、变空或哈希变化后，当前检查点变为
+   `stale`；任一输入产物变化后，下游检查点同样变为 `stale`。
+6. 普通内部步骤允许直接 `completed` 并自动进入下一步，不要求伪造人工确认。只有真实
+   用户决策使用 `awaiting-user`；其具体问题必须写入 `waitingFor`，用户明确回答后才
+   写 `completed --confirm`。
+7. 每次总控 Skill 被调用时都先定位项目、读取实际产物和 checkpoint，然后循环推进到
+   `waiting-user`、不可安全恢复错误或 `complete`。v1 是线性流程，允许从已有文章进入
+   并把当前路线不需要的步骤记为 `skipped`；不实现 DAG、分布式调度或通用工作流引擎。
+8. 每个 Markdown 产物使用 `dxc-content-stage@1` 轻量元数据，记录项目、阶段、Skill、
+   时间和实际输入哈希。CLI checkpoint 仍是机器恢复真值，不再为内部产物建立第二套
+   复杂校验系统。
+9. 研究、可唯一收敛的 Brief、大纲、视觉计划和通过的审校自动完成。真正的停点是实质
+   立场分叉、最终正文、标题、公众号、封面、不可变预览和不可安全恢复错误。
+
+### 3. 本地历史文章知识库
+
+1. 用户必须显式指定 `.md`、`.markdown` 或 `.txt` 文件；CLI 不扫描主目录、浏览器、Obsidian 仓库或云盘。
+2. SQLite 保存文章元数据、分段、来源标签、内容/分段哈希和向量，是本地事务与迁移真值；数据库默认位于 `~/.dxc/content-memory.sqlite`，目录 `0700`、文件 `0600`。
+3. 检索采用三条边界：
+   - SQLite FTS5 `trigram` 做标题、章节和原句的字面召回；
+   - Tokenizers.js 负责本地分词，ONNX Runtime Web 的单线程 WASM 执行器运行固定版本的 `Xenova/bge-small-zh-v1.5` q8 中文模型，在本机生成 512 维向量；
+   - 语义路先剔除固定模型探针中明显不相关的低相似度尾部，再用 RRF（倒数排名融合）合并关键词和语义排名，并限制同一文章的重复片段。该阈值只是降噪参数，不是事实置信度，必须用目标用户标注集继续校准。
+4. 模型仓库、revision（修订哈希）、量化类型和向量维数都是契约的一部分。模型或切分规则变化时必须显式重建索引，不能在同一数据库里静默混用。
+5. 历史文章规模下直接计算归一化向量的点积，避免引入额外向量数据库或 pre-v1 SQLite 扩展。只有真实规模和基准证明线性扫描不足时才评估 ANN（近似最近邻）。
+6. 默认建立混合索引；`--lexical-only` 只用于用户明确选择的离线退化。混合查询发现向量缺失时返回稳定错误，不静默伪装为语义检索。
+7. 召回结果只返回有界片段及 `articleId`、`chunkId`、标题、章节和哈希。CLI 不判定片段一定是案例、金句或观点；对应内容 Skill 结合任务判断。
+8. 数据库和模型缓存在本机，不同步到 DxC Cloud。Agent 把召回片段放入对话时，片段可能由 Agent 宿主或模型提供方处理，首次使用必须披露。
+
+## 后果
+
+正面结果：
+
+- 用户只需记住一个入口，Agent 可以从本地真值恢复；
+- 用户更换会话后可以按文章标题恢复，且不依赖旧对话上下文；
+- 各步骤可以独立迭代而不改变交接协议；
+- 上游产物变化会自动使下游阶段失效，不会继续沿用旧标题或旧预览；
+- 历史内容召回既保留原句精确性，又覆盖无共同关键词的语义相关内容；
+- 不需要服务端向量库、全文同步或新的生产组件；
+- 文章与检索证据仍由用户掌握并可单篇删除。
+
+代价和限制：
+
+- 首次语义索引需要下载约 24 MB 的量化模型；当前 WASM 推理依赖解压后约 92 MB，但比同时安装 Node 原生、多平台 Web 和图像运行时的整包方案更轻；
+- 小模型和 RRF 仍可能产生弱相关候选，必须通过目标用户的标注查询集持续评估 `Recall@k` 和首位命中率；
+- v1 没有跨设备同步、自动目录监听或跨编码模型迁移；
+- 视觉步骤原先只输出计划、不支持正文内联图片；这项限制已由
+  [ADR-0008](0008-end-to-end-content-workflow-continuity.md) 取代；
+- 内容质量主要依赖 Skill 遵守 contract 和最终用户确认，不建设通用工作流引擎。
+
+## 核验来源
+
+以下能力于 2026-07-26 核验：
+
+- [Node.js 24 `node:sqlite`](https://nodejs.org/docs/latest-v24.x/api/sqlite.html)
+- [SQLite FTS5 与 trigram tokenizer](https://www.sqlite.org/fts5.html)
+- [ONNX Runtime Web 的 Node.js/WASM 支持](https://onnxruntime.ai/docs/get-started/with-javascript/web.html)
+- [Hugging Face Tokenizers.js](https://github.com/huggingface/tokenizers.js)
+- [BAAI `bge-small-zh-v1.5` 模型卡](https://huggingface.co/BAAI/bge-small-zh-v1.5)
+- [固定 ONNX q8 模型文件](https://huggingface.co/Xenova/bge-small-zh-v1.5/blob/75c43b069aac4d136ba6bc1122f995fedcfd2781/onnx/model_quantized.onnx)

package/docs/decisions/0006-separate-wechat-user-login-from-account-authorization.md

@@ -0,0 +1,87 @@
+# ADR-0006：个人微信登录与公众号授权分离
+
+日期：2026-07-27
+
+状态：Accepted（已接受）
+
+## 背景
+
+现有 `dxc wechat connect` 在第一次公众号管理员授权成功后，同时创建 owner、租户、设备身份和 24 小时设备会话。这足以验证单设备公众号草稿闭环，但不是完整登录系统：
+
+- 设备会话到期后只能重新走公众号授权；
+- 第三方平台回调只能证明某个公众号已授权，不能识别正在登录的自然人；
+- 新设备被正确阻止仅凭公众号授权接管已有租户；
+- 网站管理、权益、支付和多设备恢复都需要稳定的个人用户身份。
+
+## 决策
+
+### 1. 两种微信授权严格分离
+
+1. 个人登录使用微信开放平台“网站应用微信登录”，作用域固定为 `snsapi_login`。
+2. 公众号绑定继续使用微信开放平台第三方平台授权。
+3. 网站登录 AppID/AppSecret 不得复用 Component AppID/AppSecret。
+4. 网站登录只建立或恢复 DxC 用户和设备会话，不能新增、迁移或重新授权公众号。
+5. 公众号授权只改变指定租户下的公众号能力，不能作为新设备接管已有用户的依据。
+
+固定 URL：
+
+- 网站应用授权回调域：`content.deployxai.com`
+- 登录发起页：`https://content.deployxai.com/auth/wechat/login`
+- 登录回调：`https://content.deployxai.com/callbacks/wechat/login`
+- 第三方平台事件回调继续为 `https://content.deployxai.com/callbacks/wechat/component-events`
+- 授权公众号消息回调继续为 `https://content.deployxai.com/callbacks/wechat/authorizers/$APPID$/callback`
+
+### 2. 关联、首次注册和新设备登录
+
+1. 已登录设备执行 `dxc auth link-wechat`，把网站应用返回的个人微信身份关联到当前 `userId + tenantId`。
+2. 关联必须绑定当前有效设备会话；logout（注销）或到期后回调不能完成关联。
+3. `dxc auth login` 只接受已经关联的个人微信身份。未关联身份不得静默创建第二个租户。
+4. 用户主动执行 `dxc auth start` 或统一的 `dxc setup` 时，未关联个人微信可以明确创建
+   一个新 owner；已关联身份恢复原 owner。该补充决策与并发保护见 [ADR-0007](0007-explicit-personal-wechat-start.md)。
+5. 旧初始化顺序保持兼容：此前通过 `dxc wechat connect` 创建的 owner 仍可随后执行
+   `dxc auth link-wechat`。
+
+### 3. 外部身份最小化
+
+1. MongoDB 不保存网站登录 access token、refresh token、授权 code 或完整回调查询串。
+2. `openid` 使用 `website appId + openid` 的 SHA-256 摘要作为应用内查找键。
+3. `unionid` 仅在微信可靠返回时保存摘要，用于同一开放平台帐号下的辅助一致性检查；不得假设它一定存在。
+4. 同一个外部身份只能关联一个 DxC 用户；冲突时失败，不自动合并租户。
+
+### 4. 设备会话续期
+
+1. 24 小时设备 Token 保持短期访问凭据。
+2. 已证明持有 Ed25519 私钥的设备可登记一个 30 天、单次轮换的 DxC 设备刷新凭据。
+3. 刷新同时校验高熵刷新 Token 和设备签名；服务端只保存 Token 摘要。
+4. 刷新请求预先绑定下一组访问/刷新 Token 摘要，并使用 `rotationId` 支持同一轮重放恢复。
+5. logout 同时撤销当前访问和刷新能力；微信网站登录产生的微信 access/refresh token 在完成身份解析后立即丢弃。
+6. 首版仍使用用户私有的 `~/.dxc/wechat-session.json`；接入系统钥匙串是后续存储适配，不改变协议。
+
+### 5. 可恢复状态
+
+网站登录会话使用统一状态：
+
+```text
+URL_READY → EXCHANGING → IDENTIFIED → SUCCEEDED
+        └──────────────→ FAILED
+        └──────────────→ EXPIRED
+```
+
+`IDENTIFIED` 是授权 code 已消费且外部身份摘要已持久化的恢复检查点。服务崩溃后只从该检查点继续本地绑定，不重复向微信交换同一个 code。
+新设备登录在写入该检查点前，必须把对应设备绑定会话延长到同一恢复截止时间，避免短时绑定 TTL 先于可恢复登录记录失效。
+
+## 后果
+
+- 普通登录不再要求公众号管理员每天重新授权；
+- 全新用户可以通过文案明确的 `start` 先创建个人内容空间，再授权公众号；
+- 新设备只有在个人微信身份已经关联后才能进入原租户；
+- 多设备不再依赖“每租户最多一个活动设备”的临时索引；
+- 网站应用审核完成前，可用假微信登录适配器完成全部本地契约测试；
+- 本轮不增加密码、短信、邮箱登录、社交账号自动合并或 Web 工作台。
+
+## 核验来源
+
+核验日期：2026-07-27。
+
+- [微信开放平台网站应用微信登录开发指南](https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&id=%E7%BD%91%E7%AB%99%E5%BA%94%E7%94%A8%E5%BE%AE%E4%BF%A1%E7%99%BB%E5%BD%95%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97&lang=zh_CN&t=resource%2Fres_list&verify=1)
+- [微信 UnionID 机制](https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/union-id.html)

package/docs/decisions/0007-explicit-personal-wechat-start.md

@@ -0,0 +1,67 @@
+# ADR-0007：个人微信显式首次注册入口
+
+日期：2026-07-27
+
+状态：Accepted（已接受）
+
+## 背景
+
+ADR-0006 已把个人微信网站登录与公众号第三方平台授权分开，并以“现有 owner 先关联，
+新设备再登录”保护已有租户。但首个真实用户若从全新安装开始，仍要先借公众号授权创建
+owner，再回头关联个人微信，操作顺序绕且混淆两次扫码的身份语义。
+
+DxC 需要一个顺畅但不降低接管保护的首次入口：
+
+- 个人微信负责创建或恢复 DxC 用户；
+- 公众号管理员扫码只把公众号加入当前租户；
+- 新设备的恢复登录仍不能用未关联身份静默创建另一个租户；
+- 并发扫码不能为同一个人留下多个 owner 或孤立租户。
+
+## 决策
+
+### 1. 增加显式 `start`，保留严格 `login`
+
+个人微信登录会话支持三个明确用途：
+
+- `start`：由用户主动执行 `dxc setup` 或 `dxc auth start`。已关联身份恢复原 owner；
+  未关联身份明确创建一个新的 owner 和租户，并立即建立身份映射。
+- `login`：只恢复已经关联的 owner。未关联身份固定失败为
+  `WECHAT_LOGIN_IDENTITY_NOT_LINKED`，不得创建租户。
+- `link`：把个人微信关联到当前有效 owner 设备，用于兼容此前已由公众号 bootstrap
+  创建的租户。
+
+“未关联身份不得静默建租户”继续成立：只有用户主动进入文案清楚的 `start` 流程才允许
+创建。公众号授权、普通 `login`、回调重放或 Agent 自报身份都不能触发该行为。
+
+### 2. 同一身份的首次分配必须收敛
+
+首次 owner 的候选 `tenantId` 和 `userId` 由已经作用域化并哈希的个人微信 subject
+通过带版本和用途分隔的 SHA-256 确定性派生。Mongo 仍使用设备 bootstrap 原子认领：
+
+- 同一 subject 的并发首次请求只能认领同一个候选租户；
+- 首个请求完成身份唯一映射；
+- 竞争请求要么在映射可见后作为新设备加入同一 owner，要么失败并要求重试；
+- 不得为竞争失败请求保留第二个随机租户。
+
+这两个 UUID 不是认证凭据；认证仍要求微信 OAuth、短时 state、设备持钥证明和服务端
+身份唯一索引。
+
+### 3. 统一首次体验
+
+`dxc setup --server <url>` 顺序执行：
+
+1. 检查当前设备会话；
+2. 无有效会话时发起个人微信 `start`；
+3. 查询当前租户的公众号；
+4. 没有公众号时发起第三方平台授权。
+
+已登录或已绑定状态会被复用，不重复扫码。两个扫码页面和回调仍使用不同 AppID、
+凭据、状态机和身份语义。
+
+## 后果
+
+- 全新用户可以先建立个人身份，再绑定自己的公众号；
+- 已有 owner 和第二设备继续使用原映射，不会创建第二个租户；
+- 旧的“公众号 bootstrap 后再 `link`”路径仍兼容，但不再是推荐首次路径；
+- 当前不增加密码、手机号、邮箱登录或 Web 工作台；
+- 部署与网站应用真实扫码仍需独立生产授权和核验。

package/docs/decisions/0008-end-to-end-content-workflow-continuity.md

@@ -0,0 +1,115 @@
+# ADR-0008：端到端内容闭环连续性
+
+日期：2026-07-30
+
+状态：Accepted（已接受）
+
+## 背景
+
+真实端到端运行证明，固定八步、不可变渲染快照、双确认门和幂等草稿意图能够恢复并
+安全交付。但运行也暴露了四个直接影响首位用户的断层：
+
+- 视觉步骤只给建议，正文没有真实配图，封面又要求用户预先准备；
+- 项目初始化不提示本地历史文章知识库，研究阶段常在空库中继续；
+- 同类 CLI 参数和错误提示不一致；
+- 异步状态、预览有效期、阶段确认依据和预览承载界面不够明确。
+
+这些问题不需要引入新平台、通用工作流引擎或生产部署，也不能改变云端权威渲染与微信
+副作用边界。
+
+## 决策
+
+### 1. Agent 生产与本地素材共同进入视觉闭环
+
+1. `visual-plan` 保留阶段机器名，但职责升级为视觉生产：既做决策，也必须形成可交付的
+   本地素材集合。默认目录为项目内
+   `assets/visuals/`；CLI 只读取用户显式传入的目录，不递归扫描其他目录。
+2. 宿主 Agent 的图片生成能力与用户明确指定的本地素材是互补来源。没有合适本地素材时，
+   Agent 在披露执行位置、数据去向和额度后实际生成图片；已有截图、照片或品牌资产时，
+   可以选择并复制到项目素材目录。两者最终使用同一文件、哈希和快照通道。
+3. Markdown 已引用的本地 PNG/JPEG 直接进入素材清单。显式素材目录中的其他图片按
+   稳定文件名顺序补入正文视觉锚点，并去除已引用图片和保留的 `cover.*`。
+4. 视觉阶段必须存在内容相关的 `cover.png`/`cover.jpg` 或文章明确声明的封面才能完成。
+   CLI 的 `--cover auto` 只解析这些已生产素材，不生成纯色、占位或测试封面。宿主没有
+   图片生成能力且没有本地封面时，流程暂停并给出启用生成能力或选择本地文件的路径。
+5. 正文图片、封面和文章正文分别计算哈希并绑定到 `assetManifestHash` 和不可变
+   `snapshotHash`。正文图片与封面使用不同微信端点和语义，不复用 MediaID。
+
+### 2. 云端权威预览由 Agent 内置浏览器承载
+
+1. 当前不提供 `preview-local`。渲染、模板和样式预览是 DxC Cloud 的权威能力，也是后续
+   权益和收费可以承载的产品价值，不能为了回应“本地优先”而复制到本地并削弱边界。
+2. 云端创建不可变快照，并在响应中返回创建时间、剩余秒数和到期时间。
+   过期后用 `preview-refresh` 为同一个快照重建短时链接，不重复上传正文和图片；旧链接
+   不能被当作仍有效的确认依据。
+3. Agent 取得短时 URL 后必须在宿主右侧内置浏览器直接展示，不在对话里发送链接，也不把
+   URL 写入项目产物。若当前宿主没有内置浏览器，不能绕过预览确认门。
+4. “是否以及如何提供本地回看”保留为独立产品 TODO，必须先回答离线能力、模板收费、
+   样式真值和隐私叙事的关系，不能由一次端到端反馈直接决定实现。
+
+### 3. 正文图片交付
+
+1. Server 接收正文、封面和有界正文图片清单，逐项校验媒体类型、大小、维度、逻辑
+   路径和 SHA-256，再形成内容寻址文章与快照。
+2. 预览图片通过同一短时 token 的受控路由读取，不暴露对象存储 URL。
+3. Worker 先复核所有快照哈希，再调用微信正文图片上传接口获得 HTTPS URL，替换最终
+   HTML 中的逻辑路径，最后上传或复用永久封面并调用一次 `draft/add`。
+4. 正文图片上传结果不确定时进入 `ASSET_UPLOAD_UNVERIFIED`，停止创建草稿且不盲目
+   重试。
+
+### 4. 初始化、CLI 与确认治理
+
+1. `project init` 必须读取本地知识库状态。用户可以在初始化时显式传入
+   `--knowledge <files...>`；空库时返回可执行的导入建议，用户也可以明确选择稍后导入
+   或跳过。CLI 仍不得自动扫描目录。
+2. `project init/resolve/status/checkpoint` 统一使用 `--directory`。调试阶段不保留目录
+   位置参数；草稿创建只接受 `--snapshot`，不保留 `--snapshot-id`。
+3. 同一动作缺少多个必填参数时一次列全。需要确认的阶段不再只抛异常，而是返回
+   `awaiting-user`、具体 `guidance` 和下一条可执行命令。
+4. `StepCheckpoint` 升级到 v3。真实确认结构化记录确认类型、绑定的产物或渲染快照
+   SHA-256、请求时间、确认时间和确认者；完成确认必须匹配上一条待确认绑定。正文和
+   标题绑定稳定的用户可见内容哈希，交付哈希必须与交付产物中的渲染快照一致；输入或
+   内容哈希变化后原确认失效。
+5. 草稿状态响应提供中文标签、说明、下一步和建议查询秒数。内部状态机继续存在，但 Agent
+   和普通 CLI 输出不得向用户展示英文状态名、Worker 或内部处理阶段。
+
+## 数据与迁移
+
+- 新文章和快照写入正文图片清单；读取旧记录时缺失清单按空数组处理。
+- `assetManifestHash` 纳入文章去重索引。Server 只迁移名称、字段顺序、唯一性和选项都
+  精确匹配的旧 `tenantId + sourceHash + coverHash` 自动索引，再建立包含
+  `assetManifestHash` 的新唯一索引；partial、sparse、collation、hidden 或自定义名称
+  的索引一律保留。生产执行这一迁移仍属于部署写入，必须先备份、只读核对并取得授权。
+- 当前调试阶段新写入统一使用 checkpoint v3。现有 v1/v2 文件仍仅用于读取已有项目；
+  旧确认没有快照绑定证据，不能在新交付动作中冒充 v3 确认。
+
+## 后果
+
+正面结果：
+
+- 具备宿主图片生成能力的用户可以自动得到内容封面与必要配图；已有本地素材也会真正进入
+  正文和草稿；
+- 知识库不再藏在独立命令里，空库状态对用户可见；
+- 云端预览直接出现在 Agent 右侧，确认体验不再依赖用户点击短时链接；
+- 队列、有效期和确认依据变成机器可读状态。
+
+代价和限制：
+
+- 当前只支持显式本地 PNG/JPEG，正文图片单张小于 1 MiB、单篇最多 20 张，不做递归
+  素材发现、裁切或压缩；
+- 宿主必须具备图片生成能力或由用户提供真实封面；不会用测试占位图假装完成视觉生产；
+- 本地回看是否存在、开放哪些样式以及如何计费仍是待决产品问题；
+- 权益、SkillPay、通用多租户 Worker 租约和自动 reconciliation（核验补偿）仍是后续
+  闸门。
+
+本 ADR 取代 ADR-0005 中“视觉只输出计划、通用闭环不支持正文内联图片”的限制描述；
+ADR-0005 的单一总控、本地知识库和线性八步边界继续有效。
+
+## 核验来源
+
+以下微信端点契约于 2026-07-30 重新核对；生产启用正文图片前仍须以测试公众号完成
+无正式发布的现场验证：
+
+- [上传图文消息内图片](https://developers.weixin.qq.com/doc/service/api/material/permanent/api_uploadimg)
+- [新增永久素材](https://developers.weixin.qq.com/doc/service/api/material/permanent/api_addmaterial)
+- [新增草稿](https://developers.weixin.qq.com/doc/service/api/draftbox/draftmanage/api_draft_add)

package/docs/decisions/0009-privileged-multitenant-draft-scheduling.md

@@ -0,0 +1,36 @@
+# ADR 0009：特权多租户草稿调度边界
+
+日期：2026-07-31
+
+状态：Accepted（已接受）
+
+## 背景
+
+微信公众号草稿 Worker 是共享后台进程，必须处理所有租户已经通过确认门创建的草稿意图。
+旧实现由环境变量锁定一个租户，导致其他租户的合法意图永久停留在队列中。直接把普通
+租户仓储改成无 `tenantId` 查询，又会模糊租户隔离边界。
+
+## 决策
+
+在 Worker 内保留一个极小的特权调度仓储边界，只允许两类跨租户操作：
+
+1. 按 `status + createdAt` 原子领取一条排队意图；
+2. 按 `status + updatedAt`、固定批次上限扫描需要中断恢复的意图。
+
+该边界：
+
+- 不接受来自用户、CLI 或 HTTP 请求的租户参数；
+- 不读取或返回文章正文、对象字节、Cookie、Token、密钥或授权凭据；
+- 只返回已经过运行时 schema 校验、且携带 `tenantId` 的任务身份与状态字段；
+- 不对 Server 路由、CLI 或其他业务仓储开放；
+- 使用与查询形状一致的全局索引，恢复扫描每批最多 100 条。
+
+任务一旦领取，账号、授权、快照、对象存储键、状态转移、凭据更新和审计事件均必须显式
+使用任务自带的 `tenantId`；状态转移同时比较 `_id + tenantId + 旧状态`，防止跨租户
+串写和并发跳转。
+
+## 结果
+
+- 一个 Worker 可以公平处理所有租户，不再依赖单租户环境变量。
+- 跨租户能力被限制在不可由外部调用的调度原语中，普通业务查询继续保持租户显式绑定。
+- 新增跨租户查询或让调度仓储返回租户内容，必须修改本 ADR 并重新进行安全评审。

package/docs/decisions/0009-versioned-cloud-template-catalog.md

@@ -0,0 +1,39 @@
+# ADR-0009：版本化云端模板目录
+
+日期：2026-07-31
+
+状态：Accepted（已接受）
+
+## 背景
+
+`wechat-minimal@1` 保住了旧工具兼容和安全边界，但不足以覆盖教程、报告、知识整理和品牌
+内容的排版需求。模板若由本地 CLI 或 Agent 自行生成 CSS，会破坏预览、确认和草稿交付使用
+同一不可变 HTML 的保证。
+
+WeMD 是 MIT 许可的开源公众号 Markdown 编辑器。本次只吸收其十套发布主题的视觉设计，
+不采用其允许原始 HTML 的 Markdown 解析链路。
+
+## 决策
+
+1. 云端维护一个固定、版本化的模板目录；目录只在预览页面呈现，不向 CLI 暴露模板管理或
+   选择能力。
+2. Agent 可以在文章 frontmatter 中填写受控 `dxc_wechat_template_hint` 作为首次预览建议；
+   用户只在预览页提交目录内的 `templateId`。服务端以受控注册表校验，拒绝未知 ID、任意
+   CSS 和任意 HTML。
+3. 保留 `wechat-minimal@1` 原样，新增模板均使用新 ID；已生成快照绝不因模板升级被重写。
+4. 所有模板复用 DxC 的 `marked` token renderer、HTML allowlist、逻辑图片路径规则、预检、
+   外链降级和最终草稿 URL 替换链路。
+5. 每个目录模板必须具备固定样例 HTML 哈希、安全回归测试和非生产公众号验证记录。未完成
+   微信后台现场验证的模板只能标记为代码契约通过，不能宣称已完成平台兼容验证。
+
+## 结果
+
+- 模板选择纳入 `RenderSnapshot`、确认和草稿幂等边界，切换模板必然产生新快照并要求重新确认。
+- CLI 只创建首个预览和发起确认；用户在预览页面的选择会记录为同一原始快照的最终选择，
+  确认和草稿交付自动使用该新快照。CLI 不携带样式资产。
+- 允许继续增加新版本模板；模板商城、租户级配置和用户 CSS 仍不在当前范围。
+
+## 许可证与来源
+
+WeMD 模板设计的版本、名称和 MIT 归属见
+[WeMD 模板来源说明](../references/wemd-template-attribution.md)。

package/docs/eight-stage-implementation-audit.md

@@ -0,0 +1,62 @@
+# 八阶段实现度审计
+
+日期：2026-08-01
+
+状态：Current（当前）
+
+## 结论
+
+八个阶段都已有可分发 Skill，但“Skill 已存在”不等于“阶段已产品化”。此前 CLI 在写
+checkpoint 时只检查产物文件存在且非空，测试甚至用一段 `# research` 占位 Markdown
+跑通八步。因此原来的 `available` 只能证明入口可调用，不能证明产物契约真实执行。
+
+本次已补齐所有阶段共用的机器校验：
+
+- YAML frontmatter、项目 ID、工作流 ID、阶段和固定 Skill 版本；
+- 实际输入种类、相对路径和 SHA-256 与 checkpoint 一致；
+- `completed`、`awaiting-user` 与产物自身状态一致；
+- 标题最终选择和 32 个 Unicode 字符上限；
+- 正文发布格式；
+- 视觉封面和正文图片的真实 PNG/JPEG、目录、体积和哈希；
+- 审校 `pass/block` 与阻断计数一致；
+- 交付完成时存在意图 ID、微信 MediaID 和完成状态。
+
+catalog 继续使用 `available` 表示“可调用”，同时新增：
+
+- `implementationLevel`：Agent 引导、Agent + 本地工具、本地 + 云端闭环；
+- `verificationLevel`：契约测试、本地集成测试、真实平台冒烟；
+- `knownGaps`：当前仍未关闭的边界。
+
+## 分阶段判断
+
+| 阶段 | 当前实现 | 判断 | 仍未完成 |
+| --- | --- | --- | --- |
+| research | 研究 Skill、本地知识库混合召回、来源/输入/产物契约校验；本地 RSS、HTTP API、公开 HTML 一次性采集；公开来源注册、手动检查和增量去重 | 部分产品化 | 定时 Runner、具名来源适配器、热度/聚类和来源健康度尚未形成 DxC 能力 |
+| brief | 九字段 Brief Skill、输入哈希和结构校验 | Agent 引导已实现 | 命题质量本来就应由 Agent 判断，不适合伪装成确定性 CLI |
+| outline | 结构选择 Skill、结构/情绪字段和输入校验 | Agent 引导已实现 | 大纲质量由 Agent 判断；尚无必要增加规则引擎 |
+| article | 写作 Skill、正文确认门、微信文章解析和渲染预检 | Agent + 本地工具已实现 | 事实质量仍依赖研究和审校；生产前仍需真实内容人工确认 |
+| titles | 候选生成 Skill、最终选择、正文哈希、长度和确认绑定 | Agent 引导已实现 | 点击效果不能靠静态规则证明，后续只能用发布数据反馈 |
+| visual-plan | 本地素材选择或宿主图片生成、真实文件/格式/体积/哈希校验、交付上传 | Agent + 本地工具已实现 | 宿主没有图片生成能力且用户未给素材时仍会暂停；当前自动内联按正文二级标题和文件顺序分布，精确语义锚点仍待单独契约化 |
+| quality-review | 审校 Skill、输入绑定、结论和阻断计数校验 | Agent 引导已实现 | 事实语义核验和风格判断仍由 Agent 承担，没有独立自动事实核查器 |
+| delivery | 账号选择、上传、云端权威渲染、右侧预览、快照确认、Worker、微信草稿和回读 | 本地 + 云端闭环已实现 | 正文图片真实平台专项验证、通用租约心跳/核验补偿、支付权益和生产部署门禁仍未关闭 |
+
+## 哪些不是“阶段没实现”
+
+Brief、大纲、正文、标题和审校的核心工作是 Agent 的语义判断。它们不需要各自再造一个
+服务端生成器。正确完成标准是：
+
+1. Skill 真正被调用；
+2. 输入和输出结构可验证；
+3. 需要确认时不能绕过；
+4. 上游变化后下游自动失效；
+5. 交付前由权威渲染和真实平台边界再次校验。
+
+本次补的是第 2 项此前缺失的机器真值，不把“再写一个规则引擎”误当成实现进度。
+
+## 下一条真实缺口
+
+现在最明显的缺口不再是八阶段壳子，而是 research 上游的持续采集能力。RSS、HTTP API
+和公开 HTML 已能由本机一次性、可追溯地读取；`dxc monitor` 也已能保存公开来源、手动运行、
+记录结果并增量去重。它仍不是定时监控系统：时间序列、调度、健康度、热度和聚类应作为八阶段
+之外的本地研究监控层，产出候选和证据，再由 `research` 阶段按具体文章主题消费。具体设计见
+[研究监控与爆款拆解设计](research-monitoring-design.md)。