Website and living documentation

The CriProx website is a small static site hosted on GitHub Pages at criprox.themanamarket.com. Its source lives in site/ beside the application on main. The website has its own dependency lockfile and output directory, and is never included in the Electron installer. GitHub Actions publishes a build artifact directly to Pages; no separate website or gh-pages branch is needed. Keeping the sources together lets a feature and its documentation ship in the same pull request.

Deployment and custom domain

1. Merge website changes into main.
2. Under Settings → Pages → Build and deployment → Source, select GitHub Actions.
3. Set Custom domain to criprox.themanamarket.com and enable Enforce HTTPS. These settings are already configured for this repository.
4. At the DNS provider, the criprox CNAME points to go2engle.github.io, without a repository path.
5. Open Actions → Website → Run workflow, leaving the branch on main, if a manual deployment is needed. Website changes deploy automatically after merge.
6. After the deployment completes, visit https://criprox.themanamarket.com/.

If Pages is enabled before the merge, the merge triggers the initial deployment automatically. The generator and local preview use / as the base path. Production builds default to SITE_ORIGIN=https://criprox.themanamarket.com, so canonical links, social previews, the Atom feed, the sitemap, and robots metadata all use the custom domain. The Website workflow uses these same defaults. Navigation, scripts, styles, screenshots, and guide links are rooted at /, with no repository prefix.

The domain binding lives in GitHub Pages settings. With this custom Actions publishing workflow, a CNAME file is not required and would be ignored by Pages; see the GitHub custom-domain guide. For another host or a project-path preview, override SITE_ORIGIN and SITE_BASE_PATH together when building, and use the same SITE_BASE_PATH when previewing.

Sources of truth

The guides describe the current project on main; the changelog describes each published release. There is no duplicate copy of feature documentation to maintain in the website. Markdown links between published guides are rewritten to the corresponding website pages. Source-only links continue to point to GitHub.

Automatic updates

The Website workflow rebuilds after canonical documentation or website changes reach main, when a release is published, edited, or deleted, and after a successful Release workflow. That last trigger is necessary because a release published with GITHUB_TOKEN does not start another release-triggered workflow. A daily reconciliation run catches missed external changes. Manual workflow runs are also available.

The release timeline contains stable, published releases only. Drafts and prereleases are excluded; installer builds must finish before the latest stable download links change. The generator fetches all release pages, removes commit hashes and duplicate entries, preserves issue links, and labels the existing categories as New, Improvements, and Fixes. It does not invent release prose or hide technical changes. Each timeline entry links to its version and date. Its heading uses a custom GitHub release title when present, otherwise the first feature subject (or the first change for a release without features). These headings come from existing notes and need no separate maintenance. Use readable Conventional Commit subjects, since Release Please turns those subjects into release notes. Release notes can also be edited on GitHub and the site will pick up those edits automatically.

Production builds fail if GitHub cannot supply release data, preserving the last deployed site instead of silently replacing it with an incomplete or stale release timeline. The published site makes no API calls from visitors and uses no external fonts or app dependencies. Navigation and release notes remain usable without JavaScript. A small local script enhances the native mobile menu with Escape, outside-click, link-selection, and desktop-resize dismissal. Desktop navigation uses inline links; below 768px it becomes a floating menu with the same destinations and support link.

Website changes and app releases

Website updates publish through the Website workflow independently of app releases. Use non-breaking chore(site):, docs(site):, or style(site): commits and PR titles for website changes. They must never produce application release notes or version bumps; do not use feat, fix, perf, !, or breaking-change footers. Keep app behavior changes in a separate PR with its own release subject.

The application package in release-please-config.json excludes commits confined to the site/ and docs/assets/ directories before calculating versions and generating release notes. These are directory prefixes, not file globs. CI additionally checks website PR titles, including website workflow changes and README updates accompanying website files. Mixed app and documentation commits remain eligible for app releases, so genuine app features are still released normally.

Adding a feature

Update docs/FEATURES.md or the relevant workflow guide in the same PR as the feature. Add a row to the README feature table when the capability belongs on the overview, and update the screenshot when the interface changes substantially. Those changes are published automatically on merge.

The CI documentation check requires a README or guide update for feat: pull requests that change src/, electron/, or public/. For an internal feature that needs no user documentation, a maintainer can apply the documentation-not-needed label, explain the reason in the PR, and rerun CI. Fixes should update documentation when behavior or instructions change, even though the check does not require a prose edit for every fix.

Automation publishes and checks documentation; it cannot reliably infer new behavior from arbitrary code changes. Contributors and coding agents remain responsible for describing features accurately.

Local preview

The website needs only its own small dependency set:

npm ci --prefix site
npm test --prefix site
npm run build --prefix site
npm run preview --prefix site

Open http://127.0.0.1:4174/. The build uses public GitHub release data; set GITHUB_TOKEN locally if needed to avoid the unauthenticated API rate limit. Never commit the token. The preview serves a snapshot of the generated files. After making changes, rebuild the site and restart the preview server to see the new output.

For a preview without network access:

npm run build --prefix site -- --offline
npm run preview --prefix site

Offline preview uses CHANGELOG.md and explicitly identifies that source on the changelog page. It is not used for production publishing. The generated site/_site/ directory is ignored by Git. Pull requests affecting the site get a website-preview Actions artifact; they never deploy to the public Pages site.