cleveragents/cleveragents-core

Fork 3

UAT: `DefaultDepthResolver` is a no-op — named depth levels from `ContextRequest.depth` are never resolved to integers before fragment assembly #2402

New issue

Open

opened 2026-04-03 17:33:33 +00:00 by freemo · 1 comment

freemo commented

2026-04-03 17:33:33 +00:00

Owner

Metadata

Branch: fix/acms-depth-resolver-noop
Commit Message: fix(acms): implement DefaultDepthResolver to resolve named depth levels from ContextRequest
Milestone: v3.4.0
Parent Epic: #396

Description

The ACMS pipeline's Phase 2 DetailDepthResolver component is responsible for resolving named depth levels (e.g., "SIGNATURES", "FULL_SOURCE") from the ContextRequest to integer depths. The DefaultDepthResolver implementation is a no-op that returns fragments unchanged, and the pipeline never passes the ContextRequest.depth field to the resolver.

Problematic Code

src/cleveragents/application/services/acms_service.py — DefaultDepthResolver:

class DefaultDepthResolver:
    """No-op depth resolver — returns fragments unchanged."""
    def resolve(
        self,
        fragments: Sequence[ContextFragment],
        budget: int = 0,
    ) -> Sequence[ContextFragment]:
        return fragments  # ← always returns unchanged

ACMSPipeline.assemble() — Phase 2 Fragment Fusion:

# Phase 2: Fragment Fusion pipeline
fused = self._deduplicator.deduplicate(ranked)
fused = self._depth_resolver.resolve(fused, budget.available_tokens)
# ← ContextRequest.depth is never passed to the resolver

src/cleveragents/domain/models/acms/crp.py — ContextRequest.depth:

depth: DetailDepth = Field(
    default=3,
    description="How much detail to include. May be a raw integer (0-N) or a named level string (e.g., 'SIGNATURES') resolved via the active DetailLevelMap."
)

Impact

When an actor requests context at depth "SIGNATURES" (a named level), the ContextRequest.depth is never resolved to an integer and never used to filter or adjust fragment depths.
Fragments at higher detail depths than requested are included in the assembled context, wasting token budget on unnecessary detail.
The ContextRequest.depth_gradient field (per-hop depth overrides) is also never applied — all fragments receive the same depth regardless of their distance from focus nodes.
The spec requires the DetailDepthResolver to "resolve detail depth levels" as part of the Fragment Fusion phase (spec §42638-42646), but the default implementation is explicitly documented as a no-op.

Expected Behavior (per spec §42638-42646)

The DetailDepthResolver should:

Accept the ContextRequest.depth (integer or named level string) and resolve it using the fragment's domain DetailLevelMap.
Filter or re-render fragments to match the requested depth level.
Apply ContextRequest.depth_gradient to assign different depths to fragments at different hop distances from focus nodes.

Actual Behavior

DefaultDepthResolver.resolve() returns fragments unchanged. Named depth levels from ContextRequest.depth are never resolved. ContextRequest.depth_gradient is never applied. The pipeline assembles fragments at whatever depth they were originally created, regardless of what the actor requested.

Code Locations

src/cleveragents/application/services/acms_service.py — DefaultDepthResolver class and ACMSPipeline.assemble() Phase 2
src/cleveragents/domain/models/acms/crp.py — ContextRequest.depth and ContextRequest.depth_gradient fields
src/cleveragents/domain/models/acms/detail_level.py — DetailLevelMap.resolve() (exists but never called from pipeline)

Subtasks

Update DefaultDepthResolver.resolve() signature to accept ContextRequest (or at minimum depth and depth_gradient parameters)
Implement named depth level resolution in DefaultDepthResolver using DetailLevelMap.resolve() from detail_level.py
Implement integer depth filtering/re-rendering of ContextFragment objects to match the resolved depth level
Implement depth_gradient application — assign per-hop depth overrides to fragments based on their distance from focus nodes
Update ACMSPipeline.assemble() Phase 2 to pass ContextRequest.depth and ContextRequest.depth_gradient to self._depth_resolver.resolve()
Tests (Behave): Add scenarios for DefaultDepthResolver with named depth levels (e.g., "SIGNATURES", "FULL_SOURCE")
Tests (Behave): Add scenarios for DefaultDepthResolver with integer depth values
Tests (Behave): Add scenarios for depth_gradient application across hop distances
Tests (Behave): Add scenario verifying ACMSPipeline.assemble() passes ContextRequest.depth to the resolver
Tests (Robot): Add integration test verifying assembled context respects the requested depth level end-to-end
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.
DefaultDepthResolver.resolve() correctly resolves named depth level strings to integers via DetailLevelMap.resolve() and filters/re-renders fragments accordingly.
ACMSPipeline.assemble() passes ContextRequest.depth and ContextRequest.depth_gradient to the depth resolver in Phase 2.
ContextRequest.depth_gradient per-hop overrides are applied to fragments at the correct hop distances.
A Git commit is created where the first line of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation.
The commit is pushed to the remote on 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.
All nox stages pass.
Coverage >= 97%.

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

