0.8.4

• Every run of a lesson's check is kept, pass or fail (okl review R3, first slice). The
  stamp keeps only a lesson's last pass, so a check that failed, the run that caught a
  change, left nothing but a line on stderr, and a check that has caught regressions looked
  the same as one that never failed. okl verify, and okl reverify through it, now keeps
  each run (command, expected signal, outcome, commit) in a new check_run table: its own
  table, so an older okl rewriting a lesson's row cannot lose it. okl show prints how
  often the check passed and failed and its last failure; okl_get returns the latest
  runs and the counts. A shared service gets POST /check-run; against an older service,
  or if the write fails, verify warns that the run was not logged and its result stands.

• Every unbriefed prompt now says so (okl review R21). OKL_OFFLINE=1 let a prompt
  through when okl could not run, with a line on stderr that neither the agent nor, in
  most views, the person ever saw: the agent started the task as if a check had found
  nothing. The prompt hook now hands the agent a notice that it was not briefed, with okl's
  reason and that the absence of a briefing is not a clean check, and shows the person one
  line saying the same. Without OKL_OFFLINE, a prompt okl cannot brief is still blocked.

• A pinned okl that cannot start no longer blocks a prompt another okl could brief
  (#152). A venv okl whose python was removed, by a Homebrew upgrade for example, still
  exists and is executable, so the hooks accepted the pin and the prompt hook blocked on its
  exit 126 even with a working okl on PATH. When a command fails to start within 2 s, the
  prompt hook now moves on to the next layer (OKL_BIN, then the pin, then PATH, then
  python3 -m okl), never running a command that already failed, and adds the one it
  passed over, with its fix, to the line you see. A command that ran and then exited 127,
  such as a docker run whose image lacks okl, is not run again: at three layers it could
  have taken the hook past Claude Code's 30 s limit. A working pin costs nothing extra;
  with nothing else to run, the block names the pin and says to re-run okl init.

• A 200 that is not JSON is no answer, not a refusal (okl review R10). Something other
  than okl can answer at the service's address with a web page: a proxy's sign-in page,
  or a web app on the port OKL_SERVICE_URL names. The client's JSON parse failed with a
  ValueError, which okl check reported as "OKL REFUSED THE CHECK" and the MCP tools as
  a refusal. It is now reported as unreachable, showing the start of what came back, and
  after a write it says MAYBE, since the service behind the page may have stored it.

• The MCP okl_record tool says MAYBE RECORDED when a write may have landed. It caught
  only ValueError, so a shared service that took the lesson and never answered reached
  the agent as an opaque tool error, and one that could not be reached did too.
  okl_update and okl_retire already said MAYBE. It now says the service may have
  stored the lesson, to look with okl_search before recording it again, and that
  recording it again with the same id is safe; a refused connection says NOT RECORDED.

• The A/B harness no longer counts a sample with no code as a clean run (#164). The judge
  now says whether the submission implemented the task at all. A plan, a description, a
  question or a refusal is unevaluable: a failure, kept out of both arms' denominators and
  counted toward the usability bar, with the code's length and an excerpt so the verdict
  can be audited. §4j's briefed idor_endpoint sample was a plan the harness scored clean.
  Receipts also record the model each alias resolved to (review item R12), and the harness
  refuses a judge that resolves to the generator's model under a different command string.
  REPORT §4k pre-registers the change of instrument.