Task ID or area
GH-C06 (cli) — CLI ownership and hot-module extraction
Technical direction
Core control-plane hardening
Intent
I want to claim an existing task
Goal and acceptance gap
Goal/source: GH-C06 asks for one remaining oversized CLI ownership seam to be characterized and moved into a bounded module. loopx/cli_commands/support_control.py registers seven unrelated top-level commands in one 898-line module.
Current gap: promotion-gate, promotion-readiness, and upgrade-plan are registered and dispatched from support_control.py even though they form one cohesive canary-promotion and upgrade-propagation group. The module has no bounded owner for that group, so any new promotion flag grows the shared seam.
Accepted outcome (before → after): before, the three promotion commands live inside the shared support-control seam; after, loopx/cli_commands/support_control_promotion.py owns both halves (registration and dispatch), support_control.py delegates, and no public invocation, flag, payload, exit code, or help text changes.
Proposed scope
In scope / owner: move the promotion-gate, promotion-readiness (with its record subcommand), and upgrade-plan registration and dispatch blocks into a new support_control_promotion.py; keep the three commands inside SUPPORT_CONTROL_COMMANDS so the top-level router is unchanged; add tests/test_support_control_promotion_ownership.py pinning set membership, single registration, both halves living in the new module, and fall-through for unrelated commands.
Existing related work / dependencies: #4521 (refresh-state extraction, same shape), #3656 (registry admin extraction), examples/cli-command-module-size-ownership-command-modularization-smoke.py, regression/cli-command-module-contract.py.
Out of scope: update, registry, registry-boundary, and serve-status stay in support_control.py; no behavior change, no compatibility wrapper, no change to the 1000-line default budget or any frozen starter budget.
If staged: single-slice extraction; the remaining support-control seam is a later GH-C06 slice.
Intended base branch
main
Relevant files or commands
loopx/cli_commands/support_control.pyloopx/cli_commands/support_control_promotion.py (new)tests/test_support_control_promotion_ownership.py (new)python3 examples/cli-command-module-size-ownership-command-modularization-smoke.pypython3 regression/cli-command-module-contract.pypython3 -m pytest -q tests/test_support_control_promotion_ownership.py
Validation plan
Accepted result and independent oracle: the module-size/ownership smoke still passes with support_control.py under the default budget and each of the three commands registered by exactly one module; regression/cli-command-module-contract.py stays clean; the new ownership test proves registration and dispatch moved together and that an unrelated command falls through untouched.
Actual entrypoint / safe command: python3 examples/cli-command-module-size-ownership-command-modularization-smoke.py, python3 regression/cli-command-module-contract.py, and python3 -m pytest -q tests/test_support_control_promotion_ownership.py; plus python3 -m loopx.entrypoint promotion-gate --format json and python3 -m loopx.entrypoint promotion-readiness record --dashboard-readiness skipped as read-only invocation parity probes.
Negative or recovery case: the smoke fails if a command is registered by two modules or if a module exceeds its budget; the ownership test fails if the new module handles a command it does not own; a parity probe that changes payload shape, flags, or exit code fails this slice.
Frontend / Lark / CLI impact or verified N/A: CLI help and payloads are unchanged by construction; the parity probes above verify that. No dashboard or Lark surface is touched.
Public/private boundary
Task ID or area
GH-C06 (cli) — CLI ownership and hot-module extraction
Technical direction
Core control-plane hardening
Intent
I want to claim an existing task
Goal and acceptance gap
Goal/source: GH-C06 asks for one remaining oversized CLI ownership seam to be characterized and moved into a bounded module.
loopx/cli_commands/support_control.pyregisters seven unrelated top-level commands in one 898-line module.Current gap:
promotion-gate,promotion-readiness, andupgrade-planare registered and dispatched fromsupport_control.pyeven though they form one cohesive canary-promotion and upgrade-propagation group. The module has no bounded owner for that group, so any new promotion flag grows the shared seam.Accepted outcome (before → after): before, the three promotion commands live inside the shared support-control seam; after,
loopx/cli_commands/support_control_promotion.pyowns both halves (registration and dispatch),support_control.pydelegates, and no public invocation, flag, payload, exit code, or help text changes.Proposed scope
In scope / owner: move the
promotion-gate,promotion-readiness(with itsrecordsubcommand), andupgrade-planregistration and dispatch blocks into a newsupport_control_promotion.py; keep the three commands insideSUPPORT_CONTROL_COMMANDSso the top-level router is unchanged; addtests/test_support_control_promotion_ownership.pypinning set membership, single registration, both halves living in the new module, and fall-through for unrelated commands.Existing related work / dependencies: #4521 (refresh-state extraction, same shape), #3656 (registry admin extraction),
examples/cli-command-module-size-ownership-command-modularization-smoke.py,regression/cli-command-module-contract.py.Out of scope:
update,registry,registry-boundary, andserve-statusstay insupport_control.py; no behavior change, no compatibility wrapper, no change to the 1000-line default budget or any frozen starter budget.If staged: single-slice extraction; the remaining support-control seam is a later GH-C06 slice.
Intended base branch
main
Relevant files or commands
loopx/cli_commands/support_control.pyloopx/cli_commands/support_control_promotion.py(new)tests/test_support_control_promotion_ownership.py(new)python3 examples/cli-command-module-size-ownership-command-modularization-smoke.pypython3 regression/cli-command-module-contract.pypython3 -m pytest -q tests/test_support_control_promotion_ownership.pyValidation plan
Accepted result and independent oracle: the module-size/ownership smoke still passes with
support_control.pyunder the default budget and each of the three commands registered by exactly one module;regression/cli-command-module-contract.pystays clean; the new ownership test proves registration and dispatch moved together and that an unrelated command falls through untouched.Actual entrypoint / safe command:
python3 examples/cli-command-module-size-ownership-command-modularization-smoke.py,python3 regression/cli-command-module-contract.py, andpython3 -m pytest -q tests/test_support_control_promotion_ownership.py; pluspython3 -m loopx.entrypoint promotion-gate --format jsonandpython3 -m loopx.entrypoint promotion-readiness record --dashboard-readiness skippedas read-only invocation parity probes.Negative or recovery case: the smoke fails if a command is registered by two modules or if a module exceeds its budget; the ownership test fails if the new module handles a command it does not own; a parity probe that changes payload shape, flags, or exit code fails this slice.
Frontend / Lark / CLI impact or verified N/A: CLI help and payloads are unchanged by construction; the parity probes above verify that. No dashboard or Lark surface is touched.
Public/private boundary