Design — internal document space (board. + public.cloudbase.foundation)

Date: 2026-06-25 · Owner: Both (Jonathan = Cloudflare + Workspace/Drive + board-group; Claude = repo/site/theme build) · Status: Design approved — implementation plan pending Fulfills: the doc-space design referenced but never written in 2026-06-09-workspace-admin-audit-design.md (which assumed "11ty, no CMS, PagesCMS retired" — corrected here: non-technical editing brings a CMS back, so PagesCMS is revived, not deleted).

The need

Jonathan + Jacob want one place to store all internal CBF documents — IT plans, board agendas, operating budgets, proof of 501(c)(3) status, foundational docs (Theory of Change), etc. Today these are scattered (a git documents repo of mixed Markdown/HTML, plus ad-hoc files), with no access control and no friendly editing path for non-technical board/staff. This design gives the org a single, brand-styled, access-controlled document space that both technical and non-technical people can use.

Decisions (locked)

1. Hybrid store. Narrative/reference docs live as a built static site; living and binary files (budgets, working financials, board packets) live in a Google Shared Drive, which the site indexes and links to. Each content type in its best-fit tool.
2. Two tiers → two subdomains (not one site with path exclusions):
   • board.cloudbase.foundation — internal, entirely gated by Cloudflare Access → the board@cloudbase.foundation group. One blanket policy, no path exceptions to misconfigure (fail-safe — the reason subdomains beat a /public/* carve-out for a store holding budgets + legal docs).
   • public.cloudbase.foundation — public document store, ungated.
3. One repo, two builds. The existing documents repo is the single source of truth and single CMS surface. A top-level public/ subtree builds to public.cloudbase.foundation; everything else builds to the (gated) internal site.
4. Stack: Eleventy (11ty) + PagesCMS → Cloudflare Pages. Lightweight, free, GitHub-native, no hosted-CMS dependency; .pages.yml already exists (revive + update, don't delete). Non-technical editors edit in PagesCMS's browser UI.
5. Brand lives in a shared theme, not in each file. The design system currently embedded in each HTML doc (:root tokens --navy #0c2540 / --gold #c8a14a / --paper #f6f1e7; fonts Barlow Condensed, Newsreader, IBM Plex Mono; components .pill/.panel/.section; Mermaid) is lifted once into a shared 11ty layout. Routine docs are authored in Markdown and render through that theme → on-brand automatically; editors touch content, never CSS.
6. Showcase docs stay bespoke HTML. Highly-designed docs (tech/domain-map.html, tech/roadmap.html) remain hand-crafted HTML pages inside the same themed site — not forced into Markdown. Recurring branded components (status pills, panels, callouts) are exposed as 11ty shortcodes so editors can use them without writing HTML.
7. Repo-vs-Drive rule. Living/collaborative files (operating budgets, working financials, packet drafts) → Shared Drive. Final/static published artifacts (the 501(c)(3) determination letter PDF, signed final policies) → repo (version- pinned, directly servable, especially on the public tier).
8. Not the marketing site. public.cloudbase.foundation is a public document store, distinct from cloudbase.foundation (the Next.js marketing site). The marketing site simply links to public docs.
9. No Workspace automation. Drive use here is native folders + group sharing + hand-maintained index links. This explicitly does not revive the GAM / Workspace-admin tooling track (set aside in the rebrand work).

Architecture

documents repo  (one source of truth · one PagesCMS · shared brand theme)
│
├── public/  ─────────────────→  public.cloudbase.foundation   [ungated]
│     Theory of Change, 501(c)(3) letter (PDF), annual report
│
└── (everything else) ────────→  board.cloudbase.foundation    [Cloudflare Access → board@]
      it/  agendas/  tech/  research/  projects/  resumes/  foundational/(working)
      │
      └── file-index pages ──→  Google Shared Drive "CBF Internal"  (board@ permissioned)
                                 operating budgets (Sheets), board packets,
                                 working financials, signed forms (PDF)

• Internal site builds the full repo (it can also surface the public docs, same source) and is gated.
• Public site builds only the public/ subtree and is open.
• Drive is reached only via links on internal index pages — no API integration.

Components

1. The site (Eleventy)

• One 11ty project building the documents repo. Shared base layout carries the brand theme (extracted from the existing embedded <style>). Markdown pages render through it; bespoke HTML showcase pages live alongside as their own templates/pages.
• Two Cloudflare Pages deployments off the same repo: one builds the full site (board.*), one builds public/ (public.*). (Implementation detail — separate build configs/output dirs vs. two projects — decided in the plan.)
• Shortcodes for recurring branded components (pill, panel, callout) so non- technical Markdown stays on-brand without raw HTML. Mermaid preserved.

2. Editing (PagesCMS)

• PagesCMS configured via .pages.yml (revive + update for the new structure), GitHub sign-in, editing Markdown + frontmatter in-browser. Non-technical board/staff edit here; technical edits still go through git directly. Showcase HTML docs are edited as files (not via the CMS).

3. Living/binary files (Google Shared Drive)

• A Shared Drive ("CBF Internal"), permissioned to the board@ group, holds living budgets/financials/packets. Internal index pages on board.* link to the Drive files/folders. Editing happens natively in Google Sheets/Drive. Final static artifacts that should be publicly downloadable (501(c)(3) PDF) instead live in public/ in the repo.

4. Access control (Cloudflare Access)

• board.cloudbase.foundation: one Cloudflare Access application + policy allowing the board@cloudbase.foundation Google group (Google IdP). Blanket — the whole hostname requires auth.
• public.cloudbase.foundation: no Access app. Public.
• Shared Drive: Google-native sharing to the board@ group — independent of Cloudflare.

Content taxonomy

Theory of Change is public and board-approved 2026-06-25, so it ships on the public tier immediately.

Dependencies & sequencing

1. board@cloudbase.foundation Google group — create once; shared with the rebrand (board ACL) and audit workstreams. Membership = board + staff (one tier today).
2. DNS (Cloudflare, cloudbase.foundation zone) — board. and public. subdomains pointed at the Pages deployments.
3. Cloudflare Pages — one repo, two deployments (board = full build, public = public/ build).
4. Cloudflare Access — app + policy on board.* → Google IdP → board@ group.
5. Google Shared Drive "CBF Internal" — created, shared to board@.
6. Repo work (Claude): add the 11ty build + shared brand theme (extract embedded CSS), shortcodes, the public/ subtree split, port showcase HTML pages, update .pages.yml. Migrate existing content into the structure.

This work does not block on the domain-rebrand primary-domain flip; it can proceed in parallel.

Risks & rollback

• Internal leak via misconfig → mitigated by the two-subdomain split (blanket Access on board.*, no path exceptions). Verify with an unauthenticated fetch of an internal URL during rollout.
• PagesCMS friction for non-technical editors → pilot with one real editor on one doc before rollout; keep showcase/HTML docs out of the CMS to avoid confusion.
• Drive ↔ site link rot (hand-maintained) → keep index pages small and reviewed; acceptable given no automation by choice.
• Brand drift → eliminated by centralizing the theme; per-doc stylesheets removed as docs migrate.
• Rollback → all DNS/Pages/Access changes are revertible; the repo is the source of truth and unaffected by hosting changes.

Out of scope (non-goals)

• GAM / Workspace-admin automation (separate, set-aside track).
• Folding public docs into the cloudbase.foundation marketing site (it links instead).
• A third (staff-only) tier — board and staff are one tier today; revisit if that changes.
• Full-text search across Drive contents.

Open items (resolve in the plan)

• Exact two-build mechanic (two Pages projects vs. one project + branch/output split).
• Whether the internal site re-lists the public docs or just links to public.*.
• Migration order of existing documents/ content into the themed structure.