Terminal Ops

Was macht Terminal Ops?

Verwenden Sie dies, wenn der Benutzer echte Repository-Ausführung wünscht: Commands ausführen, Git-Status prüfen, CI oder Builds debuggen, einen schmalen Fix vornehmen und genau berichten, was geändert und was verifiziert wurde.

Dieser Skill ist bewusst enger gefasst als allgemeine Code-Beratung. Er ist ein Operator-Workflow für evidenzbasierte Terminal-Ausführung.

Skill Stack

Diese ECC-nativen Skills bei Bedarf in den Workflow einbeziehen:

• verification-loop für exakte Nachweisschritte nach Änderungen
• tdd-workflow wenn der richtige Fix eine Regressionstestabdeckung benötigt
• security-review wenn Geheimnisse, Authentifizierung oder externe Eingaben beteiligt sind
• github-ops wenn die Aufgabe von CI-Läufen, PR-Status oder Release-Status abhängt
• knowledge-ops wenn das verifizierte Ergebnis in den dauerhaften Projektkontext aufgenommen werden soll

Wann verwenden

• Der Benutzer sagt „fix", „debug", „run this", „check the repo" oder „push it"
• Die Aufgabe hängt von Command-Ausgabe, Git-Status, Testergebnissen oder einem verifizierten lokalen Fix ab
• Die Antwort muss unterscheiden zwischen: lokal geändert, lokal verifiziert, committed und gepusht

Schutzmechanismen

• Vor dem Bearbeiten prüfen
• Im Nur-Lese-Modus bleiben, wenn der Benutzer nur eine Prüfung/Überprüfung angefordert hat
• Repository-lokale Skripte und Helfer bevorzugen gegenüber improvisierten Ad-hoc-Wrappern
• Nicht behaupten, dass ein Fix abgeschlossen ist, bevor der Nachweisbefehl erneut ausgeführt wurde
• Nicht behaupten, dass gepusht wurde, es sei denn, der Branch wurde tatsächlich auf das Remote-Repository übertragen

Workflow

1. Arbeitsfläche auflösen

Folgendes klären:

• exakter Repository-Pfad
• Branch
• lokaler Diff-Status
• angeforderter Modus:
  • inspect
  • fix
  • verify
  • push

2. Fehlschlagende Fläche zuerst lesen

Vor jeder Änderung:

• Fehler prüfen
• Datei oder Test prüfen
• Git-Status prüfen
• Bereitgestellte Logs oder Kontext verwenden, bevor blind erneut gelesen wird

3. Fix schmal halten

Einen dominanten Fehler nach dem anderen beheben:

• zuerst den kleinsten nützlichen Nachweisbefehl verwenden
• erst zu einem größeren Build-/Testdurchlauf übergehen, wenn der lokale Fehler behoben ist
• Wenn ein Befehl immer wieder mit derselben Signatur fehlschlägt, breite Wiederholungen einstellen und den Umfang eingrenzen

4. Exakten Ausführungsstatus berichten

Exakte Statuswörter verwenden:

• inspected
• changed locally
• verified locally
• committed
• pushed
• blocked

Ausgabeformat

SURFACE
- repo
- branch
- requested mode

EVIDENCE
- failing command / diff / test

ACTION
- what changed

STATUS
- inspected / changed locally / verified locally / committed / pushed / blocked

Fallstricke

• Nicht aus veralteten Speicher arbeiten, wenn der Live-Repository-Status gelesen werden kann
• Einen schmalen Fix nicht zu einer repositoryweiten Änderung ausweiten
• Keine zerstörerischen Git-Befehle verwenden
• Unabhängige lokale Arbeiten nicht ignorieren

Verifikation

• Die Antwort benennt den Nachweisbefehl oder -test
• Git-bezogene Arbeiten benennen Repository-Pfad und Branch
• Jede Push-Behauptung enthält den Zielbranch und das exakte Ergebnis