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
- Security, especially SQL — any risk of SQL injection, unsanitized input going straight into a query?
- Reuse of code — is there an obvious repeated pattern that should be a function/include instead of copy-pasted per page?
- Sleek CSS — is styling planned as organized/reusable, or likely to sprawl?
- File structure — is there a sensible plan for how files/folders are organized, not just "one big file"?
- User object needed? — does this app need accounts/login, and if so, is that reflected in the Database Architecture section?
- Responsive — does the spec account for mobile/smaller screens at all?
- Error/edge cases — empty states, invalid input, no results found — planned for, or only the happy path?
- Data validation — both client-side (form checks) and server-side (never trust what the browser sends)?
- Naming conventions — consistent table/field/variable naming (callback to their Step 4 lesson), not whatever Claude Code happened to generate?
- 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.
- External API error handling (if relevant) — what happens if the call fails or is slow, not just the happy path?
Checklist Review Table
| Name | Project Name | Security (SQL) | DRY | CSS | File structure | User Object | Responsive | Errors/Edges | Data Validation | Naming Conv | Scope Feasibility | API Error |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| LouiseO | SeatSaver | |||||||||||
| MargaretP | MVP Workout | |||||||||||
| CameronL | ||||||||||||
| Elizabeth | Family Meal Planning | |||||||||||
| Name | Project Name | Security (SQL) | DRY | CSS | File structure | User Object | Responsive | Errors/Edges | Data Validation | Naming Conv | Scope Feasibility | API Error |
