# Handoff — hartlingowners > Newest first. What landed, what's in flight, what's next. ## 2026-09-10 — direct SSH to client servers is CLOSED — go through host Logging into a client server directly (`ssh master_…@…`, any key in `~/.ssh`) no longer works: the owner's keys were removed from every client server, and host now logs in with keys of its own. Direct logins as the platform's privileged account were leaving files the site's own WordPress could not write. For any change to a LIVE site use host — see "For Claude: Changing a LIVE client site" in `/srv/CLAUDE.md`: `srv-gw live-sites` · `srv-gw live-wp --project -- ` · `srv-gw live-patch` · `srv-gw live-purge`. Older entries below that show an `ssh master_…` login are superseded. If something is refused, stop and ask rian — do not look for another way in. ## 2026-09-01 — v0.38.0: dates hidden, board bios erased **347 tests green.** Both asks from rian after Joan's first look. **The two board bios erased.** "Stan Hartling" and "Stephen Sisca" were sitting in the shoreclub Trash — they came from board data, not documents. Deleted for good, **and their files removed from storage**: `Document.delete()` alone orphans the file, which the app's own empty-trash view also does (worth fixing there one day). Shore Club trash is now empty. **Document dates hidden — `SHOW_DOCUMENT_DATES`, default off.** They are WordPress POST dates: when a file was put on the old site, not when the document is from. That is why the 2023 AGM minutes carry 21 Apr 2026, and it is the same wrongness that produced the mis-named groups. Hiding the row text alone would not have been enough. **The year filters are built on the same value**, so "2023 AGM Minutes" would still have appeared under a 2026 heading — the exact thing hiding the dates was meant to stop. So everything date-derived is off together: the row date, the detail date, the "Year" rail group, and the `?group=date` / `?when=` modes, which the view now refuses even when typed into the URL. The rail's category links used to route through the date view; they now go to the flat list. **Hidden, not discarded.** The dates stay in the database and in the staff edit form, so they can be corrected. One environment variable (`PORTAL_SHOW_DOCUMENT_DATES=1`) brings the whole date UI back when documents carry real dates of their own — pinned by a test that asserts exactly that. Five existing tests covered the date grouping and year filters; they now run with the setting on, so the feature keeps its coverage rather than being quietly abandoned. **Owner view now:** shoreclub 54 · sands 147 · palms 146 documents, no groups, no dates anywhere, no Year rail. **Still open:** force a password reset for every owner before launch · OCR the ~70 scanned documents · DigitalOcean setup. And, when real document dates exist, decide whether to populate `published_date` properly and turn the date UI back on. ## 2026-09-01 — v0.37.0: documents put back to match the live site **341 tests green.** Joan's first look went badly: the library showed a group called "2025 AGM documents" containing the 2023, 2024 AND 2025 AGM minutes. Reads as the site having its facts wrong, which is fatal for trust on day one. **The titles and dates were never the problem.** Diffing every document against WordPress by its stored `wp_id`: shoreclub 1 title wrong and **0 dates**, sands 1 title, palms 3 titles + 2 dates. What was wrong was **grouping** — the importer bundled every document sharing an upload date and named the bundle by guesswork. 77 groups across the three sites, several misnamed (the 2021-07-01 batch was "2021 AGM documents" but held the 2020 AGM). WordPress has no such concept; the groups were invented here. All dissolved, per rian: no grouping for now. New `resync_from_wordpress` command (file-based export, like the other importers — the portal never connects to the WordPress database). Metadata only; stored files are never opened or moved. Snapshots of the previous state are in `data/backups/-before-resync-*.json`. **Caught before it shipped:** copying WordPress titles verbatim would have put `&` back on screen in two Palms titles — the double-escaping this project already fixed once. Titles are `html.unescape`d, and a test pins it. **Three more real faults found while reconciling, each invisible until the sets were compared rather than the pages eyeballed:** 1. **"2026 AGM Minutes" and "Strata Financial Statements AGM May 2026" were in the portal's Trash** while published on the live site — the two NEWEST documents, the ones an owner looks for first. Restored, files intact. (Found because rian asked where the 2026 minutes were; a set-level comparison would have caught it without being asked, and now does.) 2. **20 junk documents on sands** that exist in no WordPress record: 17 with 32-character hex titles (filename hashes from a failed import) and 3 duplicates ending "(2)". Moved to Trash — reversible — not deleted. 3. Three sands documents that appear on the live site but not here turned out to have **no file attached in WordPress at all**; the importer was right to skip them. Not a gap. **Final state:** shoreclub 54 · sands 147 · palms 146 documents, **0 groups** anywhere, titles and dates identical to the live site (a fresh dry run reports zero differences on all three). **One to watch:** on the first pass a shoreclub title reported as changed but did not persist; the same command re-run applied it, and sands/palms persisted first time. Cause not identified. Every site was re-verified with a fresh dry run afterwards, which is the check that would catch a recurrence — worth keeping that verification step in any future resync. **Still open:** two board bios ("Stan Hartling", "Stephen Sisca") sit in the shoreclub Trash rather than the library — they came from board data, not documents; confirm they should stay out. Plus the standing pre-launch items: force a password reset for every owner, OCR the ~70 scanned documents, DigitalOcean setup. ## 2026-08-28 — v0.36.0: false sign-in dates fixed, WP history imported, security pass **335 tests green**, three instances deployed, `security-audit` 0 critical. Triggered by rian believing the site had been broken into. It had not — but three genuine weaknesses came out of investigating it. ### The false "last signed in" (the thing that caused the scare) `last_login` is stamped by Django for ANY call to `login()`, including request-less server-side ones made while verifying owner-facing pages during development. The owners page read that field, so accounts that had never once been signed into showed a current date — and rian reasonably read that as an intruder using Joan's account. - `LoginEvent.source` (`web` / `internal` / `wordpress`), migration `0004`, which also backfills every existing row. - **The test that mattered:** my first implementation keyed on `request is None` and was WRONG — Django's test client passes a bare `HttpRequest()` with empty META, so the request exists and tells you nothing. The real discriminator is what production actually showed: **no IP and no user-agent**. A browser always sends both. - The owners page and the "Active" filter now annotate `last_seen` from LoginEvent and ignore `last_login` entirely. ### WordPress sign-in history imported WordPress core keeps no last-login date. **Wordfence does** — `wp_wfLogins`. New `import_login_history` command (file-based, like `import_wordpress`; the portal never connects to the WordPress database). Imported 165 / 437 / 197 events. Unmatched names are accounts deleted from WordPress whose Wordfence history survives — verified, not guessed. Real activity, first time this has been visible: **shoreclub 32 of 49 have ever signed in, 8 in the last year · sands 72 of 130, 14 · palms 40 of 138, 6.** Joan's genuine last sign-in on palms was **2021-03-11**, not 2026. ### Security pass — three real gaps closed 1. **No throttling on the sign-in form.** Downloads were rate-limited since the start; the login form was not. Every owner password is the one migrated from WordPress, and those sites were not under our control — an unthrottled form is the cheapest route to the documents. `accounts/throttle.py`: 10 failures per account+address and 30 per address in a sliding 15-minute window, built on the LoginEvent rows that already existed (no cache server). Refused **in the backend**, so a correct guess while locked out still fails; the page says "wait", not "wrong password". 2. **Cross-tenant file visibility.** Every instance mounted the whole `data/` directory, so the Palms container could list the Sands' documents. Three separate condo corporations — the boundary existed in the database but not on disk. Each service now mounts only `./data/` plus a read-only `import`. Verified live: each container sees only its own tree. 3. **No HSTS.** Added (1 year, includeSubDomains, no preload — preload covers the parent domain and is not ours to declare), plus `Referrer-Policy`. `X_FRAME_OPTIONS` was left at SAMEORIGIN **deliberately**: the detail page frames its own PDF preview, and tightening to DENY would have broken it — caught before deploying, and now pinned by a test that says why. Verified clean: anonymous access to every document/board/staff URL redirects to login; private files unreachable by any path; `DEBUG=False`; distinct SECRET_KEY per instance; separate media roots; secure+httponly cookies; downloads carry `X-Robots-Tag: noindex` and `Cache-Control: no-store`; the legacy WordPress copies bind only to `172.17.0.1` and hold no Caddy route. ### ⚠ Findings on the LIVE (.com) WordPress sites — rian's to act on - `thesandsowners.com/wp-content/uploads/…/TheSandsAtGraceBay_Newsletter2018.pdf` returns **200, application/pdf** with no authentication. - Palms upload PDFs now return **302** (protected), but Google holds indexed entries whose titles were taken from the documents' contents — including a name with an age and a residential address. Protecting the file does not remove the index entry. - **Order matters:** block access first, then request removal in Search Console. Adding `robots.txt Disallow` first stops Google re-crawling and seeing the block, which can freeze the entries in the index instead. - `thepalmsowners.com` was serving a **"Database connectivity issue"** page during this check. The rebuild does not have this failure mode: documents have no public URL at all, are served only through an authenticated view, and carry noindex headers. ### Still open - **Force a password reset for every owner at launch** — migrated hashes come from sites with a known compromise. This is the largest remaining risk. - `shoreclubowners.demoing.info` currently has `auth_enabled: false` (no shared-password gate). Deliberate for Joan's access; confirm before launch. - OCR for the ~70 scanned documents with no text layer · DigitalOcean setup. ## 2026-08-28 — v0.33.1: the shine, and walkthrough revisions **319 tests green**, deployed, audit 0 critical. TOUR_VERSION 2 → 3, so the walkthrough re-offers itself to anyone who has already seen it. **The shine is the wavefront, not an imitation of it.** rian asked for the sweep to "ripple through the logo area" as it crosses the middle of the screen. The trick that makes this exact rather than hand-tuned: `background-attachment: fixed` positions the highlight against the **viewport**, so giving it the same angle, size and start position as the sweep's mask makes the logo block a window onto the same moving edge. No timing to guess and nothing to re-tune at other window sizes. JS reads the sweep's OWN delay and duration off the animation object and hands them over as `--shine-dur`/`--shine-delay`, so the quicker entrance sweep and the slower rotation both stay in step for free. Where `background-attachment: fixed` is unsupported (notably older iOS Safari) it degrades to sweeping the block on its own — still a shine, just not aligned. Brightness `rgba(255,255,255,.11)`, halved from .22 after rian saw it live. **One function now starts a sweep.** `sweepIn(layer, isIntro)` adds the classes, triggers the shine, and RETURNS the length, which removed the last hard-coded `3600` from the rotation loop. The shine cannot fall out of step with the sweep because it is handed the sweep's own numbers. **Walkthrough (5 changes rian asked for):** - "What staff can do" merged into the owner-view switch step — one idea, one step. Still 12 steps: one merged away, one added. - The library / board / owners intros now point at their **nav item** instead of spotlighting a whole region. - New step after reordering: adding a board member (`#board-add`). - Nav links gained `id="nav-documents|nav-board|nav-owners"`. Stable ids rather than `a[href=…]` because the steps live in a **single-quoted** `data-steps` attribute — an attribute selector would need a quote character that closes either the attribute or the JSON string. **A step may now carry `targets` (a list), and the engine picks the first one actually LAID OUT.** Pointing at the nav introduced a phone bug: the nav folds into the hamburger, so `#nav-documents` still EXISTS and the old existence-only check would have spotlit a zero-sized box in the corner. Each nav-pointing step falls back to what it used to target (`#browser`, `.board-grid`, `.search-field`), so nothing is lost on a narrow screen. Pinned by `test_a_step_pointing_at_the_nav_offers_a_fallback`. **Next:** OCR for the ~70 scanned documents with no text layer · DigitalOcean production setup. ## 2026-08-28 — v0.32.0: entrance once per session, no white box, half the hold **318 tests green**, deployed, audit 0 critical. **The white box.** rian: *"I see a white box, then it fades into the white box."* `.login-card` carried `background: var(--surface)`, and during the hold the card is only as tall as its brand block — so a white card sat on the ground while the brand block (which is what fades) was still at opacity 0, and the logo appeared to fade INTO it. The white belongs to the form, not the frame: background moved to `.login-body`, and the card's box-shadow moved into the `login-open` keyframes so the frame arrives with the form rather than before it. Now the ground is untouched until the whole logo box fades up out of it. **Half the hold:** `--hold: 1s → .5s`. Because the other beats are `calc(var(--hold) + …)` they followed on their own — logo 0→500ms, panel 680→1180ms, sweep 700→1500ms. That is the payoff for the property; nothing else was edited. **The entrance now plays ONCE per browsing session.** It is a greeting, and it was standing between someone and the form on every back-button return and every re-render after a mistyped password. A `sessionStorage` check sets `no-entrance` on ``; CSS cancels all three beats and the scene skips the intro sweep. **The check must sit in the HEAD** — the beats are CSS animations that start at first paint, so deciding any later would flash a frame of the opening state before it could be cancelled. `sessionStorage` is the right lifetime (per tab, cleared on close) and the access is wrapped in try/catch, so private mode just plays the greeting rather than breaking the page. Verified in a real browser session: visit 1 animates and stores the key; visit 2 has `no-entrance`, both animations `none`, card already open, photograph already shown. This also closes the `form.errors` question raised in v0.31.2 — no separate case needed. **Next:** OCR for the ~70 scanned documents with no text layer · DigitalOcean production setup. ## 2026-08-28 — v0.31.2: the entrance holds on the logo **317 tests green**, deployed, audit 0 critical. rian found v0.31.0 "too fast" and asked for the logo to fade in softly over about a second and be held there, with the rest of the entrance unchanged behind it. **One property drives all three beats.** `--hold: 1s` on `main.wrap.login-page`; the logo's fade IS the hold (`animation: login-mark-in var(--hold)`), and the other two are `calc(var(--hold) + …)`, so changing the hold moves the entrance together instead of leaving three literals to drift. Measured on a real load: logo 0→1000ms, panel 1180→1680ms, sweep 1200→2000ms. The rise was cut 9px→5px — over a full second that much travel reads as drift rather than a fade. The JS promote-time is now read off the animation object rather than repeated as a constant. **The hold exposed a mask-geometry bug that had been there all along.** The sweep's "hidden" start was not hidden: at `mask-size: 300%` and start position `100%`, the viewport maps onto 66.7–100% of the gradient, which is only fully transparent from 78% — so the left third of the screen showed a band of the incoming photograph *before* the sweep ran. At the old 200ms delay nobody could see it; holding on the logo for a second made it obvious, and it had been flashing on every rotation transition too. Start moved to `120%` (past 78%) plus `mask-repeat: no-repeat` so the region beyond the mask stays transparent rather than tiling back to opaque. Pinned by `test_the_sweep_starts_completely_hidden`, which computes the gradient fraction rather than asserting a magic number. **Verification method that finally worked — seek, don't sample.** Screenshots under `--virtual-time-budget` cannot time CSS animations (established in v0.31.0). The reliable technique: load the page, **pause every animation and set `currentTime`** to the wanted moment, then screenshot — deterministic and clock-independent. One trap: the promote timer is not an animation, so pausing animations does not stop it; once it fired the layer went `is-front` and every seeked frame showed the finished photograph. Stubbing `setTimeout` for delays ≥1s held it off, and only then did the left-edge band become visible. **Note for rian (not implemented, his call):** the entrance now runs on EVERY render of the sign-in page, including the re-render after a wrong password — a 2s wait when someone is mid-task. Skipping it when `form.errors` is set is a few lines if wanted. **Next:** OCR for the ~70 scanned documents with no text layer · DigitalOcean production setup. ## 2026-08-28 — v0.31.0: the sign-in entrance **316 tests green**, three instances deployed, audit 0 critical. rian's ask: on first load, logo first on solid colour, then the sign-in expands, then the first photograph sweeps in — **"not more than a one second process"**. **Three beats, and the design was already half-built.** `.login-brand` is `var(--masthead)` — the same colour as the scene's ground — so before a photograph arrives the brand block reads as a mark floating on solid colour, not as a panel. That gave beat one for free. - **0–400ms** `.login-brand` fades and rises (`login-mark-in`). - **180–680ms** `.login-card` opens by animating its **grid row** `auto 0fr → auto 1fr` (`login-open`). A row, not a scale, so the form unfolds instead of being squashed; and because the card is only as tall as its brand block to start with, there is never an empty white box on screen. Padding moved to a new `.login-body-inner` so the row can actually collapse to nothing. - **200–1000ms** the first photograph sweeps in on the SAME mechanism as every later transition, just quicker (`.is-intro`: 200ms delay + 800ms), then hands off to the 3600ms rotation sweep. **The opener choice moved to the server** so the photograph can be **preloaded in the head** (`rel="preload" as="image" fetchpriority="high"`). The entrance cannot spend its budget waiting for JS to decide which file to ask for. `opening_url()` replaces `opener_urls()`; the template sends `data-opening` and the shuffle just honours it. Real fetch measured 0.12–0.17s for the 135–360KB scene JPEGs, so the preload comfortably covers the 200ms delay. **Two real bugs found while verifying, both invisible to a green suite:** 1. **Reduced-motion lost the cascade.** The `prefers-reduced-motion` override sat ABOVE the new rules; a media query adds no specificity, so the later rule won and the entrance still animated for someone who had asked for stillness. Moved below, and pinned by `test_stillness_wins_over_the_entrance`. 2. **`load()` unblocked without reporting readiness.** The 2.5s guard resolved even when the bytes had not arrived, so the sweep animated an empty layer and popped the image in afterwards — the jolt again, in a new costume, on slow connections. It now resolves with WHETHER the pixels are there (`img.complete && naturalWidth`, so a decode-stalled hidden tab still counts as ready). The intro shows plainly instead of sweeping nothing; the rotation skips that photograph entirely. **Measurement note — virtual time cannot time CSS animations.** Two filmstrips captured with `--virtual-time-budget` showed frames that could not be real (a 1500ms frame in an 80ms state, photographs absent at 1.5s). Chrome fast-forwards timers and JS but the compositor's animation clock does not follow, and each headless run also drew a different random opener. Diagnosing from those frames would have chased ghosts. What actually settled it: reading the **Animation API** in-page — `is-intro` present with `delay: 200, dur: 800` on the first arrival and `delay: 0, dur: 3600` on the second, identical across three runs — plus an in-page `performance.now()` sample of beats one and two (logo 0→0.49→0.96, panel 0→194→315→320px). *Measure animation from the animation objects, not from screenshots of a fast-forwarded clock.* **Also:** the tour question is closed — rian confirmed owners do not need a walkthrough, so the long-standing "owner-facing tour" item is dropped, not deferred. **Next:** OCR for the ~70 scanned documents with no text layer · DigitalOcean production setup. ## 2026-08-28 — v0.30.0: the jolt REALLY fixed (stacking), opener photos **313 tests green**, all three instances deployed, migration `0012` applied, audit 0 critical. **The jolt was never the animation — it was stacking.** v0.29.1 rebuilt the scene on two layers and I certified it 18/18 with a headless harness. rian still saw it, and gave the decisive detail: *"nice, jolt, nice, jolt"* — alternating. The two layers swap roles each cycle, and `.login-layer` carried **no z-index**, so stacking fell to DOM order: the first layer always painted underneath the second. Every second transition swept perfectly *behind* the opaque outgoing photograph, and all you saw was the old one blink off. Fix: `is-arriving { z-index: 2 }`, `is-front { z-index: 1 }` — the arriving layer is above the one it replaces whichever way round they are. **The testing lesson, which is the real one here.** My v0.29.1 harness asked "did the animation run and is the mask applied?" — both were TRUE on the broken cycles. It never asked "can you SEE it". A green test certified a bug the user was staring at. The harness now reads real paint order via `elementsFromPoint` and asserts the arriving layer sits above the outgoing one. Negative control (z-index forced back to `auto`): **9/18 clean — exactly 50%, exactly the reported alternation**, with `sweep: "login-sweep", masked: true` on every failure. With the fix: 18/18. Pinned in Django by `test_the_arriving_photograph_stacks_above_the_one_it_replaces`. *Rule: when the complaint is visual, the test must measure what is visible, not the mechanism believed to produce it.* **Openers.** A photograph can be lovely in the rotation and a poor first impression (rian's example: a close-up of food). `LoginPhoto.is_starter` (migration `0012`) + a ☆/★ toggle on each card in `/staff/scene/`. The login view sends `data-openers` alongside `data-photos`; the shuffle pulls a random opener to position 0 and leaves the rest of the order alone. **Deliberate fallback:** `LoginPhoto.openers()` returns ALL photographs when none are marked, so the scene works uncurated and a fresh install is never blank. Marking is "may go first", never "only appears first" — the photo stays in the rotation. Verified 10/10 loads opened with the single marked photo. **Card layout:** the caption row was restacked — with a third control added, every filename collapsed to an identical `sands-…` and you could not tell one card from another. **⚠ I destroyed two of rian's opener marks on the Sands.** After testing the toggle I "cleaned up" with a blanket `LoginPhoto.objects.filter(is_starter=True).update(is_starter=False)`. It cleared 3 — one mine, two rian's, marked while I was working (he was using the feature live: Shore Club had grown to 27 photographs). No history table, so they were unrecoverable; he re-marks them by hand. **Rule: delete test data by primary key, never by filter, on a system someone is actively using.** **Tutorial status (rian asked what was outstanding):** the revisions he had in mind — spotlight not clearing the highlighted area, and making staff-only features obviously staff-only — both landed in v0.28.0. The one genuinely open tutorial item is an **owner-facing walkthrough**: the tour is staff-only (12 steps, 3 pages) and owners get no tour markup at all, which two tests pin deliberately. Joan's owners currently sign in with no guidance. **Next:** owner-facing tour (if wanted) · OCR for the ~70 scanned documents with no text layer · DigitalOcean production setup. ## 2026-08-28 — v0.29.1: photo manager, sweep fixed, hidden-tab backdrop **306 tests green**, all three instances deployed, `security-audit` clean (0 critical, no hartlingowners findings). **Photo manager (rian's ask: "accessable for people who know the upload URL").** New `LoginPhoto` model (migration `0011_loginphoto`) — the login backdrop now comes from the DB, not a static filename convention. Staff-only manager at **`/staff/scene/`**, deliberately UNLISTED (linked from no menu; a test pins that it appears in no nav). Multi-upload; `_fit_scene()` normalises every file to 1800×1200 JPEG q68 via `ImageOps.exif_transpose` + `ImageOps.fit`, so an unprocessed phone photo can't blow up the page weight or arrive sideways. An unreadable upload is named back, not crashed on. Delete refuses to remove the LAST photograph (an empty rotation would render a blank sign-in page). `import_scene_photos --prefix ` seeded the existing sets — Sands 7, Shore Club 8, Palms 8. **The photo endpoint is the app's one deliberate public file.** `login_photo` is NOT `@login_required` — the sign-in page is unauthenticated, so its backdrop must be too. Everything else stays behind `PrivateMediaStorage`. Caught during the build: `@login_required` belonging to `board_photo` had landed directly above the new view and would have gated the backdrop; removed before deploy. A test asserts non-scene pks 404 there, so the endpoint can't become a general private-file reader. **The "sweep only works ~50% of the time" jolt — root-caused and fixed.** Live MutationObserver showed a slide receiving `.is-on` while still carrying `.is-leaving`; `.is-leaving` wins the cascade (`animation: none; mask-image: none`) and silently cancelled the sweep. Cause: two racing timers (3900ms cleanup vs 6000ms cycle), and timer throttling decided the winner. Rebuilt on **two layers with mutually exclusive roles** (`is-front` / `is-arriving`, never both on one element), driven by ONE sequential async loop — there is no second writer of those classes, so coexistence is impossible by construction. Only two full-size images are ever in memory, however many photographs are in the rotation. *Measured, not eyeballed:* the shipped page was run under headless Chrome with `--virtual-time-budget` and watched from outside — **18/18 transitions clean**. Negative control (a stylesheet rule reproducing what `.is-leaving` did) scored **0/18 clean** with the user's exact symptom (`sweep:""`, `mask:"none"`), so the harness genuinely detects the failure it certifies absent. **Hidden-tab backdrop bug found while verifying.** Chrome never settles `img.decode()` in a BACKGROUND tab, and the first paint awaited it — so opening sign-in in a background tab (cmd-click, session restore) left BOTH layers at opacity 0: no backdrop at all until the tab was focused. Decode is an optimisation and must never be load-bearing; `load()` now resolves on any of three paths (decoded, image error, or a 2.5s guard) and can only settle once. Pinned by `test_the_backdrop_never_waits_forever_on_a_decode`. **Next:** the tutorial content revisions rian deferred ("one thing to fix before we do any revisions on the tutorial"). Then still open: OCR for the ~70 scanned documents with no text layer; DigitalOcean production setup. ## 2026-08-28 — v0.28.0: spotlight fixed, staff flags, login set ×23, rail aligned **296 tests green**, deployed; spotlight + alignment verified in rian's browser at his real width. **Spotlight bug:** `.tour-overlay` painted rgba+blur over EVERYTHING — including the target; the spot only cut a hole in its own box-shadow, so the "highlighted" element was as dim as the page. Fix: overlay is transparent while a target is spotlit (the spot's 9999px shadow does the dimming — a hole in the thing that dims); overlay gains `.is-dim` only for centred panels (welcome/finale). NO blur anywhere: a backdrop-filter cannot be punched through. Verified on the owner-view-switch step: target fully lit. **Staff awareness:** `.staff-flag` chip ("Staff only") on the uploader, board tools, add-owner box, Owners + Trash page heads, and a tiny `nav-staff` label before the Owners/Trash links. Walkthrough copy reinforced on every staff step ("owners never see this…"). Tests pin: flags present for staff, absent for owners AND in owner view. **Login photos:** 23 frames (Sands 7 · Shore Club 8 · Palms 8), all from native ≥1900px sources — `Rope-Bar-from-pool.jpg` turned out to be **807px upscaled** (the pixelation rian saw) and was replaced. Order shuffled per visit (Fisher-Yates; the server's first `is-on` handed to the shuffled winner so no-script still works). Per-property `PORTAL_LOGIN_COUNT`. Contact sheets used for curation; rejected: duplicates, an "UPDATE" stamp graphic, wedding/crowd shots. **Rail alignment:** `.cabinet` gets `--edge: max(20px, calc((100vw - 1020px)/2 + 20px))` (the masthead .wrap is 1020/20); rail column = `--edge + 244px`, rail-inner padding-left = `--edge - 12px` (labels carry 12px of their own). Measured in-browser: logo left 149 == rail text left 149 at vw 1278. Below 1060px it degrades to the old geometry; drawer untouched. ## 2026-08-28 — v0.27.0: staff walkthrough live; login motion retuned **294 tests green**, deployed, walkthrough exercised live in rian's browser (welcome personalised "Welcome, rian!", step 1 spotlights and renders). **Login motion:** cycle 7s→6s, sweep 2.4s→3.6s; the photograph moved to its own always-animating layer (`.login-drift`, 28s ease-in-out infinite alternate, staggered per frame) so the drift NEVER stops — the jolt rian saw was the one-shot transform finishing. Slide classes only touch opacity/mask; they can no longer restart the movement. **Walkthrough (v2, rian's script):** engine re-enabled (`TOUR_ENABLED=True`, `TOUR_VERSION=2` — v1 testers re-offered). 12 steps over library/board/owners in `_tour.html`; welcome "Welcome, !" and finale "That's it!" in `tour.js` (name via `data-first-name`). Included only when `staff_ui` — owners never get the markup, and owner-view suppresses it mid-demo. Retrigger: "Site walkthrough" in the profile menu (`[data-start-tour]`, hook already existed). **Any dismissal records seen** (×/Escape/Not now) — v1's complaint was the re-nagging. **Three bugs found by watching it run, not by the suite:** - `${firstName}` referenced but the `const` insertion had silently no-op'd → ReferenceError → EMPTY welcome bubble. (Another unasserted `str.replace`.) - Step 1 targeted `.page-head`, which the Cabinet redesign renamed on the library — engine silently skipped to step 2. - My "every target exists" test PASSED anyway: the page embeds the steps JSON, so the selector string was always present — **circular validation**. Fixed by cutting `#tour-root` out of the body before asserting, then seeding the fixture (several targets only render when content exists). The test caught a real miss (`.board-grid` on an empty board) on its first honest run. **Note:** rian's own tour_seen is now recorded (I closed it during verification) — he reviews the full run via the menu link, and it will auto-open fresh for Joan's account. ## 2026-08-28 — v0.25.0 owners polish · v0.26.0 sign-in scene **288 tests green**, both deployed; sign-in verified live in rian's browser. **Owners page (rian's testing list):** live filter as you type (rows carry `data-search`; Enter still submits for server counts) · Generate new password answers `X-Requested-With: XMLHttpRequest` with JSON and shows in a dialog beside the row (plain POST stays as the no-script path) · add-owner box reopens ONLY on error (`?add=1` — it was `{% if messages %}open`, which is why generating a password scrolled up AND opened the add box) · buttons renamed "Email a password reset" / "Generate new password" · ≤760px the table becomes stacked cards; emails get word-break so rules can't stagger · **invite email** is its own template (`registration/invite_email.txt`): subject "You have been invited to ", body "You've been invited… Click here to set your password." — the reset email untouched, and a test pins BOTH. **`&` root cause:** WP exports arrive titles-escaped once; two Palms titles stored `&` literally. Un-escaped in data (2 fields) and `import_wordpress` now `html.unescape`s titles/summaries/category/board names so a re-sync can't reintroduce it. **Board:** `.member-stage` carries the property texture (`--rail-image`, multiply) — same language as the browse panel. **Sign-in (v0.26.0):** full-screen slideshow of the property's own photography (`static/login/-N.jpg`, per-instance `PORTAL_LOGIN_PREFIX`/`COUNT`, 4×3 properties prepared at 1800×1200 q66). No masthead/footer on this page — base.html gained `{% block masthead %}`/`{% block footer %}`. The brand moved INSIDE the card as a masthead-coloured band (white-only logos need the dark field). Transition = feathered diagonal mask sweep + slow settle (`login-sweep` keyframes), 7s cycle; `prefers-reduced-motion` → still frame. Link is "Reset your password"; the redundant heading/instructions are gone. **Traps:** three tests pinned the old login markup (including the branding tests, which used the login page to check the masthead logo — now they check `login-mark`/`login-word`). And another silent no-match `.replace()` (12- vs 14-space indent) — the regex-with-assert pattern is the rule now. ## 2026-08-28 — v0.24.0: board rebuilt to rian's synthesis (A+B hybrid) **277 tests green**, deployed to all three, verified: Sands desktop (all photos), Palms (1 of 9 with photo — the true mixed case), phone, expanded. **The design** (rian's spec, from the canvas exploration): one uniform card per member — no featured lead. `has-photo` card = 1/3 matted whole portrait (aspect 4/5, `--panel` matte) + 2/3 text; bio clamps to ~portrait height with a mask fade and "Read the full profile" expands inline (button hides itself when the bio fits — nothing hidden, no button). No photo → single-column full-width text, NO placeholder (initials pattern removed from the grid; it survives only as tiny thumbs in the staff reorder dialog). Accent left rule on every card. The bio POPUP is gone. Phone: photo stage stacks above text, 300px tall. **`BoardMember.bio_html`** normalises the two storage formats: imported bios are plain text (escape + linebreaks →

), editor bios are already clean_html HTML (passed through). Test pins the escaping. **Data cleanup:** 2 Sands bios opened with an echo of the role/name line from the WP page headings; stripped in data (idempotent regex on title/name prefixes), not at render. **⚠ Template-surgery incident (recovered, lesson recorded):** a python edit sliced `s[start:end]` where `end` was found with `s.index(...)` WITHOUT a start offset — the needle matched EARLIER in the file, end < start, slice = '' , and `str.replace('', new)` inserted the replacement between EVERY character: board.html went 12KB → 8MB. Nothing noticed until the suite read the rendered page. Rebuilt the file from scratch (its full content was in session context). Rules: always pass a start to `index` when slicing forward; assert `end > start`; never `replace()` with a possibly-empty needle. No git here — the session transcript was the only backup. ## 2026-08-28 — outbound email live via Resend All three portals now send real email: Resend SMTP (`smtp.resend.com:587`, TLS, user literally `resend`, key as password), From ` Owners ` per instance (domain verified in rian's Resend account). No settings changes were needed — the env-driven SMTP block existed; this was config only. **The key lives in `/srv/apps/hartlingowners/.email.env`** (0660 rian:hartlingowners-dev, same pattern as `.app.*.env`), consumed via `env_file` by the three WEB services only — the db services never see it. One file, one rotation point. Filled by rian himself; never in chat, never read back — verified by `grep -c REPLACE_WITH_` = 0 and by behaviour. **Verified end-to-end:** `send_mail` from the Sands container → SMTP handoff accepted (1); real password-reset POST → 302, clean logs; rian receives. **Two traps hit and worth keeping:** - `env_file` is read at container CREATION. rian filled the key and tried a reset — nothing sent, because the running containers still held the placeholder. `srv-gw deploy` (recreate), not restart-only thinking. - `setup_test_environment()` swaps the email backend for the in-memory one — a "send" through the test client after it goes into `mail.outbox`, not out. My first reset trigger silently sent nothing; re-ran without it. This also closes the earlier flag: the console-backend fallback no longer writes reset links into container logs — SMTP is active. ## 2026-08-28 — v0.23.1: pill only in Flat; dark-mode panel fixed **269 tests green**, deployed. **Category pill:** `hide_category` was `group_by == "category"`, which predates the rail — a rail-picked category is `group=date&category=`, so every row still carried a pill repeating the page title. Rule per rian: the pill shows ONLY in Flat (`hide_category = group_by != "all"`). An old test asserting the date-view-shows-pill rule was updated (rule change, noted in its docstring). **White-on-cream Browse on phones:** dark mode. `--panel` derives from `--brand-ground`, which is per-instance and never flips — so dark phones got the light panel under dark-mode (light) text. The dark block now sets `--panel: #1a2124` (a step above the dark ground); ink 14.4:1, ink-2 8.0:1 on it, and `--panel` joined the dark-mode contrast test's surface list. **Method:** `--force-prefers-color-scheme=dark` does NOT work in this host's headless Chrome — the render silently stays light. To see the dark theme, rewrite the CSS media query to `@media all` on a copy and render that. **Trap this exposed:** any token derived from a per-instance brand value is light-mode-only unless the dark block overrides it — same class of bug as the accent collapse fixed in v0.17.0. When adding a brand-derived token, add its dark counterpart in the same commit. ## 2026-08-28 — v0.23.0: one-line phone masthead, Browse strip **268 tests green**, deployed, phone states proven via the iframe technique (closed / menu open / drawer open). **Masthead ≤620px:** burger · centered logo · avatar on ONE line; the nav is a drop-down panel under the bar (absolute, masthead colour, vivid bottom rule, 48px targets, Escape/click-away/link-tap closes). Markup restructured: the usermenu moved OUT of `.site-nav` into `.header-right` so the avatar stays on the bar while the links drop — desktop renders identically. **Browse ≤900px:** no longer a rounded pill — a full-width strip in the panel's own shade (`var(--panel)`, hairline bottom), label left, chevron-right at the edge signalling the side drawer. One hamburger per screen, and it belongs to the masthead. **Bug caught by measuring:** I gave the strip `-28px` bleed margins assuming it sat inside the pane's padding — it is a grid child of `.cabinet`, so the negative margin dragged it under the sticky masthead (probe: stripTop=51 vs headerBottom=79). In a grid, a child's negative top margin overflows its row upward; the row still holds its space. The strip needs `width:100%; margin:0` — the cabinet is already full-bleed. ## 2026-08-28 — v0.22.0: masthead-mirrored footer + owner-view switch **265 tests green**, deployed, exercised end-to-end in rian's browser (toggled on, verified the owner render, toggled back off — his session ends in staff view). **Footer** mirrors the masthead: same `--masthead` field, `--vivid` rule on top, centered logo at 80% masthead size, version at 11px/38% white. **Owner-view switch** (footer, next to the version; real staff only). It is a **server-side rendering flip**, not CSS hiding: session flag `owner_view`; `staff_ui(request)` in `config/context_processors.py` is the single effective flag; every template that branched on `user.is_staff` now branches on `staff_ui`, and the two view-context branches (library `_upload_context`, board `removed`) follow it. **Not an authz boundary** — every privileged endpoint still checks real `is_staff`, so flipping it can never lock rian out (test pins this). The switch itself renders on real `is_staff`, never `staff_ui` — otherwise there is no way back. Turning it ON from a `/staff/` page redirects to the library, since owners cannot stand there; `next` is refused unless it is a local path (`/…`, not `//…`). **Bug caught in-browser before rian saw it:** a wrapped `{# … #}` template comment — Django's `{# #}` is single-line only, so it rendered as footer text. Now `{% comment %}`, plus a test that greps the page for comment leakage. **Trap for later sessions:** detail/serve trashed-and-unpublished visibility (documents/views.py) still follows REAL staff, deliberately — the switch changes UI surfaces only. ## 2026-08-28 — v0.21.2: textures corrected to the resort register **254 tests green**, deployed, verified in rian's own browser (zoomed). Rian's side-by-side (portal sidebar vs the resort's own use of the same tile) exposed two faults: **I upscaled the tiles** (89px art at 150px = pixelation; `PORTAL_RAIL_TILE` is now `auto` = native size, crisp), and **I spent the whole contrast budget**. The ≥220 legibility floor is a CEILING, not a target — the resorts run their own textures at a fraction of it. Now: Palms wave max darkening 8/255 (~3%), Shore Club quatrefoil 7/255 (~2.7%); before: 34 and 16. Sands fronds unchanged (18/255) — rian has not flagged it since the redo. **Rule worth keeping: when copying a brand element, copy its USAGE (scale, opacity), not just its file.** The file was right both times; the rendering wasn't theirs. Also this session: rian "not seeing changes" was tab staleness — open tabs hold the old HTML which references the old hashed CSS; a plain reload suffices. Verified live in his browser via claude-in-chrome (all three properties on the new fonts after the " fix). Cloudflare serves the gated HTML as DYNAMIC / no-store, so no server-side cache exists to purge. ## 2026-08-27 — v0.21.0: real fonts, real palettes, resort textures **253 tests green**, deployed to all three. **⚠ `srv-gw db-query --project ` READ THE WRONG DATABASE.** It reported thepalmstc as `twentytwentyfive` with 3 published posts; the container and its `.env` both say `wp_thepalmstc`, which is `kadence-child` with 44 pages and a full palette. Two conclusions in this project were wrong because of it. **Read these sites through their container** — `docker exec -wordpress wp --allow-root option get …` — not through db-query, until the gateway discrepancy is understood. Worth an ops ticket. **Recovered per property (from the containers):** | | display | body | brand colour | paper | |---|---|---|---|---| | The Sands | EB Garamond | Source Sans 3 | `#00b3b0` | `#f6f3ec` | | The Shore Club | **OptimaLTStd** | Open Sans | `#ff7760` | `#faf7f2` | | The Palms | Cinzel | Didact Gothic | `#739ac6` | `#fbf8f1` | The Palms' accent `#4e6987` and masthead `#222e3b` are its own blue darkened until text passes — its earlier green was my invention and is gone. **OptimaLTStd** is vendored from `theshoreclubtc/.../OptimaLTStd-regular.woff2` with rian's explicit go-ahead (licensed Linotype face; the licence question was raised and answered). `@font-face` in `portal.css`; only the instance whose `--serif` names it ever loads it. **Textures replace the photo watermark.** Resort background tiles, not pictures: Palms `wave_tr_bg.png` (its luminance, not its alpha — the alpha is nearly uniform and extracting it yields a flat file), Shore Club `bg-pattern.jpg` (quatrefoil, echoes their medallion). Both squeezed into the same ≥220 band and shipped as **PNG**, which sidesteps the JPEG overshoot that bit the watermarks. `--rail-size` / `--rail-repeat` switch the panel between one covering photograph and a repeating tile. **Open:** The Sands still shows its photo watermark — rian pointed at "palm leaves on the Grace Bay Beach section" but the section carries no `bgImg`, no custom CSS background, and no leaf asset that route surfaces. Asked him to point at it. ## 2026-08-27 — v0.20.0: resort typefaces and full-strength header accents **253 tests green**, deployed to all three. **Recovered from the resort sites' own settings** (`theme_mods_kadence-child`, serialised PHP — parse with a regex for `s:6:"family"`): | | headings | body | footer colour | |---|---|---|---| | The Sands | EB Garamond | Source Sans 3 | `palette2` = **#128c8c** | | The Shore Club | **OptimaLTStd** | Open Sans | `palette1` = **#ff7760** | | The Palms | — | — | — | **The Palms' local site is on stock `twentytwentyfive`**, not Kadence — no palette, no typography, no global styles. Its brand is not recoverable from this box; rian has been asked for the blue he means and for its fonts. **OptimaLTStd is licensed (Linotype) and self-hosted** at `theshoreclubtc/wp-content/uploads/2025/03/OptimaLTStd-regular.woff2`. Not copied — Marcellus stands in until rian confirms the licence covers the portal. **Why the vivid colours are accents, not backgrounds.** White on #ff7760 is 2.61:1 and on #00b3b0 is 2.60:1 — neither can sit behind white text, and the logos are white-only so the bar cannot go light. The masthead therefore stays dark and takes the colour as a 3px rule plus the active nav link. Shore Club's bar moved #3c3e40 → #2f3133 so its orange clears 4.5:1 on it (4.12 → 5.01). `--header-h` grew to `+ 35px` for the thicker rule; `MastheadAccentTests` pins all of it, including a guard that fails if a vivid colour ever becomes legible enough behind white text to tempt someone into reversing the decision. **Note:** `PORTAL_FONT_CSS` holds a literal `&`. Django escapes it into the tag; pre-escaping in compose double-escapes and the fonts silently fall back. ## 2026-08-27 — v0.19.0: watermark, near-flat panel, two bugs rian's screenshot caught **248 tests green**, deployed to all three. **Panel** is now `--brand-ground 97% / --ink 3%` — near-invisible as a tint; the `border-right: 1px solid var(--line)` does the separating. 88% read as heavy. **Watermark, not emboss** — rian's correction, and the right word. Recipe: `-colorspace Gray -normalize -sigmoidal-contrast 4,50% +level %,100%`, no blur, `background-blend-mode: multiply`. `.rail-inner` took `height` instead of `max-height` so the picture fills the whole visible column — it had been confined to the content box, which is why rian saw it start below the year list. **The tonal band is the safety mechanism and it is measured:** multiply can only darken, and the faintest rail ink (`--ink-2`) clears 4.5:1 only while the watermark stays at or above **220/255**. Anything darker fails on all three properties. **JPEG broke that silently.** Levelling the source to 220 produced files whose actual minimum was **209–215** — compression overshoots at edges. The floor is now found per image by encoding and re-measuring until the real minimum clears 220 (Sands 88%, Shore Club and Palms 89.5%, quality 94). `RailWatermarkTests` opens the SHIPPED images with Pillow and fails if any dips below 220 — the recipe is not the guarantee, the file is. **Two bugs visible in rian's screenshot:** - `total` is the count AFTER the category filter, so the rail's "All documents" reported the open collection's size. Added `library_total` from the unfiltered queryset. - `.year-count` positions with `margin-left: auto`, which needs a flex parent — only `.year-label.has-colour` had one, so the by-year view rendered "2026 1". Flex moved onto the base rule. ## 2026-08-27 — v0.18.3: the browse panel goes light and embossed **245 tests green**, deployed to all three. The dark panel made the site feel heavy. It is now `--panel: color-mix(in srgb, var(--brand-ground) 88%, var(--ink))` — the property's own paper one step down, per property, with a `--line` right edge. **The photograph became a texture, not a picture.** Recipe (ImageMagick): `-colorspace Gray -blur 0x14 -emboss 5 -colorspace Gray +level 34%,66%`, then in CSS `background-blend-mode: soft-light` against the panel colour. That last part matters: blending against the *colour* means one greyscale file tints correctly for all three properties, with no overlay layer and no opacity juggling. Files dropped from ~50–100 KB to 16 KB each. **Tuning notes, so this isn't re-derived:** `-shade` was tried first and vanished entirely once levelled — it has too little local contrast to survive. `-emboss` survives. Blur is the dial between picture and texture: 0x5 still shows sand grain, 0x20 is mush, **0x14** is the point where shapes read as relief and nothing reads as detail. **Contrast had to move with it.** Darkening the panel eats exactly the headroom `--ink-3` had on the page — at a 95% panel it already failed on two of three properties. The rail therefore uses `--ink-2` and `--ink`, which clear 4.5:1 down to an 81% panel. `RailPanelTests` re-derives the panel from the stylesheet and fails if `--ink-3` ever appears as rail text, checking against the *lightest* extreme the emboss can lift the panel to, since that is the hard case for dark text. ## 2026-08-27 — v0.18.2: the browse panel goes flush and full-height **245 tests green**, deployed to all three, measured on each. Rian did not want the floating-card look. The library page now escapes the centred `.wrap` entirely (`{% block main_class %} full-bleed{% endblock %}`, `.wrap.full-bleed { max-width: none; padding: 0 }`) so the panel sits on the window edge with no radius and no shadow; the pane carries the page padding instead. **The rail is deliberately two elements.** `.rail` is the COLUMN — full page height, flat masthead colour, so the dark never stops halfway down a long list. `.rail-inner` is the PANEL — sticky under the masthead, capped at the viewport, carrying the photograph and scrolling inside itself if the collections outgrow the window. One element could not do both: a viewport-height element leaves the column bare below the fold, and a page-height element stretches the photograph over the whole document. **`--header-h` is derived, not hardcoded:** `max(var(--logo-h), 40px) + 33px` — the masthead's 16px padding top and bottom, its 1px rule, and whichever is taller, the property's logo or the 40px account button. The three logos are three different heights (34 / 44 / 54), so a fixed offset would misalign two of them. First attempt used `40px` as `34px` and every property with a short logo tucked 6px under the masthead on scroll — measured against the real rendered header to catch it. **Method note (third time):** headless Chrome's viewport is not what `--window-size` says — it was 733px for an 820px window here, and floors around 485px. Every screenshot check must go through an exact-size `iframe`, or the capture is a crop and a correct layout reads as broken. Two false alarms came from this before I stopped trusting it. ## 2026-08-27 — v0.18.1: the browse panel goes dark, and carries the resort **245 tests green**, deployed to all three, checked at 1340px and 390pt. Rian asked for more separation between the browser and the documents, and for resort photography worked in subtly. Both are the same move: the rail became a **dark panel in the property's masthead colour with a photograph behind it**. **Images** are pulled from each resort's own marketing site on this box: Sands `Grace-Bay-Beach.jpg`, Shore Club `Long-Bay-Beach-HR-3-Crop.jpg`, Palms `JPR-ThePalms-026-Crop.jpg`. Cropped to a tall strip, slightly desaturated, lightly blurred, ~50–100 KB each, in `main/static/rail/`. Per-property config (`PORTAL_RAIL_IMAGE`), exposed as `--rail-image`; a property without one falls back to a transparent gradient and renders fine. **The overlay figure is measured, not chosen.** Compositing the masthead colour over a blown-out WHITE pixel of the photograph and then the text alpha on top: at 78% the faintest label fails on Shore Club (4.27:1), at 82% it just passes, so the gradient runs **84% → 93%**. My first attempt used 94–98% and the photographs were invisible — worth knowing that the honest range is narrow. `RailPhotographTests` re-derives that sum from the stylesheet itself and fails if the overlay is ever thinned, if the faintest text stops clearing 4.5:1, if a property's photograph gets hardcoded, or if the no-image fallback stops being a valid image value. **Still open:** rian may switch the phone rail from the flyout to the pinned chip row once he has felt it on a real handset; both remain on the exploration canvas. ## 2026-08-27 — v0.18.0: the library rebuilt as The Cabinet **241 tests green**, deployed to all three, checked at 1400px and 390pt. **Rian chose The Cabinet, with the flyout on mobile** (over the pinned chip rail) — with the caveat that he may change his mind once he feels it on a phone. Both mobile options stay drawn on the exploration canvas, so switching is a CSS change, not a rebuild. **Shape:** a standing rail of Collections (with document counts and the category colour) and Years beside the pane; below 900px it becomes a drawer behind a Browse button, with scrim, Escape, focus move, and auto-close on navigation. **The rail replaced the two control rows without losing an axis.** Picking a collection is `?group=date&category=` — that collection, grouped by year. Picking a year is `?group=category&when=…` — that year, grouped by collection. So the two groupings are the two rail sections, and no view logic changed. The old "Everything" grouping survives as a **Grouped / Flat** switch by the search box. **Everything else came across untouched:** `_item.html` / `_row.html` were not edited at all, so expandable groups, staff edit and trash, colour coding, "show more", search, the uploader and every dialog behave exactly as before. Eleven tests now pin that explicitly, so the next layout change cannot quietly drop one. **Two real bugs found by building it:** - Counts beside a category counted **rows, not documents** — a collection of three showed as one. The rail said Minutes 31 while the section heading said 24, about the same category. Everything counts documents now. - Category counts came through `category.documents.count`, which ignores `published` and `removed_at` — a category emptied into the trash still showed a tally. Counted from the visible queryset now. **Also:** the masthead wrapped raggedly under ~620px (a regression from the v0.17.0 masthead); brand and nav now take a row each. **Method note:** headless Chrome floors its viewport at ~485px on this host, so `--window-size=390` gives a **crop, not a phone layout** — it looked like a horizontal-overflow bug that did not exist. Render the page in a 390px `iframe` inside a wider window to get a true phone viewport. ## 2026-08-27 — v0.17.1: muted text was failing WCAG AA everywhere **230 tests green**, deployed to all three. **`--ink-3` was `#7d8b90` — 3.18:1 on the Sands ground, 3.29 on Shore Club, 3.21 on Palms, 3.52 on white.** The floor for text under 18.66px is 4.5:1, and that token carries **every date, subtitle, meta line and small label in the app**. These readers are condo owners, many elderly. Now `#5f6d71` (4.84:1 worst case). Found while building design mockups, not by looking at the app. **Both warm accents were fractionally under on their own paper** — Sands `#0e7d7a` 4.48:1, Shore Club `#b8503c` 4.46:1 — while passing on white, which is exactly the case a white-background check misses. Deepened to `#0d7572` and `#b04a37`; hues unchanged. Palms `#2f5d4a` already passed at 6.80. Dark mode was fine throughout (5.0–5.4:1) — this was light-mode only. **`documents/tests/test_contrast.py`** now measures every text token against every ground the app renders on — all three brand papers plus `--surface` and `--surface-2` — in both themes, and fails below 4.5:1. It also checks white-on- accent for buttons. The brand grounds and accents are listed in the test so a fourth property adds a line. **Design exploration** (working files in `notes/library-takes/`, canvas at ): four structurally different library directions — Ledger (editorial index), Vault (dark, category-first), Concierge (search-led), Cabinet (two-pane rail). **Rian has picked the Cabinet.** Page two carries it at 390pt two ways: a pinned chip rail and a flyout drawer, with the case for each. ## 2026-08-27 — v0.17.0: per-property identity **226 tests green**, deployed to all three. Review page: **Brief (rian's answers):** resort-luxury but restrained · distinct palette per resort, shared layout · Claude derives the colours, rian reacts. **The real logos were recovered.** Each site's *active* logo is its own — `site_logo` / `custom_logo` point at different attachments. The identically named `logo-main.png` in all three media libraries is a shared-template leftover that happens to be The Shore Club's mark, which is why they looked identical at first glance. Shore Club has an **SVG**; the other two are PNG at adequate size. Installed at `main/static/brand/`. **All three marks are white-on-transparent with no dark variant anywhere.** So the dark masthead is a constraint the artwork imposes, not a preference — worth restating whenever someone asks for a light header. **Colours recovered, not invented, for two of three:** Shore Club's coral `#ff7760` + charcoal `#58595b` (27 and 17 uses in their own child theme, first two in their palette); The Sands' teal `#00b3b0` (leads `kadence_global_palette` on their resort site). Both deepened for contrast on white. **The Palms yielded nothing** — its green is a derivation from the mark and is the one open question; bronze and ink alternatives are rendered on the review page. **Architecture:** the instance supplies RAW brand values (`--brand-accent`, `--brand-ground`, `--masthead`, `--logo-h`) and the stylesheet decides how each mode consumes them — light takes the accent as given, dark mixes it toward white with `color-mix`. Injecting `--accent` directly would have been overridden by the dark-mode block and all three would collapse to one accent at night. Logo height is per-property because the marks differ in proportion. **Bug found by audit, not by eye:** four declarations used `var(--ink-soft)`, a token that does not exist — an undefined custom property is invalid at computed-value time, so the element silently inherits and looks *almost* right. `documents/tests/test_stylesheet.py` now fails on any fallback-less `var()` whose token is never defined. **Method note — screenshots without a browser session:** the host has `google-chrome`. Render a page through its own container with the Django test client, strip the shell banner, rewrite `/static/...` to local relative paths (WhiteNoise adds a content hash, so match `[a-z]+\.[0-9a-f]+\.png`), copy the CSS and brand assets next to it, then `google-chrome --headless --screenshot`. `--window-size` height sets the capture height — there is no full-page flag. ## 2026-08-26 — de Grâce photo removed from WordPress (live + local) Owner-approved. Removed from **both** the live Cloudways site (shoreclubowners.com, app `tewadwgkdv`) and the mosiah sync (`hartling-shoreclubowners`), so a re-sync cannot reintroduce it. Per site: the Gutenberg image block was cut from page 24, and attachment 784 was deleted. WordPress refuses to *trash* attachments unless `MEDIA_TRASH` is on, so `--force` was the only route — the image and both size variants were copied off first. **Backup (live server, outside the web root, owner-only):** `/home/master/shoreclub-degrace-removal-2026-08-26/` — page content before and after, plus all three image files. That is the only surviving copy; the local sync's files went with its attachment record. Verified on all three copies: five directors listed, no reference to the image, no orphaned `wp-image-784` class. The remaining portraits (Dickson, Hartling) are untouched, and the Django portal is unchanged — Stanton was already showing initials. **Method notes for future WordPress edits from a session:** - The WP containers bind-mount **only `wp-content`** — a file handed to `wp post update` must live under `/var/www/html/wp-content/…`, not the site root. Stage it there, use it, delete it immediately (anything under `wp-content` is web-servable). - Never write the backup into the web root. `/home/master/` on Cloudways. - Bound a Gutenberg block by searching outward from the payload to the nearest `` rather than regex-matching across it, and assert the cut contains no headings or paragraphs before writing. ## 2026-08-26 — v0.16.2: the Stanton photo settled, Sands board completed **221 tests green**, deployed to all three. **The `christiandegrace2018.jpg` question is answered from the WordPress revision history, not by comparing faces.** Shore Club page 24, two revisions six minutes apart on 2026-04-21: | rev 1239 (21:19) | rev 1241 (21:26) | |---|---| | img degrace → **CHRISTIAN DE GRÂCE** | — removed — | | img mitchzajac → MITCHELL T. ZAJAC | — removed — | | **JAMES D. STANTON** (no image) | James D. Stanton → **img degrace** | That edit dropped two directors. Zajac's portrait was deleted with him; de Grâce's was left behind, and Stanton — who has never had a photo on the site — moved up into the vacated slot and inherited it. **The picture is Christian de Grâce.** Stanton has no portrait anywhere in the media library. The same edit also flipped that page from photo-above-name to photo-below-name, which is the origin of the layout inconsistency between the three sites. **Sands board completed:** Wes Stearns is "Candidate for Board of Directors" and Tom McKeown has his photo (`Screenshot-2022-07-12-103959-1.jpg` — the filename carries no name, which is why the matcher could not place it; rian identified it). All five Sands members now have a portrait. **Parser fix behind Wes:** `
` was stripped rather than treated as a line break, welding "…Board of Directors" to "The Sands at Grace Bay" into a 54-character run — past the 48-character limit for a role, so it was filed as biography and he showed no role at all. **Left alone:** the de Grâce photo is still on the legacy WordPress site; the Django side no longer shows it. Removing it there is rian's call. ## 2026-08-26 — v0.16.1: duplicate email removed, and the door closed **218 tests green**, deployed to all three. **`rian80` deleted on Sands** (owner-approved). It was a WordPress-import twin of `rian` — same address, never signed in, nothing attached to it (checked with `NestedObjects` first: the cascade was the User row alone). Two superusers existed, so removing one left an administrator. `rian@rian.ca` now resolves to exactly one account, which is the condition email sign-in needs. No duplicate addresses remain on any of the three sites. **Why it mattered:** the login backend refuses to guess between two accounts sharing an address, and that check runs *before* the is-active check — so the duplicate rejected `rian@rian.ca` + any password, and deactivating it would not have helped. It reads exactly like a forgotten password, which is how it surfaced. **Closed the source.** `_import_users` matched on username only, so two WordPress accounts sharing an address both kept it. It now drops the contested address from the later account (keeping the account — it may own documents) and names it in the import report. Six tests cover it, including two duplicates inside one manifest and the re-run case where an account must not read its own address as a clash. **Password reset without email:** `docker exec -it hartlingowners-app-sands python manage.py changepassword ` — prompts in the operator's own terminal, so nothing passes through a transcript or a log. **Open, and worth doing before launch:** `EMAIL_HOST` is unset, so Django falls back to the console backend and writes reset emails — *including the working reset link* — into the container log. Only root can read those, but a reset link is an account-takeover token, and this stops being theoretical the moment owners start requesting resets. ## 2026-08-26 — v0.16.0: board photos corrected, account menu **212 tests green**, deployed and verified on all three. **The wrong-face bug rian spotted was systemic, not a one-off.** Stan Hartling wore Tom Mothorpe's portrait on Palms — and on Sands, three of five directors had the wrong face. Cause: `parse_members` took the first `` between one name heading and the next. The pages float the portrait right, and its position relative to the heading is **not consistent** — Palms puts every photo *above* the name, Shore Club *below*, Sands does one below then the rest above. So the image between two headings can belong to either of them. **Fix: match on the filename, never on position.** `stan200x300.jpg` → Hartling, `tommothorpeL.jpg` → Mothorpe. Surname needs 4+ characters (shorter runs collide inside longer words); a first name counts only when unique on the page — Sands has two men called Tom. **An image matching nobody is dropped**, not given to the nearest heading: these pages outlive their boards, and a departed member's portrait is often still in the markup. Initials are wrong in an obvious way; another director's face is wrong in a way that reads as true. Corrected live via a new `--photos-only` mode (touches photos only — Palms' roster comes from its contact table, so a full re-import would rewrite it): Palms 1 fixed · Sands 3 fixed + 1 cleared · Shore Club 1 cleared. **Tom McKeown (Sands) has no photo now.** His portrait is on the page as `Screenshot-2022-07-12-103959-1.jpg` — no name in the filename, so nothing honest to match on. He previously wore Stan's face. Rian can attach it from Board → Edit. **Account menu** replaces the Sign out link: initials avatar → profile, change password, sign out. Profile edits name + email only; username stays fixed (owners were migrated with usernames they never chose, and staff read them back over the phone). **A duplicate email is refused** — sign-in accepts an email and the backend refuses to guess between two accounts sharing one, so a duplicate would lock out both people, not just the new one. **Still open:** design direction · owner-facing tour · OCR for scanned documents · optional profile photo upload (skipped deliberately: it adds an image-upload surface and an auth-gated serving path, neither of which was asked for). ## 2026-08-26 — v0.15.0: Activity removed, owner list re-cut, row spacing **189 tests green**, deployed and verified on all three. **Activity page removed** — the screen only. `LoginEvent` and `DownloadLog` keep recording, so the history exists if it is ever wanted, and `DownloadLog` could not have gone anyway: it is what the per-user download rate limit counts. Also removed the tour step that pointed at it (the tour is dormant, but a `{% url %}` to a deleted route would have raised `NoReverseMatch` the moment it was switched on). **The owner list now has five views** — All current / Owners / Staff / Active / Deleted, each with a count. Counts are of the whole list, not the current search, so searching cannot make them move. **"Deleted" is a soft delete**, matching the document trash: the account is deactivated and kept, and putting someone back restores their password intact. Erasing for good is a separate action offered only inside the Deleted view. This replaced the old Deactivate/Delete pair, which put a recoverable and an irreversible action side by side under similar labels. **`last_login` is empty for imported owners** (2 of 137 on Palms) — WordPress has no such column, so Active reads near-zero until people sign into the new portal. Correct, but worth knowing before showing the number to Joan. **Row spacing:** a lone document had no margin beneath it. A folder is a `

` with its own margin; a lone document is a one-item `