How 恋爱积分簿 is built

The stack, in one breath

There is no build step, no framework, and no server the couple owns. index.html carries every style and every screen's markup; app.js carries all 6,000 lines of behaviour. GitHub Pages serves both as static files. Everything dynamic happens in two places: Supabase Edge Functions (Deno) holding the business rules, and Postgres holding the data.

That shape is deliberate for a couple's app that must outlive the enthusiasm of whoever maintains it. There is nothing to keep running, nothing to patch, and no dependency that can rot: open the repo in five years, and node --check app.js is the entire toolchain.

How a request travels

The security model is a shape, not a checklist. This is that shape.

There are two ways out of the browser and into the database, and they are deliberately not equal. Both carry the same public key and the same user session; what differs is what each is permitted to do at the far end.

This was tested by attack rather than by reading the policy. A genuine signed-in session was used to PATCH a row directly: the request answers HTTP 204, which looks like success, and changes nothing. Reading the value back afterwards is the only way to tell.

One write, traced end to end

partner A taps 说早安 +5. Here is everything that happens, in order.

1. The tap. A category button calls Data.addEntry(). The client computes todayStr() and monthKey() from the device clock — never toISOString(), which is UTC and rolls a day early for a UTC+8 couple.
2. Path translation. snFetch('/entries', {method:'POST'}) rewrites the ServiceNow-era path onto a function slug: …/functions/v1/entries. Thirty such translations exist so none of the call sites had to change during the migration.
3. Headers. The publishable key identifies the project; Authorization: Bearer carries the user's access token. Both are needed — the key alone gets you an anonymous session that RLS shows nothing to.
4. Preflight. Because apikey is a custom header, the browser sends OPTIONS first. Every function answers it through a shared wrapper; when that was missing, every request failed with nothing but "Failed to fetch".
5. Identity. Inside the function, getCaller() validates the JWT and reads profiles for the caller's match_id and char_id. No match_id ever arrives from the client — it is derived, so a forged one is not a thing that exists.
6. The insert. The service-role client writes the row with match_id from step 5 and the date from step 1, plus a snapshot of the category's name, icon and point value. The snapshot is why deleting a category later doesn't corrupt the history.
7. The response. {id, success:true} — the identical shape the ServiceNow resource returned, which is the reason app.js needed no change here at all.
8. The other phone. Nothing is pushed. partner B's app sees it on its next poll, and if partner B is in the pet room right now that is within four seconds.

The data model

Twelve tables. One couple. Two people who must see the same numbers — except where they must not.

Shared or personal — the distinction the whole app turns on

Two people must see byte-identical numbers, or the app is lying to one of them. But a handful of things are genuinely individual, and getting that wrong in either direction is a bug: share a bag and one partner spends the other's reward; split the pet and they are no longer raising it together.

The frontend

6,063 lines of app.js, 4,665 of index.html, no build step.

All state lives in one object, S. All server access goes through one object, Data, which has a ServiceNow-era shape the migration deliberately preserved — and a localStorage twin behind the same methods, which is what Demo mode runs on. Every screen is markup already present in index.html, shown and hidden rather than constructed.

What is cached, and why that matters

GET /photos used to return full base64 images, so pulling it on every home refresh re-downloaded megabytes on mobile data. The rule that came out of that is still in force even though photos are now signed URLs:

• History and summaries may refetch freely — they are small.
• Letters and photos load once per session and live in S. Only views that report exact counts force a reload.
• The cache is invalidated in Data.init(), because boot() runs a refresh before login — which would otherwise latch the cache onto an empty dataset for the whole session.
• A cached count must be told when it changes. Opening a letter updates the in-memory object, so the letters list re-renders — but the home card's 「1 封未拆」 badge does not, unless the open path explicitly re-renders it too. Nothing refetches to correct it.

Two versions, because HTML caches and JS does not

app.js is always fetched fresh; index.html — which carries every style and all the markup — can sit in a phone's cache for days. Running new JS against old HTML produces unstyled elements and invisible layouts. So HTML_V in app.js must equal the app-html-v meta in index.html; the app compares them on boot and reloads once, cache-busted, when they differ. The retry flag is keyed by version, or one stale flag would block every future release.

