# BLOCKED

## 对话额度拆分（2026-09-16，分支 `codex/consultation-session-capacity-20260915`，BUG-732）

- **无 Docker：** 本机 `docker` 不在 PATH。`npm run test:db` 与 `npm run db:migrate:check`（需要 `SCHEMA_DATABASE_URL` 连 Postgres）未跑。`frontend/tests/database-consultation-session-capacity.test.ts` 在无 Docker 时 skip，**不得写成通过**。替代证据是 SQL 静态合同：额度求和表达式不含 `thinkingText` / `thinkingSections`，物理上限为 `length(elem::text)`，算式写在迁移注释里。
- **详情接口体积（5.3，已量，不改接口）：** 用三域本命夹具（每轮正文 4,000 汉字 + 思考 4,000 汉字 + 实测 `thinkingSections` + 典型三个 receipt）构造 `GET /api/sessions/[id]` 的 `{ session }` JSON。19 轮 UTF-8 **562,240 B（0.536 MiB）**；50 轮 **1,479,034 B（1.411 MiB）**，约为 2.63 倍。1.4 MiB 在 2 vCPU 上打开长会话会偏沉，分页 / 按需加载历史不在本单（任务书 §9）。PostgreSQL `length()` 按字节计，汉字正文 4,000 字 ≈ 12,000 字节，线上按字节撞 200,000 额度会早于「50 轮汉字」；50 轮数字是任务书字符口径对照。

## 只读页验收修复：镜像与浏览器（2026-09-16，分支 `codex/readonly-pages-fix-20260916`）

- **无 Docker：** 无法验证 API 镜像里 `COPY vendor` 与容器内 `node --version`。不得写成通过。
- **无登录态 / 无 Chrome：** `/chart`、`/ephemeris` 浏览器走查仍留给 `docs/testing/`。
- **staging 部署：** 推送前 `/api/health` 的 `deployment.gitCommit` 仍可能停在 `2d7698ea`。本单修的是门禁红测试，部署是否追上以推送后的 health 为准，未追上不得写成已部署。

## 七政原生排盘：镜像构建与上游 checkout（2026-09-15，分支 `codex/qizheng-native-chart-20260915`）

- **无 Docker：** 本机 `docker` 不在 PATH。无法构建 `deploy/railway-api.Dockerfile`，也无法在容器内跑 `node --version` 或断言 `Path('/app/vendor/stem-branch/dist/cli.cjs').exists()`。**不得把镜像构建或容器内验证写成通过。** Dockerfile 已按任务加上 `nodejs` 运行时与 `COPY vendor ./vendor`，待有 Docker 的环境验证。
- **替代证据（宿主机）：** `node --version` = `v22.23.2`。vendored `dist/cli.cjs` 45,963 行 / 2,682,464 字节，与任务书 45,963 行 / 2.68 MB 一致。用任务书虚构资料 `1990-04-09T13:24:00+08:00 / 31.19N 121.44E` 实跑 `getSevenGovernorsChart`：11 曜、12 宫、命宫星宿·午宫、太阳宿度 177.94 奎 7.44°、相位 27、神煞 0。
- **上游以本机目录为准，不从 GitHub 拉，也不带同分支 `6c27aab6` / `8bba9cb5`。** `G:\Ferti\yinduzhanxing-codex-add-birth-time-rectification-skill` = 任务书 `/workspace/yinduzhanxing` @ `a911c890`。`vendor/stem-branch/{LICENSE,README.md,package.json,dist/cli.cjs}` 已与该目录逐字节核对（LICENSE Apache-2.0，Copyright 2026 Albert Hui）。先前从 npm 另凑的 `dist/index.cjs` 已删除，vendor 树与该快照一致。CLI 无 `ketuMode` 旗标，请求里的派别会回写，`engine_ketu_mode` 以 CLI 实际输出为准。
- **本机无仓库 `.venv` 目录：** 主仓 `.venv` 是指向 `/workspace/Jyotisha/.venv` 的 git symlink，Windows 检出为 25 字节指针文件。测试与预检使用 Anaconda Python 3.11.7（已有 `pytest` 与 `pyswisseph`）。`timezonefinder` 仍缺，与既有 BLOCKED 条目一致。

