Teil 21. Qwen-Code-Prozess für DataLakeHouse

Nun kann der Prozess als Qwen-Prozess gestaltet werden:

/sdd:profile -> /sdd:contract -> /sdd:build -> /sdd:verify -> /sdd:release

Die Hauptidee: Ein einzelner Befehl sollte nicht den gesamten Prozess ausführen. In Bankdaten ist es gefährlich, wenn der Agent die Quelle selbst profiliert, den Vertrag selbst entscheidet, SQL selbst schreibt und sich selbst überprüft.

Projektbefehle

Das Beispiel enthält:

.qwen/commands/sdd/profile.md
.qwen/commands/sdd/contract.md
.qwen/commands/sdd/build.md
.qwen/commands/sdd/verify.md
.qwen/commands/sdd/release.md

Die Befehle sind nach menschlichen Bestätigungspunkten getrennt:

• profile sammelt Fakten über die Quelle;
• contract formuliert oder überprüft die Zusage;
• build ändert dbt-Modelle;
• verify führt Prüfungen aus und sucht nach Abweichungen;
• release stellt das Beweispaket zusammen.

Skills und Subagenten

data-contract-review speichert die Review-Checkliste. data-profiler liest Quellen und gibt ein Manifest zurück, ohne Modelle zu schreiben. Generator und Reviewer müssen unterschiedliche Rollen sein. Sonst überprüft der Agent seine eigenen Vermutungen.

Der Reviewer im reinen Lesemodus ist besonders wichtig nach /clear: Wenn er die Änderung anhand der Repository-Dateien nicht verstehen kann, hat der Autor die Bedeutung im Chat hinterlassen.

Hooks

Ein Hook kann das Schreiben in models/marts/ blockieren, wenn die Änderung ein Feld pii_ hinzufügt oder die YAML-Vertragsdatei ohne Bestätigungsmarkierung ändert. Im Lernbeispiel wird der Hook konzeptionell beschrieben; er sollte nach der ersten praktischen Prüfung geschrieben werden, wenn das Team bereits versteht, welche Verstöße sich wiederholen.

Minimale Ausgabe

Erstellen Sie die Prozesskarte:

/sdd:profile -> Schema Manifest
/sdd:contract -> ODCS/ODPS-Update
/sdd:build -> dbt-Modelländerung
/sdd:verify -> dbt build + Prüffakten
/sdd:release -> Beweispaket
data-contract-review -> Reviewer-Bericht

Wenn ein Befehl kein Artefakt hinterlässt, wird er beim ersten Durchlauf nicht benötigt.

Analyse für den Leser

Die Qwen-Befehle in diesem Kapitel sollten nicht zu einem magischen Bedienfeld werden. Ihr Sinn liegt in der Trennung der Verantwortlichkeiten. /sdd:profile beobachtet die Quelle. /sdd:contract formuliert die Zusage. /sdd:build ändert die Modelle. /sdd:verify sucht nach Abweichungen. /sdd:release sammelt Beweise. Wenn ein einzelner Befehl alles erledigt, löscht er die menschlichen Bestätigungen und verwandelt SDD wieder in einen Autopiloten.

Skills und Subagenten sind nützlich, wenn sie die Rolle einschränken. Der Data-Profiler sollte keine Marts schreiben. Der Vertrags-Reviewer sollte kein SQL korrigieren. Der Generator sollte nicht selbst bestätigen, dass seine Änderung sicher ist. Eine solche Trennung erscheint formal, bis ein Fehler auftritt. Nach dem Fehler zeigt genau die Rolle, wer das Problem hätte bemerken sollen und welches Artefakt es hätte auffangen sollen.

Hooks sind die nächste Disziplin-Stufe, aber sie sollten nicht vor dem Prozess geschrieben werden. Wenn das Team noch nicht versteht, welche Verstöße sich wiederholen, wird der Hook entweder schwach oder lästig sein. Ein guter Hook blockiert eine bekannte gefährliche Klasse von Änderungen: PII in models/marts/, YAML-Vertrag ohne Genehmigungsmarkierung, Änderung des Grains ohne Auswirkungsnotiz. Er ersetzt nicht das Review, sondern verhindert, dass ein offensichtlicher Fehler das Review überhaupt erreicht.

Dieses Kapitel verbindet den gesamten Band zu einem Arbeitszyklus. Danach sollte der Leser sagen können, mit welchem Befehl die Quellenfakten gesammelt werden, mit welchem der Vertrag geprüft wird, mit welchem das Modell gebaut wird, mit welchem die Prüfungen ausgeführt werden und mit welchem das Release vorbereitet wird. Wenn diese Trennung fehlt, erhält der Agent wieder zu viel Macht über die Daten.

Praxis

Führen Sie dieselbe Anfrage in zwei Rollen aus: Autor und Reviewer. Der Autor kann Änderungen vorschlagen; der Reviewer muss im reinen Lesemodus arbeiten. Vergleichen Sie, welche Anmerkungen erst nach der Rollentrennung auftauchen.

Häufiger Fehler

Einen einzigen Befehl /sdd:do-everything zu erstellen. Er ist in der Demonstration praktisch, aber in Bankdaten gefährlich: Die menschliche Bestätigung verschwindet, und die Vertragsabweichung wird zu spät entdeckt.

Kontrollfragen

1. Warum sollte ein Befehl den gesamten Prozess nicht ohne Unterbrechungen ausführen?
2. Worin unterscheidet sich ein Skill von einem Subagenten?
3. Wo sollte die menschliche Bestätigung stehen?