Week 12 second session: defense walkthrough and studio

The second session has two parts: a walkthrough of the defense format you meet in week 13, then a studio on your own final project. Bring your project repository at the revision you intend to hand in. Keep the work in a dedicated directory, as Tools and model access describes.

Contribution 4 is due this week. The final project is due this week.

Session sequence

Minutes	Activity	What you keep
0–15	Defense walkthrough: the format, from the syllabus	your own questions about the format, asked now
15–35	Rehearse the three verbs on the practice repository	a prediction, the output that checked it, a decision line
35–65	The same rehearsal on your own project, with a partner	the frozen tag, your three statements, what the check showed
65–80	Final project: run your README from the tagged files only	the output of the fresh-copy run
80–90	Decision line for the final project; confirm what is due	one line with its evidence

A written exchange can replace the spoken parts, and every step works from a keyboard with plain text. Planned minutes organise the room; going over them costs nothing.

Defense walkthrough

This is what the syllabus and the project page publish about the defense:

It takes place in week 13, after the expo.
Each student has fifteen minutes, without devices.
The examiner changes one thing or plants one fault in your own code. You locate it, explain it and decide what to do.
It is individual. In a two-person project each member has a separate defense and is marked separately; shared milestone marks do not replace your own explanation.
Defenses use a shared rubric and comparable answering time, and you may ask for equivalent time or an equivalent way of taking part (privacy, fairness and accessibility). The resit rule is in the assessment section.

Nobody in this room knows which change the examiner will choose, and nothing below predicts it. The rehearsal practises the three verbs on changes you and a partner make up:

Locate: point to the line or the decision that differs from the revision you froze.
Explain: name an input that separates the old behaviour from the new, and say what each version does with it.
Decide: choose accept, narrow, recheck or stop, and say what evidence you would need to see first.

Without devices you cannot run anything, so every statement in the defense is a prediction from reading. The rehearsal lets you make those predictions with the screen closed and then check them with it open.

Rehearse on the practice repository

Use this small repository to learn the moves before you touch your project. From the course checkout, build it from the factory example of the notes:

mkdir week12-defense-practice
cp lectures/week-12/factory/evaluator.py lectures/week-12/factory/verify.py week12-defense-practice/
cd week12-defense-practice
git init -q
git config user.name "Week 12 practice"
git config user.email "week12@example.edu"
git add evaluator.py verify.py
git commit -q -m "Practice revision"

1. Freeze. Confirm the tree is clean, tag the revision and list what the tag holds:

git status --porcelain
git tag -a defense-practice -m "Revision I will defend"
git ls-tree -r --name-only defense-practice

evaluator.py
verify.py

git status --porcelain prints nothing on a clean tree. Run the gate once on the frozen revision, so you know what it says before anything changes. The -B keeps Python from leaving a bytecode cache in the repository, so the tree stays clean and every run reads the file as it is now:

python -B verify.py; echo "exit: $?"

{"cases": 9, "failed": []}
exit: 0

2. Plant. A partner changes one thing and does not say what. Working alone, plant this change yourself and practise on the prediction in step 3:

python - <<'__PLANT__'
from pathlib import Path

path = Path("evaluator.py")
old = 'expected = "yes" if status == "failed" else "no"'
new = 'expected = "no" if status == "passed" else "yes"'
source = path.read_text(encoding="utf-8")
assert source.count(old) == 1
path.write_text(source.replace(old, new), encoding="utf-8")
__PLANT__

3. Predict, screen closed. Read evaluator.py on paper or on your partner's screen and write three statements: where the change is; one input on which the frozen and the changed function differ, and what each returns; which of the nine cases in verify.py will fail. Do not run anything yet.

4. Check, screen open. Compare your three statements with the repository:

git diff defense-practice -- evaluator.py
python -B verify.py; echo "exit: $?"

diff --git a/evaluator.py b/evaluator.py
index f59231c..5b851d5 100644
--- a/evaluator.py
+++ b/evaluator.py
@@ -11,5 +11,5 @@ def score(status: str, output: object) -> str:
     """Classify one answer as pass, fail or unknown."""
     if not isinstance(output, str):
         return "unknown"
-    expected = "yes" if status == "failed" else "no"
+    expected = "no" if status == "passed" else "yes"
     return "pass" if output == expected else "fail"
{"cases": 9, "failed": [{"case": "correct_no_running", "observed": "fail", "required": "pass"}]}
exit: 1

The diff is the answer to "locate". The failed case is one answer to "explain": for the status running, the contract's answer is no, and the changed function now expects yes. If your prediction named a different case, find out why before you move on.

5. Decide and restore. Write the decision line, then put the frozen file back and confirm the tree is clean:

git checkout defense-practice -- evaluator.py
git status --porcelain
python -B verify.py; echo "exit: $?"

{"cases": 9, "failed": []}
exit: 0

Decision: stop — the change breaks the contract for every status other than failed and passed; evidence: the diff and the failed case correct_no_running

A planted change will not always trip a check. If your gate stays green after the plant, as it did for the second proposal in the lecture, the diff and a separating input you choose yourself are the only evidence, and the honest decision is usually narrow or recheck.

Delete week12-defense-practice when you finish.

Rehearse on your own project

Work in pairs; swap roles after one round. In your project repository:

Freeze the revision you intend to hand in, with the commands of Freeze the revision you hand in. Run your own gate once, the command your README names, and keep its output.
Your partner changes one thing in your working tree: one line of code, one configuration value or one test expectation. They do not say what, and they do not commit it.
Screen closed, read the code your partner points you to. Say or write the three statements: where, which input separates the two behaviours, and your decision with the evidence you would want.
Screen open, check each statement. Replace final-week-12 with your tag if you named it differently:

sh git diff --stat final-week-12 git diff final-week-12

Then run your gate again. If it stays green, write the separating input as a new test or case before you decide anything. 5. Restore the frozen files and confirm that nothing else changed:

sh git checkout final-week-12 -- . git status --porcelain

If your partner added a new file, git status --porcelain lists it with ??; delete that file by name.

Your partner's change is practice between two students. It is not an examiner's question and does not show what the defense will ask.

Final project: run it from the tagged files only

A project that runs on your machine may depend on a file you never committed. Check the tag in a fresh copy beside your repository, then remove the copy:

git worktree add -q --detach ../final-week-12-check final-week-12

Change into ../final-week-12-check and run the setup, run and verification commands exactly as your README gives them. Keep the output. Then, back in your project repository:

git worktree remove ../final-week-12-check

If Git refuses because the copy "contains modified or untracked files", your README's commands left files behind. Look at what they are, delete them and run the command again, or add --force once you are sure nothing in the copy is worth keeping.

If a command fails in the fresh copy and works in your working tree, something the project needs is missing from the tag. Commit it, tag the new commit under a new name such as final-week-12b, run the check again on that tag and hand in the new name. Do this before you push a tag, so that a pushed tag never has to move. The project page lists what the final revision must contain.

Decision line

End the session with one line in your project notes:

Decision: accept | narrow | recheck | stop — evidence: the tag, the fresh-copy run and the gate output

Choose the word your evidence supports. A fresh-copy run that passes supports accepting "the tagged revision runs as the README says"; it does not support claims the README's commands never exercise.