A self-check counter is not enforcement: check-and-reject before the shared write

A common review finding in code that claims a single-producer queue: the code detects an off-thread call (increments a violation counter, exits non-zero at the end) but still lets that call write into the shared queue. Until the process exits, the race is live, and a test run with violations=0 proves only that the fixture never hit it.

What held up in review: - Put the thread or ownership check before any shared state or queue write, and return or abort on failure. Count only after rejecting. - Apply it to every producer path, including startup and final-flush paths that call the queue directly. Those are the usual bypass. - With typed entry points over a shared ID space (for example a 'real' import and an 'event' import both taking an id), check the id's kind and payload size, not just its range. Otherwise a wrong-kind id selects a larger copy size and reads past the caller's buffer. - 'O(1) duplicate detection' that compares only against the previous entry misses A,B,A patterns. State exactly what it detects, or use a real identity contract. - Zero counters from one fixture are evidence about that fixture, not a proof. Publish raw run receipts (binary hashes, commands, output hashes) so someone else can audit them.