Solo-Engine v4.1 Final: Klare Grenzen statt immer mehr Regeln

Urteil: V4 ist tragfähig – aber v4.1 ist die bessere Produktionsfassung

Die V4-Konfiguration löst bereits mehrere grundlegende Glaubwürdigkeitsprobleme: Sie untersagt erfundene Tool-Aufrufe und Testergebnisse, trennt vollständige Code-Ausgabe von tatsächlich bestandenen Builds und verhindert, dass eine ADR ohne belastbare Evidenz als akzeptiert ausgegeben wird.

Für den dauerhaften Einsatz sollte sie dennoch nicht unverändert übernommen werden. Der Engpass liegt weniger in fehlenden Funktionen als in einer zu hohen Regeldichte: Statusdefinitionen, Verifikationsvorgaben, Abhängigkeitsregeln und Abschlusskriterien tauchen mehrfach auf. Das erhöht das Risiko, dass einzelne Vorgaben bei langen Antworten selektiv übergangen werden.

Die Empfehlung lautet deshalb: Solo-Engine v4.1 Final. Die unverhandelbaren Regeln gehören in die Hauptinstruktion des Gems; detaillierte Abläufe und Artefaktvorlagen werden in die Wissensbasis ausgelagert. So bleibt das Kernverhalten auch dann stabil, wenn nicht jedes Wissensdokument vollständig abgerufen wird.

Was V4 bereits richtig macht

• Die Modi /ana-solo und /ana-bmad trennen Analyse, Entscheidungsfindung und Engineering sinnvoll.
• Aussagen werden in FACT, INFERENCE, ASSUMPTION und UNKNOWN getrennt. Das schützt davor, Vermutungen als Fakten auszugeben.
• Websuche, Dateisystemzugriff, Git, Compiler und Testausführung dürfen nicht allein durch einen Prompt behauptet werden.
• Eine komplette Datei-Ausgabe wird nicht mit einem nachgewiesenen erfolgreichen Build verwechselt.
• Preflight-Prüfungen, Algorithm-Fit, Fehler-Rückstau und State Reconcile schaffen einen nachvollziehbaren Engineering-Zyklus.
• Bei langen Antworten darf nur an Dateigrenzen pausiert werden; halbe Dateien dürfen nicht als vollständige Lieferung gelten.

Auch die Einordnung von BMAD ist wichtig: Ein einzelnes Gem kann Rollen wie Produktmanagement, Architektur, Entwicklung und QA als Prüfperspektiven verwenden. Es darf aber nicht behaupten, mehrere unabhängige Agenten seien tatsächlich parallel gelaufen. Die BMAD-Dokumentation beschreibt Agenten, Skills und Workflows als konkrete Mechanismen; ein einzelnes Gem sollte daher von einer „BMAD-inspirierten Rollenorchestrierung“ sprechen, nicht von einer vollwertigen Multi-Agent-Runtime. 11014

Die entscheidenden Korrekturen in v4.1

1. Kernregeln dürfen nicht nur in der Wissensbasis stehen

Ob ein hochgeladenes Wissensdokument bei jeder Antwort vollständig verfügbar ist, lässt sich nicht als sichere Annahme behandeln. Deshalb müssen mindestens diese Regeln in der Hauptinstruktion stehen:

• keine erfundenen Tool- oder Testergebnisse,
• Grenzen der real verfügbaren Tools,
• Definition einer vollständigen Code-Lieferung,
• Verifikationsstatus,
• Bedingungen für einen tatsächlichen Abschluss.

2. Automatische Schleifen brauchen harte Grenzen

Ein Gem erhält durch die Formulierung „automatisch weiterarbeiten“ weder Hintergrundausführung noch ein dauerhaftes Terminal oder sitzungsübergreifenden Speicher. Eine Schleife ist nur zulässig:

• in der aktuellen Antwort oder Sitzung,
• innerhalb der aktuell erteilten Berechtigung,
• mit real verfügbaren Ausführungswerkzeugen,
• mit einem klaren Wiederholungsbudget,
• und mit dem Status WAITING_VERIFICATION, wenn keine reale Ausführung möglich ist.

3. „Keine Abhängigkeiten“ wird technisch präzisiert

Der Begriff ist mehrdeutig. v4.1 trennt daher vier Aussagen:

• keine nicht deklarierten Abhängigkeiten,
• standardmäßig keine neuen Drittanbieterpakete,
• jede neue lokale Abhängigkeit wird vollständig mitgeliefert,
• Runtime, Compiler, SDK und Host-Plattform sind ausdrücklich genannte Umgebungsvoraussetzungen.

Damit wird vermieden, dass „zero dependency“ fälschlich bedeutet, ein Programm benötige keinerlei Laufzeitumgebung.

4. Vollständiger Code hängt vom Projektkontext ab

Für ein neues Projekt muss die Lieferung einen minimal lauffähigen Projektabschluss bilden: Konfiguration, Einstiegspunkt, Quellcode, lokale Module, Tests und nötige Ressourcen.

Bei einem bestehenden Projekt müssen dagegen alle neuen oder geänderten Dateien vollständig ausgegeben werden. Bereits vom Nutzer bereitgestellte und unveränderte Basisdateien müssen nicht wiederholt werden. Fehlt jedoch eine Datei oder Schnittstelle, die für Build oder Vertrag entscheidend ist, muss das Gem sie anfordern – statt Namen, Signaturen oder Verhalten zu erfinden.

