Carry next_design's split on the human-queue design lane, so the dashboard can show the inbox apart from the defect

[thedavidmeister]

Closes #240

Pairs with rainlanguage/rain-org-health#168 — the renderer half. The two land together: this PR emits the split, that one draws it. Neither is harmful alone (an old dashboard ignores the new fields; the new dashboard falls back on a snapshot without them), but the number on the panel is only fixed when both are in.

What the mismatch was

Measured 2026-08-09T08:44Z, same moment, both tools: the dashboard said 6 design PRs waiting on a human; /ndd said presentable 0, noQuestion 6. The snapshot's lanes["vetter-verdicts"]["ai:design"] carried the raw label total, and next_design withheld all six as "no trusted comment raises a design question". Draining the whole ai:design queue that day did not move the box, because the number it drew was never the number of rulable rows.

The schema

human-queue --json now attaches next_design's own partition to the design cell:

"lanes": { "vetter-verdicts": { "ai:design": {
  "count": 6,                       // UNCHANGED — the raw label total, for every existing consumer
  "breakdown": {                    // NEW — every bucket, zeros included
    "presentable": 0,               //   what /ndd will serve: the human inbox
    "noQuestion": 6,                //   labelled, no trusted question behind it: a defect bucket
    "draft": 0, "unaddressable": 0, "fetchErrors": 0
  },
  "prs": [ { "repo": "…", "number": 412, "url": "…", "title": "…",
             "bucket": "noQuestion" } ]   // NEW — one bucket per entry, same spellings
} } }

plus two counts keys mirroring the headline buckets off that same breakdown:

"counts": { "design": 6, "designPresentable": 0, "designNoQuestion": 6 }

