docs: record why React Compiler cannot take over page.tsx Home

The Rust React Compiler in Next 16.3.1 refuses to compile the 2730-line
Home component in frontend/src/app/page.tsx and reports nothing at all:
the build prints the option as enabled, exits 0, and tests stay green
while zero memoization is applied. Six configurations were tried; the
compiler optimized 44 functions elsewhere (including 2 smaller ones in
page.tsx itself) but never Home, and panicThreshold: "all_errors" is a
no-op on the Rust port, so the failing construct could not be located.

The reactCompiler config is therefore rolled back per the task's
stop-loss clause while the Next 16.3.1 upgrade is kept. BUG-255 records
the silent-bailout trap so a future attempt does not mistake "option
enabled and build green" for "compiler actually working". BLOCKED.md
records the two paths out, both of which need authorization: adding
babel-plugin-react-compiler to get diagnostics, or splitting Home.

No business code, test, or CI file was touched.

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/BUG_HISTORY.md

@@ -3831,4 +3831,18 @@
 - 待跟进：run 2（问题“请综合说明我当前最值得关注的主题”的那次 `calculation_failed`）不由本机制解释——该文本不含任何领域关键词，每个领域都会回落到自己的 `themes` 并对上，本轮未能找到独立证据说明它为何失败，不认领。同一问题文本的一次失败已在 BUG-257 记为领域数乘单领域耗时超出时钟预算，但本轮没有该次运行的领域数与耗时证据可核对，因此既不视为已解释也不视为复发。另记：领域循环里任一领域抛出即让整次工具调用失败，BUG-257 已有 `omitted_domains` 这条降级披露通道，把单领域失败也接入该通道属独立改动，本轮未做——本次修复消除的是那个确定性的失败源。
 - 防复发：同一个决定必须只有一个权威来源。凡服务端自己签发的受控元数据已经声明了执行参数，就不得再由请求文本的启发式重新推导一遍并要求两者相等——这类“契约允许了服务端不接受的东西”的自伤矛盾在 fail-closed 门禁下必然表现为确定性 400。文本关键词只能作为没有声明时的兜底，且必须在返回值里标明本次由哪套规则决定。为了让文本路由同意声明路由而改写用户问题（如注入关键词前缀）不是修复而是绕行：它只覆盖被打补丁的那一个领域，还会污染模型据以作答的输入，一旦声明路由成为权威必须删除。凡是“一次运行对同一文本发出多次不同领域调用”的形态，测试必须带上产品真实发送的计划元数据并逐领域断言执行路由等于声明领域，否则测试会用一段刚好自洽的文本掩盖矛盾（本 bug 正是如此漏过）。
 - 相关记录：BUG-257、BUG-256、BUG-255
