Sanctification/functional-spec-v2.md

Christian Habit Tracker TCG - Functional Spec v2

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 customer content to be encrypted in a way where the server cannot casually read it. Statistics can still exist where possible, but content such as a user's sins, struggles, custom habit names, notes, etc. should not just be plaintext sitting in the database for a server administrator to inspect.

Exactly how we accomplish this is more of a technical-spec question. Client-side encryption and potentially some kind of BYOK design are worth exploring. The important functional requirement is that private content should be private even from us as much as reasonably possible.

Accountability sharing should also 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 user can explicitly choose to share more detail if they want to.

---

Christianity

At the core foundation, what we consider Christianity for the purposes of this application is currently founded in the words and logic of the Nicene Creed.

This is the standard for now and can be revisited later if needed.

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

Tradition-specific collections can then include:

• Catholic
• Orthodox
• Protestant
• Potentially more specific traditions later

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.

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 don't think a generic "Heretic Deck" is the best structure.

This can include things such as:

• Arianism
• Gnosticism
• Pelagianism
• Nestorian controversies
• Mormonism / Latter-day Saint theology
• Jehovah's Witnesses
• Other non-Nicene or historically disputed movements

The card should explain what the person/movement taught, why it became controversial, and how it differs from the Nicene standard we are using for the application.

The card cannot contain all the information so we can also make sure to have a panel for more information or resource links to learn more about it. It can help explain the position, why it matters historically/theologically, and how it compares to the Nicene standard. They aren't insult cards.

This should be educational rather than just putting a big "HERETIC" stamp on people and calling it a day.

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.

One idea is that during the tutorial - or immediately after skipping the tutorial - every user is given The Trinity as their first and permanent card.

This card would be different from every other card in the system:

• It is given, not earned.
• It cannot be traded.
• It cannot be destroyed.
• It is always considered mint condition.
• The user can customize the finish/material presentation however they like without affecting rarity or the economy.
• It does not participate in normal rarity or population mechanics.

The symbolism I like here is that the most important thing in the collection is something you did not grind for or earn. It was given to you and you cannot lose it.

The exact theological messaging obviously needs some thought because traditions differ on some of the implications there, but I think the overall meaning is good.

Initial verse thought: John 3:16. It seems like a pretty decent fit for the idea of something given rather than earned.

The artwork for this card also needs special consideration. I do not want us to accidentally make some weird literal depiction of the Father / Son / Holy Spirit just because we need card art.

---

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. Improve the day's reward / pack.
5. Open it now or save it for later.
6. Collect cards and variants.
7. Inspect, organize, learn from, and eventually trade cards.
8. Come back tomorrow.

The exact pack reward model still needs to be worked through.

---

Habit Tracking

Ultimately this is still a habit tracker at its base.

Positive Habit Tracking

I think initially we will start with a couple of base good habits to build on:

• Prayer
• Bible reading
• Weekly church attendance
• Study - something like a devotional, a chapter of Christian literature, digging into theology, etc.
• Volunteering ?* - I am still not sure how to track this cadence. It doesn't feel like a daily thing but it is also obviously a category that builds Christian values.

Custom habits can come later or be included early depending on how much work it ends up being.

You can log up to the day prior and still receive whatever reward that day qualified for.

You can always log older days/weeks of progress toward habits for your own records and consistency statistics, but they should not generate retroactive packs indefinitely.

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.

We can track things such as:

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

The exact windows and which ones affect rewards are still subject to change.

This also gives us more interesting achievement opportunities without making the user feel like one missed Tuesday erased three months of work.

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.

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.

Voluntary Card Burning

I still like the visual and ceremonial idea of burning a card. I just don't want it attached to mandatory punishment for honestly reporting a failure.

Maybe card burning becomes voluntary.

Possible uses:

• A user voluntarily burns a card as part of some personal ceremony / reset.
• Burning duplicates becomes part of the card economy.
• Cards can be consumed in future crafting/trade-up systems.

The exact implementation is still open.

---

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

I still like the general idea that collecting one of every base card by yourself should take something like at least a year of very consistent usage.

