PACKAGE: __PACKAGE__ — external ROUND __ROUND__
SEALED:  __TS__ (UTC)
COMMIT:  __COMMIT_FULL__   (the same commit COLLECTED.txt names)
MEASURED: __MEASURED__

0004 is not a candidate: approved at round 2, frozen on W1-W8.

BOTH ROUND-8 BLOCKERS ARE FOLDED, and both are the same disease at different
depths: a number or a status maintained BY HAND beside one produced by a
machine.

  R8-1 — `raised` was read with `.get(..., [])`, so FORGETTING the field was
  indistinguishable from declaring no findings: you injected a verdict naming
  R99-1 with no `raised` and the gate reported nothing. A returned verdict must
  now DECLARE, `raised=[]` included, and omission raises. The displayed count
  comes from `raised` rather than the legacy `findings=`, which disagrees in
  four rows — that field is now documented as what the round REPORT stated
  (historically blocking-only, or grouped differently for a coupled round)
  rather than silently contradicting the column above it. Two regressions: a
  missing field, and the rendered count against the structure.

  R8-2 — four package claims were typed. The harness line said 17/17 against
  an 18/18 executable; "All 31" evidence commands described a 33-row ledger of
  which the test runs 32; COLLECTED claimed the suite was measured with itself
  present when the sealer measures BEFORE building it; and the inventory said
  git-dependent tests skipped for want of `.git` when sealing measures the git
  checkout and the sealed reconciliation shows no such skips.

  All four are now produced rather than asserted: the sealer RUNS both
  harnesses and substitutes their output, derives the evidence split from the
  ledger, and the two-phase workflow is described as what it is.

ROUND 10 FOUND THREE, AND ALL THREE WERE THE SAME SHAPE ONE MORE TIME: a
description maintained apart from the thing described.

  R10-1 — the REVIEWER GUIDE said measurement happens in a separate extracted
  archive with no `.git`, so the measured line "already reflects the extracted
  shape a reviewer runs". The sealer measures the author's committed checkout,
  and COLLECTED said so correctly — two carriers, two answers, for ten rounds,
  while our withdrawn-claim guard read only COLLECTED and the manifest. The
  guide ships IN the archive; the guard reads it now.

  There is ONE canonical protocol and it is the one the code implements: the
  author's committed git checkout, measured before COLLECTED is built. Your run
  WILL differ — the git-dependent tests execute for us and skip for you, which
  is the largest single term in the delta — and the skip inventory is what
  makes that reconcile. Compare the decomposition, not the total.

  The guide also promised an exact command, environment, pytest version and
  node count that COLLECTED never carried. They are GENERATED now: interpreter
  path, python build, pytest version, SQLite version, cwd, and the collection
  line, measured during sealing.

  R10-2 — the extraction registry bound LABELS, not behaviour. You replaced
  verify_collected's command with `python -c pass`, kept the label, and the
  package was accepted; the advertised `render_operation.py --check` also
  omitted `--check` from its argv, harmless only because checking was the
  default. The regression pins exact normalised ARGV, `--check` is a real flag,
  and your no-op substitution is now an adversarial test that must fail.

  R10-3 — a plain `tar -xzf` could not open the package. `git archive` writes
  root/root; the three appended carriers carried the sealing user's uid/gid, so
  extraction exited 2 wherever uid 1000 cannot be restored and you needed
  --no-same-owner. Appended members are normalised to root/root 0644, and the
  sealer RUNS a plain extraction as a gate — the ordinary command is the one
  that must work.

STILL OPEN: the store-side R19 binding remains enforcement-BEFORE-
implementation. It becomes behavioural the day the store code exists, which
needs 0022 accepted.
