EVENTS-001A — Define the canonical public event view and approved source contract

[daliu]

Officer impact: Officers know where an event starts, what may be shown publicly, and how an event reaches the website. They do not copy discount codes into public event records or edit Firestore directly.

Officer documentation: Update docs/officers/EVENTS_SHOP_MEMBERS.md, docs/officers/SYSTEM_MAPS.md and its text alternative, and docs/officers/GLOSSARY.md. The officer flow must remain NOT AVAILABLE YET until a later source importer and reviewed publish path are deployed and proven.

Deployment evidence: This issue defines a contract and owner decisions; it does not deploy an importer. Closure requires approved field/source tables, synthetic examples, schema validation tests where appropriate, owner sign-off, and a backup-officer review. Later tickets must separately prove importer, admin, website, Firebase, and provider states.

User-reported gap

On 2026-07-12, the owner reported that events associated with the existing Google Site were not integrated into the website.

Read-only finding

The referenced Google Site is a single discount-oriented page, not a structured event/calendar feed. A signed-out request still returns the page. noindex is present, but that does not restrict access. The page has a race-related discount link and separate Google document/form links; their content was not opened or copied.

The MPRC website already reads published records from Firestore's events collection. Production does not use its development placeholder events. The missing outcome is an approved source and safe population/publishing contract, not another website route.

Do not scrape or synchronize the Google Site. It mixes the wrong content boundary, has no stable event schema, and would create a second source of truth.

Atomic outcome

Approve one canonical public event projection and the contract that an eventual structured source must satisfy. This issue does not import or publish live events.

flowchart LR
    A["Approved structured source"] --> B["Validate and minimize"]
    B --> C["Private draft event"]
    C --> D["Officer review"]
    D --> E["Audited publish"]
    E --> F["Public event view"]
    G["Protected registration, waiver, payment, or discount"] -. "stable opaque reference only" .-> C

Loading

Text alternative: An approved structured source becomes a private draft only after validation. An authorized officer reviews it before an audited publish creates the small public event view. Protected details remain separate.

Owner decisions required

Classify each current source/item before designing an importer:

• MPRC-hosted race or paid event.
• Regular club run or social event.
• Third-party public race listing.
• Member-only discount offer tied to a race.
• Registration/form response, volunteer record, or waiver evidence.
• Historical item that should be retained privately, archived, or deleted.

For every approved category, name the authoritative owner/source, update frequency, public fields, protected fields, retention, correction/cancellation rule, and escalation role.

Public event projection

Approve a minimum schema such as stable event ID, title, safe summary, start/end in an explicit timezone, public location or location note, status, event type, approved public URL, accessibility/contact text, source revision, and published/updated timestamps.

The final contract must define:

• Stable source ID and revision/idempotency key.
• Timezone, daylight-saving, recurrence, exception, postponement, and cancellation behavior.
• URL allowlist/validation and safe plain-text formatting; no arbitrary HTML.
• Draft, reviewed, published, updated, cancelled, and archived transitions.
• Conflict handling when the source changes after officer edits or publication.
• Minimal public query/index behavior and backward compatibility for existing event records.

Never public in an event record

• Discount or promotion codes and protected offer terms.
• Registration/guest lists, form responses, payment state, Stripe IDs, waiver evidence, or emergency contacts.
• Private meeting locations, door/access instructions, member contact details, internal notes, audit records, provider tokens, or source credentials.
• Unreviewed external text, scripts, embeds, or arbitrary HTML.

A public third-party race may reference a separate protected discount offer only through a stable opaque ID. The public record must not reveal the code or whether a person is a member.

Acceptance criteria

• BACKEND-001 — Audit the Firebase cutover and approve legacy data disposition #113 privately identifies the approved structured event source(s) and owners; this issue names exactly one source contract for the first importer.
• DATA-001B — Inventory personal data and approve a minimization/retention matrix #110 approves the public/protected field split, purpose, access, retention, and deletion/correction rules.
• A versioned public event schema and private draft/source metadata schema are documented with synthetic examples.
• Every event category has an authority, owner, lifecycle, conflict rule, and correction/cancellation path.
• Timezone, recurrence, exceptions, postponement, cancellation, duplicate, stale revision, deleted source, and invalid URL/text cases are deterministic.
• Public records cannot contain discount codes, form responses, registration/payment/waiver data, private locations, contact data, provider secrets, audit data, or arbitrary HTML.
• Existing public event reads and links have an additive/backward-compatible migration plan.
• The future importer is explicitly dry-run first, idempotent, server-side, bounded, synthetic-tested, and draft-only.
• The future officer publish path requires scoped authorization, recent authentication as approved, stable command ID, and append-oriented audit.
• The Google Site is not scraped, synchronized, or treated as event authority.
• A backup officer can explain the diagram, distinguish an event from a protected discount/registration, and identify the source owner without terminal access.

Dependencies and coordination

• MEMBERS-ACCESS-001 — Restrict the exposed Google Site and contain leaked discounts #80 owns immediate restriction of the exposed Google Site and any exposed-discount response.
• MEMBERS-CONTENT-001 — Build the Firebase-native members-only discounts page #83 owns Firebase-native protected discount offers. It must keep codes separate from public race/event information.
• BACKEND-001 — Audit the Firebase cutover and approve legacy data disposition #113 owns the private inventory of Firebase plus Google Forms/Sheets used for events, registrations, waivers, and volunteers. Do not create an importer or migration until that disposition is approved.
• DATA-001B — Inventory personal data and approve a minimization/retention matrix #110 owns the personal/public data matrix and retention decisions.
• SEC-001 — Replace the Firestore admin catch-all with resource-specific rules #100 owns Firestore trust boundaries; the current browser-admin catch-all must not be used as the publishing boundary.
• CI-001 — Establish trustworthy quality gates and protected deployment #105 owns staged/protected Firebase deployment and evidence.
• ADMIN-001/its event-configuration children own scoped server-side draft/review/publish commands and audit; do not duplicate them here.
• RACE-001 and the PAY issues own capacity, registration, price, checkout, payment, cancellation, refund, and race-commerce state for club-hosted paid events.
• INSTAGRAM-004 — Generate event-reminder drafts and an operator scheduling UI #94 consumes a stable public event schema for social reminders; it is not an event source.

After this contract and #113 identify one approved source, create a separate focused EVENTS-001B issue for one server-side draft importer. Do not create a generic multi-source sync ticket.

Explicitly out of scope

• Scraping the Google Site, opening/copying protected documents or forms, importing real records, or publishing an event.
• Discount migration, registration, waiver, capacity, payment, checkout, refunds, email, or social posting.
• Direct browser writes to sensitive event/provider/audit data.

Claim protocol

Creation is not a claim. Owner decisions and private source inventory must be complete first. Then assign the issue, post CLAIMED by <canonical agent> at <UTC>; branch <branch>, re-read comments, and keep the outcome to the contract only.