Assignment 4 · Part 3 · Page 1

Release contract and checkpoint

Topic 10: complete one bounded static project, verify it before and after a release route, and document recovery. Most fields are drafted during the two meetings; plan 35–55 minutes after class to complete and edit.

NameDate

Due

Before Topic 11; use the LMS calendar for the exact date, time, timezone, late rule, and resubmission rule.

Equal-credit routes: own local app, optional public static route, reopened local package, Study Sprint Release Lab, projected/transcript interaction, or an approved accessible equivalent. A public URL is optional.

Concise-response guide: use one or two short sentences per box unless a prompt asks for a list. Use HTML/LMS/DOCX for longer accessible electronic responses.

Route and assistance usedProject purpose and user taskRelease contract: what must open, work, recover, remain usable, and stay public-safe?Explicit non-goals: what will not be added or claimed?Last-working checkpoint: name, what it restores, and where it is kept without exposing a private pathTopic 9 handoff or recovery oracle: normal, missing, revise, and boundary expectations

Privacy boundary: your own name is allowed only in the header and is never draft-saved. Do not put any student names inside project evidence. Never publish or attach secrets, credentials, account/device screens, private absolute paths, repository access, full chats, private prompts/logs, grades, health/identity data, consent/assent records, restricted course files, or unnecessary identity evidence.

Meeting 1 · Page 2

Audit four release gates.

Rate only from current evidence. If a gate is unverified, state the next check instead of guessing.

Gate	Observed evidence	Status	Next check or repair
1 · Purpose Title, audience, instructions
2 · Behavior Normal, error, revise, reset
3 · Access Labels, keyboard, control
4 · Public safety Authorized files/data

One bounded completion decision

Weakest gate and supporting observationOne change or justified no-changeExpected focused check and regression checksTempting expansion rejected as a non-goalOptional AI/agent suggestion: accepted, changed, or rejected—and whyCheckpoint action before the change

No-change is valid when the evidence supports all four gates for the declared boundary. It still needs an explanation and smoke evidence.

Meeting 1 · Page 3

Map the package and test locally.

List public-safe files or describe the course single-file route. Record expected results before actual results.

Entry file or course-lab routeCSS/JS/assets or “embedded in one HTML file”Authorized sample data and sourcesFiles/data explicitly excluded

Local check	Exact expected result	Actual result	Status
1 · Open/assets
2 · Normal
3 · Missing/revise
4 · Access
5 · Public safety

Local limitation not proved by these checksDecision after local checks: keep, revise, restore, or defer

Course-lab baseline: single HTML entry; embedded CSS/JS; fictional input; default normal “Read chapter” + 25 → 2/20/3; blank task → linked message, preserve 25, focus Task, no plan; revise 15 → 45 → 2/40/3 and replace stale output.

Meeting 2 · Page 4

Retest after the release route and recover.

A public URL is optional. Use the same oracle for public static, reopened local, course simulation, or projected/transcript evidence.

Real-host public-safety check: review provider terms/privacy, account eligibility, site visibility, visitor logging/retention, takedown control, and whether the app solicits real input. Local/course-lab routes label these items not exercised.

Release route usedVersion/checkpoint tested

Post-route check	Exact expected result	Actual result	Status
1 · Open/assets
2 · Normal
3 · Missing/revise
4 · Access
5 · Public safety

Release diagnosis or passed edge case

Observed result; do not guess the causeMost specific supported stage and confidenceCorrection, restore, or defer decisionFocused retest plus regression results

Controlled lab fault: a simulated missing stylesheet path (as if the lab’s styles lived in a separate styles.css) supports a route/asset diagnosis. Inspect reference, filename/case, and manifest before claiming a precise source cause. The “corrected simulation” does not edit or publish a real file.

Meeting 2 · Page 5

Explain the release and carry evidence forward.

Use short, specific prose. This is a static learning prototype, not proof of production readiness.

200 words total: Audit + Eval + Release/Recover together stay under 200 words. The limitation, disclosure, and Topic 11 handoff fields are separate.

Audit: user, task, bottleneck, fixed rule, human decisionEval: five essential checks and expected outcomesRelease/recover: route, public boundary, checkpoint, trigger, retestKnown limitation and next improvementAssistance disclosure and human-review decisionTopic 11 handoff: purpose, supported capability claim, source trail, disclosure, limitation, career-ready story

Monitoring here: reopen the selected route and repeat the smoke checks. Rollback here: return to a known working file, snapshot, platform checkpoint, or optional Git commit. No analytics or production claim is required. Source trail example: course lab → observed test record → stated limitation. Career story example: scoped, tested, diagnosed, and recovered a bounded release.

Submission check

I used a real public route, reopened local package, course-lab simulation, projected/transcript run, or approved equivalent—and labeled it accurately.I kept expected and actual results separate and did not change the oracle to make a failure pass.I included four gates, one bounded decision, checkpoint/manifest, before/after smoke evidence, recovery, limitation, disclosure, and Topic 11 handoff.I removed secrets, private/access/identity evidence, consent/assent records, restricted material, and unnecessary screenshots.

Complete

Specific, observable evidence supports the route, tests, boundary, and recovery.

Developing

Core work is present, but one evidence chain or explanation is incomplete.

Incomplete

Claims rely on polish, a URL, or access proof without the required observable evidence.

Submission boundary: maximum five pages. Do not attach full source archives, repository/account screens, credentials, private paths, full chats, consent/assent records, identity data, or secret/access evidence.