Explain one interaction as input → event → validation → rule → state → output.
Interactivity and Simple IntelligenceTurn a design contract into observable behavior and test evidence.
A working feature is not “the agent said it is done.” It is an observable chain from input to event to validation to rule to state to output, supported by expected-versus-actual tests and a human approval decision.
Bring or recreate the Topic 8 input, event, exact rule, output, missing-input behavior, and three expected tests—or use the course Study Sprint Interaction Lab. No AI account, coding agent, prior packet, API key, backend, paid tool, private data, or public deployment is required.
Four outcomes you can demonstrate.
The focus is judgment students can show, not vocabulary they can merely repeat.
Implement or configure one working client-side behavior through an own-app, supplied-lab, or approved accessible route.
Run normal, missing-input, and revise/repeat cases with exact expected and actual results.
Localize one failure or passed edge case, protect secrets, explain one behavior section, and approve the Topic 10 handoff.
Two meetings with separate learning arcs.
Meeting 1 plans 68 taught minutes plus a 12-minute flex and access buffer; Meeting 2 plans 68 plus 12.
Build and Trace One Client-Side Interaction
Recover the Topic 8 oracle, predict a bounded change, and watch a teacher-led Claude Code edit with browser retests. Then reveal the six-stage interaction pipeline, run the Study Sprint lab, specify a bounded rule, and capture the first three tests.
- Retrieve, predict + teacher editFirst 5 minutes: recover six decisions and predict. Next 6: teacher requests a real file edit, inspects the diff, and retests—or labels the prepared fallback. Stop at minute 11.
- Interaction pipelineReveal six browser responsibilities and map them to one source example.
- Lab Rounds 1–2Trigger missing input, then run a successful transparent-rule result.
- Rule + testsSpecify one bounded behavior and run normal, missing-input, and revise/repeat checks.
- Checkpoint + flex/access bufferSave the trace and tests; use the course lab when setup is unavailable.
Diagnose, Retest, and Protect the Boundary
Retrieve the test oracle, localize an observed failure, choose a minimal fix, rerun regression checks, distinguish local logic from fetch/API architecture, and prepare a Topic 10 evidence handoff.
- Retrieval + bug contractRecover expected/actual evidence and write a reproducible failure or passed edge case.
- Diagnosis Rounds 1–2Localize a course-lab bug, choose the smallest fix, and reject unrelated edits.
- Retest + network boundaryRun focused and regression checks; distinguish local rules, fetch, and model APIs.
- Secrets + evidence packetRespond to a fake exposed-key scenario, explain one behavior section, and package the Topic 10 handoff.
- Flex/access bufferComplete missing evidence and verify accepted formats privately.
Interaction Evidence Packet
Show one working client-side interaction, an observable six-stage trace, three expected-versus-actual tests, one calibrated diagnosis or passed edge-case analysis, and a safe Topic 10 handoff.
What to submit
- Submit one completed packet through the course LMS before Topic 10. Preferred filename: Lastname-Topic09-InteractionEvidence.pdf; maximum five pages. LMS text, DOCX/export, scanned paper, or an instructor-approved accessible alternative is accepted. The LMS supplies the exact deadline and grading-policy details.
- Use either your own client-only app, the course Study Sprint Interaction Lab, or an approved accessible working-interaction route. All routes receive the same maximum credit for equivalent evidence; AI/coding-tool access and generated-code volume earn no automatic advantage.
- Most evidence is drafted during the two meetings. Plan about 35–55 minutes to finish the packet afterward; allow longer if beginning from a blank packet.
- Include the Topic 8 oracle (input, event, exact rule, output, missing-input behavior), a six-stage trace, the one implemented/configured change, and three tests with exact expected result, actual result, and pass/fail.
- Include one expected-versus-actual diagnosis and retest, or one deliberately chosen passed edge case with a no-bug explanation. State evidence, suspected pipeline stage, smallest change or reason no change was needed, focused test, regression checks, and remaining limitation.
- Include a local/fetch/model-API architecture decision, a fictional exposed-secret response, a plain-language explanation of one behavior section, route/assistance disclosure, and the Topic 10 smoke-test handoff.
- Do not submit source archives unless the LMS explicitly requests them, API keys, credentials, repository/account/device screenshots, push-protection alerts, access proof, full chat histories, private logs, real student/peer/instructor records, or unnecessary identity evidence.
Core sources and optional extensions.
The class deck contains the required explanation. These links support verification, deeper reading, or alternate access.
Topic 10: Complete and Deploy—or Demonstrate Locally
Own-app students carry their local file. Course-lab students carry the lab link, configuration, and test record into a course-owned continuation. Both run the same essential smoke checks and can use a public or equal-credit local fallback.