2026–Present
PlantPal+ — Full-Stack Daily Wellness & Plant-Care Platform
- 2026–present
- in active development
- typescript · expo · express
- repo
- unit-tested · CI
- 1 star
- head 1249c82 · 2026-09-04
- ci: passing
- Joseph Wright of Derby, Two Girls Dressing a Kitten by Candlelight, c. 1768–70 — public domain, Wikimedia Commons
Cross-platform app unifying plant care, fitness, and nutrition in one daily dashboard with streaks, reminders, and cloud sync.
- functional requirements
- 228
- user stories
- 119
- use cases
- 89
Problem
Plant care, fitness, and nutrition apps each implement the same daily loop — schedule, remind, log, streak, reflect — separately. PlantPal+ unifies all three domains in one loop, implemented once, across a mobile app, a web app, and a REST API.
The engineering problem underneath is duplication: when a watering calculator or a calorie formula is reimplemented per platform, the implementations drift. This project treats a single shared domain implementation, with bit-for-bit agreement between server and clients, as a hard requirement rather than an aspiration.
Approach
The codebase is a TypeScript monorepo on npm workspaces: packages/shared holds the domain logic used identically by all clients — the watering schedule calculator, the Atwater energy identity, and Mifflin-St Jeor BMR are each implemented once. apps/api is an Express + TypeScript REST service on PostgreSQL, apps/web is React + Vite, apps/mobile is React Native with Expo.
Specification came before implementation. Phase 1 produced 36 documents: 228 functional requirements, 307 business rules, 111 NFRs across 13 quality attributes, 119 user stories with Gherkin acceptance criteria, 89 fully-specified use cases, and 119 Mermaid diagrams. Phase 2 added system architecture, an OpenAPI 3.1 spec, sequence diagrams, and ADRs; Phase 3 mapped artifacts back to requirements for traceability.
Auth uses JWT with a 32+ character access secret, a refresh-token flow, and a 30-day account deletion window that blocks session renewal. Sync is an append-only event log: only three operations queue offline (watering events, workout records, meals), each carrying a client-generated UUID idempotency key that the server upserts by — conflict-free by construction, with no CRDTs or last-write-wins. All other operations require connectivity explicitly.
TypeScript monorepo: React Native (Expo) mobile app, React + Vite web app, Node.js/Express REST API on PostgreSQL; node-cron reminder engine; 11-table JWT auth service with a custom migration runner; GitHub Actions CI.
Unit-tested scientific domain layer (Mifflin-St Jeor/TDEE energy models, workout energy/1RM/volume, species- and season-aware watering intervals); offline-light sync via an append-only event log with client-generated UUID idempotency keys.
spec phase
36 docs · 228 FRs
shared domain pkg
one impl, all clients
express + postgres
JWT · event log
web + mobile
React · Expo
ci: 307 tests
Node 20.11 + 22
deploy
Pages live · Render
Decisions
- Spec-first, then code
- Writing 36 requirements documents before implementation is an unusual amount of specification for a project of this size, but it made the rest checkable: algorithm test vectors come from the specs, and Phase 3 traceability maps artifacts back to requirements. The 53 shared-package tests verify the domain formulas against those spec-derived vectors.
- One domain implementation, three clients
- The watering calculator is species-, season-, light-, and pot-aware; its canonical test vector is 7 × 0.80 × 1.10 × 0.80 × 1.00 = 4.928, rounded to 5 days. Because the calculator, Mifflin-St Jeor, and Atwater live only in packages/shared, server and clients agree bit-for-bit — there is no second implementation to drift.
- Offline sync without CRDTs
- Rather than solve general conflict resolution, the design narrows the offline surface to three append-only operations, each idempotent via a client-generated UUID key the server upserts by. That makes sync conflict-free by construction. Everything else explicitly requires connectivity — a documented constraint, not an accident. 24 mobile tests cover the offline outbox.
- Adversarial audits as a quality gate
- Two adversarial multi-agent audits were run against the system; they found 6 critical and 4 major defects, all fixed. Combined with CI running typecheck plus the full 307-test suite on Node 20.11 and 22 for every push and PR — with a PostgreSQL service container for integration tests — regressions have to get past both.
Evidence
| Functional requirements | 228 (+ 307 business rules, 111 NFRs) |
|---|---|
| Spec documents (Phase 1) | 36 |
| Use cases / user stories | 89 / 119 (Gherkin acceptance criteria) |
| Automated tests | 307 — 53 shared · 158 API · 24 mobile · 72 web |
| Audit defects found & fixed | 6 critical + 4 major |
| Seeded Indian catalogue | 94 plant species · 180 foods |
Outcome
Today the web app is live on GitHub Pages, and the API deploys via a one-click Render Blueprint — the free tier sleeps after 15 idle minutes, so a keep-alive via UptimeRobot or a GitHub Actions /healthz ping every 10 minutes is documented. Mobile EAS builds are pending. All 307 tests, including the 12-test auth integration suite against real PostgreSQL, run in CI on every push and PR.
The gaps are stated rather than hidden: growth-log photos are links, not uploads, because there is no object storage; no mail provider is wired, so password reset, email verification and the account-deletion notices have tokens and rules but no delivery; the erasure sweep removes rows but has no stored objects to erase; and a reminder whose push fails is not retried. Phase 6 — deployment — is in progress. MIT licensed.
Next
Finish Phase 6 (deployment), including EAS builds for mobile
Wire a mail provider for password reset, email verification and the account-deletion notices
Add object storage for growth-log photos (links only today)
Add retry for reminders whose push notification fails
Next: the other case files
- Warden
Gives a Python package an allow, warn or block verdict — from what its code does, where it came from, and what is known about it.
- Proactive Feasibility Scheduler
An evaluation study of ML-based GPU-cluster job scheduling — and a proven negative result.