Checkpoint Gate - After Semester 3
The checkpoint must verify that the World-Class Strand evidence exists, is reproducible, and has a written highest-risk gap.
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. |
Use this gate after you finish the modules, the semester project, and the exam. The next semester moves into systems programming, where weak design habits become more expensive. Do not advance on optimism.
Gate Question
Can you change a medium-sized codebase safely and explain the design tradeoffs in language another engineer would respect?
If the answer is not clearly yes, use the remediation section before moving on.
Readiness Standards
Mark each item only if you can demonstrate it with code, notes, or a project artifact.
Module 1: OOD Foundations & Smells
- I can explain cohesion, coupling, and encapsulation using a real example from code I touched this semester.
- I can identify at least 8 code smells without confusing symptom, cause, and refactor move.
- I can explain one situation where applying a principle too early would have made the design worse.
Module 2: Refactoring Techniques
- I completed at least one non-trivial refactor in small steps rather than a rewrite.
- I used tests or characterization checks to protect behavior before risky changes.
- I can describe which Fowler-style moves I used and why they reduced change cost.
Module 3: Behavioral Patterns
- I can explain when Strategy, Observer, and Command are useful in practical code.
- I can name one misuse case for each of those patterns.
- I used at least one behavioral pattern in the semester project or an equivalent exercise.
Module 4: Structural & Creational Patterns
- I can explain when Factory, Adapter, and Decorator are justified.
- I can distinguish composition that helps from wrapping that only adds ceremony.
- I used at least one structural or creational pattern without creating pattern salad.
Module 5: Applied Design & Code Review
- I can review a change using correctness, clarity, design, and tests as separate lenses.
- I wrote at least one design note or ADR that records a real decision and its consequences.
- I can explain whether a design decision was reversible or expensive to undo.
Minimum Evidence Pack
You are not checkpoint-ready unless you have all of the following:
- a smell log with examples from real code
- a pattern cookbook covering Strategy, Observer, Command, Factory, Adapter, and Decorator
- a project or exercise branch showing incremental refactor commits
- tests or characterization checks for the code you changed
- at least one written review of code using a rubric
- at least one ADR or short design memo tied to the project
Fast Oral Check
Answer these without opening notes:
- What is the difference between a smell and a bug?
- When should you prefer extraction over adding another conditional branch?
- Why is "use a pattern here" incomplete advice?
- What makes a review comment actionable?
- Name one decision in your semester project that was reversible and one that was not.
If you cannot answer at least 4 well, rework Module 5 and your project notes.
Remediation Path
Use the smallest fix that addresses the gap:
- Weak smell recognition: repeat Module 1 practice and annotate two unfamiliar files.
- Weak refactor safety: repeat Module 2 with characterization tests first.
- Weak pattern judgment: revisit Modules 3 and 4 and write one "when not to use this pattern" note per pattern.
- Weak review or ADR quality: repeat Module 5 practice and rewrite one review plus one ADR.
- Weak project evidence: split your project changes into smaller commits and document the design pressure behind each one.
Sign-Off
You are ready for Semester 4 when your evidence pack exists, the oral check is comfortable, and your project history shows deliberate design rather than rushed cleanup.
Added Gate Evidence
Bring these artifacts to the checkpoint:
- a test report or transcript for the OOAD case extension
- a commit graph or short history summary showing refactor steps
- one design rationale note explaining inheritance, polymorphism, composition, and dependency choices
- one "when not to use this pattern" note for a pattern you considered
- one peer-review style critique of your own final design
Mastery Rubric
| Level | Evidence |
|---|---|
| Familiar practice only | Can answer direct questions with notes; this does not satisfy independent progression gates. |
| Solid pass | Can solve new variants, explain choices, and connect the work to Semester 2 Algorithms and Data Structures. |
| 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 Semester 2 Algorithms and Data Structures, 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
HCI And Accessibility Gate
Demonstrate all five before advancing:
- A user problem supported by observed behavior rather than requested features.
- A task protocol that does not reveal the intended interface path.
- One recorded usability failure and evidence-driven revision.
- Keyboard-only and manual semantic/focus verification mapped to applicable WCAG 2.2 criteria.
- A rejected alternative and AI-use declaration.
If any item is missing, complete the Discovery, Usability, and Accessibility Lab and retest a different task.
Use these learner-visible calibration materials before self-grading or requesting review:
Behavioral runtime-contract evidence
Before sign-off, verify all BD1–BD6 at level 2 or above, including a fresh cancellation/undo trace and the remote send/record failure explanation. Missing runtime-contract evidence cannot be averaged away by checkpoint scores.
Structural composition evidence
Verify Module 4 C01–C06 and SC1–SC6, using a fresh invalid payload, retry budget or acquisition failure. Preserve the distinction between local fake-provider behavior and real external effects.
Applied review and final sign-off
Verify AR1–AR6 with a fresh tenant/cache/ownership case and the retained before/after regression. Also verify both Modules 1–2 C01–C10 sets. Use the rubric: unresolved required evidence is incomplete, regardless of aggregate percentages. Record gate scores, repair dates, delayed rechecks and whether evaluation was self-review or independent.
Construction and semantics evidence
Include Module 1 DS1–DS4 in the existing evidence packet. Explain a representation boundary, a changed outcome contract and an effect-sensitive transformation. Each gate requires at least 2 independently; existing requirements remain. Reuse the clinic defense during semester integration rather than creating another project.
Combined Module 3 gate check
Require both Module 3 C01–C10 and BD1–BD6. Ask the learner to distinguish snapshot membership from live cancellation and recorded no-op edits from redo-preserving no-ops. Neither answer passes without identifying the relevant lab contract.
Core construction and applied-review coverage
The final packet also includes Module 4 C01–C06: product families, validated construction, copying/alias topology, composite semantics, proxy lifetime and a changed-requirement design defense. Each needs level 2 alongside SC1–SC6. Reuse the core workshop artifacts within the existing semester allowance.
Module 5's review workbench maps its independent tasks to AR1–AR6 and the existing HCI/accessibility work. Passing the regression kit alone does not establish usability, independent review or delayed transfer. Use one evidence index rather than duplicate projects.