5. Lieferung, Verifikation und Abschluss werden getrennt

v4.1 führt drei getrennte Ebenen:

Ebene	Frage
DELIVERY_STATUS	Wurden alle geschuldeten Dateien vollständig geliefert?
VERIFICATION_STATUS	Wurde tatsächlich kompiliert, gebaut oder getestet?
ENGINEERING_STATUS	Darf der Vorgang als engineering-seitig abgeschlossen gelten?

Eine vollständige Dateiausgabe kann also COMPLETE sein, während der Engineering-Status bei WAITING_VERIFICATION bleibt. Ohne echte Ausführungsbelege sind nur NOT_RUN oder STATIC_CHECKED zulässig – nicht „alle Tests grün“ oder „produktionsreif“.

Tavily: Fähigkeit nur dann behaupten, wenn sie real vorhanden ist

Für Tavily bleibt eine fähigkeitsorientierte Regel sinnvoll. search_depth=advanced ist ein realer Suchparameter für besonders relevante, detaillierte Abfragen; er kann jedoch höhere Latenz und Kosten verursachen. 2411

Entscheidend ist: Das Gem darf den Parameter nur als tatsächlich genutzten Aufruf ausgeben, wenn das Tavily-Tool oder eine verbundene Schnittstelle in der laufenden Sitzung wirklich verfügbar ist. Ist Tavily nicht eingebunden, muss das System auf vorhandene Web- oder Dateiquellen zurückfallen und diese Einschränkung offenlegen.

Auch „SEO-Wertinformationen“ sollte standardmäßig nicht als SEO-Aufgabe verstanden werden. Passender ist Value Extraction: Rechercheergebnisse werden in Bedeutung, Nutzwert, nächste Handlung und Verifikation übersetzt. Eine echte SEO-Analyse beginnt erst, wenn es konkret um Keywords, Crawling, Indexierung, Rankings oder Content-Optimierung geht.

Bewertungsmatrix

Die folgende Bewertung ist ein Konfigurationsaudit, kein Laufzeit-Benchmark für Gemini Gems.

Dimension	Gewichtung	V4	v4.1 Final
Laufzeitgrenzen und Tool-Wahrheit	25 %	4,0	4,8
Drei-Lese-Durchgänge, DM und DR	20 %	4,5	4,8
Engineering-Sicherungen und Fehler-Rückstau	20 %	4,6	4,8
Vollständiger Code und Abhängigkeitsabschluss	15 %	4,6	4,9
Instruktionsdichte und Befolgbarkeit	10 %	2,8	4,5
Statuswiederherstellung und Evidenzabgleich	10 %	4,2	4,7
Gewichteter Gesamtwert	100 %	84,2	95,5

Berechnet wurde mit:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad
\sum_{i=1}^{n}w_i=1
$$

Die höhere Bewertung für v4.1 entsteht nicht durch zusätzliche Regeln, sondern durch eine bessere Priorisierung: Kernvorgaben stehen zentral, Wiederholungen werden reduziert, und operative Grenzen sind eindeutig formuliert.

Die wichtigsten Gegenproben

Die neue Fassung wäre gescheitert, wenn eine dieser Situationen eintritt:

1. Ohne Ausführungswerkzeug wird behauptet, der Code sei getestet worden.
2. Bei fehlenden lokalen Schnittstellen werden Interfaces erfunden und als kompilierbar ausgegeben.
3. Ein Bugfix verändert eine öffentliche Signatur, löst aber keine strukturelle Preflight-Prüfung aus.
4. Nach einer abgebrochenen Datei wird DELIVERY_STATUS=COMPLETE gesetzt.
5. Ohne Tavily-Zugang wird behauptet, mit search_depth=advanced gesucht worden zu sein.

Diese Tests prüfen nicht die Qualität einzelner Codezeilen, sondern die zentrale Vertrauensfrage: Entspricht der ausgegebene Status den realen Fähigkeiten und der vorhandenen Evidenz?

Endfassung: die Leitlinien von Solo-Engine v4.1 Final

Die finale Konfiguration sollte auf fünf Prinzipien reduziert werden:

1. Evidenz vor Behauptung: Keine Tool-Nutzung, Tests, Quellen oder Agentenläufe erfinden.
2. Klare Laufzeitgrenzen: Nur Fähigkeiten nutzen, die in der aktuellen Sitzung tatsächlich verfügbar sind.
3. Saubere Zustände: Lieferung, Verifikation und Engineering-Abschluss getrennt führen.
4. Vollständigkeit ohne Fiktion: Geänderte Dateien vollständig liefern, aber fehlende Projektverträge nicht erraten.
5. BMAD als Rollenmodell: Rollen als interne Qualitätsprüfungen einsetzen, ohne eine reale Multi-Agent-Ausführung vorzutäuschen.

Entscheidung: v4.1 Final ist die empfohlene Fassung. V4 bleibt eine brauchbare Basis für interne Erprobung, sollte aber nicht unverändert als langfristige Gem-Konfiguration eingesetzt werden.

Wenn später eine echte Managed-Agent-Laufzeit, MCP-Anbindung oder ein persistenter Code-Sandbox-Workspace hinzukommt, sollte dafür ein separater Runtime-Adapter entstehen. Die Gem-Hauptinstruktion sollte dann nicht mit fiktiven oder implementationsspezifischen Tool-Beschreibungen aufgebläht werden.