docs/junior-dashboard-delegation-prd.md

PRD — Junior/Intern Delegation Plan for GrowQR Dashboard MVP

Date: June 3, 2026
Owner: Senior engineer / user
Delegate audience: interns / junior engineers
Target repo for all implementation: growqr-dashboard
Deadline context: same-day AVPS deploy, 6-hour session
Primary objective: make non-critical dashboard pages demo-ready while senior engineer owns workflow/chat/API/backend integration.

---

1. Executive Summary

We are shipping a testable GrowQR dashboard + backend to AVPS today. The senior engineer will own all critical integration work: backend workflow routes, dashboard API proxy/client, workflow start/detail behavior, and chat surfaces.

Junior/intern work should still stay inside growqr-dashboard, but the target has changed from static shells to as much feature parity as possible with growqr-app/frontend for Interview, Roleplay, and Resume. The senior engineer still owns backend changes, workflow/chat integration, Clerk/proxy decisions, and deployment, but juniors can now port frontend service UI, types, hooks, and client adapters that call the new backend service gateway or direct service WebSockets.

Interns should not touch backend, Clerk middleware, workflow/chat logic, or deployment configuration. They may port frontend-only service code and may add dashboard service API clients/types under senior-approved paths.

---

2. Current Repo / Branch State

Run from workspace root: /Users/puter/Workspace/growqr.

Repo	Branch	Role	Intern access
growqr-dashboard	main tracking origin/main	Only implementation target	✅ edit only here
growqr-backend	chore/release tracking origin/chore/release	Production backend / API	❌ do not edit
growqr-next-frontend	main tracking origin/main	Reference UI only	👀 read only
growqr-app	main, behind origin by 1	Reference UI only	👀 read only

Existing uncommitted changes to be careful around

Current growqr-dashboard has existing changes. Juniors must not overwrite unrelated work.

Observed modified/untracked files:

.gitignore
app/layout.tsx
app/social/page.tsx
components/LeftRail.tsx
components/tiles/SuggestionsTile.tsx
package.json
middleware.ts
pnpm-lock.yaml
pnpm-workspace.yaml
package-lock.json deleted

Instruction: before editing, run:

git -C growqr-dashboard status --short --branch

If a file is already modified and not assigned below, do not edit it without asking.

---

3. Non-Negotiable Rules

1. Work only in growqr-dashboard.
2. Do not edit growqr-backend.
3. Do not edit growqr-next-frontend or growqr-app; use them only as references.
4. Do not edit backend code. Frontend calls are allowed only through approved dashboard service clients or direct Interview/Roleplay WS env vars.
5. Do not touch global chat implementation.
6. Do not touch workflow start/run/current-run logic.
7. Do not touch Clerk middleware/auth/proxy/deployment envs. Document required env vars instead of changing deployment config.
8. No homepage work today. Homepage is explicitly deferred.
9. No billing, entitlement, community, events, mentor, pathways, suggestions, rewards, social polish, E2E tests, mobile polish, or advanced animations.
10. Keep it functional and clean, not perfect.

---

4. Product Goal for Delegated Work

When the team tests the deployed MVP, they should be able to click around and see credible pages for:

• Interview practice
• Roleplay practice
• Resume review/building
• Q Score / Queue Score
• Career analytics

The first fallback can be static/demo-driven, but the desired target is real frontend parity with growqr-app/frontend: configure sessions, launch direct live Interview/Roleplay WebSockets, show review/feedback when available, and support Resume list/upload/analyze/preview where the backend gateway supports it.

---

5A. Full-Parity Service Architecture Context

Old frontend behavior in growqr-app/frontend

growqr-app/frontend uses three patterns:

1. Old orchestrator WebSocket for page setup, review polling, and agent data:

NEXT_PUBLIC_ORCHESTRATOR_WS_URL/ws/agent?token=...

Old action names:

configure_interview
get_review
configure_roleplay
get_roleplay_review

2. Direct Interview WebSocket for live audio/avatar interview sessions:

