建立可移交的 AI 软件交付规划文档仓库。

纳入截至 2026-10-13 会议回写后的产品基线与会议图源。

03-系统架构与领域模型.md

@@ -0,0 +1,446 @@
+# AI 软件交付与持续服务平台领域模型与架构候选
+
+状态：版本 0.15，更新日期 2026-10-13。阶段 2 历史讨论仍留在后文。2026-10-13 会议对应用、组件和工单版本的修订见下一节，依据 D085、D086。架构和实施尚未定案。
+
+## 2026-10-13 会议对领域基线的修订
+
+| 事项 | 现在采用的口径 |
+| --- | --- |
+| 任务执行与恢复 | 不单独做「任务执行、版本与恢复 / 自动能力与人工接续」层。每一次工单创建一个版本，恢复使用这个版本 |
+| 应用 | 应用指功能。邮箱应用是例子。后文把仅邮箱写成零 APP、把邮箱只写成独立服务的句子，以此节为准改读 |
+| 组件 | 初级版本不提供 Web、API、worker 选择，按应用预设固定带上。高级版本以后用界面选择这个项目要不要组件 |
+| 域名 | 域名是需要购买的资源，不包含在应用里 |
+
+工单版本是完成后的结果版本，还是同时保留发起前版本，以及带数据恢复是否仍另选时间点，尚未说明。下文原有的两层恢复记录保留，待这次口径补全后再决定是否替代。
+
+## 阶段 2 完成基线与后续交接
+
+本节汇总最终结论，后文保留各轮论证。本阶段完成的是业务概念、主要关系和默认边界；不把尚未讨论的具体价格、期限或技术实现一并认定为已确认。
+
+| 概念与关系 | 已确认基线 |
+| --- | --- |
+| 客户与项目 | 普通客户拥有项目，项目代表一个业务目标；仅邮箱可无 APP，项目可包含多个 APP |
+| 项目组 | 单层，一个项目至多归属一个组；用于整理和汇总，不改变授权、资源隔离或历史账目 |
+| 应用目录与预设 | 同时支持单应用和组合方案，项目可继续添加 APP；软件及支持版本声明必需/可选组件和资源，无平台统一必需组件清单 |
+| APP 与部署组件 | APP 是完整软件实例，Web/API/worker 等为可分别配置运行资源的组件，不与 Deployment 或副本数一一对应 |
+| 项目与环境资源 | 同集群同环境默认同 namespace，实际名称显式绑定；数据库是独立资源，业务默认项目逻辑数据库独立，同项目 APP 可按授权共享 |
+| 资源归属与引用 | 保存归属与使用绑定，最后引用移除前提示，采用使用中/待释放/已释放；宽限期重新引用可取消释放，执行前重查引用及操作状态 |
+| 独立服务与购买记录 | 域名、邮箱、API 等独立选配，购买/订阅与实际开通、使用分别记录；删 APP 不自动取消独立服务，账目按实际购买项汇总，共享资源不重复收费 |
+| 工单范围 | 一个工单只属于一个项目，可改多个 APP，跨项目分别提交；提交需求与附件保持可核对，新增/改变需求另建工单，沟通归客服/TG |
+| 发布与版本 | 平台保存业务主记录并关联 Git 工程记录；项目发布组合记录各 APP 的实际提交、产物、配置、结构及恢复点，工单提交版本与执行基准分别保存 |
+| 回退与数据恢复 | 普通版本回退默认保留业务数据并检查兼容，带数据恢复另选时间点并明确影响；风险改动前建立恢复点，基础备份独立于工单 |
+| 预览与正式访问 | K8s 持续实例通过默认域受保护预览，工单完成直接更新；正式上线允许平台购买域名或客户自有域名绑定，默认域不得正式公开 |
+| 预览地址与保护 | 使用独立唯一标识绑定应用端点，统一预览网关显示提示，采用所有者登录/受控分享并配合验证；未来沙盒为隔离临时实例及临时入口 |
+| 项目协作与公共服务 | 独立项目通过明确 API 关系和授权协作；平台拥有公共应用，客户购买其 API 服务权益，分组不自动互通 |
+| 计费与供应方式 | 持续基础服务包年，定制按原工单规则；资源支持自建与未来外部数据库/存储，供应商成本和服务加价可配置 |
+
+用户的概括认可确认上述已讨论的推荐方向，包括平台工单关联 Git 工程记录和需求固定原则；没有替代尚缺的经营主体/客户地区事实，也没有自动确定三天释放期、备份保留时长、费用金额或具体供应商。
+
+| 后续阶段 | 交接事项 |
+| --- | --- |
+| 阶段 3：02/05 | 注册购买与开通状态，付款授权和失败处理，人工金额确认，AI 转人工费用，续费/扩容/退款，释放期与备份保留，分享权限和举报处置，域名绑定/采购收费 |
+| 阶段 4：03 | 平台单库/多库和模块责任，Git 服务与同步机制，网络和入口保护，权限及一致性，托管资源适配与数据恢复技术方案 |
+| 阶段 5：迁移规划 | 旧项目标识与真实资源映射，旧默认域/正式域及工单记录导入，切换和回退 |
+| 阶段 6：04 | 应用接入版本契约，多 APP 发布协调，备份/恢复演练，沙盒隔离、工作流和资源释放实现 |
+| 阶段 7：06 | 首期范围、试点、明确验收指标、实现任务与排期 |
+
+阶段 2 无需追加全面确认。当前以 02/05 核对四条业务路径，再讨论权益和费用；新业务事实允许回溯修订。以上表保存阶段 2 收口时基线，后续补充以本节为准。
+
+### 阶段 3 对领域关系的补充
+
+| 新事实 | 模型影响与尚待评审方案 |
+| --- | --- |
+| 普通/高级向导 | 同一项目/APP/资源模型的不同操作界面，不拆成两个权威业务系统 |
+| 付款与开通 | 订单、支付及各项服务开通结果分开；支持部分完成、等待人工和异常核查 |
+| 失败后修订需求再试 | 原工单关联不可覆盖的需求修订及执行尝试；新尝试绑定一个修订/基准/预算，真正扩大范围仍新工单 |
+| 系统回执 | 状态、修改摘要、失败与恢复结果属于工单执行记录，不扩展为客服会话 |
+| 外部工作流 | 推荐平台持有执行记录，第三方运行 ID/事件/查询通过适配器关联；引擎成功不能直接作为发布完成 |
+| 年付与 AI 权益 | 年度开发/运维套餐可包含 AI 用量；充值积分、套餐包含用量与未来测试赠送独立，超额按实际成本扣充值 |
+| 熟客价格政策 | 普通账户匹配固定项目服务费和赠送政策；中介不成为新角色层级，原订单保留规则版本 |
+| 退役与再部署 | 退役不退年费，仅存代码/启动配置等轻量材料，释放运行/数据库/文件/相关备份；重部署初始化新业务，不恢复旧数据或计算退款差价 |
+| 到期未续费 | 外部停服、最多一周业务数据保留、续费恢复或释放；具体代码/备份保留与资源引用保护需协调 |
+| 系统外差额 | 首期不建退款引擎，建议订单可关联人工结算说明；不能覆盖原价或伪造自动退款结果 |
+
+代码/配置归档与业务数据清理已明确，计算减配和附件隔离仍属建议。首期充值消费，初始推荐 100 积分/USD；AI 调用成功与否不改变已耗费用。测试赠送只能支持非正式部署，平台可销毁测试资源，不能影响已购正式服务。客户/价格客户组可预留例外退役结算，但首期仅启用年付不退，客户自建项目组不等同价格客户组。
+
+上述是领域责任，不冻结表结构。包含权益、试用权益、充值账本、年度套餐和项目/资源生命周期分别表达；不能合成一个余额或“已删除”字段。原始调用、套餐抵扣、积分扣费和实际发布也不是同一结果，重复事件不得重复扣费。
+
+阶段 4 工作流/Git 专题：比较内部执行与第三方接口，确定平台状态所有权、输入/结果契约、外部标识、事件或查询、停止/超时与恢复、重复操作保护、费用核对、Git Issue/PR/发布映射。之后再决定进程/数据库/队列和执行器，首期无需先建通用可视化工作流编辑器。
+
+## 阶段 2 逐轮讨论记录
+
+阶段 1 已形成业务基线。本阶段回答客户账号、项目、应用、服务、运行类型和资源之间的关系，先解释业务概念，再决定字段和实现；不在本轮生成数据库表或决定部署成几个服务。
+
+### 第一轮：项目代表什么，核心边界已确认
+
+已经确认以项目组织客户业务、支持仅邮箱和应用加域名邮箱、系统生成标识及资源显式绑定。本轮用户进一步确认：一个项目代表一个客户业务目标，允许同时包含多个相关应用，并搭配域名、邮箱服务。
+
+项目是客户组织一项业务目标的长期单位，在其下管理相关应用和服务。项目可有零个、一个或多个应用：仅邮箱项目可以没有 Web 应用，官网可只有一个应用，商城与内容中心可为同一业务项目下的两个相关应用。实际资源数量由应用需求和购买配置决定，共享通过显式绑定与授权表达；默认 namespace 关系见第二轮已确认基线。
+
+| 概念 | 当前用于讨论的含义 | 不应靠它推断的关系 |
+| --- | --- | --- |
+| 客户账号 | 项目及购买记录的客户归属和操作边界 | 客户来源、行业或供应商账号 |
+| 项目 | 客户组织业务、改动任务及相关服务的长期单位 | 一份订单、一个仓库或固定 namespace |
+| 应用目录项与版本 | 平台已接入的一种基础软件及具体版本，如官网模板、内容中心或开源商城 | 客户已经购买或实际运行的实例 |
+| 应用实例 | 为客户运行、定制和更新的具体应用 | 模板的所有客户共用同一份代码或数据库 |
+| 服务产品与服务实例 | 产品是可购买的内容，实例是客户实际开通的域名、邮箱、托管等服务 | 一项独立服务必须对应一个新 Web 应用 |
+| 运行配置与工作负载 | 声明同一应用的 Web、API、worker、scheduler 等组成及运行参数 | 每个 worker 都需要成为独立项目或独立业务应用 |
+| 资源及绑定 | 实际 namespace、仓库、数据库、存储和供应商目标，通过标识明确关联 | 名称相等、编号后缀或手工备注所暗示的关系 |
+
+项目、应用目录项、客户实例和运行组件需区分。用户现已认可 APP 表示完整软件实例、Web/worker 表示部署组件的分层。Content Hub 的 API 与发布 worker 可表达为同一应用的不同组件；独立内容软件也可以作为另一 APP，不按进程或容器数量定义业务项目。
+
+### 用已有场景核对第一轮
+
+| 场景 | 已确认边界下的表达 | 后续细化 |
+| --- | --- | --- |
+| 企业官网加域名与邮箱 | 官网应用绑定资源，域名邮箱独立服务和账目，项目关联工单及线上版本 | 无需因为买邮箱再强制建立另一个项目 |
+| 仅邮箱 | 零个 Web 应用，无仓库或 K8s 工作负载要求 | 项目与服务实例具体归属规则后续核对 |
+| Content Hub API 加 worker | 一个应用由正式运行配置声明多个工作负载 | 不以进程数量决定项目数量 |
+| 商城加内容中心 | 可属于一个客户业务项目，各自定义运行组成、代码和数据依赖 | 版本、工单和服务怎样关联单个或多个应用 |
+| 旧 `projectxx-x` 入口 | 保存真实资源和显式业务关联，不靠后缀识别 | 新入口是否为独立应用或项目后续讨论；不在此合并或改名现网资产 |
+
+项目边界已确认，工单只能属于一个项目，可涉及其中多个 APP，跨项目需求分别提交工单。独立服务的使用关联和发布组成继续细化；一项业务目标不等同于一张订单、一笔订阅、一个 namespace 或一个数据库。
+
+### 第二轮：应用、部署、资源计费与协作
+
+用户补充的目标：多应用项目需要可解释的费用；Web 与采集 worker 可共享项目数据；独立项目可通过 API 协作；平台自有新闻 API 等公共应用可向多个客户提供独立收费服务；未来接入外部托管数据库和云存储；客户可按项目组整理和查询项目，并保留未来批量操作的可能。是否首期接入某一家云供应商、具体数据库数量和 API 计价单位尚未决定。
+
+#### APP 与部署组件：已确认保留两个层次
+
+APP 表示一套可安装、定制和维护的软件实例；部署组件表示其中可单独配置运行资源和副本的 Web、API、worker 等单元。一个 APP 可以有多个组件，组件各自扩容，但软件的兼容关系与版本组成仍有归属。APP 不按 Deployment 或副本数量定义，计费依照实际购买项。
+
+不把业务 APP 与 K8s `Deployment` 固定一一对应。运行契约可以映射到 Deployment、StatefulSet、Job 或 CronJob 等实际工作负载；同一组件的多个副本也不等于多个客户 APP。工作负载种类和资源档位是配置，不从名字或编号推导。
+
+| 层次 | 已认可的概念职责 | 例子 |
+| --- | --- | --- |
+| 客户账号 | 拥有项目与服务购买权限 | 一个客户管理多项业务 |
+| 项目组 | 单层分组，一个项目至多归属一个组，无嵌套或多组要求 | “评价与内容业务”收纳评价网和内容中心 |
+| 项目 | 长期业务与运行资源管理单位，可含多个应用和独立服务 | 一个站点及为其采集数据的相关应用 |
+| 应用实例（APP） | 一套软件的客户实例，保存基础版本及定制成果 | 官网、商城、内容中心 |
+| 环境与部署组件 | 区分生产/测试等目标，描述 Web、worker 的运行组成与资源配置 | Web 两副本，采集 worker 一副本 |
+| 资源实例及使用绑定 | 数据库、缓存、卷、对象存储等实际资源；分别记录归属和使用者 | Web 与 worker 显式绑定同一数据库 |
+| 外部服务订阅与调用关联 | 接入另一项目或平台服务的授权、接口与服务权益 | 内容中心调用评价网 API；网站订阅新闻 API |
+
+本表形成概念基线，具体关系基数及生命周期还需核对，不是强制逐层建立菜单、数据库表或微服务。一个仅邮箱项目无需为了补齐层次而创建 APP、namespace 或数据库。
+
+#### namespace、数据库和共享：默认关系与实际授权分开
+
+namespace 管理 K8s 资源作用域，不直接决定数据库能否共享。服务可以通过包含 namespace 的 DNS 名称跨 namespace 访问；实际连通还受网络策略和数据库授权限制。同 namespace 也不会自动获得另一个应用的数据库权限。[K8s 跨 namespace 服务访问](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/)
+
+namespace 本身也不等于默认网络隔离；如需项目间限制访问，需有实际生效的网络策略及数据库、服务凭据授权。网络插件必须支持策略执行。[K8s 网络策略](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
+
+以下默认关系已获用户认可；具体配置覆盖与执行机制后续细化：
+
+- 项目在某个集群的同一环境内，相关工作负载默认放在同一 namespace，符合共同管理及共享卷的需求。项目与实际 namespace 显式绑定；以后不同环境或集群有各自目标，不靠名称相等关联。
+- 数据库是独立资源，项目可有零个、一个或多个逻辑数据库；模板决定默认需求。例如官网与采集 worker 默认绑定同一数据库，两个不同基础系统也可各用各的数据库，仍属于同一项目。
+- 数据库部署在哪里、哪个应用可以用、费用归谁，分别记录。同项目应用按需要授权，并非全部自动获得相同权限；worker 可具有与 Web 不同的写入权限。
+- 评价网与内容中心按用户指定保留为两个独立项目，各有自己的数据库和 namespace，通过 API 协作。可归入同一项目组，但不因分组自动合并数据库或授权。
+
+数据库供应商实例与逻辑数据库需区分：一个数据库服务器或托管实例可以承载多个逻辑数据库。namespace 既不是数据库服务器，也不是逻辑数据库。共享与性能还取决于位置、网络和应用写入方式，不能仅靠相同 namespace 保证更快或数据格式兼容。
+
+PVC 与数据库连接有不同约束：Pod 直接引用的 PVC 必须位于同一 namespace。多组件共享同一个 PVC 还需核对访问模式、后端及应用的并发写入能力；不能将“跨 namespace 能连数据库”推导成“直接引用另一 namespace 的 PVC”。[K8s 持久卷与 namespace](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
+
+#### 资源计费：按实际购买项计算，项目汇总
+
+Web 与 worker 分别需要购买的运行配置，可以分别计价，再汇总到项目；如果售卖的是覆盖整个组合的套餐，则由套餐表达包含的组件和额度。不能同时对同一配置收套餐价和全部组件价。运行配置按本轮明确的包年档位，不按实时 CPU、内存用量收费。
+
+共享数据库、存储的费用归属于资源或其明确分配的服务份额，多个 APP 引用不会产生多份采购费用。资源的归属、使用绑定、计费归属要区分；资源成本已经包含在套餐时，不再另列同一份费用。
+
+示例：官网 Web 配置费 + 采集 worker 配置费 + 一份共享数据库服务费 + 一份共享存储服务费。域名、邮箱、公共 API 订阅与定制工单按选配另外计算。此处解释组成，不设定具体金额、套餐和服务周期；人工、AI 定制仍是核心销售价值。详见 [05 商业模式与成本指标](<05-商业模式与成本指标.md>)。
+
+#### 外部数据库与云存储：统一管理，分别适配
+
+目标模型应支持自建与外部托管资源，不把数据库限定为现有服务器上的 PostgreSQL，也不把存储限定为 Longhorn。应用契约声明所需引擎、版本、容量及访问能力；实际资源绑定选择可支持的供应方式。先保留能力边界，供应商与接入版本以后确定。
+
+| 资源类别 | 怎样接入应用 | 需要保留的差异 |
+| --- | --- | --- |
+| 自建数据库或托管数据库（RDS 类） | 显式绑定连接目标、逻辑数据库与授权；应用通过网络连接 | 引擎与扩展、区域、版本、容量、备份和恢复能力 |
+| 块存储或文件存储 | 兼容的存储驱动/后端提供卷，通过 PVC 挂载 | 节点与区域限制、访问模式、容量、快照、并发访问能力 |
+| 对象存储 | 应用通过支持的对象接口访问 bucket 或授权范围 | 应用适配、对象权限、请求/容量/流量成本，不等同普通文件系统 |
+
+外部托管数据库纳入平台资源目录、开通和账目，不意味着其 CPU、内存由 K8s 本地配额调度。建议记录供应商资源标识、规格、实际目标、状态、凭据引用、采购账目与客户服务归属；开通可以由供应商 API 或人工完成，不能因统一模型就承诺全部步骤自动化。
+
+托管数据库可减少服务器维护、数据库安装、补丁和备份等工作；应用的数据结构、查询优化、连接配置及使用方式仍需团队负责。此处以官方 RDS 的责任划分解释概念，并未选定 AWS。[RDS 管理与责任范围](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html)
+
+云盘接入不能只增加供应商字段：驱动、节点/区域可用性和网络条件必须兼容现有集群。对象存储适合经应用支持的素材、上传和备份场景，不能默认无修改替代任意 PVC。[K8s StorageClass 与存储后端](https://kubernetes.io/docs/concepts/storage/storage-classes/)、[对象存储概念](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html)
+
+用户提出第三方服务成本加 20% 服务费，后台可调整。独享资源可直接归属采购成本；共享供应商实例需先定义可核对的分配份额，不能向每个项目重复收取整台实例费用。第三方流量、请求和备份等浮动成本怎样对客户结算，进入阶段 3 决定，不自动改变既定计算资源档位订阅。
+
+#### 跨项目协作、平台公共应用和项目组
+
+跨项目协作保存独立的 API 使用关系：提供方、使用方、接口、授权引用和依赖；不因两个项目属于同一客户或分组而自动互通。评价网加内容中心是本轮明确的两个项目协作样本；服务变化时还需知道哪些依赖方可能受影响。
+
+平台自有新闻 API 则包含两个不同对象：平台部署和维护的应用，以及对外销售的 API 服务产品。客户购买的是订阅、权限和调用权益，并不必为每个客户复制一套新闻系统或开放新闻系统数据库。服务订阅与平台应用的成本各自记录；持续基础服务按包年方向，API 包含额度、超额或其他计量规则后续确定，不将计算配置规格直接套到 API。
+
+客户项目组已纳入目标，先承担命名、归组、筛选和查找。建议未来可按组汇总费用；移动分组不自动搬迁 namespace、合并资源或重定价已有账目。客户整理分组、平台行业/价格政策分组、供应商账号池分配是不同用途。
+
+未来批量操作可利用项目成员关系筛选目标，但具体操作未提出，不提前承诺批量删除、发布或扩容。以后逐项定义权限、执行范围与每个项目的成功/失败结果；分组本身不成为技术隔离边界。
+
+#### 用本轮场景检验候选模型
+
+| 场景 | 组织与运行关系 | 费用表达 |
+| --- | --- | --- |
+| 网站加持续采集 worker | 一个项目；同软件可为一个 APP 多组件，独立软件可为多个 APP；显式共享数据 | Web、worker 运行配置分别覆盖，共享数据库和存储不重复计费 |
+| 一个项目含商城和内容应用 | 多个应用，可有不同数据库引擎和存储要求 | 各组件配置与实际购买资源合并展示到项目 |
+| 评价网与内容中心协作 | 两个项目、各自数据库及 namespace，通过 API 对接，可放同一项目组 | 各自资源费归各项目；API 是否另收费按服务关系决定 |
+| 平台新闻 API 提供给多个站点 | 平台拥有服务应用，客户项目绑定 API 订阅和授权 | 客户购买 API 服务，不重复承担同一平台实例的整笔资源采购 |
+| 更换自建数据库为托管数据库 | 保留业务身份，变更资源绑定并执行数据迁移、验证和切换 | 按新服务规格与成本规则结算，不把更改连接地址当作完整迁移 |
+| 项目分组 | 客户整理多个独立项目，分组不改变运行隔离 | 可汇总既有账目；不因加入组自动新增费用或叠加资源费 |
+
+### 第三轮：应用目录、组合方案与运行配置
+
+多应用项目下，需要区分业务组织、应用基础和运行组成。例如“供应链业务”表达项目用途，“Odoo 商城”表达所选应用基础，“Web 与后台 worker、数据库和存储”表达该应用的运行要求。行业、软件来源和部署组成不能全部压成一个固定项目类型字段。
+
+已确认：目录同时支持单应用及包含多个应用的组合方案，客户可在已有项目中继续添加应用。例如先开通官网，再添加独立内容中心。组合不是固定且不可变的项目类型；它的具体默认组件、连接和配置尚需细化。
+
+用户明确：每种应用的必需和可选资源由其预设决定，平台不存在适用于全部应用的固定组件清单。应用及版本的运行配置表达组件、资源依赖、默认值和允许的选配；组合方案引用这些配置。客户业务用途和行业分类另行记录。
+
+| 应用预设样本 | 必需项 | 可选项 |
+| --- | --- | --- |
+| 自有金融官网系统 | Web、数据库、PVC；所提供软件包含后台和持久数据 | 独立域名、邮箱及该软件支持的其他能力 |
+| 纯前端个人网站 | 交付并提供访问所需的静态产物/运行能力，无应用数据库或持久 PVC 要求 | 独立域名、邮箱及其支持的额外服务 |
+
+“可选”不是随意关闭软件必需依赖；软件不支持的资源能力不能仅靠勾选生成。是否将某种附加能力接入目录，仍按接入契约验证。静态产物是否使用容器服务或专门静态托管方式，属于后续架构选择。
+
+### 第四轮：资源存续、工单范围、预览与分组
+
+#### 包年服务与资源释放
+
+用户明确持续服务采用包年，不采用随开随关的按小时模式；人工和 AI 定制仍按原工单费用规则，不变为无限次包年开发。提前删除、到期、扩容的账目与退费阶段 3 另定，资源是否还有引用与订阅是否到期分别记录。
+
+业务默认每个项目拥有独立的逻辑数据库，不设计跨项目混用业务数据库的通常路径；同项目 APP 可按需要共享。供应商实例是否承载多个独立逻辑数据库，是物理供应层面的另一问题。
+
+资源保存归属用户、所属项目及实际引用它的 APP/组件/环境。用户要求类似引用计数的机制：删除最后一个引用前提示将失去数据，并在客户资源管理页显示待释放状态；全部引用消失后可以延迟释放，用户举例为三天。三天是候选宽限期，后台参数和最终期限待确认。资源真正释放后不承诺原数据仍能恢复。
+
+建议流程为“使用中 → 待释放 → 已释放”：
+
+- 移除最后一个引用时展示将删除的数据库、卷及影响，客户确认后进入待释放。
+- 宽限期内新增有效引用或撤销释放可取消倒计时；只暂停 APP、仍保留使用绑定时不应误判为零引用。
+- 执行释放前重新检查实际引用及正在执行的发布/恢复等操作，避免只按一个过期计数删除资源。用户直接绕过平台的连接不属于可靠引用，应禁止作为正常使用路径。
+- 项目的数据库/卷、备份及独立域名/邮箱/API 订阅分别管理；零 APP 引用不意味着自动取消独立服务。备份保留及最终清除需有明确政策，避免无引用资源无限占用空间，也避免误承诺永久可恢复。
+
+用户在阶段收口时认可上述释放方案；具体宽限期、提示/取消入口及备份清除规则移交阶段 3。
+
+#### 工单范围与多个 APP 的版本组成
+
+已确认一张工单只能修改一个项目，可同时涉及项目内多个 APP；跨项目协同分别提交工单。客户提交一次需求，内部可拆分成多个 APP 的执行任务，不要求客户为了前后端接口配套改动再分成多个工单。
+
+建议建立“项目发布记录”：保存本次项目内各 APP 实际采用的 Git 提交、构建产物、配置及数据库结构版本。未改动的 APP 也有明确当前版本，因此一次工单可产生一个可核对的前后组合。多仓库分别保存实际提交，不假定存在覆盖全部 APP 的一个 Git 提交。
+
+Git 记录源代码和迁移脚本，发布记录补充实际运行组成与数据恢复点。数据库内容、上传文件、密钥和客户数据不写入 Git。恢复项目历史组合时检查共享数据及 APP 兼容关系；单独恢复一个 APP 只在兼容时提供。工单提交时与实际执行时的版本仍分别保存。
+
+多 APP 发布可以内部协调、记录部分成功并执行恢复，不能仅靠“一个工单”承诺数据库和所有部署具有瞬时原子切换。发布顺序、兼容策略和失败补偿留到运行设计。
+
+#### 代码回退与数据恢复：收口时已确认采用推荐方向
+
+用户已认可两层恢复方向：普通应用回退默认保留数据，带数据恢复作为明确选择的另一个操作；不采用所有回退都覆盖数据的默认规则。
+
+| 恢复动作 | 已确认行为 | 数据影响 |
+| --- | --- | --- |
+| 应用版本回退 | 恢复目标 APP/项目组合的代码、产物和兼容配置，先保留当前业务数据 | 保留后来新增订单、内容和上传；不兼容则进入恢复评估 |
+| 带数据的时间点恢复 | 选定明确数据库和文件恢复点，协调所有使用它的 APP | 会覆盖恢复点之后的新数据，需明确提示范围、时间及影响 |
+
+仅备份结构不足以保护记录内容：删字段或批量修改数据后，结构定义无法找回原数据。结构迁移脚本应版本化、尽量兼容前后版本；并非所有迁移都有无损逆操作。[PostgreSQL schema-only 的范围](https://www.postgresql.org/docs/current/app-pgdump.html)
+
+持久数据应有独立于工单的基础周期备份或持续恢复保护，以覆盖客户操作、采集 worker 等日常写入；仅在修改代码时备份无法覆盖平时的数据损坏。工单按风险补充关键恢复点，基础保护的规格、保留范围与成本阶段 3 定义。
+
+建议按改动风险及应用数据能力建立恢复材料：
+
+- 纯前端/样式修改：记录 Git、产物、配置及结构版本，不必为每次改字完整复制数据库或卷。
+- 数据库结构迁移、批量改写或删除：在首次影响持久数据前建立并校验恢复点；小型项目可采用逻辑备份，较大数据或高频写入项目评估基线备份加日志归档/供应商时间点恢复。
+- 上传文件、附件或应用在卷内修改内容：按需要建立卷快照或对象版本/备份；数据库记录与文件必须有可核对的一致恢复范围，独立时间的两个备份不自动组成一致状态。
+- 后台采集 worker 会持续写入，快照或备份期间需采用应用支持的一致性方法；必要时协调暂停相关写入。恢复时先停止相关写入、恢复到隔离目标并核对，再切换使用者，避免破坏正在工作的数据。
+
+PostgreSQL 时间点恢复依赖基线备份与连续 WAL，物理恢复的范围通常是整个数据库集群，不能在承载多个客户的共享实例上直接回退而影响其他客户；可恢复到隔离实例，再处理目标项目的数据。MariaDB/其他引擎及托管服务需各自适配，不能套用一套 PostgreSQL 方法。[PostgreSQL PITR](https://www.postgresql.org/docs/current/continuous-archiving.html)
+
+Longhorn 的增量备份可复用未变化数据块，减少每次备份重复复制的成本；本地快照与集群外备份职责不同，不能以本地快照替代灾难恢复。存储快照的一致性也不能自动等同于应用数据库和附件的一致性。参考官方能力，不表示现有集群已支持或配置这些方案。[Longhorn 增量备份](https://longhorn.io/docs/1.13.0/snapshots-and-backups/backup-and-restore/create-a-backup/)、[Longhorn 快照与备份概念](https://longhorn.io/docs/1.13.0/concepts/)
+
+备份占用取决于基础数据大小、变化量、写入日志、副本及保留期限，并非零成本。建议分开保留近期任务恢复点、周期备份和长期代码历史，具体期限与价格阶段 3 决定。可定位任意历史工单的代码版本，并不意味着每个历史时间的数据都永久可恢复；数据恢复界面需显示实际可用的恢复点和保留范围。
+
+数据库保护点通常建立于实际数据修改前，不应冒充工单提交时数据；两个时点可能相隔数天。发布与恢复记录保存准确时间和范围，恢复前保护当前状态。默认模式已明确，涉及数据覆盖时的具体确认步骤移交阶段 3。
+
+#### 运行实例、默认预览入口与未来沙盒
+
+已确认运行实例仍由 K8s 在线维护。新项目的应用需要访问时分配平台默认建站域，仅用于客户测试/预览，不允许当作正式公开站点。工单过程当前无需对客户透明，完成后直接更新其正在访问的运行实例；不增加发布前客户验收步骤。
+
+正式公开发布允许客户绑定自有域名，或通过平台购买域名；默认建站域仅预览。默认域名和独立域名是访问方式及发布资格，不应推导为“未买域名就没有实际 K8s 服务器”。正式上线可沿用同一持续实例，更改访问绑定与公开发布状态；如另需专属运行环境再单独选配。域名验证、绑定及采购的具体服务规则移交阶段 3。
+
+未来 AI 执行可使用临时隔离沙盒，必要时通过受保护入口映射出来。开发沙盒/临时预览与客户持续实例分开，默认不连接客户可写生产数据或以正式身份发送邮件/调用付费业务接口。独立数据副本、脱敏、权限及费用后续设计。
+
+用户与项目采用系统生成 ID，实际访问入口显式绑定应用端点。建议再生成独立的唯一预览标识，避免直接暴露用户信息或可枚举编号；例如 `p-7f2k9m-web.preview.example.net`，多 APP 的不同 Web/API 入口各自映射。不从仓库名、namespace 或可读项目编号推算目标。临时沙盒可有另外的临时入口及有效期；随机地址本身不替代访问权限。
+
+行业参考：Vercel 会为部署生成唯一访问 URL，并提供预览/部署访问保护；可借鉴稳定项目入口与具体部署入口分开的方式，无需照搬域名格式。[Vercel 生成 URL](https://vercel.com/docs/deployments/generated-urls)、[Vercel 访问保护](https://vercel.com/docs/deployment-protection)
+
+#### 默认域名的访问提示、验证码与责任边界
+
+用户提出默认预览域名统一显示免责声明，通过验证码后才展示应用。技术上可用统一预览访问网关实现，网关验证后签发限时访问凭据，再放行原访问目标，不需要让每个客户模板重复实现。页面说明这是客户测试内容，并提供投诉/举报入口。验证码是人机验证还是客户持有的访问码，及是否结合登录/限时分享，仍待定。
+
+建议默认仅项目所有者、员工及持有受控分享权限的人可访问；免责声明和人机验证作为附加提示与防滥用机制。单纯任何人答验证码即可访问，仍可被用作公开传播入口；需覆盖深链接、API、静态内容及绕过网关的后端路径。跨应用登录、Cookie、WebSocket 与机器接口兼容性留架构阶段核对。
+
+ngrok 官方描述中间提示页用于降低钓鱼风险，且提供跳过路径，不能将该产品行为当作通用法律免责证明。[ngrok 中间提示页](https://ngrok.com/docs/pricing-limits/free-plan-limits)
+
+法律适用地区尚未明确，当前不作免责结论。以欧盟 DSA 为例，托管责任例外涉及对违法内容的知情及及时移除/禁止访问等条件；免责声明或验证码并不能替代这些条件，此处不是判断本平台必然适用 DSA。产品规划应包含服务使用规则、举报受理、停用入口与处置记录，具体义务在确定经营主体、用户地区及服务性质后核对。[欧盟 DSA 第 6、16 条](https://eur-lex.europa.eu/eli/reg/2022/2065)
+
+#### 项目组保持简单
+
+用户明确：项目至多属于一个组，分组不嵌套，不需要多组或复杂标签体系。建议允许未分组；一个组可含多个项目，为协作查询及以后功能扩展提供基础。API 协作依然通过明确关系表达，分组不提供隐含授权，批量操作清单后置。
+
+### 阶段 2 逐轮核对结果（收口后）
+
+五项主题已形成领域基线，用户认可推荐方向；参数和执行细节按本文件开头交接清单进入后续阶段，不再要求阶段 2 完成采购或建表。
+
+| 顺序 | 仍需确认的内容 | 用于核对的业务例子 | 本阶段要得到的结果 |
+| --- | --- | --- | --- |
+| 1. 目录与运行配置 | 已明确按应用预设必需/可选项；支持版本和组合契约后续工程化 | 金融官网必须有 Web/数据库/PVC，纯前端个人站无数据库/PVC | 不再要求平台统一必需组件清单 |
+| 2. 资源与服务归属 | 引用释放机制及独立服务分开管理已确认 | 删除最后一个数据库使用 APP；保留独立邮箱 | 三天仅候选；账目、备份清理与订阅期限阶段 3 细化 |
+| 3. 工单与成果范围 | 单项目多 APP、项目发布组合及两层恢复方向已确认 | 同时改前后端；普通回退保留新订单 | 具体引擎、操作确认及保留期限后置 |
+| 4. 环境与部署实例 | 默认域受保护预览、沙盒后置、正式域可平台购买或自有绑定已确认 | 客户已有自己的域名 | 保护实现后置，法律地区待补事实，不承诺验证码免责 |
+| 5. 分组与关系基数 | 已明确单层、单归属，不嵌套不多组 | 两个协作项目放一个组 | 不继续扩展复杂分组模型 |
+
+阶段 2 收口后转入阶段 3 的状态、价格、续费、释放、投诉和恢复操作规则；技术选型和具体恢复实现仍按计划后置。
+
+### 本阶段后续轮次
+
+1. 项目、客户应用实例和独立服务的核心边界已形成基线，生命周期继续核对。
+2. 应用目录、基础软件版本、项目类型与运行配置分别表达什么；类型怎样声明组件和默认要求。
+3. 实例、环境、工作负载和资源的绑定、默认值及可覆盖项；处理 worker、namespace、仓库及数据库旧约束。
+4. 工单、代码、线上版本、订单和分组怎样关联，用真实场景核对完整模型。
+
+这里保留整体讨论地图，但每轮只展开一个主题。下面原有领域清单用于查阅，统一系统部署、Git 和数据库部分暂不要求逐项选择。
+
+## 统一系统与部署结构
+
+统一系统意味着公开能力目录、客户、员工、服务产品、订单、项目、工单和交付有一致的业务模型、权限与生命周期。来源不驱动系统设计；当前以普通客户账号为边界，企业组织与成员协作后置。产品整体性不由进程数量或数据库数量单独决定。
+
+客户门户、员工后台和任务执行器可以是同一产品的不同界面或运行组件，也可以共用数据库。是否拆分要依据权限、负载、故障隔离、事务边界和维护成本论证。
+
+不将几个旧后台简单拼接为新产品，也不预设所有能力必须运行在一个进程里。
+
+## 领域模型先回答的问题
+
+| 概念 | 必须明确的关系或职责 |
+| --- | --- |
+| 客户账号与内部权限 | 普通客户注册、项目归属、员工操作；中介没有特殊身份，组织与成员后置 |
+| 项目分组与定价政策 | 单层、项目单归属；客户整理与平台价格分类分别表达，不以同组推断运行权限 |
+| 应用能力目录 | 应用来源、版本、适用场景、接入状态、支持范围及运行契约 |
+| 服务产品和套餐 | 运行配置档位及域名、邮箱、人工、AI 等独立选配服务，购买后交付什么 |
+| 订单和订阅 | 配置档位年付、扩容调整、独立服务购买、报价确认、费用与续费 |
+| 项目 | 客户组织业务的单位，与订单、服务、应用的关系 |
+| 项目类型 | 是否定义业务能力、默认组成或资源要求，怎样支持组合与版本 |
+| 应用与环境 | 项目支持多应用、APP 与组件分层已确认；组件版本及预览/生产环境关系待定 |
+| 工作负载 | Web、worker、scheduler 等角色及运行配置 |
+| 资源与绑定 | namespace、仓库、数据库、域名、邮箱和存储的归属及使用关系 |
+| 改动工单 | 限一个项目、可涉及多个 APP；文字与附件、处理模式、人工金额确认、执行及版本追踪 |
+| 客服渠道 | 在线客服、Telegram 及拟接入 TG 机器人中的咨询、澄清、价格沟通和反馈；关联方式待定 |
+| 成果版本与恢复 | 工单提交时版本、执行基准、各次预览、发布组成、历史回退及数据恢复范围 |
+| 代码协作关联 | 平台工单与外部 Issue、PR、提交和构建的明确映射，不依赖编号相等 |
+| 供应商账号池与分配 | Cloudflare、Migadu 等账号的可用状态、共享容量、独享关系及实际资源绑定 |
+| 托管资源供应方式 | 自建/外部数据库、卷和对象存储的能力、供应商目标与账目，不以供应商实例代替逻辑数据库 |
+| API 协作与公共服务 | 客户项目间接口依赖，以及平台自有服务产品、订阅、调用授权与收费 |
+| 价格与成本记录 | 后台可调参数、价格规则版本、供应商采购成本与客户独立账目 |
+
+这些不是建表清单。概念、基数和数据所有权先用业务实例验证，再转成具体数据库设计。
+
+运行资源按购买的配置档位订阅，不按实际瞬时用量收费；购买配置、运行观测及价格版本分别表达。项目业务分组、价格分类、供应商账号分配不预设一一对应。供应商账号池也不是客户账户或组织模型，不能混淆权限归属。
+
+首期复杂定制走人工模式，内部评估与设置价格，客户同意后执行并更新线上。自动模式后续按能力开放，提交后 AI 修改并发布，需要人工时自动切换到同一工单的人工模式；人工金额确认是条件步骤，沟通与反馈由客服渠道承担。
+
+## Git Issue 集成方案评估
+
+用户建议将工单绑定 Git Issue，并在阶段 2 收口时认可平台业务主记录关联 Git 工程记录的推荐方向。下面保留方案比较；具体实现、Issue 强制范围、Git 服务供应商及同步机制留到阶段 4。
+
+Git 本身管理代码版本，Issue 是 Gitea、GitHub 等托管服务的协作能力。GitHub 支持 Issue 与 PR 关联；Gitea 支持 Issue、PR、提交引用，也支持外部工单追踪引用。这能建立工程追踪关系，处理模式、人工价格确认、实际发布和恢复记录仍需产品模型表达。[GitHub Issue 与 PR 关联](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue)、[Gitea 引用与外部追踪](https://docs.gitea.com/usage/issues-prs/automatically-linked-references/)
+
+| 候选 | 适用性与代价 | 本轮建议 |
+| --- | --- | --- |
+| 改动工单以 Git Issue 承载需求和开发记录 | 与主要伴随代码的任务更契合，可复用工程追踪；处理模式、客户权限、人工金额确认、费用及实际发布恢复仍需平台表达 | 可以评估，但不能仅靠 Issue 状态决定整个业务任务是否完成 |
+| 平台工单直接关联 PR、提交和发布，无独立 Git Issue | 工程关联较少，避免两套讨论或状态同步；团队若需要 Issue 看板需另评估 | 可作为较轻的接入方案 |
+| 平台改动工单关联 Git Issue、PR、提交和发布 | 平台表达任务授权、模式和人工金额确认，Git 追踪改动，客服独立；需明确关联和同步边界 | 当前推荐方向，Issue 是否必须及首期接入范围待定 |
+
+推荐方案仍是一个产品：客户通过平台提交改动工单，客服渠道承担沟通，Git 服务接入工程能力。平台保存原始文字与附件、需求版本、初始与当前模式、人工金额确认、执行状态及线上版本；Git 侧保存开发任务、内部技术记录和代码改动。代码工单可关联 Issue，少量无代码服务任务不强制建立 Issue。
+
+已确认保存工单提交内容及附件的不可覆盖版本，新增或改变需求另建工单，客服/TG 不自动修改原范围，用于防止追加及完成争议。补缺、原需求未完成修复和新增的区别、执行中变更及费用细则阶段 3 处理。
+
+建议一个平台工单可关联零个或多个开发任务，一个开发任务可关联多个 PR 或提交；发布版本可包含多个工单的成果，关系基数仍需真实场景验证。关联记录包含实际服务实例、仓库及外部标识，不以工单号等于 Issue 号或仓库名等于项目名建立关系。
+
+先同步任务、链接及必要工程摘要，不复制在线客服或 TG 的全部对话。Issue 关闭或 PR 合并不能代替生产发布成功和费用状态；工单执行完成应关联实际线上更新结果。同步失败不丢失客户提交，重试不得产生重复 Issue，具体接口及一致性策略留到架构阶段。
+
+现有 Gitea 可以作为候选接入能力评估，无需为绑定 Issue 先迁移到 GitHub。候选服务的实际版本、API 和权限支持在实施前核对，当前未操作任何外部仓库或工单。
+
+## 版本追踪与恢复模型建议
+
+仅绑定 Git Issue 无法定位整个应用的历史运行状态。建议将平台成果版本和部署记录明确建模，关联到工单、目标应用及环境，并保存版本组成：
+
+| 记录 | 需要解释的内容 |
+| --- | --- |
+| 需求与执行 | 提交与附件版本、工单发起时应用版本、执行时基准及每次处理尝试 |
+| 代码与构建 | 仓库、实际提交、PR、构建结果和可追踪的镜像 digest 或产物引用 |
+| 应用组成 | Web、worker 等工作负载采用哪些产物及配置版本，相关配置和凭据版本引用 |
+| 发布与完成 | 哪个成果更新到哪个目标环境、健康检查及执行结果；不设默认客户验收发布门槛 |
+| 数据兼容与恢复 | 数据结构版本、迁移及备份或快照引用，能否保留现有业务数据运行历史应用 |
+| 回退 | 当前版本、目标历史版本、涉及工单、恢复范围、执行状态及恢复后有效版本 |
+
+工单发起时版本和执行时基准需分别保存；排队期间其他工单可能已发布。平台业务记录和账目不随应用回退恢复为旧状态，回退作为新的动作保留完整历史。
+
+回到一个完整历史版本，与仅撤销某张工单的修改分别提供语义。Git 的 revert 可通过新提交撤销历史提交的改动；它不等同于重新部署历史镜像，也不恢复数据库和外部资源。[Git revert 官方说明](https://git-scm.com/docs/git-revert)
+
+目标是可选择任意历史工单发起前的应用版本。能否直接恢复需核对产物保留、配置及数据兼容，无法直接恢复时进入恢复评估，不把需求静默改成“只能回退最近一次”。已确认普通回退保留数据，带数据恢复另选实际可用时间点；版本材料、数据恢复点的保留与长期成本阶段 3/6 细化。
+
+## 用户指出的旧约束与目标要求
+
+| 旧约束 | 新模型需支持的能力 |
+| --- | --- |
+| 人工编写 `projectxx` 编号 | 系统生成稳定标识；可读编号和历史别名独立 |
+| 用 `-x` 后缀识别入口和关联 | 显式描述用途、类型及关联关系 |
+| worker 等依赖人工特殊处理 | 类型配置声明工作负载组成、依赖和资源要求 |
+| namespace 只能跟随约定 | 默认命名可覆盖；保存实际资源目标并检查冲突 |
+| 项目、namespace、数据库名称关联 | 用资源 ID、目标配置和凭据引用明确绑定 |
+| 仓库名要与 namespace 相同 | 代码来源与部署目标独立配置，CI 根据绑定定位 |
+
+业务用途、软件目录/支持版本、组合方案与运行配置分别表达，资源必需/选配由应用预设声明；类型模型不能成为另一套固定命名约束。实例可覆盖参数的具体清单按版本运行契约在阶段 6 定义。
+
+示例：一个应用由 Web 与 worker 组成，它们是否共享镜像、数据库、存储，以及 worker 的副本数和启动命令，都应有配置表达，而不是从项目名字推测。
+
+## 数据库问题需拆开讨论
+
+先区分两种数据：**平台数据**包含账户、订单、工单、项目和交付记录；**客户应用数据**是客户网站自身的会员、内容、订单等业务数据。平台数据库是否统一，与客户应用数据库如何隔离，是两个独立决定。
+
+平台还可能保存日志、素材和构建产物，它们是否使用其他存储也需单独论证。“统一数据库”不代表所有文件和运行日志必须塞进同一组业务表。
+
+| 平台候选方案 | 可以怎样组织 | 需要权衡的问题 |
+| --- | --- | --- |
+| 模块化应用与一个平台数据库 | 客户、订单、工单及项目按模块管理，一个数据库保存业务记录 | 事务便利、责任边界、权限及后续拆分能力 |
+| 多个运行组件与一个平台数据库 | API 与异步执行器分开运行，明确各模块的数据写入责任 | 故障隔离、并发访问、迁移协调和耦合 |
+| 多个服务与各自数据库 | 服务拥有各自数据，通过 API 或事件协作 | 一致性、幂等、查询汇总、分布式恢复及运维成本 |
+
+这里只列候选方案，不选定一种。先完成领域模型和完整流程，再按真实负载、团队维护能力与事务要求比较。
+
+无论哪种方案，客户注册都需身份与项目归属，工单需作者、权限、状态、范围和成果关联；成员模型后置。是否适合重用旧表必须逐项评估，不能只增加用户和工单表就认为设计完成。
+
+客户应用的数据技术不能由平台数据库选择决定。现有官网与 Odoo 样本使用 PostgreSQL，货代样本使用 MariaDB 及 Redis；目标目录需描述应用依赖，不能将所有客户应用强制套进旧站点数据库规则。
+
+Content Hub 提供两个需分开的关系样本：同一应用的 API 和 worker 共用应用数据；内容中心通过 API 为目标网站发布内容，目标网站仍有自己的业务数据。平台交付任务与被部署应用内部的内容任务也要分别建模。
+
+## 迁移与目标模型
+
+旧 ID 通过导入映射关联新 ID。namespace、仓库、数据库及域名按实际目标导入，不要求重命名，也不依靠名称相等建立关系。
+
+旧名称后缀、备注和默认规则可以提供映射线索，但需校验才能形成正式关系；无法确认的记录进入待核对清单。迁入的多工作负载需归入正式运行配置，不能丢失启动命令、副本、数据和权限等差异。
+
+旧代码或脚本复用需评估模型适配、权限、幂等、恢复、测试和维护成本。可以保留合格能力，也可以重写；迁移计划独立于代码复用决定。
+
+## 后续架构讨论的产物
+
+先完成概念关系及典型场景，再形成模块与数据所有权、应用和数据库候选比较、架构决策记录。最后细化表结构、API、事件、任务、权限和数据迁移契约。
+
+AI 执行、构建、资源开通和发布都需有输入输出、授权、状态、恢复和成本边界。具体部署分工待目标设计确认，不把旧 CI 或脚本限制作为永久前提。
+
+## 现状参考
+
+旧代码只用于盘点和迁移分析，不是新系统的结构要求：
+
+- [旧资源配置](<D:\work\env\config\k8s\webui\src\server\schema.ts>)
+- [旧数据库结构](<D:\work\env\config\k8s\webui\src\server\migrate.ts>)
+- [旧业务与运维接口](<D:\work\env\config\k8s\webui\src\server\index.ts>)
+
+现网操作继续遵守当前运维规则。对新模型的讨论不触发生产改名、表结构变更或部署切换。