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 (\"does X count as Y?\", \"should that count as\u{2026}: is that right?\"). Ask about their situation. Bind clear entailments from their answers using help/schema; do not quiz them on the mapping.\n\nNever present your interpretation as the truth (\"that counts as\u{2026}\", \"that\'s fine\", \"is sturdy\"). When a judgment call cannot be answered from their situation plus help/schema, ask for their confirmation.\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. Keep that Show for type/help/suggest lookups. Empty `needed_by_rules` means reuse catalog only \u{2014} do not prompt or bind those keys; intake keys come from the `Missing data` block on `run`.\n3. **`run`** one target via `rules` (string or array). Response is formatted explanation trees (always on). Unbound input **keys** appear in a `Missing data` block \u{2014} look up type, help, and suggest on the Show from step 2. Prefer tool `run` (deprecated alias `evaluate` still works).\n\n**After every user turn (primary loop)**\n\n4. Bind every `Missing data` field that utterance decides, including clear entailments across fields. Supply bindings in `data` (JSON object) and re-`run`.\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 `run` 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-`run`, and verify again. Only then treat the outcome as final.\n\nRepeat the intake loop until the rule answers, then verify, then stop.\n";