Introduce /v1 target API prefix (4.1.1)

[leynos]

Summary

This branch implements roadmap task (4.1.1) by introducing /v1 as the target prefix for Episodic's existing client-facing canonical REST API resources.

It registers series-profile, episode-template, reusable-reference, reference-binding, and binding-resolution Falcon routes under /v1, leaves root health endpoints unversioned, and does not add compatibility aliases for old pre-v0.1.0 canonical paths.

Execplan: docs/execplans/4-1-1-introduce-v1-target-api-prefix.md

Review walkthrough

• Start with episodic/api/app.py for the route-table change.
• Review tests/test_api_route_versioning.py for the explicit /v1, unversioned 404, and root-health routing contract.
• Review the updated API tests and BDD step modules for /v1 client paths.
• Review docs/developers-guide.md, docs/users-guide.md, and docs/roadmap.md for the documented routing convention and roadmap completion.

Validation

• make fmt: passed. Unrelated Markdown formatter churn was reverted.
• mbake validate Makefile: passed.
• make check-fmt: passed.
• PATH=/root/.bun/bin:$PATH make markdownlint: passed with 0 errors.
• make nixie: passed; all diagrams validated successfully.
• make build: passed.
• make lint: passed.
• make typecheck: passed.
• make test: passed with 662 passed and 3 skipped.
• make check-migrations: passed.
• coderabbit doctor: passed with 9 passed, 0 warnings, 0 failed.
• coderabbit review --agent: passed with 0 findings after clearing all concerns.

References

• Lody session: https://lody.ai/leynos/sessions/b33e77aa-4c5e-41e4-b03a-64fbf23fa4f7

Summary by Sourcery

Route existing canonical REST API resources under a new /v1 API prefix and document the versioning contract while keeping health endpoints unversioned.

New Features:

• Expose series-profile, episode-template, reusable-reference, reference-binding, and binding-resolution HTTP resources under the /v1 API namespace.

Enhancements:

• Clarify API versioning and routing conventions in the developers guide and users guide, including which endpoints are versioned and which remain internal.
• Add explicit tests to assert /v1 routes are registered, unversioned canonical routes return 404, and health endpoints continue to work at root paths.
• Mark roadmap item 4.1.1 as complete and record the associated execution plan document for the /v1 prefix rollout.

Documentation:

• Add an execution plan document detailing the rationale, constraints, and validation steps for introducing the /v1 target API prefix.

Tests:

• Update existing API, BDD, and support tests to target /v1 paths for canonical resources and validate route-versioning behaviour via a new dedicated test module.

[sourcery-ai]

Sorry @leynos, you have reached your weekly rate limit of 2500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 076689f0-87ab-40a2-9747-9d747cb12da2

📥 Commits

Reviewing files that changed from the base of the PR and between 8a8662b and 7382b47.

📒 Files selected for processing (21)

• docs/developers-guide.md
• docs/execplans/4-1-1-introduce-v1-target-api-prefix.md
• docs/roadmap.md
• docs/users-guide.md
• episodic/api/app.py
• episodic/api/resources/episode_templates.py
• episodic/api/resources/series_profiles.py
• tests/api_fixtures.py
• tests/steps/test_binding_resolution_steps.py
• tests/steps/test_profile_template_api_steps.py
• tests/steps/test_reference_document_api_steps.py
• tests/steps/test_reference_document_model_steps.py
• tests/test_api_route_versioning.py
• tests/test_binding_resolution_api.py
• tests/test_binding_resolution_brief_endpoint.py
• tests/test_binding_resolution_support.py
• tests/test_lifespan_hooks.py
• tests/test_profile_template_api.py
• tests/test_reference_document_access.py
• tests/test_reference_document_api_support.py
• tests/test_reference_document_validation.py

---

Overview

