Status: ready-for-agent

# 01 — Generic capability and recipe report

## What to build

Create a model-agnostic node capability domain object and local versioned recipe-manifest reader. It must represent a selected Model Artifact identity/revision/config fingerprint, Shard range, named recipe ID/version, device/backend identity, validation timestamp/duration, success/failure state, and sanitized diagnostics.

Do not add Qwen-, FLA-, Triton-, CUDA-, ROCm-, or vendor-specific branches. A recipe is generic data; specific runtime behavior remains in the existing backend.

**Code refs:**

- `packages/node/meshnet_node/model_catalog.py` — existing generic HF config/model metadata helpers
- `packages/node/meshnet_node/hardware.py` — device identity/executability inventory
- `packages/node/meshnet_node/model_backend.py` — model/shard loading path
- `packages/node/pyproject.toml` — package data declarations

## Test-first

1. Write a unit test building reports for two arbitrary fixture model IDs and asserting no model-specific normalization/branch is required.
2. Write a manifest-version validation test: valid local manifest loads; malformed/unknown schema produces actionable non-secret diagnostics.
3. Implement the smallest schema, serialization, and local manifest reader needed by later stories.

## Acceptance criteria

- [ ] Capability report has a stable JSON-serializable schema with model identity/fingerprint, shard range, recipe ID/version, backend/device identity, status, timing, and sanitized diagnostic fields
- [ ] Generic arbitrary model IDs are preserved; no Qwen or optional-kernel name is a product default or code-path discriminator
- [ ] Local recipe manifest has an explicit schema/catalogue version
- [ ] Malformed manifest/report input fails locally with actionable diagnostics and never leaks environment secrets
- [ ] Unit tests cover serialization, schema validation, and model-agnostic behavior

## Blocked by

None.