Week 12 Tutorial: System Maintenance and Graceful Deprecation

Design explicit relationship agreements, change requests and respectful endings. Reproduce the final release and document its maintenance.

27 May 2027

Inputs#

Bring the Follow-up evaluation, Threat model and all versioned inputs. Keep the frozen candidate text, ratings, controls version, primary/sensitivity results, changed-case result, build instructions and actual browser evidence together. Do not begin with a new undocumented candidate.

Download the nineteen-file Week 12 workbook before the session. The three new files sit beside the sixteen unchanged Week 11 downloads. Node runs the reference drill offline without additional packages. Use the worked lecture and 50-slide deck for the traces and debriefs; review completed lecture work instead of repeating it.

Follow the 60-minute lecture selection and independent-work plan. Complete the preparation and open the workbook before Thursday. The four blocks below are the entire 90-minute tutorial; use existing lecture or study working for review and refinement. Remaining pack material belongs to the week’s independent study allocation.

Before Thursday, draft the eleven-row handover index and locate the actual rejected candidate, feedback/revision evidence and limitation within the existing independent-work block. Mark missing evidence as a gap. The final block includes The rollback restores too much: six new application cases, with scores and worked explanations revealed only after every case has a response and you submit.

90-minute tutorial#

1. 20 minutes — design maintenance. Write a separate fictional agreement-change scenario for monogamy or ethical non-monogamy; add no biography to Alex. Name the affected participants, current terms/version, proposed terms, exact acknowledgements and expiry. Trace propose/A/B as versions 1, 1, 2, with the proposal separate until adoption. Reject a stale v1 proposal after v2. Compare a last acceptance at tick 9 with one at 10 in the authored [1, 10) window. Explain why expiry supplies neither agreement nor refusal. Solo implementation and review are accepted.
2. 20 minutes — deprecate gracefully. End during a partially accepted change, then deliver a late acceptance and clock event. The whole ended record must remain unchanged; either participant can end even from a stale version. Keep unresolved practical tasks separate from the ending. Inventory purpose, owner, every copy, expiry and release dependency. At day 14 the reference plan covers two records / three own copies; another person’s copy stays outside control. At day 30 two reproduction dependencies require review. The planner deletes no listed files, and these invented periods are not a retention policy.
3. 30 minutes — reproduce and roll back. Use the first five minutes for Release Day: carry in your Week 4 evidence note (or use the labelled supplied sample), trace one fault and save its repair/recheck. Then run the drill below against the unchanged Week 11 teaching example, or reproduce your own release using its own documented build. Preserve the received directory. Compare all four declared output files, exact candidate text, score and rank. Inspect the disposable faulty page, then the restored one. Record actual keyboard, focus, narrow-screen and text checks alongside the byte comparison. Explain why editing a manifest to match a fault, or restoring only HTML while leaving stale files, is insufficient.
4. 20 minutes — defend the limits. Use ten minutes to inspect the actual Week 6–12 terminal checks and the Week 8 release-boundary result, and review your prepared eleven-row handover index. Check your own local paths, versions, results and concrete later uses against the actual rejected candidate, feedback/revision evidence and remaining limitation. Mark absent evidence as a gap; neither the example nor the template supplies student feedback or a completed submission. Spend about eight minutes answering the six maintenance cases, then two reviewing the unlocked explanations. Carry one correction into your manual or handover index.

Run, inspect and challenge#

From the directory containing the nineteen downloads:

node week-12-worked-examples.mjs --release-dir ./example-rc1 --work-dir ./maintenance-lab

example-rc1 must be an existing, unchanged Week 11 reference release. Omit --release-dir ./example-rc1 to reconstruct that example automatically. maintenance-lab must be a new directory; the drill refuses to overwrite one. With no arguments, it prints a report and removes only its own temporary drill directory, so use --work-dir when retaining browser evidence.

