Commit 07dce2

2026-04-12 19:41:51 jeremy: Add C01-1 checkpoint proposal for design brief readiness Proposes student self-check criteria, teacher quick-check, and feedback prompts for Checkpoint A (Design Brief Ready). For Jeremy's review. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

/dev/null .. SAT/C01-1-Checkpoint-Proposal.md
@@ 0,0 1,51 @@
+	# C01-1 Checkpoint Proposal: Design Brief Ready
+
+	**Status:** Proposal (pending Jeremy's approval)
+	**Created:** 2026-04-12
+	**Source:** TKT-004 — C1-1 Assessment Package
+
+	---
+
+	## Checkpoint A: Design Brief Ready
+
+	This checkpoint gates C1-1 (Design Brief Presentation). A student who completes all items is ready to join the presentation queue. A student who hasn't completed the checkpoint uses class time to finish --- naturally reducing their validation time and depth.
+
+	### Student Self-Check Criteria
+
+	Students can check each item themselves before the lesson:
+
+	1. **Problem/need/opportunity stated** --- Brief has a clear section naming a specific, concrete problem, need, or opportunity.
+	2. **Solution described** --- Brief explains what the software does and how it addresses the problem. A reader unfamiliar with the project could understand the idea.
+	3. **Users identified and described** --- Primary and secondary users are named with enough detail to picture them (not just "students" but specific types of users with context).
+	4. **Programming language stated with reasons** --- Language or framework is named with an explanation of why it suits the project.
+	5. **Feasibility and originality addressed** --- Brief includes a section on whether the project is achievable and what makes it different.
+	6. **Artefact ready** --- Brief committed to GitHub, printed copy in hand, cue card prepared (quarter A4, key talking points only), practiced presenting at least once timed at ~5 minutes.
+
+	### Teacher Quick Check (circulating, <60 seconds per student)
+
+	| Check | What to look for |
+	|-------|-----------------|
+	| Printed brief | Physical copy on desk, covers all 5 content sections. They exist and say something specific. |
+	| Cue card | Quarter A4 or smaller. Key words, not a script. |
+	| Quick verbal | "In one sentence, what problem does your project solve?" Clear + specific = ready. |
+
+	### Feedback Prompts (done to strong)
+
+	| Area | Prompt |
+	|------|--------|
+	| Problem too vague | "Your problem is generic. Which specific people have this problem and when?" |
+	| Users generic | "You say 'teachers and students.' What does a teacher actually do with your app first?" |
+	| Language thin | "You chose Python. Why Python and not something else? What does it give you?" |
+	| Feasibility missing | "I see what you're building but not why you can build it. What's your argument?" |
+	| Originality unclear | "If I Googled this, what would I find? What's your twist?" |
+	| Ready for depth | "Now think about weaknesses. What could go wrong, and what would you do?" |
+
+	---
+
+	## Proposed Checklist Integration
+
+	**Where:** C01-2026 checklist, before the C1-1 assessment tasks.
+
+	**Suggestion:** Group learning tasks under "Checkpoint A tasks" heading so students can track their readiness. The checkpoint items above become the self-assessment criteria at the end of the learning sequence, before the presentation.
+
+	**Note:** The full assessment package (teacher protocol, question bank, scoring guide) is in `SD26-Teachers/sat/C01-2026/C01-1-Assessment-Package.typ`. This wiki page covers only the checkpoint criteria suitable for the student-facing checklist.