harness-observabilitylisted

# Harness Observability Harness observability is the measurement layer that makes context engineering, architectural constraints, and garbage collection evidence-based rather than intuition-based. Without it, a harness is infrastructure you hope works. With it, you know. This skill covers four layers of observability, each answering a different question at a different timescale. This skill does not cover CI workflow configuration (middle loop), individual constraint design, or garbage collection rule authoring — those belong to their respective skills. It covers how to observe whether those mechanisms are operating effectively. For the snapshot schema and field definitions, consult `references/snapshot-format.md`. The snapshot includes a Diaboli panel (after Session Quality, before Operational Cadence) that surfaces advocatus-diaboli activity as descriptive stats across all objection records. ## The Four Layers | Layer | Question | Timescale | Consumer | | ------- | ---------- | ----------- | ---------- | | Operational Cadence | "Is the harness running?" | Session / weekly / quarterly | Developer in session | | Trend Visibility | "How has the harness changed?" | Weekly / quarterly | Team over time | | Telemetry Export | "Can I visualise this externally?" | Continuous | External dashboards | | Meta-Observability | "Is the observability itself working?" | Quarterly | Agents + team | ## Layer 1: Operational Cadence The harness has mechanisms — audit, GC, reflection, muta