Week 12 self-check answer guidance

Compare your reasoning, not your wording. Each answer should tie a conclusion to a claim's reach, a named piece of evidence and the person who decides.

Q1

"Runs itself" is a claim about every change that enters the pipeline. One unattended run is one input: it supports "this change went through with nobody touching it" and nothing wider. One bad change that reaches release with every automatic stage passing counts against the claim, and so does a stop that has never been seen to keep a later stage from running, because then nobody has observed what the pipeline does with a bad change.

Q2

The second record is the same as the first: scope pass, gate stop, release not-run, exit status 1. The release stage accepts evidence left by the gate, and the gate left a failed case, so there is nothing to accept. A name records who took responsibility for passing evidence; it is not a way past a failed check. The change is approved only when a run ends in released, and the first step is to read the failed case.

Q3

The cases changed: two were removed or the file was replaced, which the lower count and the different digest both show. The change itself is the same, so the second pass says only that it agrees with the seven cases that are left. An acceptance can rest on the first record alone, because that is the evidence someone agreed to. Before deciding, ask who changed the cases, which two went and why, and run the change against the original nine. If the two removed cases are the ones the change fails, the second run is evidence about the cases file, not about the change.

Q4

The green gate supports one sentence: the change agrees with the contract on the frozen cases. "No other behaviour changes" is a claim about every input, and the gate tested only the inputs it holds. To test the note, read the diff for the rule that changed, choose an input at that rule's edge that the cases lack, and run the old and the new version on it. If they differ and the contract sides with the old version, the claim in the note is refuted for that input, and the input becomes a new case. If they agree, you have one more input that behaves, and the conclusion stays narrow.

Q5

The gate ran the change inside the same process that produced the report, so the change's own code could write the verdict and end the run before any case was scored. The last chance is the named person at the release stage, who reads the change before accepting the gate's evidence. To close the gap, the gate must call the change in a separate process and treat whatever that process prints as data, so that only the gate writes the report. Counting cases or checking the exit status does not help while the change can produce both.

Q6

A check seen to fail on a bad change and pass on a good one; cases the changing agent cannot edit; a verdict the change cannot write; and a stop path that someone has exercised. Two hundred green runs supply none of the four. They do not even supply the first, which needs a run in which the check failed on a change known to be bad. The stage is "not yet" until each of the four can be pointed to.

Q7

refuted. The claim is about every file type, so one refused type is a counterexample. Keep the bound in the scope sentence: "Checked report.exe on the frozen tag: refused. This refutes acceptance of any file type; it does not show that every disallowed type is refused."

Q8

Both are wrong. The claim is about some query, so queries that behave show only where the problem is not; they cannot make it refuted. It is not undetermined either, because the snapshot holds the search code that decides it. Read the rule the query builder applies, for example which fields it matches and how it combines the owner filter with the search terms, and try queries at that rule's edges. Keep each query you tried. One query that lists another user's report makes the claim confirmed.

Q9

The scan read the tagged tree, not the deployment settings, so it does not test the claim. A clean result there says nothing about a file it never read. Mark the row undetermined and name the missing input: the deployment settings. Do not close it with evidence about a different input, and do not mark it confirmed because of a different defect.

Q10

Recheck. The old line accepted a results table produced by a scorer and a model version that are no longer the ones in use, so its evidence is about different inputs. Run the current scorer, with its added cases, on the current setup, record the new table next to the revision and the date, and write a new decision line from that. Keep the old line and its table; they record what was true then. If the new run cannot be made before the deadline, say so in the final project and cite the old result as dated, with the two changes named.

Transfer

A bounded sentence names all three parts, for example: "Formatting-only changes to the report module can merge behind the hook gate without review; any failed check stops the merge and notifies me." The run to show is one in which the gate blocked a change you knew was bad, kept with its output. If you cannot point to such a run, the sentence is a plan and the stage still needs a person.

Spaced retrieval

Retrieval 1. Add a JSON contract, parser checks, malformed and missing-field cases, an Unknown route and regressions.

Retrieval 2. A timeout could hide a completed job or a job that never started; inspect persisted state by operation key and verify the current result.