[Auto] Recurring failure: Repeated failures with gene: gene_auto_2ce76294

[travelvector]

Environment

• Evolver Version: 1.80.4
• Node.js: v24.15.0
• Platform: win32 x64
• Container: no

Failure Summary

• Consecutive failures: 5
• Failure signals: consecutive_failure_streak_5, failure_loop_detected, ban_gene:gene_auto_2ce76294, high_failure_ratio, force_innovation_after_repair_loop

Error Signature

Repeated failures with gene: gene_auto_2ce76294

Recent Evolution Events (sanitized)

#	Intent	Gene	Outcome	Reason
1	innovate	gene_auto_2ce76294	failed
2	innovate	gene_auto_2ce76294	failed
3	innovate	gene_auto_2ce76294	failed
4	innovate	gene_gep_innovate_from_opportunity	failed
5	innovate	gene_gep_innovate_from_opportunity	failed

Session Log Excerpt (sanitized)

[NO SESSION LOGS FOUND]

---

This issue was automatically created by evolver v1.80.4.
Device: node_1778c... | Report ID: 69dfcbe45857

[autogame-17]

Hi @travelvector, thanks for the auto-report. A few quick observations and what we need from you to move this forward.

What the auto-report tells us

• Gene gene_auto_2ce76294 is locally auto-generated, not a network-published Gene -- it does not exist in our Hub database, so we cannot inspect its strategy/validation_commands from here. Locally auto-generated Genes carry the gene_auto_* prefix; network-published Genes look like gene_gep_* or gene_<canonical>_<hash>.
• The signal stack failure_loop_detected + ban_gene + force_innovation_after_repair_loop means the failure-loop detector worked correctly: it banned the local Gene after 5 failures, then escalated to the built-in innovation Gene. Innovation also failed twice -- which is the part we want to understand.
• Session Log Excerpt came back as [NO SESSION LOGS FOUND] and the Reason column on every recent event is empty. That means evolver could not capture the underlying error each Gene was trying to fix, which is exactly the diagnostic we need.

To move this forward, please do these in order

1. Upgrade

You're on 1.80.4; the current stable is 1.80.7 which includes a proxy stale-secret fix (issue #529) and an opencode plugin verifier (issue #531). Some of those paths sit on the same code as innovation/repair, and at minimum it gets us onto a known-good baseline before deeper triage.

npm i -g @evomap/evolver@latest
evolver --version

Please paste the output of evolver --version so we know we're aligned.

2. Re-run and grab a session jsonl

After upgrading, reproduce the failure once more (one full run is enough):

evolver run

Then attach the most recent session jsonl from your memory directory. On Windows that is roughly:

Get-ChildItem "$env:USERPROFILE\.evomap\evolver\memory\sessions\" -Recurse | Sort-Object LastWriteTime -Descending | Select-Object -First 1

Drop the resulting session_*.jsonl here as an attachment (drag-and-drop into the comment box). It is automatically sanitized by evolver before write, but if you see anything you would rather not share, feel free to redact further.

3. Tell us the trigger

What were you running when the failure first appeared? Specifically:

• What was the original task / prompt evolver was working on?
• Which model / provider (EVOLVER_MODEL, EVOLVER_PROVIDER)?
• Any unusual environment (proxy, custom EVOLVER_HUB_URL, sandbox, etc)?

4. (Optional, if you're comfortable sharing) the local Gene definition

The local Gene file lives at:

%USERPROFILE%\.evomap\evolver\assets\gep\genes.json

Search inside that file for "gene_auto_2ce76294" and paste just that one Gene entry (it's a self-contained JSON object with assetId, signals, strategy, validation_commands). That tells us whether the auto-innovation produced a malformed Gene, which we can then fix at the innovation layer.

Why we need this

Without the session log + reason field, we can't tell whether the failure is:

• the local Gene's validation_commands always erroring on your platform (fixable by us in the validator sandbox), or
• the underlying task itself being unreachable (network/credential), or
• a malformed auto-generated Gene shape (fixable by us in the innovation logic).

Each path has a very different fix and we don't want to ship the wrong one.

I'm marking this needs-info per our triage policy. If we don't hear back within 7 days we'll auto-close, but feel free to reply at any point and we'll reopen and continue from there.