fix(cli): raise on subcommand registration failure instead of partial silent return #3264

Merged

freemo merged 1 commits from fix/cli-incomplete-subcommand-registration-on-error into master 2026-04-05 21:13:59 +00:00

Conversation 3 Commits 1 Files Changed 3

+153 -2

freemo commented 2026-04-05 08:44:48 +00:00

Owner

Copy Link

Copy Source

Summary

This PR fixes a silent error-suppression bug in _register_subcommands within the CLI entry point, where an exception during subcommand registration caused the function to return silently with exit code 0 instead of propagating the error. This violated the project's core error-handling principle: "Errors must never be suppressed. Exceptions should propagate to the top-level execution handler."

Changes

• src/cleveragents/cli/main.py — In _register_subcommands, replaced the bare return statement inside the exception handler with raise SystemExit(1) from exc. This ensures that any failure during subcommand module import or registration:
  1. Exits the process with a non-zero exit code (exit code 1), making the failure observable to callers and CI pipelines.
  2. Chains the original exception via from exc, satisfying the B904 flake8-bugbear linting rule (exception chaining in except blocks).
  3. Allows the error message to be printed before the process exits, giving the operator actionable feedback.
• src/cleveragents/cli/main.py — Removed the # pragma: no cover annotation from the exception handler block. The handler is now exercised by the new BDD tests, so the pragma was no longer accurate or necessary.
• features/tdd_cli_incomplete_subcommand_registration.feature — Added a new Behave BDD issue-capture feature file with 3 scenarios:
  • Scenario 1: Verifies that when a subcommand module raises an exception during registration, the CLI exits with a non-zero exit code (new correct behaviour).
  • Scenario 2: Verifies that the error output contains "Failed to register subcommands" when registration fails.
  • Scenario 3 (@tdd_expected_fail): Captures the old buggy behaviour (silent return with exit code 0 on error) as an expected-failure scenario.
• features/steps/tdd_cli_incomplete_subcommand_registration_steps.py — Added the corresponding Behave step definitions.

Design Decisions

raise SystemExit(1) from exc over alternatives:

• A bare raise was considered but rejected because it would propagate the raw exception up the call stack, bypassing the CLI's top-level error formatting.
• raise SystemExit(1) from exc explicitly chains the causing exception (from exc), required by the B904 linting rule and improves debuggability.

@tdd_expected_fail scenario:

• Documents the pre-fix behaviour (exit code 0 on error) as an expected failure, providing a living regression record.

Removal of # pragma: no cover:

• The new BDD tests exercise this path directly, so the pragma was misleading and would have artificially inflated coverage metrics.

Testing

• Lint (nox): ✅ PASS
• Typecheck (nox): ✅ PASS
• New BDD scenarios: 3 scenarios added

Modules Affected

Module	Change
src/cleveragents/cli/main.py	Bug fix: return → raise SystemExit(1) from exc; removed # pragma: no cover
features/tdd_cli_incomplete_subcommand_registration.feature	New: BDD issue-capture feature with 3 scenarios
features/steps/tdd_cli_incomplete_subcommand_registration_steps.py	New: Behave step definitions

Closes #2604

---

Automated by CleverAgents Bot
Supervisor: Implementation | Agent: ca-pr-api-creator