## 只读星盘页（2026-09-15，分支 `codex/chart-page-20260915`）

- **浏览器级走查未做：** 执行环境无登录态、无 Chrome。清单在 `docs/testing/chart-page-20260915.md`，不得标成通过。
- **无 Docker：** 未跑 `npm run test:db`。本单未动表。
- **`next build`：** 本 worktree 的 `frontend/node_modules` 是指向主仓的 junction。Turbopack 可能报 `Symlink ... points out of the filesystem root`。`/` 是否仍 Static 用 `next build --webpack` 核，不得把未跑的构建写成通过。

## ~~快速门 timezone 推断依赖~~（2026-09-15 解除：验收机已装 `timezonefinder 9.0.0`）

- **`run_quality_gate.py --profile quick` 必红一条，不是 BUG-693/694 的回归。** 验收机在 `1d2aeffa` 上 `739 passed, 1 failed`；同一条在修复前的 `039b0a26` 上同样红。
- 失败测试：`tests/test_api_server_security.py::test_shadbala_endpoint_returns_ranked_planet_strength`
- warning 原文：`WARNING [api_server] shadbala advanced layer failed: timezone inference dependency unavailable`
- 断言：`assert ['core_sixfold'] == ['core_sixfold', 'advanced_evidence']`（缺 `timezonefinder`，高级层没挂上）。
- **解除（2026-09-15 验收，`8d56d0ab`）：这不是缺口，是验收机少装了一个已声明的依赖。** `timezonefinder>=6.5` 在 `requirements.txt:6` 与 `pyproject.toml:31` 都写着，venv 里没有。按本单让步顺序第 2 条装上 `timezonefinder 9.0.0`（附带 `numpy` / `h3` / `flatbuffers`；全仓无任何 `import numpy`，不影响既有代码），该条测试立即通过，快速门 pytest 段 **740 passed, 1 skipped, 0 failed**（装之前 739 passed / 1 failed）。断言未改。
- 执行机（Windows / Anaconda）仍缺 `timezonefinder` 与 `mcp`，在那边跑快速门会先红在别处；以验收机数字为准。

解除命令（缺依赖的机器照做）：

```bash
.venv/bin/pip install "timezonefinder>=6.5"
.venv/bin/python -m pytest tests/test_api_server_security.py::test_shadbala_endpoint_returns_ranked_planet_strength
```

## 快速门整体仍非绿：`npm test` 的 27 条无 Docker 失败（2026-09-15 记）

- `run_quality_gate.py --profile quick` 的最后一步是 `npm test`。Python 段全绿之后，门仍 `exit=1`、日志尾 `== Quality gate failed ==`，卡在这里。
- 实测 `# tests 3214 / # pass 3173 / # fail 27 / # cancelled 0 / # skipped 14`，27 条**全部**是数据库、部署、Better Auth、迁移类用例（`database roles have no cluster privileges`、`migration runner is serialized…` 等），本机无 Docker。
- 因此本机「快速门通过」的口径是：**Python 段 0 失败，且 `npm test` 失败数 = 27（与基线逐条一致）**。不得据此宣称门全绿，也不得为了让门变绿去动这 27 条。

## 采集流程重设计（2026-09-10，分支 `codex/rectification-collection-redesign-20260910`）

- **`next build` / 首屏 gzip 未核。** 本 worktree 的 `frontend/node_modules` 是指向主仓的软链。实测 `npm run build` 在 Next 16.3.1 Turbopack 失败：`Symlink [project]/frontend/node_modules is invalid, it points out of the filesystem root`。不得把 `/` Static 或 gzip ±2% 写成通过。
- **浏览器级走查第 19～21 条未做：** 执行环境无登录态。清单在 `docs/testing/rectification-scenarios-20260907.md`。部署后须先打开绑定 Skill 10.0.22 的历史校正。
- **无 Docker：** 未跑 `npm run test:db`。本单未动表。

## 生时校正常驻时间轴（2026-09-09，分支 `codex/rectification-timeline-20260909`）

