Public explainer ships at a stable URL with description, mechanic, and example output

### Summary -- What & Why

Ensure the explainer is authored and present in a dedicated branch so it can be shipped independently of the runtime product. Without an independent branch containing the explainer, the KR cannot be completed and the explainer may break if the runtime regresses.

### Acceptance Criteria (pre-merge)

- [ ] A new dedicated branch exists in the repo that contains the explainer content as static files
- [ ] The explainer content on the branch includes: a product description, a statement of the product's primary mechanic, at least one reference to an example output asset, and a methodology paragraph of at least 80 words
- [ ] A PR is open for review that adds the branch content and documents the intended stable URL and deployment target

### Acceptance Criteria (post-merge)

- [ ] Nightly job can GET the explainer stable URL and receives HTTP 200
- [ ] Nightly job confirms the page body contains a product description, the primary mechanic, a methodology paragraph of >=80 words, and a link to an example asset that resolves HTTP 200

### Prerequisites for Autonomous Execution

- Human configures the chosen-product subdomain routing in the hosting provider (DNS/Vercel/GitHub Pages) so the branch can be served at the stable URL

### Summary -- What & Why

Produce at least one concrete example output (image, JSON, or rendered HTML snapshot) and add it as a static asset referenced by the explainer so the public page can demonstrate real output. If example assets are missing or unreachable the smoke test will fail and users won't see concrete results.

### Acceptance Criteria (pre-merge)

- [ ] A static example output asset is committed in the branch and referenced by the explainer content
- [ ] The reference to the asset is a publicly resolvable URL in the PR description and explainer content (so reviewers can confirm it exists without deployment)

### Acceptance Criteria (post-merge)

- [ ] Nightly job GETs the example asset URL and receives HTTP 200
- [ ] Nightly job confirms the explainer page includes an embedded or linked example asset and that the asset content matches the committed sample (basic sanity check)

### Prerequisites for Autonomous Execution

- If the asset will be served from a hosted stable URL (subdomain), the hosting subdomain must be wired by a human to point to the branch/site

### Summary -- What & Why

Provide the explanatory copy that explains how and why the product works, including the schema/inputs/outputs or primary mechanic, and ensure the methodology paragraph is at least 80 words. Without clear methodology and mechanic content the explainer audit will fail and external readers won't understand the product.

### Acceptance Criteria (pre-merge)

- [ ] Explainer PR contains a clearly titled methodology section with >=80 words that explains how the product works and why, written in plain English
- [ ] Explainer PR contains a concise statement of the product's primary mechanic (schema/inputs/outputs or equivalent) separate from the methodology paragraph

### Acceptance Criteria (post-merge)

- [ ] Nightly job confirms the deployed explainer page contains the methodology paragraph and the mechanic statement as plain text and that the methodology paragraph length is >=80 words

### Prerequisites for Autonomous Execution

### Summary -- What & Why

Provide an automated check that validates the explainer page is reachable signed-out, returns HTTP 200, contains the required content pieces, and that example assets resolve. Without an automated audit, regressions can go unnoticed and the KR cannot be validated reliably.

### Acceptance Criteria (pre-merge)

- [ ] A runnable automated content-audit script/check is added that accepts an explainer URL and exits non-zero when any of the KR content rules are unmet (HTTP status, presence of description, mechanic, example asset link resolving HTTP 200, methodology >=80 words)
- [ ] Running the check locally against a failing HTML fixture visibly fails and against a passing fixture visibly succeeds (so reviewers can validate behavior)

### Acceptance Criteria (post-merge)

- [ ] Nightly workflow runs the content-audit against the explainer stable URL and exits 0 when the page meets all content assertions; the workflow records the result in CI logs
- [ ] Step-by-step nightly verification: 1) Nightly runner invokes the audit with the explainer URL, 2) Assert HTTP 200, 3) Assert presence of description, mechanic, and methodology paragraph >=80 words, 4) Assert example asset URL resolves HTTP 200

### Prerequisites for Autonomous Execution

