How Releavo follows your code

What happens between a push or merge request and a story moving on the board.

Following your code only ever reads it. Releavo doesn't commit, comment on pull requests or change a branch because of a push; what it does happens in Releavo. (Releavo writes code only when a project switches coding on, and then only on its own releavo/ branches.)

From push to story

1. The tool tells Releavo. Pushes and pull or merge requests arrive as signed webhooks. Bot pushes, tags and drafts are ignored.
2. It waits for things to settle. Events for a project are gathered until none has arrived for 45 seconds, so ten quick commits are one piece of work, not ten.
3. It reads the diff. Releavo fetches what actually changed.
4. It finds the story. A story key in the branch name, title or commit messages (VD-35) settles it. Without one, it compares the change with open stories and only acts when it's clearly the same work.
5. It moves the story forward, never back:
   • push to a work branch: Ready → In progress
   • pull or merge request opened: → In review
   • merged: stays In review, and QA is told it's ready to test (it goes to Done only if your team agreed a merge means done)
6. It checks the code against the story. An acceptance criterion the diff doesn't cover, or work the story doesn't ask for, becomes a comment on the story. A change the architecture doc doesn't describe (a new service, a migration) becomes a risk, and the tech lead hears about it.

Make it certain

Put the story key in branch names or titles: feat/VD-35-tier-ids. Then matching never has to guess.

Change the rules

How Releavo reacts is a playbook (playbooks/repo-events.md), not a setting. Ask Releavo to change it for your project, for example "a merge means done here".