Found during the September 2026 tech-debt audit (see the register section in #118).
Problem
The coverage gate is:
python -m pytest -q --cov=backend --cov=screeners --cov=ui --cov-fail-under=89
app.py is not in that list. The 927-line Streamlit entrypoint contributes zero to the 89% floor, despite roughly 14 tests/test_app_*.py modules actively exercising it. Dependencies/dhan_token_setup.py and migrations/versions/ are likewise unmeasured.
That means changes to app.py can lose coverage without the gate noticing — the exact failure mode the floor exists to prevent.
What makes this non-trivial
The command string is duplicated verbatim in five places and asserted as policy:
.github/workflows/quality-and-security.yml:52
AGENTS.md §6, README.md, docs/operations.md, docs/adding-a-screener.md
tests/test_supply_chain_policy.py:55 (the CI_COMMANDS tuple) and again at :127
Per AGENTS.md §7, changing a CI command requires co-updating tests/test_supply_chain_policy.py in the same commit. So this is a deliberate, reviewed change, not a drive-by.
Suggested work
- Add
--cov=app.py (or move to --cov=. with an explicit [tool.coverage.run] omit for tests/, migrations/, Dependencies/).
- Measure the new total and re-baseline
--cov-fail-under to just under it, keeping the existing thin-headroom convention.
- Update all five copies of the command string plus the two policy-test assertions in the same commit.
Worth deciding at the same time
There is currently no [tool.coverage] or [tool.pytest.ini_options] section anywhere — no pytest.ini, setup.cfg, .coveragerc or tox.ini (verified absent). Nothing is being hidden, which is genuinely good. But there are also no registered markers and no --strict-markers, so a typo'd @pytest.mark.slwo would silently do nothing. If a [tool.coverage.run] section is being added anyway, adding [tool.pytest.ini_options] with --strict-markers is a cheap rider.
Acceptance
app.py appears in the coverage report with a real percentage.
- The floor is re-baselined and CI passes.
tests/test_supply_chain_policy.py asserts the new command string and passes.
🤖 Generated with Claude Code
Found during the September 2026 tech-debt audit (see the register section in #118).
Problem
The coverage gate is:
app.pyis not in that list. The 927-line Streamlit entrypoint contributes zero to the 89% floor, despite roughly 14tests/test_app_*.pymodules actively exercising it.Dependencies/dhan_token_setup.pyandmigrations/versions/are likewise unmeasured.That means changes to
app.pycan lose coverage without the gate noticing — the exact failure mode the floor exists to prevent.What makes this non-trivial
The command string is duplicated verbatim in five places and asserted as policy:
.github/workflows/quality-and-security.yml:52AGENTS.md§6,README.md,docs/operations.md,docs/adding-a-screener.mdtests/test_supply_chain_policy.py:55(theCI_COMMANDStuple) and again at:127Per AGENTS.md §7, changing a CI command requires co-updating
tests/test_supply_chain_policy.pyin the same commit. So this is a deliberate, reviewed change, not a drive-by.Suggested work
--cov=app.py(or move to--cov=.with an explicit[tool.coverage.run] omitfortests/,migrations/,Dependencies/).--cov-fail-underto just under it, keeping the existing thin-headroom convention.Worth deciding at the same time
There is currently no
[tool.coverage]or[tool.pytest.ini_options]section anywhere — nopytest.ini,setup.cfg,.coveragercortox.ini(verified absent). Nothing is being hidden, which is genuinely good. But there are also no registered markers and no--strict-markers, so a typo'd@pytest.mark.slwowould silently do nothing. If a[tool.coverage.run]section is being added anyway, adding[tool.pytest.ini_options]with--strict-markersis a cheap rider.Acceptance
app.pyappears in the coverage report with a real percentage.tests/test_supply_chain_policy.pyasserts the new command string and passes.🤖 Generated with Claude Code