cleveragents/cleveractors-core

Fork 0

test(registry): add failing regression for missing content fetch after registry resolve (#135) #137

Open

CoreRasurae wants to merge 1 commit from tdd/m1-registry-content-fetch into master

CoreRasurae commented

2026-08-20 18:58:28 +00:00

Member

Summary

Companion TDD issue for #135. Adds a Behave scenario proving PackageContentResolver._resolve_registry_async (src/cleveractors/registry/reference_resolver.py) never performs the Package Registry Standard §8.2.1 GET /packages/{package_id} fetch for REGISTRY-scheme references — it returns the §8.2.2 resolve stub ({"package_id": ..., "type": "agent"}) directly as if it were the resolved package content, instead of the real package payload (type: llm, etc.) that docs/index.md §4.1.1 and ADR-2037 D-3 require.

The new scenario mocks both the §8.2.2 resolve endpoint and the §8.2.1 get-package endpoint behind distinct request paths, resolves an agent registry reference through PackageContentResolver.resolve(), and asserts the returned content's type field is "llm" (not "agent") and that the get-package endpoint was actually requested. Confirmed locally that both assertions fail with AssertionError when @tdd_expected_fail is removed.

Test plan

nox -s lint green
nox -s format -- --check green
nox -s typecheck green
nox -s security_scan green
nox -s dead_code green
nox -s unit_tests green (3084 scenarios, scenario passes via @tdd_expected_fail inversion)
nox -s integration_tests green (362 Robot tests, unaffected)
nox -s coverage_report green (96.9% >= 96.5% threshold)
Confirmed locally that removing @tdd_expected_fail makes the scenario fail for real

Closes #136

## Summary Companion TDD issue for #135. Adds a Behave scenario proving `PackageContentResolver._resolve_registry_async` (`src/cleveractors/registry/reference_resolver.py`) never performs the Package Registry Standard §8.2.1 `GET /packages/{package_id}` fetch for REGISTRY-scheme references — it returns the §8.2.2 resolve stub (`{"package_id": ..., "type": "agent"}`) directly as if it were the resolved package content, instead of the real package payload (`type: llm`, etc.) that `docs/index.md` §4.1.1 and ADR-2037 D-3 require. The new scenario mocks both the §8.2.2 resolve endpoint and the §8.2.1 get-package endpoint behind distinct request paths, resolves an `agent` registry reference through `PackageContentResolver.resolve()`, and asserts the returned content's `type` field is `"llm"` (not `"agent"`) and that the get-package endpoint was actually requested. Confirmed locally that both assertions fail with `AssertionError` when `@tdd_expected_fail` is removed. ## Test plan - [x] `nox -s lint` green - [x] `nox -s format -- --check` green - [x] `nox -s typecheck` green - [x] `nox -s security_scan` green - [x] `nox -s dead_code` green - [x] `nox -s unit_tests` green (3084 scenarios, scenario passes via `@tdd_expected_fail` inversion) - [x] `nox -s integration_tests` green (362 Robot tests, unaffected) - [x] `nox -s coverage_report` green (96.9% >= 96.5% threshold) - [x] Confirmed locally that removing `@tdd_expected_fail` makes the scenario fail for real Closes #136

CoreRasurae added this to the v2.1.0 milestone

2026-08-20 18:58:29 +00:00

CoreRasurae added 1 commit

2026-08-20 18:58:32 +00:00

test(registry): add failing regression for missing content fetch after registry resolve (#135 )

CI / lint (pull_request) Successful in 45s

Details

CI / typecheck (pull_request) Successful in 1m36s

Details

CI / quality (pull_request) Successful in 48s

Details

CI / security (pull_request) Successful in 2m38s

Details

CI / build (pull_request) Successful in 2m3s

Details

CI / integration_tests (pull_request) Successful in 3m54s

Details

CI / unit_tests (pull_request) Successful in 5m8s

Details

CI / coverage (pull_request) Failing after 14m53s

Details

CI / benchmark (pull_request) Failing after 19m22s

Details

CI / status-check (pull_request) Has been cancelled

Details

cb4fc5186f

PackageContentResolver._resolve_registry_async (reference_resolver.py)
only performs the Package Registry Standard §8.2.2 "resolve" call
(GET /{package_type}/{namespace}/{name} -> {"package_id", "type"}) and
returns that stub directly as if it were the resolved package content.
It never performs the required §8.2.1 "get package by ID" call
(GET /packages/{package_id} -> {"content": "<YAML string>"}) to fetch
and parse the actual package payload, so a REGISTRY-scheme agents.<name>
reference ends up with type: "agent" (the resolve stub's package-type
field) instead of the real package's type: "llm", per docs/index.md
§4.1.1 and ADR-2037 D-3.

Adds a new scenario to features/registry_http_client.feature (extending
the existing shared registry_http_client_steps.py rather than a new
step file) that mocks both the §8.2.2 resolve response and the §8.2.1
get-package response behind distinct paths, resolves an "agent"
registry reference through PackageContentResolver.resolve(), and
asserts the returned content's "type" field is "llm" (from the real
package) and that the get_package endpoint was actually requested.
Confirmed locally that both assertions fail with AssertionError when
@tdd_expected_fail is removed, proving the bug is genuinely reproduced;
with the tag present, the TDD policy inverts the failure so
nox -s unit_tests stays green.

ISSUES CLOSED: #136

CoreRasurae added the

Type

Testing

label

2026-08-20 18:59:12 +00:00

CoreRasurae added a new dependency

2026-08-20 18:59:35 +00:00

#136 TDD: PackageContentResolver never fetches package content for REGISTRY references — agents.<name>/skills:/routes.<name> get the §8.2.2 stub instead of real config

CoreRasurae referenced this pull request

2026-08-20 21:39:42 +00:00

fix(registry): fetch and parse package content for resolved registry references #138

hurui200320 approved these changes

2026-08-22 06:21:38 +00:00

hurui200320 left a comment

PR Review: !137 (Ticket #136)

Verdict: Approve

This PR adds a focused, well-structured TDD regression scenario that correctly captures the missing §8.2.1 content-fetch bug described in #135. The scenario mocks both the resolve endpoint and the get-package endpoint, asserts that PackageContentResolver.resolve() returns the real package content (type: llm) rather than the §8.2.2 stub (type: agent), and verifies that the content endpoint is actually requested. The required tag combination @tdd_issue @tdd_issue_135 @tdd_expected_fail is present, and the failing assertions raise AssertionError, so the TDD expected-fail inversion policy will handle them correctly. No critical or major issues were found.

Critical Issues

None

Major Issues

None

Minor Issues

None

Nits

None

Summary

The changes extend the existing features/registry_http_client.feature and features/steps/registry_http_client_steps.py rather than duplicating them, the step definitions are clean and reuse existing mock helpers, and the test genuinely reproduces the bug on current master. Approved.

## PR Review: !137 (Ticket #136) ### Verdict: Approve This PR adds a focused, well-structured TDD regression scenario that correctly captures the missing §8.2.1 content-fetch bug described in #135. The scenario mocks both the resolve endpoint and the get-package endpoint, asserts that `PackageContentResolver.resolve()` returns the real package content (`type: llm`) rather than the §8.2.2 stub (`type: agent`), and verifies that the content endpoint is actually requested. The required tag combination `@tdd_issue @tdd_issue_135 @tdd_expected_fail` is present, and the failing assertions raise `AssertionError`, so the TDD expected-fail inversion policy will handle them correctly. No critical or major issues were found. ### Critical Issues None ### Major Issues None ### Minor Issues None ### Nits None ### Summary The changes extend the existing `features/registry_http_client.feature` and `features/steps/registry_http_client_steps.py` rather than duplicating them, the step definitions are clean and reuse existing mock helpers, and the test genuinely reproduces the bug on current `master`. Approved.

CI / lint (pull_request) Successful in 45s

Details

CI / typecheck (pull_request) Successful in 1m36s

Details

CI / quality (pull_request) Successful in 48s

Details

CI / security (pull_request) Successful in 2m38s

Details

CI / build (pull_request) Successful in 2m3s

Details

CI / integration_tests (pull_request) Successful in 3m54s

Details

CI / unit_tests (pull_request) Successful in 5m8s

Details

CI / coverage (pull_request) Failing after 14m53s

Details

CI / benchmark (pull_request) Failing after 19m22s

Details

CI / status-check (pull_request) Has been cancelled

Details

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin tdd/m1-registry-content-fetch:tdd/m1-registry-content-fetch

git switch tdd/m1-registry-content-fetch

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master

git merge --no-ff tdd/m1-registry-content-fetch

git switch tdd/m1-registry-content-fetch

git rebase master

git switch master

git merge --ff-only tdd/m1-registry-content-fetch

git switch tdd/m1-registry-content-fetch

git rebase master

git switch master

git merge --no-ff tdd/m1-registry-content-fetch

git switch master

git merge --squash tdd/m1-registry-content-fetch