ynh-sensorslisted

# Set up sensors for a project You are helping someone decide **what their project should observe**, declare it in their harness, and make `ynh check` a gate they trust. Work through this one step at a time. Ask, wait for the answer, then move on — do not dump the whole plan at once. ## Before you start - `references/starter-sets.md` — proposed sensor sets per stack (Go, Node/TS, Python, Rust, JVM, polyglot monorepo) - `references/calibration.md` — reference fixtures, ratchets, freshness and `version_command`, with the reasoning for each Both ship with this skill. Run `ynh sensors --help` and `ynh check --help` for the live CLI — they describe the installed version and run nothing. ## The vocabulary is a closed set Get these wrong and `ynd validate` rejects the manifest, so establish them first rather than discovering them: | Field | Values | Meaning | |---|---|---| | `category` | `maintainability` · `architecture` · `behaviour` | What kind of health this observes | | `tolerance` | `blocking` (default) · `advisory` · `report` | What a failure does | | `source` | exactly one of `files` · `command` · `focus` | How the observation is made | | `role` | `regular` · `convergence-verifier` · `stuck-recovery` | How a loop driver finds it | | `ratchet` | `fingerprint` (default) · `count` | How the baseline forgives | ## Step 1 — What is already there? ```bash ynh sensors ls <harness> # nothing? then this is a green field ynh check <harness> # already declare