## Summary This PR fixes a silent error-suppression bug in `_register_subcommands` within the CLI entry point, where an exception during subcommand registration caused the function to return silently with exit code 0 instead of propagating the error. This violated the project's core error-handling principle: *"Errors must never be suppressed. Exceptions should propagate to the top-level execution handler."* ## Changes - **`src/cleveragents/cli/main.py`** — In `_register_subcommands`, replaced the bare `return` statement inside the exception handler with `raise SystemExit(1) from exc`. This ensures that any failure during subcommand module import or registration: 1. Exits the process with a non-zero exit code (exit code `1`), making the failure observable to callers and CI pipelines. 2. Chains the original exception via `from exc`, satisfying the `B904` flake8-bugbear linting rule (exception chaining in `except` blocks). 3. Allows the error message to be printed before the process exits, giving the operator actionable feedback. - **`src/cleveragents/cli/main.py`** — Removed the `# pragma: no cover` annotation from the exception handler block. The handler is now exercised by the new BDD tests, so the pragma was no longer accurate or necessary. - **`features/tdd_cli_incomplete_subcommand_registration.feature`** — Added a new Behave BDD issue-capture feature file with **3 scenarios**: - *Scenario 1*: Verifies that when a subcommand module raises an exception during registration, the CLI exits with a non-zero exit code (new correct behaviour). - *Scenario 2*: Verifies that the error output contains "Failed to register subcommands" when registration fails. - *Scenario 3* (`@tdd_expected_fail`): Captures the old buggy behaviour (silent `return` with exit code `0` on error) as an expected-failure scenario. - **`features/steps/tdd_cli_incomplete_subcommand_registration_steps.py`** — Added the corresponding Behave step definitions. ## Design Decisions **`raise SystemExit(1) from exc` over alternatives:** - A bare `raise` was considered but rejected because it would propagate the raw exception up the call stack, bypassing the CLI's top-level error formatting. - `raise SystemExit(1) from exc` explicitly chains the causing exception (`from exc`), required by the `B904` linting rule and improves debuggability. **`@tdd_expected_fail` scenario:** - Documents the pre-fix behaviour (exit code `0` on error) as an expected failure, providing a living regression record. **Removal of `# pragma: no cover`:** - The new BDD tests exercise this path directly, so the pragma was misleading and would have artificially inflated coverage metrics. ## Testing - **Lint (nox):** ✅ PASS - **Typecheck (nox):** ✅ PASS - **New BDD scenarios:** 3 scenarios added ## Modules Affected | Module | Change | |---|---| | `src/cleveragents/cli/main.py` | Bug fix: `return` → `raise SystemExit(1) from exc`; removed `# pragma: no cover` | | `features/tdd_cli_incomplete_subcommand_registration.feature` | New: BDD issue-capture feature with 3 scenarios | | `features/steps/tdd_cli_incomplete_subcommand_registration_steps.py` | New: Behave step definitions | Closes #2604 --- **Automated by CleverAgents Bot** Supervisor: Implementation | Agent: ca-pr-api-creator

freemo added 1 commit 2026-04-05 08:44:48 +00:00

fix(cli): raise on subcommand registration failure instead of partial silent return ... 6e09842731

- What was implemented
  - Fixed _register_subcommands in src/cleveragents/cli/main.py: replaced bare return with raise SystemExit(1) from exc in the exception handler to propagate a non-zero exit code and preserve the original traceback context.
  - Removed # pragma: no cover from the exception handler, enabling test coverage for this path.

- Why this change
  - Ensures the CLI exits with a non-zero status on subcommand registration failure and provides proper error context for debugging, aligning with the project's error-handling goals and B904 linting requirements.

- Tests and verification
  - Added Behave BDD issue-capture test features/tdd_cli_incomplete_subcommand_registration.feature with 3 scenarios to exercise and validate the failure path.
  - Added step definitions features/steps/tdd_cli_incomplete_subcommand_registration_steps.py corresponding to the new scenarios.
  - The @tdd_expected_fail scenario captures the previous buggy behavior (silent return with exit code 0) to ensure regression is addressed.
  - All nox quality gates pass (lint, typecheck).

- Key design decisions
  - Use raise SystemExit(1) from exc to exit with a clear non-zero status while preserving the original exception chain (satisfies B904).
  - Coverage ensured by removing the pragma, bringing the error path under test.
  - Behavior now explicitly signals failure to the shell and any orchestrating tooling, avoiding silent failures.

- Affected modules and artifacts
  - src/cleveragents/cli/main.py
  - features/tdd_cli_incomplete_subcommand_registration.feature
  - features/steps/tdd_cli_incomplete_subcommand_registration_steps.py

ISSUES CLOSED: #2604

