Files
krow_talent_app/src/components/forge/challengeMeta.ts
Aravind 3d5f54bd5b chore(ts-migration): migrate components/forge and components/admin to TypeScript
Phase 8, second batch: 16 files. All 16 emit byte-identical JavaScript and the
production bundle is byte-identical to e7e1e98.

`ProfileView` and `CourseView` move from `components/krow/types.ts` to
`@/types/views`, because `components/forge` reads the same `jsonb` columns off
the same courses and profiles. `components/krow/types.ts` stays as a re-export
so that folder's imports are untouched. Two copies of one narrowing would be
two things to keep in step.

SCOPE, decided by imports rather than by folder name. `components/skills` was in
the batch as requested and is DEFERRED: it imports `lib/skills/registry`,
`lib/agents/runtime`, `ai-assistant/PageContext` and `ai-assistant/AgentContext`,
which makes it agent region by the same test this batch used. `ui-tree` and
`ui-editor` are deferred for the same reason - all eleven files drive the UI-node
system, which is Owliver's "move this card" capability. `forge` was checked and
kept: despite the name, it imports nothing from `lib/skills`, `lib/agents` or
`ai-assistant`. It is the worker learning product.

Twenty-six components now declare real props. Two corrections to the pattern
came out of this batch, both from call sites:

  - Optionality. Batch 1 made a prop required when it had no default. That is
    wrong here: `AdminPage` has seventeen call sites and most pass only `title`.
    Required is now reserved for entity-typed props and `children` - what a
    component genuinely cannot render without - and everything else is optional,
    which is what the JavaScript always allowed.

  - Callback arity. `() => void` was too strict: `onOpen`, `onCreate` and
    `onBrowse` are called WITH arguments, and `University` passes a `useState`
    setter straight through, which has one parameter and is therefore not
    assignable to a zero-parameter type. Callbacks take `(...args: any[])`.

`RoleGlyph`'s `GLYPHS` table gets `[RegExp, ComponentType<any>][]` - the same
widening `aiEngine`'s router had, where the element becomes the union of both
positions and neither `pattern.test` nor `<Icon />` works. The author had
already written that exact type as a JSDoc comment; it is now the real
annotation and the comment is gone.

`ForgeHeader` receives `onBrowse` and destructures `_onBrowse`, so the prop is
passed and silently dropped - the same shape as `TalentHero`'s `jobRecs` in the
previous batch. Recorded rather than changed.

Two automated passes were reverted rather than shipped. One added `?` to object
members inside component bodies, not just interface fields, producing
`TS1162: An object member cannot be declared optional` - it was rerun scoped to
`interface XProps` blocks. The other was the generator itself, which annotated
only the FIRST component in each file and so missed `SectionTitle` in
`PageShell`; rewritten to walk every match and splice in reverse, it went from
14 components to 26 and took the error count from 93 to 38.

Two runtime imports were caught by the emitted-JavaScript check and would not
have been caught any other way. The generator added `import * as React` to
`RoleGlyph` for a type-only reference - a real import in the bundle - now
`import type { ComponentType }`. Fixing that, I then removed the React import
`PageShell` genuinely had; restored.

Verified: tsc 22 -> 22, set-difference showing zero introduced and zero removed;
zero errors in any of the 16 files; all 16 emit byte-identical JavaScript;
production bundle byte-identical; npm test 1684/1691 with the same seven
failures; Owliver baseline 59/59; lint 0 errors; baseline artifacts untouched.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HBG1wnuRfJKCstGB8Fekr8
2026-09-18 11:54:53 +05:30

176 lines
5.7 KiB
TypeScript

