cleveragents/cleveragents-core
4
0
Fork 3
Code Issues 6.0k Pull Requests 115 Actions Packages Projects Releases Wiki Activity

feat(security): add safety profile model and enforcement stubs #450

Merged
CoreRasurae merged 1 commits from feature/post-safety-profile into master 2026-03-02 20:09:47 +00:00
Conversation 4 Commits 1 Files Changed 35
+1907 -139
CoreRasurae commented 2026-02-25 23:50:02 +00:00
Member
Copy Link
Copy Source

Summary

Add SafetyProfile domain model with configurable safety constraints (allowed skill categories, sandbox/checkpoint requirements, human-approval flag, unsafe-tool gating, cost/retry limits) and integrate it into the Action model via from_config/as_cli_dict support. Persistence is backed by a safety_profile_json column on LifecycleActionModel with Alembic migration c4_001_safety_profile_column and a merge migration for multiple heads.

The resolve_safety_profile() stub raises NotImplementedError in local mode, signalling that real enforcement is deferred to server mode. Resolution follows plan > action > project > global precedence.

Covered by 26 Behave BDD scenarios, 6 Robot Framework smoke tests, 5 ASV benchmark suites (11 timing functions), and docs/reference/safety_profile.md reference documentation.

Issue Reference

Closes #332

Dependencies

This PR blocks issue #332 (safety profile model and enforcement stubs).

## Summary Add `SafetyProfile` domain model with configurable safety constraints (allowed skill categories, sandbox/checkpoint requirements, human-approval flag, unsafe-tool gating, cost/retry limits) and integrate it into the `Action` model via `from_config`/`as_cli_dict` support. Persistence is backed by a `safety_profile_json` column on `LifecycleActionModel` with Alembic migration `c4_001_safety_profile_column` and a merge migration for multiple heads. The `resolve_safety_profile()` stub raises `NotImplementedError` in local mode, signalling that real enforcement is deferred to server mode. Resolution follows plan > action > project > global precedence. Covered by 26 Behave BDD scenarios, 6 Robot Framework smoke tests, 5 ASV benchmark suites (11 timing functions), and `docs/reference/safety_profile.md` reference documentation. ## Issue Reference Closes #332 ## Dependencies This PR blocks issue #332 (safety profile model and enforcement stubs).
CoreRasurae added this to the v3.6.0 milestone 2026-02-25 23:50:06 +00:00
CoreRasurae added the
Type
Feature
 label 2026-02-25 23:50:07 +00:00
CoreRasurae force-pushed feature/post-safety-profile from ccb96e8261 to fff9da60ee 2026-02-26 19:38:17 +00:00 Compare
CoreRasurae requested review from brent.edwards 2026-02-26 19:39:02 +00:00
brent.edwards requested changes 2026-02-26 20:05:46 +00:00
Dismissed
brent.edwards left a comment
Member
Copy Link
Copy Source

Review Summary

Scope: SafetyProfile domain model + Action integration + persistence JSON field + tests/bench/docs.

CI status isn’t visible via the API on my side. Please confirm required checks per docs/development/ci-cd.md (lint, typecheck, security, quality, unit_tests, integration_tests, coverage, build) pass before merge.

Findings

P1:must-fix — Missing Alembic migration for the new safety_profile_json column. The ORM now reads/writes safety_profile_json, but no migration exists (and docs reference c4_001_safety_profile_column which is missing). This will break persistence once an Action uses safety_profile.

  • Code: src/cleveragents/infrastructure/database/models.py:268, src/cleveragents/infrastructure/database/models.py:368, src/cleveragents/infrastructure/database/models.py:421
  • Docs mention nonexistent migration: docs/reference/safety_profile.md:174

P2:should-fix — Action.from_config silently ignores invalid safety_profile types. If a user supplies a non-dict, the field is dropped instead of raising a validation error. Consider raising when safety_profile is present but not a dict/SafetyProfile for strict config validation.

  • Code: src/cleveragents/domain/models/core/action.py:626

P2:should-fix — docs/timeline.md contains a large, unrelated historical rewrite (dates/status regressions). Please split it into a separate PR or revert to keep this change focused on safety profiles.

  • Doc: docs/timeline.md