- **浏览器级验收全部未做：执行环境无登录态、无 Chrome。** 六节走查条目写进 `docs/testing/rectification-timeline-20260909.md`，未标记为通过。替代证据是 `frontend/tests/rectification-timeline-20260909.test.ts` 的 17 项（几何换算、二元编码、闭区间边界、跨午夜窗口、放宽后仍落在轴内、三处源码锁、CSS 合同）。
- **最需要真人确认的一条：贴底跟随。** 时间轴在滚动容器之外，高度固定是靠 CSS 与合同测试保证的；「贴底时新消息不会滑出视野下缘」只有真实滚动能确认。BUG-218/252 的教训正是纯源码合同测试固定不了几何。
- **时段阶段的区块未画（任务书 §6 让步 1）。** 区块边界在客户端只以显示字符串存在（`BLOCK_PERIOD_LABELS` 形如 `"清晨 04:00—07:59"`），没有结构化 `start/end` 下发；反解析展示文案太脆，未做。该阶段区间带铺满窗口、读数写窗口宽度。若日后要画区块，需要服务端把子段边界结构化下发——属于另立一单的响应新增字段。
- **桌面端时间轴与右侧板「换升时刻」是否重复，未判定。** 任务书决策记录第 7 条明确留给真人走查（清单 1.1），本轮未做取舍。

## 报告生成分章进度（2026-09-09，分支 `codex/report-progress-20260909`，BUG-601）

- **真实报告生成一次都没跑过：执行环境无登录态、无 Chrome、无模型凭据。** 因此"写作阶段真的会出现""章节名不错位""慢章节文案真的会切换"这三条**没有任何运行时证据**，只有纯函数测试与源码锁（`frontend/tests/personal-report-progress.test.ts` 16 项）。逐条走查清单见 `docs/testing/report-progress-20260909.md`，交给有真实账号的人。
- **分章行在生成中是否真的可读，未在真库上验证。** `personal_report_sections` 的 RLS 给了 `authenticated` 对自己行的 select，路由用的也是已认证客户端，逻辑上成立；但本机无 Docker/Postgres，`npm run test:db` 的相关套件（`database-personal-report-sections`）在基线就因缺 Docker 失败，本轮同样没跑。**若上线后等待屏始终停在准备阶段，第一嫌疑就是这里**——分章行读不到时代码会安静回落到准备态，不会报错。
- **`next build` 的 First Load JS 分路由数字取不到。** Next 16.3.1 的 Turbopack 构建输出只有路由表（`○ /` 已确认 Static），没有 Size / First Load 两列，`build-manifest.json` 也不含按路由的 CSS 清单。本轮改用可直接测量的口径：`/` 唯一受影响的产物是 `globals.css`，gzip 33,324 → 33,641 B（+317 B，+0.95%），在 ±2% 内；新增 JS（`personal-report-progress.ts`、`personal-report-progress-panel.tsx`）只被 `/reports` 路由引用，已用反查确认 `/` 的组件树不引入任何 personal-report 模块。


## 普通咨询上下文窗口与模型缓存（2026-09-06，分支 `codex/consultation-context-and-cache-20260906`）

