Sanctification/docs/sanctification-tcg-workshop-backlog.md

Sanctification TCG — Functional Spec Workshop Backlog

This document collects the unresolved or insufficiently-defined decisions in the current functional spec.

The goal is to work through these one at a time, make explicit decisions, and then fold the final answers back into the functional spec so the spec no longer contains contradictory, placeholder, or ambiguous behavior.

---

Tier 1 — Core Product Mechanics

1. What exactly earns the daily reward?

Questions to resolve:

• If one user tracks 3 habits and another tracks 8, can the second user earn a better pack?
• If custom habits exist, how do we prevent users from creating extra trivial habits to improve rewards?
• Should rewards be based on:
  • Raw number of completed habits?
  • Percentage of planned habits completed?
  • A fixed set of reward-eligible core habits?
  • Weighted categories?
  • Some other normalized system?
• How should optional or non-daily habits interact with the reward?

The functional spec already establishes:

• Habit completion is binary from the application's perspective.
• Duration or self-reported difficulty should not increase rewards.
• The economy should assume honest participation rather than attempt anti-cheat verification.

ANSWER:

Daily habits Unlimited habits can be tracked. Up to 5 can be reward-eligible. Opening/checking in gives 2 cards. Each completed reward-eligible habit adds 2 cards. Maximum daily pack: 12 cards. Changing which habits are reward-eligible should take effect the next day. Weekly habits Tracked separately from daily habits. Can include things like church attendance, Bible study, volunteering, etc. A limited number can contribute to a separate weekly pack. This gives weekly commitments real significance without distorting the daily pack economy. Users can track any number of weekly habits. Up to 3 weekly habits can be reward-eligible. Each completed reward-eligible weekly habit adds 2 cards. Maximum weekly pack: 6 cards. No separate “weekly login” cards. Monthly habits Supported as a tracking cadence. No card reward for now. They can still contribute to history/consistency metrics. Reward design can be revisited later if monthly goals become important enough to justify it.

Daily maximum: 12 cards/day Weekly maximum: 6 cards/week Maximum weekly output from habits: 90 cards/week if someone gets every possible reward.

---

2. What is the lifecycle of a daily pack?

The current core loop says the user can open the day's pack immediately or save it, while the pack-upgrade idea says the same pack improves throughout the day.

Questions to resolve:

• Can the user open the pack before finishing their habits?
• If so, what happens to rewards earned afterward?
• Does the pack remain sealed and upgrade throughout the day until the user explicitly finalizes it?
• Is there a cutoff time when the day's pack automatically finalizes?
• Can the user manually finalize early?
• Does opening a pack end that day's reward progression?
• How does logging yesterday's habits affect yesterday's pack?

This should become one explicit state machine in the functional spec.

ANSWER:

• Each day starts with a 2-card pack.
• Completing one of the day's five reward-eligible habits adds 2 cards, up to 12.
• The pack can be opened at any point.
• Opening permanently finalizes that day's reward state.
• Any reward-eligible habits completed or logged afterward still count toward habit history and consistency, but cannot add cards to that day's pack.
• Because users can log the previous day's habits, an unopened previous-day pack can still be upgraded during that grace period.
• Opening an unfinished pack triggers an explicit warning that doing so is irreversible and forfeits any remaining reward potential for that day.
• The warning applies equally when opening today's unfinished pack or an unfinished pack from the previous day.
• Users can disable that warning in settings.

---

3. How does habit completion upgrade a pack?

Candidate mechanisms:

• Add cards.
• Improve rarity odds.
• Improve expected condition.
• Upgrade the pack type.
• Some combination of the above.

The current spec leans toward adding cards because it may feel less like manipulating gambling-style odds, but this is not yet decided.

Questions to resolve:

• Which mechanism feels rewarding without becoming casino-like?
• Should users visibly understand exactly what each completed task did?
• Should later upgrades affect every card in the pack or only newly-added slots?
• Is the pack upgrade path deterministic or probabilistic?

ANSWER:

Each completed reward-eligible habit adds 2 cards. Habit completion does not modify rarity odds, condition, material, finish, or pack type.

---

4. How much better is a fully completed day than simply logging in?

The login pack needs to:

• Be meaningful enough to establish the daily hook.
• Not make opening the application equivalent to actually completing habits.

Questions to resolve:

• How weak is the starting pack?
• What is the maximum daily pack?
• What is the expected-value difference between:
  • Login only.
  • Partial completion.
  • Full completion?
• Should full completion unlock a distinct final slot or presentation rather than merely adding more probability?

ANSWER:

For initial release, 2 cards for login vs. 12 cards for completing all five reward-eligible daily habits We can modify as we see fit but that feels good currently.

---

5. What does consistency do mechanically?

The spec has moved away from positive-habit streaks and toward consistency metrics.

Potential measurements include:

• 7-day consistency.
• 30-day consistency.
• 90-day consistency.
• Lifetime completion rate.
• Total completions.
• Returning after time away.

Questions to resolve:

• Which metrics exist in the MVP?
• Which are purely informational?
• Which, if any, affect rewards?
• Should consistency ever improve card economy output?
• Could consistency instead unlock:
  • Cosmetics.
  • Achievements.
  • Binder decoration.
  • Profile elements.
  • Special non-economic recognition?
• How should consistency treat scheduled days versus days on which a habit was not expected?

ANSWER:

Positive-habit consistency is measured using completion rate over scheduled opportunities rather than streaks. Consistency is informational and does not modify card rewards. The application may recognize consistency milestones and returning after time away through non-economic messaging or visual acknowledgement.

7 / 30 / 90 / lifetime <- the windows we use for tracking consistency

---

