Hwip Auto — Zeitbegrenzter Autonomer Arbeitsmodus

Was macht Hwip Auto — Zeitbegrenzter Autonomer Arbeitsmodus?

Arbeiten Sie autonom für ein festgelegtes Zeitbudget: Erkunden → Planen → Implementieren → Verifizieren → Committen, eine Einheit nach der anderen. Der Benutzer steuert von seinem Telefon aus über hwip_ask-Schaltflächen; wenn er nicht antwortet, fahren Sie mit einem angegebenen sicheren Standard fort, anstatt anzuhalten. Der gesamte Durchlauf erfolgt in einer einzigen Antwort – das Beenden Ihres Zuges beendet den Modus.

Vorbedingungen – Start verweigern, wenn nicht erfüllt

• Eine Hook-ID ist konfiguriert – hookId in ~/.hwip/config.json (was hwip install schreibt) oder der HWIP_HOOK_ID-Override. Der SessionStart-Kontext endet mit Mode: two-way (notify + ask), wenn eine vorhanden ist; Mode: one-way bedeutet, dass es keinen Steuerungskanal gibt – verweigern und den Benutzer auf /hwip-config verweisen.
• Nicht stummgeschaltet. Wenn /hwip-mode NOTIFICATIONS: muted meldet, verweigern: Autonomer Modus ohne Benachrichtigungen ist unbeaufsichtigte Arbeit ohne Steuerung. Schlagen Sie /hwip-mode unmute vor.
• Explizite Benutzeraufforderung. Lösen Sie diesen Modus niemals selbst aus, weil eine Aufgabe „lang aussieht“. Der Benutzer meldet sich mit /hwip-auto ... an.

Argumente

/hwip-auto [Dauer] [Aufgabenbeschreibung...]

• Dauer – 2h, 90m, 1h30m oder eine bloße Zahl, die Minuten bedeutet. Standard: 1h. Begrenzung auf 10m–8h.
• Aufgabe – alles nach der Dauer. Wenn ausgelassen, leiten Sie es aus dem bisherigen Gespräch ab; wenn es keines gibt, schlagen Sie 2–3 Kandidatenaufgaben in der Startanfrage vor (z. B. fehlgeschlagene Tests beheben, Lint-Warnungen beseitigen, TODO-Aufräumaktion).

Einrichtung

1. Frist aufzeichnen (eine Zustandsdatei überlebt die Komprimierung des Kontexts – lesen Sie sie erneut, wenn Sie sich nicht sicher sind, wie viel Zeit noch übrig ist):

   HASH=$(printf '%s' "${CLAUDE_PROJECT_DIR:-$(pwd)}" | cksum | cut -d' ' -f1)
   STATE_DIR="${XDG_STATE_HOME:-$HOME/.local/state}/hwip"
   mkdir -p "$STATE_DIR"
   MINUTES=120   # aus dem Dauer-Argument geparst
   DEADLINE=$(( $(date +%s) + MINUTES * 60 ))
   printf '%s %s\n' "$DEADLINE" "$MINUTES" > "$STATE_DIR/auto-$HASH"
   date -r "$DEADLINE" 2>/dev/null || date -d "@$DEADLINE"   # macOS | Linux
   

2. Schutz für geschützte Branches – niemals direkt auf main/master/develop arbeiten:

   BRANCH=$(git branch --show-current 2>/dev/null)
   case "$BRANCH" in
     main|master|develop) git checkout -b "auto/$(date +%Y%m%d)-<aufgaben-slug>" ;;
   esac
   

3. Verifier entdecken, bevor Sie Code schreiben: die deterministischen Prüfungen des Projekts (Test-/Lint-/Typecheck-/Build-Befehle aus package.json, Makefile, CI-Konfiguration). Diese steuern jeden Commit. Wenn das Projekt keine hat, sagen Sie dies in der Startanfrage und behandeln Sie „Code kompiliert/läuft“ als minimale Hürde.

4. Startanfrage – ein hwip_ask vor dem Berühren von irgendetwas:

   • title: "Auto-Modus: ()"
   • body: 2–3-zeiliger Plan + welcher Verifier Commits prüft + der Branchname
   • actions: [{id:"start", label:"Starten", style:"primary"}, {id:"stop", label:"Abbrechen"}] (wenn die Aufgabe mehrdeutig war, ersetzen Sie "Starten" durch 2–3 Kandidatenaufgaben-Buttons)
   • placeholder: "Plan oder Umfang anpassen..."
   • timeout: 180, fallback: "start" (oder der empfohlene Kandidat)

   Freitext-Antworten ändern den Plan; stop bricht den Modus ab (Zustandsdatei entfernen).

Die Schleife

Teilen Sie die Aufgabe in Einheiten auf: die kleinsten unabhängig verifizierbaren, commitfähigen Blöcke (~15–45 Min. pro Stück). Dann für jede Einheit:

