register-fixturelisted

# Skill: register-fixture Make something a spec can ask for by name. This is the step most often skipped, and it fails loudly but misleadingly: the spec errors on an undefined argument, so the investigation starts in the spec rather than at the missing registration. ## Preconditions 1. `.claude/test-profile.md` exists and names where fixtures are defined. If it says `none`, this repo passes dependencies some other way — follow that, and do not introduce a fixture layer without asking. 2. The thing being wired already exists and is importable. ## Procedure ### 1. Pick the file The profile records whether this repo has one shared context file or several independent ones, one per test group. Both designs are legitimate: - **Independent per group** — a browser spec cannot accidentally acquire a database connection. Cheap isolation, some duplication. - **One shared, composed** — no duplication, but a careless dependency makes every spec pay for a resource only some need. Whichever it is, add to it. Do not migrate the repo to the other design as a side effect of wiring one model; that is a separate, discussable change. ### 2. Register Three edits, in the repo's own style: 1. import the thing; 2. declare it in whatever type or shape describes the available context; 3. provide it — construct, hand it to the test, and clean up afterwards. Match the neighbours exactly, including ordering if the file is ordered. This file is read constantly; an entry that reads di