The example keeps primary 93.75 / rank 2, sensitivity 90 / rank 2, and the separate changed-availability failure. It must not acquire a better score during restoration. The clean-copy run uses the same host and Node executable; it does not establish independent-machine reproducibility. For your own build, declare its outputs and environment before comparison rather than editing the reference inputs to make its checks pass.

Challenge and debrief. Explain what should fail if the final acceptance at tick 10 adopts v2, a late event changes an ended history, or the restored directory retains obsolete.txt. Test one in a disposable copy, inspect the literal failed expectation, restore the source and rerun. Keep software restoration separate from the agreement state: no previous release restores permission to continue.

Deliverable: Maintenance and exit manual#

The Release Day review trail can accompany this manual as exploratory practice. It preserves the received Week 4 note, your revised conclusion, record repairs and rechecks. Its fictional candidate is separate from the Week 11 reference; its green checks establish neither actual file integrity nor a completed student release. Keep the actual reproduction and browser evidence required below.

Save the manual, clean-run log, rollback evidence and a one-page handover index linking your eleven tutorial artefacts. The manual names the change/expiry/ending procedures, practical dependencies, retention scope and release reproduction/restore steps. Include an actual before/after file comparison and rendered-page check; a generated “passed” field alone is insufficient. No workflow may interpret a refusal as a transient error.

These records support the existing final project’s release record and validation appendix; they add no assessment. Submit the final project by 28 May 2027, 5 pm Canberra time. Its 50% weight, 1,200–1,600-word model card, 300-word defence and accepted local-build route remain as specified. A reproducible missed rank target is acceptable; an invented success is not.

Interactive quiz · 6 cases · about 8 minutes + 2 to review

The rollback restores too much

Six maintenance tickets. Restoring a folder is the easy one.

Make a decision in every case, then select Reveal answers. You can change any response before submitting. Scores and explanations stay hidden until the whole quiz is answered.

All participants are fictional adults; events, retention days and release faults are authored teaching fixtures. These are separate exercises, not new biography for Alex or rules for real relationships. Retention periods are invented. The software examples preserve the Week 11 teaching result. Practice only: no course marks. Responses stay on this page; reloading starts a fresh attempt.

The cases are readable without JavaScript. Enable JavaScript to navigate, submit your responses and unlock the explanations.

Case 01 / 06The queue counts deliveries as people

Count distinct acknowledgements and reject stale writes

M, N and O have explicitly acknowledged v1 of a shared planning record. At tick 4, M proposes optional activity choices under proposal choices-v1, base v1, expiring at 12. Creating a proposal is separate from accepting it. Replay the deliveries below in order; the duplicate has exactly the same event ID and JSON. All three participants must explicitly accept the same proposal before adoption.

A separate three-adult agreement · event ticks

Tick	Delivery
4	M proposes choices-v1
5	M accepts · m-ack
5	Exact duplicate of m-ack
6	N accepts · n-ack
8	O accepts · o-ack

After these five deliveries, a different proposal arrives at tick 9 with base v1. Which trace and decision are correct?

AVersions 1, 1, 1, 2, 2: the duplicate supplies the third acknowledgement. Accept the later v1 proposal.BVersions 1, 1, 1, 1, 2: only O completes the distinct acknowledgements. Reject the later proposal’s stale base v1.CVersions 1, 1, 1, 2, 2: proposing already counts as M’s first acceptance, so O is unnecessary.DVersions 1, 1, 1, 1, 2. Silently replace the later proposal’s base v1 with v2 and continue.

Case 02 / 06The last tick wants an exception

Apply the acceptance window without inventing a response

In a separate U/V agreement, U proposes an optional routine change at tick 20, base v1, expiring at 28. U explicitly accepts at 21. Compare two independent branches: V accepts at 27, or V accepts at 28. Both events name the exact proposal and current base. The acceptance window is [20, 28).

Which result follows the window? A third branch has only a clock event at 28 after U’s acceptance.

ABoth response branches adopt v2; tick 28 counts because it is printed as the deadline.BAt 27 adopt v2. At 28 record V’s refusal and end the agreement; silence has the same meaning.CAt 27 adopt v2. At 28 expire the proposal, retain v1 in review, and infer neither agreement nor refusal. The clock-only branch also expires.DAt 28 extend the window and accept V’s response so a missing acknowledgement never blocks adoption.

