Dramivio项目文档下载文档包 ↗
2026.10.03 · 设计实施与自动回退修订本地实现与复审进展 · 真实服务尚未发布Markdown

视觉按最新原型，业务按已确认PRD。现有代码为满足设计而改造。执行见按设计实施与任务卡；当前代码与验证范围见消费者功能页。

A03 注销后端独立复审

本页目录结论独立发现与关闭证据P2：注销改写另一方的已结案邀请与申诉依据（已关闭）实际检查与证据范围测试计数保留的明确能力边界文件与作者分工

日期：2026-10-03。模型继承当前主 Agent，环境未公开具体型号；reasoning_effort=max。

作者为 root；本 Agent 未编写或修改候选业务代码。之前完成的只读接线探索不作为本轮实现验证。本轮只写独立 RAM PostgreSQL 复现脚本和报告，未访问生产数据库、SMTP、真实媒体或发布服务。

结论

发现并实际复现 1 项 P2：注销清理改写已结案的邀请拒绝原因和审核时间。root 已最小修复；本 Agent 使用原失败脚本独立复验并补重复清理断言，关闭该问题。当前核对范围未发现其他已证实 P1/P2。

这是注销后端接缝复审，不是完整 A03 产品验收。自动运营 worker 尚未挂载；现在只有可导入 processPending 和成功框架路由后的即时处理。注销 UI、本机离线/缓存擦除尚待后续，不将这些能力写成已完成。

独立发现与关闭证据

P2：注销改写另一方的已结案邀请与申诉依据（已关闭）

候选 services/platform/src/referral.mjs:398–400 原分支为 r.state !== 'rewarded'，连已 rejected 的关系也调用 rejectRelation(..., 'account_terminal', now)。

本 Agent 在独立 PostgreSQL 18 tmpfs 中通过实际领域函数和官方认证 HTTP 完成：

  1. 实际注册双方、发布隔离活动、创建邀请码并绑定。
  2. 实际 reviewReferral 拒绝为 risk_rejected，记录原 reason/reviewed_at。
  3. 活跃邀请人通过实际 submitReferralAppeal 提交申诉。
  4. 被邀请人创建注销意图、使用官方邮箱 OTP 取得新会话并调用 /api/auth/delete-user。
  5. 注销返回 200；另一方申诉行仍在，但原原因变为 account_terminal、审核时间也变成注销时间。

原 reconcileReferral 明确保留已 rejected 的终局结果；注销没有理由重写既有审核记录。重复清理原实现还会再次变更时间，破坏其稳定性。

失败日志：work/existing-project/a03-deletion-independent-before-fix.log。其中实际差异：

expected reason: risk_rejected
actual   reason: account_terminal
expected reviewed_at: 2026-10-03T09:49:15.070Z
actual   reviewed_at: 2026-10-03T09:49:15.115Z

最低修复由 root 完成：分支排除 rewarded 和 rejected；既有 reward receipt 恢复分支继续保留。未增加状态表或新审核流程。

修复后独立原脚本通过；又直接调用第二次 eraseTerminalReferralData，原原因/时间和另一方申诉仍保持。最终证据：work/existing-project/a03-deletion-independent-after-fix.log。

实际检查与证据范围

接缝 实际证据 结论
官方 beforeDelete 上下文 只读实际 BA 1.7.7 与 auth.mjs；独立重跑实际 HTTP 作者测试 getCurrentAuthEndpointContext().context.session 取得官方会话，身份来自框架；裸 fresh session/旧 session 不构成动作证明
直接路线防绕过 独立重跑：无意图、未复验、GET callback、POST 官方 token 分支拒绝 callback 禁用、token 分支拒绝，公开 beforeDelete 同一检查，没有另一个公开任意 userId 删除路径
Proof 新会话/归属/过期 作者实际 HTTP基线；本 Agent 新增持有真实 owner 行锁并让 intent 在等待中到期 不同账号/原 session/未知 operation/已过期 proof 拒绝；等锁后仍检查过期，terminal 和 command 都未落库
Terminal/Proof 次序 只读 account-deletion.mjs、entitlements.mjs；作者故障恢复实测重跑 原 stable operation 先记录 terminal/result/outbox，后消费 proof；失败恢复用原收据，不要求停用用户再登录
删除 sessions 后失败 作者真实故障测试独立重跑 cleanup503 后实际 session 数为0，原 worker 重试完成；原 command 只有1条
官方 user snapshot no-op 作者实际 SDK SQL 故障测试独立重跑 身份仍在时不 ACK、不报 deleted；解除故障后同 event 完成
普通管理 terminal 作者基线，以及本 Agent 新增实测原 admin event claim 的 kind＋commandActor＋operation 筛选不误删普通管理员 terminal 用户；该身份保留且 event 未被误 ACK
私人 query/AI budget 只读 owner→插入/预算同事务锁；作者迟到 AI callback 和 terminal budget 测试独立重跑 终态清理后旧 callback 不重建 private snapshot/usage，共享 global budget 不因销号清空
已入账丢 ACK 本 Agent 新增真实 creditReward 提交后保 pending referral event，再官方注销邀请关系一方 原 event 变 delivered、关系 rewarded/consumed，reward/credit ledger 各只有1条；另一方真实会话仍有效
未入账奖励 本 Agent 新增真实关系/待处理 event 后官方注销 event blocked、关系 rejected/released，另一方没有生成 reward；不在 reward claim 队列里
另一方申诉与旧结案结果 本 Agent 实际 review/appeal/官方注销/重复清理 P2 已关闭，原原因、时间、另一方申诉保留
锁序/max1 本 Agent 与作者基线均使用独立 max=1 pool；独立 expiry 等锁另用控制连接持既有 owner 行 各业务事务完成释放后再调官方 helper，无嵌套连接死等；H00/F00/private search 与终态同既有 owner 收敛
同邮箱重新注册 作者实际官方 HTTP测试独立重跑 新 userId 与旧不同，原 completed worker 不误删新身份

