fix(rectification): preserve grounded agent responses
This commit is contained in:
@@ -56,7 +56,7 @@ Before choosing an action, read the contracts in `references/`. Treat `assets/re
|
||||
1. During evidence interpretation, read the complete Case Dossier: recent raw turns, full revision ledger, current target disposition, pending evidence, candidate contrasts, event sensitivity, and range gate. During final planning, do not assume those server-owned views are already loaded; request only the focused tool observations needed for the decision.
|
||||
2. Propose every explicit event in the latest answer. Use exact source spans and declared date text; propose `revise` only with a server-issued event ID already present in the Dossier.
|
||||
3. After the server stages valid revisions and recomputes diagnostics, choose the single most useful focus. Read focused server observations through `case_read`, `candidate_scan`, `evidence_gap`, or `diagnostic_read`; each result advances the in-run Dossier revision and must inform the next decision. Stop the loop as soon as the evidence supports one useful question, a gated range, or an honest low-confidence result. Do not rotate through domains or ask for finer dates unless the observations show value.
|
||||
4. Write one short natural question and the public reply in the same TurnPlan. Do not expose internal IDs, scores, contribution details, tools, or candidate minutes.
|
||||
4. Write the public reply and one short natural question in the same TurnPlan. When the latest answer adds or refines a concrete event, first summarize that event in the user's own terms, then add one short public-safe sentence explaining why its date and type of change help compare candidate ranges, and only then ask the question. Do not expose internal IDs, scores, contribution details, tools, candidate minutes, chart divisions, houses, or technique names.
|
||||
5. If server validation rejects the TurnPlan, repair it once. If it still fails, accept the generic safety fallback. Offer a range only when the current server Snapshot allows it; otherwise stop honestly at low confidence when no useful question remains.
|
||||
|
||||
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.
|
||||
@@ -72,7 +72,7 @@ A user who answers with a different complete event may have that event saved wit
|
||||
|
||||
## Public language
|
||||
|
||||
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.
|
||||
Use a brief acknowledgement tied to the user's actual event, a brief high-level explanation of why that event helps candidate comparison when an event was added or refined, an optional gated candidate update or limitation, and at most one question. The explanation should describe only observable features such as date precision, event type, or cross-event comparison; it must not name D-charts, houses, astrology techniques, scores, candidate minutes, or hidden reasoning. Do not repeat an unchanged range, over-interpret the event, or turn sparse/conflicting evidence into certainty.
|
||||
|
||||
|
||||
## Analysis process receipt
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
## 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`.
|
||||
- Invalid V8 Director output gets one repair attempt, then uses a server-owned fallback. Without a current target the fallback is domain-neutral; with a current target it asks only the necessary anchored factual clarification. Legacy Renderer paths may still use a validated opportunity fallback for compatibility.
|
||||
- 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.
|
||||
|
||||
@@ -15,20 +15,24 @@ Public output keeps the existing shape:
|
||||
|
||||
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.
|
||||
|
||||
## Evidence-value explanation
|
||||
|
||||
When the latest answer adds or refines a concrete event and the final action asks another question, include one short explanation before the question. Explain only why the event's date precision, event type, or relationship to other independent events helps compare candidate ranges. This explanation is required for such turns, but it must remain high-level: do not name chart divisions, houses, astrology techniques, scores, candidate minutes, or hidden reasoning.
|
||||
|
||||
## Question
|
||||
|
||||
When a validated opportunity is selected, `question` is required; otherwise it is `null`. The question must:
|
||||
For V8, the Director independently chooses the focus and wording from the complete dossier, declined domains, candidate contrast observations, and read-only tool results. The server does not select a domain from a fixed rotation, require domain keywords, or substitute a prewritten domain prompt. `question` is required only when the final action is `ask_question`; 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`;
|
||||
- ask one thing only and remain consistent with the structured focus;
|
||||
- include a valid full event anchor when `targetEventId` is present;
|
||||
- avoid reopening a declined event or declined domain;
|
||||
- ask about one possible new event without presuming it occurred when the focus is independent evidence;
|
||||
- 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`.
|
||||
Validate semantic consistency and safety, not fixed Chinese words. Reject multi-question transitions such as “另外”, “还有”, “同时再说”, or “并且告诉我” only when they introduce another request. When no current target exists and the model is unavailable, use a domain-neutral recovery question; when a current target requires a factual clarification, the fallback may ask only that necessary anchored fact.
|
||||
|
||||
## Candidate update
|
||||
|
||||
@@ -43,7 +47,7 @@ Do not describe LOEO/LODO as an independent holdout, prospective validation, or
|
||||
|
||||
## 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.
|
||||
Fallback follows the same public rules as model output: acknowledge the actual event naturally, briefly explain its public-safe evidence value when present, ask one anchored question, avoid repetition and over-interpretation, and never claim exact-minute certainty.
|
||||
|
||||
|
||||
## Persisted analysis process
|
||||
|
||||
@@ -1,21 +1,20 @@
|
||||
# Question policy
|
||||
|
||||
## Semantic opportunities
|
||||
## Agent-directed focus
|
||||
|
||||
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`.
|
||||
In V8, the dossier and read-only tools expose facts, constraints, and candidate-contrast observations. The Director decides which evidence direction is most useful and writes the question. The server must not rotate through a fixed domain list, rank domains with hand-authored recall/privacy weights, require domain keywords, or turn test transcripts and example events into production scripts.
|
||||
|
||||
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.
|
||||
Candidate contrast may identify discriminating technique layers and all supported missing event kinds. Treat these as observations the Agent can weigh against the complete event ledger, recent conversation, refusals, privacy, and expected value. They are not a server-selected question and must not be copied mechanically into public wording.
|
||||
|
||||
Use the latest answer and latest accepted event as the current topic. Do not let keywords from older turns pull the conversation back to a stale domain, and do not give an uncovered domain both a coverage reward and a second topic reward from the same older event. Once the minimum domain coverage is already present, continuity and information gain should outweigh collecting another domain merely because it is missing.
|
||||
Legacy semantic opportunities remain readable for compatibility and deterministic target clarification. Their `fallbackPrompt` is a failure-recovery surface, not the normal V8 topic selector. A no-target fallback must stay domain-neutral; a targeted fallback may ask only the server-known missing fact for that event.
|
||||
|
||||
### New-event existence and recall cues
|
||||
### New-event questions
|
||||
|
||||
- Ask whether a relevant event exists before asking for its details. Use an existence form such as “过去是否有过……” or “如果有……”, not a presuppositional form that implies the user must have had that event.
|
||||
- Offer 2–5 concrete recall cues as non-exhaustive examples. Make it explicit that they are examples, allow any other relevant event, and allow the user to say that none occurred.
|
||||
- Recall cues may name ordinary event types supported by the selected domain, but must not assert that any cue happened to this user.
|
||||
- Do not invent an age, life stage, year, month, date range, or relative time window. A time or age may appear only when it already comes from accepted user evidence or another server-owned fact allowed by the opportunity contract.
|
||||
- Compare every new-event opportunity with the latest accepted event even when their domain labels differ. If they overlap semantically in subject, action, transition, or outcome, apply a utility penalty before ranking. If the candidate is merely a cross-domain paraphrase of the latest event, suppress it instead of asking the same event again with different words.
|
||||
- Domain coverage must not override semantic continuity or duplicate-event protection. A missing domain is not sufficient reason to ask a semantically overlapping question.
|
||||
- Ask whether one relevant event exists; do not imply the user must have experienced a particular category.
|
||||
- The Agent may use its own natural recall cues when useful, but examples are non-exhaustive and never server-required keywords.
|
||||
- Do not invent an age, life stage, year, month, date range, or relative time window. A time or age may appear only when it already comes from accepted user evidence or another server-owned fact.
|
||||
- Compare a proposed direction with the complete event ledger so the next question does not paraphrase an event already supplied.
|
||||
- A missing domain alone is not a reason to ask about it. If no safe, useful question remains, stop with low confidence.
|
||||
|
||||
## One-turn rule
|
||||
|
||||
|
||||
Reference in New Issue
Block a user