Standardize route handler error responses

[itsmiso-ai]

Creates shared api-errors module with errorResponse and handleApiError helpers, adds unit tests, and updates the GET handler in agent-work/route.ts to use the new helper. All 34 tests pass (30 existing + 4 new).

Fixes#534

Opened by foreman on review GO (workload wl-misospace-dispatch-534).

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

Recommendation: Approve

This PR cleanly addresses issue PR 534 by introducing shared error-response helpers (errorResponse, handleApiError) and applying them to one route handler. All 5 CI checks pass (Docker Build, Tests, Lint, Build, Typecheck).

Change-by-Change Findings

1. src/lib/api-errors.ts (new file, +40 lines)

Creates two exported helpers:

• errorResponse(message, status=500) → NextResponse.json({ error: message }, { status })
• handleApiError(context, error, status=500) → logs console.error("Failed to <context>:", error) then returns a 500 response

The implementation is straightforward, TypeScript-typed, and docstring-commented. No route-level changes, no auth changes, no new endpoints.

2. src/lib/api-errors.test.ts (new file, +33 lines)

Four vitest cases covering:

• Canonical 500 + { error: string } shape from errorResponse
• Custom status codes respected
• handleApiError log + 500 response agreement
• Non-Error throw values (e.g. strings) still handled gracefully

3. src/app/api/agent-work/route.ts (modified, +2/−2 lines)

Replaces two lines in the GET handler's catch block with a single call to handleApiError:

- console.error("Failed to fetch agent work:", error);- return NextResponse.json({ error: "Failed to fetch agent work" }, { status: 500 });+ return handleApiError("fetch agent work", error);

This is a pure refactor — identical behavior, just centralized.

Must-Check Checklist

✅ verify route access controls are in place

The diff shows only the catch-block error handling change. The GET handler in agent-work/route.ts already calls authorizeRequest (imported on line 3, called before the try block). The PR does not touch, bypass, or remove that authorization check. Existing access controls remain fully in place.

✅ check for unintended public endpoints

No new routes are added. No existing routes are modified in their URL path, HTTP method, or authentication requirements. This PR introduces only a utility module and a single usage in one catch block.

Standards Compliance

• Code Standards: error instanceof Error pattern is not strictly followed in handleApiError (it accepts unknown), but this is intentional — it makes the helper resilient to both Error objects and primitive throw values, which is the whole point of the abstraction.
• API routes: Return appropriate HTTP status codes ✅ (the helper preserves the 500 default and allows custom statuses).
• No secrets committed: No secrets or env files touched.

Linked Issue Fit

Issue PR 534 called out inconsistent error handling across route handlers — specifically noting that agent-work/route.ts logs errors without returning structured responses. This PR:

• ✅ Adds a shared helper to standardize the pattern
• ✅ Applies it to the exact route mentioned in the issue
• ✅ Adds tests

The PR scope is intentionally narrow (one route, one helper, tests) per the issue's description. Full rollout to other routes can follow as subsequent work.

Unknowns / Needs Verification

None. The corpus provides complete diffs, CI results, and linked issue context.

[itsmiso-ai]

Creates shared api-errors module with errorResponse and handleApiError helpers, adds unit tests, and updates the GET handler in agent-work/route.ts to use the new helper. All 34 tests pass (30 existing + 4 new).

Fixes#534

Opened by foreman on review GO (workload wl-misospace-dispatch-534).

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

Recommendation: Approve

This PR cleanly addresses issue PR 534 by introducing shared error-response helpers (errorResponse, handleApiError) and applying them to one route handler. All 5 CI checks pass (Docker Build, Tests, Lint, Build, Typecheck).

Change-by-Change Findings

1. src/lib/api-errors.ts (new file, +40 lines)

Creates two exported helpers:

• errorResponse(message, status=500) → NextResponse.json({ error: message }, { status })
• handleApiError(context, error, status=500) → logs console.error("Failed to <context>:", error) then returns a 500 response

The implementation is straightforward, TypeScript-typed, and docstring-commented. No route-level changes, no auth changes, no new endpoints.