- **`npm run test:db` 未绿：Docker 用户自定义网络地址池耗尽。** `docker compose` 起 postgres fixture 时报 `all predefined address pools have been fully subnetted`。本机 Docker daemon 可用，且已有十余个遗留 `jyotisha-postgres-*` 容器占着网络；本单未做 `docker network prune`（会动共享宿主状态）。`test:db` 36 项里 19 项不需要新网络（备份路径、env 校验等）通过，17 项因建网失败。
- **迁移语法检查（任务书 §5.1 空库口径）：** 用默认 `bridge` 起一次性 `postgres:17-alpine`（不新建 compose 网络）。对空库 `psql --set ON_ERROR_STOP=1 -f 20260906010000_chat_session_context_summary.sql` 退出码 3：`relation "public.chat_sessions" does not exist`。在同一空实例上 `CREATE ROLE authenticated NOLOGIN; CREATE TABLE public.chat_sessions (id uuid PRIMARY KEY);` 后再跑同一文件：`BEGIN / ALTER TABLE / GRANT / COMMIT` 成功；列 `context_summary jsonb`、check `jsonb_typeof = 'object'`、`authenticated` 对该列 `UPDATE` 为真。容器已删。
- **`npm run build -- --webpack`：** webpack 编译通过（45s）。随后 Next 类型检查停在既有 `api/rectification/cases/[caseId]` 的 `dossierResponse` 导出，与 BUG-551/553 同因，本单未改该文件。因此构建未走到 `Collecting page data`，本机看不到 `○ /` Static 行。`page.tsx` 未改；缓存表只在后台用量页。
- ~~部署前仍需产品负责人跑 Gitea `Migrate Staging Database`（本迁移 + 积压的 `5010000_personal_report_longform_appendices.sql`）~~ **已解决（2026-09-06 产品确认）**：附录迁移 `20260905010000_personal_report_longform_appendices.sql` 于 migrate 2431（09-06 00:00）真实 `applied`（此前 09-05 的 migrate/deploy 2419/2420/2425/2428 死于 runner 磁盘满；22:56 的 deploy 2430 被 checker 以 pending migrations 明确拒绝）；随后 deploy 2432 成功。`20260906010000_chat_session_context_summary.sql` 于 migrate 2440（09-06 15:31）`applied`；migrate 2445 幂等复确认两条均 `already applied`。当前 health：`deployment.gitCommit=a444c493`、`database.latestMigration=20260906010000`、`requiredMigrationsPresent=true`。

## 仓库整备任务 1：发布门仍有三条非环境红（2026-09-03，分支 `codex/repo-hygiene-20260903`）

任务 0 之后，附录里 staging 独有的 6 条里，夹具大运 / 用户调用验收 / 技能包验收已绿。剩下 3 条**不改期望值、不改校正打分**：

| 测试 | 现象 | 分类 | 处置 |
| --- | --- | --- | --- |
| `test_local_accuracy_report_outputs_machine_readable_baseline` | `valid_packets` 3 ≥ 4；`dasha_shadbala_oracle_cases.json` 4 包里 1 个仍是 `template_only` | 参考值/oracle 未齐 | 不改断言、不升级模板包。公开案例复验已 `66/66`。 |
| `test_historical_event_priority_preserves_vimshottari_actor_difference` | `selection_priority == 0.0`（1879-03-14 相邻分钟、1922 career） | 校正引擎 / Vimshottari 边界，本轮禁止改阈值 | 交产品 |
| `test_v3_development_result_stays_shadow_only` | `v3_improved_case_count` 1 ≠ 0 | 同上 | 交产品 |

因此 `run_quality_gate.py --profile release` **不能**在本轮声称退出 0。全量 pytest 里附录那 83 条生产同样红的环境/过期项不在本轮修。

复现：

```bash
.venv/bin/python -m pytest -q tests/test_local_accuracy_report.py tests/test_dynamic_rectification_fact_priority.py::test_historical_event_priority_preserves_vimshottari_actor_difference tests/test_minute_rectification_development.py::test_v3_development_result_stays_shadow_only
```

## 生时校正会话面：消除空白假死与交互摩擦（2026-09-03，分支 `codex/rectification-ux-20260903`，重做）

