# Christian Habit Tracker TCG - Functional Spec v4 I think a good name for the application would still be **Sanctification TCG**; as the objective is to grow in Christ and move towards holiness. Habit trackers are super common place and incredibly overdone. I find the same issue with every single one of them - tracking your habits needs to be a habit itself. Many applications try to add a "carrot" but nothing actually seems to provide a good sense to really reel you back in. On the opposite front, bad habits also tend to just be a number or a streak. If you fail, the app resets the number and that is about it. I want this to feel more human than that and I especially do not want failure to become a reason to avoid opening the app again. One thing that has become hugely popular is TCGs - more importantly card openings. This idea that you can collect the cards, try to obtain rare instances, collect wide variations of the same card, trade with friends, and just enjoy the experience of opening something you earned. All these card games are typically built in their own universe - but I want to do it Christian themed. The collection system is not really secondary to the habit tracker. It is the thing that makes the habit tracker unique. If I just wanted to track habits I could use pen and paper or download one of the thousand other habit trackers that already exist. The cards are the hook that should make me want to come back and keep using it. Below breaks this down into the larger functional pieces of the project, the things I think are already decided, and the unknowns that still need to be explored. --- ## Product Principles ### Core Purpose Ultimately this is a tool to help build essential habits with God. The collecting, trading, opening animations, social aspects, etc. are all there to make that process fun enough that someone actually wants to keep coming back. I think four concepts are equally important here: * Completion - actually doing the habits you said you wanted to do. * Honesty - being truthful with yourself about whether you actually did them. * Consistency - building something sustainable over time rather than obsessing over a perfect streak. * Returning from failure - if you fall off for a day, week, month, or longer, the application should make you want to come back instead of making you feel like everything was lost. ### Honor System How or whether someone actually is doing what they are tracking is between them and God - and with accountability partners if they choose to do that. What it means to complete a task is also between the user and God. If prayer for them means 5 minutes or 1 hour, that is fine. I think we should outline during onboarding that trying to say a 5 second prayer before entering the app is not really qualification. It is a matter of the heart - not trying to min/max the game. At the same time, the app should not try to grade the quality of someone's prayer, Bible reading, church attendance, etc. Five minutes of prayer should not give a worse pack than sixty minutes. A whole day of prayer should not give more rewards than an earnest five minutes. Habit completion is binary from the application's perspective. ### Honesty vs. the Economy I don't think we should build this like an anti-cheat system. The rarity and economy should be modeled around the assumption that everyone earnestly completes every task and reaches the consistency targets available to them. That is basically the maximum expected supply. If people miss days or do not complete everything, the economy simply develops more slowly than that baseline. If someone lies and clicks every task anyway, that is technically just reaching the baseline we already modeled for. It is between them and God, and I do not want the app to turn into a verification system for prayer or Christian practice. Because of that, rewards should also never scale based on self-reported duration or difficulty. We should not create an incentive to claim that a five minute prayer was a two hour prayer because it gives better cards. ### Privacy Habit tracking is private by default. This becomes especially important with negative habits because the user may be putting extremely sensitive information into the application. I want sensitive user-authored content encrypted **on the client before it is stored or synchronized**. The backend should only receive the minimum unencrypted metadata it actually needs to run schedules, rewards, accounts, and explicitly initiated social features. That means the server may need to know that an opaque habit ID was scheduled and completed, but it should not casually be able to read the user's custom habit name, notes, sins, struggles, negative-habit details, or detailed accountability content. Negative-habit content and history should get the strongest protection because they do not participate in the card economy and may contain especially sensitive information. The exact cryptographic design, key wrapping, multi-device synchronization, and recovery system belong in the technical/security spec. I no longer think BYOK needs to be part of the design. Whatever recovery model we use also cannot quietly undermine the privacy promise by leaving us with a master key that can read everything. Accountability sharing should still be obscure by default. A user should be able to say something like: > Daniel needs your prayer today. without automatically telling the accountability partner exactly what happened. The exact detailed-sharing permission model can be worked out later. ## Christianity At the core foundation, what we consider orthodox Christianity for the purposes of this application is founded in the words and logic of the Nicene Creed. This is the doctrinal baseline for the application. Beliefs and movements outside the core theology expressed by the Nicene Creed are outside that baseline and may be identified as heretical or non-Nicene where that is historically and theologically appropriate. > We believe in one God the Father Almighty, Maker of heaven and earth, and of all things visible and invisible. > > And in one Lord Jesus Christ, the only-begotten Son of God, begotten of the Father before all worlds, God of God, Light of Light, Very God of Very God, begotten, not made, being of one substance with the Father by whom all things were made; who for us men, and for our salvation, came down from heaven, and was incarnate by the Holy Spirit of the Virgin Mary, and was made man, and was crucified also for us under Pontius Pilate. He suffered and was buried, and the third day he rose again according to the Scriptures, and ascended into heaven, and sitteth on the right hand of the Father. And he shall come again with glory to judge both the quick and the dead, whose kingdom shall have no end. > > And we believe in the Holy Spirit, the Lord and Giver of Life, who proceedeth from the Father, who with the Father and the Son together is worshiped and glorified, who spoke by the prophets. And we believe in one holy catholic and apostolic Church. We acknowledge one baptism for the remission of sins. And we look for the resurrection of the dead, and the life of the world to come. Amen. ### Shared Core Plus Traditions Rather than treating Catholic, Orthodox, Protestant, etc. as completely separate decks, I think it makes more sense to have a shared Christian core and then tradition-specific collections around it. The shared core can contain things such as: * Scripture * Biblical people * Biblical places * Biblical events * Early church history * Major ecumenical councils * Core Christian doctrines * Things generally shared within Nicene Christianity A user does **not** pick one tradition and get locked into it. A Catholic-specific card can be visible to and collected by an Orthodox or Protestant user, and vice versa. I want people to be able to collect every tradition because part of the point is also learning what other Christians actually believe and where traditions differ. The detailed tradition taxonomy now lives in the **Master Card Catalog** rather than being duplicated here. That should be the canonical place for deciding how deep individual tradition collections go. Maybe the user can choose a UI/theme that matches their tradition at some point, but that would be visual and not limit the cards they can collect. ### Controversies / Non-Nicene Movements I still want historical heresies and theological controversies represented because they are genuinely interesting and useful to learn about. I just do not want every disagreement thrown into one generic "Heretic Deck." The Nicene Creed is the line for the application, but there are different kinds of disagreement around that line: * **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** - disputes primarily about 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. This can include things such as Arianism, Gnosticism, Pelagianism, Nestorian controversies, Latter-day Saint theology, Jehovah's Witnesses, and other historically disputed or non-Nicene movements. The cards should be clear about what the person, movement, or teaching actually believed, its historical context, why the issue became controversial, whether it falls inside or outside the Nicene baseline, and how the Nicene position differs when it falls outside it. The application does not need to pretend every theological position is equally compatible with Christianity in order to describe those positions fairly. At the same time, these are still educational cards. They are not insult cards. A label like "heresy" should not replace an actual explanation of what was taught and why it matters. Disagreements within Nicene Christianity should also 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. ### The Trinity Card I no longer think The Father, The Son, and The Holy Spirit should be the highest collectible rarity tier. I do still really like the idea of the Trinity having a unique place in the application though. The working mechanical idea is that during the tutorial - or immediately after skipping it - every user is given **The Trinity** as their first and permanent foundation card. This card is different from every other card in the system: * It is given, not earned. * It cannot be traded. * It cannot be burned or consumed in a trade-up. * It does not participate in normal rarity or population mechanics. The exact name, theological framing, Scripture, artwork, and customization rules still need their own content/art pass. I do not want to force those decisions into the functional spec before they have had enough thought. ## Core Application Loop The rough loop is: 1. Open the application. 2. See today's habits and current pack state. 3. Complete and report habits honestly. 4. Add cards to the day's pack as reward-eligible habits are completed. 5. Open the pack now or leave it sealed for later. 6. Collect cards and variants. 7. Inspect, organize, learn from, and eventually trade cards. 8. Come back tomorrow. The important part is that completing habits adds **more card draws**, not better hidden rarity odds. ## Habit Tracking Ultimately this is still a habit tracker at its base. ### Positive Habit Tracking I want users to be able to track predefined or custom positive habits. Some obvious starting examples are: * Prayer * Bible reading * Weekly church attendance * Study - something like a devotional, a chapter of Christian literature, digging into theology, etc. * Volunteering Habits can have different cadences. For M1 I care about daily, weekly, and monthly tracking. #### Daily habits A user can track as many daily habits as they want, but only **five** can be designated as reward-eligible at a time. Each completed reward-eligible daily habit adds two cards to that day's pack. Changing which daily habits are reward-eligible takes effect the following day. This is not meant as some giant anti-cheat system; it just keeps the meaning of the day's commitment stable. #### Weekly habits Weekly habits are tracked separately from daily habits. A user can track as many weekly habits as they want, but only **three** can be reward-eligible at a time. A weekly habit may require one or more completions during the week. It still occupies one weekly reward slot and awards its two cards only once, when its weekly target has been met. That gives things such as church attendance, Bible study, or volunteering a real place in the reward system without forcing them into an artificial daily cadence. #### Monthly habits Monthly habits are supported as a tracking cadence, but they do **not** generate cards in M1. They can still contribute to history and consistency statistics. If monthly rewards ever become useful, that can be revisited later. #### Retroactive logging Reward-eligible habit completion can be logged through the end of the following calendar day. During that grace period, changes can still add or remove cards from an **unopened** daily pack. Once the pack has been opened, its reward state is final. Older habits can still be edited for history and consistency purposes, but they cannot retroactively change card rewards. ### Consistency Instead of Streaks I don't think positive habits should revolve around streaks anymore. A streak makes one missed day disproportionately destructive. Going from 93 days to "0" is a terrible way to represent someone who completed something 93 out of the last 94 days. Consistency is a much stronger metric. For M1 I want to track: * 7-day consistency * 30-day consistency * 90-day consistency * Lifetime completion rate * Total completions * Returning after time away Consistency is calculated against **scheduled opportunities**, not raw calendar days. If a habit is only scheduled three times per week, the other four days do not count against it. Consistency is informational and does **not** modify card rewards. That is intentional. The person already receives the reward when they complete the habit. I do not want someone who had a rough month to come back and discover that they are also economically disadvantaged because their consistency score fell. We can still recognize consistency milestones or returning after time away with messaging, visual acknowledgement, achievements, binder/profile decoration, etc. Those should remain non-economic. ### Negative Habit Tracking I want there to be an option to track bad habits that someone may have. These can be custom input although we can provide some baseline categories/examples like lust, addiction, smoking, drinking, anger, etc. This tracks separately from the positive habits the user is trying to build. For negative habits, I think there are two useful measurements: #### Abstinence How long has it been since the behavior occurred? This can still naturally be represented as a streak because the elapsed time itself is meaningful here. #### Honesty / Engagement Is the user continuing to truthfully track, return, and work on the problem? This should **not** reset when someone fails. If someone falls after 100 days and reports it honestly, we should not turn that into: > You failed. Everything is gone. Start over. The abstinence count resets because that is simply factual, but the user's larger journey does not. Negative-habit tracking is **economically separate from the TCG**. Abstinence, honest reporting, recovery milestones, and returning after failure do not generate cards or improve pack odds. That avoids creating a system where failure or recovery becomes part of an optimal card strategy, and it avoids making a lapse feel like an additional economic punishment. A positive replacement behavior can still be tracked separately as an ordinary reward-eligible positive habit if the user wants. ### Recovery Milestones After a fall, I like the idea of recovery milestones: * First day back * Three days back * One week back * Other meaningful points we decide on Every milestone should be celebrated, but **not with card packs or rarity rewards**. I do not want to accidentally create some weird side incentive where failure becomes part of an optimal reward strategy. The celebration can be messaging, visual acknowledgement, Scripture, encouragement, etc. ### Failure Messaging Every fall needs to be met with grace and good messaging. The experience I want the morning after someone fails badly is basically: > We are glad you're back. You are still loved. Christ died for our sins. Repent, get back up, and keep moving forward. Every journey begins again with the first step. The exact wording will need theological/content review later, but that is the tone. The application should never make the user feel like they should avoid opening it because they are ashamed of what happened. ### Card Burning / Trade-Up Presentation I still like the visual idea of cards burning, but for M1 I think its best use is as the **trade-up animation** rather than a separate punishment or economy. When ten cards are consumed in a trade-up, they can burn together and form the new higher-rarity card. Any standalone voluntary burning / personal ceremony idea can be deferred. Most importantly, card destruction should never be mandatory punishment for honestly reporting a failure. ## TCG / Collection The whole premise of the "game" is collection. This is the carrot that makes the habits more interesting and hopefully gives the application a real community around it. There is no actual card combat system planned. The fun is collecting, opening, inspecting, organizing, trading, learning, and hunting for rare variants. ### Collection Completion Collection completion is based on **base card identity**. If you own one instance of a card, that identity counts as collected regardless of its finish, material, printing, artwork variant, weight, or other instance-level properties. The initial full catalog is currently **500 base card identities**. I no longer think the useful target is "you should hit exactly 500/500 after one year." Random duplicates naturally make the last few cards much harder than the first few hundred. Using the initial rarity model, the target experience for a maximally consistent user opening normal rewards is roughly: * 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. * Around 99% completion after about one year. Those are economy-model targets, not promises to an individual user. Normal packs do not use duplicate protection or quietly favor cards missing from the user's collection. The final few percent should be a substantially longer collector challenge if someone relies only on random packs. Trading and trade-ups can eventually give people more directed ways to close that gap. Variant collecting is intentionally much deeper than base-compendium completion. Pulling one Moses does not mean there is nothing left to chase for Moses. If someone eventually completes the full base compendium, I still think some kind of prestige/profile/binder recognition could be cool rather than resetting anything. ### Binders Everyone gets a binder that holds their entire compendium that they can look through. Other people can look through a user's public collection/binder if that user allows it. Later we can have different binder designs and different ways to organize cards. This would let someone make dedicated collections such as: * All metal cards * All holographic cards * All foil cards * All Catholic cards * All church-history cards * Whatever other collection they want to show off I previously mentioned microtransactions here, but there is currently no monetization plan. If this somehow becomes large enough that monetization matters, cosmetic binder/profile customization could be revisited later. ### Packs The daily reward is intentionally simple: completing habits gives the user **more draws**, not secretly better draws. #### Daily Pack Every day begins with a **2-card login pack**. Up to five daily habits can be reward-eligible. Each completed reward-eligible daily habit adds **2 cards**. That means: ```text Login only 2 cards 1 / 5 completed 4 cards 2 / 5 completed 6 cards 3 / 5 completed 8 cards 4 / 5 completed 10 cards 5 / 5 completed 12 cards ``` Twelve cards is the maximum normal daily pack for M1. The user can open the pack before finishing the day's habits if they want. Opening it permanently finalizes that day's reward state. If reward potential remains, the application should warn them that opening is irreversible and that later habit completions will still count toward history/consistency but will no longer add cards to that pack. The user can disable this warning in settings. The same warning applies when opening an unfinished previous-day pack during its grace period. #### Weekly Pack Weekly reward-eligible habits build a separate weekly pack. There is no weekly login reward. Up to three weekly habits can be reward-eligible and each completed weekly target adds **2 cards**, for a maximum weekly pack of **6 cards**. A weekly habit can require multiple completions, but it only awards its two cards once when the weekly target is satisfied. Monthly habits do not generate a pack in M1. At maximum reward generation this gives us a clean upper bound of **90 cards per week**: ```text 12 daily cards × 7 days = 84 Maximum weekly pack = 6 ---- Maximum = 90 ``` #### Pack Finalization and Saving Users can save earned packs and open them later. A pack's contents are generated when the pack is **finalized**, not when it is opened. A daily pack finalizes when: * The user opens it early. * It reaches its maximum reward state. * Its reward-eligible grace period expires. When a pack finalizes, the system generates and stores the actual card instances inside it - identity, rarity, finish, material, printing, weight, and whatever other instance properties are active in the economy. Opening later is only the reveal. It does not reroll anything. That means a saved pack can sit unopened indefinitely without being affected by future economy changes, and a client crash during the reveal cannot change what was awarded. It is useful to distinguish the time a card instance was created/finalized from the time it was actually revealed to the user. #### Pack Odds Normal daily and weekly card slots use the same global rarity distribution. Each slot is an independent draw: | Rarity | Pull Probability | | --- | ---: | | Common | 59.00% | | Uncommon | 28.50% | | Rare | 9.00% | | Extraordinary | 2.75% | | Legendary | 0.75% | | **Total** | **100.00%** | Habit completion does **not** change these odds. There are no guaranteed Rare+, Extraordinary+, or Legendary slots in normal packs. Within a rarity tier, eligible card identities initially have equal probability unless we intentionally introduce a different set-specific mechanic later. These are M1 starting values, not sacred constants. They should be configurable and validated through simulation and playtesting. If we rebalance them later, the change should be global and transparent. I do not want probabilities dynamically changing per user behind the scenes to manipulate engagement. #### Pack Types I still think special pack types could be fun later, potentially with different presentation or explicitly different rules. Initial names like Common / Gold / Illuminescent were only placeholders. For M1, the normal daily and weekly reward packs are the important part. Special pack types can be worked out later. ### Pack Opening Experience Opening cards is one of the most important parts of the entire application, so I think this is an area where we can intentionally be a little excessive. Possible opening modes: * Cards in a row, clicking each one to flip. * Cards stacked front-to-back and revealed one at a time. * Auto-open / open all for when the user does not care about the full animation. Rarity can affect anticipation without going full casino. For example, higher-rarity cards can have different pacing, lighting, sound, or reveal animation, but I do not want the application screaming flashing slot-machine effects at people. The reveal should feel special because the card is special, not because we are trying to mimic gambling psychology. Pack-opening presentation should be implemented by the active runtime renderer rather than depending on pre-rendered videos or Blender-authored animation clips. The sequence needs to respond to the cards actually awarded, support user interaction, scale across device capabilities, and remain skippable. The wrapper can be generated from a subdivided procedural mesh with controlled seams, tear paths, peel zones, and spring- or cloth-like deformation. Wrinkles, metallic reflections, particles, lighting, and sound can provide additional realism. A controlled and deterministic simulation is preferable to unrestricted cloth physics because it produces repeatable results, is easier to synchronize, and can degrade gracefully on lower-power devices. Blender is not required even if we pursue convincing wrapper tearing or crumpling. Runtime physics libraries, renderer extensions, skeletal deformation, morph targets, or custom shader deformation may be used where appropriate. Blender or another digital content creation tool remains optional for visual exploration or unusually complex assets. ### Rarity The rarity structure for M1 is: * Common * Uncommon * Rare * Extraordinary * Legendary Rarity represents **prominence within the collection and pull scarcity**, not spiritual worth, holiness, or importance to God. Each base card identity has one canonical rarity. A Legendary card participates in the same Legendary economy whether it represents a Biblical person, historical event, doctrine, tradition-specific subject, or something else. Sets do not define independent rarity probabilities in M1. Finish, material, printing, artwork variant, and weight are separate collectible properties. A holographic Common is still Common, and a plain-paper Legendary should still visually read as Legendary. The current 500-card master catalog is distributed like this: | Rarity | Card Identities | Share of Catalog | | --- | ---: | ---: | | Common | 192 | 38.4% | | Uncommon | 150 | 30.0% | | Rare | 101 | 20.2% | | Extraordinary | 39 | 7.8% | | Legendary | 18 | 3.6% | | **Total** | **500** | **100.0%** | The percentage of identities in a rarity tier is intentionally different from that tier's pull probability. Rarity should also materially affect base composition/framing/presentation rather than just adding more glow. The exact visual rules belong in the Art Direction document. ### Filler Cards I am deferring a dedicated filler-card economy for M1. With a 500-card catalog already in place, I do not think we need a special filler sub-pool just to make duplicates normal or to pad the Common tier. Simple subjects can still exist as perfectly normal Common cards. If economy testing later shows a real need for a high-frequency low-value classification, we can bring the filler concept back then. ### What Makes a Card Unique At a high level, I think a card instance is made up of things such as: * Card Identity * Artwork / artwork variant * Rarity * Finish * Printing * Material * Simulated weight * Provenance / who originally opened it and when There should still be a clean distinction between the base **card definition** and an individual **card instance**. For example: ```text Card Definition David - Card 001 Artwork A Legendary Biblical People Card Instance David - Card 001 Holographic Borderless Metal 128.4g Opened by Daniel Opened on ``` Randomized wear/condition and random imperfections are **not** part of the card-instance model. That general contract should stay renderer-independent. The database should not care whether Three.js or some future engine is displaying the card. ### Finish Finish is an independent collectible property and needs to be visually obvious when interacting with the card. Things such as matte, glossy, textured, holographic, foil, weathered, antiqued, distressed, patinated, or future variations are all art-direction territory. I do not want the functional spec to prematurely lock the finish taxonomy. The exact finish types, composability, compatibility rules, subtypes, and visual implementation belong in [Art Direction](./art-direction.md). What matters functionally is that finish participates in card generation, population grouping, and trade-up inheritance and remains separate from base rarity. ### Printing Printing is an independent collectible property that can materially alter the artwork composition, framing, layout, or text treatment rather than just being metadata. Exact printing types - including what ideas such as Normal, Borderless, Textless, or Boundless actually mean - belong in [Art Direction](./art-direction.md). Functionally, printing participates in card generation, population grouping, and trade-up inheritance. ### Material Each card instance has exactly one material representing its physical substrate. M1 candidates are: * Paper * Linen * Wood * Metal Paper is the default. Material is independent of base rarity and participates in card generation, population grouping, trade-up inheritance, and simulated weight. The exact visual treatment, physical appearance, compatibility constraints, thickness, lighting response, and renderer behavior belong in [Art Direction](./art-direction.md). ### Wear / Condition I am cutting randomized wear / condition from the card-instance model entirely. The more I thought about it, the more it felt like negative variance rather than a fun collector property. Getting the Legendary you wanted in the finish, material, and printing you wanted only for it to be a "bad" damaged copy would feel like being punished for no reason - especially when packs are earned through habits rather than something you can endlessly buy or grind that same day. Finish, material, printing, artwork variants, and rarity already give us plenty of collector depth. We can still intentionally design things such as weathered, antiqued, distressed-parchment, or patinated treatments if they look good. Those should be deliberate visual variants, not a quality score that makes one copy objectively worse. ### Weight I still like the completely unnecessary physical-card idea that cards have simulated weight. Each card instance can have a simulated physical weight derived primarily from its material, with a small deterministic variation and optional minor adjustments from finish/printing. Weight does not affect base rarity, compendium completion, or trade-up eligibility. Eventually there could still be some fun digital-scale idea for unopened packs, but the advanced gameplay around weight is deferred. The metadata itself is cheap enough to keep now. ### Imperfections Cut. I do not want randomized fingerprints, hairs, print defects, or other accidental-looking imperfections as an instance-level collectible system. If we want intentional visual irregularity, it should come from a designed finish, material, printing, or artwork treatment rather than a random defect roll. ### Population / Provenance Cards should retain meaningful provenance such as who originally opened them and when. For population, I want to track meaningful collectible combinations: ```text Card Identity + Artwork Variant + Finish + Material + Printing ``` The system should track both: * Total instances of that combination ever created. * Number of those instances currently surviving. Burning / trade-up consumption reduces the surviving population but does not reduce the historical "ever created" count. Ownership, opener identity, timestamps, trade history, and simulated weight do not create separate populations. I do **not** want to keep an enormous database of fully queryable dead card instances forever just for provenance. Aggregate historical/destruction counters are enough for destroyed cards in M1. For living cards, original opener and opening date remain part of provenance even after trading. Whether population statistics are globally public everywhere can be decided later. ### Card Economy / Destruction M1 will use a straightforward **10-to-1 trade-up system**. A trade-up consumes ten card instances of the same rarity and creates one card from the immediately higher rarity: ```text 10 Common -> 1 Uncommon 10 Uncommon -> 1 Rare 10 Rare -> 1 Extraordinary 10 Extraordinary -> 1 Legendary ``` The rarity upgrade is guaranteed. Trade-ups cannot skip tiers. For M1, the resulting card identity is selected randomly from the eligible identities in the next rarity tier. The identities of the ten inputs do not influence the resulting identity. Set/category targeting can come later. #### Instance-property inheritance Finish, material, and printing from the ten input cards directly influence the corresponding property on the output. Each input contributes an equal 10% share to that property's roll. For example: ```text Finish 10 Holographic -> 100% Holographic output 7 Holographic 3 Matte -> 70% Holographic -> 30% Matte ``` The same idea applies independently to material and printing: ```text Material 5 Metal 3 Paper 2 Linen -> 50% Metal -> 30% Paper -> 20% Linen ``` ```text Printing 8 Normal 2 Borderless -> 80% Normal -> 20% Borderless ``` Each property is rolled independently. That means five Holographic/Paper cards plus five Matte/Metal cards could produce a Holographic/Metal result. If all ten inputs share a property, that property is guaranteed on the output. I like this because low-rarity cards can still have meaningful collector/crafting value. Ten holographic Commons are not just ten generic Commons; they can guarantee a holographic Uncommon. The ten input cards are permanently consumed and leave the surviving population. We should retain aggregate destruction counts rather than full dead-card records. Visually, I like the idea of the ten cards burning together to form the new card. That gives the old burning concept a clear purpose without tying it to punishment or failure. More advanced recipes, targeted identities, targeted sets, and other crafting systems can wait until we have tested this economy. ### Content The full card library is now being managed separately in the **Master Card Catalog**. The current baseline is 500 base identities across Scripture, history, theology, traditions, controversies, people, items, places, events, and other categories. Unless it is a specific printing such as textless, every card should have meaningful text associated with it. Priority for card text: 1. Scripture where directly relevant. 2. Quote where directly relevant. 3. Historical / theological fact. The educational side is important. Pulling something unfamiliar should be an invitation to learn what it is rather than just seeing a rarity number. #### Sources / citations Card content should have source metadata sufficient for someone to understand where factual, historical, scriptural, and doctrinal claims came from. The face of the card should stay visually concise. Full citations and supporting resources belong mainly in the expanded information / learning panel. Where applicable, I want to prioritize: 1. Scripture. 2. Primary historical or theological sources - creeds, council texts, letters, sermons, confessions, catechisms, or writings by the person represented. 3. Tradition-specific authoritative sources when explaining a tradition's teaching. 4. Reputable secondary historical or scholarly sources for context, chronology, interpretation, or claims that cannot be established from a primary source alone. Research tools, general websites, and tertiary summaries can help during research, but they should not be the sole published authority for an important doctrinal/historical claim when something stronger is available. The card face can still show concise references such as a Scripture citation, short quote attribution, council/date, or author/work. Direct quotations need clear attribution. Where practical that means author/speaker, source work, relevant section/chapter/paragraph/page, and translation/edition where wording materially depends on it. If something is genuinely disputed, the information panel should say so rather than flattening the uncertainty. That includes traditional attribution, scholarly disagreement, uncertain dates, and different interpretations among Nicene traditions. Sources belong primarily to the **card definition**, not the individual physical-looking instance. Who ultimately performs doctrinal/historical review is still deferred until we get deeper into actual card writing. ### Art Style I think the current art direction is strong enough that we can treat it as the working direction rather than something completely undecided. The main visual language is: > **Stained-glass-inspired as the primary style, with tapestry / linen and illuminated-manuscript influence as supporting texture and ornament.** The overall target is sacred, beautiful, and stylized rather than hyper-photorealistic or a dense museum reconstruction. Rarity should materially affect the composition and framing rather than just adding more glow. For example: * Common - simple geometric borders, restrained colors, wider / calmer compositions. * Higher rarities - progressively more storytelling, symbolism, ornament, richer framing, and more elaborate compositions. * Legendary - highly bespoke art / framing and much tighter, more iconic presentation where appropriate. Finish and material remain separate from rarity. A Common holographic card is still a Common card, and a Legendary matte-paper card should still visually read as Legendary. The detailed rules for finish taxonomy, printing definitions, material appearance, compatibility, and religious-art depiction belong in [Art Direction](./art-direction.md). At the functional level I only want a few religious-art guardrails: * Treat sacred subjects respectfully and intentionally. * Avoid irreverent, trivializing, or unnecessarily sensational depictions. * Allow tradition-specific visual treatments where traditions genuinely differ. * Use symbolic/non-figurative approaches where literal depiction would be inappropriate, uncertain, or theologically sensitive. * Historical/traditional iconography can inform the artwork where appropriate. * Rarity should never imply greater spiritual worth. The Trinity/Foundation card remains a special art case that needs its own pass. I still expect to lean heavily on LLM/image-generation tooling and MCP servers for creating and iterating on the artwork since I am a software engineer, not an artist. ## Visual Experience The visual experience is not just decoration for this application. Opening and physically inspecting the collectible is part of the reward. ### Card Interaction Cards should be represented as tactile physical objects rather than static collectible images wherever practical. When inspecting a card, the user must be able to: * Rotate the card freely. * Flip between front and back. * Zoom in to inspect artwork and physical characteristics. * Observe material and finish properties responding dynamically to lighting. * Return quickly to the originating collection/binder context. Card finish and material must have visually distinguishable properties. For example, foil, holographic, paper, linen, wood, and metal cards should not all react to lighting in the same way. Lower-power devices must be able to fall back to simplified visual representations without affecting gameplay. ### Where 3D Is Used I do **not** think every card in every screen should be an actively rendered 3D object. The primary 3D use cases should be: * Pack openings * Full card inspection * Potentially special collection/showcase views later Normal binder pages, search, trading lists, etc. can use static or pre-rendered thumbnails until the user chooses to inspect a card. This should keep the application responsive while still making the moments that matter visually interesting. ### Visual Properties Should Matter If we add a collectible property, the user should ideally be able to see or interact with it somehow. For example: ```text Finish -> visible Material -> visible Printing -> visible Weight -> indirectly observable Provenance -> inspectable metadata Population -> inspectable metadata ``` Otherwise there is not much point in storing increasingly complicated metadata that never changes the actual experience. ## Social Interaction The other important aspect of card collections is trading and having some kind of community around them. I still want friends and accountability partners to be intentionally different concepts because someone may want to trade/show collections to a lot of people while keeping accountability very private. None of the multiplayer/social system is required for M1. The first build should be able to function fully locally. ### Future Social Functionality Things I still think would be great later: * View another user's public compendium / binder. * Offer trades. * Add friends. * Add explicit accountability partners. * Send predetermined messages of encouragement. * Send Scripture / verses. * Send generic prayer requests without revealing why. If a user makes their collection/binder public, useful visible card metadata can include: * Card ownership. * Finish / material / printing. * Original opener. * Opening date. * Population information. * Trade history. The original opener should continue to persist after a card is traded. I do not currently want provenance anonymization. Destroyed cards do not need to remain individually visible in historical collection records. Aggregate population/destruction counts are enough. Whether population data is globally public outside the context of someone's collection can be decided later. ### No General Chat I do not want general chat integration. That creates a massive moderation problem and can very quickly turn into the application becoming a social network instead of the thing I actually want to build. Predetermined messages and controlled interactions should cover most of what is useful here without adding an entire moderation product. ### Accountability All habit tracking is private unless explicitly opened to accountability partners. Even then, the default shared state should be obscure rather than detailed. For example: > Daniel asked for prayer today. rather than: > Daniel failed Habit X at 9:42 PM. The exact accountability permission levels and what triggers a prayer/accountability signal are deferred for now. If we later allow detailed sharing of encrypted habit content, that needs to preserve the privacy model rather than making the server readable just because another user is involved. ## Monetization I genuinely have no real plan to make money off this right now. My current plan is to build it, use it myself, and try it with friends. If it somehow blows up in popularity, then infrastructure costs and monetization can be figured out later. One thing I do want to make an explicit product principle now: **Absolutely no paid loot boxes or buying better pack odds.** Gambling already ruins lives and building that psychology into an application that is supposed to help people grow in Christ would be anathema to what I am trying to accomplish. If monetization ever becomes necessary, things like purely cosmetic binder designs, profile customization, or other non-random features can be considered separately. Money should not buy spiritual-habit rewards or manipulate rarity odds. --- ## Integrations I still think API and webhook support would be useful eventually so the application can integrate into other things. Examples: * Fluxer bot * Discord bot * Other automation / personal tooling Exactly what gets exposed and when is a technical/API-spec question. This is not a priority for M1. --- ## M1 / First Build There is not really a formal deliverable or deadline right now. This is a project I want to build because the product is interesting and some of the technical problems are fun. For the first real build, I want something closer to a **fully working local vertical slice** than a multiplayer production launch. The important thing is that the whole core experience works locally end-to-end. ### Initial M1 Scope Something like: * Web client first. * Works on desktop and mobile browsers. * Fully functional locally; multiplayer is not required. * Positive habit tracking. * Negative habit tracking with abstinence + honesty/engagement concepts. * Daily, weekly, and monthly habit cadences. * Consistency metrics instead of positive-habit streaks. * Daily 2-12 card pack/reward flow. * Separate 0-6 card weekly reward pack. * Ability to save packs. * Around **50 real cards** drawn from the Master Card Catalog, with a few representatives from each major category. * Multiple rarity levels. * Multiple finishes/materials/printings. * 10-to-1 trade-ups with instance-property inheritance. * Binder / compendium. * Full 3D card inspection. * 3D pack-opening flow. * Basic population/provenance model. * Simulated card weight metadata. * Enough economy simulation to begin validating rarity math. I would rather have **50 cards where all of the difficult rendering/material/variant systems actually work** than hundreds of cards that are basically static images. The full catalog can still contain 500 identities. M1 only needs a representative subset actually implemented. Randomized wear/condition and randomized imperfections are cut from the design. Filler-card economics, multiplayer trading, and advanced social behavior are not required for M1. ### Not Required for M1 Likely later: * Multiplayer/social backend. * Native Android/iOS applications. * Full trading economy. * Advanced accountability sharing. * API/webhook ecosystem. * Full 500-card production content rollout. * Digital pack scale / advanced weight mechanics. * Deep achievement/prestige systems. * Monetization. * Dedicated filler-card economy. ### M1 Art-Direction Rules See [Art Direction](./art-direction.md). ### M1 Collection Use around **50 cards from the Master Card Catalog**, with enough variety across categories and rarities to exercise the real renderer and economy. The exact list should live in the catalog rather than being duplicated here so the two documents do not drift. A handful of deliberately difficult "hero" cards should still exercise things such as: * Holographic/foil treatment. * Metal. * Borderless or other unusual printings. * Emissive/fire. * Water/specular effects. * Text-heavy layouts. * Linen/paper/embossing. * Large environmental compositions. ## Initial Technical Direction The functional requirements should stay mostly engine-independent, but the way the cards look and behave is important enough that rendering architecture matters early. ### High-Level Direction The web client is the M1 target because it gives us something usable on desktop and mobile browsers immediately. Three.js won the renderer spike and is the current runtime rendering direction for the web client. The exact surrounding web framework belongs in the technical spec. The important part is still that the **shared card model remains renderer-independent**. Card identity, artwork references, rarity, finish, material, printing, weight, provenance, etc. should not be encoded as Three.js-specific database structures. ### Card Rendering Contract The renderer should receive a contract describing what the card is rather than the database storing engine-specific details. Very rough example: ```json { "cardId": "david-001", "artworkId": "david-a", "finish": "holographic", "material": "metal", "printing": "borderless", "weightGrams": 128.4 } ``` Then Three.js interprets that contract. That keeps room for another renderer in the future without touching the card economy or rewriting the backend/shared model. ### Asset / Renderer Direction The runtime renderer should own the standard card geometry, materials, lighting, card flips, inspection interactions, and pack-opening animation. Artwork, masks, card metadata, and finish/material/printing selections should remain engine-independent inputs. Blender is not a production dependency for standard cards or pack openings. It can remain useful for visual exploration, promotional renders, material experiments, or future bespoke 3D assets. The detailed shader/material architecture has already been explored in the **card-harness spike** and belongs in the technical/art implementation documentation rather than being duplicated here. Static/pre-rendered thumbnails for binder/search views can be spiked later. I am not married to a particular thumbnail architecture yet; we can optimize that once the main renderer is working. ## Deferred / Separate-Spec Questions A lot of the old open questions are now decided. The things I intentionally do **not** want to force into this functional spec yet are: ### Trinity Card * Final name / exact theological framing. * Final Scripture. * Artwork. * Exact customization behavior. ### Content / Art * Who ultimately performs doctrinal and historical content review. * Exact finish taxonomy. * Exact printing taxonomy and visual definitions. * Material/finish/printing compatibility exceptions. * Detailed religious-art/iconography rules. Those belong primarily in the Master Card Catalog and Art Direction documents. ### Privacy / Accountability * Exact cryptographic/key-recovery implementation. * Multi-device encrypted synchronization. * Detailed accountability permission levels. * Exact triggers for prayer/accountability signals. Those belong in the technical/security spec or a later accountability pass. ### Economy / Collection * Dedicated filler-card economy. * Exact finish/material/printing generation probabilities. * Special pack types. * Advanced/targeted trade-up recipes. * Whether population statistics should be globally public. * Full trading rules. * Advanced weight/pack-scale mechanics. ### Technical * Exact web framework. * Static thumbnail architecture. * Future native renderer/client architecture. * API/webhook implementation. The renderer itself is no longer an open question for M1: **Three.js is the current choice**. ### Product / Roadmap * Monetization. * Native Android/iOS. * Full multiplayer/social launch. * Deep prestige/achievement systems. * Full 500-card production rollout timing.