freemo added a new dependency 2026-04-05 08:46:56 +00:00

#2604 BUG-HUNT: [error-handling] Incomplete subcommand registration on error

freemo added this to the v3.6.0 milestone 2026-04-05 08:49:33 +00:00

freemo referenced this pull request 2026-04-05 09:08:50 +00:00

BUG-HUNT: [error-handling] Incomplete subcommand registration on error #2604

freemo commented 2026-04-05 09:14:17 +00:00

Author

Owner

Copy Link

Copy Source

🔒 Review claimed by reviewer-pool-1 [claim-token: reviewer-pool-1-3264-1775374200]

---

Automated by CleverAgents Bot
Supervisor: PR Review | Agent: ca-continuous-pr-reviewer

🔒 Review claimed by reviewer-pool-1 [claim-token: reviewer-pool-1-3264-1775374200] --- **Automated by CleverAgents Bot** Supervisor: PR Review | Agent: ca-continuous-pr-reviewer

freemo commented 2026-04-05 09:22:17 +00:00

Author

Owner

Copy Link

Copy Source

🔒 Review claimed by reviewer-pool-1 [claim-token: reviewer-pool-1-3264-1775373000]

---

Automated by CleverAgents Bot
Supervisor: PR Review | Agent: ca-continuous-pr-reviewer

🔒 Review claimed by reviewer-pool-1 [claim-token: reviewer-pool-1-3264-1775373000] --- **Automated by CleverAgents Bot** Supervisor: PR Review | Agent: ca-continuous-pr-reviewer

freemo reviewed 2026-04-05 16:33:42 +00:00

freemo left a comment

Author

Owner

Copy Link

Copy Source

Review Summary (Self-Review — Independent Code Review Agent)

Reviewed PR #3264 with focus on error-handling-patterns, edge-cases, and boundary-conditions.

Recommendation: APPROVE ✅ (posted as COMMENT due to Forgejo self-review restriction)

Core Fix Assessment

✅ Specification Compliance: The fix correctly aligns with CONTRIBUTING.md's error-handling mandate: "Errors must never be suppressed. Exceptions should propagate to the top-level execution handler."

✅ Error Handling Fix: Replacing return with raise SystemExit(1) from exc is the correct approach:

• SystemExit(1) ensures a non-zero exit code, making the failure observable to callers and CI pipelines
• from exc preserves the exception chain, satisfying B904 and improving debuggability
• The error message is still printed before the raise, giving operators actionable feedback
• The main() function's existing except SystemExit as e: handler properly catches and converts this

✅ Pragma Removal: Removing # pragma: no cover is correct since the error path is now exercised by tests

✅ PR Metadata: Complete and correct — Closes #2604, milestone v3.6.0 matches issue, Type/Bug label present, branch name matches issue metadata, commit message follows Conventional Changelog format with ISSUES CLOSED: #2604 footer

✅ Commit Hygiene: Single atomic commit with detailed body explaining what/why/tests

Deep Dive: Error Handling Patterns

Given special attention to error handling:

1. Exception propagation chain is correct: raise SystemExit(1) from exc → caught by main() → except SystemExit as e: return convert_exit_code(e.code) → returns 1. The error flows through the established architecture cleanly.

2. Module-level call safety: _register_subcommands() is called at module level. If it raises SystemExit(1), the import of cleveragents.cli.main will propagate the error. This is actually the desired behavior — the module should not be importable in a half-initialized state. When invoked through main(), the SystemExit is properly caught.

3. Guard flag behavior on failure: When the exception is raised, _subcommands_registered remains False. This is correct — if the process somehow survives (e.g., in tests where SystemExit is caught), a retry would re-attempt registration rather than silently assuming success.

4. Broad except Exception catch: The broad catch is acceptable here since this is a top-level registration function where any failure during module import should be fatal. The issue's scope was specifically about the return → raise change, not narrowing the exception type.

Deep Dive: Edge Cases & Boundary Conditions

