What authorized value enters?
Screen 1 of 100:00–0:05
Make one interaction observable from beginning to end.
By the end of Meeting 1, run one feature, map its input-to-output pipeline, and compare three expected results with what the browser actually did.
WORKING
INTERACTION
INTERACTION
INPUTAuthorized value
EVENTUser action
RULEExact transformation
EVIDENCEExpected vs actual
What user action starts the behavior?
What exact transformation occurs?
Which expected-versus-actual record proves it?
Opening discussion: Why is one polished result insufficient evidence that an interaction works? Name one alternative path you would test. Then predict: if Study Sprint adds 30 minutes, what three times should appear? What must survive a blank task?
Why this leads forwardThe Topic 8 contract already contains the oracle needed to judge the first behavior.
5 MIN
Screen 2 of 100:05–0:11
Watch the file change. Then verify the browser.
Packet completion never gates Topic 9. Retrieve these six decisions or use the supplied contract. The test oracle is the expected result written before the run.
INPUTAuthorized value.
EVENTUser action.
RULEExact mapping.
OUTPUTVisible result.
ERRORMissing-input state.
TESTSThree expected results.
Teacher demonstration: predict → request 30 in Claude Code → inspect the changed file → refresh the local preview → compare expected with actual.
Open the live-edit guide, starter, prompt, and tests · Check 30 → 2 / 25 / 3, blank/spaces recovery, and old choices.
Six-minute limit: at minute 8, if no edited file is ready to inspect, open the labeled prepared reference. At minute 11, move to the pipeline; mark unrun checks.
Full-credit recovery route: Study Sprint Interaction Lab; no setup, student AI account, or prior file is required.
Why this leads forwardThe six pipeline stages explain where the observed file change becomes browser behavior.
6 MIN
Screen 3 of 100:11–0:19
You click the button. Name every step between click and result.
Reveal one stage at a time. This is an analytic trace for this feature, not a universal browser execution order. Every stage produces something a reviewer can name or test.
1 · INPUTRead task + duration
2 · EVENTListen for submit/click
3 · VALIDATEAccept or explain
4 · RULECompute exact steps
5 · STATEPreserve or replace remembered values
6 · OUTPUTUpdate what the user sees
After all six: the correct result exists in memory but never appears. Which stage should you inspect first—and what observation separates state from output?
Course synthesis from MDN Events and MDN DOM scripting.
Why this leads forwardRound 1 runs the chain with deliberately missing input.
8 MIN
Screen 4 of 100:19–0:28
Round 1: Submit with the task empty. What should happen?
In the course lab, choose 25 minutes, leave Task blank, and press Build my plan. Commit your expected state before running it.
Course recovery app: Study Sprint reads one fictional task and a 15/25/45-minute choice, applies a transparent time-split rule, and displays prepare/focus/reflect steps.
Topic 9 boundary
Client-side only. No login, backend, database, model API, secret, private data, or public deployment.
INVALID FIELDTask is blankShow a specific linked message and direct focus or attention here.
+
VALID STATE25 minutesKeep this choice while the student corrects only the missing task.
What should the defensible result preserve?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your evidence, then revise one field.
Run and record: expected state, actual state, preserved value, focus/attention, and pass/fail.
Why this leads forwardRound 2 uses valid input and makes the exact rule observable.
9 MIN
Screen 5 of 100:28–0:37
Round 2: Predict the exact result before the browser shows it.
Rule: reserve 2 minutes to prepare and 3 minutes to reflect; assign the remaining time to focus. Input: “Read chapter” + 25 minutes.
What exact output should appear, which values should remain visible, and what revise/repeat action should the user have?
1 · COMMITWrite the behavior or evidence you would expect first.
2 · CHALLENGEAsk which pipeline stage, boundary, or test is still missing.
3 · REVISEChange one decision and record what evidence changed it.
Working alone? Write two plausible explanations, test both against the visible evidence, then choose.
Course clarification
Expected result: Prepare 2, Focus 20, Reflect 3. Keep the task and 25-minute choice visible. Provide a revise or start-over action. The rule is “simple intelligence” because it is bounded, inspectable, and repeatable—not because it imitates a person.
Why this leads forwardThe next screen maps that observed result to a small source flow.
9 MIN
Screen 6 of 100:37–0:45
Read the source. Who or what is responsible for each part?
The source map shows where the browser finds controls, listens for the event, applies the rule, preserves state, and updates the page.
1 · SELECTFind task, duration, form, error, and result elements.
2 · LISTEN
form.addEventListener('submit', buildPlan)3 · DECIDEBlank → error; valid → apply the time rule.
4 · RENDERSet text, move focus, and preserve or reset state intentionally.
Which line of reasoning best explains Enter-key support?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your evidence, then revise one field.
Why this leads forwardA bounded feature contract now connects the source responsibility to the student’s own concept.
8 MIN
Screen 7 of 100:45–0:52
Where does this rule stop working, and can you say why?
A decision table, scoring rule, category match, template, or safe random choice can adapt output without a model. It must not infer private conditions or claim expertise it does not have.
Compare “if energy is low, show a short low-effort option” with “if the student seems depressed, prescribe what they should do.” Which inputs are authorized, which claims overreach, and how would you narrow the second rule?
1 · COMMITWrite the behavior or evidence you would expect first.
2 · CHALLENGEAsk which pipeline stage, boundary, or test is still missing.
3 · REVISEChange one decision and record what evidence changed it.
Working alone? Write two plausible explanations, test both against the visible evidence, then choose.
Course clarification
The first rule uses a user-chosen category and returns a bounded suggestion the user can reject. The second infers a sensitive condition and makes a health-like prescription. Remove the inference and high-stakes claim; use fictional or non-sensitive choices and advice-light output.
Why this leads forwardThe three manual tests convert the chosen rule into evidence.
7 MIN
Screen 8 of 100:52–1:00
Write three tests. What must each one prove?
Reveal the sequence. Record exact expected behavior before running each case; then record actual behavior without editing the expectation afterward.
TEST 1 · NORMALValid inputExact output values and visible state.
Expected: 2 / 20 / 3
TEST 2 · MISSINGRecoverySpecific error, focus/attention, preserved valid work.
Expected: Task error + 25 kept
TEST 3 · REVISEReplacementNew result replaces stale state; no duplicate output.
Expected: one current result
For your route, record input/action, exact expected result, actual result, and pass/fail for all three tests.
Why this leads forwardA failed or surprising result becomes a diagnostic trace—not a reason to add random edits.
8 MIN
Screen 9 of 101:00–1:04
Choose a working route; keep the evidence standard constant.
The assignment evaluates trace, tests, diagnosis, explanation, and boundaries. Own-app students implement; course-lab students configure. Code authorship differs, but both demonstrate the Topic 9 evidence outcomes.
Configure + test
Keep or change allowed integer rule values, update the oracle consistently, run three tests, and explain the behavior.
Implement + test
Use a local editor or approved agent; keep the same client-only scope and evidence fields.
Ask before class
Message the instructor through the LMS for a keyboard, projected, transcript, or equivalent five-page route.
Disclosure: name the route and assistance used. Lab-route students carry the lab link, configuration, and test record into the Topic 10 course-owned continuation.
Why this leads forwardThe checkpoint preserves the trace Meeting 2 will diagnose and defend.
4 MIN
Screen 10 of 101:04–1:08
Leave with one trace and three expected-versus-actual records.
Complete missing fields during the protected buffer. Meeting 2 starts from one failure, surprise, or deliberately injected course-lab bug.
Six stages
Input through output.
One behavior
Own app or course lab.
Three cases
Expected, actual, pass/fail.
Client-side
No secrets or private data.
Before leaving: circle one result that deserves diagnosis or one passed edge case that deserves explanation.
Why this leads forwardMeeting 2 turns that evidence into a minimal diagnosis, fix decision, and safe architecture boundary.
4 MIN
Screen 1 of 100:00–0:06
Diagnose what happened—not what you assume happened.
Bring one failing result, surprising result, or passed edge case. Keep the exact input, action, expected result, and actual result visible.
INPUTExact values.
ACTIONExact event.
EXPECTEDOracle.
ACTUALObserved.
REPEATReproducible?
Read your evidence aloud to a partner—or write it alone—without using “broken,” “weird,” or “doesn’t work.”
Why this leads forwardA bug contract makes the observation reproducible before anyone edits code.
6 MIN
Screen 2 of 100:06–0:14
What has to be in a bug report before someone can act on it?
Reveal the sequence. Stop adding features while the observed result disagrees with the oracle.
1 · REPRODUCESame steps, same result?
2 · LOCALIZEWhich pipeline stage?
3 · REDUCESmallest failing case
4 · FIXOne targeted change
5 · RETESTFocused + regression
6 · RECORDEvidence + limitation
Which step prevents a confident agent explanation from replacing observed evidence—and what artifact should that step produce?
Why this leads forwardRound 1 uses this sequence on a deliberately injected state-preservation bug.
8 MIN
Screen 3 of 100:14–0:24
Round 1: The error is right, but something else broke. What?
Course bug: choose 25 minutes, leave Task blank, submit. Actual: linked Task error appears and focus moves correctly, but duration resets to 15.
EXPECTEDTask error + 25 keptValidation explains the blank field; valid duration survives.
≠
ACTUALTask error + 15 resetThe message and focus are correct, but the valid duration changes.
Which pipeline stage is the most specific first target?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your evidence, then revise one field.
Packet diagnosis: evidence → pipeline stage → smallest suspected cause. Do not claim a root cause until source or behavior supports it.
Why this leads forwardRound 2 chooses the smallest correction and names what must not change.
10 MIN
Screen 4 of 100:24–0:32
Round 2: Define the fix before asking an agent to edit.
The successful 25-minute output already works. Only the blank-task branch resets duration. The fix must preserve error text, focus, success behavior, and the 15/25/45 options.
Write the smallest edit request, the focused failing test, and two regression checks. Which unrelated “improvements” should be rejected during this fix?
1 · COMMITWrite the behavior or evidence you would expect first.
2 · CHALLENGEAsk which pipeline stage, boundary, or test is still missing.
3 · REVISEChange one decision and record what evidence changed it.
Working alone? Write two plausible explanations, test both against the visible evidence, then choose.
Course clarification
Request only that the blank-task path stop changing duration. Course-lab simulation: record the bug, select Prepare corrected simulation to disable injection and restore 25, then rerun blank + 25. This simulates corrected behavior; it is not a source edit. Regression: valid Task + 25 stays 2/20/3; revise 15 to 45 replaces the result. Reject redesign, dependencies, new features, or model calls.
Why this leads forwardThe next screen separates a reported fix from a verified fix.
8 MIN
Screen 5 of 100:32–0:38
The agent says it is fixed. What do you do before believing it?
Run the focused case first, then regression checks—short reruns of behavior that previously worked. Record actual results; do not copy the expected column into the actual column.
The focused test passes, but the 25-minute success case now shows Focus 25 instead of 20. What is the correct status?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your evidence, then revise one field.
Why this leads forwardWith local behavior verified, we can distinguish it from optional network/API architecture.
6 MIN
Screen 6 of 100:38–0:45
Three ways to add intelligence. What does each one obligate you to?
Topic 9 requires only local browser behavior. A network request adds downtime, response/status, source, privacy, browser-permission, and error-handling questions; a protected API adds an approved server-side secret boundary.
REQUIRED ROUTELocal ruleBrowser + transparent code. No network or secret.
FAILURE: rule/state mismatch
OWNER: student tests behavior
FAILURE: rule/state mismatch
OWNER: student tests behavior
CONCEPT ONLYPublic fetchBrowser requests a public resource and handles response status.
ADDS: downtime, source, parsing, failure states
ADDS: downtime, source, parsing, failure states
NOT A TOPIC 9 BUILDModel APIClient → approved server/proxy → provider.
ADDS: secret boundary, variable output, cost, privacy, verification
ADDS: secret boundary, variable output, cost, privacy, verification
For each lane, name one new failure mode and one new human responsibility. Why can the browser not safely hold a private API key?
Reference: MDN Fetch API. Fetch returns a response promise; network use still requires explicit status and failure handling.
Why this leads forwardThe architecture distinction makes the exposed-key scenario unambiguous.
7 MIN
Screen 7 of 100:45–0:52
Your key is in the JavaScript the browser downloads. Who can read it?
Scenario: an assistant places a realistic-looking API key in app.js and suggests committing it. Treat the displayed key as fictional; never paste a real credential into class evidence.
1 · STOPStop disclosure. Do not commit, share, or keep testing with the displayed key.
2 · NOTIFYTell the owner and the instructor. If you cannot revoke it yourself, this is how it gets revoked.
3 · REVOKEAssume it is live. Have it revoked and replaced before any cleanup — removing it from a file does not make it unusable.
4 · REDESIGNMove protected calls behind an approved server-side boundary.
What is the strongest response?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your evidence, then revise one field.
References: OpenAI production key guidance and GitHub push protection.
Why this leads forwardSafe approval also requires the student to explain the behavior they are accepting.
7 MIN
Screen 8 of 100:52–0:58
Explain one behavior section at the responsibility level.
A student does not need to recite every token. They must identify what triggers the behavior, what input it reads, what decision it makes, what state it changes, and what visible result proves it.
Use the Study Sprint event flow or your own app. Explain it in five plain-language sentences, then name one limitation or condition you have not tested.
1 · COMMITWrite the behavior or evidence you would expect first.
2 · CHALLENGEAsk which pipeline stage, boundary, or test is still missing.
3 · REVISEChange one decision and record what evidence changed it.
Working alone? Write two plausible explanations, test both against the visible evidence, then choose.
Course clarification
Strong explanation: submitting the form triggers one handler; it reads task and duration; the blank branch shows a linked error and preserves duration; the valid branch applies the 2 / remaining / 3 rule; the result region is replaced and announced. Limitation: only the approved duration choices were tested.
Why this leads forwardThe packet packages implementation, tests, diagnosis, safety, and explanation for Topic 10.
6 MIN
Screen 9 of 100:58–1:04
What counts as evidence here, and what does not?
Own-app and course-lab routes use the same evidence fields. The PDF is for printing; use editable HTML, LMS text, DOCX/export, or an approved route for accessible electronic completion.
PAGE 1Route + Topic 8 oracle.
PAGE 2Six-stage trace + working change.
PAGE 3Three tests: expected vs actual.
PAGE 4Diagnosis, fix/no-bug case, retest.
PAGE 5Architecture, secret response, explanation, disclosure, Topic 10 handoff.
Evidence boundary: no full source archive, generated-code volume, AI chat, credentials, account/device screen, access proof, private log, or public URL is required.
Why this leads forwardThe close defines exactly what Topic 10 may reuse.
6 MIN
Screen 10 of 101:04–1:08
One behavior. Three tests. One diagnosis. One safe handoff.
Submit the packet before Topic 10 using the LMS calendar. Bring or recreate the same interaction in Topic 10 regardless of packet score or completion status.
Interaction Evidence Packet
Preferred filename: Lastname-Topic09-InteractionEvidence.pdf; maximum five pages.
Own app or course lab
Lab handoff = lab link + configuration + test record; Topic 10 supplies the course-owned continuation.
Secrets or access proof
No keys, credentials, account/device screens, full chats, private logs, or unnecessary identity evidence.
Topic 10 handoff: working interaction → tests or disclosed limitation → smoke-test list (short essential checks after packaging) → deployment or equal-credit local/course-lab fallback.
Why this leads forwardTopic 10 completes, packages, and smoke-tests the static project without making public deployment a grading gate.
4 MIN