The Homework Board

Wayfinder was selected as the winning shape for the Journey vault (from the Shape Lab in roots-jar-compare.html — angular, octagonal edges like a compass housing). However, the session ended on HOLD because the orb animations inside the jar had drifted significantly from Ashley's preferred style. Before closing out this card: (1) Ashley needs to find the reference file or session showing the orb animation style she preferred, (2) open the ROOTS_Development session to pick up where we left off, (3) restore orb animation to the preferred style, then (4) finalize and commit the Wayfinder as the official Journey vault shape across all product pages. Do not change the Wayfinder shape decision — that is locked. Only the animation style is open. Added 04.12.26.

The emotional-design direction for the home screen: quiet, hopeful, intentional, uncluttered. No ads, no chaotic feeds. Users see a soft horizon timeline with floating seeds drifting at different depths — closer = blooming soon, distant = years away. Looking forward in life, not scrolling backward.

Periodic gentle wind passes through the dandelion every 8–14 seconds. Front seeds sway more than back seeds (parallax). Occasionally a single seed catches a stronger gust and drifts a few pixels off its base before settling. Background gradient subtly shifts to suggest the wind passed through. Differentiation: most app dandelions are static or single-loop — "wind that comes and goes" makes the screen feel like a living place, not a graphic.

Each active seed on the dandelion colored by its time-distance bucket (Purple 1+ year / Sky 31-364 days / Gold 0-30 days / Gold-Light imminent / Sage bloomed — per the locked spec). At a glance, the dandelion's overall color tells you the state of your entire memory portfolio. Implementation: already supported by color system — just apply per-seed instead of global. Low effort, high information density.

Second-highest-leverage concept. Tap a vault chip → that vault's seeds glow in vault color, others dim, faint gold lines connect the seeds into a constellation. Solves a real problem (how do you see "what's in this vault" without leaving the dandelion?) AND adds visual delight. The constellation metaphor pairs with "your memories are stars across time." Prototype interactive in TEMP-dandelion-concepts.html. Ashley feedback 2026-04-24 evening: "Constellation mode feels better, softer, elegant. Love the stem glow!" — promoted to flagship-tier. Asked whether this is "just filtering" — answer: core mechanic IS filtering, but with two visual upgrades that make it feel alive (selected stems shift to vault color, gold connecting lines show belonging).

A subtle new state between "Blooming Soon" (gold) and "Bloom Now" (gold-light). When a seed is within ~24 hours of blooming, its glow develops a faster fluttering whisper — almost like a held breath. Users who check the app often will notice the whisper start and feel the bloom approaching. Tiny UX gift for attentive users. Low effort — extends existing pulse system with a 4th speed tier.

The biggest concept. Alternate "Home / Discover" view replacing the static vault grid. Translucent 3D dandelion sphere floats in a star-flecked sky. Seed-fluffs stick out in all directions — drag to spin the globe, release and it idle-drifts at ~120s/revolution (Apple Maps pattern). Seeds you've forgotten about drift into view from the back of the sphere. Built in pure Canvas 2D with 3D math in TEMP-dandelion-globe.html — no Three.js dependency so Josh can port directly. From Inspiration Library Entry 013.

Ashley flagged the current Unsealing Flow V3 visual in brand-vault-renditions.html as "pretty poor." Deep read identified 3 specific failures: (1) timing desync — lid fades at ~1.35s but dandelion keeps scaling/moving until 3s, reads as two disconnected animations instead of one ceremony; (2) no portal moment — no visual cue at the lid opening marking "this is where the dandelion emerges"; (3) layering conflict — jar fades while dandelion is still inside jar bounds, so dandelion briefly appears to push through jar walls instead of emerging through the lid. This is the ceremony that happens on every bloom reveal — it must feel like one continuous birth, not a 2-phase transition.

Per brand-vault-renditions.html Section 05 Idea 05, the Single-Seed Bloom is "the most product-critical animation because it's the most-used." When a single seed blooms, one orb lifts from the dandelion, drifts up through the lid opening, and opens into the bloom-reveal view. This happens every single time a seed is ready to reveal — potentially multiple times per user session. Spec is currently open: lift trajectory, easing curve, duration, transition into bloom-reveal content, whether the orb "opens" or dissolves. Related to HW142 (Bloom Lift-Off) which is the same idea with a prototype already built.

Before DandyLine is shared with anyone outside Ashley — family, close friends, or a first 100-person beta — a simple, warm onboarding guide needs to exist. This is not a terms of service wall. It's a human-written doc or in-app screen that covers: (1) What DandyLine is and what they're being invited into ("you're a founding Grove member, not just a tester"). (2) How to install it — step-by-step with visuals showing the "Add to Home Screen" flow for both iOS (Share icon → Add to Home Screen) and Android (three-dot menu → Add to Home Screen / Install App). Android note: PWA install works better on Android than iOS — notifications, home screen icon, and full-screen mode all work more smoothly. (3) What beta means — the app is real and functional, but it's early. Things may change. Feedback is welcome and shapes the product. (4) Data safety promise — their media (photos, videos, notes) is stored securely in the cloud. They can export everything at any time. If DandyLine ever shuts down, Ashley personally commits to delivering all their vault content back to them as a downloadable archive — nothing will be lost. (5) What NOT to expect yet — no App Store listing, no public sharing, invite-only. This guide doubles as the legal-lite coverage layer for the family/beta period before formal terms of service are written. Keep it warm, on-brand, and short enough that Grandma reads it. Added 04.09.26.

Under GDPR (and CCPA for California users), any user has the right to request deletion of their data. In a single-user vault, that's simple. In a multi-contributor vault that's already been sealed and shared, it gets complex: how do you remove one contributor's seeds without breaking the experience for everyone else? The seed may already have bloomed. The vault's cryptographic state may depend on all seeds being intact. Key questions to resolve: can deletion be requested on already-bloomed seeds, how the vault UX handles a "missing" seed after deletion, whether recipients keep their copy of a bloomed seed after a contributor is deleted, and what compliance documentation DandyLine needs to evidence the deletion request and execution. The data model decision has to come first — this can't be retrofitted easily. Plan for both GDPR and CCPA from day one. Migrated from coaching dashboard 04.09.26.

How do you actually verify someone died? Death certs can be forged. The 7-30 day wait only works if someone reports the death. What if nobody does — vault sits forever? Consider a 'proof of life' ping — annual check-in where the planter confirms they're still active. Miss 2-3 in a row → system alerts Guardians. Sensitive territory but critical for Legacy Vaults to deliver on their promise. Needs: ping frequency, what happens on missed pings, false positive handling, privacy implications. Added 04.12.26.

Death verification, posthumous delivery, and Guardian rights vary wildly by country. US death cert looks nothing like Brazil or India. COPPA affects 'Held in Trust' for minors. GDPR affects data storage after death. Start US-only for posthumous features. Document legal boundaries clearly. This complexity is actually a MOAT — competitors won't bother getting it right. Needs: jurisdiction-specific rules matrix, US-first legal framework, GDPR/COPPA compliance checklist, international expansion roadmap. Added 04.12.26.

If a Guardian can't see content, how do you prevent someone from planting harmful content in a vault that a Guardian will deliver to a child? The Guardian is responsible for delivery but has no way to screen it. Solution: DandyLine-level moderation layer (AI content scan at plant time, not Guardian-level review). The content-blind promise stays intact, but DandyLine itself acts as a safety net. Needs: moderation policy, AI scan integration, what happens when content is flagged, appeal process, legal liability framework. Added 04.12.26.

DandyLine is currently a personal project with no legal entity. Before signing any advisor agreements, accepting investment, or entering formal partnerships, a business entity must exist. Recommendation: Delaware C-Corporation (standard for VC-backed startups). This also triggers formal IP assignment — transferring the code, brand assets, and design system from personal ownership to the company. Questions for counsel: (1) Is Delaware C-Corp right given VC fundraising plans? (2) What's the right timing relative to bringing on a technical partner? (3) What documents need to exist before an advisor agreement can be signed? Options to explore: Clerky or Stripe Atlas for flat-fee formation (~$500–1,500), or a full-service startup attorney who includes formation in an engagement package. Added 04.12.26.

DandyLine stores deeply personal content (photos, videos, voice notes, messages) and makes an explicit privacy promise. Required before any public-facing launch: a Privacy Policy (legally required), Terms of Service, and a COPPA compliance assessment. COPPA applies if any user under 13 can be a Gardener or appear in a Grove vault — which is likely in a family product. GDPR and CCPA also need to be addressed for California and EU users. Questions for counsel: (1) Does the Grove vault trigger COPPA? (2) What's minimum viable GDPR compliance at this stage? (3) What are data breach notification obligations given the sensitivity of content stored? (4) What are obligations around content not yet bloomed if the platform ever shuts down? Also needs a documented data retention and deletion policy for the compost mechanic. Added 04.12.26.

The Legacy vault is DandyLine's most legally novel feature. It delivers content after a user passes away, managed by a designated Legacy Guardian. This creates digital estate obligations under RUFADAA (Revised Uniform Fiduciary Access to Digital Assets Act). Scenarios needing legal coverage: (1) Guardian is designated, user dies, Guardian requests access — what authority does DandyLine recognize? (2) User dies with no Guardian designated — what is DandyLine's obligation? (3) Designated Guardian dies before the user — what happens? (4) Family member disputes the Guardian's authority — what's DandyLine's position? (5) Legacy content is intended for a minor. Questions for counsel: (1) Can Terms of Service establish that the Guardian designation supersedes family claims? (2) What documentation should DandyLine require before releasing access? (3) Should Legacy vault functionality require a separate consent agreement beyond standard ToS? (4) Is there meaningful liability exposure if a family member disputes delivery? This is genuinely novel legal territory — ask if counsel has experience in digital estate law specifically. Added 04.12.26.

Three distinct IP threads: (1) Trademark — "DandyLine" wordmark needs a clearance search and registration in Class 42 (SaaS/tech) and possibly Class 45. Need to understand trademark strength (fanciful vs. suggestive), whether the "dandelion" root creates any descriptive risk, and which classes apply. (2) Platform copyright — All code was written with AI assistance (Claude). Need counsel's view on how AI-assisted code generation affects copyright registration and enforcement. All brand assets (dandelion mark, design system) were hand-coded SVG — need to confirm best way to establish copyright in these. (3) User content copyright — Users own their Seeds (photos, videos, voice notes). DandyLine needs a limited license in the ToS to store/process/deliver content. Additional questions: What happens to a user's copyright-protected content after they die — does the Legacy vault create complications? Does DMCA safe harbor apply to DandyLine given that content is time-locked and private (not publicly shared)? Does the compost mechanic satisfy content license withdrawal? Added 04.12.26.

DandyLine is solo-founded. No active hire in progress. But when a technical partner or advisor enters the picture, the legal agreements need to be ready — not written under pressure. Templates to request from counsel: (1) Technical partner / equity agreement — including 4-year vesting with 1-year cliff, IP assignment, role definition, departure provisions. (2) Advisor agreement — standard 0.1–0.5% equity with vesting, IP assignment, confidentiality. (3) Mutual NDA — for use before agreements are signed, when sharing architecture or product plans in conversations. (4) Cap table guidance — how to structure equity from the start to avoid complications at pre-seed or seed. Questions for counsel: (1) What's standard vesting/equity for a technical partner at this stage? (2) Is a spreadsheet cap table sufficient until a seed round? (3) What's the exposure for verbal commitments before a written agreement is signed? (4) What provisions are commonly overlooked early that cause problems later? Added 04.12.26.

⚠ HOLD · 2026-05-07 evening · Ashley picked Direction D (the ambient compost pill that lives on the seed's normal viewing surface · gold center orb · sage-left "Bring back" / terra-right "Let it go" zones · tap orb to reveal optional detail card) — but said "it needs some work" before locking. Wound down for the night before specifying what.

Re-entry point: Open SCRATCH-HW179-composting-popup-2026-05-07.html in browser. The 4 panels at top show A/B/C/D side-by-side. The "Direction D in context · does it hold up?" section below the panels shows D applied across 3 surfaces (Voice Memo Bloom · Tier 1 popup in field · Tier 2 expanded card) at 3 scale variants (Full · Compact · Mini).

What's settled (don't relitigate):
· Direction D is the chosen pattern (ambient layer · not a discrete modal). A/B/C are off the table unless Ashley reverses.
· Gold center orb (radial gradient · matches main-nav button quality) — replaces cream/white. "No white" rule applied across all slider orbs in the SCRATCH.
· Two-gesture pattern from Entry 032 stays — drag-to-commit is the irreversible action; the reversible "Bring back" lives in the same gesture (left zone) instead of needing a separate slide-confirm.
· Three scale variants identified: Full (~70px · 30px orb · for full-bleed Bloom Views + vault detail) · Compact (~36px · 22px orb · for Tier 2 cards) · Mini (~18px · 14px orb · for Tier 1 popups in the field).

What's open (the "needs some work"): Ashley didn't specify. Candidates surfaced during the session, in order of likely importance:
· Mini-scale open question — does the Tier 1 mini-pill need a slider at all, or should it just be the existing locked Composting visual signal (terra dotted ring counter-rotating) with a tap-to-escalate-to-Tier-2 affordance? My lean: just the ring (avoids false-affordance · reuses already-locked visual language). Ashley to confirm.
· Pill placement on dense surfaces — multiple composting-seed pills stacked in a list view could compete. Spec needs a collapse-to-dot rule on dense rows.
· Detail card content + animation refinement — currently a small floating card with one quote + one sub-line. Could be: bigger ritual scale (Direction B's content) · or simpler · or different copy entirely.
· Drifting variant of the same chassis — Drifting is the warning state before Composting. Same pill at oat tone with "press now if loved" copy? Or no pill at Drifting (warning only)?
· Batch / multi-select compost mode — Entry 032's multi-select variant ("SLIDE TO COMPOST 4 SEEDS") not yet specced for D. Likely a separate surface (Compost view), not the per-seed pill.
· "Bring back" vs "Press to keep" vocabulary — both used in the SCRATCH. Single canonical word pair needs locking before the surfaces propagate.

Files to load on resume:
· SCRATCH-HW179-composting-popup-2026-05-07.html — the SCRATCH (open in browser, scroll to D-in-context)
· app-design-system-v3-2026-05-07.html — v3 spec §07 (popup variants) + §10 (lifecycle). HW#179 still in critical-path until D is locked.
· biz-dev-decisions-log.md — the B3 lock entry from earlier today shows the format for the eventual D lock entry.
· ux-inspiration-library.html Entry 032 — two-gesture pattern source · also Entry 010 (compost pile) for the multi-select batch case
· product-seeds.html §03 — the locked Composting visual signal (orange dotted ring · 50% opacity) for the Mini-scale question

Re-entry prompt suggestion:
"Picking back up on HW#179 Composting popup. Direction D was picked but needs work. Open SCRATCH-HW179, scroll to D-in-context. I'll tell you what to refine — start with whichever surface or scale I name. Don't relitigate A/B/C."

Cascade impact: still on critical-path in v3 spec. Once locked, closes the second-of-two remaining critical-path gaps · only HW#176 (Bloom moment animation) left. Whatever D's final shape, it propagates as a chassis to every surface that can show a composting seed (Field popup · Compost view · vault detail · bloom view · list rows).

Consolidated follow-up work for TEMP-dandelion-globe-V4.html from Ashley's Apr 27 EOD feedback. Pick up next session in this order — items are scoped so you can ship them in one or two focused passes.

Re-entry point: Open TEMP-dandelion-globe-V4.html. Snapshot first. Tackle in roughly this order:

① RING VISUAL (the main "I misread the brief" item) · Build the canonical donut/ring counter from ux-field-homepage-v3-motionmark-depth.html (lines 252-267 HTML + 370-442 JS) into the Field bottom sheet. Outer R 78, inner R 58, breathing pulse, segment glow per lifecycle color, big "47 SEEDS" in center. KEEP the existing bar chart — Ashley is TBD whether she'll prefer ring or bar. Add a small toggle to switch between the two if both stay.

② Popup-stuck for back-hemisphere orbs (Drifting/Composting) · ✅ RESOLVED 2026-05-01 · Per-lifecycle threshold added in positionTooltipsByUid — Drifting + Composting now require projZ > 0.20; everyone else stays on > 0.05. Verified via direct unit test on the function. Also closes HW#195 sub-item ③ (Composting popup-stuck — same root cause).

③ Lifecycle filter split · Filter panel's Lifecycle row currently mixes pre-bloom + post-bloom in one long pill row. Split into two groups: Sealed (warming: Bloom Now/Blooming Soon/Approaching/Patient/Distant/Location-Locked) + Memory (post-bloom: Bloomed/Drifting/Composting/Pressed). Group labels TBD — "Sealed / Memory" or "Coming Soon / Bloomed."

④ Mode badge cleanup + per-vault metadata swap · Badge currently reads "ROOTS · COVE · SINGLE VAULT" (three units, redundant). Drop the "single vault" suffix. Also: when filter narrows to a different vault (e.g. Grove), the badge changes but contributor avatars + jar metadata (Started by KeKe · Summer 2023 · "Anyone who loves the Cove...") don't swap — feels inaccurate. Build a per-vault metadata lookup so jar info actually changes when filter changes (mock data is fine).

⑤ Composer mini jar icons · Vault-picker chips in the Plant composer currently show colored dots — should use canonical mini jar SVG icons per brand-vault-renditions.html drawIconJar() + ux-vault-flow.html createGroveJar / createPersonalJar / createLegacyJar.

⑥ Toggle rename · ✅ RESOLVED 2026-05-01 · Picked Puff / Roll. Applied to topbar toggle in TEMP-dandelion-globe-V4.html + the descriptive note in the future-renditions list ("Puff → Roll transition"). Verified live in preview.

⑦ High-density rendering at 60/120 + Stems Only mode breaking down · Investigate. Stem density math may need cap; Stems Only mode probably needs an explicit empty-state visual ("plant your first seed" CTA in bottom sheet?). The "perpetual depth" rule (HW#143 ref) should make 120 feel intentionally abundant, not chaotic.

⑧ Tier 1 → Tier 2 click-expansion QA · Ashley reported "pop-ups don't expand currently." DOM eval confirmed the handler is wired + the card opens with correct data. Possible: she may want a more prominent/dramatic expansion (currently 230px wide, may not read as "expanded enough"). Verify in real browser; if confirmed insufficient, bigger card / more lift feel.

⑨ Search function · Add a search input above the filter pill row. Lets a Gardener type to find Seeds/Vaults by name, contributor, date, or content type. Pairs with — but doesn't replace — the existing lifecycle/Vault/contributor filters. Mocked results for now; real wiring waits on the API. Inspired by Moleskine intake (May 2, 2026 session).

What's already done in V4 (don't redo): Garden mode default · Apr 28 vocabulary lock · tooltip identity bug fix · density toggle 12→120 · 10 lifecycle states (Drifting added) · anchored-depth popups · 5-popup cap · floating chrome + backdrop blur · pill-based filter panel · push-aside→modal-overlay · sheet pull-up gesture · Tier 1→2 click handler wired · vault-picker on Plant FAB · Starlight Cove cast · canonical avatars · field stats bar · labels on/off eye toggle · Drift Oat + Compost Terra in brand palette.

Snapshots to roll back from if needed: 5 dated V4 snapshots in folder + git history e8fbe7d ← 91d57ec ← 0cf90d2 ← 69d03a2.

Captured 2026-04-27 from V4 dandelion-globe build. When the gardener taps the gold Plant FAB in the bottom nav, an inline composer should slide up — letting them quickly plant a seed without leaving the Field/vault context. Currently stubbed in TEMP-dandelion-globe-V4.html as: Step 1 vault picker (chips for Grove/Personal/Legacy/Roots/Journey + New vault) → Step 2 media-type picker (Photo/Video/Voice/Note/Mix). Long-press on Plant FAB opens the full ux-planting-flow.html.

What needs to be designed: the post-picker UX (capture surface for each media type · title field · emotion tag picker · timing chooser · recipient field · plant CTA · how it ties back to the canonical full planting flow). Should the inline composer be the ONLY composer, with the full flow being for first-time setup? Or is full-flow always available for advanced cases (multi-recipient, location-locking, Held-in-Trust setup)?

Linked: ux-planting-flow.html · HW#75 (compost trigger) · brand vocab Mix as the 5th media type (per product-roots-storyline-starlight-cove).

Vocab decision locked 2026-04-27: "Drifting" is the warning state between Bloomed and Composting — a bloomed seed approaching its compost window where the user gets a last chance to Press it before passive degradation begins. Visualized in TEMP-dandelion-globe-V4.html as the 10th lifecycle state (warm cream/oat color, italic state label).

What's TBD: the trigger logic itself. Options to evaluate: (a) auto after N days post-bloom regardless of opens · (b) auto after N days unopened · (c) when storage tier is being reclaimed · (d) hybrid — softer warning at X days, hard tip into Composting at Y days. Picking the right formula depends on understanding storage cost economics and how conservative/aggressive DandyLine should be with the degradation window.

Why we're parking this: No need to lock the formula yet. Visualization + vocab are in V4 so the concept is captured. Decision can be tweaked later. Hard deadline: before broader onboarding (don't ship to non-internal users with this undefined — the implications hit real user data).

