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