Academy End-to-End QA Report

All four Academy API endpoints return 401 when unauthenticated

POST /api/academy/attempts, GET /api/academy/attempts/:id, PATCH /api/academy/attempts/:id, and GET /api/academy/questions all return {"error":"Unauthorized"} with HTTP 401 when called without a valid session cookie. Verified via httpCheck.

Ownership check on PATCH and GET prevents cross-user access

PATCH /api/academy/attempts/:id and GET /api/academy/attempts/:id both query with AND(id = ?, userId = ?) so a learner cannot read or modify another learner's attempt even if they know the UUID.

1,712 active questions across 240 assessments confirmed in DB

All three primary courses (level-funded-health-plans, self-funding, small-group-fully-insured) have full question pools: 15 module quizzes × 5 questions each + 50/60/50 final exam questions respectively. GC courses (ebiq-*, employer-learning-portal) and track courses (advanced-strategies, compliance, cost-containment) are also fully seeded.

compliance-legal final exam had only 1 question seeded

The compliance-legal course final exam (exam_ref: "final-exam") had a single stub question (id: seed-compliance-final-001). The GET /api/academy/questions endpoint would return a 1-question pool, causing a broken final exam experience. The compliance-legal course pages use the GC engine which has a static fallback, so learners would fall back to static questions — but the attempt would be recorded against a 1-question pool.

Options were not shuffled per attempt in POST /api/academy/attempts

The original POST handler selected and shuffled questions but did NOT shuffle the options array within each question. This meant every attempt for the same question always presented options in the same order (a, b, c, d), making it trivial to memorize answer positions rather than understanding content.

Question order is randomized per attempt

POST /api/academy/attempts uses Math.random() sort (now replaced with Fisher-Yates) to select and order questions. Each attempt gets a different question order from the same pool.

onStart race condition: DB questions not used before quiz phase rendered

LFQuizEngine.startQuiz() called await onStart?.() but discarded the return value. The engine then immediately set phase to "quiz" using the stale questions prop (fallback static questions). The DB pool returned by the API was stored in React state (setQuestions) but state updates are async — the randomizedQuestions memo had already computed from the old value. Result: learners always saw fallback static questions even when the DB pool loaded successfully.

No in-progress answer autosave — reload lost all answers

The original PATCH handler only accepted complete:true requests. There was no way to save in-progress answers, so a page reload during a quiz would lose all answers. The learner would have to restart from question 1 with a new attempt.

GET /api/academy/attempts list endpoint was missing

The memory notes referenced GET /api/academy/attempts as a learner attempt/review retrieval endpoint, but only GET /api/academy/attempts/:id (single attempt) was registered. There was no way to list a learner's attempt history for a course or assessment.

GET /api/academy/attempts/:id now supports resume (returns questions for in-progress)

The original GET handler returned review data but did not return the question list for in-progress attempts. A learner who reloaded mid-quiz could not resume because the questions were not available from the API.

correctId was exposed on incomplete attempts in GET /api/academy/attempts/:id

The original GET handler included correctId in the review items regardless of whether the attempt was complete. A learner could start an attempt, immediately call GET /api/academy/attempts/:id, and read all correct answers before answering any questions.

Scoring uses stored question snapshot (correctId in questionIds JSON)

Both the original and updated PATCH handler score using the correctId stored in the questionIds JSON column at attempt creation time. This means scoring is always consistent with what the learner saw, even if the question bank is updated after the attempt starts.

Pass threshold is 80% across all assessment types

PATCH handler uses (score / total) * 100 >= 80 for pass determination. This matches the LFQuizEngine passingPct=80 prop used across all quiz and final exam pages.

Static fallback activates correctly when DB pool unavailable

useAcademyAttempt.startAttempt() catches fetch errors and returns fallbackRef.current. LFQuizEngine uses the returned pool, so if the API fails the quiz still runs with static questions. The attempt is not persisted in fallback mode (attemptId remains null, saveAttempt no-ops).