Source: https://guthlabs.ai/docs/field-guides/cloudflare-operations/steps/ field guide / candidate # Cloudflare operations โ€” steps The distinct steps 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. ## Ordered procedure - Create or locate the canonical field-guide record and preserve its source reference to agents/index.html#stan; do not replace the source with an inferred provider record. - State the operational objective, affected scope, and authority boundary in a source-labelled Notebook note. - Classify every requested action as local documentation, review, preparation, or external effect. Mark provider, credential, database, customer, publication, deployment, and production effects as held unless supplied evidence explicitly establishes otherwise. - Collect only supplied artefacts and create source-labelled file references beside the Notebook records; do not upload, copy to protected storage, or imply that a provider connection exists. - Record the known current state, desired state, assumptions, dependencies, risks, and rollback concept. Mark unknown values as unknown rather than filling them from convention. - Create bounded to-dos for evidence collection, security review, architecture review, SRE or incident review, approval, and receipt-backed handoff. Assign due dates and priorities without creating hidden automation. - Open a PointGuard contextual room for the current operational question and link the field guide, notes, files, to-dos, project, and agent log. - Prepare a change or investigation proposal with explicit verification criteria. Keep all messages as drafts and all agenda changes as drafts until a human owner reviews them. - Run the checkpoint review: confirm source provenance, scope, authority boundary, evidence completeness, accessibility of the record, and presence of a named owner for every open action. - If the proposal requires an unverified Cloudflare surface, credential, live provider state, customer data, publication, deployment, or production write, stop at Held and create a failure receipt with the missing prerequisite. - If evidence conflicts, preserve both revisions, identify the conflict, assign a resolver, and do not select a winner without human review. - If the evidence is sufficient for a local proposal but not execution, record the proposed state, verification plan, and rollback concept as a receipt-backed handoff to the responsible specialist owner. - Close only when completion criteria are met; otherwise retain the guide as proposed with an explicit next action and deadline. ## Deadline and chronology rules - Set a preparation deadline before the target review date; if no target date is supplied, leave the target date explicitly unknown rather than inventing one. - Set an evidence-freeze deadline before security and architecture review so later changes become a new revision. - Set security, architecture, and SRE review deadlines before any approval deadline. - Set the approval deadline before the handoff deadline; no external effect may be treated as approved merely because a to-do is complete. - For incidents or time-sensitive work, record the incident priority and next human check-in time in the to-do; do not imply live monitoring or automated escalation. - When a deadline is missed, mark the to-do incomplete or held, preserve the revision, and create a new next-action deadline rather than silently moving the old deadline. - Review recurrenceCandidate explicitly; never convert it into hidden automation without a human-approved record. ## Failure branches during execution - Treating the name Cloudflare as proof of a connected provider feature or live account. - Applying credentials, changing DNS, routing, security policy, access rules, deployment settings, or production configuration without verified authority and human approval. - Confusing a local prototype or index route with a canonical provider, database, customer, or production system. - Using stale, conflicting, unsigned, or incomplete evidence as operational truth. - Exposing private operational notes, credentials, customer references, or protected assets through public documentation or search. - Creating hidden automation from recurrence, deadlines, approvals, or PointGuard context. - Losing provenance, source hashes, revisions, or receipt links during handoff. - Declaring incident resolution, security qualification, deployment success, or rollback success without supplied evidence. - Relying on inaccessible files, unlabelled screenshots, or doorway documentation URLs as evidence. - Failing to provide keyboard-accessible labels, readable status distinctions, clear error text, and non-color-only indications for Held or Needs review states. ## 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/`