243 lines
56 KiB
Markdown
243 lines
56 KiB
Markdown
# Felis 生产就绪审计 — 2026-09-22（真机 E2E + 混沌）
|
||
|
||
分支：全部修复**逐 commit 直接推 `main`**（不再用功能分支）。环境：CentOS Stream 9 / aarch64 / k3s v1.36.4，
|
||
IPv6-only 接入（`ssh -6 -i ~/.ssh/id_ed25519 root@fdb2:2c26:f4e4:0:21c:42ff:fede:69ec`），
|
||
面板经 `socat TCP6:443 → 127.0.0.1:30443` 中继（手动启动，重启 VM 后需重开）。
|
||
|
||
## 已修复并验证（分支内）
|
||
|
||
| # | 缺陷 | 证据 | 修复 |
|
||
|---|------|------|------|
|
||
| 1 | **失败恢复后重试被静默吞掉**：restore Job 固定名 + `ErrAlreadyExists` 一律当"幂等成功"；失败 Job 占名 10 分钟（TTL），期间重试返回 202 `restoring` 但什么都不跑 | 真机：坏 ref 制造失败 → 立刻合法重试 → Job 原地不动、无新 Pod | `k8sjobs.go`：撞名时检查已完成（成功/失败）→ 删除+**等 finalizer 释放**（有界 10s）+ 重建；进行中仍幂等吸收。单测 3 个。**真机复验：重试 4s 完成恢复** |
|
||
| 2 | **备份 Job 全部 FailedMount**：Job 在 minecraft 命名空间挂 `felis-config`，而 bootstrap 只在 felis 命名空间创建该 Secret | 事件：`MountVolume.SetUp failed: secret "felis-config" not found` | `felis setup` 用既有 `ensureSecretReplica` 把 felis-config(`felis.toml`) 复制到 minecraft；VM 上手工复制后备份成功（167MB 归档） |
|
||
| 3 | RBAC 缺 `jobs:get/delete`（修复 #1 需要） | Role 检查 | `APIMinecraftRole` jobs → create/get/delete，测试同步更新 |
|
||
| 4 | gofmt 9 文件漂移 + CI 无 gofmt 门禁；staticcheck 9 处 | 基线扫描 | 全部修复；CI 加 gofmt job |
|
||
| 5 | 依赖漏洞：pgx v5.7.1（GO-2026-5004，可达 pgrepo.go）、x/net、x/text | govulncheck | 升 pgx v5.9.2 / x/net v0.55.0 / x/text v0.39.0 |
|
||
| 16 | **`ConsumeLoginEmailOTP` PG 实现与接口契约漂移**：契约/`fakeRepo` 说「同 VerifyEmailOTP 生命周期（扣尝试/锁定/ErrOTPInvalid/ErrOTPLocked）」，PG 却是单条 UPDATE+`ErrNotFound` → 错码/重放/过期在 login 门、op-login finish、migration confirm 三个入口全部 500；且尝试次数永不累计、`otpMaxAttempts` 锁定失效 | 真机：login 门重放正确码 → **HTTP 500**；修复前错码不扣次。修复后复测：5 次错码 400 且 attempts=5（正确码因锁定也 400、码未消费）、新码可用、重放 400 | `pgrepo.go` 改置为 VerifyEmailOTP 同构事务（FOR UPDATE、先锁后比、mismatch 扣次、match 消费），无 users 写副作用。提交 `52549f7` |
|
||
| 17 | **`ListPendingOpLogins` PG 少列**：接口注释承诺「joined to its staff username」，handler 输出 `username`/`created_at`，fake 正确填充；PG SQL 未 JOIN 也未取 `created_at` → 真机 pending 列表 username 为空、created_at 为 `0001-01-01` | 真机 internal `/op-login/pending` 响应 | `pgrepo.go` SQL 改为 JOIN users + 取 created_at。提交见分支 |
|
||
| 18 | **绑定码并发兑换 500**：`RedeemPlayerBindCode` 无 `FOR UPDATE`（同文件 `VerifyLinkCode` 有），且裸 INSERT。6 路并发同码兑换 → 3×HTTP 500（`users_username_key` 唯一冲突）+ 1×400 + 2×200；跨码并发同 UUID 同样会撞 | 真机四组并发测试 + API 日志 `unmapped error ... duplicate key` | 同码：码行 `FOR UPDATE`（输家干净地 400 invalid_code）；跨码：`INSERT users ... ON CONFLICT (username) DO NOTHING`+重读、`account_links ON CONFLICT (mc_uuid) DO NOTHING`（两路汇聚同一 user）。复测：同码×6=1×200+5×400、双码×2=2×200 同 ID、DB 干净、日志零 unmapped |
|
||
| 19 | **reaper CronJob 渲染位置错误，永远无法调度**：`felis manifests` 把 CronJob 渲染到控制 ns，却引用 minecraft ns 的备份 PVC（Pod 不能跨 ns 挂 PVC：真机 `FailedScheduling: persistentvolumeclaim "felis-backups" not found`）；修正 ns 后又发现 ServerAccount 也不能跨 ns 使用（`serviceaccount "felis-reaper" not found`）。而 reaper 的 Role/RoleBinding 本就在 minecraft ns | 真机三层取证（PVC/SA/调度）| CronJob 与 SA、RoleBinding subject 全部移到 `MinecraftNamespace`（提交 `e4f2cff`+`c839454`）。**修复后完整演练通过**（见下） |
|
||
| 6 | **默认安装无备份能力 + 回收链路不可达/不可用**：(a) 没有任何环节渲染归档 PVC，`FELIS_BACKUP_PVC` 永远为空 → backup/restore 恒 503；(b) bootstrap 从不下传 reaper 三旗标 → 官方安装路径根本无法启用回收；(c) 即便启用，stock k3s 的 `<root>/<pvc>` 布局不存在，且 k3s storage root 是 `0700 root:root`、reaper pod 以 uid 1000 运行 → 真机 `lstat /worlds/…: permission denied`（fail-closed 跳过，但纯空转）；(d) README 口径（“定时备份”）不实 | 真机全链路：默认渲染 PVC+env → 建服→marker→备份 202→jobs 端点 running→succeeded→改 marker→restore→读回原值 ✅；再建 resolvecheck 世界（20d idle，marker）→ CronJob 手动 Job：`evaluated=2 reaped=1`，归档含 marker、PVC+宿主目录回收、`world_backups` 得 `inactive_15d` 行、servers 行/CR 保留 ✅ | `platform/workloads.go` 渲染归档 PVC（minecraft ns、RWO 10Gi、默认 SC），`felis manifests --backup-pvc` 默认 `felis-backups`（`=` 空为显式关闭），bootstrap 统一下传 env/旗标并写 [archive] local_path；`resolveWorldDir` 新增精确 local-path 目录解析（读 PVC `spec.volumeName`，非 glob，杜绝陈旧 PV 目录顶替）；ReaperRole 增 `pvc:get`；bootstrap 设 `FELIS_WORLDS_HOST_PATH` 时给 uid 1000 授 traverse（setfacl/o+x）；README/故障手册改写。提交 `fd33fd0`+`2b87a5a` |
|
||
| 8 | **磁盘打满灾难链**：DiskPressure → kubelet 驱逐控制面（无 PriorityClass 保护）→ 镜像被 GC（无外网、registry 空）→ 全部 ImagePullBackOff；释放后数分钟才恢复调度。恢复依赖人工 `docker save | k3s ctr images import -` | 三轮真机 drill（原缺陷复现 + 两轮修复验证）：①自定义 1e6 类：游戏 pod 先走、控制面随后仍被驱逐（kubelet 日志逐条列出 ranked/evicted），随后镜像被 GC → ErrImagePull；②内建 `system-cluster-critical`（2e9）：填盘至 1.7G free，kubelet 对 felis-api/operator/registry 全部报 **“cannot evict a critical pod”**，三者在整个 DiskPressure 期间保持 Running；游戏 pod（0）被驱逐；③释放磁盘后：`DiskPressure` 经 ~5 分钟（`eviction-pressure-transition-period`）转 False——即“恢复慢”的主因；被 GC 的游戏镜像按 runbook 重导入后 25s 恢复 ✅ | 控制面四类 pod 挂内建 `system-cluster-critical`（用户自定义类值上限 1e9，达不到 2e9 临界阈值；preemption 保留=管理面可调度，已记录权衡）；troubleshooting §13b 固化事件链、5 分钟条件过渡与镜像恢复路径。提交见下 |
|
||
| 9 | **升级策略 Recreate**：单副本 + Recreate：任何控制面升级=停机；坏升级（错 tag）中断约 95s 且需人工 `rollout undo`（无自动回滚） | 复核部署模板（Recreate + 单副本 + 无 leader election 的注释理由成立） | 不改策略（Recreate 是对无 leader election 的正确取舍），改为固化 runbook：troubleshooting §15 = 升级即重跑安装器；停机窗口=rollout 时长；坏镜像在安装器 180s 等待内以 `kubectl describe` 诊断呈现；回滚 `kubectl rollout undo`（镜像被 GC 时先按 §13b 重导入）。提交见下 |
|
||
| 10 | **备份语义**：归档包含整个 /data（jar、libraries、cache），167MB；是否符合 world backup 定位待评估 | 真机 tar 清单（cache/、config/、eula.txt、server.properties、jar）+ 恢复语义（overlay+prune） | 评估结论：**整卷备份是正确语义**（回滚=整服状态回滚，含配置/插件），保留行为；文档化：troubleshooting §10「backup contains」+ OpenAPI/README 口径改为“整服数据卷”。提交见下 |
|
||
| 20 | **验证邮箱唯一性只存在于注释里**：errors.go/repo.go 都声称迁移 0010 建了 `users_verified_email_unique` 部分唯一索引、`VerifyEmailOTP` 会返回 `ErrEmailTaken`；实际上**索引从未创建**、`ErrEmailTaken` 全仓库从未被返回 → 两个账号可同时验证一个邮箱，而登录门正是按 verified email 解析账号 → 同一邮箱的登录码归谁由数据库任意决定 | pgint 首跑即红：第二账号验证同邮箱返回 `nil`；`grep users_verified_email_unique internal/store/migrations/*.sql` 零命中。真机复验（auditfix17 邮箱 409 演练）：同码二次 verify 仍 409（码未被消费） | 新增迁移 `0020_verified_email_unique.sql`（`lower(email) WHERE email_verified`）；`VerifyEmailOTP` 在消费码**前**查「他人已验证」→ `ErrEmailTaken`（不消费码、不扣次数），并把并发唯一冲突映射为同一答案；handler 新增 409 `email_taken`。提交 `b6ef27c`；PG 契约测试基建 `2a55a0d`（`-tags pgint`，见 CONTRIBUTING） |
|
||
| 21 | **admin 改邮箱不清 verified**：`UpdateUser` 写入新地址但保留 `email_verified=true` → 面板改错一个字符就能让登录码寄到别人邮箱（该 flag 正是邮箱登录解析/寄码的依据）；fake 同错 | pgint 契约测试 | 改地址时同写 `email_verified = email_verified AND email IS NOT DISTINCT FROM 新值`（同值 no-op 保留证明；换值即清除）；fake 同步。提交 `d1ec40f`。真机验证：PATCH→`f`、PATCH 回原值仍 `f`、玩家重验证→`t` |
|
||
| 22 | **`role='owner'` 是死信**：迁移 0011 加了 owner 角色并把全部用户管理路由压在 `IsOwner()` 上，但**没有任何代码写过 `owner`**——breakGlass(`UpsertOwner`)、setup MC 绑定(`CompleteOwnerSetup`)、重置路径一律写 `admin` → 全新安装的整个 owner 层（用户列表/创建/编辑/禁用/删除/配额/会话）不可达；且新角色没进各处 staff 判定（op-login 只认 admin、玩家邮箱门只拒 admin、reclaim 保护与 AdminExists 只认 admin）；面板一旦有 owner 行还可被降级/删除/禁用 | 真机：owner 会话加载 `/api/v1/users` 403；promote 后 200。op-login：修复前 owner start 中立不发码，修复后铸请求+finish 得 `role=owner` 会话 | `UpsertOwner`/`CompleteOwnerSetup` 改写 `role='owner'`（冲突臂重断言，即 0011 文档的 promote 路径）；op-login 双端改 `staffRole`；玩家邮箱门改 `role != 'user'`；`IsProtectedAdminLink`/`AdminExists` 计入 owner；面板新增守卫：owner 行不可降级/删除/禁用（用户名/邮箱编辑仍可）。提交 `e0d2378` |
|
||
| 23 | **配额门非原子 + storage 缓存被清零**：(a) audit #4：`QuotaCheck` 与 `ClaimServer` 两条语句，同一用户并发认领两台无主服可双双通过 `max_servers`（deferred-seams 曾把这条挂为“只能在真 PG 上关闭”）；(b) 更隐蔽：PATCH 资源时 `UpdateServerResources(..., 0)` 把本不能改的 storage 缓存写 0，而缓存列是配额聚合的**唯一**输入 → 此后该服的 storage 维度在配额里凭空消失 | (a) 新增 pgint 并发测试：修复前两台全赢；修复后恰 1 赢 + 1 `ErrQuotaExceeded`，DB 只 1 行 owned；(b) hermetic 测试 `TestPatchServerPreservesStorageCache`（修复前 `resourceUpdates` 里 storage=0） | (a) 门槛进 `ClaimServer`：同一事务内 `pg_advisory_xact_lock(hashtext(user_id))` + 四维重查（与 `QuotaCheck` 共用 `quotaAllows` 防漂移）+ 行 `FOR UPDATE`，两个 claim handler 把 `ErrQuotaExceeded` 映射为与串行一致的 403；(b) resize 前读取现值并透传 storage。提交 `bb68fef`；deferred-seams 对应条目核销 |
|
||
| 24 | **reaper 警告信从不真正投递**：`felis reaper` 从不装配任何 Warner（`r.Warner` 恒 nil），而 `maybeWarn` 对 nil warner / 投递失败一律照样 `MarkWarned` + `warned++` → 每位有主的服都在**无人收到提醒**的情况下 15 天后被静默回收，跑批日志还谎报"已警告 N 台"。红线⑤的"best-effort 不阻塞回收"被误读成了"失败也要记成已通知" | hermetic 单测 3 例（坏 notifier / nil warner → 不盖章、成功才盖章）。真机 drill（auditfix20）：13d idle 实收 1 封（收件人=owner 的验证邮箱、subject 含 3d）；重跑不重发；14.5d 补发 1d（elif 档位）；SMTP 端口打坏 → 日志 `warn delivery failed; will retry next run` 且**不盖章**，恢复后补发；邮箱未验证 → `has no verified email` 不盖章；owner NULL → 静默跳过；边界 11d23h 不发 / 12d1m 发；全程 `world_backups` 保持 4 条不动（纯警告零备份副作用） | `mail.SendNotice` + `mailWarner`：查 owner 的 verified email → `SendNotice`；nil/失败不盖章、下次重试；reaper pod 模板加 optional `FELIS_SMTP_PASSWORD` env；`felis setup` 复制 felis-smtp 镜像并在「configure email」刷新 minecraft ns 的 felis-smtp+felis-config 镜像；docs/troubleshooting §10 更新。提交 `8e7c7bb` |
|
||
| 25 | **idle auto-stop 从未触发（三层复合缺陷）**：条件齐备的空载服永远不停。① CRD status schema 未声明 `emptySince`，apiserver **pruning** 掉计时戳（`unknown field "status.emptySince"`），计时器每次读回都是 nil；② 即使戳幸存，Running 空载稳态**没有任何 watch 事件**（玩家进出不碰 CRD、RCON 只在 Reconcile 内探），盖章一次后 reconcile 链停摆，无人叫醒；③ auto-stop 用整对象 `Update` 写 spec 且 OperatorRole 从未有 `minecraftservers:patch/update` → 403 `cannot update resource`。三层任一都让功能永久失效，而单测（fake client 不剪 schema、手动驱动、无 RBAC）全部覆盖不到 | 真机逐层实锤：schema 修复后 `empty=2026-09-22T20:02:13Z` 首次成功持久化；静置 88s+ 无动作、operator 日志 90s 零行（②实锤）；修复前日志 5 条 403（③实锤）；全修后场景 1：超时戳触发即 Stopped；场景 2：起服 → 20:11:43 盖章 → **全程无干预** → 20:12:17 自动 Stopped；翻转 Running→Stopped→Running 收敛 Running；`idle=null` 后不再自停 | ① schema 补 `emptySince`（`c04a3f0`）；② `reconcileRunning` 尾部返回 RequeueAfter——空载=到点精确唤醒、有人=30s 探针周期，+3 个单测（`1c89a5e`）；③ auto-stop 改 merge-patch（防 status clobber，与 reaper 的 Stop 同型）+ OperatorRole 补 `patch` + rbac 测试锚点（`f650bf8`）。真机 auditfix22 全通；troubleshooting §11 增自检三连 |
|
||
| 26 | **RCON Secret 被删 → 服务器永久锁死**：删掉 per-server RCON 密码 Secret 后，(a) operator 没有任何 watch 能看到删除（Running 稳态零事件），secret 一直不重建；(b) 一旦被任意事件带到 reconcile：新密码铸造成功，但运行中的 pod 仍持有旧密码、sts 模板无变化 → pod 永不重启 → 探针用新密码连旧密码 pod，**永久 `RconNotReachable`** 直至 300s `ReadinessTimeout`；恢复只有人工删 pod。`ensureRconSecret` 的注释却声称"heals on the next pass" | 真机：删 secret 后静置 60s 无重建、无日志；annotate 触发后 96s+ 持续 RconNotReachable（新密码 `91dd62…` vs pod 旧密码）；删 pod 后 17s 恢复 Running——根因=密码漂移实锤 | ① `SetupWithManager` 增 `Owns(&corev1.Secret{})`（controller-owned，删除事件映射回 CR）——真机日志见 `source="kind source: *v1.Secret"`；② pod template 新增 `RconSecretAnnotation` = 当前密码 SHA-256 指纹（64-bit）：secret 重建指纹变 → sts 自动 rollout 用上新密码，未重建则恒定不抖动；测试 2 例（跨 reconcile 稳定 / 重建必变）。提交 `56f3abd`。真机复测：删 secret 后**同秒**察觉+重建+换戳，31s 全自动恢复 Running |
|
||
| 27 | **陈旧启动锚点 → 已恢复的服务器被误判 StartupTimeout + Provisioned 永久 False**：`status.startRequestedAt` 只在 Stop 时清，成功（markRunningReady）不清——一旦服务器曾经历一次长 Starting，其 300s 预算就悬在健康运行中；此后任意一次 pod 波动（rollout/崩溃）都会立即套用旧戳判 `Failed(StartupTimeout)`。且 `markFailed` 写入的 `ConditionProvisioned=False` 无人复位，恢复后仍永久挂着失败标记 | 真机：20:19 已恢复 Running 的 test-one，20:21 因一次 stamp 注入引发的 pod rollout 被标记 `Failed StartupTimeout`（锚点残留自 20:16）；恢复后 status.conditions 里 `Provisioned=False … StartupTimeout` 持续存在 | `markRunningReady`：清 `StartRequestedAt`（每次启动/恢复尝试各有独立预算）+ 复位 `ConditionProvisioned=True`；测试 2 例（Ready 清锚点、Failed→Running 后 Provisioned 恢复）。提交 `82b5a60`。真机复测：清戳生效（`startRequestedAt: None`）、pod blip 删→33s 恢复全程无 Failed、锚点重新盖章后成功清除 |
|
||
| 28 | **cfsetup 把 "policy already exists" 当成功吞掉 → fail-closed 保证可被旧策略顶替**：Cloudflare Access 的 `CreateAccessPolicy` 在收到 already-exists 时直接返回 nil；若该 app 上已有一条更宽松的旧策略（改 identity 后重跑、或此前手工配置），守卫 op.console 的仍是旧策略，而 Setup 报告成功——`validateFailClosed` 只校验过"我们构建的策略"，从未校验证留在线上的那条 | 代码审查（集成侧无真实 CF 账号，无法真机）：httptest 3 例复刻——已存在同名策略、缺席、POST 竞态。修复前第 1 例吞错返回 nil 且不发 PUT | 改为按名 upsert：lookup → PUT 覆盖守卫体 → 缺席才 POST（POST 撞 already-exists → 重查后 PUT，绝不吞）。`apiPost/apiPut` 共用一个 `apiWrite`。提交 `30857df` |
|
||
| 29 | **"configure email" 的工作负载镜像复制从不生效**：`replicateSMTPToWorkloadNamespace` 把硬编码 `namespace: felis` 的 felis-smtp manifest 用 `-n minecraft apply` 发出——kubectl 拒绝 namespace 冲突（`the namespace from the provided object ... does not match`）→ 第一段直接 return err，**第二段 felis-config 的镜像复制根本不会执行**。于是任何"装好后再改 SMTP"的部署，reaper 的 pre-reap 警告永远拿不到新配置（这正是 8e7c7bb 添加该刷新要解决的事），且失败仅 warning 不中止 | 真机 kubectl 行为实验：`-n minecraft apply` 带 `namespace: felis` 的 manifest → `error: … does not match …`；修复后（manifest namespace=minecraft）→ `accepted-namespace=minecraft`（server dry-run）；felis-config 渲染+apply 序列同为 accepted | `smtpSecretManifest(password, namespace)` 显式参数（控制面调用传 "felis"，镜像传工作负载 ns）；回归测试 `TestSMTPSecretManifestCarriesTargetNamespace`。提交 `ed722d5` |
|
||
|
||
## 待决策台账（未修）
|
||
|
||
前两日台账的 #7、#11–#15 已全部修复（本批核销，证据见下），不再挂在"未修"里：
|
||
|
||
| # | 主题 | 状态 |
|
||
|---|------|------|
|
||
| 7 | 异步失败不可感知 | ✅ 修复：`GET /api/v1/servers/{name}/jobs`（`ff7c57c`，含 RBAC `jobs:list` 与 OpenAPI）；真机 drill 用它看到 running→succeeded |
|
||
| 11 | PG 断连报 401 | ✅ 修复：会话存储故障改为 503（`2a8f897`） |
|
||
| 12 | ready 门滞后 | ✅ 修复：operator 启动期内每 2s 重探 RCON（`a2df2f2`） |
|
||
| 13 | setup URL 截断 | ✅ 修复：TUI 折行（`abce381`） |
|
||
| 14 | controller-runtime 日志噪音 | ✅ 修复：SetLogger 接 slog（`a415246`） |
|
||
| 15 | reaper 启用未演练 | ✅ 已演练（见"第二日"节；CronJob 仍 `suspend=true` 防误删） |
|
||
|
||
## 已验证事实（正向清单）
|
||
|
||
- 安装→hook 发码→Owner 绑定→passkey（虚拟认证器）→面板管理员全链路 ✅
|
||
- 建服（POST /servers）→ 唤醒（operator 拉 StatefulSet pod）→ RCON `list` → SSE 控制台 → 停止 ✅
|
||
- 文件编辑：列目录/读/写（wire 为 base64）/256KiB 413/路径穿越 5 变体全拦截/运行中 409 ✅
|
||
- **备份→篡改→恢复数据演练**：v1→备份→v2→恢复→读回 v1 ✅（G2 数据可恢复）
|
||
- **毒档案 fail-closed**：穿越/绝对路径/符号链接条目 → `archive entry escapes target` 退出码 1，零写入 ✅
|
||
- 混沌：PG 掉线（healthz 仍 200、恢复后连接池自愈）、API pod 击杀（~2s 中断）、整机重启（32s 回归、会话/CRD/停止态全保留）✅
|
||
- `felis update` 报告（k3s/velocity 有更新、私有仓库 404 优雅处理）✅
|
||
- 账户全套真机 E2E：绑定码新玩家注册（幂等/并发见 #18）、邮箱验证（onboarding 门）、邮箱 OTP 登录（错码扣次/5 次锁定后正确码也 400、重放 400、staff 账号 403 拒绝）、Passkey 注册+discoverable 登录+邮箱优先登录（虚拟认证器；Chrome 要求 `Page.bringToFront` 才能过 focus 检查）、登出吊销会话（旧 cookie 401）
|
||
- op-login 全状态机（start→status→approve→finish；早 finish 不烧码、错码扣次且请求保留、重放/重复批准/非管理员批准/未知 handle 全部按契约返回）✅
|
||
- 并发：OTP 风暴 8 路 = 1×202 + 7×429 且仅铸 1 码；绑定码并发（同码/双码）见 #18 ✅
|
||
- **reaper 全链路真机演练**（修复 #19 后）：绑定挂载假世界 → `felis reaper` 一 pass：归档 tar 落盘（内容含标记文件）、`world_backups` 行 `inactive_15d`+90d 过期、**PVC 删除且宿主目录回收**、servers 行保留且 activity 时钟重置（红线②）、CRD 保留；第二 pass：伪造过期归档被驱逐（`expired=1`，文件删、行转 `deleted`），合法归档未动；`evaluated=2 reaped=1` 只动到期的世界 ✅
|
||
|
||
### 本轮新增真机证据（第二日）
|
||
|
||
- **默认安装的备份闭环**：apply 新 bundle → 归档 PVC 自动创建（WaitForFirstConsumer，被首个 backup Job 拉绑定）→ `POST /backup` 202 → `GET /jobs` running→succeeded → 漂移 marker → `restore-backup` → 读回备份前内容 ✅
|
||
- **回收闭环（真实 k3s 布局 + 权限）**：resolvecheck（20d idle）→ CronJob 派 Job：`evaluated=2 reaped=1`；归档含 marker、PVC+宿主目录回收、`world_backups` 记 `inactive_15d`；期间先经历 `lstat /worlds/…: permission denied`（k3s storage root 0700）→ 修 ACL/root 权限后通过 ✅
|
||
- **磁盘压力三连 drill**：①1e6 自定义类：游戏 pod 先走、控制面随后仍被逐（kubelet ranked/evicted 日志）→ 镜像 GC → ErrImagePull；②改内建 `system-cluster-critical` 后：`cannot evict a critical pod` × felis-api/operator/registry，全部保持 Running；③恢复阶段实测 `DiskPressure` 条件 ~5min（eviction-pressure-transition-period）转 False，被 GC 的游戏镜像按 runbook 重导入后 25s 恢复 ✅
|
||
- **混沌**：SIGKILL k3s 主进程 → kubectl 与 felis-api ready 均在 **10s** 内恢复（api pod 本身未被重启）✅；内存压力（2.6G tmpfs 满写）：无 OOM kill、无人被逐（swap 5.9G 吸收 + 内核回收），控制面不受影响 ✅
|
||
- **构建链路定位（当时未修）**：Kaniko/Trivy 默认镜像是外部的 → 已加 `[registry] kaniko_image/trivy_image/build_cpu_limit/build_mem_limit` 覆写；上下文跨 ns 不可挂载（PVC 不能跨 ns）是设计级缺口，s3 lane 也缺凭据注入 ✅（证据：`internal/submit/blobstore.go:40`、`cmd/felis/api.go` contextBase 分支、jobspec 无 volumes/env）→ **第三批已修复，见下**
|
||
|
||
### 本轮新增真机证据（第三批：探针 + 构建链路全通）
|
||
|
||
- **控制面探针（`0c8e29b`）**：felis-api / felis-operator / registry 三个 Deployment 此前**完全没有探针**。修复后真机验证：api、operator `/readyz`+`/healthz`（internal 8081），registry `/v2/`（含命名端口解析）；三个 Pod `Ready=true`、`restartCount=0`、无 `Unhealthy` 事件；operator 新增 `--health-probe-bind-address`（8081，与 metrics 8080 分离，零检查也 404 → 已注册 ping）
|
||
- **构建链路全通（`f79e5eb` + `02fd2de`）**：
|
||
- 传输：context_ref 改为 internal-face URL；`felis fetch-context` initContainer 走 service token（对象来自 `felis-build` 里按 `bootstrap`/`felis setup` 同款 Secret 复制机制落地的 `felis-service-token`；netpol 只放行控制 ns:8081）+ zip-slip 安全解包到限容 emptyDir；Kaniko `--context=/context` 只读挂载
|
||
- **真机 E2E**：玩家 OTP 登录 → 建 submission → 上传 gzip context（marker `felis-e2e-build-marker`）→ Owner approve → Job：fetch ✅ → Kaniko 构建并 push `registry.felis.svc:5000/user-uploads/<sub>:latest` ✅ → Trivy 扫描（内建镜像 DB）✅ → Job `Complete`；**从 registry 拉回镜像校验 `/hello.txt` 内容 = 上传的 marker** ✅
|
||
- 演练中真机抓到并修复 3 个单测看不到的缺陷：① Job requests=limits（2C/4Gi）在 4C/5.5G starter 上**永远 Pending**（`FailedScheduling/Insufficient memory`）→ requests 改为地板值（250m/512Mi，不超上限）；② Kaniko 重拷 Dockerfile 时 chown/chmod 到源文件 owner（distroless uid 65532）在 drop-ALL 能力下失败（`copying dockerfile: chown … operation not permitted`）→ fetch 容器以 root 解包（= Kaniko 自身 uid）；③ Trivy DB 默认 `mirror.gcr.io` 正被 egress 锁拒绝（fail-closed）→ 新配置 `[registry] trivy_db_repository` + 文档 §8e 固化镜像配方（`docker pull/tag/push aquasec/trivy-db:2` 进内建 registry；`--insecure` 已覆盖明文 HTTP）
|
||
|
||
### 本轮新增真机证据（第四批：PG 契约测试 + 验证邮箱唯一性 + owner 角色）
|
||
|
||
- **PG 契约测试首跑抓到 #20**：`internal/pgint` 对着真实 PG（`felis_pgint`，drop schema + 重放迁移）跑会话/OTP/op-login/绑定码/submission/build 全契约；`TestOnboardingEmailOTPRejectsTakenEmail` 当场变红 → 挖出「索引从未创建 + `ErrEmailTaken` 从未返回」。
|
||
- **迁移 0020 真机应用**：`felis migrate up` → `applied 1 migration(s): [20]`；`schema_migrations` max=20；`pg_indexes` 出现 `users_verified_email_unique`。
|
||
- **邮箱唯一性真机 409 演练（auditfix17）**：owner 已验地址被玩家 onboarding 流程二次验证 → 第一次 409 `email_taken`；**同码重放仍是 409**（证明码未被消费，符合契约；若被消费会是 400）。
|
||
- **admin 改邮箱清 verified 真机演练（auditfix18）**：PATCH player.test → `[email protected]` 后 `email_verified=f`；PATCH 回原地址仍 `f`；玩家走 onboarding 重验证 → `t`。
|
||
- **owner 角色真机闭环（auditfix18）**：owner 行按 0011 文档升级路径置 `role='owner'` → `GET /api/v1/users` 200（修复前 403）；owner op-login start 铸请求+发码、finish 得 `role=owner` 会话；PATCH owner role / DELETE owner / DISABLE owner 全部 403；玩家邮箱登录回归 200。
|
||
- **配额原子门（第五批，`bb68fef`，auditfix19 已上线）**：pgint 并发实证（真实 PG 上两路并发认领：恰 1 赢 + 1 `ErrQuotaExceeded`；修复前两路全赢）；`docs/deferred-seams.md` 的 audit #4 条目核销。
|
||
|
||
### 本轮新增真机证据（第六批：reaper 警告链路端到端演练，auditfix20）
|
||
|
||
- **演练装置**：独立 hostNetwork Pod（`felis:auditfix20`，SA/卷结构复刻 live CronJob）+ 宿主本地零依赖 SMTP sink（捕获完整 RFC5322 原文）+ 专用 `felis-config-drill` Secret（SMTP 指向 `127.0.0.1:1025`）；场景服 `warntest`（独立 CRD，desiredState=Stopped，不占资源），期间 operator 暂停防 reconcile。
|
||
- **投递**：13d idle → 恰 1 封，`To: [email protected]`（owner 的**验证**邮箱）、subject 含 `3d`、正文含 server/remaining；`warned_3d_at` 盖章、`warned_1d_at` 留空；`world_backups` 保持 4 条（纯警告零备份）。
|
||
- **去重与档位**：重跑 0 封（已盖章不重发）；14.5d idle → 补发第 2 封 = `1d` 档（elif 顺序正确，不是重复 3d），`warned_1d_at` 盖章。
|
||
- **失败语义（三连）**：SMTP 端口打坏 → 日志 `warn delivery failed; will retry next run`（err=`connection refused`）、**不盖章**，恢复端口后同一 run 补发成功；邮箱 `email_verified=false` → `resolve owner email: … has no verified email`、不盖章，恢复后补发；owner NULL → 静默跳过（无日志无警告）。
|
||
- **边界**：idle=11d23h（< 12d 阈值）不发不盖章；idle=12d1m 发。`http_code` 冒烟：升级 auditfix20 后 panel 200 / op-login 200。
|
||
- **环境还原**：warntest CRD+行删除、drill Secret/Pod 删除、operator 恢复；`servers` 表回到 resolvecheck+test-one，CRD 回到 lobby/login/resolvecheck/test-one。
|
||
|
||
### 本轮新增真机证据（第七批：idle auto-stop 三层修复，auditfix21/22）
|
||
|
||
- **发现路径**：operator 深挖时先怀疑"计时器无驱动"，真机实验立刻抓到 pruning（操作日志 `unknown field "status.emptySince"`）+ 触发后 88s 无动作 + RBAC 403，三层各自独立、各自足以致死。
|
||
- **场景 1（超时点唤醒 + 写权限）**：EmptySince 已超时 11 分钟 → annotate 触发一次 → 秒级内 desiredState=Stopped、sts 0/replicas、EmptySince 清、phase=Stopped。
|
||
- **场景 2（完整自驱，决定性）**：desired=Running → pod 起 → 20:11:43 盖章 → 静置无干预 → **20:12:17 自动 Stopped**（30s 到点后 ~4s 完成 stop+scaledown+markStopped）。
|
||
- **翻转混沌**：3 秒内 Running→Stopped→Running，最终收敛 Running ready（期间 409 竞争为控制器正常噪音，controller-runtime 重试自愈）。
|
||
- **收尾**：`spec.idle` 删除后再无自停；test-one 回 Stopped、空 sts、无 EmptySince；VM 镜像 auditfix22 = `f650bf8`。
|
||
|
||
### 本轮新增真机证据（第八批：operator 自愈深挖，auditfix23/24）
|
||
|
||
- **RCON Secret 删除自愈（`56f3abd`）**：修复前——删 secret 静置 60s 零察觉、触发后 96s+ 永久 `RconNotReachable`、仅人工删 pod 可恢复；修复后——删 secret **同秒**（20:22:16）察觉（Secret watch 日志）→ 新密码 + stamp 换值（`3b24164f…`→`c465b627…`）→ rollout → **20:22:47 全自动恢复 Running**（31s）。
|
||
- **陈旧锚点（`82b5a60`）**：修复前——已恢复服务器因锚点残留被 `Failed(StartupTimeout)`、`Provisioned=False` 永挂；修复后——Ready 即清锚（`startRequestedAt: None`）、`Provisioned: True`；pod blip 演练：删除→20:24:48 重锚→20:25:19 恢复→锚清空，**全程无 Failed**。
|
||
- **StatefulSet 误删自愈**：删除 sts → **秒级**重建（PVC `world-test-one-0` 保持 Bound，Retain 策略）、29s 后 Running、stamp 保持 `c465b627…`（未触发多余 rollout）。
|
||
- **收尾**：期间 7 条 operator ERROR 全为 CR/sts 409 竞争噪音（自愈）；test-one 回 Stopped。
|
||
|
||
### 本轮新增真机证据（第九批：未演练端点地毯覆盖 — 迁移 / access / window / credentials）
|
||
|
||
- **account/migrate 四步状态机全链路（首个端到端演练，0 缺陷）**：造 user2 目标账户（绑定码 `FDTGKYAQ`）→ player.test claim test-one → 内部 start（未联动 UUID=404 not_linked；源=201 initiated）→ `passkey_required 409`（有 passkey 强制强因子）→ **passkey credentials list + DELETE 204**（顺带覆盖管理端点；删后 OTP 门自动解除）→ OTP start 202 / 错码 400 / 真码 confirmed → issue-code（self=400 / missing=400 / 真目标=201）→ redeem 负例×2（源持码=400；target 错码=403 setup_required——**onboarding 门正确拦截未验证账户**；验证邮箱后重试）→ **redeem 成功**（小写+空格码兼容，`servers_moved:1`）。
|
||
- **retire 断言全对**：servers.owner→user2；migration=redeemed（含时间戳）；源 disabled+软删；源活跃 session=0；源旧 cookie 401；double-redeem 400；源再加迁移 409 account_retired。**环境复原**：源复活 + 新 OTP 会话、test-one 归还无主。
|
||
- **access 玩家管理全组（0 缺陷）**：players/whitelist/banlist 三个读 projector 解析正确（`There are 0 of a max of 20 players online: `→[]）；kick/permission/group/luckperms-info 调用全通（demo 服无 LuckPerms → 原样透传 `Unknown or incomplete command`，API 不掩饰）；输入负例 4 连 400（bad player/bad action/bad node/bad world）；`whitelist add/remove` 在空档案服上得到 vanilla `That player does not exist`（fail-closed egress 无法解析 Mojang profile——**vanilla 约束非 API 缺陷**，命令已如实送达）；手写 whitelist.json + `command whitelist reload` 验证成功路径解析（`players:["E2E_Tester"]`）；**audit 7 条 access.\* 全记录**。
|
||
- **updates/window**：unset→null；PUT 正例+读回；半设 400；倒置 400；clear→null 全对。
|
||
- **/fleet**：4 服全量（含运行中 lobby/login 的 endpoint 地址）一次读全。
|
||
- **bootstrap-assets crd**：嵌入式资产含 `emptySince`（auditfix24 二进制核对）。
|
||
|
||
### 本轮新增真机证据（第十批：configure email 复制链修复，auditfix25）
|
||
|
||
- **发现路径**：复核 `8e7c7bb` 新增的 replicate 逻辑时怀疑 manifest/-n namespace 冲突 → kubectl 真机实验裁决（hardcoded `namespace: felis` 版直接 `error: … does not match …`，证实第一段必错、第二段被跳过）。
|
||
- **修复后行为验证**：两条命令序列（felis-smtp manifest 携带目标 ns + `felis-config` create--dry-run|apply）均被 server 接受且落点 `minecraft`。
|
||
- **live 收敛项（随下次 `felis install/setup` 重跑）**：live CronJob 仍是旧模板（无 `FELIS_SMTP_PASSWORD` env）；`felis-smtp`/镜像两 ns 均未创建（SMTP 未配置，属正常）；与 operator Role 手动补 patch 同批处理。
|
||
- **部署**：`felis:auditfix25` = `ed722d5`（api/operator/reaper 三处 set；api/operator rollout 完成，panel 200）。
|
||
|
||
### 本轮新增真机证据（第十一批：submission 全路由负例矩阵 + 内部面取件 + owner 会话重铸）
|
||
|
||
- **session 重铸路径（hook）**：owner 旧 cookie 过期（401）→ 临时插 `account_links`（owner↔假 UUID）→ op-login 三件套：start 202 → 日志取码 → 内部面 `op-login/{id}/approve`（hook，经 service token）→ status `approved:true` → finish 200 `role=owner` → op 域新 cookie 生效（`/fleet` 200）；**演习后已删除假链接行**。顺带复证：approve 失败时 status=false、finish 400 `op_login_invalid`（码不烧，复用同码二次 finish 成功）。
|
||
- **submission 车道负例矩阵（23/23 PASS，0 缺陷）**：create 未知字段/空名/非法字符/超长 → 全 400；非 gzip 上传 400、未知 id 404；跨用户上传 → **404 不可见**（非 403）；玩家打 admin 三路由（queue/approve/reject）全 403；reject 空理由/1001 字/夹带字段 → 400，成功 200（`reject_reason`/`reviewed_by`=验主邮箱/`status=rejected` 全对）；重复 reject 409、reject 后 approve 409；**无 blob approve → 400 且行保持 pending_review（未 stranded）**；玩家列表严格只见自己。
|
||
- **内部面取件**：`GET /api/v1/internal/submissions/{id}/context`（service token）→ 200 + gzip magic `1f8b` + 解包内容 = 上传 marker；无 token 401；未知 id 404。
|
||
- **演习清理**：E2E-Lane-\* 8 行已删、假链接已删；队列只留历史 "E2E *"（approved）行。
|
||
- 备注：port-forward 再次因 API pod 重建悬死（空响应）→ 按速查重启即恢复；本轮无需新镜像（纯验证）。
|
||
|
||
### 本轮新增真机证据（第十二批：users 管理面全量矩阵 → 抓到并修复 #30）
|
||
|
||
- **/users 管理面矩阵（修复前，39 PASS / 2 NOTE）**：create/get/patch/list 权限与负例全对（未知字段/非法用户名/owner 角色/未知 id → 400/404；owner 保护 403 复证）；sessions 单条吊销→旧 cookie 立即 401→重登恢复、revoke-all 同效（重登两次含 61s 冷却等待，全绿）；passkeys 无凭证 200 no-op；links 幂等/跨用户 409/非法 auth_source 400/解链 404 全对；disable/enable/delete/double-delete 全对。
|
||
- **缺陷 #30（两处 FK 500 + 一处假 200）**：`PUT /users/{unknown}/quotas` 与 `POST /users/{unknown}/links` 触碰 user_id 外键 → **500 internal**（契约要求 404）；`GET /users/{unknown}/quotas` 回**零值视图（=unlimited）**，像 id 存在。修复：`PGRepo.requireLiveUser`（live 行 + `deleted_at IS NULL`）守卫三个方法，`handleGetQuotas`/`handleLinkAccount` 补 ErrNotFound→404 映射；单测 `TestAdminSubresourcesRequireLiveUser`（fake 同步 liveUserExists 契约）+ pgint 真库契约（ghost→ErrNotFound、live 对照、软删后→ErrNotFound）。commit `1918da2`。
|
||
- **auditfix26 真机复验**：ghost 三连 → **404 not_found**；活用户对照 → PUT/GET quotas 200（读回 2）、POST link 200、delete 200；panel 200，api/operator 滚动完成（新 pod 24s Ready）。
|
||
- 契约备注（非缺陷）：软删用户 `GET /users/{id}` 仍 200（带 `disabled=true` + `deleted_at`，列表已过滤）；`DELETE .../sessions/deadbeef` 幂等 200；revoke-all 对未知用户 200 no-op。
|
||
|
||
### 本轮新增真机证据（第十三批：CLI / 镜像面 / 直接构建 / 面板 CDP 全路由 + #31/#32）
|
||
|
||
- **CLI 面 19/19（VM，`felis-auditfix26`）**：`version`/`-h`/无参=exit2/未知命令=exit2；`manifests` 缺 `--velocity-cidr`、缺 `--felis-image`、坏 CIDR、坏 NodePort 全 fail-loud exit2，正例渲染 25 文档且 `--worlds-host-path` 分支出 CronJob+三条前置警示——整包 `kubectl apply --dry-run=server` **全部 `configured`**；`apply` 缺 `-f`/文件不存在/坏 JSON 各自 exit2/1/1；`migrate up` 二次幂等（`database already up to date`）；`bootstrap-assets crd`（含 `emptySince`）与 `game-stack`（tar）正常；`update` 正常。
|
||
- **镜像面负例 + builds 负例**：`/images` 列表 200、空体 400、合法 201、重复幂等 201、无 `?ref` 400、删除 **204**（契约；我的 200 预期作废）、再删 404、坏 ref 400；`/images/build/unknown` GET/cancel 均 404；空体提交 400；玩家打 `/images*` 全 403。
|
||
- **`/images/build` 正路径（直接构建）**：借遗留 submission blob 作 context，`FROM scratch` 内联 Dockerfile → **202 → 12s succeeded**；`/logs` SSE 实收 Kaniko 流；真机 registry `tags/list` 出现 `e2e/direct-probe:latest`（镜像确实被推入）。留档：该 drill 镜像保留在 registry。
|
||
- **`auth/options`**：未知邮箱 → `{"methods":[]}`；玩家 → `["email_otp"]`（无 passkey 时）；坏邮箱 400。
|
||
- **`PATCH /servers/{name}`**：空体/storage/空 policy/未知字段/坏名 → 400；未知服 404；displayName 设置+还原 200。**契约备注**：`displayName:""` 因 `omitempty`+merge-null 语义 = **清除该字段**（本次 drill 先误读为设空串，比对 patch 前 fleet 快照确认 test-one 原无 displayName，无数据损失）。
|
||
- **面板 CDP 全路由巡检（owner 会话，14 路由）**：全部有标题/有内容/无崩溃；唯二发现 = #31/#32（见下）；`luckperms` 页对 stopped 服 409 → **优雅降级**为「服务器已休眠 + 启动」态（browser 级 409 日志属正常资源日志，非缺陷）。玩家会话 4 路由零错误且**导航分级正确**（不见管理/平台组）；未登录 `/login` 渲染正常（`/me` 401 为预期探测）、`/account` 未登录重定向 `/login`。
|
||
- **缺陷 #31（面板 mock 残留·owner 判定）**：`ImageBuildPage` 用 `email==="[email protected]" || startsWith("owner@")` 猜 owner——真实 owner（`[email protected]`）**不被识别**（只能看 approved 提交），而任何 `owner@x` 邮箱都冒充 owner。改为消费 TierProvider 服务端 `isOwner`。commit `6907961`。
|
||
- **缺陷 #32（面板 mock 残留·假构建种子）**：首次访问 `/admin/builds` 向 localStorage 播种 `["bld-1","bld-2"]` → 每个新浏览器打两个必然 404 的请求（页面注释自认“in production will 404”）。移除播种。同 commit。
|
||
- **auditfix27 复验**：清掉该 localStorage 键后重访 → **只发 `/me`**、零错误、空态正确；面板 111 单测 + typecheck 全绿。
|
||
- **passkey 全流程复验（CDP 虚拟认证器，面板 UI 实操）**：注册（对话框输入→仪式→列表出现 `E2E-Key`）→ API logout → 邮箱优先 passkey 登录（`/me` 回 `[email protected] user`、落回 `/`）→ `DELETE credentials/{id}` 204 → 列表清空（环境复原）。
|
||
- **环境**：api/operator/reaper 镜像 = `felis:auditfix28`（= `6907961`）；面板 200。**教训**：`pkill -f "port-forward …"` 会匹配到**执行该命令的 ssh 自身 cmdline**（命令里同时含明文 `port-forward svc/…`）→ 自杀式断连；改为 `ss -ltnp` 取 PID kill，另起一条 ssh 启动转发。
|
||
|
||
### 本轮新增真机证据（第十四批：#33 死账号复活漏洞 —— 全登录门闭环 + 资产切断）
|
||
|
||
- **发现路径**：users 管理面演习收尾核对时发现软删用户仍留 `account_links`/`quotas` 孤儿行 → 顺藤摸瓜确认 `UserByEmail` 与 `SessionUser` 均不过滤 `disabled`/`deleted_at`。
|
||
- **红证据（auditfix27，真机）**：禁用用户的邮箱门重登录 `verify=200`、`/me=200`（**禁用锁死可绕过**）；**已删号**用户 `start=202`（真实发码）、`verify=200`、`/me=200`（**删号可复活**）。
|
||
- **修复（`5853589`，7 文件 / +306 行）**：① `UserByEmail` 只解析 live 账号（覆盖 email/passkey 邮箱优先/op-login/auth options 全部前置门）；② `SessionUser` 同样过滤（皮带：任何门铸出的死号会话都立即失效）；③ `RedeemPlayerBindCode` 两个解析臂拒绝死账号（新哨兵 `ErrPlayerAccountRetired` → 403 `account_retired`，**不消费码**，可逆重试）；④ `DeleteUser` 事务内 `DELETE webauthn_credentials` + `account_links`（凭证与 `UNIQUE(mc_uuid)` 占用不再外泄）；⑤ discoverable passkey resolve 补 liveness 检查。单测 `TestDeadAccountsCannotLogInOrKeepSessions` + pgint `TestDeadAccountsAreLockedOutInPG`（含"删后新铸会话不验证"与资产清点）。
|
||
- **绿证据（auditfix28，真机）**：红期为死号铸出的会话 → **401**（皮带生效）；死号 `start=202` 中立且 **90s 日志窗口 0 条码**、`verify=400 invalid_code`；禁用中 `start` 中立（日志码数 1→1 不变）→ `verify=400`；**恢复启用后 `verify=200` + `/me=200`（可逆）**；bind 门死账号 → **403 `account_retired`** 且码保留 `count=1`（retryable）；删号后 `account_links`/`webauthn_credentials` 行数 = 0。
|
||
- **演习清理**：红演练遗留（2 个测试账号的 quotas 行、1 条旧链接、2 条死号会话）已清除；`/fleet` 与 panel 冒烟保持 200。
|
||
|
||
### 本轮新增真机证据（第十五批：#34 死账号同族收尾 —— in-game 身份解析与链接接管，auditfix29）
|
||
|
||
- **发现路径**：#33 修完 Web 登录门后做同族复查——**in-game 面是 UUID 驱动、不走 Web 会话，因此 #33 的会话皮带盖不住它**。两处：① `UserByMCUUID`（claim / menu / wake 授权 / op-login vouch / QR link-status 五处共享解析）直接读 `account_links`、不过滤 users 的 liveness；② `VerifyLinkCode` 对「holder 已死」的接管语义未定义——一刀切 409 会把迁移退役这类真实场景锁死。
|
||
- **修复（`bb9798e`，5 文件 / +182−7）**：① `UserByMCUUID` JOIN users 过滤 `disabled`+`deleted_at`——死账号的链接在游戏面**读作未链接**（claim 412、wake 落回 policy 门、vouch 403、status `linked:false`），绝不作为遗留身份存活；② `VerifyLinkCode`：**软删** holder 的链接可由新账号凭新 mint 码**接管**（账号已亡，码证明调用者仍持有该 UUID），**禁用** holder 仍 409（接管= 绕过锁死，不允许）、任何失败都不消费码。fake 单测 `TestLinkVerifyTakesOverDeletedLinkOnly`；pgint `TestVerifyLinkCodeTakesOverDeletedLink` + `TestDeadAccountsAreLockedOutInPG` 增「禁用链接无资格 / 复启用恢复」断言。
|
||
- **绿证据（auditfix29 真机，三面六点）**：
|
||
1. `link/status`：活 `{"linked":true}` → 禁用 `{"linked":false}` → 恢复 `{"linked":true}`；
|
||
2. `claim`：活链 404（身份已解析、ghost 服不存在）→ 禁用 **412 not_linked** → 恢复 404；未知 UUID 对照 412；
|
||
3. **接管正例**：临时软删 holder（`de49df52`）→ 新 mint 码 `X3G3RZZM` 由 player.test verify → **200 linked:true**；链接行迁移到 player.test（`auth_source=mojang`）、码被消费（`account_link_codes` 0 行）；演练后 holder 与链接全部还原；
|
||
4. **接管负例**：临时禁用 holder（user2）→ 新码 `X5W94S42` verify → **409 already_linked**；同码重试仍 409（**不消费**）；恢复启用后**同码**由 holder verify → **200**（码保留、可逆）；
|
||
5. **wake 授权**：活 owner **202**（真实启动）→ 禁用 **403 forbidden** → 恢复 **202**；test-one 已停回 Stopped 且所有权释放；
|
||
6. **op-login vouch**：禁用 owner UUID → **403 not_admin**（与未链接/非 staff 同一个拒绝面）；活 owner UUID → 404 op_login_not_found（vouch 已解析、只是请求不存在）。
|
||
- **环境刷新（部署态）**：热升级遗留 `FELIS_IMAGE=felis:auditfix16`（job 侧执行器 backup/restore/fileedit/forwarding-init 引用的镜像）→ 已 `set env` api/operator 双 Deployment 至 `felis:auditfix29` 并滚动完成；api/operator/reaper 三镜像一致 = auditfix29；port-forward 重启后内部面绿；panel 200、op 面 `/me` 200。
|
||
- **运维备注**：`account_link_codes` 会积累过期行（"失败不消费"的另一面），巡检顺手 `DELETE FROM account_link_codes WHERE expires_at < now()`。
|
||
|
||
### 本轮新增真机证据（第十六批：内部面残面地毯补测 —— ready / join-event / status / reclaim / blacklist / backup 负例）
|
||
|
||
- **背景**：对内部面做覆盖盘点后发现五个端点此前无真机证据：`ready`、`join-event`、`status`、`player/reclaim`、`player/blacklist`，以及 `internal/servers/{name}/backup` 的负例臂。本批全部补测（auditfix29），**0 新缺陷**。
|
||
- **`ready`**：test-one → **204**（advisory 语义）；坏名 → 400。
|
||
- **`join-event`**（临时 UUID `3333…`）：首次 **204**、重复 **204**（幂等）；DB 实锤：`test-one.last_active_at` 15:02→05:53（重置）、`server_allowlist` 恰 1 行；缺 uuid → 400；未知服 → 404。演习后 allowlist 行删除、`last_active_at` 复原。
|
||
- **`status`**：test-one → 200 全字段（phase/desiredState/endpointMode=fallback/…）；未知服 → 404。
|
||
- **`player/reclaim`**：新建（临时 UUID `4444…`）→ 200 `hold_expires_at`=+30d；**幂等重试返回同一时间戳**（首窗保留，与存储行 21:53:51.726017Z 完全一致）；缺字段 → 400；**protected-admin 负例**：临时插 owner↔thirdparty 链接 → **409 protected_admin**（不 bar、不 stash）。清理后 `username_blacklist`/`player_data_holds`/`server_allowlist`/临时链接 = 0/0/0/0。
|
||
- **`player/blacklist`**：bar 后命中 `{"blacklisted":true}`；陌生 UUID → `false`。
|
||
- **`internal backup` 负例**：未知服 → 404；坏名 → 400；保留名（login）→ 400 `bad_name`（在入队前拒绝，RWO 闸门单测已覆盖）。
|
||
- **探针**：`/healthz` 200、`/readyz` `{"status":"ready"}`。
|
||
|
||
### 本轮新增真机证据（第十七批：hasJoined 多源会话校验器 —— 假 Yggdrasil 全链路 + 三方身份重写/改名）
|
||
|
||
- **背景**：`hasJoined`（velocity 指向的 vanilla sessionserver 协议面，`handleHasJoined`）此前零真机覆盖。本批用「VM 主机假 Yggdrasil + 临时将 `[[auth_source]]` 换向」的方式把正/负路径全部打通。
|
||
- **装置**：主机 python 假源（`:18099`，按 username 分流 `ftok`/`ftnotch`/`ftbadname`/`ftdown`/其余 204）；`felis-config` 的 littleskin 源临时改指 `http://10.42.0.1:18099/fake`（tag=`faketest`/prefix=`FT`），api 滚动后逐项打靶。**演练后配置已还原 littleskin、装置已清理**。
|
||
- **结果（全绿，0 缺陷）**：
|
||
1. **三方身份重写**：`ftok` → 200 `{"id":"74409c3bbae93acabd2176e517b4f2a0",…}`，与本地按 `uuid.NewMD5(felisAuthNS, "faketest:native-123")` 的预算值**逐位一致**；
|
||
2. **保费名冲突改名**：`ftnotch` → `47c5527a18b03fe5a49ec50c11154dcd` + `name="FT_Notch"`（Mojang 实查 Notch=200 premium）；`ftok` 的 `FtPlayer` 恰也是真实 Mojang 名（`640c1672…`）→ `FT_FtPlayer`，改名按设计触发（非保费名保持原名）；
|
||
3. **敌意插件名拒绝**：假源返回 `§4admin` → **204**（不落 proxy 玩家列表）；
|
||
4. **源故障不静默**：假源 500 → **503**（velocity 报 auth servers down），对照未知玩家 → 204；
|
||
5. **形状负例**：缺参 / 超长参 → 204；声明 body → **400 + `Connection: close`**（防 drain 挂连接）。
|
||
- **顺带覆盖**：`isPremiumName` 的 Mojang 实查（`api.mojang.com`，超时/错误 fail-closed=改名）——404→非保费、200→保费判别实测成立。
|
||
|
||
### 本轮新增真机证据（第十八批：缺陷 #35 —— world 执行器 uid 1000 读不了游戏服写的世界 + 面板备份模块补全）
|
||
|
||
- **发现路径**：给备份页新增「立即备份 + 最近操作」后做第一次真机 drill——面板链路全对（按钮/成功消息/运行态→终态、零坏请求），**但 backup Job 真的失败了**：`Job has reached the specified backoff limit`，pod 日志 `felis backup: archive: backup: tar walk: open /world/world/level.dat: permission denied`。
|
||
- **根因（缺陷 #35，跨模块）**：世界卷的属主是**游戏镜像自己的 UID**（我们发布的 Paper 镜像都是 root），而 Paper 保存 `level.dat` 用的是 **0600**（Files.createTempFile 默认权限）→ 固定 uid 1000 的 **backup / restore / fileedit / reaper** 四类执行器：读不了（归档 `permission denied`）、也覆盖不了（restore 写不进 600-root 的 level.dat）。此前 drill 侥幸全绿，是因为当时的世界文件由 uid-1000 工具（restore/夹具）写的；**服务器真实启动保存过一次之后**，所有备份从此必死。测试全部是 shape 断言（无集群），这条只能真机抓。
|
||
- **修复（`2010961`）**：四类执行器统一改**以 root 运行**（`runAsNonRoot:false`，省略 fsGroup 防误 chgrp），容器保持除 `DAC_OVERRIDE` 外 drop-ALL——与 operator `init-forwarding` 容器的既定先例同源（"只有 root 能可靠读写这些文件"）；DAC_OVERRIDE 兜住"游戏镜像是非 root UID"的任意镜像场景。四份 shape 测试同步改断言。troubleshooting §10「Permissions」段落重写（uid-1000 + setfacl 时代结束）。
|
||
- **绿证据（auditfix31，真机四联 drill）**：
|
||
1. **backup**（面板 CDP 实操，红→绿同场景）：点击「立即备份」→ `进行中` → **`成功`**（同页面 reload 后仍在）；Job pod `runAsUser:0` + DAC_OVERRIDE；新归档 `test-one-1790115428472416736.tar.gz` 实测含 `world/level.dat`（471B）与 server.properties，共 499 条。
|
||
2. **restore**：`POST restore-backup`（bk-9df0…）→ 202 → Job **Succeeded**（root 写路径过关），日志 `restored from … into /world`。
|
||
3. **fileedit**：`GET /servers/test-one/file?path=world/level.dat` → **200**（base64-gzip 内容 628B）——修复前该请求必然 permission denied。
|
||
4. **reaper**（从 live CronJob 派生一次性 Job + 复刻钻取世界：1Gi PV/PVC + `world/level.dat` 512B **0600 root** + marker + 20d idle 行）：pod **root+DAC_OVERRIDE**；`world reaped server=reapdrill2 …`、`evaluated=3 reaped=1`；归档 711B 含 marker 与 level.dat；PVC 删除；`world_backups` 得 `inactive_15d` 行；servers 行/CRD 保留（红线②）。**钻取现场全部清理**（job/CRD/行/PV/宿主目录/临时归档）。
|
||
- **面板补全（`97a64c8`）**：备份页新增「立即备份」（仅 Stopped 可用，409 原文呈现）与「最近操作」卡（GET `/servers/{name}/jobs`，running 每 5s 自刷新，failed 显示 Job 失败文本——正是它把上面这次失败暴露出来的）。面板 113 单测 + typecheck 全绿。
|
||
- **部署注意**：backup/restore/fileedit 的 Job spec 是 api **运行时渲染**，随镜像即生效；**reaper CronJob 的 pod 模板是安装期静态渲染**——本轮已按新形状热补丁 live 对象（root + DAC_OVERRIDE），`felis install/setup` 重渲染时收敛。
|
||
|
||
### 本轮新增真机证据（第十九批：面板补齐 owner 解绑通行密钥入口）
|
||
|
||
- **背景**：`DELETE /users/{id}/passkeys`（owner-tier 凭据补救：密钥丢失/被盗时切断登录脚架，且不锁死账号——邮箱码/游戏内审批仍可用）后端早已实现并审计，但面板无入口，owner 只能靠 API。属"功能缺口"而非缺陷。
|
||
- **修复（`11ac4f5`）**：用户详情页危险操作区新增「解绑通行密钥」行 + 确认对话框（`api.unbindUserPasskeys` 客户端方法 + 双语 i18n + wire-shape 测试）。
|
||
- **绿证据（auditfix32，CDP 真机全链）**：player.test 注册虚拟认证器密钥 `E2E-Unbind` → `/auth/options` 从 `["email_otp"]` 变为 `["passkey","email_otp"]` → owner 在 `/admin/users/<id>` 点「解绑通行密钥」→ 对话框 → 确认 → **凭据列表清空、options 回落 `["email_otp"]`**（passkey 门确实关闭）；审计 `user.unbind_passkeys` 落账（同批还可见 `account.passkey.registered`/`backup.create`/`backup.restore`/`reap_world` 各审计行）。面板 114 单测全绿。
|
||
|
||
## 结论：离"生产可用"还差什么（按优先级）
|
||
|
||
1. ~~构建链路的上下文通道~~ ✅ **已修**（`f79e5eb`/`02fd2de`，真机全链路含拉回校验；Trivy DB 需按 §8e 镜像一次）。
|
||
2. **镜像耐久**：kubelet 仍可能 GC 掉"当前无人使用"的镜像（游戏镜像已实测发生）。把控制面与游戏镜像推入内建 registry 并让 Deployment/StatefulSet 引用 registry 路径，可免去"事故后人工重导入"。本轮已用 runbook（troubleshooting §13b）兜住。
|
||
3. ~~PG 级契约测试~~ ✅ **已落地**（`2a55a0d`）：`internal/pgint`（`-tags pgint`，需 `FELIS_TEST_PG_URL` 指向名字含 `pgint` 的库，harness 会 drop schema + 重放真实迁移）已覆盖会话/OTP/op-login/绑定码/submission/build/owner 角色；**首跑即抓到 #20**（索引与 ErrEmailTaken 从未存在）。运行方式见 CONTRIBUTING.md。
|
||
4. **面板把 /jobs 显示出来**：API 已有出口（#7），`ServerBackups` 页加一块"最近操作"即可让普通用户看见失败原因。
|
||
5. **多节点回收**：reaper CronJob 无 nodeSelector，多节点需按卷所在节点加 selector（代码与文档均已标注，未实现调度约束）。
|
||
6. **告警**：felis_* 指标已全有生产者，但无非告警；磁盘/内存阈值告警建议随部署一并给出。
|
||
7. **玩家可见的构建结果（新发现）**：构建失败目前只有 admin 路由（`/images/build/{id}`）能看到；`/me/submissions` 只回 `approved`，玩家看不到 failed/succeeded。建议在 submission 视图附上 `build_status`（或在面板里链到构建详情）。
|
||
|
||
## 系统性观察
|
||
|
||
- **PGRepo 与接口契约/fake 漂移**（#16/#17/#18）：`fakeRepo` 与接口注释是对的、PG 实现在细节上落后，单测全绿也发现不了。建议后续引入 PG 级契约测试（testcontainers 或针对关键写路径的集成测试），重点覆盖「接口注释承诺了字段/错误码/生命周期」的方法。
|
||
- 部署知识：交叉编译必须先把 `panel/dist` 拷进 `internal/panel/static` 再 `go build`，否则镜像内 SPA 缺失（页面显示 “assets were not built”）。本批镜像为 `felis:auditfix7`。
|
||
|
||
## 复现入口速查
|
||
|
||
- 面板会话 cookie：`/tmp/felis-cookies.json`；API 助手：`/tmp/fcurl.sh`
|
||
- 测试服：`test-one`（minecraft ns，stopped）；合法备份 `bk-47ee2e7e96e5a4ca9d0e51b805518bac`
|
||
- CDP 调试口：Mac `127.0.0.1:9333`（独立 Chrome，profile `/tmp/felis-chrome2`）；WebAuthn 虚拟认证器需在**同一 CDP 会话**内完成仪式，且先 `Page.bringToFront`（否则 NotAllowedError: page does not have focus）
|
||
- 已部署到 VM：`felis-api`/`felis-operator`/`felis-reaper`(CronJob) 镜像 = `felis:auditfix32`（含 #20–#35 全部修复；job 侧执行器镜像 `FELIS_IMAGE` 已同步；**world 执行器以 root+DAC_OVERRIDE 运行**，reaper CronJob 模板已热补丁为新形状；迁移 0020 已应用，`schema_migrations` max=20；CronJob 仍 `suspend=true`，SMTP 密码 env 待 `felis setup`「configure email」刷新时落地；operator Role 已手动补 `minecraftservers:patch`，`felis install/setup` 重渲染时收敛）
|
||
- 构建链路 drill 现成条件：`felis-build` 里有 `felis-service-token`（Secret 复制）；`felis-config` 里 `kaniko_image/trivy_image` 指向 k3s containerd 已导入的 pin tag、`trivy_db_repository = registry.felis.svc:5000/mirror/trivy-db:2`（镜像配方 §8e；VM 上 docker daemon 的 `insecure-registries` 已含 registry ClusterIP）
|
||
- VM 内部面：`k3s kubectl -n felis port-forward svc/felis-api-internal 18081:8081`（Pod 重建后转发会悬死，需重启）；reaper CronJob（minecraft ns）已应用但 `suspend=true`
|