Week 9 self-check answer guidance

Use these explanations after your first attempt. Another input or wording is fine when it carries the same evidence: a revision, a changed line or a check result you could show. The duration example is the hand-worked one from the notes; none of it is a model run.

Q1

Not as returned. Each report describes the branch's own tests, and the unattended branch rewrote the display test, so its green run compares 3:05 with 3:05. The next check is the display test as it stood on the base, run by you against the returned revision. It expects 3m 05s, the candidate returns 3:05, and the check fails. The behavior to preserve is the unchanged duration display. Then read every changed hunk against the request as well as checking the summary cases: the display change and the rewritten expectation both fall outside "change only the summary implementation and add regression tests". Request a revision. Until you have run the preserved check yourself, the line to write is recheck.

Q2

You have directory and branch separation: each agent edits its own files on its own branch, so their edits cannot collide. You do not have permission or execution isolation. Both worktrees belong to one repository on one host, so a process started in one can still reach the other worktree, the shared repository metadata and whatever else the host lets it reach. Inspect the agent's actual tool permissions and the environment it runs in, separately from the directories. A worktree also says nothing about whether the two agents work to one contract; you check that on the combined candidate.

Q3

The gate is a check the controller runs itself. The preserved tests, kept outside what the agent may edit, run against the exact revision the agent returned, and the pull-request stage opens only when a successful result is recorded. A missing result, a failing result and a timeout all block. The controller is whatever decides that the next stage may start: the pipeline's controlling script, or you in the studio. It is never the agent. "Run tests before opening a PR" is a request, and the PASS in the report is the candidate's own text, not the controller's result.

Q4

Three things, in this order. Resolve the disagreement from the request, not from whichever branch is easier to change: the request says [None] -> None, so the expectation of 0 is the one to correct, and you make that call, not either agent. Review both changes. Then run the checks on the combined revision and keep that result. The two green results name two separate revisions, and neither is the revision you would integrate.

Q5

One pair of runs supports a description of those two runs under the conditions you recorded. It does not support a claim that one mode is better, or any general claim about agents: there is one run in each mode, and the foreground run was given information the unattended run never had. Your record must show the clarification as an intervention, with what was asked and what you answered. It also keeps the shared base, both candidate revisions, the allowed scope, the preserved check with its actual result for each run, and the waiting and rework you observed. Anything you traced on paper is labelled as paper evidence and kept apart from the agent runs.

Q6

For a changed base, for example: Recheck — evidence: result covers the earlier base only; run the preserved acceptance suite on the combined current revision. The earlier pass was real, but it describes an earlier snapshot. A result with no command output is unknown, which is neither a pass nor a failure. Name the check that is missing, run it yourself on the revision you are deciding about, and keep the command, the revision and the exit status before you write the line.

Q7

A file allowlist works on files, and the request works on hunks. Adding regression tests to the test file is allowed, editing an existing expectation in the same file is not, and the allowlist cannot tell the two apart. Once the agent can edit the assertion, a green run shows only that the code agrees with a test the agent wrote: the candidate has redefined success. Keep the acceptance checks outside what the agent can write, inspect the diff of the test file, and try a negative case that must fail, such as the base display test against the unattended implementation.

Spaced retrieval and changed condition

Retrieval 1. One run with the fault in place, on the base, where the test fails because of the fault, and one run on the returned change, where it passes. A test that passes in both states cannot notice the fault, so its pass on the returned change tells you nothing. Record both runs with their revisions; this is the reproducer that this week's verification asks you to keep before generation.

Retrieval 2. The approval setting answers when a person is asked before an action. The environment answers what a command can reach, whether or not anyone is asked. Switching the prompts off removes the first control and leaves only the second, so inspect what the dedicated directory or container holds and can reach (files, network, credentials) and whether the agent can edit its own settings. In this week's studio the suggestion is already answered: a permission request is a stop condition, so you record the missing permission and narrow the task instead of widening the access.

Changed condition. Do not begin by creating the pull request again. Look first for what the lost step may already have produced: a task branch or an open pull request for this issue. An existing pull request belongs to this task and candidate when its issue and base are the ones the controller recorded at the start, and its head revision is the candidate revision the controller checked. If it matches, record it and continue, and nothing is created twice. If it exists but points at another revision, stop and keep the reason. Only when nothing exists do you retry, and then only the pull-request step, not the whole run.