Sync pipeline

The push event creates a deployment record — that's the "building" row you see under Deployments, tied to the commit SHA it is processing.

The sync lists the repository tree and locates nookdocs.config.json. In a monorepo the folder containing the config becomes the base — everything else resolves relative to it, which is how subtree setups work without extra configuration.

The config is fetched, validated and stored before any page is read — it decides the contentRoot the rest of the run filters by. Validation never rejects a deploy: errors and ignored-key warnings go to the deploy log, and the site keeps serving the last good config for anything broken.

Patterns in a .nookignore file exclude matching paths from sync — gitignore syntax, relative to the base.

Only Markdown/MDX inside the content root becomes pages. Repo noise — README.md at the root, AGENTS.md, planning folders — never turns into a docs page by accident.

A normal push syncs only the files that changed in it — added and modified pages are re-fetched, removed pages are deleted, everything else is untouched. The first sync of a project, and a manual Resync, scan everything.

Each changed file's frontmatter is parsed and the page row updated — this is the moment a page's Updated date changes, search indexes the new text, and the URL starts serving the new content.

If the config names an api.openapi spec and this push touched it, the spec is re-fetched and re-parsed — that's what feeds the generated API reference and the playground. Untouched specs are left alone.

The record flips to ready with counts of what happened. The log keeps the per-file detail.