Files
drew b499834c0f
CI / lint (pull_request) Successful in 42s
CI / typecheck (pull_request) Successful in 55s
CI / quality (pull_request) Successful in 59s
CI / security (pull_request) Successful in 1m16s
CI / helm (pull_request) Successful in 40s
CI / build (pull_request) Successful in 43s
CI / push-validation (pull_request) Successful in 20s
CI / unit_tests (pull_request) Successful in 4m26s
CI / docker (pull_request) Successful in 1m25s
CI / coverage (pull_request) Successful in 9m34s
CI / integration_tests (pull_request) Failing after 21m41s
CI / status-check (pull_request) Failing after 3s
fix(coverage): resolve fail-under from pyproject in threshold-enforcement step (WS5)
The coverage_report noxfile session now delegates COVERAGE_THRESHOLD to the
pyproject single source (`COVERAGE_THRESHOLD = _read_coverage_fail_under()`),
so the AST value is a Call, not a Constant. The
coverage_threshold_enforcement.feature step "I parse the COVERAGE_THRESHOLD
constant from noxfile.py" raised ValueError (errored scenario) because it only
handled a literal constant — this was the missed third WS5 step file (the
config + consolidated steps were already reconciled).

Add the same pyproject `[tool.coverage.report].fail_under` fallback used by
coverage_threshold_config_steps.py, and fix the phantom-97 in the feature
description prose. Verified: the four coverage feature files now pass
(136 scenarios, 0 errored); previously unit_tests errored on
coverage_threshold_enforcement.feature:7.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-06-01 17:37:24 -04:00
..