Introduces a /v1 URL prefix for canonical REST API resources (series-profiles, episode-templates, reusable references, reference bindings, and binding resolution endpoints), whilst retaining unversioned health check endpoints. The implementation aligns with roadmap milestone 4.1.1 and is documented in the execution plan docs/execplans/4-1-1-introduce-v1-target-api-prefix.md.

Changes

Route Registration (episodic/api/app.py): Canonical API routes now register under /v1 prefix in the Falcon application, whilst the underlying resource classes and unit-of-work wiring remain unchanged. Health endpoints (/health/live, /health/ready) remain unversioned.

Documentation Updates:

• docs/developers-guide.md: Revised endpoint path examples to show /v1/ prefixed routes, clarified versioning conventions, and expanded sections on migration checks and response validation.
• docs/users-guide.md: Updated canonical API examples to reference /v1/ paths throughout (series-profiles, reference documents, bindings), and clarified that health checks remain at root level.
• docs/roadmap.md: Marked milestone 4.1.1 as complete and corrected reference link formatting.
• docs/execplans/4-1-1-introduce-v1-target-api-prefix.md: New execution plan detailing success criteria (specific /v1/… routes reachable, unversioned canonical paths returning 404, health endpoints unversioned), scope constraints, architectural boundaries, milestone-by-milestone execution approach, and a comprehensive progress timeline with validation evidence and outcomes.

Test Coverage (tests/test_api_route_versioning.py): New module-level contract tests asserting:

• Canonical API routes accessible only under /v1 prefix
• Unversioned canonical paths return 404
• /v1/health/live and /v1/health/ready return 404
• Root health endpoints (/health/live, /health/ready) remain registered and return 200
• POST requests to unversioned write endpoints (e.g., /series-profiles, /episode-templates) also return 404

Test Updates: All BDD steps and integration tests across tests/ updated to target /v1/ prefixed routes, including tests/api_fixtures.py, test steps, and route-specific integration tests. Request payloads and response assertions remain unchanged.

Documentation Examples (episodic/api/resources/): Updated module-level route registration examples to reference /v1/ paths.

Review Resolution

Addressed reviewer feedback by consolidating route specifications into a single source constant (_CANONICAL_ROUTE_CONTRACT_PATHS), simplifying route registration assertions to check for non-404 responses only (removed brittle validation-coupled assertions), parametrising versioned health tests to cover both /v1/health/live and /v1/health/ready, adding non-GET assertions for unversioned write routes, and updating the execution plan to define acronyms (ADR, BDD, CLI) on first use.

Validation

All checks passed: make test (662 passed, 3 skipped), make lint, make typecheck, make check-migrations, CodeRabbit doctor (9 passed, 0 warnings), and CodeRabbit review (0 findings).

Walkthrough

Register canonical Falcon endpoints under /v1; require unversioned canonical paths to return 404; keep health checks at root; add route-versioning contract tests; update tests, fixtures, BDD steps, and developer/user documentation to use /v1 paths.

Changes

API Versioning Implementation

