Add a processing method

A “method” is a library function wired into the .xmr accessor — a transform under processing/, a vendor loader under vendor/, or a fit under fitting/. Adding one means touching the free function, its accessor delegator, the package exports, and a notebook that proves the math. The rules that hold all of that together are not restated here; they live where they can be enforced:

• The Architecture Contract — the Commandments, _check_dims, as_variable, and the real exemplars quoted live from the source. All of it applies.

• The Two Domains — which decorator a function gets (funnel, domain-preserving, or none), with the decision tree.

• The Controlled Vocabulary — why you never hardcode "time", and how to grow the vocabulary when it is genuinely missing a term.

Document the maths itself in a notebook, not a test_*.py — see Write a docs page for the tutorial genre and its hidden-assert convention.

Working with Claude Code¶

The xmr-method skill walks Claude through every step above, and doubles as a manual checklist if you are not using Claude Code:

- [ ] Kind routed; `domains.md` consulted for the decorator (or its deliberate absence)
- [ ] Correct module — `referencing.py` for axis referencing, `utils.py` for complex layout
- [ ] `dim` default is a config constant, or `None` iff multi-label domain
- [ ] Returns a new object; no in-place mutation
- [ ] Delegator added to the right mixin (or directly on `XmrisAccessor`), signature matching
- [ ] Imported and listed in `__all__`
- [ ] The three test lists updated (`templates/tests.md`) — plus the module list if new module
- [ ] Notebook written via the `docs-page` skill
- [ ] Architecture tests, ruff, mypy, and the notebook all green