6. How do weekly and other non-daily habits work?

Examples currently include:

• Weekly church attendance.
• Volunteering.
• Potential future custom habits.

Questions to resolve:

• Can habits have arbitrary schedules?
• Are cadence types limited to daily / weekly for the MVP?
• How does a weekly habit affect a daily pack?
• Does church attendance improve one specific day's pack?
• Does it contribute gradually across the week?
• Does it produce a separate weekly reward?
• How is consistency calculated for habits that are not expected every day?
• How do flexible goals such as "volunteer once this month" work?

ANSWER:

A weekly habit may require one or more completions within the week, but it occupies one weekly reward slot and awards its 2 cards only once, when its weekly target is met.

---

7. Do negative habits affect card rewards at all?

The spec intentionally avoids rewarding recovery milestones with packs so that failure cannot become part of an optimal reward strategy.

Questions to resolve:

• Does negative-habit abstinence ever improve pack rewards?
• Does simply continuing to honestly track affect rewards?
• Should negative-habit tracking be entirely economically separate from the TCG?
• Should its rewards instead be:
  • Messaging.
  • Scripture.
  • Visual recognition.
  • Recovery milestones.
  • Accountability interactions.
• Could tying card rewards to abstinence unintentionally create shame when a user falls?

A strong candidate direction is to keep negative-habit recovery entirely outside the card economy, but this still needs an explicit decision.

ANSWER:

Negative habits are tracked separately and do not directly affect card rewards. Abstinence, honest reporting, recovery milestones, and returning after failure receive non-economic recognition only. Positive replacement behaviors may be tracked separately as ordinary reward-eligible habits.

---

8. How far back can reward-eligible logging go?

Current working rule:

• The user can log the previous day and still receive the reward that day qualified for.
• Older history can still be entered for statistics but does not generate packs indefinitely.

Questions to resolve:

• Is the grace period exactly one previous calendar day?
• Is it based on the user's timezone?
• What happens after travel or timezone changes?
• Does yesterday's pack still exist if it was never finalized?
• What happens if yesterday's habits are edited after its pack was opened?
• Should completed entries become immutable after the reward is claimed?

ANSWER

Reward-eligible habit completion may be logged through the end of the following calendar day. During this grace period, completion changes may continue to add or remove cards from an unopened daily pack. Opening the pack permanently finalizes its reward state. When the grace period expires, an unopened pack automatically finalizes at its current size and may be saved and opened later. Older habits remain editable for history and consistency purposes but cannot alter card rewards.

---

Tier 2 — Economy and Collection Design

9. How many cards are in a pack, and what are the rarity probabilities?

Questions to resolve:

• Base number of cards in the weakest pack.
• Maximum number of cards in a completed-day pack.
• Rarity distribution for each pack state/type.
• Whether every pack guarantees a minimum rarity.
• Whether pack types have distinct probability tables.
• Whether rarity odds should remain globally fixed.
• How often economy variables may be rebalanced after launch.

This needs simulation rather than intuition alone.

ANSWER:

Normal daily and weekly pack slots use the same global rarity distribution. Habit completion increases the number of cards in a pack but does not improve the rarity odds of any individual card.

Pack sizes

Daily pack

• Login / start of day: 2 cards.
• Each completed reward-eligible daily habit adds 2 cards.
• Up to 5 daily habits may be reward-eligible.
• Maximum daily pack: 12 cards.

Weekly pack

• No automatic login cards.
• Each completed reward-eligible weekly habit adds 2 cards.
• Up to 3 weekly habits may be reward-eligible.
• Maximum weekly pack: 6 cards.

Monthly habits do not generate cards in M1.

M1 rarity distribution

Each card slot independently rolls against the following global rarity table:

Rarity	Pull Probability
Common	59.00%
Uncommon	28.50%
Rare	9.00%
Extraordinary	2.75%
Legendary	0.75%
Total	100.00%

These probabilities are separate from the percentage of card identities assigned to each rarity tier.

The initial 500-card catalog currently contains:

Rarity	Card Identities
Common	192
Uncommon	150
Rare	101
Extraordinary	39
Legendary	18
Total	500

Within a rarity tier, eligible card identities initially have equal probability unless a later set-specific mechanic explicitly defines otherwise.

Normal packs do not contain guaranteed Rare+, Extraordinary+, or Legendary slots. Every card slot is an independent draw from the same rarity distribution.

The purpose of completing additional habits is therefore to receive more draws, not better hidden odds.

These values are the M1 starting economy rather than permanent constants. They should be configurable and validated through economy simulation and playtesting. Any future rebalance should remain global and transparent rather than dynamically manipulating probabilities for individual users.

---

10. What does "about a year to complete the collection" mean?

The current spec suggests that one person collecting every base card should take roughly at least a year of very consistent use.

Questions to resolve:

• Does this refer to:
  • The launch set?
  • The shared Christian core?
  • Every currently-released base card?
  • Each individual set?
• What happens as new cards are added?
• Is duplicate protection ever used?
• Is completion expected without trading?
• How much should trade-ups accelerate completion?
• What completion target should be used for economy simulation?

ANSWER:

Collection completion is measured by base card identity. A user needs at least one instance of each base card to complete the base compendium. Finish, printing, material, condition, imperfections, and other instance-level properties do not affect base-compendium completion.

The M1 economy should not be designed around guaranteeing 100% natural completion after a fixed period. Random duplicates intentionally create a progressively slower collection curve.

Using the initial 500-card catalog and M1 rarity distribution, the target experience for a maximally consistent user opening normal rewards is approximately:

50% completion after about 4 weeks. 75% completion after about 9–10 weeks. 90% completion after about 19 weeks. 95% completion after about 28 weeks. Approximately 99% completion after about one year.

