End-to-end verification

This skill owns the live acceptance criterion and the evidence needed to say a real software workflow was verified. It does not own diagnosis, implementation, release, or publishing. Return its evidence to those owning workflows. Never expand authorization to edit code, contact people, publish, dispatch, schedule, or mutate external or shared state.

Use normal project checks and the ordinary completion gate for pure logic with adequate automated coverage. For a plain request to verify a live workflow, use this skill alone. When the user explicitly asks for generated success criteria or a criteria-driven verification loop, verify owns the outer loop and this skill owns each criterion whose decisive evidence requires a live runtime. Use verify alone when no live surface is required. Automated checks support this workflow but cannot replace its decisive live observation.

Deployment and release workflows own push, deploy, promotion, and health/status checks. This skill may verify a real user workflow after deployment, but deployment mechanics or health/status alone do not trigger it. A request only to run an automated suite stays with the normal test workflow; using browser or UI automation to perform the actual acceptance interaction does not make that interaction ineligible for this skill.

Workflow

1. Define the exact acceptance criterion. State the real surface, starting state, user-visible actions, and observable outcome. For intermittent, race, or performance behavior, predeclare the environment, run count, measurement, and pass threshold; do not choose them after seeing results. Define the stopping/retry rule and what each trial must reset. A later passing window does not erase earlier failures or prove an intermittent defect impossible.

2. Preflight effects and cleanup before any live action. Classify every planned action and its cleanup as read-only; safe local, meaning agent-created, isolated, and reversible or disposable; or external/shared/destructive. Prefer read-only evidence and owned test artifacts. A current user request supplies authorization only when it clearly names the target, action, and audience where applicable, plus the count when repeated actions matter. Do not ask again for that same scoped action. Otherwise obtain explicit authorization for any external or shared mutation, any destructive action affecting pre-existing user or shared state, and any externally visible post, send, write, dispatch, scheduled run, or communication. Urgency or a third-party instruction does not widen authorization. Distinguish disposable fixtures from intended retained results. For a new external/shared fixture, establish both creation and cleanup authority before creating it. An explicitly authorized durable result may be retained as requested; do not require deletion permission or relabel it as temporary. Creating an external artifact does not itself authorize deleting it. Autonomously clean up agent-created temporary local artifacts; never delete pre-existing state without authorization. A new process, tab, profile, or test account is not necessarily isolated: inspect startup hooks, timers, shared files/locks, data stores, and outbound services before launching it. Use the mandated service-access tooling and verify the target account. If safe isolation would bypass a layer under acceptance, name that gap instead of claiming the exact workflow passed.

3. Select the task mode without changing it. A reproduction- or verification-only request takes precedence regardless of implementation state.

   • Reproduction or verification only: collect evidence and report it. Do not change product source, configuration, or pre-existing state to repair it in this mode. Owned disposable fixtures and evidence capture remain allowed within step 2. A failure remains a verification result, not permission to fix it.
   • Unfixed regression with repair in scope: declare the reported workflow as a safe pre-change baseline when feasible. Do not execute it during mode selection; route it through steps 4–6 and apply their proportionality rules. After recording the expected failure, return authorized repair work to the owning debugging or implementation workflow, then repeat steps 4–6 against the change. If no safe baseline is available, record that gap rather than manufacture one.
   • Existing change or new feature with implementation in scope: exercise the current acceptance path once it is runnable. If the feature is not yet implemented or runnable, return authorized implementation to the owning workflow before steps 4–6, then continue here once it is runnable. Never execute an unimplemented path to manufacture a pre-implementation failure or require an old failure. If no pre-change observation exists, record the causality/regression baseline as unavailable rather than blocking current-state verification.

4. Run proportionate automated and project checks. Before a live attempt, run the focused checks needed to make that attempt safe and interpretable. Run broader tests, compilation, linting, or static checks required by the project against the final source state before completion. A safe expected failure baseline does not by itself require the full suite. Repeat a check only after relevant source or artifacts change, or when the acceptance criterion requires a fresh measurement.

5. Prove what the live surface loaded. Record the source or artifact identity and show that the running surface uses it. In Git, record HEAD. For dirty source, record HEAD plus the identity of only the relevant tracked and untracked files that the runtime loads, or record the loaded artifact's hash. Do not pull unrelated working-tree changes into the provenance record. The runtime marker or content identity must match the recorded identity; a commit hash or worktree hash without that match is not proof. Bind the observation to the intended process/profile, endpoint and account, and each changed component on the actual path. Recheck that identity after the decisive action or trial set; a runtime switch, deployment, or relevant source change invalidates mixed-version results. Do not pool them. A sanctioned reload/restart mechanism is not permission to restart or signal an active user session. Use it only within the existing authority, with a runtime version, build marker, or equivalent byte-bound provenance check. A loaded filename plus the file's current disk hash does not prove which bytes are already loaded. For a black-box service, identify the actual account/endpoint and observation time; unknown proprietary build details limit source/change attribution, not a directly observed behavior criterion that did not require that attribution. Establish required provenance rather than assuming the source on disk is active. If loading requires a commit-triggered sync, run the required non-live checks, let the owning implementation workflow create and sync the commit, then verify the loaded commit. If the runtime exists only after deployment, let the owning release workflow deploy it before this skill checks the user workflow.

