The next person can identify the user, task, and instructions.
Screen 1 of 100:00–0:05
Complete one project without expanding its promise.
By the end of Meeting 1, your own app or the course continuation should pass four release gates, have a named last-working checkpoint, and complete the local smoke test.
RELEASE
CANDIDATE
CANDIDATE
1 · PURPOSEWho is it for, and what should they do?
2 · BEHAVIORDo normal, error, revise, and recovery paths work?
3 · ACCESSCan a person understand and control it?
4 · PUBLIC SAFETYIs every shipped file and value authorized?
Expected results survive normal, error, revise, and recovery paths.
People can understand, operate, and correct the interface.
Only authorized files and values enter the shared package.
Discuss: what evidence separates “the feature worked once” from “another person can open and trust this release candidate”?
Why this leads forwardThe Topic 9 handoff supplies the interaction and oracle; the course route supplies an equivalent continuation.
5 MIN
Screen 2 of 100:05–0:12
Bring the Topic 9 interaction—or open the course continuation.
Prior completion never gates Topic 10. Own-app students carry a local file and tests. Course-lab students carry the lab link, configuration, and tests into the supplied Release Lab.
Course continuation: Study Sprint Release Lab packages the Topic 9 fictional task planner as one public-safe HTML file. It supports the same normal, missing-input, revise, release-route, and recovery checks.
Topic 10 boundary
No login, backend, model API, secret, private data, consent/assent record, student identity evidence, analytics, account proof, or public deployment is required.
Local package
Open the last working local file or folder.
Release Lab
Use the same Study Sprint behavior in a release-ready single file.
Accessible route
Predict, observe, and record the same checks.
Why this leads forwardBefore changing anything, the class needs a shared definition of completion.
7 MIN
Screen 3 of 100:12–0:20
What would let a reviewer call this project complete?
A one-feature project can be complete for its stated boundary. A ten-feature project can still be unsafe or unusable.
A student wants to add login, AI recommendations, and a database before sharing. Which one missing property would you repair first, and which expansion would you reject?
1 · COMMITWrite one decision and its evidence.
2 · CHALLENGEAsk what could fail after packaging or sharing.
3 · REVISENarrow the release claim or add a check.
Working alone? Write the strongest case for release and the strongest reason to pause, then decide.
Course clarification
Repair the smallest load-bearing gap: clear purpose, reliable behavior and recovery, accessible control, or public-safe data. Reject new login, backend, model, or sensitive-data scope unless a later assignment explicitly authorizes and tests it.
Why this leads forwardThe four gates make that completion claim observable.
8 MIN
Screen 4 of 100:20–0:28
Four gates. Which ones can a reviewer actually inspect?
A gate passes only when the current project provides evidence. “Looks good” and “the agent said done” are not evidence.
After all four: name the weakest gate and cite one visible observation—not a confidence impression.
Why this leads forwardRound 1 applies the gates to the course continuation or an own app.
8 MIN
Screen 5 of 100:28–0:37
Round 1: Rate the current package from evidence.
Open the Release Lab or your app. Inspect the title/instructions, normal/error/revise paths, keyboard/user controls, and the visible public-data boundary.
Which audit statement is defensible before running the tests?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your evidence, then revise one field.
Record: one observed pass, one unverified gate, and the next check.
Why this leads forwardRound 2 decides the smallest completion change or justified no-change.
9 MIN
Screen 6 of 100:37–0:45
Round 2: Choose one completion move—and stop there.
Examples: clarify instructions, add a missing-input message, preserve a valid value, add a revise/reset control, repair a label, remove sensitive sample data, or document why no change is supported.
Which one move most improves the weakest gate? What evidence will show that it worked, and what tempting extra feature stays out of scope?
1 · COMMITWrite one decision and its evidence.
2 · CHALLENGEAsk what could fail after packaging or sharing.
3 · REVISENarrow the release claim or add a check.
Working alone? Write the strongest case for release and the strongest reason to pause, then decide.
Course clarification
A bounded completion move names one gate, one change or justified no-change, one expected check, and one explicit non-goal. Optional agent help must preserve that boundary and must be reviewed by the student.
Why this leads forwardA checkpoint protects the current working state before the bounded change.
8 MIN
Screen 7 of 100:45–0:51
Name the last-working state before you touch the release candidate.
A checkpoint may be a copied file/folder, an editor version, a platform snapshot, or a Git commit. Git is optional; recoverability is required.
Write: “My checkpoint is ___; it restores ___; it does not contain ___.” Then tell a partner what observation would trigger restore. Working alone? Write the observation that would trigger restore, and what you would check first.
Why this leads forwardThe public-file manifest defines exactly what belongs in the package.
6 MIN
Screen 8 of 100:51–0:58
You ship the folder. Which of these files can a stranger open?
A static project can be one HTML file or a small folder. The browser can inspect HTML, CSS, JavaScript, images, and sample data sent to it.
Human inspection: circle every file in the published folder, including any nothing links to. For each one, ask, “May an unknown visitor inspect every value in this file?”
Exclude from the package: secrets, credentials, answer keys, full AI chats, private prompts, grades, health or identity details, consent/assent records, student names, and restricted course files.
Static architecture synthesis from MDN Learn Web Development and GitHub Pages documentation.
Why this leads forwardThe local smoke test now checks the package rather than trusting the editor preview.
7 MIN
Screen 9 of 100:58–1:04
Run the essential checks from the packaged route.
A smoke test is a short set of essential checks after packaging or release. Reuse the Topic 9 oracle; do not invent new expectations after the run.
Before running: write the exact expected result. After running: record route, actual result, pass/fail, and one limitation. Public safety always requires human package inspection.
Why this leads forwardThe checkpoint packages the four-gate audit and local evidence for Meeting 2.
6 MIN
Screen 10 of 101:04–1:08
Leave with a release candidate—not a vague “finished” claim.
Use the protected buffer for missing evidence or the course continuation. Meeting 2 changes the route and tests the package again.
Four gates
Observed rating + weakest gate.
One bounded move
Or justified no-change.
Checkpoint
Named last-working state.
Local smoke
Expected vs actual.
Do not submit: repositories, credentials, account/device screens, consent/assent records, student identity data, private logs, or access proof.
Why this leads forwardMeeting 2 separates public publishing from the evidence of a trustworthy release.
4 MIN
Screen 1 of 110:00–0:05
Two release routes. What changes, and what must not?
Public deployment is optional. Every route must reopen the package, rerun the same checks, protect the same boundary, and explain recovery.
Predict before we test: what can break after a route change even when the editor preview worked? Name one route-specific failure and the check that would reveal it.
Why this leads forwardThe last-working checkpoint provides the comparison point for every route.
5 MIN
Screen 2 of 110:05–0:13
You have a public link. Is that proof? Of what?
A URL demonstrates reachability at one moment. It does not by itself establish correct behavior, access, privacy, authorship, understanding, or recovery.
Student A has a public URL but no recorded tests. Student B has no hosting account but demonstrates the local package, before/after smoke checks, limitation, and rollback. Which evidence better supports the learning target—and why?
1 · COMMITWrite one decision and its evidence.
2 · CHALLENGEAsk what could fail after packaging or sharing.
3 · REVISENarrow the release claim or add a check.
Working alone? Write the strongest case for release and the strongest reason to pause, then decide.
Course clarification
Student B currently provides stronger evidence of the course outcomes. Student A can strengthen the URL route by adding the same tests, boundary review, and recovery evidence. Hosting access must not determine the grade.
Why this leads forwardThe route choice now states exactly what changes and what remains equivalent.
8 MIN
Screen 3 of 110:13–0:20
Choose one route; use the same core rubric and route-specific evidence.
Public deployment adds real reachability, provider, and path evidence. Local/course-lab routes use a documented reopen or simulated route change. Every route must show package, before/after tests, boundary, recovery, and limitation without pretending the experiences are identical.
Choose and disclose: name your route and material assistance. Record a local path generically; never submit a private absolute path, account screen, repository, or access proof.
Why this leads forwardBefore changing routes, inspect exactly what would become public.
7 MIN
Screen 4 of 110:20–0:27
Assume every shipped static file can be read.
Removing text from the visible page is not enough if the value remains in JavaScript, comments, data files, storage defaults, images, or downloadable assets.
PUBLIC STATIC PACKAGE
Which package is eligible for the public route?
Choose one answer; that click commits your judgment and reveals its rationale. Compare it with your evidence, then revise one field.
Then inspect: filenames, source text, comments, sample data, images, saved defaults, generated artifacts, provider terms/privacy, account eligibility, site visibility, visitor logging/retention, takedown control, and whether the app solicits real input.
Why this leads forwardThe release map explains what an optional static host does and does not do.
7 MIN
Screen 5 of 110:27–0:31
Static hosting serves your files. What does it not do?
A host receives public static files and serves the entry page and assets. Updates require another publish action. Secrets and protected computation do not belong in the browser package.
Point to the boundary where a secret becomes public. Then explain why adding a host does not add authentication or protected computation.
Optional route: GitHub Pages Quickstart. Account setup and remote publishing are not required in class.
Why this leads forwardThe post-route smoke test detects packaging and route-specific failures.
4 MIN
Screen 6 of 110:31–0:39
Repeat the same checks after the route changes.
Do not weaken expectations to make a release pass. Compare route, version/checkpoint, expected result, actual result, status, and evidence.
Run in the new route: public URL, reopened local package, Release Lab simulation, or projected transcript. Compare the same expected results with the new actuals. The lab may execute behavior checks; it never auto-passes human package review.
Why this leads forwardA controlled release-only failure gives the class a precise diagnosis target.
8 MIN
Screen 7 of 110:39–0:47
Local works. Released route loses its styles. What is supported?
Observed: title and interaction load, but the released simulation reports a missing stylesheet path. Local behavior tests still pass. The exact source line has not been inspected.
ROUTE
CHANGE →
CHANGE →
What is the most specific supported diagnosis, what remains uncertain, and what focused plus regression checks should follow a correction?
1 · COMMITWrite one decision and its evidence.
2 · CHALLENGEAsk what could fail after packaging or sharing.
3 · REVISENarrow the release claim or add a check.
Working alone? Write the strongest case for release and the strongest reason to pause, then decide.
Course clarification
Supported: the failure is route/asset related rather than evidence that the interaction rule failed. Inspect the stylesheet reference, filename, case, and published manifest. After correction, reopen the release route, then rerun normal, missing/revise, keyboard/control, and public-boundary checks. Do not claim a precise source line without inspection.
Why this leads forwardRecovery uses the checkpoint when the release candidate cannot be corrected confidently.
8 MIN
Screen 8 of 110:47–0:51
The release broke and class is in ten minutes. What do you do first?
Choose based on evidence: keep the candidate, correct one supported cause and retest, restore the last-working checkpoint, or defer public release and use the local route.
Choose from evidence: keep, correct, restore, or defer. A documented local fallback is a successful learning route—not a failed assignment.
Why this leads forwardThe short workflow brief explains why the chosen release and recovery fit the user task.
4 MIN
Screen 9 of 110:51–0:58
Explain audit + eval + release/recover in 200 words total.
Use audit → eval → release/recover as one practitioner lens, adapted to this static learning prototype. It is not a claim of production readiness or a universal job definition.
BOUNDED
PROTOTYPE
PROTOTYPE
AUDITUser, task, bottleneck, rule, and human decision.
EVALUATEEssential checks with expected outcomes.
RELEASERoute plus authorized data boundary.
RECOVERCheckpoint, trigger, retest, and limitation.
AUDITUser, task, bottleneck, fixed rule, human decision.
EVALFive essential checks with expected outcomes.
RELEASE + RECOVERRoute, boundary, checkpoint, trigger, retest, limitation.
200 words total: support one claim about this prototype. Monitoring means reopening and retesting; rollback means returning to a known working file, snapshot, or commit. Do not imply analytics, backend, or production readiness.
Why this leads forwardThe packet combines the release evidence without requiring a repository or URL.
7 MIN
Screen 10 of 110:58–1:04
Assemble five pages of release evidence.
Most fields are drafted during class. The packet grades observable completion, verification, safety, recovery, and explanation—not access to hosting or an AI tool.
PAGE 1Route, contract, checkpoint.
PAGE 2Four gates + bounded move.
PAGE 3Manifest + pre-route smoke.
PAGE 4Post-route smoke + recovery.
PAGE 5Brief, review, limit, disclosure, Topic 11.
Accepted routes: public static URL, reopened local package, course Release Lab, projected/transcript interaction, LMS text, DOCX/export, scanned paper, or approved accessible equivalent. The PDF is the print route; use HTML/LMS/DOCX for accessible electronic completion.
Why this leads forwardThe close states the assignment boundary and carries the project into Topic 11.
6 MIN
Screen 11 of 111:04–1:08
Submit evidence of a release decision—not proof of account access.
Submit before Topic 11 using the LMS calendar. Bring or recreate the same project story next week regardless of packet status or whether a public URL exists.
Release Evidence Packet
Preferred filename: Lastname-Topic10-ReleaseEvidence.pdf; maximum five pages.
Public or local evidence
Same gates, smoke tests, recovery, and explanation.
Private/access evidence
No credentials, repository access, device/account screens, private paths, consent/assent records, identity data, or secrets.
Topic 11 handoff: project purpose → one supported capability claim → source trail → AI-use disclosure → one limitation → one career-ready story.
Why this leads forwardTopic 11 turns the verified project into research, source, disclosure, and career evidence.
4 MIN