These are economy-model targets rather than guarantees for individual users.

The final few percent of the compendium should represent a substantially longer collector challenge when relying only on random packs. Normal pack opening does not provide duplicate protection or dynamically favor cards missing from the user's collection.

Future mechanics such as trading and trade-ups may provide more directed ways to acquire missing cards and complete the compendium.

Variant collecting is intentionally much deeper than base-compendium completion. Obtaining one copy of a card identity does not imply that the user has exhausted the collectible possibilities associated with that card.

Whether filler cards participate in base-compendium completion is decided separately under the filler-card economy.

---

11. How do filler cards work economically?

Questions to resolve:

• Exact percentage of Common pulls that are filler.
• Whether filler cards:
  • Have individual weights.
  • Exist in a dedicated filler sub-pool.
• Whether fillers count toward:
  • Base compendium completion.
  • Prestige completion.
  • Set completion.
• Whether every crafting/trade-up system treats filler the same as normal Common cards.
• Whether filler cards can have finish/material/printing variants.
• Whether fillers should be visually recognizable as a special classification.

ANSWER

DEFERRED FOR M1

---

12. How do trade-ups / crafting work?

Current conceptual example:

Consume 20 Common cards to generate 1 Uncommon card.

Questions to resolve:

• Exact input ratio.
• Whether output is guaranteed to be the next rarity.
• Whether input rarity must all match.
• Whether finish influences output.
• Whether material influences output.
• Whether printing influences output.
• Whether the user can choose the destination set.
• Whether the result can already be owned.
• Whether some cards are protected from trade-ups.
• Whether a card must be manually unlocked before it can be consumed.
• Whether destroyed inputs remain visible in provenance history.
• Whether trade-ups are the primary card sink or one of several sinks.

ANSWER

Status: Resolved for M1

M1 will include a straightforward 10-to-1 rarity trade-up system.

A trade-up consumes ten card instances of the same rarity and permanently generates one card of the immediately higher rarity:

10 Common → 1 Uncommon 10 Uncommon → 1 Rare 10 Rare → 1 Extraordinary 10 Extraordinary → 1 Legendary

Trade-ups cannot skip rarity tiers, and the rarity upgrade is guaranteed. The random outcome is the resulting card identity and its instance properties, not whether the trade-up succeeds.

Card identity

For M1, the resulting card identity is selected randomly from the eligible cards in the next rarity tier.

The identities of the input cards do not influence the resulting identity.

Set-specific or category-targeted trade-ups may be considered later but are not part of the initial mechanic.

Instance-property inheritance

The finish, material, and printing of the input cards directly influence the corresponding properties of the resulting card.

Each input contributes an equal share of probability.

For a ten-card trade-up, each input therefore contributes 10 percentage points to its represented property.

For example:

Finish

10 Holographic → 100% Holographic output

7 Holographic 3 Matte → 70% Holographic → 30% Matte

The same system independently applies to material and printing.

For example:

Material

5 Metal 3 Paper 2 Linen

→ 50% Metal → 30% Paper → 20% Linen

and:

Printing

8 Normal 2 Borderless

→ 80% Normal → 20% Borderless

Each property is rolled independently. This means a trade-up can produce combinations that were not present on any single input card.

For example, five Holographic/Paper cards and five Matte/Metal cards could potentially produce a Holographic/Metal result.

This is intentional. Trade-ups act as a way to combine desirable collectible traits as well as increase rarity.

Guaranteed property inheritance

If all ten input cards share a property, that property is guaranteed on the resulting card.

Examples:

10 Holographic cards → guaranteed Holographic. 10 Metal cards → guaranteed Metal. 10 Borderless cards → guaranteed Borderless. Inputs sharing all three properties guarantee all three properties on the output.

This allows collectors to deliberately construct trade-up recipes rather than treating every duplicate of the same rarity as economically identical.

Destruction

All ten input cards are permanently consumed by the trade-up and are no longer part of the active card population or any user's collection.

Their historical provenance should not be erased. We could have a counter of how many of the different cards you have traded up but we don't want to have a huge DB of dead cards. So a basic counter

Design intent

Trade-ups serve two purposes:

Provide a meaningful use for duplicates and permanently remove cards from circulation. Allow low-rarity cards with desirable finishes, materials, printings, or condition to retain meaningful collector and crafting value.

A highly desirable Common card is therefore not automatically disposable merely because its base identity is Common. Its instance properties can make it valuable either as a collectible or as an ingredient in a deliberately constructed trade-up.

More advanced crafting systems, targeted card identities, targeted sets, and additional recipes are deferred until after the M1 economy has been tested.

---

13. What role does voluntary card burning actually serve?

Possible concepts currently overlap:

• Personal ceremony / reset.
• Destroying duplicates.
• Crafting input.
• Trade-up input.
• Economy sink.

Questions to resolve:

• Is "burning" a standalone action?
• Does burning yield anything?
• Is crafting visually represented as burning?
• Can any normal card be burned?
• Should rare or sentimental cards require extra confirmation?
• Does a burned card remain visible in historical records?
• Is the religious symbolism appropriate and useful, or is this simply an economy mechanic with a dramatic animation?

ANSWER

I think for now it would be a nice animation for the card trade up. Like the 10 cards burn together to form the new one

Other aspects we can defer.

---

14. When are saved-pack contents determined?

Questions to resolve:

• Are card identities rolled:
  • When the pack is earned?
  • When the day is finalized?
  • When the pack is opened?
