Assignment 4 · Part 2

Interaction Evidence Packet

Topic 9: run one working client-side behavior, trace six stages, compare three expected and actual results, diagnose one case, protect the architecture boundary, and prepare Topic 10.

NameDate

Due

Before Topic 10; use the LMS calendar.

Preferred submission

One five-page PDF

Lastname-Topic09-InteractionEvidence.pdf. The PDF is for paper/printing; use this editable HTML, LMS text, DOCX/export, or an approved route for accessible electronic completion.

Equal-credit routes

Own app or course lab

Tool access, generated-code volume, framework choice, and visual polish earn no automatic advantage.

Work plan: draft pages 1–3 in Meeting 1 and pages 4–5 in Meeting 2; plan about 35–55 minutes to finish afterward. Ask the instructor through the LMS before class for an approved accessible route; the same five-page maximum applies.

Local-save route: responses save only in this browser; nothing is sent, and your name is never saved. On a shared device, use fictional data, save only to personal storage, select Clear visible responses + local draft, remove downloads/print artifacts, and close the browser.

Never submit: API keys, credentials, source archives unless requested by the LMS, account/repository/device screens, secret alerts, access proof, full chats, private logs, real records, or unnecessary identity evidence.

1 · Route and Topic 8 oracle

Working route

Authorized input

Event/action

Exact rule

Expected visible output

Expected missing-input state + preserved work

Why this route can produce the required working-interaction evidence

Return to Topic 9 hub

Local draft ready. Most fields should use 1–3 concise sentences.

Interaction trace

Explain what the browser did.

Use responsibility language. A short source excerpt or line reference is optional; do not paste a full generated file.

Stage	Responsibility in this interaction	Visible or source evidence
1 · Input
2 · Event
3 · Validate
4 · Rule
5 · State
6 · Output

Working change or configuration

One behavior implemented, configured, or intentionally preserved

What remained outside scope

Source/tool/assistance used

What I accepted, revised, or rejected—and why

Working evidence: use an actual course-lab or own-app run, a teacher-projected run with your own prediction/record, or an approved accessible transcript-backed interaction. A static description alone does not demonstrate the working-interaction outcome.

Expected versus actual

Run three manual tests.

Write the expected result before running the case. Record what actually happened without rewriting the oracle to make a failure pass.

Test	Input + action	Exact expected result	Actual result	Status
1 Normal
2 Missing
3 Revise

Test integrity

What valid state should remain after missing input?

What stale state must be replaced on revise/repeat?

Keyboard/focus or equivalent access check

What these three tests do not prove

Default course-lab oracle: normal “Read chapter” + 25 with rule 2/remaining/3 → 2/20/3; missing Task + 25 → linked message, focus/attention, preserve 25, no plan; revise 15 → 45 → 2/40/3 replaces the prior result. If you configure other allowed whole-number rule values, rewrite the expected results before running.

Evidence-first diagnosis

Localize, change one thing, and retest.

Use a failure, surprising result, deliberately injected course-lab bug, or a deliberately selected passed edge case.

Case route

Exact input, action, expected, and actual evidence

Most specific pipeline stage—and confidence

Smallest supported suspected cause—or why no defect is supported

Smallest change requested/made, or simulated correction—and why

Retest evidence

Focused test + actual result

Regression check 1 + result

Regression check 2 + result

Approve, revise, reject, or defer—and why

Remaining limitation or untested condition

Calibration: an observed state loss supports “the state path failed.” It does not prove the exact source line until source inspection or a targeted change/retest supports that conclusion. Course-lab route: record the injected failure, choose Prepare corrected simulation (disables injection and restores 25), rerun, and disclose that this simulated corrected behavior rather than editing source.

Architecture + approval + Topic 10

Protect the boundary and explain the handoff.

Architecture decision

Evidence, added failure modes, and human responsibility

Fictional key response: stop sharing it; notify the owner; if real, have it revoked and replaced (“rotated”) first; then, with approved help, remove it from files and inspect copies/history; never rewrite history destructively yourself; redesign the boundary Plain-language explanation: trigger, input, decision, state, output, and one limitation

Route and assistance disclosure

Topic 10 handoff: own app = local file; lab = lab link + configuration/test record. Add essential smoke checks, limitation, and deployment/local route.

Submission check

I included a working route, Topic 8 oracle, six-stage trace, and one implemented/configured behavior. I recorded three expected and actual results without changing the oracle to hide a failure. I included one calibrated diagnosis or passed edge-case analysis, focused retest, regressions, and limitation. I included architecture/secret safety, behavior explanation, disclosure, and Topic 10 handoff. I submitted no key, credential, account/device/repository screen, secret alert, access proof, full chat, private log, or real record.

Evidence anchors: complete evidence addresses every named element with observable expected/actual results and a calibrated approval decision; developing evidence leaves elements unclear or unsupported; incomplete evidence is largely unrun, untestable, or missing the working route. The instructor evaluates trace, behavior, tests, diagnosis, architecture/safety, explanation, disclosure, and handoff—not code volume, visual polish, framework, AI access, or account proof. Official points or course weight come from the LMS; this packet sets no automatic pass threshold.