Verification Loop: From Local Checks to Target Acceptance

What it does

ECC’s verification loop sequences build, types, lint, tests, security checks and diff review. Its target-acceptance section makes an essential distinction: a local check can pass while the user-visible outcome remains unverified. The workflow labels target behavior VERIFIED, FAILED or NOT PERFORMED and links claims to observable evidence. This is useful for deployment and integration tasks where a successful command is only an intermediate state. The example command list is a starting point, not a reason to add tools or enforce an arbitrary coverage number on every repository.

When to use it

• Confirm a deployed API change through its public route after local checks pass.
• Review a patch before release without overlooking unrelated changes or leaked secrets.
• Report a blocked integration honestly when only a mock service was available.

Step-by-step workflow

1. Read the repository’s real validation commands and define the target behavior and environment the user expects.
2. Run relevant build, type, lint and test checks while preserving exit status and enough output to diagnose failures.
3. Inspect the diff for unrelated edits, credentials and incomplete error handling; apply focused fixes where authorized.
4. Exercise the actual target boundary, such as the public route or installed client, using a safe representative action.
5. Write a short evidence report distinguishing passed local checks, target acceptance, failures and checks not performed.

Example request

Verify the deployed webhook fix. Run this repository’s required checks, inspect the exact diff and confirm the production endpoint handles one signed synthetic event without creating a real order. Record the deployment identifier and response evidence. If production access is unavailable, mark target acceptance NOT PERFORMED even if the local suite passes. Do not truncate command output in a way that hides exit failures or claim a running process proves webhook processing. Include a rollback reference and leave unrelated files unchanged.

Worked example

A build and unit suite pass, and the service manager reports the process running. The public route still reaches an old deployment because a proxy points elsewhere. A verification report that stops at process status would incorrectly close the task. The target check instead sends a signed synthetic event through the same public boundary as the real integration and inspects its recorded result. If the request reaches the wrong version, acceptance is FAILED and the evidence identifies the routing gap. After repair, the same bounded check demonstrates the new behavior without using real customer data.

What you get

An evidence report containing commands and outcomes, a diff review, target acceptance status and unresolved limitations tied to the requested behavior.

How to evaluate the result

• Every completion claim points to the relevant observed result.
• Target acceptance is separate from local build and test success.
• Unperformed checks and material failures remain visible in the final report.

What you need

Repository validation instructions, access to the intended runtime and a safe way to exercise the target. Some production actions require separate authorization or fixtures.

Setup and activation

The reviewed ECC source provides an .agents skill layout. Consult the repository README for the chosen client, retain referenced supporting files and explicitly activate only the workflow needed. This catalogue read source files; it installed and executed nothing. Client compatibility depends on available tools and instruction loading, and was not runtime-tested here. Before installation, scan the exact source version, review permissions and use disposable non-sensitive examples.

Limits and considerations

A passing suite cannot prove untested infrastructure or business behavior. Piping output into a short preview can hide the original exit code. Coverage targets and scanner output are signals, not automatic release permission. Never turn a verification request into an unauthorized purchase or customer action.

Related workflows

• Use Security Review for reachable trust-boundary issues.
• Use Eval Harness when target quality needs repeated task measurements.

License and reuse

MIT in the selected SKILL.md and repository LICENSE. Preserve notices; external packages, services and example dependencies retain their own terms.

Further reading

• Reviewed skill at immutable commit
• Reviewed publisher README
• Reviewed MIT license