Event Series Integrity

Use these manual reports to inspect Event Series and Edition discrepancies without changing application state. Both commands run in a backend environment configured for the database and media provider you intend to inspect. They emit versioned, deterministic, sanitized JSON and contain no acknowledgement, cleanup, or repair path.

These commands are backend diagnostics. They do not extend the existing deployed-dev media-discrepancy orchestration, schedule themselves, or authorize an adjacent mutation.

Confirm The Target

Before running either report:

Confirm the selected application environment and database.
For media inspection, confirm the provider, storage location, and prefix resolved by runtime configuration.
Prefer a narrow public-ID scope while investigating one known record.
Keep raw output private; it can contain public entity identities and storage locator evidence.

The reports are read-only, but a shell configured for a retained database or shared storage target deserves the same target awareness as any operator command.

Inspect Event Series Media

Inspect all Event Series media in the configured storage scope:

pnpm wavemap -- maintenance media discrepancies report --entity event-series --json

Narrow the database and object-prefix scope to one Series:

pnpm wavemap -- maintenance media discrepancies report \
  --entity event-series \
  --event-series-public-id WmSeries0001 \
  --json

Inspect all Edition media:

pnpm wavemap -- maintenance media discrepancies report --entity event-series-edition --json

Narrow to one nested Edition. Both public identities are required so the scope cannot detach an Edition from its parent:

pnpm wavemap -- maintenance media discrepancies report \
  --entity event-series-edition \
  --event-series-public-id WmSeries0002 \
  --event-series-edition-public-id WmEdition001 \
  --json

The command also accepts explicit --provider, --location, and --prefix overrides for a deliberate storage investigation. Do not use them casually: an override changes which provider inventory is compared with the selected database rows. The parser rejects unknown flags, cross-entity identity flags, incomplete Edition scope, and mocked storage inspection.

Media Report Shape

The document contains:

schemaVersion, generatedAt, and the selected entity kind.
Provider, storage-location, and prefix scope plus optional public Series/Edition identity.
Database-row and provider-object inspection counts.
Totals by stable discrepancy kind.
Deterministically ordered discrepancy evidence using public media and owner identity where applicable.

Series and Edition media accept fully external legacy URLs when no provider locator was ever claimed. Partial locator metadata remains a discrepancy because the application cannot resolve or clean it up reliably.

Discrepancy Kind	Meaning
`db-record-expects-missing-provider-object`	A persisted locator points to an object absent from the provider listing.
`provider-object-missing-db-record`	A listed provider object has no matching media row in the selected scope.
`canonical-present-thumbnail-missing`	The canonical object exists but its expected thumbnail does not.
`thumbnail-present-canonical-missing`	The thumbnail exists but its canonical object does not.
`stored-url-disagrees-with-locator`	The stored render URL conflicts with the canonical locator projection.
`locator-metadata-missing`	A provider-backed row has incomplete locator metadata.

Counts are telemetry, not automatic failure or cleanup authority. Confirm the underlying row and object history before planning any mutation.

Inspect Edition Program Integrity

Scan every active Edition beneath active Series:

pnpm wavemap -- maintenance event-series edition-integrity report

Narrow to one Series:

pnpm wavemap -- maintenance event-series edition-integrity report \
  --event-series-public-id WmSeries0002

Narrow to one nested Edition:

pnpm wavemap -- maintenance event-series edition-integrity report \
  --event-series-public-id WmSeries0002 \
  --event-series-edition-public-id WmEdition001

An Edition ID without its parent Series ID is rejected. Inactive Series and Editions are intentionally outside the report scope.

Edition Report Shape

The document contains:

schemaVersion, generatedAt, and the active-only scope declaration.
Optional public Series and Edition scope.
Edition and finding counts, including counts by stable finding code.
Deterministically ordered records with public Series/Edition identity, Edition revision, and structured findings.
Public Event or Venue identity and revisions only when required to explain a finding.

It excludes internal IDs, names, descriptions, users, credentials, raw request bodies, and a repair candidate.

Finding Code	Meaning
`program-event-partially-outside-window`	Part of an Event schedule falls outside the Edition window.
`program-event-outside-window`	The Event schedule does not overlap the Edition window.
`program-event-uses-undeclared-venue`	A program Event uses a Venue absent from the Edition’s official set.
`official-venue-unused-by-program`	An official Venue is not used by the current program.
`program-event-attendance-scope-mismatch`	Event attendance is outside the Edition’s derived physical/digital scope.

Window findings state whether comparison used exact instants or conservative calendar boundaries. TBA windows do not manufacture a temporal comparison.

Response And Repair Boundary

Treat every finding as a review prompt:

Confirm organizer intent from a trustworthy source.
Identify which entity owns the incorrect claim: Edition window, official Venues, attendance link, or Event truth.
Edit that entity through its normal protected authoring capability with the current revision.
Re-run the narrow report.
Confirm the finding is resolved without erasing intentional satellite or exception behavior.

Do not update database fields directly from report output. Do not delete provider objects or rows based on discrepancy counts alone. Any future acknowledgement, cleanup, or repair command requires its own authorization, preview, safety guards, and audit posture.

Migration And Reset Boundary

Migration proof distinguishes three different claims:

Fresh schema proof applies the complete journal to a newly empty disposable test database without seed logic.
Retained migration proof starts from the exact older lineage, preserves valid data, and proves ambiguous legacy states fail closed without partial cutover.
Reset-safety proof allows destructive reset only for exact disposable DB-backed, local-development, or deployed- development targets.

Ordinary migration owns no reset call. Never use a disposable development reset to resolve a staging or production migration problem. Production migration, rollback, retained-row repair, cleanup, and deployment sequencing require a separately reviewed operational plan and backups appropriate to that environment.