The download includes the before, intentionally buggy and fixed JavaScript versions, their tests, a local verification script and recorded results. The CI workflow is a template; it has not been run in hosted CI.
Download verification examples (ZIP)Choose what each layer is allowed to decide
A parser establishes that input has valid syntax for its configuration. A linter applies selected rules. A project type checker uses the project’s type and dependency context. Tests execute assertions about behavior. A source-security scanner looks for supported vulnerability patterns. These are complementary checks, not interchangeable proofs of correctness.
Start with stable, actionable checks as mandatory gates. Keep model-only suggestions advisory until their consequences can be assessed. A model’s confidence cannot turn a failing behavioral assertion into success, and an empty model response cannot establish that a scan or review completed.
| Layer | Required evidence | Suggested initial role |
|---|---|---|
| Syntax or lint | Named command, configuration and exit result | Block on agreed diagnostics |
| Project tests | Assertions, revision and actual execution result | Block on failure or missing execution |
| AI review | Candidate finding and supporting context | Investigate; do not override checks |
| Human approval | Reviewed requirement, risk and remaining exceptions | Own the acceptance decision |
Use a small runnable project before adding infrastructure
The example under examples/cross-file-units uses only the Node.js standard library. Its catalog and invoice modules model a price-unit migration. The same four assertions run against the before, buggy and fixed versions. This avoids hiding the tutorial behind service accounts, dependency installation or a private repository.
Run node examples/verify.mjs from the project root. The script verifies expected process exits, records TAP output and hashes the six source modules. In our local run on Node.js v24.16.0, before and fixed passed all four contract tests; buggy failed two amount assertions. All six modules passed syntax checks. That is a local demonstration of these assertions, not a hosted CI result.
node examples/verify.mjs
node --test examples/ci-gates/gate.test.mjs
FIXTURE_VERSION=fixed node --test examples/cross-file-units/contract.test.mjsKeep the first workflow intentionally narrow
The companion quality-workflow.yml has a syntax branch, a test branch and a final quality gate. It is stored in examples rather than .github/workflows so publishing a tutorial does not silently enable remote automation. Copy it into a repository you control, review the action references and adapt it before relying on the result.
The syntax branch runs node --check on the two fixed modules. It is deliberately a parser check, not a full linter, security scan or type checker. The test branch runs the fixed contract and gate-policy suites. For a real application, add your existing package installation, build, type-check and relevant tests; do not imply these two small commands cover a production codebase.
The example uses pull_request, pushes to main and merge_group triggers, read-only contents permission, pinned action commits and no model credentials. Its action references were checked against the official repositories. We have not verified the hosted runner execution, repository settings or protected-branch behavior in a live destination.
Make a required gate require success
Producing a report and blocking a merge are separate operations. Configure the destination repository to require the named final gate. Then run a deliberate failing pull request and confirm that the intended merge path is blocked. Review who can bypass that rule and how an exceptional bypass is recorded.
GitHub documents that some skipped or neutral outcomes can satisfy required-check handling. Our proposed gate therefore explicitly requires upstream success rather than treating the absence of a failing report as permission to proceed. The example gate runs with always() and tests the aggregate checks result. Confirm that this behavior still matches your workflow when you add jobs or conditions.
A required workflow must also be triggered for the changes it is meant to protect. Broad path filters or inconsistent check names can leave a workflow pending or omit evidence. Test the configuration in the actual repository instead of assuming a locally valid YAML file establishes enforcement.
gate:
if: ${{ always() }}
needs: [checks]
runs-on: ubuntu-latest
steps:
- name: Require successful mandatory checks
env:
RESULT: ${{ needs.checks.result }}
run: test "$RESULT" = "success"Bind reports and review comments to the tested revision
Preserve the repository identity, PR number, head revision, base revision and tested commit with machine-readable reports. GitHub may test a merge revision rather than the branch head, so name the artifact that the result describes. A newer push invalidates an older finding’s location and may change its conclusion.
The example gate model demonstrates rejecting a mismatched revision string. A real integration must obtain and compare those identities from trusted workflow metadata, not from arbitrary PR text. Deduplicate comments and avoid posting a late successful review over a newer failed check.
Cancel obsolete work to reduce waste, but do not call cancellation a successful scan. Before deployment, ensure the artifact being promoted is the one whose results you are evaluating. Commit identity and artifact identity support traceability; neither alone proves the software behaves correctly.
Keep untrusted code away from privileged review actions
Run proposed code with the minimum necessary permissions and without production credentials. A PR can modify tests and scripts, so treat everything it executes as untrusted. Keep model credentials, comment-write permissions and protected review policy outside that execution context.
GitHub’s secure-use guidance recommends least privilege and warns about handling untrusted code. An AI adapter should receive bounded source and reports as data, validate its structured output and check locations before any publication. Do not let a code comment or model response request extra repository permissions or command execution.
For external contributions, verify how fork approval and secret availability affect your chosen workflow. Do not solve a missing token by exposing it to the submitted code. A safer incomplete review is preferable to a credentialed process that trusts an arbitrary change.
Add checks only when you can operate them
Once the small workflow is observable, add language-specific linting, project types, dependency checks or source-security analysis according to the risks you need to cover. Preserve each check’s configuration, outputs and actual failure threshold. A scanner that always exits successfully is not a blocking gate simply because its report lists findings.
Introduce rules in a manageable set, investigate false alarms and distinguish existing debt from newly introduced defects when your tooling supports that policy. Recheck rule licensing before redistributing a scanner or rule collection as a service. A tutorial about using a tool inside a project is not permission to repackage that tool’s rules.
Know what this site provides
AI Code Verify’s current checker runs fixed checks on one JavaScript, TypeScript or Python snippet in your browser. It does not upload source, invoke an LLM, connect to GitHub or execute these tests. The pipeline described here belongs in your own project and CI environment.
Use the main framework to define the requirement, the checklist to review acceptance, and the cross-file guide to design better negative cases. Adopt the workflow only after its success, failure and unavailable states have been demonstrated in the repository that it will protect.
Our single-snippet static checker runs local fixed rules. It does not connect a repository, execute your tests, perform cross-file analysis or prove a program correct. Use it as one layer of the workflow.
Sources and editorial notes
Product capabilities can change. Links below are primary references used for this guide; examples are demonstrations unless explicitly stated otherwise. Suggest a correction.