Example project — Frond is not real.

Authored demo content for a fictional plant-care app, rendered by the same parsers and held to the same invariants as a real project's dashboard. This is the system in use, three months in.

docs/decisions.mdCommitmentsactive2026-07-18Read when: phase close (lift load-bearing walkthrough decisions here), retrospectives

Decisions log

The long-term institutional memory: dated design + product decisions, newest first. Each entry answers What we decided, Why (alternatives considered), and Where it shows up.

Format

## YYYY-MM-DD · Short title

**What:** One sentence stating the decision.
**Why:** 1-3 sentences on reasoning. Name the alternatives considered.
**Where:** Files / surfaces / docs affected.

Entries

2026-07-18 · Reminders are a daily digest, not per-plant pushes

What: All due plants collapse into one notification per day, at a time the user picks. Why: Per-plant pushes tested as the fastest route to being muted: six plants meant six buzzes. A digest costs us the ability to nag about a single urgent plant, which we accepted. Alternative considered: per-plant with a rate limit, rejected as harder to reason about and still bursty. Where: features/watering-reminders.md, notifications/digest.ts.

2026-07-14 · Light readings are a range, never a number

What: The room survey reports a band ("bright, indirect") instead of a lux figure. Why: A phone camera cannot justify three significant figures, and a precise-looking number invites the user to trust it more than it deserves. A band is honest about our resolution and is still enough to pick a schedule. Where: features/room-light-survey.md, archive/phases/room-light-survey.md.

2026-07-09 · One plant before any account

What: Onboarding adds the first plant before asking the user to sign up. Why: The signup wall was where the funnel died: people had nothing invested yet. Letting them add a plant first means the account protects something they already made. Alternative considered: full anonymous mode, deferred as sync complexity we cannot carry yet. Where: features/onboarding.md, archive/phases/onboarding-v1.md.

2026-07-02 · Species data is licensed, not curated

What: We license a third-party species database rather than maintaining our own. Why: Curating care data is a full-time botany job we are not staffed for, and being wrong about a rare plant is worse than being generic. The cost is that we cannot fix a bad entry directly, which the "never present as certainty" principle is meant to absorb. Where: docs/strategy/Scope & Constraints.md, data/species/.

2026-06-27 · Offline is the default assumption, not a mode

What: Every read path serves from the local store first; the network is an enhancement. Why: Watering happens in bathrooms, basements and balconies. Building an explicit "offline mode" would mean two code paths and one of them would rot. Alternative considered: online-first with a cache, rejected after the first hallway test. Where: implementation/data-layer.md, every feature doc.

2026-06-20 · Adopted Groundwork as the work model

What: The project runs on phases, modes and rituals, with a derived dashboard at /system. Why: Two prior attempts drowned in stale docs and a README nobody trusted. Making the dashboard derived means it cannot lie, and distill-and-delete keeps the working set small. Where: CONTRIBUTING.md, CLAUDE.md, the whole docs/ tree.