## Metadata - **Branch**: `fix/acms-depth-resolver-noop` - **Commit Message**: `fix(acms): implement DefaultDepthResolver to resolve named depth levels from ContextRequest` - **Milestone**: v3.4.0 - **Parent Epic**: #396 ## Description The ACMS pipeline's Phase 2 `DetailDepthResolver` component is responsible for resolving named depth levels (e.g., `"SIGNATURES"`, `"FULL_SOURCE"`) from the `ContextRequest` to integer depths. The `DefaultDepthResolver` implementation is a no-op that returns fragments unchanged, and the pipeline never passes the `ContextRequest.depth` field to the resolver. ### Problematic Code **`src/cleveragents/application/services/acms_service.py`** — `DefaultDepthResolver`: ```python class DefaultDepthResolver: """No-op depth resolver — returns fragments unchanged.""" def resolve( self, fragments: Sequence[ContextFragment], budget: int = 0, ) -> Sequence[ContextFragment]: return fragments # ← always returns unchanged ``` **`ACMSPipeline.assemble()`** — Phase 2 Fragment Fusion: ```python # Phase 2: Fragment Fusion pipeline fused = self._deduplicator.deduplicate(ranked) fused = self._depth_resolver.resolve(fused, budget.available_tokens) # ← ContextRequest.depth is never passed to the resolver ``` **`src/cleveragents/domain/models/acms/crp.py`** — `ContextRequest.depth`: ```python depth: DetailDepth = Field( default=3, description="How much detail to include. May be a raw integer (0-N) or a named level string (e.g., 'SIGNATURES') resolved via the active DetailLevelMap." ) ``` ### Impact 1. When an actor requests context at depth `"SIGNATURES"` (a named level), the `ContextRequest.depth` is never resolved to an integer and never used to filter or adjust fragment depths. 2. Fragments at higher detail depths than requested are included in the assembled context, wasting token budget on unnecessary detail. 3. The `ContextRequest.depth_gradient` field (per-hop depth overrides) is also never applied — all fragments receive the same depth regardless of their distance from focus nodes. 4. The spec requires the `DetailDepthResolver` to "resolve detail depth levels" as part of the Fragment Fusion phase (spec §42638-42646), but the default implementation is explicitly documented as a no-op. ### Expected Behavior (per spec §42638-42646) The `DetailDepthResolver` should: 1. Accept the `ContextRequest.depth` (integer or named level string) and resolve it using the fragment's domain `DetailLevelMap`. 2. Filter or re-render fragments to match the requested depth level. 3. Apply `ContextRequest.depth_gradient` to assign different depths to fragments at different hop distances from focus nodes. ### Actual Behavior `DefaultDepthResolver.resolve()` returns fragments unchanged. Named depth levels from `ContextRequest.depth` are never resolved. `ContextRequest.depth_gradient` is never applied. The pipeline assembles fragments at whatever depth they were originally created, regardless of what the actor requested. ### Code Locations - `src/cleveragents/application/services/acms_service.py` — `DefaultDepthResolver` class and `ACMSPipeline.assemble()` Phase 2 - `src/cleveragents/domain/models/acms/crp.py` — `ContextRequest.depth` and `ContextRequest.depth_gradient` fields - `src/cleveragents/domain/models/acms/detail_level.py` — `DetailLevelMap.resolve()` (exists but never called from pipeline) ## Subtasks - [ ] Update `DefaultDepthResolver.resolve()` signature to accept `ContextRequest` (or at minimum `depth` and `depth_gradient` parameters) - [ ] Implement named depth level resolution in `DefaultDepthResolver` using `DetailLevelMap.resolve()` from `detail_level.py` - [ ] Implement integer depth filtering/re-rendering of `ContextFragment` objects to match the resolved depth level - [ ] Implement `depth_gradient` application — assign per-hop depth overrides to fragments based on their distance from focus nodes - [ ] Update `ACMSPipeline.assemble()` Phase 2 to pass `ContextRequest.depth` and `ContextRequest.depth_gradient` to `self._depth_resolver.resolve()` - [ ] Tests (Behave): Add scenarios for `DefaultDepthResolver` with named depth levels (e.g., `"SIGNATURES"`, `"FULL_SOURCE"`) - [ ] Tests (Behave): Add scenarios for `DefaultDepthResolver` with integer depth values - [ ] Tests (Behave): Add scenarios for `depth_gradient` application across hop distances - [ ] Tests (Behave): Add scenario verifying `ACMSPipeline.assemble()` passes `ContextRequest.depth` to the resolver - [ ] Tests (Robot): Add integration test verifying assembled context respects the requested depth level end-to-end - [ ] 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. - `DefaultDepthResolver.resolve()` correctly resolves named depth level strings to integers via `DetailLevelMap.resolve()` and filters/re-renders fragments accordingly. - `ACMSPipeline.assemble()` passes `ContextRequest.depth` and `ContextRequest.depth_gradient` to the depth resolver in Phase 2. - `ContextRequest.depth_gradient` per-hop overrides are applied to fragments at the correct hop distances. - A Git commit is created where the **first line** of the commit message matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant details about the implementation. - The commit is pushed to the remote on 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. - All nox stages pass. - Coverage >= 97%. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-uat-tester

