<!--
  Agent rules file from "How coding agents fail" (carrick.tools).
  Paste the sections below into the instructions file your agents read
  (CLAUDE.md, AGENTS.md or equivalent) and edit the bracketed parts.
  The full guide explains what each rule prevents and where rules stop
  working: https://carrick.tools/agent-failures/
-->

# Working in this codebase

## Contracts and other services
If the answer is defined by another service (its endpoints, its real
request/response types, who consumes it, or any local type, constant,
or SDK helper that mirrors it), verify against the producing service
before you rely on anything local. Local copies of another service's
contract drift and lie; the producing service defines the contract,
and if two definitions disagree, the producer's wins.

## Before writing new code
Inside this repo, grep and read are fast; use them. One exception:
before writing any new helper, parser, validator, or domain function,
check whether the behaviour already exists. Search likely names and
their synonyms, and read the module where that behaviour would live;
if you have a semantic or intent-based code search, query it with a
plain-English description of the behaviour instead. Grep can prove a
name is absent; it can never prove the behaviour is. Run that check
before your first search on the task, not once you are about to
write. By the time you have a design in mind, a near-miss reads as a
reason to start fresh.

## Adopting what you find
If an existing function implements the behaviour you need, import it
or extend its module. A signature mismatch is a reason for a thin
wrapper, not a rewrite. If you deliberately do not adopt something
you found, say so in one line and give one of these reasons: the
behaviour genuinely differs, the module cannot be imported from
here, or it is deprecated. A signature mismatch, a naming
difference, or an extra parameter are not on that list. Those are
wrapper cases.

## Enumeration
For any "find all X" task, enumerate from a listable source of truth
(registry, routes table, directory listing, dependency graph) and
cite it. Do not answer enumeration questions from search results.

## Where things live
[Repo/domain map: which repo owns which domain, where contracts are
defined, which repos to check out side by side for cross-repo work.]

## Verification
Agreement between runs, agents, or reviewers is not verification.
Verify against ground truth: run the code, read the producing
service's actual contract.
