阶段七:本地应用 MVP 与应用运行规范
阶段状态:已完成并归档
计划状态:已完成
当前工作包:P7-8 连续使用、生产发布与阶段归档(已完成)
计划状态
- 计划名称:阶段七:本地应用 MVP 与应用运行规范。
- 阶段编号:P7。
- 当前状态:计划已完成,P7 已授权实施;当前进入 P7-8 连续使用、生产发布与阶段归档收口。
- 前置依赖:P6 应用注册、应用中心、本地资料分析与验收样板、平台对象关联、恢复路径和生产验收已完成并归档。
- 当前记录:本页冻结 P7 的实施边界、工作包、成果契约和验收方法;Runtime/Console 已完成首批增量实现,生产发布与连续使用验收仍未完成。
- 完成边界:把 P6 的“可运行样板”收敛为可持续使用、可配置、可追溯、可恢复、可导出、可备份和可维护的正式本地应用,并形成可供 P8 复用的应用运行规范。
阶段目标与最终成果契约
P7 不增加新的业务赛道,而是解决“P6 样板已经跑通,但还不能作为长期应用稳定使用”的问题。完成后,Benson 应能在应用中心持续使用“本地资料分析与验收工作台”,无需理解 Task Graph、Worker、Runtime Call、Nomad Allocation 或底层存储路径。
P7 的最终交付必须同时包含:
- 一套稳定、版本化的应用 Manifest、设置、输入集合、运行、结果和历史契约。
- 一个面向人的正式应用工作区,覆盖创建分析、查看进度、读取结果、比较版本、重新运行、导出和恢复。
- 每次运行可追溯到冻结的应用版本、设置版本、输入哈希、模型通道、预算、成果和证据。
- 可审计的 Token、模型调用和基础设施成本归属;事实缺失时显示“未知”,不得以
0伪装精确值。 - 不覆盖旧结果的受控重新运行、部分失败处理、中断恢复和错误说明。
- 可校验的结果导出、应用逻辑备份和受控恢复,以及对应运维手册。
- 连续真实使用、桌面与移动端、Runtime 重启、生产发布和回滚证据。
最终成果只有在本页所有出口条件通过后才可标记为“P7 已完成”。单项页面、接口或测试通过不能代表阶段完成。
进入条件
P7 启动前必须确认:
- P6 已完成并归档,且权威归档记录包含提交、CI、镜像摘要、数据库迁移、生产健康和公网验收证据。
- 应用中心已经存在稳定的
application_id、Manifest 版本、注册状态和独立工作区。 - 本地资料样板已能从明确文本或已登记 Cloudreve 文件引用生成结构化结果,并关联 Conversation、Plan、Task、Deliverable 和 Evidence。
- P6 已验证刷新不串应用、停用不删除历史、Runtime 重启不重放模型请求,以及失败时不误报成功。
- P6 真实使用问题、技术债和不支持输入清单已经形成可审阅记录。
- Runtime SQLite 已完成发布前备份与
quick_check,P1-P6 数据迁移回归通过。
任一条件未满足时,问题归属 P6 收口,不得通过 P7 新功能掩盖。
定位与非目标
P7 的定位是“单个本地应用的正式 MVP 和应用运行规范”,不是多应用平台扩展。
本阶段明确不做:
- 第二个应用、应用市场、第三方插件安装或任意代码加载;
- 求职、职位抓取、商业机会发现、外部账号、投递、邮件、付款或其他外部业务写入;
- React 重写、微前端、第二 Runtime、第二任务状态机或第二调度器;
- 多用户、多租户、跨应用共享隐式状态或复杂组织权限;
- 应用自行管理 Provider、凭据、Worker、Nomad、Cloudreve 管理权限或长期记忆;
- 用 P7 重新实现 P6 已完成的应用注册表、基础入口或平台对象关联。
P7 发现 P6 基础契约缺陷时,应先记录兼容影响并修正权威基础契约,不得在应用页面增加旁路状态。
技术栈与架构选型
P7 延续现有 FastAPI + SQLite + Vanilla JavaScript 和 Runtime 内置应用机制,不引入新的前端框架、数据库、队列或调度器。
| 方案 | 可维护性 | 部署复杂度 | 性能 | 学习成本 | 后续扩展 | 结论 |
|---|---|---|---|---|---|---|
| 扩展现有 Runtime、SQLite 与 Console | 与 P1-P6 迁移、认证、审计和发布链一致 | 低,只做增量迁移和现有镜像发布 | 满足当前单用户、本地应用负载 | 最低 | P8 可复用稳定契约 | 采用 |
| 引入 React 或微前端重写应用区 | 产生第二套构建和状态管理 | 中高 | 对单应用 MVP 无决定性收益 | 高 | 适合多团队独立发布,当前过早 | 不采用 |
| 独立应用服务和独立数据库 | 容易形成双状态和跨库恢复 | 高 | 当前规模没有实际收益 | 中高 | 多应用规模扩大后再评估 | 不采用 |
| Redis、消息队列或应用私有调度器 | 增加恢复、幂等和运维面 | 高 | 当前吞吐不需要 | 中高 | 会破坏 Runtime 与 Nomad 权威边界 | 不采用 |
该方案优先保持数据权威唯一、部署简单和回滚可控。P7 冻结的应用运行规范必须能被 P8 复用,但不为尚未发生的多应用需求预建复杂扩展层。
简化架构与职责边界
flowchart LR
Benson["Benson"] --> Console["Console 应用工作区"]
Console --> Runtime["现有 AI Runtime"]
Runtime --> Contract["应用设置 / 输入集合 / 运行快照"]
Runtime --> Boss["AI BOSS / Worker"]
Runtime --> Result["结果 / 证据 / 版本历史"]
Runtime --> Cost["用量 / 成本 / 审计"]
Runtime --> Storage["SQLite / Cloudreve"]
Result --> Console
Storage --> Export["导出 / 备份 / 恢复"]
- Console 负责面向人的操作和结果表达,不保存权威业务状态,不直接访问 Worker、Nomad 或系统 WebDAV。
- Runtime 负责契约校验、状态、版本、幂等、恢复、平台对象关联和审计,不复制 OmniRoute Provider 管理。
- AI BOSS 负责分析目标、计划、审核和人类可读结论;Worker 只执行已登记的无状态任务。
- Nomad 继续是唯一节点放置与任务调度器;应用不得创建自己的队列或后台执行器。
- SQLite 保存结构化状态和小型结构化结果;长期文件、导出包和较大成果进入 Cloudreve。
- 文件内容只经
cloud.yohan.fun公网 HTTPS 数据面传输。Console、认证回源代理和普通 Runtime JSON API 不上传、下载或中转文件字节。
稳定数据契约
P7 在 P6 表结构上做增量扩展,不迁移或重写 P1-P6 既有 Plan、Task、Deliverable、Evidence、Conversation、Memory、预算或审计记录。具体表名可在实施前按现有代码命名规范确定,但下列逻辑对象和字段语义必须稳定。
应用设置版本
ApplicationSettingsVersion 至少保存:
settings_version_id、application_id、递增版本号和状态;- 分析目标模板、输出结构、语言、允许输入类型和结果保留选项;
- 模型通道选择规则、推理等级、工具白名单和预算引用;
- 创建时间、创建来源、替代关系和内容哈希。
设置保存必须创建新版本,不原地改写被运行引用的版本。旧版本可读、不可静默删除;恢复旧设置应创建一个内容相同的新当前版本,而不是移动历史指针伪造时间线。
输入集合与输入项
ApplicationInputSet 与 ApplicationInputItem 至少保存:
- 输入集合 ID、应用 ID、名称、用途、创建时间和内容哈希;
- 文本输入的受限内容或哈希;文件输入的 Cloudreve 已登记引用、显示名称、类型、大小和 SHA-256;
- 输入排序、有效状态、解析状态、真实失败原因和替代关系;
- 数据等级、来源声明以及 Benson 明确选择的事实。
原始文件不写入 SQLite。输入集合版本一旦用于运行即冻结;后续增删资料必须创建新输入集合版本。
应用运行快照
ApplicationRun 在 P6 运行对象基础上至少冻结:
application_run_id、application_id、应用版本和 Manifest 版本;- 设置版本、输入集合版本及其组合哈希;
- Conversation、Plan、Task、Deliverable、Evidence 关联;
- 模型通道、实际 Provider/模型事实、推理等级、预算和工具白名单;
client_request_id、幂等键、父运行、重跑原因和触发人;- 状态、阶段、开始/结束时间、错误分类、错误原因和下一步。
同一个 client_request_id 的重复请求不得创建第二次运行或重复消费 Token。运行快照形成后不可修改,只能通过追加事件、结果版本或新运行表达变化。
P7 直接继承 P6 的 created -> validating -> queued -> running -> checking -> reviewing 运行状态机及其终态,不另造同义状态。P7-0 只允许根据 P6 生产证据补充转换条件或错误分类;如确需新增状态,必须先修订 P6 基础契约、兼容读取和迁移方案,不能由 Console 或单个工作包自行增加。
结果与版本
ApplicationResultVersion 至少保存:
- 结果版本 ID、应用运行 ID、版本号、状态和内容哈希;
- 摘要、已确认事实、发现的问题、风险、验收项、证据引用和下一步;
- 完整、部分成功、失败、等待 Benson 或被替代等真实状态;
- 生成来源、AI BOSS 审核、Benson 决定、创建时间和替代关系;
- 小型结构化内容或 Cloudreve Artifact 引用。
结果修正、审核返工和重新运行都必须保留旧版本。任务执行完成不等于应用结果已验收;最终状态只能由现有成果检查、AI BOSS 审核和 Benson 决策链得出。
用量与成本归属
ApplicationUsageAllocation 关联应用运行、Runtime Call、任务和实际用量事实,至少包含:
- 输入/输出/总 Token、调用次数、时长和状态;
- Provider 返回的原始 USD 成本及来源时间;
- 可验证时的业务成本与换算依据;
- Nomad 任务、Worker 时长或其他可审计基础设施事实;
known、partial、unknown的完整性状态。
缺失 Token、价格或换算依据时必须显示“未知”或“部分可知”。不得建立 Console 不可见的内部 Token 限制;预算完全复用现有 AI 工作台的可见设置,“无限制”必须按无限制执行。
导出、备份与恢复记录
ApplicationExport、ApplicationBackup 和 ApplicationRestore 至少保存:
- 请求 ID、应用 ID、范围、格式、状态、创建人和时间;
- 清单版本、对象数量、文件引用、SHA-256 和 Cloudreve 精确路径;
- 源平台版本、Manifest 版本、兼容性检查结果和失败原因;
- 恢复模式、目标命名空间、冲突决定、恢复结果和审计关联。
恢复记录只追加。任何失败不得留下“已恢复”的假状态,也不得覆盖 P1-P6 或当前应用的既有对象。
API 契约
接口沿用现有管理员认证、版本号、状态校验、client_request_id 和幂等规范。路径前缀应与 P6 实际实现一致;以下描述冻结能力和语义,不要求建立第二套 API 风格。
设置与输入
- 查询当前设置和设置历史;创建新设置版本;从历史版本创建新的当前版本。
- 创建、查询和关闭输入集合;登记文本或已允许的 Cloudreve 文件引用;提交前校验类型、大小、哈希和数据范围。
- 禁止通过这些接口上传文件字节、提交主机路径、任意 URL、WebDAV 凭据或浏览器文件系统路径。
运行与历史
- 创建运行、查询运行列表/详情、取消仍可取消的运行、查询人类可读进度和错误。
- 历史列表支持状态、时间、输入集合和结果状态筛选,并返回稳定分页游标。
- 运行详情返回结果摘要、版本、证据、成本完整性和下一步;技术事件默认按需展开。
重新运行与恢复
- “重新运行”必须先显示将冻结的输入、设置、模型通道和预算,再由 Benson 通过项目主题的居中自定义弹窗确认。
- 重新运行创建新的
application_run_id、幂等键和预算快照,并保存父运行与原因;不得重放旧模型请求或覆盖旧结果。 - 中断后的恢复只推进已经具备确定性证据的后续步骤;需要再次调用模型时必须创建新运行。
- 部分失败允许只对明确失败、无副作用且输入未变化的步骤创建修正任务,但必须保留原任务和证据。
导出、备份与恢复
- 导出支持人类可读报告和结构化清单;大文件结果只返回 Cloudreve 入口和精确路径。
- 应用逻辑备份包含 Manifest/设置/输入元数据/运行/结果/证据关联/成本与审计清单,不复制凭据、隐藏推理或主机路径。
- 恢复必须先执行只读预检,输出兼容性、对象数量、哈希和冲突;Benson 明确确认后才执行。
- 相同恢复请求重复提交不得重复创建对象;对象 ID 冲突使用明确映射并保留来源 ID,不得静默覆盖。
所有接口错误必须返回稳定错误码、人类可读原因、是否可重试和下一步。不得以笼统 409 或 500 隐藏状态冲突、输入不支持、文件不可达、预算不足或版本不兼容。
Console 工作区契约
P7 继续在 P6 应用中心内完善单应用工作区,不创建第二控制台。页面至少包含:
- 顶部应用身份、版本、状态、最近运行、当前设置和主要操作;
- “新建分析”区:选择或新建输入集合、分析目标和设置版本,提交前展示可读摘要;
- “当前进度”区:说明正在做什么、已完成什么、失败原因和下一步,不把技术 ID 当作主要内容;
- “结果”区:摘要、事实、问题、风险、验收项、证据和下一步,支持明确的完整/部分/失败状态;
- “历史”区:筛选、搜索、版本比较、返回结果和受控重新运行;
- “设置”区:当前版本、历史版本、差异和从旧版本创建新版本;
- “用量与成本”区:本次与历史汇总、数据完整性和更新时间;
- “导出与恢复”区:导出、备份、恢复预检、结果和审计记录。
面向 Benson 的关键决定在应用工作区和对应 AI BOSS 对话中提供一致入口;底层任务页、成果页和审计页继续用于查询,不产生第二套决定状态。
所有确认、设置、重新运行、删除边界和恢复操作使用符合项目主题、页面居中的自定义弹窗,禁止浏览器 alert、prompt 和 confirm。桌面 1440x900 与移动端 390x844 均不得横向溢出;长文件名、路径、哈希和错误必须折行或在详情中展开。
历史、版本与重新运行规则
- 历史以
application_id聚合,以运行和结果版本形成时间线,不按当前页面状态临时拼装。 - 切换、刷新或重新登录后必须恢复同一应用、筛选条件和已选择记录,不得串到其他主题或运行。
- 版本比较只比较可解释字段:输入、设置、模型通道、结果章节、证据、成本和状态;隐藏 Prompt 与隐藏推理不展示。
- 旧运行、旧结果、旧设置和旧证据默认长期可读。停用应用只阻止新运行,不隐藏历史。
- “重新运行”表示基于明确选择的输入和设置创建新运行;“修正结果”表示针对已有检查或审核意见创建新版本,两者文案和状态不得混用。
- 删除在 P7 只支持明确的数据修正或逻辑解除引用,必须展示影响范围、保留审计并遵守既有长期数据规则;不得提供无边界批量删除。
导出、备份与恢复边界
结果导出
- 小型结果可导出为 Markdown 和 JSON;PDF 如实施必须由受控、版本化转换器生成并纳入测试。
- 导出内容包含应用/运行/结果版本、生成时间、输入摘要、结果、证据清单和哈希。
- 大型或长期导出通过 Runtime 的 root-only StorageAdapter 写入 Cloudreve 长期范围;用户从
cloud.yohan.fun数据面访问。
应用逻辑备份
- 逻辑备份用于单应用迁移和恢复验证,不取代发布前的 Runtime SQLite 全库备份。
- 备份包由结构化清单和 Cloudreve Artifact 组成,必须可离线校验 SHA-256。
- 不包含 Provider Key、Console Key、WebDAV 密码、Nomad Token、主机凭据、原始隐藏 Prompt 或隐藏推理。
受控恢复
- 先做只读预检,再由 Benson 确认执行;恢复过程中不得调用模型或自动重新执行历史任务。
- 默认恢复到隔离的应用恢复批次并建立 ID 映射,校验通过后才标记可用。
- 恢复后必须比对对象数量、清单哈希、结果哈希、Cloudreve 文件可达性和审计链。
- 回滚恢复操作只撤销本次新增映射和对象,不删除恢复前数据;无法安全撤销时必须在执行前明确阻止。
工作包与验收契约
P7-0 基于 P6 证据冻结 MVP 与应用运行规范
目标:把 P6 实测证据转化为 P7 的固定范围和兼容基线。
交付:P6 问题清单、Manifest v1 兼容矩阵、P7 数据/API/Console 契约、迁移和回滚设计。
验收:每项 P7 能力都有 P6 证据或明确用户价值;P6 缺陷已归属;不存在第二应用、外部业务或第二调度器范围。
依赖:仅在 P6 完成并归档后开始;通过后才能实施其他 P7 工作包。
P7-1 稳定设置、输入集合和运行快照
目标:建立不可被后续修改污染的版本化输入与设置。
交付:增量 SQLite 迁移、设置版本、输入集合/输入项、运行冻结字段、索引和兼容读取。
验收:旧数据库迁移通过;被运行引用的设置和输入不可原地改写;刷新和重启后哈希、版本与关联一致;不重写 P1-P6 数据。
依赖:P7-0。
P7-2 正式应用工作区与人类工作流
目标:让 Benson 不接触平台内部对象即可完成一次完整分析。
交付:新建分析、当前进度、结果、错误、下一步、设置摘要和对应 API。
验收:成功、部分成功、失败、取消和中断均显示真实状态;关键决定有即时反馈;所有弹窗为主题一致的居中自定义弹窗;桌面和移动端无溢出。
依赖:P7-1;复用 P6 工作区和对象关联。
P7-3 历史搜索、版本比较和结果追溯
目标:把多次使用形成可查、可比、可返回的长期记录。
交付:稳定分页历史、筛选和搜索、设置/输入/结果差异、证据与平台对象跳转。
验收:至少三次不同设置或输入的运行可正确比较;刷新、切换和重新登录不串记录;从结果到证据、从技术详情回应用工作区均可达。
依赖:P7-1、P7-2。
P7-4 受控重新运行、部分失败和中断恢复
目标:在不覆盖历史、不重复消费和不自动重放模型请求的前提下恢复工作。
交付:重新运行预览与确认、父子运行关系、失败步骤修正、Runtime 启动恢复和幂等处理。
验收:重复请求只创建一次;重新运行产生新 ID 和快照;重启中的未完成模型调用标记中断且不自动重放;旧结果、证据和成本完整保留。
依赖:P7-1 至 P7-3。
P7-5 用量、成本与运行观测
目标:为单应用建立可解释、可审计的资源使用归属。
交付:Runtime Call/Task 到应用运行的用量关联、成本完整性、历史汇总、最近失败和数据时间戳。
验收:已知成本与 OmniRoute/Runtime 事实一致;未知或部分数据不显示为零;不产生隐藏 Token 限制;“无限制”设置不被内部冻结值阻断。
依赖:P7-1、P7-2;可与 P7-3 后半段并行,但不得改动其历史权威模型。
P7-6 结果导出与数据修正边界
目标:让结果可带走、可验证,并允许受控修正错误元数据。
交付:Markdown/JSON 导出、导出清单与哈希、Cloudreve 访问能力、有限数据修正和审计。
验收:下载侧哈希与登记值一致;大文件不经 Console/Runtime JSON 中转;修正不覆盖旧版本或删除审计;不可导出时给出原因和下一步。
依赖:P7-2、P7-3、P7-5。
P7-7 应用备份、恢复、升级与回滚
目标:证明首个正式应用能够在单应用范围内迁移、恢复和升级,而不破坏平台既有数据;P8 只负责把这条已验收路径泛化为按 application_id 隔离的多应用升级。
交付:逻辑备份格式、恢复预检与执行、Manifest/设置兼容检查、运维手册、升级和回滚路径。
验收:在隔离恢复批次完成一次真实备份恢复;对象数和哈希一致;不包含凭据;失败恢复可清晰回退;P1-P6 和恢复前 P7 数据不变。
依赖:P7-1 至 P7-6。
P7-8 连续使用、生产发布与阶段归档
目标:用真实连续使用证明应用达到正式 MVP,而不是一次性演示。
交付:自动化报告、浏览器证据、连续运行记录、重启与恢复证据、生产发布记录、回滚验证和 P7 归档。
验收:本页“验证矩阵”和“P7 出口”全部通过;问题修复后完成复测;Docs、公网 Console 和生产镜像与 GitHub 权威提交一致。
依赖:P7-0 至 P7-7 全部完成。
分布式底座接入声明
- 接入结论:接入 P6 已验收的统一 AI Runtime 与分布式底座,不新增基础设施组件。
- 使用层:Network 只承载已登记控制面通信;Nomad 是唯一分布式任务调度器;Compute 只执行不含 Cloudreve 文件字节的已登记无状态分析能力;Storage 保存应用设置、输入引用、运行、结果和 Artifact;Observability 汇总真实状态、Token、已知成本和错误。
- Adapter 归属:复用现有 Model、Nomad、Storage、Tool 和 Feedback Adapter;本地应用不得创建私有 Provider Router、调度器、凭据代理或第二套成果状态机。
- 执行映射:主节点保存应用权威状态、私有内容、审核和审计,并通过 root-only StorageAdapter 完成所有 Cloudreve 文件下载、校验与解析;
pcdell-101、pcdell-103仅在 Nomad 根据实时能力选择后执行不含文件字节的最小化无状态任务,应用和模型不能指定节点。 - 数据路径:文件只经
cloud.yohan.fun公网 HTTPS 在 Cloudreve 与实际使用方之间直达;Console 与 Runtime JSON API 不接收文件字节,不经 Tailnet、SSH、Nomad 分发或节点共享目录传输业务文件。 - 凭据路径:凭据只由受控服务持有并保存引用;Worker、模型、浏览器和 MCP Tool 不得取得基础设施、Provider、Cloudreve 管理、WebDAV、SSH、Docker 或 Nomad 控制凭据。
- 生命周期:应用设置、输入元数据、运行、结果、证据、成本和审计长期保留;受控重新运行创建新
application_run_id;只清理精确归属的临时副本和一次性凭据,普通状态不设置人为 TTL。 - 验收证据:真实应用运行、Nomad Job/Allocation(适用时)、实际执行节点、Runtime 调用、Storage 下载侧哈希、结果版本、成本完整性、故障恢复、Console 桌面/移动端和公网回读。
依赖顺序
flowchart LR
P70["P7-0 契约冻结"] --> P71["P7-1 数据与快照"]
P71 --> P72["P7-2 正式工作区"]
P72 --> P73["P7-3 历史与比较"]
P73 --> P74["P7-4 重跑与恢复"]
P72 --> P75["P7-5 用量与成本"]
P73 --> P76["P7-6 导出与修正"]
P75 --> P76
P74 --> P77["P7-7 备份与升级"]
P76 --> P77
P77 --> P78["P7-8 生产验收与归档"]
P7-5 在 P7-2 完成后可与 P7-3 并行,但不得改动 P7-3 的历史权威模型;数据库迁移、恢复和发布必须按依赖串行推进。不得为了并发让多个实现同时修改同一迁移或状态机。
验证矩阵
单元与迁移
- 从 P6 生产结构的副本执行增量迁移,验证旧数据、索引、外键和
quick_check。 - 设置和输入不可变、内容哈希、版本递增、幂等键、父子运行和替代关系。
- 成本
known/partial/unknown、无限制预算、导出清单、恢复 ID 映射和冲突处理。 - 不支持类型、大小超限、哈希不符、Cloudreve 不可达和版本不兼容的稳定错误。
集成
- 文本、Markdown、JSON 和 P6 已确认支持的 PDF 输入形成完整运行、结果、证据、成本和审计。
- 同一输入使用不同设置生成两个独立版本,并可比较差异。
- 重复提交不重复调用模型;重跑创建新运行;部分失败只修正允许步骤。
- Runtime 重启将不确定调用标记中断,不自动重放;受控重跑后保留原历史。
- 导出、Cloudreve 写入、下载侧哈希、逻辑备份、预检和隔离恢复闭环。
Console 浏览器
1440x900和390x844覆盖新建分析、进度、结果、历史、比较、重跑、设置、成本、导出和恢复。- 刷新、前进后退、切换标签、重新登录和慢请求不丢状态、不串运行。
- 所有弹窗居中且符合主题;长名称、哈希、路径、错误和结果无横向溢出。
- 技术 ID 和原始审计默认折叠;页面主要内容对非技术用户可理解。
连续真实使用
- 使用不含敏感信息的真实本地资料,完成至少三个自然日或一个经 Benson 确认的连续使用窗口。
- 覆盖至少三次成功、一次部分失败、一次输入拒绝、一次受控重新运行和一次 Runtime 重启恢复。
- 比对每次输入、设置、结果、证据、用量、成本完整性和下一步,不允许假通过。
生产与公网
- 发布后回读 Runtime 健康、Console 应用工作区、Cloudreve 结果和 Docs 计划/归档。
- 验证生产数据库备份、镜像摘要、服务重启恢复、外部 HTTPS、静态资源和浏览器错误。
- 从用户数据面下载导出或备份 Artifact 并复算 SHA-256。
发布顺序
- 冻结权威提交,执行计划状态校验、单元、迁移、集成、严格 Docs 构建和浏览器回归。
- 备份 Runtime SQLite,记录路径和哈希,并执行
quick_check。 - 发布 Runtime,完成迁移、健康、兼容读取和重启验收。
- 发布 Console,完成桌面、移动端和真实应用工作流验收。
- 发布 Docs,从公网回读 P7 当前状态、运行手册和实际完成证据。
- 记录 Git 提交、CI、镜像摘要、数据库版本、健康、真实运行和回滚证据后,才允许归档 P7。
生产运行只依赖已发布镜像、Runtime SQLite、Cloudreve 数据和既有服务,不依赖 Git 工作树常驻。
回滚策略
- Runtime 和 Console 使用上一已验证镜像回滚;回滚前后都执行数据库备份和
quick_check。 - 增量列和新表默认保留,旧版本必须忽略不认识的数据;不得为回滚删除 P7 历史、结果、证据、导出、备份或审计。
- 新功能通过明确开关控制时,关闭开关只阻止新操作,不隐藏或删除既有记录。
- Manifest 或设置升级失败时恢复上一兼容版本用于新运行,已冻结运行继续引用原版本。
- Cloudreve Artifact 保留原路径与哈希;回滚不得把长期文件复制回主机或经 Tailnet/SSH/Nomad 传输。
- 数据迁移若无法向后兼容,发布必须在生产前停止;不得依赖破坏性降级脚本补救。
P7 出口与 P8 进入条件
P7 只有同时满足下列条件才可完成归档:
- P7-0 至 P7-8 的交付与验收全部通过,没有被文档措辞替代的未实现能力。
- 本地资料分析与验收工作台已完成连续真实使用,不再只是 P6 样板。
- 设置、输入、运行、结果、历史和证据版本稳定,刷新与重启后不丢失、不串联。
- 重新运行、部分失败、中断恢复和幂等经过真实验证,不覆盖历史、不重放旧模型请求。
- 成本归属真实可审计,未知明确显示,不存在 Console 不可见的内部 Token 限制。
- Markdown/JSON 导出、Cloudreve 数据面、下载侧哈希、逻辑备份和隔离恢复通过。
- Runtime、Console、Docs 的自动化、桌面、移动端、生产、公网和回滚验收全部通过。
- GitHub 权威提交、生产镜像摘要、数据库版本和 Docs 状态一致。
完成归档后,才允许进入阶段八:多应用扩展与应用生命周期,验证第二个应用、跨应用隔离和生命周期。P8 不得在 P7 尚未形成稳定单应用运行规范时提前实施。