Repository navigation
[Bug]: the pinned top-level module budget is already exceeded on main (150 measured against 147) #5685
Description
Activity
Update from the latest canonical main: at 42e55a8, the tracked loopx/*.py count is back at 147. The focused budget test passes (6 passed) on a documentation-only head based directly on that main SHA; the changed files do not touch the module tree or budget test. The 150 count at bfe3c43 is no longer reproducible on current main. I have not changed the budget pin or opened a duplicate PR; please close this report if this current-main readback resolves it for you.
Rechecked canonical main at a00509b: the top-level loopx/*.py count is 147, matching the pinned budget. The reported 150-module failure is no longer reproducible on current main, so I’m closing this report without a code change.
Correction: I can confirm the failure is absent on current main, but this account does not have permission to close the report. It remains open for maintainer closeout.
Current-main recheck: the same budget gate has regressed after the earlier 147-module readback. On unmodified
mainatda45cfe771e96d20b9c5129a021a8c971ee03324,tests/architecture/test_top_level_module_budget.pyreports 1 failed, 5 passed:loopx/contains 148 top-level Python modules while the fixture still pins 147. The additional module isloopx/chat_explore_results.py, added by merged PR #5743.The architecture RFC's M1 moves
loopx/chat_*intoloopx/chat/with import compatibility; its open D3 decision assigns the compatibility-shim lifetime to the release owner before M1. Could the release owner or maintainers decide the D3 lifetime and whether to authorize this M1 slice? I can then prepare the migration and regression validation against the agreed compatibility boundary. I have not changed the budget pin, which would mask the growth this gate is intended to surface.Rechecked on a clean worktree at exact upstream main
2244b96f1e2e5c90bef43ae4c140c0994bfcc07a: the focused budget gate is1 failed, 5 passed, with 148 top-level Python modules against the pinned 147. Since baseline9eaacfbf2ff93d5386cee82ddf0847d9c739e78a, the root-level delta ischat_explore_results.pyandchat_todo_detail.pyadded, withchat_configuration_api.pymoved topresentation/configuration_api.py(net +1). The failure detail'sworkflow_skill_install.pyis a lexical diagnostic artifact; that file already exists at the pinned baseline. The architecture RFC still makes the release owner's D3 shim lifetime choice a precondition for M1. Please confirm whether to authorize that migration and select the one- or two-minor-release compatibility window, or identify a different accepted correction. I have not changed the pin or started the migration.Latest canonical-main readback: at
a1890a37f4f759bc2e39823074bbe78f78e49fdb, the trackedloopx/*.pycount is 147, matching the pinned budget.tests/architecture/test_top_level_module_budget.pypasses (6 passed) on a worktree based on this exact SHA with only nested Effect-runtime changes; those changes do not affect the top-level module set or this gate. The reported over-budget state is not reproducible on this current main revision. No pin change or patch is warranted from this measurement; maintainer closeout remains appropriate if the report is considered resolved.Current-main readback: the gate passes on
mainatbe15bf4ff.git ls-tree --name-only origin/main loopx/lists 147 top-level*.pymodules, which equalsmax_top_level_modules: 147intests/architecture/top_level_module_budget.json.tests/architecture/test_top_level_module_budget.pypasses on a clean checkout of that commit.
As earlier comments show, the count has moved between 147 and 150 as PRs merged. The gate catches a new top-level module in the PR that adds it, which is its job. The leftover problem was that main itself was red, and that is not the case at the moment. I'd suggest closing this. If the count rises again on
main, the PR that pushed it over is the place to fix it.
What is failing on
maintests/architecture/test_top_level_module_budget.py::test_top_level_module_count_stays_at_the_pinned_budgetfails on an unmodifiedmain.Measured on
bfe3c4344(currentmaintip at the time of writing):git ls-tree --name-only main loopx/filtered to*.py→ 150 top-level modules.tests/architecture/top_level_module_budget.jsonstill pinsmax_top_level_modules: 147, withbaseline_commit: 9eaacfbf2.mainby 3 modules, and every PR based on currentmaininherits that failure.For context, #5597 — merged about an hour before this was written — measured 149 at its own base and disclosed the same gate as pre-existing red. The drift is not hypothetical, it is happening between PRs.
Which commits raised it
The top-level additions since the 147 baseline, read with
git log --diff-filter=A --name-only -- 'loopx/*.py':9eaacfbf29cb6a5433feat: back up complete machine and Goal configuration checkpointsloopx/configuration_backup.py,loopx/chat_configuration_backup_api.pyd7ad25654feat(chat): add authorized ordinary workspace conversationsloopx/chat_project_context.pyb9df6d1d0(#5587)fix(workspace): isolate edits and preserve complete current evidenceloopx/chat_todo_detail.pyNone of those is wrong on its own terms; the count is what RFC
monorepo-distribution-split-v0Section 9 asked to keep visible. This issue exists so the number is decided on purpose rather than inherited as a red test.What this is not asking for
147 → 150without a decision is exactly the drift the gate exists to catch, and the RFC's Appendix A already recorded the same surface moving 143 → 148 while the proposal was being reviewed.chat_*→loopx/chat/is milestone M1 and*_goal_mode→loopx/hosts/is M2 of that RFC, and both are gated on decisions D1–D4 which the RFC says are not authorised by merging M0.Options for the owner, with the cost of each
loopx/semantics/vocabulary_v0.json→inventory_ratchets.meaning.What I have verified locally
bfe3c4344— same interpreter (uv venv+uv pip install -e ".[test]"), Node pinned to the repository's qualified 22 line,npm ci --ignore-scriptsrun once.tests/architectureplustests/canaryon that unmodified tree: 24 failed / 1378 passed, of which 22 aretests/architecture/test_contributor_task_board.py(the contributor-task-board anchor rules), 1 is this budget gate, and 1 istests/canary/test_maintainability_ratchet.py::test_current_repository_debt_is_reviewed_without_line_count_pins. refactor(lark): decide the sink visibility pair in one owner #5597 disclosed three pre-existing reds including this budget gate and the ratchet; the task-board file accounts for the rest.refactor(control-plane): decide the agent-lane progress scope in one owner) deliberately places its new owner insideloopx/control_plane/rather than atloopx/*.py, so it cannot add to this count.Refs #5072 (the distribution-split programme this gate belongs to) and #5191 (the PR that landed the pin). No milestone claimed or closed here.