Oronts Engineering Harness

KI benotet bei uns nicht ihre eigene Arbeit

Jede Änderung durchläuft eine feste Schleife, ein unabhängiges Modell und Nachweispflichten, bevor sie in Ihr Repository gelangt.

Der Harness ist eine proprietäre Steuerungsebene, die wir selbst gebaut haben und betreiben. Er macht aus KI-Programmierung statt schneller Generierung eine Entwicklungsorganisation mit dauerhaftem Gedächtnis, unabhängiger Review und Freigaben, die bei Ihnen bleiben. Er steuert auch unsere eigene Auslieferung, einschließlich dieser Website.

claude · order-service
$ claude fix the order status race
understandtraced 3 consumers
implementRED test, minimal slice
verify18 passed
reviewcodex + 2 opus lenses
findingHIGH race on status transition
fixroot cause, reviews re-run
reviewclear
gatepush: your approval

Wie stellt Oronts sicher, dass KI-geschriebener Code verlässlich ist?

Indem wir die beiden Abkürzungen entfernen, die agentische Programmierung unzuverlässig machen. Das Modell, das den Code schreibt, gibt ihn niemals frei, und der Gesprächsverlauf ist niemals die Quelle der Wahrheit. Die Review läuft auf einem anderen Modell, und der Zustand liegt in dauerhaften Dateien, die einen Kontextverlust überstehen.

  • Ein anderes Modell prüft die Arbeit, ergänzt um zwei gegenläufige Prüfperspektiven und Fachprüfer nach betroffener Fläche
  • Wiederverwendung wird gegen den echten Abhängigkeitsgraph geprüft und kann nicht einfach behauptet werden
  • Fertig heißt: Abnahmekriterien erfüllt und Nachweise aktuell, nicht ein einzelner grüner Test
  • Produktentscheidungen, rechtliche Fragen und irreversible Schritte bleiben bei Ihnen
Das Problem

Vier Fehlermuster, vier Mechanismen

Gewöhnliche agentische Programmierung scheitert auf vier vorhersehbare Weisen. Der Harness beantwortet jedes Muster mit einem Mechanismus statt mit einem Versprechen.

FehlermusterWas tatsächlich passiertDer Mechanismus
Sie generiert, statt zu entwickelnNeuer Code entsteht, obwohl das Framework, die Standardbibliothek oder das Repository das Problem längst löst.Eine Wiederverwendungsleiter, die auf der ersten korrekten Stufe stoppt, plus eine Prüfung, die jeden Plan ablehnt, der ein Paket oder einen Pfad nennt, den es nicht gibt.
Sie vergisstDer Kontext füllt sich, das Gespräch wird verdichtet, das Ziel geht verloren und Sie sollen alles neu erklären.Dauerhafte Gedächtnisdateien sind die Quelle der Wahrheit. Beim Start und nach jeder Verdichtung wird der Zustand neu eingespielt und die exakte nächste Handlung fortgesetzt.
Sie benotet ihre eigene ArbeitDasselbe Modell, das den Code geschrieben hat, prüft ihn und gibt ihn frei.Ein anderes Modell prüft, dazu zwei unabhängige gegenläufige Perspektiven und Fachprüfer. Befunde werden über Nachweise abgeglichen und nach jeder Korrektur frisch neu geprüft.
Sie liefert den SchönwetterpfadEin grüner Test, keine Negativfälle, kein Laufzeitnachweis, und das gilt als fertig.Fertig heißt: Abnahmekriterien erfüllt, risikoangemessene Nachweise aktuell gegen den Git-Stand, Prüfer ohne Befund, Zustand synchronisiert.
Echte Ausgabe

Wie ein Lauf tatsächlich aussieht

Zwei Ansichten aus einer echten Sitzung. Links meldet die Schleife jede Stufe, während sie passiert. Rechts leitet der reine Lesebeobachter eine Momentaufnahme aus den Gedächtnisdateien und dem laufenden Git ab und gibt sie aus.

claude · order-service
$ claude
SessionStart: reconciling git, injecting durable state
resumeT-008 active, next action recorded, 1 gate open
understandtraced 3 consumers of OrderProjection
reuseladder stopped at rung 4 (framework native)
checkplan cited @acme/retry, not in dependency graph
planrewritten, acceptance + non-goals recorded
implementRED test first, then minimal root-cause slice
verify18 passed, runtime proof at exact scope
reviewcodex + 2 opus lenses + database specialist
findingHIGH race on concurrent status transition
fixroot cause, reviews re-run fresh
reviewclear, evidence current against ad2fcd4
gateG-004 push to origin: owner approval required
stopped at owner gate, state persisted

