diff --git a/docs/proposals/2026-10-12-service-restart-data-recovery.md b/docs/proposals/2026-10-12-service-restart-data-recovery.md index 53fa609..c79c22b 100644 --- a/docs/proposals/2026-10-12-service-restart-data-recovery.md +++ b/docs/proposals/2026-10-12-service-restart-data-recovery.md @@ -7,10 +7,11 @@ execution: code product_contract_source: ce-plan-bootstrap --- -# 服务重启与全量数据恢复方案 r2 +# 服务重启与全量数据恢复方案 r3 -确认状态：待人工评审。当前交付为源码调查、方案与实施/验收计划；业务实施、故障注入、部署、运行验收均为 NOT_RUN。 +确认状态：原 r2 批准记录保留（Dev PROJECT.md 记录 2026-10-12 五阶段批准）；**r3 本轮增补待人工评审**。本轮仅调查、修订方案及本地文档核查，不代签历史批准，不授权业务实施、账户变更、迁移、故障注入、部署、推送或合入。 修订记录：r1＝2026-10-12 初稿并完成六角色文档自审（见同名审阅记录第一轮）；r2＝2026-10-12 吸收外部源码复核（U1/U3/U4/第9节四处修订，见审阅记录第二轮），需求范围与量化指标未变。 +r3＝同日根据 dev 8788 账户故障续查刷新源码／运行事实，保留 R1–R10、KTD1–KTD12、U1–U7；补充 R11/R12、KTD13–KTD15、U8 单实例保护及近期验证合同。原故障档和时间指标保持候选值，未宣称实测达标。 需求来源：2026-10-12（Asia/Shanghai）用户要求“系统应该在停止并再次启动（通过 svc 或异常终止）后，应当能够恢复所有服务和数据，给我一个完善方案”。负责人：weichen；编制：Codex；实施与运维负责人在启动对应增量时指定。 主记录：本文；任务卡：Dev `.task/feature-service-restart-recovery-plan.md`。本文的源码路径以 Dev 根目录为基准。 @@ -34,20 +35,24 @@ product_contract_source: ce-plan-bootstrap ## 2. 当前事实及重点差距 -本次源码基线：Dev `5e57029b439e5690f28dc6002f9784f0b08920eb`；Backend `eb12f102f23d8d026c3458be7ea8b2fef07ada93`；Core `89f3906c390027512ef47b5333088c3d3a019e84`；Frontend `aaced8796bb45d151833e12bc1cc17fc5090ef6d`；Documents `23e2276905eaf3d5b266a5218a53a12a38321284`。来源为 SELF·源码观察，原始命令和输出由 Dev `make evidence` 写入本任务卡；风险是源码推断，不是已重现事故。 +本轮源码基线：权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`；文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`（任务元数据提交）；Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`；Core `89f3906c390027512ef47b5333088c3d3a019e84`；Frontend `cc233fec908d0f8c12193042942b94ad68508091`；固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。草案独立 Documents 基线 `1048e7c6afc2bb4efc541e68575c3fb2669ee332`，未推进 Dev gitlink。原 r2 对象为历史，不用于证明当前运行行为。 +来源为 SELF·只读观察；原始脱敏命令和运行输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。故障表现为源码推导，故障／恢复／耐久性验收 NOT_RUN。 | 对象 | 已存在的基础 | 尚需解决的恢复缺口 | |---|---|---| -| 数据库绑定 | `scripts/svc.sh:1373` 已统一解析 dbref/DSN/config；裸启动、restart/deploy 停前预检已接入 | 自定义 data/plugins 在参数重建时可能漂移；临时环境配置无法保证下次存在；配置多次逐键更新有崩溃中间态 | -| 服务生命周期 | svc 管理 agent/static/postgres；PostgreSQL 复用 pgdata；分发仓有单应用 systemd 模板 | svc 没有服务组依赖恢复与持久启动意图；无统一进程组监管；不管理 Redis 类型 | +| 数据库绑定与身份 | svc 统一解析已接线；manifest/marker 和 Backend DB identity 已存在；manifest 写入已有 file/dir fsync | 部分消费方仍读派生 svc.env；自定义根和 legacy/direct 启动需要完整核验；identity 不等于活动服务独占锁 | +| 服务生命周期 | svc 已有 desired/autostart、recover、watchdog timer；PG 优先拉起 | 没有完整服务组依赖／单一进程组监管；不管理 Redis 类型；登记版本与实际二进制可能不一致 | | 启动与停机 | 启动对账开放 run；优雅停机尝试中断和事件 flush | 恢复通知/子代理发生在完整接线前；HTTP停机超时可跳过flush；无所有worker等待；子代理 cancelled 可覆盖 interrupted | | 运行恢复 | `runmgr.go:2046` 对账、子代理派生请求/转录、pending_notices持久化、恢复hold检查 | 主run与HITL统一收为中断/取消；子代理先派生再写文件标记；notice消费非事务且绕过PG会话占用 | | 执行所有权与额度 | `store/execution.go` 有 owner/epoch/lease，终态有fencing；额度有持久表 | 续租只有定义未接入生产调用；15分钟租约可过期；额度无崩溃回收；不能据此宣称安全接管 | | 命令与投影 | 取消/HITL持久收件箱、Surface待投递标志、事件seq与SSE续传 | 命令先 consumed 后执行，kill窗口丢命令；跨实例取消入队缺conversation；Surface失败仍可清pending且仅扫100条 | | 工具副作用 | Native Session已有tool intent/result转录、安全重放判定；Backend有hold表及管理员释放入口 | `SetRecoveryHold`仅定义；Native的未知效果被写成工具错误后仍可继续模型，尚未与Backend run/owner/epoch和持久hold形成统一隔离闭环 | -| 文件与备份 | blob临时写+rename；工件元数据在DB；SQLite在线备份；svc有pg_dump | 覆写文件与更新元数据不是同一原子提交；未显式fsync；DB备份不含上传、工件、工作区、转录、配置/版本 | +| 文件与备份 | blob temp+rename、SQLite 一致性快照、pg_dump 已存在；Native 转录 Write→Sync；manifest 有原子同步链 | 工件原文先覆写再更新 DB，无不可变版本；agent 快照缺权威 manifest，PG 和文件快照不是同一恢复点 | +| SQLite 服务所有权 | WAL、30 秒 busy_timeout、每进程一连接；数据库事务可排队 | 无跨进程活动服务独占；恢复扫描全部开放 run，第二个服务可打断第一服务；不具备 PG 的会话执行租约 | -当前登记元数据显示 dev 绑定 `pg1/agent`，部署制品的 Backend revision 与上述Backend一致；这只证明登记和制品元数据。**实际运行进程的数据库身份、全栈恢复、数据耐久性尚未实测，不能写为PASS。** +2026-10-12 17:37:03（Asia/Shanghai）实际 dev 进程打开 `runtime/dev/data/agent-system.db`，DB marker 为 `sqlite`，运行 Backend `5e8ada7`；没有登记 PG 绑定。候选 rdmcand 已停止且登记来源与实际文件版本不符。前一轮共享数据观察是历史风险线索，不冒充当前双进程事实。**实际文件／marker 已核对，不等于全栈恢复或断电耐久性 PASS。** + +当前 PG 事件总线已有真重连、分页追赶和周期补查，Native 已接持久工具转录；这些基础不重复建设。SQLite 应用连接未显式声明 synchronous；诊断连接 PRAGMA 不能证明应用配置，见 R12。 旧报告中“DSN重启丢失”“迁移DDL与版本分开提交”“通知仅内存”等问题已有源码改进，本案只验证并复用这些基础，不把旧缺陷重新列成新建设。 @@ -65,6 +70,8 @@ product_contract_source: ce-plan-bootstrap | R8 | 停机与就绪 | 停机先拒绝新工作再排空；全部worker、sidecar和工具子进程收口；错误不跳过后续清理；ready反映业务可用 | | R9 | 升级与灾难 | 保留上一程序/插件/资产组合及兼容合同；备份恢复到新目标并完成业务/权限/文件对账；不在普通启动覆盖现库 | | R10 | 可见与证据 | 用户能区分继续、等待审批、等待恢复确认、失败；运维能定位阻塞依赖；每项验收绑定精确组合、制品、配置与原始输出 | +| R11 | 本地服务隔离 | 同一 SQLite/数据资源只允许一个活动服务运行时；直接二进制、路径别名和 legacy 入口同样受保护；账户短事务 CLI 不启动第二运行时；测试实例使用独立根 | +| R12 | 耐久性档 | 显式设置并从应用实际连接核验 DB 耐久策略；文件和目录同步覆盖权威对象；DB/文件持久失败不能确认成功；未实测的断电 RPO 保持候选 | 覆盖“所有数据”需要先完成数据归属清单：除Backend业务表，还含插件自有持久库/目录和下游RDM等已启用模块。每个插件声明恢复适配器、版本、权威位置、必需程度与兼容性；无法证明可恢复的必需插件阻塞全系统签收，不能只恢复Backend便宣称全部完成。 @@ -114,6 +121,12 @@ flowchart TB systemd的顺序依赖不能替代DB可用性检测；需真实探测，且明确依赖断开后的重连/恢复政策。监管策略参考systemd官方[service契约](https://github.com/systemd/systemd/blob/main/man/systemd.service.xml)与[进程组停止契约](https://github.com/systemd/systemd/blob/main/man/systemd.kill.xml)。 +KTD13. **SQLite 活动服务锁由 Backend 强制。** 在迁移和启动 run 对账之前按实际 DB／数据资源取得 OS advisory lock，持有至运行时退出；覆盖规范化路径和文件别名。marker/PID 不替代锁，SIGKILL 后由 OS 释放。合法账户 CLI 只核验同实例和兼容 schema 后做 DB 短事务，不启动 Manager；迁移独立维护。锁文件丢失或 DB 替换导致身份改变时拒绝自动续跑，不能新建可绕过的锁继续。 + +KTD14. **初始化与事故后缺库分开。** 已登记实例启动和运维先验证预期库／marker，缺失则阻塞；显式 init 才允许创建。SQLite 可靠档明确 WAL＋FULL 并核验每个连接；PG 核验实际 fsync/synchronous_commit/full_page_writes 等，不用诊断连接默认值证明应用配置。[SQLite WAL](https://www.sqlite.org/wal.html)、[PostgreSQL WAL](https://www.postgresql.org/docs/current/runtime-config-wal.html)。 + +KTD15. **manifest 单一权威与派生视图修复。** 复用现有 temp→fsync→rename→dirsync；读侧直接消费 manifest 或验证派生 revision。manifest 提交后、svc.env 派生前崩溃可重新生成视图，不能按旧派生配置换库。未知制品能力、登记／实际版本不符报告并拒绝危险操作，不猜测。 + ## 5. 启停流程与恢复政策 ### 5.1 启动和优雅停止 @@ -127,6 +140,7 @@ sequenceDiagram C->>D: 校验manifest、数据身份与操作锁 C->>C: 启动归本组管理的依赖并探测 C->>A: 启动固定版本 + A->>A: SQLite取得活动服务锁；PG按既有执行所有权合同 A->>D: 校验schema、文件与恢复候选 A->>W: 完成插件/权限/预算/工作区全部装配 A->>D: 分类认领、对账未知效果、恢复命令与额度 @@ -138,6 +152,7 @@ sequenceDiagram W-->>A: bounded join与子进程结果 A->>D: 持久化恢复意图、flush、收口许可/所有权 A->>D: 关闭存储 + A->>A: 释放本进程SQLite活动服务锁 A-->>C: 停机结果（含未完成原因） C->>C: 复核进程组消失；逆序停止独占依赖 ``` @@ -178,7 +193,7 @@ stateDiagram-v2 `recovering/hold`在这里是目标业务语义，**不是声称现有Core枚举已支持**。过渡可用恢复账本表达；若新增公开状态，Core/Backend/Frontend/下游契约兼容必须同增量处理。已有interrupted历史记录保留，不强改成成功。 -用户侧复用现有任务状态、对话卡和管理员恢复入口，显示恢复原因、进度和允许动作；SSE按持久seq补发并丢弃旧事件，页面刷新重载权威快照。断连或无增量不能推断任务完成。实施界面前重读根DESIGN.md并遵循UI令牌、Collapsible和单异步状态所有者规则。 +用户侧复用现有任务状态、对话卡和系统管理区，显示恢复原因、进度和动作。当前只有管理员恢复 API 基础，Frontend 对账接线待 U4 实施，不宣称已有可用界面。SSE按持久seq补发并丢弃旧事件，刷新重载权威快照；断连不推断完成。实施界面先读 DESIGN.md，遵守令牌、Collapsible和单异步状态所有者。 ## 6. 全量数据与组合备份 @@ -193,12 +208,16 @@ stateDiagram-v2 普通启停不从备份还原；数据库与文件继续使用同一身份及位置。灾难恢复由显式受管入口在新目标进行，禁止start自动覆盖当前数据。 +当前 agent backup 只复制 svc.env、history 和 data（逐 SQLite 一致性导出），不含权威 manifest，在线非 DB 文件与 DB 没有统一快照时点；它是数据目录快照，不是完整恢复包。当前 pg_dump 默认在 runtime 子目录，完整包及副本须放在数据／runtime 生命周期之外；生成时使用受限临时目录，校验成功后原子发布完成标记。半成品不列作恢复点，完成且验证的新备份存在前不执行保留策略删除。 + 首期备份取得明确停写窗口：关闭准入、排空或隔离在途操作、停止全部相关写者，核对独占管理边界后备份DB及文件并生成manifest。共享PG不能仅停一个API实例便宣称一致；写者无法证明停止则阻塞此类快照。后续可用不可变对象、DB发布记录、物理基础备份+连续WAL/PITR建立在线恢复点，manifest关联source snapshot、时间/LSN、schema、源码/制品/插件组合和对象版本。 恢复到新目标首先处于隔离验证模式，不启动任务调度/副作用，也不自动连接生产外部写目标。正式切换须证明旧实例、worker、sidecar、工具子进程及已发请求的写路径已经隔离：可采用停止并验证、资源侧拒绝旧执行代次、专用执行凭据失效或网络写路径隔离；不得为此擅自轮换共享凭据。生成新的恢复权威代次，并保证实际写目标能够拒绝旧路径。两个独立恢复库各自认可的epoch不能互相围栏；旧实例不可联系不能当作停止证明。无法核实则保持副作用hold，只开放受权的数据核验。 同时对账恢复点至故障/隔离完成期间的外部效果：它们可能已执行却不在恢复后的账本里。结合独立receipt、目标日志或人工核对，将已确认动作登记到恢复账本，确认安全后逐项解锁；不能仅扫描备份里的started记录就自动重试。灾难档报告批准RPO内可能丢失的写入范围、恢复点内完整性与外部对账结果。 +灾难恢复另设安全状态门禁：开放正常认证前作废备份中的全部会话和未使用登录 Key，防止已注销／消费的凭据复活。恢复点后的改密、长期 Key 撤销、角色／成员／插件授权变更与独立受信记录核对；缺记录或无法证明当前有效性时，相关主体／资源保持鉴权隔离，有权 owner／运维重新建立凭据或确认授权后开放。新执行 epoch 不代替认证撤销。普通启停／更新不执行此规则；普通账户恢复保留集成 Key 的合同也不允许灾难恢复盲目启用旧 Key。 + PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续WAL，不能用pg_dump冒充其基础备份，依据[PostgreSQL备份与PITR](https://www.postgresql.org/docs/current/continuous-archiving.html)。SQLite使用现有一致性备份接口，不能在线只复制.db遗漏WAL。文件内容先耐久发布再提交DB引用，备份保留覆盖恢复点所需的对象版本。 备份副本及密钥与原数据同级保护：加密、专用受限目录/角色、异机或异故障域副本、保留期限与清理owner；密钥须独立可恢复。拟定每日日常备份、持续WAL、每月及重大升级前恢复演练，频率按批准的RPO与数据量固定。实际恢复须验证登录、跨项目隔离、历史文档与附件、任务/HITL、工件下载和插件业务链；恢复时间从故障触发开始计时。 @@ -211,12 +230,16 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W ### U1. 实例与数据恢复身份 +当前 manifest／DB identity 基础已在源码，既有合同见 Dev `docs/recovery/u1-identity-manifest.md`；本轮只规划消费缺口、派生修复和显式 init/restore，不重复建立身份层。 + 对应R2/R3/R9；无前置。范围：`scripts/svc.sh`、`docs/svc.md`、`tests/test_svc.py`、`tests/test_svc_precheck.py`及新增manifest/identity验证模块。 做完整配置、逐字段覆盖、原子revision与操作锁、稳定秘密引用、DB/数据目录身份marker、独立init/restore入口；保留现有dbref修复并提供旧登记一次性兼容迁移。先补现状刻画回归，再改解析器。 验收：连续两次裸启停保持同一DB与原始记录；只改端口保持data/plugins；单独data覆盖按合同生效/拒绝；配置迁移每个写边界kill后只能读到完整旧/新版；缺凭据、错DB、丢marker不得新建空系统；更换二进制路径/程序版本或以不同cwd调用svc后，DB identity、数据/工件/工作区根与插件组合保持一致（对应R2更换程序/cwd条款）。使用真实PG特有测试记录核对，桩测试只能辅助。 ### U2. 服务组与进程监管 +当前 recover/watchdog/desired 已有首切片，余量为服务组、依赖 readiness、唯一监管与完整操作恢复，不再记为全部未实现。 + 对应R1/R8；依赖U1。范围：svc组编排、可选Redis适配、分发仓`deploy/agent-system.service`及安装接线、新增隔离服务组故障测试。 按KTD3/KTD4建立依赖图、desired state、可恢复lifecycle operation与单一监管；加入boot/start/exe身份与进程组校验。必需/可选、受管/外部资源由manifest决定。首次切监管在明确停机窗口完成，失败回到原监管且不形成双启动。 验收：全组停止后启动；先PG后应用；主动stop保持停止；kill自动退避恢复；主机重启按策略恢复；PID复用、残留子进程、端口冲突、依赖启动失败、不透明外部DB均正确拒绝/报告；不得停止其他服务组的共享依赖。 @@ -231,6 +254,7 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W 对应R4/R5/R7；依赖U3，并复用U5所有权接口；U4/U5作为同一安全交付批次，完整性验收前不开放自动续跑。范围：runmgr/runtime工具入口、store运行/恢复/hold表、checkpoint适配、Core公开状态及Frontend兼容、对应恢复与真实工具替身测试。 落实KTD7/KTD8，主run、Workflow、子代理、已配置后台executor共享恢复政策；持久化步骤/输入/结果/operation；自动hold连接到工具与启动扫描。HITL保持gate、答案和权限；修复子代理恢复链唯一性。文件checkpoint仅承担其明确的文件修改范围；若新增recovering/hold为公开状态，设计阶段先交付Core枚举→Backend→Frontend及下游契约的最小状态映射表，作为设计评审前提。 +Frontend 接线复用任务／对话卡和系统管理区：有权 owner/admin 查看具体 operation、未知原因和证据引用，提交已完成 receipt、未执行终态及旧请求隔离证明，或明确放弃。提交防重复，失败保留输入与原因，成功重载权威状态；Backend 按 operation 权限／版本／epoch 裁决，不以当前整 run release API 代替逐项对账。浏览器验收覆盖发现 hold→对账→剩余步骤恢复，拒绝越权和「放行即重跑」，不新增页面。 验收：排队/主run/子run/HITL/索引各类任务kill并两次恢复；工具“完成外部动作、结果未提交”只hold不重做；查询暂未发现但外部请求稍后完成时不发送第二次请求；幂等目标使用同operation key；Native pending intent只由统一账本决策，不生成普通错误后绕过hold；确认一个operation完成后执行剩余必要步骤，不假结算整run；未知工具默认隔离；撤权后禁止续跑；无executor类型明确blocked。真实模型最小任务级恢复对照单独申请测试资源，未跑标NOT_RUN。 ### U5. 所有权、额度、命令、通知与投影闭环 @@ -244,6 +268,7 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W 对应R3/R7/R9；依赖U1/U3，恢复账本完整验收依赖U4/U5。范围：blobstore/content、workspace与checkpoint、插件恢复适配合同、svc deploy/update/backup、分发仓安装、备份manifest与restore测试。 按KTD11发布不可变版本，扫描缺失/孤立对象；登记全部插件/下游存储；按第6节生成一致恢复点、保护副本、恢复到新目标；候选完整构建后切版本，保留兼容上一组合。 验收：对象写后DB提交前kill；覆盖发布过程中kill；日志尾截断/文件缺失保留现场；备份恢复后原文hash/权限/插件链一致；恢复新目标后旧实例复活仍不能产生外部效果，未完成旧写路径隔离时新目标不调度；恢复点后已发生的外部效果对账完成前保持hold；升级ready失败可在兼容条件下回退；不兼容schema拒绝程序自动回退；数据回退不静默丢新写入。 +另覆盖恢复点后注销会话、消费／撤销登录 Key、撤销集成 Key、改密与撤回角色／项目／插件权限：恢复旧包后旧会话和登录 Key 不再有效，无法证明有效的长期 Key／授权保持隔离；owner 正常确认后的新凭据可用。与普通重启原密码保持分别签收。 ### U7. 故障验收与交付放行 @@ -253,11 +278,28 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W 建议交付批次：A=U1/U2/U3（可靠启动及安全停机，自动任务续跑关闭）；B=U4/U5（安全自动续跑与命令闭环）；C=U6/U7（文件耐久性、灾难恢复及全系统签收）。只交付A不能宣称完成用户的全部需求。 +### U8. SQLite 活动服务隔离与既有存储门禁 + +覆盖 R2/R3/R6/R11/R12，复用 U1 身份；近期优先于自动恢复和共享库测试。范围：Backend `internal/app/app.go`、`internal/store/store.go`、`internal/store/system_identity.go`、新增 `internal/instanceguard/`（拟定）；Dev `scripts/svc.sh`、`docs/svc.md`。锁只控制活动服务运行时，CLI 身份／schema 合同由[账户方案](2026-10-12-svc-unified-deploy-and-login-key.md) U7 负责。负责人待实施批准时指定。 +依赖：既有 U1；联合确认 service／CLI／migration 模式，先刻画原例和别名冲突，再实现；不直接把当前 dev 数据迁往 PG。 +测试：新增 Backend `internal/instanceguard/guard_test.go`，扩展 `internal/store/system_identity_test.go`；Dev 新增 `tests/test_svc_storage_ownership.py`，复用 `tests/test_svc_identity.py`。新增路径为计划。 +T8-1：两个独立进程同时启动同 SQLite，只有一个进入迁移／恢复；第二个明确拒绝，第一个 run/HITL 不变。 +T8-2：直接二进制、legacy、符号链接和可构造的文件别名不能绕过；真实 DB 替换／锁根丢失被识别。 +T8-3：活动服务 SIGKILL 后合法同实例可重启，OS 释放锁；主动停止不被 watchdog 错拉起。 +T8-4：服务运行期间合法账户 CLI 可提交短事务；错实例／缺库拒绝、不建目录、不 migrate；迁移不与活动服务并发。 +T8-5：更换端口、cwd、程序版本保持同一资源；测试候选默认独立根，显式指定共享根也不得绕过保护。 +T8-6：参数来自应用实际连接；SQLite FULL/PG 同步设置按批准合同核验，磁盘满／写失败不返回成功。 +环境：独立 SQLite 根与端口、真实 PG 独立库回归；双进程和 kill 禁止在当前 dev/candidate 执行。全部 T8 当前 NOT_RUN。 + +近期批次 A0=U8＋账户方案 U7/U5：先稳定数据归属和账户链路；另行授权后完成 dev 原账户正常登录／重启／更新验收，见账户方案 §7。A/B/C 保留；U4/U5 联合验收后才开放自动续跑，A0 不代替全量恢复。 + ## 8. 验证合同 | 故障/操作 | 最小判据 | 对应需求 | |---|---|---| | `svc stop/start`连续两次、restart、地址与版本变更 | 原DB identity、记录/权限、data/plugins/artifacts根和固定组合一致 | R1/R2/R3 | +| SQLite 双进程、直接启动、别名、锁释放 | 第二活动服务在迁移／run对账前拒绝；合法 CLI 可用；kill 后同实例可重启 | R2/R6/R11 | +| 实际 DB 耐久档、权威文件发布点、磁盘满 | 参数来自应用连接；确认结果已耐久；失败不发布成功；旧版本可读 | R3/R7/R12 | | 应用SIGTERM/SIGKILL/OOM | 持久数据完整；安全工作可恢复；额度无永久占用；无残留写者 | R3/R4/R6/R8 | | PG停止/重启、断连或提交响应丢失 | 不切SQLite；不假接受；按幂等记录对账；重连后可用 | R2/R3/R5 | | 主动stop与异常退出、监管/编排中途kill | 主动停止不拉起；异常按running意图恢复；操作重复安全 | R1/R2/R8 | @@ -280,16 +322,16 @@ PG逻辑pg_dump用于独立逻辑恢复；PITR须有物理基础备份和连续W 本案补充[多人协作存储与分布式演进方案](2026-10-11-collaboration-storage-and-distribution.md)的R7及恢复/运维合同；不覆盖其批准记录或迁移、多实例放行条件。已存在的执行所有权、命令、outbox实现以当前代码为基础继续，不另起重复模块。 -调查时发现`feature/svc-autorecover`在途工作区，任务卡为manual且目标/方案仍待填；其实施与批准范围未经本轮证实。**U1/U2启动实施前必须人工二选一**：(a) 以`feature/svc-autorecover`为实施载体，把本案r2作为其需求与方案来源填入该任务卡后按其流程推进；(b) 记录原因后放弃或合并该任务卡，由本案派生的独立任务实施；两任务不得同时充当svc启动/监管改动的权威，该归属决定与首批实施范围一并报批；`feature/collab-storage-u5-outbox`也存在工作区，其变化未纳入当前固定源码。实施前核对当前主记录、卡片、PR、owner及组合SHA，不能依据分支名断言能力已完成。相关RDM/插件只有纳入兼容和恢复清单并验收后才能覆盖“所有数据”承诺。 +原 r2 的 svc-autorecover 二选一属于历史启动现场；当前 recover/watchdog 和 U1 身份已有源码，不再要求重新启动同一基础任务。新实施前仍核对在途 svc 监管／RDM UI／端口回收任务，避免重复修改入口。RDM／插件只有纳入兼容与恢复清单并验收后才能覆盖「所有数据」承诺。 备选：仅修svc脚本成本较小，只能覆盖启动配置/进程，无法满足在途任务和副作用恢复；另造常驻恢复daemon会增加新的监管者与恢复责任，首期无需。推荐现有svc+系统监管+Backend恢复协调的职责划分。 实施批准时需要固定：目标实例/服务组及独占管理权、实际数据归属清单、故障档与RPO/RTO、正常停机预算、既有在途任务分工。本文已给默认建议；没有这些确认不在共享运行环境做故障/迁移/监管切换。后台是否自动重做模型回合可按任务政策配置，但未知副作用不得靠默认重试放行。 -下一任务建议为U1并同步审查U3生命周期缺口：先保证再次启动绝不换库、换数据根或假就绪，再接监管和自动续跑。预计产物为兼容manifest合同、数据归属清单、隔离真实PG恢复回归与生命周期设计；进入实施前人工批准本案的需求、设计和首批测试范围。后续数据库备份、systemd安装、部署/启停与故障实验分别按授权执行。 +下一任务建议为 U8 与账户方案 U7/U5 的首批设计／实施评审：先保护 dev 原数据，补足账户一致性与登录语义；随后 U3 停机／就绪、U4/U5 任务恢复、U6/U7 文件与灾难演练。新增 U8 未批准前不实施。数据清单、故障档预算、正式组合验证仍为放行条件；PG 迁移、监管切换、备份恢复、部署和故障实验分别授权。 ## 10. 全系统完成条件 -只有在所有启用的必需服务/插件被纳入清单、R1–R10均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。 +只有在所有启用的必需服务/插件被纳入清单、R1–R12均有当前组合与运行对象的重放证据、第8节故障矩阵通过、未知副作用有可处理隔离状态、组合备份实际恢复成功、人工验收及代码Review通过并完成合入/部署后，才可声明“系统停止或异常终止后能够恢复所有服务和数据”。 本轮交付状态止于**待审核方案**；不以记录、源码能力、桩测试、健康接口或本地文档检查代替上述完成条件。 diff --git a/docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md b/docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md index 1a28135..b7bf37f 100644 --- a/docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md +++ b/docs/proposals/2026-10-12-svc-unified-deploy-and-login-key.md @@ -7,10 +7,11 @@ execution: code product_contract_source: ce-plan-bootstrap --- -# svc 统一部署与一次性登录 Key 方案 r1 +# svc 统一部署与一次性登录 Key 方案 r2 -确认状态：**已批准**（2026-10-12 用户「批准，继续推进」：需求拆解→实施计划五阶段及 U1/U4 规格一并批准；授权推送/PR 与启动 U1/U4 实施；合入仍由 owner 执行）。业务实施、测试、部署与运行验收在批准时仍为 **NOT_RUN**，由后续实施任务推进。 +确认状态：**r1 原批准保留；r2 本轮增补待人工评审**。r1 的批准记录为 2026-10-12 用户「批准，继续推进」（五阶段及 U1/U4 规格，允许对应实施和 PR）。本轮用户要求仔细调研、详细方案并「继续」，覆盖方案修订及本地文档准备，不扩展为业务实施、账户变更、迁移、部署、故障注入、推送或合入授权。 修订记录：r1＝2026-10-12 草案经源码复核后定稿（四项取舍采纳；补齐 §6 合同；对齐恢复方案 KTD 与已合入的 recovery U1 实例身份）；同日获批并进入推送与 U1/U4 实施。 +r2＝同日复核 dev 登录故障、当前 U1/U4 源码和帮助缺口；保留 R1–R12、KTD1–KTD10、U1–U6 的含义与编号，补充 R13–R15、KTD11–KTD14、U7/U8，并细化 U5。新增内容未批准；不以原批准记录代签新增范围。 需求来源：2026-10-12 用户提出将 `svc.sh` 增强为统一部署入口（二进制与源码、环境准备、无初始密码开户与账户恢复），并要求一次性 API Key 只能兑换「设置密码」受限会话。负责人：weichen；编制：Cursor Agent。 主记录：本文；任务卡：Dev `.task/feature-svc-unified-deploy-login-key.md`。源码路径以 Dev 根目录为基准。 @@ -26,7 +27,7 @@ product_contract_source: ce-plan-bootstrap | 环境检测与准备 | `doctor` 只报告；`env prepare` 按模式执行可幂等计划 | 不把任意发行版 Go/Node 标为可构建；工具链版本读自所选提交或发布清单 | | 账户激活 / 恢复 | 无预设密码开户或签发恢复 Key；原子兑换 → 受限会话 → 设密 → 正常登录 | 不删除重建用户；不迁移业务归属；普通找回默认不撤销长期集成 Key | -与 [服务重启与全量数据恢复方案 r2](2026-10-12-service-restart-data-recovery.md) 的关系： +与 [服务重启与全量数据恢复方案](2026-10-12-service-restart-data-recovery.md) 的关系： - **复用** KTD1–5、KTD12：持久 manifest、唯一监管者、team=PG 且失败不回落 SQLite、readiness 与身份。 - **复用** 已合入的 recovery U1（Dev #415）：`runtime//manifest.json`、启动身份校验、`svc init`、原子写路径（见 Dev `docs/recovery/u1-identity-manifest.md`）。 @@ -35,7 +36,9 @@ product_contract_source: ce-plan-bootstrap ## 2. 当前事实及重点差距 -源码基线（SELF·工作区观察，启动 precheck READY）：Dev `af9c2de663be5ff102dcab7698464a645832f569`；Backend gitlink 以该提交为准；本地评审时曾对照 `3fa0d3a` / Backend `696ef15`，与当前 main 可能有漂移，实施前以 `task-sync` 后 SHA 为准。运行验收 **NOT_RUN**。 +本轮 source 基线（SELF）：权威 Dev `2723e452440fc11022c0f6d916cd34cc4cd17335`；文档任务同步后 HEAD `26f2045e33516207959b5983acd32e1d3ea66bca`（增加任务元数据）；Backend `5e8ada727c358438f8ff9f94eabb697e99fe28dc`；Frontend `cc233fec908d0f8c12193042942b94ad68508091`；Dev 固定 Documents `8d0810bd35f4934e0ad37fb96d7bab6d7a732473`。本轮 Documents 草案从其独立权威 main `1048e7c6afc2bb4efc541e68575c3fb2669ee332` 起步；与 Dev 固定版相比，两份目标方案正文没有上游差异。Dev gitlink 未推进。原 r1 基线只作历史，不用于当前能力判断。 + +2026-10-12 17:37:03（Asia/Shanghai）的只读运行观察和启动／同步命令，原始脱敏输出由 Dev `make evidence` 写入 `.task/feature-svc-account-durability-plan.md`。这是 SELF 观察，不是登录、故障或恢复验收，后者均 NOT_RUN。 | 对象 | 已存在的基础 | 尚需补齐 | |---|---|---| @@ -43,15 +46,32 @@ product_contract_source: ce-plan-bootstrap | 部署生命周期 | 预检失败不停机；预检通过后 **先停再构建**；无程序备份/自动回滚 | 候选获取与校验全程不停旧服务；缺摘要硬失败；迁移后回退独立判断 | | 实例身份 | recovery U1：manifest + marker + init；`svc.env` 派生 | 账户 CLI 必须绑定实例最终配置；缺绑定拒绝，禁止回落 `./data` | | 环境 | 端口/`flock`/pg 工具链按需检查；文档列前提 | `doctor` / `env prepare`；无 `flock` 时不得放行冲突操作（现状直通） | -| 账户 CLI | `user create\|reset-password\|list`；省略密码 → 随机明文一次 + `must_change` | 无密码创建 + 激活 Key；恢复 Key；OpenExisting（不建空库、不静默 migrate） | -| API Key | 明文只显示一次；可长期复用；无 TTL/次数 | **独立**一次性登录凭据表；不可走 Bearer/`?key=` | -| 强制改密 | 前端门控 + `/api/me` 标志；`changePassword` 要求原密码 | 服务端中间件拦截待改密/受限会话；设密分型（一次性会话不要求原密码） | +| 账户 CLI | Backend 已有 create/reset-password/list/issue-login-key/revoke-login-key/bootstrap-admin；svc 已接 `user` 且附加 OpenExisting | 顶层／专题帮助未列账户入口；OpenExisting 仍 migrate；账户路径未完整验证 DB identity；参数回显及 argv 凭据需整改 | +| 登录凭据 | 长期 `api_keys` 与独立 `login_keys` 已分离；一次性 Key 原子兑换为短期受限会话 | 原子开户＋签发、统一密码变更及审计仍有缺口；不能把基础实现等同于整体验收 | +| 强制改密 | Backend 已有受限会话和 must-change 中间件，强制设密成功销毁会话并要求重新登录 | Frontend 仍只有密码／长期 Key 两个入口，未接兑换及 sessionScope/reloginRequired；设密后直接 onDone 与后端不兼容 | | 安装双轨 | Dev `svc deploy` 多实例；Releases `install.sh` 系统 systemd | 统一部署计划；`install.sh` 薄封装或明确遗留 | 命题裁定（源码复核）： -1. 长期 API Key 是 **show-once plaintext，不是 single-use** — **成立**。 -2. **无**统一中间件拦截 `must_change_password` — **成立**。 +1. 长期 API Key 是 show-once plaintext，不是 single-use；一次性登录 Key 是独立类型，当前代码已区分。 +2. r1 所记「无统一改密门」已被 U4 源码覆盖，不能继续作为待建能力；普通改密／管理员重置仍缺统一事务及旧恢复 Key 作废，见 `modules/backend/internal/server/accounts.go:208`、`modules/backend/internal/store/auth.go:244`。 +3. `scripts/svc.sh:1503` 已实现 user 转发，但帮助未列；`modules/backend/internal/app/app.go:743` 的账户插入和 Key 签发分别提交，不能采信注释中的「同事务」。 + +### 2.1 dev 8788 事件与归因边界 + +用户明确故障对象为 dev（127.0.0.1:8788）。17:37 的实际进程打开 `runtime/dev/data/agent-system.db`，数据库 marker 为 dev 的 SQLite 身份；该现场没有使用 PostgreSQL，不能沿用旧报告的 pg1/agent 描述。 + +| 只读对象（北京时间） | 账户身份 | 最后设密时间 | 与 live 摘要比较 | +|---|---|---|---| +| 12:35:03 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 | +| 14:50:37 快照 | 与 live 用户 ID 相同 | 09:52:11 | 不同 | +| 17:37 的 live | 同一账户，must-change=0 | 16:03:20 | 当前值 | + +比较仅输出时间、状态及相等性，不输出摘要或凭据。它证明字段重写，不证明明文改变；随机盐使同一明文的重新散列也可能不同。未发现正常启动／更新／迁移 up／设置播种自动覆盖既有密码的路径；现有 audit_events 只有 Surface 事件，无法归因此次写入。另有已消费恢复 Key，但其消费时间不能证明之后哪次设密由它触发。 + +前一轮观察到 dev 与候选 rdmcand 指向同一数据根；本轮候选已停止，因此不把历史共享描述成当前双进程事实。共享数据说明跨实例改密的影响范围，不证明某次更新主动改密。候选登记来源与实际二进制版本也不一致，应作为制品归属核验问题交恢复方案处理。 + +本轮不进行真实账户登录尝试或再次重置来验证旧密码；故障重放仅在脱敏、独立数据副本上执行。首批完成还需另行授权的 dev 原账户正常登录验收，见 U5／U8 合同；该验收不在 live 进行 kill、并发或故障注入。历史操作者归因仍未证实，新增审计不能反向补造旧事件。 ## 3. 需求合同 @@ -69,6 +89,9 @@ product_contract_source: ce-plan-bootstrap | R10 | 集成 Key | 普通找回默认保留长期 API Key；失陷恢复显式 `--revoke-all-credentials` | | R11 | 首次管理员 | 仅核验为新实例（无用户且无历史业务标记）；事务防并发；不得因「未发现管理员」接管有数据环境 | | R12 | 证据 | 验收绑定固定源码/制品摘要/环境；SELF/REPLAY/GATE 分源 | +| R13 | 可发现与兼容 | 完整／短帮助、help user、实例 user --help 和文档列出实际账户能力；不支持的制品在调用前拒绝；帮助／探测不建库、不迁移、不启动服务 | +| R14 | 账户稳定与审计 | 普通启停／更新不隐式重置；密码变更、恢复凭据／会话处理及成功审计原子提交；记录 actor、入口、实例、operation 与时间，不记录密码、摘要或 Key 明文 | +| R15 | 运维既有库 | 账户操作核验预期库和实例；读操作不建库或 migrate；schema 不兼容明确拒绝，迁移走独立入口；CLI 参数和日志不暴露凭据 | ## 4. 技术决策（KTD） @@ -92,6 +115,15 @@ KTD9. **候选校验完成前不停旧服务**；切换短窗；schema 迁移后 KTD10. **双轨收敛到同一部署计划。** 新旧 CLI 同后端；Releases `install.sh` 变为薄封装或文档降级为遗留，禁止第三套生命周期。 +KTD11. **能力声明与帮助同源，但后端仍是执行权威。** 新制品提供无副作用的结构化能力声明；旧制品仅按已验证版本兼容，未知形态拒绝。禁止尝试未知子命令或靠 strings 包含某词推断能力。保留 reset-password 的直接重置语义，不偷偷改成签发恢复 Key。 + +KTD12. **统一密码与开户事务。** 严格唯一 INSERT；散列计算在事务外，事务内重新核验权限／账户版本。主动改密、CLI／管理员重置、恢复设密共同执行密码＋标志＋旧登录 Key 作废＋规定会话处理＋审计。普通路径保留集成 Key，失陷模式按 KTD8 明确撤销；失败全部回滚。 +首次管理员按实例串行，不能只依赖 owner UNIQUE：PG 锁定既有实例身份行，SQLite 使用立即事务，取得串行权后重新核验无用户、无历史业务；引导与能改变此前置条件的开户共用串行点。管理员、激活 Key 和审计共同提交；marker 缺失时由显式 init 处理，账户命令不得补建身份。 + +KTD13. **审计可归因，运维不隐式迁移。** 成功审计与变化同事务；失败记录注明未提交；HTTP actor 来自已认证会话，CLI 记录受信 OS 运维 UID／身份来源，不接受调用方填写的 actor 作为证明。实例身份和操作 ID 实填。既有库读命令只校验兼容性；迁移另行批准和执行。 + +KTD14. **凭据只经安全输入和单次交付。** 优先无回显输入／stdin／受保护文件，DSN 不传 argv。serve 已消费 AGENT_SYSTEM_DSN，账户 CLI 的等价安全输入需在 U7 显式接入并以能力声明核验，不能假定当前 user flags 已读取环境。非交互输出独占创建 0600 文件，日志／evidence 只记凭据 ID。提交后交付失败按 operation 查询，再撤销／重发；库存摘要不能重新打印旧明文，不把重试当首次创建。 + ## 5. 职责划分与接口示例 | 部分 | 负责 | @@ -123,7 +155,7 @@ Linux 服务账户与应用账户分开管理。 2. 会话 scope / 中间件 allowlist；覆盖 `must_change` 普通首登。 3. 设密接口分型：受限会话不校验原密码；普通改密继续要求原密码；同事务完成写 hash / 清标志 / 作废 Key / 吊销会话。 4. 密码未设置状态：`password_hash` 可空或 sentinel；`VerifyLogin` 拒绝未设密；创建 = 用户行 + 激活 Key 同事务。 -5. CLI `OpenExisting`：目录/DB 不存在则失败；运维模式可禁止自动 migrate / 要求 schema 兼容。 +5. CLI `OpenExisting`：目录/DB 不存在则失败；账户运维默认只校验兼容 schema，不 migrate；迁移独立执行。配套 U1 v0.2 候选同此合同，原 requireCompatible 自动 migrate 是历史实现。 6. `release@` 必须解析到该版本目录；缺摘要硬失败。 7. 部署：获取/构建/校验不停旧服务；组合切换；迁移后回退独立判断。 8. `install` 与 `--from` 同一计划；双轨收敛（KTD10）。 @@ -144,10 +176,40 @@ Linux 服务账户与应用账户分开管理。 | **U2** 二进制与源码来源 | 下载/离线导入、仓库物化、版本清单、候选先校验 | 无开发仓可部署；固定版本与摘要可核验；修复 release 钉扎 | | **U3** 环境检测与准备 | 系统适配器、依赖计划、专用工具链、监管配置 | Ubuntu/Debian 首验；幂等；不接管共享服务；binary 不装 Go/Node | | **U4** 一次性凭据与认证限制 | Backend CLI/Store/Server/迁移 | 原子开户/兑换/设密；受限会话无法调业务 API；并发兑换单胜 | -| **U5** 脚本与登录页接线 | 账户命令、首次管理员、凭据交付、Login/设密页 | 新建与恢复走通；刷新与异常可续；DESIGN.md | +| **U5** 脚本与登录页接线 | 账户帮助、无副作用能力探测、凭据安全交付、Login/设密页 | 新建与恢复走通；设密后清受限会话并返回密码登录；不支持的产品明确拒绝；DESIGN.md | | **U6** 组合与故障验收 | Dev 组合、发布包、真机、数据保护 | 两种部署 × 存储档；故障注入；浏览器 + 真机；治理回归 | +| **U7** 账户事务与稳定性补齐 | 原子开户／引导、统一改密与撤销、审计、只读兼容打开 | 并发建号不覆盖；中断无半状态；旧恢复 Key 失效；身份缺失不改库；升级保持登录能力 | +| **U8** 实例运维核验与凭据诊断 | 账户状态／事件查询、绑定和制品诊断；补齐 U1 身份消费 | 可定位合法变更来源、识别错库／失效会话／错误 Key 类型；只展示非秘密元信息 | -**近期优先 U1、U4**（可并行兄弟分支、共用 R0）。跨仓顺序：Backend（U4）→ Frontend（U5）→ Dev gitlink + `svc.sh`（U1/U2/U3/U5）；组合 `make test` 后宣称可合入。 +**当前 U1/U4 基础已在源码中，近期优先 U7 和 U5，并与恢复方案 U8 隔离保护协调。** U7 先冻结后端账户事务／审计及能力声明合同；U5 随后完成浏览器与脚本；U8 诊断复用其记录。U2/U3 保留后续，不让通用安装器阻塞 dev 账户稳定。各仓从共同批准基线起独立任务；Backend → Frontend → Dev 组合，正式组合验证后才推进 gitlink。 + +### U7 近期实施与验证合同 + +覆盖 R5/R6/R9/R10/R11/R14/R15；依赖既有 U1/U4，实施负责人待指定。 +范围（相对于 Backend）：`internal/store/auth.go`、`internal/store/login_keys.go`、`internal/store/platform.go`、`internal/app/app.go`、`internal/server/accounts.go`、`cmd/agent-system/main.go`；迁移目录仅在 schema 需要时改动。 +先刻画现有显式改密、重置及建号行为，再修复并发与中断窗口。账户校验、禁止隐式 migrate、严格 INSERT 和统一密码事务是单一后端实现，脚本不直接写表。 + +现有测试参考 `internal/store/login_keys_test.go`、`internal/server/login_key_test.go`、`auth_e2e_test.go`；新增 `internal/store/account_lifecycle_test.go` 与真实 PG 跨进程用例（路径相对于 Backend）。 +T7-1：两个独立进程同名开户，只有一个账户／激活 Key 成功，败者不改变胜者角色、密码和成员。 +T7-2：开户、Key 签发、改密、会话处理、审计提交各故障点，最终只见完整旧态／新态；输出失败但提交未知时按 operation 查询。 +T7-3：普通改密、临时重置、恢复设密后旧未用 Key 都不可兑换；长期集成 Key 按 R10 保留／撤销。 +T7-4：读命令命中旧 schema、缺库、错 marker 均拒绝且不 DDL／建库；两个独立进程以不同 owner 并发首次引导单胜，另覆盖引导与普通开户竞争；有历史业务而无用户时拒绝。 +T7-5：普通重启、两次更新、SIGTERM/SIGKILL 后测试账户原密码仍验证成功，账户权限及成员不变；不以摘要是否变化替代密码可用性。 +执行环境：独立 SQLite 副本、真实 PostgreSQL 独立库、独立端口；不在当前 weichen 账户上故障注入。所有 T7 用例当前 NOT_RUN。 + +### U5／U8 近期接线与验证合同 + +U5 覆盖 R7/R8/R9/R13/R15，依赖 U7 对外字段合同；范围 `scripts/svc.sh`、`docs/svc.md`、Frontend `src/api.ts`、`src/auth.ts`、`src/components/LoginPage.tsx`、`src/App.tsx`。复用现有登录／设密页，类型明确消费 sessionScope、passwordSet、reloginRequired；恢复 Key 不写持久浏览器存储或 URL。 +同一登录页保留默认账号密码入口，增加「激活／恢复 Key」入口并说明只用于设密；长期 API 密钥入口标清集成用途。错类型提示指向正确入口，切换清输入，更新初始密码旧说明，不新增独立恢复页面。 +刷新／兑换响应不确定时先查询会话，有效受限会话恢复设密；会话不存在且 Key 已消费／过期时提示联系账户管理员重发，返回「激活／恢复 Key」入口。无密码账户不得被引导用旧密码登录。 +测试参考 `tests/test_svc_user_binding.py`、Frontend `test/auth.test.ts`、`e2e/changepw-form.playwright.ts`；新增 Dev `tests/test_svc_user_help.py`、Frontend `e2e/login-key.playwright.ts`（计划文件）。 +T5-1：完整／短／专题／实例帮助覆盖六个账户命令，并均无 DB／目录／服务副作用。 +T5-2：旧产品和 RDM 不支持账户 CLI 时在执行前拒绝；stdout 单次交付，stderr／进程参数／history 无秘密；两类 Key 双向填错有正确引导且切换清输入。 +T5-3：激活／恢复完成兑换→设密→重新密码登录；刷新／响应丢失先核会话；Key 已消费而会话失效时经管理员重发的新 Key 可以续办；过期、重复兑换、CSRF 错误有准确提示。 +T5-4：受限会话无法访问业务／下载／SSE／admin／插件；设密成功后不得因直接 onDone 误放行。 +U8 覆盖 R2/R14/R15，依赖 U7 审计；在 `user info`／账户事件查询（拟新增）展示实例、设密时间、凭据类型及状态。错误配置、注销、Key 失效与密码错误分别诊断，普通登录错误不泄漏他人账户信息。CLI/HTTP 两入口产生可追溯同一 operation 记录；历史无审计事件保持未知。 + +首批 dev 原账户闭环（NOT_RUN）：实现及隔离验证通过后，另行确认运行验收窗口／实例／版本，由 owner 在浏览器输入已知密码，检查原 user ID、角色、成员及原数据访问。若确实不能登录，明确恢复授权后才签发恢复 Key，保持账户和业务归属；不能为验收先重置能用的密码。随后在授权窗口验证普通重启及两次受控更新后原账户仍可登录。密码不交给 Agent、不进入证据；本轮不操作 live。 ### 必须覆盖的验收场景（摘要） @@ -172,11 +234,11 @@ flowchart LR ## 9. 风险与未授权范围 - 实施、故障注入、真机部署、浏览器验收：**未授权 / NOT_RUN**。 -- 本任务交付终点：正式提案 r1 + U1/U4 规格 + 任务卡与索引入口；推送/PR 须另获授权。 +- 本轮交付终点：r2 本地草案、恢复配套修订、任务卡与索引、文档核查和审阅记录；以本地文档提交固定审阅对象并满足同步门禁。新增修订仍待批准，不推进 Dev gitlink、不推送／建 PR；启动／同步工具的任务元数据提交单独记录。 - 与 recovery U1 重叠处只做增量，不重做已合入的 manifest 层。 ## 10. 规划进展与下一步 -- 本次推进：源码复核；四项取舍定案；正式提案 r1；U1/U4 规格细化。 -- 首选下一任务（**待授权**）：并行启动 U1 实施与 U4 实施（兄弟分支、共用 R0）；U2/U3 规格可随后写作但不阻塞 U1/U4。 -- 前置：人工批准本提案 r1（至少需求表 + 方案设计 + U1/U4 实施计划阶段）；实施前 `make precheck` 与 `task-sync`。 +- r1 已批准；U1/U4 基础实现存在于当前固定源码，完整浏览器／故障／运行验收不可据此推断通过。r2 的新增需求和设计仍待人工评审。 +- 首选下一任务（待授权）：恢复方案 U8 的 SQLite 服务隔离＋本案 U7 账户一致性；先消除共享测试数据和不可归因密码变化，再落实 U5。U2/U3 保持后续。 +- 前置：审核新增 R13–R15、U7/U8 及 U5 更新，明确实现和隔离测试范围／owner；实现、测试、部署分别授权。Documents 与 Dev 文档草案位于各自独立工作区；正式组合、gitlink 推进与运行验收未执行。