Status: ready-for-agent

# 05 — Model-agnostic operator documentation and hardware-lane contract

## What to build

Document the capability-admission lifecycle, `doctor` usage, failure states, model-agnostic recipe semantics, and the certified hardware-lane release check. Correct setup guidance so it does not imply that an optional accelerator path is universally supported merely because a package can be installed.

Use generic commands/placeholders in primary docs. Any concrete model used for development belongs in a clearly labelled optional example or environment-gated test configuration, never a support guarantee.

**Code refs:**

- `QUICKSTART.md` — node installation/ROCm/optional-backend guidance
- `packages/node/meshnet_node/cli.py` — doctor user-facing output
- `docs/adr/0023-model-agnostic-node-capability-admission.md`
- `tests/test_node_startup.py`, `tests/test_real_model_backend.py` — integration marker conventions

## Test-first / verification

1. Add tests for concise doctor output/category mapping where practical.
2. Verify documentation commands use the generic selected-model interface and explain the distinction between validated versus merely detected hardware.
3. Add a release-CI runbook contract for an opt-in `integration` doctor run per certified hardware lane, with model identity supplied by CI configuration.

## Acceptance criteria

- [ ] Docs explain that readiness requires a successful real-forward capability report
- [ ] Docs distinguish detected hardware, validated recipe, and routable Node states
- [ ] Docs make no model/vendor/optional-kernel universal support promise
- [ ] Certified-lane CI contract is documented, including model-configurable integration environment and expected evidence
- [ ] Signed Node updates are listed as a follow-up; P0 is explicit that it does not dynamically install executable recipes or system dependencies

## Blocked by

`02-doctor-real-forward.md`, `04-tracker-validated-capability-routing.md`.