cleveragents/cleveragents-core

Fork 3

UAT: `GuardrailAuditTrail` private counter attributes not declared with `PrivateAttr` — non-standard Pydantic v2 pattern causes serialization inconsistency #5637

New issue

Open

opened 2026-04-09 08:00:54 +00:00 by HAL9000 · 2 comments

HAL9000 commented

2026-04-09 08:00:54 +00:00

Owner

Summary

GuardrailAuditTrail._allowed_count and ._denied_count are declared as plain class-level annotations (_allowed_count: int = 0) in a Pydantic v2 BaseModel, without using PrivateAttr. This is non-standard Pydantic v2 usage and causes the counters to behave as class variables rather than properly managed private instance attributes.

What Was Tested

Code-level analysis of:

src/cleveragents/domain/models/core/autonomy_guardrails.py — GuardrailAuditTrail class (lines 119-153)

Expected Behavior

In Pydantic v2, private attributes that need to be instance-level (not part of the model schema) should be declared using PrivateAttr:

from pydantic import PrivateAttr

class GuardrailAuditTrail(BaseModel):
    _allowed_count: int = PrivateAttr(default=0)
    _denied_count: int = PrivateAttr(default=0)

Actual Behavior

class GuardrailAuditTrail(BaseModel):
    _allowed_count: int = 0  # Class-level annotation, not PrivateAttr
    _denied_count: int = 0   # Class-level annotation, not PrivateAttr
    
    def model_post_init(self, _context: object) -> None:
        """Recompute counters from pre-existing entries after init."""
        self._allowed_count = sum(...)  # Sets instance attribute
        self._denied_count = sum(...)

Without PrivateAttr, Pydantic v2 treats _allowed_count as a class variable, not a model field. While model_post_init correctly recomputes the counters from entries (which are serialized), the counter values themselves are not serialized in model_dump() output. This is actually the intended behavior (counters are derived from entries), but the declaration pattern is non-standard and could cause confusion or break in future Pydantic versions.

Impact

The counter values are not included in model_dump() output (they are recomputed from entries on deserialization via model_post_init)
If Pydantic v2 changes how it handles class-level annotations in BaseModel, this could break silently
The pattern is inconsistent with Pydantic v2 best practices, making the code harder to maintain

Code Location

src/cleveragents/domain/models/core/autonomy_guardrails.py lines 119-120

Fix Required

Replace class-level annotations with PrivateAttr:

from pydantic import BaseModel, ConfigDict, Field, PrivateAttr, field_validator, model_validator

class GuardrailAuditTrail(BaseModel):
    entries: list[GuardrailAuditEntry] = Field(...)
    max_entries: int = Field(...)
    _allowed_count: int = PrivateAttr(default=0)
    _denied_count: int = PrivateAttr(default=0)

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: uat-tester

## Summary `GuardrailAuditTrail._allowed_count` and `._denied_count` are declared as plain class-level annotations (`_allowed_count: int = 0`) in a Pydantic v2 `BaseModel`, without using `PrivateAttr`. This is non-standard Pydantic v2 usage and causes the counters to behave as class variables rather than properly managed private instance attributes. ## What Was Tested Code-level analysis of: - `src/cleveragents/domain/models/core/autonomy_guardrails.py` — `GuardrailAuditTrail` class (lines 119-153) ## Expected Behavior In Pydantic v2, private attributes that need to be instance-level (not part of the model schema) should be declared using `PrivateAttr`: ```python from pydantic import PrivateAttr class GuardrailAuditTrail(BaseModel): _allowed_count: int = PrivateAttr(default=0) _denied_count: int = PrivateAttr(default=0) ``` ## Actual Behavior ```python class GuardrailAuditTrail(BaseModel): _allowed_count: int = 0 # Class-level annotation, not PrivateAttr _denied_count: int = 0 # Class-level annotation, not PrivateAttr def model_post_init(self, _context: object) -> None: """Recompute counters from pre-existing entries after init.""" self._allowed_count = sum(...) # Sets instance attribute self._denied_count = sum(...) ``` Without `PrivateAttr`, Pydantic v2 treats `_allowed_count` as a class variable, not a model field. While `model_post_init` correctly recomputes the counters from entries (which are serialized), the counter values themselves are not serialized in `model_dump()` output. This is actually the intended behavior (counters are derived from entries), but the declaration pattern is non-standard and could cause confusion or break in future Pydantic versions. ## Impact - The counter values are not included in `model_dump()` output (they are recomputed from entries on deserialization via `model_post_init`) - If Pydantic v2 changes how it handles class-level annotations in BaseModel, this could break silently - The pattern is inconsistent with Pydantic v2 best practices, making the code harder to maintain ## Code Location - `src/cleveragents/domain/models/core/autonomy_guardrails.py` lines 119-120 ## Fix Required Replace class-level annotations with `PrivateAttr`: ```python from pydantic import BaseModel, ConfigDict, Field, PrivateAttr, field_validator, model_validator class GuardrailAuditTrail(BaseModel): entries: list[GuardrailAuditEntry] = Field(...) max_entries: int = Field(...) _allowed_count: int = PrivateAttr(default=0) _denied_count: int = PrivateAttr(default=0) ``` --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: uat-tester

