docs(spec): document docker test runner and model selection guideline

Add a "Running locally" subsection to §13 with the docker invocations
for phpunit / phpstan / php-cs-fixer (composer is not on the host),
plus a guideline to switch to Sonnet 4.6 for running the suites/lints
and back to Opus for diagnosing failures or wrapping up.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

SPEC.md

@@ -963,6 +963,31 @@ Execute in order. After each milestone: run tests, run linter, commit with a cle
 - **Static analysis**: PHPStan level 8 on `src/`. PHP-CS-Fixer for style.
 - **Security**: `composer audit` in CI.
 
+### Running locally
+
+Composer/PHP are **not** installed on the host — every PHP-side command runs inside the prebuilt `irdb-api` / `irdb-ui` images, mounting the working tree at `/app` and bypassing the entrypoint with `--entrypoint php`.
+
+```bash
+# api
+docker run --rm -v "$PWD/api":/app -w /app --entrypoint php irdb-api:latest vendor/bin/phpunit --exclude-group perf
+docker run --rm -v "$PWD/api":/app -w /app --entrypoint php irdb-api:latest vendor/bin/phpstan analyse --memory-limit=512M
+docker run --rm -v "$PWD/api":/app -w /app --entrypoint php irdb-api:latest vendor/bin/php-cs-fixer fix --dry-run --diff
+
+# ui (same pattern, swap image + path)
+docker run --rm -v "$PWD/ui":/app -w /app --entrypoint php irdb-ui:latest vendor/bin/phpunit
+docker run --rm -v "$PWD/ui":/app -w /app --entrypoint php irdb-ui:latest vendor/bin/phpstan analyse --memory-limit=512M
+docker run --rm -v "$PWD/ui":/app -w /app --entrypoint php irdb-ui:latest vendor/bin/php-cs-fixer fix --dry-run --diff
+```
+
+Filter to a single test with `--filter <ClassName>`. Pass `-d memory_limit=…` if a suite needs more headroom.
+
+### Model selection for test/lint runs (Claude Code)
+
+- **Switch to Sonnet 4.6 (`/model sonnet`) before running test suites, PHPStan, or PHP-CS-Fixer.** These are long, repetitive tool-call loops with cheap reasoning per step — Sonnet is the right tool for the job.
+- **Switch back to Opus (`/model opus`) to diagnose failures, design fixes, or once verification is finished.** Opus is the right tool for understanding why a test failed and deciding what to change.
+
+This is a workflow guideline, not a hard rule: if Sonnet gets stuck interpreting an error, escalate to Opus immediately rather than thrashing.
+
 ---
 
 ## 14. Coding Conventions