[Task]: GH-C06 own the update command in its own module

[Chumaniac]

Task ID or area

GH-C06 (cli)

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 a cohesive command or rule group moved into its bounded
module, preserving public invocations and keeping the module-size/import budget
honest.

Current gap: loopx/cli_commands/support_control.py is a 898-line module that
registers several unrelated top-level commands. promotion-gate,
promotion-readiness, and upgrade-plan are being extracted elsewhere, and
backup-state, chat/dashboard, chat-endpoint, and the supervisor group
already have owners. The remaining unowned group is update: the only
support-control command that mutates the active installation, with a 60-line
parser, a 68-line dispatch branch carrying update/rollback/installed-doctor
qualification, and seven ..self_update imports that nothing else in the module
uses.

Accepted outcome (before → after): before, support_control.py owns the update
parser, its dispatch branch, and its self-update imports alongside registry
inspection, status serving, and heartbeat prompt handling; after,
cli_commands/support_control_update.py owns registration and dispatch for
update while the command stays inside SUPPORT_CONTROL_COMMANDS, and the
parent module drops ~130 lines and all seven ..self_update imports.

Proposed scope

In scope / owner: move the update parser (including the update_action
positional, the --check / --dry-run / --execute / --rollback mutually
exclusive group, and --repo, --ref, --archive-url,
--installed-doctor-json, --timeout-seconds) and its dispatch branch verbatim
into loopx/cli_commands/support_control_update.py as
register_update_command and handle_update_command. Add
tests/test_support_control_update_ownership.py pinning that update is still
a support-control command, still registered exactly once, that the owner module
exposes both halves, and that a non-update command falls through untouched.

Existing related work / dependencies: loopx/self_update.py owns the plan,
rollback, and execution helpers and is unchanged; the promotion/upgrade-plan
extraction is a separate slice touching the same parent module and is
deliberately not duplicated here.

Out of scope: changing any flag, payload, exit code, or the update/rollback
semantics themselves; extracting registry, registry-boundary,
serve-status, or the heartbeat-prompt branch; and new update behavior.

If staged: this is one cohesive slice, not a staged increment. The remaining
unowned groups in the parent module are a separate GH-C06 slice for a separate
owner.

Intended base branch

main

Relevant files or commands

• loopx/cli_commands/support_control.py
• loopx/cli_commands/support_control_update.py (new)
• tests/test_support_control_update_ownership.py (new)
• python3 examples/cli-command-module-size-ownership-command-modularization-smoke.py
• python3 regression/cli-command-module-contract.py
• loopx update plan --format json, loopx update --help

Validation plan

Accepted result and independent oracle: the extraction is behavior-preserving,
so the oracle is a baseline-versus-head comparison rather than a new assertion
about update behavior. loopx update plan --format json and
loopx update --help must be byte-identical before and after the move (compare
against git stash -u), and the module-size/ownership smoke must still pass.
The new ownership test pins the two structural facts that could silently break
the public invocation: membership in SUPPORT_CONTROL_COMMANDS and single
registration.

Actual entrypoint / safe command: python3 examples/cli-command-module-size-ownership-command-modularization-smoke.py,
python3 -m pytest -q tests/test_support_control_update_ownership.py, and the
read-only loopx update plan --format json diff against the stashed baseline.

Negative or recovery case: handle_update_command must return None for a
non-update command before doing any work, and the ownership test asserts that.
regression/cli-command-module-contract.py fails in a source checkout because
it shells out to loopx doctor; it fails identically before and after the
change, so the failure is environmental rather than introduced.

Frontend / Lark / CLI impact or verified N/A: CLI only, no behavior change. The
top-level loopx --help output is unchanged, which the baseline diff covers.

Public/private boundary

• This issue does not include private benchmark traces, verifier output, credentials, internal document links, raw agent sessions, or local runtime state.
• I will not run or duplicate maintainer-owned benchmark cases unless a maintainer explicitly splits out a public issue for it.