Ein Befund schickt die Arbeit zurück in die Prüfung statt vorwärts in einen Commit. Der Lauf stoppt an einer Freigabe, statt zu pushen.

oronts-status --watch

$ node .claude/tools/oronts-status.cjs --watch

HEAD
ad2fcd4 · tree: clean
active
T-008
next
German barge-in
gates
G-004
TASKS
12 total · active 1 · ready 4 · completed 7
BLOCKERS
1
FINDINGS
crit 0 · high 0 · med 2 · low 5 (2 open of 7)

Der Beobachter schreibt keine Datei und verändert Git nicht. Ein Löschen ließe die Entwicklungsschleife unberührt.

Die Schleife

Ein Takt, Aufwand nach Tragweite

Jede substanzielle Aufgabe folgt demselben Takt. Ein Tippfehler bekommt eine gezielte Prüfung. Eine Zahlungs-Race-Condition, eine Migration oder ein Berechtigungspfad bekommt eine Designdebatte, Fachprüfung und echten Laufzeitnachweis. Die Tiefe ergibt sich aus der Tragweite, nie aus der Zahl geänderter Zeilen.

1

Verstehen

Den echten Repository-Zustand abgleichen, den tatsächlichen Ablauf und seine Konsumenten nachvollziehen.

2

Recherche und Wiederverwendung

Die Wiederverwendungsleiter durchgehen und jede Behauptung gegen die echten Manifeste belegen.

3

Debatte

Nur bei echten Designentscheidungen. Unabhängige Alternativen, dann eine entschiedene Wahl.

4

Planen

Ein ausführbarer Aufgabenvertrag mit Abnahmekriterien und ausdrücklichen Nicht-Zielen.

5

Umsetzen

Zuerst ein fehlschlagender Test oder ein Nachweis des Ist-Verhaltens, dann der minimale Schnitt an der Ursache.

6

Nachweisen

Risikoangemessene Nachweise im exakten Umfang, gegen den aktuellen Stand ausgeführt.

7

Unabhängige Review

Ein anderes Modell, zwei gegenläufige Perspektiven und Fachprüfer nach betroffener Fläche.

8

Festhalten und fortsetzen

Doku, Gedächtnis, Entscheidungen und Historie abgleichen, dann den nächsten Punkt nehmen oder an einer Freigabe stoppen.

Befunde schicken die Arbeit zurück in die Prüfung, nicht vorwärts in einen Commit. Die Schleife schließt erst, wenn die Prüfer ohne Befund sind.

Wiederverwendungsleiter

Auf der ersten Stufe stoppen, die es korrekt löst

Der Harness optimiert auf das Minimum an neuem Code für ein korrektes System, nicht auf möglichst viel sichtbare Programmierung. Eine deterministische Prüfung belegt jede Behauptung zur Wiederverwendung im echten Abhängigkeitsgraph. Ein Plan, der ein Paket nennt, das im Repository nicht existiert, fällt durch, bevor die Umsetzung beginnt.

  1. 1Muss das überhaupt existieren?
  2. 2Löst das Repository es bereits?
  3. 3Löst die Standardbibliothek es?
  4. 4Ist es nativ im Framework oder in der Plattform vorhanden?
  5. 5Löst eine bereits installierte Abhängigkeit es?
  6. 6Gibt es einen vorhandenen Erweiterungspunkt?
  7. 7Erst dann: das Minimum an neuem Code
Architektur

Eine Engine, drei Belange, eine Freigabe

Benannte Einstiegspunkte speisen eine einzige Engine. Die Engine treibt Urteilsbildung, Determinismus und Dauerhaftigkeit parallel an, und alles Irreversible verlässt das System über eine Freigabe, die Ihnen gehört.

Einstiegspunkte

Klartext, ein benannter Skill oder eine begrenzte autonome Kampagne.

  • Skills33
  • Ziel
  • Kampagne

Engine