NEXT_PUBLIC_INTERVIEW_WS_URL/api/v1/session/:sessionId
Default: ws://localhost:8007/api/v1/session/:sessionId

3. Direct Roleplay WebSocket for live audio/avatar roleplay sessions:

NEXT_PUBLIC_ROLEPLAY_WS_URL/api/v1/roleplays/session/:sessionId
Default: ws://localhost:8008/api/v1/roleplays/session/:sessionId

4. Resume REST service for templates, resumes, upload, parse, AI analysis, preview/export:

NEXT_PUBLIC_API_URL=http://localhost:8000/api/v1

New backend gateway available in growqr-backend

The new backend already exposes service gateway routes under /services:

/services/interview/configure
/services/interview/preview
/services/interview/approve
/services/interview/review/:sessionId
/services/interview/artifacts/:sessionId/:artifactType
/services/interview/sessions/:sessionId/video/upload-url
/services/interview/sessions/:sessionId/video/uploaded

/services/roleplay/configure
/services/roleplay/preview
/services/roleplay/approve
/services/roleplay/review/:sessionId
/services/roleplay/artifacts/:sessionId/:artifactType
/services/roleplay/sessions/:sessionId/video/upload-url
/services/roleplay/sessions/:sessionId/video/uploaded

/services/resume/templates
/services/resume/resumes
/services/resume/resumes/:resumeId
/services/resume/resumes/:resumeId/analyze
/services/resume/resumes/:resumeId/suggestions
/services/resume/ai/copilot
/services/resume/ai/optimize-summary
/services/resume/ai/optimize-experience
/services/resume/ai/suggest-skills
/services/resume/ai/generate-summary
/services/resume/resumes/:resumeId/versions
/services/resume/resumes/:resumeId/preview

Full-parity strategy for dashboard

• Use the new backend REST service gateway for configure/preview/approve/review/resume operations.
• Use direct frontend WebSocket connections to Interview and Roleplay services for live sessions.
• Do not recreate the old orchestrator WebSocket in the dashboard. Replace old sendAction(...) flows with REST calls.
• Preserve old WebSocket message contracts for live session hooks as much as possible.

Required frontend env vars to document / expect

Do not edit deployment env. Document these if missing:

NEXT_PUBLIC_GROWQR_BACKEND_URL=https://<new-backend>
NEXT_PUBLIC_INTERVIEW_WS_URL=wss://<interview-service>/api/v1
NEXT_PUBLIC_INTERVIEW_ARTIFACTS_URL=https://<interview-service>/api/v1
NEXT_PUBLIC_ROLEPLAY_WS_URL=wss://<roleplay-service>/api/v1
NEXT_PUBLIC_ROLEPLAY_ARTIFACTS_URL=https://<roleplay-service>/api/v1

Resume should preferably go through the dashboard/backend proxy, not direct public resume service, unless senior engineer approves otherwise.

Old source files to port from

