Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
 jesse-uxandGrok (agent loop)
|
bccceff91f | ||
|
Jesse_ChenandClaude Opus 5.5
|
0c04755560 | ||
|
Jesse_ChenandClaude Opus 5.5
|
963276ca2f | ||
|
Jesse_ChenandClaude Opus 5.5
|
856bc850ba | ||
|
Claude
|
3cc7fe23d1 | ||
|
jesse-uxandGrok (agent loop)
|
606f4d3aef | ||
|
jesse-uxandGrok (agent loop)
|
b0818ee1c3 | ||
|
jesse-uxandGrok (agent loop)
|
6e6fae8d84 |
@@ -1,5 +1,11 @@
|
||||
# 印度占星 Skill 更新日志
|
||||
|
||||
## 2026-10-13 — 明说要做生时校正时，第一步就能打开（待合入 staging）
|
||||
|
||||
- 新对话第一句就说「帮我做生时校正 / 生时纠正 / 核对出生时间」，会直接打开校正，只留一句过渡，不先写一段解读。
|
||||
- 问事业、感情这类普通问题，仍是先排盘再回答。只是觉得解读不准，仍是认下来改着读，不会被拉去做校正。
|
||||
- Skill 版本不变（BUG-1317，是 BUG-1306 的复发）。
|
||||
|
||||
## 2026-10-13 — 新报告正文画出分盘，中文更干净，上升行和同位列能读懂（待合入 staging）
|
||||
|
||||
- 重新生成的报告里，「本命与分盘北印度图盘」每张有数据的盘下面有一张北印度图。同一张盘只画一次。报告最末不再重复「分盘核对」。旧报告打开仍是当时保存的正文。
|
||||
|
||||
@@ -17556,6 +17556,7 @@
|
||||
- 防复发：`frontend/tests/rectification-explicit-entry-20261012.test.ts` 锁住直达、同一轮不重复开案、无 caseId 的 opened 绑定与找回、四种拒绝说明、两条路径不重试、普通咨询仍重试一次、规则只定义一处、申报时段「在哪一段附近」、结算调用 `complete_consultation_free`。F3 另锁：结算记录是 `offered` 且 `autoOpen: true`、卡片在绑定前不说「已经开始」、绑定后才说已经开始、打开失败仍是 `offered`、旧的 `offered` / `opened` / `returned` 照常解析且 `returned` 不出卡。用户可见句长度 ≤20。真机清单 `docs/testing/rectification-explicit-entry-20261012.md`。
|
||||
- 相关记录：BUG-1247、BUG-1248（入口改为提议卡）、BUG-976/977（禁正则判意图）。
|
||||
- 复发自：无。
|
||||
- 复发：BUG-1317（2026-10-13。直达已部署，但第 0 步仍只有排盘工具，模型排完盘后没有带 explicitRequest 打开校正）。
|
||||
- 修复版本：staging `b8bdc003`（实现 `6a799582` 变基到 `9f1e8257`，代码逐字节相同；2026-10-12 Claude 验收通过、产品要求合入；部署核对：health gitCommit=b8bdc003、`requiredMigrationsPresent` true，`/login` 200，未登录 `/api/account` 401）。跟进项 F3（打开失败卡片仍说已开始）见 `TASK-rectification-1012-batch-fix-20261012`。 F3 跟进（`51a77721`）已部署 staging `586561eb`（2026-10-12 核对：health gitCommit / apiGitCommit=586561eb、`requiredMigrationsPresent` true，`/login` 200，未登录 `/api/account` 401；合并后 npm test 5025 条、失败 24 逐名同 `798e15ef` 基线）。
|
||||
- 决策日志（2026-10-12，产品）：选 A——用户明确要求做生时校正时直接进入校正，不先写解读、不用点卡；意图由模型判断，禁正则 / 关键词。**推翻 BUG-1248 两处**：①明确要求的这一轮不再「只出卡、点卡才进」；②`product_disabled`、`pricing_unavailable`「正文不要提校正」改为必须一句话说明做不了，不得静默。普通对话模型不得承诺收窄出生时间、不得在对话里收集经历假装校正；申报时段下不得写大运 / 子运精确起止。服务端本人 / 开关 / 进行中 case / 价格判定不变。同日另立 BUG-1307（最近分界开场）、BUG-1308（父母静态题研究）。
|
||||
|
||||
@@ -17616,6 +17617,21 @@
|
||||
- 复发自：无。
|
||||
- 修复版本：已部署 staging `586561eb`（2026-10-12 核对：health gitCommit / apiGitCommit=586561eb、`requiredMigrationsPresent` true，`/login` 200，未登录 `/api/account` 401；合并后 npm test 5025 条、失败 24 逐名同 `798e15ef` 基线）。Claude 直接执行，产品 10-12 授权。
|
||||
|
||||
## BUG-1311 | 聊天输入框内层圆角把第一个字左缘裁掉
|
||||
|
||||
- 状态：fixed-pending-verify（合同测试已锁住；真机看普通聊天和生时校正两个输入框后标 resolved）
|
||||
- 首次发现 / 最近更新：2026-10-13 / 2026-10-13
|
||||
- 来源：产品负责人在 issue #52 的截图。placeholder 第一个字左侧有一道圆弧，打字时第一个字左边缺一块。
|
||||
- 现象：聊天输入框里第一个字的左缘被裁成圆弧。普通聊天和生时校正共用同一个输入框，两处都有。
|
||||
- 触发条件：输入框只有一行高，左右内边距为 0，内层文本框仍带着 12px 圆角。
|
||||
- 根因：`Textarea` 原语默认 `rounded-lg`（12px）。`.composer textarea` 清掉了边框、背景和左右内边距，没有清圆角。文本框按圆角裁切内容，第一个字正好压在左上和左下两个圆角上。
|
||||
- 修复：只在 `.composer textarea` 加 `border-radius: 0`。外框 `.composer` 的圆角不动。原语不改，别的表单仍用圆角。
|
||||
- 验证：`frontend/tests/chat-reading-load-mobile.test.ts` 新增断言，规则必须含 `border-radius: 0`。改样式前该条失败（7 过 1 失败，cancelled 0）；改后该文件 8 过 0 失败，cancelled 0。真机清单 `docs/testing/composer-first-glyph-clip-20261013.md` 未走。
|
||||
- 防复发：同上测试锁住内层直角。不改 `textarea.tsx`，避免别的表单丢掉圆角。
|
||||
- 相关记录：无。
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/composer-first-glyph-clip-20261013`，尚未部署。推送后的 40 位 SHA 写在 issue #52 的执行回报里。
|
||||
|
||||
## BUG-1312 | 中文完整数据报告正文仍有英文功能词，并与汉字粘在一起
|
||||
|
||||
- 状态：fixed-pending-verify（只对新生成的报告生效；真机清单 `docs/testing/report-translation-gaps-20261013.md` 未走，不标 resolved）
|
||||
@@ -17674,3 +17690,19 @@
|
||||
- 复发自：无。
|
||||
- 修复版本：分支 `codex/report-translation-gaps-20261013`，尚未合入 staging。
|
||||
|
||||
## BUG-1317 | 明说要做生时校正时，仍先排完盘再写解读，校正没打开
|
||||
|
||||
- 状态：fixed-pending-verify（真机清单未走，没有模型凭据，不标 resolved）
|
||||
- 首次发现 / 最近更新：2026-10-13 / 2026-10-13
|
||||
- 来源：issue #54。staging 首页普通对话第一句说要生时纠正，回答先显示排盘完成，再写校正开不了、走另一个入口。
|
||||
- 现象：没有打开校正。正文是模型自己写的解读，不是那句固定过渡。
|
||||
- 触发条件：新对话第一句明确要做校正。普通问题、以及只是觉得解读不准，不在这条里。
|
||||
- 根因：第 0 步只给排盘工具（BUG-923）。模型必须先排完盘，才看得到校正工具。规则里「明确要校正就打开」夹在禁止句中间，「纠正」又和「用户纠正解读」撞了。BUG-1306 的测试直接调用工具，没有让真实模型选工具；真机清单因没有模型钥匙没跑过。
|
||||
- 决策：产品选 B。第 0 步在校正工具确实挂上时，可以排盘，也可以打开校正。`toolChoice` 仍是 auto。两个都没按就写答案时，仍走原来的「运行合同不完整」重试，逼它先排盘。不加关键词判断。
|
||||
- 修复：本命和申报时段的第 0 步，在挂了校正工具时多放这一个工具。还没看盘就顺口提议，不算已经提议过，先去排盘。明确要求则第一步就打开，不先写解读。规则第一句改成「校正就在这个对话里能开」，并把「纠正规则」改称「改读规则」。`FOLLOW_UP_CORRECTION_RULE` 本身没改。没挂校正工具时，第 0 步仍只有排盘工具。
|
||||
- 验证：见 `docs/tasks/PROGRESS-rectification-step0-entry-20261013.md`。规则原 374 字，新 416 字，增加 42，不超过 80。
|
||||
- 防复发：第 0 步断言锁住「没挂只有排盘、挂了是两个工具」。另有三条：第一步明确要求不排盘且正文是固定过渡；一步都不按会重试到排盘后的回答；没看盘的顺口提议不占额度。
|
||||
- 相关记录：BUG-1306、BUG-923、BUG-937、BUG-922。
|
||||
- 复发自：BUG-1306。
|
||||
- 修复版本：分支 `codex/rectification-step0-entry-20261013`，尚未合入 staging。
|
||||
|
||||
|
||||
@@ -0,0 +1,28 @@
|
||||
# 进度 · 输入框第一个字被圆角裁掉（2026-10-13）
|
||||
|
||||
- 分支：`codex/composer-first-glyph-clip-20261013`（从当时的 `origin/staging` `804b6ee3f355f67015cde4d9bc42f2f79c3f267f` 新建）
|
||||
- 任务书：`docs/tasks/TASK-composer-first-glyph-clip-20261013.md`
|
||||
- 结论：内层输入框改为直角。外面的圆角框没动。普通聊天和生时校正共用这一个输入框。
|
||||
|
||||
## 做了什么
|
||||
|
||||
- `frontend/src/app/globals.css`：`.composer textarea` 增加 `border-radius: 0`。
|
||||
- `frontend/tests/chat-reading-load-mobile.test.ts`：锁住这条规则必须含 `border-radius: 0`。
|
||||
- `frontend/DESIGN.md`、`docs/BUG_HISTORY.md`（BUG-1311）、`docs/tasks/README.md`。
|
||||
- 开工时 `docs/BUG_HISTORY.md` 最大号是 BUG-1310，本单用 BUG-1311，没有被占用。
|
||||
|
||||
## 检查
|
||||
|
||||
| 检查 | 命令 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 合同测试（改样式前） | `node node_modules/tsx/dist/cli.mjs --test tests/chat-reading-load-mobile.test.ts` | 8 条，7 过，1 失败，cancelled 0。失败的就是新断言 |
|
||||
| 合同测试（改样式后） | 同上 | 8 条，8 过，0 失败，cancelled 0 |
|
||||
| 类型检查 | `frontend\node_modules\.bin\tsc --noEmit -p frontend` | 退出码 0 |
|
||||
| lint | `npm run lint`（frontend） | 退出码 0，0 error，125 warning（原有，未改） |
|
||||
| 全量前端测试 / Python 快速门 / test:db | 未跑 | 任务书不要求；未动数据库 |
|
||||
|
||||
## 偏离
|
||||
|
||||
- 没有。真机还没看，清单在 `docs/testing/composer-first-glyph-clip-20261013.md`。推送后的 40 位 SHA 写在 issue #52 的执行回报里。
|
||||
- 本轮开始时评论接口在 Windows PowerShell 5.1 里把评论列表粘成一条，计划被滤掉，误发过一条「需拍板」。接口修好后读到计划，那条作废，本轮按任务书改完。标签「需拍板」已去掉。
|
||||
- 按修复单跟上最新版本，修复内容未变。已推送的提交不能改写，所以把最新版本合并进原分支，没有重写历史。任务索引两行都留着。样式、测试、设计说明、缺陷记录与上次相同。
|
||||
@@ -0,0 +1,32 @@
|
||||
# 进度 · 明说要校正时第一步就能打开（2026-10-13）
|
||||
|
||||
- 分支：`codex/rectification-step0-entry-20261013`
|
||||
- 任务书：`docs/tasks/TASK-rectification-step0-entry-20261013.md`
|
||||
- 基线：`origin/staging` `0c04755560f0b6a772116130392b56eb2b40ae0e`（任务书写的 `963276ca2` 的后代，也是计划里的 base）
|
||||
- issue：#54，BUG-1317，复发自 BUG-1306
|
||||
|
||||
## 做了什么
|
||||
|
||||
1. 本命和申报时段的第 0 步，在校正工具挂上时可以排盘，也可以打开校正。没挂时仍只有排盘。选择仍是自动，没有改成必须调用某个工具。
|
||||
2. 还没看盘就顺口提议，不算已经提议过，先去排盘。这一轮明确要校正，第一步就打开，正文换成那句过渡。
|
||||
3. 规则第一句改成校正就在这个对话里能开，并写明校正、纠正、核对出生时间都算。不认同解读改称「改读规则」，避免和「生时纠正」撞词。
|
||||
4. 规则字数：原 374，新 416，增加 42，上限是加 80。
|
||||
|
||||
## 检查
|
||||
|
||||
| 检查 | 命令 | 结果 |
|
||||
| --- | --- | --- |
|
||||
| 定向测试 | `node node_modules/tsx/dist/cli.mjs --test` 五个相关测试文件 | 149 通过，0 失败，0 取消。类型收窄改完后，入口测试文件再跑 19 通过，0 失败，0 取消 |
|
||||
| 类型检查 | `frontend\node_modules\.bin\tsc --noEmit -p frontend` | 通过，退出码 0。第一次在测试里把「还没提议」收成永远是空，已改成先记在局部再断言 |
|
||||
| 前端 lint | `npm run lint --prefix frontend` | 退出码 0，0 error，125 条原有 warning，没有顺手改 |
|
||||
| 隐私标记 | `.venv\Scripts\python -m pytest tests/test_repo_privacy_markers.py -q` | 通过，退出码 0 |
|
||||
| 名人生平回测 | 未跑 | 本机没有模型钥匙 |
|
||||
| 数据库 | 未跑 | 不改表 |
|
||||
|
||||
## 偏离
|
||||
|
||||
- 没有。真机清单补在原来的 `docs/testing/rectification-explicit-entry-20261012.md`（第 1b 步和第 9 步），没有另写一份。
|
||||
|
||||
## 环境缺口
|
||||
|
||||
- 真实模型会不会在第一步打开校正，以及名人生平回测，都没有模型凭据，不能写成通过。部署后按真机清单，用 deepseek-v4-flash 和默认模型各走一遍。
|
||||
@@ -134,7 +134,7 @@
|
||||
|
||||
| 任务书 | 进度 | 主题 | 状态 | 落点 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `TASK-composer-first-glyph-clip-20261013.md` | — | **输入框第一个字被圆角裁掉（agent 循环 issue #52）**：`Textarea` 原语自带 12px 圆角，`.composer textarea` 清了边框与左右内边距却没清圆角，浏览器按圆角裁滚动内容，第一个字左缘被裁成圆弧；只在 `.composer textarea` 加 `border-radius: 0`，原语不动。执行方 Grok。BUG-1311 | 待领取 | `codex/composer-first-glyph-clip-20261013` |
|
||||
| `TASK-composer-first-glyph-clip-20261013.md` | `PROGRESS-composer-first-glyph-clip-20261013.md` | **输入框第一个字被圆角裁掉（agent 循环 issue #52）**：`Textarea` 原语自带 12px 圆角，`.composer textarea` 清了边框与左右内边距却没清圆角，浏览器按圆角裁滚动内容，第一个字左缘被裁成圆弧；只在 `.composer textarea` 加 `border-radius: 0`，原语不动。执行方 Grok。BUG-1311 | 待验收 | `codex/composer-first-glyph-clip-20261013` |
|
||||
| `TASK-composer-first-glyph-clip-fix-20261013.md` | — | **#52 第 1 次打回（只需 rebase）**：`6e6fae8d` 内容全部通过，因 staging 前进了一个纯文档提交而不能快进 | 待领取 | `codex/composer-first-glyph-clip-20261013` |
|
||||
| `TASK-consult-card-full-source-20261007.md` | `PROGRESS-consult-card-full-source-20261007.md` | **对话数据卡与报告同源 + 领域综合判断表**：事业卡只有约 7,600 字符、无自然代表星、无大运主星关系、D10 联动只能补取、补取上限 1；全 12 领域；综合判断表、参与清单（不止 D1/D9，含精度闸）、补取 3 次、资料目录均已确认；KP 不上卡、不联网、不接书籍语料；排在 sync6 与报告单之后 | 验收未通过（`35dafd1e`，见 fix-20261009） | `codex/consult-card-full-source-20261007` |
|
||||
| `TASK-consult-card-full-source-fix-20261009.md` | `PROGRESS-consult-card-full-source-fix-20261009.md` | **对话卡同源修复**：缓存键无日期致当前大运冻结、整卡 37.5K（每格带内部路径）、星照整列 blocked（资料库其实有出处）、前端测试手写数据、无预热；合入前用临时 key 跑模型 A/B 与生平回测 | F1–F5 已验收，F6 未过（见 fix2） | `codex/consult-card-full-source-20261007` |
|
||||
@@ -211,6 +211,8 @@
|
||||
|
||||
| 任务书 | 进度 | 主题 | 状态 | 落点 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| `TASK-rectification-step0-entry-20261013.md` | — | **明说要校正时第一步就能打开（agent 循环 issue #54，BUG-1306 复发）**：第 0 步只放排盘工具、规则正向句埋在禁止句里、「纠正」撞词，模型没带 explicitRequest 调工具（BUG-1317）。产品选 B：第 0 步放出校正工具 + 规则重排；推翻 BUG-923 第 0 步限制，保险用现有 runtime-contract-retry。执行方 Grok | 待领取 | `codex/rectification-step0-entry-20261013` |
|
||||
| `TASK-report-focus-card-20261013.md` | — | **报告开篇「重点」做成摘要卡（agent 循环 issue #55）**：10-08 加的开篇重点从未设计——三重「重点」、标题无样式、MD/AD/PD 行话、数据句堆砌（BUG-1316）。产品选 A 摘要卡 + 名字与日期 + 保留提醒句；引擎出 `jyotish-focus` 围栏，前端一个组件渲染。执行方 Grok | 待领取 | `codex/report-focus-card-20261013` |
|
||||
| `TASK-report-translation-gaps-20261013.md` | — | **个人报告中英混杂、正文图盘空白、上升行、同位列（agent 循环 issue #53）**：中文完整数据版靠短词替换英文，正文残留 218 处英文词与 14 处中英粘连，卫生检查只有黑名单（BUG-1312）；完整数据版图盘节只有空标题、无围栏，BUG-1203 的回归（BUG-1313）；报告本命表无上升行（BUG-1314）；D9 同位列「—」读如没数据，改「是/否」（BUG-1315）。分盘核对段随 T1 自动消失。执行方 Grok | 待领取 | `codex/report-translation-gaps-20261013` |
|
||||
| `TASK-report-translation-gaps-fix-20261013.md` | — | **#53 第 1 次打回**：`a295afa4` 实现四项都验过，但分支未基于最新 staging，且全量 pytest 新增 1 条失败（报告 Jaimini 星位名改成「灵魂星（AK）」后 `test_chara_karaka_8_bphs_order` 未跟改）。要求 rebase + 按三栏改测试，不改 `KARAKA_CN` | 待领取 | `codex/report-translation-gaps-20261013` |
|
||||
| `TASK-report-full-data-edition-20261007.md` | `PROGRESS-report-full-data-edition-20261007.md` | **报告改为完整数据版、删除阅读版**：网站阅读版中文 7.6 万字符 vs 上游 `pl9_ai_density` 97 万；移植原始数据附录 / 清理器 / 时间补充，中英文；我方报告口径（BUG-1199～1229）全部保持；旧报告仍可打开；排在 sync6 之后 | 已验收（Claude 补修 BUG-1282 后合入 staging） | `codex/report-full-data-edition-20261007`（未推 staging） |
|
||||
|
||||
@@ -0,0 +1,97 @@
|
||||
# TASK · 明说要校正时第一步就能打开（issue #54，BUG-1306 复发）
|
||||
|
||||
- 日期：2026-10-13
|
||||
- 来源：Gitea issue #54（agent 循环试点），产品负责人在 staging 首页普通对话（deepseek-v4-flash）第一句说「请你帮我生时纠正」，回答「已完成 3 步、本轮技法 43 项」后写「生时校正这次我这边开不了，它走的是另一个入口……」，没有打开校正
|
||||
- 执行方：**Grok（Windows + Docker）**，分支 `codex/rectification-step0-entry-20261013`，只推这个分支
|
||||
- 验收：Claude（Linux）
|
||||
- BUG 编号：**BUG-1317**（BUG-1316 已预留给 issue #55；开工时核对 `docs/BUG_HISTORY.md` 最大号）。BUG-1317 标「复发自 BUG-1306」，并在 BUG-1306 记录里补一行指向它
|
||||
|
||||
## 1. 基线
|
||||
|
||||
- 基线 commit：`origin/staging` `963276ca2`
|
||||
- `git log 586561eb..origin/staging -- frontend/src/mastra frontend/src/lib/consultation-thinking-plan.ts frontend/src/lib/rectification-in-chat*.ts frontend/src/lib/stream-agent-response.ts frontend/src/app/api/consult frontend/src/hooks/use-consultation-run.ts` 为空：BUG-1306 部署后这条链没人动过，**不是代码回归**。
|
||||
|
||||
## 2. 事故实证
|
||||
|
||||
- 产品负责人这一步就是 `docs/testing/rectification-explicit-entry-20261012.md` 第 1 步（「请你帮我进行生时纠正」），未通过。该清单（BUG-1306 的 T5）因无模型凭据从未跑过（`BLOCKED.md`「TASK-rectification-explicit-entry-20261012：T0 日志、T5 模型」）。
|
||||
- 用户看到的是模型自由写的整段解读。而工具只要收到 `explicitRequest=true`，不论放行还是拒绝，服务端都会用固定句覆盖模型正文（`frontend/src/lib/rectification-in-chat.ts` 的 `RECTIFICATION_DIRECT_*_COPY`，`frontend/src/lib/stream-agent-response.ts::rectificationDirectRunCompleted`）。所以**模型没有带 `explicitRequest=true` 调用 `offer-birth-time-rectification`**，这是代码可证的，不是推测。
|
||||
- 「另一个入口」「开不了」在提示词、skill、`frontend/src` 里都搜不到，是模型自己编的；「我也不会先用一两件事去反推一个更窄的时间」是在复述规则里的禁止句。
|
||||
|
||||
BUG-1306 的防复发措施逐条核对仍在：唯一规则 `RECTIFICATION_OFFER_RULE`（`frontend/src/lib/consultation-thinking-plan.ts`）注入首轮、追问轮与时段路线；`createRectificationOfferTool` 与 `finishExplicitRectificationRequest`（`frontend/src/mastra/consultation-tools.ts`）；`decideRectificationOfferWith`（`rectification-in-chat.ts`）；`contractReady()` 对 `rectificationDirectEntry` 放行（`stream-agent-response.ts`）；浏览器自动打开（`frontend/src/hooks/use-consultation-run.ts`）。
|
||||
|
||||
## 3. 根因
|
||||
|
||||
1. **第 0 步只给排盘工具。** `consultationNatalPrepareStep` / `consultationWindowPrepareStep`（`consultation-tools.ts`）在 `stepNumber === 0` 时 `activeTools` 只有排盘工具（BUG-923 定、BUG-937 改 `auto`）。模型必须先排完整盘（43 项），此时已进入解盘状态，才轮到它考虑校正工具。
|
||||
2. **规则正向句埋在禁止句中间。** `RECTIFICATION_OFFER_RULE` 以「用户说你推得不准时」开头，「明确要做校正就调用…explicitRequest=true」夹在「不承诺能收窄」「不在对话里收集经历」之间；模型照禁止句执行。
|
||||
3. **「纠正」撞词。** 同一规则写「按纠正规则认下、改读」，`FOLLOW_UP_CORRECTION_RULE` 讲的是用户「纠正」解读；用户说「生时纠正」被归到「读法问题、不提校正」那一支。
|
||||
4. **没告诉模型校正就在本对话里可开。**
|
||||
5. **为什么没拦住：** `frontend/tests/rectification-explicit-entry-20261012.test.ts` 直接 `tool.execute({explicitRequest:true})` 并用正则查规则文本；「真实模型是否选择调用」只能靠 T5，而 T5 一直是环境缺口。
|
||||
|
||||
## 4. 决策记录
|
||||
|
||||
- 产品负责人 2026-10-13 在 issue #54 选 **B：改规则 + 第 0 步可调用校正工具**（备选 A 只改规则、C 每个新对话加一次小模型意图判断均未选）。
|
||||
- **推翻 BUG-923「第 0 步只放排盘工具」**：第 0 步 `activeTools` 为「排盘工具 + `offer-birth-time-rectification`」（仅当本轮 `ctx.rectificationOffer` 存在，即该工具确实挂上时）。`toolChoice` 仍为 `"auto"`（BUG-282 / BUG-937 不变）。
|
||||
- 保险沿用现有机制，不另造：第 0 步模型既没排盘、也没走直接进入时，`contractReady()` 为假，`stream-agent-response.ts` 已有的 `runtime-contract-retry` 会重试，仍不就绪则按现有降级 / 失败处理。BUG-922 / 923 的「不看盘就写答案」不得因此复发。
|
||||
- 不加关键词 / 正则分类器（BUG-976/977、BUG-1247 的既有决定不变）。
|
||||
- 产品负责人已确认：普通问题（「看看事业」）仍先排盘再解读；「你说得不准」仍是认下改读、不主动拉去校正。
|
||||
|
||||
## 5. 硬红线
|
||||
|
||||
1. 不写任何按关键词判断意图的代码（含正则、词表匹配进入校正）。规则里列举「校正 / 纠正 / 核对出生时间」等说法只作为给模型的说明。
|
||||
2. `toolChoice` 不得改成 `required` 或指名工具（BUG-282 / BUG-937）。
|
||||
3. 第 0 步不得放出排盘与校正之外的工具；第 1 步起不变。
|
||||
4. 不改 `decideRectificationOfferWith` 的资格判断（本人 / 产品开关 / 进行中的校正 / 价格）、不改固定句文案、不改计费。
|
||||
5. 规则只在 `RECTIFICATION_OFFER_RULE` 一处定义（BUG-1248 / 1306），工具描述不复述规则。
|
||||
6. 不改数据库结构；不碰 `frontend/src/app/(app)/page.tsx`；不改 `.gitea/**`。
|
||||
7. 改既有断言按 §7.3 写「原值 / 新值 / 原因」三栏。开工先 grep：`grep -rn "consultationNatalPrepareStep\|consultationWindowPrepareStep\|RECTIFICATION_OFFER_RULE\|纠正规则\|activeTools" frontend/tests tests`（已知：`frontend/tests/consultation-agentic-runtime.test.ts` 「natal first step exposes only the chart calculation tool」与 window 对应用例、`frontend/tests/consult-single-pass-answer-20260927.test.ts`、`frontend/tests/rectification-explicit-entry-20261012.test.ts`）。
|
||||
8. 改了普通对话提示词：按 AGENTS.md §10 需要名人生平回测，本轮无模型凭据，写成环境缺口（见 §10），不得写成通过。
|
||||
|
||||
## 6. 任务分解
|
||||
|
||||
### T1 · 第 0 步放出校正工具
|
||||
|
||||
- `consultationNatalPrepareStep` / `consultationWindowPrepareStep` 改为能知道本轮是否挂了校正工具（例如改成工厂 `consultationNatalPrepareStepFor({ rectificationOffer: boolean })`，或在 `route.ts` 组装时传入），第 0 步 `activeTools` = 排盘工具 +（有则）`RECTIFICATION_OFFER_TOOL_ID`；没挂校正工具时与现在逐字节相同。
|
||||
- 第 0 步模型以**非** `explicitRequest` 方式调用校正工具（还没看过盘就想「顺口提议」）：工具返回一句「先排盘，看过盘再决定要不要提」之类的说明，**不**记为已提议（不占用「同一次对话提议过就不再提」的额度），之后照常排盘。
|
||||
- 验收：
|
||||
- `consultation-agentic-runtime.test.ts` 两条第 0 步断言按三栏改，新增「没挂校正工具时第 0 步只有排盘工具」「挂了时第 0 步是两者」。
|
||||
- 新增运行时测试（用现有假模型 / 假流的写法）：① 第 0 步直接 `explicitRequest=true` → 不调用排盘、正文是固定过渡句、`contractReady` 为真；② 第 0 步什么工具都不调用就写字 → 走 `runtime-contract-retry`，最终答案来自排盘之后；③ 第 0 步非 explicit 调用校正工具 → 不记为已提议，随后排盘、正常作答。
|
||||
|
||||
### T2 · 改写规则
|
||||
|
||||
- `RECTIFICATION_OFFER_RULE` 重排，**正向句放第一句**，大意：「校正就在这个对话里能开。用户这一轮明确要做出生时间校正（说法可能是校正、纠正、核对出生时间、看看出生时间准不准等），第一步就调用 offer-birth-time-rectification 并传 explicitRequest=true，不用先排盘，工具通过后只写那一句过渡。」其后才是「推得不准 → 先分读法 / 时间」与各禁止句。
|
||||
- 把规则里描述「用户不认同解释」那支的「纠正规则」改称「改读规则」（`FOLLOW_UP_CORRECTION_RULE` 的名字与内容不改，只改 `RECTIFICATION_OFFER_RULE` 里引用它的叫法），避免与「生时纠正」撞词。
|
||||
- 提示词总长不得明显增长（BUG-1256 瘦身后的口径）：新规则字数 ≤ 原规则 + 80 字，进度记录写原 / 新字数。
|
||||
- 验收：`rectification-explicit-entry-20261012.test.ts` 里查规则文本的断言按三栏改；新增断言：规则第一句含 `explicitRequest=true`，规则文本不含「纠正规则」。
|
||||
|
||||
### T3 · 记录
|
||||
|
||||
- `docs/BUG_HISTORY.md` 新增 BUG-1317（复发自 BUG-1306：为何旧测试与 T5 没拦住、本次推翻 BUG-923 第 0 步限制的决策、保险机制），BUG-1306 记录补「复发：BUG-1317」。
|
||||
- `docs/tasks/PROGRESS-rectification-step0-entry-20261013.md`、`CHANGELOG.md`。
|
||||
- 真机清单：在 `docs/testing/rectification-explicit-entry-20261012.md` 第 1 步后补一行「新对话第一句：『请你帮我生时纠正』（不带『进行』）」，并加第 9 步「新对话问『看看我今年事业』：照常先排盘解读，不出现校正」；或另写 `docs/testing/rectification-step0-entry-20261013.md` 引用原清单。
|
||||
|
||||
## 7. 让步顺序
|
||||
|
||||
T1 与 T2 都必须做（只做 T2 就是产品没选的 A）。时间不够时 T1 的第③条（非 explicit 调用不占额度）可降为「记录在 BLOCKED.md，回报里说明」。
|
||||
|
||||
## 8. 验收命令分工
|
||||
|
||||
| 谁 | 命令 |
|
||||
| --- | --- |
|
||||
| Grok 自跑 | 前端 `tsc --noEmit`、`npm run lint`；`node --test` 跑 `consultation-agentic-runtime.test.ts`、`consult-single-pass-answer-20260927.test.ts`、`rectification-explicit-entry-20261012.test.ts` 及新增文件（fail 与 cancelled 都为 0）。前端全量 `npm test`、整站构建不跑，以 Claude 为准 |
|
||||
| Claude 验收 | 上述 + 前端全量 `npm test` 与基线逐条比对 + `next build`（`/` 仍 Static，首屏 gzip ±2%）+ 逐行审规则文本 |
|
||||
| 不需要 | `test:db`、Python 快速门（不动 Python、不动数据库访问层） |
|
||||
|
||||
## 9. 开工前置命令
|
||||
|
||||
```bash
|
||||
git fetch origin --prune
|
||||
git worktree add -b codex/rectification-step0-entry-20261013 .worktrees/rectification-step0-entry-20261013 origin/staging
|
||||
cd .worktrees/rectification-step0-entry-20261013
|
||||
git log -1 --format=%h # 应为 963276ca2 或其后代
|
||||
grep -n "^## BUG-" docs/BUG_HISTORY.md | tail -3 # 核对最大号；BUG-1316 已预留给 #55
|
||||
grep -rn "consultationNatalPrepareStep\|consultationWindowPrepareStep\|RECTIFICATION_OFFER_RULE\|纠正规则\|activeTools" frontend/tests tests
|
||||
```
|
||||
|
||||
## 10. 环境缺口（预告）
|
||||
|
||||
- **真实模型是否会在第一步调用校正工具**，本机与 Grok 侧都没有模型凭据（供应商 key 加密存于管理端数据库），无法自动验证；名人生平回测同理。部署后由产品负责人按真机清单用 deepseek-v4-flash 与默认模型各走一遍（每个场景至少两次）。在此之前 BUG-1317 只能是 `fixed-pending-verify`。
|
||||
@@ -0,0 +1,144 @@
|
||||
# TASK · 个人报告开篇「重点」页做成摘要卡（issue #55）
|
||||
|
||||
- 日期：2026-10-13
|
||||
- 来源：Gitea issue #55（agent 循环试点），产品负责人截图：报告第 1/39 章「重点」只有一行粗体标题、一行「重点：当前主运 MD …」、一个「## 重点」大标题和四句数据句，「一点 UI 设计都没有」
|
||||
- 执行方：**Grok（Windows + Docker）**，分支 `codex/report-focus-card-20261013`，只推这个分支
|
||||
- 验收：Claude（Linux）
|
||||
- BUG 编号：**BUG-1316**（开工时核对 `docs/BUG_HISTORY.md` 最大号；写作时最大号为 BUG-1315）
|
||||
|
||||
## 1. 基线
|
||||
|
||||
- 基线 commit：`origin/staging` `856bc850b`
|
||||
- 个人报告走完整数据版：`frontend/src/lib/personal-report-longform-generate.ts` 请求体 `edition: "full_data"` → `scripts/pl9_full_data_export.py::render_full_data_markdown` → `scripts/pl9_reader_export.py::render_pl9_parity_markdown`。
|
||||
- 复现（虚构盘）：
|
||||
|
||||
```bash
|
||||
PYTHONPATH=.:scripts python - <<'EOF'
|
||||
import copy
|
||||
from scripts.pl9_reader_export import _pl9_export_markdown_for_edition
|
||||
from tests.test_report_english_edition import CASES, _packet
|
||||
print(_pl9_export_markdown_for_edition(copy.deepcopy(_packet(CASES["day"])), "full_data")[:1200])
|
||||
EOF
|
||||
```
|
||||
|
||||
## 2. 事故实证（`856bc850b`）
|
||||
|
||||
虚构日盘中文完整数据版开头，与产品截图结构一致：
|
||||
|
||||
```
|
||||
# 印度占星星盘报告
|
||||
重点：当前主运 MD 北交点，子运 AD 木星，次子运 PD 木星。
|
||||
## 重点
|
||||
- 事业第10宫主 土星 落在第9宫，尊贵为入庙，功能吉凶为功能吉星。
|
||||
- 财富第2宫主 … / 婚恋第7宫主 …
|
||||
- 这段时间可能突出这些宫主所守护的主题，不是确定会发生的事。
|
||||
## 出生资料与图盘 …
|
||||
```
|
||||
|
||||
| # | 问题 | 位置 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 「重点」三次：目录第 1 章、「重点：…」一行、`## 重点` | `scripts/pl9_interpretation_packs.py::opening_focus_block` 写死该行；`scripts/pl9_full_data_export.py::_sanitize_pl9_ai_density_markdown` 在首行没有「摘要：/结论：/重点：」时会注入一段固定的「摘要… / ## 重点 1.2.3.」清单，`_insert_opening_focus` 也按这一行去重，所以这一行是为了躲开注入才存在的 |
|
||||
| 2 | 报告标题与正文一样大 | `frontend/src/components/personal-report/personal-report-markdown-view.tsx::markdownComponents` 无 `h1` 映射；`frontend/src/app/globals.css` 中 `.personal-report-md-article h1` 只设字体（注释仍写「像 `.personal-report-cover h1`」，封面已于 09-29 去掉） |
|
||||
| 3 | 行话与车轱辘话：MD / AD / PD 无起止日期；「功能吉凶为功能吉星」；「宫主 火星 落在」多空格 | `opening_focus_block::lord_line`，`_role` 已返回「功能吉星」又被拼在「功能吉凶为」后 |
|
||||
| 4 | 无版式：四句纯文本列表 | 同上；阅读器把首个 `##` 之前的内容当 lead，与 `## 重点` 同在第 0 章卡片里 |
|
||||
|
||||
## 3. 根因
|
||||
|
||||
10-08 `TASK-report-full-data-fix-20261008` T3 按上游加了「开篇重点：当前三级大运 + 三宫宫主」，验收只要求内容存在，没有任何呈现规定；`frontend/DESIGN.md`「Personal report reader」也没有开篇或标题的条目。09-29 去掉报告封面后，标题只剩字体，没人回头补。**不是回归，是从未设计。** `docs/BUG_HISTORY.md` 检索「重点：」「opening_focus」「当前主运 MD」无记录。
|
||||
|
||||
## 4. 决策记录
|
||||
|
||||
- 产品负责人 2026-10-13 在 issue #55 选 **A：做成设计过的摘要卡**（备选 B 改写两三句、C 删页均未选）。
|
||||
- 标题下**写名字和生成日期**；**保留**末尾提醒句「这段时间可能突出这些主题，不是确定会发生的事」。
|
||||
- 问题 1～4 一并修。
|
||||
- 不推翻任何既有红线；不恢复 09-29 去掉的报告封面（只给标题本身样式）。
|
||||
|
||||
## 5. 硬红线
|
||||
|
||||
1. 不改引擎数值（大运、宫主、落宫、尊贵、功能吉凶的判定）；只改呈现。
|
||||
2. 摘要卡的数据由 Python 生成结构化围栏（与 `jyotish-chart` 同一模式），前端只解析和渲染；前端不自算大运或宫主。
|
||||
3. 只做一个新组件；不写第二套 Markdown 渲染、不加 spinner / 骨架（AGENTS.md §6）。
|
||||
4. 旧报告（正文里没有新围栏）必须照旧显示，不崩、不空白。
|
||||
5. 名字只在报告阅读页（本人登录可见）显示；**不得**把名字加进 `frontend/src/lib/report-public-projection.ts` 的公开投影，也不写进任何测试 / 文档 / 提交里的真实姓名（测试用虚构名）。
|
||||
6. 不改数据库结构与迁移；不碰 `frontend/src/app/(app)/page.tsx`；`scripts/jyotish_api_server.py` 不增长。
|
||||
7. 改既有断言按 §7.3 写「原值 / 新值 / 原因」三栏；开工先 grep：`grep -rn "重点：\|## 重点\|Focus: current\|opening_focus\|personal-report-md-lead\|personal-report-md-article h1" tests frontend/tests`（已知：`tests/test_report_full_data_fix.py` 173–174、197 行附近）。
|
||||
8. 不升级依赖，不顺手修别的 warning。
|
||||
|
||||
## 6. 任务分解
|
||||
|
||||
### T1 · 引擎输出结构化「重点」围栏（Python）
|
||||
|
||||
- `opening_focus_block` 改为输出：
|
||||
|
||||
````
|
||||
## 重点
|
||||
```jyotish-focus
|
||||
{"version":1,"periods":[{"level":"md","lord":"Rahu","start":"YYYY-MM-DD","end":"YYYY-MM-DD"},…ad,pd],
|
||||
"domains":[{"key":"career","house":10,"lord":"Saturn","placed":9,"dignity":"…","role":"…"},…wealth/2,relationship/7],
|
||||
"caveat":"这段时间可能突出这些宫主所守护的主题，不是确定会发生的事。"}
|
||||
```
|
||||
````
|
||||
|
||||
起止日期取当前 MD / AD / PD 行自带的 `start` / `end`（`_timing(packet)["dasha"]`，见同文件英文分支已在用 `current_ad.get('start')`）；拿不到的写 `null`，不编。`dignity` / `role` 用现有 `_dignity` / `_role` 的公开词（中文版中文、英文版英文）。
|
||||
- 删掉「重点：当前主运 MD …」那一行（中英两版）。
|
||||
- `_sanitize_pl9_ai_density_markdown` 的「开篇摘要」判断与 `_insert_opening_focus` 的去重，改为识别 `## 重点`（英文 `## Focus`）及其下的 `jyotish-focus` 围栏，**不得**因删掉那一行而重新注入固定清单。
|
||||
- 围栏格式写一个 Python 构造函数（建议放 `scripts/report_chart_block.py` 旁新建 `scripts/report_focus_block.py`，或同文件），附 `FOCUS_FENCE_RE`。
|
||||
- 中文残留门（BUG-1312 的 `_zh_body_residue`）对围栏的处理与 `jyotish-chart` 一致：结构化负载不计入正文。
|
||||
- 验收：
|
||||
- 新测试：虚构日盘中英两版，`## 重点` 下恰有一个可解析的 `jyotish-focus` 围栏；`periods` 三级 lord 与 `_current_lords` 一致、日期与大运表一致；`domains` 三行宫号 10 / 2 / 7；全文不再出现「重点：当前主运」与 `MD ` / `AD ` / `PD `（中文版）；不出现固定清单「先核对出生资料、图盘」。
|
||||
- `tests/test_report_full_data_fix.py` 相关断言按三栏改。
|
||||
- `tests/test_report_chart_blank_columns.py`、`tests/test_report_english_edition.py`、`tests/test_reader_appendix_language.py`、`tests/test_report_reader_main.py` 全绿。
|
||||
|
||||
### T2 · 阅读页摘要卡组件（前端）
|
||||
|
||||
- `frontend/src/lib/` 新增解析器（参照 `report-chart-block.ts::parseReportChartBlock`），`personal-report-markdown-view.tsx` 的 `pre` 分支识别 `jyotish-focus` 渲染新组件 `ReportFocusCard`（放 `frontend/src/components/personal-report/`）。
|
||||
- 版式（写进 DESIGN.md，用现有 token，不新增颜色）：
|
||||
- 第一行「现在走的大运」：主运 · 子运 · 次子运，各写行星中文名 + 起止（`YYYY.MM – YYYY.MM`），三者横排，窄屏换行；中文不出现 MD / AD / PD。
|
||||
- 下面三行：事业 / 财富 / 婚恋。每行左侧领域名，右侧「第 N 宫主 · 行星 · 落第 M 宫」+ 两个小标签（尊贵、功能吉凶），标签沿用站内已有的 pill / badge 样式。
|
||||
- 最后一行提醒句，弱化字色、小一号。
|
||||
- 手机宽度不横向滚动；深浅色都可读。
|
||||
- 解析失败：显示一句「重点数据无效」（英文 "Focus data is invalid"），与图盘无效同口径，不崩。
|
||||
- 导出与公开投影：`frontend/src/lib/report-export-blocks.ts` 把该围栏转成可读文字（参照 `chartBlockText`），导出文件里不得出现原始 JSON；`report-public-projection.ts` 对该围栏的处理与 `jyotish-chart` 一致（按其现有可见性规则），不新增名字字段。
|
||||
- 验收：新测试——用 T1 真实引擎输出生成的 golden（`frontend/tests/fixtures/`，`fixtureProvenance` 写明命令，虚构盘），渲染出三级大运与三行领域、无 `MD`、有提醒句；坏 JSON 渲染失败句；导出文本无 `{"version"`；旧正文（无围栏）快照不变。
|
||||
|
||||
### T3 · 标题样式 + 名字与日期（前端）
|
||||
|
||||
- `markdownComponents` 增加 `h1` 映射与样式：显示字体、明显大于 h2、上下留白；去掉 globals.css 里指向已删封面的过时注释。
|
||||
- 标题下一行小字：`{名字} · 生成于 YYYY-MM-DD`。名字取报告文档 `subject.displayName`（`personal-report-generation.ts` 已写入），日期取 `createdAt`；若阅读页当前拿不到 `displayName`，从报告读取接口带出（仅本人可见的接口，不改表结构）。没有名字时只写日期；标题本身已含名字（引擎 `_pl9_public_report_title` 在有名字时会写「X的印度占星星盘报告」）时不重复名字。
|
||||
- 英文版：`{name} · Generated YYYY-MM-DD`。
|
||||
- 验收：前端测试覆盖「有名字」「无名字」「标题已含名字」三种；`tsc --noEmit` 0 错、`npm run lint` 0 error。
|
||||
|
||||
### T4 · 记录
|
||||
|
||||
- `frontend/DESIGN.md`「Personal report reader」加「开篇重点卡」与「报告标题」两条（版式、token、旧报告兼容、导出口径）。
|
||||
- `docs/BUG_HISTORY.md` 新增 **BUG-1316**（报告开篇「重点」页无设计：三重「重点」、标题无样式、MD/AD/PD 行话、数据句堆砌）。
|
||||
- `docs/tasks/PROGRESS-report-focus-card-20261013.md`、`CHANGELOG.md`。
|
||||
- 真机清单 `docs/testing/report-focus-card-20261013.md`（已随本任务书提供，可补充）。
|
||||
|
||||
## 7. 让步顺序
|
||||
|
||||
T1 → T2 → T3 → T4。T3 的「名字」若需要改报告读取接口且发现牵涉数据库或公开投影，先只做日期 + 标题样式，名字写进 `BLOCKED.md` 并在回报里说明，由 Claude 判断是否 @产品负责人。
|
||||
|
||||
## 8. 验收命令分工
|
||||
|
||||
| 谁 | 命令 |
|
||||
| --- | --- |
|
||||
| Grok 自跑 | `python -m pytest tests/test_report_full_data_fix.py tests/test_report_chart_blank_columns.py tests/test_report_english_edition.py tests/test_reader_appendix_language.py tests/test_report_reader_main.py -q`；前端 `tsc --noEmit`、`npm run lint`、改到 / 新增的前端测试单文件（看 fail 与 cancelled 都为 0）。前端全量 `npm test`、Python 快速门、整站构建**不跑**，以 Claude 为准 |
|
||||
| Claude 验收 | 上述全部 + 全量 `pytest` 与基线逐条比对 + 前端全量 `npm test` + `next build`（`/` 仍 Static，首屏 gzip ±2%）+ 重生成虚构盘中英报告核对围栏 |
|
||||
| 不需要 | `test:db`（不动数据库访问层；若 T3 改了报告读取接口的查询，则需要并按 `windows-known-failures.txt` 比对） |
|
||||
|
||||
## 9. 开工前置命令
|
||||
|
||||
```bash
|
||||
git fetch origin --prune
|
||||
git worktree add -b codex/report-focus-card-20261013 .worktrees/report-focus-card-20261013 origin/staging
|
||||
cd .worktrees/report-focus-card-20261013
|
||||
git log -1 --format=%h # 应为 856bc850b 或其后代
|
||||
grep -n "^## BUG-" docs/BUG_HISTORY.md | tail -3 # 核对最大号
|
||||
grep -rn "重点：\|## 重点\|Focus: current\|opening_focus\|personal-report-md-lead\|personal-report-md-article h1" tests frontend/tests
|
||||
```
|
||||
|
||||
## 10. 环境缺口（预告）
|
||||
|
||||
- 只对**新生成**的报告生效；旧报告照旧显示。
|
||||
- 浏览器级观感留给 `docs/testing/report-focus-card-20261013.md`。
|
||||
@@ -5,6 +5,7 @@
|
||||
| 步 | 怎么做 | 通过标准 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 新对话第一句：「请你帮我进行生时纠正」 | 直接打开校正。这一轮不写解读，不用点卡。过渡只有一句 |
|
||||
| 1b | 新对话第一句：「请你帮我生时纠正」（不带「进行」） | 同样直接打开校正，不先出「已完成几步」再写解读。BUG-1317 |
|
||||
| 2 | 另开三条新对话，分别说「帮我校正出生时间」「想核对一下出生时间准不准」「我出生时间是估的，帮我对一下」 | 三次都直接打开，不先出卡 |
|
||||
| 3 | 新对话先问一件普通的事，答完后再说「请帮我做生时校正」 | 这一轮直接打开，不把刚才的解读再写一遍 |
|
||||
| 4 | 新对话问事业，答完后说「你说我事业不顺，我觉得挺顺的」 | 认下、改读。不进入校正，下面没有提议卡 |
|
||||
@@ -12,5 +13,6 @@
|
||||
| 6 | 换到一个家人档案，第一句就说「请帮我校正出生时间」 | 一句「给家人校正暂时还不支持」。不打开校正 |
|
||||
| 7 | 在校正开关关闭，或价格暂时不可用时，本人说「请帮我做生时校正」 | 一句「出生时间核对这会儿还做不了。」不沉默，不写价格，不写内部原因。构造不了这一步就在进度里标环境缺口，不要改开关去试 |
|
||||
| 8 | 申报出生时段的本人档案，问一件普通的事，不要提校正 | 正文不写大运、子运的起止年月日，也不承诺能收窄出生时间 |
|
||||
| 9 | 新对话问「看看我今年事业」 | 照常先排盘再解读，不出现校正，下面没有提议卡 |
|
||||
|
||||
做不了的两句和家人那句以界面上的原句为准。点数：直接进入的那一轮不按解读扣咨询点；校正本身仍按原来的开案扣费。
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
# 真机清单 · 报告开篇「重点」摘要卡（issue #55，BUG-1316）
|
||||
|
||||
部署到 staging 后，**重新生成一份个人报告**（旧报告不会变），手机和电脑各看一遍。
|
||||
|
||||
1. 第 1 章最上面是报告标题，明显比正文大；标题下一行小字写「名字 · 生成于 年-月-日」（没有名字的盘只写日期；标题里已有名字时不重复）。
|
||||
2. 「重点」只出现一次（目录里那一条除外），没有单独一行「重点：当前主运 MD …」。
|
||||
3. 第一行写「现在走的大运」：主运、子运、次子运各是哪颗星、从哪年哪月到哪年哪月；没有 MD / AD / PD 字样。
|
||||
4. 下面三行：事业、财富、婚恋，各写「第几宫主、哪颗星、落第几宫」，后面跟两个小标签（强弱、吉凶）；没有「功能吉凶为功能吉星」这种重复。
|
||||
5. 最后一行小字提醒「这段时间可能突出这些主题，不是确定会发生的事」。
|
||||
6. 手机上不需要左右滑；深色、浅色模式都看得清。
|
||||
7. 切到 English：同样的卡片，英文标签。
|
||||
8. 导出一份文件，打开后「重点」是文字，不是一串花括号代码。
|
||||
9. 打开一份**以前**生成的旧报告：照旧能看，不白屏。
|
||||
@@ -344,6 +344,7 @@ Radii have two visual steps. Controls use 8px (`--radius-md`; `--radius-xs` and
|
||||
- **Queue:** one pending card (`.composer-queue`) sits above the field while an answer is in flight. Copy: “已排队，回答结束后发出”, plus the text and a 44px “撤回”. A second Enter appends to the same card with a newline. Successful settlement sends it; stop, failure, or recovery puts the text back in the field. The send button is disabled while a card is waiting. No spinner.
|
||||
- **Accessibility:** persistent label where practical; composer has an explicit accessible label.
|
||||
- **One composer:** the rectification surface renders the same `ChatComposer` as the main chat; there is no second composer. A surface that owns its own draft passes it as `value`; the main chat reads the draft store. Both count down from the same 500-character ceiling through `CharacterRemaining`, which the composer renders inline and only once `characterRemainingVisible()` is true — it no longer has a permanent container. Controls that belong to the composer go through the `toolbar` slot; nothing is stacked below it.
|
||||
- **Inner field corners:** the textarea inside `.composer` has `border-radius: 0`. Rounding stays on the outer `.composer` only. The field has no horizontal padding, so a radius on the textarea itself clips the first glyph's left edge (BUG-1311).
|
||||
|
||||
### Answer start anchor
|
||||
|
||||
|
||||
@@ -25,8 +25,8 @@ Jyotisha 的可见文案是产品的一部分。正确性红线（真实性、
|
||||
|
||||
## 生时校正从对话进入（2026-10-07，BUG-1247～1251；2026-10-12，BUG-1306）
|
||||
|
||||
- **何时提议**：用户说推得不准时先分清读法问题和时间问题。只是不认同某个解释，按纠正规则认下、改读，不提校正。不承诺能收窄出生时间，不在对话里收集经历做校正。说出过去的具体事情和盘对不上、说出生时间是估的或记不准、但没有明确要做校正，才调用提议工具。同一次对话提议过、用户没接，不再主动提；用户自己再要求时传 `userAsked=true`。规则只定义在 `consultation-thinking-plan.ts` 的 `RECTIFICATION_OFFER_RULE`。不用关键词判断。
|
||||
- **明确要求则直接进入**：用户这一轮明确要做校正，由模型判断，不用关键词。服务端放行后直接打开校正：不先写解读，不用点卡。过渡只有一句「好，我们开始核对出生时间。」已经有一次没做完的，直接接着做那一次，不新开。开案还没成功时，回答下面仍是普通提议卡，不说「已经开始」；打开失败可以再点「开始核对出生时间」。开案并绑定来源之后才改成「已经开始」。
|
||||
- **何时提议**：校正就在这个对话里能开。用户说推得不准时先分清读法问题和时间问题。只是不认同某个解释，按改读规则认下、改读，不提校正。不承诺能收窄出生时间，不在对话里收集经历做校正。说出过去的具体事情和盘对不上、说出生时间是估的或记不准、但没有明确要做校正，要先看过盘再提议。同一次对话提议过、用户没接，不再主动提；用户自己再要求时传 `userAsked=true`。还没看盘就顺口提议，不算已经提议过。规则只定义在 `consultation-thinking-plan.ts` 的 `RECTIFICATION_OFFER_RULE`。不用关键词判断。
|
||||
- **明确要求则直接进入**：用户这一轮明确要做校正（校正、纠正、核对出生时间都算），由模型判断，不用关键词。第一步就可以打开，不用先排盘写解读。服务端放行后直接打开校正，不用点卡。过渡只有一句「好，我们开始核对出生时间。」已经有一次没做完的，直接接着做那一次，不新开。开案还没成功时，回答下面仍是普通提议卡，不说「已经开始」；打开失败可以再点「开始核对出生时间」。开案并绑定来源之后才改成「已经开始」。
|
||||
- **做不了必须说一句**：开关关着，或暂时没有价格，都说「出生时间核对这会儿还做不了。」不写内部原因，不写价格，不得沉默。家人档案说「给家人校正暂时还不支持」，不开案。有进行中的校正但这次打不开原来的会话，说「可在历史对话里接着做。」
|
||||
- **正文怎么提**（没有明确要求、只是时间可能不准）：一句，放在最后一段（例：「如果想确认出生时间准不准，可以用下面的卡片，答几道过去经历的题核对一下。」），不写价格和题数——卡片上写。
|
||||
- **卡片**：「可以用几道过去经历的题，核对一下你的出生时间。大约 N 题，会用掉 M 点；开始答第一题时才扣。」按钮「开始核对出生时间」；已开始（开案并绑定来源之后，不是结算当时）「出生时间核对已经开始。」/「继续核对出生时间」。点数来自 `feature_pricing`，不写死。
|
||||
|
||||
@@ -1215,11 +1215,17 @@ export async function POST(request: Request) {
|
||||
};
|
||||
const natalStreamOptions = {
|
||||
...streamOptions,
|
||||
prepareStep: consultationNatalPrepareStep,
|
||||
prepareStep: (input: { stepNumber: number }) => consultationNatalPrepareStep({
|
||||
stepNumber: input.stepNumber,
|
||||
rectificationOffer: true,
|
||||
}),
|
||||
};
|
||||
const windowStreamOptions = {
|
||||
...streamOptions,
|
||||
prepareStep: consultationWindowPrepareStep,
|
||||
prepareStep: (input: { stepNumber: number }) => consultationWindowPrepareStep({
|
||||
stepNumber: input.stepNumber,
|
||||
rectificationOffer: true,
|
||||
}),
|
||||
};
|
||||
const answerPhaseSignal = runClock.answerSignal;
|
||||
const startAnswerPhase = () => {
|
||||
|
||||
@@ -1857,7 +1857,7 @@ section[popover]:has(> [data-sonner-toaster]), section[popover][aria-label^="页
|
||||
.composer-tools { min-width: 0; display: flex; align-items: center; gap: var(--space-2); }
|
||||
.composer-row-end { display: flex; flex: 1; align-items: center; justify-content: flex-end; gap: var(--space-3); }
|
||||
.composer:focus-within { border-color: var(--color-action); box-shadow: 0 0 0 3px color-mix(in srgb, var(--color-action) 15%, transparent); }
|
||||
.composer textarea { width: 100%; min-width: 0; min-height: 28px; max-height: 148px; resize: none; padding: var(--space-1) 0 0; border: 0; outline: 0; background: transparent; color: var(--color-ink); line-height: 1.5; font-size: var(--type-body-md); }
|
||||
.composer textarea { width: 100%; min-width: 0; min-height: 28px; max-height: 148px; resize: none; padding: var(--space-1) 0 0; border: 0; outline: 0; background: transparent; color: var(--color-ink); line-height: 1.5; font-size: var(--type-body-md); border-radius: 0; }
|
||||
.composer .composer-row-end > button { width: 36px; height: 36px; display: grid; flex: 0 0 auto; place-items: center; border: 0; color: var(--color-on-action-fill); cursor: pointer; transition: background-color 120ms ease-out, transform 120ms ease-out; border-radius: 999px; background: var(--color-action-fill); }
|
||||
.composer .composer-row-end > button:disabled { opacity: 1; background: var(--color-action-fill-disabled); color: var(--color-on-action-fill-disabled); }
|
||||
.composer .composer-stop { background: var(--color-action-fill); }
|
||||
|
||||
@@ -459,7 +459,7 @@ export function natalAnswerShapeInstruction(): string {
|
||||
* Never decided from keywords. Defined here once; the offer tool names the
|
||||
* same parameters and does not restate this rule.
|
||||
*/
|
||||
export const RECTIFICATION_OFFER_RULE = "出生时间核对：用户说你推得不准时，先分清是读法问题还是时间问题。只是不认同某个解释，按纠正规则认下、改读，不提校正。不承诺能收窄出生时间，不在对话里收集经历做校正。用户这一轮明确要做校正，就在写回答之前调用 offer-birth-time-rectification 并传 explicitRequest=true；工具通过后只写那一句过渡，不写解读。用户说出过去某件具体的事和盘对不上、说自己的出生时间是估的或记不准、但没有明确要做校正，才在写回答之前调用 offer-birth-time-rectification，再按工具结果在正文里用一句话提一下（不写价格和题数，卡片上有）。同一次对话提议过、用户没接，就不再主动提；用户自己再要求时调用并传 userAsked=true。工具说不能提供时（比如问的是家人），照工具说明用一句话说清楚。";
|
||||
export const RECTIFICATION_OFFER_RULE = "校正就在这个对话里能开：用户这一轮明确要做出生时间校正（说法可能是校正、纠正、核对出生时间、看看出生时间准不准等），第一步就调用 offer-birth-time-rectification 并传 explicitRequest=true，不用先排盘，工具通过后只写那一句过渡，不写解读。用户说你推得不准时，先分清是读法问题还是时间问题。只是不认同某个解释，按改读规则认下、改读，不提校正。不承诺能收窄出生时间，不在对话里收集经历做校正。用户说出过去某件具体的事和盘对不上、说自己的出生时间是估的或记不准、但没有明确要做校正，才在看过盘之后调用 offer-birth-time-rectification，再按工具结果在正文里用一句话提一下（不写价格和题数，卡片上有）。同一次对话提议过、用户没接，就不再主动提；用户自己再要求时调用并传 userAsked=true。工具说不能提供时（比如问的是家人），照工具说明用一句话说清楚。";
|
||||
|
||||
/** D4 / BUG-1166: the user corrects an earlier reading; acknowledge it, never defend the reading. */
|
||||
export const FOLLOW_UP_CORRECTION_RULE = "用户纠正了前面的判断（比如说父亲其实不常在身边）：先认下这件事，再只说盘上真正对得上的那几条、原来哪句读偏了；盘本身分不出的，直说「盘本身分不出这一点」，不把普通配置说成必然；不为原判断辩护。";
|
||||
|
||||
@@ -176,34 +176,41 @@ export const MAX_EVIDENCE_LOOKUPS_PER_TURN = 3;
|
||||
export const CONSULTATION_WINDOW_CALC_TOOL_ID = "run-jyotish-window-consultation";
|
||||
|
||||
/**
|
||||
* Step 0 exposes only the natal chart tool. Some thinking-mode providers
|
||||
* reject named and required toolChoice (BUG-282, BUG-937); the first step
|
||||
* therefore narrows with activeTools and leaves the choice as auto. Later
|
||||
* steps stay auto so the model can write after the request-scoped
|
||||
* calculation is in hand.
|
||||
* Step 0 narrows with activeTools and leaves toolChoice auto. Thinking-mode
|
||||
* providers reject named and required toolChoice (BUG-282, BUG-937).
|
||||
* When this turn mounted the rectification offer, that tool is available
|
||||
* beside the chart tool so an explicit request can open before a reading
|
||||
* (BUG-1317). Without it, step 0 is still only the chart tool (BUG-923).
|
||||
* Later steps stay auto.
|
||||
*
|
||||
* Window and general agents must not share this hook: they do not own this tool.
|
||||
* Window and general agents must not share the natal hook.
|
||||
*/
|
||||
export function consultationNatalPrepareStep(input: { stepNumber: number }) {
|
||||
return input.stepNumber === 0
|
||||
? {
|
||||
export function consultationNatalPrepareStep(input: { stepNumber: number; rectificationOffer?: boolean }) {
|
||||
if (input.stepNumber !== 0) return { toolChoice: "auto" as const };
|
||||
if (!input.rectificationOffer) {
|
||||
return {
|
||||
activeTools: [CONSULTATION_NATAL_CALC_TOOL_ID],
|
||||
toolChoice: "auto" as const,
|
||||
}
|
||||
: {
|
||||
toolChoice: "auto" as const,
|
||||
};
|
||||
}
|
||||
return {
|
||||
activeTools: [CONSULTATION_NATAL_CALC_TOOL_ID, RECTIFICATION_OFFER_TOOL_ID],
|
||||
toolChoice: "auto" as const,
|
||||
};
|
||||
}
|
||||
|
||||
export function consultationWindowPrepareStep(input: { stepNumber: number }) {
|
||||
return input.stepNumber === 0
|
||||
? {
|
||||
export function consultationWindowPrepareStep(input: { stepNumber: number; rectificationOffer?: boolean }) {
|
||||
if (input.stepNumber !== 0) return { toolChoice: "auto" as const };
|
||||
if (!input.rectificationOffer) {
|
||||
return {
|
||||
activeTools: [CONSULTATION_WINDOW_CALC_TOOL_ID],
|
||||
toolChoice: "auto" as const,
|
||||
}
|
||||
: {
|
||||
toolChoice: "auto" as const,
|
||||
};
|
||||
}
|
||||
return {
|
||||
activeTools: [CONSULTATION_WINDOW_CALC_TOOL_ID, RECTIFICATION_OFFER_TOOL_ID],
|
||||
toolChoice: "auto" as const,
|
||||
};
|
||||
}
|
||||
|
||||
const CONSULTATION_DOMAIN_DURATION_MS = 31_000;
|
||||
@@ -1174,6 +1181,12 @@ function createRectificationOfferTool(ctx: Readonly<{ state: ConsultationRuntime
|
||||
}
|
||||
return { offered: false as const, note: "已经在打开。不要再写解读。" };
|
||||
}
|
||||
if (input.explicitRequest !== true && !ctx.state.consultationToolCompleted) {
|
||||
return {
|
||||
offered: false as const,
|
||||
note: "先排盘，看过盘再决定要不要提。这次不算已经提议过。",
|
||||
};
|
||||
}
|
||||
if (hook.alreadyOffered && input.userAsked !== true && input.explicitRequest !== true) {
|
||||
return { offered: false as const, reason: "already_offered_in_session", note: "这次对话里已经提议过一次，用户没接。不再主动提校正，正常回答。" };
|
||||
}
|
||||
|
||||
@@ -62,6 +62,10 @@ test("otp and composer keep their existing safe sizes", () => {
|
||||
assert.match(ruleFor(".composer textarea {"), /font-size:\s*var\(--type-body-md\)/);
|
||||
});
|
||||
|
||||
test("composer textarea radius is 0 because a 0 left padding clips the first glyph on rounded corners", () => {
|
||||
assert.match(ruleFor(".composer textarea {"), /border-radius:\s*0/);
|
||||
});
|
||||
|
||||
test("personal-report tables are not retargeted by the chat wide-table rule", () => {
|
||||
const mobile = css.slice(css.indexOf("@media (max-width: 767px)"));
|
||||
const wide = mobile.match(
|
||||
|
||||
@@ -679,26 +679,40 @@ test("guided-topic entrypoint ignores a model domain rewrite instead of executin
|
||||
|
||||
test("natal first step exposes only the chart calculation tool", () => {
|
||||
assert.equal(CONSULTATION_NATAL_CALC_TOOL_ID, "run-jyotish-consultation");
|
||||
// 原值: 第 0 步 toolChoice "required" / 新值: "auto"
|
||||
// 原因: BUG-282 供应商拒收 thinking 模式下的 required，BUG-937 撤回
|
||||
// 原值: 第 0 步 toolChoice "required"，后来改为只有排盘工具且 toolChoice "auto"
|
||||
// 新值: 没挂校正工具时第 0 步仍只有排盘工具；挂了时是排盘工具和 offer-birth-time-rectification。toolChoice 仍是 "auto"。第 1 步不收窄。
|
||||
// 原因: BUG-937 保持 auto；BUG-1317 按产品选择，第 0 步在工具确实挂上时可以打开校正。
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 0 }), {
|
||||
activeTools: ["run-jyotish-consultation"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 1 }), {
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 0, rectificationOffer: false }), {
|
||||
activeTools: ["run-jyotish-consultation"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 0, rectificationOffer: true }), {
|
||||
activeTools: ["run-jyotish-consultation", "offer-birth-time-rectification"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationNatalPrepareStep({ stepNumber: 1, rectificationOffer: true }), {
|
||||
toolChoice: "auto",
|
||||
});
|
||||
});
|
||||
|
||||
test("window first step requires the window consultation tool", () => {
|
||||
assert.equal(CONSULTATION_WINDOW_CALC_TOOL_ID, "run-jyotish-window-consultation");
|
||||
// 原值: 第 0 步 toolChoice "required" / 新值: "auto"
|
||||
// 原因: BUG-282 供应商拒收 thinking 模式下的 required，BUG-937 撤回
|
||||
// 原值: 第 0 步 toolChoice "required"，后来改为只有窗口排盘工具且 toolChoice "auto"
|
||||
// 新值: 没挂校正工具时第 0 步仍只有窗口排盘工具；挂了时再加上 offer-birth-time-rectification。toolChoice 仍是 "auto"。
|
||||
// 原因: 与本命同一条 BUG-1317 决定，申报时段也要能在第一步打开校正。
|
||||
assert.deepEqual(consultationWindowPrepareStep({ stepNumber: 0 }), {
|
||||
activeTools: ["run-jyotish-window-consultation"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationWindowPrepareStep({ stepNumber: 1 }), {
|
||||
assert.deepEqual(consultationWindowPrepareStep({ stepNumber: 0, rectificationOffer: true }), {
|
||||
activeTools: ["run-jyotish-window-consultation", "offer-birth-time-rectification"],
|
||||
toolChoice: "auto",
|
||||
});
|
||||
assert.deepEqual(consultationWindowPrepareStep({ stepNumber: 1, rectificationOffer: true }), {
|
||||
toolChoice: "auto",
|
||||
});
|
||||
});
|
||||
|
||||
@@ -233,8 +233,12 @@ test("consult streams reserve an answer budget and keep provider thinking on a s
|
||||
route.indexOf("const natalStreamOptions = {"),
|
||||
);
|
||||
assert.doesNotMatch(sharedStreamOptions, /prepareStep/);
|
||||
assert.match(route, /prepareStep: consultationNatalPrepareStep/);
|
||||
assert.match(route, /prepareStep: consultationWindowPrepareStep/);
|
||||
// 原值：prepareStep: consultationNatalPrepareStep / consultationWindowPrepareStep，函数本身不知道校正工具在不在。
|
||||
// 新值：路由把 rectificationOffer: true 传进去，因为这两条路线都会挂上校正工具。
|
||||
// 原因：BUG-1317，第 0 步在工具挂上时要能打开校正；没传时函数仍只留排盘工具。
|
||||
assert.match(route, /prepareStep: \(input: \{ stepNumber: number \}\) => consultationNatalPrepareStep\(\{/);
|
||||
assert.match(route, /prepareStep: \(input: \{ stepNumber: number \}\) => consultationWindowPrepareStep\(\{/);
|
||||
assert.match(route, /rectificationOffer: true/);
|
||||
assert.match(route, /streamWithOverflowRetry\(agent, natalStreamOptions\)/);
|
||||
assert.match(route, /streamWithOverflowRetry\(agent, windowStreamOptions\)/);
|
||||
assert.match(
|
||||
|
||||
@@ -72,8 +72,14 @@ function offerTool(options: {
|
||||
alreadyOffered?: boolean;
|
||||
decide?: () => Promise<OfferDecision>;
|
||||
loadResumableSessionId?: () => Promise<string | null>;
|
||||
/** False only for a step-0 call that has not seen the chart yet. */
|
||||
chartReady?: boolean;
|
||||
} = {}) {
|
||||
const state = createConsultationRuntimeState();
|
||||
if (options.chartReady !== false) {
|
||||
state.consultationToolCompleted = true;
|
||||
state.consultationToolSuccessCount = 1;
|
||||
}
|
||||
let decisions = 0;
|
||||
let loads = 0;
|
||||
const tools = createConsultationTools({
|
||||
@@ -520,6 +526,111 @@ test("an ordinary consultation still retries once when the calculation never fin
|
||||
assert.equal(events.some((event) => event.type === "activity" && event.label === "正在补齐方法与计算步骤"), true);
|
||||
});
|
||||
|
||||
test("step 0 explicit request opens rectification without calculating a chart", async () => {
|
||||
const fresh = offerTool({ chartReady: false });
|
||||
const result = await fresh.tool.execute({ explicitRequest: true });
|
||||
assert.equal(result.directEntry, "new");
|
||||
assert.equal(fresh.state.consultationToolCallCount, 0);
|
||||
assert.equal(fresh.state.consultationToolCompleted, false);
|
||||
assert.equal(fresh.state.rectificationDirectEntry?.sentence, RECTIFICATION_DIRECT_NEW_COPY);
|
||||
let contractRetries = 0;
|
||||
const response = streamAgentResponse({
|
||||
runId: "run-step0-explicit",
|
||||
requestId: REQUEST_ID,
|
||||
state: fresh.state,
|
||||
requireTool: true,
|
||||
pass4Mode: "verified_chart",
|
||||
stepScopedAnswer: true,
|
||||
toolStatus: () => "ready",
|
||||
receipt: () => receipt(fresh.state),
|
||||
stream: (async function* () {
|
||||
yield { type: "text-delta", payload: { text: "我先看看盘，然后写一段解读。" } };
|
||||
yield STOP_FINISH;
|
||||
})(),
|
||||
retry: async () => {
|
||||
contractRetries += 1;
|
||||
return (async function* () { yield STOP_FINISH; })();
|
||||
},
|
||||
});
|
||||
const events = await readStream(response);
|
||||
assert.equal(contractRetries, 0);
|
||||
assert.equal(visibleAnswer(events), RECTIFICATION_DIRECT_NEW_COPY);
|
||||
assert.equal(events.some((event) => event.type === "run.completed" && event.responseKind === "smalltalk"), true);
|
||||
});
|
||||
|
||||
test("step 0 text without a tool still retries into a chart answer", async () => {
|
||||
const state = createConsultationRuntimeState();
|
||||
let contractRetries = 0;
|
||||
const response = streamAgentResponse({
|
||||
runId: "run-step0-empty",
|
||||
requestId: REQUEST_ID,
|
||||
state,
|
||||
requireTool: true,
|
||||
pass4Mode: "verified_chart",
|
||||
stepScopedAnswer: true,
|
||||
toolStatus: () => "ready",
|
||||
receipt: () => receipt(state),
|
||||
stream: (async function* () {
|
||||
yield { type: "text-delta", payload: { text: "还没排盘就想写。" } };
|
||||
yield STOP_FINISH;
|
||||
})(),
|
||||
retry: async () => {
|
||||
contractRetries += 1;
|
||||
state.consultationToolCompleted = true;
|
||||
state.consultationToolSuccessCount = 1;
|
||||
return (async function* () {
|
||||
yield { type: "text-delta", payload: { text: "事业方向可以看。" } };
|
||||
yield STOP_FINISH;
|
||||
})();
|
||||
},
|
||||
});
|
||||
const events = await readStream(response);
|
||||
assert.equal(contractRetries, 1);
|
||||
assert.equal(visibleAnswer(events), "事业方向可以看。");
|
||||
assert.equal(state.rectificationDirectEntry, undefined);
|
||||
assert.equal(events.some((event) => event.type === "activity" && event.label === "正在补齐方法与计算步骤"), true);
|
||||
});
|
||||
|
||||
test("a soft offer before the chart is not recorded, then a chart answer can still offer", async () => {
|
||||
const fresh = offerTool({ chartReady: false });
|
||||
const early = await fresh.tool.execute({});
|
||||
assert.equal(early.offered, false);
|
||||
assert.match(String(early.note), /先排盘，看过盘再决定要不要提/);
|
||||
// 记在局部上再断言。直接断言 state 上的字段会把它收成永远是空，排盘后再读就对不上类型。
|
||||
const offerBeforeChart = fresh.state.rectificationOffer;
|
||||
assert.equal(offerBeforeChart, undefined);
|
||||
assert.equal(fresh.state.rectificationDirectEntry, undefined);
|
||||
assert.equal(fresh.decisions(), 0);
|
||||
fresh.state.consultationToolCompleted = true;
|
||||
fresh.state.consultationToolSuccessCount = 1;
|
||||
const later = await fresh.tool.execute({});
|
||||
assert.equal(later.offered, true);
|
||||
const offerAfterChart = fresh.state.rectificationOffer;
|
||||
assert.equal(offerAfterChart?.status, "offered");
|
||||
assert.equal(offerAfterChart?.autoOpen, undefined);
|
||||
assert.equal(fresh.decisions(), 1);
|
||||
const response = streamAgentResponse({
|
||||
runId: "run-step0-soft",
|
||||
requestId: REQUEST_ID,
|
||||
state: fresh.state,
|
||||
requireTool: true,
|
||||
pass4Mode: "verified_chart",
|
||||
stepScopedAnswer: true,
|
||||
toolStatus: () => "ready",
|
||||
receipt: () => receipt(fresh.state),
|
||||
stream: (async function* () {
|
||||
yield { type: "text-delta", payload: { text: "事业方向可以看。" } };
|
||||
yield STOP_FINISH;
|
||||
})(),
|
||||
retry: async () => {
|
||||
throw new Error("chart contract should already be ready");
|
||||
},
|
||||
});
|
||||
const events = await readStream(response);
|
||||
assert.equal(visibleAnswer(events), "事业方向可以看。");
|
||||
assert.equal(visibleAnswer(events).includes(RECTIFICATION_DIRECT_NEW_COPY), false);
|
||||
});
|
||||
|
||||
test("the offer rule is defined once, and direct entry settles with the free completion", () => {
|
||||
const definitions = walkSources(fileURLToPath(new URL("../src/", import.meta.url))).filter((file) => (
|
||||
readFileSync(file, "utf8").includes("export const RECTIFICATION_OFFER_RULE")
|
||||
@@ -530,7 +641,12 @@ test("the offer rule is defined once, and direct entry settles with the free com
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /不在对话里收集经历做校正/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /explicitRequest=true/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /只写那一句过渡，不写解读/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /只是不认同某个解释，按纠正规则认下、改读，不提校正/);
|
||||
// 原值：规则以「用户说你推得不准时」开头，并写「按纠正规则认下」。
|
||||
// 新值：第一句就写 explicitRequest=true，并改称「改读规则」。全文不含「纠正规则」。
|
||||
// 原因：BUG-1317，「生时纠正」和「纠正解读」撞词，正向句被埋在禁止句中间。
|
||||
assert.match(RECTIFICATION_OFFER_RULE.split("。")[0] ?? "", /explicitRequest=true/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /按改读规则认下、改读，不提校正/);
|
||||
assert.doesNotMatch(RECTIFICATION_OFFER_RULE, /纠正规则/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /userAsked=true/);
|
||||
|
||||
const tools = src("../src/mastra/consultation-tools.ts");
|
||||
|
||||
@@ -117,6 +117,11 @@ test("the server decides whether a card may be shown: self, product on, no case
|
||||
|
||||
function offerTool(options: { alreadyOffered?: boolean; decide?: () => Promise<{ ok: true; creditCost: number; questionEstimate: number } | { ok: false; reason: "not_self" | "product_disabled" | "case_in_progress" | "pricing_unavailable" }> } = {}) {
|
||||
const state = createConsultationRuntimeState();
|
||||
// 原值：建出来还没排盘也能直接提议。
|
||||
// 新值：这些用例表示已经看过盘，所以先标计算完成。
|
||||
// 原因：BUG-1317，还没排盘的顺口提议不算已经提议过。
|
||||
state.consultationToolCompleted = true;
|
||||
state.consultationToolSuccessCount = 1;
|
||||
const tools = createConsultationTools({
|
||||
userId: "user-fictional",
|
||||
sessionId: SOURCE_SESSION,
|
||||
@@ -194,7 +199,10 @@ test("the C2 rule is defined once and reaches first turns, follow-ups and declar
|
||||
assert.ok(followUpAnswerShapeInstruction().includes(RECTIFICATION_OFFER_RULE));
|
||||
const route = readFileSync(new URL("../src/app/api/consult/route.ts", import.meta.url), "utf8");
|
||||
assert.match(route, /这只是粗看。" \+ RECTIFICATION_OFFER_RULE;/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /只是不认同某个解释，按纠正规则认下、改读，不提校正/);
|
||||
// 原值：/按纠正规则认下、改读，不提校正/
|
||||
// 新值：/按改读规则认下、改读，不提校正/
|
||||
// 原因：BUG-1317，避免「生时纠正」被读成「用户在纠正解读」。
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /只是不认同某个解释，按改读规则认下、改读，不提校正/);
|
||||
assert.match(RECTIFICATION_OFFER_RULE, /userAsked=true/);
|
||||
});
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ Claude（开发机，Linux）负责规划与验收，Grok Build（产品负责
|
||||
| --- | --- | --- |
|
||||
| `agent/待规划` | Claude：诊断 → 任务书推 staging | `agent/待执行` 或 `agent/需拍板` |
|
||||
| `agent/待执行` | Grok：按任务书在 `codex/*` 实现、自测、推分支 | `agent/待验收` 或 `agent/需拍板` |
|
||||
| `agent/待验收` | Claude：只验 Grok 回报的 SHA | 通过 → 推 staging → `agent/部署中`；不通过 → 修复单 → `agent/待执行`（打回 2 次 → `agent/需拍板`） |
|
||||
| `agent/待验收` | Claude：只验 Grok 回报的 SHA | 通过 → 推 staging → `agent/部署中`；不通过 → 修复单 → `agent/待执行`（打回 2 次 → `agent/需拍板`）；只是落后于 staging 且合并只碰文档时，Claude 自己合并，不打回、不计次数（2026-10-13 产品决定） |
|
||||
| `agent/部署中` | Claude 脚本（不用模型）：核对 `/api/health` | `agent/待真机`；3 小时未部署 → `agent/需拍板` |
|
||||
| `agent/待真机` | 产品负责人 | 关 issue，或评论问题并改回 `agent/待规划` |
|
||||
| `agent/需拍板` | 产品负责人 | 回复后改回原状态 |
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
## 要做的
|
||||
|
||||
1. `git fetch origin`，`git checkout --detach <extra.sha>`。确认 `git merge-base --is-ancestor origin/staging HEAD` 成立（分支基于最新 staging 可快进）；不成立则判 `fail`，修复单要求 Grok 在最新 staging 上重做。
|
||||
1. `git fetch origin`，`git checkout --detach <extra.sha>`。确认 `git merge-base --is-ancestor origin/staging HEAD` 成立（分支基于最新 staging 可快进）；不成立时先试 `git merge --no-ff origin/staging`：若无冲突，或冲突**只在 `docs/**`、`CHANGELOG*.md` 等纯文档里**（如两单都往 `docs/BUG_HISTORY.md` 末尾加条目），由你解决冲突、提交合并（提交信息写明「只碰文档」），核对 `scripts/`、`tests/`、`frontend/` 等代码路径与被验 SHA 的树完全相同，再按下面验收并推送，**不打回、不计打回次数**（2026-10-13 产品负责人在 #53 选定方案 A）。冲突碰到任何代码文件则判 `fail`，修复单要求 Grok 在最新 staging 上重做（Grok 不能改写已推分支，用 merge 而不是 rebase）。
|
||||
2. 对照任务书逐条给出 **通过 / 未通过 / 环境缺口**。验收命令按 `CLAUDE.md`「验收口径」与 `AGENTS.md` §7、§10 跑，前端全量 `npm test` 与 Python 快速门以你这里为准。依赖缺失时先在本工作目录 `npm ci --prefix frontend`；Python 用 `.venv/bin/python`，没有就用 `python3`。
|
||||
3. `test:db` 你这里跑不了：以 Grok 回报为准，但要核对它贴的失败清单与 `tools/agent-loop/windows-known-failures.txt` 逐条一致；对不上即未通过。
|
||||
4. 检查越界：diff 里有没有任务书没要求的文件、`.gitea/**`、依赖升级、冻结文件增长、弱化断言（缺"原值 / 新值 / 原因"三栏）、隐私数据。有就 `fail`。
|
||||
|
||||
Reference in New Issue
Block a user