1. _subcommands_registered early-return guard: Correctly prevents double-registration. After a successful registration, subsequent calls are no-ops. After a failed registration (SystemExit raised), the flag remains False, allowing retry if the process survives.

2. Multiple call sites: _register_subcommands() is called from three places: module-level, main_callback, and main(). All three paths now correctly propagate the SystemExit.

Test Quality Assessment

✅ Scenario 1 (non-zero exit code): Correctly tests that callers of _register_subcommands propagate the error by patching the entire function to raise ImportError. This validates the integration between the function and its callers.

✅ Scenario 3 (@tdd_expected_fail): Correctly documents the old buggy behavior as a living regression record. This is proper TDD practice.

⚠️ Scenario 2 (error message test): The mock approach in step_then_error_message patches cleveragents.cli.commands.project with side_effect=ImportError(...). However, from cleveragents.cli.commands import project binds the name without calling the mock, so the side_effect won't directly trigger an ImportError. The test likely works because Typer's add_typer() fails when given a MagicMock instead of a real Typer app, which triggers the except Exception block and prints the "Failed to register subcommands" message. This is fragile — it depends on Typer's internal validation behavior rather than directly simulating the intended failure mode.

Minor Suggestions (Non-blocking)

1. Scenario 2 mock robustness: Consider patching builtins.__import__ or using importlib mocking to directly trigger an ImportError inside the try block of _register_subcommands, rather than relying on Typer's validation of mock objects. This would make the test more explicit about what it's testing. For example:

   with patch.dict("sys.modules", {"cleveragents.cli.commands": None}):
       # This would cause `from cleveragents.cli.commands import ...` to fail
   

   Or alternatively, patch the specific import inside the function using unittest.mock.patch on the import target with create=True.

2. Feature file documentation: The feature file narrative is excellent. Consider adding a brief note in the @tdd_expected_fail scenario about when it should be removed (e.g., "Remove this scenario after #2604 is merged and verified").

Decision: APPROVE ✅

The core fix is correct, well-motivated, and properly integrated with the existing error-handling architecture. The primary behavior (non-zero exit on registration failure) is well-tested. The minor test robustness concern does not block approval.

---

Automated by CleverAgents Bot
Supervisor: PR Review | Agent: ca-pr-self-reviewer

