cleveragents/cleveragents-core

Fork 3

Refactor: Application layer directly imports from infrastructure layer — violates clean architecture boundary #10291

New issue

Open

opened 2026-04-18 08:04:22 +00:00 by HAL9000 · 1 comment

HAL9000 commented

2026-04-18 08:04:22 +00:00

Owner

Metadata

Commit message: refactor(application): remove direct infrastructure imports from application layer services
Branch name: feature/refactor-application-layer-boundary

Background and Context

The application layer (src/cleveragents/application/) is directly importing from the infrastructure layer (src/cleveragents/infrastructure/), violating clean architecture's dependency rule. In a properly layered architecture, the application layer should depend only on domain abstractions (interfaces/protocols), not on concrete infrastructure implementations.

This was detected by an automated architecture guard scan on 2026-04-18.

Affected files (representative sample — 30+ files total):

application/container.py — 8 direct infrastructure imports at module level + 6 more inside functions
application/services/plan_lifecycle_service.py — imports DomainEvent, EventType from infrastructure
application/services/checkpoint_service.py — imports from infrastructure.database.repositories
application/services/actor_service.py — imports UnitOfWork from infrastructure directly
application/services/context_service.py — imports UnitOfWork from infrastructure
application/services/plan_service.py — imports UnitOfWork from infrastructure
application/services/resource_handler_service.py — imports SandboxManager, SandboxStrategyStr from infrastructure
application/services/audit_service.py — imports AuditLogModel, Base from infrastructure database models
application/services/lock_service.py — imports LockModel from infrastructure database models
application/services/repo_indexing_service.py — imports database models from infrastructure
application/services/resource_registry_service.py — imports database models from infrastructure
application/services/_resource_registry_dag.py, _resource_registry_data.py, _resource_registry_ops.py — all import from infrastructure database models

Total violations: 90+ import statements across 30+ application service files.

Current Behavior

Application layer services directly import concrete infrastructure classes:

# application/services/actor_service.py
from cleveragents.infrastructure.database.unit_of_work import UnitOfWork
from cleveragents.infrastructure.events.models import DomainEvent
from cleveragents.infrastructure.events.types import EventType

# application/services/resource_handler_service.py
from cleveragents.infrastructure.sandbox.factory import SandboxStrategyStr
from cleveragents.infrastructure.sandbox.manager import SandboxManager

This creates tight coupling between the application and infrastructure layers, making it impossible to swap infrastructure implementations without modifying application code.

Expected Behavior

The application layer should depend only on abstract protocols/interfaces defined in the domain or application layer itself. Infrastructure implementations should be injected via dependency injection (already used in container.py), not imported directly.

# application/services/actor_service.py — correct pattern
from cleveragents.application.protocols import UnitOfWorkProtocol, EventBusProtocol
# Infrastructure implementations injected via DI container, not imported

Events (DomainEvent, EventType) and database models that are used by the application layer should either be moved to the domain layer or have protocol abstractions defined in the application layer.

Acceptance Criteria

No file under src/cleveragents/application/ contains a top-level from cleveragents.infrastructure import
No file under src/cleveragents/domain/ contains any from cleveragents.infrastructure import
Infrastructure-specific types used by application services are replaced with protocol/abstract interfaces
DomainEvent and EventType are either moved to the domain layer or abstracted behind a protocol
Database model types (LockModel, AuditLogModel, etc.) used in application services are replaced with domain entities or DTOs
All existing Behave scenarios continue to pass after refactoring
Coverage remains ≥ 97%

Supporting Information

Scan date: 2026-04-18
Scan tool: Architecture Guard Worker (automated)
Pattern: Clean Architecture — application layer must not depend on infrastructure layer
Reference: src/cleveragents/application/ (30+ files affected)
The container.py already uses DI correctly for wiring — the issue is that individual service files bypass DI and import infrastructure directly

Subtasks

Audit all 30+ affected application service files and catalogue every infrastructure import
Identify which infrastructure types need protocol abstractions vs. which should be moved to domain
Create protocol interfaces in application/protocols/ or domain/ for UnitOfWork, EventBus, SandboxManager, etc.
Move DomainEvent and EventType to domain/events/ or create domain-layer abstractions
Replace direct infrastructure model imports (LockModel, AuditLogModel, etc.) with domain entities
Update container.py to wire the new protocols to their infrastructure implementations
Remove all from cleveragents.infrastructure imports from application/ files
Tests (Behave): Add architecture boundary enforcement scenario to features/architecture.feature
Verify coverage ≥ 97% via nox -s coverage_report
Run nox (all default sessions), fix any errors

Definition of Done

This issue is complete when:

All subtasks above are completed and checked off.
No file under src/cleveragents/application/ or src/cleveragents/domain/ imports from cleveragents.infrastructure.
A Git commit is created where the first line matches the Commit Message in Metadata exactly, followed by a blank line, then additional details.
The commit is pushed to the branch matching the Branch in Metadata exactly.
The commit is submitted as a pull request to master, reviewed, and merged before this issue is marked done.

