Finished up most documentation

docs/sanctification-tcg-workshop-backlog.md

@@ -220,6 +220,10 @@ Questions to resolve:
 
 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?
@@ -238,6 +242,11 @@ Questions to resolve:
 - 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
@@ -256,6 +265,63 @@ Questions to resolve:
 
 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?
@@ -275,6 +341,31 @@ Questions to resolve:
 - 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?
@@ -293,6 +384,11 @@ Questions to resolve:
 - 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?
@@ -316,6 +412,110 @@ Questions to resolve:
 - 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?
@@ -338,6 +538,12 @@ Questions to resolve:
 - 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?
@@ -356,6 +562,42 @@ Questions to resolve:
 
 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
@@ -383,6 +625,20 @@ Questions to resolve:
   - 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?
@@ -399,6 +655,13 @@ Questions to resolve:
 - 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?
@@ -424,6 +687,13 @@ Questions to resolve:
 - 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?
@@ -448,6 +718,11 @@ Questions to resolve:
 - 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?
@@ -470,6 +745,10 @@ Questions to resolve:
 - 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?
@@ -493,6 +772,10 @@ Questions to resolve:
 - 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?
@@ -516,6 +799,18 @@ Questions to resolve:
 - 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?
@@ -536,6 +831,10 @@ Questions to resolve:
 - 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?
@@ -548,8 +847,6 @@ 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.
@@ -561,6 +858,11 @@ Questions to resolve:
   - 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?
@@ -581,6 +883,11 @@ Questions to resolve later:
 
 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
@@ -608,6 +915,10 @@ Questions to resolve:
   - 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?
@@ -627,6 +938,10 @@ Questions to resolve:
   - 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?
@@ -644,6 +959,10 @@ Questions to resolve:
 - 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?
@@ -663,6 +982,10 @@ Questions to resolve:
 - Whether customization changes provenance.
 - Whether a customized Trinity card remains one canonical instance.
 
+#### ANSWER
+
+Deferred for now
+
 ---
 
 ## Tier 5 — Christian Content and Editorial Policy
@@ -679,6 +1002,25 @@ Questions to resolve:
 - 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?
@@ -709,6 +1051,10 @@ Questions to resolve:
   - 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?
@@ -736,6 +1082,27 @@ Questions to resolve:
 - 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?
@@ -754,6 +1121,10 @@ Questions to resolve:
 - 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?
@@ -773,6 +1144,77 @@ Questions to resolve:
 - 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?
@@ -799,6 +1241,24 @@ Questions to resolve:
 - 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
@@ -828,6 +1288,14 @@ Questions to resolve:
 
 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?
@@ -853,6 +1321,10 @@ Questions to resolve:
 - Whether access is permanent or temporary.
 - Whether users can revoke previously-shared information.
 
+#### ANSWER 
+
+DEFERRED FOR NOW
+
 ---
 
 ### 37. What triggers an accountability / prayer signal?
@@ -870,6 +1342,10 @@ Questions to resolve:
 
 Privacy suggests manual or explicitly-configured behavior rather than implicit disclosure.
 
+#### ANSWER 
+
+DEFERRED FOR NOW
+
 ---
 
 ### 38. What collection metadata is public?
@@ -879,21 +1355,29 @@ 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.
+- 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.
 
 ---
 
@@ -916,6 +1400,10 @@ Questions to resolve later:
 
 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
@@ -955,6 +1443,10 @@ Questions to resolve:
 
 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?
@@ -962,7 +1454,7 @@ The current scope reads more like a vertical slice designed to prove the unique
 Current target:
 
 - Around 50 real cards.
-- Plus 4–6 filler cards, possibly inside or outside that count.
+- Plus 4–6 filler cards, possibly inside or outside that count. - DEFERRED
 
 Questions to resolve:
 
@@ -970,10 +1462,15 @@ Questions to resolve:
 - 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?
 
+#### ANSWER 
+
+50 For now
+
+a few of each category.
+
 ---
 
 ### 42. Three.js vs Flutter Scene / Flutter GPU
@@ -1000,6 +1497,10 @@ The proposed hard test card is:
 
 This decision should follow the spike rather than be made theoretically.
 
+#### ANSWER
+
+Already decided. Three.js wins
+
 ---
 
 ### 43. What is the exact web framework?
@@ -1019,6 +1520,10 @@ Questions to resolve after the renderer spike:
 - Mobile-browser architecture.
 - Whether the renderer lives as an isolated package.
 
+#### ANSWER
+
+FOR TECH SPEC
+
 ---
 
 ### 44. What is the shader/material architecture?
@@ -1043,6 +1548,10 @@ Still unresolved:
 - 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?
@@ -1060,6 +1569,10 @@ Questions to resolve:
 - 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