+
+## BUG-260 | React Compiler 无法接管 `page.tsx` 的 `Home`：编译器静默拒编 2730 行组件且不报任何错
+
+- 状态：won't fix（本轮不修；Next 已升到 16.3.1 并保留，编译器配置已回滚，原因见下）
+- 首次发现：2026-08-17
+- 最近更新：2026-08-17
+- 影响面：`/` 主对话页 `frontend/src/app/page.tsx` 的重渲染性能，以及后续任何「靠 React Compiler 免除手写记忆化」的计划。
+- 用户现象：无终端用户可见现象。对维护者而言的现象是：`next.config.ts` 里 `reactCompiler: true` 开启后构建打印 `✓ turbopackRustReactCompiler`、退出码 0、测试全绿，**看起来完全成功**，但 `Home` 一个函数都没被优化。这个失败不产生任何警告、错误或日志，只看构建输出无法察觉。
+- 根因：`page.tsx` 有 3738 行，其中 `export default function Home()` 单个函数占 2730 行（1002–3738），带 24 个 `useState`、18 个 `useEffect`、0 个手写 `useCallback`/`useMemo`。Next 16.3.1 的 Rust 版 React Compiler 会正常编译同一文件里的其他函数，却拒编 `Home`：默认 `infer` 模式下全项目 44 个函数拿到缓存槽（`app-sidebar` 112 槽、`use-birth-time-guided-journey` 84 槽、`sidebar-session-row` 73 槽等），`page.tsx` 内部两个小组件（原始行 760、815）也拿到了 11 和 24 槽，唯独 `Home` 的生成代码仍以裸 `useState` 序列开头、没有 `_c(N)` 前导。把 `compilationMode` 设为 `all`（绕过组件识别启发式、强制编译每个函数）后 `page.tsx` 被编译函数从 2 涨到 47，`Home` 依然不在其中——既然 `all` 模式下不存在「未被识别为组件」，只剩一种解释：编译器尝试了 `Home` 并失败，然后按 `panicThreshold` 默认值 `none`（官方文档原话 "skips components which cannot be compiled"）静默跳过。具体是 `Home` 哪一处代码触发失败，本轮**未能定位**：`panicThreshold: "all_errors"` 在 Rust 版下形同虚设，设了也不报错、不打印任何编译器诊断。
+- 修复：未修复。`next.config.ts` 的 `reactCompiler: true` 与 `experimental.turbopackRustReactCompiler: true` 已回滚到与 `origin/staging` 逐字节一致；Next 16.2.10 → 16.3.1 的升级保留（该升级本身独立验证通过，是 Rust 版编译器的前置条件）。本轮共试六种配置全部失败：`reactCompiler: true`、加 `panicThreshold: "all_errors"`、再加文件顶部 `"use memo"`、`compilationMode: "all"`、`"all"` + `all_errors`、`compilationMode: "annotation"` + `Home` 体内 `"use memo"`。其中 `compilationMode: "all"` 还会直接把构建搞坏：它会编译模块作用域的普通回调，`birth-time-intake.tsx:22` 的 `Array.from({length:24}, (_, index) => ...)` 被插入 `useMemoCache`，预渲染 `/` 时抛 `TypeError: Cannot read properties of null (reading 'useMemoCache')`。注解模式（领导指定的退路）反而最差：全项目 0 个缓存槽，连原本能编的 44 个也停了。
+- 验证：`npx tsc --noEmit` 无输出；`npx eslint` 0 error（4 个既有 warning 在未改动文件里）；`npx next build` 退出码 0；非数据库套件 199 个文件 1592 条全绿、fail 0 skipped 0 todo 0（与开工基线一致）。取证方式：`Home` 在产物里被压缩改名，`function Home(` 搜不到，改用 source map 反查——解 `.next/server/chunks/ssr/*.js.map` 的 VLQ mappings，把每个缓存槽 `_c(N)`（压缩后真实形态是 `(0,X.c)(N)`）归属回原始文件与行号。反向验证：只加/删 `page.tsx` 顶部一行 `"use no memo"`，`page.tsx` 被编译函数数在 2 与 0 之间可见切换，且切换只影响 `page.tsx`、其他文件槽数不变，证明取证方法不是恒为真；两种状态下都判定 `Home` 未编译。构建代价（各测 4 次取最快，同机噪声大）：开启前 36.65s / 关闭后 35.11s，差异落在噪声内，Rust 版没有可测量的构建变慢；`/` 首屏 JS gzip 470.1 KB → 481.9 KB，+12031 B / +2.50%，低于 5% 阈值。
+- 待跟进：其一，定位 `Home` 里究竟哪一处挡住编译器，需要能出诊断的编译器；Rust 版不出诊断，Babel 版（`turbopackRustReactCompiler: false`）能出，但要新增依赖 `babel-plugin-react-compiler`（next 的可选 peer，未装；Next 只内置了 compiler runtime，没内置这个 plugin），需授权。其二，是否为了那 44 个能编的组件而保留 `reactCompiler: true`：它们大多在 `/` 上渲染（侧边栏、会话行、日期选择器、三个引导 hook），收益真实但本轮未测量，代价是首屏 +2.5%；本轮按止损条款选择回滚，这个取舍留给决策。其三，若要让 `Home` 真正受益，最可能的路是把它拆成若干个小组件——但那是业务代码重构，本轮明令禁止碰 `frontend/src/**`。
+- 防复发：**「配置开启 + 构建绿」绝不等于「React Compiler 生效」**。编译器放弃某个组件时不报错、不警告、不留日志，这是它的默认行为（`panicThreshold: "none"`）而非缺陷。任何启用 React Compiler 的改动都必须在构建产物里定位目标组件、确认存在编译器注入的缓存槽，并用 `"use no memo"` 做一次反向验证证明取证方法会随编译状态变化；只贴构建退出码等于没验证。另外 `"use memo"` / `"use no memo"` 是函数体内的指令，写在文件顶部时 `"use no memo"` 可作整文件退出、但 `"use memo"` 不构成整文件加入。
+- 相关记录：BUG-260 无前序同类记录。本记录三次改号：初次写作取 255；第一次 rebase 到 `origin/staging`（`c8d9ec64`）时远端已占 254–255，改 256；第二次 rebase 到 `e1db5762` 时远端又占到 259，改 260。每次都按 BUG-254 的防复发要求处理——标题与远端各记录均不同，故另分新号而非合并。BUG-253 所记的抢号失效模式在同一轮交付里连续复现两次，暴露出「追加前检索最大编号」这条措施的边界：它只在写记录那一刻成立，防不住推送前远端继续前进。可靠做法是把定号推迟到推送前最后一次 rebase 之后。
 - 修复版本：本地未提交候选