Linked: HW#75 (Compost Trigger Logic — auto vs opt-in), HW#76 (Storage Visibility), HW#90 (Released ceremonial UX). Memory: see feedback_lifecycle_vocabulary.md for the full lifecycle order.

Allow gardeners to preserve an entire jar with one action. Show hidden detail of full jar size (excluding items others already preserved). Display vault-wide preservation status and rules. Design logic for edge cases: what if some seeds are already pressed by others? Can you "double-preserve"? Needs visual treatment in jar details view. Ashley wants this to feel like peace of mind, not a sales pitch.

Does composting auto-trigger (assume nothing is pressed)? Or do gardeners opt to press/preserve at planting time? Or both? Ashley's concerns: "what if no one ever opens it to trigger composting?" "what if every user preserves everything?" Consider: compost countdown notifications — do they get more aggressive over time? Emotionally weighted prompts for monetization ("Are you sure you want to compost 'Secret Drunk Chicken Family Recipe' from Grandpa?"). Options on compost card: Compost (schedule delete), Preserve/Press, Download to Device, Delete Now. Ties to existing compost homework items — merge/update as needed.

Design storage visibility dashboard with easy access to add storage and see pricing/packages. Ashley took 4 Apple iCloud storage screenshots (April 15) as inspiration — reference those. Needs: current usage bar, breakdown by vault, easy upgrade path, price/package options visible. Should feel empowering ("look how much you're preserving") not alarming. Tie to Preserve Jar (HW#72) and compost prompts (HW#75).

When a Gardener taps "Release Now" in the Compost bin — choosing to permanently release a seed before the 30-day window expires — this is a conscious, intentional act. It deserves a ceremonial moment. Proposed: the seed dissolves into dandelion wisps that float upward and away. Gone, but gently. The automatic case (30-day timer expires with no one watching) could trigger a soft notification: "A seed was released today" — tapping it shows the same brief floating animation. Open question: does the notification-triggered ceremony feel right, or does it feel like being summoned to watch something disappear? Could be lovely, could feel wrong — needs a design sprint to find out. High priority polish item, not a launch blocker. Build after the core compost flow is live. Vocabulary locked: Released = permanently gone. Press = preserve. Composting = decay window.

Artkive charges $75 for a mail-in art book. DandyLine can do this in the planting flow for free, with more emotional depth. An "Artwork Seed" photo type that adds a custom overlay field: "You told me this was ___." The parent photographs the crayon drawing, types what the child said it was ("a rocket ship that flies to the moon for snacks"), and the seed preserves both the artwork and the story behind it. When it blooms in 10 years, the child sees the art and reads what they told their parent about it. This is the Artkive play, but the story layer is the differentiator — Artkive just archives, DandyLine archives + contextualizes. Needs: a new seed type variant (or a metadata field on photo seeds), the caption overlay design, and the bloom card layout that presents artwork + caption as a paired unit. Added 04.22.26.

Pairs with HW#95 (Artwork Seeds). If a parent plants 20+ Artwork Seeds over a year, DandyLine could auto-generate an "Art Year" collage when the year-end Journey Vault blooms — a beautifully laid-out digital page (or physical book upsell) showing all the artwork from that year with captions. Think of a kindergarten memory book, but made from seeds the parent already planted throughout the year. The magic: no extra work required at bloom time. The parent planted the seeds one by one. DandyLine assembles the collage automatically. Competitors (Artkive, Chatbooks) require you to gather everything at the end. DandyLine's content is already organized because it was planted with intention. This feature requires: vault content filtering by seed type, collage layout algorithm or template, digital output design, optional print-to-book upsell. A premium output feature that drives both upgrades and emotional purchase decisions. Added 04.22.26.

Default Grove vault schedule is always "Surprise" — everyone receives the bloom at the same random time. Countdown clock exists but nobody knows who sent it. Group anticipates together. Strong retention mechanic. Needs: full UX flow for Surprise mode, notification design, how countdown displays when sender is hidden.

Can storage be pooled across a group? One person pays, everyone in the group gets access. Shared capacity bar visible to all members. Needs: pricing tiers, shared bar visual, whether multiple people can contribute to the same pool, what happens if the payer stops paying.

Four roles: Original Gardener → Lead Gardener → Gardener → Recipient. A grandparent assigns a daughter as Lead Gardener so future grandkids (even unborn) can be added later. Critical for legacy vaults that outlive their creator. Needs: permission model UX, succession flow, storage ownership on transfer.

Ashley raised a critical question while designing the Roots vault: do visibility and join settings exist for ALL vault types, not just Roots? The current design doesn't address this. Three distinct settings need to be defined and applied across all vault types: (1) Discovery — who can see the vault exists? Options: fully private, visible by name to invited people only, open/searchable. (2) Join access — who can become a member? Options: open, request-to-join (owner approval required), invite-only. (3) Contribution rules — who can plant seeds? (Mostly relevant for Grove + Roots, but applies to any shared vault.) For Roots these are especially rich because of the geofence dimension — discoverable-but-invite-only is a unique mode where the vault appears when you arrive, but you must request permission to join. Needs: decision on whether all 3 settings apply to all vault types or only select ones, UI for the settings panel, and how this surfaces in the vault chooser flow. Added 04.09.26.

When a user opens or selects a jar, there should be a brief description visible — not just the title, contributor count, and seed count. The owner can write a custom description when creating the jar, but if they don't, a default kicks in. Defaults should feel alive, not generic. Options: a single rotating default per vault type, or 2–3 curated variations the system cycles through. Also locked: two copy lines for Roots arrival/join moments — "Plant something true to this place." (arrival notification, before joining) and "This jar holds what this place has held." (invitation or jar open screen). Hard-rule jars (strict GPS enforcement) get firmer copy like "Only what was captured here belongs here." Needs: default description copy written for all 6 vault types, UI placement in the jar view, and settings panel for owner to write/edit custom description when building a jar. Added 04.09.26.

A user should be able to change a vault's type after creation — within reason. Real example: a solo parent builds a Personal vault (blue) contributing to it for years, then wants to gift it to their child on their 18th birthday. A Personal vault showing up as the gift feels wrong — it should become a Milestone vault (green). The conversion flow: system prompts "Do you want to transfer your seeds into a different vault type? Here are your options." It then sorts seeds — some may transfer cleanly, some may not comply with the new vault's rules (e.g., hard-location seeds moving to a non-location vault). Seeds that can't transfer are flagged separately. The owner keeps access as the original Gardener after gifting. The recipient (the child) sees a Milestone vault, sees what's already bloomed, sees countdowns for future unlocks. Key rules to define: which vault type conversions are allowed (Personal → Milestone, Personal → Grove, etc.), what triggers a conversion prompt vs. an error, what happens to non-compliant seeds, and whether partial conversion is allowed. The gifting flow is its own mechanic — separate from conversion but often paired with it. Added 04.09.26.

Default: a planter can always access their own seeds even when they're scheduled/locked for others. Optional toggle: "Surprise me too" — hides the seed from the planter themselves until it blooms. Use cases: the Grove Hatch Family vault where everyone gets surprised at the same time including the planter; a personal sobriety journey vault where you want to rediscover what you captured. When a seed is self-locked, the planter can still see: the date it was planted, that they planted it, and optionally the title (toggleable). Title visibility and Gardener name visibility should each be separately controllable — default is both visible (builds anticipation), but planter can hide either. Gardener name should always default to visible because it's a point of emotional connection and enticement. Needs: toggle UX design, decision on what metadata is always visible vs. optionally hidden, and whether self-locked seeds can still be recalled (yes — but recalling breaks the surprise). Added 04.09.26.

When a new user creates a vault, they shouldn't start from a blank box. Vault Templates are pre-named, pre-configured starting points with a mood, a suggested schedule rule, and example seed ideas built in — so a user instantly understands what kind of vault they're making. Needs: a full library of template archetypes to develop. Starting examples to build upon: (1) The Joke Vault — a Grove or personal vault where everything is set to "Surprise" scheduling. Anyone in the Grove can drop in a funny meme screenshot, a voice memo of Dad's worst dad joke, a typed-out text of something ridiculous a friend said, or a video clip of a chaotic accidental moment. Nobody knows when it blooms. Pure joy. (2) Kids Vault — a parent-curated space for things a child says, does, or becomes. (3) Legacy Vault — messages from someone important, sealed for a future moment. (4) Journey Vault — a shared travel or milestone vault that fills over time and blooms at the end. (5) Future Self Vault — notes, photos, and voice memos to your own future self. Goal: when someone sees these templates at onboarding, they immediately picture themselves using one. Vault Templates are also a marketing asset — each archetype is its own story to tell. Added 04.09.26.

What happens to a seed that never gets a delivery date — especially if the planter dies? Options to evaluate: (1) Mandatory default — planter must set at least a fallback date at creation, even if vague. (2) System-assigned default — DandyLine assigns a default window (e.g., 5 years) if nothing is set. (3) Open default — unscheduled seeds are accessible immediately. (4) Compost default — unscheduled seeds begin composting after X years if never claimed or scheduled. For Legacy specifically: if no date is set and the planter dies, the Legacy Guardian should be prompted to set the delivery date when they activate the legacy — the vault doesn't auto-fire without human confirmation. This connects to the Pressed vs. Compost mechanic (#03) and the fuzzy dates system (#26). Needs: decision on default behavior per vault type, and Guardian activation flow for Legacy. Added 04.09.26.

DandyLine's data portability promise means content should always be downloadable — but the rules around who can download what, and when, likely vary by vault type. The core tension: private family vaults feel open and trusting (anyone in the Grove can save content), but community or semi-public vaults may need creator-level controls to feel safe. This is NOT an MVP problem — don't add complexity to the first build. But it needs to be thought through before any community vault feature ships. Starting framework: (1) Personal vault — full download always, it's just yours. (2) Family/Grove vault — open by default, lead gardener can optionally restrict. (3) Community vault — restricted by default, lead gardener can open it. (4) Legacy vault — timed download; content may only become downloadable after the bloom. Key design constraint: this should never hit the user as a wall of settings on upload. Think contextual defaults that feel obvious, not a permission grid. Also consider: screenshots are always possible anyway — so download restrictions are about friction and intent signaling, not true prevention. Note the Snapchat parallel: people save before posting precisely because they don't trust platforms to preserve original quality. DandyLine's download default should always preserve original quality — that's the differentiator. Added 04.09.26.

Resend (email) and Twilio (SMS) are in the stack, but there's no design for the notification system itself. What triggers a notification? Who gets one — the planter, the recipient, or both? Notifications to think through: (1) "Your vault is about to bloom — X days away." (2) "A seed has bloomed for you." (3) "Someone planted a seed in your Grove." (4) "Your vault is getting full." (5) "A seed you planted X years ago just bloomed." Each of these needs copy, timing, and a decision about email vs. SMS vs. both. This is a prerequisite for building the bloom delivery pipeline in Step 6 of the build sequence. Added 04.12.26.

Updated 2026-05-02 — Weather Hub umbrella spec (Moleskine intake):

Weather is the in-app surface that surfaces all time-sensitive signals to the Gardener. It REPLACES "daily tasks" and "today's schedule" patterns from generic productivity apps. Each Weather item is a signal plus an action button that navigates the Gardener to the relevant surface.

Signal types (tied to notification types from this same card):
— "Your Seed has bloomed" → goes to Bloom reveal
— "A Seed has been planted for you" → goes to Held in Trust / claim flow
— "You have N Seeds ready to bloom" → goes to bloom queue
— "Your Vault hasn't been tended in [time]" → goes to that Vault
— "Time to contribute to [Grove/Journey]" → goes to contribute flow
— "You have N Seeds in your Seed Packet — ready to plant?" → goes to Seed Packet (HW#201)
— + posthumous variants (HW#54), Vault rename announcements (Weather Update card), On This Day surfacing (HW#140)

Layout — TBD: dashboard, feed, or card-stack are all viable. Plan: "draft three" pass at build time before committing.

Hard NO: "Today's Schedule" framing. Wrong metaphor.

Sister cards feeding Weather: HW#54 (posthumous notification language), the Weather Update — Vault Name & Description card, HW#140 (On This Day + Weather-at-Bloom). These are sub-specs that feed the umbrella Weather Hub.

Connection: notification types and Weather signals are the SAME underlying events — same source, two surfaces (push/SMS for notifications; in-app Weather hub for in-app prompts).

If I plant a seed today for my daughter's 18th birthday, she doesn't have a DandyLine account yet — and may not in 18 years. When the bloom arrives, what does she receive? An email with a link? Does she need to create an account to open it? If yes, what's the minimum signup? If no, how does she access it securely without one? This is one of the most emotionally charged moments in the entire product — a person receiving a message from someone they love — and right now it has no design at all. Decide this before building the bloom delivery system. Added 04.12.26.

Grove vaults are multi-contributor — multiple Gardeners plant seeds into the same vault. But the mechanics of how that works have never been designed. How does the lead Gardener invite contributors? (Email link? QR code?) Does a contributor need a DandyLine account to contribute, or can they submit as a guest? What can a contributor see — just their own seeds, or all seeds? Can the lead Gardener remove a contributor's seed? Can a contributor remove their own seed before it blooms? These decisions directly shape the Grove data model and auth system. Added 04.12.26.

A "Community Garden" where you browse open/public vaults you can join. Shows: title, # contributors, description, general rules, # bloomed seeds, # pending seeds. Ties to Roots ghosted discovery (C1-C5) but broader — could include Journey vaults and other public types. Ashley referenced ux-mockup-reference.html jar browser visual as rough starting point. Needs: discovery mechanism, join flow, role assignment on join. See also C4 vault roles/ownership notes.

Insight surfaced in competitive research: for platforms like FamilyAlbum, sharing a photo motivates more contributions. The act of contributing (seeing others respond, seeing the shared space fill up) creates its own flywheel. DandyLine is NOT social — but this dynamic still applies. When a Grove vault gets a new seed, contributors see "3 more seeds have been planted" without seeing what's inside. The unsealed vault is growing visibly. That's a contribution motivator that doesn't break privacy. Design principle to formalize: visible growth signals should show QUANTITY but not CONTENT before bloom. "Your vault has 7 seeds and counting" creates anticipation and motivates others to add more. This applies to: Grove vault contribution prompts, Journey vault progress states (a progress bar from 0 → 12 monthly seeds), and the "Something is growing for you" recipient tease (HW#59). This isn't a separate feature — it's a design principle that needs to be formalized in the UX system and explicitly documented in the brand guide as a distinction from social media mechanics. "We show growth, not reactions." Needs: design principle documented, specific UX applications across vault types, copy guidelines for "vault is growing" language. Added 04.22.26.

The full financial model: pricing assumptions ($69/yr premium, $120/yr family), conversion rates, storage math, operating cost estimates, profitability trajectory, and the two-phase build split (Family MVP at ~$0 cost → Public Scale requires pre-seed). Stack note: Supabase references in the original have been updated to the April 12 Cloudflare-only decision.

DESIGNED April 12, 2026. Full spec in product-seed-keys.html. Covers: Seed Key generation and sharing, four recipient states (Active, Invited, Held in Trust, Open Claim), Guardian assignment and acceptance flow, content-blind guardianship, planter-set passphrases, posthumous delivery with death verification, multi-recipient vault logic, and schema implications for D1. Josh cliff notes in JOSH-UPDATE-APRIL-12.md. Remaining open questions documented in Section 11 of the product page.

A vault's planter dies. The Guardian takes over. But what if the Guardian also dies — or becomes incapacitated? Does the vault persist and wait indefinitely? Is there a secondary Guardian (chain of succession)? Does the system eventually release the content after a long enough period? This is a low-frequency but high-stakes edge case. For MVP, "vault persists indefinitely" may be the right answer. At scale, a secondary Guardian option or an estate-level release mechanism may be needed. Related to HW#18 (digital legacy planning). Added 04.12.26.

Open Claim Seed Keys could power event-based experiences. Wedding planners print QR-code Seed Keys on place cards — 150 guests scan, plant seeds (video, photo, note), couple's vault fills in real time, blooms on the anniversary. Applies to corporate retreats, graduation ceremonies, baby showers. Revenue opportunity: per-event pricing or bulk Seed Key packs. Partnership channel: event planners, wedding coordinators, corporate retreat organizers. Needs pricing model, bulk key generation UX, and event-mode vault settings. Added 04.12.26.

Instead of a single Guardian, allow a trust circle — 2-3 people who collectively manage delivery if the planter passes. No single person bears the full weight. Adds redundancy (what if the one Guardian also dies?). Could use voting: 2 of 3 Guardians agree → action proceeds. Connects to Shamir's Secret Sharing concept already in open questions. Needs: trust circle UX, voting mechanics, what happens on disagreement, minimum circle size. Added 04.12.26.

Guardian dies before planter. Or Guardian goes inactive — deleted account, lost phone, moved countries. Trust chain is broken. Connects to HW#55 (Guardian Succession) but needs a concrete fallback design. If Guardian unreachable for X months → system prompts planter to reassign. If planter also gone → vault enters 'community trust' state where DandyLine itself becomes temporary custodian (content-blind). Needs: inactivity detection, reassignment flow, community trust rules, legal framework for platform-as-custodian. Added 04.12.26.

Born out of the April 18 planting-flow session. Add a profile-level setting called "My Default Guardian" (or similar) that auto-fills as the suggested Guardian every time a Gardener plants a new vault. Must be editable on the vault itself so any single vault can override the default. Includes a sibling "My Guardianships" view showing (a) vaults I've been named Guardian for, (b) vaults I'd inherit via Grove/Roots default, (c) guardianship acceptance status, (d) ability to decline. Design considerations: how is the default set? (empty by default — first time a user assigns a Guardian, prompt "make this your default?"); how is it changed? (profile settings + "change default" nudge on every 5th vault); can a user have no default? (yes — opt-in, not forced). This is a RETENTION feature — it gives returning users a reason to maintain their account so their guardianship chain stays intact.

Born out of the April 18 planting-flow session. Super Lock is a one-way toggle during planting that makes the bloom date completely immovable — not by the Planter, not by a Guardian, not by a Premium subscriber, not by anyone. Used for sacred/ritual dates: "bloom on her 18th birthday," "bloom the day he gets married," "bloom on our 50th anniversary." UX needs: (1) friction-heavy confirmation — this cannot be undone; (2) clear visual treatment on the vault card ("🔒 Super Locked — {date}") so nobody forgets it's permanent; (3) recipient-facing notice "this date is immovable — it was sealed by {planter} at planting time"; (4) Guardian-facing notice on the vault dashboard explaining why the date can't be edited even if they'd otherwise have authority; (5) edge-case handling — if the Planter Super-Locks then dies, Guardian still can't move the date (which is the point). This is the feature that lets Gardeners trust the system with their most sacred commitments.

Born out of the April 18 planting-flow session. When a Planter replaces a Guardian (e.g., divorced husband swapped for sister), the system must notify BOTH the outgoing and incoming Guardian — but the notification tone matters. Decision: subtle and dignified, not dramatic. Design: (1) outgoing Guardian gets an in-app + email notice "{planter} has updated guardianship for their vault '{vault-name}.' You are no longer named as Guardian. No action needed." — NO "why" field, NO apology text, NO rejection framing; (2) incoming Guardian gets standard guardianship acceptance flow; (3) the vault's Guardian changelog (visible only to the Planter) logs the swap with timestamp; (4) no public-facing notice anywhere — guardianship changes are private between Planter and the Guardians involved. Stress-test edge cases: what if outgoing Guardian had already accepted and was holding seeds in trust? (Seeds revert to Planter's vault control, Guardian loses access cleanly.) What if outgoing Guardian is dead? (Swap silently — no notification attempt.)

Born out of the April 18 planting-flow session. Groves (shared vaults with multiple Gardeners) need two guardianship layers because personal ownership must survive inside a shared container. (1) VAULT GUARDIAN — structural/admin role: can the vault itself continue if the owning Gardener dies or account-deletes? Manages membership, lifecycle, archive. Defaults to the Grove creator; Grove members can vote to replace. (2) CONTRIBUTOR GUARDIAN — per-person role attached to each member's own planted seeds inside the Grove. If Grandma Memaw contributes 40 seeds to a family Grove and passes away, HER seeds respect HER Contributor Guardian (a daughter she named), not the Vault Guardian. Build scope: data model (two FK columns on seed records — vault_guardian, contributor_guardian); UX for setting your Contributor Guardian when joining a Grove; dashboard view showing "seeds I've planted + who guards them"; vault-level dashboard showing both layers. Stress-test: Grove Vault Guardian dies AND Contributor Guardian for a deceased contributor dies — is the Grove ever orphaned? (Falls into the 3-Layer Ladder — nudges, then Held in Trust, then Sunset.)

Define the full sonic identity of DandyLine — what does planting a seed sound like? What does a vault opening sound like? Explore a palette of micro-interactions: swooshes (navigation/transitions), whispers (intimate/personal moments), chimes (bloom delivery, celebration), pops (taps, confirmations). Needs: sound direction/mood board, trigger mapping across key moments, and decision on opt-in vs. ambient-on approach.

What does the Roots map actually look like? Visual direction already set: organic and calm, not utilitarian — soft terrain textures, glowing underground root systems, floating seed markers, warm light pulses for emotional intensity. Needs: full map UI design, how locations are represented as pins vs. clusters, zoom behavior, seed density at a single location, and the entry point into the map from the main nav.

Location seeds have two sub-states that need subtle visual distinction on the popup card. "Sprouted Here" = GPS auto-captured, memory was born at this place (the wormhole experience). "Rooted Here" = manually assigned, memory was intentionally dedicated to this place. Both remain purple. Needs: icon variation exploration (root-anchor vs. dedicated-pin feel), sub-label placement on the popup card, and a subtle info icon or hover tooltip that explains the difference without interrupting the emotional moment.

A new vault type (or major Roots mode): a community jar anchored to a physical location. When someone arrives at the location, a geofence notification fires — "Our roots run deep here. Want to garden?" — and they can join and contribute. All contributors can see what others planted (some open, some time-locked). Every seed shows provenance: taken here vs. tagged here vs. manually placed. Key distinction from #06 (Location-Locked): that vault can't be OPENED until you arrive. This vault can't be CONTRIBUTED TO unless you're there — or the creator allows otherwise. Jar-level location rules: creator chooses soft mode (anyone can contribute from anywhere) vs. hard mode (GPS must be live, only media captured at this exact location allowed — no imports, no uploads from other places). Hard mode creates a "window in time" — the jar feels like a living record of a place. Needs: new vault type definition (or Roots sub-mode), arrival notification UX, join-the-jar flow, contribution rule settings, provenance labeling on seeds, and how this integrates with the Roots Map (#09). Added 04.09.26.

Journey seeds trickle in at randomized intervals after someone hits a milestone — not all at once. Creates the feeling that someone just thought of you in real time, even if the seed was planted years ago. Time as the medium applied to delivery itself. Low seed volume is invisible — sparse pools feel as meaningful as full ones. Re-engagement is earned. Needs: max seeds per milestone (suggested 3–5), delivery window (suggested 1–4 weeks), spacing logic (randomized, not fixed schedule), curation logic (tone variety, media type variety), and notification copy that makes each arrival feel handpicked — not algorithmic. The notification copy is especially high-value creative work. Added 04.09.26.

Spawned 2026-05-10 from HW#028 lock. HW#028 locked the FORMULA + ARCHITECTURE for Journey vault delivery. This card covers the actual TEMPLATE DESIGN work for the 5 curated templates that ship in V1: Sobriety / Recovery, Pregnancy / New Parent, Grief / Loss, Military Leave / Deployment, Weight Loss. Each curated template needs: (1) anchor milestone schedule (the day-offsets from vault creation that fire pool delivery waves — uniform across all users of that template); (2) prompt library (12–30 rotating questions per template, brand-voice-aligned, used by the Personal Prompts system when reminders fire); (3) default Personal Prompts cadence (weekly / monthly / per-template); (4) restart-UX copy (template-specific because the emotional context differs across Sobriety / Pregnancy / Grief / Military / Weight Loss); (5) default Walk With Others setting (proposed ON for all curated templates); (6) default Strangers Only setting (proposed ON for all curated templates). Plus: Custom journey scaffolding — the user-defined milestone setup flow + generic prompt library + soft-floor fallthrough behavior. References: biz-dev-decisions-log.md 2026-05-10 entry for the full HW#028 spec · SCRATCH-HW028-journey-delivery-2026-05-10.html for the locked copy doc + voice rules. Cross-references: HW#86 (Journey Vault Deep Dive page should consume this work) · HW#093 (monthly prompted upload mechanism = Personal Prompts cadence option, no separate template needed) · HW#177 (cold-start dignity informs prompt library design for early-days experience).

Per CLAUDE.md, the file biz-why-dandyline.html is the "Hidden genius list · investor wins · why DandyLine is designed this way" living document — but it doesn't exist yet. HW#028 close-out (2026-05-10) generated the first investor-list entry to add, captured here until the file is created.

First entry to seed the file (LOCKED 2026-05-10):

Reciprocity-as-Architecture · "The Exchange Is the Magic"
Journey vaults run on a hard reciprocity rule — to receive peer seeds from anonymous others walking the same path, you must also share yours. No lurker mode. No asymmetric consumption. The system enforces the contribution at the architectural level; it isn't a community guideline.

Why this is brilliant from an investor lens: social media's growth model relies on lurking being free (90% read, 9% engage, 1% post). DandyLine inverts that for the pools where peer signal matters most. Reciprocity-gated software exists in anonymous venting apps (Sincerely, Silent Ink, Unsent Letter Mailbox, Therapeer) — but has never been applied to journey-cohort peer support, where the same-path constraint makes contributions emotionally valuable. Sobriety, grief, recovery, weight-loss, and military-deployment apps universally allow lurking; we invert that for the categories that need contribution most.

The novel combination isn't reciprocity in software (it exists). It's reciprocity gated on shared-journey cohorts in a time-delayed memory system — three primitives that have never been combined. This solves three problems at once: pool quality (everyone contributes → richer pool), emotional authenticity (no voyeurism in vulnerable spaces), and category differentiation.

The framing shift: this is participation as product, not content as product — a structurally different category from social media.

Tag: Moat + Product Truth

Refinement note 2026-05-10: Competitor scan post-HW#028 confirmed the original "no app-native competitor does this" framing was too broad and falsifiable in diligence. Refined to "no journey-cohort peer-support competitor does this" — narrower but defensible. Closest competitors found in software: Sincerely, Silent Ink, Unsent Letter Mailbox, Therapeer — all general-purpose emotional venting / letter exchange. None are journey-cohort matched or time-delayed memory systems.

Action: Create biz-why-dandyline.html using brand-shared.css + standard Founder Tools FAB. Seed the page with this entry as the first item. Add link from biz-dev-command-center.html TOC under the appropriate category (Business or Marketing).

Journey Vaults expose users to a community pool — the algorithm surfaces others at the same milestone (e.g., both on Day 30 of sobriety). Problem: what happens when surfaced content clearly doesn't belong, or is upsetting? The solution is not upvoting/downvoting (too social) or formal reporting (too punitive). Instead: a private, lightweight "soft sentiment signal" — something like "this didn't feel right" or "unrecommend" — that the creator never sees, generates no public count, and quietly feeds the algorithm. One flag = personal filter (never show me this again). Enough flags = pool-wide de-weight (content fades from circulation without anyone being notified). Seeds rotate in a growing pool — there are no view counts, no validation metrics. The act of sharing is the thing, not the reception of it. Key design questions: what does the gesture look like (long-press? swipe? single tap?), whether to offer soft category options or a single signal, how the algorithm handles personal vs. pool-wide flags, and how this interacts with hard vault rules set by the Journey creator. Migrated from coaching dashboard 04.09.26.

The emotional space between planting and blooming is currently invisible to recipients. What if recipients with pending vaults could see a 'Something is growing for you' indicator? Not what's inside. Not when it blooms. Just that something exists. Like a wrapped present under the tree. Drives retention (people check back), creates anticipation, and makes the bloom moment even more powerful. Needs UX design: where does this show up? How much do you reveal? What if the planter wants it to be completely secret? Added 04.12.26.

The Short Years built a business on one habit: plant one photo per week, get a beautiful book at the end of the year. DandyLine can do this better. A "Monthly Moments" Journey Vault template that sends a monthly prompt ("What's the most surprising thing that happened this month?") and nudges one photo or voice upload in response. At the end of 12 months, the vault blooms — not as a generic photo dump, but as a curated timeline of intentional moments. Key differences from The Short Years: cross-media (photos + voice + text), no printing required (but could trigger print upsell), family-shareable, and the bloom is a revelation rather than a product delivery. Needs: prompt library (12 monthly questions), notification UX for the monthly nudge, end-of-year bloom experience design, optional print-to-book upsell trigger. This is the "habit formation" template that solves the empty-vault problem — users who don't know what to plant now have a guided container. Added 04.22.26.

Update 2026-05-10 (post-HW#028 lock): the monthly-prompted-upload mechanism is now provided by HW#028's Personal Prompts system — any Journey vault (curated or Custom) can be set to monthly cadence. Whether to ship a "Monthly Moments" branded curated template in V1 was decided NO — V1 ships with 5 curated templates (Sobriety, Pregnancy/New Parent, Grief, Military Leave/Deployment, Weight Loss) + Custom catch-all. Branded Monthly Moments template deferred to post-MVP if user demand surfaces. See biz-dev-decisions-log.md 2026-05-10 entry.

When someone hits Day 30 of sobriety, how many seeds do they receive? From whom? Curated or random? Can they receive multiple? How does DandyLine verify a Journey milestone without violating privacy? If self-reported, what prevents abuse? Does the honor system work here?

PMF score is stuck at 3 because signups are intent, not behavior. You can close some of that gap before a full product exists using "concierge MVP" testing — manually simulating the DandyLine experience for a small number of real people. The goal is to find 3–5 real users (not friends being nice — actual potential users who have the problem) and walk them through the experience one-on-one. Start by identifying the specific moment in each person's life when they feel the problem most sharply. Then design a manual version of the plant-a-seed flow tailored to that moment — even if it's just you sending a message at the right time. The PMF signal you're looking for: are they upset when it doesn't work, or relieved that it did? One real person saying "I would have paid for that" is worth more than 100 waitlist signups. This could move PMF from 3 → 4 or 5 before any code ships, and gives you a real story to tell investors. Started as a coaching session (HW: Improve Market Fit Score) — pick up there for prompts and framework. Added 04.12.26.

The coaching advice is clear: find 3 couples getting married in the next 90 days, offer them a free vault, and document the experience. This is the fastest path to a real traction data point for investors and to moving PMF from 3 → 5. But "find 3 couples" is not a plan. A plan looks like: (1) Who specifically will Ashley reach out to? (2) What does she offer them? (3) What's the ask in return — feedback call? Permission to share their story? (4) What does she actually give them right now — a prototype, a manual experience, a promise? (5) How does she document it? This session is where that plan gets written. Added 04.12.26.

Four core growth mechanics, ranging from immediate viral coefficient (Shared Seeds) through event-based scaling (Event-Based Vaults) to trust-driven adoption (Founder Journey Vault, Public Vault Inspiration). Loop 1 identified as strongest.

The 5-year user-growth and revenue projection model — directional startup assumptions for planning only. Year 1: 50k users / $103k revenue → Year 5: 3M users / $24.8M revenue. Paired storage cost projection shows the business is sustainable if most content stays sealed.

Two complementary use cases that tell a powerful, specific story — worth developing as a targeted campaign or landing page, not a core brand narrative. **Direction 1 — The Deployed Gardener (Outbound):** A service member preparing to ship out plants a vault of seeds before they leave — scheduled to bloom on birthdays, holidays, first days of school, milestones. They may not have reliable internet access while deployed, but the seeds are already planted and will bloom on schedule regardless. The dandelion framing writes itself: you blow the seeds before the wind carries you away, and they land when they're meant to. Message to the family: I was here. I thought of you. I planned for this moment even when I couldn't be in it. **Direction 2 — The Family at Home (Inbound):** The family preserving the life happening while their person is away — capturing the moments their loved one is missing — so when they return, there's a vault of everything they missed, ready to bloom all at once or over time. A "here's what you came home to" experience. **The dandelion hook:** The dandelion is actually the official flower of military children — children raised to bloom wherever the wind carries them. This can be a marketing hook for this specific audience without needing to be the central brand story for everyone. **Potential partners:** USAA, Blue Star Families, Military OneSource, National Military Family Association. **What needs developing:** A campaign concept (which direction leads, or do both?), a landing page story, a specific vault template ("Deployment Vault"), and a pitch to at least one military-adjacent organization. Added 04.09.26. **Brand-sweep note (2026-05-02):** The "official flower of military children" reference was removed from biz-mktg-ad-ideas.html line 277 (the Ad Philosophy section — brand-narrative territory) and reframed as the dandelion-experience ("a flower you find without looking, a wish you make in a single breath, a seed that floats forward"). **The principle (Ashley clarified 2026-05-02):** Military-children / "dandelion people" / "carry your roots with you" language is *welcome inside campaign creative aimed at those specific audiences* — military families, immigrants, diaspora communities. It is *not welcome in brand-narrative material* (why-dandelion philosophy, brand ethos, founder story, ad-philosophy intros) where it would imply the metaphor describes everyone. **Reference uses that are correct (don't sweep):** The "Audiences" section of biz-mktg-ad-ideas.html (lines ~996-1000, "Long-Distance Families" card with "The original dandelion people") is a *correct* use of this language — it's audience targeting, not brand identity. **The partnership opportunity is preserved here** as a campaign-specific GTM angle — exactly as Ashley framed it: pitching DandyLine as a product for military families to preserve and schedule memories when they're unavailable. Develop the campaign here; do not reintroduce military-children language into brand-narrative files.

"Pressed" = permanent, added to your Pressed Flowers collection. "Compost" = organic decay — photos lose resolution over time, text is last to go. Emotional stakes: the bloom is something you could lose. Needs: compost window duration (~1yr free?), decay mechanics, "Compost Soon" filter UX, whether sender knows the outcome, storage tier integration.

The entire vault stays sealed until you physically arrive — not just one seed, the whole jar. Childhood home, engagement spot, family's country of origin. Different from location-triggered seeds (which are one seed inside an otherwise-accessible vault). Needs: GPS UX, sealed jar visual treatment, re-lock mechanics, arrival notification design.

"Buy a jar" = purchase a vault that permanently preserves everything inside it, no subscription required. Ideal for Legacy vaults and milestone collections. Also giftable — a grandparent could buy a preserved jar for a grandchild. Paired idea: vault compost notification — when a vault's payer stops paying, all members get notified that seeds are at risk, can see which seeds are already pressed by someone vs. unclaimed, and anyone can rescue an at-risk seed into their own storage. Needs: one-time vs. fixed-term purchase options, notification design, "Keeper" recognition for the volunteer contributor who funds the vault, and product pricing model.

This is one of the most consequential product questions DandyLine will face. When a gardener dies: (1) their unsealed future blooms must still bloom on schedule — the scheduler can't just stop; (2) their whole garden (pressed flowers, vaults, seeds) needs to go somewhere; (3) someone needs to be able to access or export everything. Competitors in the "digital estate" space include GoodTrust and Everplans — there's a whole category here. DandyLine's angle is different and more emotionally rich. Options to explore: designate a digital executor in advance (like a trusted contact), pre-paid legacy export purchase (one-time fee that funds a full archive delivery after death), or subscription tier that includes estate planning. Big infrastructure question: in a zero-knowledge encryption model, how do we pre-authorize a digital executor to decrypt the garden without compromising security during life? Added 04.09.26.

✅ Direction locked April 27, 2026. Core principle: treat the mechanics like Google Drive — admin/owner level vs. invited contributor level, with most changes allowed at admin level even after seal.

Decisions per setting:

(a) Add new recipient to a sealed vault — YES, allowed. Set as an option, not a default. Real use case: gifting — someone could buy/seal a vault and want to add the recipient later (gift card scenario). Treat like Google Drive's "share with new person" flow.

(b) Swap Guardian after seal — YES, allowed. Already locked in Section C7 of QUESTIONS-FROM-ASHLEY.md (Guardian replacement uses subtle notify flow — outgoing Guardian gets a dignified non-dramatic message). Guardian assignment provides flexibility regardless of whether the planter is alive or gone.

(c) Move bloom date after seal — RESTRICTED. The compromise: bloom date IS movable, because locking it is almost pointless (a planter could just delete + replant to work around it). But:
• Only the planter can move the bloom date by default.
• An assigned Guardian can move bloom dates if the planter has explicitly designated them with that authority — either for the whole vault or for specific seeds. Guardian designation provides flexibility "regardless of whether I'm here or not."
• Super Lock remains the override. When Super Lock is engaged, the bloom date is permanently immovable — no override, not even by Guardian. Super Lock is a PREMIUM feature (see HW#83 Premium Features). Adds to premium tier list.

(d) Edit vault name/description — YES, but ADMIN/OWNER level only. Don't let invited contributors change vault name on a whim — vaults evolve over time, but the framing should be stable. Like Google Drive: only admin can rename. Description updates make sense as the vault grows.
NEW · "Weather Update" passive notification when name/description changes: Subtle in-app notification (NOT a push), styled like a group-chat "X changed the vault name from Y to Z" announcement. Optional UI idea: show "(formerly: Old Name)" in parentheses for ~90 days as a transition marker. Goal: passive awareness without disruption — engaged users see it, others get a soft signal next time they're in the app. Add this to the Weather Update system spec (relevant card to scope: see notification system + bloom-prep flow).

Underlying mental model — like Google Drive: Owner/Admin (planter) has full editing rights. Invited contributors can plant/contribute but can't change vault-level settings. Co-admin role is a separate question that needs its own design pass — see HW#56 spawned questions for the co-admin/co-owner model design blocker.

Open scenarios Ashley wants prompts on (not yet decided):
• Gray area: changing who a specific seed is assigned to within the vault after seal
• Gray area: revoking a Seed Key before it's claimed (different from after-claim removal which is harder)
• Gray area: changing claim limits on Open Claim keys after issue
• Open: how do peer products (Gmail's drafts, Drive's shared docs, iOS Photos shared albums) handle these scenarios? Worth a survey before locking.

Original card added 04.12.26. Direction locked 2026-04-27 with Claude.

Spawned April 27, 2026 from HW#53 (Vault Settings Editability) and HW#56 (Generational Forwarding). The co-admin / co-owner model is the actual underlying design blocker behind several gray-area questions, and needs its own dedicated design pass.

The core question: When someone is invited into a vault, what role can they hold? Today the assumption is "contributor" — they can plant seeds. But several recent decisions assume there's another tier — someone who can manage the vault (rename it, swap the Guardian, take on responsibility/weight when the planter is gone). Like the Google Drive distinction between Editor and Owner / Co-Owner.

Why this is foundational: Without a co-owner role defined, several other decisions are underspecified:
• HW#53 (Vault Settings Editability) — the "admin-level only" gating for vault name/description changes only works if there's a clear admin/co-admin tier.
• HW#56 (Generational Forwarding) — when the planter dies and there's no Guardian, who picks up the vault? A co-owner is the natural answer.
• HW#85 (Hybrid Grove Guardian) — Vault Guardian vs. Contributor Guardian distinction overlaps with co-owner mechanics.

Tiers to consider (Google Drive-inspired):
1. Owner / Planter — full control. Can rename, change description, swap Guardian, modify settings, transfer ownership.
2. Co-Owner / Co-Admin — same powers as Owner except can't transfer or delete the vault. Can add other admins. Picks up vault management if Owner is gone.
3. Contributor — can plant their own seeds inside the vault. Cannot change vault-level settings. Can press their own seeds. Default invite role.
4. Viewer / Recipient — can see/receive blooms but cannot plant. Most restricted role.

Per-vault-type implications: Co-owner makes obvious sense for Grove (multi-contributor) and Legacy (intergenerational), but probably doesn't apply to Personal vaults (solo). Milestone and Journey are gray. Each vault type's deep dive (HW#86) should explicitly answer whether co-owner is allowed, default-on, default-off, or disabled.

What this card needs:
• Permission matrix: rows = actions (rename · invite · change Guardian · move bloom date · press · plant · etc.), columns = roles (Owner · Co-Owner · Contributor · Viewer)
• Per-vault-type defaults — which roles are available, which is the default invite role
• UX for "promote to co-owner" — should be deliberate, not casual
• Edge case: what happens when the Owner tries to leave / delete the vault and there's a Co-Owner? Does ownership transfer? Does the vault keep going?
• Schema impact: new vault_member_role column (or similar) replacing any binary "is_admin" flag

Peer-product reference points: Google Drive (Editor / Commenter / Viewer / Owner / Co-Owner) · Notion (Workspace Owner / Member / Guest) · iOS Photos shared albums (Owner / Subscriber). Worth a 30-min survey before locking the model.

Added 2026-04-27. Direction blocker for HW#53, HW#56, HW#85, HW#86.

Born out of the April 18 planting-flow session. The Roots vault page has the deepest, most resolved thinking of any vault type — it documents triggers, edge cases, identity, verification, ownership, location mechanics, abandonment, and Guardian logic in a way the other vault types don't yet match. Use it as the TEMPLATE and bring the other 5 vault types up to parity: (1) Personal Vault Deep Dive, (2) Grove Vault Deep Dive (pairs with HW#85), (3) Milestone Vault Deep Dive — must capture the "one vault, multiple internal bloom dates" structure (Wedding vault holds seeds for the wedding, 1-year, 5-year, 10-year anniversaries) with a minimum bloom floor; (4) Legacy Vault Deep Dive — must capture the non-morbid use cases (living grandparent to unborn grandchild, 50th-anniversary plant-today-bloom-later, company time capsule, teacher messages for future students) and the decision that Guardian is STRONGLY RECOMMENDED not REQUIRED; (5) Journey Vault Deep Dive. Each page should follow the Roots structure: Overview → Triggers → Who Can Plant → Seed Shape → Guardian Defaults → Edge Cases → Open Questions. This is foundational documentation debt — once done, the planting-flow doc can reference these as the source of truth instead of re-explaining each time.

Re-entry update 2026-05-10: Canonical audit + roadmap doc created — SCRATCH-Vault-DeepDive-Audit-2026-05-10.html in MASTER folder. Contains: (a) the canonical 13-section vault deep page template extracted from Roots · (b) a Roots audit identifying 4 stale items + 4 missing items · (c) a Journey deep page section-by-section map (HW#028 spec fills ~70%) · (d) Known Unknowns per vault type (starter questions for each of the 6) · (e) a 6-vault Order of Operations roadmap · (f) a copy-paste-ready prompt for the next deep-build session. Color + shape canonical locks confirmed per brand-vault-renditions.html — all 6 vaults specced. Session 1: Roots sweep + Journey new file (this is the canonical re-entry point). Sessions 2-5: Personal · Milestone · Grove · Legacy (in that order, by blocker severity).

The full walkthrough of what happens when a vault finally blooms: notification → sealed jar opens → preserved dandelion revealed → seeds explored one by one → multi-contributor reveals → long-term capsule evolution. This is the central DandyLine ritual and differentiator from any social memory format.

The full Roots concept: memories planted into real-world locations that unlock through presence, timing, or shared experience. Includes private root discovery, personal root trails, public roots layer, unlock mechanics, and the April 7 architectural decisions that rehomed Roots from its own vault type into a seed-level metadata variable.

Location needs to be a clearly available option when first planting a seed — both in the planting flow settings and as a nav entry point in the app. Model: if location services are on, auto-grab GPS and suggest nearby places (user confirms or adjusts). Manual search/type always available. Always skippable — location is never required. Needs: planting flow UI update to include location picker, nav placement decision for Roots access.

✅ DECIDED (April 15): Location granularity uses GPS with radius + named place ("Grandma's House"). Choose per seed or when setting up Roots jar.

🔥 PRIORITY. The planting flow starts from the medium (what you're planting) after tapping the Plant nav icon. Then prompts vault selection — established vault or new one. Vault rules gate what's allowed (schedule, type, etc.). If rules conflict, user gets: "The 'XXX' Vault has rules that only allow XXX. Do you still want to plant here? Or build/plant in a new vault?" Needs connection to A1 stat counter vault-building flow. Reference: ux-mockup-reference.html (screen order is close but layout needs work). Note: current mockup says "choose date for vault to bloom" which conflates vault unseal date and seed bloom date — must separate. Ashley's notes: see A1 Plane Workbook.

Each seed media type needs its own bloom/reveal pop-up card design. Photo cards exist (ux-bloom-reveal.html screen 10). Voice memo needs: animated visual + transcript display (is transcription an added tool?). Notes need: rich text rendering — do we allow emojis/formatting when planting text seeds? Also need "After the Bloom" prompts per media type. Heavy dev — this is a huge part of the experience. Reference: ux-bloom-reveal.html.

One vault holding multiple seeds with different bloom dates is a premium feature worth designing carefully before building. Three sketching tasks to complete:

Curator View (Gardener managing 4 seeds with different unlock dates):
— Dashboard layout: how does a gardener see all 4 seeds at once?
— Unlock timeline visualization: a horizontal or vertical timeline showing each seed's bloom date
— Per-seed controls: edit date, add/remove contributors, silence notifications
— How does the gardener see "who can contribute what"?

Guest View (someone added to a multi-seed vault):
— Initial view: all seeds visible (locked + unlocked), grouped by bloom date
— Filtered view: guest can show "only 1-year seeds" or "only bloomed"
— Countdown timers on each locked seed — how prominent? How styled?
— What happens when one seed blooms but others are still locked?

Roots Filtering System ("roots" = unlock date categories):
— Each unlock date = one "root" in the garden metaphor
— Visual hierarchy: show all seeds, but group by root/unlock date
— Filter by root: "Show only 1-year seeds" / "Show only bloomed"
— Users see full garden OR filtered garden view

Open Question to decide first: How many preset unlock date options do curators need? Options: 1-week, 1-year, 5-year, 10-year, custom. Or just custom always? Presets reduce friction for event-based vaults (weddings). Custom is more flexible but requires more input. Decide before sketching the curator controls.

The ux-planting-flow.html file holds the most thorough UX decision map in the entire project — 8 decision layers, 5 vault types, 5 media types, 7 bloom triggers, 26+ unique paths. Right now it's presented as an expandable decision-tree document, which works but doesn't feel like DandyLine.

The vision: redesign it as a visual interactive workflow map. Strong visual. A little subtle animation to keep it fun and alive. Hover or click each node to expand and read the detail underneath. The reader should be able to trace a path through the flow visually — not just scroll through a long document.

Must reference existing brand decisions for visual accuracy:
— brand-logo-marks.html — logo, marks, app icons
— brand-icon.js — dandelion mark renderer
— product-dandelion.html — canvas rules, animation reference
— product-vaults.html — canonical in-vault dandelion & jar rendering, dot language per vault
— product-seeds.html — seed color specs, lifecycle, state rules
— brand-shared.css + brand-system.html — tokens, palette, type

Design principles: no hard angles, no sharp animation easing (per brand-guide Don'ts), dark background, warm gold accents, organic/breath-like motion. Nodes should feel alive — not static diagram shapes.

Scope note: this is a full design session, not a cleanup pass. Do not combine with other work. When it's time, open with Opener D (thinking session) to sketch direction before building.

Added April 22, 2026 from the ux-planting-flow cleanup conversation.

The vault chooser needs decision logic, not just descriptions. "Is someone else planting with you? → Grove. Is this for a specific event? → Milestone." Also: what is the minimum viable planting ritual? How long should it take? What confirms to the planter that this moment has been honored?

product-seeds.html and the vault UX pages need updates to reflect the new preservation state design decisions. Specifically: the crystallized/shimmer visual for pressed seeds, the brown/amber composting tier appearance, the third "shared access" color state, and the "already preserved by [name]" indicator on shared seeds. The brand standards keep evolving as product decisions are made — this sweep should happen after Homework #13 (pressed seed visual) is resolved so changes can be applied consistently across all pages at once.

The current founder story captures the preservation angle well, but a new dimension emerged in session: the raw, everyday capture problem. Not just "I want to send this forward" — but "my kid just said the most hilarious, heartbreaking, perfect thing and I have nowhere to put it right now." The example: a funny thing a child said in their sleep, or an unexpectedly deep/embarrassing question they asked out of nowhere. You caught it in the moment. No video. No recording. Just your memory. And that memory will fade. Everyone — parent or not — has this feeling. The founder story should gain a beat that names this specific pain: the preciousness of a fleeting moment that has nowhere to go except a notes app nobody looks at. Keep examples vague and universal (avoid specific holidays or religious references). Also tie in the "personal vault as a joke archive" angle — even a solo vault set to Surprise scheduling, full of things-you-never-want-to-forget, is a deeply relatable use case. Added 04.09.26.

The nighttime skin has full design love. The daytime version doesn't. When the day/night toggle switches to light mode, several elements get lost or feel unfinished. Decision required before launch: either give the daytime skin proper full treatment (explore a "negative effect" approach — inverting the nighttime design logic so the two skins are true counterparts), or remove the toggle entirely and add full light mode as a future milestone. The toggle should not ship half-done. If removed short-term, document "Full Light Mode / Daytime Skin — Platform-Wide" as a post-launch item. Once built, the daytime color logic should be formalized in the Brand Standards & Design Guidebook alongside the nighttime system. Migrated from coaching dashboard 04.09.26.

✅ DECIDED April 21, 2026: Dark mode ships first. Light mode is HIGH PRIORITY before wider release — target after first 100 users. Approach: CSS variable swap (define a [data-theme="light"] override set — same variables, different values). Canvas elements and glows need individual attention but this is ~20-30% of original design effort, not a redesign. Accessibility driver: older users and bright environments. No toggle until light mode is fully designed.

Vocab note (locked 2026-05-02): "Theme" is the official term for visual day/night modes app-wide — replaces "Skin" everywhere. Distinct from "Bloom Mode" (HW#94), which is the reveal-experience layer for a Vault, not a visual theme.

Started in a dedicated session — working notes saved in dandyline-story-project-notes.md. One story per vault type: Grove, Personal, Milestone, Legacy, Journey, Roots. Milestone was attempted but kept feeling off because it started from the product mechanic (here's what it replaces, here's how timing works) rather than from a single human truth. The fix: restart each story from one specific character, one specific moment, and let the vault reveal itself through the story — exactly the way the ad ideas work ("Before I Forget," "Still Arriving"). Milestone re-entry point: try the bride's mom who quietly set the whole thing up without telling anyone, or the groom the night before. Reference biz-mktg-ad-ideas.html for tone and structure before writing each story. Read dandyline-story-project-notes.md before starting. Added 04.12.26.

✅ Resolved April 27, 2026. The canonical tone library now lives in product-seeds.html — a 21-word tone library organized by color family, not a flat list. The system auto-detects 1–2 dominant tones from the seed's title and notes (the gardener never picks a color manually). Two-tone seeds get halo treatment.

Canonical 21-word tone library (by color family):
• Gold — Joyful · Proud · Warm · Funny · Playful · Hopeful
• Sky (default if no match) — Reflective · Quiet · Peaceful · Nostalgic · Timeless · Practical
• Purple — Wise · Awe · Wonder
• Plus tones in additional families (Pink for Tender, Sage, etc.) — see product-seeds.html Section 02 for the full library.

Why both old lists were wrong: List A was too sparse (4 tones · couldn't hold grief), List B was too flat (no color-family structure). The new system is richer than either — it has emotional range AND drives a visual color system simultaneously.

How this got missed in homework: HW#113 was filed April 22; the tone library work happened in the April 27 parallel color-model session and updated product-seeds.html directly. The card didn't get back-updated at the time. Flagging as a closing-ritual / dashboard-sweep gap to watch for in future parallel sessions.

Source of truth: product-seeds.html (Section 02 · "Color says WHO the seed is") — auto-detection logic + halo behavior for cross-family vs same-family pairs both documented there. Bloomed 2026-04-27.

The foundational DandyLine vision: why it exists, what it solves, what it is, the meaning behind the name and dandelion symbolism, core taglines, capsule types, emotional story examples, and the "why now" cultural case. Celestial framing (sun/moon/stars) and military-children framing have been stripped per the April brand-sweep decision.

The "Emotional Storage" category positioning: why DandyLine isn't inventing new tech but recombining proven tech into a new emotional category. Differentiation vs Apple/Google Photos (media backup) and social media (attention platforms). The positioning reduces technical risk while increasing adoption potential.

DandyLine has made a real brand commitment — the "25-year guarantee," "50-year Legacy Promise," and "Sunset offboarding" plan if the company ever shuts down. Today the language lives in three separate places (product-vaults.html Legacy section, product-seed-keys.html Section 15, biz-competitive-landscape.html) with no single canonical home. Risk: pages drift, numbers fall out of sync, investors and lawyers can't point at one source of truth. Bigger question Ashley flagged: is this still a promise we want to make once we understand the real long-term storage costs? Card holds both the language-reconciliation work AND the financial-modeling decision until storage-cost analysis lands.

Captured 2026-05-10 PM session at Ashley's request — "Do a pre-mortem of the DandyLine app. Destroy my idea so I can build it stronger." Ashley has NOT yet reviewed as of the save timestamp. Read fully before reacting. Voice is intentionally harsh per the request — that's the deliverable, not a tone problem.

━━━ HOW TO USE THIS CARD ━━━

1. Read all 10 failure modes top to bottom. Don't argue with them on first pass — let them land.
2. After reading, answer the three "What to sit with" questions at the bottom. Those are the action triggers.
3. The output of this work is NOT "rebut Claude" — it's "which critique do I now treat as a hypothesis to test, and what's the smallest test that would falsify it?"
4. Cross-reference: each failure mode points to specific files (DEEP-AUDIT, decisions log, biz-why-dandyline) so the critique is auditable, not abstract.

━━━ THE PRE-MORTEM ━━━
Frame: It's November 2027. DandyLine shut down. Here's the autopsy.

1. Reciprocity-as-Architecture starved the very pools it was supposed to enrich.
The activation barrier ("you must plant before you can receive") filtered out 80% of users at exactly the moment they were most fragile: day 3 of grief, week 2 of sobriety, hour 6 of postpartum despair. The people who showed up to receive couldn't bring themselves to give in that state. So they bounced. Reddit's r/stopdrinking has a million subscribers because it's free to lurk. DandyLine's Journey Vault had 47 active sobriety pools at peak — most with 2–4 contributors per pool. Reciprocity didn't produce richer pools. It produced empty ones.

⚠ Warning sign today: No user has ever tested whether reciprocity-gating works in this category. biz-why-dandyline card #1 is a thesis, not a finding. The competitor scan found ZERO journey-cohort peer-support apps using reciprocity gates — that's the moat AND the warning. They didn't do it because someone tried it and it failed.

2. The bundled vault taxonomy was feature creep dressed up as a moat.
Investor #14 in the seed round asked: "What's your single best vault type?" You couldn't answer. Six vault types meant none were best-in-class. Storyworth wins family interviews. Tinybeans wins parent photo-share. SafeBeyond wins posthumous. Chatbooks wins printed photo books. DandyLine was 7th-best at six things instead of #1 at one. The "Six Vaults, One Story" investor card looked great in v0.1. By v3.0 it read as "we couldn't decide what to be." The persona-routing strategy was supposed to mask this — but Phase 1 (persona ranking) never finished, because every persona ranked roughly the same, because the product genuinely served no one persona dramatically better than the others.

⚠ Warning sign today: HW127-128 (MVP vault selection) is parked. Persona-routing is locked in concept but Phase 1 hasn't shipped. You're approving a strategy ("ship narrow from a wide engine") whose load-bearing decision ("which two or three vaults ship first") is open. That decision IS the actual product.

3. Posthumous trust is unearnable at indie scale.
A user signed up at 34 to leave Vaults for her newborn daughter. She wanted the daughter to receive them at 18 — 17 years away. She read the ToS, saw the indie scale, googled "what happens to legacy apps when they shut down," found StoryFile (Ch 11), Legacy Locker (acquired and shut), SafeBeyond (dead). She signed up anyway because she liked the brand. She paid $5/month for 14 months. Then DandyLine pivoted away from Legacy Vault entirely because the operational complexity (death verification, executor disputes, legal escrow) was bleeding the company dry. Her Vaults were migrated to a "read-only export." Her daughter, age 4, will never see them at 18.

The Guardian content-blindness card is architecturally elegant. Architectural elegance is not the same as institutional durability. Trust at 30-year horizons requires legal infrastructure, escrow partnerships, and corporate continuity that bootstrap economics cannot fund. The category dies at the moment users do diligence on the company instead of the product.

⚠ Warning sign today: You're going to ship Legacy Vault as a marquee use case without solving — or even costing — the death verification, legal escrow, and corporate-continuity problems that make Legacy delivery a real promise instead of a beautiful aspiration.

4. The brand was owned. The customer never was.
By month 18, you had: the prettiest dandelion brand in the category, the deepest ritual vocabulary, an investor list of 13 mechanics, and 847 paid subscribers. Lumhaa had 23 iOS reviews after seven years of trying. Cocoon Weaver had 311 reviews after thirteen. You were beating them — and going broke at the same pace they did.

DEEP-AUDIT scored Marketing Capability at 7 ("you can do your own marketing") with "no marketing track record yet." Memory/legacy apps are uniquely hard to market: Meta restricts grief-targeted ads, TikTok's algorithm punishes "heavy" content, organic discovery requires events (deaths, weddings, births) that no one wants to invoke proactively. The persona-routing plan assumed paid acquisition would work; it didn't, because the personas you were good for (long-distance grandparents, sobriety folks, military families) are precisely the audiences that platforms restrict ads to.

⚠ Warning sign today: No A/B test data. No cost-per-acquisition number. No conversion funnel measurement on existing landing pages. Your marketing strategy is theoretical, and the theory is "I have a marketing background" — which is true and not the same as "I have memory-app marketing experience."

5. The cost structure was a fantasy.
$22/month burn was real for Cloudflare + Resend. It became $1,800/month at 4,200 users and $11,000/month at 18,000 users. That's not Cloudflare scaling — that's:
• A part-time customer support contractor (because Journey Vault peer-pool moderation cannot be done in your spare time when 30 people are exchanging vulnerable content per day)
• A part-time content moderator (because someone planted CSAM in a Grove and you couldn't take it down within 24 hours)
• A lawyer on retainer (because two families are suing over a Legacy Vault delivery they say went to the wrong recipient)
• Identity verification API costs ($0.50–$3 per Seed Key claim at scale)
• PCI compliance, fraud chargebacks, refund processing time
• Insurance (E&O, cyber, professional liability)

The "low burn" framing was honest about Cloudflare and dishonest about everything Cloudflare doesn't include. By the time you noticed, the runway extension required either raising money (you didn't want to) or cutting features that made DandyLine DandyLine (you couldn't).

⚠ Warning sign today: biz-dev-financials.html has the dev infrastructure modeled. It does not have the operational infrastructure modeled. At any meaningful scale, the latter dwarfs the former.

6. Single-developer dependency was a single point of failure.
Josh took a job at Anthropic in October 2027. Six months earlier he'd been signaling burnout in side comments in QUESTIONS-FROM-ASHLEY.md. The audit scored Dev Resource Reliability at 8 based on commit cadence. Commit cadence measures throughput, not durability. When Josh left, the entire codebase had one person who understood it. Hiring at indie-scale economics meant offering equity-heavy comp to a developer who'd inherit a complex monorepo, take 3+ months to ramp, and make decisions you couldn't technically evaluate.

You had two options: pay senior salary you didn't have, or accept a 6-month freeze. You picked the freeze. During the freeze, two security CVEs in dependencies went unpatched, three competitors launched features you'd specced 18 months earlier, and your subscriber base churned 22% because new feature velocity is what kept paying users paying.

⚠ Warning sign today: No second developer, no documented onboarding for the codebase as it exists today, no contingency plan for Josh's exit. The "structured comms doc" workflow is a productivity tool, not a continuity plan.

7. The audit scored AROUND user validation, not THROUGH it.
DEEP-AUDIT-FINAL gave you a 7.5 viability score with 25 sub-scores. Twenty-four of them were assessable from documentation. One — User Validation — was a 5, and you scored everything else as if that 5 didn't matter. Architectural depth is real. Brand ownership is real. Cost discipline is real. None of them tell you whether anyone wants this product enough to pay for it twice.

Eighteen months later, you had your answer: 1,200 lifetime paid subscribers across all six vault types. Net-30 churn at 31%. ARPU of $4.40 (because most chose the cheap tier, and the premium tier features didn't justify $25/month for the audience that actually showed up). Annualized revenue at peak: $63K. Burn at peak: $14K/month. Runway: 4.5 months.

⚠ Warning sign today: Every other sub-score in the audit is theoretical until users validate. The audit knew this and flagged it. You acknowledged it and built v0.1 of biz-why-dandyline.html instead of HW109 (multi-audience GTM doc that ships) or a paid landing-page test or a 5-user paid-pilot. Building investor-narrative pages is what founders do when they can't bring themselves to test demand.

8. "Time Is the Medium" was a moat against competitors and a wall against indifference.
The thesis is beautiful and it's defensible in a Storyworth comparison — and most users never had that comparison in their head, so the moat solved a problem they didn't have. They had a different problem: they didn't know they wanted any of this until a specific event made them want it (engagement, baby, illness, deployment, parent decline). Event-driven acquisition has high cost and unpredictable timing. By the time the user wanted DandyLine, they'd already been routed by Google to FutureMe, Storyworth, or a printed photo book service. The category re-frame doesn't matter if the user never enters the category. You owned the diligence question and lost the search-intent question.

⚠ Warning sign today: You don't have organic search traffic data because there's no public site beyond dandyline.app landing. You're locking strategic positioning before testing whether the positioning is FINDABLE by the people you want.

9. The biggest bone-truth no one wants to say.
Founder fit scored 9.2 — the highest in the audit. That's also the riskiest score in the matrix because high vision plus high resilience plus low external validation looks identical to unfalsifiable belief. Every founder who's ever shipped a beautiful brand into a quiet market scored their own vision as a 10. The retroactive autopsies always include the line "she just couldn't see it wasn't working."

The audit's comment about your resilience — "devastation in the afternoon, reframing by evening, strategic clarity by night" — describes exactly the cognitive pattern that lets founders absorb negative signal and convert it into renewed conviction. That's heroic in winners. It's tragic in losers. The signal that distinguishes which one you'll be is EXTERNAL, and you don't have it yet.

The personal cost of failure isn't $14K/month. It's identity. You've built so much around being the founder of DandyLine that an honest pivot or shutdown will feel like losing yourself. Plan for that NOW, while you're still in the early innings — not in month 16 when the data is clear and your brain is rejecting the data because the alternative is unbearable.

10. The thing your existing systems are too polite to surface.
Look at the structure of your homework, your dashboard, your decisions log. Look at how much energy goes into deciding the right way to display vault status badges versus running a $200 paid-acquisition test. Look at the proportion of "spec-locked" decisions vs. "user-tested" decisions. Look at the fact that biz-why-dandyline.html exists before user-validation infrastructure does.

You are spending the resource you have least of (founder hours) on the work that produces the smallest signal change (architectural elegance) instead of the work that produces the biggest signal change (paying users). The audit framework, the lock tier system, the brand vocab, the auto-surfacing protocol Claude helped build this afternoon — all of it is founder-comfort infrastructure. It feels like progress because it feels like discipline. It is not the same as progress.

This is the hardest truth in the pre-mortem because every system in your project is optimized to confirm you're being disciplined. Including the system Claude helped you build this afternoon.

━━━ WHAT TO SIT WITH (action triggers — answer these to convert this card into next moves) ━━━

Q1. Which one of these 10 is closest to true today? Don't argue with the others — pick the one that lands. That's the one to act on first.

Q2. What would convince you you're wrong about the answer to Q1? If you can't answer that, the answer is unfalsifiable belief, not analysis.

Q3. What's the smallest test you could run in the next 14 days that would generate external signal — not internal artifact? Not a SCRATCH file. Not a decisions-log entry. A real-world action that produces a yes-or-no from a stranger.

━━━ RE-ENTRY ━━━

When you come back to this card: open in a private tab, read it without your laptop touching anything else for 20 minutes, then answer Q1/Q2/Q3 in writing (not in your head). The answers become new homework cards or a "plant a flag" decision. Don't spawn a debate session with Claude until you've answered the three questions yourself — Claude will agree with whichever way you frame it, which would defeat the purpose. External signal first, internal processing second.

The original homepage "Problem" section had strong stats and proof points (2800+ camera roll photos, 30-min social post half-life, 0 platforms built for later, 22% photo compression, 58% lost-in-transit stat, memory decay timeline, four problem cards: Performative Trap / Lost in Transit / Timing Problem / No Future Orientation). These were replaced on the homepage with the new emotional elevator pitch section on April 9, 2026. The copy is saved in the Copy Vault under "Founder & Investor Proof Points." The full original HTML with all visual treatments (animated counters, decay timeline, glass cards) is archived at archive/site-landing-problem-section-ORIGINAL-2026-04-09.html. These stats MUST live somewhere visible on the site — not buried in footnotes or reference docs. Best candidates: investor page, founder story page, or a dedicated "Why DandyLine" section. The visual treatment was strong — don't just dump the text, rebuild or relocate the original design. Added 04.09.26.

New users would automatically be added to a vault showing Ashley's journey building DandyLine in real-time. Some seeds pre-unlocked on Day 1; others unlock gradually over months/years. The question is whether Ashley commits to doing this or not — and if not, what growth mechanism fills the same role.

⚡ The Decision (Yes or No):
Will you document DandyLine in DandyLine? This is the core commitment question.

If YES — What to plan next:
— Name your first 3 seeds (examples: "Why I built this" voice note · Original logo + evolution timeline · First failure moment)
— Set bloom dates for each
— Plan cadence: weekly text (wins/failures/decisions), biweekly photos (UI before/after), monthly video (talking-head, honest, 3-5 min)
— Identify past content you can backfill: original pitch deck screenshots, early UI mockups, team photos, moments of doubt, breakthrough moments

If NO — What to answer:
— What other growth strategy excites you?
— Why doesn't the Founder Vault feel right? (discomfort, positioning, time?)
— What replaces Loop 3 (Founder Journey) in the growth model?

Tone Guide (NON-PERFORMATIVE):
✅ "I was terrified. Still am." · "This feature took 2 weeks and we're still not sure it works." · "I almost gave up here. Here's what changed my mind." · "We failed at this. Here's what we learned."
❌ "So grateful for this journey!" · "Excited to announce..." · "I'm so blessed to be building this"

Risk to mitigate: Could feel like "follow the founder" instead of "use the platform." Balance with public vault templates from 5+ different user types (weddings, births, personal journeys, collaborations).

🌱 Spawned May 11, 2026 from HW#103 — Ashley locked YES on the Founder's Vault commitment but flagged she needs a supporting system to make documentation easy and habitual before the app/vault is live. Without this scaffold, the commitment becomes a guilt-loop instead of a growth-loop. Priority: high. Do soon — not tonight.

━━━ ASHLEY'S FRAMING (captured 2026-05-11) ━━━
"I really do want to do this project of, like, actually starting to document this and build the system for it — the playbook of what I should be doing and when as recommendations to give me prompts and inspiration for doing it. I can act it out and make it feel like it was in real time. You even have all this reference material for how progress has been going and moments and things to maybe think about for inspiration. To me, this could be kind of something we build connected to the dashboard that we've been building and working from to kind of keep track of what I'm providing. And then I can just dump it in a folder for now, and later, we can upload it into a vault once it's live. It'll be way more fun to execute once the vault's already live and built, but I don't think I should wait that long."

━━━ WHAT THIS CARD BUILDS ━━━
1. The Playbook (prompts + inspiration engine)
A living doc — likely `biz-dev-founder-vault-playbook.html` — that gives Ashley scheduled recommendations: "This week's seed candidates: (a) record a 2-min voice note about the moment you knew the Translator Rule would work · (b) screenshot today's homework page and write 3 sentences about what changed · (c) audio diary of why you reframed HW#197 for Adam tonight." Auto-pulls inspiration from session activity (SESSION-LOG.md, git diffs, dashboard score movements, conversation excerpts). Reduces the "what should I document?" friction to zero.

2. Dashboard Integration
Add a Founder Vault module to `biz-dev-coaching-dashboard.html` or `biz-dev-command-center.html` showing: seeds planted this week · upcoming bloom dates · cadence adherence (am I hitting weekly text / biweekly photos / monthly video?) · backfill candidates from session log. Treats founder documentation as a tracked behavioral KPI like any other.

3. Dump-Folder Workflow (works NOW, before app is live)
A designated folder (e.g., `Founder Vault Dump/` in the MASTER folder or one level up · gitignored to keep personal media out of source). Ashley drops files in by date/topic. The Playbook tracks what's been dumped vs. what's still owed. Migration plan: when the real Founder's Vault is live in-app, port the folder contents → seeds with original timestamps preserved (so "real-time" feel is maintained even though some content was backfilled).

4. Real-Time Re-Enactment Mode
Per Ashley's framing: she can "act it out and make it feel like it was in real time" — meaning the system supports back-dating seed timestamps to when moments actually happened (vs. when they were captured). E.g., she records a voice note today about the moment in April when she renamed Roots from Field — the seed bloom date is set for the actual April moment. This is on-brand with DandyLine's whole philosophy (seeds bloom in their own time, not when convenient). Worth investor-list flag: "DandyLine treats founder authenticity as a product feature, not marketing copy."

5. Backfill Source Map
Index of where existing material lives that can become seeds: SESSION-LOG.md (dated narrative) · git commits (technical decision moments) · biz-dev-coaching-dashboard.html (scoring evolution) · conversation transcripts from major sessions · ChatGPT reference docs folder · Adam onboarding docs (collaboration moments) · early logo iterations · pitch deck drafts. Surfaces these as "backfill candidates" in the Playbook.

━━━ DELIVERABLES ━━━
1. `biz-dev-founder-vault-playbook.html` — the prompts/recommendations engine + cadence tracker
2. Dashboard module — new section in coaching-dashboard or command-center showing Founder Vault progress
3. Dump folder + naming convention — designated location + file-naming rules (YYYY-MM-DD_seedtype_description)
4. Backfill candidate index — surfaced as a seed-suggestion list in the Playbook
5. Migration plan doc — exactly how dump-folder content ports into the real Founder's Vault when live

━━━ EXECUTION SEQUENCE ━━━
• Session 1 (initial build): Ashley + Claude. Build the Playbook page + dump-folder structure + naming convention. Index the backfill candidates from existing source material.
• Session 2 (dashboard integration): Add the Founder Vault module to coaching-dashboard or command-center.
• Ongoing (weekly): Playbook auto-suggests prompts based on the week's session activity. Ashley dumps content. Counts update on dashboard.
• App-live trigger: Run the migration plan — port dump folder into the real Founder's Vault with timestamps preserved.

━━━ AUTO-SURFACED FOR EOD ━━━
Two biz-why-dandyline candidates from this card:
(a) "Founder-as-Product" — DandyLine treats founder documentation as a core product feature (not marketing). The vault that ships with the app already has the founder's journey planted in it.
(b) "Real-Time Re-Enactment" — Backdating-with-integrity. DandyLine philosophy lets founder seeds bloom in their own time, even if recorded later — turning the "should I have documented this in the moment?" anxiety into a non-issue. This is also a USP for ALL users, not just the founder.

Surface drafts at EOD.

This narrative traces a grandmother's emotional journey using DandyLine to preserve moments for her newborn granddaughter — from first realization through legacy continuity. It illustrates retention-through-love, relationship gravity, and how time-delayed memory delivery creates ongoing engagement. This is the anchor story for the founder/investor narrative.

The 5-layer TAM story for investor conversations. Layer 1: Smartphone users (6.8B global). Layer 2: Paid digital storage behavior ($100B+ market). Layer 3: Life event economy (trillions). Layer 4: Digital wellbeing ($200B+). Layer 5: Generational legacy (under-digitized). Category positioning line: "If social media monetized attention, Future Memory Platforms will monetize emotional continuity."

The long-horizon plan for DandyLine to create and dominate the Emotional Storage category. Phase 1 (Years 0–2): Time Capsule Platform MVP + early adopters. Phase 2 (Years 2–4): Premium Memory Archive Service. Phase 3 (Years 4–7): Global Digital Legacy Platform. Includes defensibility moats and long-term outcome possibilities.

CLAUDE.md already references this page as the "investor list / why DandyLine list" — a living document updated whenever Ashley says "add this to the investor list." The page doesn't exist yet, but the format is locked: each entry = the feature or decision · why it's brilliant from an investor/business lens · one tag from Moat · Virality · Cost Discipline · Retention · Investor Signal · Product Truth. The point is to compound — every clever design decision and architectural moat becomes a citable proof point in the investor narrative without having to remember and re-derive it later. Critical for any near-term investor-pitch / fundraise moment because the cathedral of decisions Ashley has built is currently scattered across CLAUDE.md, decisions-log, and session memory; this page makes them legible and quotable in 15 seconds. Build outline: hero (the one-line "why DandyLine") · running list of entries grouped by tag · last-updated timestamp · investor-direct landing variant. Add to biz-dev-command-center.html TOC under Business and link from biz-investors.html. Cross-link to biz-mktg-copy-vault.html and biz-dev-coaching-dashboard.html so it informs the running narrative score. Added 05.07.26.

⚠ Page is ON HOLD as of 2026-05-11. The current `biz-investors.html` has real content value but the layout is partially broken and the content is dated: ~30+ instances of generic "user/users" where DandyLine vocab says "Gardener", no May strategic locks absorbed (Persona-Routing, Six-Vault model, Reciprocity-as-Architecture, Journey Delivery Formula, etc.), last meaningful commit was 2026-04-11 — a month stale relative to where the investor narrative actually is now.

Strategy (locked 2026-05-11): Keep `biz-why-dandyline.html` as the active compounding dumping ground for new investor-narrative insights — that page grows organically every session. Hold `biz-investors.html` as a preserved-but-locked artifact (do NOT delete · do NOT archive). When MVP is closer to ship, do a substantial refresh of `biz-investors.html` that draws from the matured `biz-why-dandyline.html` list (it'll be much richer by then). Both pages stay strong, neither gets lost.

Lock applied 2026-05-11:

• `` attributes added (Lock Tier System per CLAUDE.md)
• `` added — search engines won't crawl
• Title bar updated to "DandyLine — Investor Narrative (ON HOLD · Refresh Pending)"
• Sticky on-hold banner inserted at top of `` — visible to anyone landing on the page, points to HW#211 and to `biz-why-dandyline.html`
• Moved from ✅ LIVE → 🔴 ON HOLD in `DEPLOY-STATUS.md`

• Content sweep: rewrite hero, paradox, problem, category, gap, product, market, model, retention, moat, roadmap, financials, whynow, signal, founder, ask, closing sections — pulling proof points from `biz-why-dandyline.html` entries that have matured by then
• Brand vocab pass: "user/users" → "Gardener" throughout; audit for any other generic tech terms per CLAUDE.md vocabulary table
• Moat section reconciliation: compare current 7 moat cards against HW#108's 6 layers — current page has 5/6 verbatim + 1 renamed ("Emotional Brand Ownership" became "Category Language Ownership", a narrower framing) + 1 extra (Cryptographic Time-Lock). Decide: restore HW#108's broader Layer 1 framing, keep the narrower one, or split into two cards.
• Nav sweep: remove/restore biz-investors links across the ~40 working files based on whether it's going public again at refresh time (currently in nav of nearly every page)
• Layout audit: investigate whatever's currently visually broken — Ashley flagged it 2026-05-11 ("looks broken and dated")
• Cross-link to biz-why-dandyline.html: add a "see also: the running compounding proof-point list" link in the moat or closing section

Vocab note (locked 2026-05-02): Renamed from "Vault Skin" to "Bloom Mode" to avoid collision with "Theme" (visual day/night, HW#32). A Bloom Mode is how a Vault reveals — wedding timeline carousel, baby book page-flip, sobriety counter+gallery, etc. Not a visual skin.

A Vault doesn't have to bloom the same way every time. Bloom Modes are different presentation modes that change how content is revealed when a Vault blooms — not the content itself, just the experience layer. Examples: a wedding Vault could bloom as a timeline carousel with music; a baby book Vault could bloom as a simulated book-flip; a sobriety journey Vault could bloom as a counter + gallery. Competitors (especially in the physical book space) have one output mode. DandyLine's digital-native model lets you pick the emotional experience, not just the container. Needs: a defined list of Bloom Modes (3–5 for MVP), design for each, and a "choose your Bloom Mode" step in the Vault creation flow. This is also a premium feature candidate — free tier gets the standard reveal; paid tier unlocks cinematic Bloom Modes. Added 04.22.26.

When a bloom arrives from a planter who has died, every touchpoint needs a softer, more reverent version. This includes: email subject lines (no "Grandma just sent you!" energy), bloom reveal screen (slower animation, warmer tones), seed detail pop-up cards (gentle indicator acknowledging the planter is no longer here), and the Gardener tab status display. The system needs a planter_status field (alive/deceased) to trigger the right language. This connects to HW#41 (notification system design) and ux-bloom-reveal.html. Needs its own copy + UX design session. Added 04.12.26.

Someone could create a vault for an ex or someone who doesn't want contact. The notification 'Someone planted something for you' could feel creepy or harassing. Design needed: recipients must be able to reject/block a vault BEFORE seeing content. 'Someone planted a vault for you — Accept / Decline / Block sender.' Declined vaults return to planter with no explanation. Blocked senders can never target that person again. Needs: block list system, notification copy, what planter sees on rejection, legal implications for harassment edge cases. Added 04.12.26.

Once a seed blooms, recipients should be able to download individual media files (standard, likely free). But what about bulk export? If someone wants to export an entire legacy jar — all the photos, videos, voice notes from their grandmother — that's a different beast. Large vault exports generate significant retrieval costs from cold storage and could be a paid feature. Core mechanics to define: single-file download UX, expiring signed link behavior (the download link should expire — how long? 24hrs? 72hrs?), bulk vault export flow (async job + email link when ready), and whether bulk export is free or paid. Added 04.09.26.

The Security Architecture Brief v2 (DandyLine_Security_Architecture_Brief_v2.docx) needs a full sweep to reflect decisions made since it was last updated. Key new areas that likely have implications: the preservation state model (pressed / composting / degraded tiers), shared vault storage economics (one payer, many beneficiaries), the buy-a-jar permanent storage concept, compost notification mechanics, and the volunteer Keeper model. Do not update in isolation — review the full doc first, cross-reference all product notes from 04.07.26 onward, then update comprehensively.

How DandyLine enforces time-locked content — so that even DandyLine itself cannot open a seed before its scheduled bloom — requires an architectural decision with serious moat implications. Three options: (1) Third-party escrow — seed encryption keys held by a neutral third party, released at scheduled time. Simple to implement, introduces a trust dependency. (2) HSM (Hardware Security Module) — a physical enterprise device manages key release on schedule. High security, high cost, used by banks and payment processors. (3) Smart contract — a blockchain-based contract holds release logic in publicly auditable code. Trustless, but adds Web3 complexity and infrastructure overhead. The choice affects the security architecture brief, the investor narrative ("even DandyLine can't open your seeds early" is a strong moat statement if it's architecturally enforced), and the cost model. Foundational decision — needs technical advisor input before building. Migrated from coaching dashboard 04.09.26.

Every open technical item on the homework board — time-lock cryptography, GDPR selective deletion, the full build roadmap — ultimately needs a person to build it. The MVP can be constructed with Claude/AI assistance as a PWA, but the path from family MVP to public product at scale requires a technical lead who can own the architecture. Options: (1) Technical co-founder — equity-based, permanent partnership; ideally someone with consumer app experience and some background in media storage or security. (2) First engineer hire — post-pre-seed, transactional but clearly scoped. (3) Fractional CTO — part-time advisor available during MVP phase to make key architectural decisions, then steps back. Investors at pre-seed stage often want to see a technical lead or at least a credible technical plan — worth having someone in place before the round closes. Entry paths: wedding tech founders (warm via guest book vault angle), Alzheimer's/memory wellness founders, consumer app accelerators, YC network. Migrated from coaching dashboard 04.09.26.

✅ DECISION LOCKED (April 12, 2026): Stack is now Cloudflare-only. Josh (technical advisor) recommended dropping Supabase in favor of Cloudflare D1 + Workers — keeps everything in one ecosystem, stronger architecture at scale. Ashley created Supabase and Resend accounts during this session but pivoted before integrating. Supabase account can be left idle or deleted — no integration was built. Resend account stays — still needed for email delivery (bloom notifications). NEW Step 00 plan: Josh is setting up Cloudflare D1 (database) and wiring wrangler.toml to bind D1 + R2 to the Pages project. The 4 core tables (profiles, vaults, seeds, bloom_schedule) will be recreated in D1 using SQLite syntax. Re-entry point: Josh completes D1 setup → come back to Claude to start writing Workers functions and the planting flow.

The 5 seed types are: photo, video, voice note, written note, and mixed. But the actual technical limits have never been defined. What file formats are accepted? (JPG/PNG only? HEIC from iPhone? MOV from iPhone video?) What's the max file size per seed? What's the max storage per vault? Per account on the free tier vs. paid? These decisions directly shape the R2 storage cost model, the upload UX, and what the Memory Health Bar (HW#12) actually measures. Without them, the storage model can't be finalized and the upload flow can't be built. Added 04.12.26.

The happy path: vault blooms → recipient gets email → they open it. But what about failure? The recipient's email no longer exists (typed 15 years ago). The email bounces. The link expires before they click it. For a 10-year bloom, some of these failures are almost guaranteed. Decisions needed: Does the planter get notified of a failed delivery? Is there a retry window? Is there a secondary SMS delivery via Twilio? Is there a recovery URL the planter can share manually? This needs to be designed before the Cloudflare Cron Trigger bloom scheduler is built (Step 7 of the build). Added 04.12.26.

Before any real person uses DandyLine — even a family member — there needs to be a way to verify the full flow works end to end: plant a seed → seal a vault → set a bloom date → confirm the Cloudflare Cron job fires → confirm the email arrives via Resend → confirm the recipient can open the bloom. This is especially tricky because the whole point is a time delay. Plan needed: How do you set a "test bloom" for 5 minutes in the future? Is there a dev mode that bypasses the date lock? What's the checklist? Build this alongside the Cron Trigger step, not after. Added 04.12.26.

Cloudflare has a Startups program offering free or deeply discounted credits for Pages, Workers, R2 — the exact stack DandyLine already runs on. Applying takes about 20 minutes and costs nothing. If approved, it reduces running cost at scale from ~$50/month to potentially $0 for a significant period. This has been mentioned in strategy notes and then dropped every session. It's a real-world action only — Claude can't apply for you. But Claude can pull up the application and walk you through it. Do this before the MVP launches. Added 04.12.26.

DECISION LOCKED: Switching from Resend to Cloudflare Email Workers (~$5/mo). Keeps the entire stack on Cloudflare — simpler billing, fewer vendors, native domain sending (hello@dandyline.app). Steps: (1) Set up Cloudflare Email Workers in the dashboard, (2) configure DNS records for sending from dandyline.app, (3) update Josh's API code to use CF Email instead of Resend, (4) remove any Resend API keys/configuration, (5) cancel Resend account if one exists. This is a priority because email verification and password reset already depend on a working email provider.

Guests contributing to a vault from a web link (no app download required) is a powerful growth mechanic — but it raises a security question that needs to be understood before building. This is a learning task, not an implementation decision yet. Estimated time: 20 minutes.

Research task: How do these platforms handle temporary/timed access to sensitive content?
— Dropbox — how do shared links expire? How is content protected between upload and access?
— WeTransfer — content is available for 7 days then gone. How is it secured in the window?
— Signal — disappearing messages. What's the encryption model?
— Proton Mail — end-to-end encrypted email. How does a non-Proton user receive a message?

Questions to answer after research:
— How would you technically ensure a seed is inaccessible until a future date?
— Is server-side decryption safe, or should decryption happen client-side?
— If a guest contributes a photo via web, how do we prevent it from being extractable before bloom day?

Why this matters: The web-contribution flow (Idea 3 from the April 18 session) is high-value for growth but needs a sound security model before Ashley commits to building it. Understanding how established platforms solve this will inform whether DandyLine can do it cleanly or whether it's too risky for v1.

Note: this research is the prerequisite for any decision on Idea 3 (Web-Based Contributions). Do not design or build the feature until this is done.

Every page in the DandyLine folder has its own nav, and they're inconsistent — different logos, different icons, different menus, some still reference pages meant to stay hidden. Sweep the ~40 pages into one canonical nav so the experience is consistent regardless of which page you land on first. May 2 update: Canonical nav spec is now LOCKED (decisions-log Restyle Q1). The actual sweep work is tracked under HW#201 ⑤ port-DoD audit and ① brand-nav.js build. This card sits at 🎯 Spec tier — moves to 🔨 Component when the sweep runs, ✅ Live when all ~40 pages pass the port DoD.

The near-term founder action roadmap — what to do in the next 30 days, 3–6 months, 6–12 months, and 12–24 months. This was written in March 2026 as a reference checklist; many items are now in progress or complete (e.g., waitlist launched). Preserved here for horizon-checking during Phase B.

After the 4/25 Phase C-3 regroup-by-Quest, cards in low-population Quests (Sound Design = 1 card, Bloom Day Ritual = 1 card, Military Families = 1 card, Post-Launch Support = 2 cards) stretch to full row width because the .hw-grid uses grid-template-columns: repeat(auto-fill, minmax(300px, 1fr)). The 1fr tells leftover space to stretch single cards across the whole container. Result: cards look like columns, not cards. Likely fixes: (a) cap individual card max-width (e.g. max-width:380px), (b) change 1fr to auto on Quest sections, (c) use justify-content:start. Pick whichever preserves the multi-card layout for big Quests (Family MVP 18, App Design System 16) without stretching small ones.

Audit complete. The "What to start next session" widget (lines 586–613 in biz-dev-homework.html) is being actively maintained — most recent update references REVIEW-BOARD-2026-05-07.md + SESSION-HANDOFF-2026-05-07-EVE.md with structured tier-A-through-H priorities. It's manual (not auto-generated from BUILD-RESUMPTION-NOTES.md), but the manual maintenance is happening session-over-session, so the widget is fulfilling its purpose. Decision: KEEP. No further action needed.

Confirmed 5/7 — the widget is intentionally stubbed, not broken. The HTML, CSS, and collapse/expand JS are all present in biz-dev-homework.html (around line 817–834), but there is NO JavaScript that scans cards by data-priority + data-status and renders them into #next5-list. The placeholder text says: "Next 5 will populate once cards are retro-tagged with data-priority and data-status (Phase B + D)." Phase B retro-tagging is largely done — most cards now carry data-priority and data-status — but the Phase D wiring was never built. Result: the widget at the top of the page sits empty no matter how many priority items get added, which is exactly what Ashley feels.

Ashley flagged 4/25: the "VIEW" toggles on the homework page don't work yet. The Ripeness lens was wired (filter chips worked for status), but the Owner and Area lenses were cosmetic placeholders labeled "soon" — clicking them did nothing functional. The Quest restructure (Phase C-3) had moved cards into quest-{slug} sections, and the lens grouping JS that would have made Owner/Area lenses live was never built.

Two navigation aids that the homework page needs after Phase C-3 split it into 22 Quest-grouped sections. Both consolidate here because they share the "make the page feel less heavy" goal and would be built in one coherent design pass.

Two small housekeeping items captured 2026-05-02 from the cleanup session. **(1) Moleskin folder pending archive:** The "Moleskin Journal App - Screenshots for Ideas/" folder is gitignored and currently in active use by Ashley in a parallel session. When that session wraps, move the folder to ARCHIVE/ via the normal flow (copy first, then delete original after explicit go-ahead). **(2) Stale RESUME doc audit:** RESUME-2026-04-25-CONTINUE-GLOBE.md is conceptually stale — it claims V2-FAITHFUL is "the current active globe build" but the project is now on V4. Sweep all RESUME-* docs for similar staleness; update each to point at current state OR move outdated ones to ARCHIVE with a SUPERSEDED- prefix. Inventory first via `find . -maxdepth 1 -name "RESUME-*"`. Re-entry point: open this card, run the find command, decide per-doc whether to update or archive. Added 2026-05-02.

Right now functions/api/waitlist.js captures email only — passive intent with no activation moment. Ashley wants to upgrade the waitlist into a real launch list: when DandyLine is ready for testing, push one button and every opted-in person gets a personal-feeling text from Ashley Sparks ("Hey — DandyLine is ready for you to try. Would love your participation. — Ashley"). This converts passive list to warm beta tester far better than another email blast, and gives Ashley her first real activation moment.

ux-mockup-reference.html (Visual Concept v5) is a strong reference starting point — 7 screens showing the full planting flow arc. Key elements worth keeping: button patterns, seed depth layers (Near / Mid / Far), vault-opening sphere, and the flow from Home Timeline → Vault → Content Type → Vault Selection → Bloom Timing → Sealed Confirmation. Needs a rebuild using current design decisions, updated vault types, and in-vault dandelion rendering (in-vault style from product-vaults.html). Reference the existing file, don't start from scratch.

The bloom reveal has been designed (ux-bloom-reveal.html). The planting flow is being designed. But the in-between state — a vault sealed and waiting — has no UX. When a Gardener visits a sealed vault before it blooms, what do they see? A countdown? A visual of the sealed jar? Can they still add seeds? Can they peek at what they planted? Can they un-seal it? This middle state is where users will spend the most time (months or years), and it's currently blank. The visual language for "sealed but not yet bloomed" needs to be designed before the vault UI is built. Added 04.12.26.

Power users (grandparents with many grandchildren) could end up managing a LOT of Seed Keys. If the Gardener tab becomes a wall of codes and statuses, it loses the emotional magic. Design principle: group keys by vault, not by individual key. Show the people, not the codes. 'Emma — Invited, waiting to join' is better than 'SK-7X9K2M — status: invited.' The key is a backend mechanic; the human is what the Gardener sees. Needs: Gardener tab information architecture, grouping logic, search/filter for heavy users, mobile-friendly card layout. Added 04.12.26.

Full gardener profile system. Includes: photo, "gardening since" date, stats (# vaults, # planted seeds, # received seeds). Editable display names (Snapchat-style — "Granny" instead of "Judy Dobbs"). Shared vaults view. Quick-action prompts: plant a seed to this person, add them to a vault, build a vault with them. First-time setup: determine required vs. optional fields (keep it minimal for invited users). Discoverability: default to discoverable? Private option? If private, how are they found — by code only? Consider badges/levels based on contribution (future). Ashley wants guidance on what profile stats should be public vs. private vs. user-choice.

Every time a new HTML page gets built, the nav/menu formatting drifts — nav placement, logo position, founder FAB, footer links all render slightly differently across pages. This is a sprawl problem that compounds silently. A proper design session is needed to: (1) Design mobile + desktop nav side-by-side — lock logo placement, primary nav structure, secondary/dropdown items, bottom-right widget behavior, footer. (2) Build a shared nav component — likely a `brand-nav.js` include (pattern modeled on `brand-icon.js` / `brand-shared.css`) so each page renders nav from one source of truth; changes propagate everywhere. (3) Two nav modes from one component: PUBLIC nav (visitors see — product-*, brand-*, site-landing, biz-investors, biz-mktg-founder-story) and FOUNDER nav (Ashley/Josh/Adam internal — biz-dev-*, biz-legal-counsel, biz-competitive-landscape, homework, dashboard, command center). (4) Status system for in-progress pages — data-status attribute on links (`live` / `in-progress` / `vision-board` / `coming-soon`) rendered with a DandyLine-branded badge like "Vision Board — growing" instead of generic "Coming Soon". Pages stay viewable in their natural habitat on mobile + desktop even when rough. (5) Hidden founder zone — LOCKED April 18, 2026: the hidden zone is called **Greenhouse** (on-brand — where things grow before they're ready to bloom). Unlinked URL `dandyline.app/greenhouse` that only Ashley/Josh/Adam bookmark; houses all `biz-dev-*` internal pages; tagged `noindex` so search engines skip; public nav never references it. Optional future: keyboard shortcut "secret handshake" (Cmd+Shift+D) on public pages reveals hidden founder links. (6) Consistency rules for CLAUDE.md — add to session-start protocol: "If this session touches any HTML page, check it uses shared nav include before closing." Add a rule: "Never hand-copy nav HTML into new pages — always use the shared component." (7) Sweep existing HTML files to standardize once the component is built. Critical blocker to resolve before the nav diverges further. Coordinates with HW#69 (Button Design System) — both are design-system consistency work that should share a session arc.

April 18 session: patched `ux-field-homepage-v3-motionmark-depth.html` and `ux-roots-arrival.html` with an `@media (max-width: 419px)` rule that collapses the decorative phone-frame mockup into a fullscreen layout on real phones — fixes the stat-counter cutoff and general overflow on narrow viewports. `ux-planting-flow.html` was checked: it's a documentation page (max-width:1200px), no cutoff bug. Remaining `ux-` and `product-` files that use a phone/frame mockup pattern should get the same treatment so Ashley can view everything in its natural habitat on mobile. Files to audit: `ux-bloom-reveal.html`, `ux-vault-flow.html`, `ux-button-system.html`, `ux-button-decisions.html`, `ux-component-decisions.html`, `ux-filter-decisions.html`, `ux-mockup-reference.html`, `ux-style-guide-draft.html`, `ux-reference-key-moments.html`, `product-dandelion.html`, `product-seeds.html`, `product-vaults.html`, `product-roots.html`, `product-seed-keys.html`. Also: SESSION-BRIEF.md referenced `ux-field-homepage.html` but actual filename is `ux-field-homepage-v3-motionmark-depth.html` — update the brief. Goal: one consistent media query pattern that any `ux-` or `product-` file can import from `brand-shared.css` once HW#87 (nav redesign) lands a shared include approach.

A live counter showing how many gardeners exist in the world. Low technical effort (a single database count query), high emotional and marketing value. Like Kickstarter's backer count — it signals momentum, builds social proof, and makes early testers feel like they're part of something. Could live on: the landing page ("Join X gardeners already tending their vaults"), the founder dashboard (private growth view), or even inside the app as a subtle community signal. Framing ideas: "X Gardeners worldwide" / "X Groves in bloom" / "X seeds planted and waiting." Also consider: a founder-only dashboard view showing gardener count over time (a growth curve), vault count, seeds planted, blooms delivered. This data tells the founder story when pitching. Extremely cheap to build — just a counter query on the users table. Add to the founder dashboard and landing page simultaneously. Added 04.09.26.

The waitlist is live and people are signing up. But after they submit, nothing happens — no welcome email, no follow-up, no "here's what's coming." Every person who signs up already felt something, and that moment fades fast if it goes unacknowledged. What should they receive? A welcome email immediately? A second email a week later with the founder story? A "we're getting closer" update when the MVP launches? Resend is already in the stack — the infrastructure is there. This is a writing task more than an engineering one. Write the sequence first, then build it. Added 04.12.26.

Define DandyLine's monetization strategy. This decision gates product design (what's free vs. paid), vault size limits, sharing restrictions, and the entire pitch deck financial slide. Explore: (1) Freemium subscription — free tier (3 vaults, text-only) vs. paid ($4.99–9.99/mo for unlimited vaults, photos, video, Grove sharing, custom bloom ceremonies). (2) Storage tiers — free 500MB, paid 5GB/50GB. (3) One-time vault packages — Wedding Vault ($19.99), Baby Time Capsule ($14.99), etc. KEY INSIGHT: one-time packages have massive virality potential — a wedding vault onboards 50-200 guests into DandyLine instantly. Gifting packages ($15 to give someone a vault) might be the best customer acquisition cost you'll ever spend. (4) Enterprise/institutional — schools, hospices, military families, funeral homes, therapists (annual contracts). (5) Marketplace potential — professional "Gardeners" (photographers, videographers) who plant seeds for hire. Consider: which model matches the emotional nature of the product? Subscriptions feel transactional; one-time purchases feel like gifts. Maybe hybrid. Draft a rough model with estimates even if incomplete — Ashley needs something tangible to think through.

🌱 MAY 11, 2026 REFRAME — Adam's deep research brief
Reassigned to Adam (was Ashley). Reframed from "jar preservation pricing" into the master pricing-strategy + perpetuity-mechanics map. Ashley's directive: "This feels like a deep research session I want Adam to own — if he started from scratch but thought through all these scenarios, what to consider, and what to build a map for in a pricing model that covers all the possible holes and also makes it a really strong business model structure."

Two of DandyLine's strongest differentiators are currently buried in internal notes and need to be surfaced as named, articulated USPs — in the investor page, brand guide, and eventually consumer-facing copy. 1. ONE-PRESS-FOR-ALL: In a shared vault, one member pressing a seed preserves it for everyone with access. No one else needs to pay. "When someone in your vault preserves a memory, it's safe for everyone who shared it. One press. Protected for all." Investor angle: creates organic, emotionally-motivated upgrade behavior — the family member who cares most becomes the natural subscriber. No dark patterns. Needs: named feature callout in product-seeds.html, investor talking point in biz-investors.html, and eventual consumer-facing explainer copy. 2. THE GIANT VAULT MOMENT: When a large vault blooms all at once and tips a user over their storage cap, the upgrade prompt appears at an emotional high — they just experienced something meaningful and have a genuine reason to want to keep it. This is upgrade pressure through emotional stakes, not algorithmic manipulation. Needs: investor talking point, UX spec for the storage-cap prompt experience, copy for the "you're running low" notification. 3. STORAGE MODEL (locked April 21): Everything bloomed stays alive until storage cap is hit — not on a time clock. Free tier = smaller cap. Paid = more room. Upgrade prompt: "Your garden is getting full. Want more room?" This model needs to be reflected in product-seeds.html, the brand guide pricing section, and the investor page. Done when: all three are documented in biz-investors.html as investor talking points + product-seeds.html as feature specs + copy candidates in biz-mktg-copy-vault.html.

Short Years sells their app as a gift ("get this for the new parents"). Kept Collection sells a $59 physical baby book as a gift. DandyLine's version: buy a pre-configured vault as a gift — "Here's a 'First Year Baby Vault' — ready for you to start planting, blooms on their first birthday." The purchaser pays, configures the vault type and bloom date, and sends a gift link to the recipient who activates it. The recipient immediately has a beautiful, pre-named vault with a meaningful bloom date — zero setup friction. Gift Vault is the lowest-friction acquisition channel DandyLine has: (1) buyer joins to give, (2) recipient joins to receive, (3) family plants together = instant Grove behavior. Pricing anchor: a $19.99 "Baby's First Year Vault" or $14.99 "Anniversary Vault" gift is a genuinely thoughtful present — and it costs less than a photo book. Needs: gift flow UX, pricing tiers, vault template configurations per gift type, gift message (physical card or digital), fulfillment (email delivery). This pairs with HW#60 (Seed Key as Physical Product) — a physical gift card variant. Added 04.22.26.

The competitive landscape research surfaced a powerful investor narrative that needs to be developed into a slide and pitch moment. The story: parents today are spending real money across multiple products to solve ONE problem — preserving their children's lives and memories. They might buy: Kept Collection ($59 baby book), The Short Years ($89 annual package), HappyMe Journal ($22 wellbeing journal), Little Life Stories (subscription), Artkive ($75 art book). That's $250+ in one-off purchases per year, none of which talk to each other, none of which are digital-first, and none of which have a time-capsule layer. DandyLine is all of these in one app — and it grows with the child from birth to 18 (and beyond). The investor ask is not "why DandyLine vs. Google Photos" — it's "why pay for 5 products when one app does everything those products do, plus the thing none of them do (bloom delivery, time-delay, cross-family contribution)." This should become: (1) an investor slide showing the fragmented product landscape and DandyLine's consolidating position, (2) a pitch moment where Ashley names the products and prices out loud — "parents today are spending over $200 a year across apps and books that don't connect. DandyLine is the one place that replaces all of them", (3) a "problem slide" companion to the current investor deck. Needs: competitor price mapping table, slide design, pitch language rehearsed. Added 04.22.26.

When multi-seed vaults launch, one metric should tell you whether the feature is working. Pick ONE from these five candidates and define a specific target:

1. % of vaults created with 2+ seeds — measures immediate adoption of the multi-seed feature
2. Avg time spent organizing/curating a vault — measures engagement depth (higher = more invested)
3. Repeat organizers (created 2+ vaults) — measures retention and habit formation
4. Guest conversion to app download — measures viral loop effectiveness (does multi-seed bring in new users?)
5. Guest conversion to own vault creation — measures full funnel (from recipient to creator)

The exercise: Pick one. Then define a target with a timeframe. Example format: "30% of vaults have 2+ seeds within the first 90 days of launch." Without a specific target, you can't know if the feature is working or just being politely ignored.

This is a ~20 minute decision session. Bring it to Adam — his financial analysis background is exactly right for this kind of metric definition.

Create a dedicated living page for every moment where DandyLine's design serves a brilliant, non-obvious business or investor purpose. Each entry: the feature or decision · why it's brilliant · one tag (Moat · Virality · Cost Discipline · Retention · Investor Signal · Product Truth). Triggered any time Ashley says "add this to the investor list" or "add this to the why DandyLine list" — Claude appends immediately, same session. File goes in MASTER folder, added to Dashboard Sweep, linked from biz-investors.html and Command Center TOC. Decided April 26, 2026.

Once the file is built (HW#173), do a one-time sweep to pull all existing "investor value prop" moments scattered across QUESTIONS-FROM-ASHLEY.md, biz-dev-homework.html, and session notes. Known entries already waiting: export filename as brand touchpoint · storage upgrade at emotional bloom moment · one-press shared vault preservation · Cloudflare startup program timing · 5 growth metrics tracked from day one · parents spending $250+/year on fragmented products (HW#100). Blocked by HW#173.

Adam takes lead on building DandyLine's financial roadmap — the path from pre-revenue indie startup to a real, profitable, sustainable business. The Apr 24 audit confirmed DandyLine is going indie/bootstrapped (not VC-track), so the work here is bootstrap business modeling, not pitch-deck math. This card is also Adam's entry point into using Claude for the first time. Claude can walk him through every step below; he just needs to ask out loud.

Goal: a defensible financial roadmap that answers (a) what DandyLine needs to gross to be a sustainable business that supports a full-time founder, (b) the realistic path to that number across Year 1 / Year 2 / Year 3, and (c) which milestones change the cost stack (Josh's eventual compensation, legal, infra scaling, marketing spend, contractors, taxes). Final output: a 3-scenario financial model (conservative / base / aggressive) plus a recommendation on entity structure.

Why this is priority: right now every revenue conversation is operating on industry-shape extrapolations, not validated numbers. Until the foundation pieces below are real, any operating plan is a vibe with numbers attached. Adam is the right owner because the judgment calls — entity structure, compensation philosophy, the cost-stack reality, household-level financial planning — are his domain. Ashley + Claude work alongside; Adam leads.

Do these in order — top-down math is fiction until ①–③ are done:

Twelve-slide pre-seed deck outline from opening vision through the ask — plus the underlying psychological adoption strategy (why people adopt memory tools, who the early adopters are, which retention psychology mechanics keep them). Includes the behavior loop (Capture → Plant → Anticipate → Unlock → Reflect → Share → Repeat) and the goal habit: "I need to save this in DandyLine."

From day one, capture how every user arrived. This data is invaluable for pitching, fundraising, and understanding growth loops. Three layers to build: (1) Automatic attribution — if someone signs up through a vault invite link, that's tracked automatically (who invited them, which vault). This covers most early users and requires no extra input. (2) Referral links — every gardener gets a unique shareable link (dandyline.app/invite/ashley). When someone signs up through it, the referrer is logged. No relying on user memory. (3) Self-reported at signup — a single optional question: "How did you find DandyLine?" Options: Invited to a vault / Shared by a friend / Founder invite / Saw it somewhere. Keep it one tap, never required. The goal is to know: organic vs. invited, and who the super-sharers are (people like Ashley's sister who could bring in many users at once). Build the invite link system in Phase 1 — it also solves the Grove invite UX problem at the same time. Data to store per user: source (vault_invite / referral_link / direct / self_reported), referrer_id, referral_vault_id, signup_date. Added 04.09.26.

The strategic decision (locked 2026-05-07): DandyLine ships with the full vault engine intact — all 6 vault types in code — but the v1 surface (homepage, intake, onboarding, ads) leads with 2–3 persona-routed front doors. Each Meta/TikTok/etc. ad targets a single persona. An intake screen ("which best describes you?") routes the user into a tailored onboarding flow. Other vault types stay backgrounded and surface via earned discovery after the user blooms their first seed. Channel + intake + activation are tracked end-to-end so every wedge can be validated independently.

Why this card exists: Ashley locked this direction after pushing back on the "kill four vault types" recommendation from the 5/7 viability gut check. Her marketing instinct was right — multiple use cases ≠ multiple products when the engine is uniform. This card captures the full plan as a 7-phase prompted sequence so the work can happen across multiple sessions without re-deriving context.

Cross-references: HW#166 (Attribution & Referral Tracking — extends into Phase 5 here) · HW#040 (Concierge MVP — Phase 4 may run before code ships) · HW#049 (Wedding Vault Pilot — one of the lead personas) · HW#205 (SMS waitlist — the activation moment after Phase 7 launches) · HW#204 (biz-why-dandyline.html — the persona-routing decision belongs on the investor list once it's working).

Persona-routing project · Phase 1 · Persona Inventory & Ranking.

Read CLAUDE.md, HW#206 in biz-dev-homework.html, product-seeds.html, product-vaults.html, biz-mktg-ad-ideas.html. Then for each of the 6 vault types (Personal · Milestone · Legacy · Grove · Roots · Journey):

1. Translate the vault into outcome-language: not "Personal vault" but "I want to send my future self a message."
2. Sketch the real persona who'd want it — age, life stage, the moment they'd decide to use DandyLine.
3. Score each persona 1–10 on SIX axes:
   (a) market evidence — is anyone paying for this today?
   (b) emotional pull — will they cry / get goosebumps?
   (c) defensibility — how hard is this to copy?
   (d) ad-targeting feasibility — can I find them on Meta/TikTok cheaply?
   (e) retention likelihood — will they come back?
   (f) **willingness-to-pay precedent — does a comparable product actually monetize this audience?**

For axis (f), use this comp framework as scoring reference (pulled from the 5/7 monetization gut check):
   • Storyworth (legacy/family memoir) — $99/yr · ~$50–100M revenue · sold ~$100M to Hallmark 2023 → PROVES legacy monetizes
   • HereAfter AI (AI legacy interviews) — ~$99/yr · profitable niche → second-strongest legacy comp
   • Cameo (gift-occasion video) — $50–500/video · peaked ~$100M ARR → gift-occasion monetizes transactionally
   • Marco Polo (family async) — $0–10/mo · profitable mid-scale → family-async subscribes
   • Tribute (group video tributes) — $75–200/tribute · low-millions ARR → wedding/retirement transactional works
   • FutureMe (email-future-self) — mostly free · never crossed $1M → CAUTIONARY: pure personal time-capsule does NOT monetize
   • TimeHop (daily nostalgia) — free with ads · failed → CAUTIONARY: nostalgia without transaction moment dies

Score axis (f) by direct comp similarity. Legacy persona → likely 9–10. Wedding/Birth occasion → likely 7–8. Personal/Future-Self → likely 3–4 (FutureMe range).

Then rank all 6 by composite score (weight axis (f) heaviest — the market has already voted on which audiences pay). Recommend the 2–3 lead personas for v1 marketing. Explicitly say which 3–4 we are NOT leading with and why each one is being deferred (not killed — deferred until earned).

Output: a markdown table with all 6 axes I can paste into HW#206 + a 3-bullet recommendation + a one-line "comp-anchor" per persona (which existing app's economics they'd most resemble). Force the ranking. Don't argue for all 6.

Persona-routing project · Phase 2 · Intake Screen Copy.

Locked from Phase 1: lead personas are [PASTE FROM PHASE 1]. Now translate each into intake-screen language.

Rules:
- Outcome language. Never product language. Never "Personal vault" — always "I want to..."
- Each option = a moment in someone's life, not a feature.
- 5–10 words max per option.
- Emotionally specific: not "for my family" but "for my kid when she turns 18."

For each lead persona, draft 5 candidate phrasings. Show me all 5 (so I can sense what I'm rejecting), then your pick.

Also draft:
- The screen header (one line — what is this screen asking?)
- The screen sub-header (one line — why we're asking)
- The "I'm not sure / show me everything" fallback option language
- A "skip for now" option's exact copy

Reference brand vocabulary in CLAUDE.md — Gardener, Plant, Bloom, Vault — but only where it adds clarity, never where it adds friction for a first-time visitor who hasn't learned the language yet.

Persona-routing project · Phase 3 · Onboarding Flow Per Lead Persona.

For each lead persona [PASTE FROM PHASE 1], design the post-intake first-touch flow:

1. Welcome screen language — 1–2 sentences, persona-specific, in their emotional register.
2. Sample template — what does the first vault look like, pre-filled with what? Concrete.
3. The scripted first plant — 3–5 seed examples the user is guided to plant. Specific copy and prompts.
4. The "magic moment" definition — the single instant where the user feels DandyLine click. Name it precisely (it's not a vague feeling — it's a measurable moment in the flow).
5. The first-week experience — what does the user see in the app between first plant and first bloom? How does DandyLine stay alive without being noisy?

Cross-reference ux-planting-flow.html and ux-bloom-reveal.html for any locked UX patterns this needs to respect. Reference HW#107 (Grandparent Legacy seven-phase journey) for the depth of emotional flow expected.

Output: one section per persona, prototype-ready by end of phase.

Persona-routing project · Phase 4 · Channel & Ad Strategy.

For each lead persona [PASTE FROM PHASE 1], propose:

1. The single best channel to acquire that persona — Meta · TikTok · IG Reels · Pinterest · partnership · organic · referral. Justify the pick.
2. The ad creative concept — visual direction, headline, 1–2 second hook, CTA.
3. The UTM structure — utm_source / utm_medium / utm_campaign / utm_content. Standardize so funnel tracking is clean from day one.
4. CAC estimate based on similar consumer-app benchmarks.
5. Budget allocation: if I have $1000/month for v1 acquisition, how do I split it across the lead personas and why?

Cross-check biz-mktg-ad-ideas.html — flag any of the 6 flagship campaigns (Grandparent Legacy, etc.) that already map to a lead persona. Don't reinvent existing creative.

Also check HW#040 (Concierge MVP). Should we run pre-build manual outreach for any persona before paid ads start? Concierge wins are cheaper proof points than paid funnel tests.

Persona-routing project · Phase 5 · Analytics & Funnel Spec.

Spec the full attribution loop. Output a markdown doc Josh can implement directly.

1. Events to fire at each funnel step:
   - landed (capture all UTM params)
   - intake_completed (with persona selected)
   - first_seed_planted (with vault type used)
   - first_bloom_seen (with time-to-bloom, vault type)
   - day_7_return (yes/no)
   - day_30_return (yes/no)
   - earned_discovery_clicked (which secondary vault type)
2. Storage model: D1 table or Cloudflare Analytics? Pick one and justify.
3. Founder-side view: where does this live? Probably a new section in biz-dev-coaching-dashboard.html showing funnel by persona. Sketch the layout.
4. Privacy: opt-in language, what we DON'T track, alignment with ASHLEY_SAFETY_RULES.md Rule 4 (no storing personal data externally). Local-first wherever possible.
5. Extend HW#166 (Attribution & Referral Tracking) — this phase replaces parts of that scope. Note the supersede.
6. Loop Josh in: append to dandyline-app/QUESTIONS-FROM-ASHLEY.md so he can scope effort + cost.

Persona-routing project · Phase 6 · Earned Discovery Design.

The other 3–4 vault types exist in code but don't appear in v1 marketing or default onboarding. When + where do they surface?

1. Trigger conditions: when does the app first say "you can also..." — after first bloom? After day 7? After second plant? Specify the exact behavioral trigger.
2. Surface design: a card on the dashboard? A modal? An email? A subtle nav addition? Reference ux-inspiration-library.html for relevant entries (especially Push-Aside, Radial, anything around progressive disclosure).
3. Copy: how do we introduce a second vault type without making the user feel they were sold a smaller product than they thought? Tone matters here.
4. Cross-persona migration: if a Legacy user discovers Journey and switches their primary use, how do we capture that signal in analytics?

Constraint: never surface more than 1 new vault type per discovery moment. Layered, not menu-style. Earned, not advertised.

Output: a flow doc + 2–3 mockup sketches (text or simple HTML).

Persona-routing project · Phase 7 · Validation Plan + Kill Criteria.

For each lead persona, define what "this is working" looks like AND what "kill it" looks like. Specific numbers, not vibes.

1. Week 1 success: signups per ad spend, intake-completion rate, first-plant rate.
2. Month 1 success: day-7 retention, day-30 retention, multi-seed plants per user.
3. Month 3 success: bloom completion (did the user actually receive their first delivery?), referral signal, paid conversion if pricing is live.
4. Kill criteria: at what numbers do we stop spending on a persona? Be specific — "if CAC exceeds $X and day-30 retention is below Y%, deprioritize."
5. Iteration cadence: how often do we review per-persona? Weekly? Biweekly?

Output:
- A single dashboard mock-up (text or simple HTML) showing all metrics across all lead personas at a glance — the founder dashboard view.
- A ripple-check: list every existing homework card that becomes outdated by this plan. Update each with "see HW#206 for new approach" notes.
- A short "what's the next experiment" forward-look: once we have 4 weeks of data, what's the first iteration on the persona model?

Adam — this card is yours. Ashley wants you to bring your CPA + business-model lens to the monetization picture. The notes below are a starting framework Claude pulled together on 5/7 during a viability gut-check session. Treat them as a draft to validate, stress-test, and build into a real financial model — not as gospel. Your output lives in the shared GDrive WIP folder; Ashley moves it to Completed when it's ready.

Why this matters now: Ashley locked the persona-routing v1 marketing strategy on 5/7 (see HW#206 + biz-dev-decisions-log.md). That decision is load-bearing — but it only works if the personas we lead with actually monetize. Phase 1 of HW#206 ranks personas by 6 axes, and the 6th axis (willingness-to-pay precedent) is anchored to the comp set in your card here. Your work feeds directly into Phase 1 + Phase 4 + Phase 7.

Some users will want to turn a vault — especially a legacy jar or milestone collection — into something physical: a printed photo book, a bound archive, a keepsake. Competitors like Chatbooks and Artifact Uprising do this as a primary business model. For DandyLine this would be an add-on product: "Turn this vault into a photo book." Options are a direct partnership with a print vendor (they handle fulfillment, we handle the content handoff) or a native DandyLine export format optimized for print. Needs: partner research, export format design, revenue model (we take a cut? or flat fee?), and UX for triggering a print order from within a vault. Added 04.09.26.

Monetization isn't just storage upgrades. There's a whole category of things someone might want to purchase from DandyLine beyond "more GB": Buy-a-Jar (already defined), bulk export packages, physical photo books, digital estate / legacy planning, gifted vaults, and probably things we haven't thought of yet. The question is whether these live inside the main app experience, in a separate "Shop" or product hub, or as one-off purchase flows triggered by specific moments (e.g., a bloom prompts "Want to turn this vault into a photo book?"). Needs: full map of purchasable product categories, pricing model thinking, UX for how purchases are surfaced (contextual vs. shop model), and how this interacts with App Store billing rules (Apple/Google take 15–30% of in-app purchases). Added 04.09.26.

✅ Direction locked April 27, 2026. Yes — vaults keep living after the planter is gone. The vault does NOT auto-lock when DandyLine learns the planter has died; that would create a weird emotional moment ("you don't want DandyLine to know they died because then it'd lock").

The principle: A Hatch family Legacy vault that Grandma built shouldn't shut down because Grandpa is gone. If anyone in the vault wants to keep adding to it, they should be able to.

Locked decisions:
1. Vault keeps living after planter death. No auto-close, no auto-lock. Family/recipients/Guardians can continue interacting with the vault.
2. Default Guardian inheritance pattern still applies. If a Guardian is named, the Guardian receives oversight when the planter is gone (already locked in Section C of QUESTIONS-FROM-ASHLEY.md). If no Guardian is set, the question of "who steps in" needs design — see open question below.
3. Everyone with vault access retains the right to preserve / seal. Including pressing the entire jar, not just individual seeds. This is a meaningful right, not a paid-only feature gate.
4. Mixed-author content is fine — it's a feature, not a bug. Layered, multi-generational memory objects are exactly the differentiator. No competitor offers this.

Open questions spawned (need their own design pass):
• Co-admin / co-owner model — when you invite someone into a vault, are they a contributor (can plant seeds) or a co-owner (can add other admins, take on responsibility/weight)? Like the Google Drive distinction. This is foundational and ties directly to HW#53 (Vault Settings Editability). Without it, "what happens when the planter dies" is underspecified.
• "Request to claim" flow — when DandyLine notifies that a planter is gone (or their account expires), should there be an explicit handoff/claim prompt for the remaining vault members? Or does the vault just keep functioning under whoever has access?
• Pricing model implication — preserving the entire jar. Pressing one seed is one thing; pressing the whole jar (or "buying" the jar with a max storage cap that members can extend) is a real product question. Tie into HW#80 (Revenue Model) and HW#051 (Pricing Model Spec) — flag "jar preservation" as a paid feature candidate. If anyone is willing to pay for it storage-wise, the system should let them.

Where this goes next: The co-admin / co-owner question (and its connection to HW#53) is the actual design blocker. Once that's locked, the rest of "vault keeps living" falls out naturally. Not MVP-blocking — Personal Vault MVP doesn't have multi-author at all — but needs to be locked before Grove + Legacy build.

Original card added 04.12.26. Direction locked 2026-04-27 with Claude.

✅ Pursue · April 27, 2026. Add this to the building plan as its own separate endeavor — same shape as the Printed Books / Physical Seed Key Cards stream. These are all parallel product streams alongside the core DandyLine app, not features inside it.

Decision framing: Don't try to launch all of these at once. Once core DandyLine is stable, prioritize which separate streams to pursue first — pick one, work out the details, then move to the next. This card is a placeholder commitment that the stream is real, not a "build now."

Original concept: Organizations that deal in time + memory embed DandyLine vaults into their services. Hospitals giving new parents a Seed Key at birth. Retirement communities offering Legacy Vault setup as end-of-life planning. Schools giving graduating seniors a Grove Vault their classmates plant into. Each partnership = distribution channel + emotional proof point for investors.

Will need (when prioritized): Partnership pitch deck · institutional pricing tier · API for bulk vault creation · partnership-specific onboarding flow.

Added 04.12.26. Direction locked 2026-04-27.

✅ Pursue · April 27, 2026. There's definitely a place for actual physical products. The gift-card use case in particular is real — physical Seed Keys would help with gifts.

Format flexibility: Could ship as email format (digital gift card, instant) OR physical card format (printed, beautiful, holdable). Both have a place — different occasions, different price points, different shopper psychologies.

Strategic frame: Same shape as HW#58 (Institutional Partnerships) and the printed-books stream — these are parallel product streams alongside the core DandyLine app, not features inside it. Each is its own separate endeavor with its own business development plan. Prioritize among them later once core DandyLine is stable.

Why this matters: Solves the "how do I explain this app to my mom" problem. Physical = real = trustworthy. Could be a revenue stream AND a marketing channel simultaneously.

Will need (when prioritized): Business development plan · card design + packaging · retail/e-commerce strategy · QR code generation flow · email gift card flow · pricing tiers.

Added 04.12.26. Direction locked 2026-04-27.

The Seed Key system isn't just a feature — it's DandyLine's core growth engine. Every vault for someone not on the platform = organic invitation. Every Open Claim Key at a wedding = 150 potential signups. Every 'Held in Trust' vault for an unborn child = a user who joins years later and arrives to something already waiting. That's not onboarding — that's an emotional moment. 'Sign up and immediately receive a message from someone who loved you before you existed.' No other app can offer this. Needs: growth model documentation, viral coefficient estimates, investor slide narrative, security/legal brief updates to cover growth mechanics. Added 04.12.26.

The competitive landscape document (biz-competitive-landscape.html) has grown to v3 with 45+ products, but the "Honest Assessment" and "Blind Spots" tabs haven't been fully updated to reflect new features, new competitors, or recent product decisions. Both sections likely contain outdated risk assessments, missing competitive angles, and opportunities that weren't visible when they were first written. This is a scheduled refresh task — ideally done in 1–2 weeks once the brain has some distance from today's session. What to re-run: (1) Tab 5 "Honest Assessment" — re-read every risk card and opportunity card; update any that are now better or worse given new product decisions (pricing, vault types, Guardian model, Journey Vault, Artwork Seeds, etc.); add new risks and opportunities surfaced by the Keepsake category research. (2) Tab 6 "Blind Spots" — re-read every blind spot; assess which have been partially resolved by product decisions; add any new blind spots surfaced by Artkive, HappyMe, Little Life Stories analysis. (3) Full scorecard audit — re-run weighted scores for existing competitors where market position may have shifted; check if any tier 3 items should be moved up. (4) Feature matrix — confirm the matrix still reflects DandyLine's current planned feature set (Journey Vault, Artwork Seeds, Gift Vault should now appear as DandyLine plans). Goal: biz-competitive-landscape.html goes from a historical document to a living document reviewed quarterly. Set a reminder: re-run this session in the week of May 5, 2026. Added 04.22.26.

A defense of DandyLine's competitive position through six structural layers: emotional brand ownership, time-based data gravity, family memory networks, ritual habit formation, trust infrastructure, and cultural narrative ownership. Summary: "The longer users stay, the stronger the product becomes."

Strategic guide to leveraging the dandelion symbol as the landing page hook — not explaining mechanics, but making visitors *feel* what the dandelion means before they understand the product. Includes three hero headline options, messaging concepts, visual direction, and waitlist conversion psychology.

Round 2 of the May 1 site-landing tightening pass. Round 1 (4 quick mechanical fixes) shipped May 1 — see "Already Locked" below. Round 2 is the deeper creative + UX work that needs proper time. Re-entry: open site-landing.html in MASTER folder, work through ①–⑥ in order. Pre-edit backup at ARCHIVE - no longer using_store for historical reference/BACKUP-pre-tweaks-2026-05-01-site-landing.html.

Two presentation issues on TEMP-dandelion-globe-V4.html surfaced May 1 when Ashley opened it as the "Experience the UX" target from site-landing. Site-landing now links to this file, so its presentation matters.

Foundational strategy positioning time itself as DandyLine's primary product primitive — not a constraint, an emotional experience layer. Covers use cases, category creation ("Future Memory Platforms"), market timing, emotional network effects, retention philosophy, and defensibility rooted in time-based accumulation.

Two related ideas born from the Apr 23 competitive re-audit. (1) An "On This Day" passive surface that re-surfaces previously-bloomed seeds on their anniversary date so Gardeners get the dopamine hit of rediscovery without planning it. (2) Ambient weather capture at plant-time and bloom-time — "it was raining the day your dad wrote this" — as emotional texture. Both address a specific competitive gap (see Highlights) without compromising DandyLine's intentional-bloom identity.

Recipients rename gardeners in their own settings — "Judy Blue" becomes "Grandma" everywhere (seeds, filters, notifications, popup cards). Like renaming a phone contact. Gardeners can't see the nickname. Needs: settings UX, where the name appears, privacy rules, personal avatars.

Design a beautiful, branded storage bar (like iPhone storage) that shows users their full memory health at a glance. Three preservation states: Purple (pressed/hard storage — permanent, protected), Brown/Amber (composting tier — compressed, accessible but degrading), and a third color for shared vault content someone else is paying to preserve. Should also break down by content type (photo, video, voice, text) within each state. Needs: color system decision, layout, entry point in the app, emotional tone (feels like care, not a dashboard).

DandyLine has its own vocabulary (Sprouted Here, Rooted Here, Pressed, Compost, Bloom, Gardener, etc.) that users need to learn without feeling overwhelmed. The design principle: teach vocabulary through light, optional discovery — never through mandatory tutorials. Key pattern: a small info icon (ⓘ or a more DandyLine-fitting symbol — not the eye/visibility icon, which means something else) appears next to any term that needs explanation. Tap it for a one-sentence definition that appears inline and disappears. Used sparingly — only on terms that are genuinely unique to DandyLine, not obvious UI labels. Broader question to resolve during UX build: what is the right icon? And how do we balance this across the whole app so it never feels like there are "little eyes everywhere"? Consider: icons only appear on first encounter with a term, then fade out once the user has seen the definition. Needs: icon decision, list of all DandyLine-specific terms that need a tooltip, and a rule for when to show vs. hide the icon. Added 04.09.26.

New user auto-joins an instructional vault with temporary "tutorial seeds" that coach them through how DandyLine works. Seeds auto-compost after reading, teaching composting/pressing organically. Different vault types get different instruction sets. Could also serve as the app's update/announcement channel (new features bloom as scheduled seeds). Ties to D1 empty-state concept. May also prompt for notification permissions during flow. Consider: can instruction seeds be "preserved but not counted against storage" to teach pressing? Ashley's detailed notes: see Plane Workbook section D1. PRIORITY: HIGH — determines build/flow for onboarding.

Surfaced 2026-04-28 EOD after Q2 reversal. The morning's Q2 lock attempted to supersede TAB2 with Entry 034 (Melting Ball Tabbar). After viewing the SVG goo-filter prototype with the actual viscous morph in motion, Ashley felt it was "offputting" and "too far off" for DandyLine's nav. Reverted to canonical TAB1-family direction (Field · Pressed · + Plant raised gold · Gardener) per ux-field-homepage-v3-motionmark-depth.html. Ashley's note: "anything you want to creatively come up with to make it feel like it has a little more swipe interaction would feel valuable... I just feel like it needs to be a little better than a boring menu." The challenge: add restrained micro-interactions that feel native to DandyLine WITHOUT another big-mechanic experiment.

Consolidated 2026-04-27 from HW#178/179/180/181 (formerly 4 separate cards · all surfaced 2026-04-28 during POPUP-SPEC-V1 future-state inventory). Per app-design-system.html Section 7, these 4 popup states are already grouped as one inventory — they need to be designed in the same pass for visual coherence. Each state needs an orb-level treatment AND a popup treatment (Tier 1 + Tier 2). Master spec ships INCOMPLETE without these designed.

Why one card, not four: these 4 states are explicitly grouped in app-design-system Section 7 as one "Future popup states inventory" — they need to be designed together for visual coherence (each is a sibling lifecycle-state visualization). Consolidated 2026-04-27 per the new homework consolidation rule (one card per coherent pass, not one per sub-step).

Surfaced 2026-04-28 during POPUP-SPEC-V1 lockdown. Journey Vaults work via prompt-sequenced contributions: multiple gardeners contribute to the same prompt-set over time, and contributing can unlock or auto-bloom others' contributions at the same point in the journey. The cold-start risk: if no one else has contributed yet (early days · low user base · niche prompt-set), a gardener contributes and gets NOTHING back → emotional flatline → user concludes the product is broken or empty. The product math (random unlock timing to drive return engagement) makes this MORE likely to happen at scale, not less.

What needs to be designed:

Surfaced 2026-04-28 during POPUP-SPEC-V1 lockdown. When a recipient taps a Bloom Now Tier 2 popup, the transition into the bloom view (Tier 3) is the emotional centerpiece of the entire DandyLine experience — the moment the wish unfolds, the seed reveals what's been held for them. Right now this is partially specified: POPUP-SPEC-V1.html B2=C locks the transition motion (Tier 2 docks as a thumbnail in the corner as Tier 3 takes over) and the A4 routing matrix names the Tier 3 destination (Bloom view per Entry 014). But the actual blooming animation itself — what the user SEES + FEELS in those 2–4 seconds of opening — has never had a dedicated design pass. ux-bloom-reveal.html exists as an early prototype but predates the V2 motion system, B1=D anchored depth, and A13 ambient pulse. Needs: a fresh design pass that treats the bloom as the FLAGSHIP motion moment of the app, mining the strongest bloom-related inspiration entries and synthesizing them into a buildable spec for Josh.