feat(agents): allow per-invocation timeout override on shell/http tools #113

Merged

CoreRasurae merged 1 commit from feature/m1-shell-timeout-override into master 2026-08-05 12:40:43 +00:00

Conversation 3 Commits 1 Files changed 17 +1791 -16

CoreRasurae commented 2026-08-04 23:01:33 +00:00

Member

Copy link

Summary

Adds an optional per-invocation timeout argument to the shell and http_request tools so an LLM driving them can raise the execution limit for a single long-running call — instead of being told to "increase the timeout config value", which it cannot do at runtime. The model previously threaded timeout N into the call, corrupting the command.

• New immutable TimeoutPolicy value object resolves the effective timeout.
• Generic max_timeout config field (default 120s) bounds any override; an optional shell-only shell_max_timeout refines the ceiling for shell alone and is never consulted by http_request.
• Absent the argument, behaviour is byte-for-byte unchanged. Invalid overrides are rejected before any subprocess is spawned / request is sent. Timeout errors now direct a retry with a larger timeout argument.

Specification / ADR

• docs/adr/ADR-2030-tool-calling-spec-extensions.md D-9 (accepted revision).
• Actor Configuration Standard §4.5 + §21.1 → Version 1.2.0 (adds the generic max_timeout field).

Testing

• Behave: features/shell_timeout_override.feature — 32 scenarios (shell + http, including one proving shell_max_timeout does not leak into http_request). Full suite green (2943 scenarios, 0 failed).
• Robot: robot/shell_timeout_override.robot — 4 real-subprocess integration tests.
• ASV: benchmarks/timeout_policy_benchmark.py.
• Coverage 96.7% (new files: timeout_policy.py 100%, llm_tools.py 100%, tool.py 98%). lint / format / typecheck / security / dead_code all green.

Closes #111

## Summary Adds an optional per-invocation `timeout` argument to the `shell` and `http_request` tools so an LLM driving them can raise the execution limit for a single long-running call — instead of being told to "increase the timeout config value", which it cannot do at runtime. The model previously threaded `timeout N` into the call, corrupting the command. - New immutable `TimeoutPolicy` value object resolves the effective timeout. - Generic `max_timeout` config field (default 120s) bounds any override; an optional shell-only `shell_max_timeout` refines the ceiling for `shell` alone and is **never** consulted by `http_request`. - Absent the argument, behaviour is byte-for-byte unchanged. Invalid overrides are rejected before any subprocess is spawned / request is sent. Timeout errors now direct a retry with a larger `timeout` argument. ## Specification / ADR - `docs/adr/ADR-2030-tool-calling-spec-extensions.md` **D-9** (accepted revision). - Actor Configuration Standard §4.5 + §21.1 → **Version 1.2.0** (adds the generic `max_timeout` field). ## Testing - **Behave:** `features/shell_timeout_override.feature` — 32 scenarios (shell + http, including one proving `shell_max_timeout` does not leak into `http_request`). Full suite green (2943 scenarios, 0 failed). - **Robot:** `robot/shell_timeout_override.robot` — 4 real-subprocess integration tests. - **ASV:** `benchmarks/timeout_policy_benchmark.py`. - Coverage **96.7%** (new files: `timeout_policy.py` 100%, `llm_tools.py` 100%, `tool.py` 98%). lint / format / typecheck / security / dead_code all green. Closes #111

CoreRasurae added this to the v2.1.0 milestone 2026-08-04 23:01:34 +00:00

CoreRasurae added the

Type

Feature

label 2026-08-04 23:01:35 +00:00

hurui200320 approved these changes 2026-08-05 05:51:56 +00:00

hurui200320 left a comment

Copy link

