zehuichan/vibe-harness

Agent Notes

Agent Notes halten das Entscheidungs-Repository klein und maßgeblich: Jede Note erfasst rationale Gründe, die Code und Dokumentation nicht tragen können, und nichts anderes. Die Regeln für Layout, Klassen und das Dateiformat befinden sich in .agents/notes/README.md; dieses Skill besitzt den Workflow. Beurteilen Sie jede Note semantisch; Wortzahl und Alter sind Hilfsmittel zur Entdeckung, niemals Kriterien. Dies ist eine Anleitung, keine Checkliste.

Entscheiden, ob eine Note benötigt wird

Schreiben oder aktualisieren Sie eine Note nur für dauerhafte Entscheidungsrationale: warum ein Design gewonnen hat, was es aufgegeben hat, welche Alternativen verloren haben und warum, und welche Verifikation es verankert. Schreiben Sie keine für mechanische oder lokale Änderungen, einschließlich lokaler UI-Präsentationsänderungen, oder für Fakten, die in Code, API-Dokumentation, READMEs oder ein Kochbuch gehören.

• Ein Vorschlag für umfangreiche zukünftige Arbeit geht nach proposed/<class>/; eine im aktuellen Änderungsvorgang getroffene Entscheidung geht nach implemented/<class>/.
• Wenn eine aktive Note die Entscheidung bereits abdeckt, aktualisieren Sie sie anstatt ein Duplikat zu erstellen.
• Eine Umkehrung einer Entscheidung ist eine neue Note, die die alte Querverweise enthält; bearbeiten Sie niemals eine Note zu einer anderen Entscheidung.

Schreiben Sie die Note

1. Wählen Sie die Klasse aus der Tabelle in .agents/notes/README.md und benennen Sie die Datei yyyy-mm-dd-thema-titel.md, wobei Sie das Datum verwenden, an dem das Thema zuerst vorgeschlagen wurde.
2. Verwenden Sie die exakte Kopfzeile und das Abschnittsgerüst des Lebenszyklus aus dem README. ## Berücksichtigte Alternativen ist obligatorisch: Erfassen Sie jede echte Alternative und warum sie verloren hat; erfinden Sie niemals Alternativen.
3. Schreiben Sie implementierte Noten im Präsens als ausgelieferte Realität: keine Pläne, Akzeptanzchecklisten oder „sollte“. Halten Sie die Verifikation fest, die das Verhalten verankert, sowie alle genannten Abdeckungslücken.
4. Verlinken Sie andere Noten und Dokumente mit relativen Markdown-Links. Folgen Sie prose-standard und trim-cot-leakage: keine Überprüfungs-Choreographie, Sitzungszitate oder Änderungserzählungen außerhalb der eigenen Änderungsgeschichte-Abschnitte der Note.

Überprüfung auf Supersession für jede neue Note

Vor dem Entwurf durchsuchen Sie den aktiven Baum (proposed/, implemented/, rejected/) nach Notizen, die dieselbe Entscheidung, denselben Mechanismus oder dieselbe abgelehnte Alternative abdecken. Klassifizieren Sie jede Übereinstimmung während des Schreibens der neuen Note:

• Vollständige Supersession einer implementierten Note: Konsolidieren Sie (der neue Eigentümer bewahrt jede einzigartige Rationale, Alternative, Konsequenz, Verifikation und Abdeckungslücke, dann wird die alte Note gelöscht und eingehende Links werden repariert) oder archivieren Sie sie im selben Änderungsvorgang.
• Partielle Supersession: Behalten Sie beide aktiv, verlinken Sie sie kreuzweise und aktualisieren Sie jeden Fakt, der aktuell bleibt.
• Veralteter Vorschlag: Verschieben Sie ihn mit einem ehrlichen einzeiligen Grund nach rejected/.
• Veraltete Ablehnung: Löschen Sie sie, wenn sie keinen plausiblen Fehler mehr verhindert.

Schieben Sie eine bekannte Übereinstimmung nicht auf eine spätere Prüfung auf.

Klassifizieren vorhandener Notizen nach zukünftigem Wert

