Event Schedule Integrity
Use the event schedule integrity report before a time-zone runtime upgrade, while investigating a suspicious event, or when validating a migrated or restored event dataset. The command reads active event schedule fields and emits sanitized JSON. It does not repair, rewrite, or publish an event.
Run The Report
Section titled “Run The Report”Run the command from a backend environment configured for the database you intend to inspect:
pnpm wavemap -- maintenance event schedule-integrity reportNarrow the report to one public event identity when investigating a known record:
pnpm wavemap -- maintenance event schedule-integrity report --event-public-id WmEvtSeed001Confirm the selected environment and database before running any adjacent mutation command. This report itself is read- only, but a shell configured for a shared or retained database still deserves the same target awareness as other operator work. Use a disposable DB-backed test database for migration/seed proof; do not reset a retained database merely to run this report.
Report Shape
Section titled “Report Shape”The versioned JSON contains:
- Generation time and optional public-event scope.
- Node, ICU, and time-zone-data runtime versions.
- Counts by integrity state, schedule completeness, repair disposition, and stable issue code.
- Public event identity, revision, schedule-only evidence, and any update-compatible candidates.
It intentionally excludes event names, descriptions, relationships, internal IDs, users, credentials, and request bodies. Store raw reports with the same care as other operational evidence; publish only reviewed, durable conclusions.
Interpret Integrity State
Section titled “Interpret Integrity State”| State | Meaning | Default Response |
|---|---|---|
valid | Stored projections agree with the authored schedule under this runtime. | No repair. |
projection-drift | Current resolution does not match at least one stored exact projection. | Review the evidence and candidate. |
unresolvable | The current runtime cannot resolve the authored values safely. | Manual review; do not invent a projection. |
structural-inconsistency | Stored authored and exact fields violate the schedule shape. | Investigate how the row bypassed ordinary constraints. |
Completeness is not an error state. Date-only, date-range, timed-start, timed-range, and mixed-precision schedules may all be valid.
Repair Boundary
Section titled “Repair Boundary”The report can emit a candidate containing the normal authored schedule request and expectedRevision. A candidate is
review material only.
To apply an approved correction:
- Confirm the intended organizer-local date, time, reference zone, and any fold choice from a trustworthy source.
- Confirm that the event revision still matches the candidate.
- Submit the candidate through the protected event update capability as an authorized admin.
- Re-run the narrow integrity report for that public event ID.
- Confirm relationships, revision, and provenance remain correct through the normal application or DB-backed proof.
Never update exact projection columns directly from the report. The normal mutation owns resolution, authorization, transaction rollback, revision conflict detection, update provenance, and relationship preservation. A stale candidate must fail rather than overwrite an intervening edit.
Runtime Upgrade Posture
Section titled “Runtime Upgrade Posture”The report records runtime provenance so two scans can be compared. A changed result does not, by itself, prove that an ICU or IANA time-zone update caused the drift; persisted evidence cannot establish that causal history.
For a runtime or dependency upgrade that can change time-zone resolution:
- Run the integrity report before the change and retain private evidence.
- Apply the upgrade in the normal reviewed dependency workflow.
- Run the report against the same representative data afterward.
- Reconcile every new mismatch before presenting the upgrade as schedule-safe.
Disposable Verification
Section titled “Disposable Verification”The CI-owned DB-backed inventory creates a fresh PostgreSQL database, applies migrations and seeds, and proves the active fixture set scans cleanly:
pnpm check:db-backedThat proof is separate from a report against retained Development data and is not a backup or restore guarantee.