Open items

After the second pass, every item that was open here has been reproduced or refuted. Confirmed defects moved to Findings (sections 10–24). What remains are two documented risks:

Item	Where	Status
With a very small `PqWorkspace`, below the total length of the relations (for our groups below about 1000 words), `setup` and the reading of relations write a few words past the end of the workspace before, or instead of, reporting `Ran out of space`. Plain builds stop with that message in every case we tried; only AddressSanitizer sees the writes	`src/setup.c:75`, `src/pretty_filter.c:195, 420`	verified (ASan); harmless in practice; patch kept, no PR
`image_of_generator` writes the image of a generator into the workspace without a space check. Its length is bounded by $(p-1)^2 \cdot \mathrm{lastg}^2$, more than the nearest check reserves ($7 \cdot \mathrm{lastg} + 4$)	`src/stabiliser.c:227–281`	measured: at most 20 words written, at least 94 to spare, also at the smallest workspace that suffices; documented risk

Checked and refuted

A non-homogeneous relation is reported and ignored, and the computation goes on (src/echelon.c:52–60). On pq's own paths a relation can be non-homogeneous only if the previous class is already wrong; a probe build saw no case in the test suite or the SmallGroups check. Where a user hands in an arbitrary word (PqCollect, PqEchelonise), ignoring it is the right response: a relation that fails in a lower class cannot be imposed in class $c$. Only the report is weak: the message appears from InfoANUPQ level 4, and PqEchelonise returns fail.
One death of pq in the standard presentation check of order 64. Not a defect: pq was killed from outside. At that second the audit itself ran pkill -f ".../pq -G", which matches every pq started by GAP from that build. Six reruns of order 64 (6408 calls of PqStandardPresentation; master, correctness, master under ASan) had no failure. The first run of order 128 died the same way.