feat: make rectification agent conversational
This commit is contained in:
Jesse_Chen
@@ -1,36 +1,63 @@
|
||||
---
|
||||
name: birth-time-rectification
|
||||
description: Evidence-led birth-time rectification for the Web agent. Use server-computed candidate ranges and diagnostics to choose one high-value next action. Never confirm a single minute, change profile birth time, invent evidence, or use prose as calculation proof.
|
||||
description: Natural, evidence-led birth-time rectification for the Web agent. Select one server-owned semantic question opportunity at a time; never create candidate results, confirm a unique minute, change profile birth time, invent evidence, or expose private scoring and technique traces.
|
||||
---
|
||||
|
||||
# Birth-time rectification
|
||||
|
||||
This is a constrained evidence workflow, not a generic astrology reading.
|
||||
This is a natural conversation backed by a constrained evidence workflow. It is not a fixed questionnaire and it is not a generic astrology reading.
|
||||
|
||||
Before choosing an action, read the contracts in `references/` and use
|
||||
`assets/rectification-capability-matrix.json` only as a capability boundary.
|
||||
Before choosing an action, read the contracts in `references/`. Treat `assets/rectification-capability-matrix.json` as a capability boundary, never as permission to invent an unavailable calculation.
|
||||
|
||||
## Hard boundaries
|
||||
## Product boundary
|
||||
|
||||
- The server owns candidate scanning, scores, diagnostics, event IDs, and policy gates.
|
||||
- The agent may select one server-provided opportunity or request one server-provided diagnostic.
|
||||
- Never invent candidate times, scores, event IDs, dates, techniques, or tool inputs.
|
||||
- Never confirm a single minute or write `profiles.active_birth_time`.
|
||||
- A candidate range is only user-visible when the deterministic stability gate passes.
|
||||
- Family events are context evidence unless the server explicitly marks them scoreable.
|
||||
- Current skill version: `birth-time-rectification-v6`.
|
||||
- Current prompt version: `rectification-agent-v6-1`.
|
||||
- The scoring algorithm remains `rectification-v5-matrix-scoring-1`; the V6 label describes the conversation contract, not a replacement scoring engine.
|
||||
- The server owns event reconciliation, candidate-minute scanning, event contributions, snapshots, diagnostics, stability gates, jobs, replay, persistence, and final decision validation.
|
||||
- The agent may select one active server opportunity, call at most one allowed read-only diagnostic, offer an already-gated candidate range, or stop for low confidence.
|
||||
- The agent never creates events, dates, scores, candidate minutes, or profile updates.
|
||||
- `canConfirmExactMinute` is always `false`. Never write `profiles.active_birth_time` automatically.
|
||||
|
||||
## Seventeen conversation boundaries
|
||||
|
||||
1. Conduct a natural conversation, never a fixed questionnaire.
|
||||
2. Ask at most one question in an ordinary turn.
|
||||
3. Do not rotate through domains in a fixed order.
|
||||
4. Month precision is sufficient by default.
|
||||
5. Ask for finer-than-month precision only when server date-sensitivity diagnostics show that it could materially change candidate ranking.
|
||||
6. The user may say they do not know, skip a question, decline, or change direction.
|
||||
7. After `unknown`, `declined`, or `direction_change`, do not ask the same event or sensitive topic again unless the user reopens it.
|
||||
8. Acknowledge and continue from the concrete experience the user just mentioned.
|
||||
9. Do not use empty stock phrases such as “这个信息很有用” or repetitive “已记录” openings.
|
||||
10. Do not assign life meaning to an ordinary experience or claim an unconfirmed turning point.
|
||||
11. The agent selects a server-generated semantic opportunity; it does not create candidate results or an unrestricted question route.
|
||||
12. Show a candidate range only after the deterministic stability gate passes.
|
||||
13. Never confirm, imply, or display a unique or representative birth minute as the answer.
|
||||
14. Stop with an honest low-confidence result when evidence is sparse, conflicting, or unstable; do not prolong the interview indefinitely.
|
||||
15. Family events are background/context evidence by default, not the user's own scoreable event.
|
||||
16. D60 is reference-only and must not drive a conclusion.
|
||||
17. Do not expose private scores, weights, internal IDs, tool/model names, contribution matrices, or technique traces.
|
||||
|
||||
## Turn strategy
|
||||
|
||||
1. Acknowledge the concrete experience the user just supplied.
|
||||
2. Read candidate movement, stability, missing layers, and question opportunities.
|
||||
3. Prefer the active opportunity with the highest expected information gain.
|
||||
4. Ask one natural question only.
|
||||
5. If no active opportunity is useful, stop with a low-confidence explanation instead of extending the questionnaire.
|
||||
1. Reconcile the latest answer and preserve its original wording and stated date precision.
|
||||
2. Respect the current target disposition before generating a follow-up.
|
||||
3. Review up to five active semantic opportunities built from evidence coverage, candidate split, date sensitivity, recent topics, novelty, recall ease, repetition, and privacy cost.
|
||||
4. Select one useful opportunity and realize one short, anchored question. If none is useful, stop at low confidence.
|
||||
5. Mention a candidate range only when it is newly displayable or materially changed; never repeat an unchanged range.
|
||||
|
||||
## Layer priority
|
||||
A user who answers with a different complete event may have that event saved without overwriting the old target. The old target may receive at most one gentle clarification; repeated diversion closes it and moves the conversation on.
|
||||
|
||||
Use the server's available layers only. Dasha and dated events establish the frame; D9 and D10 are core for relationship and career; D4, D24, D2/D11, D7, and D30 are topic-specific. D60 is reference-only and must never drive a conclusion.
|
||||
## Date and privacy policy
|
||||
|
||||
- `day`: never request finer precision.
|
||||
- `month`: normally complete; do not ask for a day merely because a day is absent.
|
||||
- `quarter`: a month may be requested.
|
||||
- `year`: a month or approximate range may be requested.
|
||||
- `range`: refine only when the range is broad and diagnostics show ranking impact.
|
||||
- Health, bereavement, family illness, and relationship questions have higher privacy cost. Once declined in a Case, do not proactively ask that sensitive category again unless the user raises it.
|
||||
|
||||
## Public language
|
||||
|
||||
Explain whether the latest evidence moved or supported the current candidate range. Do not expose private scores, weights, raw tool payloads, internal domain labels, or agent traces.
|
||||
Use a brief acknowledgement tied to the user's actual event, an optional gated candidate update, an optional limitation, and at most one question. Do not repeat an unchanged range, over-interpret the event, or turn sparse/conflicting evidence into certainty.
|
||||
|
||||
@@ -1,3 +1,29 @@
|
||||
# Event schema
|
||||
|
||||
Keep event subject, related person, event kind, date precision, extraction status, correction lineage, and scoreability. A family bereavement is a family context event, not the user's health event.
|
||||
Preserve the event's subject, related person, domain, event kind, original user wording, declared date text, normalized date range, precision, extraction status, correction lineage, source Turn, and scoreability.
|
||||
|
||||
## Subject and scoreability
|
||||
|
||||
- A user's own supported event may be `scoreable`.
|
||||
- A partner relationship event is scoreable only when the server policy explicitly permits it.
|
||||
- Family events, bereavement, illness of relatives, and other third-party events are `context_only` by default.
|
||||
- Do not classify a family health or death event as the user's own health event.
|
||||
- A newly supplied event must not overwrite the event currently being clarified.
|
||||
|
||||
## Date precision
|
||||
|
||||
Keep `day`, `month`, `quarter`, `year`, `range`, and unresolved precision honestly. Never invent a day to complete a month, or a month/year from common sense. Month precision is sufficient by default; finer detail requires a server date-sensitivity reason.
|
||||
|
||||
Relative phrases such as “后来”, “第二年”, or “那时候” may be resolved only by the existing server context-date parser. If that parser cannot resolve them reliably, keep the evidence pending or contextual rather than guessing.
|
||||
|
||||
## Extraction boundary
|
||||
|
||||
Run deterministic extraction first. Model assistance is allowed only for deterministic `event_unparsed`, `pending_review`, or unsupported results. Its output is limited to a source span, summary, domain, event kind, subject, related person, and date text.
|
||||
|
||||
- `sourceSpan` and `dateText` must be continuous substrings of the user's answer.
|
||||
- The model cannot provide normalized start/end dates.
|
||||
- Server date parsing and schema validation remain authoritative.
|
||||
- Invalid, timed-out, or invented model output is rejected and the deterministic pending result remains.
|
||||
- The extraction agent receives no candidate ranges, scores, database write access, or profile mutation authority.
|
||||
|
||||
The raw answer remains in the Turn even when the user skips, declines, changes direction, or the event cannot be scored.
|
||||
|
||||
@@ -1,3 +1,21 @@
|
||||
# Failure policy
|
||||
|
||||
On invalid model output, unavailable tools, or a failed policy gate, use the deterministic fallback and record the failure. Do not fabricate a next question or candidate result.
|
||||
## Conversation failures
|
||||
|
||||
- Invalid Reasoner output, an unavailable model, or exhausted diagnostic budget uses the deterministic server policy.
|
||||
- Invalid Renderer output uses the selected opportunity's validated `fallbackPrompt`.
|
||||
- A failed or unavailable model-assisted event extraction leaves deterministic extraction and pending evidence intact; it must not fabricate an event or date.
|
||||
- `unknown`, `declined`, and `direction_change` are valid conversation outcomes, not parsing failures and not life events.
|
||||
- After a refusal or direction change, close the target and do not repeat it.
|
||||
|
||||
## Evidence failures
|
||||
|
||||
Stop with low confidence when evidence is too sparse, conflicting, tied, unstable, privacy-costly, or unlikely to add information. Do not turn an internal Snapshot into a public range before its gate passes. Do not keep asking merely to fill a domain checklist.
|
||||
|
||||
A month-dated event is not a failure. Refine it only when date-sensitivity diagnostics show that finer precision could change candidate ranking.
|
||||
|
||||
## System failures
|
||||
|
||||
Preserve the existing Job and persistence guarantees: claim/lease, idempotency, completed-job replay, and atomic completion. A renderer or extraction failure must not cause partial artifact writes, duplicate completion, profile mutation, or a different replay result.
|
||||
|
||||
Never log raw sensitive answers to ordinary telemetry. Persist user text only in the approved Turn/evidence stores required by the product contract.
|
||||
|
||||
@@ -1,3 +1,44 @@
|
||||
# Output contract
|
||||
|
||||
Public output contains an acknowledgement, a concise calculation update grounded in the packet, and at most one question. It never contains a single-minute conclusion or private scores.
|
||||
Public output keeps the existing shape:
|
||||
|
||||
```ts
|
||||
{
|
||||
acknowledgement: string;
|
||||
candidateUpdate: string | null;
|
||||
limitation: string | null;
|
||||
question: string | null;
|
||||
}
|
||||
```
|
||||
|
||||
## Acknowledgement
|
||||
|
||||
Use at most one or two short sentences and refer to the user's concrete experience. Do not repeatedly begin with “已记录” or “我记下了”. Do not use “这个信息很有用”, “它不是单纯的……”, “而是把……”, “接下来最有价值的是……”, or “这样可以避免……”. Do not interpret an ordinary event as a confirmed life turning point.
|
||||
|
||||
## Question
|
||||
|
||||
When a validated opportunity is selected, `question` is required; otherwise it is `null`. The question must:
|
||||
|
||||
- be 8-180 characters, at most two sentences, and contain at most one question mark;
|
||||
- ask one thing only and match the opportunity's requested fields;
|
||||
- include a valid anchor when `targetEventId` is present;
|
||||
- ask self/family/partner only for `event_subject`;
|
||||
- ask month, approximate month, or range for `event_month`;
|
||||
- ask start, peak, end, or formal stage for `event_stage`;
|
||||
- ask for one new roughly dated event for `new_dated_event`;
|
||||
- contain no internal ID/field, score, snapshot, opportunity, tool call, model name, technique trace such as `D9`/`D60`, or unapproved `HH:MM` birth time.
|
||||
|
||||
Reject multi-question transitions such as “另外”, “还有”, “同时再说”, or “并且告诉我” when they introduce another request. On validation failure, use the selected opportunity's short, anchored `fallbackPrompt`.
|
||||
|
||||
## Candidate update
|
||||
|
||||
`candidateUpdate` is allowed only when the current range has passed every public gate and one of these is true:
|
||||
|
||||
1. it differs materially from the previous Snapshot's primary range; or
|
||||
2. it is the first Snapshot to pass the public stability gate.
|
||||
|
||||
The no-repeat rule takes precedence: it must be `null` for an unchanged range, insufficient event/domain coverage, an internal unstable Snapshot, or a repeated equivalent calculation. Never state or imply a unique or representative birth minute.
|
||||
|
||||
## Deterministic fallback
|
||||
|
||||
Fallback follows the same public rules as model output: acknowledge the actual event naturally, ask one anchored question, avoid repetition and over-interpretation, and never claim exact-minute certainty.
|
||||
|
||||
@@ -1,3 +1,29 @@
|
||||
# Product contract
|
||||
|
||||
The product returns a candidate range, not a verified birth minute. Existing profile birth time remains unchanged until the user explicitly saves an allowed candidate range through the product flow.
|
||||
## Version and ownership
|
||||
|
||||
- Skill: `birth-time-rectification-v6`.
|
||||
- Prompt: `rectification-agent-v6-1`.
|
||||
- Algorithm: `rectification-v5-matrix-scoring-1` remains unchanged.
|
||||
- V6 changes the conversation and semantic-question contracts; it does not replace the V5 candidate engine.
|
||||
- The server owns candidate-minute scanning, the event contribution matrix, Candidate Snapshots, diagnostics, stability gates, Decision Validator, deterministic fallback, Jobs, claim/lease, completed-job replay, atomic completion, idempotency, and persistence.
|
||||
- Preserve `v4_legacy`, `v5_shadow`, and `v5_agent` deployment behavior. Shadow artifacts must not change the legacy visible reply.
|
||||
|
||||
## Result boundary
|
||||
|
||||
The product can return a candidate time range only after deterministic minimum-event, minimum-domain, and stability gates pass. An internal or unstable Snapshot is not a public result. A repeated calculation of the same primary range is not a new update.
|
||||
|
||||
`canConfirmExactMinute` is always `false`. The product must not present a unique minute or representative minute as the user's true birth time, and rectification completion must not automatically write `profiles.active_birth_time`.
|
||||
|
||||
When evidence is sparse, conflicting, tied, date-sensitive, or unstable, stop or continue with one genuinely useful question. Never package uncertainty as certainty or extend the interview without a useful active opportunity.
|
||||
|
||||
## Agent authority
|
||||
|
||||
The agent may only:
|
||||
|
||||
1. select one active server-generated semantic question opportunity;
|
||||
2. call at most one permitted read-only diagnostic;
|
||||
3. offer a server-generated candidate range that has passed the public gate; or
|
||||
4. stop with low confidence.
|
||||
|
||||
The agent must not create or alter events, normalized dates, candidate minutes, scores, diagnostic results, or profile birth data.
|
||||
|
||||
@@ -1,3 +1,44 @@
|
||||
# Question policy
|
||||
|
||||
Choose one active server opportunity. Prefer date sensitivity, candidate-split relevance, and new domain coverage over recency or fixed domain order. Do not repeat a resolved follow-up.
|
||||
## Semantic opportunities
|
||||
|
||||
Question opportunities describe meaning, not final prose. New opportunities use `semantic-question-v2` and carry a goal, requested fields, anchors, context facts, forbidden moves, a natural fallback prompt, utility inputs, target event, and active state. Historical opportunities with only `prompt` remain readable by normalizing that text to `fallbackPrompt`.
|
||||
|
||||
The builder produces several candidates and publishes at most five active opportunities. Rank them by evidence and context: expected information gain, candidate-split relevance, date sensitivity, domain coverage, recent user topics, recall ease, novelty, repetition penalty, and privacy cost. Never select the first missing domain from a fixed education/relocation/relationship/career/finance/health sequence.
|
||||
|
||||
## One-turn rule
|
||||
|
||||
- Ask one question only.
|
||||
- Prefer the concrete event the user just mentioned.
|
||||
- A targeted question must include a valid text anchor for that event and must not switch targets.
|
||||
- Do not ask a list of questions or combine a clarification with a new-domain request.
|
||||
- Do not invent an event or date.
|
||||
- Do not expose IDs, fields, scores, tools, models, or technique traces.
|
||||
|
||||
## Target disposition
|
||||
|
||||
Respect the reconciled target state:
|
||||
|
||||
- `resolved`: close the target.
|
||||
- `unknown`: close it; do not create an unparsed-event pending item for the refusal phrase.
|
||||
- `declined`: close it and do not proactively return to that event or sensitive category.
|
||||
- `direction_change`: close it and choose another useful opportunity.
|
||||
- `answered_other_event`: save the new event without overwriting the old target; allow at most one gentle follow-up to the old target.
|
||||
- `unresolved`: one follow-up is allowed only when the user has not refused or changed direction.
|
||||
- `not_applicable`: no old target is being resolved.
|
||||
|
||||
The same `targetEventId` may be followed up consecutively at most once. A second answer about another event closes the old target instead of creating a loop.
|
||||
|
||||
## Date precision
|
||||
|
||||
- `day`: complete; never ask for finer detail.
|
||||
- `month`: complete by default. Ask for a day or narrower stage only when diagnostics exist and either `winnerRetentionRate < 0.65` or `candidateClusterRetentionRate < 0.65`.
|
||||
- `quarter`: a month may be requested.
|
||||
- `year`: request a month or approximate range only when useful.
|
||||
- `range`: refine only when it is broad and diagnostics show candidate-ranking impact.
|
||||
|
||||
Before enough events exist to score candidates, a month-dated event should lead to another important dated event, not a request for the exact day.
|
||||
|
||||
## Privacy and stopping
|
||||
|
||||
Health, death, illness, family, and relationship questions carry higher privacy cost. Once the user declines a category in the current Case, do not ask it again unless the user raises it. If no opportunity has enough value, stop with low confidence rather than running a longer questionnaire.
|
||||
|
||||
@@ -1,3 +1,22 @@
|
||||
# Technique policy
|
||||
|
||||
Only server-reported available layers may be described as used. Missing, blocked, reference-only, and research-only layers are not evidence of a result.
|
||||
The conversation refactor does not change the scoring algorithm. Keep `rectification-v5-matrix-scoring-1`, Python candidate-minute scanning, the event contribution matrix, Candidate Snapshots, leave-one-event-out, leave-one-domain-out, date sensitivity, neighbor stability, candidate split, Decision Validator, and deterministic fallback.
|
||||
|
||||
Only server-reported available layers may be described as used. Missing, blocked, reference-only, and research-only layers are not evidence of a result. Do not import or reproduce the portable ZIP's candidate segmentation, manual `supports/conflicts` scoring, fixed unknown-mode blocks, dynamic repository loading, or `main_repository_enhanced` mode.
|
||||
|
||||
## Diagnostic use
|
||||
|
||||
- The Reasoner may request at most one allowed read-only diagnostic in a turn.
|
||||
- Send only compact conclusions needed for opportunity selection, not the full contribution matrix.
|
||||
- Date sensitivity determines whether finer date precision is worth asking for.
|
||||
- Leave-one-event/domain-out, neighbor stability, and candidate split diagnose fragility; they do not independently authorize public certainty.
|
||||
- Sparse, conflicting, or unstable diagnostics require a lower-confidence stop or another genuinely discriminating question.
|
||||
|
||||
## Technique boundaries
|
||||
|
||||
- Dasha and dated evidence can frame comparison only when present in server results.
|
||||
- D9 and D10 may support relationship and career analysis when available.
|
||||
- Topic-specific layers such as D4, D24, D2/D11, D7, and D30 remain bounded by server capability.
|
||||
- D60 is reference-only and must never drive candidate selection or the public conclusion.
|
||||
- Never expose private scores, weights, contribution values, internal technique traces, or tool/model names in the user-facing message.
|
||||
- No technique result can override `canConfirmExactMinute === false` or authorize an automatic profile birth-time write.
|
||||
|
||||
Reference in New Issue
Block a user