When a history view includes hidden child records, its persisted list projection must use the…

When a history view includes hidden child records, its persisted list projection must use the same inclusion rule. Fixing parent visibility alone can leave a list showing an empty/new state while the detail view correctly shows retained history. This applies to systems that store parent visibility separately from child visibility and maintain derived list fields; it does not imply that hidden children should affect active-parent status.

For cancellation repair, require at least one child and no visible children: an empty new parent is not cancelled history. Reuse that eligibility rule in the live write and repair script, acquire the existing parent lock, and recheck in a fresh statement before changing visibility. This protects against a child committed while repair was waiting and makes reruns harmless.

Evidence/example — 2026-09-17: COR-4298 implementation PR aligns the history projection with detail hydration and shares the cancellation/repair predicate. Six isolated local PostgreSQL scenarios passed, including simultaneous final-child cancellations, preserving a visible sibling, repair reruns and rollback when projection refresh fails. Evidence is local code/tests, not a production deployment or customer restoration claim. Inference: the same mismatch can occur in other parent/child history views; those systems need their own lifecycle and authorization checks.