That number is very subject to change once we actually model the economy and start testing it.

If someone completes the full base compendium, regardless of finish/material/etc., I think some kind of prestige system could be cool.

Maybe it decorates the profile or binder rather than just resetting everything.

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

I still need to deliberate on exactly how packs are awarded, how many cards each pack contains, and all of the statistics behind them.

Working Daily-Pack Idea

I still like having some kind of login pack because it establishes the initial hook.

The user opens the app and sees the pack, which can immediately remind them:

Oh right. I need to actually accomplish my tasks today.

One idea I like more than simply giving one pack per task is that the daily pack upgrades as tasks are completed.

For example:

• Login / start of day - very weak pack or only a couple cards.
• Complete one task - improve the pack.
• Complete additional tasks - improve odds, card count, or pack quality.
• Complete everything for the day - reach that day's maximum pack state.

This keeps the login hook without making simply opening the application equivalent to actually doing the habits.

I am not sure yet whether task completion should:

• Improve rarity odds.
• Increase the number of cards in the pack.
• Improve expected wear / quality.
• Upgrade the pack type itself.
• Use some combination of the above.

I particularly like the idea that the initial login pack might only have something like two cards and completing tasks adds additional cards to it. That may feel less casino-like than constantly manipulating rarity odds, but we need to test it.

Saving Packs

Users can choose to save earned packs and open them later.

Some people may want to open every day. Other people may want to save ten or twenty packs and have one larger opening session.

Once a day's pack is finalized, saving it should not continue to improve it later unless we intentionally design a mechanic around that.

Pack Odds

Pack probabilities should initially be globally fixed.

We should still wire the probability variables in a way where they can be adjusted later if testing shows that the economy is developing too quickly or too slowly.

I do not want probabilities dynamically changing per user behind the scenes just to manipulate engagement.

Pack Types

I still think different types of packs could be fun, with different expected card qualities or presentation.

Initial placeholder ideas:

• Common / normal
• Gold
• Illuminescent

Names and exact meaning are still TBD.

Different packs can have different opening animations.

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.

Rarity

I still want different tiers, although I want to find better Biblical/thematic names for them eventually.

Placeholder tiers:

• Common
• Uncommon
• Rare
• Extraordinary
• Legendary

Rarity should represent prominence within the collection, not spiritual worth, holiness, or importance to God.

I also really like the idea that different sets can have independent rarity structures.

For example, rarity within a Biblical People set does not necessarily need to mean the exact same thing as rarity within a Church History set or a Catholic collection.

This needs more work when we start building the actual card catalog.

What Makes a Card Unique

At a high level, I think a card instance is made up of things such as:

• Card Identity
• Artwork
• Rarity
• Finish
• Printing
• Material
• Wear
• Potential imperfections
• 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:

Card Definition
    David - Card 001
    Artwork A
    Legendary
    Biblical People Set

Card Instance
    David - Card 001
    Holographic
    Borderless
    Metal
    97.3% condition
    Opened by Daniel
    Opened on <date>

That general contract should be renderer-independent. The database should not care whether Three.js, Flutter Scene, or some future engine is displaying the card.

Finish

Possible finishes:

• Matte
• Glossy
• Textured
• Holographic
• Foil
• Potentially multiple kinds of holographic/foil patterns later

Different finishes should be visually obvious when interacting with the card. A holographic card should not just have a little "Holographic" tag underneath it.

Printing

Placeholder printing types:

• Normal
• Borderless
• Textless
• Boundless

These can materially alter the card artwork/layout rather than just being metadata.

Material

Possible materials:

• Paper
• Plastic
• Wood
• Linen
• Metal

Material should affect the way the card looks and reacts to light.

Wear / Condition

I still like every normal card instance having a wear/condition value between 0.00 and 1.00, but I am reconsidering what the low end actually looks like.

1.00 would be essentially pristine.

0.00 does not need to mean the card looks like it went through a washing machine. It could still be clearly readable and attractive, just visibly scratched / worn / damaged compared to a mint card.

We can expose condition to users as percentages and named bands.

Very rough example:

