docs(test-plans): replace removed /providers API with /agents and /catalog-items

[vkolodny]

Summary

control-plane#51 removed
the /providers endpoint entirely (replaced by agent-based architecture over NATS).

• TC-08: rewrite from "Provider CRUD" to "Agent CRUD" (POST/GET /agents)
• TC-02, TC-34: replace provider create/delete with agent registration
• All other TCs: /providers → /catalog-items as generic protected endpoint
• TC-37/38: clarify step titles for SP-as-agent context
• Add migration note documenting the API change

No functional test coverage lost — agent DELETE doesn't exist by design
(FK constraints preserve resource→agent history).

Test plan

• N/A (documentation only)
• Verified /catalog-items and /agents return 200 on live stack

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can copy the agent prompt from any finding and feed it to your IDE agent

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 9c3e00d ⏭️ Skipped

Results up to commit 2ea37fb ⏭️ Skipped

No changes from previous review

[qodo-code-review]

PR Summary by Qodo

Migrate authentication test plan from providers to agents

📝 Documentation 🧪 Tests 🕐 10-20 Minutes

AI Description

• Replaces removed /providers calls with /catalog-items for authentication checks.
• Reworks provider lifecycle scenarios around agent registration, listing, retrieval, and idempotent
 updates.
• Documents the agent API migration and intentional absence of agent deletion.

Diagram

graph TD
  A["Auth test cases"] --> B{"Validation goal"}
  B -->|Auth behavior| C["Catalog items API"] --> D["Auth responses"]
  B -->|Agent lifecycle| E["Agents API"] --> F["Agent records"]

Loading

High-Level Assessment

The endpoint split is appropriate: /catalog-items provides a stable protected read endpoint for generic authentication checks, while /agents directly covers the replacement management lifecycle. Reusing /agents everywhere would introduce unnecessary registration side effects, and retaining provider terminology would document a removed API. Omitting deletion checks correctly reflects the intentional lack of an agent DELETE endpoint.

Files changed (1) +90 / -105

Documentation (1) +90 / -105

FLPATH-3254-dcm-authentication-test-plan.mdMigrate authentication scenarios to catalog-items and agents APIs +90/-105

Migrate authentication scenarios to catalog-items and agents APIs

• Updates generic authentication checks to use '/catalog-items' instead of the removed '/providers' endpoint. Rewrites provider CRUD and service-provider scenarios around agent registration, listing, retrieval, and idempotent updates, while documenting that agents have no DELETE endpoint. Also advances the test plan to version 1.9 and records the API migration history.

test-plans/FLPATH-3254-dcm-authentication-test-plan.md

[qodo-code-review]

Code review by qodo was updated up to the latest commit 9c3e00d

[gciavarrini]

However, this is a MANUAL test case (not just subsystem), so testers running this locally will accumulate test agents. The cleanup should provide a SQL DELETE statement or explain that running make compose-down -v removes the agent. The current text only addresses automated subsystem test runs. Can you double check?

[vkolodny]

done

[gciavarrini]

This step egisters an agent named 'helm-smoke-agent' but doesn't verify whether an agent with that name already exists from a previous test run. Since there's no DELETE endpoint and agents persist, re-running this test will trigger the idempotent update path (HTTP 200) instead of creation (HTTP 201), causing the expected result to be wrong. Can you please double check?

[vkolodny]

done

[gciavarrini]

the description should be updated to reflect that we're polling agent health status, not provider health directly no?

[vkolodny]

done

[chadcrum]

TC-02 Step 2 needs a quick update to match TC-08 and TC-34. Expected result currently only shows HTTP 201, but agent registration is idempotent by name — re-running returns HTTP 200. TC-08 and TC-34 already document this from earlier review feedback. Manual testers re-running TC-02 will see 200 and think it failed.

[chadcrum]

lgtm