01-projects / hq-raydata-co

hq proposal v1

Tue Apr 21 2026 20:00:00 GMT-0400 (Eastern Daylight Time) ·project ·status: draft-for-founder-review

hq.raydata.co — Initial Proposal (v1)

Why this exists

Founder iMessage 2026-04-22 (after raydata.co domain successfully migrated to Cloudflare):

“What if we made an hq.raydata.co subdomain website? This one should be private. This one should just be for us. No scraping. No bots. No other visitors… A personal dashboard. What are my focuses for the day? A feed of recent activity… A way to navigate the knowledge base… A way to glimpse each of our projects and their current status… it’ll need to be mobile friendly too.”

This proposal scopes a v1 that solves three real founder problems at once:

  1. The “novel-length iMessage” problem. Currently substantive Ray output goes through iMessage. His wife teases him about the back-and-forth length. Ray needs a place to publish detail and just link to it from iMessage. (../../../.claude/projects/-Users-ray/memory/feedback_brief_imessage_link_to_hq.md)
  2. The “Ray is doing things without me” visibility problem. Cron loops, sub-agent dispatches, vault filings happen between channel touchpoints. Founder wants a passive feed.
  3. The advisor-mode decision-surface problem. “DECISION NEEDED” items get scattered across iMessage, Discord #ops, the Notion board, and various skill reports. Founder needs a single pane: what only you can do.

Scope — what’s in v1

A. Founder-requested panes

  1. Today’s focus — top 1-3 priorities for today, derived from morning-prep output + Notion board top-priority Ray-or-Both tasks
  2. Activity feed — chronological log of vault filings, skill runs, sub-agent dispatches, cron fires (last 7 days, paginated)
  3. Vault navigator — searchable + browsable view of ~/rdco-vault/. Supports tag filter, folder browse, full-text search via QMD
  4. Project status — one card per 01-projects/<name>/, showing current status, last-touched date, open decisions, link into the project folder

B. Ray-proposed adds (high-value)

  1. Decision queue (consolidated) — every “DECISION NEEDED” surfaced by any skill in the last 14 days, in one ranked list. Marked-as-resolved (✅), deferred (⏸), or open (🔴). This is the load-bearing pane for the advisor-mode operating model. Founder can clear his queue from one place instead of scrolling iMessage/Discord history.
  2. Founder-owned task pane — Notion tasks where Owner=Founder OR Owner=Both with founder-side blocker. “What only you can do.” Direct link to each Notion page.
  3. “New since last visit” markers — vault docs and decisions tagged “Ben hasn’t seen this” so he can skim what Ray filed without re-reading old material. Cleared on view.
  4. Energy-input tap — single number tap (1-10) for the morning Brené Brown protocol. Writes to ~/.claude/state/founder-energy.txt. Drives queue depth across check-board, curiosity, and morning-prep skills.
  5. Quick-capture inbox — text/voice/photo input from mobile that lands in ~/rdco-vault/00-inbox/ for Ray’s /process-inbox to triage. Replaces “I need to remember to drop this in Obsidian later.” (Voice → Whisper → text via a Cloudflare Worker.)
  6. Cron / system health — visual status of all cron loops (last fire, next fire, success/fail), rdco-doctor pass count, vault-health score, audit-newsletter pass rate. “Is Ray actually doing things and is the system healthy?”
  7. Cost strip — running daily/monthly Anthropic + tooling spend. Honest visibility, no surprises.

B+. Founder-added panes (2026-04-22 follow-up)

  1. Relationships pane — two tiers, both load-bearing:

    • Family tier: spouse, children, parents, siblings, in-laws. Important dates (birthdays, anniversaries). Gift history (so we don’t repeat). Reminders T-30/T-14/T-7/T-1 days out for each upcoming date. Ray-proposed gift directions for founder approval, sourcing logistics if approved. Postcards via PostGrid for “thinking of you” prompts when appropriate.
    • CRM tier: contacts from 03-contacts/ + Notion Contact Candidates DB. Last-touched age + “should-touch” suggestions. Birthday/work-anniversary detection from public profiles (when discoverable). PostGrid postcard automation for personalized birthday/milestone notes (draft → founder approves → send).
    • Mother’s Day pattern (immediate test case): Mother’s Day 2026 is Sunday May 10 — 18 days from today. This is the founder-visible decision-needed for the next ~14 days. Use it to validate the relationships-pane workflow end-to-end before generalizing.

  2. Claude Agent SDK integration — interactive Ray inside HQ — two layered patterns:

    • A. Global chat sidekick: persistent chat box on every HQ page, Ray answers any question with full vault + state + Notion + email context. Powered by the Claude Agent SDK running on a Cloudflare Worker. Tools available: vault read, QMD search, Notion read/write, PostGrid send-postcard, calendar lookup, send-iMessage-back. Behind Cloudflare Access so only the founder can chat.
    • B. Pane-specific actions: each pane has Ray actions where they’re useful — “draft a follow-up to this person” (relationships), “stress-test this decision” (decision queue), “summarize this project for the team” (project status), “what should I focus on next?” (today’s focus). Reuses the same Worker; pane-specific system prompts.
    • C. Cross-channel symmetry: the HQ chat is the SAME Ray as the iMessage Ray — same memory, same skills, same vault state. HQ becomes the third surface (alongside iMessage and Discord) for two-way comms. Per the advisor-mode memory, HQ chat replaces “novel-length iMessage” with “tap-into-Ray when you have time + bandwidth.” Mobile-friendly with voice input.
    • Implementation: Claude Agent SDK on a Cloudflare Worker. Anthropic API token in Cloudflare Workers Secrets (1Password-managed). Session memory in Cloudflare D1 or Durable Object so chats persist across visits. Tool definitions reuse the Mac Mini API endpoints from the read-only data layer (already designed) plus a small set of write tools (Notion update, PostGrid send, vault append).

