ynh-sensors

Topics in the source

• Set up sensors for a project
• Before you start
• The vocabulary is a closed set
• Step 1 — What is already there?
• Step 2 — Propose a set across all three categories
• Step 3 — Place each on the tolerance ladder
• Step 4 — Adopt into a repo that is already failing
• Step 5 — For a files sensor, declare observes

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. 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 versioncommand, 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. 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 | is an installed

This is an excerpt. Refer to the complete source and its current requirements.