Week 2 self-check: context and tool contracts
Answer these questions after the studio, then check each answer against the notes and the source you cite. They are formative and add no separate submission. Keep one correction in your work record. The public answer guidance is available after your first attempt; use the notes to explain each answer.
- A proposal says “never write under
reports/.” Name one research artifact, one plan line, one schema field and one negative acceptance case that preserve this constraint. - A plan says only “implement CSV export.” Which phase lost information, and what evidence would you collect before editing?
- Write a Given/When/Then case for a malformed row. What must remain unchanged when it fails, and what command would observe that?
- A tool description says “use a path under out/,” but its schema accepts any string. What can the model attempt, what should the handler enforce, and what error should it return?
- A tool schema rejects an unknown field, while the description asks for three lines of context that the code never checks. Label each rule as schema, handler or description.
- A context summary says “tests passed” but omits the tested revision. What six items belong in a handoff, and which check must be rerun after the next write?
- A valid call returns a refusal. What should the controller send to the model next, and why is a refusal an observation rather than proof that the task is complete?
- Compare one rule from Source 1 or Source 2: what does the text request, what code checks, what runtime checks, and what remains unknown?
R1. A later plan omits the read-only boundary. What one research artifact and one negative case would you add before implementation?
R2. A tool returns “invalid” without naming a field. What schema or error change would make the next model call easier to verify?
Finish with: Decision: accept | shrink | recheck | stop — evidence: ....