fix(groomer): promote claimable lane work

[joryirving]

Fixes the groomer gap that left issues in the Board Backlog when a model selected a claimable lane or promote_to_ready but omitted actionability: "ready".

The validation boundary now enforces status/ready for every readiness signal and covers the #406 regression.

[its-saffron]

AI Automated Review

Full PR review.

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

Recommendation: Approve

This PR tightens the groomer validation boundary so that every readiness signal — actionability, nextGroomingAction, and lane selection — is handled consistently. The change is well-scoped, tested, and CI-clean.

Change-by-Change Findings

src/lib/groomer/schema.ts

The core logic introduces a readyForWork boolean that ORs together three readiness signals:

• actionability === "ready" (existing behavior)
• nextGroomingAction === "promote_to_ready" (new)
• isClaimableLane(lane.id) (new)

Both cross-field invariants (claimable-lane coercion and status/ready label enforcement) now gate on readyForWork instead of only actionability. This closes the gap where a small model omits actionability while picking a claimable lane like local, leaving the issue stranded in the board backlog.

The changes are additive and conservative — they only kick in when readiness is signaled through any of the three paths, and they coerce to safe defaults rather than rejecting input.

src/lib/groomer/schema.test.ts

Two new test cases:

1. Claimable lane without actionability — validates that lane.id: "local" with no actionability field results in status/ready being added.
2. Explicit promote_to_ready action — validates that nextGroomingAction: "promote_to_ready" with backlog lane correctly promotes lane to default claimable and adds status/ready.

Existing tests at lines 435, 452, 465 were updated to include status/ready in labelsToAdd — this is correct because those tests now implicitly signal readiness via claimable lane aliases (normal/escalated/local), triggering the invariant.

Required Checks

✅ review migration for data loss risk

Does not apply. This PR contains zero database migrations or schema changes. The diff touches only two TypeScript files in src/lib/groomer/. No Prisma migration files are created or modified, no schema.prisma changes exist, and no data transformation logic is introduced. There is no data-loss surface.

✅ test migration on a copy of production schema

Does not apply. As noted above, no migration exists in this PR to test. The change is a pure in-memory validation logic fix in validateGroomerOutput() that operates on parsed JSON input before any database write.

Standards Compliance

• Prisma/schema conventions: N/A — no schema or migration files touched.
• Code standards: TypeScript types, instanceof Error pattern, and validation-before-write are all respected by the existing validateGroomerOutput function; this PR extends its coverage without violating existing patterns.
• No secrets committed: No secrets, .env, or build-output files are in scope.

Linked Issue Fit

No linked issue body was present in the corpus. The PR body references the problem this solves: issues stranded in Board Backlog when a model signals readiness through lane selection or promote_to_ready but omits actionability: "ready". The implementation matches this description — readyForWork now aggregates all three signals.

Evidence Provider Findings

No evidence providers were configured for this review.

Tool Harness Findings

No tool harness findings were produced (native tool-calling loop issued no calls; reviewed corpus directly).

CI Check Results

All CI checks passed: Docker Build, Lint, Tests, Build, Typecheck — all success.

Unknowns / Needs Verification

None. The diff is self-contained, the fix is localized to validateGroomerOutput, and the test coverage is comprehensive for the new code paths.