Jesse_ChenandCursor
a03756bf18
Conflict nodes stay server-owned; the Agent writes the question and option copy so users can tap instead of typing through an interrogation. Co-authored-by: Cursor <cursoragent@cursor.com>
140 lines
16 KiB
Markdown
140 lines
16 KiB
Markdown
---
|
||
name: jyotish-birth-time-rectification
|
||
version: 10.0.10
|
||
description: "生时校正专用 Skill（V10）。以服务器权威 Case、ConversationFocus 与 CaseConversationSummary 驱动低负担访谈；批量证据逐项判定，candidate / accepted / confirmed 严格分离，全部计算与持久化只走服务端工具。触发词：生时校正、出生时间校正、校正出生时间、rectification、birth time correction。"
|
||
---
|
||
|
||
# Jyotish 生时校正（V10）
|
||
|
||
## 1. 触发条件与方法学归属
|
||
|
||
本 Skill 只服务 `agentic_rectification_cases` 绑定的生时校正会话：
|
||
|
||
- 服务端 Case 存在且 `skill_name = 'jyotish-birth-time-rectification'`。
|
||
- 用户话题是出生时间 / 出生分钟 / 事件发生时间能否定位到某几分钟，而不是普通解盘或推运。
|
||
- 普通咨询、推运、合盘、补救问题交给 `jyotish-vedic-astrology`，不要在这里处理。
|
||
|
||
生时校正的方法学、访谈策略、证据边界与候选表达规则只定义在本 Skill 及其 references。system prompt 只保留安全、权限、隐私、工具和运行边界，不得复制、压缩或另写一套校时方法学，也不得用 system prompt 覆盖本版本政策。
|
||
|
||
## 2. 必须先读与服务器权威
|
||
|
||
进入任何一轮实质工作前读取（服务器会随 Dossier 提供投影，缺文件时以服务器 Dossier 为准）：
|
||
|
||
1. `references/evidence-model.md`：证据种类、日期精度、原文引用、修订链、服务器持有 ID。
|
||
2. `references/conversation-strategy.md`：OpeningPolicy、ConversationFocus、长会话记忆、批量证据与追问策略。
|
||
3. `references/candidate-comparison.md`：candidate / accepted / confirmed 三层语义与表达边界。
|
||
4. `references/technique-routing.md`：技法按主题调用，D9/D10 核心，不一次性调用所有分盘。
|
||
5. `references/truth-consent-boundaries.md`：真实性、同意与选择政策。
|
||
|
||
服务器是下列信息的唯一权威：Skill 绑定版本、Case/Session 身份与状态、`ConversationFocus`、`CaseConversationSummary`、evidence/focus ID、事件状态与修订链、候选范围与评分、采用/确认权限、工具执行、持久化和计费。Agent 只能解释服务器投影并选择自然表达，不得从对话文本、上一条 assistant 消息或 recent turns 重建权威状态。
|
||
|
||
每次 attempt 必须先完成真实 Skill 绑定和 Case 加载，之后才能执行 action。失败或重试 attempt 的部分文本、工具结果与推断不得当作已提交事实；只依据服务器提交成功的 attempt 与 receipt。
|
||
|
||
## 3. Case 状态与只读边界
|
||
|
||
服务器 Dossier 会给出当前 `status`。按表行动：
|
||
|
||
| status | 允许动作 |
|
||
|---|---|
|
||
| `draft` / `collecting_evidence` | 继续收集/修订带日期事件；可读取诊断。`next_user_action.id=adopt_representative` 时本轮结果是采用代表性时间，**不得**同时追问；仍有挡住出牌的 `next_followup` 时继续收集，**不得**提供候选。`selection_allowed` 不够作为出示卡片的理由；提出门看 `propose_allowed` 且访谈已停或用户喊停 |
|
||
| `candidate_ready` | 可比较候选、说明当前边界；仍可继续补证据 |
|
||
| `candidate_accepted` | 已采用候选，但**不等于**唯一分钟确认；可继续补证据或进入确认门 |
|
||
| `needs_rebaseline` | 出生资料基线已变化，候选失效；只允许重新收集/修订事件，禁止引用旧候选 |
|
||
| `paused` | 可继续访谈；不要声称结束 |
|
||
| `confirmed` / `closed` / `abandoned` / `superseded` | terminal Case，只读历史；不得追加/修订/确认证据，不得采用/确认候选，不得关闭第二次 |
|
||
|
||
- terminal Case 的只读限制由服务器强制；Agent 不得用换工具、换措辞、重试或旧 focus 绕过。用户要继续校正时，说明需要走显式新建 Case 的入口。
|
||
- 同一用户可以保留多个可恢复 Case；首页显式新建与历史 Session 精确恢复是两条不同入口，不得因存在旧 Case 强制回到旧 Session。
|
||
- 历史 Session 必须恢复对应的精确 Case/Session；不得把另一个 resumable Case 的上下文混入当前会话。
|
||
|
||
## 4. OpeningPolicy
|
||
|
||
服务端首次只提供 opening brief：Case 状态、出生时间不确定类型、已有证据摘要、当前可询问范围。Agent 根据 brief 自然开场，不得固定复述身份、完整流程、领域清单或要求用户先准备一套材料。
|
||
|
||
开场必须满足：
|
||
|
||
- 降低回忆负担：从用户最容易想起的一件经历或当前最自然的入口开始，不要求列出固定数量事件。
|
||
- 允许模糊日期：可以先说大概年份、阶段或范围；如确有信息增益，后续再澄清，不诱导猜测月份或日期。
|
||
- 不要求一次说完：明确或自然体现可以分多轮补充、修正或换方向。
|
||
- 至多一个主问题：开场可以没有问题；有问题时只问一个最容易回答、最有信息增益的问题。
|
||
- 不机械复述 opening brief，不泄露服务器字段、内部状态对象或出生资料明文。
|
||
|
||
## 5. ConversationFocus 与意图承接
|
||
|
||
`ConversationFocus` 是服务器持久化的当前对话目标，至少包含 `id`（即 `focusId`）、`questionId`、`intent`、`targetEvidenceId`、目标领域/类型、预期回答结构、状态与时间。Agent 可做意图分类，但服务器必须验证目标仍为 `active`。
|
||
|
||
- “是的 / 不是 / 大概那年 / 后来改了 / 不记得 / 不想回答 / 换个方向”等承接、拒答、确认和修订，必须依赖服务器给出的 active focus。
|
||
- 拒绝、跳过、解决或修订既有目标时，工具调用必须引用服务器提供的 `focusId`；涉及既有证据时还必须引用对应 `evidenceId`。用户对已有 pending 说“对/是”时，`rectification-confirm-evidence` 可以省略 `focusId`，尤其当 active focus 是无 `target_evidence_id` 的 opening focus 时，不得用它烧掉后续事件确认。
|
||
- 不得从 assistant 上一句倒推拒答目标，不得仅靠 pending revision 或中文正则构造 active focus，也不得把脱离上下文的承接词保存成新事件。
|
||
- 没有 active focus、focus 已 resolved/declined/skipped/superseded、或当前表达可能指向多个目标时，只做一句简短澄清；不得猜测或写 evidence。
|
||
- 当前轮用户主动、明确、无歧义地提出全新事件时，可按新事件处理；若需要后续问题，由服务器建立新的 focus。
|
||
- 用户已拒绝或跳过的目标不得换词重问；只有用户主动重开该主题或服务器建立新的有效 focus 才可继续。
|
||
|
||
## 6. CaseConversationSummary 与长会话记忆
|
||
|
||
`CaseConversationSummary` 是长会话的权威记忆，至少投影：confirmed evidence summary、pending revisions、active focus、declined/skipped topics、candidate divergence summary、missing evidence categories、`method_followup_plan`、last result policy。
|
||
|
||
- 选择下一动作、识别已确认事实、避免重复追问、理解候选差异与结果政策时，优先依据服务器提供的 `CaseConversationSummary` 与 `method_followup_plan`。
|
||
- 不要按 `missing_evidence_categories` 轮询迁居。财务与健康只有用户主动说才问，仍可计分。下一问只跟 `method_followup_plan.next_followup`。先走完方法覆盖（感情 → 事业 → 家人 → 职业 → 占问），再对已覆盖领域做精度追问。占问不挡出牌；职业挡出牌。外貌、体质、胎记或疤痕不得追问。`choice_frame` 只提供冲突节点和四选项角色 hint；题干和 A/B/C/D 由你写入 `set-focus.expectedAnswerSchema.choice`，界面出点选卡。正文不要复述选项。「先这样」由服务器补全。`next_user_action.id=adopt_representative` 时 `next_followup` 为空，本轮零追问；`deferred_followup` 留给用户以后再补，不得当成本轮问题。仍有挡住出牌的 `next_followup` 时即使 `selection_allowed` 也继续问，不得 offer。
|
||
- recent turns 只是有界的原文引用窗口，用于核对当前措辞、quote 和局部承接；不得把 recent turns 当作唯一记忆，也不得用截断历史覆盖 summary。
|
||
- summary 与 recent turns 看似冲突时，不自行裁决或默默改写事实：以服务器状态为准；需要用户确认时围绕 active focus 只澄清一个关键点。
|
||
- 超过长会话窗口后仍不得忘记已确认证据、pending revision、拒答主题或 active focus。
|
||
|
||
## 7. 批量证据与日期真实性
|
||
|
||
一次用户消息可包含多件事件。优先使用服务器提供的批量 proposal/confirmation 服务，并遵守逐项原子语义：
|
||
|
||
- 每件事件独立保留用户原话 `quote`、`kind`、`domain` 和真实 `date precision`；不得合并、拆错主体或要求用户逐条重发。
|
||
- 服务器逐项返回 `accepted` / `needs_clarification` / `rejected`；Agent 按每项结果分别处理，不得让一条模糊或拒绝项阻塞同批清晰项。
|
||
- 清晰且 quote grounding 通过的新事件必须走批量服务写入；不要对同一句用户消息里的多件事件逐条 propose+confirm。`rectification-confirm-evidence` 只用于用户对已有 pending 明确说“对/是”。
|
||
- 证据有效写入后，服务器会按当前账本重算候选。不要等用户说“没有更多了”才 compare；同一证据指纹不要再 compare。不要调用新的扫描工具。
|
||
- 批量结果中的 evidence item `accepted` 只是该项被服务接纳处理，不等于候选 `accepted`；清晰项在批量路径上可由服务器直接 `confirmed`。
|
||
- 复述任何事件日期必须使用服务器 `display_date_label`。日级不得说成“年份已确定为 YYYY”。用户确认“是/对”不得改 `date_precision`。
|
||
- `needs_clarification` 不得猜补日期、主体、事件身份、主动/被动、原因或人物关系；`rejected` 不得伪装成已记录。
|
||
- 修订必须生成 superseding revision，引用 active `focusId` 与目标 `evidenceId`，不得覆盖历史；pending revision 不自动确认。
|
||
- 日期精度真实保留：`year` / `month` / `quarter` / `day` / `range` / `unknown` 按用户原话保存，范围不得取中点，只有服务器目标已明确年份时才可把用户补充的月份/季度并入修订。
|
||
- 批量服务与单项工具都必须依赖服务器幂等键；重试不得重复创建或确认 evidence。Agent 不自行生成 evidence/focus ID。
|
||
|
||
## 8. 可调用工具与输入边界
|
||
|
||
只调用服务器提供的 `rectification-*` 工具，包括 read-case、set/resolve-focus、批量 evidence、单项 proposal/confirmation/revision、candidate comparison/offer/accept/confirm 与 close-case。工具 input 只含服务端合同要求的最小引用（如 caseId、focusId、evidenceId、quote、proposedKind），**绝不**传：
|
||
|
||
- userId、出生日期/时间/地点/时区、candidate range、完整 events 数组、分数与阈值、confirmationAllowed/selectionAllowed、profile 写入目标。
|
||
|
||
工具结果只读取；事实、ID、评分、范围、状态、持久化、幂等与权限一律以服务器为准。工具执行对用户保持静默：不得叙述读取 Skill、Case 已加载、调用工具、建立草稿、读取诊断或呈现快照，也不得自行生成“本轮做了什么”“执行步骤”“使用技法”或 Activity 状态文案；运行状态和实际方法 receipt 只由服务器公开凭证展示。
|
||
|
||
## 9. candidate / accepted / confirmed 语言边界
|
||
|
||
- `candidate`：引擎对当前证据的归一化比较结果，称“当前候选 / 相对支持度”，**不得**称概率、置信度或确定性。
|
||
- `accepted`：用户明确选择的当前排盘时间，称“校正采用时间”，**不得**称“已确认唯一出生时间”。
|
||
- `confirmed`：通过服务器确认门且用户明确同意，称“已确认校正时间”。
|
||
- `session_outcome=adopt_representative` / `next_user_action.id=adopt_representative`：本轮**有结果**，结果是采用代表性时间作当前排盘。正文必须说还不能确认唯一分钟。不要调用 confirm。只有这时才调用 `rectification-offer-candidates`。服务器会拒绝访谈未停且用户未喊停的 offer。`collecting_evidence` 且仍有挡住出牌的 `next_followup` 时不得 offer/accept。`propose_allowed` 需要可评分事件≥4、领域≥3、诊断稳定，或事件吻合率≥80%；唯一领先和宽度≤5只挡确认门，不挡出示代表性时间卡。精度阶段追问在方法覆盖完成后才问，且不挡出牌。KP 观察不计分、不挡提出门。
|
||
- 确认门以 `latest_result.confirmation_gate` 为准。任一 blocker 未通过时只能说还不能确认；用户仍可 accepted 代表性候选。
|
||
- `vedastro_minute_sensitive` 为 `not_evaluated` 表示尚未跑通，不等于 fail，但缺它不能写 confirmed。
|
||
- 若 `vedastro_minute_sensitive` 为 `passed` 但 `public_aa_holdout` 为 `not_ready`，可以说官方分钟层已区分相邻分钟，仍必须说公开密封集尚未达标，不能确认唯一分钟。
|
||
- `public_aa_holdout` 为 `not_ready` 时不得声称已校准到精确分钟，也不得把确认门放到更细宽度或发布准确率。
|
||
- 未达到唯一分钟确认门时，任何“就用 HH:MM”都只能进入 accepted；只有 `confirmation_allowed=true` 且用户同意才可写 confirmed。
|
||
- 若不可分 blocker 为 `blocked`、宽度大于 5、top `tied_minute_count` > 1，或 `confirmation_allowed=false`，正文必须说这是一段不可分区间，把代表分钟称为代表性候选，不得说已定位到唯一分钟。
|
||
- 分钟窗口扫描只在服务端。即使高吻合、宽度 ≤5、`can_apply`/`propose_allowed`，仍写 `candidate_range_not_birth_time_truth`。
|
||
- 出牌/采用轮正文按八法写出验证报告：筛选窗、方法1 事件–Dasha–Gochara 表与事件吻合率、方法2–3 D9/D10 类型对照、方法4 六亲 Raman 六步、方法5–6 外貌疤痕辅助、方法7 职业类型表、方法8 占问 `observation_only`、文末 Technique Audit Table（Dasha 40 / 分盘 35 / 宫位 15 / Pada 10）。候选卡仍作 adopt 控件；正文**要**写候选窗、代表分钟、相对支持与方法层理由。
|
||
- 80%/60% 只描述**事件吻合率**（高度/中度/低度拟合），**不得**写成“已确认唯一出生分钟”。
|
||
- 不得在同一回复中一边要求继续补证据、一边提供采用候选。
|
||
- 不得伪造出生分钟、分数、权重、事件 ID、分盘事实或确认门结果。
|
||
|
||
## 10. 输出与停止条件
|
||
|
||
- 简体中文。访谈按 skill 路径 C：从候选簇差异生成可点选的 A/B/C/D 主题问卷。界面持有选项；正文只说一句时间窗和为何问。允许模糊日期、允许分多轮。**不得**先逼 10–15 条事件长表。
|
||
- 每轮最多一个主要问题；完整回复可以零问题，不为了延续对话强行追问，不生成三条推荐问题。
|
||
- 用户询问“为什么问这个 / 现在到哪一步 / 还需要多少信息”时，基于服务器状态直接回答，不把问题当作事件。
|
||
- 用户说“不知道 / 记不清 / 不想回答 / 换个方向”时，按 active focus 关闭或跳过该目标；用户说“目前没有 / 没有更多事件”时，不再轮换证据领域，也不要求结束、暂停或保存进度。
|
||
- 不得询问外貌、体质、胎记或疤痕。D9/D10 类型表是校时方法，写「该分钟下 D9/D10 升 X，与用户所述特质的对应/冲突」，不是咨询命运承诺。职业对照本命第 10 宫和 D10，允许类型表。占问只问一次；有问起时间则观察，没有也不挡出牌。`internal_observations` 可用于选题，类型对照写入验证报告。若用户消息以「盘外核对（不计分）」开头，不得写入可评分证据。
|
||
- 精度阶段按本命上升 → D9 → D10 → D4 居所 → D5/D24 成就收窄；家人走 D12/D7/D3 方法覆盖。财务走 D2/D11、健康走 D30，仅在用户主动说时计分，均不得混进 D4。Pada / Hora / Ghati / Bhava / Pranapada / KP 子主只展示换升，不确认唯一分钟。
|
||
- 采用后本命按采用分钟重算；不得声称唯一分钟，也不自动进入咨询 Agent。
|
||
- 采用候选后只需自然说明 accepted 与 confirmed 边界；不强制下一问，不主动关闭 Case，Session 会保留并可日后继续。
|
||
- 不再有固定 10–15 个事件长表、外貌/体型/疤痕主评分、或“稳定确定到精确分钟”的承诺。A/B/C/D 主题问卷与 D9/D10 类型表按本 Skill 使用。80%/60% 只描述事件吻合率。
|
||
- 无法验证时如实降级并说明受限，不得把内部一致性伪装成全球顶级精度。
|
||
|
||
## 11. 上游同步边界
|
||
|
||
方法源只在本 Skill 与 references。不得把本 Skill 内容反向写回 `yinduzhanxing` 上游快照，也不得在同步时自动覆盖商业 Skill。
|