UAT: agents validation attach does not reject simultaneous --project and --plan flags — spec requires "at most one scope flag per invocation" #1988

Open
opened 2026-04-03 00:31:26 +00:00 by freemo · 4 comments
Owner

Metadata

  • Branch: bugfix/m4-validation-attach-scope-flag-mutex
  • Commit Message: fix(cli): enforce mutual exclusion of --project and --plan in validation attach
  • Milestone: v3.4.0
  • Parent Epic: #357

Bug Report

Feature Area: Decision and Validation System (v3.4.0)

What Was Tested

The agents validation attach command's enforcement of the mutual exclusion between --project and --plan scope flags.

Expected Behavior (from spec)

Per docs/specification.md lines 9548–9552 (agents validation attach section):

At most one scope flag may be provided per invocation.

When both --project and --plan are provided simultaneously, the command should reject the invocation with a clear error message.

Actual Behavior

The agents validation attach command accepts both --project and --plan simultaneously without any validation error. The command proceeds to call service.attach_validation() with both project_name and plan_id set, which is an invalid state per the spec.

Reproduction:

agents validation attach --project local/myproject --plan 01PLAN0000000000000000000 local/api-repo local/run-tests

The command does not reject this invocation. Instead, it proceeds to the service layer (which fails with a database error in a test environment, but the CLI itself does not validate the mutual exclusion).

Code Location:

  • src/cleveragents/cli/commands/validation.pyattach() function

The add command correctly validates mutual exclusion of --required and --informational:

if required and informational:
    console.print("[red]Error:[/red] --required and --informational are mutually exclusive")
    raise typer.Abort()

But the attach command has no equivalent check for --project and --plan.

Expected Fix

Add a mutual exclusion check at the start of the attach() function:

if project is not None and plan_id is not None:
    console.print("[red]Error:[/red] --project and --plan are mutually exclusive")
    raise typer.Abort()

