CS 319 · Meeting 3 of 10
Where human intent becomes machine-checkable — and the anatomy of the machine that checks it.
Agenda · 100 min
Reading: chapters 6–7
Core concept · ch 6
PRD — for humans
Intent, market, narrative. Read by people who decide what and why. Changeable by conversation.
Spec — for machines and tests
Boundary, criteria, refusal conditions. Consumed by agents and turned into pass/fail checks. Changeable only by edit — like code, because it is code.
Without a good spec, no loop can know whether it succeeded. The spec is the difference between a loop that ships and a loop that wanders.
The artifact · memorize these
Example · the spec artifact itself
task: update dependency patches in web/ (minor + patch only) boundary: bump versions in package.json, run tests, open ONE PR tools: [read_files, edit_files, run_tests, open_pr] # allowlist refusal: - major version bump required # stop, don't improvise - any test failure after bump - license change detected acceptance: AC-1: package.json versions changed, lockfile consistent [check: npm ci] AC-2: npm test exits 0 [check: npm test] AC-3: PR body lists old→new versions + test summary [check: regex] AC-4: diff touches ONLY dependency files [check: path glob] out_of_scope: refactors, changelog edits, version pinning of peer deps
Every AC maps to a mechanism in brackets. A criterion that can't be made pass/fail is a question, not a criterion.
Core concept · ch 7
4 moving parts
trigger · file structure · tools · agent-ready codebase
3 triggers
cron (time) · webhook (event) · agent-to-agent (delegation)
3 operational primitives
durable state · plugins · guardrails
State split
hot — in the context window
warm — in files the loop reads/writes
cold — in the DB, for audit and replay
4 exit conditions
goal satisfied · max iterations · stagnation breaker · human escalation
The one exam question
A loop with no breaker doesn't stop when it stops progressing — it stops when it runs out of iterations or money. The breaker asks a different question than the verifier:
verifier asks
"Is the output correct?"
breaker asks
"Are we still moving? Did run N differ from run N−1 at all?"
# breaker: hash the state that matters; identical twice = stuck
H=hash(output+diff_stats)
if H == LAST_H: STAGNANT++; else STAGNANT=0
[ $STAGNANT -ge 2 ] && escalate "stagnation: identical outputs x2"
A foreman who cannot design the trigger, state, and exit of a loop is just a babysitter.
Case study · part 3 of 10
Target: the dependency-update chore loop (their lead dev "Rasa" did it manually every Friday, 90 minutes, hated it). First draft had 12 acceptance criteria — everything was a criterion. Kata'd down to 4.
The interesting field: refusal conditions. The team's instinct was "handle everything." The spec's job was the opposite — major bump? stop. peer-dep conflict? stop. license change? stop. Three ways to refuse, written before one line of loop code.
Week one: 6 runs, 4 refused correctly, 2 landed clean PRs. Rasa's Friday: 90 → 15 minutes (review only). The spec, not the model, was the lever.
Spec kata · 20 minutes
Your task (pairs)
"Triage the support inbox every morning: label, prioritize, draft replies for the easy ones."
Test: swap with the pair next to you. Try to write an output that passes their criteria but is obviously wrong. If you can, their criteria have a hole.
Assignment A3 · due before Meeting 4
Task
Pick a task you (or a team you know) do ≥3×/week. Produce a complete spec.md: all five fields, criteria numbered and each mapped to a check.
Deliverables
spec.md · a 150-word defense of one refusal condition (why stop there?) · the hole-hunt: have a classmate try to pass your criteria with a bad output, document the attempt.
Rubric
Criteria quality (binary + mapped) 40% · refusal conditions 30% · hole-hunt documentation 30%.
Next: the four-phase pipeline and the six documents — what a council produces when it's working properly. Read ch 8–9.