# FIRST RULE OF CURSOR - MANDATORY: READ THIS FIRST
MANDATORY FIRST ACTION: When the user sends their first request in a conversation, you MUST immediately read style.md using the read_file tool BEFORE performing any other action (no searches, no code reading, no tool calls of any kind). This is the absolute first step - do not answer the question, do not search, do not read other files. Read style.md first, then proceed with the user's request.


--

### Cursor Rule: Claims vs Hypotheses

- Label uncertain reasoning as Hypothesis; only use Claim with explicit evidence.
- Claims must cite evidence (code refs, logs, metrics). Otherwise, downgrade to Hypothesis.
- For each Hypothesis, include:
  - Hypothesis: concise, falsifiable statement.
  - Predictions: measurable outcomes if true.
  - Test: minimal experiment (setup, variables, metrics, pass/fail).
  - Confounders: likely alternatives and controls.
- Language:
  - Hypothesis: “suggests”, “may”, “indicates”.
  - Claim (with evidence): “shows”, “demonstrates”, “causes”.
- Trigger this rule when explaining performance differences, algorithm behavior, or proposing changes.
- Whenever you see an error happen more two or more times in a row, stop, state the problem clearly, then hypothesize the cause.  Then test to determine the cause. Once the cause is determined, fix the problem.

--

When running python code, you'll need to set PYTHONPATH

--

When your write code, always make sure `pytest -sv tests` and `ruff check` pass.
Iterate until they do.

--

# Debugging process rule

When debugging: run the broken code first to observe the actual failure, write a test that reproduces that exact failure, then fix it. Don't guess—observe empirically. Replicate the exact code path that fails in the test, not a simplified version. The broken code is the source of truth; observe it directly before fixing.
--


Acronyms we can use to make communication more efficient:
DRY: Don't Repeat Yourself. The user would like you to look for opportunities to factor out common code.
DCC: Don't Change Code. Repond to the user's query, but don't change *any* code.
DCT: Don't Change Tests.  Repond to the user's query, but don't change any tests. You may change non-test code, though.
OCT: *Only* Change Tests. Repond to the user's query, but don't change any non-test code. You may change test code, though.
RR: Restate my request clearly. Lmk if you have any questions. DCC

--

# Cursor Roles
The Tester: The Tester writes unit tests but does not implement the code being tested. Tests for unimplemented code should be failing tests.
The Implementor: The Implementor writes code but does not write or change tests.

--

After every 5th request, `cat .cursorrules`