Live sync between two phones

There is no websocket. There is a poll that knows when to care.

Measured against the real backend, a config poll is small but takes about a second, so "instant" does not exist here — a couple of seconds is the floor. Rather than poll fast all the time, the gap adapts to whether anything is happening:

It is a self-rescheduling setTimeout, not setInterval, so the gap can change between ticks without tearing the timer down. Change detection is an order-independent fingerprint of the room — _roomSig() — rather than a timestamp, so two phones that disagree about the clock still agree about whether anything moved.

Identity and pairing

Two accounts, one couple, and a six-digit code that exists for about a minute.

1. Partner one registers. A matches row is created with a random six-digit pair_code, an auth.users record with a hashed password, and a profiles row claiming char1.
2. They share the code. Out of band — spoken, messaged, whatever.
3. Partner two registers with it. The code resolves to the existing match, so the second profiles row joins it as char2. A unique (match_id, char_id) constraint means the slot cannot be taken twice.
4. From then on, identity is derived. Every request carries only a session token; the function looks up match_id and char_id from profiles. The client never sends them, so it cannot lie about them.

Supabase Auth requires an email address and these usernames are not emails, so one is synthesised deterministically from the username. That detail caused the migration's last bug: it must be derived from the stored username, because cs and partner A hash to different addresses — and ServiceNow's queries had been case-insensitive for years, so a lowercase login that had always worked started reporting "account does not exist".

Settlement — the one destructive operation

Everything else adds. This is the only thing that sweeps the board.

A 月末结算 archives a month: it writes a monthly row holding each partner's total and outcome, stamps monthly_id onto exactly the entries it counted, and clears every reward's claim flags so both partners can claim again next round. Afterwards those entries no longer appear in the live score — they are history.

• It guards on "is there anything to settle", not "has this month been settled". That lets a couple settle several rounds inside one calendar month, while a partner's duplicate tap still safely no-ops — once the entries are archived there is nothing left to find.
• It settles per month, but the client groups first. The frontend takes whatever /entries returns, groups by each entry's own month, and settles once per group — so a month that was missed becomes its own history row instead of being merged into today.
• The current month is never swept automatically. Past months settle on their own; the running one is opt-in, defaulting to off when older months are pending.
• The annual recap needs the archive. Settling hides entries from the normal call, so ?year=YYYY exists to return everything for a year, settled included — otherwise 年度回顾 would only ever see the current unsettled month.

The endpoints

27 functions. ServiceNow needed 41 resources for the same surface, because it wanted one per path and method.

Rules the design encodes

Each of these is in the schema or the function layout because forgetting it once caused a real bug.

• Unsettled, never "this month". entries.monthly_id IS NULL is the live score — not a date filter. A month filter once hid a whole month of entries the instant the calendar rolled over without a settlement, and the score silently read zero; the couple thought their data had been deleted. A partial index is built for exactly this query.
• Dates come from the phone. The server is UTC. Every function takes date/month from the request and only falls back to its own clock if absent.
• The pet can only grow. pet_exp is a high-water mark the server refuses to lower, because EXP is derived from activity that can shrink — deleting a photo, or settling a negative month. Adoption is the one legal reset, signalled by pet_base arriving alongside it.
• Snapshots outlive their source. bag keeps the item's name and icon; entries keeps the category's name and points, copied at write time. Deleting a shop item or category clears the link (ON DELETE SET NULL) without erasing history — which is also why Postgres had to be taught to allow that delete at all, since ServiceNow never blocked it.
• One implementation per rule. The unsettled-score sum is a single shared function called by both shop-buy and bag-claim, because when those two drifted apart the UI showed a purchase as affordable and the server rejected it as insufficient.
• Derive rather than store, but watch the floors. Badges, moods and levels are computed from existing data so they cannot drift. The exceptions are values that must never go backwards, and anything that needs a baseline — the pet stores one at adoption so it doesn't hatch at max level from months of prior history.