2. src/lib/api-errors.test.ts (new file, +33 lines)

Four vitest cases covering:

• Canonical 500 + { error: string } shape from errorResponse
• Custom status codes respected
• handleApiError log + 500 response agreement
• Non-Error throw values (e.g. strings) still handled gracefully

3. src/app/api/agent-work/route.ts (modified, +2/−2 lines)

Replaces two lines in the GET handler's catch block with a single call to handleApiError:

- console.error("Failed to fetch agent work:", error);- return NextResponse.json({ error: "Failed to fetch agent work" }, { status: 500 });+ return handleApiError("fetch agent work", error);

This is a pure refactor — identical behavior, just centralized.

Must-Check Checklist

✅ verify route access controls are in place

The diff shows only the catch-block error handling change. The GET handler in agent-work/route.ts already calls authorizeRequest (imported on line 3, called before the try block). The PR does not touch, bypass, or remove that authorization check. Existing access controls remain fully in place.

✅ check for unintended public endpoints

No new routes are added. No existing routes are modified in their URL path, HTTP method, or authentication requirements. This PR introduces only a utility module and a single usage in one catch block.

Standards Compliance

• Code Standards: error instanceof Error pattern is not strictly followed in handleApiError (it accepts unknown), but this is intentional — it makes the helper resilient to both Error objects and primitive throw values, which is the whole point of the abstraction.
• API routes: Return appropriate HTTP status codes ✅ (the helper preserves the 500 default and allows custom statuses).
• No secrets committed: No secrets or env files touched.

Linked Issue Fit

Issue PR 534 called out inconsistent error handling across route handlers — specifically noting that agent-work/route.ts logs errors without returning structured responses. This PR:

• ✅ Adds a shared helper to standardize the pattern
• ✅ Applies it to the exact route mentioned in the issue
• ✅ Adds tests

The PR scope is intentionally narrow (one route, one helper, tests) per the issue's description. Full rollout to other routes can follow as subsequent work.

Unknowns / Needs Verification

None. The corpus provides complete diffs, CI results, and linked issue context.

[itsmiso-ai]

Creates shared api-errors module with errorResponse and handleApiError helpers, adds unit tests, and updates the GET handler in agent-work/route.ts to use the new helper. All 34 tests pass (30 existing + 4 new).

Fixes#534

Opened by foreman on review GO (workload wl-misospace-dispatch-534).

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

Recommendation: Approve

This PR cleanly addresses issue PR 534 by introducing shared error-response helpers (errorResponse, handleApiError) and applying them to one route handler. All 5 CI checks pass (Docker Build, Tests, Lint, Build, Typecheck).

Change-by-Change Findings

1. src/lib/api-errors.ts (new file, +40 lines)

Creates two exported helpers:

• errorResponse(message, status=500) → NextResponse.json({ error: message }, { status })
• handleApiError(context, error, status=500) → logs console.error("Failed to <context>:", error) then returns a 500 response

The implementation is straightforward, TypeScript-typed, and docstring-commented. No route-level changes, no auth changes, no new endpoints.

2. src/lib/api-errors.test.ts (new file, +33 lines)

Four vitest cases covering:

• Canonical 500 + { error: string } shape from errorResponse
• Custom status codes respected
• handleApiError log + 500 response agreement
• Non-Error throw values (e.g. strings) still handled gracefully

3. src/app/api/agent-work/route.ts (modified, +2/−2 lines)

Replaces two lines in the GET handler's catch block with a single call to handleApiError:

- console.error("Failed to fetch agent work:", error);- return NextResponse.json({ error: "Failed to fetch agent work" }, { status: 500 });+ return handleApiError("fetch agent work", error);

This is a pure refactor — identical behavior, just centralized.

Must-Check Checklist

✅ verify route access controls are in place

The diff shows only the catch-block error handling change. The GET handler in agent-work/route.ts already calls authorizeRequest (imported on line 3, called before the try block). The PR does not touch, bypass, or remove that authorization check. Existing access controls remain fully in place.

✅ check for unintended public endpoints