• Mint: 1.00 - 0.95
• Minimal Wear: 0.95 - 0.75
• Additional bands: TBD

The actual ranges need to be modeled and tested rather than guessed here.

The wear value should affect visible rendering where practical:

• Edge whitening
• Surface scratches
• Small scuffs
• Roughness changes
• Other subtle damage

Even poor-condition cards should still look like something someone wants to collect.

Weight

I still like the completely unnecessary physical-card idea that cards have simulated weight.

Cards might have a baseline around 100g with slight variance, while material/finish can add or subtract minor amounts.

Eventually there could be an achievement or unlockable digital scale that lets the user weigh an unopened pack and try to infer what might be inside.

This is very much a future fun feature and not core functionality.

Imperfections

This is still a maybe.

We could generate some number of masks for things like:

• Fingerprints
• Hair
• Minor print artifacts
• Surface marks

Then an individual card instance could have a very small chance of receiving one based on a deterministic seed.

This would make otherwise-identical variants slightly more interesting.

Population / Provenance

Cards should retain metadata about when they were opened and who originally opened them.

I also like tracking population for meaningful combinations such as:

Card ID + Finish + Printing + Material

That way someone can see that their metallic holographic borderless Adam is 1 of 1, while another combination may already have 1,000 copies.

I don't think wear, weight, and individual imperfections should count toward this population grouping because then effectively everything becomes a fake 1-of-1.

Card Economy / Destruction

This is one area I want to work on more specifically.

One mechanic that might be useful is some kind of trade-up / crafting system similar in spirit to Counter-Strike trade-ups.

For example:

Consume 20 Common cards to generate 1 Uncommon card.

The exact number and output obviously need to be modeled.

I like this because it gives duplicates a use while also permanently removing cards from circulation.

Questions we need to answer later:

• Is the output guaranteed to be the next rarity?
• Does finish/material influence the result?
• Can users choose which set the resulting card comes from?
• Are some cards protected from trade-ups?
• Does a burned/traded-up card remain in provenance history as destroyed?

I think actual destruction can become an important sink in the economy, but it should mostly be voluntary rather than punishment.

Content

I want to eventually have a very large repository of cards.

Possible categories include:

• People
• History
• Icons
• Items
• Places
• Events
• Theologians
• Theology
• Apologetics / arguments
• Councils
• Traditions
• Controversies
• Probably many more once we actually start cataloging things

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.

There should also be a way to click through and learn more or understand why the text/artwork is associated with that card.

The educational side is important. Pulling something unfamiliar should be an invitation to learn what it is rather than just seeing a rarity number.

Art Style

I still have not decided how I want the cards themselves to look.

This is something where I will probably lean heavily on LLM/image-generation tooling and MCP servers to help explore art direction since I am a software engineer, not an artist or 3D modeler.

I think we should generate a bunch of visual directions before committing to one common design language.

Tradition/set flavor can affect things such as:

• Colors
• Borders
• Typography
• Card backs
• Ornamentation
• Maybe 3D material treatment

---

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 properties responding dynamically to lighting.
• Observe wear and imperfections where applicable.
• Return quickly to the originating collection/binder context.

Card finish and material must have visually distinguishable properties. For example, foil, holographic, paper, linen, and metal cards should respond differently to lighting.

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:

Finish        -> visible
Material      -> visible
Wear          -> visible
Imperfections -> 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.

Users can have friends and accountability partners. Those are intentionally different concepts because someone may want to trade/show collections to a lot of people while keeping accountability very private.

Initial Social Functionality

Things I think would be great:

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

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 user can choose to share exact habits/details with a specific accountability partner if they want to.

This avoids both hubris and shame - neither of those is the point of the project.

---

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 the first MVP.

---

MVP

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.

Since I am a software engineer and not an artist or 3D modeler, I expect to lean on LLMs, MCP servers, image generation, and other tooling to help with those parts.

I think the MVP should intentionally focus on the difficult / interesting pieces rather than spending months filling out content.

Initial MVP Scope

Something like:

