Das Werkzeug ist nicht der Architekt: die Engineering-Entscheidung verantworten
Clowdrs Engineering-Verantwortung auf Architektur, generierten Code, Verhaltensprüfungen, Integration und eine wartbare Übergabe anwenden.

- Primärer Practice Area
- Engineering
- Editorial Format
- Position
- Artikelautor
- Robert Trippler
- Veröffentlicht
- Aktualisiert
- Zusätzliche Practice Areas
- Production & Verification
Ein Beitrag braucht eine verantwortliche Person im Engineering, die erklären kann, warum er ins Spiel gehört, und ihn bei Änderungen am umgebenden System anpassen kann. Diese Anforderung gilt bei jeder Werkzeugwahl, auch wenn ein Agent den gesamten Patch schreibt.
Clowdr verlangt, dass Contributors ihre Arbeit erklären, überarbeiten, integrieren, prüfen und übergeben können. Diese Position überträgt die Regel auf Code. Sie behauptet nicht, dass ein bestimmtes Werkzeug den Projekterfolg bestimmt.
Die Grenzen vor Annahme des Patches verantworten
Benennt das Verhalten, das die Aufgabe liefern muss, und die Systeme, die sie ändern darf. Erklärt, wo Zustand liegt, wie Fehler behandelt werden und von welchen bestehenden Annahmen die Änderung abhängt. Die Erklärung soll einem anderen Contributor spätere Anpassungen ermöglichen.
Bei einer hypothetischen Änderung am Speichersystem muss die verantwortliche Person erklären, wann Daten geschrieben werden, was bei einer Unterbrechung geschieht und wie ein älterer Spielstand gelesen wird. Eine generierte Umsetzung, die einmal funktioniert, entscheidet diese Fragen nicht.
Kann die Person den Patch nicht erklären, pausiert die Annahme. Vereinfacht ihn, untersucht das relevante Verhalten oder ersetzt die Umsetzung, bis sie verantwortet werden kann. Die Aufgabe weiterzugeben überträgt die Verantwortung nicht an das Werkzeug.
Das Verhalten prüfen, auf das das Spiel angewiesen ist
Nutzt Prüfungen, die ein Scheitern des zugesagten Verhaltens aufdecken können. Konzentriert automatisierte Tests auf relevante Grenzen und Fehlerfälle. Prüft anschließend den integrierten Spielerpfad, in dem die Änderung wirkt.
Unit-Tests belegen nicht den vollständigen Build Proof. Der Release Candidate muss auf jeder angegebenen Plattform starten, laufen und den kritischen Pfad ohne offene Release Blockers abschließen. Haltet Prüfungen, Build und Bedingungen, Befund sowie Grenzen der Abdeckung fest.
Ein Speichertest kann korrekte Daten beim Schreiben und Lesen bestätigen, während die Prüfung im Build einen Menüpfad findet, der den falschen Slot lädt. Behandelt das als unterschiedliche Nachweise und behebt den Fehler, bevor das relevante Verhalten als bereit gilt.
Eine wartbare Übergabe hinterlassen
Haltet die Änderung mit Umfang, Entscheidungen, Prüfungen und bekannten Grenzen in der Versionsverwaltung fest. Klärt wesentliche Quellen, Abhängigkeiten, Lizenzen und Credits. Dokumentiert wesentliche AI-Unterstützung oder bewussten Verzicht gemäß der AI Production Note des Projekts.
Der nächste Contributor soll die verantwortliche Person finden, eine relevante Prüfung reproduzieren und offene Unsicherheiten erkennen können. Undurchsichtige Komplexität, die niemand überarbeiten kann, ist nicht allein deshalb verantwortete Arbeit, weil sie kompiliert.
Der Clowdr-AI-Standard definiert die gemeinsame Regel; How We Ship erklärt die Release-Nachweise. Nutzt das Werkzeug, das die Arbeit unterstützt, und verantwortet anschließend die Engineering-Entscheidung, bei der es geholfen hat.