olonok69/cursor_code_ml_engineer

day — den Arbeitstag öffnen und schließen

Warum dies ein Skill und nicht nur ein Dokument ist. Die Regel "pull am Anfang, push am Ende" stand monatelang in einem Operations-Dokument und wurde auf der Publisher-Maschine nicht befolgt — nichts zeichnete eine Synchronisation auf, also konnte nichts die Abweichung zeigen. Dokumentation kann keine Gewohnheit erzwingen; eine aufrufbare Routine kann das. Lies dies für die Form, nicht die Befehle: jeder gefährliche Schritt beantwortet zuerst eine Frage, und wo die Antwort mehrdeutig ist, stoppt und fragt es.

Das gemeinsame Record unter data/ ist nur so aktuell wie die letzte Synchronisation, und nichts anderes fordert diese an. Zwei Momente, verpackt:

day start     # pull das Neueste vom Team, dann ein kurzes Orientierungs-Briefing
day end       # veröffentliche die heutige Arbeit und markiere den KG, wenn sich das Korpus bewegt hat
day status    # wer hat kürzlich gepullt/gepusht, maschinenübergreifend; wer hält den KG-Stab
day baton     # übergib die Publisher-Rolle an eine andere Maschine (Reise, Urlaub, Übergabe)

Alles unten läuft auf macOS, Linux und WSL — einfaches bash, kein PowerShell. Kopie der Skripte: ejemplos/metodologia/s3-sync/ (beginne mit config.env.example — niemals eine echte config.env ausliefern).

Schritt 1 — finde den Synchronisationsordner und lies die Rolle dieser Maschine

Die Rolle entscheidet, was du tun darfst. Lies sie bevor du etwas in den Bucket schreibst.

S3=""
d="$PWD"
while [ "$d" != "/" ]; do
  if [ -f "$d/data/changes/s3-sync/data-pull.sh" ]; then S3="$d/data/changes/s3-sync"; break; fi
  d="$(dirname "$d")"
done
if [ -z "$S3" ]; then echo "Keine Shared-Record-Synchronisation in diesem Repo (öffne <dein-repo>-Root)."; fi
sed -n '1,20p' "$S3/IDENTITY.md"

Keine IDENTITY.md, oder sie sieht veraltet aus? Generiere sie neu — sie ist das, was der Agent liest, um seine Rolle zu erfahren, und eine veraltete Karte hat einmal ein AWS-Profil genannt, das gelöscht worden war:

(cd "$S3" && ./identity.sh --write)

Wenn S3 leer ist, teile dem Benutzer mit, dass dieses Repo kein gemeinsames Record hat, und STOPP.

Schritt 2 — day start

1. ⚠️ Prüfe ZUERST auf unveröffentlichte lokale Arbeit — ein pull kann sie überschreiben. aws s3 sync überträgt immer dann, wenn sich die Größe unterscheidet, nicht nur wenn das Remote neuer ist, also ersetzt ein Pull eine lokal bearbeitete Datei mit der älteren Kopie aus dem Bucket und erstellt alles, was du lokal umbenannt hast, unter seinem alten Namen neu. Kein --delete nötig.

   (cd "$S3" && ./data-push.sh --root changes)   # Trockenlauf — alles, was aufgelistet wird, ist lokale Arbeit
   

   --root changes begrenzt den Durchlauf auf die einzige Wurzel, die sich von Tag zu Tag bewegt (gemessen 212s → 123s: eine Verkleinerung, keine Größenordnung). Gut für diesen Check; verwende den vollständigen Durchlauf beim Veröffentlichen.

   Nichts aufgelistet → fortsetzen. Etwas aufgelistet → sag, was es ist, und biete an, es zuerst zu veröffentlichen; pull nicht darüber hinweg ohne die ausdrückliche Zustimmung des Benutzers.

2. Pull. Niemals --delete. Das Skript schützt dich jetzt, aber du MUSST lesen, was es sagt.

   (cd "$S3" && ./data-pull.sh --go)
   

   Bevor es etwas anwendet, führt es einen Trockenlauf durch, erstellt einen Schnappschuss jeder lokalen Datei, die der Pull ersetzen würde, in data/_prepull/<timestamp>/, und listet sie auf. Zwei Ergebnisse, auf die reagiert werden muss:

   • "⚠️ N vorhandene lokale Datei(en) werden ERSETZT" — lies diese Liste dem Benutzer laut vor. Gemeinsame Hub-Dateien (STATUS.md, FOLLOWUPS.md, SHARP_EDGES.md, TEST_MAP.md, _RESUME_*.md), die dort erscheinen, bedeuten, dass die Kopie eines Kollegen auf deiner landet, und jede Seite kann Inhalt enthalten, der der anderen fehlt — das braucht einen Merge, keinen Gewinner. Vergleiche den Schnappschuss mit der neuen Datei, bevor du etwas anderes tust: diff data/_prepull/<ts>/changes/STATUS.md data/changes/STATUS.md Um den gesamten Pull rückgängig zu machen: cp -a data/_prepull/<ts>/. data/
   • Exit-Code 3, "CASE-COLLIDING FILES" — zwei Bucket-Objekte unterscheiden sich nur in der Groß-/Kleinschreibung und werden auf einer Datei auf dieser Maschine abgebildet. Stopp. Der Pull würde zufällig einen Gewinner auswählen. Lösche zuerst den Schlüssel mit der falschen Schreibweise im Bucket; kanonische Schreibweise für Ticket-Dokumente ist Kleinbuchstaben sst-NNNN.md (Platzhaltermuster).

   Credential-Fehler? Logge dich neu ein, bevor du etwas abschließt — ein abgelaufener zwischengespeicherter Token sieht genauso aus wie ein Berechtigungsproblem: aws sso logout && aws sso login.