Layer / File(s)	Summary
Core route registration and resource docstrings episodic/api/app.py, episodic/api/resources/series_profiles.py, episodic/api/resources/episode_templates.py	create_app() registers series-profiles, episode-templates, reference-documents, and reference-bindings routes under the /v1/ prefix while preserving existing resource wiring; example docstrings updated to show /v1/ paths.
Route versioning contract tests tests/test_api_route_versioning.py	Add contract tests that assert /v1 canonical GET routes are registered (not Falcon not-found), identical unversioned canonical GET/POST routes return 404 with the Falcon not-found payload, /v1/health/* endpoints are unregistered, and root /health/* remain registered and return expected health payloads.
Test fixtures and BDD step updates tests/api_fixtures.py, tests/steps/*	API fixture helpers and BDD step modules updated to call versioned /v1/ endpoints for profile, template, document, revision, binding, brief, history, and resolved-bindings operations.
Integration and API test updates tests/test_binding_resolution_*.py, tests/test_profile_template_api.py, tests/test_reference_document_*.py, tests/test_lifespan_hooks.py	Integration and feature tests updated to target /v1/ API paths for binding resolution, profile/template creation and updates, reference-document workflows, pagination/validation checks, lifespan checks, and cross-series access validation.
Developer and user documentation and ExecPlan docs/developers-guide.md, docs/users-guide.md, docs/roadmap.md, docs/execplans/4-1-1-introduce-v1-target-api-prefix.md	Developers' guide documents /v1 routing and details for canonical endpoints; users' guide updates examples and semantics to /v1/ paths; roadmap marks milestone 4.1.1 complete; ExecPlan added describing scope, milestones, progress, decisions, and retrospective.

Poem

🚀 Routes now versioned under /v1,
Canonical paths receive a clear new spin,
Health checks steady at the root,
Tests and docs aligned, neat and astute,
Ship the prefix, let client calls begin. 🎯

Suggested labels

Roadmap

🚥 Pre-merge checks | ✅ 19 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
User-Facing Documentation	⚠️ Warning	Users-guide documents new /v1 paths clearly, but no dedicated migration guide exists to signpost the breaking change and guide API consumers from unversioned paths to /v1.	Create a migration guide documenting the breaking API change, showing before-and-after endpoint examples, and clarifying that unversioned paths return 404.

✅ Passed checks (19 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly summarises the main change: introducing a /v1 API prefix, and correctly includes the roadmap reference (4.1.1) as required.
Description check	✅ Passed	The description comprehensively details the changeset scope, implementation approach, validation steps, and references the execplan—all directly related to the /v1 prefix introduction.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Testing (Overall)	✅ Passed	Real tests verify /v1 routes invoke handlers, unversioned return 404, health untouched. POST tests enforce versioning. Would fail if routing absent.
Developer Documentation	✅ Passed	Developers guide documents /v1 API routing; roadmap 4.1.1 marked complete; execplan with Decision Log, Outcomes, and acronyms marked COMPLETE; users guide updated; no language sync needed.
Module-Level Documentation	✅ Passed	All modules carry module-level docstrings explaining purpose and utility. New test_api_route_versioning.py docstring details the 4.1.1 strategy and endpoint versioning requirements.
Testing (Unit And Behavioural)	✅ Passed	Tests verify routing through real Falcon TestClient; integration tests exercise end-to-end workflows; BDD scenarios cover appropriate functional boundaries and meaningful payloads.
Testing (Property / Proof)	✅ Passed	PR adds static route configuration and contract tests. No algorithmic invariants, path composition, or formal proofs introduced. Execplan correctly notes static prefixes need no property tests.
Testing (Compile-Time / Ui)	✅ Passed	PR implements API routing changes for a Python project. No compile-time Rust code exists (no trybuild needed); no text-based or structured output generation occurs (no snapshots needed).
Unit Architecture	✅ Passed	Changes preserve unit architecture: query/command separation maintained, dependencies properly injected, tests validate routing contracts without implementation coupling.
Domain Architecture	✅ Passed	Domain logic remains fully segregated from HTTP adapter. Only episodic/api/app.py route paths changed; zero domain modifications. Service signatures, handlers, and serialisers untouched.
Observability	✅ Passed	PR is a URL routing prefix change only; underlying request handlers and operational logic remain unchanged, so no new observability instrumentation is required.
Security And Privacy	✅ Passed	No secrets, authentication bypasses, authorisation gaps, injection risks, or sensitive data exposed. Routes prefixed with /v1; health endpoints unversioned; security logic and validation unchanged.
Performance And Resource Use	✅ Passed	PR introduces only route path string updates and documentation changes. No algorithmic changes, unbounded allocations, blocking I/O, or hot-path regressions detected.
Concurrency And State	✅ Passed	PR introduces only route path string updates; no changes to shared state, async execution, locking, transactions, task lifetimes, or concurrency patterns detected.
Architectural Complexity And Maintainability	✅ Passed	Route-prefix changes maintain minimal complexity: no unnecessary abstractions, clean dependencies, single source of truth for test routes via proper derivation, and clear architectural documentation.
Rust Compiler Lint Integrity	✅ Passed	Repository contains zero Rust files and no Cargo.toml. PR modifies only Python code and Markdown documentation. Rust compiler lint check is not applicable.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 4-1-1-introduce-v1-target-api-prefix

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[sourcery-ai]

Reviewer's Guide

Introduces /v1 as the canonical prefix for all client-facing REST API resources (series profiles, episode templates, reusable references, bindings, and binding resolution), keeps health checks unversioned at /health/*, updates tests and documentation to reflect the new routing contract, and marks roadmap item 4.1.1 as complete.

Sequence diagram for new /v1 API routing and unversioned health checks

sequenceDiagram
    actor Client
    participant GranianRuntime as GranianRuntime
    participant FalconApp as FalconApp_create_app
    participant HealthLiveResource
    participant SeriesProfilesResource

    Client->>GranianRuntime: GET /health/live
    GranianRuntime->>FalconApp: route_request
    FalconApp->>HealthLiveResource: on_get
    HealthLiveResource-->>Client: 200 OK

    Client->>GranianRuntime: GET /v1/series-profiles
    GranianRuntime->>FalconApp: route_request
    FalconApp->>SeriesProfilesResource: on_get
    SeriesProfilesResource-->>Client: 200 OK

    Client->>GranianRuntime: GET /series-profiles
    GranianRuntime->>FalconApp: route_request
    alt [no /series-profiles route registered]
        FalconApp-->>Client: 404 Not Found
    end

Loading

File-Level Changes

Change	Details	Files
Register all canonical Falcon API routes under the /v1 prefix while keeping health endpoints unversioned at root paths.	Update Falcon route registrations for series-profile, episode-template, reusable-reference, reference-binding, and binding-resolution resources to use /v1/... paths. Leave /health/live and /health/ready registered at unversioned root paths. Add explicit tests asserting /v1 routes are reachable, unversioned canonical routes return 404, /v1/health/live is not registered, and root health routes remain available.	episodic/api/app.py tests/test_api_route_versioning.py tests/test_lifespan_hooks.py
Align API tests, fixtures, and BDD step modules with the new /v1 client-facing paths.	Update direct API tests for profiles, templates, references, bindings, and binding-resolution to call /v1/... URLs. Adjust shared API fixtures and support helpers to construct /v1 paths when seeding or querying entities. Update BDD-style step definitions to use /v1 endpoints in scenario flows. Ensure validation, optimistic locking, and access-control tests still cover the same behaviours under the new paths.	tests/test_profile_template_api.py tests/test_binding_resolution_api.py tests/test_binding_resolution_brief_endpoint.py tests/test_binding_resolution_support.py tests/test_binding_resolution_access.py tests/test_reference_document_validation.py tests/test_reference_document_access.py tests/test_reference_document_api_support.py tests/api_fixtures.py tests/steps/test_profile_template_api_steps.py tests/steps/test_reference_document_api_steps.py tests/steps/test_binding_resolution_steps.py tests/steps/test_reference_document_model_steps.py
Document the versioned routing convention and update user-facing endpoint examples to /v1.	Add a "Versioned API routing" section to the developers' guide specifying /v1 as the target prefix for client-facing canonical resources, clarifying that old unversioned routes are pre-v0.1.0 implementation details and not compatibility aliases, and that health endpoints remain at /health/live and /health/ready. Update documented endpoint lists and narrative examples in developers' and users' guides to use /v1/... paths for currently implemented series-profile, episode-template, reusable-reference, and binding-resolution endpoints. Tidy minor Markdown wrapping/formatting issues introduced by previous tooling runs.	docs/developers-guide.md docs/users-guide.md
Record the execution plan and roadmap completion for introducing /v1 routing.	Add an execplan document describing the purpose, constraints, risks, work plan, tests, and validation for introducing /v1 as the target API prefix. Mark roadmap item 4.1.1. Introduce /v1 as the target API prefix. as completed and keep related reference links formatted consistently.	docs/execplans/4-1-1-introduce-v1-target-api-prefix.md docs/roadmap.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[leynos]

@coderabbitai Have the following now been resolved?

Annul any requirements that violate the en-GB-oxendict spelling (-ize / -yse / -our) conventions (for example a request to replace "normalize" with "normalise" or "artefact" with "artifact"), or where the requirement unnecessarily increases cyclomatic complexity.

Please address the comments from this code review:

## Overall Comments
- The `_CANONICAL_ROUTES` table in `tests/test_api_route_versioning.py` duplicates knowledge of every endpoint path and expected status, which will be easy to desync from `create_app`; consider narrowing this test to only assert that `/v1/...` routes are non-404 and unversioned `/...` routes are 404, or deriving the route list from a smaller shared constant to reduce maintenance coupling.
- Several route-versioning tests assert specific 400 responses for malformed UUIDs, which ties the routing contract test to validation behaviour; if the goal is to test routing rather than request validation, simplifying these assertions to only check that the route is registered (non-404) would make the tests less brittle to future validation changes.

## Individual Comments

### Comment 1
<location path="tests/test_api_route_versioning.py" line_range="104-112" />
<code_context>
+    )
+
+
+def test_versioned_health_route_is_not_registered(
+    canonical_api_client: testing.TestClient,
+) -> None:
+    """Keep operator health endpoints outside the client-facing API prefix."""
+    response = canonical_api_client.simulate_get("/v1/health/live")
+
+    assert response.status_code == 404, (
+        f"Expected 404 for /v1/health/live, got {response.status_code}."
+    )
</code_context>
<issue_to_address>
**suggestion (testing):** Also assert that `/v1/health/ready` remains unregistered alongside `/v1/health/live`.

Consider extending this test to cover `/v1/health/ready` as well, e.g. by parametrizing over `['/v1/health/live', '/v1/health/ready']` and asserting 404 for both, similar to the unversioned health checks.

```suggestion
@pytest.mark.parametrize(
    "path",
    ("/v1/health/live", "/v1/health/ready"),
)
def test_versioned_health_routes_are_not_registered(
    canonical_api_client: testing.TestClient,
    path: str,
) -> None:
    """Keep operator health endpoints outside the client-facing API prefix."""
    response = canonical_api_client.simulate_get(path)

    assert response.status_code == 404, (
        f"Expected 404 for {path}, got {response.status_code}."
    )
```
</issue_to_address>

### Comment 2
<location path="tests/test_api_route_versioning.py" line_range="91-99" />
<code_context>
+    )
+
+
+@pytest.mark.parametrize("path", _UNVERSIONED_CANONICAL_PATHS)
+def test_unversioned_canonical_api_routes_are_not_registered(
+    canonical_api_client: testing.TestClient,
+    path: str,
+) -> None:
+    """Keep pre-v0.1.0 canonical API routes unavailable without `/v1`."""
+    response = canonical_api_client.simulate_get(path)
+
+    assert response.status_code == 404, (
+        f"Expected 404 for unversioned {path}, got {response.status_code}."
+    )
</code_context>
<issue_to_address>
**suggestion (testing):** Consider adding at least one non-GET assertion that unversioned canonical routes are not available.

To further harden the contract, consider a similar test that uses a write method (e.g. `POST /series-profiles` or `POST /episode-templates` without `/v1`) and asserts `404`. That would help catch accidental reintroduction of unversioned write aliases while keeping these tests focused on versioning behavior.
</issue_to_address>

### Comment 3
<location path="docs/execplans/4-1-1-introduce-v1-target-api-prefix.md" line_range="89" />
<code_context>
+- `docs/adr/adr-009-source-to-script-rest-vertical-slice.md`, which records
+  the accepted decision that existing unversioned routes do not need
+  preservation before v0.1.0.
+- `docs/episodic-podcast-generation-system-design.md`, which links ADR 009 and
+  already describes the source-to-script vertical-slice direction.
+- `docs/async-sqlalchemy-with-pg-and-falcon.md`,
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym "ADR" is introduced without definition; please expand it on first use (for example, "Architecture Decision Record (ADR)").

To follow the acronym rule, consider rephrasing this to something like:

"`docs/episodic-podcast-generation-system-design.md`, which links Architecture Decision Record (ADR) 009 and ..."

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

### Comment 4
<location path="docs/execplans/4-1-1-introduce-v1-target-api-prefix.md" line_range="330" />
<code_context>
+
+### Milestone 3: align behavioural and runtime coverage
+
+Run the API BDD scenarios that use Falcon route paths:
+
+```shell
</code_context>
<issue_to_address>
**suggestion (review_instructions):** "BDD" is introduced here without definition; it should be expanded on first use in the document.

Consider expanding BDD the first time it appears, for example:

"Run the API behaviour-driven development (BDD) scenarios that use Falcon route paths:"

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

### Comment 5
<location path="docs/execplans/4-1-1-introduce-v1-target-api-prefix.md" line_range="121" />
<code_context>
+  already implemented canonical API resources.
+- Do not implement future phase-4 resources such as `/v1/episodes`,
+  `/v1/uploads`, `/v1/ingestion-jobs`, `/v1/generation-runs`,
+  `/v1/voice-previews`, WebSocket streams, CLI commands, approval workflows, or
+  web-console flows.
+- Preserve health checks at `/health/live` and `/health/ready` unless a
</code_context>
<issue_to_address>
**suggestion (review_instructions):** The acronym "CLI" is used without being defined; it should be expanded on first use.

To satisfy the acronym rule, you could write:

"`/v1/voice-previews`, WebSocket streams, command-line interface (CLI) commands, approval workflows, or ..."

<details>
<summary>Review instructions:</summary>

**Path patterns:** `**/*.md`

**Instructions:**
Define uncommon acronyms on first use.

</details>
</issue_to_address>

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Check current state of the versioning test file
cat tests/test_api_route_versioning.py

echo "---EXECPLAN---"
# Check first 200 lines of execplan for acronym definitions
cat docs/execplans/4-1-1-introduce-v1-target-api-prefix.md

Length of output: 34902

---

@leynos Yes — all comments are resolved in the current branch state. Here is the full account:

Overall Comments

Comment	Resolution
_CANONICAL_ROUTES duplicates path knowledge	_CANONICAL_ROUTE_CONTRACT_PATHS is now the single source of truth; _UNVERSIONED_CANONICAL_PATHS and _VERSIONED_CANONICAL_PATHS are both derived from it. ✅
Tests assert specific 400 responses, coupling routing to validation	test_versioned_canonical_api_routes_are_registered now asserts only != 404 — no validation-specific status codes. ✅

Individual Comments

#	Comment	Resolution
1	Also cover /v1/health/ready	test_versioned_health_routes_are_not_registered is parametrized over ["/v1/health/live", "/v1/health/ready"]. ✅
2	Add a non-GET assertion for unversioned routes	test_unversioned_canonical_write_routes_are_not_registered uses simulate_post over /series-profiles and /episode-templates. ✅
3	"ADR" undefined on first use	Defined as "architecture decision record (ADR)" in the Purpose section of the ExecPlan. ✅
4	"BDD" undefined on first use	Defined as "behaviour-driven development (BDD)" in the Risks section, before first use in Milestone 3. ✅
5	"CLI" undefined on first use	Defined as "command-line interface (CLI)" in the Purpose section, before use in Constraints. ✅

No annulments were required: none of the original comments violated en-GB-oxendict spelling conventions, and none of the implemented changes increase cyclomatic complexity.

[leynos]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.