expand_query: add rule 15 no-fabrication guard for unrecognized named entities (#44)

A regression run of the merged decomposition rules (13/14) found the
existing no-fabrication clause too narrow: rule 13 stops invented category
*members*, but the model still manufactured authoritative-sounding domain
detail for a *named entity it does not recognize* (a fictional medical
condition expanding to confident clinical terminology — actively harmful
in medical/legal/safety contexts).

Rule 15 (UNRECOGNIZED OR UNVERIFIABLE NAMED ENTITIES) generalizes the
guard: do not manufacture members, terminology, treatments, or attributes
for an unrecognized entity; expand only with generic, neutral phrasings of
the surrounding topic. Additive; recognized-entity queries expand as before.
Text is byte-identical to scolta-php's DefaultPrompts and scolta-python's
prompts.py copy; the compiled WASM must be rebuilt downstream.

Adds test_expand_query_forbids_fabricating_unverified_entities and a CHANGELOG entry.

Author: jeremyandrews

CHANGELOG.md

@@ -6,6 +6,9 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 
 ## [Unreleased]
 
+### Added
+- **No-fabrication guard for unrecognized named entities in the default `expand_query` prompt (rule 15).** A behavioral regression run of the merged decomposition rules (13/14) found the existing no-fabrication clause too narrow: rule 13 forbids inventing *members* to fill a category list, but nothing stopped the model from manufacturing authoritative-sounding domain detail for a *named entity it does not recognize*. Observed across demos, a fictional medical condition expanded to confident clinical terminology and a made-up product to confident attributes, while a fictional planet was handled correctly — inconsistent, and in a medical/legal/safety context actively harmful. New rule 15 (UNRECOGNIZED OR UNVERIFIABLE NAMED ENTITIES) generalizes the guard: when a query names a specific entity the model does not recognize as real and well-known, it must not manufacture members, terminology, treatments, or attributes for it, and must expand only with generic, neutral phrasings of the surrounding topic ("treatment for Glorptosis" → "medical treatment" / "therapy options" / "symptom management", not invented pathology). The rule is a guard, not a decomposition rule, so the existing 2-4/up-to-6 cap line is unchanged, and it does not affect cases where rule 13 already works (those name *known* categories). This text is byte-identical to the line added to scolta-php's `DefaultPrompts` `'expand_query'` template and scolta-python's `prompts.py` copy; the compiled WASM must be rebuilt downstream so the client-side AI path picks up the new text. Covered by `test_expand_query_forbids_fabricating_unverified_entities`. Additive: queries that name a recognized entity expand exactly as before.
+
 ## [1.0.1] - 2026-06-05
 
 ### Added

src/prompts.rs

@@ -20,6 +20,7 @@ IMPORTANT RULES:
 12. For CONSTRAINT QUERIES ("without X," "X-free," "no X," "can't have X," "vegetarian," "gluten-free," "dairy-free," etc.): preserve the constraint in your expansions. "Without eggs" → ["egg-free baking", "vegan baking recipes", "eggless recipes"]. Do NOT drop the constraint and expand only the general topic.
 13. CATEGORY → MEMBERS. When the query names a category, family, or region that has well-known concrete members, expand into the members, not synonyms of the category: "version control systems" → ["Git", "Mercurial", "Subversion"]; "European cars" → ["German cars", "Italian cars", "French cars"]; "Nordic countries" → ["Sweden", "Norway", "Denmark"]; "Southeast Asian food" → ["Thai", "Vietnamese", "Indonesian"]. Only decompose when you can name the members confidently. If you cannot, fall back to normal alternate phrasings — never invent members to fill the list.
 14. CONTEXT / USE-CASE → CONCRETE ITEMS. When the query names a context, occasion, or use-case rather than a thing, expand into the concrete item types that serve it, not restatements of the context: "home office setup" → ["standing desk", "ergonomic chair", "monitor arm"]; "first aid supplies" → ["bandages", "antiseptic", "gauze"]; "summer lunch" → ["cold salads", "chilled soups", "sandwiches"]. Keep the context implicit in the phrasing; do not restate it as a synonym ("light summer meals").
+15. UNRECOGNIZED OR UNVERIFIABLE NAMED ENTITIES. When the query names a specific entity you do not recognize as real and well-known — a product, place, organization, mission, regulation, medical condition, or similar — do NOT manufacture members, terminology, treatments, or attributes for it. Expand only with generic, neutral phrasings of the surrounding topic, and never produce authoritative-sounding domain-specific detail that presupposes the entity is real. This matters most for medical, legal, and safety queries, where inventing plausible clinical, legal, or technical detail is actively harmful: "treatment for Glorptosis" → ["medical treatment", "therapy options", "symptom management"], not invented drugs or pathology.
 
 Examples:
 - "customer support" → {"terms": ["help desk", "customer service", "support center", "contact us"]}
@@ -387,6 +388,18 @@ mod tests {
         );
     }
 
+    #[test]
+    fn test_expand_query_forbids_fabricating_unverified_entities() {
+        assert!(
+            EXPAND_QUERY.contains("UNRECOGNIZED OR UNVERIFIABLE NAMED ENTITIES"),
+            "expand_query must contain rule 15 (no-fabrication guard for unrecognized entities)"
+        );
+        assert!(
+            EXPAND_QUERY.contains("do NOT manufacture"),
+            "rule 15 must forbid manufacturing detail for unrecognized entities"
+        );
+    }
+
     #[test]
     fn test_expand_query_reconciles_term_cap_for_decomposition() {
         // The 2-4 cap must explicitly allow a larger fan-out when decomposing.