3. Sieh, wer sonst noch aktiv war: (cd "$S3" && ./activity.sh)

3b. Aktualisiere die Ticket-Status-Tabelle (Sekunden; ≤ 5 Zeilen — füge sie in das Briefing ein). Optional: nur wenn das Projekt eine Status-Tabelle führt, die aus dem Tracker + Git-Host generiert wird.

(cd "$(dirname "$S3")/tools" && uv run -q --with openpyxl python ticket_status/sync.py)

Publisher: schreibt die Status-Arbeitsmappe und die daraus erstellte .md-Datei neu, von Jira (Status, Typ, Links) und GitHub (PR, Merge-Datum, erste Veröffentlichung). Contributor: gleiche Zusammenfassung, schreibt nichts — eine binäre Arbeitsmappe mit zwei Schreibern ist "letzter Schreiber gewinnt". skipped — workbook is open → bitte den Benutzer, sie zu schließen und erneut auszuführen. CANARY FAILED → es wurde nichts geschrieben; lies das Ausführungsprotokoll, bevor du etwas anderes tust.

3c. Service-Fehler in den letzten 24 h (≈1 Min.; nur Anzahlen, lädt nichts herunter — füge die Gruppenzeilen in das Briefing ein):

T="$(dirname "$S3")/tools/evidence"
(cd "$T" && uv run -q --with boto3 python evidence.py discover --env dev --since 24h --list; \
            uv run -q --with boto3 python evidence.py discover --env stg --since 24h --list)

--list existiert, weil der erste Live-Durchlauf ~240 Problemdurchläufe in 24 h auf dev gefunden hat: ein herunterladendes Discover würde jeden Morgen seine eigene --max-runs-Grenze auslösen. Exit 2 → zuerst neu anmelden. Exit 6 → der Bucket hat aufgehört, alte Versionen zu behalten: teile es dem Benutzer mit. Um Beweise für eine Gruppe zu sammeln, verwende den evidence-Skill (fetch --doc <id> oder discover --since 2h ohne --list).

4. Orientiere dich — zuerst die Historie, dann den Status. Neueste data/changes/_RESUME_*.md (ältere Tage: _PENDING_*.md), dann data/changes/STATUS.md für deinen Bereich, dann git fetch --all --prune und git status -sb. Verwende den kg-Skill für den Stand der Technik, bevor du etwas entwirfst — niemals ein grep von data/changes/ als ersten Schritt.

5. Nur Publisher-Maschinen (IDENTITY.md sagt PUBLISHER): überprüfe den Stab und die Aktualisierungswarteschlange.

   (cd "$S3" && ./publisher.sh status)
   bash data/knowledge-graph/kg_refresh.sh queue
   (cd "$S3" && ./delete.sh --check)            # gelöschte Dateien, die zurückgekommen sind (nur Bericht)
   

   Berichte, was ansteht; starte keine Aktualisierung ungefragt — es sind ~100 Benennungsentscheidungen und eine volle Stunde, und ein halb benannter Graph passiert keine Kontrolle.

6. Gib dem Benutzer ein kurzes Briefing in wenigen Zeilen, dann stoppe. day start bereitet die Maschine vor; es wählt nicht die Arbeit aus.

Schritt 3 — day end

1. Schreibe den Tag auf, bevor du ihn veröffentlichst: das Ticket-Dokument unter data/changes/<ticket>/, eine STATUS.md-Zeile, etwaige Folgeaufgaben in FOLLOWUPS.md. Arbeit ohne schriftliche Aufzeichnung ist nicht von Arbeit zu unterscheiden, die nie stattgefunden hat.

2. Vorschau und lies die Dateiliste. Dies ist der Moment der Bereinigung — keine Schlüssel, keine Geheimnisse, nichts, was nicht in das gemeinsame Record gelangen sollte.

   (cd "$S3" && ./data-push.sh)
   

   ⚠️ Achte auf Fixture-Dateien (.docx/.pdf unter Fixture / Issue / Sample-Verzeichnissen). Ein Extractor-Lauf speichert Fixtures direkt an Ort und Stelle neu, und eine neu gespeicherte Fixture kann ihre exakte Byte-Größe behalten, während sich ihr Hash ändert. Überschreibe nicht die makellose Kopie des Buckets — stelle stattdessen deine aus dem Bucket wieder her.

