Feat : adaptive micro practice engine

[Ashishpatra0-0]

What this PR does

Adds Micro-Practice - a spaced-repetition practice system that generates small, targeted printable papers for a student's specific weak competencies, tracks real difficulty progression as they improve, and provides a full workflow for teachers to evaluate completed papers.

What's included

• Generation - reuses the existing question engine to build small (3–5 question), single- or multi-competency papers targeted at a student's actual weak areas. Class-scoped bulk generation for a whole class at once.
• Real difficulty progression - good performance genuinely advances a student through harder curriculum variations and levels, not just a disconnected counter. A competency is marked mastered only once genuinely out of content for it.
• Re-assessment reconciliation - when a student is re-diagnosed, their existing practice progress is reconciled: resolved if no longer weak, reset if their placement changed significantly, left untouched otherwise.
• Evaluation - QR-based paper identification, photo/PDF upload (including multi-page support), manual answer entry with real question context, and a new "visual-confirm" answer type for previously-ungradeable drawing questions.
• Bulk evaluation - upload and grade many completed papers at once, grouped and navigable as a batch.
• Scheduling - history-aware spaced repetition: intervals now factor in recent performance consistency (not just the latest score) before deciding how much to lengthen or shorten the next practice gap, independent per competency.

[jgupta05072003-code]

Thank you for this, Ashish. I spent some time tracing the core logic in detail, including the schedule reconciliation, the spaced-repetition interval calculation, and the duplicate-question exclusion handling, rather than relying only on the PR description. The underlying design holds up well, and the problem this feature is trying to solve is an important one for the platform: turning a known weakness such as Fractions into repeated, targeted practice rather than waiting for the next broad diagnostic.

There are two relatively contained changes I would request before merge.

1. Please align the on-screen manual practice flow with the PDF-generation flow.

At the moment, /api/practice/generate/:studentId uses generateQuestionsForLevel(), which in this level range falls back to the placeholder generation path in conceptQuestionGenerator.ts. This is also the behavior that issue #359 is already trying to move away from for production use.

The manual flow also appears to search around student.currentLevel ± 5 rather than using the student's exact Micro-Practice schedule position.

The PDF-generation flow already seems to handle both of these concerns correctly through generateMicroPracticePaper(), which uses the real generators from levels_main.html and respects the scheduled levelId and subIdx. Since that function already returns the generated questions as structured data in addition to producing the PDF, could we please reuse the same path for the on-screen flow as well?

That would help ensure that both ways of delivering Micro-Practice use the same content source and the same progression logic.

2. Please move the new Micro-Practice routes out of backend/src/index.ts.

The PR currently adds the /api/practice/* and /api/students/:id/micro-practice/* endpoints directly into index.ts. Recent backend work has been moving feature-specific routes out of this file and into backend/src/routes/*, so it would be helpful for this feature to follow the same structure.

A dedicated file such as backend/src/routes/microPractice.ts would keep the feature easier to maintain.

I would also suggest moving calculateNextScheduleState() out of the startServer() closure and into the relevant service layer, likely alongside the other scheduling logic in practiceScheduleService.ts. Since this function contains the core progression and interval logic, keeping it exported and isolated would also make it much easier to unit-test directly.

I do not think either of these changes requires expanding this PR into the larger question-bank or misconception-mapping work already planned under the later milestones. Those are broader pieces of work and can remain separate. The requests here are mainly about making the two Micro-Practice delivery paths internally consistent and keeping the new feature aligned with the backend structure the repository is already moving toward.

Overall, the scheduling and remediation flow here is thoughtfully designed, and I appreciate the amount of work that has gone into it. These changes would make the feature much easier to maintain and give us a cleaner foundation for the deeper concept-mastery and misconception work that follows.

[Ashishpatra0-0]

@jgupta05072003-code Thank you for the detailed review, both requested changes are now complete:

1. On-screen practice flow now reuses the real generation logic. /api/practice/generate/:studentId now calls generateMicroPracticePaper() directly, resolving the student's real Micro-Practice schedule position (levelId/subIdx) instead of the old currentLevel ± 5 search and placeholder generator. It also now persists a MicroPracticePaper record, matching the PDF flow, so the returned paperId is usable via the existing /api/practice/paper/:paperId and grading endpoints. I confirmed this with a real test: it correctly resolved a student's actual schedule position, ran the real generator, and returned the same question shape as the printed papers.
   Note : this route currently has no frontend caller, so I verified it via direct API calls rather than the UI.

2. Micro-Practice routes moved into their own file. All 15 routes now live in backend/src/routes/microPractice.ts, following the same pattern as routes/students.ts. calculateNextScheduleState() (and its helper) moved into practiceScheduleService.ts and is now exported for direct unit testing, alongside the other scheduling logic there. I also re-verified end-to-end afterward -> generation, upload, partial/full grading, Due Today, and a real diagnostic submission all still work correctly, including confirming routes/students.ts's existing call into the shared service module was unaffected by the move.

Also merged in the latest main and resolved the resulting conflicts. Let me know if you'd like anything adjusted further.

Thank you again for the thorough review!