C. Out of scope for v1 (deferred to later versions)

Stack

Frontend

Auth (the load-bearing piece)

Data sources

The vault, Notion, and Ray’s state files all live on the Mac Mini. Two architectural options:

Option 1 (preferred): Cloudflare Tunnel + small read-only API on Mac Mini.

Option 2: Daily sync to Cloudflare R2 + read from R2.

Recommendation: Option 1. The Mac Mini is already always-on for the agent loop. Adding a small read-only API alongside is one process, simple deploy, and gives real-time fidelity that matches how Ray operates.

Quick-capture inbox flow (the only write path in v1)

Tech stack summary

Security model

LayerMechanismThreat addressed
EdgeCloudflare Access (Google SSO @raydata.co only)Scrapers, bots, random visitors
APITunnel-only access (no public IP)Direct API attacks
Sensitive endpointsTOTP step-upLost/stolen phone
Data at restVault stays on Mac Mini diskCloud breach exposure
Secrets1Password, never on disk in repoPer existing RDCO discipline
RepoPrivate GitHubCode visibility

Bot/scraper guarantee: Cloudflare Access blocks unauthenticated requests at the edge before they reach static HTML or API. There is no path for a non-authenticated request to retrieve any HQ content. Even SEO crawlers see only the Access challenge page.

v1 build plan (1-2 weeks, sub-agent-built)

DayTaskOutput
Day 1DNS setup (hq.raydata.co subdomain in Cloudflare), Access policy (Google SSO, ben@raydata.co only), empty Pages project deployedEmpty page reachable only by Ben
Day 2Mac Mini API skeleton (Hono) + Tunnel setup (api.hq.raydata.co), /api/today, /api/health endpointsLive data flowing
Day 3Astro frontend skeleton + first three panes: Today’s Focus, Decision Queue, Activity FeedFirst useful screen
Day 4Vault navigator + project status + founder-owned-tasks panesBrowse + status
Day 5Energy input + cost/cron health strip + “new since last visit” markersPolished v1 read-only
Day 6-7Quick-capture inbox flow (mobile-friendly, voice → Whisper → vault) + PWA install supportFirst write path
Day 8-10Mobile UX pass, performance, error handling, end-to-end test from phoneShip v1

Sub-agent dispatch pattern

What founder needs to do (small list)

  1. Confirm v1 scope. The 11 panes in section A+B above. Cut anything you don’t want; add what’s missing.
  2. Confirm stack choice. Astro + Cloudflare Pages + Tunnel. Or override with another path (e.g. Vercel + Next.js) — though Cloudflare is the natural fit since the domain is already there.
  3. Authorize Cloudflare Access setup. Ray will ask for a ben@raydata.co Google SSO test once the policy is live.
  4. Authorize sub-agent dispatch on the build. This is multi-day, multi-sub-agent work. Default: I dispatch and check in at end of each phase. Override if you’d rather pair on it.

Open questions for founder

  1. Voice capture privacy: OK to send voice clips to Whisper API (OpenAI), or local Whisper model on Mac Mini only? Local is feasible but slower; cloud is faster but data leaves the perimeter.
  2. Edge-render or server-render? Default is mostly server-rendered (SSR via Pages Functions). Alternatives: more client-side reactivity (htmx, Svelte). Lean server-side for now; HQ doesn’t need real-time interactivity beyond polling every few seconds.
  3. PWA only, or native iOS app eventually? PWA covers 95% of mobile UX needs and ships in a week. Native iOS is a 2-3 month project and only worth it if push notifications or deeper iOS integration becomes load-bearing. Default: PWA only.

Inputs needed from founder (to unblock build)

These don’t need answers up-front for the v1 architecture, but will block the relationships pane the moment it’s built:

  1. Family roster — names + relationship + birthdays + addresses for the Family tier (spouse, kids, parents, siblings, in-laws, anyone else who should get reminders). Format doesn’t matter — text dump, screenshot, or shared Apple Contacts vCard.
  2. Mom’s profile (Mother’s Day immediate) — name, address, gift history (so Ray doesn’t propose a duplicate), 2-3 things she likes / 1-2 she’d hate. May 10 deadline = T-18 days.
  3. PostGrid sender setup confirmed — confirm the API key + sender address are still valid in 1Password (it’s been on the postgrid skill for a while; do a test send before relying on it for Mother’s Day).
  4. Cloudflare Access SSO test — once Access is configured, founder logs in once via Google to confirm the policy works end-to-end.

Mother’s Day immediate plan (validates the relationships pane workflow)

Even before HQ ships, treat Mother’s Day as a single-shot dry run of the relationships workflow. End-to-end:

  1. Founder shares mom’s name + address + gift-history + likes/dislikes (one iMessage burst is fine).
  2. Ray drafts 3 gift directions (price ranges varied) + a postcard message draft, files to 01-projects/hq-raydata-co/relationships/2026-mothers-day-mom.md.
  3. Founder picks one gift direction (or overrides with his own pick) + approves/edits the postcard message.
  4. Ray executes: source the gift (Amazon, Etsy, or appropriate venue), confirm shipping deadline, queue PostGrid send for the postcard.
  5. Document the workflow in 02-sops/relationship-touchpoint-sop.md so the relationships pane can codify the same pattern.

This is real work that needs to happen regardless of HQ shipping. Doing it now also pressure-tests the workflow before we generalize it across all relationships.

Changelog