Automated by Architecture Guard Worker — scan date 2026-04-18

Automated by CleverAgents Bot
Agent: new-issue-creator

## Metadata - **Commit message:** `refactor(application): remove direct infrastructure imports from application layer services` - **Branch name:** `feature/refactor-application-layer-boundary` ## Background and Context The application layer (`src/cleveragents/application/`) is directly importing from the infrastructure layer (`src/cleveragents/infrastructure/`), violating clean architecture's dependency rule. In a properly layered architecture, the application layer should depend only on domain abstractions (interfaces/protocols), not on concrete infrastructure implementations. This was detected by an automated architecture guard scan on 2026-04-18. **Affected files (representative sample — 30+ files total):** - `application/container.py` — 8 direct infrastructure imports at module level + 6 more inside functions - `application/services/plan_lifecycle_service.py` — imports `DomainEvent`, `EventType` from infrastructure - `application/services/checkpoint_service.py` — imports from `infrastructure.database.repositories` - `application/services/actor_service.py` — imports `UnitOfWork` from infrastructure directly - `application/services/context_service.py` — imports `UnitOfWork` from infrastructure - `application/services/plan_service.py` — imports `UnitOfWork` from infrastructure - `application/services/resource_handler_service.py` — imports `SandboxManager`, `SandboxStrategyStr` from infrastructure - `application/services/audit_service.py` — imports `AuditLogModel`, `Base` from infrastructure database models - `application/services/lock_service.py` — imports `LockModel` from infrastructure database models - `application/services/repo_indexing_service.py` — imports database models from infrastructure - `application/services/resource_registry_service.py` — imports database models from infrastructure - `application/services/_resource_registry_dag.py`, `_resource_registry_data.py`, `_resource_registry_ops.py` — all import from infrastructure database models **Total violations:** 90+ import statements across 30+ application service files. ## Current Behavior Application layer services directly import concrete infrastructure classes: ```python # application/services/actor_service.py from cleveragents.infrastructure.database.unit_of_work import UnitOfWork from cleveragents.infrastructure.events.models import DomainEvent from cleveragents.infrastructure.events.types import EventType # application/services/resource_handler_service.py from cleveragents.infrastructure.sandbox.factory import SandboxStrategyStr from cleveragents.infrastructure.sandbox.manager import SandboxManager ``` This creates tight coupling between the application and infrastructure layers, making it impossible to swap infrastructure implementations without modifying application code. ## Expected Behavior The application layer should depend only on abstract protocols/interfaces defined in the domain or application layer itself. Infrastructure implementations should be injected via dependency injection (already used in `container.py`), not imported directly. ```python # application/services/actor_service.py — correct pattern from cleveragents.application.protocols import UnitOfWorkProtocol, EventBusProtocol # Infrastructure implementations injected via DI container, not imported ``` Events (`DomainEvent`, `EventType`) and database models that are used by the application layer should either be moved to the domain layer or have protocol abstractions defined in the application layer. ## Acceptance Criteria - [ ] No file under `src/cleveragents/application/` contains a top-level `from cleveragents.infrastructure` import - [ ] No file under `src/cleveragents/domain/` contains any `from cleveragents.infrastructure` import - [ ] Infrastructure-specific types used by application services are replaced with protocol/abstract interfaces - [ ] `DomainEvent` and `EventType` are either moved to the domain layer or abstracted behind a protocol - [ ] Database model types (`LockModel`, `AuditLogModel`, etc.) used in application services are replaced with domain entities or DTOs - [ ] All existing Behave scenarios continue to pass after refactoring - [ ] Coverage remains ≥ 97% ## Supporting Information - Scan date: 2026-04-18 - Scan tool: Architecture Guard Worker (automated) - Pattern: Clean Architecture — application layer must not depend on infrastructure layer - Reference: `src/cleveragents/application/` (30+ files affected) - The `container.py` already uses DI correctly for wiring — the issue is that individual service files bypass DI and import infrastructure directly ## Subtasks - [ ] Audit all 30+ affected application service files and catalogue every infrastructure import - [ ] Identify which infrastructure types need protocol abstractions vs. which should be moved to domain - [ ] Create protocol interfaces in `application/protocols/` or `domain/` for `UnitOfWork`, `EventBus`, `SandboxManager`, etc. - [ ] Move `DomainEvent` and `EventType` to `domain/events/` or create domain-layer abstractions - [ ] Replace direct infrastructure model imports (`LockModel`, `AuditLogModel`, etc.) with domain entities - [ ] Update `container.py` to wire the new protocols to their infrastructure implementations - [ ] Remove all `from cleveragents.infrastructure` imports from `application/` files - [ ] Tests (Behave): Add architecture boundary enforcement scenario to `features/architecture.feature` - [ ] Verify coverage ≥ 97% via `nox -s coverage_report` - [ ] Run `nox` (all default sessions), fix any errors ## Definition of Done This issue is complete when: - All subtasks above are completed and checked off. - No file under `src/cleveragents/application/` or `src/cleveragents/domain/` imports from `cleveragents.infrastructure`. - A Git commit is created where the first line matches the Commit Message in Metadata exactly, followed by a blank line, then additional details. - The commit is pushed to the branch matching the Branch in Metadata exactly. - The commit is submitted as a pull request to `master`, reviewed, and merged before this issue is marked done. --- *Automated by Architecture Guard Worker — scan date 2026-04-18* --- **Automated by CleverAgents Bot** Agent: new-issue-creator

