Week 1 self-check answer guidance

Try each question before reading this page. These are evidence prompts, not a graded answer key: cite the fixture, the request index or your own captured record.

The minimal loop

Q1. The proposer generates an assistant message containing tool calls. The controller checks the message and executes permitted calls; the tool returns the file text, written, verified or a refusal. A tool result is an observation, not the proposal that caused it.

Q2. written reports that the controller wrote bytes to the permitted path. It does not compare those bytes with the requirement. The fixed bash verification is the observation that checks the required 4\n content.

Q3. The controller answers calls in their listed order and returns one tool message per call. Each message carries the corresponding tool_call_id, including for a refused call, so the next request can match every result to its proposal.

Q4. final means a reply had no calls and the controller stopped normally. step_limit means the request budget ended. Neither stop reason proves that the candidate is correct.

Q5. “Done” after a write does not establish that the required bytes are present. Run the fixed verification on the current file and retain its result before accepting the claim.

Reading a request

Q6. A valid answer names one role or goal instruction, one argument constraint from a tool definition, and one earlier message carried in request 4. Label each with its request or message location. If the capture hides system content, say that it was not visible rather than filling the gap from a published prompt.

Q7. A schema or checked() rejection prevents the malformed call from running; the tool's own code can return a refusal after the call is received. A sentence in the prompt is only a request unless a checker or runtime control enforces it. Cite one example of each from the prompt and fixture.

Q8. Count request blocks because one assistant response can contain several tool calls. The viewer's request index identifies a model request; a call ID identifies one proposed action inside that request.

Q9. course-made-sample identifies the supplied record as a hand-authored teaching example. It does not establish what a real agent sent or what a student's session did.

Your studio record

Q10. An observed claim has a citation containing the event, such as a command, result or visible instruction. An inference explains why it happened or predicts a next action. A follow-up run of the same check, or a newly visible request field, can turn a bounded inference into an observation.

Q11. With no verification result, choose re-check (or narrow if a re-check is impossible). The evidence supports that a proposal or write occurred, not that the required behavior is correct.

Q12. Preserve both sentences: “I predicted ___ before the check” and “After the check on revision , I observed .” This keeps the original prediction available while recording what the new evidence changed.

Decision line

Decision. Accept only the current revision and cases covered by a passing check; otherwise narrow the claim, re-check the current revision or stop. Name the command, result and next check that support the selected decision.

Retrieval 1. A generated call is an assistant proposal with a call ID; a tool effect is the returned result carrying that same ID. Record both sides before explaining what the effect means.

Retrieval 2. A final completion sentence is insufficient without a verification result tied to the latest write; preserve that result and its call or command ID.