Instruction file imported from symmatree/tiles (.cursor/rules/theories-vs-facts.mdc). Copyright stays with the author.

Theories vs facts (communication)

Theories are fine. Reasonable guesses, likely mechanisms, and "this would explain the symptoms" belong in the conversation. What is not fine is dressing a theory as a fact.

Do not:

• Write situation-specific diagnostics or finished-manual voice for the reader's exact run when you are actually drafting the record as you go. That reads like fan fiction with a manual's authority. Stay behind the evidence: only what was observed or cited belongs in that register.
• Say or imply that something was checked, confirmed, or verified unless you actually performed that check in this session or cite concrete evidence (log line, command output, doc section).
• Say or imply that a vendor documents, guarantees, or states something unless you can point to that text (link, section, quote).
• Use frequency words like often, usually, typically for product or tool behavior unless they rest on cited documentation or clearly labeled first-hand observation.

Do:

• Mark inference explicitly: theory, hypothesis, plausible explanation, not verified here, operator-reported pattern, I did not find a primary source.
• Separate what we observed from what we infer in separate sentences or bullets.
• When uncertain, say so plainly instead of sounding authoritative.

If a statement could be read as "this is how the world works" but you only have a likely idea, rewrite until the epistemic status is obvious to a careful reader.