HAL9000 added the

labels

2026-04-18 08:08:57 +00:00

HAL9000 added this to the v3.5.0 milestone

2026-04-18 08:13:54 +00:00

HAL9000 commented

2026-04-18 08:15:26 +00:00

Author

Owner

[GROOMED] Quality Analysis Complete

Issue Assessment

✅ Valid & Actionable: This is a legitimate architectural issue detected by the Architecture Guard Worker. The issue describes a real violation of clean architecture principles where the application layer directly imports from the infrastructure layer.

Label Verification

✅ All Required Labels Present:

State/Unverified — Correctly set (issue needs human verification before work begins)
Type/Refactor — Correctly classified (this is a code restructuring task)
Priority/High — Appropriately set (affects core architecture across 30+ files)

Milestone Assignment

✅ Assigned to M6 v3.5.0 (Autonomy Hardening) — This foundational architecture refactoring is critical for system reliability and autonomy. Clean architecture boundaries must be enforced before the system can reliably execute complex autonomous tasks.

Epic Verification

ℹ️ No Epic Parent Found — This issue stands alone as a technical debt/quality improvement task. It is not part of a larger epic but is a foundational refactoring that benefits the entire system.

Issue Quality

✅ Well-Structured:

Clear background and context
Detailed acceptance criteria (6 checkpoints)
Comprehensive subtasks (10 items)
Definition of Done is explicit
Affected files clearly documented (30+ files, 90+ violations)

Grooming Summary

Aspect	Status	Notes
Validity	✅ Valid	Real architectural violation
Labels	✅ Complete	State/, Type/, Priority/ all present
Milestone	✅ Assigned	M6 v3.5.0 (Autonomy Hardening)
Epic	ℹ️ None	Standalone technical debt task
Assignee	ℹ️ Unassigned	Ready for team assignment
Actionability	✅ High	Clear scope and acceptance criteria

Recommendation

Ready for Verification — This issue is well-groomed and ready for human verification (State/Unverified → State/Verified). Once verified, it can be assigned to a developer for implementation.

Automated by CleverAgents Bot
Supervisor: Grooming | Agent: grooming-pool-supervisor

## [GROOMED] Quality Analysis Complete ### Issue Assessment ✅ **Valid & Actionable**: This is a legitimate architectural issue detected by the Architecture Guard Worker. The issue describes a real violation of clean architecture principles where the application layer directly imports from the infrastructure layer. ### Label Verification ✅ **All Required Labels Present**: - **State/Unverified** — Correctly set (issue needs human verification before work begins) - **Type/Refactor** — Correctly classified (this is a code restructuring task) - **Priority/High** — Appropriately set (affects core architecture across 30+ files) ### Milestone Assignment ✅ **Assigned to M6 v3.5.0 (Autonomy Hardening)** — This foundational architecture refactoring is critical for system reliability and autonomy. Clean architecture boundaries must be enforced before the system can reliably execute complex autonomous tasks. ### Epic Verification ℹ️ **No Epic Parent Found** — This issue stands alone as a technical debt/quality improvement task. It is not part of a larger epic but is a foundational refactoring that benefits the entire system. ### Issue Quality ✅ **Well-Structured**: - Clear background and context - Detailed acceptance criteria (6 checkpoints) - Comprehensive subtasks (10 items) - Definition of Done is explicit - Affected files clearly documented (30+ files, 90+ violations) ### Grooming Summary | Aspect | Status | Notes | |--------|--------|-------| | Validity | ✅ Valid | Real architectural violation | | Labels | ✅ Complete | State/, Type/, Priority/ all present | | Milestone | ✅ Assigned | M6 v3.5.0 (Autonomy Hardening) | | Epic | ℹ️ None | Standalone technical debt task | | Assignee | ℹ️ Unassigned | Ready for team assignment | | Actionability | ✅ High | Clear scope and acceptance criteria | ### Recommendation **Ready for Verification** — This issue is well-groomed and ready for human verification (State/Unverified → State/Verified). Once verified, it can be assigned to a developer for implementation. --- **Automated by CleverAgents Bot** Supervisor: Grooming | Agent: grooming-pool-supervisor

HAL9000 referenced this issue

2026-04-18 08:51:02 +00:00

[AUTO-GUARD] Architecture Guard Status — Cycle 4 #10287

HAL9000 referenced this issue

2026-04-18 08:58:14 +00:00

[AUTO-ARCH] Architecture Supervisor — Cycle 1 Status (2026-04-18) #10350

HAL9000 referenced this issue

2026-04-18 09:13:33 +00:00

[AUTO-GUARD] Architecture Guard Status — Cycle 5 #10366

HAL9000 added

State

Verified