[CRM][Frontend] - Update chip spans to use Chip component
Description
Right now we have a shared Chip component in src/lib/components/ui/Chip.tsx with variants (neutral, success, error, warning, primary) and a single source of styling. We also have helpers in src/lib/utils/status.utils.ts that map statuses to chip variants: getAssessmentStatusVariant, getDecisionStatusVariant, getSubmissionVariant, and to labels (getAssessmentStatusLabel, getDecisionStatusLabel). Some parts of the app already use <Chip> and these helpers (e.g. PositionCard, TaskCard, TaskTemplatePreviewPanel), but in other places we're still rendering chip-like UI with <span> plus manual Tailwind and getStatusBadgeColor. That duplication means if we change chip styling or someone adds a new "chip" with different classes, we get inconsistent look and feel across the app.
Your ask is to find every place where we're using a span (or similar) to show a chip-style badge and replace those with the Chip component, using the existing variant/label helpers where they fit so styling stays consistent.
One example: In src/lib/components/core/CandidateTable.tsx, the ASSESSMENT and DECISION columns both render status as a span with chipPaddingClass, getStatusBadgeColor, and manual classes:
cell: ({ row }) => {
const decision = row.original.decisionStatus ?? 'Pending';
const decisionLabel = formatDecisionLabel(decision);
return (
<span
className={cn(
`inline-flex items-center gap-1 rounded-md ${chipPaddingClass} text-xs font-medium`,
getStatusBadgeColor(decision)
)}
>
{decisionLabel}
</span>
);
},These should instead use <Chip variant={getDecisionStatusVariant(decision)}>{getDecisionStatusLabel(decision)}</Chip> (and the assessment column should use getAssessmentStatusVariant / getAssessmentStatusLabel). The same idea applies anywhere else that uses getStatusBadgeColor or ad-hoc chip-like classes on a span: swap to Chip + the appropriate variant/label helper.
If a given spot uses a label function that doesn't exist in status utils (e.g. a different casing or wording), either reuse an existing helper or add a small helper that stays consistent with the rest of the file; the important part is that the rendered element is <Chip> with a variant from our helpers so styling stays centralized. If you're unsure whether something should be a chip or a different component, check with the team.
Acceptance Criteria
[CRM][Frontend] - Update chip spans to use Chip component
Description
Right now we have a shared
Chipcomponent insrc/lib/components/ui/Chip.tsxwith variants (neutral,success,error,warning,primary) and a single source of styling. We also have helpers insrc/lib/utils/status.utils.tsthat map statuses to chip variants:getAssessmentStatusVariant,getDecisionStatusVariant,getSubmissionVariant, and to labels (getAssessmentStatusLabel,getDecisionStatusLabel). Some parts of the app already use<Chip>and these helpers (e.g.PositionCard,TaskCard,TaskTemplatePreviewPanel), but in other places we're still rendering chip-like UI with<span>plus manual Tailwind andgetStatusBadgeColor. That duplication means if we change chip styling or someone adds a new "chip" with different classes, we get inconsistent look and feel across the app.Your ask is to find every place where we're using a span (or similar) to show a chip-style badge and replace those with the
Chipcomponent, using the existing variant/label helpers where they fit so styling stays consistent.One example: In
src/lib/components/core/CandidateTable.tsx, the ASSESSMENT and DECISION columns both render status as a span withchipPaddingClass,getStatusBadgeColor, and manual classes:These should instead use
<Chip variant={getDecisionStatusVariant(decision)}>{getDecisionStatusLabel(decision)}</Chip>(and the assessment column should usegetAssessmentStatusVariant/getAssessmentStatusLabel). The same idea applies anywhere else that usesgetStatusBadgeColoror ad-hoc chip-like classes on a span: swap toChip+ the appropriate variant/label helper.If a given spot uses a label function that doesn't exist in status utils (e.g. a different casing or wording), either reuse an existing helper or add a small helper that stays consistent with the rest of the file; the important part is that the rendered element is
<Chip>with a variant from our helpers so styling stays centralized. If you're unsure whether something should be a chip or a different component, check with the team.Acceptance Criteria
Chipcomponent from@/lib/components/ui/Chip.@/lib/utils/status.utils.ts(e.g.getAssessmentStatusVariant,getDecisionStatusVariant,getAssessmentStatusLabel,getDecisionStatusLabel) instead ofgetStatusBadgeColorand manual classes.getStatusBadgeColor(or equivalent ad-hoc chip classes) on spans for chip-like UI; any still needed for non-chip usage is documented or removed.