02 — H11a Containment

Mechanism proven live

autofix_heal_description_basic (in /opt/incomex/dot/bin/dot-hc-executor, lines 548-690):

1. For each governed entity with empty description, runs UPDATE <tbl> SET description='' expecting a description birth-guard to regenerate.
2. Post-heal verify: if still empty → NT9 anti-loop → fn_log_issue('heal_description_basic','critical','H11a anti-loop: heal empty on <tbl>.<code>', ... 'template_gap' ...).
3. For system_issues rows (NULL description by construction) the guard never regenerates → anti-loop logs a NEW system_issues row with NULL description → re-detected next run = self-amplifying recursion (all-time 216,378 issue rows / 2,105 entity codes).
4. Successfully-healed entities get INSERT INTO entity_labels(entity_code,'PROV-DOT','dot') → the 4,043 entity_labels births.

Containment applied

UPDATE system_health_checks SET check_kind='detect_only', auto_fix_action=NULL WHERE code='H11a'.

• Rollback: SET check_kind='detect_and_fix', auto_fix_action='heal_description_basic'.
• Config-row change only; no code edit; executor and all other checks untouched.
• healed=0 historically, so no real healing capability is lost; H11/H11b still surface coverage.

Status views

v_h11a_containment_status = CONTAINED (heal_disabled=true). v_h11a_no_go_guard 3/3 pass (heal disabled, fn_log_issue idempotent, gateway enforces). v_h11a_next_cycle_expectation: 13:00 cycle → zero heal-driven births.

Why not stop the whole executor

Forbidden unless active runaway with no narrower option. H11a is one check among many (dot-context-pack-verify, dot-dot-health, etc. all log via the same executor). Disabling only H11a's fix action is the narrowest containment and is exactly Codex's recommendation.