growqr-app/frontend/src/hooks/useInterviewSession.ts
growqr-app/frontend/src/hooks/useInterviewMedia.ts
growqr-app/frontend/src/hooks/useInterviewReview.ts
growqr-app/frontend/src/hooks/useRoleplaySession.ts
growqr-app/frontend/src/hooks/useRoleplayReview.ts
growqr-app/frontend/src/lib/interview/types.ts
growqr-app/frontend/src/lib/roleplay/types.ts
growqr-app/frontend/src/lib/api/interview.ts
growqr-app/frontend/src/lib/api/roleplay.ts
growqr-app/frontend/src/lib/api/resumes.ts
growqr-app/frontend/src/types/resume.ts
growqr-app/frontend/src/components/interview/*
growqr-app/frontend/src/components/roleplay/*
growqr-app/frontend/src/components/resume/*

Port carefully. Do not blindly copy imports that reference old app-only contexts, billing, onboarding, or layout. Create dashboard-compatible wrappers where needed.

---

5. Priority-Ordered Delegated Tasks

Tasks are listed in priority order. Start from the top. If time runs out, leave lower-priority tasks unfinished.

---

P0 — Frontend Service Parity Foundation

Owner

Junior/intern, with senior review before final wiring.

Files to create

growqr-dashboard/lib/services/service-config.ts
growqr-dashboard/lib/services/interview-service.ts
growqr-dashboard/lib/services/roleplay-service.ts
growqr-dashboard/lib/services/resume-service.ts
growqr-dashboard/types/interview.ts
growqr-dashboard/types/roleplay.ts
growqr-dashboard/types/resume.ts

Goal

Create dashboard-compatible service clients/types that replace the old orchestrator action pattern with explicit REST calls to the new backend service gateway, while preserving direct WS base URLs for live Interview/Roleplay.

Requirements

Service config

Expose frontend-safe constants:

export const GROWQR_BACKEND_URL = process.env.NEXT_PUBLIC_GROWQR_BACKEND_URL ?? "";
export const INTERVIEW_WS_BASE_URL = process.env.NEXT_PUBLIC_INTERVIEW_WS_URL ?? "ws://localhost:8007/api/v1";
export const INTERVIEW_ARTIFACTS_BASE_URL = process.env.NEXT_PUBLIC_INTERVIEW_ARTIFACTS_URL ?? "http://localhost:8007/api/v1";
export const ROLEPLAY_WS_BASE_URL = process.env.NEXT_PUBLIC_ROLEPLAY_WS_URL ?? "ws://localhost:8008/api/v1";
export const ROLEPLAY_ARTIFACTS_BASE_URL = process.env.NEXT_PUBLIC_ROLEPLAY_ARTIFACTS_URL ?? "http://localhost:8008/api/v1";

If the senior API proxy exists, REST calls should use /api/growqr/services/... instead of direct backend URL.

Interview REST client

Implement functions equivalent to old orchestrator actions:

configureInterview(payload)       // POST /services/interview/configure
previewInterview(payload)         // POST /services/interview/preview
approveInterview(sessionId)       // POST /services/interview/approve
getInterviewReview(sessionId)     // GET  /services/interview/review/:sessionId
requestInterviewVideoUploadUrl(sessionId)
confirmInterviewVideoUploaded(sessionId)

Roleplay REST client

configureRoleplay(payload)        // POST /services/roleplay/configure
previewRoleplay(payload)          // POST /services/roleplay/preview
approveRoleplay(sessionId)        // POST /services/roleplay/approve
getRoleplayReview(sessionId)      // GET  /services/roleplay/review/:sessionId
requestRoleplayVideoUploadUrl(sessionId)
confirmRoleplayVideoUploaded(sessionId)

Resume REST client

Implement what the new backend gateway currently supports:

listTemplates()
listResumes()
createResume(payload)
getResume(resumeId)
updateResume(resumeId, payload)
analyzeResume(resumeId, payload?)
getResumeSuggestions(resumeId)
optimizeSummary(payload)
optimizeExperience(payload)
suggestSkills(payload)
generateSummary(payload)
listVersions(resumeId)
createVersion(resumeId, payload)
getPreview(resumeId)

Also document missing full-parity endpoints if needed:

multipart upload
parse resume
delete resume
set primary resume
binary PDF/original PDF export
analysis report PDF export

Acceptance criteria

• Clients compile.
• No backend code edited.
• No old orchestrator dependency remains in new dashboard service clients.
• Missing parity endpoints are clearly listed in handoff notes.

---

P1 — Port Live Interview Frontend Flow

Owner

Junior/intern for frontend port; senior reviews service call wiring.

Files to create/update

growqr-dashboard/app/features/interview/page.tsx
growqr-dashboard/hooks/useInterviewSession.ts
growqr-dashboard/hooks/useInterviewMedia.ts
growqr-dashboard/hooks/useInterviewReview.ts
growqr-dashboard/components/interview/*

Goal

Port as much of the old Interview UX as possible from growqr-app/frontend into dashboard.

Required behavior

1. Configure interview via new REST client, not old orchestrator.
2. Receive or store session_id from configure response.
3. Connect live session directly to:

${NEXT_PUBLIC_INTERVIEW_WS_URL}/session/:sessionId

4. Preserve old WS protocol:

Frontend sends:

session.start
audio.input
session.finish
avatar.frontend_ready
presence_metrics_summary

Frontend receives:

session.ready
assistant.audio
assistant.audio.interrupted
assistant.transcript
candidate.transcript
turn.saved
session.completed
session.time_warning
session.context.warning
session.terminated
error

5. Poll review via REST:

GET /services/interview/review/:sessionId

Cut lines

If time is short, keep the UI flow but disable or stub:

• LiveKit/avatar rendering
• video recording/upload
• advanced video analysis

Do not block live audio/session parity on those.

Acceptance criteria

• User can configure/start an interview session when services are available.
• Direct WS hook uses dashboard env vars.
• Transcript renders.
• Finish session works.
• Review area attempts real review polling and degrades gracefully.

---

P2 — Port Live Roleplay Frontend Flow

Owner

Junior/intern for frontend port; senior reviews service call wiring.

Files to create/update

growqr-dashboard/app/features/roleplay/page.tsx
growqr-dashboard/hooks/useRoleplaySession.ts
growqr-dashboard/hooks/useRoleplayReview.ts
growqr-dashboard/components/roleplay/*

Goal

Port as much of the old Roleplay UX as possible from growqr-app/frontend into dashboard.

Required behavior

1. Configure roleplay via new REST client, not old orchestrator.
2. Receive or store session_id from configure response.
3. Connect live session directly to:

${NEXT_PUBLIC_ROLEPLAY_WS_URL}/roleplays/session/:sessionId

4. Preserve old WS protocol:

Frontend sends:

session.start
audio.input
session.finish
avatar.frontend_ready
presence_metrics_summary

Frontend receives:

session.ready
assistant.audio
assistant.audio.interrupted
assistant.transcript
candidate.transcript
turn.saved
session.completed
error

5. Poll review via REST:

GET /services/roleplay/review/:sessionId

Cut lines

If time is short, keep scenario selection + live WS + transcript. Stub advanced feedback/video analysis if needed.

Acceptance criteria

• User can configure/start a roleplay when services are available.
• Direct WS hook uses dashboard env vars.
• Transcript renders.
• Finish session works.
• Review area attempts real review polling and degrades gracefully.

---

P3 — Port Resume Frontend Flow

Owner

Junior/intern for frontend port; senior reviews service call wiring.

Files to create/update

growqr-dashboard/app/features/resume/page.tsx
growqr-dashboard/components/resume/*
growqr-dashboard/types/resume.ts
growqr-dashboard/lib/services/resume-service.ts

Goal

Port as much of the old Resume UX as the new backend gateway currently supports.

Required behavior

• List resumes if backend service is available.
• Show resume cards.
• Create/edit basic resume data if practical.
• Analyze resume through:

POST /services/resume/resumes/:resumeId/analyze

• Show analysis score/breakdown if returned.
• Show preview if gateway supports it.

Known full-parity gaps likely requiring senior/backend work

POST multipart upload
POST multipart parse
DELETE resume
PATCH primary resume
binary PDF export
original PDF fetch
analysis report export

Do not implement backend for these. Add UI fallbacks and document gaps.

Acceptance criteria

• Resume page uses real client functions where supported.
• Missing operations show graceful disabled/coming-soon states instead of broken buttons.
• Old resume components are adapted without importing old app-only contexts.

---

P4 — Q Score Page / Service Analytics

Owner

Junior/intern.

Files to create/update

growqr-dashboard/app/features/qscore/page.tsx
growqr-dashboard/app/analytics/page.tsx

Goal

Provide Q Score page and analytics that integrate real data if available and static fallback otherwise.

Acceptance criteria

• Q Score page exists.
• Analytics page exists.
• Static fallback is credible if service summary endpoint is not ready.

---

P5 — Feature Pages MVP Shells / Fallback

Owner

Junior/intern.

Files to create or update

growqr-dashboard/app/features/interview/page.tsx
growqr-dashboard/app/features/roleplay/page.tsx
growqr-dashboard/app/features/resume/page.tsx
growqr-dashboard/app/features/qscore/page.tsx

If the folder structure does not exist, create it.

Goal

Create four demo-ready service pages using static data and existing dashboard styling.

Requirements

Each page should have:

• Clear page title
• Short user-facing explanation
• Status/summary cards
• One primary CTA
• 2–4 supporting sections that make the service feel real
• No backend dependency
• No fake loading spinners that never resolve
• No lorem ipsum
• No broken links

Page-specific guidance

Interview page

Title examples:

• Interview Practice
• Interview Coach

Suggested sections:

• Readiness score
• Upcoming mock interview / practice session card
• Focus areas: behavioral answers, role fit, confidence, technical clarity
• Recent feedback summary

Primary CTA:

• Start Interview Practice

Reference only:

growqr-next-frontend/src/app/v2/services/interview/*
growqr-app/frontend/src/components/interview/*
growqr-app/frontend/src/app/(dashboard)/upskilling/interview/*

Do not port complex media/avatar/session hooks. Keep the dashboard page simple.

Roleplay page

Suggested sections:

• Scenario cards: recruiter screen, hiring manager, salary negotiation, promotion conversation
• Confidence score
• Last practice feedback
• Recommended next roleplay

Primary CTA:

• Start Roleplay

Reference only:

growqr-next-frontend/src/app/v2/services/roleplay/*
growqr-app/frontend/src/components/roleplay/*

Resume page

Suggested sections:

• Resume strength score
• ATS readiness
• Missing keywords
• Suggested improvements
• Recent resume versions/demo cards

Primary CTA:

• Analyze Resume

Reference only:

growqr-next-frontend/src/app/v2/services/resume/*
growqr-app/frontend/src/components/resume/*

Q Score page

Suggested sections:

• Q Score / Queue Score headline score
• Score breakdown: resume, interview, roleplay, market fit, momentum
• Trend or progress cards
• Recommended next actions

Primary CTA:

• Improve My Q Score

Reference only:

growqr-next-frontend/src/app/qx-score/page.tsx
growqr-next-frontend/src/app/v2/qx-score/page.tsx

Acceptance criteria

• pnpm build or at least pnpm lint does not fail because of these pages.
• Each page opens directly by URL.
• Each page uses static/demo data only.
• Each page feels coherent enough for a customer/team demo.

---

P6 — Feature Catalog Cleanup

Owner

Junior/intern.

Files to update

growqr-dashboard/app/features/page.tsx
growqr-dashboard/data/features.ts

Goal

Make the features index page focus on the four MVP services.

Requirements

Feature cards should include only or prominently emphasize:

1. Interview
2. Roleplay
3. Resume
4. Q Score

Each card should have:

• Name
• Short benefit-driven description
• Status badge or category
• CTA/link to the correct page

Recommended routes:

/features/interview
/features/roleplay
/features/resume
/features/qscore

Acceptance criteria

• All four cards are visible.
• All four cards link to working pages.
• No dead CTA buttons.
• Non-MVP features are removed, hidden, or clearly de-emphasized.

---

P7 — Analytics / Career Score Dashboard Fallback

Owner

Junior/intern.

File to update

growqr-dashboard/app/analytics/page.tsx

Goal

Make analytics feel career-specific and aligned with Q Score, even if static for today.

Requirements

Use static/demo data. Include:

• Overall Q Score
• Interview readiness
• Resume strength
• Roleplay confidence
• Workflow progress
• Recommended next action

Suggested visual sections:

• Top KPI cards
• Score breakdown cards
• Progress/trend area
• Recent activity list
• Recommended next actions

Do not wait on backend analytics. Senior engineer may later plug real data into this.

Acceptance criteria

• Page renders cleanly.
• Looks intentional and career-focused.
• Does not use unrelated generic analytics copy.
• No backend dependency.

---

P8 — Reusable Empty / Loading / Error UI Components

Owner

Junior/intern.

Files to create

growqr-dashboard/components/EmptyState.tsx
growqr-dashboard/components/LoadingState.tsx
growqr-dashboard/components/ErrorState.tsx

Goal

Create small presentational components senior engineer can plug into API-driven workflow/chat pages.

Requirements

Components should be dumb/presentational only.

Suggested props:

type EmptyStateProps = {
  title: string;
  description?: string;
  actionLabel?: string;
  href?: string;
};

type LoadingStateProps = {
  title?: string;
  description?: string;
};

type ErrorStateProps = {
  title?: string;
  description?: string;
  actionLabel?: string;
  onAction?: () => void;
};

Use existing card/tile styling patterns.

Acceptance criteria

• Components compile.
• No API calls.
• No external dependencies unless already installed.
• Easy for senior engineer to import.

---

P9 — Navigation Copy / MVP Path Cleanup

Owner

Junior/intern, but coordinate before editing because current nav files are already modified.

Candidate files

growqr-dashboard/components/LeftRail.tsx
growqr-dashboard/app/layout.tsx

Goal

Make demo navigation obvious.

Desired MVP nav order

1. Dashboard
2. Workflows
3. Talk to Me
4. Features
5. Analytics
6. Settings

Important warning

components/LeftRail.tsx and app/layout.tsx already have uncommitted changes. Do not edit without checking with senior engineer.

Acceptance criteria

• MVP routes are easy to find.
• No prominent links to unfinished/community/social/rewards/mentor/pathways pages.
• No broken nav links.

---

P10 — Copy Polish Pass

Owner

Junior/intern.

Files

Any assigned feature/analytics files, plus potentially data/features.ts.

Goal

Make labels and descriptions sellable and human-readable.

Tone

• Clear
• Benefit-driven
• Professional
• Not too verbose
• Not too technical

Important workflow names to use consistently

Interview-to-Offer Accelerator
Career Transition Sprint
Salary Negotiation War Room
Promotion Readiness Packet
Personal Brand Opportunity Engine

Avoid

• Lorem ipsum
• Placeholder copy
• Over-promising AI capabilities
• Internal implementation terms like actor, moduleId, adapter, Rivet, Drizzle

---

6. Tasks Not Assigned to Juniors

The senior engineer owns these:

growqr-dashboard/app/api/growqr/[...path]/route.ts
growqr-dashboard/lib/api.ts
growqr-dashboard/lib/growqr-api.ts
growqr-dashboard/types/workflows.ts
growqr-dashboard/types/chat.ts
growqr-dashboard/app/workflows/page.tsx
growqr-dashboard/app/workflows/[id]/page.tsx
growqr-dashboard/app/talk/page.tsx or app/chat/page.tsx
growqr-dashboard/components/ActiveWorkflowDetail.tsx
growqr-dashboard/components/AvailableWorkflowCard.tsx
growqr-dashboard/components/PromptBar.tsx
growqr-backend/**

Do not modify these unless explicitly asked.

---

7. Backend API Context for Awareness Only

Juniors may call approved /services/... routes through dashboard service clients, but should not touch workflow routes unless explicitly asked.

Key backend routes:

GET    /workflows
GET    /workflows/:workflowId
POST   /workflows/:workflowId/runs
GET    /workflows/:workflowId/runs/current
GET    /workflow-runs/:runId
POST   /workflow-runs/:runId/run
POST   /workflow-runs/:runId/modules/:moduleId/run
GET    /workflow-runs/:runId/artifacts
GET    /workflow-runs/:runId/events
POST   /chat

The senior engineer will own workflow/chat API proxy wiring. Service pages should prefer the approved dashboard service clients described above.

---

8. Sellable Workflow Context

The dashboard should align with these five workflows:

ID	Display name	Modules / services
interview-to-offer	Interview-to-Offer Accelerator	Resume, interview plan, Sara, Emily, Q Score
career-transition	Career Transition Sprint	Transition map, resume
salary-negotiation-war-room	Salary Negotiation War Room	Negotiation script, Emily roleplay
promotion-readiness	Promotion Readiness Packet	Evidence packet, Emily roleplay
personal-brand-opportunity-engine	Personal Brand Opportunity Engine	Profile rewrite

Feature pages should feel like services that support these workflows.

---

9. Design / Implementation Guidelines

Use the existing growqr-dashboard style. Prefer existing components and classes.

Common style direction:

• Rounded cards / tiles
• Soft surfaces
• Clear section headers
• Simple status badges
• Brand orange accents where appropriate
• Desktop-first; mobile polish not required today

Keep implementation simple:

• Use client components only where hooks, browser media, or WebSockets are required.
• Avoid complex animations.
• Avoid new dependencies.
• Prefer frontend wrappers over broad refactors.
• Use static fallback data only when a real service endpoint is missing or unavailable.
• Do not import old app-only providers/contexts unless they are also ported safely.

---

10. Suggested Work Plan for Interns

First 15 minutes

1. Pull latest branch.
2. Run status check.
3. Inspect existing dashboard page/component style.
4. Confirm assigned files.

Commands:

cd /Users/puter/Workspace/growqr/growqr-dashboard
git status --short --branch
pnpm install
pnpm lint

Next 45–60 minutes

Build P0 service parity foundation: config, types, REST clients, direct WS constants.

Next 90–120 minutes

Port P1 Interview flow: configure → direct WS live session → transcript → review fallback.

Next 90–120 minutes

Port P2 Roleplay flow: configure → direct WS live session → transcript → review fallback.

Next 60–90 minutes

Port P3 Resume flow for gateway-supported operations; document missing parity endpoints.

Optional final 30–45 minutes

Build P4/P6/P8 polish: Q Score, feature catalog, reusable states, copy.

---

11. Handoff Checklist

Before handing off, juniors should report:

• Files changed
• Routes created/updated
• Any known broken links
• Whether lint/build was run
• Any errors seen

Minimum validation commands:

cd /Users/puter/Workspace/growqr/growqr-dashboard
pnpm lint
pnpm build

If pnpm build fails for unrelated existing project issues, capture the error and report it. Do not attempt broad refactors.

---

12. Definition of Done

Delegated work is done when:

• /features shows the four MVP services.
• /features/interview works.
• /features/roleplay works.
• /features/resume works.
• /features/qscore works.
• /analytics shows career/Q Score analytics.
• Interview/Roleplay use direct WS URLs when services are available.
• Resume uses real gateway-supported operations where possible.
• Missing full-parity endpoints are documented and have graceful UI fallbacks.
• No lorem ipsum or obvious placeholders remain.
• No critical senior-owned files were modified.

---

13. Delegation Message to Send

Copy/paste:

Please work only in growqr-dashboard on branch main. Do not touch backend, chat, Clerk middleware, API proxy, deployment env, or workflow logic. New target is as much feature parity as possible with growqr-app/frontend for Interview, Roleplay, and Resume. Work in this order:

1. Create dashboard service config/types/clients for Interview, Roleplay, Resume using /services/... REST and direct Interview/Roleplay WS env vars.
2. Port Interview flow from growqr-app/frontend: configure via REST, connect direct WS, render transcript, finish session, poll review.
3. Port Roleplay flow similarly: configure via REST, connect direct WS, render transcript, finish session, poll review.
4. Port Resume flow for supported gateway operations: list/create/get/update/analyze/suggestions/preview; document missing upload/export/parse parity.
5. Add Q Score/analytics and feature catalog polish with graceful fallbacks.

Use existing dashboard styles, no new dependencies, no backend code edits, and no lorem ipsum. Frontend service calls are allowed only through approved dashboard clients. Run pnpm lint and pnpm build before handoff or send the errors if they are unrelated.