P3:nit — New docs/reference/safety_profile.md isn’t added to the reference nav list. Add it in docs/gen_ref_pages.py so it appears in the Reference sidebar.

  • Doc: docs/reference/safety_profile.md
  • Nav list: docs/gen_ref_pages.py

Positive Notes

  • SafetyProfile validation coverage and Behave/Robot suites are thorough and follow existing patterns.
  • Action integration (CLI dict + persistence JSON) is straightforward and consistent.
## Review Summary Scope: SafetyProfile domain model + Action integration + persistence JSON field + tests/bench/docs. CI status isn’t visible via the API on my side. Please confirm required checks per `docs/development/ci-cd.md` (lint, typecheck, security, quality, unit_tests, integration_tests, coverage, build) pass before merge. ## Findings **P1:must-fix** — Missing Alembic migration for the new `safety_profile_json` column. The ORM now reads/writes `safety_profile_json`, but no migration exists (and docs reference `c4_001_safety_profile_column` which is missing). This will break persistence once an Action uses `safety_profile`. - Code: `src/cleveragents/infrastructure/database/models.py:268`, `src/cleveragents/infrastructure/database/models.py:368`, `src/cleveragents/infrastructure/database/models.py:421` - Docs mention nonexistent migration: `docs/reference/safety_profile.md:174` **P2:should-fix** — `Action.from_config` silently ignores invalid `safety_profile` types. If a user supplies a non-dict, the field is dropped instead of raising a validation error. Consider raising when `safety_profile` is present but not a dict/SafetyProfile for strict config validation. - Code: `src/cleveragents/domain/models/core/action.py:626` **P2:should-fix** — `docs/timeline.md` contains a large, unrelated historical rewrite (dates/status regressions). Please split it into a separate PR or revert to keep this change focused on safety profiles. - Doc: `docs/timeline.md` **P3:nit** — New `docs/reference/safety_profile.md` isn’t added to the reference nav list. Add it in `docs/gen_ref_pages.py` so it appears in the Reference sidebar. - Doc: `docs/reference/safety_profile.md` - Nav list: `docs/gen_ref_pages.py` ## Positive Notes - SafetyProfile validation coverage and Behave/Robot suites are thorough and follow existing patterns. - Action integration (CLI dict + persistence JSON) is straightforward and consistent.
CoreRasurae force-pushed feature/post-safety-profile from fff9da60ee to 78142df33b 2026-02-27 17:22:10 +00:00 Compare
freemo added the
MoSCoW
Must have
Points
8
Priority
Low
State
Verified
 labels 2026-03-01 04:36:11 +00:00
CoreRasurae force-pushed feature/post-safety-profile from 78142df33b to 1b6e585b9d 2026-03-02 11:21:15 +00:00 Compare
CoreRasurae force-pushed feature/post-safety-profile from 1b6e585b9d to 2677abb4ad 2026-03-02 14:34:53 +00:00 Compare
freemo requested changes 2026-03-02 15:23:31 +00:00
freemo left a comment
Owner
Copy Link
Copy Source

Code Review: PR #450 — feat(security): add safety profile model and enforcement stubs

Overall Assessment

The SafetyProfile domain model, its Action integration, persistence layer, and test coverage are technically well-implemented. The composition approach (AutomationProfile.safety: SafetyProfile) correctly follows the project owner's guidance from issue #332 comments, and the code quality is solid throughout. However, there are several process-level violations of CONTRIBUTING.md that must be addressed before this PR can be merged.

Critical / High Priority — Process Violations

