docs: record unit-test invocation and e2e component routing

- AGENTS.md documented only the E2E command; add the parallel unit one
- note that ha_search routes to the component on every e2e lane

Author: Sergey

AGENTS.md

@@ -417,6 +417,16 @@ uv run hamcp-test-env --no-interactive   # For automation
 
 Test token centralized in `tests/test_constants.py`.
 
+**Unit tests** (`tests/src/unit/`, no Docker) — run them in parallel, as CI does
+(`pr.yml`); serial takes 25+ minutes for ~11k tests:
+
+```bash
+uv run pytest tests/src/unit/ -n auto --tb=short
+```
+
+`tests/pytest.ini` sets `--maxfail=3`, so a run reporting "3 failed" has stopped
+early rather than finished — pass `--maxfail=0` when you need the full picture.
+
 ### Code Quality
 
 C901 (mccabe complexity ≤10) is enforced repo-wide with zero per-file exemptions (issue #925 cleared the grandfathered list) — never reintroduce a `["C901"]` per-file-ignore; extract helpers instead.
@@ -896,7 +906,10 @@ empty, so the English a `tools` entry translates is read from the tool
 definition in `src/ha_mcp/tools/` — the `title=` kwarg and the summary
 paragraph of the docstring, or the `FEATURE_GATED_TOOLS` stub where a gated
 tool shows one instead. Editing that summary moves the English out from under
-six catalogs; the pipeline retranslates them. One deliberate exception: a
+six catalogs; the pipeline retranslates them. A parameter's
+`Field(description=...)` is NOT in the baseline — only the title and the
+docstring summary are — so editing one owes no translation work. One
+deliberate exception: a
 change to a feature-gated tool's PARSED docstring (its stub unchanged) is
 stub-review work, not translation work — the pipeline holds that baseline key
 stale, and the locale-sync run stays red until a human confirms the stub

tests/AGENTS.md

@@ -39,6 +39,10 @@ testcontainer run).
   EVERY lane by `_install_custom_component`. A test may therefore rely on
   component-gated behaviour with no marker — e.g. a config entry's
   `unique_id`, which Home Assistant's own API never exposes on any endpoint.
+  Consequence for `ha_search`: a query-driven call is served by the component's
+  in-process scan, not the legacy REST path, so a test written for legacy-only
+  behaviour passes *vacuously*. Naming a `search_types` the component does not
+  serve (`"dashboard"`) sends the whole call down the legacy path.
 - **The in-process "server" config entry** of that same component (#1527) is
   the embedded backend only, seeded separately. That one IS lane-specific.