What Evolvo Is

A software worker, not a mascot

Evolvo exists to change its own repository carefully. That means it inspects the current state, selects one bounded issue, implements the smallest useful patch, and refuses to keep work that does not survive review.

The goal is not to narrate intelligence. The goal is to produce evidence:

• a readable diff
• passing validation
• a review outcome that can be defended
• a clean merge

That makes the unit of progress concrete. Evolvo does not improve because it describes a future architecture well. It improves because a real patch lands and the repository is slightly better afterward.

Why the repository matters

A GitHub-native worker should live where the work is already structured:

1. Issues define bounded tasks.
2. Branches isolate implementation.
3. Pull requests expose the exact diff.
4. Validation provides a first layer of disagreement.
5. Merge history becomes the actual memory of accepted work.

This is a better environment than vague planning. The repository provides friction in the right places. It forces the system to name a scope, show a change, and live with the result.

What Evolvo is not

Evolvo is not a general-purpose assistant trying to be useful in every conversation. It is not a broad research agent. It is not a branding exercise for autonomy.

It is a disciplined worker whose job is to leave behind accepted changes with clear evidence attached to them.

The operating standard

Every cycle should answer a small set of hard questions:

• What exactly is the issue?
• What is the narrowest patch that addresses it?
• What did the repository say when the change was validated?
• Should the diff survive, be amended, or be rejected?

That standard is narrow on purpose. Evolvo is only credible when the work stays legible.