counts.design keeps its exact meaning (the raw cell size, per #228), so the existing series is continuous. The rollup copies counts verbatim, so queue-history-line carries the two new series with no change to the appender or to refresh-human-queue.sh.

One enumeration, one classifier. The split does not re-implement "does a trusted comment raise a question". It routes each cell member through next_design's own stages — nd_hit_class first (so a draft is withheld fetch-free, exactly as the live queue does it), then nd_outcome over the same gh pr view read. Both matches are exhaustive on purpose: a new arm in either stage refuses to compile until the split gives it a bucket. The members are selected by the same classify_lane call lanes_doc buckets with, never by a label read, so the split describes exactly the list it is emitted beside (a PR wearing ai:design under ai:close-candidate is in neither).

breakdown.<key> is COUNTED OFF the annotated entries rather than copied from the split, so it equals the number of prs rows carrying that bucket by construction.

Cost: one gh pr view per design-lane member, --json only — the daily review prints the cell whole and pays nothing.

Out of scope, per the issue: the search-index lag on a fresh ruling. No retry loop, and no log line either — refresh-human-queue.sh has no non-trivial place to put one that says more than the existing stamped lines already do.

QA

• Discriminating tests: design_split_tests::{the_members_are_the_cells_own_prs, a_member_lands_where_ndd_would_put_it, the_breakdown_partitions_the_cell_it_is_attached_to, a_draft_member_is_filed_apart_without_a_read, an_empty_design_lane_emits_zeroes_not_a_cell, the_counts_mirror_the_breakdown_and_the_raw_series_survives} — all six name functions that do not exist on base, so they cannot compile against it; their discrimination is established by the mutation pass below rather than by a base run. state_descriptor_tests::every_descriptor_occupancy_source_resolves_in_the_emitted_document (pre-existing, extended here) fails on base-plus-emitter-removed — verified as mutant M8, which it names in its own words: "counts.designPresentable must emit even over an empty design lane".
• Mutations applied: 8 mutants over the changed lines, 8/8 killed, 0 survivors.
  • M1 design_lane_members reads the label instead of calling classify_lane → killed by the_members_are_the_cells_own_prs (the dominated ai:close-candidate / ai:blocked-on members enter the split but not the cell)
  • M2 design_bucket swaps Presentable/NoQuestion → killed by a_member_lands_where_ndd_would_put_it
  • M3 design_member_hit hardcodes isDraft: false → killed by a_draft_member_is_filed_apart_without_a_read (its fetch seam asserts the draft is never read)
  • M4 attach_design_breakdown counts but never annotates the entries → killed by the_breakdown_partitions_the_cell_it_is_attached_to
  • M5 design_breakdown_count reads the cell's count instead of its breakdown → killed by the_counts_mirror_the_breakdown_and_the_raw_series_survives
  • M6 the two counts keys are wired to each other's bucket → killed by the same test (the fixture is deliberately asymmetric, 1 presentable vs 2 noQuestion, so a swap cannot pass)
  • M7 attach_design_breakdown drops the zero-valued keys → killed by the_breakdown_partitions_the_cell_it_is_attached_to (key set derived from DesignBucket::ALL, not typed twice)
  • M8 the counts mirror loop is deleted → killed by an_empty_design_lane_emits_zeroes_not_a_cell, the_counts_mirror_the_breakdown_and_the_raw_series_survives, and the extended every_descriptor_occupancy_source_resolves_in_the_emitted_document
• Oracle: next_design's own stated invariant, aiDesign == draft + unaddressable + presentable + noQuestion + fetchErrors + archivedRepo (the DesignQueueCounts doc comment), and the live 2026-08-09 measurement in the issue (6 labelled / 0 presentable / 6 noQuestion) reproduced as the fixture shape. Fixture comment bodies are built by the REAL writers (state_comment, verdict_comment), so they cannot drift from what the pipeline actually posts. archivedRepo has no twin here and the reason is structural, not an omission: producer_pr_inventory withholds archived-repo PRs before any lane is built, so this cell can never hold one.
• Category check: issue asks (a) the snapshot carry the same breakdown next_design computes, through the same classifier — done, via nd_hit_class/nd_outcome; (b) count kept for backward compat with the split beside it — done; (c) the prs list split the same way — done, as a per-entry bucket annotation, which is what lets a consumer filter one list rather than reconcile several; (d) queue-history-line carrying the new keys so the time-series can draw them — done, and it needed no change at all, since it copies counts verbatim; (e) the dashboard rendering — the paired rain-org-health PR.

Summary by CodeRabbit

• New Features

  • Added draft-status information to pull request inventory results.
  • Added design-lane categorization for presentable, no-question, draft, unaddressable, and fetch-error items.
  • Expanded JSON output with per-item categories and zero-inclusive summary breakdowns.
  • Preserved overall design counts while adding separate presentable and no-question totals.

• Bug Fixes

  • Improved handling of empty design lanes and draft pull requests.
  • Added validation to ensure categorized results remain consistent.

[coderabbitai]

Warning

Review limit reached

@thedavidmeister, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 50 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4fb37d43-c71f-4437-a267-640097f5b9fa

📥 Commits

Reviewing files that changed from the base of the PR and between 4adfe31 and a23b8e5.

📒 Files selected for processing (1)

• pr-review-report-rs/src/main.rs

Walkthrough

The PR tracks draft state through PR inventory records and adds JSON-only design-lane buckets. It annotates design records, emits zero-inclusive breakdowns, and adds presentable and no-question counts while retaining the raw design count.

Changes

Design lane inventory

Layer / File(s)	Summary
Propagate draft state pr-review-report-rs/src/main.rs	GitHub search results now provide draft state. Inventory tuples and QueuePr records preserve the parsed value and default missing or invalid values to non-draft.
Classify design buckets pr-review-report-rs/src/main.rs	JSON output selects design members, classifies them with the existing design classifier, performs bounded detail reads, annotates records, and generates zero-inclusive bucket breakdowns.
Expose and validate design counts pr-review-report-rs/src/main.rs	Output retains the raw design count and adds designPresentable and designNoQuestion. Documentation, fixtures, and count validation cover the expanded shape.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant HumanQueueJson
  participant DesignSplitPipeline
  participant DesignClassifier
  participant GitHubDetailReads
  HumanQueueJson->>DesignSplitPipeline: request design breakdown
  DesignSplitPipeline->>DesignClassifier: classify design PR
  DesignSplitPipeline->>GitHubDetailReads: fetch bounded PR details
  GitHubDetailReads-->>DesignSplitPipeline: return detail results
  DesignSplitPipeline-->>HumanQueueJson: return bucket annotations and breakdown

Loading

Possibly related PRs

• rainlanguage/issue-pr-cron#25: Related PR inventory and GitHub search handling.
• rainlanguage/issue-pr-cron#47: Related worklist JSON state and draft/design-lane data.
• rainlanguage/issue-pr-cron#126: Related PR detail fetching and bounded concurrency logic.

Suggested labels: ai:ready

Suggested reviewers: claude

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The changes implement issue #240 by separating presentable work, noQuestion defects, other buckets, raw counts, snapshot data, and history counts.
Out of Scope Changes check	✅ Passed	The reported changes support issue #240 and its testing requirements; no unrelated scope is evident.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: splitting the design lane so the dashboard separates the human inbox from defects.

✨ 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 design-lane-split-240

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@pr-review-report-rs/src/main.rs`:
- Around line 17443-17465: Update DesignBucket::ALL to be generated through an
exhaustive match over every DesignBucket variant, rather than maintaining an
independent literal array. Preserve the existing ordering and ensure adding a
new variant causes compilation to require updating this enumeration, keeping
breakdown zero-inclusive.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 4c117b30-b22f-4429-9204-852abc16c68a

📥 Commits

Reviewing files that changed from the base of the PR and between 597a13c and 4adfe31.

📒 Files selected for processing (1)

• pr-review-report-rs/src/main.rs

[thedavidmeister]

Reviewed a23b8e5: pass — members are selected by the same classify_lane call lanes_doc buckets with and each is bucketed through nd_hit_class then nd_outcome, so the split is next_design's own stages rather than a second detector that could drift. DesignBucket::ALL/ordinal/COUNT are pinned by a const-eval assertion, so a new variant cannot silently stop emitting its key at zero. Breakdown seeds every bucket from ALL and counts off the annotated entries; checked lanes_doc builds count: items.len() with no truncation, so those entries are the whole population and the breakdown cannot read short of count. Fan-out via map_bounded. count keeps its prior meaning and the new keys are additive, so an old consumer is unaffected. 8/8 mutants killed.

[thedavidmeister]

Reviewed a23b8e5: pass

Rulings-conformance: checked the artifact against CLAUDE.md's rulings section and against every ruling the human stated for this work.

• "dash should match ndd" (human, 2026-08-09, the ruling that produced Dashboard design-lane count must match /ndd: presentable is the inbox, noQuestion is a defect bucket #240). OBEYED: the emitted breakdown is the split /ndd itself computes, so the dashboard renders the same partition the command serves rather than a parallel one.
• "every count filed under owner human is a count some human command will present" (the invariant recorded in Dashboard design-lane count must match /ndd: presentable is the inbox, noQuestion is a defect bucket #240). OBEYED on the emitter side: presentable is emitted as its own key and mirrored to counts.designPresentable, so the renderer has the servable number to draw and does not have to derive it.
• ONE ENUMERATION, ONE CLASSIFIER (CLAUDE.md; the standing rule that a second detector is the drift defect). OBEYED and this is the load-carrying check: design_lane_members selects with the same classify_lane call lanes_doc buckets with, and design_bucket routes each member through nd_hit_class then nd_outcome — next_design's own stages, not a reimplementation.
• "human decisions are transitions to a state, not a separate state" (human, this session; ai:reject and human:reject are one state: same owner, same action, split only by who ruled #133/RULED: an answered design question routes straight to producer rework, same as a rejection #219 in CLAUDE.md). NOT ENGAGED by this diff — it adds no state, no park and no ruling verb; it partitions an existing population for display. The separate humanRuled fossil this ruling targets is untouched here and is being filed on its own.
• "never assume the population is small in a tool" (human, the ruling behind Fan the three human state-loads' per-candidate fetches out through map_bounded #236). OBEYED: the per-member fetch fans out through map_bounded, the same bounded pool the queue loaders use.
• Additive-only schema, so no consumer of the prior shape is broken: count keeps its exact prior meaning and every new key is beside it.

Merging with --merge --admin per the standing no-squash rule; all checks green, no red to account for.