## Review Summary (Self-Review — Independent Code Review Agent) Reviewed PR #3264 with focus on **error-handling-patterns**, **edge-cases**, and **boundary-conditions**. **Recommendation: APPROVE** ✅ (posted as COMMENT due to Forgejo self-review restriction) ### Core Fix Assessment ✅ **Specification Compliance**: The fix correctly aligns with CONTRIBUTING.md's error-handling mandate: *"Errors must never be suppressed. Exceptions should propagate to the top-level execution handler."* ✅ **Error Handling Fix**: Replacing `return` with `raise SystemExit(1) from exc` is the correct approach: - `SystemExit(1)` ensures a non-zero exit code, making the failure observable to callers and CI pipelines - `from exc` preserves the exception chain, satisfying B904 and improving debuggability - The error message is still printed before the raise, giving operators actionable feedback - The `main()` function's existing `except SystemExit as e:` handler properly catches and converts this ✅ **Pragma Removal**: Removing `# pragma: no cover` is correct since the error path is now exercised by tests ✅ **PR Metadata**: Complete and correct — `Closes #2604`, milestone v3.6.0 matches issue, `Type/Bug` label present, branch name matches issue metadata, commit message follows Conventional Changelog format with `ISSUES CLOSED: #2604` footer ✅ **Commit Hygiene**: Single atomic commit with detailed body explaining what/why/tests ### Deep Dive: Error Handling Patterns Given special attention to error handling: 1. **Exception propagation chain is correct**: `raise SystemExit(1) from exc` → caught by `main()` → `except SystemExit as e: return convert_exit_code(e.code)` → returns 1. The error flows through the established architecture cleanly. 2. **Module-level call safety**: `_register_subcommands()` is called at module level. If it raises `SystemExit(1)`, the import of `cleveragents.cli.main` will propagate the error. This is actually the desired behavior — the module should not be importable in a half-initialized state. When invoked through `main()`, the `SystemExit` is properly caught. 3. **Guard flag behavior on failure**: When the exception is raised, `_subcommands_registered` remains `False`. This is correct — if the process somehow survives (e.g., in tests where `SystemExit` is caught), a retry would re-attempt registration rather than silently assuming success. 4. **Broad `except Exception` catch**: The broad catch is acceptable here since this is a top-level registration function where *any* failure during module import should be fatal. The issue's scope was specifically about the `return` → `raise` change, not narrowing the exception type. ### Deep Dive: Edge Cases & Boundary Conditions 1. **`_subcommands_registered` early-return guard**: Correctly prevents double-registration. After a successful registration, subsequent calls are no-ops. After a failed registration (SystemExit raised), the flag remains False, allowing retry if the process survives. 2. **Multiple call sites**: `_register_subcommands()` is called from three places: module-level, `main_callback`, and `main()`. All three paths now correctly propagate the SystemExit. ### Test Quality Assessment ✅ **Scenario 1** (non-zero exit code): Correctly tests that callers of `_register_subcommands` propagate the error by patching the entire function to raise ImportError. This validates the integration between the function and its callers. ✅ **Scenario 3** (`@tdd_expected_fail`): Correctly documents the old buggy behavior as a living regression record. This is proper TDD practice. ⚠️ **Scenario 2** (error message test): The mock approach in `step_then_error_message` patches `cleveragents.cli.commands.project` with `side_effect=ImportError(...)`. However, `from cleveragents.cli.commands import project` binds the name without *calling* the mock, so the `side_effect` won't directly trigger an `ImportError`. The test likely works because Typer's `add_typer()` fails when given a `MagicMock` instead of a real Typer app, which triggers the `except Exception` block and prints the "Failed to register subcommands" message. This is fragile — it depends on Typer's internal validation behavior rather than directly simulating the intended failure mode. ### Minor Suggestions (Non-blocking) 1. **Scenario 2 mock robustness**: Consider patching `builtins.__import__` or using `importlib` mocking to directly trigger an `ImportError` inside the `try` block of `_register_subcommands`, rather than relying on Typer's validation of mock objects. This would make the test more explicit about what it's testing. For example: ```python with patch.dict("sys.modules", {"cleveragents.cli.commands": None}): # This would cause `from cleveragents.cli.commands import ...` to fail ``` Or alternatively, patch the specific import inside the function using `unittest.mock.patch` on the import target with `create=True`. 2. **Feature file documentation**: The feature file narrative is excellent. Consider adding a brief note in the `@tdd_expected_fail` scenario about when it should be removed (e.g., "Remove this scenario after #2604 is merged and verified"). **Decision: APPROVE** ✅ The core fix is correct, well-motivated, and properly integrated with the existing error-handling architecture. The primary behavior (non-zero exit on registration failure) is well-tested. The minor test robustness concern does not block approval. --- **Automated by CleverAgents Bot** Supervisor: PR Review | Agent: ca-pr-self-reviewer

freemo referenced this pull request 2026-04-05 19:48:58 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 #3377

freemo referenced this pull request 2026-04-05 20:07:24 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 #3572

freemo referenced this pull request 2026-04-05 21:00:52 +00:00

[Automated] CleverAgents Build Session - 2026-04-05 #3377

freemo merged commit b565d86847 into master 2026-04-05 21:13:58 +00:00

freemo removed this from the v3.6.0 milestone 2026-04-07 00:11:48 +00:00

HAL9000 referenced this pull request 2026-04-14 04:05:13 +00:00

[AUTO-INF-2] Restore Ruff compliance for plan explain failure path #8943

Sign in to join this conversation.

Reviewers

No Reviewers

freemo

Labels

Clear labels

auto/needs-reevaluation

Controller deferred this PR; awaiting Phase 6+ scope-evaluator or operator re-enablement.

