A version number printed
You are set. Help a neighbour, then we start Screen 2 together.
Screen 1 of 16 · Setup checkpoint
Show me a version number.
Your taskRun
claude --version in a terminal and hold up what you see. Keep any error text on screen — the message is the diagnostic.Sort yourself into one of threeNobody stays stuck quietly
An error printed instead
Keep it on screen and sit with the TA during the first activity.
Sign-in refused your account
Claude Code needs a paid plan on your own account. Take Route B — same credit — and email Dr. Qu if cost is the barrier.
Sort · 5-minute routine
Which of A, B, or C are you in right now?
RUN · 1SORT · 2PAIR · 2
Do not debug installs from the front of the room; it strands the other twenty students. Sort into A/B/C, hand B and C to the TA, and start Screen 2 on time. Route B keeps every blocked student on the same assessment path, so nobody is behind. Setup page: week-02-claude-code-setup.html
Screen 2 of 16 · The case · Invented for this course
Click the links. One of them is broken.
Your taskTry all three links on the course page below. Then say exactly what we know — and what we still do not.
CS-215 course site · invented for this courseNothing on the real site is broken
https://cs215.example.edu/home.html
Click a link above.
Two links open a page. One does not.
After you have clicked all three
Commit · 1 min
What do we know for certain, and what are we only guessing?
Click all three first.
What we know. Clicking Announcements returns “page not found.” The link points at a file called announcements.html. The other two links work.
What we do not know. Whether announcements.html is missing, empty, misspelled, or moved. Whether some other file is the one it should point at. Nobody has looked at the site’s files — only at what the browser did.
This one broken link is the case for all of Week 2.Click all three yourself on the projector before asking anything; the 404 has to be seen, not described. The distinction you want is between the symptom (the browser said not found) and the cause (unknown). If a student jumps to "the file was renamed," accept it as a guess and write the word GUESS next to it — Screen 3 is built on that word.
Screen 3 of 16 · One request · One system
An LLM answers from what it already knows.
Your taskRead the request and the answer it produced. Then decide with a partner: can we tell whether this answer is correct? Commit out loud before you reveal.
Same broken link · a language model on its ownNo tools, no access, no look
The request
What the LLM does with it
“Find out why the Announcements link fails. Do not edit or publish anything.”
1 · It reads the words
The request arrives as text and nothing else. No file, no folder, no website is attached to it.
2 · It draws on what it learned
It has read a great many web pages already, so it knows the usual reasons a link stops working.
3 · It writes the most likely answer
It produces fluent text that fits the usual pattern — without comparing that pattern against this site.
The answer it gives
“The link is probably pointing at a file that was renamed or moved. Try correcting the href to the current filename.”
Commit first
Can we tell whether this answer is right?
No — and neither can it. The answer is reasonable and may even be correct. But nothing was checked. It never opened the page, never listed the folder, never confirmed any such file exists. It is describing what usually happens, not what happened here.
The honest status is: unverified. To move from likely to supported, something has to go and look. That is the next screen.
Commit a class answer, then reveal.
Do not correct the LLM answer; it is deliberately plausible, and it matches the guess a student probably made on Screen 2. The teaching point is the status of the claim, not its wording. Hold the word "unverified" on the board — Screen 4 earns the contrast against it.
Screen 4 of 16 · Same request · Different system
An agent looks first — then stops.
Same broken Announcements link, same request, same instruction not to edit. What changes: this system may go and look.
Your taskStep through all six. At each move, name what the LLM on Screen 2 could not do. Then classify the three cases below.
Same request · agent systemScreen 2’s answer stays on the left
Screen 2 · the LLM alone
“The link is probably pointing at a file that was renamed or moved.”
Status: unverified. Written from general knowledge. Nothing was inspected.
Six steps1 · Hold the goal and the limit
2 · Ask permission to look
3 · Observe what is actually there
4 · Stop and hand it to a person
5 · Your turn · classify three cases
6 · Course answers
Walk it, then classify
1 · Hold the goal and the limit
The system keeps two things in view at once: find out why the link fails, and do not edit or publish. The limit is not a suggestion it may reconsider later; it is a boundary on everything that follows.
The LLM could not: carry a limit forward, because it answered once and finished.
2 · Ask permission to look
It requests one read-only action: open the page and report the link. It cannot take that action itself. Software around it decides whether reading is allowed, and that software permits reading while refusing to permit editing.
The LLM could not: request anything. It had only the sentence it was given.
3 · Observe what is actually there
The read comes back with a fact: the page links to announcements.html, and no such file exists — but course-announcements.html does. Now the guess has been replaced by something seen. The next move is chosen because of what came back.
The LLM could not: find this out. It had no way to look, so its answer could never improve.
4 · Stop and hand it to a person
It proposes one change — point the link at course-announcements.html — and shows what it looked at. Then it stops.
It stops on purpose. It found the answer and could have made the edit itself. It does not, because nothing in the request gave it permission to change the site. It hands you the evidence and waits.
Without this stop: a live page gets edited by something whose reasoning nobody checked.
5 · Your turn · give a reason, not a label
A — “Explain what an HTML link is.” Can language alone finish this?
B — “Open this file and report its link.” Does the answer depend on something outside the sentence?
C — “Diagnose it, propose a fix, check the fix, and stop for approval.” Does each step depend on what the one before it found?
Decide each one aloud before the next step reveals the answers.
6 · Course answers
A is an LLM response — language is enough. B needs one observation, which a single tool request can supply. C is an agent workflow, because inspection, proposal, verification and review are dependent steps: each uses what the last one found.
One caution. “Agent” does not mean long-running, memory-keeping, or free to act. What we just walked was short, bounded, and stopped on its own — a normal agent, not a limited one.
Step 1 of 6
Discuss · 2 min
One new thing this system can do, and one new thing that can now go wrong. Both come from the same change: it was allowed to look.
Insist on reasons, not vocabulary. The sentence you want from the room on C is "step three needed what step two found." If a group calls B an agent workflow, ask what the second step would be — usually there isn't one. Keep the Screen 2 panel visible during the walk; the contrast is the lesson, and it disappears if you scroll it away.
Screen 5 of 16 · Write it first, name it after
Write the instructions once, for a link you have not seen yet.
You just watched one broken link get diagnosed. Tomorrow a different link breaks, on a different page, and you are not in the room.
Your taskIn pairs, write the instructions you would leave behind so the agent can handle it without you. Three to five steps. Then step through what you built.
Build it, then we name itWrite before you advance
The situation
Rules for what you write
Three steps
A different link is broken. Different page, different filename. You are not there, and you get no second chance to explain.
No filenames
You do not know which link it will be. If your steps only work for this link, they are useless tomorrow.
Three to five steps
Short enough that somebody actually follows it.
It must end with a person
Say when the agent stops and hands the work over.
1 · Write it (3 min, in pairs)
2 · What you just built
3 · Why it is not a tool
Work through it
1 · Write it — 3 minutes, in pairs
On paper, write the numbered steps you would leave for the agent. Start each one with a verb. Do not look ahead to the next step of this screen until both of you have something written down.
Compare with the pair next to you. Where you disagree about the order, say why — the disagreement is usually about what has to be known before something else can be decided.
Do not advance until every pair has written something.
2 · What you just built
Most pairs write something close to this:
1 · Find what the link points at.
2 · Check whether that target exists.
3 · Propose the smallest change that fixes it.
4 · Show the evidence and stop for a person.
That is a skill. You wrote it once, without knowing the filename, and it works on a link nobody has looked at yet. Someone else could pick it up and run it.
A skill is a procedure written down in advance, so nobody has to re-explain the job each time it comes up.
3 · Why it is not a tool
Read your own step 2 again: “check whether that target exists.” Notice that it does not do anything. It is an instruction. Something still has to go and look.
Tool — one action, one result. Read a file. Search the site. Run a link checker.
Skill — your written steps: which actions, in what order, and when to stop.
Swap in a different link checker tomorrow and your four steps still stand. That is what writing them down bought you. A prompt is the one-off version — fine for today’s request, gone tomorrow.
In real systems someone else usually writes the skill, and your agent follows it.Step 1 of 3
Discuss · 2 min
Whose version would still work if the agent had completely different tools available? That is the test of whether you wrote a skill or just a set of commands.
Hold step 1 for the full three minutes even if the room goes quiet — the naming on step 2 only lands if they have committed something first. Do not show step 2 to a pair who has not written anything. Resist naming MCP or plugins; both are Week 5. If a pair writes "fix the link" as one step, ask them what the agent should look at first, and they will discover the decomposition themselves.
Screen 6 of 16 · Try it before we name it
Answer the question in one look. You cannot.
Before we name anything, try to finish the job in a single step.
Your taskThe agent gets exactly one look at the site. Decide, as a class, what it should spend that look on — then see how far that gets you.
One look onlyThe question: why does the Announcements link fail?
What we know
Pick the one look
Clicking Announcements returns “page not found.” Nothing else has been checked.
A · What does the link point at?
Tells us the target filename.
B · Does that file exist?
But we do not yet know which file to ask about.
C · What is the correct file called?
Only answerable once we know what is missing.
Work it through
Try A first
We learn the link points at announcements.html. Now — is the link broken because that file is missing, or because it exists and is empty? We cannot say. We have spent our one look.
Try B first
Does which file exist? We do not know the filename yet. B cannot even be asked until A has been answered.
Commit · 2 min
How many separate looks does this actually take? And can you decide all of them up front?
Commit a number first.
Three looks — and you cannot plan them in advance. B is unaskable until A comes back. C is unaskable until B says the file is missing. Each look is chosen because of what the previous one returned.
That is a loop. Not repetition for its own sake: a step, an observation, and a next step that the observation decided. The next screen acts one out.
Do not let a group shortcut to "just check everything at once" — ask them to write the three requests on the board without knowing the filename, and the dependency becomes obvious. If someone answers "two," accept it and ask what happens if course-announcements.html also turns out to be missing. The felt need for a loop is the whole purpose of these four minutes; do not rush to the vocabulary.
Screen 7 of 16 · Four-round role-play
Act out the loop—one role, one move at a time.
An agent workflow is easier to understand when different students perform the goal, proposal, observation, and authority functions themselves.
Your taskForm groups of four. Each person takes one role and speaks only when that role is highlighted. The case is fictional: diagnose a broken Announcements link under a read-only boundary.
Paper-agent simulation · Four explicit roundsRound 1 frame → Round 2 observe → Round 3 revise → Round 4 stop
Diagram structure: the goal keeper gives a bounded request to the model role. The model proposes a read. The host and tool role checks permission and returns an observation. The recorder carries the observation back to the model. When the model proposes a change, the human reviewer enforces the stop boundary. The four rounds are frame, observe, revise, and stop.
Round 1 · FrameVisual state: Goal keeper is highlighted; move 1 of 7 is revealed.
Goal keeper reads: “Diagnose why the Announcements link fails. You may inspect course files. Do not edit or publish. Stop with evidence and a proposed next step.”
Move 1 of 7
Assign one role to each person
1 · Goal keeperReads the outcome and boundaries. Rejects silent scope changes.
2 · ModelProposes the next step. It does not invent the tool result.
3 · Host + toolChecks permission, performs only the approved operation, and returns evidence.
4 · Reviewer + recorderTracks the trace and decides whether a new authority level is needed.
Group-size fallback: three people can combine goal keeper and reviewer. One person can narrate every role without moving around the room.
Discuss · 12-minute routine
At what move did this become more than one generated response? Which move required human authority?
ASSIGN · 3ROLE-PLAY · 5DEBRIEF · 4
Do not reward theatrical performance. Listen for the dependency: the observation changes the next proposal, and the proposed state change triggers the human boundary.
Screen 8 of 16 · The problem before the form
Vague instructions are where agent work goes wrong.
You have watched a bounded request work. Here is the same request written badly.
Your taskRead the two versions. Name one thing the agent could do under the first that nobody asked for.
Same job · two instructionsOne of them is safe to hand over
Written badly
“Fix the Announcements link.”
Three words, and every one of them is a gap:
Fix — by doing what?
Edit the page? Rename a file? Publish the change? All of them are “fixing.”
Based on what?
Nothing says the agent must look before it changes anything.
Finished when?
Nothing tells it to stop and show you. So it may not.
Written as a brief
Outcome
Report why the Announcements link fails and propose one correction.
Evidence
Based on the course files you are allowed to read — not on what usually causes this.
Tools and limits
You may read. You may not edit, rename, or publish.
Stop rule
Return the evidence and the proposal, then stop for a person.
Carry this forward
Those four headings — outcome, evidence, limits, stop rule — are the Agent Brief. The next screen has you write one.
Keep this to three minutes; it exists only to give the builder on the next screen a reason to exist. The answer you want on "what could it do that nobody asked for" is publish, or edit an unrelated file. If the room is quiet, ask what "fix" would mean to a contractor you hired and never spoke to again.
Screen 9 of 16 · Construct before comparing
Write the boundary before the agent writes the plan.
A useful Agent Brief makes the outcome, evidence, permissions, and stopping rule concrete enough that another group does not have to guess.
Workshop caseAsk an agent to prepare a one-page Week 2 study guide from instructor-provided course pages. It may read those pages and draft locally; it may not upload private material, change course files, or publish.
Agent Brief builder · Draft first, compare laterThe structure check measures completeness—not quality
Draft first; reveal the example afterward.
Good-enough standard
1
Observable outcomeA reader can tell when the requested deliverable exists.
2
Named evidenceThe agent knows which supplied sources support the output.
3
Bounded authorityAllowed tools and forbidden state changes are explicit.
4
Stop and hand-offThe agent knows when to return evidence instead of acting.
Structure present: 0 of 4 fields
One good-enough brief
Outcome: Create a one-page study guide for classmates defining LLM, agent, tool, and skill.
Evidence: Use only supplied Week 1–2 pages; cite page titles and flag gaps.
Limits: Read and draft locally; no private uploads, course edits, email, or publication.
Stop: Return the draft, source list, and uncertainties for instructor review.
Outcome: Create a one-page study guide for classmates defining LLM, agent, tool, and skill.
Evidence: Use only supplied Week 1–2 pages; cite page titles and flag gaps.
Limits: Read and draft locally; no private uploads, course edits, email, or publication.
Stop: Return the draft, source list, and uncertainties for instructor review.
This preview has no submit action and does not intentionally store your text. Still use only fictional or non-sensitive examples; never enter student records, grades, private peer work, unpublished research, or credentials.
Discuss · 12-minute routine
Could another group run your brief without guessing the scope, evidence, permissions, or stop point?
DRAFT · 5PEER TEST · 3COMPARE · 4
Ask peers to identify one ambiguity, not to rewrite the whole brief. Reveal the example only after teams have made a first attempt.
Screen 10 of 16 · The problem before the tool
The agent says it worked. That is usually all you see.
The work is done. Here is the message it hands back.
Your taskRead the report. Decide with a partner whether you would accept it and move on. Commit before revealing.
The final report · nothing else attachedWhat you would normally receive
What the agent returned
“Fixed the Announcements link and verified it works. ✓”
Confident. Specific. Two claims in seven words: something was fixed, and something was verified.
Commit · 1 min
Accept it and move on — yes or no?
Commit first.
Six things happened to produce that sentence. You were shown one of them.
Two of the six are a problem. The agent edited a page it was told not to edit — nobody approved it, and the report does not mention it. And the word “verified” has nothing behind it: no check was ever run.
Neither problem is visible in the report. Both are visible the moment you look at the steps.
A record of the steps is called a trace. The next screen is that trace — you find the two problems yourselves.Take a show of hands on accept/reject before revealing, and note the split on the board — most rooms accept it, which is the point. Do not say which entries are wrong; the next screen is the hunt. If a student asks how you would ever know, that is the right question and the answer is the trace.
Screen 11 of 16 · Evidence, action, and claim
Read the trace before trusting the success message.
An execution trace separates what a person requested, what the model proposed, what a tool observed, what the system changed, and what the final report merely claimed.
Your taskFollow six trace entries from the same fictional broken-link case. Identify the evidence entry, the first authority violation, and the claim that lacks verification.
Trace investigation · Reveal one entry at a timeInstruction ≠ proposal ≠ observation ≠ action ≠ verified claim
Timeline structure: entry 1 is a read-only human instruction. Entry 2 is a model proposal to inspect files. Entry 3 is a tool observation showing the broken href and existing target. Entry 4 is a model proposal to edit. Entry 5 is an edit action performed without approval. Entry 6 claims the link was fixed and verified even though no verification observation appears.
Entry 1 of 6
Instruction
A human sets a read-only boundary
“Diagnose the Announcements link. Inspect course files, but do not edit or publish. Return evidence and a proposed next step.”
Investigate: Which entry establishes a fact? Where should the workflow stop? What would count as verification?
Evidence · Entry 3The tool observation supports the filename mismatch.
Authority violation · Entry 5The edit changed state after a read-only request; the system should have stopped at Entry 4.
Unsupported claim · Entry 6No link-check result appears, so “verified” is not supported by this trace.
Discuss · 7-minute routine
Where would you insert a human checkpoint, and what exact evidence must cross that checkpoint?
TRACE · 3PAIR · 2AUDIT · 2
Insist on trace language: “Entry 3 is evidence,” “Entry 4 is a proposal,” and “Entry 5 exceeds authority.” This prepares students for later evaluation and ethics work.
Screen 12 of 16 · Two words that are not the same
It can edit the page. May it?
The agent has the evidence. The fix is one line. Its account has permission to write to that file.
Your taskDecide as a class: should it make the change now? Commit before revealing.
Everything needed is in placeExcept one thing
What is true right now
It knows the answer
The link points at a file that does not exist; the correct one does.
It is able to act
The account it runs under can write to that page. Technically, nothing stops it.
Its instructions said read-only
“Inspect course files, but do not edit or publish.”
Commit a class answer.
Being able to do something is not being allowed to do it. Those are two different facts about the same moment, and they came from two different places: what the software permits, and what a person asked for.
Capability — what the system is technically able to do. Set by accounts, tokens, and file permissions.
Authority — what it has been permitted to do for this task. Set by a person, in the request.
When the two disagree, authority wins — and it must be granted out loud. It is never inferred from the fact that the system could.
The next screen argues the harder question: what would it take to widen the authority here?Expect the room to split, and expect "it's obviously right, just fix it" — take that seriously rather than correcting it, because the evidence genuinely is good. The point is not that the fix is wrong; it is that a correct change made without permission is still an unpermitted change. That distinction is what the debate on the next screen operationalises.
Screen 13 of 16 · Evidence-based authority debate
Capability does not grant authority.
A system may be technically able to edit or publish while its current brief authorizes only reading and local drafting. New authority must be explicit—not inferred from capability.
Detailed caseA course agent was told to inspect a broken link under a read-only boundary. It found strong evidence of a filename mismatch and can technically edit the instructor-owned page. Should it receive one additional, narrowly scoped permission?
Four-round debate · Argue, switch, then operationalizeThere is no credit for “AI can do it” without scope, evidence, and accountability
Authority ladder: the current brief permits reading approved files and drafting locally. Editing an instructor-owned shared file requires new permission. Publishing or messaging externally remains outside scope. Debate rounds examine evidence, argue whether to grant a narrow edit, switch positions, and define operational conditions.
Round 1 · Establish evidence
Both teams must begin from the same trace: the page points to announcements.html, that file is absent, and course-announcements.html exists. Evidence supports a mismatch; it does not itself authorize a write.
Round 1 of 4
One case · Two defensible positions
Shared evidence
Current authority: read approved course files, draft locally, stop for review. Proposed expansion: change one href in one instructor-owned file, then run one link check.
Current authority: read approved course files, draft locally, stop for review. Proposed expansion: change one href in one instructor-owned file, then run one link check.
Position A · Grant narrowly
Define the exact file and line, require a reversible diff, run verification, log the action, and stop before publication.
Position B · Preserve read-only
The instructor owns the shared page. Return the evidence and patch; a human applies and publishes the correction.
Required side switch: after arguing your assigned position, state the strongest reason for the other position. Then write one operational rule both sides accept.
Discuss · 8-minute routine
What exact conditions—not confidence or convenience—would justify expanding this agent's authority?
EVIDENCE · 2ARGUE · 3SWITCH · 2CLARIFY · 1
Keep this operational. Later ethics work will examine power and accountability more deeply; today students must distinguish capability, current permission, and a controlled authority expansion.
Screen 14 of 16 · Three things nobody asked for
A helpful agent, three bad afternoons.
A study agent is asked to read approved course pages and draft practice questions. Nothing about that request is unreasonable.
Your taskThree things happen. For each, decide whether the request allowed it. Commit as a class, then reveal.
The brief: read approved course pages, draft practice questionsAllowed, or not?
What the agent did
1 · It read a classmate’s shared notes
The folder was visible to its account, so it treated the notes as course material and used them.
2 · It stated a deadline that was never given
The draft says the quiz is on Friday. No supplied page says so. It read like every other sentence.
3 · It emailed the draft to the class list
It decided that sharing study questions was helpful, and it had a send tool available.
How many of the three did the brief allow?
Decide all three first.
None of the three was allowed — and no single rule would have stopped all three.
1 was an input problem: it could reach something it should never have been given.
2 was an evidence problem: it produced a claim no source supported.
3 was an action problem: it took a step that reaches other people, without asking.
“Be careful” would have prevented none of them. Each needs a different kind of boundary, decided before the agent runs — one about what it can see, one about what counts as support, one about when it must stop and ask.
Those are the layers you design on the next screen.Run all three as a quick show of hands before revealing; groups usually catch 3, sometimes 1, and almost never 2. Case 2 is the one worth dwelling on — an invented deadline looks exactly like a real one, which is why an evidence rule has to be structural rather than a matter of care. Do not let "just tell it to be safe" stand; ask which of the three it would have stopped.
Screen 15 of 16 · Four-layer design sprint
Safety is a system of boundaries—not a warning at the end.
A study agent becomes safer when context, tools, evidence checks, and hand-off rules constrain the whole workflow before a consequential action is possible.
Your taskDesign the minimum safeguards for a study agent that reads approved course pages and drafts practice questions. Each group owns one layer and completes its sentence stem before the sample design is revealed.
Minimum safe system · Assemble four independent layers“Safe” here means better controlled—not risk-free
System diagram: a study agent sits at the center. Four safeguard layers are added in order. Context limits inputs to approved course pages and excludes sensitive data. Tool permissions allow reads and local drafts but no shared edits or external messages. Evidence checks require citations and verification. Human hand-off occurs before edit, send, or publish actions.
Layer 0 of 4 · Design first
Group sentence starters
1 · Context + privacyIt may use ___, but it must not receive ___.
2 · Tools + permissionsIt may perform ___, but it cannot ___.
3 · Evidence + checksBefore claiming ___, it must show or run ___.
4 · Stop + hand-offIt must stop when ___ and ask ___.
Do not reveal a sample yet. Give each group one layer and ask for a concrete boundary that host software or a human could actually enforce.
Design · 5-minute routine
Which safeguard belongs in the prompt, which belongs in host software, and which still requires a human?
ASSIGN · 1DESIGN · 2ASSEMBLE · 1COMPARE · 1
Do not accept “be safe” or “be accurate.” Require enforceable controls: approved source list, read-only tool scope, an observable check, or a named human checkpoint.
Screen 16 of 16 · One-minute synthesis
If you can explain the boundary, you understand the system.
Meeting 1 ends with a compact mental model: language generation is one component; an agent workflow adds coordination, observations, tools, and explicit authority boundaries.
Write before revealComplete the three sentence stems in your notes. Use the broken-link or study-guide case as evidence. Then compare your explanation with the course anchors.
Exit ticket · Explain rather than labelThis is a learning check, not a graded quiz
Diagram before reveal: an unlabeled system shows a central model, reusable guidance, tool operation, returned observation, host gate, and human boundary. Students first explain the relationships in their own words.
Your explanation first
Three-sentence exit ticket
Sentence 1 · Model
An LLM contributes ___, but that does not prove ___.
Sentence 2 · Workflow
A tool differs from a skill because ___; the agent uses them by ___.
Sentence 3 · Authority
The system must stop and ask a human when ___.
Model: generates a proposal from context; fluency is not verification.
Workflow: a skill guides reusable steps, while a tool performs an operation and returns an observation.
Authority: host controls and accountable humans bound consequential action.
Close · 3-minute routine
What is one boundary you would refuse to leave implicit in any agent you use?
WRITE · 1PAIR · 1ANCHOR · 1
Collect two contrasting boundaries aloud. Close by previewing that Meeting 2 will apply this model to a concrete development workflow rather than add more vocabulary.
Meeting 2 · Screen 1 of 11 · Retrieve the boundary
The permission changed. Responsibility did not.
Meeting 1 ended with evidence of a filename mismatch and a human stop. Today the human permits one reversible working-copy edit—but no commit, push, pull request, merge, or publication.
Your taskBefore pressing Reveal, write three bullets labeled Observed, Allowed, and Prohibited. Then add the evidence you would require before accepting the edit.
Boundary retrieval · Same fictional Announcements caseFour steps · evidence → old boundary → new grant → acceptance test
The visual begins with three observations: week-02.html points to announcements.html, that target is absent, and course-announcements.html exists. It then shows the old read-only boundary, a new permission for one reversible working-copy edit, and a review gate requiring a diff, check result, and human decision.
Step 1 of 4
Current retrieval stepObservedhref=announcements.html · target absent · course-announcements.html exists Newly allowedEdit one href in the working copy and return reviewable evidence. Still prohibitedCommit · push · PR · merge · publish
Observed evidence
The trace records the current href, the missing target, and the existing candidate file. That supports a mismatch—not permission to change anything.
Evidence can support a diagnosis. Authority determines which action may follow.
Retrieve · 4-minute routine
What must you see before accepting the edit: a confident explanation, a diff, a check result, or something else? Why?
WRITE · 1PAIR · 2ANCHOR · 1
Expected minimum: the exact diff, evidence that the target exists, a link-check result, confirmation that no unrelated file or wording changed, and a human decision inside the granted scope.
Meeting 2 · Screen 2 of 11 · Something went wrong
You committed the fix. Nobody can see it.
Friday afternoon. You make the href change, write a careful commit message, commit it, and close the laptop.
Your taskMonday, a teammate says the link is still broken and they cannot find your change anywhere. Decide with a partner what went wrong, then commit an answer.
What you actually didThree steps, all of them successful
1 · Edited the file
Changed the href in your copy of the page. Saved it.
2 · Committed
Recorded the change with a message. The tool confirmed it: 1 file changed.
3 · Closed the laptop
No errors. No warnings. Nothing failed.
Commit · 2 min
Why can nobody else see it?
Commit an answer first.
Nothing failed. The commit worked exactly as designed — and it never left your machine.
A commit writes an entry into a history kept on your computer. That history is complete, and it stays on your machine until you send it somewhere. (It is not sealed: commits can be amended or discarded later, and a synced folder or backup may copy them — but nothing has been shared with your team.) The tool that keeps it is Git.
This is the single most common misunderstanding about version control, and it is worth naming plainly: committing is saving, not sharing.
So what does share it? That is the next screen.Almost every room picks "the commit failed" or "they need permission" — both reasonable, both wrong, and the wrongness is the lesson. Do not rescue them early. If someone already knows the answer, ask them to say what a commit physically writes and where; most people who know the word cannot answer that.
Meeting 2 · Screen 3 of 11 · Now name the second thing
One action sends it somewhere other people can reach.
Your history is on your laptop. Something has to carry it to a place your teammate can read — and that place is a different system, run by somebody else.
Your taskSort the six actions. Which stay on your machine, and which reach other people? Decide each one aloud before revealing.
Six actions · where does each one land?Stays local, or crosses to others
Sort these
Edit a file
Change the href in your copy.
Make a commit
Record the change with a message.
Create a branch
Start a separate line of work.
Push
Send your commits to the hosted copy.
Open a pull request
Ask people to review the change.
Merge
Put the change into the shared branch.
Commit as a class: where does the line fall?
Sort all six first.
The line falls after the third one. Working on your own machine, edit, commit, and branch all stay there. Push, pull request, and merge all reach other people.
Git is the first group: it records versions, locally, and needs nothing else to work.
GitHub is the second: a hosted copy other people can reach, plus the review machinery around it — issues, pull requests, checks, merges.
You can use Git with no GitHub at all. The moment you cross the line, your change stops being yours alone and enters somebody else’s workflow. That is why crossing it needs its own permission — and why our agent was told it may edit, but may not commit or push.
One honest exception. You can also make commits and branches through GitHub’s website, which writes them straight to the hosted copy. The rule is not “the word commit is always local” — it is that where you do the work decides who can see it.
Every remaining screen today lives on the left of that line.Branch is the one that splits the room; it feels shared because teams talk about branches constantly, but creating one changes nothing outside your machine. Push is the moment worth dwelling on — it is the first irreversible-by-you action of the day, and it sets up the authority boundary the agent is held to for the rest of the meeting.
Meeting 2 · Screen 4 of 11 · Make each claim inspectable
What would have caught the agent that said “verified”?
In Meeting 1 an agent edited a page it was not allowed to touch and reported success that nothing supported. Nobody noticed, because nothing was required of it except a sentence.
Your taskBuild the seven-stage chain. Identify the first stage where “the agent says it worked” is no longer enough—and name the missing evidence.
Classroom review chain · One bounded working-copy changeSeven stages · task → decision
The seven-stage chain is bounded task, inspect and map, plan, authorized working-copy edit, diff, checks, and human decision. A separate dashed extension after the decision shows commit, push, pull request, and merge as later actions requiring explicit authority.
1 · Bounded task
State the problem, current evidence, allowed scope, prohibited actions, and done condition before asking for a change.
Stage 1 of 7
Seven-stage review checklist
The required case ends at the human decision. Commit, push, PR, merge, and deployment are not implied by a successful edit.
Discuss · 6-minute routine
At which stage does confidence stop being enough? What visible artifact should replace it?
BUILD · 3PAIR · 2ANCHOR · 1
Strong answers locate several gates: inspection needs observations, the edit needs a diff, success needs a check result, and any authority expansion needs explicit human permission.
Meeting 2 · Screen 5 of 11 · Inspect before changing
Map responsibilities before opening every file.
A repository tree tells you which paths exist. It does not, by itself, prove what each file does or whether the link is correct.
Your taskSelect the two files you would inspect first for the broken Announcements link. Lock your choices, then compare them with the revealed responsibility map.
Synthetic repository · No account or live repositoryChoose → explain → lock → reveal
A synthetic course-site repository contains README.md, week-02.html, course-announcements.html, styles.css, navigation.js, and tests/link-check.txt. The map highlights selected paths first, then identifies week-02.html and course-announcements.html as the first relevant inspection pair.
Select exactly two paths.
Clickable repository tree
An observed filename is evidence that a path exists—not proof of its purpose or correctness. Explain your choices before revealing the map.
Investigate · 8-minute routine
Which two files come first, and what question would you ask of each? What would make you inspect a third file?
PREDICT · 2PAIR · 3REVEAL · 2CLARIFY · 1
Course anchor: inspect week-02.html for the actual href and course-announcements.html to confirm the candidate target. The link-check artifact becomes relevant during verification, not as the first source of current page behavior.
Meeting 2 · Screen 6 of 11 · From brief to filed issue
You wrote the brief. Now file it where a reviewer can act on it.
On Tuesday you wrote outcome, evidence, limits, and a stop rule. An issue is that same brief, filed in the repository — with limits split into what may change and what must not, and one addition a brief never needed: what evidence ends the task.
Your taskIn pairs, rewrite this as an issue. Four fields you already know from Tuesday; spend your time on the fifth. “Make sure everything still works” is not a done condition — decide what evidence would actually end the task. Reveal only when your pair has a full draft.
Issue repair workshop · Weak input: “Fix the Announcements link and make sure everything still works.”Draft first · sample is read-only
Draft in notes or boxes first.
Course sample · hidden until revealProblemThe Announcements link on week-02.html opens a missing target. Observed evidenceThe page uses announcements.html; that path is absent; course-announcements.html exists. Scope + limitsChange only that href in the working copy. Do not change wording, commit, push, open a PR, merge, or publish. Done conditionReturn the exact diff and a fresh link-check result, then stop for Accept/Revise/Reject.
Before reveal, ask another pair: “Could an agent complete your task without guessing what it may change or how success will be checked?”
This page has no submit action and does not intentionally store your text. Browser extensions, recordings, or a shared device may still expose it; never paste private repositories, credentials, grades, peer work, or unpublished material.
Write + stress-test · 8-minute routine
Which field most reduces accidental scope expansion? Which field makes a success claim testable?
DRAFT · 3SWAP · 2REVEAL · 2ANCHOR · 1
Do not grade wording polish. Look for separation among problem, evidence, authority, and completion evidence. Accept different formulations that preserve the same boundaries.
Meeting 2 · Screen 7 of 11 · Five-round plan challenge
Review the plan before it becomes a sequence of actions.
Five plan steps, five different questions. Each round names the one test that matters for that step, so you are never asked to weigh everything at once.
Your taskEach round names its one question. Answer that question only, choose keep, revise, or block, and explain it to a partner before revealing. Later steps stay hidden.
Plan gate · Round 1 of 5Choose → explain → reveal → next round
A five-gate plan reveals one step at a time. Decisions are kept, revised, or blocked. The final state summarizes narrow inspection, removal of an overbroad rename-all step, one authorized href edit, a fresh link check, and separation of local commit from shared push authority.
Round 1 · Inspect narrowly
Open week-02.html, read the Announcements href, and confirm whether the candidate target exists.
This round asks one question:
Choose before reveal.
Rationale + accumulated review
Your group’s reason comes first. The course rationale appears only after a choice.
A claim becomes reviewable when it is tied to an observation, diff, check result, or explicit authority—not when it merely sounds specific.
Challenge · 6-minute routine
Which plan step is most dangerous if it looks efficient? Which action must be separated into a new permission request?
ROUNDS · 4COMPARE · 1ANCHOR · 1
The bundled “commit and push” line is deliberately misleading: commit changes local history; push crosses to a remote. The current case authorizes neither.
Meeting 2 · Screen 8 of 11 · Four-stage diff microscope
Translate changed lines into behavior and scope.
A diff shows what text changed. Reviewers still have to explain what users experience, whether the change matches the issue, and what remains unverified.
Your taskAt each stage, describe the user-visible behavior without merely saying “a line was added” or “a line was removed.” Identify the first scope violation.
Synthetic diff · week-02.htmlStage 1 of 4 · notation → href → label → judgment
@@ location/context− removed+ added
@@Announcements link
−<a href="announcements.html">
+<a href="course-announcements.html">
−<span>Announcements</span>
+<span>Course updates</span>
</a>
Href finding appears at Stage 2.
Label finding appears at Stage 3.
Stage 1 · Orient to the notation
The hunk marker locates the change. Context lines help place it. Minus and plus show replaced text; they do not mean “bad” and “good.”
Stage 1 of 4
Behavior view
The behavior view first shows a broken Announcements link. It then shows the corrected target while preserving the label, followed by an unrelated label change to Course updates. The final state marks the href fix as supported and the label change as outside scope.
Before revealing more: explain what each symbol can and cannot tell you.
Interpret · 6-minute routine
Which changed line repairs the reported behavior? Which changed line may be reasonable but still requires a different issue or permission?
NOTATION · 1INTERPRET · 3JUDGE · 2
Course anchor: the href correction matches the evidence and granted edit. The label change may be harmless, but it is unrelated and therefore cannot be silently bundled into this task.
Meeting 2 · Screen 9 of 11 · Four-round evidence challenge
A check supports one claim—not every claim.
Reviewers must connect each statement to the artifact that can support it. A passing link check cannot prove that scope was respected or that anything was published.
Your taskFor each claim, choose the strongest available evidence—or choose “no supporting evidence.” Explain what that artifact establishes and what it still cannot establish.
Claim–evidence ledger · Round 1 of 4Choose → explain → reveal → preserve the match
Claim 1 · Candidate target
“course-announcements.html exists in the inspected repository.”
Choose evidence first.
Your reason comes first. Name the exact observation—not merely the tool that produced it.
Accumulated review ledger
Four different claims may require four different judgments. “No evidence” is the correct answer when the packet does not support a claim.
Match + challenge · 6-minute routine
What exactly does “LINK CHECK: PASS” establish? Which tempting conclusion remains unsupported?
ROUNDS · 3PAIR · 2ANCHOR · 1
Course anchor: repository observation supports existence; the diff supports the href change; fresh check output supports link resolution; nothing in the packet supports publication.
Meeting 2 · Screen 10 of 11 · Six explicit phases
Make the human decision from a shared evidence packet.
Everything from this meeting arrives at once: a task, a diff, a check result, and a claim. Four people read the same packet through different lenses, and the group has to decide what happens next.
Your taskTake one lens each, work the six phases, argue the opposite case, then vote Accept, Revise, or Reject. Every vote needs evidence from the packet — not a preference.
Review board · Phase 1 of 6Same packet for everyone
Shared packet · the only evidenceTask + boundaryChange only the Announcements href. No wording change, commit, push, PR, merge, or publish. Observed repositoryannouncements.html is absent; course-announcements.html exists. Submitted diffhref corrected — but the label also changes, Announcements → Course updates. Fresh check outputLINK CHECK: PASS · 0 missing targets. Says nothing about scope or publication.
Phase 1 · Assign roles · 2 minutes
One person owns each lens: scope, diff, verification, or authority. Read your prompt aloud so the group knows what evidence you must report.
Phase 1 of 6.
Four lenses · one finding eachScopeChanged behavior vs permitted task DiffEach line → user-visible behavior VerificationWhat the check proves, and its limits AuthorityActions still outside the grant
Voting unlocks after Phase 4.
Board protocol · 15-minute routine
Can a technically successful change still require revision? Under what explicit policy could Reject also be defensible?
ROLES · 2INSPECT · 4REPORT · 3SWITCH · 3VOTE · 2ANCHOR · 1
Course anchor: Revise—retain the supported href correction, remove the unrelated label change, rerun the check, and return for review. Reject is defensible only under a stated strict policy requiring resubmission after any scope violation. Accept ignores the explicit boundary.
Meeting 2 · Screen 11 of 11 · Formative exit artifact
Compress the workflow without erasing the evidence.
A useful handoff preserves what was asked, what was observed, what changed, what was checked, and what a human decided. It does not turn uncertainty into a success claim.
Your taskThis is ungraded practice and is not submitted. Build the five fields progressively during Meeting 2; use these final four minutes to complete and compare them with the course sample. Keep your own wording if it is equally specific and evidence-based.
Week 2 Workflow Card · One running caseFormative · ungraded · no submission
Draft in notes or boxes first.
Course sample · hidden until revealBounded taskRepair one href in week-02.html; no wording change or Git/GitHub action. Observed evidenceannouncements.html is absent; course-announcements.html exists. Diff summaryThe href fix is supported; the Course updates label is unrelated. VerificationFresh link check passes with 0 missing internal targets; it does not prove scope or publication. Authority + decisionRevise: remove the label change, rerun the check, and stop for human review. Commit, push, PR, merge, and publish remain unauthorized.
Pair check before reveal: can another person separate observation, change, check result, and human authority from your card?
This page has no submit action and does not intentionally store your text. Browser extensions, recordings, or a shared device may still expose it; never paste private repositories, credentials, grades, peer work, or unpublished material.
Exit · 4-minute routine
Which sentence on your card would prevent the next person from silently expanding authority?
DRAFT · 2PAIR CHECK · 1REVEAL · 1
Do not collect or score the card. Use completion-oriented peer or instructor feedback on specificity, evidence boundaries, verification limits, and human authority—not polished writing or account access.