Skip to content

rollout(agent-mode): apply the shared control envelope across commands #323

Closed

Description

@pengfei-threemoonslab

Depends on #333. This issue applies the approved envelope; it does not redesign it.

Summary

The first-adoption workflow still exposes command-specific machine interfaces. After #333 settles the compact permission/control shape, roll that single vocabulary across detect, init, doctor, scan, verify, and check.

Semantic boundary

  • scan, verify, and check must project the existing authoritative release decision; no renderer may compute a second verdict.
  • detect, init, and doctor run before a release decision exists. Their control state derives from setup facts such as detection confidence, manifest validity, and unresolved human-owned placeholders. The payload must identify that source explicitly.
  • Command-specific result fields remain available through the documented compatibility window.

Acceptance criteria

Activity

  1. added this to the v0.17.0 milestone on Aug 7, 2026
  2. added
    enhancementNew feature or request
    P1Picked up inside the current milestone window; keep about 15 open
    area:agent-modeAgent-mode contract: control envelope, next actions, command strings
    on Aug 7, 2026
  3. pengfei-threemoonslab commented on Aug 7, 2026

    @pengfei-threemoonslab
    ContributorAuthor

    Triage note, and the important call on this one is that it is not new surface.

    derive_agent_control already exists (core/agent_control.py:34) and already produces exactly the envelope this issue describes — state, completion_allowed, next_action, allowed_next_commands, human_review. verify and check use it. init does not: cli/_register_init.py emits next_action as a free-text string in most branches (:303, :340, :412, :517), with one branch that does produce a structured next_actions=[action.model_dump(mode="json")] at :328.

    So the domain states are not merely "already shared" as the issue puts it — the implementation is already shared, and four commands simply bypass it. That reframes the work as applying an existing surface consistently, which lands on the right side of the CONTRIBUTING.md gate: "Deleting or consolidating surface never needs this new-surface justification." No headline metric is owed here. Reducing four transport shapes to one is consolidation.

    Two constraints worth writing into the design before implementation:

    The envelope must project the decision, never restate it. The roadmap non-goal is "no second verdict — nothing gates independently of release_decision.decision." A control.state on scan has to be a projection of the existing decision, not a parallel judgement computed in the renderer. #318 is a live example of what happens when a projection starts deciding for itself.

    init and doctor have no release_decision to project. They run before or outside a scan, so their control.state derives from a different source — placeholder state, manifest validity, detection confidence. That is legitimate but needs stating explicitly, or the same field will mean "the gate says" in one command and "setup says" in another, which is the ambiguity this issue exists to remove. #325 is effectively the first instance of that question and should be settled here rather than separately.

    Sequencing suggestion: settle the init control semantics as part of #325 (which needs a decision anyway), then generalize. Doing #323 first risks fixing the transport while leaving the state vocabulary underspecified.

    Labeled P1 / v0.17.0.

  4. pengfei-threemoonslab commented on Aug 7, 2026

    @pengfei-threemoonslab
    ContributorAuthor

    Milestone and scope update: this issue is merging into #333, which stays in v0.17.0 as part of the control-plane foundation.

    The two are the same surface approached from opposite ends — this one horizontal (make init, doctor, scan, detect, verify, check all speak one vocabulary), #333 vertical (make that object compact and unambiguous about what is permitted). Both land in core/agent_control.py and schemas/agent_control.py. Building them separately produces two envelope definitions and a migration between them.

    #333 absorbs the scope because the compact/permission model is the harder constraint; the horizontal rollout is mechanical once the shape is fixed. The two constraints raised here carry over verbatim and are restated on #333:

    • the envelope must project release_decision, never restate it (roadmap non-goal: no second verdict);
    • init and doctor have no release_decision to project from, so their control state derives from setup facts — which must be stated explicitly or control_state means two different things depending on the producing command.

    Keeping this issue open as the horizontal-coverage checklist against #333's shape; it moves to v0.18.0 as the rollout step, with the design decided in v0.17.0. Close it in favour of #333 if you would rather track that as one item.

  5. changed the title [-]ux(agent-mode): expose a common control envelope across init, doctor, scan, and verify[/-] [+]rollout(agent-mode): apply the shared control envelope across commands[/+] on Aug 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1Picked up inside the current milestone window; keep about 15 openarea:agent-modeAgent-mode contract: control envelope, next actions, command stringsenhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions