UAT: `agents validation attach` does not validate that the target resource exists #3881

New issue

Open

opened 2026-04-06 07:07:43 +00:00 by freemo · 0 comments

freemo commented

2026-04-06 07:07:43 +00:00

Owner

Summary

The agents validation attach <resource> <validation> CLI command passes the resource argument directly to ToolRegistryService.attach_validation() as resource_id without first verifying that the resource exists in the Resource Registry. This means a user can attach a validation to a non-existent resource name (e.g., local/nonexistent) and the attachment will be silently persisted with an invalid resource reference.

Metadata

Branch: fix/validation-attach-resource-check
Commit Message: fix(validation): validate resource existence before attaching validation
Milestone: (backlog — no milestone)
Parent Epic: #397

Subtasks

In agents validation attach CLI command, resolve the resource argument via ResourceRegistryService.show_resource() before calling attach_validation()
If the resource does not exist, print a clear error message and abort
Pass the resolved resource.resource_id (ULID) to attach_validation() instead of the raw string argument
Add BDD scenario: agents validation attach nonexistent-resource local/my-validation fails with "Resource not found"

Definition of Done

agents validation attach <resource> <validation> raises a clear error if <resource> does not exist in the registry
The stored resource_id in ValidationAttachmentModel is always a valid ULID (not a raw name string)
Unit tests (Behave) cover the resource-not-found path
All nox stages pass
Coverage >= 97%

Steps to Reproduce

Code location: src/cleveragents/cli/commands/validation.py, attach() function

@app.command("attach")
def attach(
    resource: Annotated[str, typer.Argument(...)],
    validation_name: Annotated[str, typer.Argument(...)],
    ...
) -> None:
    # ...
    service = _get_tool_registry_service()
    attachment = service.attach_validation(
        validation_name=validation_name,
        resource_id=resource,   # <-- raw string, no existence check!
        ...
    )

Expected behavior:

$ agents validation attach local/nonexistent local/my-validation
Error: Resource not found: local/nonexistent

Actual behavior: The attachment is created successfully with resource_id="local/nonexistent" even though no such resource exists. The ValidationAttachmentModel row stores the raw name string instead of a ULID.

Additional Context

The spec states: "Validations are attached directly to a resource." — this implies the resource must exist
The ResourceRegistryService.show_resource() method already supports lookup by both name and ULID
The ValidationAttachmentRepository.attach() stores resource_id as a string; if a name is passed instead of a ULID, downstream code that looks up attachments by ULID will fail silently
Compare with agents project link-resource which correctly resolves the resource via registry.show_resource() before creating the link

Backlog note: This issue was discovered during autonomous operation
on milestone v3.5.0. It does not block milestone completion and has been
placed in the backlog for human review and future milestone assignment.

Automated by CleverAgents Bot
Supervisor: UAT Testing | Agent: ca-new-issue-creator

## Summary The `agents validation attach <resource> <validation>` CLI command passes the `resource` argument directly to `ToolRegistryService.attach_validation()` as `resource_id` without first verifying that the resource exists in the Resource Registry. This means a user can attach a validation to a non-existent resource name (e.g., `local/nonexistent`) and the attachment will be silently persisted with an invalid resource reference. ## Metadata - **Branch**: `fix/validation-attach-resource-check` - **Commit Message**: `fix(validation): validate resource existence before attaching validation` - **Milestone**: *(backlog — no milestone)* - **Parent Epic**: #397 ## Subtasks - [ ] In `agents validation attach` CLI command, resolve the resource argument via `ResourceRegistryService.show_resource()` before calling `attach_validation()` - [ ] If the resource does not exist, print a clear error message and abort - [ ] Pass the resolved `resource.resource_id` (ULID) to `attach_validation()` instead of the raw string argument - [ ] Add BDD scenario: `agents validation attach nonexistent-resource local/my-validation` fails with "Resource not found" ## Definition of Done - `agents validation attach <resource> <validation>` raises a clear error if `<resource>` does not exist in the registry - The stored `resource_id` in `ValidationAttachmentModel` is always a valid ULID (not a raw name string) - Unit tests (Behave) cover the resource-not-found path - All nox stages pass - Coverage >= 97% ## Steps to Reproduce **Code location:** `src/cleveragents/cli/commands/validation.py`, `attach()` function ```python @app.command("attach") def attach( resource: Annotated[str, typer.Argument(...)], validation_name: Annotated[str, typer.Argument(...)], ... ) -> None: # ... service = _get_tool_registry_service() attachment = service.attach_validation( validation_name=validation_name, resource_id=resource, # <-- raw string, no existence check! ... ) ``` **Expected behavior:** ``` $ agents validation attach local/nonexistent local/my-validation Error: Resource not found: local/nonexistent ``` **Actual behavior:** The attachment is created successfully with `resource_id="local/nonexistent"` even though no such resource exists. The `ValidationAttachmentModel` row stores the raw name string instead of a ULID. ## Additional Context - The spec states: "Validations are attached directly to a resource." — this implies the resource must exist - The `ResourceRegistryService.show_resource()` method already supports lookup by both name and ULID - The `ValidationAttachmentRepository.attach()` stores `resource_id` as a string; if a name is passed instead of a ULID, downstream code that looks up attachments by ULID will fail silently - Compare with `agents project link-resource` which correctly resolves the resource via `registry.show_resource()` before creating the link > **Backlog note:** This issue was discovered during autonomous operation > on milestone v3.5.0. It does not block milestone completion and has been > placed in the backlog for human review and future milestone assignment. --- **Automated by CleverAgents Bot** Supervisor: UAT Testing | Agent: ca-new-issue-creator

freemo added a new dependency

2026-04-06 07:07:54 +00:00

#397 Epic: Server & Autonomy Infrastructure

freemo added the

Points

label

2026-04-06 07:09:30 +00:00

freemo referenced this issue

2026-04-06 07:11:08 +00:00

[Automated] CleverAgents Build Session - 2026-04-06 #3775

freemo referenced this issue

2026-04-06 07:21:26 +00:00