Research audit handoffs of 2026-09-20 to 2026-09-25 have no record here: catalogue, what #31 repairs, what remains

Start by reading the handoff document ANSWERS_TO_IMPLEMENTER and the full audit records for the listed open findings, checking each against the current master and repairs in PR #31. The catalogue names the remaining timestamp, lineage, store, transport, and configuration boundaries; group related findings into their planned repairs and update this issue as each is addressed. Done when every REPAIR REQUIRED finding has an implementation or a recorded reason it will not be adopted.

Found by the review of 2026-09-25.

The finding

Since 2026-09-20 the research process has been running bounded static audits of this repository at master a8726f5, about one per hour, and recording each with a verdict and a named regression boundary. Between 2026-09-20 and today it produced roughly fifty of them, some forty with the verdict REPAIR REQUIRED. By its own rules it records them on Drive (the handoff document ANSWERS_TO_IMPLEMENTER and the owner's mirror folder) and does not open issues for members of a family it considers already tracked, which for most of them is #12. The result is that the repository had no record of them: no issue names them, the roadmap's standing obligation ("research finding: adopt it, or record why not, before continuing queued work") could not fire, and PR #31 claimed to adopt every delivered judgement while about forty findings sat next to it unread.

This issue is the catalogue, so the obligation can be worked from here. PR #31 repairs the first group; the rest are open.

Repaired in #31

Open, with the boundary each names

Timestamp and chronology family (runs 382 to 395). The researcher's cross-run conclusion is that timestamp authority is fragmented across parser, formatter, adapter, normalization and classifier, and that one strict instant-admission layer should replace independent checks. That is the right shape for the repair and it is not a one-evening change, so it is its own PR:

Verifier and lineage family (runs 337 to 348). These ask verification to dispatch on the exact stored lineage before interpreting a member, and to validate each member structurally under that lineage: PV-AUDIT-BUNDLE-LINEAGE-001, PV-AUDIT-MANIFEST-SHAPE-001, PV-AUDIT-MANIFEST-PREIMAGE-BINDING-001 (the renderer_version replay-skip bypass is concrete), PV-AUDIT-OBSERVATION-LINEAGE-001 (saved observations are not dispatched on schema / observation_contract_version), PV-AUDIT-VECTOR-LINEAGE-001, PV-AUDIT-SNAPSHOT-LINEAGE-001 (Vital order and uniqueness not enforced), PV-AUDIT-DEMAND-LINEAGE-001, PV-AUDIT-OBSERVATIONS-MEMBER-LINEAGE-001, PV-AUDIT-SEMANTIC-CONFIG-BINDING-001, PV-AUDIT-RECEIPT-DIGEST-BINDING-001, PV-AUDIT-SNAPSHOT-MANIFEST-BINDING-001, PV-AUDIT-GAUGE-SNAPSHOT-BINDING-001. Several overlap #12 finding 4, which 0.1.9 repaired in part (the metadata binding); the lineage dispatch itself is the accepted compatibility policy's job (PV-COMPAT-002, see the Phase B/C issue), so this family is best done together with that adoption rather than piecemeal.

Store and transport, remaining: PV-AUDIT-HISTORYSTORE-CONCURRENCY-001 (no same-project writer serialization; concurrent commits can race on latest.staging), PV-AUDIT-HISTORYSTORE-RENAME-RECOVERY-001 (relocation happens before the new bundle, copy and index are complete; a failure mid-way leaves a moved directory), PV-AUDIT-GITHUB-PAGINATION-LINK-001 (an exact-cap full final page is reported PARTIAL although the absence of rel="next" proves completeness; GH-PAGINATION-LINK-01..06), PV-AUDIT-RENDER-OBSERVABILITY-TRUTHFULNESS-001 (the observability section of the report), PV-AUDIT-REGISTER-SHAPE-001 beyond the state field (target-id pattern, duplicate members in register JSON, full schema validation), PV-AUDIT-CONFIG-SHAPE-001 beyond the two concrete mismatches (complete schema validation before defaults).

Produced today (runs 397 to 403), read only through their one-line handoffs, so each needs reading in full against the new head before it is worked: PV-AUDIT-GITHUB-RESPONSE-SIZE-001 (the transport must bound raw response bytes from the stream before parsing, on 2xx and error paths alike, and surface overflow as ERROR / RESPONSE_TOO_LARGE; GH-RESPONSE-SIZE-01..08), PV-AUDIT-CLI-PROVIDER-ENDPOINT-001 (ENDPOINT-BINDING-01..08), PV-AUDIT-GITHUB-CACHE-CONTEXT-001 (cache entries must be namespaced by the normalized API base and representation context before configurable endpoints exist; GH-CACHE-CONTEXT-01..08), PV-AUDIT-GITHUB-BASE-TLS-001 (fail-closed validation of a configured provider base before transport dispatch; GH-BASE-TLS-01..08), PV-AUDIT-GITHUB-CHECK-SUITES-PAYLOAD-001 and PV-AUDIT-GITHUB-PAGINATED-ROW-SHAPE-001 (the check-suite and per-row shapes #31 now validates; to be checked case by case against GH-CHECK-SUITES-PAYLOAD-01..08), and PV-AUDIT-TARGET-MARKER-SYNTAX-001 (the Target: marker must be parsed as a standalone configured syntax, not as text embedded in a larger token such as SubTarget: B1; LINK-MARKER-01..08; it also assumes the state-neutral linkage of the Direction repair tracked in #33).

Verified non-findings, for the record: PV-AUDIT-STORE-IMMUTABLE-COLLISION-001, PV-AUDIT-GITHUB-PAGINATION-STOP-001, PV-AUDIT-CANONICAL-NUMBERS-001, PV-AUDIT-REPORT-RENDER-BINDING-001.

Two process observations

1. The research side's deduplication rule ("same family as #12, no new issue") makes #12 the nominal home of some thirty findings that nobody reading #12 can see. The obligation in the roadmap is only workable if every REPAIR REQUIRED unit has a line somewhere in this repository. Proposal: this issue is that place until each family has its own PR, and the implementation side (not the researcher) keeps it current when it reads the handoff document; a session that starts here reads ANSWERS_TO_IMPLEMENTER first, as the memory of this project already says it should.
2. The owner's Drive mirror has one copy error: the document titled PV-AUDIT-FORGE-WINDOW-UPPER-BOUND-001 holds the text of PV-AUDIT-CANONICAL-DECIMAL-001. The research status report for runs 385 to 396 already notes "an accidentally copied 03 - Work document remains non-authoritative"; the mirror copy should be replaced from the canonical one before anyone implements FORGE-WINDOW-01..08 from it.