# DandyLine — Decisions Log

A running record of decisions that have been locked — what was decided, why, what was rejected, and which files it touches. Ashley's anti-amnesia system: when a decision is logged here, we don't re-argue it.

Newest entries on top. Never delete — if a decision is superseded, add a new entry that references and overrides the old one.

---

## 2026-05-02 (eve) — Q2/Q3/Q4 IMPLEMENTATIONS landed · scratch pad archived

**Decision:** Three of the Restyle Q-locks (Q2 taglines, Q3 status badges, Q4 Field icon) moved from "decided" to "implemented in canonical files." The scratch preview file that surfaced these decisions has been archived (a copy lives in `ARCHIVE - no longer using_store for historical reference/RESOLVED-SCRATCH-restyle-preview-2026-05-02-Q2Q3Q4-locked-and-implemented.html`).

**What landed (canonical homes):**

| Lock | File | What was added |
|---|---|---|
| Q4 Field icon (Option A loose dot cluster) | `brand-icon.js` | New `FIELD_ICON_SVG` constant + `renderFieldIcon(targetId, size)` helper. Reusable across any page that needs the Field tab icon. |
| Q3 Status badges (4-state · Live/Growing/Wishing/Ripening) | `brand-shared.css` | Full `.status-badge` class family with `[data-status="..."]` selectors, all 4 color states, optional motion (cards only, never nav), plus `.page-status-banner` variant for rough pages. |
| Q2 Three taglines (universal/CTA/poetic registers) | `biz-mktg-copy-vault.html` | Updated three line-cards under Taglines & Brand-Level: "Time isn't a feature" promoted to Universal Footer slot, "Plant a moment. Watch it bloom." re-scoped to Hero/CTA register, "Find it. Wish it forward..." added as the Brand-Ethos poetic register card. |
| Q2 Footer brand-violation guardrails | `brand-guide.html` Section 08 (Don'ts) | Three new prohibitions added: No fake-rendered brand marks · No solid-weight wordmarks · No italic taglines. Each cites the SCRATCH violation that prompted the rule. |

**What's still PENDING (not blocked, just not built yet):**
- `brand-footer.js` shared component (Q2 build) — uses the canonical patterns now codified in the prohibitions
- `brand-status-system.html` visual gallery (Q3 build) — peer of color-system / typography / logo-marks
- `biz-dev-command-center.html` migration from 2-state to 4-state badges (Q3 ripple)
- `lab.html` data-status sweep (Q3 ripple)
- `CLAUDE.md` rule update: "Every new HTML page declares data-status on its primary entry point" (Q3 ripple)

**Considered and rejected:**
- **Migrating ALL pages to 4-state badges in one pass** — too much surface area for one EOD; CSS landing now means new pages can adopt immediately; existing pages migrate when next touched.
- **Building `brand-footer.js` tonight** — bigger lift than fits the pause; the prohibitions in `brand-guide.html` already prevent re-violation in the meantime; canonical examples live in `site-landing.html`.
- **Deleting the scratch file** — copied to archive instead per CLAUDE.md "never delete outright" rule. Original still in MASTER until Ashley confirms deletion.

**Files affected / ripple checks:**
- `brand-icon.js` — new export `FIELD_ICON_SVG` + `renderFieldIcon()`. Pages that need the Field icon can import via existing `<script src="brand-icon.js"></script>`.
- `brand-shared.css` — new section "STATUS BADGE SYSTEM (4-state)" appended before responsive block. Backwards compatible — uses both `.live` / `.growing` etc. AND `[data-status="..."]` selectors.
- `biz-mktg-copy-vault.html` — Taglines & Brand-Level category reorganized to put Universal Footer first.
- `brand-guide.html` — Section 08 Don'ts now has 11 items (was 8).
- ARCHIVE folder — new file `RESOLVED-SCRATCH-restyle-preview-2026-05-02-Q2Q3Q4-locked-and-implemented.html`.

**Locked by:** Ashley · May 2, 2026 (eve)

---

> 🎯 **Lock Tier reference (adopted 2026-05-02):** All entries below dated 2026-04-27 onward are at **🎯 Spec tier** (locked specifications, source of truth, not yet built/live) unless explicitly noted otherwise. See `CLAUDE.md` "Lock Tier System" section for the 4-tier definitions and how to advance items toward 🔨 Component → ✅ Live.

---

## 2026-05-02 — Restyle Q10 locked · "Feels-like-dandelion Done" = 10-criterion port checklist

**Decision:** A live page is officially **"feels-like-dandelion done"** (status: `live`) when it passes all 6 universal criteria + any applicable conditional criteria. This becomes the canonical Definition-of-Done for the live-pages restyle port and the audit instrument for any future re-audit (e.g., when new locks land).

**Universal — every live page must pass:**
1. Uses shared `brand-nav.js` (PUBLIC variant; site-landing uses minimal variant per Q1)
2. Uses shared `brand-footer.js` with universal tagline "Time isn't a feature. It's the medium." per Q2
3. Page root has `data-status="live|in-progress|vision-board|coming-soon"` attribute per Q3
4. Passes brand-vocab sweep (no upload/post/folder/album/user/sender/open/unlock/save/delete/register/activate/admin in copy)
5. Uses CSS vars from `brand-shared.css` — no hex drift, no off-scale font sizes
6. Readable at ≤420px viewport; adopts mobile collapse pattern from `ux-field-homepage-v3-motionmark-depth.html`

**Conditional — applies if the page uses these surfaces:**
7. **Filters present** → use F08 Routing (Push-Aside for spatial, F05=B for lists, Pull-down chips for Pressed Shelf)
8. **Animation/transitions present** → use MOTION-SPEC-V1 picks (B1 filter expand · B2 popup tier · B3 height collapse · B4 type-in)
9. **Pop-up / disclosure cards present** → use POPUP-SPEC-V1 picks (B1 Stacked-with-offset · B2 A+C combo · always-gold Tier 3)
10. **Renders seeds/orbs** → use Tone-Driven Color System (5 families, motion-only lifecycle)

**Why:**
- Concrete completion signal — "feels like dandelion" stops being subjective when it's 10 checkable criteria.
- Parallelizable — Adam, Josh, or future-Claude can audit pages without re-explaining the brand.
- Auto-updates as new locks land — each future decision becomes a new line (universal) or row (conditional).

**Considered and rejected:**
- **Per-page handwritten "vibe check"** — subjective, doesn't scale across 30+ pages, doesn't survive a re-audit.
- **Tooling-based linter only** — would catch tokens/vocab but miss intentional design fit. Human check + checklist is the right balance.
- **Fewer criteria (5 universal)** — too lossy; mobile and status-declaration are non-negotiable in DandyLine context.

**Files affected / ripple checks:**
- This DoD becomes the spec the eventual `app-design-system.html` master spec consolidates.
- `biz-dev-homework.html` — port-DoD card to be added in Phase 3 wrap (today).
- `CLAUDE.md` — should be referenced from "When creating a new file" rules section so new pages are born meeting the DoD.

**Locked by:** Ashley · May 2, 2026

---

## 2026-05-02 — Restyle Q4 locked · Field tab icon = loose dot cluster (Option A)

**Decision:** The Field tab icon in the in-app bottom nav (TAB1-family) is **Option A — Loose Dot Cluster** (7 small filled circles in organic spread, no stem, no bracts, no outer ring). Solves both the "tab icon at small scale needs to be legible" problem AND the "Field master view vs individual vault view look identical" problem at the icon layer.

**The SVG (24px viewBox):**
```svg
<svg viewBox="0 0 24 24" fill="none">
  <circle cx="12" cy="6"  r="1.6" fill="currentColor"/>
  <circle cx="7"  cy="9"  r="1.4" fill="currentColor"/>
  <circle cx="17" cy="9"  r="1.4" fill="currentColor"/>
  <circle cx="12" cy="12" r="1.8" fill="currentColor"/>
  <circle cx="6"  cy="14" r="1.4" fill="currentColor"/>
  <circle cx="18" cy="14" r="1.4" fill="currentColor"/>
  <circle cx="12" cy="17" r="1.6" fill="currentColor"/>
</svg>
```

**Why:**
- Visually distinct from the brand mark (no stem/leaves) — prevents nav-icon-mirrors-brand-logo redundancy.
- Visually distinct from individual vault views (which render as a dandelion-globe) — helps disambiguate the Field master view at the icon layer.
- Says "field of many seeds" cleanly at tab scale; legible down to 16px.
- Static (no motion) — Field is "you are here home," should feel anchored.

**Considered and rejected:** Option X (mini master-dandelion w/ stem) — perpetuated the Field-vs-vault-view visual confusion. Option C (sprout/seedling, current placeholder) — single-seed metaphor for a multi-seed view. Option D (horizon line + dots) — doesn't fit a square tab icon naturally.

**Files affected / ripple checks:**
- `ux-field-homepage-v3-motionmark-depth.html` — replace current sprout SVG with the dot cluster.
- `ux-button-system.html` lines 2885–2913 — TAB1-family tab nav reference: update Field tab icon spec.
- `brand-shared.css` (when built per Q3 plan) — add `.icon-field` class as canonical SVG include.
- Future `brand-nav.js` build — include the Field icon in the in-app tab nav component.
- **NEW homework card needed:** "Master Field view vs single-vault view — visual differentiation" (the deeper UX question Ashley raised — separate from icon, deserves its own card). Add to App Design System Quest in Phase 3 wrap.

**Locked by:** Ashley · May 2, 2026 (after viewing visual preview at `SCRATCH-restyle-preview-2026-05-02.html`)

---

## 2026-05-02 — Restyle Q3 locked · Status Badge System (Live · Growing · Wishing · Ripening)

**Decision:** Four-status badge system locked for use across nav dropdowns, lab.html cards, page banners, and any link-with-state context. Each status has: a `data-status` attribute, a brand-vocabulary label, a color from the locked Tone-Driven Color System, a single-character glyph, and optional motion (cards only). Replaces ad-hoc "(Reference only — see Homework #X)" / "in progress" / "Coming Soon" notes scattered across pages with one canonical system.

**The 4-status spec:**

| `data-status` | Label | Color (Tone family) | Glyph | What it means |
|---|---|---|---|---|
| `live` | **Live** | Gold `#D4A853` (Warmth · Celebration · Pride) | • (solid dot) | Approved · deployed · linked · public on dandyline.app |
| `in-progress` | **Growing** | Sage `#7A9E7E` (Wisdom · Heritage · Awe) | ◐ (half-dot) | Active build · visible if you know where to look · not green-lit |
| `vision-board` | **Wishing** | Purple `#6B5B8A` (Adventure · Bravery · Far Horizon) | ✦ (sparkle) | An idea on the wall · may or may not become real |
| `coming-soon` | **Ripening** | Sky `#8BAEC8` (Memory · Stillness · Reflection) | ◌ (hollow ring) | Build complete · awaiting Ashley's green-light to ship |

**Why these labels (brand-vocabulary integration):**
- **"Live"** kept universal — using "Blooming" would conflate with the seed-blooms-product mechanic (a Bloom is an unsealing event in the product, not a page-shipped state).
- **"Growing"** follows the seed-lifecycle metaphor. Pages grow before they bloom.
- **"Wishing"** ⭐ — directly invokes the dandelion-wish brand metaphor. A vision-board page is a wish on the wall. Perfect DandyLine register.
- **"Ripening"** tracks the seed-lifecycle vocabulary already locked Apr 27 (Distant → Patient → Approaching → Blooming Soon → Bloom Now). Ripening = approaching bloom.

**Render variants by context:**

1. **Nav dropdown (small pill, static):**
   ```
   Brand Guide                    • Live
   Motion Spec V1                ◐ Growing
   Photography Style              ✦ Wishing
   Greenhouse                     ◌ Ripening
   ```
   ~9px text · 6px padding · pill rounded · matches color · static (animation in nav = clutter).

2. **Lab.html card (medium, with optional descriptor):**
   ```
   [card content]                ◐ Growing · since Apr 25
   ```
   Descriptor adds context ("since Apr 25" / "wishes from Apr 12" / etc.) — optional per surface.

3. **Inline page banner (rare — for pages shipped rough):**
   ```
   ┌──────────────────────────────────────────────┐
   │  ◐ This page is GROWING                      │
   │  Interactive prototype · not final design    │
   └──────────────────────────────────────────────┘
   ```
   Used only when a page is genuinely rough and warrants setting expectations on entry. Border-left color matches status.

**Optional motion (cards only — NOT nav):**
- **Live:** static
- **Growing:** gentle slow pulse (90→100% opacity, 4s loop)
- **Wishing:** sparkle rotates 0→15° and back (4s loop) — "wish in motion"
- **Ripening:** ring expands subtly (80% baseline → 100%, 5s loop) — "approaching bloom"

**Why:**
- Replaces ~8 ad-hoc inconsistent patterns ("Reference only", "in progress", "Coming Soon", "(NEW)", "(needs feedback)") with one canonical system.
- Tone-Driven Color System integration means status badges share the same visual language as seed orbs — internally consistent design system.
- "DandyLine-branded badges" requirement from HW#112 is fulfilled with category-defining labels (Wishing, Ripening) instead of generic ones (Vision Board, Coming Soon).
- Each new page declares `data-status` at creation — no more "is this still active?" anxiety; future-Ashley scanning lab.html or any nav sees the truth at a glance.

**Considered and rejected:**
- **"Vision Board" as label** (HW#112's draft phrasing) — generic; "Wishing" is stronger DandyLine vocab.
- **"Coming Soon" as label** — generic startup language; "Ripening" stays inside the seed-lifecycle vocabulary.
- **"Blooming" for live** — conflates with the seed-product mechanic where Bloom is a specific unsealing event.
- **Animations on nav badges** — clutter; nav stays static, motion only on cards/banners where it has space.
- **5+ statuses** — kept to 4 to match HW#112 spec; if a future state emerges (e.g. "Composting" for retired-but-linked-to), add then.

**Files affected / ripple checks (the "intelligent spot" plan):**
- **NEW build needed:** `brand-shared.css` — add `.status-badge` class family with `[data-status="live"|"in-progress"|"vision-board"|"coming-soon"]` selector pattern. Single source of CSS truth.
- **NEW canonical reference page:** `brand-status-system.html` (or section added to `brand-system.html`). Mirror the pattern of `brand-color-system.html` / `brand-typography.html` — visual gallery showing each status badge in all 3 render variants (nav pill / card / page banner) plus motion previews. **PENDING BUILD — homework card to be added in Phase 3 wrap.**
- `brand-system.html` — at minimum, add a top-level link/anchor to `brand-status-system.html` once built so the brand system index includes status badges as a peer of color-system / typography / logo-marks.
- `lab.html` — currently lists working files in cards; sweep to add `data-status` on each card so badges render automatically once the CSS lands. **PENDING SWEEP.**
- `biz-dev-command-center.html` TOC — uses status badges already in some form (live / in-progress / on-hold / queued per CLAUDE.md). Reconcile to the canonical 4-status system: "on-hold" maps to "Growing" (active but not green-lit), "queued" maps to "Wishing" (idea, not yet building).
- All HTML pages that ship rough — add the `<page-status-banner data-status="...">` pattern at the top once the component exists.
- `CLAUDE.md` — **add a new session-start protocol rule: "Every new HTML page declares `data-status` on its primary entry point."** Add to "When creating a new file" rules section. **PENDING UPDATE in Phase 3 wrap.**
- `biz-dev-homework.html` — HW#112 (Main Nav Consistency Sweep) and the bigger Nav/Menu System card both reference status badges as part of their spec; both should reference `biz-dev-decisions-log.md` 2026-05-02 entry as the canonical source.

**The "intelligent spot" structure (4 places this lives, by design):**
1. **`biz-dev-decisions-log.md` 2026-05-02 entry** ← THIS ENTRY · the WHY and full spec (canonical source of truth for design rationale)
2. **`brand-shared.css`** (build pending) ← CSS implementation (canonical source of truth for visual rendering)
3. **`brand-status-system.html`** (build pending) ← visual gallery + usage guide (canonical source of truth for visual reference)
4. **`CLAUDE.md` session rules** (update pending) ← the maintenance rule that keeps every new page in compliance going forward

The structure is intentional — decisions log captures the WHY (deep), CSS captures the HOW (technical), brand-status-system page is the WHAT-IT-LOOKS-LIKE (visual), CLAUDE.md is the OPERATIONAL rule that prevents drift. If any of the four go stale, the others surface the truth.

**Locked by:** Ashley · May 2, 2026

---

## 2026-05-02 — Restyle Q2 locked · Footer pattern (B-Light) + universal tagline elevated to "Time isn't a feature. It's the medium."

**Decision:** Footer is locked as **Path B-Light** — a calm, brand-led closing moment (logo + universal tagline + 5 quick links + copyright). NOT a 3-column sitemap. The universal footer tagline across every page is **"Time isn't a feature. It's the medium."** — promoted from copy-vault's "consider elevating" note. The previous footer designations "Plant a moment. Watch it bloom." and the brand-ethos sweep tagline "Find it. Wish it forward. Let it bloom when it's ready." are retained but now serve different registers (see below).

**The locked footer spec (Path B-Light):**

```
─────────────────────────────────────────
       [🌼 dandelion canvas]
            DandyLine

      Time isn't a feature.
        It's the medium.

  Home · Brand · Product · Investors · Founder Story

       © 2026 DandyLine · v1.0
       Privacy-first memory preservation
─────────────────────────────────────────
```

**Tagline register split (all three taglines remain LIVE — different jobs):**

| Tagline | Register / job | Where it lives |
|---|---|---|
| **"Time isn't a feature. It's the medium."** | **Universal footer · brand-philosophy register** | Footer on every page (NEW — locked today) |
| "Plant a moment. Watch it bloom." | Hero / CTA · action register | Hero copy, marketing CTAs, ad headlines (the "do this thing" voice) |
| "Find it. Wish it forward. Let it bloom when it's ready." | Brand-ethos · poetic register | brand-ethos.html (the deeper why-the-name story); the Find/Wish/Seed three-part framing |

**Footer spec details:**
- Single shared `brand-footer.js` component (no PUBLIC/FOUNDER split — footer is utility, doesn't need privacy variants)
- Logo: dandelion canvas + DandyLine wordmark, centered
- Universal tagline (Syne, gold-tinted, ~14px)
- 5 quick links in horizontal middle-dot row (Home · Brand · Product · Investors · Founder Story) — Outfit uppercase tracking, dim ink
- Copyright with auto-year: `© ${new Date().getFullYear()} DandyLine · v1.0` (fixes the stale "2025" on brand-guide footer)
- Subtitle: "Privacy-first memory preservation" (kept from site-landing's footer)
- Mobile: links wrap multi-line, everything centered, generous spacing

**Why:**
- DandyLine's brand vocabulary explicitly calls for *"calm design, no feeds/likes/metrics, reflection over performance."* A 3-column 12-link sitemap footer fights that principle — the heavy footer is a tech-startup convention, not a DandyLine one.
- The nav (Restyle Q1) handles full navigation comprehensively, so the footer is freed to be a brand moment — the exit equivalent of a sigh, not a sitemap.
- Promoting "Time isn't a feature. It's the medium." gives the footer category-defining philosophical weight in 6 words. The note in copy-vault literally flagged this line for elevation.
- Three distinct tagline registers (philosophy/action/poetry) means each can do its job without competing — vs. forcing one tagline to be everything everywhere.

**Considered and rejected:**
- **Path B-Heavy (3-column 12-link grid)** — too dense for the brand. Rejected for being a tech-convention pattern that fights DandyLine's calm-design principle.
- **"Plant a moment. Watch it bloom." as universal footer** — Ashley flagged this; the action voice doesn't suit a closing moment, and using it everywhere dilutes its power in CTAs. Now scoped to hero/CTA register only.
- **"Find it. Wish it forward. Let it bloom when it's ready." as universal footer** — too long for the footer rhythm; better suited to the brand-ethos page where its poetic three-part rhythm gets room to breathe.
- **PUBLIC/FOUNDER footer split** — unnecessary; visitors who land on Greenhouse pages directly (unlikely) get clean exit links either way.
- **Newsletter signup in footer** — site-landing's waitlist IS the signup; don't compete with the primary CTA.

**Files affected / ripple checks:**
- **NEW build needed:** `brand-footer.js` shared component (paired with the `brand-nav.js` from Q1).
- All brand-/product-/biz-/site- pages (~25 files) — sweep to use `brand-footer` once component is built. Replace per-page footer markup.
- `site-landing.html` — current footer has stale tagline "Plant a moment. Watch it bloom." in footer position; will be replaced by `brand-footer` (universal tagline) on sweep. The site-landing HERO can still use "Plant a moment. Watch it bloom." since that's the hero/CTA register.
- `brand-guide.html` — current footer has "v1.0 · 2025" — fixed by auto-year + the `brand-footer` component sweep.
- `biz-mktg-copy-vault.html` — needs update to reflect three-register split:
  - "Plant a moment. Watch it bloom." note: from *"Primary · footer/nav/hero"* → *"Hero/CTA register — action voice"*
  - "Time isn't a feature. It's the medium." status: from "consider elevating" note → *"Primary universal tagline (footer everywhere)"*
  - "Find it. Wish it forward. Let it bloom when it's ready." should be added if not already present, marked *"Brand-ethos register — poetic Find/Wish/Seed framing"*
  - **PENDING UPDATE in this session or next.**
- `brand-ethos.html` — no change needed; "Find it. Wish it forward..." stays as the hero/section tagline there.
- `CLAUDE.md` Brand Vocabulary section — no change needed; vocab table doesn't include taglines.

**Locked by:** Ashley · May 2, 2026

---

## 2026-05-02 — Restyle Q1 locked · Final marketing nav spec (split chassis · PUBLIC + FOUNDER · sticky/hamburger)

**Decision:** The marketing-site nav is finalized as a split chassis with two variants from one shared `brand-nav.js` component. PUBLIC variant for visitors; FOUNDER variant for Ashley/Josh/Adam at `/greenhouse`. Site-landing keeps a minimal anchor-link nav (intentionally separate from the comprehensive variants) to preserve conversion focus.

**The four sub-decisions:**

**A · Two public-nav variants (minimal + full):**
- `brand-nav minimal` — for `site-landing.html` only. Keeps current 4-anchor layout (How · Stories · Vaults · Request Access).
- `brand-nav full` — for all brand-/product-/biz- pages (visitor exploration mode).

**B · PUBLIC nav (`brand-nav full`) menu structure:**
```
[DandyLine logo]                                  [Request Access — gold pill]
├─ Home → site-landing
├─ Brand ›
│   FOUNDATION   ▸ Brand Ethos · Founder Story
│   IDENTITY     ▸ Brand Guide · Brand System · Color System · Typography · Logo & Marks (incl. App Icons)
│   COMING UP    ▸ Motion Guide · Photography Style · Social Templates  (greyed, no link)
├─ Product ›    ▸ The Dandelion · Seeds · Vaults · Roots · Seed Keys & Guardians
└─ Investors
```
Notable: Logo & Marks is the canonical home for app icons (per today's brand-app-icons retire). Founder Story under FOUNDATION (it's brand narrative, not product). No Founder Tools dropdown publicly (per 2026-04-22 "keep public landing clean" decision).

**C · FOUNDER nav (`brand-nav founder`) at `dandyline.app/greenhouse`:**
```
[DandyLine · Greenhouse logo+badge]               [Push to Cloudflare CTA]
├─ Brand ›        (same as PUBLIC)
├─ Product ›      (same as PUBLIC)
├─ Investors      (same)
└─ Founder Tools ›
    SESSION & TRACKING ▸ Coaching Dashboard · Command Center · Homework · Prompt Playbook · Decisions Log · Session Log
    SPECS & DESIGN SYSTEM ▸ Lab · App Design System (when built) · Motion Spec V1 · Pop-up Spec V1 · UX Inspiration Library · UX Component/Filter/Button Decisions · Style Guide Draft
    WORKING FILES ▸ Field Homepage prototype · Globe V4 (current) · Vault Renditions
    OPS ▸ Financials · Legal Counsel · Why DandyLine (investor list)
```
Greenhouse is unlinked, `noindex`, bookmark-only.

**D · Mobile + sticky behavior:**
- Desktop: sticky on scroll with backdrop-blur + subtle shadow when scrolled past hero
- Mobile (≤768px): hamburger right; full-height drawer; dropdowns become accordions
- Logo always-left at every viewport
- Right-side CTA always visible (Request Access for PUBLIC, Push to Cloudflare for FOUNDER)
- Existing Founder Tools FAB widget retires once `brand-nav founder` ships — its 4 links are absorbed into the Founder Tools dropdown's "SESSION & TRACKING" group

**Why:**
- Single canonical chassis reduces sprawl across ~30 live pages where each currently maintains its own nav (the exact problem HW#112 calls out).
- Two-variant approach respects: (a) site-landing's conversion focus (keep minimal), (b) deeper-page exploration (need comprehensive), (c) founder-tools privacy (hidden via greenhouse URL + `noindex`).
- Status badge support is built into the chassis (live / in-progress / vision-board / coming-soon) — implementation details deferred to Restyle Q3 today.
- Sharing one component means future nav changes propagate automatically across every page using it.

**Considered and rejected:**
- **One unified nav for everything** — dilutes site-landing's CTA focus; rejected per A.
- **FAB widget instead of Founder Tools dropdown** — current FAB has 4 links; we have ~18 founder tools. FAB doesn't scale; rejected for D.
- **Founder Tools accessible from PUBLIC nav (just hidden)** — defeats the privacy purpose; the FOUNDER variant at `/greenhouse` is cleaner.
- **Nav always-visible (no sticky)** — loses utility on long pages where re-navigating means scroll-to-top; rejected for D.

**Files affected / ripple checks:**
- **NEW build needed:** `brand-nav.js` shared component (modeled on `brand-icon.js` / `brand-shared.css`). Includes both variants. Status-badge data attributes on every link.
- **NEW page needed:** `greenhouse.html` (or route) — internal landing for FOUNDER variant; bookmark-only.
- `site-landing.html` — keep current minimal nav (no change today).
- All brand-/product-/biz- pages (~25 files) — sweep to use `brand-nav full` once component is built. Per CLAUDE.md: "Never hand-copy nav HTML into new pages — always use the shared component."
- `CLAUDE.md` — add a session-start protocol rule: "If this session touches any HTML page, check it uses shared `brand-nav` include before closing." (Pending update in Phase 3.)
- `biz-dev-homework.html` HW#112 + the bigger Nav/Menu System card — update with status (spec locked, ready to build the component).
- `lab.html` — currently links most internal docs; will be reachable from FOUNDER nav's "Lab" entry under SPECS.
- `DEPLOY-STATUS.md` — when greenhouse ships, add to LIVE list.

**Locked by:** Ashley · May 2, 2026

---

## 2026-05-02 — Apr-27 Q3 resolved · Radial Carousel (Entry 029) locked as canonical browse-many pattern + per-surface routing matrix

**Decision:** Open Thread #1 (carried from Apr 26: *"how do you browse many seeds at once?"*) is resolved. **Radial Carousel (Entry 029) is the canonical browse-many pattern across DandyLine.** Per-surface routing matrix locked alongside (mirrors F08's structure for filters): different browse contexts have different physics, and most spatial-content surfaces use Radial; sequential/grid surfaces use the patterns that fit their feel.

**Browse-many routing matrix:**

| Surface | Pattern | Why |
|---|---|---|
| Vault interior (browse seeds inside a vault) | **Radial Carousel (Entry 029)** | Seeds-as-orbs, dandelion-feel, constellation metaphor |
| Recipient picker (planting flow) | **Radial Carousel (Entry 029)** | Orbs as people, focused-center commits |
| Multi-media seed (browse media inside one seed) | **Radial Carousel (Entry 029)** | Each media item as glyph in the arc |
| Grove vault (browse gardeners) | **Radial Carousel (Entry 029)** | Orb-avatars in arc, contributor profile detail above |
| Pressed Shelf (browse keepsakes) | **Mixed-media thumbnail strip (Entry 024)** | Already locked for Pressed Shelf filter today — same pattern for browse, conceptual unity |
| Journal-style vault (browse notes) | **Stacked-card browse (Entry 021)** | Sequential reading feel, each note is a "page" |
| "What's next to bloom" / master-visual contexts | **Master-visual + queue (Entry 015)** | Hero seed + queue below |
| Ring-of-files magnetic flip (Entry 033) | **Parked as alt** | Strong feel; no clear canonical surface yet — revisit if a use case emerges |

**Why:**
- Radial Carousel uniquely solves the "browse 6–15 distinct items WITHOUT making them feel like list rows" problem. Per Entry 029's own description: *"A list-scroll = files. A radial picker = constellation, deck of cards, jewelry on velvet. Each item has weight because it has POSITION."* That is precisely DandyLine's emotional territory.
- Per-surface mapping is the right resolution (same logic that made F08 land cleanly): a single browse pattern can't fit every context. Sequential reading (Journal vault) needs Stacked-card; flat-grid keepsake browsing (Pressed Shelf) needs the strip pattern; "now playing + queue" contexts need a master-visual.
- Locking now (vs. prototype-first) is consistent with the **Provisional Locks Principle** — the lock is a tool for moving forward, not a chain. If prototyping later reveals Radial doesn't work in a specific context (most likely Recipient Picker — some users may prefer a searchable list), supersede that row only; the rest of the matrix stands.

**Considered and rejected:**
- **Stacked-card (Entry 021) as default browse-many** — too sequential for the "constellation" feel; reads as cards-in-a-deck rather than items-on-velvet. Kept for Journal vault only.
- **Mixed-media strip (Entry 024) as default** — too horizontal/scrolly for spatial contexts; loses the radial composition that makes seeds feel anchored. Kept for Pressed Shelf only (where it doubles as the filter chassis).
- **Master-visual + queue (Entry 015) as default** — implies a hierarchy ("now playing > what's next") that doesn't fit most browse contexts where items have equal weight. Kept for narrow "what's blooming next" contexts.
- **Ring-of-files magnetic flip (Entry 033) as default** — strong tactile feel but no surface called for it strongly enough to commit. Parked.
- **No lock today, prototype-first only** — would block the live-pages restyle indefinitely. Provisional Locks Principle covers the upgrade path if testing reveals a better fit.

**Files affected / ripple checks:**
- `ux-inspiration-library.html` — Entry 029 (Radial Carousel) status: **CANONICAL — default browse-many pattern**. Entries 015, 021, 024, 033 statuses: locked for specific surfaces (021, 024) or parked alt (033) per matrix above.
- `MOTION-SPEC-V1.html` — needs cross-reference: Radial Carousel motion sits adjacent to A1 (press-spring on arrival), A6 (counter roll-up for pagination), A8 (ambient drift for idle). No new motion picks; Radial reuses existing canonical motions.
- `product-vaults.html`, `product-roots.html`, `ux-vault-flow.html` — when vault-interior browse / Grove gardener browse / multi-media seed browse get built, follow Radial Carousel motion.
- `RESUME-2026-04-28-CONTINUE-LOCKDOWN.md` — Q3 status RESOLVED. Doc archived in this session.
- `biz-dev-homework.html` — eventual `app-design-system.html` master spec build (Quest "App Design System") will consolidate Radial spec.
- *No homework card* needs to be created for "build Radial Carousel prototype" — that work happens organically inside whichever surface implements it first.

**Locked by:** Ashley · May 2, 2026

---

## 2026-05-02 — Apr-27 Q1 formally logged · F08 Context-Adaptive Filter Surface confirmed + Pressed Shelf "OR" broken (Pull-down chips wins)

**Decision:** The Apr-27 supersede question Q1 (Filter F05=B Left Panel vs Entry 028 Push-Aside Reveal) is officially resolved per the F08 routing matrix already locked in `ux-filter-decisions.html` on Apr 28. F08 was completed that day but never formally entered in the decisions log, leaving the RESUME-04-28-CONTINUE-LOCKDOWN.md handoff and homework cards unsure. This entry closes that loop. Additionally, the Pressed Shelf row in the F08 matrix had an unresolved "OR" between F05=B Left Panel and Pull-down chips (Entry 024) — **Pull-down chips (Entry 024) wins.**

**The locked F08 routing matrix (verbatim from `ux-filter-decisions.html`):**

| Surface type | Filter chassis |
|---|---|
| Vault interior (dandelion visible) | Push-Aside Reveal (Entry 028) |
| Roots map / Garden globe (spatial content visible) | Push-Aside Reveal (Entry 028) |
| **Pressed Shelf (flat grid)** | **Pull-down chips (Entry 024) ← locked today, breaks the OR** |
| Search results (flat list) | F05=B Left Panel |
| Garden grid view (toggle from globe) | F05=B Left Panel |
| Homepage (top of app) | F04=A Card Counters (untouched) |
| Recipient picker / planting flow | Faded-Context Bottom Sheet (Entry 020) |
| Quick-glance lifecycle filter (anywhere) | Always-on top pill row |

**Why:**
- Per-surface mapping is the right resolution — a single filter chassis was wrong. Spatial-content surfaces (vault interior, Roots map, Garden globe) need Push-Aside so the dandelion stays visible during filtering with live A10c orb-fade feedback. List views (Search, Garden grid post-toggle) need F05=B Left Panel because the list IS the content.
- Pressed Shelf specifically is a keepsake archive — already curated, already meaningful. The use case is "narrow my pile" not "construct a query." Pull-down chips match the tone (light, photo-album browsing) and don't displace the grid. F05=B Left Panel was built for query construction (Search Results), heavier than this use case warrants.
- Tonal lineage: Pressed Shelf is conceptually aligned with Entry 024 (Canopi mixed-media thumbnail strip) — using Pull-down chips here mirrors that heritage.

**Considered and rejected:**
- **Push-Aside as default app-wide** — loses utility on flat lists where there's no spatial content to preserve. Rejected per F08 logic.
- **F05 as default app-wide** — loses live filter feedback in spatial contexts; turns the dandelion into "something hidden behind a panel." Rejected per F08 logic.
- **F05=B Left Panel for Pressed Shelf** — heavier than the keepsake-browsing use case warrants; built for query construction, not pile-narrowing.
- **Both Pull-down chips AND F05=B Left Panel for Pressed Shelf (toggle)** — rejected as over-engineering. Pick one chassis per surface.

**Files affected / ripple checks:**
- `ux-filter-decisions.html` — F08 already locked Apr 28; this entry formalizes it. Should update the Pressed Shelf row to remove the "OR" (Pull-down chips only). **PENDING UPDATE in this session.**
- `ux-inspiration-library.html` — Entry 028 (Push-Aside Reveal) status: CANONICAL for spatial-content contexts. Entry 024 (Canopi pull-down chips): LOCKED for Pressed Shelf. Other surfaces unchanged.
- `MOTION-SPEC-V1.html` — B1 (Filter Expand) cross-reference: Push-Aside confirmed as B1(D) variant for vault contexts.
- `product-vaults.html` — when vault interior filtering is built, follow Push-Aside motion (Entry 028).
- `product-roots.html` — when Roots map filtering is built, follow Push-Aside motion (Entry 028).
- `RESUME-2026-04-28-CONTINUE-LOCKDOWN.md` — Q1 status now RESOLVED. Doc is being archived in this same session (Q2 was already reversed Apr 28; only Q3 remains pending).
- `biz-dev-homework.html` — no card touches this directly; Quest "App Design System" is the destination for the eventual `app-design-system.html` master spec build.

**Locked by:** Ashley · May 2, 2026 (formalization of Apr 28 lock + Pressed Shelf tiebreak)

---

## 2026-04-27 (evening) — Tone-Driven Seed Color System · color = WHO the seed is, lifecycle = WHERE it is in life

**Decision:** Seed orb color is driven entirely by the seed's emotional tone (auto-detected from its title and notes). Lifecycle is expressed through motion + glow + halo only — never through color. The two layers are orthogonal and never collide. A Pink seed stays Pink whether it's Patient or Bloom Now; only its behavior changes.

**The 5 color families (21 tone words total):**
- **Gold** — Warmth · Celebration · Pride · Hope (Joyful · Proud · Warm · Funny · Playful · Hopeful)
- **Sky** — Memory · Stillness · Reflection (Reflective · Quiet · Peaceful · Nostalgic · Timeless · Practical)
- **Pink** — Love · Devotion · Tenderness (Tender · Love · Devotion)
- **Sage** — Wisdom · Heritage · Awe (Wise · Awe · Wonder)
- **Purple** — Adventure · Bravery · Far Horizon (Adventurous · Brave · Free)

Default fallback for seeds with no detected tone: **Sky** (the quietest, most-neutral color).

**Halo logic for two-tone seeds:**
- Cross-family pair (e.g. Pink + Gold) → halo uses the secondary tone's full color (visible layered glow)
- Same-family pair (e.g. Gold + Gold) → halo uses a *lighter sibling shade* of the same family color (gentle gradient, not flat doubling)
- Single-tone seed → no halo, pure monochrome

**Lifecycle behavior layer (motion only, never color) — clustered into 5 groups:**
- *Toward Bloom* (Distant · Patient · Approaching · Blooming Soon · Bloom Now) — sealed seeds slowly ramp from dormant → ready; pulse rate, glow, ring expansion intensify as the bloom date approaches. Bloom Now has an always-on ambient outer glow + double expanding rings + 18% larger size — visible from any rotation.
- *Bloomed* — TRULY static. No breath, no pulse. The seed kept its tone color forever; halo provides dimension. (Sage no longer means "bloomed.")
- *After Bloom* (Drifting · Composting · Released) — dashed oat ring (Drifting) → orange dashed ring slowly counter-rotating (Composting) → no orb (Released). Pressing along the way preserves forever.
- *Pressed · Preserved* — sparkle cross + 5 orbiting twinkle stars + cream halo. Like pressing a flower in a book. Doesn't fade.
- *Location-Locked · Anchored* — faint dotted purple geofence ring around the orb. Anchored to a place, not a date.

**Why:**
- The prior celestial-named system (Gold·Sun · Sky·Moon · Purple·Stars · Pink·Love · Sage·Growth) tied colors to symbolic narratives that were retired earlier. Once celestial framing went away, the timing colors lost their meaning.
- Color was being asked to do TWO jobs simultaneously: timing (close/mid/far) AND emotional tag (love/heritage). The Pink-fade workaround (where pink seeds had to fade between pink and their timing color) was the system telling us it had too many jobs.
- One color = one job. Color says WHO the seed is. Motion says WHERE in life it is.
- Auto-detection at planting means the gardener never has to pick a color — the orb color emerges from the language they already wrote. Zero new UI step, zero friction.
- Sage is freed from the "all bloomed seeds turn sage" rule. Bloomed seeds keep their own tone color forever; the visual change at bloom is going truly static (no pulse) instead of changing color.
- Pulsation speed handles timing (already locked). Cross-family halos add visual richness for multi-tone seeds without color mixing on a single orb.

**Considered and rejected:**
- **Color = vault origin** (Gold = Grove, Sky = Personal, etc.) — would force single-vault gardeners to see mono-tone dandelions; loses variety; ties color to a structural concept rather than the emotional one that drives the user experience.
- **Color = pure ambient (random palette per seed)** — would lose all semantic meaning; color stops being legible; rejected because we wanted color to *mean* something, just one thing instead of two.
- **Manual color tag at planting** — adds friction at exactly the moment we want frictionless ("plant a memory"). Auto-detection from seed language solves this without a new UI step.
- **Keeping Hopeful in Sage family** — felt more like Milestone-warmth than Wisdom; moved to Gold late in the iteration (Apr 27 evening).
- **Enriched same-family halos** (Gold core + brighter Gold halo) — felt like "doubling up the same color" with only size variation. Switched to lighter-sibling-shade halos (Gold core + cream-gold halo).
- **Pin-tail under Location-Locked orb** — read as a "dingleberry hook," not a pin. Dropped the tail; kept just the dotted geofence ring.
- **Itemized 11-row lifecycle key** — felt heavy and many states looked nearly identical. Compressed to 5 collapsible cluster cards (3 narrative arcs + 2 special states).

**Files affected / ripple checks:**
- `TEMP-seed-color-demo-on-globe.html` — the live demo, canonical visual reference (built on the V4 globe canvas)
- `TEMP-dandelion-globe-V4.html` — ported to use tone-driven model (snapshot at `TEMP-dandelion-globe-V4_snapshot-2026-04-27-pre-tone-color-port.html` for rollback)
- `product-seeds.html` — Section 02 (Tone-Driven Color System) and Section 03 (Lifecycle Behavior Layer) fully rewritten
- `product-dandelion.html` — in-vault dandelion description updated from timing-based to tone-driven
- `ux-bloom-reveal.html` — comment clarified that prototype palette is not canonical
- Pending: any future doc that references seed colors should pull from product-seeds.html Section 02 as the source of truth

**Known downstream drift created by this lock (carry into next session):**
- **Field stats gradient bar** in the V4 bottom sheet — the segmented bar that shows lifecycle distribution (gold for Bloom Now, sky for Patient, purple for Distant, sage for Bloomed, oat for Drifting, terra for Composting) now visually conflicts with the tone-driven model. Those colors are LIFECYCLE colors, but in the new system colors mean TONES. A reader could reasonably misread "the gold segment" as "gold-tone seeds" rather than "Bloom Now seeds." Ashley liked the styling and doesn't want to drop the visualization, but the meaning has drifted. Captured for future iteration as part of `HW#186 V4 Round 2 follow-ups · item ①` (the ring/donut counter exploration), which already considers alternatives — including the home-screen pie chart pattern. Don't lose sight of: a redesign here may need to either (a) decouple bar colors from lifecycle, (b) explicitly label as "lifecycle" vs "tone" with a small switch, or (c) replace with the donut/pie pattern from the main home screen.

**Locked by:** Ashley · Apr 27, 2026 evening session

---

## 2026-04-28 (EOD) — Q2 REVERSED: Melting Ball Tabbar lock dropped · revert to canonical TAB1-family nav · "explore restrained swipe interactions later" parked in homework

**Decision:** The morning's Q2 lock (Melting Ball Tabbar / Entry 034 superseding TAB2) is **REVERSED** per Ashley's EOD feel-check. After viewing the SVG goo-filter prototype with the actual viscous morph in motion, the liquid mechanic felt "offputting" and "too far off" — not the right direction at all for DandyLine's nav. Per Provisional Locks Principle: locks are tools for moving forward, not chains; when a tested direction doesn't feel right, we reverse the lock and capture what we learned.

**What's now true:**
- **Tab nav reverts to the canonical TAB1-family direction** documented in `ux-button-system.html` lines 2885–2913 and `ux-field-homepage-v3-motionmark-depth.html` lines 318–341. Four tabs: Field · Pressed · + Plant · Gardener. Plant is the 3rd of 4 (slightly right of center), raised gold FAB, stands out from the other three. Standard tab pattern with the icons we agreed to.
- **The Plant FAB "slight bigger / stands out differently" rule survives** — that emotional anchor was the right instinct from Q2's option B; carry it forward into whatever the next tab nav iteration becomes.
- **Restrained swipe / micro-interaction layer is desired** but undefined — 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." This becomes future work, NOT today's scope.
- **Field icon is the known-unresolved question** carried into the next tab nav iteration. Current `ux-field-homepage-v3-motionmark-depth.html` uses a sprout/seedling SVG that hasn't been finalized.

**What we keep from the reversed lock (don't lose the learning):**
- The SCRATCH prototype at `SCRATCH-tab-melting-ball-prototype.html` stays as historical reference — preserves "what we tried + what didn't work." Marked as EXPLORED-NOT-LOCKED.
- Confirmation that the Plant FAB needs to be visually distinct (option B logic was right on that point).
- Validation that the Entry 034 liquid morph isn't a fit even when implemented properly with goo filter — the mechanic itself doesn't read as DandyLine.

**Why the reversal:**
- Implementation revealed the mechanic's actual feel was wrong for DandyLine's calm/tactile aesthetic.
- "Too far off" + "offputting" are unambiguous emotional signals from the founder; no point tuning further when the underlying direction isn't right.
- The cost of staying with the reversed lock = the master `app-design-system.html` spec inherits a tab nav direction Ashley already feels is wrong. Reversing now > sweeping consequences later.

**Considered and rejected:**
- Tune the goo filter values + animation timing to make the morph less aggressive: surface-level fix; the underlying mechanic is the issue, not the parameters.
- Try option A (blob turns gold at Plant) with refined timing: same fundamental mechanic, same likely "offputting" reaction.
- Park the Q2 supersede pending more inspiration before locking new direction: this IS what we're doing; reversal + homework card is the cleanest path.

**Files this affects:** `biz-dev-decisions-log.md` (this entry — supersedes the morning's Q2 lock entry above; per PLP we add new entries rather than delete old ones), `biz-dev-homework.html` (HW#183 added — tab nav restrained-swipe-interactions exploration), `SCRATCH-tab-melting-ball-prototype.html` (banner added marking it as explored-not-locked reference). The morning's Q2 lock entry below is preserved as the supersede trail.

---

## 2026-04-28 — Q3 resolved: Browse-many pattern → Radial Carousel (Entry 029) as primary chassis · Ring-of-files (Entry 033) informs depth-preview · Held-Medium Drawer (Entry 027) as destination

**Decision:** The "browse many seeds at once" pattern (open thread #1 carried since Apr 26) locks to **Entry 029 — Radial Carousel** as the primary chassis. Decision picked over Entry 021 (Apple Wallet stacked cards), Entry 024 (Canopi mixed-media thumbnail strip), and Entry 015 (MD Vinyl master-visual + queue) — those become candidate runners-up to test if the radial doesn't sit right in prototype use.

**The locked composition (3-chassis stack working together):**

1. **Entry 029 — Radial Carousel (primary chassis)** — items arc along a curved baseline, centered orb is full-size + full-opacity + gold focus ring, adjacent orbs scale to ~50% / ~55% opacity, far-edge orbs scale to ~33% / ~35% opacity (just enough to suggest "more on the way"). Detail panel above the arc surfaces the centered item's metadata. Swipe horizontal moves the arc; the centered item changes; pagination indicator (3 / 12) sits subtle in the corner.

2. **Entry 033 — Ring-of-files magnetic flip (informs the depth-preview quality)** — Ashley's verbal note about "rolodex feel · skewed off-screen ring · multi-media flip" carries the same emotional pull as 029 but with stronger depth signal. Rather than a separate chassis, **033's depth-preview quality informs how adjacent arc items render in 029**: the not-quite-centered orbs aren't just scaled-down dots — they carry a subtle skew + perspective-fade that hints "there's more behind, this is one of many." Both 029 and 033 share the throughline Ashley flagged: "show depth/volume/previews of what's next to keep you engaged."

3. **Entry 027 — Held-Medium Drawer (destination chassis)** — when the user taps the centered orb (commit), the arc fades + centered item scales up + transitions into the Held-Medium Drawer where the medium stays in view full-bleed and the draggable bottom sheet brings detail up over it. Already the canonical destination per A4 routing matrix; this lock confirms it as the post-radial-tap landing surface.

**Where this composition fits in DandyLine:**
- Browsing seeds in a vault (the canonical use case — dandelion's children rendered as arc orbs, tap one to open in Held-Medium Drawer)
- Browsing recipients when assigning a seed (orb-color avatars in arc)
- Browsing media inside a multi-media seed (each media item as glyph in arc; tap → Held-Medium Drawer with that medium full-bleed)
- Browsing gardeners in a Grove vault
- Journal-style vault with notes (each note's first line as an arc item)

**Why Entry 029 over the runners-up:**
- Already cross-referenced in 5+ distinct use cases (vault contents · recipients · media-in-seed · gardeners · journal)
- Strongest expression of the "doesn't feel like a file system" rule (arc IS the spatial frame — items have weight because they have POSITION, not because they're rows)
- Clean handoff to Held-Medium Drawer (Entry 027) on swipe-down or tap — the destination chassis is already canonical
- Ashley's verbal: "this feels right" + "depth/volume/previews of what's next to keep you engaged" — Entry 029's progressive scale + opacity at adjacent positions delivers this directly; runners-up don't have the same depth-preview quality

**Considered and rejected:**
- Entry 021 (Apple Wallet stacked cards) primary: still a strong "deck" metaphor, but cards-in-a-deck reads more sequential than constellation. The radial frame is more native to the dandelion-mark identity. Becomes runner-up if 029 prototype doesn't sit right.
- Entry 024 (Canopi mixed-media strip) primary: better for Pressed Shelf (already locked there per A4 routing), but for vault interior browsing the strip feels closer to file-system rows than 029's arc.
- Entry 015 (MD Vinyl master-visual + queue) primary: master-visual approach is excellent for single-item-deep-with-queue (already canonical for vault detail), but for browse-many the queue list is too linear.
- Entry 033 (Ring-of-files) as standalone primary: stronger depth-preview but the skewed-off-screen rolodex doesn't have the centered-focus + detail-panel-above structure that 029 provides. **Folded in as a quality-modifier on 029's adjacent rendering** rather than a separate competing chassis.
- Park as homework + prototype all 3-5: Ashley said "go (a)" — direction set, build prototype next, fall back if it doesn't feel right.

**Files this affects:** `biz-dev-decisions-log.md` (this entry), `biz-dev-homework.html` (HW#182 added — prototype build scope), references `ux-inspiration-library.html` (Entries 029 · 033 · 027 · 021 · 024 · 015), `MOTION-SPEC-V1.html` (A1 press-spring for tap commit · A8 ambient drift for adjacent orb idle · A6 counter roll-up for pagination 3 → 4), `POPUP-SPEC-V1.html` (Tier 1 popup styling carries through to arc orbs at small scale).

**Build notes for Josh:** the arc baseline is a simple SVG quadratic curve — items absolute-positioned along it via `x = startX + t * (endX - startX); y = baselineY - 4 * curveHeight * t * (1-t)`. Use `requestAnimationFrame` for smooth orb scale interpolation during drag. Snap thresholds at 50% of the gap to next item. Detail panel above crossfades during the swipe (old detail fades 180ms while new fades in 180ms behind, slight overlap). Adjacent orbs apply subtle CSS `transform: perspective(400px) rotateY(-8deg)` (left side) / `rotateY(8deg)` (right side) to deliver the Entry 033 depth-preview quality.

---

## 2026-04-28 — Q2 resolved: TAB2 superseded by Entry 034 (Melting Ball Tabbar) · Plant FAB stays raised gold (option B), blob routes around

**Decision:** Entry 034 (Melting Ball Tabbar — Neil Guo, Dribbble) supersedes TAB2 (Gradient Plant + Ring) as the locked tab navigation pattern. Integration path **B**: Plant FAB stays always-raised gold; blob routes around it for the 4 lifecycle tabs (Field · Pressed · Grove · Profile). Option A (single blob over all 5 tabs · turns gold over Plant) built as comparison reference but not chosen.

**The locked behavior:**
- 5 tabs: Field · Pressed · **+ Plant** (raised FAB) · Grove · Profile
- A single liquid blob (cream-toned, idle pulse per A8) sits over the active tab among Field/Pressed/Grove/Profile
- On tab tap (non-Plant), blob morphs viscously to the new position via SVG path morph or CSS clip-path interpolation — thin liquid bridge connects source + destination during transit (~380–450ms ease)
- D-Ring ripple (per A2) fires on tap simultaneously with blob transit start
- Plant FAB stays always-on gold, raised above the bar, with its own ~2.6s breathing pulse
- On Plant tap: blob fades to 0 opacity, Plant FAB scales briefly (Motion Spec A1 press-spring), planting flow opens
- On return from Plant to another tab: blob fades back in at the new tab's position

**Why B over A:**
- The Plant FAB is the most-recognizable visual anchor in the entire app (always-on gold = the commitment color, raised above flat tabs). Removing its distinct treatment to gain a unified blob loses more than it gains.
- "Plant is sacred" treatment preserved — the most committal action gets its own visual chassis, not absorbed into the navigation indicator.
- The blob handles Field/Pressed/Grove/Profile beautifully; Plant doesn't need to be in the same mechanic.

**Considered and rejected:**
- Option A (single blob over all 5 tabs · turns gold over Plant): more visually unified but loses Plant's sacred-FAB treatment. Built as side-by-side comparison in `SCRATCH-tab-melting-ball-prototype.html` for future reference.
- Stay with TAB2 (Gradient Plant + Ring): functional but reads as standard iOS-dock vocabulary; misses the chance to embody DandyLine's "doesn't feel like a file system" + "soft and clean" ethos at the navigation level.
- Park as homework + prototype both: prototype WAS built for both options (the SCRATCH page) and option B is clearly the right answer; no reason to delay the lock.

**Files this affects:** `biz-dev-decisions-log.md` (this entry), `ux-button-system.html` (TAB2 reference becomes "superseded by Entry 034 + Option B" — TODO sweep to update), `ux-button-decisions.html` (locked-pill strip line 332 needs "TAB2" replaced with "Melting Ball + Plant FAB"), `SCRATCH-tab-melting-ball-prototype.html` (NEW — interactive A vs B comparison, lock confirmed by interaction), references `ux-inspiration-library.html` (Entry 034 source), `MOTION-SPEC-V1.html` (A1 press-spring · A2 D-Ring ripple · A8 ambient drift idle pulse).

**Build notes for Josh:** SVG path morphing (Framer Motion `<motion.path>` with `d` attribute interpolated) OR CSS clip-path interpolation for the viscous bridge during transit. Two layers — one icon set in the tab bar (resting), one inside the blob (overlay). Active layer fades in as blob arrives. Use `requestAnimationFrame` for smooth interpolation. Snap thresholds at 50% of gap between tabs.

---

## 2026-04-28 — Filter system completion: F07 Live Pill Behavior + F08 Context-Adaptive Surface · Q1 resolved (Push-Aside for vault contexts only)

**Decision:** Two new filter decisions locked, fully resolving the Q1 supersede question (F05 = B Left Panel vs Entry 028 Push-Aside Reveal) without parking it as a prototype.

1. **F07 — Live Filter Pill Behavior** locks 7 rules that ride on top of F04-C (Pill Counters) anywhere filter pills appear in the app (NOT homepage stat cards — F04-A locked there): live count badge on every pill · predictive cross-filter math (counts reflect "if you tapped this on top of current selection") · zero-state visual (terracotta tint + 30% opacity per A10c, stays clickable to widen result set) · counter tick animation (per A6) · vault/lifecycle color logic on pills · selected-filter chip row above pills with one-tap clear + result count · empty-result graceful state.

2. **F08 — Context-Adaptive Filter Surface** locks the routing matrix mapping surface type → filter chassis. Spatial-content surfaces (vault interior with dandelion visible, Roots map, Garden globe) use **Push-Aside Reveal (Entry 028)**. Flat list surfaces (Pressed Shelf, search results, Garden grid view) keep **F05=B Left Panel**. Homepage keeps **F04=A Card Counters** untouched. Recipient picker / planting flow uses **Faded-Context Bottom Sheet (Entry 020)**. Quick-glance lifecycle filter (always-on top pill row) for the most-common filter case.

3. **Q1 (Filter F05 vs Entry 028 Push-Aside) explicitly resolved** as part of F08: Push-Aside replaces F05 inside vault contexts where preserving spatial content matters; F05=B Left Panel stays for list views. Two patterns for two surface types — codified in F08 routing matrix, no ambiguity remains.

**Why:**
- Ashley's core feedback: "filter options should probably come up in different areas throughout the experience" + "filtering can feel really clunky." A single filter chassis on every surface forces compromise; F08 names the right tool for each.
- F07 directly addresses the clunk with predictive math and chip-row summary — the user always knows what they've narrowed and what each tap would do next.
- The vault-color + lifecycle-color tinting on pills (F07 rule 5) makes filtering itself a visual taxonomy — vault and lifecycle become visible at a glance, not just labels.
- Per Provisional Locks Principle: Push-Aside (Entry 028) was a strong supersede candidate from the inspiration library; the routing-matrix solution preserves both patterns where each fits best, rather than full-replace.

**Considered and rejected:**
- Push-Aside replaces F05 universally: loses the "right tool per surface" benefit; flat list views don't need spatial-reveal magic.
- Park Push-Aside as A/B prototype homework: unnecessary delay — the right answer (vault contexts only) is clear from the use-case analysis.
- Single F07-style behavior spec for ALL pills including homepage stat cards: would force F04-A homepage to change, which Ashley explicitly preserved.
- Flat single-color filter pills: loses the visual taxonomy value Ashley flagged ("the more we can do to make filtering feel less painful").

**Files this affects:** `ux-filter-decisions.html` (F07 + F08 sections added · pick-bar updated to "All 8 Decisions Locked"), `biz-dev-decisions-log.md` (this entry), references `MOTION-SPEC-V1.html` (A6 + A10c), `POPUP-SPEC-V1.html` (lifecycle + vault color tokens), `ux-inspiration-library.html` (Entry 028 Push-Aside · Entry 024 Canopi · Entry 020 How We Feel · Entry 023 Craft).

---

## 2026-04-28 — POPUP-SPEC-V1 final vocabulary rule: countdown does the work, labels only for close states + Bloom Now CTA

**Decision:** Final reconciliation of popup state labels and countdown formats across POPUP-SPEC-V1 + V3 globe + future surfaces. Replaces the morning's first vocabulary pass (which used "Sealed/Blooming Soon/Bloom Now" as standalone state labels) with a more user-centered rule.

**The rule (Apr 28 final):**

| Tier | User-facing label | Countdown shown | Color |
|---|---|---|---|
| **Distant** | (none — countdown only) | shorthand `5yr 2mo 14d` | purple |
| **Patient** | (none — countdown only) | shorthand `3yr 4mo 12d` | sky |
| **Approaching** | "APPROACHING" + countdown | segmented `18 : 7 : 22` (DAYS:HRS:MIN) | gold |
| **Blooming Soon** | "BLOOMING SOON" + countdown | segmented `2 : 33 : 10` (HRS:MIN:SEC) | gold-lt |
| **Bloom Now** | "BLOOM NOW" + ambient pulse (per A13) | (none — countdown done) | gold-lt + glow |

Two rules underneath:
1. **Far states** (Distant / Patient) get NO label — the countdown text in lifecycle color does the work. Format (year-month-day shorthand) and color (purple → sky as time approaches) communicate distance.
2. **Close states** (Approaching / Blooming Soon) get a label PLUS segmented colon countdown. The user is forming intent at this range; the explicit label aids the moment.
3. **Bloom Now** is the CTA-active state with ambient pulse and no countdown (countdown is done).

**Special case:** **LOCATION-LOCKED** replaces the entire countdown row when location-trigger is the unlock. No countdown displayed; popup shows pin + place + "Sprouted Here"/"Rooted Here" provenance per the Roots pattern (`product-roots.html` lines 965–977).

**Filter pills are exempt:** filter pills (per F04-C) keep using categorical tier names (Distant · Patient · Approaching · Blooming Soon · Bloom Now · Bloomed · Pressed) since you filter BY category. The "no label for far states" rule applies only to individual seed popups where the countdown does the work.

**Why:**
- Ashley's verbal: "where are we ever showing these words? I think that's what feels weird... why wouldn't we just have the countdown?" The urgency tier names felt jargon-cheesy at the popup level.
- The reframe: urgency tier names (Distant / Patient / Approaching / Imminent / Blooming Soon) are INTERNAL design system vocabulary. They're useful for documentation and filter pills (filtering BY category requires names), but the user doesn't need to see "IMMINENT" as a label on top of `2:33:10` — the format + color already say "this is hours away."
- "Imminent" specifically rejected as too brand-cheesy in user-facing context. "Blooming Soon" feels native to DandyLine's voice.
- "Approaching" survives as a label because it pairs with the wider time range that was determined when designing seed orbs.
- "Bloom Now" survives because it IS user-facing (CTA word, replaces countdown when nothing left to count, gold + pulse).
- Color encoding (purple → sky → gold → gold-lt) does much of the work the labels were duplicating.

**Considered and rejected:**
- Original morning version (Sealed / Blooming Soon / Bloom Now as standalone labels): user-facing label vocabulary that didn't match the canonical urgency tiers, and "Sealed" got conflated with the Held in Trust recipient state.
- Use canonical urgency tiers (Distant / Patient / Approaching / Imminent / Bloom Now) verbatim as labels everywhere: feels jargony in user-facing popup chrome; "Imminent" especially.
- Drop ALL labels including Bloom Now: loses the CTA word that pulls the user's eye and signals "tap me." Bloom Now needs to remain visible and word-labeled.
- Show urgency tier label only on Tier 2 (full-anatomy popup): inconsistent — would mean Tier 1 says one thing, Tier 2 says another for the same seed.

**Files this affects:** `POPUP-SPEC-V1.html` (A1 = 5 variants per the rule · A2 = 4 variants including LOCATION-LOCKED · NEW Section C "Future Popup States" inventory with 6 forward refs), `TEMP-dandelion-globe-V3-POPUP-RULES.html` (tooltips updated to final vocab), `biz-dev-decisions-log.md` (this entry).

---

## 2026-04-28 — POPUP-SPEC-V1 supersede pass (B1=D, B2=C, A1/A2 multi-variant restructure)

**Decision:** Three popup-system locks updated today, applied per the Provisional Locks Principle (2026-04-27).

1. **B1 = D (Anchored depth)** — supersedes yesterday's B1 = B (Stacked with offset). Each surfacing seed gets its own Tier 1 popup anchored beside its orb (matches V2 globe pattern — popups belong to specific seeds, not a global stack point). Depth-overlap activates ONLY on collision: the lower-priority popup slides BEHIND with subtle ~3° rotation and ~55% opacity. Cap of ~5 visible per cluster. Layering is anchored to clusters, not globally — two clusters of 3 seeds on opposite sides = two small overlap groups, not one giant stack. Bloom Now popups carry the ambient pulse (per MOTION-SPEC A13) so they read as actionable even when depth-pushed behind siblings.

2. **B2 = C (Tier 2 docks as a thumbnail)** — supersedes yesterday's B2 = combo of A + C. Tier 2 card shrinks + slides to a corner as Tier 3 takes over. The "always-gold for Tier 3" rule (regardless of vault color) still stands as a separate decision.

3. **A1 reference card restructured** — single sample card replaced with 3 lifecycle variants displayed side-by-side: Sealed / Blooming Soon / Bloom Now. Same conceptual seed (Mom's letter) shown across 3 lifecycle states. Bloom Now variant carries the ambient pulse per A13.

4. **A2 reference card restructured** — single sample card replaced with 3 anatomy variants: (a) Blooming Soon voice-note seed (gold tint, countdown ticking), (b) Bloom Now photo seed (grove tint, "READY" replaces countdown, pulse), (c) Bloom Now · Location seed (legacy tint, pin row + "Sprouted Here" provenance, referencing the Roots pattern from `product-roots.html` lines 965–977).

**Why:**
- B1=B was too literal a "stack" — Ashley wanted breathing room with controlled depth, not a deck of cards. The V2 globe demonstrates the right scale of separation; B1=D codifies it.
- B2=C wins on its own once the bloom-expansion logic from A is treated as a separate concern (Bloom view = Entry 014 = full-bleed). Combining muddied the picking demo.
- A1/A2 single-variant cards forced one frozen example to communicate the entire anatomy range, and visually adjacent A1+A2 cards with mismatched state/countdown values created cognitive whiplash. Multi-variant strips show the spec adapting per context.
- The Roots cross-reference makes the location-flavored Tier 2 a real, demoable variant rather than a vague "and there's also a location version somewhere."

**Considered and rejected:**
- B1 = full stack (yesterday's B): stacking everything at one global anchor loses the seed-to-orb relationship; popups become orphans of the dandelion.
- B1 = pure A (no overlap allowed): can't handle dense clusters at all without shrinking popups too small.
- A2 single sample with annotations explaining "imagine this with a countdown / imagine this without": leaves too much to imagination, doesn't demonstrate the anatomy adaptation.
- Removing the A/B/C variants from B1 entirely: Provisional Locks Principle says we keep the prior options visible so the supersede story is self-documenting.

**Files this affects:** `POPUP-SPEC-V1.html` (rebuilt A1/A2 demos · added B1 variant D · marked B1=D and B2=C as locked · cleaned `voice note - 2:14` text → mic icon + clock format in all 3 B2 demo cards · canonical mic SVG applied to "Mom's letter" popups in B1-A and B1-B · TODO comments on the 3 ad-hoc icons in B1-A pending `brand-icons.html`), `MOTION-SPEC-V1.html` (added A13 — see separate entry below).

---

## 2026-04-28 — A13 Bloom Now Ambient Pulse added to MOTION-SPEC-V1 Section A

**Decision:** New canonical motion pattern A13 — when a seed enters Bloom Now lifecycle (countdown ended, ready to bloom), BOTH the orb AND its Tier 1 popup carry a synchronized ambient glow pulse. Gold-lt box-shadow oscillating ~12px → ~22px over 2s ease-in-out, looping indefinitely while in Bloom Now state. Orb + popup share animation phase so they breathe together (unified, not noisy). Distinct from A2 D-Ring (sharp on-tap ripple) and A12 ambient pulse (2.4s "upcoming bloom" general indicator) — A13 is faster (2s) and CTA-active.

**Why:** In B1=D anchored-depth clusters, a Bloom Now popup that's been depth-pushed BEHIND siblings still needs to call attention as actionable. The pulse pulls the user's eye to the actionable card without requiring a more aggressive treatment (color shift, motion-direction noise, badge). Also reinforces the Bloom Now state as a CTA — the seed is asking to be opened.

**Considered and rejected:**
- Reusing A12's 2.4s ambient pulse: A12 communicates "soon, in days" — using the same pulse for "now, ready to act" would flatten the temporal hierarchy.
- Color shift on Bloom Now (e.g., flash to bright gold): too aggressive, breaks the calm-memory-garden rule (A12).
- Badge or notification dot: feels like generic UI, not DandyLine's tactile anti-file-system aesthetic.

**Files this affects:** `MOTION-SPEC-V1.html` (A13 added at end of Section A), `POPUP-SPEC-V1.html` (B1=D and A1/A2 Bloom Now variants reference A13 and use the synchronized animation).

---

## 2026-04-28 — Lifecycle vocabulary clarified: "Sealed" (seed lifecycle) vs "Held in Trust" (recipient state)

**Decision:** Two state systems with adjacent dormant/wait semantics are now explicitly distinguished:

- **Seed lifecycle states** (the seed itself): **Sealed** → Blooming Soon → Bloom Now → Bloomed → Pressed / Composted / Released. **Sealed** is the canonical first state — the seed is dormant, planted but not yet ready to bloom (countdown not yet started OR still ticking down, but not imminent).
- **Recipient / Seed Keys states** (the relationship between recipient + seed): **Held in Trust** = recipient hasn't claimed the Seed Key yet (Pending / Unclaimed / Locked, per CLAUDE.md vocabulary table) → Claimed / Redeemed.

The two systems share dormant/wait semantics but live in different parts of the product. Mistake made today in POPUP-SPEC-V1 A1 lifecycle variants — initial pass used "Held" for the dormant lifecycle state. Corrected to "Sealed" per Ashley's flag.

**Why:**
- "Held in Trust" is a recipient-relationship concept (someone is holding a Seed Key on behalf of someone else who hasn't claimed it yet). Conflating it with the seed's own lifecycle dilutes the Seed Keys / Guardian / posthumous-delivery story.
- "Sealed" is an active intentional commitment ("I sealed this seed for you") — the seed IS sealed shut waiting to bloom. "Held" implies passive waiting.
- Investor + legal docs need clean state-machine vocabulary; without this distinction, the architecture story muddies.

**Considered and rejected:**
- Using "Dormant" or "Pending" for the lifecycle state: both feel generic-tech, neither has the tactile DandyLine quality.
- Renaming "Held in Trust" to something else to avoid collision: too disruptive — the term is already established in `product-seed-keys.html` and the Seed Keys story.

**Files this affects:** `POPUP-SPEC-V1.html` (A1 variant `.held` class + label corrected to `.sealed` / "Sealed"). Future-touch when validated: `product-seeds.html` (lifecycle state list), `brand-vault-renditions.html` (per-vault state language), any onboarding copy that introduces the lifecycle to gardeners.

---

## 2026-04-25 — `app-design-system` is officially Quest #23

**Decision:** The Homework system's Quest taxonomy expands from 22 Quests to 23. The new Quest slug is `app-design-system` and it covers general app UI primitives — forms, modals, tab bars, toasts, loading states, error states, iconography, voice/recording UI, account screens, spacing/grid, avatars, settings, and similar building blocks that aren't tied to a specific DandyLine concept (vault, seed, dandelion, etc.) but are needed for the actual app to work.

**Why:**
- A 4/24 app-styling prep session produced 18 cards (HW#147-164, mixed Tier A/B/C) covering app UI building blocks that didn't fit any of the existing 22 Quests.
- The closest existing slug, `ux-app-integration`, is about cross-app *consistency* (nav, mobile sweeps), not the design system itself.
- Without a dedicated Quest, future intakes will keep re-inventing this bucket under different names — drift risk.
- The 18 cards are tiered for MVP triage: Tier A = MVP blockers (8), Tier B = supporting (5), Tier C = post-MVP (3+).

**Considered and rejected:**
- Squeezing the 18 cards into `ux-app-integration`: dilutes the Quest's actual meaning (cross-app consistency) and hides the design-system as a discrete body of work.
- Splitting across several existing Quests (some into `vault-rendition-system`, some into `frictionless-first-start-ux`, etc.): scatters the audit and breaks the tier structure.
- Naming it `design-system` (no `app-` prefix): too generic; could be confused with brand design tokens (`brand-system.html`, `brand-color-system.html`).

**Files this affects:** `biz-dev-homework.html` (HW#147-164 already tagged with `data-quest="app-design-system"`), `HOMEWORK-INTAKE-BRIEF.md` (Quest table updated to 23 slugs as part of this same session), `BUILD-RESUMPTION-NOTES.md` (cleanup-session entry notes the Quest planting). Future Phase C (Quest consolidation) will need to render this Quest in the lens grouping UI.

---

## 2026-04-25 — Brand-promise reconciliation parked under HW#165 pending storage-cost clarity

**Decision:** The "25-year guarantee / 50-year Legacy Promise / Sunset offboarding" brand commitment will not be reconciled to a single canonical home today. Instead it gets a homework card (HW#165, `data-quest="brand-sweep-vocabulary"`, `data-status="thinking"`, `data-priority="medium"`) that holds both the language-reconciliation work AND the upstream financial question Ashley flagged: *is this a promise we want to keep making once we understand long-term storage costs?*

**Why:**
- The promise lives in three pages today (`product-vaults.html` Legacy section, `product-seed-keys.html` Section 15, `biz-competitive-landscape.html`) with no canonical source of truth — investors and lawyers will eventually ask where it's documented.
- But picking the canonical home and locking the promise language is premature when the underlying numbers (R2 storage economics over 25+ years, retention costs, what "Sunset" actually obligates) aren't modeled yet.
- Bundling both questions onto one card prevents the brand-language work from racing ahead of the financial reality.

**Considered and rejected:**
- Reconciling the language now into `product-vaults.html` Legacy section: locks language we may not be able to keep.
- Removing the promise from all three pages: too aggressive; the promise is part of the moat narrative and customer trust.
- Splitting into two cards (one brand, one financial): bundling forces the language decision to wait on the cost model, which is the right ordering.

**Files this affects:** `biz-dev-homework.html` (HW#165 added), eventual sweep targets `product-vaults.html`, `product-seed-keys.html`, `biz-competitive-landscape.html`, possibly `brand-ethos.html` if a "Our Promises" section becomes the canonical home.

---

## 2026-04-25 — Starlight Cove is the canonical origin source for the "Time Is the Medium" thesis

**Decision:** Every brand-narrative example, founder-story moment, and pitch reference for the "Time Is the Medium" thesis pulls from Starlight Cove first — Ashley's mom and stepdad's lake house on Lake Logan Martin in Talladega, Alabama, named for grandkids Sterling and Stella (both names mean "star"; they are the "lights of [KeKe and Papa Joe's] lives"). Sterling's first-catfish moment, KeKe's fireflies, Ella Mae sleeping under the tree, and the 20-years-from-now porch scene are the canonical example seeds.

**Why:**
- The Sterling fish story is already cited in `SESSION-BRIEF.md` as the anchor for the April 18 "Time Is the Medium" thesis and Ashley's "permission to be present" framing.
- KeKe's fireflies — *"videos never seem to do it justice"* — is the cleanest single illustration of why DandyLine exists: some moments cannot be captured as media; they can only be planted, sealed, and re-encountered.
- Pulling brand examples from one true source prevents drift across investor decks, marketing copy, and product pages.

**Considered and rejected:**
- Generic invented examples: lower trust, less defensible, harder to keep consistent.
- A mix of family stories from multiple founders/sources: dilutes the thesis and creates source-of-truth drift.

**Files this affects:** `product-roots-storyline-starlight-cove.html` (NEW canonical reference, added 2026-04-25), `product-roots.html` (Story 1 V1 stays + V2 link added), `biz-mktg-founder-story.html` (future updates pull from here), `biz-investors.html` (future pitch refresh pulls from here), `biz-mktg-copy-vault.html` (future copy options pull from here).

---

## 2026-04-25 — Signature image of Starlight Cove = golden hour on the porch

**Decision:** When DandyLine produces any visual mockup, ad, hero image, or investor slide rooted in the Starlight Cove example, the signature visual is **golden hour on the porch overlooking the cove**. Not stars-at-night despite the "Starlight" name. Not a dock shot. Not a wide lake landscape. Specifically: porch, golden hour, view of the water.

**Why:**
- Ashley's direct answer when asked which one image feels most like the place.
- The porch is the gathering spot across all four generations of presence (KeKe + Papa Joe → Ashley + Adam + Granna + Da → Sterling + Stella → future grandkids).
- Golden hour carries the right brand temperature — warm, quiet, intentional, not Hallmark-saturated.
- Single visual anchor prevents mockup drift across files.

**Considered and rejected:**
- Stars at night: literal connection to "Starlight" but cooler, more distant, less alive.
- Dock at sunset: beautiful but doesn't carry the multi-generational presence the porch does.
- Wide aerial of Logan Martin: too removed from the family experience.

**Files this affects:** Any future visual asset rooted in Starlight Cove — `product-roots-storyline-starlight-cove.html` (signature image section), future hero images for landing/investor pages, any mockups using a Roots example vault.

---

## 2026-04-25 — Roots vault Story 1: V1 (fictional, preserved) + V2 (truthful, canonical) coexist

**Decision:** The existing Story 1 in `product-roots.html` (lines 1271–1282, Grandpa-bought-the-Cove-at-thirty-four version) is preserved as V1 — it's a strong piece of writing that demonstrates the Roots vault mechanic in voice. A new V2 — the truthful, lived Sparks family version of Starlight Cove — lives in a new standalone file (`product-roots-storyline-starlight-cove.html`) and becomes the canonical reference for any brand work pulling from Starlight Cove. `product-roots.html` Story 1 gets a small note linking to V2.

**Why:**
- Ashley loves V1's voice (*"the two dogs on the shore part got me"*) — replacing it would lose a piece of writing she's emotionally attached to.
- V2's truth gives DandyLine a defensible, real-life story to anchor the brand thesis to — V1 alone is teaching material, not a brand asset.
- Both versions earn their keep: V1 demonstrates the mechanic to a new reader; V2 carries the founder origin and pulls into pitch, marketing, and reference work.

**Considered and rejected:**
- Replace V1 with V2 entirely: loses V1's writing; Ashley explicitly asked to preserve it.
- Two completely separate stories with no link: confusing — readers should understand the relationship.
- Merge V1 and V2 into a single hybrid: dilutes both; the truth and the demonstration are different jobs.

**Files this affects:** `product-roots.html` (small V1/V2 note added above Story 1), `product-roots-storyline-starlight-cove.html` (NEW canonical V2), `biz-dev-command-center.html` (TOC entry for new file), `DEPLOY-STATUS.md` (new file added to ON HOLD until Ashley green-lights).

---

## 2026-04-22 — Card numbering convention: drop the "HW#" prefix

**Decision:** Homework card numbers are displayed as `#N` (e.g., `#70`, `#107`, `#112`) — NOT `HW#N`. The "HW" letters were redundant since the entire page is homework. `data-hw-id` attribute internally stays `HW070` / `HW107` etc. for uniqueness (developer-facing), but all visible card titles, prose references, and headings use `#N`.

**Why:**
- Ashley flagged: "Why keep HW# if they're all the same type of #? Feels like useless extra letters."
- Shorter visual signal reads faster in titles.
- Internal data-hw-id keeps the HW prefix for grep-ability in source code.

**Files this affects:** `biz-dev-homework.html` (sweep titles: HW#N → #N), future intake ritual updates to use the new convention.

---

## 2026-04-22 — Status taxonomy rename: "fleshed-out" → "spec-ready"

**Decision:** The third rung of the status ladder is renamed from `fleshed-out` to `spec-ready` — clearer meaning: "decisions are locked and the thing is defined, but not yet built."

**New ladder:** `parked` → `thinking` → `spec-ready` → `designed-built` → `bloomed`

**Why:**
- Ashley asked what "fleshed-out" meant; the name was ambiguous.
- "spec-ready" directly signals: we know what we want, next step is build/design.
- All other states kept as-is.

**Files this affects:** `biz-dev-homework.html` (CSS selectors, JS switch cases, sub-lens filter chip label, HTML schema template comment, any card `data-status="fleshed-out"` values), Phase B tag proposals.

---

## 2026-04-22 — Add "research" as a work-type badge (effort class)

**Decision:** Add `.hw-effort-research` to the existing effort-badge vocabulary (alongside quick / medium / deep / decision / external). Research = "work needed to resolve this is investigation, not design or build." A card can be `data-status="thinking"` AND have the research effort badge, meaning "I need to research X before I can decide."

**Why:**
- Ashley flagged that some "thinking" cards are really "needs research first" — different in kind from "needs a judgment call" (decision).
- Makes the filter/visual vocabulary more honest about what kind of work a card demands.
- Additive change: doesn't invalidate existing tags.

**Considered and rejected:**
- Split status into two attributes (ripeness + worktype): more correct but more work. Option open for Phase C if research-effort feels valuable in practice.

**Files this affects:** `biz-dev-homework.html` (CSS for `.hw-effort-research`), HTML schema template, any future card proposals.

---

## 2026-04-22 — Priority unification: single 3-level system (high / medium / low) + filter chip

**Decision:** Legacy priority labels ("HOT PRIORITY — DO TOMORROW", "HIGH PRIORITY — KEY DECISION", etc.) collapse during Phase B retro-tagging into the already-locked `data-priority="high|medium|low"` system (from Decision #2). A new Priority filter chip ships alongside Status/Owner during Phase D. No card carries two priority systems after Phase B completes.

**Why:**
- Current legacy cards show mixed, inconsistent red labels — "HOT", "HIGH", "TOP PRIORITY" — that mean roughly the same thing but aren't filterable.
- Ashley asked for one system that she can filter by. The existing `data-priority` attribute is the right home; it just needs universal application.
- Keeping both systems during migration creates confusion, so the rule is: after a card is retro-tagged, its legacy priority label disappears.

**Considered and rejected:**
- Keep all legacy labels as decorative: unfilterable; contradicts Decision #2.
- Invent a new 4th priority level ("hot"): adds cognitive load; high+due-date already expresses urgency.

**Files this affects:** `biz-dev-homework.html` (Phase B retro-tagging — each batch strips legacy priority prose and sets `data-priority`; Phase D adds Priority sub-lens chip), `CLAUDE.md` (Phase E documents the priority system).

---

## 2026-04-22 — Homework card is the project hub (Working Pages, nav discipline)

**Decision:** Every in-progress project or scratch HTML page lives *behind* its home homework card — the card is the active entry point, not a historical footnote. The main site nav holds only launch-ready pages. Work-in-progress pages are never dumped into the nav; they surface via a new card section called **Working Pages**.

**Schema extension:** Cards gain a 5th structured section called **Working Pages**, placed between Highlights and Notes. Distinct from References (Decision #5, historical):
- **Working Pages** = active artifacts currently being built/revised (status pill: `draft` · `review-ready` · `archived`)
- **References** = historical decision-record links (existing, unchanged)

This gives the card three distinct link surfaces:
1. Highlights: cross-card dependencies + inline references
2. Working Pages: *active* HTML/doc artifacts for this project
3. Notes: migrated prose + deep context

**Why:**
- Ashley has been publishing in-progress HTML pages just to have a URL to reference, which bloats the nav and destroys the signal of "what's launch-ready vs what's not."
- Tying a work-in-progress page to its homework card means the card becomes the one-stop navigator for the project.
- Nav stays clean — only things users would see go there.
- When a project graduates (ships), its Working Pages promote to launch status and optionally get added to the real nav.

**Considered and rejected:**
- Extend References to cover both active and historical: loses the active-artifact signal; makes it unclear what's current.
- Single "Linked Files" section with status tags: less visual noise but mixes concerns — Ashley explicitly chose the separate-section mental model.
- Keep the status quo (in-progress pages live in nav): already proving unmanageable; Ashley surfaced this as the pain point.

**Status pill rules for Working Pages:**
- `draft` — being built; subject to change; not stable enough to reference elsewhere
- `review-ready` — ready for eyes on it; share-stable
- `archived` — superseded but preserved (never deleted, per Safety Rule 6)

**Files this affects:** `biz-dev-homework.html` (CSS for `.hw-working-pages` + schema template), navigation across the site (pending audit: `biz-dev-homework.html`, `biz-dev-command-center.html`, `site-landing.html` footer, any other pages with nav menus), `CLAUDE.md` (document the hub principle + nav discipline in Phase E).

**Nav audit follow-up:** Completed 2026-04-22. Current nav (8 items) is fine; only the 3 dying notes pages need removing, and that's already queued for post-Phase-B retirement. No invasive prune today. Working Pages discipline applies going forward: scratch HTML files are reachable through their home card via `file://` links — they never need to be deployed live just to be referenced.

---

## 2026-04-22 — Pressed (completed) cards roll up to one global bottom section

**Decision:** The `organizePressedItems()` script is rewritten so all bloomed cards from every grid on the Homework tab collapse into a **single global "Pressed" section at the bottom of the page** — not one Pressed pile per grid. Collapsed by default. Still never-delete (Safety Rule 6); just tucked away from the active thinking space.

**Why:**
- Per-grid Pressed piles scattered completed work through the middle of the page, interrupting the scan for active cards.
- A single global pile gives Ashley one predictable place to look when she wants to see "what's bloomed" — and keeps the rest of the page focused on what's open.
- Preserves the momentum counter and "never deleted" archive properties.

**Considered and rejected:**
- Hide completed entirely: Ashley wants them reachable, just not in the way.
- Separate tab for completed: yet-another-tab; cost > benefit.

**Files this affects:** `biz-dev-homework.html` (JS rewrite of `organizePressedItems()`).

---

## 2026-04-22 — Notes-section-is-the-destination (no new reference-file prefix)

**Decision:** Content migrated out of the three notes pages (`biz-dev-notes-product.html`, `biz-dev-notes-business.html`, `biz-dev-notes-strategy.html`) lands inside homework card `Notes` sections — not in any new standalone reference file, not in a new "archive-notes" HTML, not scattered across prose in card descriptions. This reinforces Decision #9 (Notes section is the 4th card anatomy slot) and makes a single homework card the one true home for all thinking on that topic.

**Why:**
- Preserves "one card, one memory" — the card itself holds the full history including migrated prose.
- Avoids proliferation: a new reference-prefix file for migration byproducts would re-create the scattered-thinking problem we're solving.
- Makes the audit + migration self-documenting — the Notes section shows exactly what came from where.

**Considered and rejected:**
- A new `biz-dev-reference-notes-archive.html`: would duplicate decision #9 and create another page to maintain.
- Leaving the three notes pages in place indefinitely: they'd drift out of sync with card Notes; confuses source of truth.
- Migrating into card descriptions (prose): kills scannability, violates decision #9.

**Files this affects:** `biz-dev-homework.html` (Notes sections on gem + useful-item target cards), archive workflow for the three notes pages (copy-to-archive, per Safety Rule 6 — never delete).

---

## 2026-04-22 — Gem-first migration strategy for notes-pages retirement

**Decision:** Notes-page retirement runs in this order: (1) create the 5 high-value "gem" cards now under their target Quests; (2) fold the 14 useful items into existing-card `Notes` sections during Phase B retro-tag batches as each item's Quest comes up; (3) retire the three notes pages after the last Phase B batch lands — copy to archive folder, remove links from `site-landing.html`, `biz-dev-homework.html` sidebar, and `biz-dev-command-center.html` TOC/sidebar; update `CLAUDE.md` archive rules and `biz-dev-prompt-playbook.html`.

**Why:**
- Gems first = protect high-value scattered thinking before anything else touches the files.
- Useful items piggyback on Phase B work — no extra migration pass, no wasted cycles.
- Retire-last sequencing keeps the three pages intact and reachable until everything worth saving is verifiably homed elsewhere.
- "Copy to archive, never delete" honors Safety Rule 6.

**Considered and rejected:**
- Option A (migrate all 19 items today, retire next): front-loaded effort; heavy session today with no structural benefit over piggyback.
- Option C (retire first, rebuild): highest loss risk — anything the audit missed would vanish before rebuild.

**Pre-migration edits required on all gems:** strip celestial framing (sun/moon/stars — retired); separate military brand framing (retired) from Quest #9 military partnership GTM (kept); update any lingering "Supabase" references to Cloudflare-only stack.

**Files this affects:** `biz-dev-homework.html` (5 new gem cards immediately + 14 useful items woven into Phase B), `biz-dev-notes-product.html` + `biz-dev-notes-business.html` + `biz-dev-notes-strategy.html` (archived after last Phase B batch), `site-landing.html` (footer links ~1494-1496), `biz-dev-command-center.html` (TOC + sidebar), `CLAUDE.md` (archive rules), `biz-dev-prompt-playbook.html` (references to notes pages).

---

## 2026-04-22 — MVP Build Roadmap lives on its own tab inside `biz-dev-homework.html`

**Decision:** The MVP Build Roadmap section stays in `biz-dev-homework.html` but moves behind a top-of-page tab switcher: **📋 Homework** (default) and **🛠 Build Roadmap**. Same file, one always-current source of truth — different visual contexts. Individual roadmap steps are modeled as homework cards tagged `data-quest="family-mvp-build"` so the roadmap view is literally a filter over the same cards.

**Why:**
- Homework page is Ashley's thinking/deciding workspace. Build Roadmap is Josh's execution sequence. Visually interrupting daily homework flow with a roadmap was noisy.
- Auto-sync was mandatory: "where it always updates both if you can set that rule" — one file solves this for free.
- Modeling roadmap steps as homework cards means any change to a roadmap step shows up in both views automatically. No duplication, no drift.

**Considered and rejected:**
- Move to Command Center: clean separation but introduces cross-file sync burden. Not worth it.
- Move to Dashboard: similar sync cost; Dashboard is already overloaded.
- Keep as inline section (status quo): visually interrupts homework use; Ashley flagged.

**Files this affects:** `biz-dev-homework.html` (add tab switcher markup + JS; wrap existing roadmap in a `<section>` that shows when "Build Roadmap" tab active; `data-quest="family-mvp-build"` on roadmap-step cards during Phase B).

---

## 2026-04-22 — Card anatomy adds a 4th collapsible section: "Notes"

**Decision:** Every card now has **four** structured sections (up from three):
1. **What's Next** — always visible, 1-3 lines, today's concrete next step.
2. **Highlights** — always visible, scannable bullets (done / in-progress / deps / refs).
3. **Notes** — collapsed by default, unlimited prose. Holds heavy note migrations, meeting transcripts, full context dumps.
4. **History** — collapsed by default, dated log of decisions/locks/status changes.

**Why:**
- Ashley is about to migrate hefty note content into homework cards; without a dedicated home, it would clutter Highlights or crowd History.
- Separating "scannable at rest" (Highlights) from "deep dive when I want it" (Notes) preserves card scannability at 127+ cards.
- History is reserved for chronological tracking, not prose; mixing them makes both harder to use.

**Considered and rejected:**
- Letting Highlights grow unbounded: kills scannability.
- Putting everything in History: makes History too dense to skim for the progression.
- Linking out to separate files: breaks the "one card, one memory" principle from decision #7 (card anatomy).

**Files this affects:** `biz-dev-homework.html` (CSS for `.hw-notes` section + update card schema HTML comment template), `CLAUDE.md` (document the 4-section anatomy in Phase E).

---

## 2026-04-22 — Momentum stats re-layout + Next 5 collapsed by default

**Decision:** (1) The three momentum stat tiles (Seeds Bloomed / Seeds Growing / Field Progress) stack vertically in a narrow **right column** next to "What to start next session" — not full-width below it. (2) The "Next 5 Priority Queue" widget is **collapsed by default** with a click-to-expand affordance.

**Why:**
- Full-width stat tiles eat real estate that Ashley wants for the session note itself.
- Next 5 is useful but not something Ashley needs shouting at her every page load; she wants it available, not demanding.
- Collapsing by default respects that this is a tool for focused work, not a dashboard to stare at.

**Considered and rejected:**
- Removing stats entirely: she values the momentum counter — keep it, just quieter.
- Auto-expanding Next 5 based on whether it has items: ambiguous behavior; collapsed-default is predictable.

**Files this affects:** `biz-dev-homework.html` (top-of-page section layout + Next 5 widget markup/CSS).

---

## 2026-04-22 — Card anatomy: What's Next + Highlights + collapsible History

**Decision:** Every homework card carries three standard sections below its description: (1) **What's Next** — 1-3 lines, always visible, the concrete next step; (2) **Highlights** — always visible bullet list of done / in-progress / dependencies / references; (3) **History** — a `<details>`-collapsed, dated list of progress entries, decisions, and locks, collapsed by default. Each card becomes a small living memory of its own life.

**Why:**
- When a topic reopens after weeks away, Ashley needs to see "where did we leave this?" without scrolling a massive page or re-reading a long log.
- "What's Next" answers the single most common daily question: *what do I do with this card today?*
- "Highlights" surfaces the structured cross-references (deps, refs) without burying them in prose.
- Collapsed "History" keeps the card scannable at rest but preserves the full paper trail one click away.
- Enables Claude to write *into* a card over time rather than overwriting it.

**Considered and rejected:**
- Plain description only: no anchor for "what's next today."
- Full history always visible: cards become walls of text; scannability dies at 127 cards.
- History in a separate log file: splits the card's memory from the card; breaks the "one card, one truth" principle.

**Files this affects:** `biz-dev-homework.html` (card HTML + CSS for the three sections, JS for collapsible behavior), `CLAUDE.md` (document the schema and intake update ritual).

---

## 2026-04-22 — Homework system: B+C hybrid architecture (Quests + Lenses)

**Decision:** Rebuild `biz-dev-homework.html` as a Quest-structured page (~20–25 parent Quests containing all 127 current cards as nested steps) with three toggleable Lenses layered on top (Ripeness / Owner / Area). Default lens on load = Ripeness.

**Why:**
- The homework list has 127 cards across 15 inconsistent groups — un-scannable at current scale.
- Ashley opens it daily; Josh and Adam open it occasionally. All three need useful views without maintaining three separate files.
- Quests force consolidation and surface long-horizon strategy; Lenses give each role a natural entry point without rebuilding.

**Considered and rejected:**
- Kanban (Option A): optimized for sprint work, not long-horizon arcs; underserves Josh/Adam.
- Lenses-only (Option C): doesn't consolidate the 127 count; data-hygiene debt would surface quickly.
- Quests-only (Option B): strong consolidation but no role-scannability; source-based groupings (plane workbook, etc.) dissolve with no alternative view.

**Files this affects:** `biz-dev-homework.html` (full rebuild), `biz-dev-command-center.html` (TOC entries — decide later), `CLAUDE.md` (add Quest taxonomy + 5 statuses as reference).

---

## 2026-04-22 — Three-role ownership is mandatory on every homework card

**Decision:** Every homework card carries an explicit `owner` field with one of: Ashley · Josh · Adam · Shared. Handoffs are modeled on the card (e.g., "Ashley decides → flips to Josh to build") rather than requiring card duplication.

**Why:**
- Josh, Ashley, and Adam all open the homework page. Without ownership, each has to hunt for what's theirs.
- Handoffs are common in Ashley's workflow (she decides, then Josh builds; or she answers Adam's question). Modeling them on a single card prevents duplicates.

**Considered and rejected:**
- Leaving ownership in prose (status quo): invisible to any filter or counter; fails Josh and Adam entirely.
- Separate pages per owner: maintenance burden; cards drift out of sync.
- Multi-owner cards with two equal primaries: ambiguous; nobody acts.

**Files this affects:** `biz-dev-homework.html` (schema), future intake prompts in `biz-dev-prompt-playbook.html`.

---

## 2026-04-22 — Status is a 5-state structured taxonomy, not freeform text

**Decision:** Every homework card carries an explicit `status` field drawn from this closed ladder: `parked` → `thinking` → `fleshed-out` → `designed-built` → `bloomed`. The Blooms Counter reads `data-status`, not prose.

**Why:**
- The current counter scans status text for magic words (`locked`, `designed`, `bloomed`, etc.) and miscounts when cards use freeform statuses.
- Ashley wants visible progress between "just an idea" and "done" — strict binary (open/closed) hides that.
- Five states cover: unstarted → working-through → decisions-made → has-a-design-or-build → shipped-or-locked.

**Considered and rejected:**
- Binary (open/bloomed): too coarse; hides real progress.
- 8+ states: too much cognitive load during intake.
- Keeping freeform status prose: already proven unreliable for the counter.
- "Blocked (waiting on someone)" as a 6th state — held open for one more conversation; may live as a flag across states rather than its own state.

**Files this affects:** `biz-dev-homework.html` (schema + counter script), `CLAUDE.md` (document the taxonomy).

---

## 2026-04-22 — Intake ritual: propose-and-confirm with auto-link bias

**Decision:** When Ashley says "add this to homework," Claude first searches existing card titles + descriptions for matches, surfaces the top 1–2 candidate parents (Quest or card), and defaults the question toward *"attach as a step under HW#X, or new card?"* rather than always creating new.

**Why:**
- Ashley dumps ideas from many sources (chat, notes, screenshots). Without dupe-prevention, the list explodes.
- She explicitly rejected "always new, merge later" — said it gets out of control.
- Auto-linking without confirmation risks wrong-parent burial; propose-and-confirm costs one beat and preserves correctness.

**Considered and rejected:**
- Always create new, merge later: rejected by Ashley — list grows unbounded.
- Pure auto-link (no confirmation): wrong-parent risk is too high for items she can't easily find later.

**Files this affects:** Intake behavior (Claude-side); `biz-dev-prompt-playbook.html` may get a new keyword shortcut (`"add to homework"`) with explicit dupe-check behavior documented.

---

## 2026-04-22 — Homework cards carry reference document links

**Decision:** Every card can capture the local files where decisions or progress were recorded — filename + date + 1-line summary. Displayed on the card in a "References" section. Clickable for Ashley locally (via `file://` links); Josh and Adam at minimum see the filenames as text references.

**Why:**
- When a topic reopens (idea expands), Ashley needs to see what was already solved and where. That history currently lives only in her head.
- Gives Claude a persistent anchor: "we solved this in `product-seeds.html` on April 14 — the expansion goes here."
- Makes each card a small history of its own life, not just a current-state snapshot.

**Considered and rejected:**
- Prose-only references (status quo): invisible to filters, easy to lose in edits.
- A separate "decisions-per-topic" file: duplicates this log; the card itself is the better home.

**Files this affects:** `biz-dev-homework.html` (card schema), a local-file-link convention documented in `CLAUDE.md`.

---

## 2026-04-22 — "Blocks Josh" (and "Blocks Adam") is a first-class query

**Decision:** Any Ashley-owned card can carry a `blocks: josh` or `blocks: adam` tag. The Owner Lens pins the "Ashley-blocks-Josh" list to the top whenever that lens is active, so Ashley can clear a collaborator's critical path in seconds before a call.

**Why:**
- Ashley said explicitly: while Josh is in build mode, she wants to know what blockers she needs to remove for him as a priority.
- Without a structured tag, she'd have to re-scan the list each time.
- Same pattern applies to Adam, though less frequently used.

**Considered and rejected:**
- Leaving "blocks Josh" in prose: invisible to filters; fragile.
- A separate "Josh's blockers" page: Josh already lives in his roadmap; he doesn't need a separate page, Ashley does.

**Files this affects:** `biz-dev-homework.html` (card schema + Owner Lens rendering), `QUESTIONS-FROM-ASHLEY.md` (cross-reference when a blocker clears).

---

## 2026-04-27 — Motion Spec V1 — 4 motion patterns locked

**Decision:** Four undefined motion patterns from `MOTION-SPEC-V1.html` Section B are locked. Source canvas: a 4-group / 12-variant interactive comparison page Ashley played and picked from in real time.

| Group | Pick | Pattern |
|-------|------|---------|
| **B1 — Filter Expand** | **C** — Modal expand FROM the pill | Filter pill grows into a centered modal with origin = pill location. Most "magic" feel of the three; the pill IS the panel, just expanded. |
| **B2 — Popup Tier-1 → Tier-2 expand** | **B** — Crossfade in same position | Tier 1 (glance tooltip) fades out at same anchor as Tier 2 (full preview card) fades in. Calm, controlled, no motion-direction noise. |
| **B3 — List enter/exit on filter change** | **C** — Height-collapse with stagger | Items collapse vertically with a 40ms stagger when filter results change. Feels like the list is taking a breath; new items rise into the same gap. Most "garden-like" of the three. |
| **B4 — Vault / Jar Title float-in** | **B** — Type-in letter-by-letter | Titles type in at ~25ms per character on first view (cached as "seen" so re-visits show fully written). Storytelling feel — paired with A7 (canonical text-reveal rule for first-time greetings). |

**Why:**
- Ashley played all 12 variants in `MOTION-SPEC-V1.html` and chose what felt least like an app and most like "a quiet thing happening" (her filter-rule for the entire motion vocabulary).
- Choosing locks per group means we can build the consolidated motion spec for Josh without leaving placeholders.
- These join Section A's 12 already-canonical patterns (press-spring, D-Ring ripple, element entrance, bottom-sheet rise, stacked-card lift, counter roll-up, text reveal, ambient drift, chip-tap pulse, downstream terracotta flash, per-vault dot language, calm-memory-garden rule).

**Considered and rejected (per group):**
- **B1**: A (slide-down from button) — felt cramped; B (bottom-sheet rise) — heavier than needed for a filter pill.
- **B2**: A (lift + grow in place) — buggy positioning Ashley flagged; C (slide up from below to replace) — Ashley dropped explicitly: "doesn't feel right."
- **B3**: A (fade through) — no direction, doesn't communicate cause-and-effect; B (slide horizontal) — too active for a passive filter result.
- **B4**: A (drift up + fade) — was non-functional in test; C (scale up from .96) — also non-functional. B was the only working variant AND felt right for storytelling, so the win is genuine even though the alternates were buggy.

**Open / parked considerations:**
- **Entry 028 (Push-Aside Reveal)** is parked as a future **B1(D) candidate** specifically for vault-context filtering (where preserving the dandelion view matters). May supersede B1=C inside vault contexts. Worth A/B testing in prototype before the lock is treated as universal.
- **A10 sub-rules** (pick-confirm + sibling-dim, reveal-new-options, cascade-invalidation retuned) still need prototypes. Tracked in `BUTTON-CONSOLIDATION-FEEDBACK-2026-04-26.md`.
- **Bug parked**: B4(A) and B4(C) replay buttons don't fire even after a double-RAF fix attempt. Doesn't block the lock since B was chosen; revisit when consolidating the spec.

**Files this affects:**
- `MOTION-SPEC-V1.html` — source page for the lockdown (kept as reference).
- Future `MOTION-SPEC-LOCKED.html` (or equivalent section in the consolidated spec for Josh) — these 4 picks roll in alongside Section A's canonical patterns.
- `BUTTON-CONSOLIDATION-FEEDBACK-2026-04-26.md` — already cross-referenced.
- Eventual buildable spec for Josh — these are buildable rules with concrete CSS easings and durations (already inline in the variant code).

---

## 2026-04-27 — Provisional Locks Principle (meta-rule for every design decision)

**Decision:** Every lock in this design system is **provisional** — held only as long as no stronger inspiration has been captured. If a later inspiration entry, gesture, swipe pattern, or action-activated interaction is meaningfully more powerful than the current lock, the locked pick gets superseded by a new entry — not defended.

**Why:**
- Ashley's exact words (paraphrased): "I don't want any of what we're deciding on to override something that could be stronger because you're setting it as a rule." Locks are tools for moving forward, not chains.
- Gesture / swipe / action-activated interactions are often more powerful than basic pill-clicks → dropdowns. The inspiration library is the canonical source of these stronger patterns; it must be allowed to outweigh quick comparison-page picks.
- Without this principle, "we already locked B1=C" becomes a reason to NOT explore Push-Aside (Entry 028), which would be a worse outcome than the lock itself.
- The decisions log explicitly says "supersede with a new entry if needed" — this rule names that pattern as the default expectation, not the exception.

**How to apply:**
- When a new inspo entry lands that overlaps with a locked pick, evaluate: is it meaningfully stronger (more on-brand, more powerful, more emotional, more "DandyLine and not a generic app")?
- If yes → build a quick prototype to compare side-by-side, then write a new "supersedes [previous decision]" entry in this log.
- If no → keep the lock, but file the inspo entry as a future-consideration cross-reference.
- Lock language should always read as "the best of what's been built so far" — never "the final answer ever."
- Specifically: **never refuse to build a stronger candidate because something earlier was 'locked.'**

**Considered and rejected:**
- Treating locks as final-final to "stop revisiting decisions": too rigid for a pre-MVP design system where the inspiration library is actively growing weekly.
- Removing locks entirely (only inspiration entries, no decisions): too soft — Josh needs concrete buildable rules to ship.
- The middle path (provisional locks) is the only one that respects both the need for shippable specs AND the need to keep evolving toward "feels like DandyLine, not one of 30 generic apps."

**Files this affects:** Every locked decision page (`ux-button-decisions.html`, `ux-component-decisions.html`, `ux-filter-decisions.html`, `MOTION-SPEC-V1.html`, future spec files), this decisions log, and CLAUDE.md (the rule should be referenced there too).

**Concrete next-up application:** B1=C (Modal expand FROM the pill) is provisional. Entry 028 (Push-Aside Reveal) is the strongest candidate to supersede it inside vault contexts. Building B1(D) prototype is on the todo list for after the YouTube inspo batch — that prototype either confirms B1=C wins or supersedes it with B1(D)=Push-Aside.

---

## 2026-04-27 — Pop-up Cards V1 — 2 picks locked + reference fixes

**Decision:** Two undecided pop-up card patterns from `POPUP-SPEC-V1.html` Section B are locked. Plus three corrections applied to the canonical Tier 2 reference card.

### B1 — "Crowded Dandelion" pop-up treatment
**Pick: B — Stacked with offset.** When 4–5 popups want to surface around a tight seed cluster, all popups stack at ONE anchor point (next to the cluster, not the individual orbs), each offset slightly with a small rotation — like cards on a table, top one full size + opacity, others peeking out behind at lower opacity. Tap to flip through. Replaces the rejected variants A (smaller-scale crowd — too cluttered) and C (pointer chips — too quiet, loses identity).

### B2 — Tier 2 → Tier 3 transition
**Pick: COMBO of A + C** — the bloom expansion (A) **and** Tier 2 docks as a thumbnail (C).
- **Mechanics**: when the gardener taps "open" on Tier 2, the seed's surrounding area expands outward (A — Entry 030 bloom expansion) into the Tier 3 view. Simultaneously, a small thumbnail of the original Tier 2 card persists in a corner of Tier 3 as a "you came from here" anchor (C). Tapping the thumbnail returns to Tier 2.
- **Tier 3 expansion is ALWAYS gold** — never vault color. **Why:** a seed can live in multiple vaults at once; the ACT of blooming is universally a gold (commitment) moment per the Golden Rule. The vault color belongs to browsing/choosing context, not the bloom.
- **Caveat from Ashley**: "as long as it proportionally feels okay when executed." The thumbnail must not feel parasitic on the Tier 3 view. Specifically: the thumbnail should be ~15–20% of the Tier 3 width, in a non-blocking corner (likely top-right or top-left where the back-arrow already lives), with a soft cream-glass backdrop to read against any Tier 3 medium.

**Why these picks:**
- B1=B preserves identity (each seed still has its own popup) without crowding the dandelion (the Throughline rule). Cards-on-a-table is a tactile, "doesn't feel like a file system" treatment.
- B2 combo is the strongest reading of Ashley's reaction. A alone (just expansion) doesn't preserve "where you came from." C alone (just thumbnail dock) loses the powerful bloom-moment energy. The combo lets the bloom feel powerful AND keeps the thread back to the preview.

### Reference fixes (Section A2 Tier 2 anatomy reference)
1. **Media row**: replaced text "voice note - 2:14" with the actual mic icon + just the duration "2:14". Per Ashley: "should have an actual icon in place of the words."
2. **Emotion separator**: dash → middot (`·`). Per Ashley: "the dash feels weird to me." Up to 3 emotions allowed.
3. **State + status text consistency**: changed "Bloom Now" to "Blooming Soon" in both the state pill and the status row, since the countdown was showing "2h 43m 18s" — "Bloom Now" implies "right now," which is contradictory to a countdown. Now reads: state="Blooming Soon", countdown="2h 43m 18s", status="Blooming Soon · Planted Mar 12, 2024" — internally consistent.

### Open thread raised by Ashley during this lockdown
- **Small-medium-icon disambiguation** — the canonical mic / camera / video / note / location icons need a SMALL-SIZE variant set that stays distinguishable at the sizes used in B1 (stacked-popup variant — icons render at ~10–12px). Risk: at small size the icons might look too similar (mic vs note silhouette especially). Need to finalize a small-icon set before the crowded-dandelion treatment ships. Tracked separately — likely an addition to `brand-system.html` or a new `brand-icons-small.html` reference.

**Files this affects:**
- `POPUP-SPEC-V1.html` — picks marked, A2 reference fixed.
- Future `app-design-system.html` (master spec) — these picks roll in alongside MOTION-SPEC and component picks.
- `brand-system.html` (or new `brand-icons-small.html`) — small-icon disambiguation work.

---

*This file is a living document. When you want to add a decision, say "plant a flag" to Claude and describe what locked. Never delete entries — supersede with a new entry if needed.*