• Are finish/material/printing/wear rolled at the same time?
• Can economy rebalancing affect already-earned unopened packs?
• Does population count change only once the pack is opened?
• Can an unopened pack have provenance?
• Can saved packs ever become collectible objects themselves?

The implementation should be deterministic enough that server/client behavior cannot accidentally reroll contents.

ANSWER

The contents of a pack are generated when that pack is finalized, not when it is opened.

Finalization occurs when:

The user opens an active pack early. The pack has reached its maximum possible reward state. The pack's reward-eligible grace period expires.

When a pack finalizes, the system determines and stores all resulting card instances, including:

Card identity. Rarity. Finish. Material. Printing. Condition. Any other instance-level properties enabled by the current economy.

Opening a pack does not generate or reroll its contents. It only reveals card instances that were already created when the pack finalized.

This ensures that:

Saved packs are not affected by future rarity or economy rebalancing. Opening cannot be retried to obtain different results. Client interruptions during the reveal process cannot change awarded cards. Population and provenance can be tracked consistently.

A saved unopened pack may therefore remain unopened indefinitely without changing its contents.

Card provenance should distinguish between the time an instance was created/finalized and the time it was actually revealed to the user.

For an active pack opened before its reward period ends, confirming the open action first finalizes the pack at its current card count, generates its contents, and then begins the reveal experience.

---

Tier 3 — What Constitutes a Card

15. What is the final rarity structure?

Current placeholder tiers:

• Common.
• Uncommon.
• Rare.
• Extraordinary.
• Legendary.

Questions to resolve:

• Final names.
• Number of tiers.
• Whether rarity names should be explicitly Biblical/thematic.
• Whether thematic names create theological implications that should be avoided.
• Whether rarity affects only pull probability or also:
  • Artwork composition.
  • Border complexity.
  • Animation.
  • Presentation.
• Whether filler remains outside the rarity hierarchy.

ANSWER

Common Uncommon Rare Extraordinary Legendary

Card rarity = identity prominence / pull scarcity

Instance rarity = not a separate thing

Finish/material/printing/condition = independent collectible properties

---

16. What does rarity mean across different sets?

The spec defines rarity as prominence within the collection rather than spiritual worth.

It also allows sets to have independent rarity structures.

Questions to resolve:

• Is a Legendary from one set economically equivalent to a Legendary from another?
• Are rarity probabilities shared globally or defined per set?
• Can a historically important person be Common in one thematic set and Legendary in another?
• Does a card identity have one canonical rarity or can each printing/set version have its own?
• How should rarity be communicated so users do not interpret it as spiritual importance?

ANSWER

A Legendary card therefore participates in the same Legendary rarity tier regardless of whether it represents a Biblical person, historical event, doctrine, tradition-specific subject, or another category.

Sets do not define independent rarity probabilities in M1.

---

17. Are finish, printing, and material fully combinatorial?

Current model implies independent properties:

• Finish.
• Printing.
• Material.

This creates combinations such as:

• Holographic + borderless + metal.
• Textless + wood + matte.
• Foil + boundless + linen.

Questions to resolve:

• Is every combination legal?
• Can individual card definitions restrict combinations?
• Are some finishes incompatible with some materials?
• Are some printings incompatible with text-heavy cards?
• Do special combinations have different population tracking?
• Should invalid combinations be encoded as rules or simply never generated?

ANSWER

Finish, material, and printing are independent collectible properties and are combinatorial by default.

Unusual combinations are not considered invalid merely because they would be uncommon or difficult to manufacture as physical cards. Sanctification TCG is a digital collectible system, and unusual combinations are desirable when the renderer can present them convincingly.

---

18. What exactly is a printing?

Current placeholders:

• Normal.
• Borderless.
• Textless.
• Boundless.

Questions to resolve:

• Concrete visual definition of each.
• Difference between Borderless and Boundless.
• Whether printings can change:
  • Cropping.
  • Typography.
  • Text placement.
  • Artwork.
  • Frame geometry.
• Whether alternate artwork is itself a printing or a separate artwork property.
• Whether tradition-specific versions are printings, separate cards, or artwork variants.

ANSWER

Printing is an independent collectible property that may materially alter a card’s artwork composition, framing, layout, or text treatment. Exact printing types, visual definitions, compatibility rules, and art-production requirements are defined in the Art Direction specification.

---

19. What is the finish taxonomy?

Current possibilities:

• Matte.
• Glossy.
• Textured.
• Holographic.
• Foil.
• Future holographic/foil patterns.

Questions to resolve:

• Are these mutually exclusive?
• Can a card be both textured and holographic?
• Is "foil" a finish or a layer/effect?
• Are holographic patterns subtypes of holographic?
• Are finish variants purely visual, or do they also affect rarity/value?
• Do finishes alter simulated weight?

ANSWER

Will be in the art direction

---

20. What is the material taxonomy?

Current possibilities:

• Paper.
• Plastic.
• Wood.
• Linen.
• Metal.

Questions to resolve:

• Final MVP materials.
• Whether every card can exist in every material.
• Physical thickness by material.
• Weight implications.
• Lighting response.
• Flexibility / deformation behavior.
• Edge wear behavior.
• Whether unusual materials should be extremely rare or simply another independent variant dimension.

ANSWER

Each card instance has exactly one material representing its physical substrate. M1 candidate materials are Paper, Linen, Wood, and Metal. Material is independent of base rarity, participates in card generation, population grouping, and trade-up inheritance, and may have its own economy probabilities. Exact visual treatment, physical appearance, compatibility constraints, thickness, lighting response, and renderer behavior are defined in the Art Direction specification. Paper would be considered the default

---

21. How does condition / wear work?

Current concept:

