feat: render board and lane filters from lane configuration#433
Conversation
- Update work-summary API to use getConfiguredLanes() instead of VALID_LANES - Update groom API escalate action to use getEscalationLane() - Add lane filter support to issues API route and board page - Add lane dropdown to FilterBar component with non-claimable labels - Add lane badge to IssueCard using configured title, color, and claimable state - Wire lane config through KanbanBoardClient -> KanbanBoard -> IssueCard - Fix hardcoded backlog checks in reconcile and next-task routes
![its-saffron[bot]](https://avatars.githubusercontent.com/in/3901073?s=60&v=4){kind=small}
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
- Normalize hex colors in issue-card lane badge (handle with/without #) - Return 400 for invalid lane query param on /api/issues - Add tests for lane badge rendering and invalid lane filter - Add FilterBar lane filter tests
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
- Add authorizeRequest to GET /api/issues before query parsing - Add authorizeRequest to GET /api/agents/[agentName]/work-summary - Both routes return 401 for unauthorized requests - Unauthorized requests short-circuit (no DB calls) - Add auth tests: 401 no header, 401 bad token, authorized behavior, short-circuit verification, and invalid lane still returns 400 after auth
There was a problem hiding this comment.
AI Automated Review (incremental)
Incremental review: reviewed the changes since the last managed review; unresolved findings from that review are carried forward.
Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic) — routed smart (risk match: public_route_changes)
Review Summary
Recommendation: Approve
This PR adds route-level authorization to two API endpoints that previously lacked it, tightening access controls rather than exposing new endpoints.
Change-by-Change Findings
1. src/app/api/issues/route.ts — Authorization Added
- Added
authorizeRequestguard at the top of theGEThandler - Returns
401 Unauthorizedwhen no valid auth token/cookie is present - The
authorizeRequesthelper (from@/lib/auth) supports all configured auth modes: Basic Auth, Bearer token (DISPATCH_AGENT_TOKEN), and OIDC session cookies - No new query parameters or request shape changes; auth is additive
2. src/app/api/agents/[agentName]/work-summary/route.ts — Authorization Added
- Same
authorizeRequestguard pattern applied - Consistent 401 response for unauthorized requests
- No behavioral changes to the existing query logic
3. Test Coverage (route.test.ts files)
- Both test suites now include explicit auth-negative cases: missing
Authorizationheader, wrong bearer token - Verifies Prisma queries are NOT called on unauthorized requests (defense-in-depth)
- Existing positive cases preserved to confirm normal operation continues
Standards Compliance
| Standard | Status |
|---|---|
| API routes return appropriate HTTP status codes | ✅ 401 returned for auth failures |
Error handling via error instanceof Error pattern |
✅ Not applicable to auth guard |
| No new endpoints introduced | ✅ Auth is additive, not expansive |
The authorizeRequest helper is the repository's canonical auth gate and is used consistently across other API routes (e.g., groom/route.ts, reconcile/route.ts as shown in tool harness reads). This PR extends that pattern uniformly.
Linked Issue Fit
PR body references "Closes PR 386". The diff adds authorization to issue listing and work-summary endpoints, which are foundational API routes. Without full issue PR 386 body, the intent appears to be securing these read endpoints that return issue data — consistent with a feature adding configurable lane UI rendering, where both the UI and its backing APIs should require authentication.
Evidence Provider Findings
No evidence providers configured for this PR.
Tool Harness Findings
The incremental diff was verified against the actual source files:
| File | Authorization Present |
|---|---|
src/app/api/issues/route.ts |
✅ authorizeRequest check added |
src/app/api/agents/[agentName]/work-summary/route.ts |
✅ authorizeRequest check added |
src/app/api/issues/groom/route.ts |
✅ Already had auth (not modified in diff) |
src/app/api/issues/reconcile/route.ts |
✅ Already had auth (not modified in diff) |
Required Checks — Explicit Results
| Check | Result |
|---|---|
| verify route access controls are in place | ✅ VERIFIED — Both modified endpoints (GET /api/issues, GET /api/agents/[agentName]/work-summary) now enforce authorizeRequest. Test files confirm 401 responses for missing/invalid credentials and verify no database queries execute without auth. |
| check for unintended public endpoints | ✅ VERIFIED — No new endpoints introduced. All changes are additive auth guards on existing routes. No endpoint was changed from protected to public. |
Unknowns / Needs Verification
None identified. CI passed (Docker Build, Validate), auth patterns are consistent with the repository's established authorizeRequest helper, and test coverage explicitly validates auth rejection paths.
1 participant
Closes #386