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.

---

### 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?

---

## 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.

---

### 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?

---

### 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.

---

### 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.

---

### 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?

---

### 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.

---

## 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.

---

### 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?

---

### 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?

---

### 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.

---

### 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?

---

### 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.

---

### 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.

---

### 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?

---

### 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 condition should remain excluded.
- Whether imperfections remain excluded.
- 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.

---

### 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.

---

## 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.

---

### 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.

---

### 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.

---

### 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.

---

## 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?

---

### 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.

---

### 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.

---

### 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.

---

### 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.

---

### 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.

---

## 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.

---

### 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.

---

### 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.

---

### 38. What collection metadata is public?

Potential metadata:

- Binder.
- Card ownership.
- Finish/material/printing.
- Condition.
- Original opener.
- Opening date.
- Population.
- Trade history.
- Destroyed-card history.

Questions to resolve:

- Default visibility.
- Per-user privacy controls.
- Whether original-opener identity persists after trading.
- Whether users can anonymize provenance.
- Whether population data is public globally.
- Whether destroyed cards remain visible.

---

### 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.

---

## 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.

---

### 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.

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.
  - Filler cards.
- When does the full ~50-card MVP set become necessary?
- Should content production happen after the hard renderer is proven?

---

### 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.

---

### 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.

---

### 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.

---

### 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?

---

# 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 | |