Eine einzige lesbare Datei bedient die Lebenszyklus-Ereignisse: Git abgleichen, Zustand einspielen, Aufwand steuern, Freigaben durchsetzen. Keine versteckten Dienste, keine Hintergrundprozesse.

  • engine.cjs1
  • Git-Abgleich
  • Wiederaufnahme

Urteilsbildung

Unabhängige Prüfer und deterministische Fächerläufe mit mehreren Agenten.

  • Review-Agenten21
  • Workflows5

Determinismus

Prüfungen, die ohne Modell im Ablauf bestehen oder fehlschlagen.

  • Werkzeuge24
  • Regeln37

Dauerhaftigkeit

Zustand, der das Gespräch und jeden Kontextverlust überlebt.

  • Gedächtnisdateien15
  • Verkettete Protokolle

Ihre Freigabe

Irreversible und kommerzielle Aktionen stoppen hier, in jedem Berechtigungsmodus und auch bei unbeaufsichtigten Läufen.

  • Push und Veröffentlichung
  • Release und Deployment
  • Zerstörende Operationen
  • Geheimnisspeicher

Die Steuerungsebene wird in ein Repository kopiert und steuert es. Sie wird generisch ausgeliefert; jedes Projekt füllt seinen eigenen Zustand.

Unabhängige Review

Ein anderes Modell, keine zweite Meinung desselben Kopfes

Vier unabhängige Prüffragen und ein Entscheidungsmechanismus. Befunde werden über Nachweise abgeglichen, nicht per Mehrheit. Ein korrekter Blocker wiegt schwerer als zehn Freigaben. Nach jeder Korrektur laufen die Prüfungen frisch gegen den geänderten Stand, denn ein Prüfer, der den Baum berührt, entwertet den vorherigen Nachweis.

PrüfinstanzDie Frage, die sie stellt
Modellübergreifende ReviewWas ist falsch, das dem schreibenden Modell als demselben Kopf entgangen sein kann?
KorrektheitsperspektiveKann das fehlschlagen, Daten beschädigen, Informationen preisgeben, in eine Race-Condition laufen oder erwartetes Verhalten verletzen?
WartbarkeitsperspektiveIst das verständlich, minimal, frei von Dopplung und an der richtigen Stelle?
FachprüferIst das korrekt für Sicherheit, Datenbank, API-Vertrag, Oberfläche, Infrastruktur oder KI?
ArchitekturinstanzWie fällt eine echte Designentscheidung aus? Sie entscheidet, statt mitzustimmen.

Fachprüfer werden über die geänderte Fläche aktiviert, nicht pauschal pro Projekt. Eine Migration zieht den Datenbankprüfer, eine Berechtigungsgrenze die Sicherheitsprüfung, ein verteilter Ablauf die Nebenläufigkeit.

Ist der modellübergreifende Prüfer nicht verfügbar, wird das als nicht verfügbar protokolliert und eine zusätzliche unabhängige Perspektive ergänzt. Der Harness meldet niemals eine Prüfung, die nicht stattgefunden hat.

Rangfolge der Nachweise

Was was übertrifft

Die Rangfolge ist ausdrücklich und überlebt einen Modellwechsel. Ein grüner Test ist maßgeblich für das beobachtete Verhalten. Ein Prüfer ist maßgeblich dafür, ob dieses Verhalten die richtige Invariante ist. Keines ersetzt das andere.

  1. 1Ausführbare Tests und Laufzeitnachweise
  2. 2Unabhängige modellübergreifende Review
  3. 3Review durch dasselbe Modell
  4. 4Begründung der führenden Instanz
  5. 5Bloße Behauptung
Dauerhaftes Gedächtnis

Verdichtung ist ein Checkpoint, kein Neustart

Das schwerste Problem langer autonomer Läufe ist der Kontext. Er füllt sich, das Gespräch wird zusammengefasst, und ein naiver Agent vergisst das Ziel und bleibt stehen. Der Harness behandelt die Zusammenfassung als Checkpoint. Dauerhafte Dateien halten Ziel, aktuelle Aufgabe, exakte nächste Handlung, Entscheidungen, Blocker, Nachweise und Historie. Das Gespräch darf verworfen werden, der Zustand bleibt.

Zustand statt Gespräch

Die Gedächtnisdateien sind die Quelle der Wahrheit. Der Verlauf ist entbehrlich.

Wiederaufnahme bei Start und Verdichtung

Ein Hook gleicht Git ab und spielt Stand, aktive Aufgabe, Abnahmekriterien und offene Freigaben neu ein.

Ihre Anweisungen überleben

Eingaben werden deterministisch festgehalten, damit auch spontane Hinweise erhalten bleiben, die nie zu einer Aufgabe wurden.

Es setzt fort, statt zu warten

Nach dem Abgleich wird die festgehaltene nächste Handlung fortgesetzt, ohne nach Kontext zu fragen, der bereits vorliegt.

Fähigkeiten

Skills, Plugins und MCP-Server

Fähigkeiten liegen in drei Schichten, damit das System stimmig und schnell bleibt statt ein Bündel überlappender Werkzeuge zu werden. Zuerst die Kernfähigkeit, ein Spezialist nur bei echter Tiefe, niemals ein Duplikat dessen, was der Kern bereits kann.

33 benannte Einstiegspunkte in die Schleife

Ein Skill bestimmt, in welcher Tiefe eine Aufgabe in den Takt eintritt. Die Namen sind produkteigene Bezeichner und bleiben in jeder Sprache unverändert.

Starten und einordnen

  • start
  • route
  • triage
  • plan
  • estimate
  • capabilities

Bauen

  • implement
  • fix
  • refactor
  • ui
  • api-change
  • database-change
  • ai-change
  • infrastructure-change
  • dependency-change

Absichern

  • review
  • verify
  • audit
  • security-review
  • red-team
  • gdpr
  • debate

Betreiben und übergeben

  • autopilot
  • campaign
  • memory
  • doctor
  • handoff
  • finish
  • release
  • present
  • team
  • adopt

Mitgeliefert

  • excalidraw-diagram

Aktivierte Plugins

Sechs Plugins bilden das Rückgrat für Urteilsbildung und Review. Sie sind fest in die Schleife eingebunden, nicht optionale Beigaben.

  • superpowers

    Systematische Fehlersuche, testgetriebene Methode, Planung und Nachweis. Wird bei jeder Aufgabe aufgerufen, damit Fehlersuche reproduzieren und beheben heißt statt raten.

  • codex

    Ein unabhängiges, tatsächlich anderes Modell für die Review. Review durch dasselbe Modell teilt dieselben blinden Flecken; ein anderes Modell durchbricht diese Korrelation.

  • andrej-karpathy-skills

    Leitplanken gegen typische Fallstricke: annehmen statt nachfragen, überkonstruieren und ausufernde Diffs.

  • impeccable

    Produkt- und Designverankerung für Oberflächenarbeit, damit Screens an einer echten Aufgabe hängen statt an generischer Ausgabe.

  • claude-mem

    Sitzungsübergreifende Erinnerung, ergänzend zum Repository-Gedächtnis und niemals über dem, was Git sagt.

  • claude-obsidian

    Optionale Anbindung einer Wissensbasis für dauerhaften Geschäfts- und Domänenkontext.

Jedes aktivierte Plugin lädt seine Beschreibungen in jede Sitzung, deshalb ist die aktivierte Menge bewusst klein gehalten.

MCP-Server, bei Bedarf angesteuert

Datenkonnektoren sind ausschließlich auf Lese- und Suchoperationen verdrahtet, damit eine autonome Sitzung diese Systeme nicht verändern kann. Browser-Automatisierung kann auf einer Seite handeln, deshalb ist jede Außenwirkung freigabepflichtig statt still ausgeführt.

  • Context7lesen

    Versionsrichtige Bibliotheks- und Framework-Dokumentation statt Raten aus Trainingsdaten.

  • GitHublesen

    Aktuelle Fakten zu Abhängigkeiten, Kontext aus Pull Requests und Issues sowie Quellcode stromaufwärts.

  • PlaywrightBrowser

    Echter Browser-Nachweis für Oberflächenabläufe, damit ein Screenshot den Nachweis ergänzt statt ihn zu ersetzen.

  • filesystemlesen

    Abgegrenzter, strukturierter Dateizugriff für Recherche in großen Bäumen.

  • memorylesen

    Ein ergänzender Erinnerungsgraph, dem Repository-Zustand untergeordnet.

  • sequential-thinkingschließen

    Strukturiertes mehrstufiges Denken für ein wirklich schweres Problem.

  • opentabsBrowser

    Authentifizierter Browserzugriff über Ihre eigene Sitzung, sparsam eingesetzt und für jeden Schreibvorgang freigabepflichtig.

Spezialisten je Projekt

Sprachexperten, echte statische Analyse und enge Fachwerkzeuge werden pro Repository installiert statt in die gemeinsame Konfiguration eingebacken, denn jedes aktivierte Plugin kostet in jeder Sitzung Kontext.

Bei sicherheitskritischer Arbeit liegt die echte Lücke gegenüber der Modell-Review in echter Analyse: eine Engine für statische Analyse sowie ein Scanner für Abhängigkeiten, Container und Infrastruktur laufen zusätzlich zur Sicherheitsprüfung, weil ein Analysewerkzeug Klassen findet, die eine Modell-Review übersieht.

Aufbau

Was in der Steuerungsebene steckt

Der Harness ist generisch und projektunabhängig. Er wird in ein Repository kopiert, und jedes Projekt füllt seinen eigenen Zustand. Eine einzige lesbare Engine-Datei steuert den Lebenszyklus. Es gibt keine versteckten Dienste und keine Hintergrundprozesse.

EbeneAnzahlRolle
Entwicklungsregeln37Immer geladene Standards, dazu Sprach- und Flächenpakete
Skills33Benannte Einstiegspunkte in die Schleife
Review-Agenten21Unabhängige Prüfer, Fachprüfer und Ermittler
Workflows5Deterministische Fächerläufe mit mehreren Agenten
Deterministische Werkzeuge24Selbstprüfungen, Bewertung, Synchronisation und Statusbeobachtung
Gedächtnisdateien15Dauerhafter Zustand, der die Verdichtung überlebt
Referenzdokumente36Architektur- und Protokollspezifikationen
Vorlagen34Entscheidungsdokumente, Verträge, Runbooks, Bedrohungsmodelle
Engine1Eine einzige lesbare Datei für die Lebenszyklus-Ereignisse

Gemessen am Repository am 5. September 2026. Der Harness ist ein proprietäres Oronts-Produkt und nicht veröffentlicht. Wir zeigen ihn live im Gespräch oder unter NDA.

Ihre Freigaben

Was er niemals allein tut

Autonomie ist bewusst begrenzt. Irreversible und kommerzielle Entscheidungen werden auf der Berechtigungsebene in jedem Modus abgelehnt, auch bei unbeaufsichtigten Läufen, und lassen sich nicht per Anweisung im Gespräch freischalten.

  • Produktsemantik, Sichtbarkeit und Aufbewahrungsfristen
  • Lizenzierung, Preise und öffentlich brechende Schnittstellen
  • Produktionszugriff, Deployment und Release
  • Veröffentlichungen, Force-Pushes und zerstörende Git-Operationen
  • Zerstörende Infrastrukturaktionen
  • Zugriffe auf Zugangsdaten und Geheimnisspeicher
  • Jede Abschwächung einer Sicherheitsmaßnahme

Wenn gefragt werden muss, wird mit Nachweisen gefragt: die Optionen, die Abwägungen, eine Analyse, ein Einwand des unabhängigen Modells und eine Empfehlung. Die Entscheidung liegt bei Ihnen, die Recherche nicht.

Ehrliche Grenzen

Was wir nicht behaupten

Bekannte Grenzen sind technische Tatsachen, nichts zum Verstecken. Ein Enterprise-System ist nicht eines ohne Unsicherheit. Es ist eines, in dem Unsicherheit bekannt, begrenzt, sichtbar und durch Nachweise im Verhältnis zur Tragweite gedeckt ist.

Enterprise heißt nicht maximale Architektur

Der Harness trägt einen Prozess, der die passende Architektur je Projekt herleitet, nicht einen universellen Stack. Ein kleines internes Werkzeug und eine mandantenfähige Plattform bekommen aus demselben System unterschiedliche Strenge.

Ein gesunder Prozess ist kein ausgeliefertes Produkt

Ein grüner Harness belegt, dass der Entwicklungsprozess gesund ist. Ihr Produkt wird produktionsreif, wenn seine eigenen Nachweise grün sind: Lastzahlen, Migrations- und Rollback-Nachweis, Isolationstests und eine Sicherheitsprüfung.

Die Wiederverwendungsprüfung hat eine Grenze

Sie ist eine belastbare Integritätsprüfung gegen Manifeste und Dateien, kein vollständiger Paketauflöser für jedes Ökosystem.

Architekturqualität bleibt teils Urteil

Sie wird durch unabhängige Review gestützt, nicht als automatisierte Garantie ausgegeben.

Ihr Nutzen

Warum das für Sie zählt, nicht für uns

Code, den Sie im Review vertreten können

Jede Änderung führt ihre Abnahmekriterien, ihre Nachweise und die Prüfurteile mit, die sie freigegeben haben.

Entscheidungsdokumente statt Flurwissen

Designentscheidungen sind mit Alternativen und Begründung festgehalten. Ihr Team erbt das Warum, nicht nur das Was.

Tempo als Folge

Sorgfalt ist das Ziel. Tempo entsteht daraus, Vorhandenes nicht neu zu bauen und entschiedene Fragen nicht erneut zu führen.

Vollständiges Eigentum bei der Übergabe

Die Steuerungsebene lenkt die Arbeit. Der Code, die Entscheidungen und die Dokumentation gehören Ihnen.

Fragen, die Technikverantwortliche stellen

KI schreibt Code innerhalb einer kontrollierten Schleife, mit einem verantwortlichen Senior-Ingenieur für das Ergebnis. Entscheidend ist nicht, wer die Zeile getippt hat, sondern was wahr sein musste, bevor sie ausgeliefert werden durfte: Abnahmekriterien erfüllt, Tests und Laufzeitnachweise aktuell, ein unabhängiges Modell ohne Befund und die Designentscheidung schriftlich festgehalten.
Eine Stildatei liefert einheitliche Formatierung und ein paar Regeln. Sie hat keinen dauerhaften Zustand, keine unabhängige Review, und sie verliert das Ziel, sobald der Kontext verdichtet wird. Der Harness ergänzt Gedächtnis über Kontextgrenzen hinweg, Review durch ein anderes Modell, deterministische Prüfungen und Sperren, die Arbeit anhalten statt nur zu warnen.
Das wird als nicht verfügbar protokolliert, und eine zusätzliche unabhängige Perspektive läuft an seiner Stelle. Der Harness meldet niemals eine Prüfung, die nicht stattgefunden hat. Genau diese Regel macht die Nachweiskette in einem Audit brauchbar.
Nein. Deployment, Release, Veröffentlichung, Force-Push, zerstörende Git- und Infrastrukturoperationen sowie Zugriffe auf Zugangsdaten sind auf der Berechtigungsebene in jedem Modus gesperrt. Sie lassen sich während einer Sitzung nicht per Anweisung freischalten.
Der Harness ist ein proprietäres Oronts-Produkt und nicht Teil der Lieferung. Sie erhalten das Ergebnis: Ihren Code, Ihre Tests, Ihre Entscheidungsdokumente und Ihre Dokumentation, mit vollem Eigentum und ohne Abhängigkeit von unserem Werkzeug, um das System zu betreiben oder zu ändern.
Ja. Wir gehen einen echten Lauf im Gespräch durch, bei sensiblen Repository-Inhalten unter NDA. Der 90-Tage-Produktionspilot ist der übliche Weg, das an Ihrer eigenen Codebasis zu sehen.

Sehen Sie es an einem echten Problem laufen

Bringen Sie eine Änderung mit, bei der Ihnen sonst mulmig wäre. Wir gehen durch, wie die Schleife damit umgeht, welche Nachweise entstehen und an welcher Stelle sie stoppen und Sie fragen würde.

Mit wem Sie arbeiten

HRB 288224
Eingetragen in München
15+
Jahre, gründergeführt
DE · EN · AR
Liefersprachen
2
Open Source auf GitHub
EU
Datenresidenz, Frankfurt
AVV/DPA
Unterschriftsbereit, Art. 28

Engagement-Stufen

Oronts arbeitet mit ernsthaften Teams, die Senior-Delivery brauchen, kein Billig-Outsourcing.

Production Pilot
ab 25k EUR
Individualsoftware- und KI-Projekte
ab 50k EUR
Laufende technische Retainer
ab 15k EUR/Monat

Der genaue Preis hängt von Umfang, Verantwortung, Liefergeschwindigkeit, Teamgröße, Integrationen, Support-Erwartungen und Produktionsrisiko ab.