feat(ui): raw-status chips on Kanban cards (U2)#386
Conversation
Closes the biggest visual gap vs the .lazyweb kanban mock: cards now carry a small chip next to the id showing the source system's raw status (mock: Draft/Coder/Merged). - libs/ui: UiTask.statusChip (UiTaskBadge; distinct from outcome badges), rendered in the card top row; card-top flex/gap CSS. - electron adapter: UiTaskBadgeLabels gains statusChips (per raw desktop status, injected from i18n via the existing labels getter); chip tones map the raw status (backlog/queue neutral, in_progress info, reviews warn, done/pr_created good, error bad). New pilot.statusChips.* keys (en+fr). - web adapter: opt-in RestClientOptions.statusChipLabel keyed by the NORMALIZED backend status (suffix-stripped via the new exported normalizeStatus); tone follows the mapped column. The pilot passes labels from tasks:status.* (added the missing 'initialized' key en+fr). No option -> no chips (back-compat; demo/test clients unaffected). - also: Sonar S7735 (negated ternary) fixed in the web detail mapper. - tests: electron 12/12 (chip labels/tones + updated exact-shape case), web 13/13 (opt-in absence, callback labeling with decorated status, raw fallback). Verified: libs/ui + electron tsc exit 0; web tsc adds no new errors over the 5 pre-existing baseline; chips visually confirmed against the mock in the live demo (Draft neutral, Coder info-blue next to the id). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughAdds a ChangesStatus chip feature
Estimated code review effort: 3 (Moderate) | ~25 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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 `@apps/web-frontend/src/i18n/locales/fr/tasks.json`:
- Around line 16-17: The French status label for the initialized state is using
the wrong gender form and should match the other standalone status descriptors
in tasks.json. Update the `initialized` translation in the locale entry
alongside the other status keys (`cancelled`, `completed`, `archived`, `failed`)
in `tasks.json` so it uses the masculine form consistent with the implied
`statut`, unless this key is intentionally tied to a feminine noun elsewhere.
In `@apps/web-frontend/src/pages/KanbanPilot.tsx`:
- Around line 63-68: Tighten CHIP_LABEL_KEYS in KanbanPilot so its keys are
limited to the normalized status values produced by normalizeStatus/mapStatus
instead of using Record<string, string>. Define or reuse a narrow union type for
the allowed statuses and apply it to the CHIP_LABEL_KEYS declaration so typos or
drift between the adapter and this label map are caught at compile time.
- Around line 70-81: The AutoCodeClient is being recreated whenever the
translation function changes, which makes the injected client unstable and
triggers unnecessary refetches in useTasks. In KanbanPilot, keep the
createRestAutoCodeClient instance stable by removing t from the useMemo
dependency list and moving the translation lookup used by statusChipLabel behind
a ref or equivalent stable indirection so the label text can update without
recreating the client.
🪄 Autofix (Beta)
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: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: b90fcc57-a17d-478f-889b-bad2ba6465b3
📒 Files selected for processing (13)
apps/frontend/src/renderer/__tests__/autoCodeClient.test.tsapps/frontend/src/renderer/components/KanbanPilotView.tsxapps/frontend/src/renderer/lib/autoCodeClient.tsapps/frontend/src/shared/i18n/locales/en/kanban.jsonapps/frontend/src/shared/i18n/locales/fr/kanban.jsonapps/web-frontend/src/api/autoCodeClient.test.tsapps/web-frontend/src/api/autoCodeClient.tsapps/web-frontend/src/i18n/locales/en/tasks.jsonapps/web-frontend/src/i18n/locales/fr/tasks.jsonapps/web-frontend/src/pages/KanbanPilot.tsxlibs/ui/src/client/types.tslibs/ui/src/screens/KanbanBoard.csslibs/ui/src/screens/KanbanBoard.tsx
… (U2 review) - KanbanPilot: read translations through a ref so the AutoCodeClient identity survives locale switches (useTasks refetches on client change), mirroring the Electron pilot's labelsRef pattern - CHIP_LABEL_KEYS: Record<string,string> -> Record<ChippedStatus,string> with an Object.hasOwn guard, so a typo'd status key fails to compile - fr tasks:status.initialized: Initialisée -> Initialisé (masculine, consistent with sibling standalone status labels) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Oleg Miagkov <mrobenner@gmail.com>
|
1 participant
Closes the biggest visual gap vs the
.lazywebkanban mock (per.lazyweb/ui-proof/PROOF.md): cards now carry a small chip next to the id showing the source system's raw status — mock'sDraft/Coder/Merged.What's delivered
UiTask.statusChip(aUiTaskBadge, distinct from outcomebadges), rendered in the card's top row;card-topflex/gap CSS.UiTaskBadgeLabelsgainsstatusChips(label per raw desktop status, injected from i18n through the existing stable labels getter); tones map the raw status (backlog/queue→neutral,in_progress→info, reviews→warn,done/pr_created→good,error→bad). Newpilot.statusChips.*keys (en+fr).RestClientOptions.statusChipLabelkeyed by the normalized backend status (suffix-stripped via the newly exportednormalizeStatus); tone follows the mapped column. The pilot supplies labels fromtasks:status.*(added the missinginitializedkey en+fr). No option → no chips (back-compat).S7735negated ternary that slipped into feat(ui): task detail wired into both apps via getTask adapters (U2) #385's merge.Verification
tscexit 0; web vitest 13/13,tscadds no new errors over the 5 pre-existing baseline test-file errors;libs/uitsc clean.007 · Draft(neutral) and004 · Coder(info) next to the card ids, matchingdesktop-kanban-board-v2.html.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes