Cloudflare operations — steps

The distinct steps record for Cloudflare operations. This page is proposal-only.

Status: proposedLifecycle: 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/