• Web client first.
• Works on desktop and mobile browsers.
• Basic account/authentication.
• Positive habit tracking.
• Negative habit tracking with abstinence + honesty/engagement concepts.
• Consistency metrics instead of positive-habit streaks.
• Daily pack/reward prototype.
• Ability to save packs.
• Around 50 real cards.
• Multiple rarity levels.
• Multiple finishes/materials/printings.
• Wear rendering.
• Binder / compendium.
• Full 3D card inspection.
• 3D pack-opening flow.
• Basic population/provenance model.
• Enough economy simulation to begin testing rarity math.

I would rather have 50 cards where all of the difficult rendering/material/variant systems actually work than 500 cards that are basically static images.

The rendering canvas, shaders/materials, and card pipeline are some of the more interesting technical challenges to me.

Wiring up a backend to a client, normal CRUD, auth, API calls, etc. are much more familiar problems and can be fleshed out separately in the technical spec.

Not Required for the First MVP

Likely later:

• Native Android/iOS applications.
• Full trading economy.
• Advanced social functionality.
• API/webhook ecosystem.
• Huge card catalog.
• Digital pack scale / weight mechanics.
• Deep achievement/prestige systems.
• Monetization.

MVP art-direction rules

Seen in Art Direction

Sample MVP Collection

Permanent starter

ID	Card	Type	Notes
S-001	The Trinity	Foundation	Permanent, nontradeable, cannot be burned or consumed, always mint. User can choose/customize finish/material/printing. Suggested verse: Matthew 28:19.

Others