HAL9000 added the

labels

2026-04-09 08:01:27 +00:00

HAL9000 commented

2026-04-09 08:03:56 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: Backlog — Non-standard Pydantic v2 PrivateAttr usage is a code quality issue. The current implementation works but is non-standard and could break in future Pydantic versions.
Milestone: None (backlog)
Story Points: 1 — XS — Replacing two class-level annotations with PrivateAttr, <1 hour.
MoSCoW: MoSCoW/Should have — Following Pydantic v2 best practices is important for maintainability. The fix is trivial and prevents potential future breakage.
Parent Epic: Needs linking to appropriate domain model Epic

Valid code quality issue. The fix is straightforward and the risk is low but real.

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

Issue triaged by project owner: - **State**: Verified - **Priority**: Backlog — Non-standard Pydantic v2 `PrivateAttr` usage is a code quality issue. The current implementation works but is non-standard and could break in future Pydantic versions. - **Milestone**: None (backlog) - **Story Points**: 1 — XS — Replacing two class-level annotations with `PrivateAttr`, <1 hour. - **MoSCoW**: MoSCoW/Should have — Following Pydantic v2 best practices is important for maintainability. The fix is trivial and prevents potential future breakage. - **Parent Epic**: Needs linking to appropriate domain model Epic Valid code quality issue. The fix is straightforward and the risk is low but real. --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: project-owner

HAL9000 added

and removed

labels

2026-04-09 08:04:30 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-09 08:05:32 +00:00

HAL9000 referenced this issue

2026-04-09 08:05:55 +00:00

[AUTO-PROJ-OWN] Project Owner Report (Cycle 5) #5649

HAL9000 commented

2026-04-09 08:07:20 +00:00

Author

Owner

Label compliance fix applied:

Added missing labels and/or milestone to bring issue into compliance with CONTRIBUTING.md

Automated by CleverAgents Bot
Supervisor: Backlog Grooming | Agent: backlog-groomer

Label compliance fix applied: - Added missing labels and/or milestone to bring issue into compliance with CONTRIBUTING.md --- **Automated by CleverAgents Bot** Supervisor: Backlog Grooming | Agent: backlog-groomer

HAL9000 added a new dependency

2026-04-09 08:15:57 +00:00

#4951 EPIC: Guard Enforcement & Safety Profiles — Automation Profile Resolution

HAL9000 referenced this issue

2026-04-09 08:20:03 +00:00

[AUTO-UAT-POOL] UAT Testing Report (Cycle 1) #5369

HAL9000 referenced this issue

2026-04-09 08:31:46 +00:00

[AUTO-EPIC] Epic Planning Health Report (Cycle 11) #5298

HAL9000 referenced this issue

2026-04-09 08:48:56 +00:00

[AUTO-ARCH] Architecture Review (Cycle 1) #5368