Source: https://guthlabs.ai/docs/field-guides/cloudflare-operations/forms/ field guide / candidate # Cloudflare operations โ€” forms The distinct forms record for Cloudflare operations. This page is proposal-only. Status: **proposed**Lifecycle: **candidate** ## Record status **Record ID**: field-guide:cloudflare-operations **Parent lifecycle**: candidate **Page lane**: plan **Lane lifecycle**: proposed **Owner**: Stan **Owner role**: Not separately recorded **Owner status**: Not separately recorded **Qualification result**: NOT RUN ยท held for evidence and human review **Working browser surface:** [Field guides โ€” documentation]() โ€” Inspect the guide and persist local checkpoints. This route is local-only; provider, credential, database, customer, publication, deployment, and production effects remain held. ## Proposed form sections Each section is a candidate schema for inspectable records. Required-field presence does not establish factual truth. ### Scope and authority Define the operational question and prevent unsupported assumptions about Cloudflare or production access. - request title - requesting team or agent - operational objective - systems or surfaces in scope - systems or surfaces explicitly out of scope - claimed access status: unknown, held, or verified by supplied evidence - permitted local actions - prohibited external actions - human decision owner ### Source and evidence Bind every operational assertion to supplied source material or a recorded local artefact. - source record ID - source locator - source SHA-256 if available - evidence description - evidence origin - evidence capture time - revision identifier - provenance notes - visibility classification - linked file-reference IDs ### Proposed change or investigation Describe the proposed operation without representing it as executed. - operation type - affected hostname, zone, route, policy, or asset if supplied - current known state - desired state - assumptions - dependencies - risk level - rollback concept - verification criteria - external-effect status: held ### Workback and ownership Create explicit review points and accountable handoffs. - target review date - internal preparation deadline - evidence freeze deadline - security review deadline - approval deadline - handoff deadline - task owner - reviewer - escalation contact or role - recurrence candidate ### Receipt and closure Preserve a deterministic record of what was reviewed, what remains held, and why the guide is complete or blocked. - receipt ID - decision state: Needs review, Approved, or Held - reviewer identity - review timestamp - accepted evidence IDs - rejected or missing evidence IDs - open failure branch - next action - next deadline - closure notes ### Accessible state contract - Every field requires a visible and programmatic label. - Required and optional fields must be stated in text. - Invalid entries require an actionable message linked to the field. - Blocked and Held states remain visible without relying on color alone. ## Supporting documentation fields These fields come from the tools lane and remain separate from the primary operating form. ### Scope and ownership Define the operational question, responsible person, and authority boundary. - operation title - requester - owner agent - related job - environment label - systems or zones in scope - explicit non-goals - authority boundary ### Evidence intake Capture only supplied, source-labelled evidence and its provenance. - evidence description - source locator - source SHA-256 - capture time - observed status or headers - local file reference - visibility classification - known gaps ### Assessment and failure state Separate observed facts from hypotheses and document safe handling of uncertainty. - observed fact - hypothesis - impact statement - severity - failure state - reproduction or verification steps - rollback or containment plan - accessibility and communication needs ### Workback and review Turn the bounded procedure into owned, deadline-aware work without hidden automation. - next action - owner - priority - dueAt - dependency - recurrence candidate - review checkpoint - approval required - completion state ### Receipt and handoff Preserve a deterministic record of what was reviewed, held, approved, or completed locally. - record ID - linked records - instrument outputs - decision - approval state - external effect status - remaining risks - handoff recipient - revision ## Required or proposed record references No record existence is asserted by this documentation page. - Source record for field-guide:cloudflare-operations with canonical ID and source locator - Operational scope note identifying the requested Cloudflare-related task - Source-labelled evidence or file-reference records for supplied artefacts - Notebook to-dos for review, verification, and handoff deadlines - Approval record for any proposed decision or external effect - Receipt-backed handoff record owned by the responsible specialist app or agent - Agent log recording authority boundaries, current state, and unresolved failures - source-labelled incident or operations note - linked local file references for supplied evidence - bounded to-do record with dueAt, priority, tags, and review state - approval record for any proposed external change - agent-log receipt identifying authority, evidence, and outcome ## Sources and evidence These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment. - `source_record:field-guide:cloudflare-operations` - `field-guide:cloudflare-operations` - `agents/index.html#stan` - `Observed native contract: project_and_field_guide_collections` - `Observed native contract: deadlines` - `Observed native contract: records` - `Observed native contract: pointguard` - `/app/notebook/field-guides/` - `/app/notebook/notes/` - `/app/notebook/files/` - `/app/notebook/to-dos/` - `/app/notebook/approvals/` - `/app/notebook/agent-logs/` - `/app/pointguard/` - `/app/notebook/messages/` - `/app/notebook/search/` - `http-status-code-header-lookup` - `checksum-verifier`