• Continuous value between 0.00 and 1.00.
• 1.00 is pristine.
• 0.00 is heavily worn but still readable and collectible.

Questions to resolve:

• Exact named bands.
• Exact ranges.
• Distribution of wear values when cards are generated.
• Whether rarity affects minimum condition.
• Whether material affects wear.
• Whether condition can ever change after a card is opened.
• Whether trading affects wear.
• Whether users can repair cards.
• How much condition should affect collector desirability.
• Lowest acceptable visual state.

ANSWER

Randomized wear or condition will not be an instance-level collectible property in M1.

Earlier designs assigned every card a continuous condition value and rendered varying levels of scratches, edge wear, scuffs, and other damage. This creates undesirable negative variance: a user may obtain a rare card identity with exactly the finish, material, and printing they wanted, only for the card to feel inferior because of an additional condition roll.

Consider maybe some other finishes: Weathered Antiqued Distressed parchment Patinated metal

---

22. Do imperfections belong in the product?

Potential imperfections:

• Fingerprints.
• Hair.
• Minor print artifacts.
• Surface marks.

Questions to resolve:

• Do they make individual cards more interesting or merely noisy?
• Are they cosmetic only?
• Are any imperfections considered desirable misprints?
• Can imperfections affect population classification?
• Do users need a way to inspect/identify them explicitly?
• Should the MVP omit them until the rest of the variant system is proven?

ANSWER

CUT

---

23. How should population be counted?

Current proposed grouping:

Card ID + Finish + Printing + Material

Questions to resolve:

• Whether artwork belongs in the population key.
• Whether set belongs in the population key.
• Whether population numbers are:
  • Global.
  • Public.
  • Approximate.
  • Exact.
• Whether destroyed cards reduce current population while remaining in historical-minted counts.
• Whether the app shows:
  • Current surviving population.
  • Total ever opened.
  • Both.

ANSWER

Population is tracked for meaningful collectible variants using card identity + artwork variant + finish + material + printing. The system records both total instances ever created and the number currently surviving. Burning and trade-ups reduce surviving population but do not erase historical creation counts. Provenance, ownership, and timestamps do not create separate populations. Public visibility of population statistics is decided separately.

---

24. Does simulated weight stay in the product?

Current concept:

• Cards have simulated weight.
• Material/finish can slightly alter it.
• A future digital scale could let users weigh unopened packs.

Questions to resolve later:

• Keep or cut.
• Whether it creates meaningful collectible behavior.
• Whether pack contents are actually inferable by weight.
• Whether this becomes exploitable rather than fun.
• Whether the system is worth the implementation complexity.

This is intentionally low priority.

ANSWER

Each card instance has a simulated physical weight derived primarily from its material, with small deterministic variation and optional minor adjustments from finish/printing.

---

Tier 4 — The Trinity Card

25. What is the final conceptual / theological framing?

Current concept:

• Every user receives The Trinity.
• It is given rather than earned.
• It cannot be traded.
• It cannot be destroyed.
• It is always mint.
• It does not participate in normal rarity/population mechanics.
• Its finish/material presentation can be customized.

Questions to resolve:

• Exact theological message.
• Whether "given, not earned" is framed explicitly as an analogy to grace.
• Whether that analogy creates denominational disagreement.
• Whether the card should be called:
  • The Trinity.
  • Holy Trinity.
  • Another title.
• Whether this is technically a collectible card, foundation card, or a separate object type.

ANSWER

Deferred for now

---

26. Which Scripture belongs on the Trinity card?

The current spec is inconsistent:

• One section suggests John 3:16.
• The MVP table suggests Matthew 28:19.

Questions to resolve:

• Which passage best serves the actual purpose of the card?
• Should the card emphasize:
  • The Trinity directly.
  • Grace / gift.
  • Baptismal formula.
  • God's love and salvation?
• Whether a verse is sufficient or a short doctrinal text is more appropriate.

ANSWER

Deferred for now

---

27. What should the Trinity artwork depict?

Current constraint:

• Avoid an awkward or irreverent literal depiction of Father, Son, and Holy Spirit.

Questions to resolve:

• Symbolic approach.
• Architectural / stained-glass approach.
• Scripture-focused approach.
• Cross / dove / light symbolism.
• Whether any traditional Trinitarian iconography is appropriate.
• How to avoid accidentally privileging one tradition's visual theology.

ANSWER

Deferred for now

---

28. How customizable is the Trinity card?

Current sections disagree slightly on whether customization includes:

• Finish.
• Material.
• Printing.

Questions to resolve:

• Which properties can be changed.
• Whether customization is unlimited/free.
• Whether all users can access all options immediately.
• Whether customization has any collectible significance.
• Whether customization changes provenance.
• Whether a customized Trinity card remains one canonical instance.

ANSWER

Deferred for now

---

Tier 5 — Christian Content and Editorial Policy

29. Is the Nicene Creed permanently the doctrinal boundary?

Current language describes it as the standard "for now."

Questions to resolve:

• Is Nicene Christianity the permanent product scope?
• Is it simply the MVP editorial baseline?
• How are groups outside the Nicene boundary represented?
• Is the application presenting a doctrinal position or merely using one as an organizational framework?
• What happens with traditions that accept the Nicene Creed but interpret later doctrines very differently?

ANSWER

Sanctification TCG uses Nicene Christianity as its doctrinal baseline.

For the purposes of the application, beliefs and movements that fall outside the core theology expressed by the Nicene Creed are considered outside orthodox Christianity and may be identified as heretical or non-Nicene where historically and theologically appropriate.

This boundary is not intended to prevent the application from representing or teaching about beliefs outside it. Non-Nicene movements, historical heresies, disputed teachings, and other religious traditions may still appear in the card catalog when they are educationally or historically relevant.