No new routes are added. No existing routes are modified in their URL path, HTTP method, or authentication requirements. This PR introduces only a utility module and a single usage in one catch block.

Standards Compliance

• Code Standards: error instanceof Error pattern is not strictly followed in handleApiError (it accepts unknown), but this is intentional — it makes the helper resilient to both Error objects and primitive throw values, which is the whole point of the abstraction.
• API routes: Return appropriate HTTP status codes ✅ (the helper preserves the 500 default and allows custom statuses).
• No secrets committed: No secrets or env files touched.

Linked Issue Fit

Issue PR 534 called out inconsistent error handling across route handlers — specifically noting that agent-work/route.ts logs errors without returning structured responses. This PR:

• ✅ Adds a shared helper to standardize the pattern
• ✅ Applies it to the exact route mentioned in the issue
• ✅ Adds tests

The PR scope is intentionally narrow (one route, one helper, tests) per the issue's description. Full rollout to other routes can follow as subsequent work.

Unknowns / Needs Verification

None. The corpus provides complete diffs, CI results, and linked issue context.

[itsmiso-ai]

Creates shared api-errors module with errorResponse and handleApiError helpers, adds unit tests, and updates the GET handler in agent-work/route.ts to use the new helper. All 34 tests pass (30 existing + 4 new).

Fixes#534

Opened by foreman on review GO (workload wl-misospace-dispatch-534).

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

Recommendation: Approve

This PR cleanly addresses issue PR 534 by introducing shared error-response helpers (errorResponse, handleApiError) and applying them to one route handler. All 5 CI checks pass (Docker Build, Tests, Lint, Build, Typecheck).

Change-by-Change Findings

1. src/lib/api-errors.ts (new file, +40 lines)

Creates two exported helpers:

• errorResponse(message, status=500) → NextResponse.json({ error: message }, { status })
• handleApiError(context, error, status=500) → logs console.error("Failed to <context>:", error) then returns a 500 response

The implementation is straightforward, TypeScript-typed, and docstring-commented. No route-level changes, no auth changes, no new endpoints.

2. src/lib/api-errors.test.ts (new file, +33 lines)

Four vitest cases covering:

• Canonical 500 + { error: string } shape from errorResponse
• Custom status codes respected
• handleApiError log + 500 response agreement
• Non-Error throw values (e.g. strings) still handled gracefully

3. src/app/api/agent-work/route.ts (modified, +2/−2 lines)

Replaces two lines in the GET handler's catch block with a single call to handleApiError:

- console.error("Failed to fetch agent work:", error);- return NextResponse.json({ error: "Failed to fetch agent work" }, { status: 500 });+ return handleApiError("fetch agent work", error);

This is a pure refactor — identical behavior, just centralized.

Must-Check Checklist

✅ verify route access controls are in place

The diff shows only the catch-block error handling change. The GET handler in agent-work/route.ts already calls authorizeRequest (imported on line 3, called before the try block). The PR does not touch, bypass, or remove that authorization check. Existing access controls remain fully in place.

✅ check for unintended public endpoints

No new routes are added. No existing routes are modified in their URL path, HTTP method, or authentication requirements. This PR introduces only a utility module and a single usage in one catch block.

Standards Compliance

• Code Standards: error instanceof Error pattern is not strictly followed in handleApiError (it accepts unknown), but this is intentional — it makes the helper resilient to both Error objects and primitive throw values, which is the whole point of the abstraction.
• API routes: Return appropriate HTTP status codes ✅ (the helper preserves the 500 default and allows custom statuses).
• No secrets committed: No secrets or env files touched.

Linked Issue Fit

Issue PR 534 called out inconsistent error handling across route handlers — specifically noting that agent-work/route.ts logs errors without returning structured responses. This PR:

• ✅ Adds a shared helper to standardize the pattern
• ✅ Applies it to the exact route mentioned in the issue
• ✅ Adds tests

The PR scope is intentionally narrow (one route, one helper, tests) per the issue's description. Full rollout to other routes can follow as subsequent work.

Unknowns / Needs Verification

None. The corpus provides complete diffs, CI results, and linked issue context.

[itsmiso-ai]

