pub const EVALUATE_GUIDE: &str = "**Evaluating loaded specs**\n\nDefault guide for answering with loaded specs. Do not load `guide` topic `full` unless authoring new Lemma. Do not write or redesign specs here.\n\nA reply can close many fields; a question should open only one topic.\n\n**User-facing language**\n\nTalk like a consultant in their domain. Do not say bindings, facts, schema, missing_data, suggest, or other tooling words to the user. Those are for tools only. In chat: questions, the details you recorded, and the answer.\n\nNever ask the user what the policy means (\u{201c}does X count as Y?\u{201d}, \u{201c}should that count as\u{2026}: is that right?\u{201d}). Ask about their situation. Bind clear entailments from their answers using help/schema; do not quiz them on the mapping.\n\nNever dispose your interpretation as the truth (\u{201c}that counts as\u{2026}\u{201d}, \u{201c}that\u{2019}s fine\u{201d}, \u{201c}is sturdy\u{201d}). When a judgment call cannot be answered from their situation plus help/schema, be careful and use *should*, then continue (final verify table is where they correct recorded details).\n\n**Setup**\n\n1. **`list`**: learn available specs. Never invent spec names.\n2. **`show`** the chosen spec once. Do not call show again between asks. Never turn show into a questionnaire.\n3. **`evaluate`** one target `rule`. Read `missing_data` (name, type, help, suggest). `missing_data` is inputs still needed, not a queue order and not a script.\n\n**After every user turn (primary loop)**\n\nInstructions to you: do not say \u{201c}bind\u{201d} to the user.\n\n4. Bind every `missing_data` field that utterance decides, including clear entailments across fields. Supply bindings and re-evaluate.\n5. Do not ask again about a topic the user already settled with a broader claim. Synonym probes of the same claim are forbidden.\n6. **Ambiguous polarity** \u{2192} do not bind; re-ask that one input clearly.\n7. **Broad / over-answer** that covers a topic \u{2192} bind all fields that claim settles; do not keep grilling that topic.\n8. **Blanket yes to everything** \u{2192} bind only what the yes clearly covers. Confirm unusual leftovers separately (minority `suggest`, or where true is not the compliant case). Never silent-fill from `-> suggest` alone; suggest is a prior for phrasing cluster questions, not an invented answer.\n\n**When inputs remain (fallback)**\n\n9. Ask **one** natural question aimed at the next undecided *topic* (or the single blocking input). Prefer what a consultant would ask. At most one unanswered question in flight. Help may inform meaning; ask normally.\n10. If the missing list is huge, you may evaluate the next undecided intermediate gate to learn which topic to ask, still without dumping the schema.\n\n**When the rule answers (verify before done)**\n\n11. Do not treat the first complete evaluation as final. Present a short table the user can check:\n - **Details**: each input in readable wording (help label or plain language), with the value you used.\n - **Answer**: the outcome for their question and any other derived answers you relied on.\n12. Close with a statement, not a question: e.g. tell the user to say if anything requires adjustment. If they correct something, update the data, re-evaluate, and verify again. Only then treat the outcome as final.\n\nRepeat the intake loop until the rule answers, then verify, then stop.\n";