Indexer canonical-schema compatibility#

This is a migration-contract inventory, not a deployment signoff or blanket compatibility claim.

Commit fa5f8e8e8 replaced the legacy 001–070 migration lineage with 001_canonical_schema.sql; migration 004 restores the active runtime relations in an idempotent final-state compatibility schema. The current canonical migration chain is 001–029. Migrations 001–003 create the canonical chain/event projections plus the deployment-scoped external-market, Reclaim, maker-credit, and pre-creation-manifest tables listed in apps/indexer/docs/database-schema.md. Migration 004 (004_legacy_runtime_compatibility.sql) supplies the legacy runtime relations still queried by registered routes and scheduled jobs; it is source-reviewed and covered by schema-validation tests, but still requires a fresh-database and staging-snapshot rehearsal before launch.

Migrations 005–029 incrementally extend that foundation. Migration 029 makes processed_transactions and failed_webhooks program-scoped and adds transaction_projection_stages, the durable per-program projection-completion ledger. Startup schema validation inventories those migration-029 columns against migration 029 rather than attributing them to the migration-004 legacy compatibility surface.

The following registered route modules still issue SQL against relations owned by migration 004 rather than the canonical projection schema:

achievements, activity, admin, alerts, attestation, challenges, compliance, creators, exchange, fee-config, handles, leaderboard, legacy markets, notifications, orderbook, orders, positions, responsible-trading, share, stats, status, legacy trades, transaction builders, user, and watchlist.

The following scheduled jobs still issue SQL against migration-004 runtime relations:

achievement processing, price-alert checking, invariant watchdog, leaderboard snapshots, pull lifecycle metrics, recorder reconciliation, treasury-shard reconciliation, stats aggregation, and streak updates.

Examples of migration-004 relations include markets, orders, positions, trades, users, fee_config_history, creator_fee_claims, referrer_earnings_accounts, price_alerts, watchlists, invariant_watchdog_runs, and the recorder-reconciliation tables.

The canonical-schema-compatible public slice is the external-market/Reclaim router backed by deployment_registry, external_markets, external_market_sources, external_lifecycle_claims, reclaim_witness_epochs, reclaim_create_manifests, maker_rebate_events, and the canonical *_projection tables. A fresh 001–029 database has the source-level relation contract for the full registered route/job surface, but it must not be called production compatible until the migration is rehearsed against an empty database and a staging snapshot. Documentation gates and unit tests do not substitute for that rehearsal.

Indexer canonical-schema compatibility#

This is a migration-contract inventory, not a deployment signoff or blanket compatibility claim.

The following registered route modules still issue SQL against relations owned by migration 004 rather than the canonical projection schema:

achievements, activity, admin, alerts, attestation, challenges, compliance, creators, exchange, fee-config, handles, leaderboard, legacy markets, notifications, orderbook, orders, positions, responsible-trading, share, stats, status, legacy trades, transaction builders, user, and watchlist.

The following scheduled jobs still issue SQL against migration-004 runtime relations:

achievement processing, price-alert checking, invariant watchdog, leaderboard snapshots, pull lifecycle metrics, recorder reconciliation, treasury-shard reconciliation, stats aggregation, and streak updates.