What failed
Nightly run, test node:
tests/unit/test_validate_no_raw_redis_delete.py::TestPopotoContextEntries::test_model_list_is_complete
Exact failure output:
tests/unit/test_validate_no_raw_redis_delete.py:294: in test_model_list_is_complete
assert not missing, (
E AssertionError: Popoto models absent from _POPOTO_CONTEXT in .claude/hooks/validators/validate_no_raw_redis_delete.py: ['InfrastructureReservation']. A raw command against these keys slips the context gate. Add each name to the list.
E assert not ['InfrastructureReservation']
Likely cause
InfrastructureReservation is a popoto.Model subclass defined at models/improvement_infrastructure_ledger.py:52. It is the only class in that module. It is not present in the _POPOTO_CONTEXT list in .claude/hooks/validators/validate_no_raw_redis_delete.py (list starts at line 234), and no existing entry matches it as a substring.
Introducing commit:
37dc10b33 2026-09-14 Tom Counsell Improvement controller lane 7: cloud execution capacity (Closes #3274) (#3299)
That commit added models/improvement_infrastructure_ledger.py (+142 lines) and did not touch validate_no_raw_redis_delete.py. That is precisely the drift this test was added to catch — the comment above the list records it drifting silently twice before the test existed (#2641).
Consequence beyond the red test: the guard described in docs/features/raw-redis-guard.md is context-gated. _guard bails out early unless the command text matches something in _POPOTO_CONTEXT, so a raw Redis command naming only InfrastructureReservation keys is currently not blocked. The failing test is reporting a real hole in the guard, not just a bookkeeping lapse.
Reproduces on origin/main
Yes. Reproduced at origin/main head b13dc8ad3078381bce5fb37fc3502def37c7e654, via scripts/pytest-clean.sh on the single node.
Suggested next steps
- Add
"InfrastructureReservation" to _POPOTO_CONTEXT in .claude/hooks/validators/validate_no_raw_redis_delete.py, in the alphabetical block with the other model names. Consider whether a snake_case variant (infrastructure_reservation) is also warranted; the list already pairs AgentSession with agent_session.
- Re-run the node to confirm green.
- Worth considering separately: this test only runs in the nightly, so the gap between the model landing and the hole being noticed was a full merge cycle. If the intent is that the guard is never incomplete on main, this check belongs somewhere that gates the PR rather than only the nightly.
Triage 2026-09-15
Status: confirmed still failing on main 205344717.
Single-line hotfix: Yes. Add "InfrastructureReservation", to the _POPOTO_CONTEXT list in .claude/hooks/validators/validate_no_raw_redis_delete.py, in the alphabetical block between "ImprovementRelease", (line 263) and "Job", (line 264).
Reduce-complexity option: This is exactly the mechanical, repo-growth-driven failure mode the guard's own comment admits to ("drifted silently twice before that test existed"). A hardcoded list re-fails every time a new popoto.Model subclass is added. The test companion (test_model_list_is_complete) already enumerates popoto.Model subclasses via introspection to catch drift — the guard itself should derive _POPOTO_CONTEXT's model names the same way at runtime instead of hardcoding them, which would remove this whole issue class permanently rather than requiring a new one-line PR per model.
What failed
Nightly run, test node:
Exact failure output:
Likely cause
InfrastructureReservationis apopoto.Modelsubclass defined atmodels/improvement_infrastructure_ledger.py:52. It is the only class in that module. It is not present in the_POPOTO_CONTEXTlist in.claude/hooks/validators/validate_no_raw_redis_delete.py(list starts at line 234), and no existing entry matches it as a substring.Introducing commit:
That commit added
models/improvement_infrastructure_ledger.py(+142 lines) and did not touchvalidate_no_raw_redis_delete.py. That is precisely the drift this test was added to catch — the comment above the list records it drifting silently twice before the test existed (#2641).Consequence beyond the red test: the guard described in
docs/features/raw-redis-guard.mdis context-gated._guardbails out early unless the command text matches something in_POPOTO_CONTEXT, so a raw Redis command naming onlyInfrastructureReservationkeys is currently not blocked. The failing test is reporting a real hole in the guard, not just a bookkeeping lapse.Reproduces on origin/main
Yes. Reproduced at
origin/mainheadb13dc8ad3078381bce5fb37fc3502def37c7e654, viascripts/pytest-clean.shon the single node.Suggested next steps
"InfrastructureReservation"to_POPOTO_CONTEXTin.claude/hooks/validators/validate_no_raw_redis_delete.py, in the alphabetical block with the other model names. Consider whether a snake_case variant (infrastructure_reservation) is also warranted; the list already pairsAgentSessionwithagent_session.Triage 2026-09-15
Status: confirmed still failing on main
205344717.Single-line hotfix: Yes. Add
"InfrastructureReservation",to the_POPOTO_CONTEXTlist in.claude/hooks/validators/validate_no_raw_redis_delete.py, in the alphabetical block between"ImprovementRelease",(line 263) and"Job",(line 264).Reduce-complexity option: This is exactly the mechanical, repo-growth-driven failure mode the guard's own comment admits to ("drifted silently twice before that test existed"). A hardcoded list re-fails every time a new
popoto.Modelsubclass is added. The test companion (test_model_list_is_complete) already enumeratespopoto.Modelsubclasses via introspection to catch drift — the guard itself should derive_POPOTO_CONTEXT's model names the same way at runtime instead of hardcoding them, which would remove this whole issue class permanently rather than requiring a new one-line PR per model.