# Canopy Static Site Operations Runbook

This runbook covers operational handling for the `canopy-lang-site` static
landing page. It is limited to documentation, local validation, deployment
checks, rollback steps, and handoff boundaries for site updates.

This runbook does not change hosting, DNS, analytics providers, the Tailwind
CDN dependency, runtime behavior, or legal copy. It also does not create
uptime, response-time, commercial support, or compliance commitments.

## Scope and Guardrails

Use this runbook for changes to `index.html`, `README.md`, and repository
documentation that affect the public static site.

Evidence links:

- [README deploy instructions](../README.md#deploy-vercel)
- [security reporting path](../SECURITY.md)
- [secrets hygiene guidance](security/secrets-hygiene.md)
- [B2B readiness gap map](b2b-readiness-gap-map.md)
- [critical workflow smoke test](../tests/critical-workflow-smoke-test.sh)
- [B2B readiness validation](../tests/validate-b2b-readiness-test.sh)
- [secrets hygiene validation](../tests/validate-secrets-hygiene-test.sh)

Do not add deployment credentials, private operational contacts, production
analytics identifiers, live customer information, or external-provider
configuration to this repository.

## Static Build Validation

The site has no build step. It is a single tracked static HTML page with CDN
delivered Tailwind, as documented in `README.md`.

Before deployment or release handoff, run the static-site merge-gate command
exactly:

```bash
test -n "$(git ls-files "*.html" "*.css" | head -n 1)"
```

For documentation changes that affect B2B readiness, operations, security, or
public critical-path wording, also run the focused shell checks listed in the
README local checks section.

## Deployment Checklist

Before deploying the static site:

1. Confirm the change is limited to static site files or documentation.
2. Confirm local checks pass, including the exact static-site validation
   command in this runbook.
3. Review `README.md` for the current Vercel deploy command and domain notes.
4. Confirm no DNS, hosting, CDN, analytics-provider, or runtime configuration
   file was changed by the release.
5. Confirm public links still point to the intended PyPI, source, changelog,
   and issue-tracker destinations.
6. Record any unresolved owner or support decision as pending review instead of
   publishing an operational promise.

## Rollback

Rollback is documentation and static-file scoped:

1. Identify the last known-good commit or deployment for the static site.
2. Revert the site or documentation change in git, or redeploy the previous
   known-good static revision through the hosting provider's normal project
   controls.
3. Run the static validation command and the relevant focused checks before
   handing the rollback off for deployment.
4. Re-run the smoke checks after the rollback reaches the public site.
5. If rollback requires DNS, hosting-provider configuration, analytics changes,
   or private operational access, stop and hand off to the responsible operator.

## Smoke Checks

After deployment or rollback:

1. Open the public site and confirm the landing page renders.
2. Confirm the page still shows installation guidance for
   `pip install canopy-lang`.
3. Confirm the synthetic-data quickstart remains clear and does not imply a
   production data-provider relationship.
4. Confirm links to PyPI, source, changelog, and issue tracking still work.
5. Run the local critical workflow check when validating the repository copy:

```bash
bash tests/critical-workflow-smoke-test.sh
```

## Analytics Ownership

Analytics ownership: pending review.

Until ownership is assigned, do not add analytics scripts, identifiers,
tracking pixels, dashboards, retention statements, or conversion commitments to
the site. If analytics are later approved, the owner category, data boundaries,
retention expectations, and review path should be documented before deployment.

## Dependency and CDN Review

The site currently uses Tailwind from `https://cdn.tailwindcss.com` to keep the
deployment static and build-free. That is an operational dependency and not a
completed security or production-readiness review.

Before relying on the site as commercial collateral, review whether to pin or
self-host the generated Tailwind CSS, or explicitly accept and monitor the CDN
runtime dependency. Any dependency decision should be documented in a pull
request and reviewed alongside the security reporting and B2B readiness docs.

## Incident Owner

The incident owner is the repository maintainer or static-site operator
category until a named public owner is approved. Do not publish private contact
details or provider access details in this repository.

Use these handoff boundaries:

- Static content defect: open or update a repository issue with the affected
  file, expected behavior, and observed behavior.
- Security concern: follow the repository [security reporting path](../SECURITY.md).
- Hosting, DNS, certificate, provider console, or deployment-access issue:
  hand off to the static-site operator category.
- Analytics, commercial support, legal, pricing, customer communication, or
  compliance decision: keep the decision pending review until the responsible
  owner category is assigned.

## Release Communication Boundaries

Commercial support ownership: pending review.

Release communication should stay limited to the repository change, deployment
status, validation result, and rollback status. Do not publish guaranteed
response times, uptime targets, commercial support terms, compliance claims,
customer commitments, or private escalation channels from this runbook.