fix(view): unusable-board reads surface as JSON 400, not a text/plain 500

[mabry1985]

The bug

On an agent where the board is unusable — no project_board.repo bound, cwd has no .beads/, br init fails (e.g. a read-only cwd on a desktop-spawned manager) — the board view died with:

Could not load the board: SyntaxError: The string did not match the expected pattern.

GET /features and GET /features/{fid} were the only store-touching routes outside _guard, so the BoardError escaped as FastAPI's text/plain 500 and WebKit's r.json() threw the cryptic parse error instead of showing the (already actionable) message.

The fix

• api: both GET routes now go through _guard like every other route → JSON 400 carrying the BoardError message ("repo '.' has no beads workspace … set project_board.repo / db_path").
• view: api() parses defensively — a JSON error body throws its detail, a non-JSON body throws HTTP <status>; load()'s catch renders that. Without this, the JSON 400 would have silently rendered an empty board (r.features || []).

Tests

test_unusable_board_reads_surface_as_json_400_not_500 — a store raising BoardError on reads → both GETs answer 400 JSON with the message. 202 tests pass; ruff check + format clean.

🤖 Generated with Claude Code

[protoquinn]

👀 Quinn is reviewing — verdict (PASS / WARN / FAIL) + findings to follow.

[protoquinn]

QA Audit — PR #60 | fix(view): unusable-board reads surface as JSON 400, not a text/plain 500

VERDICT: PASS

---

CI Status

• test: success ✅

Diff Review

• api.py: both GET /features and /features/{fid} now route through _guard, consistent with every other store-touching route. The _feature handler correctly scopes _guard to just the store call so the 404 path remains distinct.
• board_view.py: api() now parses defensively — a JSON error body throws its detail, a non-JSON body throws HTTP <status>. This catches both the new JSON 400 and any future non-JSON error.
• tests/test_api.py: test_unusable_board_reads_surface_as_json_400_not_500 covers both GET routes with a BrokenStore raising BoardError, asserting 400 + message.

Observations

• No issues found. The fix is minimal (3 files, ~36 lines), follows the established _guard pattern consistently, and the test covers the exact regression path described in the PR.
• _feature's scoping (_guard on get_feature only, 404 outside) is correct — a BoardError becomes 400, a missing feature stays 404.

— Quinn, QA Engineer

[protoquinn]

Submitted APPROVE review on protoLabsAI/projectBoard-plugin#60.