Development record
the guard health report still says a broken repo guard.json means commands run unchecked, but the fail-safe fix (iss-2608261551087492) keeps the bundled hazards armed in that case: guard_health.go's guardRegistryUnloadableReason and the RegistryLoadable bool model a broken repo layer as fully-unguarded, which is now false. The health check should distinguish 'repo overrides dropped, bundled hazards still armed' (a mild, expected state) from 'no registry at all' (the only genuinely-unguarded state, which the embed makes unreachable). Refine the health model and reword the reason. Follow-up to the fail-safe change.
the guard health report still says a broken repo guard.json means commands run unchecked, but the fail-safe fix (iss-2608261551087492) keeps the bundled hazards armed in that case: guard_health.go's guardRegistryUnloadableReason and the RegistryLoadable bool model a broken repo layer as fully-unguarded, which is now false. The health check should distinguish 'repo overrides dropped, bundled hazards still armed' (a mild, expected state) from 'no registry at all' (the only genuinely-unguarded state, which the embed makes unreachable). Refine the health model and reword the reason. Follow-up to the fail-safe change.
Frontmatter
| id | iss-2608281222011114 |
|---|---|
| type | issue |
| lifecycle | resolved |
| severity | minor |
.abcd/work/issues/resolved/iss-2608281222011114-guard-health-still-reports-unchecked.md
open on GitHub ↗ · commit history ↗
mentions1
- iss-2608261551087492A malformed or oversized repo guard.json disables the entire guard registry, bundled hazards included: the guard fail-opens loud (exit 1) when the repo layer cannot load, so one broken repo file switches off protections that never depended on it. This is the recorded fail-open doctrine, and a red-team round demonstrated its cost end to end. Decide the blast radius deliberately: fall back to bundled defaults when only the repo layer is broken, or keep whole-registry fail-open and record why in an ADR.