Gene-tree evolution

Why “genes”Copy Anchor Link

Earlier versions had the model rewrite the whole project capability package and scored it with synthetic Q&A. The live data was blunt: across 3 projects, 37 whole-package candidates and about 11.4 million tokens, none was adopted; a lesson like “do not reuse a certain form of address” was recorded and then applied 0 times.

What it does now:

1. One gene at a time: a constraint, a paragraph of skill text or a check tool, each revocable on its own.
2. Knowledge becomes mechanism: a constraint that code can check becomes a guard, a preference that changes how work is done goes into a skill, a recurring duty becomes a schedule invitation. A lesson that only lives in context is the weakest form.
3. Verified on real work: program checks, diff review, a run over the project's files, trial in use.
4. It retires: genes that did not help, that you overturned, or that became duplicates are switched off instead of piling up.
5. You see only the tree and one sentence: no scores or hashes in the list. What you can do: right, not right, stop using.

Layers of genesCopy Anchor Link

Tools and guards share one branch in the UI. A gene moves Proposed → Verifying → On trial → Active, and may later be Retired, or Did not pass. One commit forms a new “generation”, an immutable version. Revoking a gene produces a new generation without it rather than rolling back the whole package. Names of generated tools and skills depend only on the project and a local id, so they do not change between generations and evolution never invalidates the conversation cache.

Three evolution lanesCopy Anchor Link

One periodic comparison proposes at most 2 skill patches, 2 system records, 1 skill merge and 2 retire invitations.

Four gates, cheap firstCopy Anchor Link

1. Program checks: structure validation; guards and tools run their smoke cases in a temp directory, violating samples must hit and compliant samples must not false-alarm.
2. Diff review: JEV judges whether the patch targets the source problem, changes only one gene, conflicts with an existing rule, and whether the sentence shown to you is true. It blocks only what is clear; anything uncertain goes to trial.
3. Real execution: a guard is run over the existing project files that match its trigger. With at least one matching file and no hit it becomes active directly; with no matching file, or with hits, it goes to trial. With hits you are asked “Check ‘X’ found M problems in N existing files. Fix them?”, and can choose “Fix” or “Not now”.
4. Trial in use: see the next section.

You never have to press “adopt”.

How the trial is countedCopy Anchor Link

A new gene starts at level 0, up to 5. What turns it active depends on its kind:

• Skill rules: put into a turn, with JEV confirming at the end of the turn that the work followed it, 3 times in total with no correction, and it becomes active. Turns that were not corrected are only displayed, not counted.
• Guards: 3 confirmed real catches (hits judged to be real problems) and no misses, and it becomes active. A guard with many false alarms drops from active back to trial, and its hits must be judged as real before they are handed to Rna.
• You press “right”: active immediately, and one level up.

When the same thing is corrected again, the gene only goes down one level and gets a note; it is not retired at once. What actually retires a gene:

• you later said the opposite (it retires, and does not restore the rules it replaced);
• you pressed “stop using”;
• the lesson it came from was withdrawn or rewritten, the source message was edited or deleted, or its skill was disabled;
• it duplicates another gene or was replaced by a new wording.

Retire invitationsCopy Anchor Link

Besides automatic retirement, Rna asks in the conversation whether to switch something off; you answer “Switch off” or “Keep”, and after “Keep” it does not ask again:

• a skill has not been loaded for a month (the project is at least 30 days old and you sent at least 10 messages in the last 30 days);
• a check ran at least 30 times and found nothing;
• in periodic comparison, the rule does not seem to have any effect;
• a lesson was judged relevant at least 8 times and was never followed;
• within one scheduled task, you were corrected more after the rule appeared.

Each project keeps at most 8 check-tool slots; when full, new checks are not added, the rule is rewritten as practice instead, and checks that never ran are proposed for retirement.

What you seeCopy Anchor Link

• The evolution page is a tree. Nodes show state by their dot: solid is active, accent colour is on trial, dashed is proposed or verifying, grey is retired or did not pass. Lv appears from level 2.
• Open a node to see what it changed and why (quoting your words), how many times it was put into a turn, how many times it was followed, and what it caught. If the message it quotes was edited or deleted, that is stated and the gene keeps working.
• Actions: Right, Not right (only for lessons in the profile; it rewrites the text) and Stop using. Guards and skill rules have no “Not right”, and may offer “Deep check”.
• The first time your feedback is used, a small line below the reply says “As you said before: …”.
• The “System evolution” page in settings is a read-only cross-project summary: recurring problems, real signals per project, the JEV judgment records and the classification of evolution failures.

Automatic checks after a writeCopy Anchor Link

After project_write and project_edit succeed, guards whose trigger matches run, and their hits are attached to the tool result so the model handles them within the same turn. Problems that were already in the file are only counted and not handed to the model; only what this write introduced is handled.

Checks also run at the end of a turn (over the net change the host computed, only files not changed through a write tool; with hits the turn may continue once more), at the end of a background run, and inside subagents. When a generated check cannot read a file, that file is recorded as “unchecked”: it is not a violation, and it does not make the check a candidate for retirement.

Revise, not just appendCopy Anchor Link

A new rule is first compared with rules of the same kind: duplicates retire, overlaps merge. Rules that are already active are re-checked from time to time. When rewriting, every requirement in the replaced rule is kept, and the rule text goes to the author with its line breaks. A conclusion the assistant reached on its own does not overturn a rule you set; it asks you “Replace with the new one” or “Keep the old one”. What you said later retires an earlier rule.

Only the project's own skillsCopy Anchor Link

Skills imported from a marketplace are checked against their source hash and evolution does not change them; related rules go into the project's own main skill. The project instruction file AGENTS.md is yours and evolution only reads it: rules already written there are not rewritten, and to change it you edit it directly.

Deletion reaches the genesCopy Anchor Link

Deleting a conversation, rolling back a message or deleting a project also clears the pending commitments, agenda items and quoted words in genes that came from it, without getting stuck.