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

New issue

Open

opened 2026-08-10 22:19:49 +00:00 by CoreRasurae · 0 comments

CoreRasurae commented

2026-08-10 22:19:49 +00:00

Member

Copy link

Metadata

Commit Message: test(registry): add failing regression for missing content fetch after registry resolve (#135)
Branch: tdd/m1-registry-content-fetch

Background and context

Companion TDD issue for #135 ("PackageContentResolver never fetches package content for REGISTRY references — agents./skills:/routes. get the §8.2.2 stub instead of real config"). Per this project's mandatory Bug Fix TDD workflow, a failing Behave scenario proving the bug exists must be written and merged to master before any fix is implemented on a bugfix/ branch for #135.

The defect: PackageContentResolver._resolve_registry_async (src/cleveractors/registry/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.

Current behavior

No Behave scenario asserts that PackageContentResolver.resolve()/aresolve() for a REGISTRY reference returns real package content. Nothing proves that a resolved agent-type (or skill-type) package's type/config fields — as opposed to the §8.2.2 stub's package-type-name type field — are present in the dict handed back to callers such as AgentFactory.acreate_agent.

Expected behavior

A Behave scenario exists, tagged @tdd_issue @tdd_issue_135 @tdd_expected_fail, that:

Configures a mock registry transport where GET /{package_type}/{ns}/{name} (§8.2.2) returns {"package_id": "pkg_agt_...", "type": "agent"} and GET /packages/{package_id} (§8.2.1) returns {"content": "name: worker\ntype: llm\nprovider: openai_compatible\n..."}.
Resolves a REGISTRY-scheme reference for that package through PackageContentResolver.resolve() (or aresolve()).
Asserts the returned dict's type field is "llm" (the real agent's type, from the §8.2.1 content) — not "agent" (the §8.2.2 stub's package-type field).
The assertion currently fails, because the bug is present (the stub's type: "agent" is returned unchanged, and GET /packages/{package_id} is never even requested) — the scenario passes in CI only because the @tdd_expected_fail tag inverts the result, per this project's TDD tag rules.
The failing step raises/asserts via AssertionError only — never ValueError, RuntimeError, or any other exception type — so the TDD CI hook inverts it correctly.

Acceptance criteria

The scenario carries all three required tags: @tdd_issue, @tdd_issue_135, @tdd_expected_fail.
The scenario's failing step raises/asserts via AssertionError only.
Running the scenario's assertion with @tdd_expected_fail removed locally fails against current master, confirming the bug is genuinely reproduced (the mock's GET /packages/{package_id} endpoint is never hit).
nox -s unit_tests is green (CI passes via the @tdd_expected_fail inversion).
Coverage stays >= 97% (nox -s coverage_report).
The scenario is merged to master via its own PR before work begins on #135's fix.

Supporting information

Bug issue: #135.
Relevant code: cleveractors.registry.reference_resolver (_RegistryReferenceStrategy, PackageContentResolver._resolve_registry_async), cleveractors.registry.client.RegistryClient.get_package/.resolve_package, cleveractors.registry.cache.RegistryCache.get_package/.resolve_package.
Existing mock transport for the registry HTTP client used by features/registry_http_client.feature / features/steps/registry_http_client_steps.py — extend rather than duplicate.
Spec: docs/actor-registry-standard.md §8.2.1/§8.2.2; docs/index.md §4.1.1; docs/adr/ADR-2037-agent-and-route-package-reference-resolution.md D-3.
Forgejo dependency: #135 depends on this issue (this issue blocks #135), per this project's TDD-before-fix workflow.

Subtasks

Write a Behave scenario (in features/registry_http_client.feature, alongside the existing registry-resolution coverage) that mocks both the §8.2.2 resolve response and the §8.2.1 get-package response, and asserts the resolved content reflects the §8.2.1 payload.
Implement any missing step definitions, extending the existing shared features/steps/registry_http_client_steps.py file rather than creating a new one.
Tag the scenario @tdd_issue @tdd_issue_135 @tdd_expected_fail.
Confirm the scenario's assertion fails when @tdd_expected_fail is removed locally (proving the bug), and passes CI with the tag in place.
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.
A Git commit is created where the first line matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant 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.
This TDD issue is closed, with #135 depending on it (Forgejo dependency set after creation).

## Metadata - **Commit Message:** `test(registry): add failing regression for missing content fetch after registry resolve (#135)` - **Branch:** `tdd/m1-registry-content-fetch` ## Background and context Companion TDD issue for #135 ("PackageContentResolver never fetches package content for REGISTRY references — agents.<name>/skills:/routes.<name> get the §8.2.2 stub instead of real config"). Per this project's mandatory Bug Fix TDD workflow, a failing Behave scenario proving the bug exists must be written and merged to `master` before any fix is implemented on a `bugfix/` branch for #135. The defect: `PackageContentResolver._resolve_registry_async` (`src/cleveractors/registry/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. ## Current behavior No Behave scenario asserts that `PackageContentResolver.resolve()`/`aresolve()` for a REGISTRY reference returns real package content. Nothing proves that a resolved `agent`-type (or `skill`-type) package's `type`/`config` fields — as opposed to the §8.2.2 stub's package-type-name `type` field — are present in the dict handed back to callers such as `AgentFactory.acreate_agent`. ## Expected behavior A Behave scenario exists, tagged `@tdd_issue @tdd_issue_135 @tdd_expected_fail`, that: - Configures a mock registry transport where `GET /{package_type}/{ns}/{name}` (§8.2.2) returns `{"package_id": "pkg_agt_...", "type": "agent"}` and `GET /packages/{package_id}` (§8.2.1) returns `{"content": "name: worker\ntype: llm\nprovider: openai_compatible\n..."}`. - Resolves a REGISTRY-scheme reference for that package through `PackageContentResolver.resolve()` (or `aresolve()`). - Asserts the returned dict's `type` field is `"llm"` (the real agent's type, from the §8.2.1 content) — not `"agent"` (the §8.2.2 stub's package-type field). - The assertion currently fails, because the bug is present (the stub's `type: "agent"` is returned unchanged, and `GET /packages/{package_id}` is never even requested) — the scenario passes in CI only because the `@tdd_expected_fail` tag inverts the result, per this project's TDD tag rules. - The failing step raises/asserts via `AssertionError` only — never `ValueError`, `RuntimeError`, or any other exception type — so the TDD CI hook inverts it correctly. ## Acceptance criteria - [ ] The scenario carries all three required tags: `@tdd_issue`, `@tdd_issue_135`, `@tdd_expected_fail`. - [ ] The scenario's failing step raises/asserts via `AssertionError` only. - [ ] Running the scenario's assertion with `@tdd_expected_fail` removed locally fails against current `master`, confirming the bug is genuinely reproduced (the mock's `GET /packages/{package_id}` endpoint is never hit). - [ ] `nox -s unit_tests` is green (CI passes via the `@tdd_expected_fail` inversion). - [ ] Coverage stays >= 97% (`nox -s coverage_report`). - [ ] The scenario is merged to `master` via its own PR before work begins on #135's fix. ## Supporting information - Bug issue: #135. - Relevant code: `cleveractors.registry.reference_resolver` (`_RegistryReferenceStrategy`, `PackageContentResolver._resolve_registry_async`), `cleveractors.registry.client.RegistryClient.get_package`/`.resolve_package`, `cleveractors.registry.cache.RegistryCache.get_package`/`.resolve_package`. - Existing mock transport for the registry HTTP client used by `features/registry_http_client.feature` / `features/steps/registry_http_client_steps.py` — extend rather than duplicate. - Spec: `docs/actor-registry-standard.md` §8.2.1/§8.2.2; `docs/index.md` §4.1.1; `docs/adr/ADR-2037-agent-and-route-package-reference-resolution.md` D-3. - Forgejo dependency: #135 depends on this issue (this issue blocks #135), per this project's TDD-before-fix workflow. ## Subtasks - [ ] Write a Behave scenario (in `features/registry_http_client.feature`, alongside the existing registry-resolution coverage) that mocks both the §8.2.2 resolve response and the §8.2.1 get-package response, and asserts the resolved content reflects the §8.2.1 payload. - [ ] Implement any missing step definitions, extending the existing shared `features/steps/registry_http_client_steps.py` file rather than creating a new one. - [ ] Tag the scenario `@tdd_issue @tdd_issue_135 @tdd_expected_fail`. - [ ] Confirm the scenario's assertion fails when `@tdd_expected_fail` is removed locally (proving the bug), and passes CI with the tag in place. - [ ] 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. - A Git commit is created where the first line matches the Commit Message in Metadata exactly, followed by a blank line, then additional lines providing relevant 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. - This TDD issue is closed, with #135 depending on it (Forgejo dependency set after creation).

CoreRasurae added the

labels

2026-08-10 22:19:49 +00:00

CoreRasurae added a new dependency

2026-08-10 22:22:24 +00:00

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