The hook's OBSERVED state, live-queried: running settings + version (vs busbar's desired copy, with a drift verdict) and self-reported metrics. reported=null when the hook doesn't answer (fail-open)

The DESIRED settings side of hooks/{name}/status: busbar's registry copy of the hook's settings (KEY NAMES only, see [super::HookView::settings_keys]) and their version.

Validated + bounded self-reported metrics; each entry carries {name, type, value} and, when the hook sent them, optional labels/quantiles/estimated/ci_low/ci_high/help/ label/unit/viz/max members.

schemars' blanket JsonSchema impl for serde_json::Value renders as the JSON-Schema-2020-12 boolean true (schemars-1.2.1's json_schema_impls/serdejson.rs), which is legal 2020-12 but, nested here as this array's items, is a boolean SUB-schema, and kin-openapi (the parser under oapi-codegen, which every published SDK generates through) cannot represent one at all: the parse aborts, taking out Python/TS/Go SDK regeneration simultaneously. #[schemars(schema_with)] overrides just this field's schema to {"type": "array", "items": {}}; {} is the equivalent "accepts anything" schema every generator DOES understand, and is what busbar-ui's own openapi-prep.py already rewrites items: true into client-side. This is the only items: true in the document; every other additionalProperties: true schemars emits elsewhere is a boolean in a position kin-openapi handles fine and is deliberately untouched.

The REPORTED settings side of hooks/{name}/status: what the hook says it is actually running (present only when the hook answered status).

KEY NAMES only, and for a sharper reason than the desired side: the reported bag is the hook's ECHO of the SECRET-RESOLVED settings busbar pushed it, i.e. the PLAINTEXT of every SecretRef, and this read is reachable at READ-ONLY admin scope. null when the hook answered status but reported no settings.