Jyotisha/BLOCKED.md

BLOCKED

• 真实收信端到端验收：执行环境没有可识别的 staging 测试邮箱/收件箱变量，仓库只记录发信配置而未提供受控测试邮箱。按任务硬规则不使用他人邮箱；代码、测试和部署继续，部署后的注册、验证码登录与忘记密码真实收信步骤待具备受控邮箱后补验。
• PostgreSQL 事务反向测试：当前执行环境没有 docker、postgres、initdb、psql、Podman/Colima/Lima。frontend/tests/admin-database.test.ts 已实现审计触发器故意失败并断言兑换码行数仍为 0 的红灯证据，但本地执行在启动 fixture 前以 spawnSync docker ENOENT 阻塞；交由 exact-SHA staging quality gate 的 Docker 环境运行。全量 npm test 因同一缺失 Docker 共阻塞 11 项数据库/部署测试，另有 1 项既有真实 DOM 测试因缺 Playwright headless Chromium 阻塞；其余 1031 项通过，skipped/todo=0。
• staging 两角色浏览器冒烟：已确认受控 admin 测试账号存在且是 user,admin，但当前执行环境没有其密码或已登录会话；也未提供受控 viewer 账号。不得读取/猜测凭据或使用他人账号。已完成匿名 shell、5 个资源 401、写请求 401 的服务端冒烟；admin/viewer 登录后浏览器冒烟待授权人员提供受控会话后补验。

React Compiler 接管 page.tsx（2026-08-17，分支 codex/react-compiler-20260817）

• Home 的编译失败原因无法定位，需要授权新增依赖。 Next 16.3.1 的 Rust 版 React Compiler 拒编 page.tsx 的 Home（2730 行），且不报任何错误或警告。panicThreshold: "all_errors" 在 Rust 版下形同虚设（试过两次，构建既不报错也不打印诊断），因此拿不到「哪一行挡住了编译器」。唯一能出诊断的路是换 Babel 版（experimental.turbopackRustReactCompiler: false），但它需要新增依赖 babel-plugin-react-compiler（next 的可选 peer，未装；Next 只内置了 compiler runtime，没内置这个 plugin），撞任务书「不新增依赖」，故未做。想继续定位需要授权装这个依赖，或等上游 Rust 版补上诊断输出。
• Home 要真正受益很可能得拆组件，属业务代码重构，本轮明令禁止。 证据是同一文件里两个小组件（原始行 760、815）被正常编译、全项目另有 44 个函数被编译，唯独这个 2730 行、24 个 useState、18 个 useEffect 的函数被拒。任务书要求「哪处代码挡住了编译器就写进 BLOCKED.md，不要自行改写」，故 frontend/src/** 一行业务代码未动（仅反向验证时临时加删一行 "use no memo"，已还原，git diff 为空）。
• 待决策 已决策（2026-08-17）：维持回滚，不为那 44 个组件保留 reactCompiler: true；若要翻案，前置条件是先测出那 44 个的渲染基准。 本轮按任务 2 止损条款已回滚该配置。数据是：构建耗时无可测量变化（噪声内），/ 首屏 JS gzip +12031 B / +2.50 %，换来 44 个函数自动记忆化，其中 app-sidebar（112 槽）、sidebar-session-row（73 槽）、birth-date-picker（58 槽）与三个引导 hook 都在 / 上渲染。这 44 个的实际运行时收益本轮未测量（无渲染基准），所以不替决策者拍板。重新开启只需在 frontend/next.config.ts 顶层加 reactCompiler: true、experimental 里加 turbopackRustReactCompiler: true。
• compilationMode: "all" 不可用，会破坏构建。 它会编译模块作用域的普通回调，frontend/src/components/birth-time-intake.tsx:22 的 Array.from({ length: 24 }, (_, index) => ...) 被插入 useMemoCache，预渲染 / 时抛 TypeError: Cannot read properties of null (reading 'useMemoCache')。这是该模式本身的性质（官方标注为不安全），不是本仓库代码的缺陷，未做任何改动。
• 顺手活一律未做，登记在此： 其一，frontend/src/lib/skill-package-registry.ts:523 的 readFileSync(currentRegistryPath, "utf8") 触发 Turbopack 构建警告「Dynamic filesystem access causes tracing of the whole project」，会把整个项目（含 public/）打进 server 产物，影响部署体积；升级前后都存在，与本轮无关，未改。其二，npx eslint 有 4 个既有 no-unused-vars warning，分别在 birth-time-candidate-result.tsx:143、birth-time-candidate-completion.ts:10,11、tests/identity-auth-factory.test.ts:48，未改。其三，eslint-config-next 仍是 16.2.10、与 next 16.3.1 版本号不同步，但 eslint 实测 0 error，按「不许顺手升别的依赖」未动。
• 测试环境噪声（非阻塞，已自行消化）： frontend/tests/rectification-v9-database.test.ts 的「v9 migration applies on a fresh database and re-applies idempotently」在全量并发下偶发失败（database migration failed，1 !== 0），单独重跑 7/7 通过、全量重跑 1592/1592 通过。靠 Docker 起临时 Postgres，判定为资源争用型 flake，与 Next 版本无关。未改任何测试文件。
• 文件名偏离： 任务书要求新建 PROGRESS.md，但根目录已有受版本控制的 progress.md（1025 行）且本机文件系统大小写不敏感，写 PROGRESS.md 等于覆盖清单外的文件，故进度记录落在 PROGRESS-react-compiler-20260817.md。