PR Review: !113 (Ticket #111)

Verdict: Approve

The implementation cleanly realizes ADR-2030 D-9 and the Actor Configuration Standard §4.5 / §21.1 (Version 1.2.0) changes. The TimeoutPolicy value object is a good abstraction, validation happens before any subprocess/request, the timeout control argument is never concatenated into the shell command, and the error messages now point the model at the actionable per-call lever. Tests (Behave, Robot, ASV) are comprehensive and the commit/branch hygiene matches the ticket metadata. Only minor gaps/note-level items remain.

Critical Issues

None

Major Issues

None

Minor Issues

1. Missing regression scenario for the original bug shape (timeout + positional args)

   • File: features/shell_timeout_override.feature
   • The original failure trace in #111 was the model injecting timeout N into the positional args list, which got concatenated onto the command line. The code now correctly reads args.get("timeout") separately from args["args"], but there is no Behave/Robot scenario that supplies both a per-call timeout and a positional args list and asserts the output is uncorrupted. Adding one scenario would close the regression loop explicitly.

2. TimeoutPolicy module docstring is slightly stale

   • File: src/cleveractors/agents/timeout_policy.py, lines 1–9
   • The docstring says the policy "backs the shell tool's per-invocation timeout argument today … and is reusable by any future tool." Since _http_request_tool also uses TimeoutPolicy today, the wording implies only shell consumes it. Rephrase to mention both current consumers or drop the "today / future" framing.

3. Invalid timeout ceilings are validated lazily

   • File: src/cleveractors/agents/tool.py, lines 325–362
   • An invalid max_timeout or shell_max_timeout is only detected when the first timeout-honouring tool is invoked, not at ToolAgent construction. For faster failure of misconfigured agents, consider validating these config fields in __init__ (or in the policy builders called from __init__).

4. Coverage sits between two documented thresholds

   • The PR reports 96.7% coverage. This passes the noxfile.py constant (COVERAGE_THRESHOLD = 96.5), but CONTRIBUTING.md states the project-specific enforced merge gate is 97%. Please confirm the actual nox -s coverage_report output; if it is below 97%, add targeted tests to meet the documented gate (the project may also need to reconcile the noxfile constant with CONTRIBUTING.md).

Nits

1. ShellTimeoutLib exposes a raw ValueError on bad timeout strings

   • File: robot/ShellTimeoutLib.py, line 36
   • float(timeout) will raise ValueError if the Robot test passes a non-numeric string. Wrapping this in an ExecutionError (or validating and raising AssertionError) would give clearer Robot failure output.

2. Empty benchmark teardown

   • File: benchmarks/timeout_policy_benchmark.py, lines 32–33
   • The teardown method is a no-op. It is harmless, but can be removed or annotated with a comment if state cleanup is truly unnecessary.

Summary

Solid, well-scoped change. The per-invocation timeout argument is implemented correctly for both shell and http_request, the ceiling logic (max_timeout / shell_max_timeout) is clean and properly separated, and the schema/documentation/spec updates are all in place. The only substantive follow-ups are adding the timeout+args regression scenario and clarifying the coverage threshold situation; neither blocks approval.

## PR Review: !113 (Ticket #111) ### Verdict: Approve The implementation cleanly realizes ADR-2030 D-9 and the Actor Configuration Standard §4.5 / §21.1 (Version 1.2.0) changes. The `TimeoutPolicy` value object is a good abstraction, validation happens before any subprocess/request, the `timeout` control argument is never concatenated into the shell command, and the error messages now point the model at the actionable per-call lever. Tests (Behave, Robot, ASV) are comprehensive and the commit/branch hygiene matches the ticket metadata. Only minor gaps/note-level items remain. ### Critical Issues None ### Major Issues None ### Minor Issues 1. **Missing regression scenario for the original bug shape (`timeout` + positional `args`)** - **File:** `features/shell_timeout_override.feature` - The original failure trace in #111 was the model injecting `timeout N` into the positional `args` list, which got concatenated onto the command line. The code now correctly reads `args.get("timeout")` separately from `args["args"]`, but there is no Behave/Robot scenario that supplies **both** a per-call `timeout` and a positional `args` list and asserts the output is uncorrupted. Adding one scenario would close the regression loop explicitly. 2. **`TimeoutPolicy` module docstring is slightly stale** - **File:** `src/cleveractors/agents/timeout_policy.py`, lines 1–9 - The docstring says the policy "backs the `shell` tool's per-invocation `timeout` argument today … and is reusable by any future tool." Since `_http_request_tool` also uses `TimeoutPolicy` today, the wording implies only `shell` consumes it. Rephrase to mention both current consumers or drop the "today / future" framing. 3. **Invalid timeout ceilings are validated lazily** - **File:** `src/cleveractors/agents/tool.py`, lines 325–362 - An invalid `max_timeout` or `shell_max_timeout` is only detected when the first timeout-honouring tool is invoked, not at `ToolAgent` construction. For faster failure of misconfigured agents, consider validating these config fields in `__init__` (or in the policy builders called from `__init__`). 4. **Coverage sits between two documented thresholds** - The PR reports **96.7%** coverage. This passes the `noxfile.py` constant (`COVERAGE_THRESHOLD = 96.5`), but `CONTRIBUTING.md` states the project-specific enforced merge gate is **97%**. Please confirm the actual `nox -s coverage_report` output; if it is below 97%, add targeted tests to meet the documented gate (the project may also need to reconcile the noxfile constant with `CONTRIBUTING.md`). ### Nits 1. **`ShellTimeoutLib` exposes a raw `ValueError` on bad timeout strings** - **File:** `robot/ShellTimeoutLib.py`, line 36 - `float(timeout)` will raise `ValueError` if the Robot test passes a non-numeric string. Wrapping this in an `ExecutionError` (or validating and raising `AssertionError`) would give clearer Robot failure output. 2. **Empty benchmark `teardown`** - **File:** `benchmarks/timeout_policy_benchmark.py`, lines 32–33 - The `teardown` method is a no-op. It is harmless, but can be removed or annotated with a comment if state cleanup is truly unnecessary. ### Summary Solid, well-scoped change. The per-invocation `timeout` argument is implemented correctly for both `shell` and `http_request`, the ceiling logic (`max_timeout` / `shell_max_timeout`) is clean and properly separated, and the schema/documentation/spec updates are all in place. The only substantive follow-ups are adding the `timeout`+`args` regression scenario and clarifying the coverage threshold situation; neither blocks approval.

CoreRasurae commented 2026-08-05 09:55:26 +00:00

Author

Member

Copy link

In the review issuecomment 321954, Minor, Issue 4, the coverage is a non-issue, since the 96.5% threshold rounds to the 97% threshold in the documentation and it is meant to be that way. The current coverage of 96.7% is within the specified range.

In the review issuecomment 321954, Minor, Issue 4, the coverage is a non-issue, since the 96.5% threshold rounds to the 97% threshold in the documentation and it is meant to be that way. The current coverage of 96.7% is within the specified range.

CoreRasurae commented 2026-08-05 10:23:48 +00:00

Author

Member

Copy link

Thanks for the review, @hurui200320! Addressed the Minor issues; Nit 1 fixed, Nit 2 kept as-is (see below). Confirmed all four against §4.5/ADR-2030 before applying — none conflict with the spec.

Minor 1 (missing timeout+args regression scenario) — Added. Two new Behave scenarios in features/shell_timeout_override.feature reproduce the original bug shape directly: a positional args list containing the literal tokens "timeout"/"99" alongside a real per-call timeout control argument, asserting the output is exactly the harmless concatenated text ("marker timeout 99") and that the override still functions (a sleep 2 succeeds under timeout=4 even with args present). Also added a matching Robot regression test.

Minor 2 (stale TimeoutPolicy docstring) — Fixed. Now states it backs the per-invocation timeout argument on both shell and http_request today, dropping the "today / future" framing.

Minor 3 (lazy ceiling validation) — Fixed. ToolAgent.__init__ now eagerly builds both timeout policies and converts a ValueError into AgentCreationError, so a misconfigured tools_max_timeout/shell_max_timeout fails at construction, not on first call. As a consequence, the two call sites (_execute_shell_command, _http_request_tool) no longer need their own try/except ValueError — the ceiling is guaranteed valid by the time they run, per ADR-2030 D-9 (updated in place with a bullet documenting this). The two existing "invalid ceiling" scenarios now assert AgentCreationError at construction time instead of ExecutionError at call time.

Minor 4 (coverage 96.5% vs 97%) — No code change; per @CoreRasurae's earlier reply this is an intentional pre-existing project-wide threshold choice, outside this ticket's scope (not part of the Actor Configuration Standard or ADR-2030). Independently verified: a coverage run scoped to the feature-relevant BDD files shows timeout_policy.py and llm_tools.py at 100%, and none of the changed/added lines in tool.py appear in that scoped run's missing-lines list — the new eager-validation code is fully exercised. Also confirmed the full 2945-scenario suite still passes with 0 failures after these changes (no regressions from touching the shared ToolAgent.__init__ path).

Nit 1 (ShellTimeoutLib raw ValueError) — Fixed. Added a _parse_timeout helper that raises a clear AssertionError on a non-numeric timeout string; added a Robot test case (Non Numeric Timeout Argument Fails With A Clear Message) exercising it.

Nit 2 (empty benchmark teardown) — Left as-is. It matches the established setup/time_*/teardown lifecycle convention used by the other benchmarks in this repo (e.g. hello_benchmark.py), so removing it would make this benchmark inconsistent with house style for near-zero benefit.

Ran nox -s lint / format --check / typecheck / dead_code / security_scan (all green), the full Behave suite (146 features, 2945 scenarios, 0 failed), and the Robot integration suite for this feature (5/5 passed) after applying the above.

Thanks for the review, @hurui200320! Addressed the Minor issues; Nit 1 fixed, Nit 2 kept as-is (see below). Confirmed all four against §4.5/ADR-2030 before applying — none conflict with the spec. **Minor 1 (missing `timeout`+`args` regression scenario)** — Added. Two new Behave scenarios in `features/shell_timeout_override.feature` reproduce the original bug shape directly: a positional `args` list containing the literal tokens `"timeout"`/`"99"` alongside a real per-call `timeout` control argument, asserting the output is exactly the harmless concatenated text (`"marker timeout 99"`) and that the override still functions (a `sleep 2` succeeds under `timeout=4` even with `args` present). Also added a matching Robot regression test. **Minor 2 (stale `TimeoutPolicy` docstring)** — Fixed. Now states it backs the per-invocation `timeout` argument on *both* `shell` and `http_request` today, dropping the "today / future" framing. **Minor 3 (lazy ceiling validation)** — Fixed. `ToolAgent.__init__` now eagerly builds both timeout policies and converts a `ValueError` into `AgentCreationError`, so a misconfigured `tools_max_timeout`/`shell_max_timeout` fails at construction, not on first call. As a consequence, the two call sites (`_execute_shell_command`, `_http_request_tool`) no longer need their own `try/except ValueError` — the ceiling is guaranteed valid by the time they run, per ADR-2030 D-9 (updated in place with a bullet documenting this). The two existing "invalid ceiling" scenarios now assert `AgentCreationError` at construction time instead of `ExecutionError` at call time. **Minor 4 (coverage 96.5% vs 97%)** — No code change; per @CoreRasurae's earlier reply this is an intentional pre-existing project-wide threshold choice, outside this ticket's scope (not part of the Actor Configuration Standard or ADR-2030). Independently verified: a coverage run scoped to the feature-relevant BDD files shows `timeout_policy.py` and `llm_tools.py` at 100%, and none of the changed/added lines in `tool.py` appear in that scoped run's missing-lines list — the new eager-validation code is fully exercised. Also confirmed the full 2945-scenario suite still passes with 0 failures after these changes (no regressions from touching the shared `ToolAgent.__init__` path). **Nit 1 (`ShellTimeoutLib` raw `ValueError`)** — Fixed. Added a `_parse_timeout` helper that raises a clear `AssertionError` on a non-numeric `timeout` string; added a Robot test case (`Non Numeric Timeout Argument Fails With A Clear Message`) exercising it. **Nit 2 (empty benchmark `teardown`)** — Left as-is. It matches the established `setup`/`time_*`/`teardown` lifecycle convention used by the other benchmarks in this repo (e.g. `hello_benchmark.py`), so removing it would make this benchmark inconsistent with house style for near-zero benefit. Ran `nox -s lint / format --check / typecheck / dead_code / security_scan` (all green), the full Behave suite (146 features, 2945 scenarios, 0 failed), and the Robot integration suite for this feature (5/5 passed) after applying the above.

CoreRasurae force-pushed feature/m1-shell-timeout-override from e3b675b7d2 to f19714a3da 2026-08-05 10:27:18 +00:00 Compare

CoreRasurae added 1 commit 2026-08-05 12:13:21 +00:00

feat(agents): allow per-invocation timeout override on shell/http tools ... 0133520555

The tool agent `timeout` config field (Actor Configuration Standard §4.5,
default 1s) was a static per-agent value, and the shell/http_request timeout
errors told the model to "increase the timeout config value" — an action an
LLM driving the tool cannot take at runtime. The model would instead thread
`timeout N` into the call, corrupting the command.

Both tools now accept an optional per-call `timeout` argument, resolved by a
new immutable `TimeoutPolicy` value object and bounded by a generic
`tools_max_timeout` config field (default 120s). An optional shell-only
`shell_max_timeout` refines the ceiling for `shell` alone and is never
consulted by `http_request`. Absent the argument, behaviour is byte-for-byte
unchanged. Invalid overrides are rejected before any subprocess is spawned or
request is sent; the timeout errors now direct a retry with a larger `timeout`
argument.

Implements ADR-2030 D-9 (accepted revision) and Actor Configuration Standard
§4.5 / §21.1 (Version 1.2.0).

ISSUES CLOSED: #111

CoreRasurae force-pushed feature/m1-shell-timeout-override from f19714a3da to 0133520555 2026-08-05 12:13:21 +00:00 Compare

CoreRasurae merged commit 0133520555 into master 2026-08-05 12:40:43 +00:00

CoreRasurae deleted branch feature/m1-shell-timeout-override 2026-08-05 12:40:56 +00:00

CoreRasurae referenced this pull request 2026-08-05 12:44:46 +00:00

Allow the shell and http_request tool timeouts to be overridden per invocation via a timeout argument #111

Sign in to join this conversation.

Reviewers

No reviewers

hurui200320

Labels

Clear labels

  

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 labels

auto/blocked-by-deps

auto/ci-timeout

auto/claimed-implementer

auto/claimed-merge

auto/claimed-reviewer

auto/driver-down

auto/invariant-violation

auto/last-attempt-tier-0

auto/last-attempt-tier-1

auto/last-attempt-tier-2

auto/last-attempt-tier-min

Automation Tracking

auto/needs-conflict-resolution

auto/needs-implementer

auto/postmortem

auto/ready-to-merge

auto/restart-throttled

auto/revert

auto/sentinel

auto/stale-inactivity

auto/unstable

Blocked

Bounty

$100

Bounty

$1000

Bounty

$10000

Bounty

$20

Bounty

$2000

Bounty

$250

Bounty

$50

Bounty

$500

Bounty

$5000

Bounty

$750

MoSCoW

Could have

MoSCoW

Must have

MoSCoW

Should have

Needs Feedback

Points

1

Points

13

Points

2

Points

21

Points

3

Points

34

Points

5

Points

55

Points

8

Points

88

Priority

Backlog

Priority

CI Blocker

Priority

Critical

Priority

High

Priority

Low

Priority

Medium

Signed-off: Owner

Signed-off: Scrum Master

Signed-off: Tech Lead

Spike

State

Completed

State

Duplicate

State

In Progress

State

In Review

State

Paused

State

Unverified

State

Verified

State

Wont Do

Type

Automation

Type

Bug

Type

Discussion

Type

Documentation

Type

Epic

Type

Feature

Type

Legendary

Type

Refactor

Type

Support

Type

Task

Type

Testing

Milestone

Clear milestone

No items

No milestone

v2.1.0

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

cleveragents/cleveractors-core!113

No description provided.