1. Zeitprüfung (vor dem Start jeder Einheit):

   HASH=$(printf '%s' "${CLAUDE_PROJECT_DIR:-$(pwd)}" | cksum | cut -d' ' -f1)
   read -r DEADLINE MINUTES < "${XDG_STATE_HOME:-$HOME/.local/state}/hwip/auto-$HASH"
   echo "Verbleibend: $(( (DEADLINE - $(date +%s)) / 60 ))m von ${MINUTES}m"
   

   Wenn die verbleibende Zeit unter der Abschlussschwelle liegt – 10 % des Budgets, mindestens 5 Minuten – keine neue Einheit starten; zum Abschluss übergehen.

2. Erkunden → Planen der Einheit (zuerst den relevanten Code lesen; keine blinden Bearbeitungen).

3. Implementieren der Einheit.

4. Verifizieren mit den deterministischen Prüfungen. Grün ist das einzige Bestehenssignal – „sieht korrekt aus“ ist kein Verifier, und niemals einen fehlgeschlagenen Test schwächen oder löschen, um auf Grün zu kommen. Bei Fehlschlag reparieren und erneut verifizieren, maximal 3 Versuche; wenn immer noch rot, die Änderungen der Einheit rückgängig machen (git checkout -- <dateien> / git stash), damit der Baum sauber bleibt, als übersprungen aufzeichnen und fortfahren.

5. Committen der grünen Einheit mit einer klaren konventionellen Commit-Nachricht. NICHT pushen.

6. Heartbeat – nach einem Commit eine kurze hwip_notify ("✅ – m übrig"), aber höchstens eine pro ~15 Minuten; kleine Einheiten bündeln. Blocker sind die Ausnahme: sofort eine Benachrichtigung mit priority: "high" senden, sobald einer auftritt.

Wiederholen, bis die Einheiten erledigt sind oder die Abschlussschwelle erreicht ist.

Frageprotokoll – niemals anhalten, niemals zerstören

Fragen während des Laufs erfolgen über hwip_ask (niemals AskUserQuestion, niemals einfachen Text – CORE_RULES-Regeln 3/10 gelten):

• Die empfohlene Standardeinstellung zuerst nennen, im Textkörper anmerken, dass bei Timeout automatisch fortgefahren wird, timeout: 180 setzen (bis zu 600 für wirklich große Entscheidungen) und fallback auf die ID dieser Standardeinstellung.
• Jede durch Fallback gelöste Entscheidung protokollieren – der Abschlussbericht listet sie auf, damit der Benutzer prüfen kann, was ohne ihn entschieden wurde.
• Jede Antwort ist eine direkte Anweisung: sofort anwenden. Eine stop-Antwort (oder eine Freitext-Sitzungsbeendigung) bedeutet, jetzt abschließen.
• Irreversible oder nach außen gerichtete Aktionen sind niemals fallback-fähig: Push, PR/Veröffentlichen, Bereitstellen, Datenlöschung, Schema-Drops, Force-Vorgänge, alles außerhalb des Arbeitsverzeichnisses. Für diese MUSS der Fallback skip sein – bei Timeout überspringen Sie die Aktion und notieren sie, Sie führen sie nicht aus. Nur ein expliziter Button-Klick autorisiert sie.

Abschluss

1. Die laufende Einheit beenden oder rückgängig machen (gleiche 3-Versuche-Regel – niemals den Baum rot oder schmutzig hinterlassen).
2. Die Zustandsdatei entfernen: rm -f "${XDG_STATE_HOME:-$HOME/.local/state}/hwip/auto-$HASH".
3. Abschlussbericht im Antworttext: abgeschlossene Einheiten (mit Commit-Hashes), übersprungene Einheiten und warum, jede durch Fallback gelöste Entscheidung und was noch übrig ist.
4. Abschlussanfrage:
   • actions: [{id:"extend", label:"+30m"}, {id:"review", label:"Überprüfen"}, {id:"done", label:"Fertig", style:"primary"}]
   • timeout: 300, fallback: "done"
   • extend → eine neue Frist (+30m) in die Zustandsdatei schreiben und die Schleife erneut betreten; review → durch den Diff gehen; done → beenden.

Wenn etwas schief geht

• Keine Hook-ID (Mode: one-way) – Zwei-Wege-Tools sind nicht verfügbar; Auto-Modus kann nicht ausgeführt werden. Führen Sie /hwip-config aus, um ihn einzurichten.
• Zustandsdatei während des Laufs fehlt (z. B. Zustandsverzeichnis gelöscht): die Frist als jetzt behandeln – abschließen, anstatt zu raten, wie viel Budget noch übrig ist.
• Benutzer tippt während des Laufs im Terminal: diese Nachricht ist Steuerungseingabe, genau wie eine hwip_ask-Antwort. Anwenden und die Schleife fortsetzen.
• Verifier ist instabil (derselbe Befehl wechselt ohne Änderung zwischen Grün und Rot): keine Versuche für Wiederholungen verschwenden – als Blocker über hwip_notify (priority: "high") melden und zur nächsten Einheit übergehen.