- **浏览器级手工验收未做：执行环境无登录态、无 Chrome。** 任务书任务 0 的手工项与任务 1 的整轮录屏（开场 → 3 道选择题 → 候选 → 采用）都做不了；已按任务书把它们写进 `docs/testing/staging-manual-walkthrough-20260901.md` 第 8 节（含深链/刷新与缺口重试两条），交给有真实会话的人。本轮的替代证据：`tests/rectification-surface-state.test.ts`（纯函数会话态/缺口态、hydration 超时/失败、turn 解析）与 `tests/rectification-surface-contract.test.ts`（源码锁：一次揭幕、prepare 阶段 hydration、无重挂、续接同一行、空态、板首态）。
- **1.3「若快照 API 提供填报时间宫位表则直接渲染」未做：API 不提供。** `frontend/src/app/api/rectification/cases/[caseId]/route.ts` 的 dossier 响应只带 `accepted_time` / `confirmed_time` / `candidate_range`，无 natal/declared 宫位表；按任务书只做文案与收窄，不造数据。
- **书面偏差：hydration 不是 `Promise.allSettled([turns, snapshot])`，而是一次请求套 4 秒 `Promise.race`。** turns 与快照来自同一个 `GET /api/rectification/cases/:id`，两个并行请求会重复；语义（拉完再切换、超时仍揭幕）不变。上限常量直接等于 `BOOTSTRAP_PREPARE_TIMEOUT_MS`，只有一个。
- **书面偏差：turns 后到的填充与重试计数复位不用 `useEffect`。** `npm run lint` 的 `react-hooks` 规则拦截 effect 内同步 setState；改为 React 文档的"渲染中按上一 prop 调整 state"模式与事件处理器内复位，行为等价。
- **书面偏差：首页卡片不带 `aria-busy`。** `tests/home-bootstrap-reveal.test.ts` 锁死 `starter-home.tsx` 不得出现 `aria-busy={`（unified-loading 裁决）；卡片只用 `data-opening` + 静态文案 + `cursor: progress`，侧栏行仍带 `aria-busy`。

## Agent 聊天流式体验与双会话面统一（2026-09-01，分支 `codex/streaming-ux-20260901`）

- **~~任务 3 未做，等待第三批拆页合入~~ 已解除并完成（2026-09-02）。** `origin/staging` 合入 `bf6989ec`（第三批）、`124d3990`、`058e5db9` 后，本分支 rebase 到其上，任务 3 按任务书原文完成：`page.tsx` 的滚动 effect 与内联「跳到最新」按钮删除，跟随并入 `useConversationScrollAnchor`，校正面接入同一 hook 与 `JumpToLatestButton`，复用 `ChatComposer`（`value` 受控、500 字上限），`rectification-sticky-scroll.ts` 删除，720px 覆写删除。对应 DESIGN.md 四条与 BUG-477/476 一并落地。
- **浏览器级手工验收未做：执行环境无登录态、无 Chrome。** 任务书里的 Performance 录制（3k 字回答无 >50ms 长任务）、结算不闪录屏、流式期间折叠时间线、校正/普通会话并排截图，全部留给有真实会话的人按 `docs/testing/staging-manual-walkthrough-20260901.md` 的方式补。本轮的替代证据是 `tests/home-streaming-render-split.test.ts` 的按帧驱动渲染计数与 `tests/stream-frame-buffer.test.ts` 的释放节奏断言。
- **`LatestAssistantEntry` 的「一次会话只 mount 一次」探针无法在测试里驱动。** 仓库没有 jsdom / happy-dom，`renderToString` 不跑 effect，所以 `latestEntryMounts` 只是留给浏览器里手动读的探针；测试改用纯函数 `latestAssistantView` 的 key 一致性 + 源码锁（只有一处 `<LatestAssistantEntry`、无 `StreamingMessageEntry`/`SettledMessageEntry`）代替。

## 报告解读深度对齐（2026-09-01，分支 `codex/report-skill-parity-20260901`）

