Engineering-Verfassung
Überblick
Eine tragbare Grundsatzordnung für die Ingenieurspraxis, aufgeteilt in fokussierte Fähigkeiten. Diese Fähigkeit ist der Index: Sie legt die unveränderlichen Prinzipien dar und leitet Sie zu der für Ihre Aufgabe spezifischen Fähigkeit weiter. Die vollständige Begründung lebt in references/engineering-constitution.md, das zusammen mit dieser SKILL.md gebündelt ist, sodass die Verfassung überallhin mitreist, wo die Fähigkeit installiert ist.
Kernidee: Softwareentwicklung ist Programmieren, integriert über Zeit. Optimieren Sie für das langlebige System – seinen Betrieb, sichere Änderungen, Wiederherstellung bei Ausfällen – nicht für die erste Bereitstellung.
Die Acht Unveränderlichen Prinzipien
- Verstehen vor dem Bauen. Kein Code ohne genehmigtes Design.
- Jede Entscheidung mit ihrer Begründung aufzeichnen – und was Sie verworfen haben.
- Tests sind ein Kontrollinstrument, keine Formalität – und Verhaltensänderung erfolgt test-first. Ein fehlschlagender Test ist Information, wird niemals wegredigiert. Strukturelle Änderungen sind stattdessen durch das Bestehen der unveränderten Testsuite blockiert.
- YAGNI, kompromisslos.
- Automatisieren Sie das Wiederholbare.
- Softwareentwicklung ist Programmieren, integriert über Zeit.
- Eine nicht durchgesetzte Regel ist ein Vorschlag. Binden Sie Regeln an Werkzeuge oder kennzeichnen Sie sie als Prüfer-Entscheidung.
- Die ausdrücklichen Anweisungen des Benutzers haben Vorrang vor diesem Dokument. Rangfolge: Benutzer → Verfassung → Werkzeug-Standardwerte.
Welche Fähigkeit Benötige Ich?
Stufe 1 – universell (gilt für jedes Projekt):
| Ihre Aufgabe | Fähigkeit |
|---|---|
| Eine Funktion starten, eine Idee in eine Spezifikation/einen Plan umwandeln | designing-before-building |
| Eine Entscheidung wurde getroffen; sie aufschreiben (ADR, Index, verworfene Ideen) | recording-decisions |
| Commiten, Commit-Nachrichten schreiben, automatisierte Releases | conventional-commits-and-releases |
| Tests schreiben/ändern; Berechtigungs-/Rollenregeln; ein Test ist bei einem Refactoring fehlgeschlagen | tests-as-a-control |
| Code schreiben oder refaktorisieren; eine Änderung strukturieren; DRY-Entscheidungen | change-hygiene-and-code-craft |
| UI, Komponenten, Styling, Barrierefreiheit bauen | interface-craft-and-accessibility |
| CI, Pre-Push-Hooks, Task-Runner, Merge-Gates | merge-gates-and-automation |
| Logging, Metriken, Tracing, Health Checks, SLOs, Alarme | observability-and-slos |
| Nicht vertrauenswürdige Eingaben, Secrets, Authentifizierung, Abhängigkeiten, Bedrohungsmodellierung | defense-in-depth-security |
| Heiße Pfade, Paginierung, N+1, Listen-Endpunkte, öffentliche Schnittstellen | performance-and-scale |
| Planung eines Deployments, Rollbacks oder eines Incidents/Postmortems | resilience-and-deploy-safety |
Stufe 2 – stack-spezifisch (nur laden, wenn das Werkzeug/Thema vorhanden ist):
| Ihre Aufgabe | Fähigkeit |
|---|---|
| PostgreSQL, PostGraphile, RLS, SQL-Dateien, den App→GraphQL→DB-Pfad | postgres-postgraphile-rls-and-sql |
| GraphQL-Abfragen, die zwischen UI und Tests geteilt werden; Route-/Schema-Vertragstests | graphql-contract-testing |
| Schemaänderung mit Daten, die überleben müssen – Migrationen, Backfills | zero-downtime-migrations |
| Deployment auf Kubernetes/AKS, Cloud-Secrets, progressive Rollouts, Umgebungen pro PR | cloud-delivery-aks |
Wie Diese Fähigkeiten auf Ein Neues Projekt Angewendet Werden
- Stufe 1 bleibt unverändert. Jede Fähigkeit oberhalb der Linie gilt für jedes Projekt – Web-App, Pipeline, CLI, Bibliothek.
- Stufe 2 ist austauschbar. Wenn der Stack abweicht, werden die Fähigkeiten der Stufe 2 nicht ausgelöst (ihre Beschreibungen sind stackspezifisch) und Sie ersetzen sie durch Äquivalente. Die Prinzipien, die sie umsetzen (ein Datenpfad, endgültige Durchsetzung niedrig, Vertragsschnittstellen, reversible Deployments), gelten weiterhin.
- An den Lebenszyklus anpassen. Ein Projekt vor dem Start oder nur lokal wendet Zero-Downtime-Migrationen, Canary und formelle Incident-Prozesse als Regel jetzt schreiben, bei Auslöser aktivieren an. Geben Sie den Modus des Projekts in seinem ersten Entscheidungsprotokoll an.
Warnsignal
Wenn Sie im Begriff sind, Code zu schreiben, zu committen, zu deployen oder einen Test zu ändern und Sie nicht die relevante obige Fähigkeit konsultiert haben – halten Sie an und laden Sie sie zuerst. Die Verfassung überschreibt die Standardgewohnheit (Prinzip 7); die Gewohnheit ist es, die sie korrigiert.