- If the CI/nighly job needs an environment variable for the explainer URL, a human must add that secret/env var to the CI configuration after merge

### Summary -- What & Why

We do not yet have a standalone, static explainer that can survive product runtime regressions. Without an independently packaged explainer and at least one example output asset published in the repo/branch, the KR cannot pass the content audit and the explainer may disappear if the main runtime regresses. Creating the explainer and asset in an independent branch ensures the content is available for deployment and programmatic smoke tests even if other systems break.

### Acceptance Criteria (pre-merge)

- [ ] An independent branch named by $EXPLAINER_BRANCH exists in the repo and is reachable via the GH API: gh api repos/$GH_REPO/branches/$EXPLAINER_BRANCH >/dev/null && echo BRANCH_OK
- [ ] The explainer content file exists in that branch and contains the required sections (description, mechanic, example, methodology). Verify by fetching file contents via GH API and asserting keywords are present: gh api repos/$GH_REPO/contents/$EXPLAINER_PATH?ref=$EXPLAINER_BRANCH | jq -r .content | base64 --decode | grep -E "(?i)description" && gh api repos/$GH_REPO/contents/$EXPLAINER_PATH?ref=$EXPLAINER_BRANCH | jq -r .content | base64 --decode | grep -E "(?i)mechanic|schema|inputs|outputs" && gh api repos/$GH_REPO/contents/$EXPLAINER_PATH?ref=$EXPLAINER_BRANCH | jq -r .content | base64 --decode | grep -E "(?i)example" && gh api repos/$GH_REPO/contents/$EXPLAINER_PATH?ref=$EXPLAINER_BRANCH | jq -r .content | base64 --decode | grep -E "(?i)methodology|how it works"
- [ ] An example output asset file exists in that branch and its raw URL returns HTTP 200. Verify raw content URL resolves: curl -s -o /dev/null -w "%{http_code}" https://raw.githubusercontent.com/$GH_REPO/$EXPLAINER_BRANCH/$EXAMPLE_ASSET | grep -q 200 && echo ASSET_OK

### Acceptance Criteria (post-merge)

- [ ] After deployment to the chosen-product subdomain, the KR smoke test must pass: run the cycle's smoke test and assert exit 0: ./scripts/measure/measure-kr121.sh && echo SMOKE_OK

### Prerequisites for Autonomous Execution

### Summary -- What & Why

There is no automated, repeatable check that the explainer URL is public and contains the required pieces. Without a parameterizable smoke-test and CI enforcement, the page can regress or be mis-deployed without detection. Adding a targeted measure script and a CI job ensures the explainer content is validated automatically and will surface regressions before they block the KR.

### Acceptance Criteria (pre-merge)

- [ ] A parameterizable smoke-test script for KR121 is present and syntactically valid: bash -n ./scripts/measure/measure-kr121.sh && echo SYNTAX_OK
- [ ] The smoke-test script accepts an EXPLAINER_URL override and exits 0 when pointed at the raw explainer files in the independent branch. Run with the branch raw URL(s): EXPLAINER_URL=https://raw.githubusercontent.com/$GH_REPO/$EXPLAINER_BRANCH/$RENDERED_OR_MARKDOWN_URL ./scripts/measure/measure-kr121.sh && echo MEASURE_OK

### Acceptance Criteria (post-merge)

- [ ] A CI workflow triggers the KR121 smoke-test on pushes to the explainer branch and the nightly verifies the public URL. Verify by invoking the same smoke-test against the public stable URL (after DNS/Vercel wiring): ./scripts/measure/measure-kr121.sh && echo CI_SMOKE_OK

### Prerequisites for Autonomous Execution

- Human: wire the chosen-product subdomain to the static deploy target (Vercel/GH Pages) and provide DNS records or Vercel project access. This step cannot be completed by agents due to dashboard/DNS interactions.
- Human: confirm which public URL will serve the static explainer (provide value for EXPLAINER_PUBLIC_URL) so the CI job and nightly can target the correct domain