Level 2 ▲ Orange: track card

Coding goal: Write your own behavioural rules and normal, invalid and boundary expectations before generation; explain one design choice and verify the final artifact.

These are planning estimates, not measured learner completion times. Keep the whole-room schedule. Use generation time to check content, write expectations or review the plan; do not fill it with cosmetic changes.

Evidence to leave with:

• Your own user, useful outcome and behavioural rules are written in the brief.
• Normal, invalid and boundary test expectations were written before generation.
• Explain one input, rule and response, and justify one design choice without reading the AI reply.
• All three original checks and the chosen boundary cases are rerun on the final saved file or permitted link.
• A peer finding, retest, tested version and any unfinished delivery or failed check are recorded.

Sprint 1: fifty minutes

At elapsed minute 20, save the available version, even if partial. A saved reference page, current project backup or numbered file is evidence of progress; name what still fails.

Peer testing: In the 20-minute swap, use the story/setup and two nine-minute silent tests. Hand over your own brief and final artifact; the peer runs three checks and two relevant edge cases and records any unclear requirement.

Sprint 2: twenty minutes

If stuck: Save the latest brief, code and fix log. Use a permitted alternative or a card 13 scaffold with a helper; reduce to one useful behaviour. Keep the current project as backup if conversion is unfinished, and record what still needs testing.

If ready: All original checks must pass first. Personal workflows take S12 before other stretches. Add one useful boundary or handoff test; choose Remember only when the outcome and red lines permit browser progress, and publishing only when it serves delivery.

Do not pretend a partial tool is finished. The final version is ready when its success checks pass; record every unmet check honestly. Use the four-minute retest for the changed or new case and three short core checks. Start content and access review during Sprint 1; ask a helper to review code and Network activity in parallel. If a check needs longer, record Not run, its next action and the version saved. Do not claim a pass or finished delivery from an incomplete run.

Write expectations before generation

Use three authored cases from your own brief. A normal case does the intended valid action; an invalid case tests a disallowed or missing action; a boundary tests an empty, first, last, repeated or reset state. These are behaviour checks, not requests for extra features.

Then explain one behaviour and one design choice in your own words: Input/action [ ] → rule/decision [ ] → response [ ]. I chose [ ] because it helps the user [ ]. Predict a variation before trying it. Your evidence must come from the final saved artifact, not only the preview.

Use the headed template on card 03 (version B). Your canvas fills these sections: outcome statement → 1; the user → 2; red lines → 6; success checks → 7 and 8.

Minimum in the session: sections 1, 3, 5, 6 and 7, plus your own normal, invalid and boundary cases written before generation. For a classroom activity, include a correct answer that must be accepted. For a teacher workflow, check the intended valid action, undo, reset and empty states; a quiz is not required.

Teacher workflow, including menu 9: adapt its Respond prompt and workflow checks on card 13 instead of the classroom build prompt below. Your brief states your own user, preparation task and checked steps. Do not add right/wrong feedback, wrong-try rules or retrieval activities.

This is a shorter version of the build prompt on card 04, which has the full rules. Paste your spec at the bottom.

Build the classroom tool described in my brief below as ONE self-contained HTML file: HTML, CSS and JavaScript in one file, with no external libraries, fonts, images or links. It must work offline, on a laptop or a phone.
No login. Nothing students type is saved or sent. No calls to any AI service or other website.
Students predict, choose or explain before any answer is revealed. All feedback says why an answer is right or wrong and what to do next. End with at least one question students answer from memory. After two wrong tries on a question, it says "Ask your teacher" or shows a worked example. Nothing decorative: no confetti, emoji, sound, points, streaks, leaderboards or timers, unless my brief says they serve the goal.
Access: text contrast of at least 4.5:1; right and wrong in words, not colour alone; everything works with the keyboard alone, with a visible focus outline; works at 320 pixels wide with no sideways scrolling.
When you have finished, list every fact, answer and formula in the file so I can check each one by hand, and anything you assumed. Do not add anything my brief does not ask for.

MY BRIEF:
[PASTE YOUR SPEC]

Before you open the result, write down three things you expect to see and one thing you expect it to get wrong. Then run your success checks one at a time, exactly as written.

Make and test the final .html file from AI Studio. Build mode may make a multi-file project; it does not guarantee an HTML code block. Ask for one self-contained HTML version of the current project, including every fix and the checked content. If no usable file is supplied, keep a project export as backup and use a permitted AI chat tool with your latest spec, current code and fix log (card 09). Save the complete file as aistudio-v1.html, then open it and rerun all three success checks and edge cases. Preview results do not establish that this new artifact works. In an AI chat tool: download the complete file, or use the universal fallback (card 09), then test the saved file.

• Save a version: save the complete .html file as -v1.html. In AI Studio, keep an export of the current project as backup if your single-file version is not ready. Preserve the latest spec and fix log; rerun the checks on the final saved file, as above.
• Rate yourself. Stuck: a sticky note on your laptop lid; a helper comes. On track: carry on. Ready for more: take a stretch card (card 14).

Find your test partner before the break. Pair with anyone at a different level; if you can't, pair with someone who hasn't seen your build. Sit next to them when you come back. An odd number makes one trio, with 6-minute turns.

1. The maker hands over the tool, the canvas and this card, then says nothing until the turn ends.
2. The tester runs each success check exactly as written, then tries two relevant edge cases from card 05: for a quiz, try no answer or a right answer in another form; for a workflow, try repeated use or an empty list; test keyboard use and phone width too. For phone width: Narrow the browser window to its smallest, or send the file to your phone.
3. The tester logs each failure in the bug log below: Check / Expected / What happened.
4. Swap roles.

Bug log. The tester writes here, on the maker's card.

Fix failed checks only: no new features. If none failed, write one new boundary check or clarify an unclear requirement; test it and repair only a real failure. One change per prompt. Re-run the check, then the others. Save each version that passes as -v2.html, -v3.html.

Success check [number] failed. When I [what I did], I expected [what should happen], but [what happened]. Fix only this.
Keep everything else unchanged. Explain what you changed and how I'd check it.

Share it: give students the .html file, by email or on your LMS, Teams or Google Classroom (card 09). They open it with no login.

Every check passes? Take S12 first for a personal workflow. Otherwise choose a useful boundary or handoff check, or the optional Remember or publishing stretch. Write the new success check first. Do not add Remember when your red line forbids persistence; menu 9 starts clean on reload.

• Respond → Remember. A Remember build may store progress in this browser only, never what students type, with a Clear button. For example: "When I reload halfway, it takes me back to the question I was on. When I press Clear, it starts clean." Your red line "save or send what students type" (section 6 of the headed template) stays as it is; write the Remember rule into section 5. Test it where students will open it: browsers differ for a file opened from the computer, and a private window forgets it.

Add one thing: it remembers [which question they reached] between uses, in this browser only, using the browser's own storage. Never store anything a student types. Add a clearly labelled "Clear" button that wipes everything it stored.
Keep everything else unchanged. Explain what you changed and how I'd check it.

• Publish a link. In AI Studio, Publish gives a public link (card 09 has the account rules). A public link is public (card 08). Open it in a private window, signed out, and re-run three of your checks on it before you share it.
• Think (AI inside the tool) is beyond this session: see card 18.

• Up: Claude Code or Codex installed and working? Pick up track card 12 and take your spec with you.
• Down: take a build menu item (card 13) and the fill-in-the-blanks spec (card 03, version A), and pick up track card 10.
• Your checks before anyone else uses it: card 08, safe building, then quality items 1 to 10.

The whole kit: www.deepeducationnetwork.com/courses/build-with-ai/kit