Subtasks

  • Add mutual exclusion guard in attach() in src/cleveragents/cli/commands/validation.py
  • Remove @tdd_expected_fail tag from the TDD scenario tagged @tdd_issue_1988 (see #1985)
  • Verify the TDD scenario now passes without the @tdd_expected_fail tag
  • Verify nox -s unit_tests passes
  • Verify coverage >= 97% via nox -s coverage_report
  • Run nox (all default sessions), fix any errors

Definition of Done

This issue is complete when:

  • All subtasks above are completed and checked off.
  • A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
  • The commit is pushed to the remote on the branch matching the Branch in Metadata exactly.
  • The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.
  • All nox stages pass.
  • Coverage >= 97%.

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: ca-new-issue-creator

## Metadata - **Branch**: `bugfix/m4-validation-attach-scope-flag-mutex` - **Commit Message**: `fix(cli): enforce mutual exclusion of --project and --plan in validation attach` - **Milestone**: v3.4.0 - **Parent Epic**: #357 ## Bug Report **Feature Area:** Decision and Validation System (v3.4.0) ### What Was Tested The `agents validation attach` command's enforcement of the mutual exclusion between `--project` and `--plan` scope flags. ### Expected Behavior (from spec) Per `docs/specification.md` lines 9548–9552 (agents validation attach section): > At most one scope flag may be provided per invocation. When both `--project` and `--plan` are provided simultaneously, the command should reject the invocation with a clear error message. ### Actual Behavior The `agents validation attach` command accepts both `--project` and `--plan` simultaneously without any validation error. The command proceeds to call `service.attach_validation()` with both `project_name` and `plan_id` set, which is an invalid state per the spec. **Reproduction:** ```bash agents validation attach --project local/myproject --plan 01PLAN0000000000000000000 local/api-repo local/run-tests ``` The command does not reject this invocation. Instead, it proceeds to the service layer (which fails with a database error in a test environment, but the CLI itself does not validate the mutual exclusion). **Code Location:** - `src/cleveragents/cli/commands/validation.py` — `attach()` function The `add` command correctly validates mutual exclusion of `--required` and `--informational`: ```python if required and informational: console.print("[red]Error:[/red] --required and --informational are mutually exclusive") raise typer.Abort() ``` But the `attach` command has no equivalent check for `--project` and `--plan`. ### Expected Fix Add a mutual exclusion check at the start of the `attach()` function: ```python if project is not None and plan_id is not None: console.print("[red]Error:[/red] --project and --plan are mutually exclusive") raise typer.Abort() ``` ## Subtasks - [ ] Add mutual exclusion guard in `attach()` in `src/cleveragents/cli/commands/validation.py` - [ ] Remove `@tdd_expected_fail` tag from the TDD scenario tagged `@tdd_issue_1988` (see #1985) - [ ] Verify the TDD scenario now passes without the `@tdd_expected_fail` tag - [ ] Verify `nox -s unit_tests` passes - [ ] Verify coverage >= 97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on the branch matching the **Branch** in Metadata exactly. - The commit is submitted as a **pull request** to `master`, reviewed, and **merged** before this issue is marked done. - All nox stages pass. - Coverage >= 97%. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-new-issue-creator
freemo added this to the v3.4.0 milestone 2026-04-03 00:32:18 +00:00
Author
Owner

Issue triaged by project owner:

  • State: Verified
  • Priority: Critical — This is a direct spec violation (docs/specification.md lines 9548–9552: "At most one scope flag may be provided per invocation"). The CLI accepts an invalid state that should be rejected, which can lead to undefined behavior in the service layer.
  • Milestone: v3.4.0 (Decisions + Validation — already assigned, confirmed correct)
  • MoSCoW: Must Have — This is a spec-mandated behavioral requirement for the validation subsystem. The v3.4.0 milestone cannot ship with a CLI that accepts invalid flag combinations.
  • Parent Epic: #357 (already linked, confirmed correct)

The issue is well-documented with clear reproduction steps, root cause analysis, and a suggested fix. The companion TDD issue #1985 follows the Bug Fix Workflow correctly.


Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: ca-project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: Critical — This is a direct spec violation (`docs/specification.md` lines 9548–9552: "At most one scope flag may be provided per invocation"). The CLI accepts an invalid state that should be rejected, which can lead to undefined behavior in the service layer. - **Milestone**: v3.4.0 (Decisions + Validation — already assigned, confirmed correct) - **MoSCoW**: Must Have — This is a spec-mandated behavioral requirement for the validation subsystem. The v3.4.0 milestone cannot ship with a CLI that accepts invalid flag combinations. - **Parent Epic**: #357 (already linked, confirmed correct) The issue is well-documented with clear reproduction steps, root cause analysis, and a suggested fix. The companion TDD issue #1985 follows the Bug Fix Workflow correctly. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner
Author
Owner

Transition attempt for issue #1988 from State/Unverified to State/Verified.

Current labels: MoSCoW/Must have, Priority/Critical, State/Unverified, Type/Bug.

Preconditions:

  • Not paused (no Blocker).

Actions taken:

  • Attempted to add new state label: State/Verified.
  • Removal of existing State/* labels is required by policy, but this API wrapper currently supports label addition only (by numeric ID) and does not expose a direct label removal operation. As a result, I could not conclusively remove State/Unverified via the available tools in this session.

Result:

  • The attempt to add State/Verified failed due to the label API requiring numeric IDs. Error seen: invalid label ID 'State/Verified': strconv.ParseInt: parsing "State/Verified": invalid syntax - labels must be numeric IDs.

Next steps (please confirm):

  • Provide the numeric label ID for State/Verified in this repository, or
  • Allow me to fetch and use label IDs dynamically if such an endpoint is available, or
  • Permit me to use an admin action to adjust labels directly.

When possible, I will re-try the transition by removing the old State/Unverified label and adding State/Verified, and then report the exact labels removed/added.


Automated by CleverAgents Bot
Supervisor: Implementation | Agent: ca-issue-state-updater

Transition attempt for issue #1988 from State/Unverified to State/Verified. Current labels: MoSCoW/Must have, Priority/Critical, State/Unverified, Type/Bug. Preconditions: - Not paused (no Blocker). Actions taken: - Attempted to add new state label: State/Verified. - Removal of existing State/* labels is required by policy, but this API wrapper currently supports label addition only (by numeric ID) and does not expose a direct label removal operation. As a result, I could not conclusively remove State/Unverified via the available tools in this session. Result: - The attempt to add State/Verified failed due to the label API requiring numeric IDs. Error seen: invalid label ID 'State/Verified': strconv.ParseInt: parsing "State/Verified": invalid syntax - labels must be numeric IDs. Next steps (please confirm): - Provide the numeric label ID for State/Verified in this repository, or - Allow me to fetch and use label IDs dynamically if such an endpoint is available, or - Permit me to use an admin action to adjust labels directly. When possible, I will re-try the transition by removing the old State/Unverified label and adding State/Verified, and then report the exact labels removed/added. --- **Automated by CleverAgents Bot** Supervisor: Implementation | Agent: ca-issue-state-updater
Author
Owner

Issue triaged by project owner:

  • State: Verified
  • Priority: Critical — spec explicitly requires mutual exclusion of --project and --plan flags; the missing guard allows invalid state to reach the service layer
  • Milestone: v3.4.0 (Decisions + Validations)
  • MoSCoW: Must Have — this is a spec compliance bug in a core CLI command; the validation system cannot be considered complete without proper input validation
  • Parent Epic: #357 (Decisions + Validations + Invariants)

The fix is well-scoped (single guard clause) and has a companion TDD issue (#1985). Dependency link to parent Epic created.


Automated by CleverAgents Bot
Supervisor: Project Owner | Agent: ca-project-owner

Issue triaged by project owner: - **State**: Verified - **Priority**: Critical — spec explicitly requires mutual exclusion of `--project` and `--plan` flags; the missing guard allows invalid state to reach the service layer - **Milestone**: v3.4.0 (Decisions + Validations) - **MoSCoW**: Must Have — this is a spec compliance bug in a core CLI command; the validation system cannot be considered complete without proper input validation - **Parent Epic**: #357 (Decisions + Validations + Invariants) The fix is well-scoped (single guard clause) and has a companion TDD issue (#1985). Dependency link to parent Epic created. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner
Author
Owner

Milestone Triage Decision: Moved to Backlog (Belongs in Earlier Milestone)

This validation logic issue has been moved out of v3.4.0 during aggressive milestone triage. Validation logic belongs in earlier milestones, not in ACMS v1 + Context Scaling.

Reasoning:

  • v3.4.0 focus: ACMS v1 implementation and Context Scaling capabilities
  • This issue: Validation attach flag logic - basic validation functionality
  • Impact: Validation behavior, not ACMS or context scaling capability

Should be addressed in v3.3.0 alongside validation core functionality.

**Milestone Triage Decision: Moved to Backlog (Belongs in Earlier Milestone)** This validation logic issue has been moved out of v3.4.0 during aggressive milestone triage. Validation logic belongs in earlier milestones, not in ACMS v1 + Context Scaling. **Reasoning:** - v3.4.0 focus: ACMS v1 implementation and Context Scaling capabilities - This issue: Validation attach flag logic - basic validation functionality - Impact: Validation behavior, not ACMS or context scaling capability Should be addressed in v3.3.0 alongside validation core functionality.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Blocks
Reference
cleveragents/cleveragents-core#1988
No description provided.