说明：奖励独立场景使用真实注册/绑定和实际 E00 credit；为了构造“已批准、待 ACK”的既有业务状态，在隔离数据库中置入 approved/event 前置记录。它们不证明真实来源签名、App 发行证明或真实观看达标自动发奖已接通。

测试计数

本轮未用此前 A03 的 133 项通过计数冒充注销验证。

  • 首轮独立执行作者当时的 tests/account-deletion.test.mjs：11 个场景＋1个父测试，Node TAP 12/12 通过，2.141 秒。日志 a03-deletion-author-tests-independent-run.log。这套基线当时尚无已结案记录检查，因此它不证明 P2 原本不存在。
  • 本 Agent 独立脚本 work/existing-project/a03-deletion-independent-check.mjs：4 个新增复合场景＋1个父测试，最终 5/5 通过，2.454 秒。包含 P2 原复现、修复后回归和重复清理断言。
  • 原 P2 失败运行：3个子场景通过、1个子场景失败，Node 连同父测试报告 pass3/fail2；原日志保留，未覆写为成功结果。
  • root 后续作者新增的注销场景和平台累计全套由 root 运行，最终计数以其运行结果为准，本报告不代报未独立执行的最新全套。
  • root 新增 Go intent/status 的4项定向测试为作者证据。本 Agent 只读核对其精确 status 例外和最少响应，未独立运行 Go 测试。

保留的明确能力边界

  1. processPending 当前是普通可导入 trusted runner；还没有定时/运营调度挂载。清理失败后的自动持续重试不能宣称已上线。
  2. 终态 owner、必要额度/设备 ledger、原 operation receipt 与脱敏关系保留。它们不是逐集位置或片单，不能将此阶段表述为“所有关联记录完全物理删除”。现 schema 无统一审计 TTL，不给虚构到期清理承诺。
  3. Core 私有消费内容已按 FK 顺序清，IP、用户申诉原文、观看证据行/其重复 command request、邀请码和设备观察处理可见。官方 verification 没有 user FK；当前 intent 被消费，但其他短期邮箱验证记录仍按框架真实 TTL 失效/清理。未配置删除邮件 token，不能模糊扫描邮箱 identifier 删除别人/新账号的 OTP。
  4. 服务端 identityAbsent 查原 userId 的 user/account/session 后才 ACK。消费者状态接口只持随机 operation 返回最少状态，不能借此继续读取旧个人数据。完整客户端退出、SecureStore/owner队列/下载归属擦除仍需后续 UI 与设备测试。
  5. 本轮未测试真实 SMTP、App attestation/source proof、外部媒体许可、生产 job 调度、所有设备平台或发布环境。没有为这些边界加自定义认证系统、新指纹或重复 store。

文件与作者分工

候选业务只读：account-deletion.mjs / auth.mjs / runtime.mjs / catalog.mjs / search.mjs / state.mjs / referral.mjs / entitlements.mjs / platform.mjs。parent 通知新增 Go 接缝后仅读取 internal/app/consumer_account.go 及精确中间件例外。

本 Agent 唯一写入：上述独立 check、日志和此报告。业务修复、作者新增回归均由 root 完成。本轮关闭结论只涵盖已列后端接缝，不代替整个 A03 已完成验收。