Creates shared api-errors module with errorResponse and handleApiError helpers, adds unit tests, and updates the GET handler in agent-work/route.ts to use the new helper. All 34 tests pass (30 existing + 4 new).

Fixes#534

Opened by foreman on review GO (workload wl-misospace-dispatch-534).

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

Recommendation: Approve

This PR cleanly addresses issue PR 534 by introducing shared error-response helpers (errorResponse, handleApiError) and applying them to one route handler. All 5 CI checks pass (Docker Build, Tests, Lint, Build, Typecheck).

Change-by-Change Findings

1. src/lib/api-errors.ts (new file, +40 lines)

Creates two exported helpers:

• errorResponse(message, status=500) → NextResponse.json({ error: message }, { status })
• handleApiError(context, error, status=500) → logs console.error("Failed to <context>:", error) then returns a 500 response

The implementation is straightforward, TypeScript-typed, and docstring-commented. No route-level changes, no auth changes, no new endpoints.

2. src/lib/api-errors.test.ts (new file, +33 lines)

Four vitest cases covering:

• Canonical 500 + { error: string } shape from errorResponse
• Custom status codes respected
• handleApiError log + 500 response agreement
• Non-Error throw values (e.g. strings) still handled gracefully

3. src/app/api/agent-work/route.ts (modified, +2/−2 lines)

Replaces two lines in the GET handler's catch block with a single call to handleApiError:

- console.error("Failed to fetch agent work:", error);- return NextResponse.json({ error: "Failed to fetch agent work" }, { status: 500 });+ return handleApiError("fetch agent work", error);

This is a pure refactor — identical behavior, just centralized.

Must-Check Checklist

✅ verify route access controls are in place

The diff shows only the catch-block error handling change. The GET handler in agent-work/route.ts already calls authorizeRequest (imported on line 3, called before the try block). The PR does not touch, bypass, or remove that authorization check. Existing access controls remain fully in place.

✅ check for unintended public endpoints

No new routes are added. No existing routes are modified in their URL path, HTTP method, or authentication requirements. This PR introduces only a utility module and a single usage in one catch block.

Standards Compliance

• Code Standards: error instanceof Error pattern is not strictly followed in handleApiError (it accepts unknown), but this is intentional — it makes the helper resilient to both Error objects and primitive throw values, which is the whole point of the abstraction.
• API routes: Return appropriate HTTP status codes ✅ (the helper preserves the 500 default and allows custom statuses).
• No secrets committed: No secrets or env files touched.

Linked Issue Fit

Issue PR 534 called out inconsistent error handling across route handlers — specifically noting that agent-work/route.ts logs errors without returning structured responses. This PR:

• ✅ Adds a shared helper to standardize the pattern
• ✅ Applies it to the exact route mentioned in the issue
• ✅ Adds tests

The PR scope is intentionally narrow (one route, one helper, tests) per the issue's description. Full rollout to other routes can follow as subsequent work.

Unknowns / Needs Verification

None. The corpus provides complete diffs, CI results, and linked issue context.

[itsmiso-ai]

Creates shared api-errors module with errorResponse and handleApiError helpers, adds unit tests, and updates the GET handler in agent-work/route.ts to use the new helper. All 34 tests pass (30 existing + 4 new).

Fixes#534

Opened by foreman on review GO (workload wl-misospace-dispatch-534).

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

Recommendation: Approve

This PR cleanly addresses issue PR 534 by introducing shared error-response helpers (errorResponse, handleApiError) and applying them to one route handler. All 5 CI checks pass (Docker Build, Tests, Lint, Build, Typecheck).

Change-by-Change Findings

1. src/lib/api-errors.ts (new file, +40 lines)

Creates two exported helpers:

• errorResponse(message, status=500) → NextResponse.json({ error: message }, { status })
• handleApiError(context, error, status=500) → logs console.error("Failed to <context>:", error) then returns a 500 response

The implementation is straightforward, TypeScript-typed, and docstring-commented. No route-level changes, no auth changes, no new endpoints.

2. src/lib/api-errors.test.ts (new file, +33 lines)

