About this site

How publishing works

Publishing is a repository push, not a database edit. A project's pages and its manifest are validated together, uploaded to the content bucket, and then picked up by the next hub build or sync.

  1. Push

    A project repository pushes its rendered pages and a versioned manifest. The hub repository does the same for its own private pages.

  2. Validate

    The contract check verifies the manifest's schema, its declared paths and its source identity. A broken manifest stops the publish; it cannot produce a partially live project.

  3. Upload

    Validated objects go to the private content bucket under the project's prefix. Their bytes are not copied into the public build, and the public origin has no route to them.

  4. Sync

    The next hub build (or a manual sync) records the new objects in the private catalog. Projects and Calendar read that catalog, so the new page appears in the right project for the people whose groups may open it.

  5. Report

    The publish writes a status object with the time, commit and result. Admin shows it per project and flags a project as stale or failed, so a silent publishing failure is visible.

Pulled sources

Material that originates in another system can be pulled in through the same contract. The pull records where the bytes came from and treats them exactly like a satellite publish: validated, uploaded to the bucket, and never written to the public build.

The privacy model

  • Two outputs. The public build and the private build are separate. There is no route from the public site to a private object.
  • Styled 404. A forbidden private path and a missing one return the same response, so the gate is not an oracle for which paths exist.
  • Access rules. Access is decided per item, then source, then section, then the default rule. Groups and roles are stored in Firestore and changed only through the audited Admin area.
  • Leak check. Every public byte is scanned for the titles, summaries, slugs, routes and payload paths of private items. The check has a self-test that must go red on an injected leak.
  • Publish allowlist. Only an allowlisted project may publish to the public origin. Everything else stays behind the gate.
  • Private-link check. Every link in the private build must resolve under the gate's base, so a member never follows a link to a public 404 or another origin.

What the owner can see

Admin lists each project's last publish, its commit and result, and links to the run. A project that has not published recently is flagged stale; a failed publish is flagged failed instead of being hidden behind an empty page.