Prove a behaviour change

Tests pass. Coverage is high. And the button still does nothing. Floors check the code; a feature map checks what your product actually does. It lists what your product can do, with a behaviour check for each capability, and the merge gate runs the checks a pull request touches, with no model and no AI key.

You are here: Level 2, with the merge gate running (a pull request is ready).

Needs aayudha 0.2. If aayu version prints 0.1.x, this page is ahead of your binary: run aayu self-update. Until 0.2 is released, go install github.com/rahulnakmol/agentic-ayudha/cmd/aayudha@dev installs the build this page describes.

What a behaviour check is

A behaviour check drives your product the way a person or a client would. It comes in four kinds, so it fits any product, not only web apps:

A small control tool, written in your product's own stack, runs each check and reports passed, failed, or unreachable. It adds no runtime your product lacks: Node and Playwright for a web app, Go for a Go module, a shell script for a command line tool.

Create your map

aayu init --verify-skill

It writes a starter verify skill at .agents/skills/verify-<product>/: a SKILL.md, a control tool chosen from your stack, and an empty features/ folder. It asks which agent app should keep the map up to date, and offers only the ones it detects. aayu install makes the skill available to your agent; in Claude Code it is /aayudha:verify-<product>.

Then ask your agent to fill it in, in plain words:

Use the verify skill to map this product's features, with one behaviour check per capability.

The agent writes one file per feature: what it is, how to reach it, its behaviour checks, and its gotchas.

You should see aayu verify --map exit 0. It compares the map with your code, runs nothing, and lists any drift: a route, command, or function your code has that no feature lists, or one the map lists that is gone.

What the gate does with it

On every pull request:

• Behaviour checks. The checks of every feature the change touches run. A failed check turns the gate red at once. unreachable means a precondition is missing: it proves nothing and fails nothing.
• Drift. The map is compared with the code. Drift is a warning until [verify] drift_blocking_from, a date in your config, and blocks from that date on.
• Evidence. A promise in the story can name checks in .aayudha/evidence/<story>.toml. It counts as proven only when every one of them passed and left evidence of the right kind.

Try a check yourself before you push:

aayu verify --check <feature>      # or <feature>.<check>, or all; a preview outside the gate

Keeping the map honest

Code moves and maps drift. Two loops keep up: a nightly sweep runs every check in GitHub Actions, with no model, and a weekly maintain pass posts a brief that @-mentions your maintainer app. The app opens at most one pull request of map fixes, through the same gate. It may never weaken a check: a real regression becomes a Bug. Set the loops up with aayu install --loops.

Bugs: proof that it was broken

For a Bug story, the gate also runs the tests that prove the fix on the base commit, before the fix. They should fail there and pass on the pull request: "red on base, green on head". This is advisory until [verify] red_on_base_blocking_from, and runs for Go tests mapped to the Bug's promises.

Honest status: both dates are 13 November 2026 by default, so drift and red-on-base are warnings until then. aayudha's own repository has no feature map of its own yet; its two examples, benefits-qa and notes, do.

Under the hood

The map format, the control tool's JSON contract, how checks are picked, and the maintain brief are in verify skills, feature maps, and behaviour checks.

What's next

• See where behaviour checks fit on the day: chapter 5 of the story.
• Ship the proven pull request: a pull request is ready.