#	Card	Category / Set	Working Rarity	Content / Visual Hook
001	Adam	Scripture · Person	Rare	Genesis 2–3. Excellent portrait/environment card; Eden imagery.
002	Eve	Scripture · Person	Rare	Genesis 2–3. Companion visually to Adam without making them a paired requirement.
003	Noah	Scripture · Person	Uncommon	Genesis 6–9. Rain, ark, rainbow imagery.
004	Abraham	Scripture · Person	Extraordinary	Genesis 12–22. Stars/sky imagery could make an excellent foil.
005	Sarah	Scripture · Person	Uncommon	Genesis 18, 21.
006	Moses	Scripture · Person	Legendary	Burning bush / Sinai gives us several strong artwork directions.
007	Ruth	Scripture · Person	Common	Book of Ruth. Wheat-field imagery; intentionally beautiful despite Common rarity.
008	David	Scripture · Person	Legendary	Shepherd/king imagery. Could support multiple artwork printings eventually.
009	Elijah	Scripture · Person	Rare	1 Kings 17–19. Fire-heavy card effects would be useful renderer testing.
010	Isaiah	Scripture · Person	Rare	Isaiah 6 / prophetic imagery.
011	Jonah	Scripture · Person	Common	Jonah. Strong visual identity even at Common.
012	Mary	Scripture · Person	Extraordinary	Luke 1–2. Could eventually have tradition-specific artwork variants.
013	Joseph of Nazareth	Scripture · Person	Uncommon	Matthew 1–2.
014	John the Baptist	Scripture · Person	Rare	Matthew 3 / John 1. Water/wilderness imagery.
015	Peter	Scripture · Person	Legendary	Gospels / Acts. Keys could appear in some tradition-specific printings without defining the base card around them.
016	Paul	Scripture · Person	Legendary	Acts 9 + epistles.
017	Mary Magdalene	Scripture · Person	Rare	John 20. Resurrection witness gives the card a clear textual focus.
018	Stephen	Scripture · Person	Common	Acts 6–7.
019	Timothy	Scripture · Person	Common	Acts 16 / Timothy.
020	Gabriel	Scripture · Angel	Rare	Luke 1. Visually lets us test a non-human person card.
021	Creation	Scripture · Event	Extraordinary	Genesis 1. Very different composition from portrait cards.
022	The Flood	Scripture · Event	Uncommon	Genesis 6–9. Water/rain shader experimentation.
023	The Exodus	Scripture · Event	Extraordinary	Exodus 12–14. Sea/fire/cloud imagery.
024	The Ten Commandments	Scripture · Event	Rare	Exodus 20. Stone/tablet materials make this particularly useful visually.
025	The Nativity	Scripture · Event	Extraordinary	Luke 2.
026	The Baptism of Jesus	Scripture · Event	Rare	Matthew 3.
027	The Last Supper	Scripture · Event	Rare	Luke 22 / 1 Corinthians 11.
028	The Crucifixion	Scripture · Event	Legendary	Central subject, but rarity represents prominence in this collection rather than "holiness."
029	The Resurrection	Scripture · Event	Legendary	Excellent candidate for one of the MVP's most visually elaborate cards.
030	Pentecost	Scripture · Event	Extraordinary	Acts 2. Fire/light effects.
031	The Ark of the Covenant	Scripture · Item	Rare	Exodus 25. Excellent first metal/gold-material showcase.
032	Bethlehem	Scripture · Place	Common	Micah 5:2 / Luke 2.
033	Jerusalem	Scripture · Place	Rare	Lets us establish how location cards differ visually from person/event cards.
034	The Sea of Galilee	Scripture · Place	Common	Strong environmental artwork; water reflection testing.
035	The Empty Tomb	Scripture · Place	Extraordinary	Resurrection-associated without duplicating the Resurrection event card.
036	The Nicene Creed	Core · Doctrine/History	Legendary	Basically the thesis statement for the app's doctrinal baseline.
037	The Council of Nicaea	Church History · Event	Extraordinary	AD 325. Also introduces historical-event cards outside Scripture.
038	Athanasius of Alexandria	Church History · Theologian	Rare	Natural connection to Nicaea and the Incarnation.
039	The Incarnation	Core · Theology	Extraordinary	John 1:14 provides a strong scriptural anchor.
040	The Resurrection of the Dead	Core · Theology	Uncommon	1 Corinthians 15 / Nicene Creed.
041	The Great Commission	Core · Teaching	Uncommon	Matthew 28:18–20.
042	The Lord's Prayer	Core · Teaching	Common	Matthew 6:9–13. Good example of a Common card that everyone should still want.
043	The Sermon on the Mount	Core · Teaching	Uncommon	Matthew 5–7.
044	The Rosary	Catholic · Item/Practice	Uncommon	Tests explicitly tradition-specific educational material.
045	Christ Pantocrator	Orthodox · Icon	Rare	Gives the MVP an actual icon card and a very different visual format.
046	Martin Luther	Protestant · Theologian	Rare	Reformation history; explicitly Protestant-tagged while collectible by everyone.
047	The Book of Common Prayer	Protestant · Item/History	Uncommon	Anglican-specific, which also starts proving that "Protestant" doesn't need to be treated as one monolithic tradition.
048	Arianism	Controversies · Theology	Uncommon	Explain what Arius taught, why Nicaea responded, and what the Nicene position is.
049	The Latter-day Saint Movement	Controversies · Movement	Uncommon	Educational treatment; explain where its doctrine of God differs from the app's Nicene standard.
050	Jehovah's Witnesses	Controversies · Movement	Uncommon	Same approach: describe rather than mock, then clearly compare with the Nicene baseline.

I'd choose maybe 10 "hero cards" and deliberately make them exercise the most difficult rendering features:

Hero card	Rendering experiment
Moses	emissive/fire
Elijah	foil + fire
Creation	borderless + large environmental artwork
Exodus	animated/specular water
Resurrection	premium holographic treatment
Pentecost	emissive/fire
Ark of the Covenant	metallic gold
Nicene Creed	text-heavy card
Christ Pantocrator	textured/icon treatment
Book of Common Prayer	linen/paper/embossing

---

Initial Technical Direction

The functional requirements should stay mostly engine-independent, but the way the cards look and behave is important enough that we need to consider rendering architecture early.

High-Level Architecture

The web client is the MVP because it gets us something usable on desktop and mobile devices immediately.

Native Android/iOS are still the north star if the project proves worth continuing.

                     Backend / API
                          |
                  Shared Card Model
                          |
               +----------+----------+
               |                     |
          Web Client              Flutter Client
           (MVP)                 (Android / iOS)
               |                     |
        +------+-------+      +------+-------+
        |              |      |              |
    Normal UI     3D Renderer  Flutter UI   3D Renderer

