Use Cases

These are real-world failure modes that CodeRadius is built to prevent. Each scenario describes a problem that cannot be solved by file-level linters, code search, or Slack threads — because the breakage is topological, not syntactical.

1. PR Modifies a Message Payload — Downstream Consumer Breaks Silently

Without CodeRadius

A developer on the Payments team renames userId to customerId in the body of a RabbitMQ message published to payment.completed. The PR passes all unit tests. CI is green. Code review approves — the change is clean and well-structured.

Two weeks later, the Notifications team starts seeing JSON parsing errors. Their consumer expects userId. A 3-day Slack thread ensues to identify the root cause. The fix is trivial — the discovery was not.

With CodeRadius

The developer runs impact evaluation before pushing:

cr blast --base main --head HEAD -m "Rename userId to customerId in payment payload"

CodeRadius:

1. Detects that the payment.completed channel's payload schema changed (field userId was removed)
2. Queries the graph for downstream consumers of payment.completed
3. Finds notifications-service (Team: Platform) and reporting-service (Team: Data)
4. Returns a DANGER finding and exits with code 1 — the PR is blocked in CI

┌─────────────────────────────────────────────────────────────────┐
│  DANGER  Breaking change detected                               │
├─────────────────────────────────────────────────────────────────┤
│  Resource:    MessageChannel payment.completed                  │
│  Change:      Field `userId` removed from payload               │
│                                                                 │
│  Downstream consumers:                                          │
│    → notifications-service  (Team: Platform)                    │
│    → reporting-service      (Team: Data)                        │
│                                                                 │
│  Exit code: 1                                                   │
└─────────────────────────────────────────────────────────────────┘

Fix: The developer (or their AI agent) adds backward-compatible field aliasing (customerId + deprecated userId) and re-runs. The evaluation passes.

2. AI Agent Refactors an API — Breaks 4 Internal Consumers

Without CodeRadius

A developer asks their IDE agent (Cursor, Claude) to "refactor the users endpoint to use the new response format". The agent modifies GET /api/v1/users/{id} to return a restructured JSON body — renaming fields, nesting objects differently. The code compiles, tests pass, the change is clean.

Four other internal services call this endpoint. None of them are in the current repository. None of them have tests against the new response shape. The change ships, and four services start returning 500 errors in production.

With CodeRadius (MCP)

The agent is connected to the CodeRadius MCP server. Before writing the change, it calls analyze_blast_radius:

{
  "resource": "GET /api/v1/users/{id}",
  "consumers": [
    { "service": "billing-service", "team": "finance" },
    { "service": "admin-panel", "team": "internal-tools" },
    { "service": "onboarding-service", "team": "growth" },
    { "service": "audit-service", "team": "compliance" }
  ]
}

The agent sees 4 downstream consumers and revises its approach: it creates a new GET /api/v2/users/{id} endpoint with the new format and adds a deprecation header to v1. Zero breakage.

3. New Service Ships Without Organizational Standards — Caught Immediately

Without CodeRadius

A new team scaffolds a service, pushes it to the repository, and starts shipping features. Six months later, during a quarterly architecture review, someone notices:

• No Makefile with standard targets (setup, test, run)
• No CI/CD pipeline configuration
• Docker base image pulled from Docker Hub with an unpinned latest tag
• No team ownership declared — nobody knows who's on-call

The remediation happens months too late, after the service has accumulated technical debt and onboarded 3 developers who learned the wrong patterns.

With CodeRadius

The Governance engine runs policy checks after every cr ui generation. When the new service is ingested, three violations fire immediately:

The Architecture Dashboard renders these as structured checklists with ✓/✗ status and fuzzy-match suggestions (e.g., "found 'tests' — did you mean 'test'?").

The team lead sees the violations the same week, not six months later.

The Common Thread

All three scenarios share one characteristic: the breakage is invisible at the file level.

• A linter can't tell you that a downstream service consumes your message payload.
• Code search can't tell you that 4 services call your API endpoint.
• A Backstage catalog can't tell you that your Makefile is missing mandatory targets — that's a topological check against organizational policy.

CodeRadius catches these because it operates on a cross-repo architectural graph, not on individual files.

Next Steps

• Governance & Golden Path — Write and enforce policies like the ones in Scenario 3.
• Impact Evaluation — Run blast radius analysis like Scenario 1.
• MCP Server — Connect your AI agents like Scenario 2.