controller-managed

Auto-agents controller manages this PR/issue (see tools/controller/deploy/RUNBOOK.md). Remove this label to abandon controller management.

overdue

auto/blocked-by-deps

PR blocked by an open issue dependency. Operator must close the dep (or remove the dependency link) before the merge driver can act. Auto-cleared by merge_drive when no open deps remain.

auto/ci-timeout

Most recent merge cycle hit CI timeout. Driver excludes this PR while last merge_cycle row is < 30 min old; label persists thereafter as visible history.

auto/claimed-implementer

Currently being processed by an implementer worker.

auto/claimed-merge

Currently being processed by the merge driver.

auto/claimed-reviewer

Currently being processed by a reviewer worker.

auto/driver-down

Merge driver heartbeat stale; pipeline halted. Closed automatically on next clean tick.

auto/invariant-violation

Detected master commit violating the strict merge invariant. Tracked as an issue (not a PR label); kept here for label completeness.

auto/last-attempt-tier-0

In-cycle escalation: most recent attempt ran at the Tier 0 slot (`tier-0`). Slot's model defined in .opencode/models/tiers.yaml.

auto/last-attempt-tier-1

In-cycle escalation: most recent attempt ran at the Tier 1 slot (`tier-1`). Slot's model defined in .opencode/models/tiers.yaml.

auto/last-attempt-tier-2

In-cycle escalation: most recent attempt ran at the Tier 2 slot (`tier-2`). Slot's model defined in .opencode/models/tiers.yaml. Gated behind IMPLEMENTER_ESCALATION_TIER2_ENABLED.

auto/last-attempt-tier-min

In-cycle escalation: most recent attempt ran at the Tier -1 slot (`tier-min`). Slot's model defined in .opencode/models/tiers.yaml. Suffix is ``-min`` (not ``--1``) so the Forgejo UI reads naturally.

Automation Tracking

Tracking issues used by the AI Automation system for agents to communicate and report.

auto/needs-conflict-resolution

Rebase conflict needs LLM conflict-resolver.

auto/needs-implementer

Failing CI needs implementer attention.

auto/postmortem

Documenting a driver incident or rollback.

auto/ready-to-merge

Reviewer has APPROVED this PR and no later REQUEST_CHANGES is outstanding. The merge driver requires this label to even consider a PR for merging. Set by the reviewer worker on APPROVE; cleared on REQUEST_CHANGES.

auto/restart-throttled

Train repeatedly lost master-tempo races. Driver excludes via merge_cycle until cooldown elapses; label persists as visible history.

auto/revert

Revert PR backing out an invariant violation. Fast-tracked through the merge driver.

auto/sentinel

Sentinel PR duplicated from upstream into a personal fork by tools/duplicate_prs_to_fork.py for pipeline testing. Lives only in the fork; the canonical pipeline never sees it.

auto/stale-inactivity

No implementer activity for N days. Flagged for human review. Auto-cleared on next push to head branch.

auto/unstable

Repeatedly fails on current master (>= 3 ci-fail-on-rebased-sha releases in 12 h). Excluded from driver until human triage.

Blocked

A ticket in a blocked state and unable to complete until some other task is completed first.

Bounty

$100

A bounty of $100 for any open-source contributor who provides a MR that solves this issue

Bounty

$1000

A bounty of $1000 for any open-source contributor who provides a MR that solves this issue

Bounty

$10000

A bounty of $10000 for any open-source contributor who provides a MR that solves this issue

Bounty

$20

A bounty of $20 for any open-source contributor who provides a MR that solves this issue

Bounty

$2000

A bounty of $2000 for any open-source contributor who provides a MR that solves this issue

Bounty

$250

A bounty of $250 for any open-source contributor who provides a MR that solves this issue

Bounty

$50

A bounty of $50 for any open-source contributor who provides a MR that solves this issue

Bounty

$500

A bounty of $500 for any open-source contributor who provides a MR that solves this issue

Bounty

$5000