- **端到端真实生成未做：执行环境没有任何模型凭据。** `ANTHROPIC_*` / `OPENAI_*` / `DEEPSEEK_*` 等全部未设置，仓内只有 `.env.official.example` / `.env.cn.example` / `deploy/.env.staging.identity.example`，不含可用 key。按红线不得读取或猜测凭据。因此任务书交付物 5 的「真实 writer 输出抽查」与交付物 7 的「改前改后同盘同主题章节全文对照 + 真实 inputTokens / 墙钟对照」本地无法产出。离线替代物已给出：`PROGRESS-report-skill-parity-20260901.md` 里的每章 prompt 载荷改前改后逐章对照、claim card 全文对照、以及对服务器确定性 conclusion 的 5 处逐行回溯。真实生成待部署后由委托方补。
- **分章生成路径还需要 PostgreSQL。** `generateSectionedPersonalReport` 依赖 `PersonalReportSectionService`（`personal_report_sections` 表）。本机没有 Docker / postgres / initdb / psql，与 BLOCKED.md 2026-08-30 条目同一缺口。本轮未改任何库结构、未新增迁移，`npm run test:db` 因此也未跑。
- **每章 prompt 原始 token p50 为改前的 2.83×（计费加权约 2.28×），超过任务书红线 6 的 2 倍线，等待裁决。** 不属于任务 3 的止损分支：`cachedSystemMessage` 已确认生效，通用知识包在缓存断点之内且缓存前缀逐字节稳定（有测试锁）。止损条款明确禁止「砍证据来凑成本」，因此本轮**未削减任何证据**，只把数据与四个可选降本项摆在 PROGRESS 里。请委托方决定是接受这个成本、还是选其中某项降本再推。
  **裁决（2026-09-01，产品确认）：接受当前成本，直接推 staging。** 依据：离线估算方法偏保守（CJK 按 1 字符 1 token），绝对量约每份报告 2.2 万输入 token。以部署后第一份真实报告的实测 `inputTokens` 为准复核；实测仍超线时再从 PROGRESS 的降本项 2/3 起做。
  **终裁（2026-09-04，产品确认）：成本线收口，接受实测成本。** 实测每章 inputTokens p50=5921（request 20c94bf4，五章 5804–6405），名义 5.22×，但对照基线 1135.5 是离线载荷估算、实测含系统提示/知识包/schema 注入，口径错位，真实涨幅低于名义值；绝对量约每份 3.5 万 input + 1 万 output tokens。2 倍线裁决就此完结，降本项 2/3 不启动，后续只做常规监控。
- **`/api/consultation_workflow` 的 `ai_prompt_pack` 是精简版，不含叙事种子 / dasa convergence / SAV。** 它来自 `scripts/jyotish_api_server.py` 的 `_build_chart_prompt_pack`，不是 `scripts/jyotish_engine.py` 的 `_build_ai_prompt_pack`。任务书列出的 `evidence_snapshot.timing.vimshottari`、`.convergence_top_domains`、`.strength.sav_scores`、`career_narrative` / `relationship_narrative` / `finance_narrative` 在该响应里**都不存在**（9 个主题一致）。本轮按验收条款标记为不可提取并改用同一响应里真实存在的等价路径，未改 Python 引擎（任务书把引擎输出改动列为不在范围内）。若要拿到真正的服务器叙事种子，需要另立项让 `/api/consultation_workflow` 附带完整 prompt pack——那是「响应新增字段」，属于任务 0 的止损分支，本轮未走。

## 客户端交互收尾（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 任务书继续实现并在进度文件中标记为未验证；不得据此声称已验证“固定题数后停止”的上游机制。

## BLK-001 · 长对话本地收窄后 VedAstro 调用窗口与断言不一致（2026-09-06）

- 状态：blocked（基线即失败，非 BUG-565～567 引入）
- 首次记录：2026-09-06
- 测试：`tests/test_active_rectification_api.py::test_long_real_conversation_reaches_vedastro_after_local_range_is_narrow`
- 复现：

```bash
.venv/bin/python -m pytest -q tests/test_active_rectification_api.py::test_long_real_conversation_reaches_vedastro_after_local_range_is_narrow --tb=line
```

- 失败断言：`result["winning_segment"]` 期望 `start_time=05:07`、`end_time=05:08`、`representative_time=05:07`、`width_minutes=2`；实测 `04:16` / `04:16` / `04:16` / `width_minutes=1`。
- 已知同样失败的 SHA：`e2f4b55c`（父任务书验收段已复跑）；工作树 `43a26a3c`（文档头，Python 与 `origin/staging` 一致）同样失败。测试首次出现于 `3ca30ed7`。未做完整二分：父任务已证明早于 BUG-558～560。
- 本单范围：只记录。不改引擎、不改门槛、不改断言来让它变绿。
- 相关：BUG-560 根因升级（分钟级原始分区分力≈随机）；`docs/tasks/TASK-rectification-convergence-exit-20260906.md` 验收段。