Commit 96d233

2026-04-12 19:13:32 jeremy: Add C01 overflow activities for extension and alternatives Feasibility deep dive, comparative brief analysis, mock interview, risk register, hand-drawn Gantt alternative, pitch document format. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

/dev/null .. SAT/C01-Overflow.md
@@ 0,0 1,117 @@
+	# C01 Overflow Activities
+
+	Useful but non-essential activities for C01 (Design Brief and Project Management). These can be used as extension work, early finisher tasks, or alternative approaches.
+
+	## Extension: Feasibility Deep Dive (T.E.L.O.S.)
+
+	For students who finish their design brief early and want to strengthen their feasibility argument.
+
+	**Activity:** Work through each T.E.L.O.S. dimension for your project:
+
+	| Dimension | Question to answer |
+	|-----------|-------------------|
+	| **Technical** | Do you have the skills and tools to build this? What will you need to learn? |
+	| **Economic** | What resources does this need? Is it achievable with school resources? |
+	| **Legal** | Any data privacy issues? Licensing concerns for libraries/assets? |
+	| **Operational** | Will your target users actually use this? How does it fit into their routine? |
+	| **Scheduling** | Can you build this in the available time? What would you cut if you run out of time? |
+
+	Write 2-3 sentences per dimension. This strengthens the feasibility section of the design brief and prepares students for probing questions in the C1-1 presentation.
+
+	**Time:** ~20 min
+
+	---
+
+	## Extension: Comparative Brief Analysis
+
+	For students who want to understand what separates a strong brief from a weak one.
+
+	**Activity:** Read the Adem's Gym example and the NiceQuiz example. Create a comparison table:
+
+	| Aspect | Brief A | Brief B | Which is stronger and why? |
+	|--------|---------|---------|---------------------------|
+	| Problem statement | | | |
+	| User description | | | |
+	| Language justification | | | |
+	| Feasibility argument | | | |
+
+	Discuss with a partner. Could you improve the weaker brief? What would you change?
+
+	**Time:** ~15 min
+
+	---
+
+	## Extension: Mock Interview (Peer)
+
+	For students who finish Checkpoint C early and want to practice for the C1-3 interview.
+
+	**Activity:** Pair up. One student is the "teacher," one is the "student." The teacher uses this question progression:
+
+	1. "Walk me through your project plan from start to finish."
+	2. "Why does [specific task] come before [other task]?"
+	3. "Show me a dependency. What happens if the first task is delayed by a week?"
+	4. "Where is your critical path? How did you identify it?"
+	5. "How will you know if your project is falling behind? What will you do about it?"
+
+	Swap roles after 10 minutes. Give each other feedback: what was convincing? Where did you hesitate?
+
+	**Time:** ~20 min (10 min each way)
+
+	---
+
+	## Extension: Risk Register
+
+	For students who want to push into high-level monitoring and planning.
+
+	**Activity:** Create a simple risk register for your project:
+
+	| Risk | Likelihood (H/M/L) | Impact (H/M/L) | Mitigation |
+	|------|-------------------|-----------------|------------|
+	| e.g., "Can't learn API in time" | M | H | "Start with simpler version, add complexity later" |
+
+	Identify 3-5 risks. For each, explain how your project plan accounts for it (or doesn't). This is excellent preparation for the C1-3 interview question about monitoring.
+
+	**Time:** ~15 min
+
+	---
+
+	## Alternative: Hand-Drawn Gantt Chart
+
+	If GitHub Projects is causing technical issues or a student works better on paper.
+
+	**Activity:** Draw a Gantt chart by hand on A3 paper:
+	- X-axis: weeks (Term 2 and Term 3)
+	- Y-axis: tasks grouped by PSM stage
+	- Use coloured bars for each stage
+	- Mark milestones with diamonds
+	- Draw dependency arrows between tasks
+
+	Photograph and commit to GitHub. This satisfies the "using software" requirement if they then transfer it to GitHub Projects, or it can serve as their annotated plan for C1-3.
+
+	**Time:** ~25 min
+
+	---
+
+	## Alternative: Design Brief as a Pitch
+
+	Instead of a formal written brief, the student creates a 1-page "pitch document" — visual, concise, designed to convince someone to fund/support the project. They still need to cover all the same content (problem, solution, users, language, feasibility) but in a more visual format.
+
+	This can be done in addition to the formal brief as presentation preparation. The visual format forces students to distil their thinking.
+
+	**Time:** ~20 min
+
+	---
+
+	## Ongoing: AI Disclosure Log Prompts
+
+	Quick prompts students can use to update their AI disclosure log throughout C01:
+
+	- "I asked AI to..." — What was the prompt?
+	- "AI produced..." — What did it generate?
+	- "I kept / changed / rejected..." — What did you do with it?
+	- "Because..." — Why?
+
+	Example entry:
+	> I asked Claude to draft a feasibility section for my design brief. It produced a paragraph about technical feasibility using Python and fasthtml. I kept the structure but rewrote the specific details because Claude didn't know about Godot's limitations for my game project. I also added scheduling feasibility which Claude didn't mention.
+
+	Remind students: the log isn't assessed separately, but it's required evidence and strengthens their interview responses.