A bounty of $5000 for any open-source contributor who provides a MR that solves this issue

Bounty

$750

A bounty of $750 for any open-source contributor who provides a MR that solves this issue

MoSCoW

Could have

Could have feature in order to satisfy the epic/legendary.

MoSCoW

Must have

Must have feature in order to satisfy the epic/legendary.

MoSCoW

Should have

Should have feature in order to satisfy the epic/legendary.

Needs Feedback

There are questions in the ticket that can not be completed until the project owner provides clarity.

Points

1

1 man-hours worth of work for an expert with no learning curve.

Points

13

13 man-hours worth of work for an expert with no learning curve.

Points

2

2 man-hours worth of work for an expert with no learning curve.

Points

21

21 man-hours worth of work for an expert with no learning curve.

Points

3

3 man-hours worth of work for an expert with no learning curve.

Points

34

34 man-hours worth of work for an expert with no learning curve.

Points

5

5 man-hours worth of work for an expert with no learning curve.

Points

55

55 man-hours worth of work for an expert with no learning curve.

Points

8

8 man-hours worth of work for an expert with no learning curve.

Points

88

88 man-hours worth of work for an expert with no learning curve.

Priority

Backlog

This ticket has backlogged priority and is not to be worked on yet

Priority

CI Blocker

Critical priority issue that blocks CI/CD pipeline and prevents PR merges

Priority

Critical

The priority is critical

Priority

High

The priority is high

Priority

Low

The priority is low

Priority

Medium

The priority is medium

Signed-off: Owner

When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

Signed-off: Scrum Master

When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

Signed-off: Tech Lead

When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

Spike

A ticket for learning a tool or technology that is needed to be able to do future planning and design.

State

Completed

The ticket has been fully implemented, completed, and merged with the source code. This label should only be applied once a ticket is closed.

State

Duplicate

A ticket that represents the same content as an existing ticket.

State

In Progress

A ticket that is actively being developed.

State

In Review

A ticket that has had some code completed to implement but is waiting to pass peer review and is not yet merged in.

State

Paused

This ticket's work started but wasn't finished. It's on hold (likely in a feature branch) and will be resumed later, either due to a blocker or a delay.

State

Unverified

All new tickets start in this state. A developer may set it to show the ticket is unverified. This means we haven't agreed to work on it. It will either move to a verified state or be closed as wontdo.

State

Verified

The issue has been verified by a developer as legitimate. It will be worked on and verified tickets are now considered part of the backlog.

State

Wont Do

This ticket has been decided it wont be done. This may mean the bug has been determined to not be real (cant verify) or the feature is one we have decided we dont want to adopt.

Type

Automation

Any edits or discussion about the AI automated coding system.

Type

Bug

Something that doesnt work as intended.

Type

Discussion

Anytime a ticket represents a discussion about a subject and doesnt fall into one of the other categories.

Type

Documentation

An error or improvement needed in the documentation.

Type

Epic

Any first tier epic. That is, an epic which contains only issues as children and will not have sub-epics.

Type

Feature

Some new functionality not present.

Type

Legendary

A type of Epic which will contain other Epics.

Type

Refactor

A code change that restructures existing code without changing its external behavior.

Type

Support

Someone needs help using the project.

Type

Task

A generic task that doesnt fit into the other type categories.

Type

Testing

Work exclusively focusing on fixing or expanding testing.

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

aditya (Aditya Chhabra) aleenaumair (Aleena Umair) brent.edwards (Brent Edwards) CoreRasurae (Luis Mendes) drew (Drew Morris) eugen.thaci (Eugen Thaci) freemo (Jeffrey Phillips Freeman) HAL9000 (HAL 9000) HAL9001 (HAL9001) hamza.khyari (Hamza Khyari) hurui200320 (Rui Hu) justin.morris khird (Kyle Hird) org.cleveragents

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Blocks

#2604 BUG-HUNT: [error-handling] Incomplete subcommand registration on error

cleveragents/cleveragents-core

Reference: cleveragents/cleveragents-core#3264