Repository navigation
[Bug]: required kernel-static-checks is red on main — chat_history.py pushes the top-level module count to 146 against the 145 pin and blocks every backend PR #7397
Description
Preflight
- I searched existing issues and discussions for this behavior.
- This report is not an unpatched security vulnerability.
- The report and attachments contain no credentials or private/internal material.
Issue origin
Observed or reproduced in a real environment
LoopX version or commit
de11f068c323d5fa8e13027bd2e9700258edb8fc (current main; the regression was introduced by ea34ecc84, merged in #7388)
Host or runtime surface
Not host-specific
LoopX area
Build, packaging, installer, or CI
Problem
The required kernel-static-checks job of Python Tests is red on main:
tests/architecture/test_top_level_module_budget.py::test_top_level_module_count_stays_at_the_pinned_budget
measures 146 top-level loopx/*.py modules against the pinned 145 and fails. Because
checks needs kernel-static-checks, pytest needs checks, and merge-gate needs pytest,
every backend PR based on current main inherits a red required merge gate even when its own
change is correct.
Who is harmed and how much. Merged #7388 added loopx/chat_history.py without lowering the
top-level count, so every backend PR opened or rebased onto current main fails before its tests
run. At the time of writing at least five open PRs show the identical failure on their exact head:
#7252 (checks, kernel-static-checks, pytest, merge-gate, stage2c-correctness-e2e all
fail; job https://github.com/loopx-project/loopx/actions/runs/40328469386/job/121591486185),
#7334 (job https://github.com/loopx-project/loopx/actions/runs/40326820315/job/121585829283),
#7380 (job https://github.com/loopx-project/loopx/actions/runs/40328026029/job/121590004064),
#7393 (job https://github.com/loopx-project/loopx/actions/runs/40324843865/job/121579012368),
and #7386. Each is a real contributor or maintainer PR that cannot satisfy the required gate for a
reason unrelated to its change; recent PRs on this branch of work have only been landing through
bypass or after maintainer intervention. This is not a one-off: the same 146-vs-145 class of
failure on main was reported as #6728 and repaired by #6734 in a few hours, and the 147-vs-145
instance was repaired by #7000. The gate is the thing that makes top-level growth visible, so it
must be decided deliberately rather than inherited red.
Minimal reproduction
From a clean checkout of de11f068c323d5fa8e13027bd2e9700258edb8fc:
uv sync --extra test
uv run --extra test python -m pytest -q tests/architecture/test_top_level_module_budget.pyObserved:
F..... [100%]
...
E AssertionError: loopx/ grew from 145 to 146 top-level modules; the RFC only allows a move into a subpackage, and new top-level modules need a recorded design decision first.
1 failed, 5 passed in 6.17s
The over-budget module is loopx/chat_history.py: comparing the pinned baseline
a4483aaece5bc74ec3f969fd067229487022401b with current main over loopx/*.py shows exactly one
addition, chat_history.py, and no removals.
Expected behavior
main's required static lane is green at the pinned count: the new stateless paging helper lives
in an existing subpackage, the top-level count returns to 145, and max_top_level_modules stays at
145 rather than being re-pinned without the recorded design decision the RFC requires. The module's
only production consumer is loopx/capabilities/manager_context/roundtrip.py, whose capability
README already owns the "frozen, revision-bound paged snapshot", so
loopx/capabilities/manager_context/ is the smallest existing home.
Actual behavior
main fails its own required pre-test gate, so checks → pytest → merge-gate are red for every
backend PR. The failing assertion names a reverse-alphabetically last module
(workflow_skill_install.py) rather than the added one, which makes the message look unrelated to
the change that caused it.
Sanitized diagnostics
$ uv run --extra test python -m pytest -q tests/architecture/test_top_level_module_budget.py
tests/architecture/test_top_level_module_budget.py:63: AssertionError
FAILED tests/architecture/test_top_level_module_budget.py::test_top_level_module_count_stays_at_the_pinned_budget
1 failed, 5 passed in 6.17s
Hosted job on PR #7380 at 2026-10-26T13:09:40Z:
https://github.com/loopx-project/loopx/actions/runs/40328026029/job/121590004064
Additional context
Related records: #5685 (the open class report for this gate), #6728 (closed previous instance of
the same 146-vs-145 overflow), #7000 (closed repair for the 147-vs-145 instance), #7388 (the merged
PR that introduced loopx/chat_history.py), and #7334 (an open PR that also edits
loopx/chat_history.py; it is itself blocked by this gate and will need a trivial rebase after the
move).
Activity
Dante-dan commentedon Oct 26, 2026
I confirmed current
mainstill has 146 top-level modules against the unchanged 145 budget. The merged #7334 only replaces the local digest regex; it does not relocate the helper. I will follow the placement proposed here: move the paging helper intoloopx/capabilities/manager_context/, update its production consumer and existing tests, and keep paging behavior and the budget pin unchanged. The architecture gate and existing history/roundtrip tests will check the move before the full repository checks.