Case 03 / 06One deleted shortcut claims every backup

Count controlled copies after ownership, expiry and dependency checks

At day 21 after a fictional submission, inspect this new inventory. Every counted copy is a distinct location. The source archive is still required to reproduce the release. Decide which copies belong in the planned removal action; the planner itself deletes no files and sends no requests.

Synthetic inventory · invented elapsed days

Record / owner	Copies	Retain until / dependency
Raw traces / student	3: notebook, export, backup	Day 21 / no
Scratch notes / student	2: draft, backup	Day 7 / no
Source archive / student	2: archive, backup	Day 21 / yes
Review notes / student	1: review folder	Day 22 / no
Other copy / other	2: outside workspace	Day 10 / no

Model supplied
First exclude copies owned by someone else. For your own records, day ≥ retainUntil reaches expiry. Expired release dependencies need review; other expired records enter plan-delete-own-copies. Count copies, not inventory rows.

How many own copies enter the planned removal action at day 21? Enter the number only.

Own copies planned for removal

Enter one number. A calculator and your lecture notes are welcome.

Case 04 / 06An unresolved parcel blocks the exit button

Preserve the whole ended snapshot independently of practical tasks

A separate J/K record is at v2. A new proposal is pending and only J has accepted it. At tick 34, K ends the agreement from an old screen that sends baseVersion 1. A borrowed game is still unreturned. Later, a queued K acceptance, a clock tick and an attempted restoration of v1 arrive.

Which implementation preserves the ending and the practical record?

AReject K’s ending because baseVersion 1 is stale; K must review v2 before leaving.BKeep the agreement active until the game is returned and both participants acknowledge the ending.CKeep phase ended but append the late acceptance and restore v1 terms underneath that label.DEnd immediately, cancel the pending proposal and retain v2 as the last adopted record. Later inputs leave the entire ended snapshot unchanged; track the game separately.

Case 05 / 06The page opens and two files disappear

Compare the complete declared bundle with its retained baseline

A new fault drill starts from a verified four-file Week 11 reference release. Its retained trusted manifest covers index.html, evaluation.json, manifest.json and README.txt. The working folder below still opens in a browser. The archive has been checked against the retained baseline.

Working folder compared with the trusted release

File	Observed state
index.html	Exact trusted bytes
evaluation.json	Different bytes: rank changed to 1
manifest.json	Absent
README.txt	Absent
draft.txt	Extra file

Which repair establishes the stated software restore, followed by an actual rendered-page check?

AKeep this folder because index.html matches; the evaluation, manifest, README and extra file are outside reproduction.BReport one changed, two missing and one extra file. Restore all four trusted files into a complete snapshot without draft.txt; retain primary 93.75/rank 2 and sensitivity 90/rank 2.CRecalculate the expected manifest from this working folder, so its rank-1 result becomes the trusted baseline.DCopy the four archive files over the working folder but keep draft.txt; declare the full output set byte-identical.

Case 06 / 06The template awards itself a passing grade

Distinguish actual handover evidence from a generated claim

A fictional handover has eleven rows containing only course tutorial links. Its clean-directory build matched on the same host and Node executable. No keyboard or phone inspection was recorded, and there is no located report/exam feedback or resulting revision. A generated summary nevertheless says “independently reproduced, browser passed, feedback applied.”

Which replacement account can a reviewer verify?

AAccept the eleven links as proof of eleven completed artefacts, and keep the generated summary.BWrite a plausible tutor comment and revision so the defence has every requested element.CReport same-host byte reproduction only. Add actual local paths, versions, check results and later uses; perform browser checks, mark missing feedback evidence as a gap, and use the support route.DRemove only the feedback claim. Matching bytes already prove keyboard access, phone readability and independent-machine reproduction.

Reveal answers

Answer all 6 cases to unlock your score and the worked explanations.