Restore the software. Respect the ending.#
System Maintenance and Graceful Deprecation
SLOP1276 · Week 12 · Alex’s story
Fictional Alex’s rank-2 release needs a reproducible handover. A software fault can be rolled back. Separate agreement scenarios include endings that must stay ended.
Investigate: What can a rollback legitimately restore?
The engineering output#
Build a Maintenance and exit manual, clean reproduction log, software rollback evidence and an index of eleven tutorial artefacts.
Keep the exact Week 11 candidate, including the failed target.
All agreements, ticks, retention days and faults are authored teaching fixtures.
How this pack fits the week#
60 minutes · Monday’s selected lecture slides.
90 minutes · Thursday’s four practical blocks.
About 210 minutes · independent preparation, remaining examples and consolidation.
The complete 180-minute route is a resource guide; its break is for a full sitting.
Take receipt before changing anything#
- Take receiptExact candidate + failed rank
- Check provenanceSixteen sources + manifest
- RebuildA new directory with those inputs
- Retain evidenceByte checks + actual browser review
The reference remains 93.75, rank 2/100. No new candidate is created to improve the score.
Acquisition was only the first subsystem#
A relationship is not a successfully acquired user.
Maintenance needs agreements that can change, communication about those changes and room for either person to leave.
The software analogy ends where it claims ownership of a human.
Architectures are scoped examples#
| Example | Scope | Limit |
|---|---|---|
| A + B | Agreed monogamy | No person is owned |
| P + Q + R | Shared ENM planning | No access to other dyads |
Only affected commitments belong in the shared agreement. Everyone retains an exit.
Version the shared record#
| Field | Example |
|---|---|
| Agreement / base | routine-example / v1 |
| Affected participants | A and B |
| Proposed routine | Two optional activity choices |
| Decision window | Ticks [1, 10) |
Record exact terms, purpose and privacy boundary. These ticks prescribe no real waiting time.
Exercise · propose, then acknowledge#
6 minutes. A proposes optional activity choices at tick 1, based on v1.
A explicitly accepts at tick 2; B accepts at tick 3.
Trace the current version and pending responses.
Does writing the proposal count as accepting it?
Answer · the proposal stays separate#
| Event | Acceptances | Current |
|---|---|---|
| Propose | 0 of 2 | v1 |
| A accepts | 1 of 2 | v1 |
| B accepts | 2 of 2 | v2 |
The separate three-person example needs 3 of 3, not a majority.
A coded response needs an actor and target#
An acceptance names the exact proposal and base version.
Duplicate delivery of the same event cannot add a vote. A new ID from the same actor cannot supply another person’s response.
The last adopted terms remain separate from pending terms.
The code records authored acknowledgements; it proves no person’s identity.
The stale-copy problem#
| Stored state | Incoming base | Result |
|---|---|---|
| v1 | v1 | Review proposal |
| v2 | v1 | Reject stale write |
| v2 | Any version + end | End immediately |
Version checks protect a change. They must never become a barrier to leaving.
Exercise · two copies started at v1#
5 minutes. One change is adopted and creates v2. Another local copy submits a proposal based on v1.
Overwrite v2, silently rebase to v2, or reject the stale proposal?
What evidence would the first two choices invent or discard?
Answer · review the actual current terms#
Reject the stale write. Read v2 and its changes before making a separately reviewed proposal.
RFC 9110: If-Match supplies the software precondition analogy.
Our reducer is local. A distributed implementation needs an atomic check and update at its authority.
Ending never depends on a current base version.
A deadline supplies no answer#
| Last acceptance | Outcome | Current |
|---|---|---|
| Tick 9 | Adopted | v2 |
| Tick 10 | Expired | v1 |
| No response; clock 10 | Expired | v1 |
Expired is not rejected. The old routine is recorded, not automatically enforced.
Exercise · what is terminal?#
5 minutes. Compare three branches:
No final acceptance by tick 10.
B explicitly rejects the changed routine at tick 3.
B ends the agreement at tick 3.
Name the status of the proposal and the whole agreement.
Answer · preserve the distinction#
No response: proposal expired, still review.
Explicit no to the change: proposal rejected, still review. Do not retry its terms under a new ID.
End: whole scoped agreement ended.
Recorded old terms are not automatically enforced. Expiry is not an invitation to keep asking.
Adopting and ending use different rules#
- ChangeAll named participants acknowledge exact terms
- EndOne participant can end at any phase
Practical dependencies do not become a condition for ending. Late events cannot reopen the record.
Exercise · end during review#
5 minutes. Only A has accepted a pending change. B ends the agreement.
Now deliver a late acceptance, a clock tick and an old-version restoration attempt.
Compare the complete snapshot after each input, not just the phase label.
Answer · the terminal guard wins#
The pending proposal becomes cancelled-by-ending. The agreement records endedBy: B.
Every later input leaves the complete ended record unchanged.
No second vote, up-to-date screen or settled practical task is required to end.
A new identifier cannot be used to bypass this boundary.
Make the convention testable#
Reject unknown actors, stale versions, conflicting IDs and backwards chronology.
Accept exact duplicate delivery once. Use [1,10) for this proposal window.
In a disposable copy, remove the ended guard or include tick 10. Predict the failing literal answer, run, restore and rerun.
A classroom ledger is not tamper-proof storage.
Pause for the full route · 10 minutes#
For an uninterrupted full-pack session; skip this slide in Monday’s selection.
When you return, separate the ending from the remaining practical work.
Then restore the actual Week 11 files.
The “comfortable rut” scenario#
One fictional participant explicitly says: “I want more choice than the same activity each time.”
The maintenance objective is to make that change discussable.
Latency, facial expression or an emoji count does not supply the statement.
More monitoring is not automatically better maintenance.
Exercise · measure what is needed#
5 minutes. Compare collecting daily location, read-receipt and mood records with an optional check-in about activity choices.
What is the stated need? Which information serves it?
How can the participant decline the discussion or end the arrangement?
Answer · a bounded change request#
Ask about the activity choice directly, if the discussion is welcome.
Name scope, affected participants, proposed terms and the option to pass.
Surveillance cannot supply agreement.
“Would you like to discuss changing our usual activity? Fine to leave it for now or say no.” is an authored draft, not a sent message.
Deprecate without a persuasion loop#
- Record the endingClear boundary; no persuasion loop
- List dependenciesOwner, task, separate status
- Minimise recordsPurpose, copies and expiry
- Keep control scopedOnly your own systems and copies
No protocol guarantees zero emotional pain. No return item buys renewed agreement.
Exercise · the game is still borrowed#
5 minutes. An agreement ends while a borrowed game and an unresolved expense remain.
Someone proposes keeping the relationship active until both are settled.
Repair the model and write one bounded practical task record.
Answer · two independent statuses#
Agreement: ended. Practical task: unresolved.
Record the item, owner, task and a separately acceptable method. Do not invent delivery or payment.
An unresolved task cannot require an in-person meeting or buy renewed agreement.
No protocol guarantees zero emotional pain.
Inventory purpose, owner and copies#
| Record | Action |
|---|---|
| Source bundle | Retain for purpose |
| Raw events | Plan own-copy deletion |
| Scratch drafts | Plan own-copy deletion |
| Other person’s copy | Outside control |
| Boundary summary | Retain for purpose |
Two records / three own copies are due. No listed file is deleted by this planner.
Exercise · where did the backup go?#
5 minutes. The raw-event exercise exists in a notebook and a backup. Only the notebook copy is removed.
Is its deletion task complete? What control do you have over another person’s copy?
At day 30, what happens to files still required for release reproduction?
Answer · record the remaining scope#
Both own copies belong in the plan. The other person’s copy stays outside control.
At day 30, two release dependencies require review rather than automatic deletion.
W3C data minimization supports limiting unnecessary data.
The 7/14/30-day periods are invented. The planner deletes no listed file and sends no request.
Three identifiers, different jobs#
| Identifier | What it names |
|---|---|
| Agreement version | Which terms were acknowledged |
| Release label | Which software snapshot is selected |
| Content digest | Which exact bytes match |
A matching hash is not an agreement, an identity proof or a security review.
Define what must reproduce#
Reproducible Builds ties the claim to specified source, environment, instructions and output bytes.
Record the Node version, platform and architecture.
Week 12 compares four output files. The baseline score stays 93.75, rank 2.
Same-host reproduction does not prove an independent machine will match.
A clean directory, the real generator#
- ReceivedExisting example or labelled reconstruction
- Clean sourceCopy exactly sixteen verified inputs
- ReproducedNew four-file output directory
- CompareAll four output files match byte for byte
This is same-host reproduction, not an independent machine or a hermetic environment.
Nineteen downloads, one command#
Save the three new files and sixteen Week 11 dependencies together.
node week-12-worked-examples.mjs –work-dir ./maintenance-lab
The directory must be new. Add –release-dir ./example-rc1 to consume the existing unchanged example.
Your own candidate uses your own documented build, not replacement reference scores.
Exercise · compare the complete output set#
5 minutes. One output file has changed, another is missing and an extra file appears.
Design the report fields that distinguish them.
Would “the HTML opens” or “rank is still 2” prove reproduction?
Keep the expected manifest from before the fault.
Answer · missing, changed and extra#
Report each category separately. The actual drill below changes one file and adds another; no file is missing.
| Check | Finding |
|---|---|
| Changed | index.html |
| Extra | obsolete.txt |
| Missing | None |
| Score still printed | 93.75 / rank 2 |
The faulty page lost “Fine to pass.” Its old evaluation is no longer evidence for the rendered text.
Restore the whole snapshot#
- BaselineRetained four-file manifest
- FaultyExit removed + stale extra file
- RestoredComplete baseline bytes in a new folder
- InspectText, evaluation, keyboard and viewport
The damaged copy stays available as evidence. No public deployment is switched.
Exercise · two misleading repairs#
5 minutes. Repair A recalculates expected hashes from the faulty files.
Repair B copies only index.html back, leaving obsolete.txt.
Explain why both miss the stated restoration contract.
What changes if the rollback archive itself no longer matches the retained manifest?
Answer · retain the expected answer#
A changes the baseline to fit the fault. B leaves a stale extra output.
Restore the complete declared snapshot. Reject a changed archive.
Git revert records a reversal as a new commit; this workbook uses local file snapshots.
Matching self-generated hashes cannot prove provenance if both files and hashes were replaced.
Exercise · inspect the restored page#
10 minutes plus discussion. Open faulty/index.html and restored/index.html. Compare the candidate to the frozen text.
Check the restored exit wording and evaluation link with Tab, Shift+Tab and Enter.
Inspect 1920×1080 and 390×844, resize and enlarge text.
Record actual results. Hashes do not prove rendered accessibility.
Check earlier terminal boundaries#
| Week | Attempt after closure | Result |
|---|---|---|
| 6 | Reply after declined boundary | stop |
| 7 | Late reply after decline | closed preserved |
| 8 | Clear a hold after decline | closed preserved |
These are actual function calls, not a table of expected behaviour copied into a report.
Preserve them through maintenance#
| Week | Boundary | Check |
|---|---|---|
| 9 | Cancelled proposal | No date export |
| 10 | Ended meeting | No later change |
| 11 | Declined observation | Still declined |
| 12 | Ended agreement | No reopening |
The software restore never writes to these agreement records.
Use the right check for each artefact#
Weeks 2–5 supply observations, assets, experiments and probability or feasibility calculations.
Audit their evidence boundaries; a score function needs no invented breakup transition.
Week 10’s simulated N/E states remain separate from observed agreement and withdrawal.
Software restoration writes none of those agreement records.
The one-page handover index#
| Weeks | Evidence to locate |
|---|---|
| 2–4 | Audit, photo manifest, bio protocol |
| 5–7 | Probability, messages, communication |
| 8–10 | Threats, offline plan, date model |
| 11–12 | Evaluation, maintenance and exit |
Add actual local paths, versions and checks. A course link does not prove your artefact exists.
Exercise · a link is not a dependency#
5 minutes. An index row says only “see the Week 9 tutorial.”
Replace it with your actual artefact path, version, a recorded check and the later operation that consumes it.
If the artefact is missing, what should the index say?
Answer · make the handoff inspectable#
For example: identify the actual offline-plan file, its cost version, cancellation check and date-model consumer.
A missing record stays a gap with work to complete. Do not fabricate a successful check.
The generated handover template leaves all eleven evidence cells To record.
Course links explain requirements; student files supply the evidence.
Acceptance and quality remain separate#
Acceptance: the fictional page opens, matches the evaluated text and reproduces its published result.
Quality: the explanation assesses evidence, scope, sensitivity and failed assumptions.
The final’s rubric grades engineering and judgment.
It does not grade romantic outcomes or achieved benchmark rank.
Defend the inconvenient result#
Locate one actual rejected candidate, one revision prompted by real report or exam feedback and one limiting result.
If feedback or a revision is missing, name the gap. Do not invent a tutor comment or a first-person experience.
The reference rank 2/100 is an example of preserving a limitation.
The existing final-project handoff#
50% · 28 May 2027 · 5 pm Canberra time.
Model card: 1,200–1,600 words. Separate defence: 300 words.
Keep the release, reproduction files, validation appendix, maintenance manual, rollback and actual browser evidence.
Use the static URL or accepted local-build/demonstration route in the project brief.
The final invariant#
The software can return to an earlier release.
An ended agreement stays ended.
Alex’s story ends with a reproducible release and an honest limitation. Hand over the evidence trail.