# A03 注销后端独立复审

> 以下保留当时后端专项的验证记录。后续 Web 和 Payload 接线及新启动竞态的独立复验见[Web 注销与任务复审](dramivio-web-deletion-review.md)，不扩大此旧报告的验证范围。

日期：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`。其中实际差异：

```text
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 已完成验收。