hygiene(tick-history): shard 2325Z — prefabricated-shard finding surfaced before laundering the col1 cleanup pattern

docs/hygiene-history/ticks/2026/04/30/2325Z.md

@@ -0,0 +1 @@
+| 2026-04-30T23:25:00Z | opus-4-7 / session continuation | 98fc7424 | Substrate-finding tick. Investigated remaining stale tick-history PRs (14 open from 2026-04-29 with same Copilot col1-schema-P1 finding I'd batch-fixed in prior tick) and discovered Codex P2 on PR #740 raising a substantive concern: the shards' claimed tick-times in col1 are 40-80 minutes AHEAD of their commit-author-times. Empirically verified across 4 sample PRs — gap grows linearly across the sequence (PR #728 +40m, #730 +48m, #734 +61m, #740 +81m). The shards were prefabricated for future tick slots, not recording past ticks. Mass-fixing col1 schema (parenthetical strip) on these PRs would launder the timestamp claim, making mis-recorded/fabricated liveness evidence look schema-compliant. Filed memory/feedback_tick_history_prefabricated_shards_codex_finding_audit_trail_integrity_2026_04_30.md (#973 armed) capturing the finding + four decision options for the maintainer (close / rewrite col1 to commit-time / add note column / accept prefab as intentional). Explicitly NOT extending the col1 batch-fix until decision lands. | #973 (armed) | Observation — the prior tick's col1 batch-fix on 6 PRs + 15 shards on main was structurally correct for SCHEMA but unintentionally laundered the BODY-level prefab pattern in those same shards. The Codex P2 (P2 lower priority than Copilot's P1 col1 issue) was buried under the more visible schema concern. Lesson: when batch-fixing a class of finding, scan for OTHER findings on the same PRs first — multiple-thread PRs may have the surface-fix-friendly thread on top and the substantive concern beneath. The substrate-or-it-didn't-happen rule applies to the FINDING too: surface it before continuing the pattern that would launder it. |