📎AppendixAI Engineer Loopcraft Workshop 2026
Glossary
These are the workshop terms a learner might reasonably pause on and ask, “what does that mean here?”
Receipt fields stay on the lesson pages. This glossary is for concepts, tools, statuses, and boundaries that carry local meaning across the workshop.
Rule: keep this alphabetized and grounded in words the public workshop actually uses. If a word is only a receipt field, explain it in that lesson instead of turning the glossary into a junk drawer.
AGENTS.md
The repo instruction file for future coding agents. In this workshop it holds short standing rules, not the lesson narrative.
Use it when: Use it when a rule should outlive the current chat, such as check commands, safe boundaries, and when an agent should stop.
See: Lesson 01
Approval-required
A work status meaning the next move needs a person before the loop can continue safely.
Use it when: Use it for product-file edits, external writes, unclear scope, or any step the project rules say needs human approval.
Bounded gardener
A cleanup helper that may propose one boring maintenance follow-up, then stops when the repo or queue is not safe to touch.
Use it when: Use it after dispatch is safe and you want cleanup without giving an agent a blank-check maintenance job.
See: Lesson 06
Check command
The command a fresh reader can run to prove the loop read the local event file and classified the issue state correctly.
Use it when: Use it as the source of truth before trusting Lakebed, dispatch, review, or a supervisor comparison.
See: Lesson 02
Claim event
A local event that records intent to work on one ready issue. It is not permission to edit product files.
Use it when: Use it before any work attempt so the loop leaves a visible trail of which issue was selected and why.
See: Lesson 05
Compare-only mode
A safe mode where a new decision check can answer beside the current checker, but the current checker still decides.
Use it when: Use it when testing a supervisor-style decision path without letting it write, dispatch, or control execution.
See: Lesson 08
Docker workshop computer
The prepared container for the workshop. It gives everyone the same repo path, tools, and local setup without using Joel's private machine config.
Use it when: Use it for the normal workshop path. Use the no-Docker appendix only when you intentionally set up the host machine instead.
See: Setup, Local setup appendix
Dry-run mode
A run that prints or saves what it would do without making the risky change.
Use it when: Use it before dispatch, cleanup, or review gets write power. The receipt should show what did not change.
Herdr
The terminal workbench used here to keep Pi, status commands, logs, and checks visible side by side.
Use it when: Use it when a lesson asks you to watch the loop state while also talking to Pi.
Input-required
A work status meaning the issue does not have enough information for a safe next move.
Use it when: Use it when the loop should ask for missing acceptance criteria, unclear files, or contradictory issue facts instead of guessing.
See: Lesson 02
Issue event
One JSONL record describing an issue fact: new work, missing input, approval required, a claim, a result, or a status change.
Use it when: Use it as the durable unit every later lesson reads before adding views, dispatch, cleanup, review, or comparison.
See: Lesson 02
Lakebed
The local issue-state view used in this workshop. It should show the same facts as the check command, not become a second source of truth.
Use it when: Use it to make the loop state visible as cards, lists, or events after the local check already works.
See: Lesson 03
Local event file
The JSONL file the loop reads during the workshop, usually issues.jsonl or data/issue-events.jsonl.
Use it when: Use it before trackers, databases, schedulers, or APIs. The file is the local source of issue facts.
See: Lesson 02
Local issue checker
The small loop you build here. It reads local issue events, classifies work, stops when approval or input is needed, shows state, and writes receipts.
Use it when: Use it as the name for the thing you are building before it has real trackers, background workers, or external writes.
See: Workshop home, Lesson 01
Maintenance event
An issue event for boring cleanup work, such as a stale receipt, missing link, outdated status, duplicate follow-up, or incomplete event.
Use it when: Use it when the gardener proposes one follow-up without editing product files or creating a pile of cleanup tasks.
See: Lesson 06
Memory mode
A safe run mode where the loop records intended work or notes without changing product files or calling external services.
Use it when: Use it beside dry-run mode when you need a saved decision or note, but not implementation.
See: Lesson 05
Pi
The coding-agent shell used in the workshop. Pi is the place you ask for small passes, run commands, inspect files, and stop before risky work.
Use it when: Use it from the repo root. Start Lesson 01 with the lesson prompt or /loop-lesson-01 when the helper command is available.
Product files
Files that change the project being checked, not just receipts, docs, local events, or review notes.
Use it when: Use this boundary when a lesson says to prove productChangedFiles is empty or to ask before editing the app.
Read-only reviewer
A helper that can inspect a bounded input file and produce a review note, but cannot edit product files.
Use it when: Use it when you want a second opinion without creating a second implementation path.
See: Lesson 07
Ready
A work status meaning the issue has enough input and no current stop reason.
Use it when: Use it carefully: ready means the next local step can be considered, not that product files can be edited automatically.
Receipt
A saved record of what the loop read, decided, refused, changed, checked, and what should happen next.
Use it when: Use it when a future reader should be able to verify the run without trusting chat history.
See: Lesson 02
Role contract
The boundary for a helper agent: what it may read, what it should produce, what it must refuse, and whether it may edit files.
Use it when: Use it before specialist review so a reviewer does not accidentally become an implementer.
See: Lesson 07
Stop rule
A plain boundary that tells the agent or loop to pause instead of guessing or editing ahead.
Use it when: Use it for missing input, required approval, dirty repo state, broken checks, unclear ownership, duplicate follow-ups, or future-lesson work.
See: Lesson 01
Supervisor comparison
The compare-only Lesson 08 move: run a new candidate decision check beside the current checker and record whether their answers match.
Use it when: Use it before promoting a new decision path. If the answers disagree, stop and explain the mismatch.
See: Lesson 08
VISION.md
The human-owned intent file created in Lesson 01. It says what the local issue checker is for, what it may change, what needs approval, and what is out of scope.
Use it when: Use it before implementation and before changing direction. It is the project intent, not a command script.
See: Lesson 01
Work packet
A small bundle for review: issue state, relevant files, constraints, acceptance criteria, commands run, receipts, and the one question to answer.
Use it when: Use it before specialist review so the reviewer can stay focused and read-only.
See: Lesson 07