Lesson 3 of 32 in this sequence

Not completed yet

Saved on this device only — not synced to an account yet.

Learning path

Step 3 of 32

Continue the sequence

ResumeReturn to this step ReviewRevisit the core idea RemediateGet repair practice Next stepChoose the next lesson manually

Completion

Review objectives and instruction
Complete the activity with manual learner confirmation
Answer every understanding-check item
Show completion feedback and reward only after the learner finishes the check

Progress

Step 3/32
15 content types
AI help source context available
Auto-advance blocked

Review objectives and instruction

AI help

Available only with source grounding, privacy limits, age controls, and measurement.

AI source context

Finding and Fixing a Mistake in a Plan · Thinking in Steps (Algorithms) · 1A-AP-14 · debugging

Evidence: local lesson AI-help metadata only; source-grounding, privacy, age-safety, and measurement hooks do not prove real model quality, production telemetry, child AI approval, or AI tutor production readiness

Production AI readiness not claimed

AI source context

Assessment shape

Local lesson assessment shape is complete.

Local shape only; production answer-attempt telemetry, live ownership/RLS evidence, mastery interpretation, release, and production readiness are not claimed here.

Objectives: 4
Activity: Prompt ready
Quiz items: 3 items, 3 answer keys, 3 explanations
Reward: Completion reward ready

Assessment progress stays manual: do not auto-advance through uncertain answers, failed writes, consent, media, payment, learner choice, or AI-assisted checks.

Learning-loop evidence: Content-map contract only; persistence and production learner-progress writes require route/API evidence.

Manual policy: assessment, media, consent, payment, learner choice, failed writes, and AI-uncertain help stay under learner control.

Prerequisite: Complete or review Find and Fix the Bug; Use with parent or guardian controls for child learners

AI guardrails

Privacy

Do not send raw child free text without consent
Use source excerpts and non-identifying progress state only
Asset is not registry-gated

Age safety

Apply junior audience controls before AI-help claims
Keep child learner AI paths behind guardian/product review evidence before readiness claims

Measurement

Log AI help usage by surface and asset slug
Evaluate answer quality against source-grounded rubric before production-readiness claims
Tie remediation prompts to completion, retry, or review outcomes

Local AI-help guardrails only; they do not prove guardian approval, production telemetry, model evaluation, release, deployment, or AI tutor production readiness.

Source and rights

Source path: koydo-app/scripts/curriculum-authoring
License: ai-generated-koydo
Attribution: Attribution decision needs owner review
AI provenance: claude-opus-4-8

Source review gates: attribution_missing

Local source evidence only; this does not prove publication rights, attribution approval, AI provenance clearance, release, deployment, or production readiness.

Route review

Current route: /library/junior/computer_science/en/lesson/spotting-and-fixing-mistakes
Route source: Fallback route needs owner canonical review
Candidate route: /library/junior/computer_science/en/lesson/spotting-and-fixing-mistakes

Local route evidence only; fallback candidates need owner-approved canonical route policy before route writes, production discoverability, or readiness claims.

Content gates: canonical_target_web_missing_uses_library_fallback

lessonslessonslesson objectivesmedia scenesdrillspractice setsquizzesfeedbackcharacterscitationsconcept mapsprogressresumereviewremediationnext steps

Finding and Fixing a Mistake in a Plan

with Byte

Byte the robot stands in a cozy kitchen, holding a recipe card and looking puzzled at a lumpy, lopsided pancake on the stove. Byte points with one finger at step three on the card, eyes wide with discovery.

Explain what it means when a plan has a broken step.
Identify which step in a short set of instructions caused something to go wrong.
Describe what debugging means in your own words.
Predict what will happen after the broken step is fixed.

Key terms

plan: a list of steps that tells you what to do
bug: a broken step that makes a plan go wrong
debugging: looking for a bug and then fixing it
test: trying the plan again to check the fix worked

Something Wrong Is a Clue

When you follow a plan and the ending is not what you wanted, do not feel upset. That surprise is actually a helpful clue. It tells you that one of your steps is broken, even before you know which one. A lumpy pancake or a still-dry plant is the plan waving a flag, saying look closer. Good problem solvers treat a wrong result as the start of a hunt, not as a reason to give up.

Checking One Step at a Time

Debugging means going through your steps slowly, one at a time. For each step you ask a simple question: did this step do what I expected? As long as the answer is yes, you move on. The first step where the answer is no is your bug. This careful, in-order checking beats guessing, because a plan can look fine overall while one hidden step quietly causes all the trouble.

Fix It and Try Again

Once you spot the broken step, you change it so it does the right thing, and you leave the working steps alone. But the job is not over until you try the whole plan again. Running it a second time proves the fix really worked. Even the best planners find bugs in their plans, so finding and fixing them is a normal and even fun part of building anything that follows steps.

Worked examples

Find the broken step in this thirsty robot plan.

Step 1 picks up the cup, which works fine, so move on.
Step 2 drinks the juice, which should make the robot not thirsty, but the robot is still thirsty, so this step did not work.
Step 3 puts shoes on, which has nothing to do with thirst, so the bug is in step 2.

Answer: Step 2 (drink the juice) is the broken step, because drinking should end the thirst but did not.

Hi, I am Byte! I love making plans — lists of steps that tell you exactly what to do. But sometimes a plan has a mistake hiding inside it. When you follow the plan and something goes wrong, that is a clue! It means one of the steps is broken. Finding the broken step is called debugging. Debug means look for the mistake and fix it. Here is how you debug: Go through each step, one at a time. Ask yourself — did this step work the way I expected? When you find the step that did NOT work right, you found the bug! Then you fix it. Change the broken step so it works. Now your plan is ready to try again. Even the best planners find bugs. Fixing them is part of the fun!

Activity

Byte wants to make a sandwich but something went wrong! Tap the broken step to find the bug, then tap the fix to repair the plan.

Practice

A sandwich plan says to put the bread in your pocket; find and replace the broken step.

Tell a friend why we try the whole plan again after fixing a broken step.

Common mistakes to avoid

A wrong result means start all over.You only need to find and fix the one broken step, not throw the whole plan away.
After you change a step the plan is done.You should try the plan again to be sure the fix really worked before calling it finished.

Check your understanding

Byte follows a plan to water a plant, but the plant stays dry. What should Byte do first?

Byte fixed the broken step in a plan. What should Byte do next?

A robot follows these steps: 1 - Pick up the cup. 2 - Drink the juice. 3 - Put shoes on. But the robot is still thirsty! Which step is most likely broken?

Recap

When a plan gives a wrong result, that is a clue that one step is broken. Debugging means checking each step one at a time, asking if it did what you expected, until you find the bug. Then you fix that one step and try the whole plan again to make sure the fix worked.

Reflect

What is a plan of yours that went wrong, and how did you find the broken step?