Wenden Sie bei der Prüfung oder Bereinigung diese Ergebnisse pro Lebenszyklus an:

• Implementiert, löschen: Notizen, die nur kleine UI-Anpassungen oder rein mechanische Änderungen beschreiben. Reparieren oder entfernen Sie eingehende Links. Lokale Fehlerbehebungen, Leistungsänderungen, neue Funktionen und substanzielle Verhaltens- oder Eigentumsentscheidungen qualifizieren nicht allein deshalb, weil ihre Implementierung klein war. Wenden Sie diesen Test vor Behalten oder Archivieren an.
• Implementiert, aktiv behalten: Rationale, Alternativen, negative Garantien, dauerhafte oder Drahtsemantik, Eigentumsgrenzen, Sicherheitsregeln oder Bedingungen für die Wiedereinführung, die wahrscheinlich eine zukünftige Änderung leiten werden. Klassifizieren Sie die Entscheidung, nicht die Größe ihrer Implementierung: Eine mechanische Umbenennung kann dennoch eine dauerhafte Namens- oder Kompatibilitätsregel aufzeichnen.
• Implementiert, archivieren: Eine substanzielle historische Entscheidung, die abgeschlossen ist und wahrscheinlich keine zukünftige Arbeit leiten wird, deren Rationale aber dennoch eine Aufbewahrung rechtfertigt.
• Vorgeschlagen, niemals archivieren: Behalten Sie einen Live-Vorschlag aktiv bei; wenn er nicht mehr verfolgenswert ist, lehnen Sie ihn mit einem ehrlichen Grund ab.
• Abgelehnt, nur als Schutzmaßnahme behalten: Behalten Sie eine Ablehnung nur so lange, wie der verlierende Vorschlag ein verlockender, sinnvoller Fehler bleibt und die Note erklärt, warum er verliert; andernfalls löschen Sie sie.

Archivieren Sie nicht auf ein Kontingent hin. Untersuchen Sie jede relevante Note, klassifizieren Sie analoge Gruppen unter einem Prinzip und erfassen Sie echte Grenzfälle für den Bericht.

Kalibrierung: Eine Note über das Styling eines eingeklappten Seitenleisten-Steuerelements wird gelöscht, egal wie lang sie ist; eine Note, die festlegt, dass Sitzungen ereignisgesteuert sind, oder die den alleinigen Eigentümer eines Speicherverzeichnisses benennt, bleibt aktiv, egal wie kurz sie ist; eine Note, die festhält, warum zwei Pakete nicht zusammengeführt werden dürfen, bleibt als Schutzmaßnahme bestehen, solange die Zusammenführung verlockend bleibt.

Archivieren Sie eine implementierte Note

1. Verschieben Sie die vollständige Note, zusammen mit allen übersetzten Gegenstücken, von implemented/<class>/ nach archived/<class>/.
2. Nehmen Sie keine Änderungen am Inhalt vor. Fügen Sie nur Archiviert: JJJJ-MM-TT unmittelbar unterhalb von Status: implementiert in jeder Sprachdatei ein, mit demselben Datum.
3. Durchsuchen Sie aktive Prosa nach eingehenden Links. Leiten Sie sie zur aktuellen Autorität um, richten Sie sie nur dann auf den archivierten Pfad um, wenn der historische Schnappschuss absichtlich zitiert wird, oder löschen Sie sie. Überprüfen oder reparieren Sie niemals Links aus der archivierten Note heraus.

Nach der Archivierung darf die Note niemals bearbeitet, verschoben, übersetzt, neu formatiert oder gelöscht werden. Archivierte Notizen bleiben gültige Link-Ziele, sind aber keine Autorität für das aktuelle Verhalten.

Validieren und berichten

Führen Sie commands.docs-check und git diff --check des Profils aus und bestätigen Sie, dass sich jeder geänderte relative Link auflöst. Berichten Sie erstellte oder aktualisierte Notizen, aktiv behaltene, gelöschte, archivierte oder abgelehnte Notizen sowie jeden Grenzfall mit dem gewählten Ergebnis.