chore: Stop tracking the _site build output

[DannyvdSluijs]

Stacked on #20 — please merge that first. GitHub will retarget this to main automatically once it lands.

Why

CI builds the site from source on every push to main (hydephp/action runs php hyde build, then uploads _site), so the committed output is never read by the deploy. Tracking it costs us churn and merge conflicts on generated HTML, and lets source and output diverge — #19 merged docs source without rebuilding _site, and the output differs depending on whether SITE_URL is set at build time.

The stale files actually reach production

Hyde's CleanSiteDirectory pre-build task calls:

Filesystem::unlink(Filesystem::findFiles(Hyde::sitePath(), ['html', 'json'])->all());

findFiles() defaults to $recursive = false and is never passed true, so "Removing all files from build directory" only clears top-level _site/*.html — never _site/docs/. Committed files in subdirectories survive the clean and get uploaded with the artifact.

That is why these two are live today despite having no source in _docs/:

URL	Status	Source?
/docs/docs/community-guide.html	200	none
/docs/docs/configuration.html	200	none

Untracking removes them from the next deploy. Worth re-checking both return 404 after this merges.

Change

Uncomments the /_site rule already present in .gitignore and drops the directory from the index. Local build output is left on disk; use php hyde serve to preview.

Tradeoff

Nothing in the repo will show the built site anymore, so a template regression surfaces only on deploy or via a local serve. If that is a concern, the follow-up is a PR build-check job (hydephp/action with deploy-to: artifact) — happy to open that separately.

🤖 Generated with Claude Code