fix(capstone): enforce unlock rule server-side

POST /api/assessments/:definitionId/start only ever checked that the
definition existed and was active — it never checked unlock_rule. GET
/api/capstone correctly computed and displayed lock state, and the
student UI never exposed a start action while locked, but a direct POST
to this route bypassed the check entirely (documented as a known gap in
docs/PHASE6A_ROOT_COURSE_FOUNDATION.md §10). Student UI state is not the
enforcement boundary.

Fixed by binding to the exact same computeCurriculumState() gate
/api/capstone already relies on, rather than re-parsing
definition.unlock_rule independently — one computation of 'is this
unlocked,' not two that could drift. Only a definition the curriculum
path actually names as ITS capstone is gated this way; an ordinary exam
is completely unaffected. Returns a clean 403 { error: 'locked',
blocking_stage_ids } — the same shape /api/capstone already exposes.

Found while fixing this: e2e-phase5b.js's own capstone-completion test
had been passing only because of this exact gap — it never included the
real-ops stage in its completion loop before attempting to start the
capstone, and the missing unlock check let it succeed anyway. Fixed
alongside the platform code (REAL_OPS added to ALL_NON_CAPSTONE), not
routed around.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

platform/api/src/learning-routes.js

@@ -156,6 +156,31 @@ module.exports = function registerLearningRoutes(app, deps) {
     );
     const definition = rows[0];
     if (!definition) return res.status(404).json({ error: 'not_found' });
+
+    // Phase 6B §10 — a known Phase 3B gap, documented in docs/PHASE6A_ROOT_COURSE_FOUNDATION.md
+    // §10: this route only ever checked the definition existed/was active. GET /api/capstone
+    // computes and displays lock state correctly and the UI never exposes a "start" action while
+    // locked, but student UI state is not the enforcement boundary — a direct POST here could
+    // start a capstone session before its prerequisite stages were actually complete. Fixed by
+    // binding to the SAME gate /api/capstone already derives from the curriculum path's own
+    // capstone stage (computeCurriculumState), rather than re-parsing definition.unlock_rule
+    // independently — one computation of "is the capstone unlocked," not two that could drift.
+    // Only a definition the path actually names as ITS capstone is gated this way; an ordinary
+    // exam (no capstone stage names it) is unaffected — see e2e-phase6b.js for both cases.
+    const path = curriculum.loadCurriculumPath();
+    const capstoneStage = path?.stages.find((s) => s.type === 'capstone' && s.capstone_assessment_id === definition.assessment_definition_id);
+    if (capstoneStage) {
+      const progress = await loadProgress(pool, req.studentId);
+      const capstoneAchievement = await getCapstoneAchievement(pool, req.studentId);
+      const state = computeCurriculumState(path, progress, capstoneAchievement ? 'completed' : undefined);
+      if (state.capstone?.status === 'locked') {
+        return res.status(403).json({
+          error: 'locked', message: 'Complete the required stages before starting this assessment.',
+          blocking_stage_ids: state.capstone.blocking_stage_ids,
+        });
+      }
+    }
+
     const cohortId = await studentCohortId(pool, req.studentId);
     try {
       const session = await assessmentsLib.startSession(pool, { definition, studentId: req.studentId, cohortId });