Four vitest cases covering:

• Canonical 500 + { error: string } shape from errorResponse
• Custom status codes respected
• handleApiError log + 500 response agreement
• Non-Error throw values (e.g. strings) still handled gracefully

3. src/app/api/agent-work/route.ts (modified, +2/−2 lines)

Replaces two lines in the GET handler's catch block with a single call to handleApiError:

- console.error("Failed to fetch agent work:", error);- return NextResponse.json({ error: "Failed to fetch agent work" }, { status: 500 });+ return handleApiError("fetch agent work", error);

This is a pure refactor — identical behavior, just centralized.

Must-Check Checklist

✅ verify route access controls are in place

The diff shows only the catch-block error handling change. The GET handler in agent-work/route.ts already calls authorizeRequest (imported on line 3, called before the try block). The PR does not touch, bypass, or remove that authorization check. Existing access controls remain fully in place.

✅ check for unintended public endpoints

No new routes are added. No existing routes are modified in their URL path, HTTP method, or authentication requirements. This PR introduces only a utility module and a single usage in one catch block.

Standards Compliance

• Code Standards: error instanceof Error pattern is not strictly followed in handleApiError (it accepts unknown), but this is intentional — it makes the helper resilient to both Error objects and primitive throw values, which is the whole point of the abstraction.
• API routes: Return appropriate HTTP status codes ✅ (the helper preserves the 500 default and allows custom statuses).
• No secrets committed: No secrets or env files touched.

Linked Issue Fit

Issue PR 534 called out inconsistent error handling across route handlers — specifically noting that agent-work/route.ts logs errors without returning structured responses. This PR:

• ✅ Adds a shared helper to standardize the pattern
• ✅ Applies it to the exact route mentioned in the issue
• ✅ Adds tests

The PR scope is intentionally narrow (one route, one helper, tests) per the issue's description. Full rollout to other routes can follow as subsequent work.

Unknowns / Needs Verification

None. The corpus provides complete diffs, CI results, and linked issue context.

[itsmiso-ai]

Creates shared api-errors module with errorResponse and handleApiError helpers, adds unit tests, and updates the GET handler in agent-work/route.ts to use the new helper. All 34 tests pass (30 existing + 4 new).

Fixes#534

Opened by foreman on review GO (workload wl-misospace-dispatch-534).

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

Recommendation: Approve

This PR cleanly addresses issue PR 534 by introducing shared error-response helpers (errorResponse, handleApiError) and applying them to one route handler. All 5 CI checks pass (Docker Build, Tests, Lint, Build, Typecheck).

Change-by-Change Findings

1. src/lib/api-errors.ts (new file, +40 lines)

Creates two exported helpers:

• errorResponse(message, status=500) → NextResponse.json({ error: message }, { status })
• handleApiError(context, error, status=500) → logs console.error("Failed to <context>:", error) then returns a 500 response

The implementation is straightforward, TypeScript-typed, and docstring-commented. No route-level changes, no auth changes, no new endpoints.

2. src/lib/api-errors.test.ts (new file, +33 lines)

Four vitest cases covering:

• Canonical 500 + { error: string } shape from errorResponse
• Custom status codes respected
• handleApiError log + 500 response agreement
• Non-Error throw values (e.g. strings) still handled gracefully

3. src/app/api/agent-work/route.ts (modified, +2/−2 lines)

Replaces two lines in the GET handler's catch block with a single call to handleApiError:

- console.error("Failed to fetch agent work:", error);- return NextResponse.json({ error: "Failed to fetch agent work" }, { status: 500 });+ return handleApiError("fetch agent work", error);

This is a pure refactor — identical behavior, just centralized.

Must-Check Checklist

✅ verify route access controls are in place

The diff shows only the catch-block error handling change. The GET handler in agent-work/route.ts already calls authorizeRequest (imported on line 3, called before the try block). The PR does not touch, bypass, or remove that authorization check. Existing access controls remain fully in place.

✅ check for unintended public endpoints

No new routes are added. No existing routes are modified in their URL path, HTTP method, or authentication requirements. This PR introduces only a utility module and a single usage in one catch block.