Their treatment should remain accurate, charitable, and informative. Cards should explain:

What the person, movement, or teaching actually believed. Its historical and theological context. Why it was or is considered outside the Nicene standard. How its beliefs differ from the doctrinal baseline used by the application.

The goal is clarity without mockery. The application does not need to present every theological position as equally compatible with Christianity in order to describe those positions fairly.

Disagreements that exist within Nicene Christianity should be distinguished from teachings that cross the Nicene boundary. Catholic, Orthodox, Protestant, and other Nicene traditions may disagree substantially on later doctrines and practices while remaining inside the application's shared Christian baseline.

---

30. How deep do tradition-specific collections go?

Initial high-level categories:

• Catholic.
• Orthodox.
• Protestant.

Questions to resolve:

• Whether those categories become hierarchical.
• Examples:
  • Catholic.
  • Eastern Orthodox.
  • Oriental Orthodox.
  • Anglican.
  • Lutheran.
  • Reformed.
  • Baptist.
  • Methodist.
  • Pentecostal.
• Whether traditions are represented as:
  • Sets.
  • Tags.
  • Collections.
  • All of the above.
• Whether cards can belong to multiple traditions.

ANSWER

Already completed in master catalog

---

31. How are controversies and non-Nicene movements classified?

Potential subjects include:

• Arianism.
• Gnosticism.
• Pelagianism.
• Nestorian controversies.
• Latter-day Saint theology.
• Jehovah's Witnesses.
• Other disputed movements.

Questions to resolve:

• Taxonomy.
• Tone.
• Difference between:
  • Historical heresy.
  • Schism.
  • Denominational disagreement.
  • Non-Nicene movement.
  • Modern religion with Christian origins.
• How labels are chosen without turning cards into insult cards.
• Who approves wording.

ANSWER

• Intra-Nicene controversy — disputes between traditions that remain inside the doctrinal baseline.
• Historical heresy — teachings historically condemned as contrary to core Christian doctrine.
• Schism / ecclesial controversy — primarily disputes over communion, authority, jurisdiction, or church structure rather than rejection of Nicene doctrine.
• Non-Nicene movement — later movements or religious bodies whose theology falls outside the Nicene baseline.

Cards dealing with controversial teachings or movements should be educational rather than insulting or polemical.

Where practical, their content should explain:

What the person, movement, or teaching actually believed or taught. Its historical context. Why the issue became controversial. Whether the disagreement falls inside or outside the application's Nicene baseline. How the Nicene position differs when the subject falls outside that baseline.

Disagreements within Nicene Christianity should be represented as genuine disagreements without implying that one side automatically falls outside Christianity unless the underlying issue actually crosses the Nicene boundary.

The goal is doctrinal clarity, historical accuracy, and charitable presentation.

---

32. Who reviews doctrinal and historical accuracy?

Questions to resolve:

• Whether content requires formal review.
• Who is qualified to review:
  • Scripture.
  • Church history.
  • Catholic-specific content.
  • Orthodox-specific content.
  • Protestant-specific content.
  • Controversial movements.
• Whether multiple reviewers are needed for disputed topics.
• How disagreements between credible traditions are presented.
• Whether the app should explicitly distinguish consensus from disputed interpretation.

ANSWER

Deferred for now. When we get to the writing, we'll deal with it then

---

33. What is the citation/source policy?

Questions to resolve:

• What sources are acceptable.
• Whether every card requires citations.
• Whether primary sources are preferred.
• How Scripture references are stored.
• How historical quotations are attributed.
• Whether users can click through to:
  • Scripture.
  • Primary texts.
  • Historical sources.
  • Further reading.
• How sources are versioned if card text changes.
• Whether citations appear directly on the card or only in the detailed information panel.

ANSWER

Card content should be supported by source metadata sufficient for users to understand where factual, historical, scriptural, and doctrinal claims come from.

The card face should remain visually concise. Full citations and supporting resources should generally appear in the card's expanded information or learning panel rather than crowding the primary card layout.

Source priority

Where applicable, sources should be prioritized approximately as follows:

Scripture, when directly relevant. Primary historical or theological sources, such as creeds, council texts, letters, sermons, confessions, catechisms, or writings by the person being represented. Tradition-specific authoritative sources, when explaining the teaching of a specific Christian tradition. Reputable secondary historical or scholarly sources, for historical context, chronology, interpretation, or claims that cannot be established from a primary source alone.

Research tools, general websites, and tertiary summaries may assist content creation but should not normally serve as the sole published authority for important doctrinal or historical claims when stronger sources are available.

Card-face references

The card itself may contain concise references when useful, such as:

Scripture citations. Short quotation attribution. Council/date references. Author/work references.

Full bibliographic details are not required on the visible card face.

Expanded information panel

The expanded card view should provide access to relevant source information and further reading.

This may include:

Scripture references. Primary-source citations. Historical references. Tradition-specific documents. Secondary sources. Further-reading links or resources. Quotations

Direct quotations require clear attribution.

Where practical, quote metadata should include:

Author or speaker. Source work. Relevant section, chapter, paragraph, or page. Translation or edition where the wording depends materially on it.

Quotation attribution should be verified before publication.

Disputed claims

When historical, theological, or attribution questions are genuinely disputed, the application should represent that uncertainty rather than presenting one interpretation as uncontested fact.

The information panel may identify:

Traditional attribution. Scholarly disagreement. Uncertain dates. Different interpretations among Nicene traditions. Data model

Sources belong primarily to the card definition, not the individual card instance.

Finish, material, printing, provenance, and other instance-level properties do not normally change the underlying citation set.

