Epic: restructure the ICI3D clinic sites

[WestonVoglesonger]

Why

The clinic sites (DAIDD, MMED) are brittle. Carl's goals:

• Editing content can't break the site.
• Out of submodules (each clinic vendors ICI3D.github.io as one — 'hacky').
• Separate sharing of data from templates/style (and: do not use the theme to share data).
• No databases (CI/Actions fine; serverless not ruled out — just nothing to administer).
• Design for more, semi-autonomous clinics — Carl: "decentralized."
• Stay on Jekyll (use the updated interface), not a different tool.
• Slides: restyle in one click; stop fighting Google Slides; ingest existing decks.

The model (Carl, 2026-06)

• Content that changes (schedule, personnel, applications) becomes flat data files (YAML/CSV/JSON) in the clinic sites, edited directly in an IDE / github.dev — no Issue Form.
• A fixed, shared renderer turns data → views (one authoritative source → multiple views). The template isn't edited live, so live edits can't break the build.
• A CI validator checks the data on push; a bad edit fails validation with a clear error, not a downed site.
• Shared logic maintained once, not N times.

Grounded reality (verified against the live repos)

• Schedule churn is the problem: 44% of MMED / 62% of DAIDD commits touch schedule/. MMED is edited live, mid-clinic, on the deploy branch.
• The existing jekyll-theme-ici3d gem bundles _data into the gem (violates "don't share data via the theme"), has drifted (57 vs 69 person records), and a branch pins ~> 0.1.3 — a version never published.
• No Gemfile.lock / .ruby-version anywhere — CI floats Jekyll. master is protected:true with no actual rule.
• The team's _team/_data split already fails silently (orphan ymls, a corrupt _team/mhlaga, typo'd type drops people) — proof that "valid data" ≠ "correct site."

Narrow the central promise

"Editing can't break the site" = can't break the BUILD (schema validator) — not can't be WRONG (needs a semantic/referential tier + a preview, see #54). Narrow the wording with Carl or fund the extra tier.

Phase 0 — reproducibility floor + the pivotal decision (cheap, do now)

• Commit .ruby-version (3.3) + Gemfile.lock (pin Jekyll ~> 4.3).
• Footer copyright year from build date (kills the ©2016-2023-for-3-years bug class).
• Delete corrupt _team/mhlaga; reconcile 9 orphan ymls + typo'd type.
• Turn ON a real branch-protection ruleset on master.
• Delete the theme_experiment branch + phantom ~>0.1.3 pin.
• Carl's written call on topology (below) + slides scope + personnel system-of-record.

Phase 1 — explore (gates the architecture)

• Spike: inventory "what changes over time?" across clinics #53 — Inventory: what changes (schedule is draft 2015 mmdd schedule #1)
• Build the data loop: flat data files, edited directly, validated in CI (schedule first) #54 — Flat-data → validate → render loop (+ semantic tier + preview); MMED 2025 first
• Substrate: stay on Jekyll, adopt the updated interface #55 — Substrate: stay Jekyll, adopt the updated interface; add the reproducibility floor
• Design axis: scale to many semi-autonomous clinics #56 — Decide topology + a safe template/data sharing prototype (not an unpinned hash-rebuild)
• Spike: slides — themeable decks + the auto-ingest question #57 — Slides as a separate epic: ingest feasibility probe + branded Slides template

Phase 2 — implement (after the loop proves out)

Per-cohort facts → data; split-done-right (pinned, data-stripped shared theme + separate personnel artifact) or monorepo; reconcile/retire the existing gem; convert the schedule (MMED 2025 first, then the rest; importer emits TODO rows that fail validation); validator as a required check + branch protection.

Open decisions

• Topology (the pivotal one — needs Carl): Carl's notes lean split / decentralized, so lead with split-done-right (separate clinic repos, pinned data-stripped shared theme, separate personnel artifact, made safe with render-tests + canary + a named owner). Monorepo (clinics = folders + CODEOWNERS + one people repo) is the lower-maintenance alternative that dissolves the pinning/pub-sub machinery — offer it explicitly. See Design axis: scale to many semi-autonomous clinics #56.
• Which programs are active; repo privacy/plan.