observability

Diagnose hard-law violations, observability modes, and event backpressure in the simulation engine.

Updated Feb 8, 2026
One-click install
npx skills add https://github.com/ttnhan18062000/rpg-based-simulation --skill observability-ttnhan18062000
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: observability
Source: https://github.com/ttnhan18062000/rpg-based-simulation/tree/main/.agents/skills/observability
Command: npx skills add https://github.com/ttnhan18062000/rpg-based-simulation --skill observability-ttnhan18062000

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When working in the src/observability/ subsystem of this deterministic RPG engine, engineers struggle to interpret HardLawViolationError failures, missing or sampled events under load, and mode-specific logging behavior without reading eight separate contract documents. ## Core Features & Use Cases - Hard Law Reference: Documents all 7 HardLawMonitor invariant laws (HP, readiness, gold, stamina, position, occupancy, spawn) with their DirtySet scopes and severity levels. - ObservabilityMode Policy: Explains OFF, LIGHT, DEBUG, CERTIFICATION, and LONG_RUN mode behavior, including the documented LONG_RUN gap where violations bypass the log stream. - EventRecorder Backpressure: Details the four backpressure modes (NORMAL, PRESSURE, DEGRADED, SURVIVAL) driven by queue fill ratio, plus Prometheus metrics for violation tracking. - Use Case: You see events disappearing under load. Instead of assuming a bug, check observability_status() to confirm whether PRESSURE or DEGRADED sampling is working as designed. ## Quick Start Ask the AI to explain why a hard-law violation warning is missing under LONG_RUN mode and where to find the persisted violation records.

Frequently Asked Questions about observability

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a HardLawViolationError in the simulation engine?

Check the current ObservabilityMode first, since DEBUG and CERTIFICATION raise HardLawViolationError immediately while LIGHT only logs warnings. Then identify which of the 7 laws failed using the law_id in the sim_hard_law_violations_total Prometheus metric.

Why are events missing from the event recorder under load?

Missing events are usually caused by EventRecorder backpressure, not a bug. When queue fill exceeds 70%, PRESSURE mode samples INFO/DEBUG events 1-in-5, and DEGRADED mode drops them entirely. Check observability_status() for the current mode and events_dropped count.

Why is there no warning log for a hard-law violation in LONG_RUN mode?

LONG_RUN mode has a documented gap: violations are persisted to hard_law_violations.jsonl and routed to AlertsManager, but the mode-gating logic only handles LIGHT logging and DEBUG/CERTIFICATION fail-fast. Check the JSONL file directly instead of the log stream.

What are the 7 hard laws monitored by HardLawMonitor?

The laws cover HP, readiness, gold, and stamina non-negativity, finite positions, single solid entity per tile, and spawn occupancy. Six are DirtySet-scoped O(1) per-tick checks; LAW-SPAWN-OCCUPANCY runs once before the first tick as a full scan.

Does LIGHT observability mode add tick-compute overhead?

No measurable overhead is added in LIGHT mode, as confirmed by tests/perf/test_hard_law_monitor_overhead.py. The checks are DirtySet-scoped and O(1) per tick, so only entities that changed are validated.

What is out of scope for the observability skill?

Development work in src/simulation_quality/, including pillar scoring and quality_hub.py internals, is a separate domain covered by the simq-dev skill. This skill covers only the src/observability/ subsystem and its contract docs.