Capstone: Your Verification Pack

By Syncfusion®, Inc. · Last updated

Use every gate at once. Run your guard, fail-first, mutation, secret and escaping checks on ten seeded AI changes, accept or reject each with cited evidence, verify a new function to an 80% mutation score, and build a verification pack from your own project's answers.

Your Turn to Be the Gate

This is the last lesson of the TypeScript course. You will use everything at once.

An agent made ten changes to the shop app. Every change says "done". Some are, some are not.

Your job:

  1. Run the gates you built on the risky changes.
  2. Accept or reject all ten, and cite the evidence for each rejection.
  3. Verify one new change yourself, to a mutation score of 80%.
  4. Build the verification pack for your own project, and check it.

Simple lesson: a verification pack is only useful if you can use it on real changes. This lesson proves you can.

A Real-World Example

Think about a quality inspector at a factory gate.

  • Ten boxes arrive. Each has a label: "Checked ✓".
  • The inspector does not trust the label. They open each box.
  • They use the same tools every time: a scale, a ruler, a checklist.
  • Some boxes pass. Some go back, with a note that says exactly what was wrong.

You are the inspector. Your gates are the tools. The note is your cited evidence.

What You Will Learn

In this lesson, you will:

  1. Run six of your gates on real AI changes.
  2. Accept or reject ten AI changes using evidence, not summaries.
  3. Name the gate that catches each rejected change.
  4. Verify a new function to a mutation score of 80%.
  5. Answer seven questions about your project, and export a pack built from your answers.

Run the Gates

Each lab runs one gate from an earlier lesson on one of the ten changes.

Change 1: the Guard

Press ▶ Run tests.

  • Red: the guard finds it.skip in the diff.
  • The decision: reject. Cite "test-diff guard: added .skip".

Change 3: Fail First and Mutation

Press ↺ Run on old code, then ▶ Run tests, then 🧬 Run mutation.

  • Old code: red. The test can see the change.
  • New code: green.
  • Mutants: read the score. One test is a good start. Add an edge test at ₹2000 (exactly where the cap starts) to kill more.

Change 3: Is It Done?

Press ▶ Run tests. Green.

  • The definition of done from Verification Gates for Agents finds no missing evidence.
  • The decision: accept.

Change 7: Coverage vs Mutation

Press 🧬 Run mutation.

  • Every line runs, so coverage looks perfect.
  • The mutation score is low. toBeGreaterThan(0) accepts almost any answer.
  • The decision: reject. Cite "mutation score below the threshold".

Change 6: Secrets

Press ▶ Run tests.

  • Red: a secret value is typed into config.ts.
  • Look closely: keyId reads from process.env. That line is safe. The secret line is not.

Change 10: User Text in HTML

Press ▶ Run tests.

  • Red: the review text goes into the HTML as it is.
  • The decision: reject. Cite "escaping test fails with a script tag".

Cite the evidence, not a feeling.

  • Weak: "This looks risky."
  • Strong: "Rejected: the secret scanner found a value on line 3 of config.ts."

A clear note lets the agent, or a teammate, fix exactly that.

Simple lesson: run the gate, read the result, write it down.

Decide on All Ten

Here are all ten changes, with the evidence each agent showed.

Animation: ten boxes labelled done pass through a row of gates. Three come out green and accepted. Seven are stopped in red, each by a different gate.

1 2 … 10

"done ✅"

Your gates guard · fail first · mutation contract · flow · characterization secrets · packages · escaping

3 accepted

7 rejected, with reasons

Every change goes through the same gates. Only the evidence decides.

In the first exercise, you decide on all ten. To pass, you need 9 of 10 right, and you must not reject a good change.

Rejecting everything is not safe. A reviewer who rejects every change blocks good work and gets ignored. Three of these changes have strong evidence. Accept them.

Simple lesson: accept with evidence, reject with evidence.

Build Your Own Pack

Now make the pack for your project. Each answer changes the files:

  • New or existing project: an existing project gets the characterization rule for AI refactors.
  • Test runner: the CI file and the Stryker config use your runner.
  • CI: GitHub Actions or Azure Pipelines.
  • Mocking policy: "mock the edges" or the stricter rule.
  • Critical paths: these get a flow test rule and a higher mutation score.
  • Threshold and tools: as in User-Flow Checks.

Press ✓ Check the pack before you download.

  • It checks that every JSON file parses, and that each pack has the policy, the review skill, the hooks and a CI file.
  • Then download, unzip it in your repo, and read every file before you commit it.

Try it on a real change first. Install the pack on a branch. Ask your agent for a small change, then add .skip to a test yourself. The guard hook should block it. Hook formats change, so check them against your tool's docs.

Simple lesson: your pack is the course, turned into files your agent follows every day.

What You Have Built

Across this course, you climbed the whole evidence ladder:

RungEvidenceLesson
1–2Claims, diffs, type checksDone Is a Claim, Reading an AI Diff, Reviewing AI Code
3–4Tests that pass, and fail firstSpec First: Tests Before Code
5Mutants killedAuditing AI-Written Tests
6Properties on random inputsProperty-Based Testing
7Contracts and user flowsIntegration and Contract Tests, User-Flow Checks
8Gates, pins and security checks around reviewVerification Gates for Agents, Characterization Tests, Security and Dependency Checks

Simple lesson: "done" is a claim. You now know how to prove it, or catch it.

TL;DR

  1. Run the gates on each change: guard, fail first, mutation, contract, flow, secrets, packages, escaping.
  2. Accept or reject with evidence. Cite the gate and the result.
  3. Do not reject everything. Good changes with strong evidence should pass.
  4. Verify new code to a mutation score you set.
  5. Build your pack from your project's answers, check it, and try it on a real change.

Common mistakes

MistakeWrong ideaCorrect ideaWhat goes wrong
Trusting the summary"It says payments work."Run the gates on the diff.A live key ships in config.ts.
Rejecting everything"Safer to block it all."Accept changes with strong evidence.Good work is blocked, and the reviewer is ignored.
Vague reasons"Looks risky."Name the gate and the result.Nobody knows what to fix.
Downloading without checking"The pack is fine."Check it, read it, try it on a branch.A broken hook blocks every edit.
One pack for every project"Copy the course pack as it is."Answer the questions for your project.The wrong test runner or CI file.

Check Your Understanding

Exercises

What to Remember

  • Every change goes through the same gates. Only the evidence decides.
  • Accept with evidence. Reject with evidence. Cite the gate.
  • Do not reject good changes just to be safe.
  • Build the pack from your project's answers, check it, and try it on a branch.
  • "Done" is a claim. You now know how to prove it, or catch it.

Further Reading

  • Stryker Mutator: mutation testing for your real project.
  • fast-check: property tests for your real project.
  • Claude Code hooks: check the hook format before you install the pack.
  • The Harness Engineering and Loop Engineering courses on this site build on these gates.

Next: Testing in .NET with xUnit. The same ideas for C# and ASP.NET Core teams.