Checkpoint Gate
Required Output Classification
| Required output | Classification | Public/private guidance |
|---|---|---|
| Closed-book prompts, self-assessment answers, and skills matrices | Practice artifact | Use for honest calibration; do not publish raw answers unless rewritten as a study guide. |
| Required evidence gate items, sign-off checklist, and readiness decision | Checkpoint evidence | Keep as private progression evidence; share only sanitized summaries with mentors or reviewers. |
| Repair artifacts produced after a weak checkpoint, such as corrected solutions, diagrams, traces, benchmarks, or runbooks | Checkpoint evidence | Store beside the checkpoint so the remediation trail is inspectable without making mistakes public. |
| Reviewer notes or mentor feedback that materially improve a project artifact | Portfolio candidate | Convert into public-safe acknowledgements or changelog entries only after removing private feedback context. |
This gate is about honesty, not punishment. Semester 0 is complete only when you can explain the core ideas without leaning on copied notes and can show one small body of real work.
Self-Assessment: "Can I Do This Without Notes?"
Check each item only if you can demonstrate or explain it closed-book. For coding items, use only a blank editor.
Launchpad integration
- I can explain how my study system, editor, terminal, and Git workflow support later technical work.
- I can show one honest weekly review or tracker artifact and explain what changed because of it.
- I can create a branch, make small commits with readable messages, and merge the work back cleanly.
Algorithm intuition (Module 1)
- I can explain why binary search is faster than simple search and when it is valid to use.
- I can compare
O(1),O(log n),O(n), andO(n^2)at a practical intuition level. - I can trace a small recursive example and point to the base case and recursive case.
- I can draw a small graph and explain why BFS needs both a queue and a visited set.
CS fundamentals (Module 2)
- I can explain what computer science studies besides "writing code."
- I can distinguish an algorithm, an ADT, a data structure, and a database with one concrete example of each.
- I can explain the path from source code to compiler or interpreter to operating system to CPU and memory.
- I can name at least three strategy families and say when each is a plausible fit.
Clean code (Module 3)
- I can explain why clear naming reduces future debugging and review cost.
- I can describe what makes a function do one job instead of several.
- I can identify at least three code smells in a small example and suggest a safer rewrite.
- I can explain why tests belong near the beginning of engineering practice instead of being a late add-on.
Integration (semester project)
- I can run my project from its README in a clean folder or fresh terminal session.
- I can explain how the tracker, algorithm visualizer, and storage fit together.
- I can walk through one algorithm step by step using my project or a paper trace.
- I can point to one place where I kept logic out of the UI or presentation layer.
Skills Verification Matrix
Use this table during a mock check with a peer, mentor, or recorded self-video. The goal is to expose weak spots before Semester 1, not after.
| Skill | Evidence / Task | Pass? | Date | Notes |
|---|---|---|---|---|
| Explain algorithm growth | Compare simple search and binary search with one concrete input-size example | [ ] | ||
| Trace graph search | Draw a small graph and explain BFS using queue and visited set | [ ] | ||
| Explain the computing stack | Walk one simple program from source code down to machine execution | [ ] | ||
| Review code quality | Identify naming, function, or duplication problems in a small snippet | [ ] | ||
| Show engineering basics | Run tests, show Git history, and explain the project layout | [ ] | ||
| Defend the semester project | Explain inputs, logic, storage, and output clearly | [ ] |
"Am I Ready?" Criteria
You are ready to treat Semester 0 as complete when all of these are true:
- At least 90 percent of the checklist above is honestly checked without hand-waving.
- The cumulative review was attempted closed-book first and every miss was logged for follow-up.
- The semester exam was completed under timed conditions and reviewed honestly.
- The semester project is runnable, documented, and defended in plain language.
If an item is "paper yes, real no," treat it as not passed. The whole point of Semester 0 is to stop fake confidence from leaking into Semester 1.
Remediation Guidance
| Gap | Suggested remediation |
|---|---|
| Big O still feels like vocabulary only | Revisit Module 1 concepts 1 and 2, then compare three growth rates using one real input-size scenario. |
| Recursion or BFS still feels magical | Hand-trace two small examples on paper before touching code again. |
| CS map is still fragmented | Redraw the Module 2 map from memory and write one sentence for each layer or area. |
| Code smells are easy to spot but hard to fix | Rework one small project file with a naming pass, a function split, and one test-protected refactor. |
| Tests feel artificial | Add tests to tracker summaries and algorithm step transitions until the value becomes obvious. |
| Git history is messy or scary | Rebuild the last small feature on a fresh branch with 3-5 clean commits and readable messages. |
Advancement Sign-Off
- I completed the cumulative review honestly.
- I completed the semester exam under real constraints.
- I can begin Semester 1 without depending on copied notes to explain Semester 0 foundations.
Mastery Rubric
| Level | Evidence |
|---|---|
| Beginner pass | Can answer direct questions and complete familiar exercises with light notes. |
| Solid pass | Can solve new variants, explain choices, and connect the work to Pre-Semester Launchpad. |
| Strong pass | Can defend tradeoffs, identify failure modes, and produce clean evidence in the portfolio artifact. |
| Not ready | Relies on copied solutions, cannot explain mistakes, or lacks durable artifacts. |
Retake and Repair Rule
If a section is weak, do not only reread. Repair it by producing new evidence: a corrected solution, a fresh implementation, a rewritten proof, a benchmark, a diagram, a runbook, or a short teaching note.
Answer-Quality Examples
Use these examples when grading written answers or spoken explanations.
| Quality | Example pattern |
|---|---|
| Weak | Names a concept but gives no example, constraint, or failure case. |
| Acceptable | Defines the concept and applies it to a familiar exercise. |
| Strong | Applies the concept to a new variant and explains why an alternative would fail. |
| Portfolio-ready | Connects the concept to Pre-Semester Launchpad, current project evidence, and a future capstone decision. |
Interleaving Prompt
For any missed answer, add one sentence starting with: This depends on an earlier skill because...
Calibration Materials
Use these learner-visible calibration materials before self-grading or requesting review: