Three defects in the branch that exists to prove the committed artifact is not
trusted. It has never once run to completion.

1. NO --target-avm-version. The contract calls op.falcon_verify, an AVM 12
   opcode; puyapy's default target is lower, so compilation FAILS outright:

     assert op.falcon_verify(m, falcon_sig.native, pubkey), ...
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   contracts/requirements.txt documented the correct invocation the whole time
   ("--target-avm-version 12"). The flag is now DERIVED from the committed
   artifact's own `#pragma version` line rather than hard-coded, because a
   literal could drift from the artifact it is meant to reproduce.

2. THE FAILURE HAD NO REASON. puyapy writes diagnostics to STDOUT; the handler
   read only exc.stderr. Measured on a failing compile: stderr 0 bytes, stdout
   848. So an operator hitting (1) saw literally "puya failed:" and nothing
   else. Now prefers stdout, falls back to stderr, and says which exit code.

3. IT OVERWROTE THE ARTIFACTS IT WAS VERIFYING. recompile_from_source was
   passed args.teal.parent -- contracts/out/ -- so running the verifier
   rewrote five tracked files as a side effect: both .teal, both .puya.map and
   the .arc56.json. A verifier that mutates its subject cannot be run on a
   clean tree, and its second run compares the output against itself. Now
   compiles into a TemporaryDirectory.

4. IT COMPARED TEAL TEXT, NOT BYTECODE, and would have reported "stale" on a
   contract that is perfectly reproducible. Measured against puyapy 5.8.1 /
   algorand-python 3.5.0 at AVM 12: committed TEAL 17,559 bytes, fresh compile
   18,179 -- 620 apart, and NOT a line-ending artifact (LF-normalising both
   does not close it). Yet both assemble to the same 667-byte program,
   sha256 308cfa75. The difference is comment and source-map formatting from a
   different compiler build.

   Bytecode is what deploys and what the drift check further down compares, so
   it is the only comparison that answers the question. Text comparison made
   the check fail on compiler-version noise while claiming source and artifact
   disagreed -- a false alarm in the one tool whose credibility depends on its
   alarms being real.

Verified end to end, first time this branch has completed:

  [0] ok    committed TEAL assembles identically to a fresh compile
  [2] expected bytecode 667 B  112fcad3...
  [3] actual   bytecode 660 B  d24d9071...
  DRIFT - application 763809096 is NOT running the committed source.

...and `git status contracts/out/` is clean afterwards.

The drift at [3] is the real, already-filed finding (TCE-01/TCE-35). What
changed is that [0] now runs and is trustworthy.

Two findings from the flagship review, both of the kind an auditor hits on day
one.

1. VERSION DRIFT. Three numbers disagreed and nothing compared them:

     sdk/pyproject.toml              version     = "0.2.2"
     sdk/src/trelyan_pq/__init__.py  __version__ = "0.1.0"   <- hand-written
     Dockerfile.verify               trelyan-pq ==  0.1.0

   Only the middle one was a defect, and establishing that took checking PyPI
   rather than assuming. Anyone installing 0.2.2 got a package reporting 0.1.0.

   __version__ is now read from installed distribution metadata, so
   pyproject.toml is the single source of truth and the two cannot drift by
   hand-editing.

   The Dockerfile pin is CORRECT: PyPI has exactly one published release,
   0.1.0, and a checker that installs from PyPI can only pin what exists. My
   first version of the test asserted the pin must equal pyproject -- an
   assertion that would have forced pinning a nonexistent release and broken
   the checker to satisfy a test. Corrected, and recorded in the test file,
   because it is the same shape of error the register documents: a check that
   looks principled while encoding a false premise.

   Three tests: reported version matches pyproject (catches a stale install,
   which the derivation alone cannot); __version__ is not a hand-written
   literal (catches someone "fixing" a future mismatch by re-hardcoding); and
   the Dockerfile divergence must be acknowledged in writing while it lasts.
   Verified both ways -- the first test failed against a stale 0.1.0 install
   and passes after `pip install -e .` reports 0.2.2.

2. FOUR CITED DOCUMENTS DO NOT EXIST: AUDITOR_HANDOFF.md,
   AUDIT_READINESS_PACK.md, CELL_MINT_SPEC.md and
   GOVERNANCE_AND_LIFECYCLE_POLICY.md. AUDIT_READINESS.md told an auditor to
   "read that for the proof-of-invariants ask" and listed two of them in its
   evidence table.

   Checked properly first: six other bare filenames flagged by the same sweep
   (falcon.py, seal.py, message.py, verify_trelyan.py and the two contracts
   memos) DO exist deeper in the tree and are ordinary prose references, not
   broken links. deterministic.c is the pinned upstream file CI fetches and is
   correctly not committed.

   Each citation now says the document does not exist and points at what does
   carry that content.

   The one that mattered: "No rotation / loss is irrecoverable by design;
   disclosed to holders in GOVERNANCE_AND_LIFECYCLE_POLICY.md" asserted a
   DISCLOSURE HAD BEEN MADE to cell holders via a document that was never
   written. Removed. Irrecoverability is real and holders should be told;
   writing that policy is outstanding work, not something this file can point
   at.

