runbook: inspect Cloudflare wiki policy and rollback controls

[ss-o]

Outcome

Create a non-secret organization runbook for inspecting and safely rolling back the Cloudflare controls that affect the public Z-Shell wiki.

Owner: @ss-o

Related public implementation: z-shell/wiki#795

Read-only inspection scope

• Determine whether Cloudflare manages or modifies the wiki's robots.txt or content-signal behavior.
• Identify the supported Pages deployment rollback workflow and the evidence needed to select a known-good deployment.
• Determine whether path-level analytics can distinguish requests for discovery and machine-readable artifacts.
• Record the available log fields and retention period needed for release verification and incident diagnosis.

Runbook requirements

• Document the non-secret dashboard navigation and observation procedure.
• Record the rollback decision points, verification steps, and restoration procedure.
• Describe how repository-owned crawler/header policy is compared with deployed behavior.
• State what analytics or logging is unavailable rather than inferring account capability.
• Minimize collected data; do not log prompts, query text, or personal data.
• Require explicit maintainer approval before any Cloudflare setting or deployment is changed.

Security boundary

Do not place account IDs, tokens, private settings, secret values, internal hostnames, or screenshots containing sensitive account data in the issue or runbook.

Done when

• A maintainer can perform the inspection without changing state.
• The runbook identifies an owner and a tested review/rollback checklist.
• Public verification evidence can be recorded without exposing Cloudflare account details.

[ss-o]

Linear mirror created: ZSH-26 (Medium, 2 points, Todo), related to ZSH-25.

Live capability check on 2026-07-19 found no Cloudflare account connector exposed in the current Codex session despite the workspace guidance naming one. Public Cloudflare documentation research and a fail-closed runbook skeleton remain safe and actionable. Account-specific dashboard navigation, available analytics/log fields and retention, and a tested rollback require connected read-only Cloudflare access; unknown capability will be recorded as unavailable rather than inferred.

No Cloudflare setting, deployment, repository file, branch, or pull request was changed.

[ss-o]

Agent handoff — 2026-07-19 design research complete

GitHub: #459
Linear mirror: ZSH-26

Verified from current official Cloudflare documentation:

• Pages rollback targets are successful production deployments only; preview deployments are not eligible. A rollback changes production immediately, and a newer successful production deployment remains available for forward restoration.
• AI Crawl Control supports hostname/path filtering and robots.txt availability/directive evidence. A domain-scoped AI Crawl Control Read Only role exists, but this account's enabled surfaces and effective permissions have not been inspected.
• Web Analytics is client-side beacon data. It can filter by path for page views, but it is not authoritative evidence for requests to raw static artifacts such as robots.txt, llms.txt, or llms-full.txt. Cloudflare documents six months of Web Analytics access, with unsampled beacon data retained for seven days before aggregation.
• Pages Functions logs are live streams and are not stored; build logs diagnose deployments rather than ordinary static-asset requests.
• Exact HTTP path evidence may require advanced HTTP traffic analytics, Logpull/Logpush, or paid Log Explorer. Cloudflare documents HTTP logs as not retained by default for Logpull; when enabled they are queryable at least three and up to seven days, with Logpush recommended for longer periods. Availability, retention, plan, and authorization must therefore be recorded as observed facts, never assumed.
• No Cloudflare connector is available in this session, so live account inspection and rollback testing remain access-gated. No Cloudflare setting was read or changed.

Recommended v1 design: a capability-aware, read-only-first inspection runbook with a non-secret evidence template, public endpoint comparison, known-good production-deployment selection, an explicit maintainer approval gate, and an approval-only rollback plus forward-restoration procedure. Every dashboard/API capability is marked Available, Unavailable, Not authorized, or Not tested. Live walkthrough status stays explicitly unverified until access is connected.

Next gate: maintainer approves or amends this v1 scope; then write and review the design/spec and implementation plan before editing the public repository.