Exporting a Builder site to GitHub

Builder can export a site to a GitHub repository you own — every page rendered to static HTML/CSS, every asset committed, in a single atomic commit on main. Use it to keep an audited snapshot of what's published, host the site somewhere else, or hand the source to a developer who wants to take it further. Module data (CRM, accounting, etc.) stays in Turtini and is never written to the repo.

Prerequisites:
• Connect GitHub first — see "Connecting GitHub to your Turtini org"
• Org owner or admin role to trigger an export

To export a site:
1. Go to Websites → Sites and open the site card
2. Click "Export to GitHub"
3. Pick the target:
• Existing repo — Turtini lists repos you can push to (filtered by the scope you authorized: public-only or public+private)
• New repo — Turtini creates one for you. Pick the name and public/private visibility.
4. Click "Export"
5. The first export takes 5–30 seconds depending on site size. You'll see a progress indicator and then a "View on GitHub" link.

What ends up in the repo:
• /index.html and /<page>/index.html for every published page
• /assets/ — CSS, JS, images, fonts pulled from the site
• /forms.json — metadata about each form on the site (the runtime POSTs to Turtini)
• /sitemap.xml, /robots.txt
• README.md — auto-generated, links back to the Builder site

What does NOT end up in the repo:
• CRM data, contact records, accounting data, member-only pages, any module data
• Unpublished pages and draft content
• Member-only / authenticated-only pages (these stay in Turtini and the export omits them)

Forms still work after export:
The exported HTML embeds Turtini's public submitWebsiteForm endpoint URL on every form. Visitors filling out a form on the exported (static) site post back to Turtini and the submission flows through the same Submissions tab as if they'd used the Turtini-hosted version. No extra setup required.

Auto-export on publish:
Toggle "Auto-export to GitHub" on the site card. Once on, every page publish/edit re-exports the site to the repo automatically. A 5-minute per-site debounce prevents thrashing if you publish in rapid succession. Auto-export never blocks a publish — if GitHub is down, the publish still succeeds and the export is retried on the next change.

Re-exports:
The export uses the Git Trees API to assemble one commit that overwrites the previous tree on main — no branch noise, no force-pushes, no rebases. If you've made manual edits to the repo between exports, they will be overwritten. Exported repos are intended to mirror Builder, not be hand-edited.

Disconnecting / cleanup:
• Disconnecting GitHub stops future exports but leaves existing exported repos untouched
• Deleting the site in Turtini does NOT delete the GitHub repo — you delete that yourself if you want it gone
• Audit log under Audit → Logs has every export attempt with status and the resulting commit SHA

Static-safety guard:
Every Builder block carries a staticSafety classification — blocks that need server-side rendering (member-only content, live database queries) are flagged as not-exportable, and the export will refuse to run if a published page contains one. The export modal shows you which blocks are blocking, with a one-click "Replace with static alternative" link.

Roadmap:
• Phase 2 — per-module exporters (Runbooks → markdown, Articles → markdown, Decks → MDX) so non-site content can graduate too
• Phase 3 — pull-to-host: connect a GitHub repo and Turtini hosts those static files at your domain (the inverse direction; the "graduation path" for sites built outside Turtini)