SDK suite 59 -> 62 passed.

v1.5.0

perf(ui): load validator and pool state in bulk, persist the query cache

TCE-23's fix was incomplete, and this is my own gate. release.yml gained a
`test` job so a tag could not produce a signed, SLSA-attested artifact without
tests running. It runs `pytest tests` with a floor of 15 executed -- but with
no `env:` block and no Falcon library build step.

So on a release tag every lib-gated test SKIPS, and the floor is satisfied
entirely by tests that touch no cryptography. Measured on this machine:

  tests executed (old floor of 15): 59  -> OLD gate PASSES, signs the release
  crypto tests skipped:             12

A gate that passes while the thing it exists to check did not run is the exact
defect class this repo's register documents, and it was sitting in the fix for
a previous instance of it.

Now mirrors ci.yml's signature-kat job: fetch the pinned Falcon source
(ce15e75, the commit go-algorand vendors), assert the pinned-build digest and
the emulated FP backend, build the shared library, then run the suite with
TRELYAN_REQUIRE_KAT=1 and grep the log for the skip marker.

Keeps the 15-test floor AND adds the skip check, because they catch different
things: the floor catches a suite that silently shrank, the grep catches a
suite that ran without the crypto. The floor alone was satisfied by a run in
which every Falcon test skipped, which is how this survived.

A release must not be held to a weaker standard than a pull request.

Verified both directions on a lib-less run: 59 executed clears the old floor,
12 skip markers trip the new guard.

HIGH. `falcon_det1024_verify_compressed` takes NO pubkey length parameter:
deterministic.c calls falcon_verify(..., pubkey, FALCON_DET1024_PUBKEY_SIZE,
...), so it reads exactly 1793 bytes from that pointer regardless of what the
caller allocated. `sig` and `message` are length-delimited and bounded; pubkey
alone was not.

FalconDet1024.verify() passed pubkey straight through as a bare c_char_p with
no check, so a shorter buffer read up to 1729 bytes past the end. Reachable
from the shipped public API -- trelyan_pq.verify is exported from __init__ --
so a verifier reading a pubkey from an arbitrary box or file could crash, or
compute a verdict partly from unrelated adjacent heap memory.

Proved with a guard page (two pages, only the first committed, payload flush
against the boundary):

  full 1793-byte pubkey -> returns cleanly, reads exactly 1793
  1792-byte pubkey      -> ACCESS VIOLATION at the first byte past the buffer
  64-byte pubkey        -> ACCESS VIOLATION

The one-byte-short case is the one that matters: it is the realistic
truncation. Reaching it needs no valid signature -- junk bytes with the right
two header values get there.

The asymmetry is what marks it an oversight rather than a decision: sign() has
always checked len(privkey) != PRIVKEY_SIZE. verify() checked nothing.

WHY NOTHING CAUGHT IT, which is the part worth keeping:

  * tests/fuzz/fuzz_falcon_verify.cc (C/ASan, 13.8M execs) DOCUMENTS this exact
    invariant and honours it -- it always hands the function a fixed 1793-byte
    buffer, and its comment calls a smaller one "a caller-side over-read -- a
    harness bug, not a finding". Correct, and it means that harness could never
    surface this by construction.
  * tests/fuzz/fuzz_encoding_atheris.py DID feed short pubkeys and asserted
    verify() "must return False, not raise" -- an assertion the code could not
    satisfy, because it crashed instead. That file is referenced by no
    workflow, so it has never run.
  * No test varied pubkey length; the KAT and fuzz suites vary the signature
    only, always with a full-size key.

The invariant was written down in one file, violated in another, and the
harness that would have caught it was never wired up.

Fixed in BOTH copies. contracts/falcon_det1024.py is the one deploy_testnet.py
signs real TestNet inscriptions with, and fixing only the SDK is exactly how
TCE-03's cwd hijack survived its first fix.

Raises rather than returning False, matching sign(): a mis-sized key is a
caller error, not a failed verification, and returning False would let a
truncated key read as "signature invalid". The Atheris harness's contract is
corrected to expect that, with the reason recorded inline.

9 regression tests, none needing the C library so they run everywhere.
Mutation-proved: removing either guard fails all 9. SDK suite 50 -> 59 passed,
19 skipped.

Security impact: closes a memory-safety defect reachable from the public API of
an audit-bound crypto SDK. No protocol, wire-format or on-chain change; the
contract's own ABI already pins committed_pubkey to 1793 bytes, so on-chain
state was never the exposure -- the off-chain verifier path was.