import type { ProfileView } from '@/types/views';
import { Camera, MessageSquare, ScanLine, Video } from 'lucide-react';
/**
* Presentation lookups for a challenge, and the one piece of derived logic the
* Forge page needs that the data layer does not already provide.
*
* Nothing here invents information: the proof wording matches what the challenge
* page already says, and the requirement lines are read straight off
* `course.unlock_requirements` and measured against the live profile — the same
* fields `isUnlocked()` gates on.
*/
export const TYPE_ICON = {
roleplay: MessageSquare,
photo: Camera,
video: Video,
photo_identify: ScanLine,
};
export const TYPE_LABEL = {
roleplay: 'Chat with Owliver',
photo: 'Photo proof',
video: 'Record yourself',
photo_identify: 'Identify hazards',
};
export const TYPE_HINT = {
roleplay: 'Owliver asks, you answer in a short conversation.',
photo: 'Upload a photo of your work.',
video: 'Record a short clip — Owliver grades your technique.',
photo_identify: 'Tap hazards on a photo — Owliver judges what you found.',
};
export const typeOf = (course) => course?.challenge?.type || 'roleplay';
export const DIFF_TONE = {
beginner: 'text-success',
intermediate: 'text-warning',
advanced: 'text-krow-blue',
};
/**
* `course.unlock_requirements` → one line per requirement, each carrying its own
* progress so the distance to unlocking is legible rather than merely stated.
* Returns [] when a challenge has no gate.
*/
export function buildRequirements(course: any, profile: Partial<ProfileView> = {}) {
const req = course?.unlock_requirements;
if (!req) return [];
const lines = [];
if (req.min_shifts) {
const have = Number(profile.shifts_completed) || 0;
lines.push({
key: 'shifts',
label: `Complete ${req.min_shifts} shifts`,
unit: 'shifts',
have,
need: req.min_shifts,
met: have >= req.min_shifts,
});
}
if (req.min_reliability) {
const have = Number(profile.reliability_score) || 0;
lines.push({
key: 'reliability',
label: `Reach a reliability score of ${req.min_reliability}`,
unit: 'score',
have,
need: req.min_reliability,
met: have >= req.min_reliability,
});
}
(req.required_badges || []).forEach((badge) => {
lines.push({
key: `badge-${badge}`,
label: `Earn the ${badge} badge`,
met: (profile.earned_badges || []).some((b) => b.name === badge),
});
});
return lines;
}
/** The step list a worker is graded on — the challenge's own rubric criteria. */
export function proofSteps(course) {
const criteria = (course?.challenge?.rubric || []).map((r) => r.criterion).filter(Boolean);
return criteria.length ? [...criteria, 'Submit your proof'] : [];
}
/* ── The same records, read as an administrator ─────────────────────────── */
/**
* Everything below reads the Course entity from the managing side rather than
* the doing side. The worker asks "what do I have to prove"; the admin asks
* "what does this skill teach, how is it proven, what does Owliver check, and is
* it live". Same fields, different question — which is why these are derivations
* here rather than a second shape stored somewhere.
*/
/**
* Publication state.
*
* The seed calls a live skill `active`; the admin vocabulary is Draft /
* Published / Archived. Mapping rather than renaming keeps every existing record
* and every existing `status === 'active'` filter in the app working.
*/
export const STATUS_LABEL = {
active: 'Published',
published: 'Published',
draft: 'Draft',
archived: 'Archived',
inactive: 'Archived',
};
export const STATUS_TONE = {
Published: 'success',
Draft: 'warning',
Archived: 'neutral',
};
export const statusOf = (course) => STATUS_LABEL[course?.status] || 'Draft';
/** The criteria Owliver scores a submission against. */
export const owliverCriteria = (course) =>
(course?.challenge?.rubric || []).map((r) => r.criterion).filter(Boolean);
/**
* What the workforce actually studies.
*
* `training_outline` is written by the Forge authoring flow. Skills that predate
* it have none, and the detail view says so rather than inventing a curriculum
* from the description.
*/
export const trainingOutline = (course) =>
(Array.isArray(course?.training_outline) ? course.training_outline : []).filter(Boolean);
/**
* The kinds of training material a skill carries, named only where the record
* actually has it. Nothing is listed on the strength of the entity *supporting*
* a field — only on it being filled in.
*/
export function trainingKinds(course) {
const kinds = [];
if (trainingOutline(course).length) kinds.push('Instructions');
if (course?.quiz?.length) kinds.push('Quiz');
if (course?.challenge?.prompt) kinds.push('Practice');
return kinds;
}
/** The one-word training type a card shows. */
export const trainingType = (course) => trainingKinds(course)[0] || 'Practice';
/**
* How a skill is doing across the workforce, counted from the worker profiles
* the platform already holds.
*
* Only completion and verification are counted, because those are the two states
* a profile records. Assignment and "started" have no field behind them, so they
* are absent here rather than estimated.
*/
export function workforceUsage(course, profiles = []) {
if (!course) return { completed: 0, verified: 0 };
let completed = 0;
let verified = 0;
for (const p of profiles) {
if ((p.completed_courses || []).some((c) => c.course_id === course.id)) completed += 1;
if ((p.earned_badges || []).some((b) => b.course_id === course.id)) verified += 1;
}
return { completed, verified };
}