Auftragsbuch: 'feature/soul-push-verify' angenommen (Ein-Klick-Gate)

2026-07-13 18:23:33 +02:00
parent 5690217d84 a1957d7094
commit 5436e4df16
1 changed files with 9 additions and 4 deletions
@@ -19,10 +19,15 @@ sauberes Handwerk.
   Ursprung, den das Auftragsbuch als „kaputt aufgesetzt" aussortiert (Vorfall
   12.07.2026: feature/cleanse-skill-index war ein git-init-Orphan mit ~/.hermes-Dateien).
   Branch-Namen: `wartung/<kurz>`, `feature/<kurz>` oder `doku/<kurz>`.
-   SELBSTCHECK vor dem Push (Pflicht, beide Zeilen müssen klappen):
+   SELBSTCHECK vor dem Push (Pflicht, DREI Zeilen müssen klappen):
-   `git merge-base HEAD origin/main` (muss einen Hash liefern) und
+   1. `git merge-base HEAD origin/main` (muss einen Hash liefern)
-   `git fetch origin && git rebase origin/main` (veraltete Basis sofort begradigen;
+   2. `git fetch origin && git rebase origin/main` (veraltete Basis sofort begradigen;
-   Konflikt → `kanban_block`, nicht raten). Committe NUR Dateien, die zum Repo gehören —
+      Konflikt → `kanban_block`, nicht raten)
   3. NACH dem Push: `git ls-remote origin <branch>` prüfen, dass der Branch WIRKLICH
      auf Gitea angekommen ist — ist die Ausgabe LEER → `kanban_block` mit Fehler,
      NICHT `kanban_complete`. Erst wenn die Ausgabe den Hash liefert, ist der Branch
      nachweislich da und „fertig".
   Committe NUR Dateien, die zum Repo gehören —
   `~/.hermes`-Artefakte (.usage.json, .bundled_manifest, Skill-Indizes) gehören NIE hinein.
 4. Gate vor dem Push: `python3 -m py_compile` für JEDE geänderte .py-Datei. Frontend
   (`frontend/`) nur anfassen, wenn der Auftrag es verlangt — die Box kann kein