Keep this light and paced. Hold up the robot, then show one idea at a time so each meaning lands before the next word.

Beat 1: fan a short line of arrow cards and say program = the arrows in order.

Beat 2: swap one card for a wrong turn and say bug = a wrong arrow.

Beat 3: fan three forward cards and say short repeat = the same step more than once (ordinary classroom talk, not a third formal concept).

Only then give the one-line lesson goal. Show the taped mat and the robot briefly so pupils see the route shape, but do not run a full program yet.

Key question: If the robot only does what we press, whose job is it when it goes the wrong way? Draw out that the bug is in our program, not in the robot being naughty.

Before the lesson: tape a simple grid mat on the floor (about 4 by 4 squares, each square one Bee-Bot step), and plan parallel run space: 2–3 short taped paths and/or clear child-robot lanes with floor squares or desk-top grids so every group can run. Mark a clear start square and a finish square that needs at least one turn and more than one forward. Make simple arrow cards from sticky notes or scrap card (several forwards, a few left and right turns per group).

This is a floor demo with the real robot on the mat (not an on-screen program). Model one full cycle aloud so pupils hear predict → run → notice → fix.

Worked cycle to say (one deliberate bug story):

• I wonder: Can I get the robot from start to the finish square around the corner?
• I plan: Forward, forward, turn right, forward, forward should land on the finish.
• I enter by mistake: Forward, forward, turn left, forward, forward (deliberate bug on the turn).
• I test: Press Go. Let the class watch in silence on the mat.
• I observed: It turned the wrong way around the corner and missed the finish.
• I fix: Change turn left to turn right and try again. Now it lands on the finish.

Ask: Which step made it go wrong? What would you change?

Misconception to head off: children may say the robot is broken. Revoice: the robot followed the program perfectly; our job is to fix the steps.

Drive the algorithm-sequencer on the IWB in challenge mode. Pupils do not need devices. They call out which step comes next; you (or one helper) drag and Run.

Class job in one line: watch the grid, call out the next step, then say which step to change if it misses.

What appears on screen: a grid with a robot sprite and a goal square, plus step cards forward, turn left and turn right. Point to the step counter or leftover slots as you build so the class can see “6 or fewer”.

Required board run: Challenge 1 only (“Around the corner”) — a short route with one turn within 6 steps. Complete predict → run → freeze-and-debug → rebuild if needed so every pupil sees one full cycle.

If time remains: use Challenge 2 as a quick teacher-led model of a longer route with repeated forwards (show forward, forward, forward as a short repeat). Do not start Challenge 2 if Challenge 1 still needs a fix. The floor investigation needs the turn-and-repeat pattern seen at least once before groups plan.

After a failed run, freeze and ask the watchers: Where is the bug? Which step would you change? Fold the whole class in; do not invent a separate desk task.

Differentiation: if the class struggles, walk the route with your finger on the grid first, saying each step aloud before building it.

Intended run model (every group must get a predict–run–fix cycle)

Expected setup for a full 2nd Class whenever you have only one programmable robot: run groups in parallel with child-robot lanes (a child moves only when shown arrow cards on marked floor squares or a desk-top grid) and/or 2–3 short taped paths if you have space. Do not rely on a single shared mat for six or more groups.

If you have several robots and floor space: tape 2–3 short paths (start and finish on each) so two or three groups can run at once, with remaining groups on child-robot lanes.

One shared mat only when group count is small (about four groups or fewer): every group plans with arrow cards first, then rotates in short timed slots (about 2 minutes to enter, run, and try one fix). While waiting, groups refine their arrow sequence at desks.

If more than four groups: default to child-robot lanes or 2–3 taped paths so every group completes at least one predict–run–fix cycle inside this step. A queue on one mat is not enough for the learning objective.

Do not put several robots on one small mat at the same time.

Before groups start

Agree the class route shape: start square, finish square, and that every program must include at least one turn and a short repeat. Show three forward arrow cards together and say: this is a short repeat — forward, forward, forward. Groups may choose the exact steps.

Group roles (keep simple)

• Groups of three to four.
• One child enters buttons or lays out arrow cards; one watches the path; one checks the spoken sequence matches the cards.
• Before Go, the whole group says aloud where they think it will stop (oral only — no journal writing in this step).
• If it misses, they change one step at a time and try again.
• Journal recording of program, bug and fix happens in the next step, using whatever run they actually did (floor robot or child-robot).

What good looks like: a clear sequence said in order, a prediction before running, and at least one thoughtful fix after a miss (or a solid first-time success they can still describe).

Safety: clear the lane; robots roll only on the mat; no chasing the robot across the room; child-robots walk carefully on marked squares only.

This is the paper recording beat. Pupils write or draw on the Investigation Journal page only. Every group should have completed a real predict–run–fix cycle in the last step (floor robot, parallel path, or child-robot). Record from that real run.

Circulate and prompt with: What were the steps in order? Which step was the bug? What did you change?

If a group landed on the finish first time, use the near-miss prompt only as extension: What wrong step would have sent it the wrong way? Do not use invent-a-bug as cover for groups who never ran; send those groups back for a quick child-robot run before writing if needed.

Journal stems (if the page is plain paper): Program in order; Bug we found; What we changed.

Do not ask pupils to type into the platform. Fast finishers can add one extra improvement they would try next time on the same page, or watch another group debug and whisper one tip.