Spec Review

Now, let's review each of your specs to see if you covered all the critical points or stated something not quite clearly enough.

Spec Review Checklist
  1. Security, especially SQL — any risk of SQL injection, unsanitized input going straight into a query?
  2. Reuse of code — is there an obvious repeated pattern that should be a function/include instead of copy-pasted per page?
  3. Sleek CSS — is styling planned as organized/reusable, or likely to sprawl?
  4. File structure — is there a sensible plan for how files/folders are organized, not just "one big file"?
  5. User object needed? — does this app need accounts/login, and if so, is that reflected in the Database Architecture section?
  6. Responsive — does the spec account for mobile/smaller screens at all?
  7. Error/edge cases — empty states, invalid input, no results found — planned for, or only the happy path?
  8. Data validation — both client-side (form checks) and server-side (never trust what the browser sends)?
  9. Naming conventions — consistent table/field/variable naming (callback to their Step 4 lesson), not whatever Claude Code happened to generate?
  10. Scope feasibility — realistically, is Basic Features buildable in the two sessions left (this build + Session 5 debug)? The single most useful thing you personally catch that students won't.
  11. External API error handling (if relevant) — what happens if the call fails or is slow, not just the happy path?
Checklist Review Table

Entries
NameProject NameSecurity (SQL)DRYCSSFile structureUser ObjectResponsiveErrors/EdgesData ValidationNaming ConvScope FeasibilityAPI Error
LouiseOSeatSaver
MargaretPMVP Workout
CameronL
ElizabethFamily Meal Planning
NameProject NameSecurity (SQL)DRYCSSFile structureUser ObjectResponsiveErrors/EdgesData ValidationNaming ConvScope FeasibilityAPI Error