neuron-tai/.scratch/node-capability-admission/issues/05-docs-hardware-lane-contract.md

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.