Launch hardened Mighty public status page

[masterfung]

Summary

• configure a dedicated public Upptime page for Mighty Website, API, and Scan Gateway
• remove upstream demo data and self-modifying/generated-graph workflows
• pin GitHub Actions, the monitor runtime, and static-site source to immutable revisions
• add an explicit STATUS_AUTOMATION_ENABLED launch gate and serialize all main writers
• add incident/maintenance operations, Cloudflare hosting, supply-chain, security, and SOC 2 evidence guidance

Security and reliability

• default GITHUB_TOKEN permissions remain read-only; production jobs request only short-lived Contents/Issues write or Contents write and consume no stored secrets
• production jobs skip unless the checked-in repository-variable gate is exactly true
• static builds use the upstream lockfile without credentials and apply a blob-checked compatibility patch
• Cloudflare security headers include CSP, anti-framing, MIME, referrer, permissions, and HSTS controls
• short/false-positive incidents are retained (skipDeleteIssues: true)
• the static shell reads live status, incidents, and maintenance from GitHub at page load, so incident updates do not wait for a site redeploy

Validation performed

• ruby scripts/validate.rb
• actionlint
• zizmor --min-severity high .github/workflows/
• git diff --check
• exact pinned status-page patch applies against v1.17.0
• isolated locked static build/export succeeds and contains Mighty assets, _headers, CNAME, 404.html, and main-branch data URLs
• Website, API, and Scan Gateway return HTTP 200 with configured API/gateway body assertions
• Ubuntu PR validation and secret-free static build pass

Launch state

This PR is safe to merge with production automation off. STATUS_AUTOMATION_ENABLED is explicitly false. After review, follow docs/HOSTING.md to enable the gated workflows, create Cloudflare Pages/DNS, run incident and maintenance tests, and retain launch evidence. No personal access token, SLA, or compliance claim is required or made.

[masterfung]

Temporarily reopening to trigger the newly enabled, read-only validation workflow.

[masterfung]

Launch safeguards now confirmed:

• repository Actions default token is read-only and cannot approve PRs
• Actions allowlist is GitHub-owned actions plus the exact pinned upptime/uptime-monitor and peaceiris/actions-gh-pages commits only
• STATUS_AUTOMATION_ENABLED is absent, so every production job remains gated off
• private vulnerability reporting is enabled
• the maintenance label exists
• Ubuntu configuration validation and the secret-free locked static-site build both pass: https://github.com/TryMightyAI/status/actions/runs/31542619111

Security-review blockers were addressed: main writers share one concurrency group; launch has a checked-in gate; maintenance/private reporting are launch controls; and the runbook explains that live status/issues are fetched at page load rather than waiting on the nightly static-shell rebuild.

[masterfung]

Security improvement after the previous note: the workflows now use GitHub’s short-lived per-job token and require no GH_PAT or other repository secret. The repository default remains read-only; only gated production jobs request Contents/Issues write (monitoring) or Contents write (publication). The validator forbids GH_PAT, secrets.*, and repository-metadata rewrites.

[masterfung]

Post-merge activation evidence:

• Uptime monitor passed with all three components healthy: https://github.com/TryMightyAI/status/actions/runs/31543048516
• Response-time writer passed using only the ephemeral job token: https://github.com/TryMightyAI/status/actions/runs/31543537496
• Pinned static build published gh-pages: https://github.com/TryMightyAI/status/actions/runs/31543419466
• GitHub Pages built the fallback branch successfully; history/summary.json and the generated client use main, with no upstream demo data
• main and gh-pages now enforce linear history and prohibit force-push/deletion, including for admins
• repository-level immutable-SHA enforcement, selected-action allowlisting, read-only defaults, private vulnerability reporting, and the production gate are enabled

status.trymighty.ai still needs the Cloudflare Pages/DNS attachment and TLS/header validation before the public control is declared launched. The API token available to this session has neither Pages nor trymighty.ai zone access, so no Cloudflare settings were changed.