A future alternate printing or artwork version that contains materially different text may reference additional or different sources where necessary.

---

34. What religious-art representation rules are needed?

The current general visual direction is established, but subject-specific rules still need consideration.

Examples:

• Jesus.
• God the Father.
• Holy Spirit.
• Angels.
• Saints.
• Crucifixion.
• Resurrection.
• Icons.
• Biblical figures without known historical appearances.

Questions to resolve:

• How literal depictions should be.
• Whether tradition-specific iconographic conventions are used.
• How visual differences between traditions are presented.
• What requires theological/art review.
• Whether some concepts should use symbolic rather than figurative art.

ANSWER

Status: Deferred primarily to Art Direction

Detailed rules for depicting Jesus, the Father, the Holy Spirit, angels, saints, icons, biblical figures, crucifixion scenes, resurrection scenes, and other sacred subjects belong in the Art Direction specification.

The functional specification should retain only the following principles:

• Religious artwork should be treated respectfully and intentionally.
• The application should avoid irreverent, trivializing, or unnecessarily sensational depictions of sacred subjects.
• Where Christian traditions have materially different artistic conventions, the application may use tradition-specific visual treatments rather than forcing every subject into one universal style.
• Symbolic or non-figurative representation may be used where a literal depiction would be inappropriate, uncertain, or theologically sensitive.
• Historical or traditional iconography may inform artwork when appropriate to the card and collection.
• Artistic representation should not imply greater spiritual worth based on card rarity.
• Exact depiction rules, iconographic references, prohibited treatments, and tradition-specific art guidance are maintained in the Art Direction document.

The Trinity/Foundation card remains a special case whose exact imagery is deferred separately.

---

Tier 6 — Privacy, Accountability, and Social

35. What is the actual privacy/encryption model?

Current principle:

Private customer content should not simply exist as administrator-readable plaintext.

Questions to resolve:

• Client-side encryption design.
• Whether encryption applies to:
  • Custom habit names.
  • Negative habits.
  • Notes.
  • Accountability messages.
  • Prayer requests.
• Whether BYOK is practical.
• Key backup.
• Account recovery.
• Multi-device synchronization.
• Search over encrypted data.
• Anonymous statistics.
• What metadata necessarily remains server-visible.

This will likely require a dedicated technical-spec decision after the functional expectations are settled.

ANSWER

Sensitive user-authored habit content is encrypted client-side before being stored or synchronized. The backend stores only the minimum unencrypted metadata necessary to operate schedules, rewards, accounts, and explicitly initiated social features. The server should not possess the information necessary to casually inspect private habit names, negative habits, notes, or detailed accountability content.

Negative-habit content and history should receive the strongest protection because they do not participate in the card economy and may contain particularly sensitive information.

The exact cryptographic design, key wrapping, multi-device synchronization, and recovery mechanism belong in the technical/security specification. BYOK is cut. Account recovery must not silently undermine the stated privacy guarantees.

---

36. What are the exact accountability permissions?

Current philosophy:

• Private by default.
• Sharing is explicit.
• Shared state is obscure by default.
• Users can choose to reveal more detail.

Questions to resolve:

• Permission levels.
• Per-partner permissions versus global settings.
• Whether users can share:
  • Generic prayer-needed status.
  • Habit category.
  • Exact habit.
  • Completion history.
  • Negative-habit lapse.
  • Notes.
• Whether access is permanent or temporary.
• Whether users can revoke previously-shared information.

ANSWER

DEFERRED FOR NOW

---

37. What triggers an accountability / prayer signal?

Questions to resolve:

• Manual request only?
• Can the app suggest sending one?
• Can anything be sent automatically?
• Does reporting a negative-habit lapse trigger a prompt?
• Should the accountability partner ever know that a failure occurred unless explicitly told?
• Can users define standing rules such as:
  • "Tell this partner when I ask for prayer."
  • "Tell this partner if I have not checked in for X days."

Privacy suggests manual or explicitly-configured behavior rather than implicit disclosure.

ANSWER

DEFERRED FOR NOW

---

38. What collection metadata is public?

Potential metadata:

• Binder.
• Card ownership.
• Finish/material/printing.
• Original opener.
• Opening date.
• Population.
• Trade history.

Questions to resolve:

• Default visibility.
• Per-user privacy controls.
• Whether original-opener identity persists after trading. - YES (nice to know who generated)
• Whether users can anonymize provenance. - NO
• Whether population data is public globally. - DEFER
• Whether destroyed cards remain visible. - NO

ANSWER

• Binder.
• Card ownership.
• Finish/material/printing.
• Original opener.
• Opening date.
• Population.
• Trade history.

---

39. How will trading work?

Questions to resolve later:

• Direct offers.
• Multi-card offers.
• Counteroffers.
• Trade confirmation.
• Trade cancellation.
• Locked/favorite cards.
• Protected Trinity/Foundation cards.
• Trade history.
• Population/provenance changes.
• Whether users need to be friends.
• Whether trading is global or limited to known users.
• Whether public trade listings ever exist.

Trading is intentionally outside the first MVP but the data model may need to leave room for it.

ANSWER

DEFERRED FOR NOW

---

Tier 7 — MVP and Technology

40. Is the proposed MVP actually an MVP or a vertical slice?

Current MVP includes:

• Positive habits.
• Negative habits.
• Consistency metrics.
• Pack rewards.
• Saved packs.
• Approximately 50 cards.
• Filler cards.
• Multiple rarities.
• Multiple finishes.
• Multiple materials.
• Multiple printings.
• Wear.
• Binder.
• 3D inspection.
• 3D pack opening.
• Population/provenance.
• Economy simulation.

