Not a code PR in the traditional sense — no functionality changes, no tests, no routes. But it's a PR I want to have, because without it I'm going to keep re-deriving the same checklist every time I update the landing pages, and I'm going to lose context between agent sessions on what the current state of the project actually is.
The landing page update checklist
Added to docs/feature-landing-pages.md as a new section: the recurring process for updating any of the four landing pages. Written as a checklist, not prose, because a checklist is the form that actually gets followed.
The rough shape:
- Make the copy / layout change on the relevant HTML file(s).
- If shared styles changed, verify all four pages still look right, not just the one you edited.
- Re-run the OG screenshot capture (Playwright, 1200×630) if the hero visuals shifted.
- Bump the
<meta name="last-updated">tag. - Preview on Vercel.
- Re-check the Facebook Sharing Debugger and Twitter Card validator to force a re-scrape of the new OG image.
- Spot-check the JSON-LD with Google's Rich Results Test.
- Merge.
Nothing revelatory. But writing it down means I don't have to remember step 6 (which is the one I always forget) by stubbing my toe on a stale OG preview in a tweet.
Memory file refresh
The rest of the PR is a batch update to docs/memory/ — the agent memory system this project uses to keep context across sessions. Twelve new or updated files:
| File | What it captures |
|---|---|
MEMORY.md | Updated index with the new entries |
feedback_docs_first.md | The "write docs before code" principle from PR #2 |
feedback_landing_design.md | The GoHighLevel-inspired design direction from PR #12 |
feedback_memory_review.md | Process for periodically reviewing and pruning memory |
project_compliance_tracker.md | Current state of the FL 718 compliance tracking build |
project_landing_pages.md | Current state of the landing page build |
project_spanish_translations.md | Early notes on the i18n work that becomes PR #15 |
project_study_portal_next.md | Follow-up work queued against the study portal |
project_website_status.md | Current state of the association website from PR #8 |
project_xero_sync_status.md | Current state of the Xero integration from PR #4 and #8 |
reference_landing_page_copy.md | Canonical copy source so agents don't invent new headlines |
reference_legal_docs.md | Where the FL statute sources live for citation |
user_profile.md | Who the user is, how to collaborate |
The memory refresh is what lets the next session of work pick up without me re-explaining "yes, we use Poppins," "yes, the sync is idempotent via SHA-256," "no, the OCR uses Anthropic native PDF, don't suggest pypdf."
Why this is a real PR and not just local notes
Because checked-in docs get code-reviewed and survive branch deletion. Because they're visible to any future contributor (human or agent). And because the memory files in particular need to be tracked in git so corrections made during one session become the ground truth for the next session. If they lived in scratch files on my disk, they'd drift.