AGENTS.md: editing erp-method

This repo changes how other agents build customers' systems. Edit it the way you would edit a contract.

1. Every rule says where it was learned: a lab run with its date, a live measurement, a recorded fault, or a named source. A rule with no origin is an opinion; leave it out.
2. Phase cards stay at or under 60 lines; erp/build.md at or under 140. Numbered steps, one copy-ready example, a "done when". Agents follow short numbered guidance and skip long prose (the lab, 2026-10-17). Reasoning goes in modules/lifecycle.md or modules/pattern.md, not the cards.
3. Name the tool, or say it does not exist. Write the exact command. If it is not built yet, say "not built yet: do X by hand". Never describe a planned tool as if it ran.
4. Changes to agent-facing text need a lab check before a release: a fresh directory, no memory, the lab CLI, signed out. Record the result in the PR. Two lab modes rehearse the customer cycle with a real person as the customer: Mode A, a new system (consult → proposal rounds → the person signs the BPMN → build → bench and an independent auditor check built = signed), and Mode B, a change to a signed, live system (v1 → v2 diff, impact with counts, migration of the test copy, v1 runs still conform to v1). Only words the person typed count as approval.
5. Public repo: no client names. Say "a pilot engagement" or "an earlier client CRM". scripts/check.py refuses the known ones.
6. The method is not "rows only". Customization has three depths (configure, extend, own the code); only the foundation is kept. Say plainly that everything is customizable down to the code.
7. Module specs (modules/<id>/module.yaml) must keep passing the blog's check:modules. Run python3 scripts/check.py and python3 scripts/build_index.py, and commit index.json.
8. Every dodil://erp/phase/<x> reference needs its file. The check enforces it.