CODING FOUNDATIONS RETROFIT · PASSPORT CHECKPOINT 4

Alignment and scoring correction for this added evidence

This block controls the retrofit evidence and supersedes any conflicting Coding Foundations wording below.

Topic: Game-feature planning, testing, and revision

Objective: Students will plan one purposeful feature in pseudocode, implement it in a working remix, test it, and revise from the result.

Essential standards:

• §126.19(c)(2)(C) — modify and implement previously written code to develop improved programs.
• §126.19(c)(3)(B) — discuss and implement a design process that includes planning, selecting digital tools to develop, test, and evaluate design limitations, and refining a prototype or model; and

Supporting standards:

• §126.19(c)(1)(E) — develop, compare, and improve algorithms for a specific task to solve a problem; and

Evidence status: Demonstrated: (2)(C) and (3)(B). Practiced: (1)(E). A plan without the recorded test result is incomplete.

Required evidence: Passport Checkpoint 4 — Game Plan: feature goal, WHEN/SHOULD statement, feature pseudocode, first test result, and one evidence-based revision. Score the plan and test within the existing Build and Testing criterion and the submitted checkpoint within Screenshot and Reflection; do not add points.

Meets the threshold when: Checkpoint 4 includes a feature goal, WHEN/SHOULD statement, pseudocode, observed test result, and one revision; the final game contains the tested feature.

Period budget: 5–8 minutes before editing + 5 minutes after the first feature test; preserve the existing full-period build.
Point-preserving scoring: Keep 100 points: score the plan/test within Build and Testing and the submitted checkpoint within Screenshot and Reflection. No additional points or public share link.

Projectable support: Editable retrofit deck, Slides 18–22 · PowerPoint fallback

• English: Make a Google copy · Word · PDF
• Español: Crear una copia de Google · Word · PDF

Teacher move: Use the Passport as the named planning/test evidence inside the current lesson and current point total. Do not create a duplicate worksheet or count completion alone as mastery.

Before students begin

• Open the student task in Student View and test the exact sign-in, link, file, or submission path students will use.
• Prepare only the listed existing materials; do not require a personal account or a new unlisted product.
• Keep the current student page available as the accessible and absence route.

Lesson flow

1. 1. Launch: Put the purpose in front of students: Students will modify a working game with purposeful features and test player experience.
2. 2. Model: Use one current example, tool, or teacher resource before students begin program revision.
3. 3. Guide: Complete the first decision or step together; conference before students commit to a direction.
4. 4. Build: Students complete the existing Canvas task. Do not add a second product or change the current rubric.
5. 5. Check + next step: Verify this evidence before students leave: Remixed game with two or more purposeful features, submission evidence, and reflection.

Close the loop

Use the current Canvas submission for grading. Record the specific misconception, access issue, or revision need you observed; use it to choose the next lesson's launch rather than creating a duplicate exit assignment.