Plan

Architecture

Single Go server binary hosting multiple apps under one process, with per-app routing. The directory app is the first; the structure anticipates more.
Client is frameworkless JavaScript served by the binary. No build step unless/until TypeScript is adopted, and then a minimal one.
Structured data is read from Google Sheets through a data-source abstraction, so a Veracross-backed implementation can replace the Sheets one without touching app code.
Photos and other blobs are stored in Google Drive and served through the binary (with caching), never linked directly.

Runs on Google Cloud Run.
Sign-in is Google authentication restricted to the school's Google Workspace domain. Community-only data is never served to unauthenticated requests.
GitHub is the source of truth. Pushes to the main branch trigger an automatic build and deploy to Cloud Run.
The Docker build produces a static binary in a minimal base image containing only tzinfo and CA certificates.

One command starts the local server.
Templates, static assets, and content reload on change without restarting the server.
A local data mode serves generated, non-production sample data so contributors never need real community data to develop or test.
A documented screenshot mechanism captures pages from the local dev server, so agents (and humans) can verify visual changes. See docs/screenshots.md.

Clone the existing app's functionality and layout, working from screenshots of the current app as the reference.
Views: browsable/searchable directory of families and individuals; detail pages with contact info, photos, and name pronunciation.
Photo handling: individual and family photos uploaded to Drive, resized/cached for serving.
Pronunciation: stored per person; representation (text respelling vs. audio) decided during the clone.

Sheets layout: one spreadsheet per app, one tab per entity type, first row is the schema. The server reads via the Sheets API with a service account.
Import tooling brings existing data from the current platforms into Sheets and Drive.
When a Veracross API is available, a second data-source implementation replaces Sheets as the backend for directory data.

Repo scaffold: server skeleton, app routing, local dev loop with reload, sample data mode, screenshot tooling, contributor/agent docs.
Directory app read-only clone against sample data.
Google Sheets and Drive integration; real data imported.
Cloud Run service, GitHub auto-deploy pipeline, minimal image build.
Google domain sign-in gating community-only data.
Photo/pronunciation upload flows.
Subsequent apps.