3. Veröffentliche. Niemals --delete.

   (cd "$S3" && ./data-push.sh --go)
   

   Ein Contributor-Push, der meldet, dass er knowledge-graph/ übersprungen hat, ist korrekt, kein Fehler — nur refresh_queue/ geht von einer Contributor-Maschine hoch.

   ⛔ Wenn der Push mit Exit-Code 4 beendet wird — "ABGELEHNT: Shared Hub-Datei(en) im Bucket geändert" — hat ein Teammitglied eine dieser Dateien geschrieben, nachdem diese Maschine das letzte Mal synchronisiert hat, und unsere Kopie unterscheidet sich. aws s3 sync hat keinen Merge, also würde ein Push ihre Kopie ersetzen. Lies die benannten Dateien dem Benutzer vor, vergleiche jede mit der Bucket-Kopie und führe einen Merge durch. Übergib --allow-clobber NICHT auf eigene Initiative — es ist für "der Benutzer hat bestätigt, dass unsere ihre ersetzt", nichts Geringeres.

   (cd "$S3" && source ./config.env && \
     aws s3 cp "s3://$BUCKET/$PREFIX/changes/STATUS.md" - --profile "$PROFILE" | diff - ../STATUS.md)
   

   Gemessen am 2026-09-18: Ein Push vier Minuten, nachdem ein Kollege seinen Tag beendet hatte, zerstörte seinen gesamten STATUS.md-Abschnitt UND sein Aktivitätsprotokoll — und nichts auf dieser Maschine sah danach falsch aus, also blieb es einen ganzen Tag lang unbemerkt. Die Schutzmaßnahme greift nicht, wenn unsere Kopie byte-identisch mit der des Buckets ist, also ist eine Datei, die wir gerade gepullt haben, niemals eine Kollision.

4. Wenn sich Ticket-Dokumente geändert haben, markiere den Graphen, damit der Publisher weiß, dass ein Neuaufbau fällig ist:

   bash data/knowledge-graph/kg_refresh.sh request "<was sich geändert hat und warum es wichtig ist>"
   (cd "$S3" && ./data-push.sh --go)
   

5. Bestätige, dass es angekommen ist: (cd "$S3" && ./activity.sh) — der Push dieser Maschine sollte Minuten alt sein.

day status

(cd "$S3" && ./activity.sh)          # letzter Pull/Push pro Maschine
(cd "$S3" && ./activity.sh --log)    # vollständiger Ereignisstrom
(cd "$S3" && ./publisher.sh status)  # wer den KG neu erstellen und veröffentlichen darf

⚠️ Es meldet, was aufgezeichnet wurde. Eine Maschine, die noch nie die instrumentierten Skripte ausgeführt hat, zeigt nichts; das Fehlen einer Aufzeichnung ist kein Beweis für fehlende Aktivität.

day baton — Übergeben der Publisher-Rolle

Eine Maschine veröffentlicht den Knowledge Graph, weil aws s3 sync "letzter Schreiber gewinnt" ist ohne Merge: zwei Publisher zerstören sich gegenseitig die manuell erstellten Community-Namen. Der Stab ist eine ratschlagende Sperre, die im Bucket aufbewahrt wird, sodass jede Maschine sie überprüfen kann.

(cd "$S3" && ./publisher.sh status)
(cd "$S3" && ./publisher.sh release)            # abgebende Maschine, ZUERST
(cd "$S3" && ./publisher.sh claim "why")        # empfangende Maschine, ZWEITENS

Die empfangende Maschine muss außerdem MACHINE_ROLE="publisher" in config.env setzen und ./identity.sh --write erneut ausführen, sonst liest ihr Agent weiterhin CONTRIBUTOR und lehnt die Arbeit ab, die sie jetzt besitzt. claim --force überschreibt einen gehaltenen Stab — bestätige jedes Mal mit dem Benutzer.

Regeln, die in jedem Branch gelten

• Niemals --delete. Nur Publisher, bewusst und nur direkt nach einem frischen Pull.
• Löschen aus dem gemeinsamen Speicher erfolgt mit ./delete.sh (Publisher), niemals aws s3 rm oder --delete — sonst laden die anderen Maschinen es bei ihrem nächsten Push wieder hoch.
• Niemals knowledge-graph/ von einem Contributor pushen. Das Tool erzwingt es; umgehe es nicht.
• Logge dich neu ein, bevor du einen Zugriffsfehler diagnostizierst — der Fehler beschreibt deinen zwischengespeicherten Token.
• Der Mensch besitzt nach außen gerichtete Aktionen. Dieser Skill synchronisiert das gemeinsame Record; er pusht keine Branches, eröffnet keine PRs, deployed nichts und sendet niemandem eine Nachricht.