freemo added this to the v3.4.0 milestone

2026-04-03 17:33:38 +00:00

freemo added a new dependency

2026-04-03 17:34:28 +00:00

#396 Epic: ACMS Context Pipeline

freemo referenced this issue

2026-04-03 17:35:14 +00:00

[CA-AUTO] UAT Pool Supervisor — v3.6.0 — Session Tracker #2360

freemo referenced this issue

2026-04-03 17:42:38 +00:00

[UAT-SUPERVISOR] Progress Report — Cycle 1511 — v3.7.0 #2421

freemo referenced this issue

2026-04-03 17:52:45 +00:00

[UAT-SUPERVISOR] Progress Report — Cycle 1521 — v3.7.0 #2422

freemo referenced this issue

2026-04-03 18:02:52 +00:00

[UAT-SUPERVISOR] Progress Report — Cycle 1531 — v3.7.0 #2433

freemo referenced this issue

2026-04-03 18:12:59 +00:00

[UAT-SUPERVISOR] Progress Report — Cycle 1541 — v3.7.0 #2434

freemo referenced this issue

2026-04-03 18:23:14 +00:00

[UAT-SUPERVISOR] Progress Report — Cycle 1551 — v3.7.0 #2445

freemo commented

2026-04-03 18:24:55 +00:00

Author

Owner

Issue triaged by project owner:

State: Verified
Priority: Medium — The DefaultDepthResolver being a no-op means named depth levels are never resolved, so fragment assembly uses unresolved depth values. This breaks the ACMS depth resolution pipeline.
Milestone: v3.4.0
MoSCoW: Must Have — Depth resolution is a core ACMS pipeline phase. Without it, context fragments cannot be assembled at the correct detail level, breaking the context management system.
Parent Epic: #396 (ACMS Context Pipeline)

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

Issue triaged by project owner: - **State**: Verified - **Priority**: Medium — The `DefaultDepthResolver` being a no-op means named depth levels are never resolved, so fragment assembly uses unresolved depth values. This breaks the ACMS depth resolution pipeline. - **Milestone**: v3.4.0 - **MoSCoW**: Must Have — Depth resolution is a core ACMS pipeline phase. Without it, context fragments cannot be assembled at the correct detail level, breaking the context management system. - **Parent Epic**: #396 (ACMS Context Pipeline) --- **Automated by CleverAgents Bot** Supervisor: Project Owner | Agent: ca-project-owner

freemo added the

MoSCoW

Must have

label

2026-04-03 18:25:34 +00:00

freemo removed the

MoSCoW

Must have

label

2026-04-05 04:09:33 +00:00

freemo removed this from the v3.4.0 milestone

2026-04-06 21:01:27 +00:00