House rules

House rules are plain-language invariants. They do not create findings by themselves — they change how a juror votes on findings that touch them.

What a rule does

A rule is not a pattern match and not a linter. It is context handed to every juror during the hearing. When a candidate finding touches a rule, jurors weigh it as evidence: a finding that would otherwise have been refuted as a style preference can be affirmed because your team declared it an invariant.

rules:
  - "Money paths must be idempotent. A retry must never settle twice."
  - "No network calls inside a request handler; queue them."
  - "Public API responses are versioned. Never change a field's meaning."

Writing rules that work

• State the invariant, not the fix. “Money paths must be idempotent” is better than “use an idempotency key” — the second one misses violations that need a different remedy.
• Give the consequence when it is not obvious. “…a retry must never settle twice” tells a juror what harm to look for.
• One invariant per rule. Compound rules get partially applied.
• Do not restate your linter. Anything a linter already enforces belongs in suppressions, not here.

Scoping rules to paths

Rules can be limited to the code they apply to, which stops an invariant about billing from colouring every hearing in the repository.

rules:
  - text: "Money paths must be idempotent."
    paths: ["src/billing/**", "src/payments/**"]

Limits

Up to 25 rules per repository, 300 characters each. Beyond that, jurors start weighing rules against each other rather than against the code — if you need more, scope them to paths instead of adding them globally.