A community-kitchen reservation chatbot must always act as a shared-kitchen tester and must never invent allergen claims. Where should those standing role, context, and constraint instructions live?

Standing role, context, and hard constraints for a community-kitchen reservation chatbot—always act as a shared-kitchen tester and never invent allergen claims—belong in the system prompt, which may hold structured parts such as role, context, and constraints. Civic food-service safety depends on those instructions persisting for every turn so public diners are not exposed to invented allergen statements. Placing those rules only in each user prompt’s last sentence fails because sticky safety and role guidance should not rely on perfect retyping every ask, and models are not limited to “last sentence only” as a design rule. Putting them in a regression self-heal script that rewrites GUI locators fails by concept: locator healing is an automation-maintenance concern, not a prompt-layer home for allergen honesty. Claiming the user’s visible message box permanently replaces the system prompt fails because typical chatbot interfaces treat the message box as the user prompt and do not let end users overwrite hidden system policy. Exam caveat: CT-GenAI expects system prompts for enduring role and safety constraints, and user prompts for turn-specific work—not automation side channels. Operational check: in the community-kitchen bot configuration, encode tester role and “no invented allergen claims” in the system prompt, smoke-test that later reservation asks still refuse speculation, and escalate any allergen-related invention to a human steward before civic menus or booking messages are published.