SB Sommar – Project Documentation

SB Sommar – Requirements: Build and Deploy

CI pipelines, lint gates, environments (local/QA/production), zero-downtime deploy, release docs, footer version, the docs site build.

Part of the requirements index. Section IDs (02-§N.M) are stable and cited from code; they do not encode the file path.

23. Event Data CI Pipeline — superseded by §50

§23.1–§23.13 are superseded — see Archived (superseded). §23.14 still applies to ci.yml.

23.0 Git history for branch comparison

CI workflows that compare the PR branch to main to detect changed files must check out with sufficient git history for the three-dot diff (origin/main...HEAD) to find a merge base. A shallow checkout (depth 1) is not sufficient.

32. HTML Validation in CI

The build generates HTML pages. Invalid HTML must be caught automatically before merge. This closes the CL-§5.1 gap.

32.1 Tool

HTML validation uses html-validate — a standard, offline HTML validator with configurable rules.

32.2 Scope

Validation runs against all .html files in public/ after the build step completes.

32.3 CI integration

A lint:html npm script runs html-validate on public/*.html.
The CI workflow (ci.yml) runs lint:html after the build step.
HTML validation failures cause the CI job to fail.
HTML validation is skipped for data-only commits (same condition as existing lint steps).

32.4 Configuration

The tool is configured via .htmlvalidate.json at the project root.
Rules must be tuned to accept the existing generated HTML without false positives. Overly strict rules that conflict with the project’s markup patterns must be disabled or adjusted.

33. CSS Linting in CI

CSS source files must be linted automatically before merge. This closes the CL-§5.2 gap.

33.1 Tool

CSS linting uses Stylelint with stylelint-config-standard as the base configuration.

33.2 Scope

Linting runs against all .css files in source/assets/cs/.

33.3 CI integration

A lint:css npm script runs Stylelint on the CSS source files.
The CI workflow (ci.yml) runs lint:css alongside the existing lint steps.
CSS lint failures cause the CI job to fail.
CSS linting is skipped for data-only commits (same condition as existing lint steps).

33.4 Configuration

The tool is configured via .stylelintrc.json at the project root.
Rules must be tuned to accept the existing CSS without false positives. Rules that conflict with project conventions (e.g. custom property patterns, selector patterns) must be disabled or adjusted.

40. Zero-Downtime Static Site Deploy

The static site deploy must use a staging-and-swap strategy that limits downtime to milliseconds. The build output is uploaded to a staging directory via SCP, then swapped into the live web root with server-side mv operations.

40.1 Deploy method (site requirements)

The static site must be uploaded to a staging directory on the server via scp over SSH, not via FTP.
After upload, an SSH command must swap the staging directory into the live web root (public_html).
The swap must preserve the hosting infrastructure domains/ directory inside public_html by moving it into the new release before the swap.
Downtime during the swap must be limited to the time needed for two mv operations on the same filesystem (milliseconds, not seconds).
Leftover directories from the previous release (public_html_old) and from any previous failed deploy (release_new) must be cleaned up automatically.

40.2 Build packaging (site requirements)

The build output must be packaged into a single tar.gz archive before upload, to avoid per-file transfer overhead.
The archive must be extracted on the server side into the staging directory.
The archive must be deleted from the server after extraction.

40.3 Secrets and configuration (site requirements)

The deploy must use the existing SSH secrets: SERVER_HOST, SERVER_USER, SERVER_SSH_KEY, SERVER_SSH_PORT.
A new secret DEPLOY_DIR must be added, pointing to the domain directory on the server (the parent of public_html).
The FTP static-site upload step and FTP_TARGET_DIR validation step must be removed from the workflow.

40.4 Unchanged behaviour (site requirements)

The server app deploy (FTP + SSH restart) must remain unchanged. Superseded by 02-§43.6–43.8: the FTP step is now removed; SSH restart is sufficient.
The build step (checkout, node setup, npm ci, npm run build) must remain unchanged.
The workflow trigger (push to main, paths-ignore data files) must remain unchanged.

40.5 Error handling (site requirements)

The SSH swap script must use set -e so any failing command aborts the deploy immediately.
If the swap fails mid-way, the state must be recoverable by a subsequent deploy (clean-up of stale directories at the start of the script).

41. Environment Management

The project uses three environments — Local, QA, and Production — deployed from a single main branch. Code changes are promoted to Production manually; event data reaches both environments immediately.

41.1 Environments (site requirements)

The project must define three environments: Local, QA, and Production.
QA deploys the full site automatically on every push to main.
Production deploys the full site only via a manual workflow_dispatch trigger.
Both QA and Production deploy from the main branch; no separate production branch exists.
Event data submitted via the API always commits to main, regardless of which environment the API runs in.

41.2 GitHub Environments (site requirements)

QA deploy secrets must be scoped to a GitHub Environment named qa.
Production deploy secrets must be scoped to a GitHub Environment named production.
Each environment must have its own independent values for: SITE_URL, API_URL, SERVER_HOST, SERVER_USER, SERVER_SSH_KEY, SERVER_SSH_PORT, DEPLOY_DIR. Production additionally requires: FTP_HOST, FTP_USERNAME, FTP_PASSWORD, FTP_APP_DIR, FTP_TARGET_DIR. QA no longer uses FTP secrets (see §43).

41.3 Reusable deploy workflow (site requirements)

A reusable workflow (.github/workflows/deploy-reusable.yml) must contain the shared build-and-deploy logic.
The reusable workflow must accept the environment name as an input.
deploy-qa.yml must call the reusable workflow with environment qa.
deploy-prod.yml must call the reusable workflow with environment production.
The original deploy.yml must be removed after the split is complete.

41.4 Event data deploy (site requirements)

When an event PR merges, event-data-deploy.yml must deploy the event data pages to both QA and Production in parallel.
Each parallel deploy job must build with its own environment’s SITE_URL and API_URL so that per-event page links point to the correct domain.

41.5 Hardcoded URL fix (site requirements)

The QR code URL in build.js must use the SITE_URL environment variable instead of a hardcoded domain.

41.6 CI workflow (site requirements)

ci.yml does not need environment-scoped secrets; its SITE_URL remains a repository-level secret.

41.7 Local development (site requirements)

Local development uses .env for all environment variables.
.env.example must document the environment management setup.

43. Replace FTP with SSH for QA Deploys

FTP transmits credentials in cleartext and requires a separate set of secrets (FTP_HOST, FTP_USERNAME, FTP_PASSWORD). The static site deploy already uses SCP/SSH. This section migrates the remaining FTP-based deploy steps to SSH for the QA environment, reducing the attack surface and the number of secrets to manage. Production remains on FTP until QA is validated.

43.1 Event data deploy — QA (site requirements)

The deploy-qa job in event-data-deploy.yml must upload event data pages via SCP over SSH instead of FTP.
The upload must use the existing QA SSH secrets: SERVER_HOST, SERVER_USER, SERVER_SSH_KEY, SERVER_SSH_PORT.
The target directory must be derived from DEPLOY_DIR (the same secret the full site deploy uses), with /public_html/ appended, instead of requiring a separate FTP_TARGET_DIR secret.
The upload must include the same files as today: schema.html, idag.html, live.html, dagens-schema.html, events.json, schema.rss, and per-event detail pages under schema/.
The FTP_TARGET_DIR validation step must be removed from the QA job.

43.2 API server deploy — remove redundant FTP step (site requirements)

The “Upload server app to FTP” step in deploy-reusable.yml must be removed.
The “Stage server files for upload” step must also be removed, since it only exists to feed the FTP step.
The SSH restart step (Deploy API via SSH) must remain unchanged — it already performs git pull and npm install, which is sufficient to deploy the API server.

43.3 Production — superseded by §50.5

§43.9–§43.10 are superseded — see Archived (superseded).

43.4 Documentation (site requirements)

docs/08-ENVIRONMENTS.md must be updated to reflect that QA no longer requires FTP secrets for event data deploy.
docs/04-OPERATIONS.md must be updated to describe the new QA event data deploy method (SCP instead of FTP).
The secrets schema in 08-ENVIRONMENTS.md must note which FTP secrets are production-only and which are shared.

43.5 QA FTP secret cleanup (operational)

After verifying the QA SCP deploy works, the FTP secrets (FTP_HOST, FTP_USERNAME, FTP_PASSWORD, FTP_APP_DIR, FTP_TARGET_DIR) should be removed from the qa GitHub Environment.
This is a manual step — no automation required.

44. PHP API for Shared Hosting

The Node.js API server (app.js) requires a Node.js-capable host with Passenger or a similar process manager. Loopia (the target webhotell) supports PHP and Apache but not Node.js. This section adds a PHP implementation of the same API so that the entire site — static files and API — can be served from a single shared hosting account.

The Node.js API is kept intact for local development and for any future host that supports Node.js.

44.1 PHP API endpoints (site requirements)

The PHP API must implement POST /api/add-event with the same request body, validation rules, and response format as the Node.js POST /add-event.
The PHP API must implement POST /api/edit-event with the same request body, validation rules, and response format as the Node.js POST /edit-event.
Both endpoints must return JSON responses with Content-Type: application/json.
A GET /api/health endpoint must return {"status":"API running"} for monitoring and deploy verification.

44.2 Input validation (site requirements)

All validation rules from §10 (required fields, type checks, length limits, YAML safety) must be replicated in the PHP implementation.
Camp date range validation (event date must fall within the active camp’s start_date..end_date) must be enforced.
Past-date blocking (§27) must be enforced for both add and edit.
Edit requests must require a non-empty id field.

44.3 Time-gating (site requirements)

The PHP API must enforce the same time-gating rules as the Node.js API (§26): submissions are accepted only when today falls within opens_for_editing..end_date + 1 day.
When outside the editing period, both endpoints must return HTTP 403 with the same Swedish error message as the Node.js implementation.

44.4 GitHub integration (site requirements)

The PHP API must commit new events to the active camp’s YAML file via the GitHub Contents API, using the same ephemeral-branch → PR → auto-merge pipeline as the Node.js implementation.
Edit requests must patch the existing event in the YAML file using the same field replacement logic as the Node.js patchEventInYaml.
The active camp must be resolved by reading source/data/camps.yaml from GitHub (not from a local file), using the same derivation rules as resolveActiveCamp.
YAML serialisation must produce output compatible with the existing data contract (05-DATA_CONTRACT.md).

44.5 Session cookies (site requirements)

The PHP API must read and write the sb_session cookie using the same format (JSON-encoded array of event IDs, URL-encoded) as the Node.js implementation.
Cookie attributes must match: Path=/, Max-Age=604800, Secure, SameSite=Strict, and optional Domain when COOKIE_DOMAIN is set.
Edit requests must verify that the event ID is present in the session cookie; return HTTP 403 if not.
The cookie is only set when the client signals consent (cookieConsent: true in the request body).

44.6 CORS (site requirements)

The PHP API must set CORS headers (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Allow-Credentials) for origins listed in ALLOWED_ORIGIN and QA_ORIGIN environment variables.
OPTIONS preflight requests must return HTTP 204 with the correct CORS headers.

44.7 Configuration (site requirements)

The PHP API must read configuration from environment variables with the same names as the Node.js API: GITHUB_OWNER, GITHUB_REPO, GITHUB_BRANCH, GITHUB_TOKEN, ALLOWED_ORIGIN, QA_ORIGIN, COOKIE_DOMAIN, BUILD_ENV.
On Loopia, environment variables are provided via a .env file in the API directory. The PHP API must load this file at startup if it exists.
GITHUB_TOKEN and other secrets must never appear in error responses or logs visible to end users.

44.8 File structure (site requirements)

The PHP API must live in an api/ directory at the project root, separate from the Node.js source.
Dependencies are managed via Composer (api/composer.json).
The directory structure must be: api/index.php (router/entry point), api/src/ (modules), api/composer.json, api/.env (not committed, git-ignored).

44.9 Apache routing (site requirements)

An .htaccess file in the api/ directory must route all requests to index.php (front-controller pattern).
The .htaccess must work on Loopia’s Apache 2.4 with mod_rewrite enabled.

44.10 Deployment (site requirements)

The deploy workflow must upload the api/ directory (including vendor/) to the server alongside the static site.
composer install --no-dev must run either locally in CI or the vendor/ directory must be included in the deploy archive.
The .env file on the server is managed manually — it is not part of the deploy archive.

44.11 Build integration (site requirements)

The build must set API_URL to point to the PHP API path (e.g. https://sbsommar.se/api/add-event) when building for environments that use the PHP API.
The existing Node.js API_URL format remains valid for environments that still use the Node.js API.

44.12 Coexistence with Node.js API (site requirements)

The Node.js API (app.js, source/api/) must remain fully functional and unmodified.
Local development continues to use npm start (Node.js).
The choice of API backend is determined solely by the API_URL environment variable in each GitHub Environment.

44.13 Documentation (site requirements)

docs/04-OPERATIONS.md must document the PHP API: directory structure, configuration, and how to set it up on a new host.
docs/08-ENVIRONMENTS.md must document the qa GitHub Environment (PHP on Loopia) and its secrets.
docs/03-architecture/ must note the dual API architecture (Node.js for local dev and Node.js hosts, PHP for shared hosting).

50. Docker-Based Event Data CI Pipeline

Event data validation (injection patterns, link protocol, length limits) runs in the API layer at submission time. Data that reaches git is already validated. The CI pipeline for event-data PRs provides a branch-protection gate, and a post-merge workflow builds and deploys event-data files.

§50.1–§50.7 (Docker image and build workflow) are superseded by §52 — see Archived (superseded).

50.3 Event data PR check (site requirements)

event-data-deploy.yml must contain a single job that logs “Validated at API layer” and passes.
The workflow must trigger on PRs to main with path source/data/**.yaml and only for branches matching event/ and event-edit/ prefixes.

50.4 Post-merge event data deploy (site requirements)

A workflow (.github/workflows/event-data-deploy-post-merge.yml) must trigger on push to main with path filter source/data/**.yaml.
The workflow must use the pre-built Docker image from GHCR instead of setup-node + npm ci.
§50.13 and §50.14 (pre-merge detect job) are superseded by §51 — see Archived (superseded).
The workflow must build the site using node source/build/build.js.
The workflow must stage only event-data-derived files for upload: schema.html, idag.html, live.html, dagens-schema.html, events.json, schema.rss, schema.ics, kalender.html, and per-event pages under schema/.
The workflow must deploy to QA via rsync in a parallel job.
The workflow must deploy to Production via SCP, skipped when the changed file belongs to a QA camp.

50.5 Production event data deploy method (site requirements)

Production event data deploy must use SCP over SSH.
The deploy must use the existing SSH secrets: SERVER_HOST, SERVER_USER, SERVER_SSH_KEY, SERVER_SSH_PORT, DEPLOY_DIR.
After validation, the FTP secrets (FTP_HOST, FTP_USERNAME, FTP_PASSWORD, FTP_APP_DIR, FTP_TARGET_DIR) should be removed from the production GitHub Environment. This is a manual step.

50.6 CI workflow for data-only changes (site requirements)

For data-only event changes (has_code == false), ci.yml must skip npm ci and npm run build, letting the job pass after the detect step.
Building event-data changes is the responsibility of the post-merge deploy workflow (§50.4).

51. Event Data Deploy — Eliminate Serial Detect Job

The post-merge event-data deploy workflow (§50.4) currently runs a serial detect job before starting the three parallel deploy jobs. This adds ~15 seconds to the critical path because the deploy jobs must wait for detect to finish before they can start. Each environment requires its own build (different SITE_URL and BUILD_ENV), so sharing build artifacts is not possible. Eliminating the serial dependency is the primary lever for reducing deploy latency.

51.1 Workflow structure (site requirements)

The post-merge event-data deploy workflow must NOT have a separate detect job that other jobs depend on.
Each deploy job must perform its own inline detection of changed event data files as its first step.
All deploy jobs must start immediately in parallel when the workflow triggers — no serial dependency between them.

51.2 Inline detection (site requirements)

Each deploy job must check out with fetch-depth: 2 to support HEAD~1..HEAD comparison.
Each deploy job must detect changed per-camp YAML files using the same git diff logic previously in the detect job: filter for source/data/*.yaml, exclude camps.yaml and local.yaml.
If no event data file changed, the job must skip build and deploy steps (exit cleanly).

51.3 Production QA gating (site requirements)

The production deploy job must additionally determine whether the changed file belongs to a QA camp, using the same camps.yaml lookup as the previous detect job.
If the changed file belongs to a QA camp, the production deploy job must skip build and deploy steps.

51.4 Superseded requirements

02-§50.13 (detect via HEAD~1..HEAD in a dedicated job) is superseded by 02-§51.2 and 02-§51.5 (inline detection per job).
02-§50.14 (QA detection sets is_qa output) is superseded by 02-§51.7 (inline QA check in production job only).

52. Replace Docker Container with setup-node + npm Cache

The post-merge event-data deploy workflow (§50.4) previously used a pre-built Docker image from GHCR to avoid running npm ci on every deploy. While this eliminated npm ci time, pulling the Docker image itself added ~20 seconds per job. Replacing the Docker container with actions/setup-node and the built-in npm cache achieves the same dependency-availability goal with lower overhead: cache restore takes ~2–3 seconds on cache hit, and npm ci --omit=dev installs four small production packages in ~3 seconds.

52.1 Dependency installation method (site requirements)

The post-merge event-data deploy workflow must use actions/setup-node@v4 with node-version: '20' and cache: 'npm' instead of a Docker container.
Each deploy job must run npm ci --omit=dev to install only production dependencies.
The workflow must NOT use a Docker container (container: key must be absent from all jobs).
The workflow must NOT require packages: read permission (no GHCR access needed).

52.2 Conditional vs unconditional installation (site requirements)

For the QA deploy job, setup-node and npm ci must be conditional on the gate step output — skipped when no event data file changed.
For the production deploy job, setup-node and npm ci must run unconditionally (before the gate step), because the gate step itself uses node -e with js-yaml to check QA camp status.

52.3 Superseded requirements

02-§50.1–02-§50.7 (Docker image and Docker build workflow) are superseded — the event-data deploy workflow no longer uses a Docker image.
02-§50.12 (workflow must use Docker image from GHCR) is superseded by 02-§52.1 (setup-node + npm cache).

60. Release and Deployment Documentation

Background

The project has a working CI/CD pipeline (QA auto-deploy, production manual trigger) but no contributor-facing documentation explaining the deploy flow, how to release to production, or who is authorized to do so. A new contributor who is not familiar with the GitHub Actions setup cannot determine how their changes reach users.

60.1 Contributor documentation requirements

The contributor guide (01-CONTRIBUTORS.md) must include a section explaining what happens after a PR is merged: QA auto-deploy for code, dual auto-deploy for event data, and manual trigger for production.
The contributor guide must link to the release guide for production deploy steps.

60.2 Environment protection requirements

The environments document (08-ENVIRONMENTS.md) must document the required reviewers configuration for the production environment.
The environments document must name the current production approver(s).

60.3 Release guide requirements

A dedicated release guide (09-RELEASING.md) must exist with step-by-step instructions for deploying to production.
The guide must cover: verifying QA, triggering the production deploy, verifying production, and rollback.
The guide must be usable without Claude Code — written for GitHub UI and standard CLI.
The guide must document release tagging conventions for milestones.

62.0 Motivation

QA testers and administrators need to confirm which version of the site is deployed. Without a visible version indicator, there is no way to know whether a deploy has completed or which build is currently live. A version string in the footer solves this with minimal visual impact.

62.1 VERSION file

The project root must contain a VERSION file with the major.minor version (e.g. 1.0). This file is the single source of truth for the base version.
Major and minor numbers are bumped manually by editing the file.

Every page that includes a site footer must display the version string in a <p class="site-footer__version"> element at the bottom of the footer.
The version text must be visually subordinate to the main footer content: smaller font size and reduced opacity.
Pages without a site footer (e.g. display mode) must not display a version string.

62.3 Version string per environment

Production: The version string must be the full semantic version derived from git tags, e.g. v1.0.4.
QA: The version string must include the full semantic version (matching the latest production tag) and the PR number from the merge commit, e.g. v1.0.4 – QA PR212. If no PR number can be extracted, the short commit SHA is used as fallback.
Local: The version string must include the base version and a Stockholm-timezone timestamp, e.g. v1.0 – Lokal 2026-03-02 14:30.
Event-data deploys: When BUILD_ENV is set but BUILD_VERSION is not (event-data deploys), no version string is rendered in the footer.

62.4 Automatic production tagging

Each successful production deploy must create an annotated git tag with the computed version (e.g. v1.0.4).
The tag must be created only after a successful deploy, not before.
If a tag already exists (re-run), the tagging step must skip gracefully.

62.5 Automatic GitHub Release on major/minor bump

When the first production deploy for a new major.minor version occurs (no prior tags with that prefix), a GitHub Release must be created automatically with --generate-notes.
Patch-only deploys must not create a GitHub Release.

62.6 Build integration

The build must accept an optional BUILD_VERSION environment variable. When set, it is used as the version string.
When BUILD_VERSION is not set and BUILD_ENV is not set (local development), the build must read the VERSION file and generate a local timestamp version.
The version logic must be in a separate module that can be unit-tested.

62.7 QA redeploy after production deploy

After a successful production deploy and tagging, the production deploy workflow must automatically trigger a QA redeploy so that QA runs the exact same build as production.
The QA redeploy must use the exact production version string (e.g. if production tagged v1.0.1, QA must also show v1.0.1). This makes it visible that QA is running the production release with no additional changes.
When the next PR is merged to main, the normal QA deploy (deploy-qa.yml) restores the QA-suffixed version string (e.g. v1.0.1 – QA PR217).

97. Project Documentation Site

97.1 Context

The project documentation in docs/ is structured Markdown covering contribution guidelines, requirements, architecture, data contract, operations, design, environments, releasing, and the traceability matrix. Reading it on GitHub’s file viewer works, but cross-file links render as raw .md file downloads in some contexts and searching requires opening files one at a time.

Publishing the same content as a small, read-only documentation site lets contributors and stakeholders browse the docs in a regular browser, follow internal links without friction, and link directly to specific sections when reporting issues or discussing changes. The documentation site is entirely separate from the main sbsommar.se site — it does not affect the camp website, the PHP API, or any existing deployment workflow.

97.2 Publication (site requirements)

The docs/ folder is published as a static website at a public URL hosted by GitHub Pages.
The documentation site is served from the main branch, mapped to the /docs folder, using GitHub Pages’ “Deploy from a branch” source.
A push to main that changes any file under docs/ causes GitHub Pages to rebuild and republish the documentation site automatically, without running the project’s own CI workflows and without manual intervention.
The documentation site is publicly readable. It exposes only files already present in the public docs/ folder of the repository; it does not surface files from outside docs/, repository secrets, or environment values.

97.3 Rendering (site requirements)

Markdown files in docs/ are rendered as HTML by GitHub Pages’ built-in Jekyll toolchain, with no custom build step or project-owned workflow.
Relative links between documentation pages written as [text](other-file.md) or [text](other-file.md#section) resolve correctly on the published site, so that navigation between docs files works without editing each link manually.
HTML comments used as inline requirement markers in the source Markdown (for example ) are preserved as HTML comments in the rendered output and are not visible to readers.

97.4 Landing page

The root URL of the documentation site renders docs/index.md as the landing page. The landing page lists every other Markdown file under docs/ (for example 01-CONTRIBUTORS.md, the 02-requirements/ index and its topic files, and the rest of the numbered docs) with a one-line description and a link to the rendered HTML page.

97.5 Constraints

The documentation site contributes no entries to package.json or api/composer.json.
No GitHub Actions workflow under .github/workflows/ publishes the documentation site; GitHub Pages’ built-in deployment is the only mechanism that builds it.
The deploy workflows for the main site and event data (deploy-qa.yml, deploy-prod.yml, deploy-reusable.yml, event-data-deploy.yml, event-data-deploy-post-merge.yml) do not interact with the documentation site or GitHub Pages; they target shared hosting only.
The documentation site uses the default *.github.io URL assigned by GitHub Pages; no docs/CNAME file is present.

97.6 Repository-root discoverability

README.md (the file GitHub renders on the repository home page) links to the documentation site’s public URL near the top of the file, before the developer setup section, so that a first-time visitor sees the link without scrolling past the marketing copy.
The documentation index in README.md lists every file currently published under docs/ (01-CONTRIBUTORS.md, the 02-requirements/ index plus its topic files pages-navigation.md, schedule-and-detail.md, add-edit-forms.md, event-data.md, build-deploy.md, caching-performance.md, platform-security.md, design-and-content.md, archive.md, then 03-architecture/, 04-OPERATIONS.md, 05-DATA_CONTRACT.md, 06-EVENT_DATA_MODEL.md, 07-DESIGN.md, 08-ENVIRONMENTS.md, 09-RELEASING.md, and 99-traceability.md), each with a one-line description and a link that works both on GitHub’s file viewer and on the rendered documentation site.

The landing page docs/index.md carries a banner near the top (above the documentation index) that links back to the source repository on GitHub, the rendered README.md on GitHub, and the GitHub issue tracker. The links target absolute https://github.com/moggleif/sbsommar URLs so they resolve identically whether the page is viewed on the published Pages site or on GitHub’s file viewer.
The landing page does not link to https://sbsommar.se (the participant-facing camp site). The §97.8 search-engine policy prohibits actively pointing search engines at the camp site from a publicly hosted Pages page.
The landing page’s main copy is project-technical: it identifies the page as the developer-facing documentation for a static-site project and points readers at README.md for additional context. It does not describe the camp’s purpose, audience, schedule, or any other content that the §97.8 search-engine policy keeps off search-engine result pages.

97.8 Search-engine and crawler policy

The published documentation site is intentionally hidden — it is discoverable only by direct link and must not appear in search engine results. This policy mirrors §1a for the camp site (sbsommar.se) but applies to the documentation site (https://moggleif.github.io/sbsommar/).
A docs/robots.txt file at the documentation site root disallows every user agent from every path (User-agent: * / Disallow: /).
Every rendered HTML page on the documentation site includes a <meta name="robots" content="noindex, nofollow"> tag in the <head> section. The tag is injected via Jekyll’s head-custom include under docs/_includes/. Both filename conventions are shipped (head-custom.html for Primer/Minima themes, head_custom.html for Cayman) so that the meta tag lands in <head> regardless of which default theme GitHub Pages selects.
No sitemap, Open Graph tags, or other discoverability metadata are added to the documentation site.