← Operations Web Function

Change Web Production Skill

CANDIDATE INTERFACE · Operations Web Function 0.1.0. Plan and execute an authorized website production change with an exact diff, approval digest, least privilege, backup, precondition, lease, idempotency key, canary, halt conditions, rollback, and independent read-back. Use when publishing or editing pages, updating CMS components, repairing an incident, migrating a site, changing redirects, DNS, analytics, forms, schema, access, or scheduling bounded fleet-wide web work.

Canonical owner: operations-web-function:change-web-production · Task registration: NOT_A_BOUNDED_TASK

Broader definitive hub · Exact Task Library page: NOT_A_BOUNDED_TASK

Download the complete plugin · Source skill SHA-256: 0df90e2c4e04b58fc42d0da1dbabd2f5ee34dce1178669a9204a1f73a1dd17a7

Candidate source: dennisyu/blitzmetrics-skills · commit: PENDING_MERGE · path: skills/change-web-production/SKILL.md

Production writes are explicit state transitions. The writer must be able to state the desired state, prove the precondition, apply the change once, and show how an independent verifier decides whether to keep or roll it back.

Before approval

  1. Resolve the target and production surface from $inventory-web-properties.
  2. Preserve incident evidence first when applicable.
  3. Capture a before fingerprint and backup or export reference.
  4. Write the exact intended diff, blast radius, capability, dependencies, canary, halt conditions, verification steps, and rollback.
  5. Calculate the plan digest and obtain the approval required by policy. A material plan change invalidates that approval.

A request such as “fix every site now” expresses intent, but it cannot approve a fleet plan whose targets, exact diff, cohorts, rollback, and digest do not yet exist. Create the plan, then obtain approval for that plan.

Execute once

  1. Acquire the (target, surface) write lease with TTL and heartbeat.
  2. Check whether the idempotency key already has a successful receipt.
  3. Re-read the precondition immediately before mutation.
  4. Apply one bounded change through the least-privilege adapter.
  5. If the response is lost or times out, read production back before deciding whether to retry.
  6. Invoke $verify-web-outcome through an independent path.
  7. On failed verification, stop the wave and execute or request the declared rollback.

Fleet changes

Proceed canary → small bounded cohort → next cohort → fleet. Each wave requires a verification receipt. Do not infer that a canary on one host proves a different host, template, plugin version, or environment is safe. One active writer owns a surface at a time.

Receipt

Record target, plan and approval digests, actor and capability, before hash, backup, action, adapter response, independent verification, rollback result, unknowns, next check, and public/private classification. Never store the credential value. From the plugin root, use schemas/change-plan.schema.json.

The change is not complete because an API returned success or an agent said “done.” It is complete only when $verify-web-outcome proves the Definition of Done or the rollback restores the precondition.

This is a generated candidate implementation page, not automatically a definitive article or accepted Task Library task. It delegates to the named canonical owner until reviewed registration and merge receipts exist.