H1: Empty PR Description (CONTRIBUTING.md §PR Process #1)

The PR body is completely empty. Per CONTRIBUTING.md:

Every PR must include a clear, descriptive body that explains the purpose of the change [...] At a minimum, the description must contain: a summary of the changes, an issue reference using a closing keyword (e.g., Closes #332), and a dependency link.

The guidelines also state: "PRs submitted without a description or without an issue reference will not be reviewed."

Action required: Add a PR description with a summary, Closes #332 closing keyword, and set up the Forgejo dependency (PR blocks #332, issue #332 depends on the PR).

H2: Non-Atomic Commit — Unrelated Deletions (CONTRIBUTING.md §Atomic Commits)

This single commit bundles the safety profile feature with the deletion of unrelated code:

Deleted File Concern
src/cleveragents/acp/clients.py Server client protocol stubs
src/cleveragents/acp/server_config.py Server connection configuration
src/cleveragents/cli/commands/server.py Server CLI commands
src/cleveragents/application/services/subplan_service.py Subplan spawning service
src/cleveragents/domain/models/acms/__init__.py + crp.py CRP domain models
features/consolidated_*.feature (17 files) Consolidated test files
benchmarks/crp_model_bench.py, server_stub_bench.py, subplan_spawn_bench.py Unrelated benchmarks
robot/crp_models.robot, server_stubs.robot, subplan_spawn.robot Unrelated robot tests

Per CONTRIBUTING.md: "One logical change per commit. Each commit must encapsulate a single, focused change." and "Never bundle cosmetic changes with functional changes in the same commit."

The safety profile feature, the removal of server/CRP/subplan code, and the feature file reorganization are three separate logical changes that should be in separate commits, each with their own issue.

Action required: The unrelated deletions (server stubs, CRP models, subplan service) and the feature file reorganization should be extracted into separate commits under their own issues. The PR should contain only the safety profile changes.

H3: Incorrect Labels on PR (CONTRIBUTING.md §PR Process #12)

The PR currently carries: MoSCoW/Must have, Points/8, Priority/Low, State/Verified, Type/Feature.

Per CONTRIBUTING.md:

Every PR must carry exactly one Type/ label [...] No other label scopes (State/, Priority/, MoSCoW/) are applied to Pull Requests; those scopes are reserved for issues only.

Action required: Remove State/Verified, Priority/Low, MoSCoW/Must have, and Points/8 from the PR. Only Type/Feature should remain.

Medium Priority — Process Items

M1: Missing Changelog Update (CONTRIBUTING.md §PR Process #6)

The PR must include an update to the changelog file. Add one new entry per commit in the PR that describes the change from the user's perspective.

No changelog update is present in the diff.

M2: Missing CONTRIBUTORS.md Update (CONTRIBUTING.md §PR Process #8)

Add your name to CONTRIBUTORS.md if it is not already listed.

No CONTRIBUTORS.md update is present in the diff. Please verify if your name is already listed; if not, add it.

M3: Issue #332 Ref Field Not Set

The issue Metadata specifies branch feature/post-safety-profile, but the Forgejo Ref field on issue #332 is empty. Per CONTRIBUTING.md: "The Ref field must be set to the same branch named in the issue body's Metadata section" for development issues in active states.

M4: Needs feedback Label Still on Issue #332

The Needs feedback label appears to be stale — the feedback from the project owner (composition approach, spec updates) has been addressed in the current implementation. This label should be removed if the feedback is resolved.

Low Priority — Code Quality Notes

See inline comments below for specific code observations on:

  • resolve_safety_profile() stub implementation
  • from_yaml() missing explicit encoding
  • _row_to_domain() hardcoded safety field defaults

L1: Commit Body Inaccuracy

The commit message body states "20 BDD scenarios" but features/safety_profile.feature contains approximately 30 scenarios. The numbers should match the actual content.

Positive Observations

  • Model design: SafetyProfile is well-designed with proper Pydantic validation, frozen immutability, cross-field validators, factory methods, and comprehensive type annotations. Stays under 500 lines.
  • Composition: The AutomationProfile.safety: SafetyProfile composition correctly follows the project owner's directive and eliminates dual authority for overlapping safety flags.
  • Test coverage: 30 BDD scenarios covering defaults, parsing, constraint validation, cross-field validation, type guards, immutability, factories, refs, stub behavior, round-trip serialization, and action integration. Robot smoke tests and ASV benchmarks are also included.
  • Documentation: docs/reference/safety_profile.md is thorough — covers schema, defaults, validation, precedence, YAML config, action integration, stub enforcement, and persistence.
  • Commit message: First line matches the issue Metadata exactly, follows Conventional Changelog format, body is descriptive, and footer references issue #332.
  • Migration: Proper Alembic migration with merge migration for multiple heads.

Summary

The safety profile feature itself is well-implemented and demonstrates good engineering practices. The blocking issues are primarily process-related: the empty PR body (H1), the bundled unrelated deletions (H2), and the incorrect labels (H3). Of these, H2 is the most significant as it makes the commit non-atomic and non-revertible in isolation. H1 and H3 are straightforward to fix.

Requesting changes primarily for H1 (empty PR body) and H2 (non-atomic commit). Once these are addressed, this PR should be in good shape for approval.

## Code Review: PR #450 — `feat(security): add safety profile model and enforcement stubs` ### Overall Assessment The **SafetyProfile** domain model, its Action integration, persistence layer, and test coverage are technically well-implemented. The composition approach (`AutomationProfile.safety: SafetyProfile`) correctly follows the project owner's guidance from issue #332 comments, and the code quality is solid throughout. However, there are several process-level violations of `CONTRIBUTING.md` that must be addressed before this PR can be merged. --- ### Critical / High Priority — Process Violations #### H1: Empty PR Description (CONTRIBUTING.md §PR Process #1) The PR body is completely empty. Per CONTRIBUTING.md: > Every PR must include a clear, descriptive body that explains the purpose of the change [...] At a minimum, the description must contain: a **summary** of the changes, an **issue reference** using a closing keyword (e.g., `Closes #332`), and a **dependency link**. The guidelines also state: *"PRs submitted without a description or without an issue reference will not be reviewed."* **Action required**: Add a PR description with a summary, `Closes #332` closing keyword, and set up the Forgejo dependency (PR **blocks** #332, issue #332 **depends on** the PR). --- #### H2: Non-Atomic Commit — Unrelated Deletions (CONTRIBUTING.md §Atomic Commits) This single commit bundles the safety profile feature with the **deletion of unrelated code**: | Deleted File | Concern | |---|---| | `src/cleveragents/acp/clients.py` | Server client protocol stubs | | `src/cleveragents/acp/server_config.py` | Server connection configuration | | `src/cleveragents/cli/commands/server.py` | Server CLI commands | | `src/cleveragents/application/services/subplan_service.py` | Subplan spawning service | | `src/cleveragents/domain/models/acms/__init__.py` + `crp.py` | CRP domain models | | `features/consolidated_*.feature` (17 files) | Consolidated test files | | `benchmarks/crp_model_bench.py`, `server_stub_bench.py`, `subplan_spawn_bench.py` | Unrelated benchmarks | | `robot/crp_models.robot`, `server_stubs.robot`, `subplan_spawn.robot` | Unrelated robot tests | Per CONTRIBUTING.md: *"One logical change per commit. Each commit must encapsulate a single, focused change."* and *"Never bundle cosmetic changes with functional changes in the same commit."* The safety profile feature, the removal of server/CRP/subplan code, and the feature file reorganization are **three separate logical changes** that should be in separate commits, each with their own issue. **Action required**: The unrelated deletions (server stubs, CRP models, subplan service) and the feature file reorganization should be extracted into separate commits under their own issues. The PR should contain only the safety profile changes. --- #### H3: Incorrect Labels on PR (CONTRIBUTING.md §PR Process #12) The PR currently carries: `MoSCoW/Must have`, `Points/8`, `Priority/Low`, `State/Verified`, `Type/Feature`. Per CONTRIBUTING.md: > Every PR must carry exactly one `Type/` label [...] No other label scopes (`State/`, `Priority/`, `MoSCoW/`) are applied to Pull Requests; those scopes are reserved for issues only. **Action required**: Remove `State/Verified`, `Priority/Low`, `MoSCoW/Must have`, and `Points/8` from the PR. Only `Type/Feature` should remain. --- ### Medium Priority — Process Items #### M1: Missing Changelog Update (CONTRIBUTING.md §PR Process #6) > The PR must include an update to the changelog file. Add one new entry per commit in the PR that describes the change from the user's perspective. No changelog update is present in the diff. #### M2: Missing CONTRIBUTORS.md Update (CONTRIBUTING.md §PR Process #8) > Add your name to `CONTRIBUTORS.md` if it is not already listed. No CONTRIBUTORS.md update is present in the diff. Please verify if your name is already listed; if not, add it. #### M3: Issue #332 Ref Field Not Set The issue Metadata specifies branch `feature/post-safety-profile`, but the Forgejo Ref field on issue #332 is empty. Per CONTRIBUTING.md: *"The Ref field must be set to the same branch named in the issue body's Metadata section"* for development issues in active states. #### M4: `Needs feedback` Label Still on Issue #332 The `Needs feedback` label appears to be stale — the feedback from the project owner (composition approach, spec updates) has been addressed in the current implementation. This label should be removed if the feedback is resolved. --- ### Low Priority — Code Quality Notes See inline comments below for specific code observations on: - `resolve_safety_profile()` stub implementation - `from_yaml()` missing explicit encoding - `_row_to_domain()` hardcoded safety field defaults #### L1: Commit Body Inaccuracy The commit message body states *"20 BDD scenarios"* but `features/safety_profile.feature` contains approximately 30 scenarios. The numbers should match the actual content. --- ### Positive Observations - **Model design**: `SafetyProfile` is well-designed with proper Pydantic validation, frozen immutability, cross-field validators, factory methods, and comprehensive type annotations. Stays under 500 lines. - **Composition**: The `AutomationProfile.safety: SafetyProfile` composition correctly follows the project owner's directive and eliminates dual authority for overlapping safety flags. - **Test coverage**: 30 BDD scenarios covering defaults, parsing, constraint validation, cross-field validation, type guards, immutability, factories, refs, stub behavior, round-trip serialization, and action integration. Robot smoke tests and ASV benchmarks are also included. - **Documentation**: `docs/reference/safety_profile.md` is thorough — covers schema, defaults, validation, precedence, YAML config, action integration, stub enforcement, and persistence. - **Commit message**: First line matches the issue Metadata exactly, follows Conventional Changelog format, body is descriptive, and footer references issue #332. - **Migration**: Proper Alembic migration with merge migration for multiple heads. --- ### Summary The safety profile feature itself is well-implemented and demonstrates good engineering practices. The blocking issues are primarily process-related: the empty PR body (H1), the bundled unrelated deletions (H2), and the incorrect labels (H3). Of these, H2 is the most significant as it makes the commit non-atomic and non-revertible in isolation. H1 and H3 are straightforward to fix. Requesting changes primarily for H1 (empty PR body) and H2 (non-atomic commit). Once these are addressed, this PR should be in good shape for approval.
src/cleveragents/domain/models/core/safety_profile.py Outdated
@@ -0,0 +222,4 @@
file_path = Path(path)
if not file_path.exists():
raise FileNotFoundError(f"Safety profile YAML file not found: {file_path}")
with open(file_path) as fh:
freemo commented 2026-03-02 15:23:31 +00:00
Owner
Copy Link
Copy Source

[L2] Missing explicit encoding parameter

open(file_path) should specify encoding="utf-8" explicitly. While the default encoding on most systems is UTF-8, relying on the platform default is fragile and can cause issues on Windows or in non-standard environments. Per Python best practices:

with open(file_path, encoding="utf-8") as fh:
**[L2] Missing explicit encoding parameter** `open(file_path)` should specify `encoding="utf-8"` explicitly. While the default encoding on most systems is UTF-8, relying on the platform default is fragile and can cause issues on Windows or in non-standard environments. Per Python best practices: ```python with open(file_path, encoding="utf-8") as fh: ```
CoreRasurae commented 2026-03-02 17:23:31 +00:00
Author
Member
Copy Link
Copy Source

addressed

addressed
src/cleveragents/domain/models/core/safety_profile.py Outdated
@@ -0,0 +312,4 @@
Raises:
NotImplementedError: Always, in local mode.
"""
raise NotImplementedError(
freemo commented 2026-03-02 15:23:31 +00:00
Owner
Copy Link
Copy Source

[L3] Stub does no resolution before raising

This function accepts four precedence levels (plan_profile, action_profile, project_profile, global_profile) but performs zero resolution logic before raising NotImplementedError. Even as a stub, it would be valuable to include the intended resolution flow as commented-out logic or pseudocode, so that the future implementer has a clear roadmap. For example:

# Future implementation should resolve in this order:
# 1. plan_profile (highest precedence)
# 2. action_profile
# 3. project_profile
# 4. global_profile (lowest precedence)
# Return the first non-None profile with its provenance.
raise NotImplementedError(...)

This would also make the function more self-documenting and align with the docstring's description of the resolution order.

**[L3] Stub does no resolution before raising** This function accepts four precedence levels (`plan_profile`, `action_profile`, `project_profile`, `global_profile`) but performs zero resolution logic before raising `NotImplementedError`. Even as a stub, it would be valuable to include the intended resolution flow as commented-out logic or pseudocode, so that the future implementer has a clear roadmap. For example: ```python # Future implementation should resolve in this order: # 1. plan_profile (highest precedence) # 2. action_profile # 3. project_profile # 4. global_profile (lowest precedence) # Return the first non-None profile with its provenance. raise NotImplementedError(...) ``` This would also make the function more self-documenting and align with the docstring's description of the resolution order.
CoreRasurae commented 2026-03-02 17:23:00 +00:00
Author
Member
Copy Link
Copy Source

comments inserted

comments inserted
src/cleveragents/infrastructure/database/repositories.py Outdated
@@ -4291,0 +4289,4 @@
safety=SafetyProfile(
require_sandbox=bool(row.require_sandbox),
require_checkpoints=bool(row.require_checkpoints),
require_human_approval=False,
freemo commented 2026-03-02 15:23:31 +00:00
Owner
Copy Link
Copy Source

[L4] Hardcoded safety field defaults deserve a comment

The new SafetyProfile fields (require_human_approval, max_retries_per_step) are hardcoded here because the database table does not have columns for them — only the original three booleans (require_sandbox, require_checkpoints, allow_unsafe_tools) are persisted. This is a reasonable approach for backwards compatibility, but a clarifying comment would prevent future confusion:

# NOTE: require_human_approval and max_retries_per_step are not
# persisted in the automation_profiles table (only the original
# three safety booleans are stored).  Defaults are used here for
# backwards compatibility.  See c4_001_safety_profile_column for
# the Action-level safety_profile_json column.
**[L4] Hardcoded safety field defaults deserve a comment** The new `SafetyProfile` fields (`require_human_approval`, `max_retries_per_step`) are hardcoded here because the database table does not have columns for them — only the original three booleans (`require_sandbox`, `require_checkpoints`, `allow_unsafe_tools`) are persisted. This is a reasonable approach for backwards compatibility, but a clarifying comment would prevent future confusion: ```python # NOTE: require_human_approval and max_retries_per_step are not # persisted in the automation_profiles table (only the original # three safety booleans are stored). Defaults are used here for # backwards compatibility. See c4_001_safety_profile_column for # the Action-level safety_profile_json column. ```
CoreRasurae commented 2026-03-02 17:23:14 +00:00
Author
Member
Copy Link
Copy Source

addressed as requested

addressed as requested
CoreRasurae removed the
State
Verified
Priority
Low
MoSCoW
Must have
Points
8
 labels 2026-03-02 17:11:48 +00:00
CoreRasurae force-pushed feature/post-safety-profile from 2677abb4ad to 01686f8cd0 2026-03-02 17:38:34 +00:00 Compare
CoreRasurae force-pushed feature/post-safety-profile from 01686f8cd0 to 66b9a4279f 2026-03-02 17:44:30 +00:00 Compare
brent.edwards approved these changes 2026-03-02 20:02:03 +00:00
brent.edwards left a comment
Member
Copy Link
Copy Source

Approve.

Approve.
CoreRasurae merged commit 66b9a4279f into master 2026-03-02 20:09:47 +00:00
CoreRasurae deleted branch feature/post-safety-profile 2026-03-02 20:09:47 +00:00
aditya approved these changes 2026-03-03 08:40:49 +00:00
freemo added the
State
Completed
 label 2026-03-04 00:58:41 +00:00
Sign in to join this conversation.
Reviewers
No Reviewers
freemo
brent.edwards
aditya
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
State
Completed
Type
Feature
Milestone
No items
No Milestone v3.6.0
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: cleveragents/cleveragents-core#450
Delete Branch "feature/post-safety-profile"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?