Verify Web Outcome Skill

CANDIDATE INTERFACE · Operations Web Function 0.1.0. Independently read a website, deployment, repair, migration, access change, or public artifact back from the relevant production vantage and decide whether its Definition of Done is proven. Use after any web change, after a monitor recovery, before resolving an incident, when a write response was lost, or whenever someone reports completion without a reproducible receipt.

Canonical owner: operations-web-function:verify-web-outcome · 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: b14be1785b10149432da102958ec1613a0ea42f1670117d7dfedf6f6ae4850d9

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

Verification tests the desired state and original failure mode through a path that does not merely repeat the writer's completion response.

Build the verification matrix

Read the approved plan, source event, target, before evidence, and Definition of Done.
Name the independent vantage: public browser, crawler identity, anonymous HTTP probe, authenticated read-only connector, analytics debugger, DNS resolver, or second operator.
Test the exact changed surface and the original failure.
Test critical adjacent paths: navigation, redirects, forms, analytics, schema, media, authentication, mobile/layout, and crawler view as relevant.
Compare observed state to the exact expected state, not to a vague “looks good.”
Check monitoring coverage and the next scheduled observation.
Assign evidence tier and one result: VERIFIED, FAILED, or UNKNOWN.

Decision rules

VERIFIED: every required assertion passed from the declared vantage and no required evidence is unknown.
FAILED: positive evidence violates an assertion; stop a cohort/fleet wave and route rollback or repair.
UNKNOWN: the path was blocked, timed out, missing access, or otherwise inconclusive. Do not close or blindly retry the write.

A 200 status is not enough when the required result is correct content, working tracking, absent cloaking, restored forms, or removed persistence. A successful CMS response is not independent verification. A public page can pass while the internal incident remains open.

Output

Write an immutable verification receipt with assertions, vantage, exact observations, source and tool hashes, evidence tier, unknowns, result, rollback decision, owner, and next check. Link it to the write or incident receipt.

On a novel discrepancy, route $document-web-lessons. On a monitor alert, return to $triage-web-incidents.

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.