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.
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.