Signierskript richtet den Klon selbst aus - kein Handgriff mehr noetig

Der Waechter brach bisher ab und legte dem Menschen einen Befehl vor. Jetzt
bringt er den Klon selbst auf origin/main, solange das nachweislich verlustfrei
ist: reiner Rueckstand wird vorgespult; Commits, die nur lokal liegen, deren
Tree aber dem des gemeinsamen Vorfahren gleicht, tragen inhaltlich nichts bei
und werden verworfen (Reflog haelt sie 90 Tage). Nur Commits, die auch den
Inhalt aendern, fuehren weiterhin zum Abbruch mit beiden Wegen zur Wahl.

Damit entfaellt die Vorbereitung vor einem Signierlauf vollstaendig - wichtig,
weil die bisher dokumentierte Vorbereitung ausgerechnet `git pull` war, also
genau der Befehl, der auf einem Klon von vor dem Rewrite die entfernten Commits
zurueckgeholt haette.

Fuenf Lagen gegen Wegwerf-Repositories geprueft: gleich, zurueck, inhaltslos
voraus, echte ungepushte Arbeit, echte Divergenz.

APPLE_DEV_BACKLOG.md, OFFEN.md und AGENTS.md (Abschnitt AJ) nachgezogen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

APPLE_DEV_BACKLOG.md

@@ -53,31 +53,26 @@ danach zu prüfen ist. `AGENTS.md` ist nur für das *Warum* nötig.
 
 ### Vorher
 
-Nichts vorzubereiten außer einem aktuellen Stand:
+**Nichts vorzubereiten** - auch kein `git pull`. Das Skript holt `origin/main`
+selbst und bringt den Klon darauf, solange das nachweislich verlustfrei ist:
+ein reiner Rückstand wird vorgespult, und Commits, die zwar nur lokal liegen,
+gegenüber dem gemeinsamen Vorfahren aber **keine einzige Datei ändern**, werden
+verworfen. Beides sagt es an; das Reflog hält Verworfenes noch 90 Tage.
 
-```bash
-git pull
-```
+> **Warum kein `git pull`:** am 07.09.2026 sind drei Commits am Ende von `main`
+> entfernt und der Branch per Force-Push zurückgesetzt worden. Ein Klon von davor
+> steht damit **vor** `origin/main` - dort wäre `git pull` genau das Falsche: der
+> Merge hängt die entfernten Commits wieder in die Historie, und der nächste Push
+> stellte sie auf dem Server wieder her (er ginge sogar ohne `--force` durch).
+> Genau diese Lage räumt das Skript von sich aus auf.
 
-> **Einmalig, für jeden Klon von vor dem 07.09.2026:** an diesem Tag sind drei
-> Commits am Ende von `main` entfernt und der Branch per Force-Push
-> zurückgesetzt worden. Ein älterer Klon steht damit **vor** `origin/main` und
-> `git pull` ist dort das Falsche — es würde die entfernten Commits per Merge
-> zurückholen, und der nächste Push stellte sie auf dem Server wieder her (er
-> ginge sogar ohne `--force` durch). Richtig ist einmalig:
->
-> ```bash
-> git fetch origin && git reset --hard origin/main
-> ```
->
-> Das Skript erkennt die Lage selbst, listet die betroffenen Commits auf und
-> bricht ab, statt zu raten — es entscheidet aber nicht für dich, weil dieselbe
-> Lage auch echte ungepushte Arbeit sein kann.
-
-Das Skript prüft das selbst und **bricht ab**, wenn der Arbeitsbaum nicht sauber
-oder `HEAD` nicht gleich `origin/main` ist - sonst signierte es einen veralteten
-Stand. Ebenso bricht es ab, wenn das Zielgerät nicht im Team eingetragen ist
-(„Your team has no devices"); das ist dann eine Portal-Sache, kein Projektfehler.
+Ab **hier** entscheidet es nichts mehr allein: liegen lokale Commits, die **auch
+den Inhalt** ändern, bricht es ab und legt dir beide Wege vor (pushen oder
+verwerfen) - ungepushte Arbeit wirft es nie weg.
+Ein nicht sauberer Arbeitsbaum bricht den Lauf ebenfalls ab - er ist die
+Voraussetzung dafür, dass Zurechtrücken oben gefahrlos ist. Und ebenso bricht er
+ab, wenn das Zielgerät nicht im Team eingetragen ist („Your team has no
+devices"); das ist dann eine Portal-Sache, kein Projektfehler.
 
 ### Der Lauf