Jyotisha/BLOCKED.md

BLOCKED

客户端交互收尾（2026-08-30，分支 codex/interaction-20260830）

• .message-actions button 不能做到 44×44。 四个 26×26 按钮，gap: 1px，中心距 27px；下方 follow-up 芯片只有 8px 底边距。44×44 伪元素会水平重叠 17px，并在有 follow-up 时垂直吃掉 1px 点击。热区做到不重叠的最大值 27×34（水平吃掉 1px 缝，垂直用掉 4px 底边距）。距 44×44 还差 17px 宽、10px 高。把 gap 拉到 18px 才能水平到 44，但那会改变视觉留白，本轮红线禁止。

• .chart-nav-chip 与 .auth-links button 停在 40px。 两者视觉高度 32px，容器 gap: 8px（chip 还会换行）。inset: -4px 把热区扩到 40px，刚好填满间距、互不重叠。再扩 4px 就会在换行后上下吃点击。距 44px 还差 4px。

• 以上两处都写进 frontend/tests/touch-target-contract.test.ts，禁止在间距不变时把伪元素硬撑到 44px。

• 登录页当前关密码通道，.auth-links 不渲染。 热区用夹具 + 注入节点量的。产品登录是 OTP，「发送验证码」已是 44px。

• 主对话计数 / 引导框中文 IME 实机未录。 无受控登录会话，headless Chrome 无输入法。四处计数与三处 isComposing 由合同测试锁定。

• 真实收信端到端验收：执行环境没有可识别的 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 登录后浏览器冒烟待授权人员提供受控会话后补验。

前端优化九条（2026-08-29，分支 codex/frontend-optimization-20260828）

• web/index.html、web/rectification.html、web/evidence_packet.html 不得按“无人引用”删除。 scripts/jyotish_api_server.py 仍把它们当作 /、/evidence、/rectification 的调试页；tests/test_api_async_job_contract.py 锁路径。任务书全仓检索漏了 Python API。移到 scripts/ 必须改 tests/** 既有断言，本轮禁止。它们不是产品 UI，继续留在 web/。
• admin 已登录目视（/admin/users|orders|roles|feature-flags）未做。 执行环境没有受控后台会话，与上方 staging 两角色冒烟同一缺口。本轮用 next build 客户端 CSS 清单代替：上述四页不再包含 globals（message-list）那 33.7 KB gzip，只剩 admin.css 1.8 KB + Inter @font-face 0.8 KB = 2.5 KB。登录后的视觉塌陷仍需人补一眼。
• error.tsx / not-found.tsx 不能 import site-styles。 它们挂在根布局段，import globals 会把聊天 CSS 重新打进每一条 admin 路由。样式用内联 style + fallback 色值（与 global-error.tsx 同一模式），不必另开布局链，也不必移动 app/page.tsx。见 2026-08-29 收尾与 BUG-433。
• React Compiler 仍关闭，见下方 2026-08-17 记录。本轮未重开。

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

• Home 的编译失败原因无法定位 已解除并已定位（2026-08-17，用户授权新增依赖后完成）。 结论：Home 的失败全部来自上游编译器未实现的语法与内部断言失败，没有一条是本仓库代码写错。稳定版 babel-plugin-react-compiler@1.0.0 报 24 条错误、三类全带 Todo:（编译器标记「尚未实现」）：13 条 try/finally、9 条 try/catch 内的 throw、2 条 MemberExpression cannot be safely reordered。更新的 experimental 版已修好前两类，Home 随即撞上两个连续的编译器内部断言失败（Invariant:，即编译器 bug）：page.tsx:2666 的 catch (error) 绑定被闭包捕获，以及 page.tsx:1837 的提升函数 refreshAccount。诊断用的依赖已卸载、锁文件已用 npm ci 权威还原、git diff 为空，不进交付——因为它买不到任何东西，见下一条。
• 换编译器版本或换 Babel 版实现，对本仓库零增益（已量化，这条路可以关掉了）。 对 frontend/src 全部 373 个文件跑批量诊断：稳定版 1.0.0 与 experimental 版编译成功的函数数完全相同，都是 134 个，失败文件都是同样 21 个，仅报错事件从 74 降到 48。原因是被上游修掉的错误类别，所在函数都还有别的拦路错误，于是一个函数都没多编译出来。所以别再指望「升个编译器版本就好了」。
• Home 要真正受益很可能得拆组件，属业务代码重构，本轮明令禁止。 诊断结果进一步说明这条路该怎么走：为迎合编译器去改 Home（删 finally、重排 6 个被声明前引用的函数、逐个绕内部断言）是被编译器 bug 牵着走的打地鼠，每步都拿确定的正确性换不确定的收益；值得做的是按职责把 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。

生时校正收敛重构任务 0（2026-08-31，分支 codex/rectification-convergence-impl-20260830）

• 无法获取任务书要求的上游 interview_playbook.md、evidence_thresholds.md：任务书所指的 ~/.workbuddy/skills/jyotish-birth-time-rectification/ 在当前执行环境不存在，仓库内只有测试对该外部路径的引用；未伪造文件，也没有可验证的上游来源可供导入。
• 无法获取一次真实本地校正会话完整记录：当前仓库没有可证明为真实线上会话的完整原始记录，执行环境也没有受控会话/上游维护者提供的记录。因此无法可靠回答轮数、最终区间宽度、confidence 与 can_apply。
• 该信息收集缺口不阻塞任务 1–3，按 v2 任务书继续实现并在进度文件中标记为未验证；不得据此声称已验证“固定题数后停止”的上游机制。