Tend T E N D

The product replaces the free-text box that every journalling app defaults to with a fixed vocabulary of eight words. That constraint is the whole product: it is what makes a year of a relationship renderable as a single field of colour, and it is what a neighbouring app cannot copy without adopting the same limitation.

The words are weather. The first vocabulary was a set of first-person verdicts (close, warm, secure, steady, off, distant, tense), and its bad end pointed at a person. Your partner reads your word, so distant landed as an accusation, and people under-logged exactly the days the app exists to catch. Weather moves the claim into the space between two people, which neither of them owns: distant is something a person is; fog is something that happens to a place.

The colours are data design, not a palette. Seven rungs run as one monotone ramp, bright to dark and warm to cool, with adjacent bands an even ~1.16 apart in luminance, so greyscale order equals ladder order and the scale reads with no colour vision at all. clearing sits off-spectrum on purpose: it is a direction rather than a rung. Every fill and ink is identical in the light and dark themes, and an executable check asserts that every band stays clear of the empty tile.

The recap is a warm paragraph about a couple's last week, month or year. It is also, structurally, a report full of quantities: an agreement rate, a trend against the prior window, the weekday that ran roughest, how a dip was recovered from. A language model asked to produce that paragraph will happily produce the quantities too, and it will sometimes be wrong.

Being wrong about a number in a spreadsheet is a bug. Being wrong about a number describing someone's relationship is something worse. The line written into the source is the design constraint:

A model that computes hallucinates relationship claims.

So the system splits in two. insights.ts is 315 lines of pure arithmetic, with no Firestore, no clock and no model, and it is the single source of every number. brief.ts turns the digest and those facts into a plain-text brief, and recap-flow.ts hands it to the model with a Zod output schema. The model's only permitted job is to phrase what the brief already says.

The discipline shows up in what the engine refuses to say. Every insight carries a hasEnoughData flag, so a thin period stays silent rather than reaching. GapDirectionFacts, which partner held the warmer word on days they diverged, deliberately ships without a leader field, so no interface downstream can ever rank one partner above the other.

Strip the subject matter away and the recap path is an extract-transform-load job with a hard payload budget at the end of it. Extract: seven Firestore reads issued in parallel: the couple document, logs range-queried on FieldPath.documentId(), gratitudes, moments and flags range-queried on date, plus the events and profiles collections. The prior equal-length window is fetched separately to give the convergence trend a baseline.

Transform: a pure reduction into a compact object with explicit caps. The sampling rules are where the domain leaks into the pipeline in a good way. The window is cut into even buckets rather than read from the front, so a recap is not just a summary of the first three days, and each bucket's pick is scored for substance and notable days, with both partners guaranteed a voice. Flag snippets prefer resolved ones, because the recap's register is "came back from it", not re-litigating the argument.

My favourite function in the file exists purely to refuse to pass data along. streakAsOf() will not hand the model couple.currentStreak, because that counter does not decay. When the streak cannot be known it returns undefined and the streak is left out of the brief entirely, rather than 0. Telling a couple their streak is nothing when it was twelve is its own kind of wrong answer.

Firestore has no schema. src/types/models.ts is the schema, and firestore.rules is the enforcement, because Cloud Functions run on the Admin SDK and bypass rules entirely, so the rules file is the authorisation layer for every client write in the product.

Writing it as a data-modelling exercise rather than a checklist is what makes it short. The strongest rules are the ones expressed as constraints on a diff rather than on an identity: a member may write to the day's log only if the set of changed keys in the entries map is exactly their own uid. The same shape is reused for resolving a flag.

The pairing claim is expressed the same way, and never became a Cloud Function. A second partner may join a couple only if the members array currently has one entry, the proposed array is exactly the existing member plus the caller, and three get()s against the invite prove it is pending, matches the couple, and has not expired.

The threat model is written into the file, your own partner, not a stranger, along with the loosening that model licenses. That is the part most rules files leave implicit, and it is the part a reviewer actually needs.

A subscription for a couple is not a subscription for a user, and almost every bug in this area comes from that gap. One partner pays; both must be entitled; either may lapse; and the person who did not pay must never lose access because the person who did let their card expire.

The webhook is deliberately conservative about what revokes. EXPIRATION does. CANCELLATION only means auto-renew is off, and BILLING_ISSUE opens a grace period; revoking on either would lock out a paying customer. Events carry a timestamp and are checked for ordering, because a renewal overtaking the cancellation before it shows up as a customer randomly losing access.

The entitlement is written in two places: the user document, and mirrored onto the couple. That mirror is what makes "one plan covers both of you" literally true rather than aspirational. Revoking clears the couple mirror only if the lapsing user is the recorded purchaser. Otherwise an expiring ex-subscriber would knock out their partner's own live subscription.

Another function exists solely because of onboarding order. Someone subscribes while still solo; their partner joins days later; the couple document has no entitlement and no webhook is due until renewal. mirrorPlusOnPairing fires on the couple document updating and closes that window. That is the main path, not an edge case.