Standards Compliance

• Code Standards: error instanceof Error pattern is not strictly followed in handleApiError (it accepts unknown), but this is intentional — it makes the helper resilient to both Error objects and primitive throw values, which is the whole point of the abstraction.
• API routes: Return appropriate HTTP status codes ✅ (the helper preserves the 500 default and allows custom statuses).
• No secrets committed: No secrets or env files touched.

Linked Issue Fit

Issue PR 534 called out inconsistent error handling across route handlers — specifically noting that agent-work/route.ts logs errors without returning structured responses. This PR:

• ✅ Adds a shared helper to standardize the pattern
• ✅ Applies it to the exact route mentioned in the issue
• ✅ Adds tests

The PR scope is intentionally narrow (one route, one helper, tests) per the issue's description. Full rollout to other routes can follow as subsequent work.

Unknowns / Needs Verification

None. The corpus provides complete diffs, CI results, and linked issue context.

[itsmiso-ai]

Creates shared api-errors module with errorResponse and handleApiError helpers, adds unit tests, and updates the GET handler in agent-work/route.ts to use the new helper. All 34 tests pass (30 existing + 4 new).

Fixes#534

Opened by foreman on review GO (workload wl-misospace-dispatch-534).

[its-saffron]

AI Automated Review

Full PR review.

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)

Recommendation: Approve

This PR cleanly addresses issue PR 534 by introducing shared error-response helpers (errorResponse, handleApiError) and applying them to one route handler. All 5 CI checks pass (Docker Build, Tests, Lint, Build, Typecheck).

Change-by-Change Findings

1. src/lib/api-errors.ts (new file, +40 lines)

Creates two exported helpers:

• errorResponse(message, status=500) → NextResponse.json({ error: message }, { status })
• handleApiError(context, error, status=500) → logs console.error("Failed to <context>:", error) then returns a 500 response

The implementation is straightforward, TypeScript-typed, and docstring-commented. No route-level changes, no auth changes, no new endpoints.

2. src/lib/api-errors.test.ts (new file, +33 lines)

Four vitest cases covering:

• Canonical 500 + { error: string } shape from errorResponse
• Custom status codes respected
• handleApiError log + 500 response agreement
• Non-Error throw values (e.g. strings) still handled gracefully

3. src/app/api/agent-work/route.ts (modified, +2/−2 lines)

Replaces two lines in the GET handler's catch block with a single call to handleApiError:

- console.error("Failed to fetch agent work:", error);- return NextResponse.json({ error: "Failed to fetch agent work" }, { status: 500 });+ return handleApiError("fetch agent work", error);

This is a pure refactor — identical behavior, just centralized.

Must-Check Checklist

✅ verify route access controls are in place

The diff shows only the catch-block error handling change. The GET handler in agent-work/route.ts already calls authorizeRequest (imported on line 3, called before the try block). The PR does not touch, bypass, or remove that authorization check. Existing access controls remain fully in place.

✅ check for unintended public endpoints

No new routes are added. No existing routes are modified in their URL path, HTTP method, or authentication requirements. This PR introduces only a utility module and a single usage in one catch block.

Standards Compliance

• Code Standards: error instanceof Error pattern is not strictly followed in handleApiError (it accepts unknown), but this is intentional — it makes the helper resilient to both Error objects and primitive throw values, which is the whole point of the abstraction.
• API routes: Return appropriate HTTP status codes ✅ (the helper preserves the 500 default and allows custom statuses).
• No secrets committed: No secrets or env files touched.

Linked Issue Fit

Issue PR 534 called out inconsistent error handling across route handlers — specifically noting that agent-work/route.ts logs errors without returning structured responses. This PR:

• ✅ Adds a shared helper to standardize the pattern
• ✅ Applies it to the exact route mentioned in the issue
• ✅ Adds tests

The PR scope is intentionally narrow (one route, one helper, tests) per the issue's description. Full rollout to other routes can follow as subsequent work.

Unknowns / Needs Verification

None. The corpus provides complete diffs, CI results, and linked issue context.