Questions to resolve:

• Is the goal:
  • Minimum viable product for external users?
  • Internal proof of concept?
  • Technical vertical slice?
  • Personal alpha?
• Which systems actually need production-grade completeness?
• Which can be prototypes?
• What does "MVP complete" mean?

The current scope reads more like a vertical slice designed to prove the unique and technically difficult parts of the product.

ANSWER

I'll iron this out as I go. I want it to be no multiplayer but fully locally functioning with like 50 cards.

---

41. How many real cards does the first build actually need?

Current target:

• Around 50 real cards.
• Plus 4–6 filler cards, possibly inside or outside that count. - DEFERRED

Questions to resolve:

• Do all 50 need finished art for the first renderer/economy prototype?
• Could the first implementation use:
  • 10 hero cards.
  • A smaller representative common/uncommon pool.
• When does the full ~50-card MVP set become necessary?
• Should content production happen after the hard renderer is proven?

ANSWER

50 For now

a few of each category.

---

42. Three.js vs Flutter Scene / Flutter GPU

Current plan:

Run a technical spike comparing them using the same difficult card.

Questions to evaluate:

• Visual fidelity.
• Shader/material flexibility.
• Desktop performance.
• Mobile performance.
• Touch interaction.
• Developer ergonomics.
• Asset pipeline.
• Code sharing.
• Future native-client implications.

The proposed hard test card is:

Legendary + borderless + metal + holographic + embossed + visible wear

This decision should follow the spike rather than be made theoretically.

ANSWER

Already decided. Three.js wins

---

43. What is the exact web framework?

Current likely direction:

• Web MVP.
• Potentially React.
• Potentially React Three Fiber if Three.js is chosen.

Questions to resolve after the renderer spike:

• React versus another framework.
• Rendering integration.
• State-management approach.
• Server rendering needs.
• Mobile-browser architecture.
• Whether the renderer lives as an isolated package.

ANSWER

FOR TECH SPEC

---

44. What is the shader/material architecture?

The functional boundary is already fairly clear:

• Database stores renderer-independent card properties.
• Runtime renderer interprets those properties.
• Blender is not a production dependency.

Still unresolved:

• Shared visual specification.
• Material parameter schema.
• Wear-mask format.
• Holographic implementation.
• Foil implementation.
• Embossing.
• Substrate response.
• Lighting.
• Renderer fallbacks.
• Performance tiers.
• How closely multiple renderer implementations must match visually.

ANSWER

This is worked out in the card-harness spike

---

45. How are static thumbnails generated?

Normal binder/search/trade screens are expected to use static or pre-rendered representations rather than active 3D rendering.

Questions to resolve:

• Client-side render-to-texture?
• Server-generated thumbnails?
• Build-time generation?
• On-demand cached rendering?
• Does each card instance need its own thumbnail because wear/finish/material differ?
• Are thumbnails generated at several lighting angles?
• How are holographic cards represented in static form?
• Can the same card contract drive both 3D and thumbnail generation?

ANSWER

Can be spiked out later. I'm not married to the idea. I can always optimize later

---

Explicitly Deferred Topics

These should not consume much workshop time until the core loop and economy are stable:

• Monetization.
• Native Android/iOS implementation.
• API/webhook ecosystem.
• Large-scale card catalog expansion.
• Digital pack scale / weight mechanics.
• Deep prestige systems.
• Advanced social features.
• Full trading economy.

---

Recommended Workshop Order

The first decisions should be made together because they define the reward economy:

1. Daily reward normalization.
2. Daily pack lifecycle.
3. Pack upgrade mechanism.
4. Login versus full-completion reward gap.
5. Consistency mechanics.
6. Weekly/non-daily habit behavior.
7. Negative-habit relationship to rewards.
8. Retroactive logging.

Once those are settled, proceed to:

9. Pack size and rarity math.
10. Collection-completion target.
11. Filler economics.
12. Trade-ups and card sinks.

Then move into the card-instance model, content policy, privacy/social design, and renderer/MVP decisions.

---

Workshop Status

Use this section as decisions are finalized.

#	Topic	Status	Decision
1	Daily reward normalization	Open
2	Daily pack lifecycle	Open
3	Pack upgrade mechanism	Open
4	Login vs full-completion gap	Open
5	Consistency mechanics	Open
6	Weekly/non-daily habits	Open
7	Negative habits and rewards	Open
8	Retroactive logging	Open
9	Pack size / rarity probabilities	Open
10	Collection completion target	Open
11	Filler economics	Open
12	Trade-ups / crafting	Open
13	Card burning	Open
14	Saved-pack generation timing	Open
15	Rarity structure	Open
16	Cross-set rarity meaning	Open
17	Variant combinatorics	Open
18	Printing taxonomy	Open
19	Finish taxonomy	Open
20	Material taxonomy	Open
21	Condition / wear	Open
22	Imperfections	Open
23	Population rules	Open
24	Simulated weight	Deferred
25	Trinity conceptual framing	Open
26	Trinity Scripture	Open
27	Trinity artwork	Open
28	Trinity customization	Open
29	Nicene boundary	Open
30	Tradition taxonomy	Open
31	Controversies taxonomy	Open
32	Content review authority	Open
33	Citation/source policy	Open
34	Religious-art rules	Open
35	Privacy/encryption model	Open
36	Accountability permissions	Open
37	Accountability triggers	Open
38	Public collection metadata	Open
39	Trading rules	Deferred
40	MVP vs vertical slice	Open
41	Initial card count	Open
42	Renderer choice	Pending spike
43	Web framework	Pending renderer
44	Shader/material architecture	Pending spike
45	Thumbnail generation	Open