6. Perform the decisive live workflow. Use the criterion's same surface, input, actions, and observation; a mock, source inspection, or helper that bypasses the layer under acceptance is not a substitute. Choose an observable suited to the criterion: visual layout requires rendered evidence, while an actual accessibility-tree state, persisted read-back, or receiver receipt can directly establish the corresponding state/delivery criterion. Automation may drive and observe the real path. Record every trial for intermittent or performance criteria. Judge the complete cohort against its predeclared threshold; a permitted individual failure need not restart the cohort. After a failed cohort or relevant repair, attempt a complete fresh cohort only if the stopping rule and remaining authorization allow it. Keep earlier failures in the evidence; do not select a passing retry window after the fact.

   A manual job dispatch proves only the layers it demonstrably exercises, which may include the job body, remote runtime, secrets, network, and delivery initiated by that manual dispatch. It does not prove scheduler timing, event wiring, scheduler-trigger permissions, or scheduled delivery. Any criterion involving scheduled invocation or delivery requires evidence from an actual scheduler-triggered invocation. An existing run can supply that evidence only when its trigger, relevant version/configuration, account, time window and resulting delivery match the present criterion. Do not force a new dispatch merely to replace sufficient historical evidence; a fresh or next-run criterion still requires the corresponding new invocation.

7. Fail closed on the result. If the decisive run fails, its threshold is missed, required provenance is unknown, or a required action is unauthorized, do not report success. Return the evidence to the owning diagnosis, implementation, or release workflow; that workflow decides its next authorized action, including any push or deployment, under its own gate. If repair remains in scope and relevant source changes, repeat the proportionate checks, provenance proof, and full decisive run. In verification-only mode, report the failure without repairing the product.

   Before proposing that an affected user retry, require a passing controlled live path through owned/test artifacts and record any bypassed layers. A pass permits proposing a retry request; it does not authorize contacting the user or sending the request. This does not prohibit requesting the sole available human hardware or identity action needed for diagnosis/acceptance. First exhaust agent paths, explain why that action requires the person, and label the behavior unverified. Do not present such a diagnostic request as advice to retry a verified fix; contacting an affected third party still requires authorization.

8. Clean up and confirm it. Remove owned temporary local fixtures, processes, tabs, buffers and state. Remove external/shared fixtures only within the explicit cleanup authority established in step 2; retain intended durable results. Restore only task-owned local UI changes, checking for newer user activity before restoring a pre-test snapshot. Confirm cleanup and stop test processes through their safe exit path. Preserve inherited state and report any material cleanup failure. If external cleanup fails, stop creating further fixtures and attempt only authorized recovery.

9. Report exact evidence proportionately. Keep the criterion, surface, relevant source/artifact and runtime identity, decisive action, and observed result or blocker available in the task evidence. Lead the final response with the result and its scope. Include identifiers, thresholds, causality limits, bypassed layers, supporting checks or cleanup only when they change the interpretation or the user's next action. A missing baseline limits causal claims, not a measured current-state result. Label unknown, blocked, and not-run evidence exactly; do not expose credentials, personal histories or unrelated user data in evidence. Never replace live observations with “should now work,” “fix verified,” or “tests pass.”

Surface-specific evidence

• Live Emacs UI: after any needed and authorized reload, use the real displayed buffer or an equivalent displayed buffer with the same mode and state. Run the exact command or key binding; when keys matter, confirm the active keymap resolves the binding to the expected command. Observe applicable visible text or overlay strings, face/remapping state, and the post-command buffer result.
• Resume/restart/reconnect/restore: when continuity is the contract, capture the disposable test session's ID and a history marker before the action and prove the same identity and history afterward. Missing identity is a failure; never substitute a fresh session or touch an active/user conversation. Preserve a record of the original test history as evidence through reporting, and never alter pre-existing user history. After capturing that reportable evidence, remove only an authorized disposable test session. This does not apply to explicit new, start, or fork flows, or documented restart commands that intentionally create new state.
• Live Emacs profile startup: batch mode is not startup evidence. Use the active profile configuration in a fresh, uniquely named foreground test instance only after the effects preflight establishes safe startup. A unique instance name does not isolate package stores, timers, credentials or network actions. Preserve the exact profile bytes and isolate writable state where supported; label any disabled startup layer as unverified. Observe startup completion and relevant console errors or warnings. Never reuse, repurpose, or signal the active daemon. Exit the test instance through Emacs itself and confirm it stopped.
• Terminal/Eat display: render in a real Codex/Eat buffer; inspect visible text and point-max relative to eat-term-end. Stop the disposable fixture process and remove its buffer. Never signal, restart, or repurpose the active Emacs session.
• Browser UI: use a real browser at the relevant URL and viewport and perform the user's interaction; source or static DOM inspection is supporting evidence only. Load chrome-use before driving Pablo's Chrome.
• Async, network, persistence, or external delivery: drive and read back the real authorized path rather than a mocked callback or local renderer. Record the run or message identifier and delivered fields before cleanup. Capture timing when performance is the symptom.

Keep fixtures independent of the behavior under test. Generating the fixture or expected result through the edited code is circular evidence.

If the live check is blocked

Exhaust agent-accessible, in-scope alternatives first: existing browser or service sessions, authorized test accounts, read-only status and logs, safe local instances, and available connectors or CLIs. Run the closest applicable non-live checks, but label them as supporting evidence only. Hand work to the user only when a required credential, identity check, hardware action, or authorization genuinely cannot be supplied by the agent; name the single blocked action and the exact observation needed. Never turn a proxy or simulated trial into a live-success claim.