🧪Lesson 04AI Engineer Loopcraft Workshop 2026

See and control the check from Pi and Herdr

Add a visible way to ask for status, run the local check, and see what happened.

The checker now has a local event file, tests, receipts, and a Lakebed view. Add one status command and one Pi command so a person can see whether the check is running, stale, waiting, or done before any claim step exists.

Your next move

You already have

A local event file, check command, tests, receipts, and Lakebed view.
A person can run the check, but the current state is not easy to see from the agent workspace yet.

Add now

One stable status command for the checker.
A Pi status/check-now path that runs against the local event file.
A Herdr pane that keeps the current status or latest check visible.

Stop before

Adding claim commands, background scheduling, or a real daemon beyond the lesson stub.
Accepting status output that disagrees between Pi, Herdr, Lakebed, and the latest receipt.

Tiny status output shape

state: waiting
checkedAt: 2026-06-29T21:00:00.000Z
lastCommand: pnpm run check:issues
lastReceipt: receipts/issue-check-001.json
waitingReason: ISSUE-002 needs approval
nextSafeAction: ask for approval or pick a ready issue

Starter prompt

Add the smallest local status command for the checker. Keep Herdr visible with a Pi pane and a status/check pane. Print state, checkedAt, lastCommand, lastReceipt, and waitingReason. Add a Pi command or prompt for status and check-now. Prove Pi output, Herdr output, Lakebed state, and the receipt name the same issue and latest check. Do not add claim commands or background scheduling yet.

Build checklist

0/4 done

Make state visible

Start with the status process, watcher, or check script. Name the pane and keep logs visible in Herdr.

Add stable status output

Return state, checkedAt, lastCommand, lastReceipt, and waitingReason as JSON or a stable text shape.

Wire Pi controls

Add the smallest Pi command or prompt path for status and check-now. Do not add claim commands yet.

Compare the outputs

Run one check from Pi, watch Herdr output, inspect the receipt, and compare Lakebed state.

Proof to save

Save proof that status, command output, and the visible panes all describe the same current state.

A named Herdr pane runs the status/check command and keeps the latest logs visible.
A status command reports state, checkedAt, lastCommand, lastReceipt, and waitingReason.
Pi can run status and check-now against the local event file.
Pi output, Herdr output, Lakebed state, and the latest receipt name the same issue and latest check.

herdrPane: pane name and command
statusCommand: command and output shape
piCommand: command or prompt used
latestReceipt: path inspected
outputAgreement: Pi / Herdr / Lakebed / receipt comparison
waitingReason: what blocks movement, if anything

Done when

Pi can run status/check-now, Herdr shows the run, and the latest receipt names the same issue, command, and checkedAt value.

Why it matters

Risk reduced: you can tell whether the checker is running, stale, waiting, or done.
Temptation avoided: hiding real state inside a terminal nobody is watching.
Do not automate yet: claim commands, background scheduling, or real work execution.

Try this 🔨

Pretend the status is stale. Name the first three places you inspect before running anything else.

Exploration prompts

Use these when you want to ask an agent for a narrower pass instead of handing it the whole lesson.

Check status visibility

Inspect the Pi command, Herdr pane setup, Lakebed status, and local check command. Tell me whether a person can see if the checker is running, stale, waiting, done, or failed without reading code.

Make status boring

Design the smallest status output for the checker. Include state, checkedAt, lastCommand, lastReceipt, waitingReason, and next safe action.

Prove agreement

Run or describe the proof that Pi output, Herdr output, Lakebed state, and the receipt all point at the same current issue state. Report mismatches before changing anything.