The important part is that the shared card model and backend contracts are renderer-independent.

Card Rendering Contract

The general idea is that the renderer receives a contract describing what the card is rather than the database storing engine-specific details.

Very rough example:

{
  "cardId": "david-001",
  "artworkId": "david-a",
  "finish": "holographic",
  "material": "metal",
  "printing": "borderless",
  "wear": 0.973,
  "imperfectionSeed": 81251
}

Then the active renderer interprets that contract.

That gives us room to use different renderers on different clients without touching the card economy or rewriting the backend model.

Asset Pipeline

Current direction:

Blender / generated assets
        |
        v
    glTF / GLB
        |
        v
  Runtime Renderer

Blender would be useful for card geometry, UVs, some material authoring, normal maps, embossing, etc.

More advanced holographic/foil/view-dependent effects will probably need to be handled in the runtime renderer rather than assuming every Blender shader can just be exported as-is.

Renderer Technical Spike - Next Step

The next major technical question should be a renderer spike comparing:

Three.js

Likely strongest candidate for the web MVP and probably via React Three Fiber if the web application is React-based.

Things to test:

• Holographic materials
• Foil
• Metal
• Wear masks
• Lighting
• Rotation/zoom/touch controls
• Pack-opening animation
• Mobile browser performance

Flutter Scene / Flutter GPU

Worth testing because native Android/iOS are the eventual goal and a good result here could let us build a native renderer without embedding the web renderer forever.

Things to test should be the same so we are comparing real output rather than toy demos.

Prototype the Hard Card

Instead of testing with a plain paper Common card, the technical spike should deliberately build something absurd:

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

If both renderers can handle the hardest card nicely, normal cards should be straightforward.

The spike should compare:

• Visual fidelity
• Shader/material flexibility
• Performance on desktop
• Performance on mobile
• Touch interaction quality
• Developer ergonomics
• Asset pipeline complexity
• How much renderer code can realistically be shared between web and future native clients

We can decide the rendering engine after that rather than locking ourselves in beforehand.

---

Open Questions / Areas to Workshop

Pack Economy

• How many cards are in the initial login pack?
• Does each completed task add cards, improve rarity, improve condition, upgrade the pack, or some mixture?
• How large should the difference be between an untouched login pack and a fully upgraded daily pack?
• How do weekly habits such as church attendance affect the pack?
• Are there separate weekly/monthly packs even though we are moving away from streaks?
• How quickly should one person be able to complete the base compendium?

Rarity / Trade-Ups

• Exact rarity probabilities.
• Exact expected supply assuming perfect habit completion.
• How set-specific rarity works.
• How many lower-rarity cards are required for a trade-up.
• Whether finish/material/printing affect trade-up outputs.
• What happens to destroyed-card provenance.

Wear

• Exact condition bands.
• Lowest acceptable visual condition.
• Whether higher rarity cards have condition floors.
• How heavily wear should affect collectability/value.

Trinity Card

• Final name.
• John 3:16 or another verse.
• Artwork that communicates the idea without bad or irreverent depiction.
• How customizable finishes/materials should look.

Christian Content

• Who ultimately reviews doctrinal/content accuracy?
• How deep tradition-specific collections go.
• Exact taxonomy for controversies / non-Nicene movements.
• How citations/sources are stored and displayed on cards.

Rendering

• Three.js vs Flutter Scene technical spike.
• Exact web framework.
• Shader/material design.
• Asset-generation workflow with Blender + AI tooling.
• Static thumbnail generation from the same card contract.

Social / Trading

• When trading belongs in the roadmap.
• Whether population numbers are public by default.
• How offers work.
• Whether destroyed cards remain visible in historical collection records.
• What parts of a user's binder/profile are private versus public.

Privacy

• Exact client-side encryption model.
• Whether BYOK is practical for normal users.
• Account recovery when encryption keys are lost.
• What anonymous/statistical data can be collected without weakening the privacy model.
• Exact accountability-sharing permissions.