# BLOCKED ## BUG-982/983 日期锚点：未部署与受控真人缺口（2026-09-20） 本轮本地实现不等于 staging 交付；未 commit/push，未部署。缺本轮受控登录态，不能把服务端动作、真实 PostgreSQL 或 SSR 当作浏览器通过。真人须按 `docs/testing/rectification-cross-midnight-fix-20260920.md` 的日期锚点补充清单走查。D4 数据库授权已解除原禁止新迁移停点，但不授权修改旧迁移、历史日期猜补、IANA/DST 修复或阈值。 固定 VedAstro 1.23.26 的独立基线 quick 为绿；宽 glob 仍有四项既有失败，详见 PROGRESS。完整初次HTTP opening到持久focus、采用返回畸形负例、lagna日期透传和报告同源链已有定向/源码证据，见PROGRESS，不再列为真人阻塞。widen真实DB修复及最后pending guard已通过标准56/56、exit0。Grok 接续的隔离 Linux final-3 已跑完 tsc/lint0、前端3649、标准DB56、quick、AA 21/21、Python 广域 0 新增失败；四既存失败仍在。这不是 staging 部署或受控真人通过。自动化代码证据与受控真人缺口分别记录，不互相冒充。未 commit/push/deploy。 ## BUG-984：受控 staging 与真人验收尚未完成（2026-09-20） - 本 agent 不调用线上、不读取凭据；没有本轮受控账号/浏览器会话证据。自动化仅使用明确虚构 fixture 与本地 Docker PostgreSQL，不能代替发布后登录态验收。 - 清单：`docs/testing/rectification-cross-midnight-fix-20260920.md`。推送、独立验收及部署由主会话负责，BUG-984 暂不标 resolved。 ## ~~BUG-984 补单：F2 混合成功身份实证触发 SQL 授权停点（2026-09-20）~~ - **已解除**：产品明确授权继续 B；本轮新增 `20260920010000_rectification_receipt_result_identity.sql`，只替换目标函数身份 SELECT，保留权限、owner/turn/attempt 与重试语义，不改表结构、已应用迁移或历史行。以下保留授权前停点事实。 - A 已局部实现：started/failed 不写算法身份，completed 只用实际结果来源。真实工具 + 原生 golden 的同 turn compare/diagnostics 组合可产生 scoring-9、scoring-10 两条成功回执；字符串 max 返回 scoring-9，不是最近成功 scoring-10。该测试证明缺陷仍存在，不是聚合修复通过。 - 既有 RPC 输出没有各 completed 的来源身份；历史 fingerprint 也不能还原。按补单须升 B（兼容函数体迁移），但当前执行授权禁止自行迁移，已停止进一步业务实施并报告。F1/F3/F4 pending；未改 SQL/UI/缓存、未推送。见 `docs/tasks/PROGRESS-rectification-cross-midnight-fix-20260920.md`。 ## ~~跨午夜前置修复合入：Gitea 写入认证失败（2026-09-20）~~ - **已解除**：主会话成功将前置代码 `3f39bafc4a1fb7fc9d0a257d2528ea1a64295792` 推 staging 并 ls-remote 核对；本轮 fetch 亦看到其后纯文档 `f09f3d80`。下面保留原认证失败历史，不再作为 BUG-984 开工阻塞；部署另行验收。 - 用户授权将已 review 通过的 `25232ce4` 合入 staging，并执行 BUG-984。已同步 `a3577ce2`，本地整合提交 `b27d4de963f9ba7c4072233cabe06c6875eb0582`；缓存补单完整保留 staging 版，BUG-985 按第三环境复验改 resolved。 - `git push origin HEAD:staging` 被拒：`remote: Failed to authenticate user` / `fatal: Authentication failed`。随后 `git ls-remote` 确认远端仍 `a3577ce2fa0bfa6047d397e50ed2e676c58a4420`，不得声称已交付或已部署。 - BUG-984 单要求前置修复合入后串行执行；因此本单暂缓，未改缓存、UI、SQL 或生产打分。需要恢复本会话本人 Gitea Git 写入认证/权限；不借凭据、不 force push。恢复后先交付并核对前置提交，再按已批准策略 b 在独立工作树实施。 ## 跨午夜门禁修复：独立机器补验与旧缓存闭环（2026-09-20） - ~~BUG-985 的同进程对照已在 Windows 与同机隔离 Linux 容器通过；Linux 原测试 ordinal 2/3 确实失败，证明浮点环境不同。但不是两台独立机器，严格按任务书保留第二台 Linux 机器/runner 的本轮提交复验缺口，不将同机容器算成另一台机器，也不据此推 staging。~~ **已解除**：产品提供第三套独立 Linux/Python 3.13 环境复验（`0ca3871d`），定向 18 项与校正 glob 216 项全绿，日期回退正反向成立；BUG-985 resolved，已授权合入 staging。 - Windows quick 基线与修改版均因缺 mcp 停在 source inventory；Linux 完整依赖的 quick 结果另见本轮进度。开工 focused 的历史镜像路径断言仍是已知环境失败，不制造目录、不削弱断言。 - F3 已证实时段真实重算经过已修 helper；旧跨午夜时段缓存证据未变时会绕过新算法，BUG-984 升为 BUG-981 端到端验收阻塞项。只限缓存命中，不能声称所有时段新算都未修；unknown 全天初始窗同日，不把它作为跨日复现。 - 证据与补验：`docs/tasks/PROGRESS-rectification-cross-midnight-gate-fix-20260920.md`、`docs/testing/rectification-cross-midnight-gate-fix-20260920.md`。本单不越界实施缓存/SQL，也未部署或改 main。 ## 跨午夜修复：既有上下游日期与回执缺口（2026-09-20） - BUG-981 本轮只修 `candidate_at` 到 Dasha 辅助评分的日期一致性。独立审查确认两个更上/下游既有缺口，不应扩大“已修复”口径：跨午夜同簇成员按钟点排序会把短簇记成全天宽度（BUG-982）；凌晨申报生成跨午夜窗时，生产枚举将起点绑定申报日，中心候选可能错到次日（BUG-983）。都不在本单仅修 helper 日期的授权内，未顺改开窗、枚举、聚类或交付策略。 - 默认与后端算法标记同步升级只保证版本接口可达、无旧环境覆盖的分钟模式按既有身份门失效缓存。已有环境覆盖、版本探测失败的回退和 `block_scan` 提前缓存路径可能继续复用旧结果；聚合回执 `max(engine_version)` 也不是实际成功计算身份。不能用 started 新版标记声称旧结果已经重新计算，T4 的全链路可区分性尚未完整验收。 - 本机无受控登录态、无授权线上环境变量读取渠道；不借用凭据。逐项补验见 `docs/testing/rectification-cross-midnight-20260920.md`；不把单元测试代替部署或真实历史会话打开。 - 本轮前端全量基线 3486 项/79 失败，最终 3493 项/79 失败，失败标题集合完全相同，但套件仍未全绿。Docker 实际可用，不沿用旧轮“无 Docker”结论；存在 Windows symlink 权限、网络地址池等环境失败。两侧 build 均被外部 node_modules junction 拦截，Static/gzip 未验；Python quick 两侧均缺 mcp。完整对照见本轮进度及 `docs/testing/rectification-cross-midnight-frontend-results-20260920.json`。 ## 寒暄快速通道：平台补验与 staging 实测（2026-09-20） - ~~Windows 标准 `test:db` 被迁移镜像普通文件 `duplicate migration filename` 阻塞。~~ **已用 Linux 标准命令补验：基线 39/39、候选 40/40。** 独立 Docker-in-Docker + Linux named volume 恢复 Git 原始符号链接，不再使用临时单目录迁移替代；未改 runner/迁移断言。 - ~~Windows Next build 被 Skill runtime alias symlink EPERM 阻塞，缺 Static/gzip 证据。~~ **Linux 两侧完整构建通过，首页均 Static；同口径首屏 JS gzip 621,299 → 621,605 B（+0.0493%）。** 未改 Skill loader/权限或业务依赖。 - pre_work_check 远端 verified；focused 23 通过/1 失败，缺 `.workbuddy` 历史镜像目录的基线断言，未造目录。 - Linux 最终全量基线 3530/3530、候选 3566/3566，tsc 0、lint 0 error/120 既有 warnings；本轮前端平台缺口已解除。未用真实模型、未读凭据、无受控登录态浏览器验收；用户已授权推 staging，交付与部署证据见本轮进度。按 `docs/testing/consult-smalltalk-fastpath-20260920.md` 复核三模式、净余额、刷新恢复、真实分类误判率和延迟。 ## 生时校正验证：独立盲测资格与申报偏差真实分布（2026-09-20） - v3 / v4 的案例成绩已曝光。`BUG-427/428` 禁止将已见案例重新算作独立盲测，任务书没有授权推翻；固定实现、重跑或刷新哈希不能恢复未见性。本轮 T2 只能提供固定口径重跑，独立发布验证仍 blocked，确认门保持 `not_ready`。 - 真实用户的申报偏差分布目前不可得：需要有独立出生记录的受控用户样本和合规采集授权，目前无受控账号；不读取、猜测或借用账号。本轮 T1 只能回答给定偏差时的敏感性，不能推算总体准确率或现实失败比例。 - 本机无项目 `.venv`，Python 3.11.7 的 mcp/hypothesis 缺失；快速门及历史 v2 封存哈希断言的基线对照见 `docs/tasks/PROGRESS-rectification-validation-20260920.md`。不改历史封存、不削弱断言来换通过。 - 前端两侧构建均因 Turbopack 不接受指向工作树外的 node_modules junction 失败；Static/gzip 无完整产物。类型检查和 lint 通过不等于构建通过，补验清单见 `docs/testing/rectification-validation-20260920.md`。 - 独立审查发现生产矩阵的 transition proximity 对跨日候选复用单一出生日期。验证补缺轮仅在离线评测按日期分组适配，不能称为未经改动的生产端到端回放。产品现已批准独立修复，跟踪 **BUG-981** 与 `docs/tasks/PROGRESS-rectification-cross-midnight-20260920.md`；生产修复、回归与部署须分别验收，未闭环前保留本条。 ## ~~私人案例清理：远程 review 分支推送认证失败（2026-09-19）~~ - **已解除：** 恢复认证后已成功推送 `codex/owner-case-purge-20260919`，远端 SHA 与本地提交一致；未推 staging 或 main，未部署。此前失败历史保留，不再代表当前状态。 - ~~产品要求先发布 `codex/owner-case-purge-20260919` 供远程 review；首次推送因 Gitea 认证失败。~~ ## ~~私人案例清理：任务书引用范围与全仓扫描口径冲突（2026-09-19）~~ - **已解除：** 产品明确批准补充引用修复范围、精确许可口径、具体删除目标及仓内脱敏。已删除 3,494 个获批文件，修复 8 份派生资料和 manifest；索引 185 → 174，缺失路径为零。没有删除完整性断言或放宽证据限制。 - ~~原任务书将待删台账描述为仅由自身合同测试读取；证据包索引和派生视图存在未列入原范围的引用，未获得授权前暂缓删除。~~ - ~~禁止标记声明会自命中，历史文档和合成样例也超出原清单，精确许可口径待确认。~~ - 授权与实施记录：`docs/tasks/TASK-owner-case-purge-fix-20260919.md`、`docs/tasks/PROGRESS-owner-case-purge-20260919.md`。仅允许经过核实的节点/样例，不豁免整目录。 ## ~~私人案例清理：删除测试清单写入权限（2026-09-19）~~ - **已解除：** 修复单允许把审查后的 12 个测试前缀、Linux 对照计数及非敏感核算写入进度文件；已补 F3，未写入私值、私人转录文件名或原始日志。此前权限拒绝历史保留。 - ~~任务书要求的逐项删除测试清单此前因本地权限分类器拒绝而未落盘。~~ ## 私人案例清理：上游哈希快照与完整验收缺口（2026-09-19） - `references/upstream/yinduzhanxing/SKILL.md` 按任务书保留为唯一临时整文件例外。等上游清理后通过受审导入流程更新并重建来源哈希，届时移除豁免；不手改快照。校正历史包与注册表保持不变。 - 本机缺项目 `.venv`、mcp/hypothesis，Python 全量在收集阶段中断，quick 缺 mcp；Windows symlink 权限和 python3 launcher 造成既有失败。不能写成通过，不为适配本机削弱测试。 - 前端基线和修改版构建受外部 node_modules junction / symlink EPERM 阻断，没有完整产物；`/` Static 与首屏 gzip 尚未验收。未借用登录态或模型凭据，历史会话真实加载与浏览器走查待受控环境补验。 - 直接运行证据索引检查确认基线与修改版均有 12 个校验器不支持的既有 claim_status；缺失路径为零不等于完整性门全绿。未越界修改状态或校验器。 - 补验清单：`docs/testing/owner-case-purge-20260919.md`。提交、推送、部署状态以本轮进度记录为准。 ## ~~侧栏导航循环：Gitea 写入认证失败（2026-09-19）~~ - **已解除：** 用户要求再次推送后，同一工作树 `git push origin HEAD:staging` 成功，`ls-remote` 确认远端为 `7e0037177d3babc9f8bb20b840dda8a060e37ace`。没有修改认证配置、读取或转交凭据；此前失败原因未确定。以下保留首次失败历史，不再代表当前推送状态。测试站 health 当次核对仍为 `d6fc4fb8`，部署未验收。 - 用户已授权 push staging，但 `git push origin HEAD:staging` 返回 `remote: Failed to authenticate user` / `fatal: Authentication failed`。只读 fetch/ls-remote 成功不代表写入认证可用。 - 本地代码提交 `2c92f6100eb982756424e6f48a38680032917c23` 已保存；失败后远端仍 `a2bcdee006397e2417f2e42d30ca030dd41ec480`，health 仍 `d6fc4fb8b3838702c62f9d2a181609ffb3df2985`，**未推送、未部署**。 - 需要产品恢复本人 Gitea Git 写入认证/仓库写权限；不在聊天中提交 token，不借用其他账号，不 force push。恢复后从本轮独立工作树 fetch 并快进交付，再验门禁和部署。 ## 侧栏导航循环：本机构建与登录态验收缺口（2026-09-19） - 同 SHA 基线 webpack 构建完成编译/TypeScript，但 collect page data 因 Skill runtime `symlink EPERM` 失败；修复版同环境结果见进度记录。未得到完整生产构建，因此 `/` Static 和首屏 gzip ±2% 尚未验收，不能用不完整产物代替。 - 基线全量前端测试 3481 tests / 3403 pass / 78 fail；包含 Windows 路径、符号链接、数据库/Docker 与既有合同失败。修复版逐项对照见 [本轮记录](docs/tasks/PROGRESS-sidebar-navigation-loop-20260919.md)，不顺带放宽断言。 - 没有受控登录态浏览器，未执行完整 Next Link 三入口点击、移动/折叠及可见分页 observer 走查。替代证据为真实 React provider/effect/transition 回归，**不等价于浏览器验收**。按 [真人清单](docs/testing/sidebar-navigation-loop-20260919.md) 补齐。 - 发布前预检远端 verified，但碎片扫描两条既有断言失败；不以同步成功声称预检全绿。修复交付与部署状态在进度记录分别标注。 ## ~~TypeSafe Jev 意图分类：等 API key（2026-09-19）~~ - ~~T2/T3 阻塞，替代证据 = T0/T1 产出。~~ - **解除（2026-09-19）：** 产品提供 `TYPESAFE_API_KEY`，T2 已用 `jev-1.13.0` 跑完来源 A+C 各两次。首版结论作废（语料为模板拼接）。 - **修复轮（2026-09-19）：** 来源 C 由 DeepSeek Flash 生成+复核后重跑。结论见 `docs/research/jev_intent_2026_09_19.md`：**缺数据**。 ## ~~生时校正 Jev 研究：无 staging 库，来源 B = 0（2026-09-19）~~ - ~~缺 staging `agentic_rectification_turns` 样本。~~ - **解除（2026-09-19 修复轮）：** 产品转交 `source_b.jsonl` 157 条（点选 17 / 采集 107 / 无焦点 33），执行方逐条人工标注 gold，未提交原文。Jev×2 + Flash×1 已跑。无焦点层与来源 C intent 差 17.2pp > 10pp，结论为缺数据。 ## ~~生时校正 Jev 研究：无会话模型凭据，现行分类器未对照（2026-09-19）~~ - **解除（2026-09-19 修复轮）：** 产品确认线上会话模型 = DeepSeek Flash。生成、复核、对照均用该模型（提示不同）。来源 C 全量一次 + 1/3 第二次；来源 B 全量一次。原「无会话模型凭据」缺口关闭。 ## 会话列表：元数据操作未上移到 provider（2026-09-17，BUG-927 让步） - **让步：** 任务书 T2 允许第一步只做「路由组 + layout 常驻 + provider 拥有列表 + 首页注册全部控制」。改名 / 置顶 / 归档 / 删除 / 翻页仍由首页注册，未挂载首页时侧栏只读。 - **现状：** 四个页面共用一份列表、切页不重拉已落地。星盘 / 星历 / 报告页不能改名或删除。 - **解除需要：** 把只依赖 `sessions` + fetch 的元数据操作搬进 `SessionListProvider`，四页都能用。另立单。 ## ~~会话列表：空咨询延迟落库未做（2026-09-17，BUG-928）~~ - ~~**让步：** 任务书 T3 要把 `startNewChat` / 启动落点改成本地创建、第一问前才 `POST /api/sessions`。牵动 `?c=` 深链和刷新恢复，本轮只做服务端过滤 + 复用已有空咨询。~~ - ~~**替代：** `GET /api/sessions` 排除 `messages = []`，响应带 `draft`；启动和「新建对话」优先用这份空咨询，不再连点就堆新行。~~ - **解除（2026-09-21，BUG-989）：** `startNewChat` 只在本地开一条，第一问 `send()` 才 `POST /api/sessions`；未落库不写 `?c=`。列表过滤收窄到咨询空行，校正会话不再被 `messages = []` 误删（BUG-987）。刷新丢掉未开口的本地空会话是可接受的。 ## 会话列表归档：本机 Docker 网段耗尽未跑 test:db（2026-09-21，BUG-990） - **Docker 在 PATH**，但 `startPostgresFixture` 建 compose 网络报 `all predefined address pools have been fully subnetted`（其它 worktree 留下的 postgres 网络占满）。**未跑 `npm run test:db`，不得写成通过。** - **替代证据：** `frontend/tests/local-postgres-not.test.ts`：`not("archived_at","is",null)` 编译 `"archived_at" is not null` 且不含 `<>`；`not(...,"is",undefined)` throw `unsupported not filter`。真实 Postgres 断言仍在 `database-session-list-visibility.test.ts`，最终验证交给门禁机。BUG-990 保持 investigating。 ## 会话列表多键排序：无 Docker 未跑翻页重叠（2026-09-17，BUG-926） - **无 Docker：** 本机 `docker` 不在 PATH。任务书要求 `npm run test:db` 插入三条不同 `updated_at` 的会话，`GET /api/sessions?limit=2` 返回最新两条且 `nextCursor` 翻页拿到第三条、无重叠。**未跑，不得写成通过。** - **替代证据：** `frontend/tests/local-postgres-order.test.ts`：两次 `order()` 生成 `order by "updated_at" desc, "id" desc`；单次 `order()` 输出不变；列表路由排序键与 `sessionCursorFilter` 键一致。 ## 生时校正常驻条：缺「收窄进度」服务端字段（2026-09-16，分支 `codex/cend-rectification-20260916`，T7.1） - **触发让步顺序第 5 条。** 任务书要常驻条写「当前区间、宽度、收窄进度、已答题数」四项。前三项里只有**收窄进度**没做，其余三项已上条。 - **缺的是什么：** 没有任何投影把「已从 N 分钟收到 M 分钟」作为字段给出。服务端能拼出这句话（`user-copy.ts` 的 `progressClause()`，由 `answer-choice.ts` / `agent-run.ts` 传 `openingRangeFromDossier(dossier)` 调用），但它只作为**旁白正文**落库，没有结构化出口。客户端要么解析消息文本，要么自己减——两条都不行。 - **为什么不在前端减。** 开场窗口 `case.candidate_range` 确实在线上（`searchWindowFromSnapshot`），但：① VOICE.md 第 2 条把进度数字划给服务端；② 更要命的是会算错——`candidate_range` 是**当前**搜索窗口且会放宽（BUG-572：±15 → ±30 → ±60 → ±120），拿它当「最初」去减，一次放宽会被报成一次收窄。 - **现状不是回归：** 收窄进度这句话服务端照旧写进旁白，用户仍看得到，只是不在常驻条上。 - **解除需要：** 投影里加一个稳定的开场宽度 / 收窄进度字段（`inference_state` 或 `case` 上都行），要求它记的是**开场**窗口而不是当前窗口，放宽时不得跟着变。届时常驻条加一项即可，`rectification-timeline-scale.ts` 已留好位置。另立单，本轮不做。 ## 对话额度拆分（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。2026-09-16 旧思考计划：19 轮 UTF-8 **562,240 B（0.536 MiB）**；50 轮 **1,479,034 B（1.411 MiB）**。2026-09-18 四标题思考计划重测：19 轮 **533,113 B（0.508 MiB）**；50 轮 **1,402,384 B（1.338 MiB）**，比例仍约 2.63。1.3–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 一致性 + 源码锁（只有一处 ` ...)` 被插入 `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` 验收段。 ## BLK-002 · 校正标题/活跃时间修补迁移无法本机实跑（2026-09-16） - 状态：blocked（环境缺口，非代码缺陷） - 分支：`codex/rectification-title-repair-migration-20260916` - 对象：`frontend/supabase/migrations/20260916020000_rectification_session_title_repair.sql`（BUG-699 / BUG-704 的一次性数据修补） - 缺什么：本机既没有 Docker（`docker info` 失败），也没有本地 PostgreSQL（`which psql postgres pg_ctl initdb` 全空），因此 - `npm run test:db --prefix frontend` **没跑**，不得视为通过； - `npm run db:migrate:check --prefix frontend` 在连库前就以 `SCHEMA_DATABASE_URL is required` 退出 1，拿不到 pending 清单。 - 替代证据（都已实跑）： - 迁移的两段 SQL 与 `frontend/scripts/repair-rectification-session-titles.mjs` 逐字一致，由 `frontend/tests/rectification-session-title-repair-migration.test.ts` 比对，5/5 通过； - 迁移器的文件级校验（文件名正则、重复文件名、目录扫描）在连库前完成——用假连接串调 `runMigrations({check:true})`，报错停在 `connect ECONNREFUSED` 而不是 `invalid migration filename`，说明新文件名与排序被接受； - `update public.chat_sessions as session`、`join lateral`、`get diagnostics ... = row_count` 三种写法在已应用的迁移里都有先例（`20260808030000`、`20260901010000`、`20260811020000`）； - 全量 `npm test`：3334 tests / 31 fail，与同一工作树上 `origin/staging` @ `37e6c519` 的 3329 / 31 逐条一致（本轮 +5 test 全绿，失败集合未变）。 - 真实证据待补：产品在 staging 点一次 `Migrate Staging Database`，从运行日志的 `notice ... repaired_titles=` / `notice ... refreshed_activity=` 读回行数，回填进 BUG-699 / BUG-704 的「验证」。解除后划掉本条而不是删除。 ## BLK-003 · 快速门 `test_chat_page_uses_authenticated_cloud_persistence` 基线即红（2026-09-16） - 状态：blocked（基线即失败，非 BUG-734 / 735 引入） - 首次记录：2026-09-16 - 测试：`tests/test_supabase_user_data_contract.py::test_chat_page_uses_authenticated_cloud_persistence` - 复现： ```bash .venv/bin/python -m pytest -q tests/test_supabase_user_data_contract.py --tb=line ``` - 失败断言：`assert 'user_id: user.id' in create_route`，其中 `create_route` 是 `frontend/src/app/api/sessions/route.ts`。该路由已改走 `chatSessionCreateInsertRow(...)` 构造插入行，源码里不再有 `user_id: user.id` 这个字面量；断言没跟上。**是断言过期，不是持久化真的丢了 user 归属**——同一条测试上面几行的「无浏览器侧写入」锁仍然成立。 - 已知失败的 SHA：`origin/staging` @ `37e6c519`（在 `git worktree add --detach` 出来的**干净检出**上复跑确认，与本单工作树无关）。 - 影响：`scripts/run_quality_gate.py --profile quick` 因这一条退出码为 1（`1 failed, 791 passed, 1 skipped`）。任何 Python 轮次在本机都会看到快速门红。 - 本单范围：只记录。AGENTS §7.7 不得顺手修不在任务书里的问题；改这条断言属于产品/前端归属，要单独立单确认「插入行里 user 归属现在由谁保证」再改，不得直接把断言删了变绿。 - 相关：本单进度记录 `docs/tasks/PROGRESS-consultation-residual-hotspots-20260916.md` 测试段。