Mildred's page — what it should become (Sam's vision, 2026-06-03)

Captured from Sam's voice note. The page (/work · mildred.html) is currently
"naked": two-way thread + scoped card list (1 card after strict default-deny) +
business calendar + a "shared cards" section. Sam wants it to do MORE. This is the
build plan + the decisions needed before each piece.

What Sam likes (keep)

• The two-way texting / thread (Ping Sam ↔ her replies). "The way you have the texting working over there is cool." Keep it central.

What he wants added (his words, structured)

1. Shared BRIEFINGS — Sam curates what she sees

"The bottom should be briefings that I'm allowing her to see — I want the ability to
check off certain briefings when we create them if I want her to know about it, so
she knows what I'm working on."
- Mechanism: each briefing gets a "Share with Mildred" toggle (on Sam's side). Marked
briefings appear in a Briefings section on her page (read-only). Default = NOT shared.
- Build: an allow-list (Worker KV or a column in a sheet) of Mildred-visible briefing
slugs + a toggle on Sam's home/briefings page that writes it + a section on her page that
reads it (referer-gated or her key, NOT the master).
- Decision needed: where Sam toggles — (a) a "share" button on each card in the
briefings list, or (b) a checkbox when a briefing is generated. (Recommend a.)

2. BOOKINGS (STR) ↔ POS sheet — two-way

"The bookings / STR will probably be connected to the POS sheet for whatever we have
over there… the bookings and the sheet will work hand-in-hand — you can fill it out on
the website for the bookings OR on the sheet itself, and they're both pulling from one
another."
- Mechanism: a bookings surface on her page (and a web form) that reads AND writes a
bookings/POS Google Sheet — bidirectional, so a booking entered on the site shows in the
sheet and vice-versa.
- Decision needed: WHICH sheet is the bookings/POS source (ID)? Does it exist yet, or
do we create it? What fields define a booking? (This is the biggest piece — real
read/write sheet integration.)

3. OBLIGATIONS — scoped to her

"The obligations will be ones that — if you connect it — pertain to her… see if it's
gonna be a sheet."
- Mechanism: show only the obligations relevant to Mildred (e.g. vendor/ops payments
she handles), filtered from the Monthly Obligations sheet — never family/personal money.
- Decision needed: which obligations are "hers"? (a lane/tag on the obligations sheet,
or a hand-picked list.)

Build order (recommended — smallest/most-contained first)

1. Shared briefings — most self-contained, no new sheet, high "she knows what I'm
   working on" value. Build first once the toggle mechanism is picked.
2. Obligations-scoped — medium; needs the "hers" definition.
3. Bookings ↔ POS sheet — biggest; needs the sheet + two-way sync design. Do last,
   ties into the broader STR/POS work.

Privacy guardrail (unchanged)

Everything on her page flows through HER scoped key / referer-gated scopes, never the
master OPS_READ_TOKEN. New sections (briefings, bookings, obligations) must each be
server-side scoped the same way — never ship the full briefings list / full obligations /
full bookings to her browser. See docs/MILDRED_SERVER_SCOPING.md.