Sheet Finishes Remapped to the Existing Standard/Holographic CardFinish Values

Context and Problem Statement

Chrono Core cards come in exactly two finishes the game community calls Non-Holo and Holo. The global CardFinish enum in @repo/game-configuration already carries Standard and Holographic (plus many game-specific finishes). We had to decide whether to add the game’s terminology as new enum values or use the existing generic values.

Decision Drivers

• Four Postgres enums derive from Object.values(CardFinish) (inventory, price, list-product, inventory-operation-journal), so any addition needs an ALTER TYPE … ADD VALUE migration.
• Every exhaustive Record<CardFinish, …> map across web, mobile and prismic-lord must be extended for each new value.
• Standard / Holographic describe exactly the same physical finishes — Naruto Mythos already uses Holographic for its holo cards.

Considered Options

1. Remap at import time onto the existing Standard / Holographic values — no enum growth, no migration.
2. Add NON_HOLO = "Non-Holo" and HOLO = "Holo" to the global CardFinish enum — rejected; widens the shared enum, touches every exhaustive finish map and requires a PG enum migration for values that are semantically identical to existing ones.

Decision Outcome

Chosen option: use the existing values end to end. ChronoCoreFinish is restricted to STANDARD = "Standard" and HOLOGRAPHIC = "Holographic", and the sheet’s finish column carries those exact values — no importer-side terminology mapping.

Consequences

• ✅ No CardFinish growth, no PG migration, no exhaustive-map churn.
• ✅ Finish labels render through the existing global i18n keys (values.standard, values.holographic), already translated in EN and FR.
• ⚠️ The catalog and the sheet both say “Standard” / “Holographic” rather than the community’s “Non-Holo” / “Holo” wording.