Was macht Project Steward?

Rolle und Routing

Project Steward speichert projektübergreifend wiederverwendbare Governance-Methoden. Die eigenen Produktentscheidungen, Architekturfakten und langfristigen Constraints eines Projekts verbleiben in den bestehenden Quellen des Projekts; variable Tool-Fakten für Benutzer und Maschinen verbleiben in Umgebungsarchiven außerhalb des Projekts und des Skills.

Wähle zuerst den Hauptpfad basierend auf dem vom Benutzer gewünschten Ergebnis; unabhängige Ergebnisse in derselben Anfrage werden in separaten Buchungen erfasst:

Dialog, Korrektur, vollständiger Implementierungsprozess oder Funktionsgrenze des Ziel-Skills: Dialoglernen und Selbstentwicklung.
Vermeidung von Nacharbeit vor Funktionsänderungen, Refactoring, Migration oder änderungsübergreifenden Anpassungen: Änderungsprävention.
Fehler, teilweise Migration, wiederholte Reparaturen, Ausfälle in der echten Kette oder Prüfung auf Kohäsion, Kopplung, Redundanz, God-Module: Ursachenbehebung.
Prüfung, Integration oder Behebung der Kompatibilität von Projekten mit externen CLIs, Ausführungswerkzeugen oder Protokollen: Externe Tool-Kompatibilität.
Verstehen des Zwecks, der Architektur und der Fähigkeiten eines Repositorys, Verzeichnisses oder Quellcodepakets, oder Recherche zu Referenzprojekten: Projektforschung und -erklärung.
Inventarisierung oder Organisation des Projektverzeichnisses mit Bewertung von tatsächlicher Nutzung, Generierungsstatus, Ignorieren, Verschieben, Archivierung und Löschung: Projektverzeichnis-Governance.
Einrichtung, Übernahme, Aktualisierung oder Prüfung von Projektvorlagen: Projektbaseline und -vorlagen.
Schreiben stabiler Standardwerte in Vorlagen: Vorlagenentwicklung.
Definition, Überprüfung, Neuerstellung oder Implementierung von Produkterfahrung und Schnittstelle: Produkterfahrung und Schnittstellen-Governance.
Prüfung, Umschreibung von README oder Erstellung von GitHub-Startseiten-Visuals: README und Startseite.
Governance von Projekt-Logs, LLM-Aufzeichnungen, Langzeitspeicher, TTS oder Log-Viewer-Ergebnissen: Humanisierte Logs.
Initialisierung von Git, Repository-Erstellung, Commit, Push, Sichtbarkeitsänderung oder Remote-Verifikation: Repository-Erstellung und -Veröffentlichung.
Auswahl, Anwendung oder Batch-Governance von Lizenzen und Drittanbieter-Lizenzen: Lizenz-Governance.
Erstellung oder Nutzung von Benutzerumgebungsprofilen, Prüfung von Tools, Caches, SDKs, Terminals oder langlaufenden Aufgaben: Benutzerumgebungsprofil und Ausführungsumgebung.
Schrittweise Überprüfung des Implementierungsplans auf Vollständigkeit, umfassende Prüfung, Bewertung des Projektzustands und Auflistung von Projektrisiken auf Projektebene: Projektumfassende Prüfung.

Wenn nur dieser Skill genannt wird, wird der am besten passende Pfad basierend auf dem vorhandenen Material ausgewählt; bei unzureichendem Material wird ein direktes Anfragebeispiel nahe am Kontext gegeben und gestoppt.

Nach Auswahl des Hauptpfads wird vor jedem Projekt-Schreibvorgang oder jeder speziellen Implementierung ein Routing-Buch geführt: Endergebnis des Benutzers, Hauptpfad, feste Pflichtlesemethoden, bedingte Spezialthemen mit Auslösernachweisen, Aktionsschwellen, formale Konsumenten, Abnahme und Stopppositionen. Feste Pflichtlesemethoden dürfen nicht übersprungen werden, nur weil eine lokale Änderung offensichtlich erscheint. Bedingte Spezialthemen werden nur hinzugefügt, wenn relevante Nachweise vorliegen. Wenn später zur selben Anfrage weitere Abnahme-Elemente hinzugefügt werden, wird das ursprüngliche Buch aktualisiert; die noch gültige Reichweite wird nicht durch die neuesten Symptome ersetzt.

Gemeinsame Grenzen

Normale Geschäftsfunktionen bleiben in der Verantwortung der aktuellen Entwicklungsaufgabe; wenn der Benutzer nur eine einzelne Fehlermeldung, eine Funktion oder ein lokales Verhalten erklärt haben möchte, wird nach der Beantwortung angehalten und nicht auf ein Umbau auf Projektebene hochgestuft. Nur wenn die Anfrage selbst Prävention, Governance, Migration, Selbstentwicklung oder projektebene Ergebnisse erfordert, wird der entsprechende Pfad betreten.
Nach der Pfadauswahl werden Reichweite, Schreibrechte und Stoppposition sofort eingefroren. Prüfungen, Audits, Diagnosen, Bewertungen, Analysen, Nachbesprechungen oder Berichte sind standardmäßig schreibgeschützt; nur wenn dieselbe Anfrage explizit Reparatur, Governance, Implementierung, Änderung, Update oder Selbstentwicklung verlangt, werden entsprechende Schreibrechte gewährt.
Wenn der Benutzer ein Quellcode-Archiv bereitstellt und darum bittet, das Projekt zu verstehen, zu prüfen oder zu erforschen, oder nur diesen Skill nennt und ein Quellcode-Archiv beifügt, ist das Entpacken eine notwendige Materialvorbereitung für die schreibgeschützte Forschung und kein formales Projekt-Schreiben. Direkt nach "Projektforschung und -erklärung" vorgehen, das Zielverzeichnis bestimmen, mit einem bestehenden Skript in ein separates, namenskonfliktfreies Verzeichnis entpacken, den vom Skript zurückgegebenen Projektstamm lesen und mit der schreibgeschützten Forschung fortfahren; keine zusätzliche Bestätigung zum Entpacken erforderlich. Diese Aktion autorisiert nur das Erstellen einer Forschungskopie und das Lesen ihres Inhalts; das Ausführen des Projekts, das Installieren von Abhängigkeiten oder Entpackwerkzeugen, das Ändern von Dateien, das Verschieben oder Löschen von Originaldateien, Commits und Veröffentlichung benötigen weiterhin separate Autorisierung.
Vernetzung, Download, Installation, Ausführung, Generierung, Schreiben, Verschieben, Archivierung, Löschung, Commit, Push und Veröffentlichung werden jeweils separat autorisiert; nur die im Folgenden explizit aufgeführten Standard-Abschlussverträge können Schreiben, Commit, Push und Remote-Abnahme im selben Benutzerergebnis zusammenfassen. Ausführen oder Generieren bedeutet nicht, dass Schreibrechte für das Projekt erworben wurden; außerhalb der Standard-Abschlussverträge autorisieren Commit, Push oder Veröffentlichung nur die Verarbeitung bereits vorhandener und genau geprüfter Änderungen, nicht nachträgliche Autorisierung vorheriger Schreibvorgänge oder nicht zusammenhängender Arbeitsbaumänderungen.
Wenn der Benutzer in der Anfrage explizit Project Steward nennt (einschließlich Aufruf von $project-steward) und ausdrücklich verlangt, ein bestehendes Git-Projekt zu ändern, zu reparieren, zu verwalten, zu aktualisieren oder zu optimieren, und der aktuelle Branch einen konfigurierten Upstream hat und der Benutzer keine Einschränkungen wie "nur lokal ändern", "nicht committen", "nicht pushen" oder eine frühere Stoppposition angegeben hat, wird diese Runde standardmäßig bis zum Abschluss durchgeführt: Verifikation des autorisierten Abhängigkeits-Closures, präziser Commit, nicht-erzwungener Push des aktuell getrackten Branches, dann Abgleich von Remote-HEAD und Schlüsselkonsumenten; nach lokaler Verifikation wird nicht ein zweites Mal gefragt, ob gepusht werden soll. Schreibgeschützte Anfragen, implizites Routing, kein Upstream, Remote-Erstellung, Sichtbarkeitsänderung, Löschung, Force-Push, Umschreiben der Historie, Verpackung, Bereitstellung und nicht zusammenhängende Arbeitsbaumänderungen werden nicht durch diese Standardautorisierung abgedeckt; wenn eine der Bedingungen in references/repository-publication.md zutrifft (Fork, Änderungen unbekannter Herkunft, nicht autorisierte Löschung, Anmeldeinformationen, Verifikation oder Authentifizierungsfehler), wird angehalten.
Wenn der Benutzer einen Selbstentwicklungsvorschlag von Project Steward bestätigt und keine Einschränkung auf lokale Änderungen angegeben hat und der aktuell getrackte Remote existiert, wird standardmäßig der gesamte aktuelle Arbeitsbereich als unteilbarer Veröffentlichungsbereich betrachtet: Alle getrackten Änderungen, nicht getrackten Dateien und bestehenden Löschungen werden verifiziert, mit git add -A gemeinsam committet und in den aktuell getrackten Branch gepusht; wenn auch nur ein Element nicht gemeinsam veröffentlicht werden kann, wird der vollständige Arbeitsbereich erhalten und angehalten. Diese Standardeinstellung autorisiert keine Remote-Erstellung, Force-Push, Sichtbarkeitsänderung oder Durchführung neuer Löschungen.
Wenn der Benutzer ausdrücklich verlangt, für ein bestehendes GitHub-Repository Star History zu integrieren, zu ersetzen oder zu reparieren, enthält der Bestätigungsvertrag standardmäßig den in dieser Runde autorisierten Abhängigkeits-Closure-Commit, -Push und -Remote-Abnahme; es sei denn, der Benutzer verlangt explizit nur lokale Änderungen, sonst wird nach dem Schreibvorgang und der Verifikation nicht auf eine zweite Veröffentlichungsautorisierung gewartet. Diese Standardeinstellung umfasst keine Remote-Erstellung, Force-Push, Sichtbarkeitsänderung, Löschung oder nicht zusammenhängende Arbeitsbaumänderungen.
Zu Beginn jeder Benutzerrunde, internen Iteration, automatischen Wiederholung und Kontextkomprimierung wird vor jedem Tool-Aufruf oder Zustandswechsel der noch nicht abgeschlossene Benutzeranfrage, die Reichweite, die Berechtigungen und die Stoppposition aus der letzten expliziten Benutzeraktion wiederhergestellt. Nur wenn dasselbe Ergebnis noch nicht geliefert wurde und sich Reichweite, betroffene Kette und Berechtigungen nicht geändert haben, wird fortgefahren; wenn ein schreibgeschütztes Ergebnis bereits geliefert wurde, keine neue explizite Aktion vorliegt, der Benutzer das Ergebnis ändert, eine nicht zusammenhängende Frage auftaucht oder neue Berechtigungen erforderlich sind, wird angehalten und auf Bestätigung gewartet. Audit-Funde, Assistentenvorschläge, interne Pläne, Zielnamen, Aufgabenlisten und automatische Hinweise können keine neuen Ergebnisse oder Schreibberechtigungen erzeugen.
Wenn sich die Arbeit von einer kurzen Aktion zu einem mehrstufigen Prozess ausweitet, in einen Wartezustand eintritt oder sich der Nachweisstatus ändert, wird der Grund für die Ausweitung, die abgeschlossenen Kontrollpunkte, der aktuelle Status, das nächste beobachtbare Ergebnis und die erforderliche Eingabe aktiv erklärt; wenn sich der Status nicht ändert, wird nicht wiederholt der Bildschirm geflutet, noch dürfen Prozesserklärungen eine Reichweitenerweiterung verschleiern.
Wenn eine neue unabhängige Anfrage ein noch nicht abgeschlossenes Ergebnis ersetzt, werden zuerst die bereits geschriebenen oder geänderten Objekte, vorhandenen Nachweise, noch nicht validierten Benutzerzusicherungen, laufenden Prozesse, Residuen, ursprünglichen Berechtigungen und Stopppositionen übergeben; die neue Anfrage autorisiert nicht die Fortsetzung, Rücknahme oder Bereinigung des alten Ergebnisses.
Zuerst werden der genaue Projektstamm, der Materialumfang, die aktiven Dateien und die echten Konsumenten eingefroren. Git wird nur verwendet, wenn im genauen Projektstamm direkt ein .git existiert und der aktuelle Pfad tatsächlich Historie, Arbeitsbaum oder Veröffentlichungsnachweise benötigt.
Quellen müssen bis zum Ende klar gelesen werden; lange Dateien werden zuerst auf Zeilenanzahl, Byteanzahl oder Seitenfähigkeit geprüft, dann in stabilen Intervallen vollständig gelesen. Wenn gleichzeitige Änderungen den Verhaltensvertrag, betroffene Dateien, Konsumenten, Verifikation oder das Benutzerergebnis berühren, verlieren alte Bestätigungen ihre Gültigkeit, und es wird neu geplant und bestätigt.
Mehrere voneinander unabhängige Sondierungen werden nur parallelisiert, wenn der Orchestrator Ausgabe, Fehler und Exit-Status für jede einzelne beibehalten kann; wenn eine einzige dazu führt, dass der gesamte Batch vorzeitig abgebrochen wird, werden sie einzeln ausgeführt. Nach einem Batch-Fehler werden die noch frischen Erfolgsnachweise beibehalten; nur die Elemente, die überschattet, nicht ausgeführt oder deren Status unbekannt ist, werden einzeln nachgeholt.
Projektfakten werden zurück in die einzige aktive Quelle des Projekts geschrieben; Umgebungsfakten werden in separate Benutzerprofile geschrieben; nur übertragbare Governance-Methoden gelangen in diesen Skill; Vorlagen akzeptieren nur stabile Standardwerte, die bei jeder Iteration eines bestimmten Projekttyps ausgeführt werden sollen.
Bei der Beurteilung, ob eine Fähigkeit aus der Historie oder externem Material bereits existiert, wird zuerst eine unabhängige Aufteilung des Ergebnisses und eine notwendige kausale Sortierung durchgeführt, dann die Quelle verdeckt und überprüft, ob das Ziel dieselbe Bedingung erkennen, dieselben konstitutiven Details beibehalten und dieselbe spezifische Verarbeitung durchführen kann; nur übergeordnete Governance-Frameworks gelten als teilweise vorhanden. Erst nach vollständigem Vergleich werden gemeinsame Mechanismen und spezielle Dimensionen destilliert.
Die Verifikation wird basierend auf dem Änderungsrisiko in Stufen gewählt: Zuerst werden gezielte Prüfungen ausgeführt, die direkt die vorgenommene Änderung und die Abnahmeaussagen abdecken; bei Änderungen nur an Dokumentation, Lizenz, Danksagungen oder reinen Metadaten wird nach erfolgreichem Bestehen des entsprechenden Wartungseintritts angehalten, ohne irrelevante Browser oder End-to-End-Ketten zu starten; erst wenn öffentliche Verträge, Kernlaufzeit, grenzüberschreitende Repositorys, Veröffentlichung oder die Zielprüfung systemische Auswirkungen offenbaren, wird auf vollständige Regression und echte Benutzerketten hochgestuft.
Nach einer Zustandsänderung wird direkt die autoritative Quelle zurückgelesen. Die Verifikation muss entlang der formalen Produzenten, Übertragungs- oder Speichergrenzen, Konsumenten und für den Benutzer beobachtbaren Ergebnisse erfolgen; es dürfen keine manuell eingegebenen Testdaten oder Mock-ups der zu verifizierenden Kernkette auf der Konsumentenseite verwendet werden.
Bevor Testergebnisse zur Erfüllung einer Zusage oder zur Deklaration des Abschlusses verwendet werden, müssen die Identitäten der erwarteten Schlüsseltests mit den tatsächlich vom Test-Framework gesammelten eindeutigen Identitäten übereinstimmen; fehlende oder nicht eindeutige Identitäten werden nur als nicht abgedeckt markiert.
Beim Lesen von Einstellungen, Ausführungsberichten, strukturierten Artefakten oder Logs wird zuerst gemäß references/log-audit-standard.md die für die aktuelle Beurteilung erforderlichen zulässigen Felder projiziert; unbekannte Strukturen dürfen nicht vollständig rekursiv ausgegeben werden, und Anmeldeinformationen müssen vor dem Eintritt in die Tool-Ausgabe, den Dialog oder den Diagnoseexport desensibilisiert werden.

Dialoglernen und Selbstentwicklung

Zuerst references/conversation-learning-and-self-evolution.md vollständig lesen.

Wenn ein Benutzerergebnis Fehler, Korrektur, Schutzunterbrechung, temporäre Umgehung oder Residuen enthält, dann auch references/root-cause-remediation.md lesen. Die Lesereihenfolge ist festgelegt: Nach Wiederherstellung des vollständigen Prozesses entlang des Ergebnisses; entlang der kausalen Hierarchie die wichtigsten Lerninhalte und unabhängigen Nebenergebnisse bestimmen; dann die Details wiederherstellen, die zukünftige Governance ändern würden, und die Fähigkeiten gemäß den gemeinsamen Grenzen Element für Element vergleichen; erst danach gemeinsame Mechanismen und spezielle Dimensionen destillieren, Übertragbarkeit, Funktionsgrenzen und formale Eigentümer beurteilen; schließlich historische Verantwortung beurteilen. Umgehungen und Residuen dürfen keine früheren, nachweislich gültigen kontrollierbaren Ursachen überdecken; wenn eine spätere Korrektur die Hauptursache ändert, verlieren bestehende Pläne und Bestätigungen sofort ihre Gültigkeit. Nur bei erfolgreichen Ergebnissen ohne diese Signale wird die Ursachenmethode nicht geladen.

Beim Fähigkeitsvergleich muss zuerst zwischen "fehlender Methode" und "vorhandener Methode, die nicht geroutet, ausgeführt oder abgenommen wird" unterschieden werden. Ersteres stärkt nur den alleinigen Methodeninhaber an Ort und Stelle; letzteres repariert nur den frühesten fehlgeschlagenen Haupt-Route, Aktionsschwellen, formale Konsumenten oder Verifikation und fügt keine synonymen Regeln in anderen Dateien hinzu. Pläne werden nach Besitzern und Verbrauchsketten organisiert, nicht nach Auftreten im Dialog als gestapelte Patches.

Wenn der Benutzer nur eine Analyse anfordert, bleibt dieser schreibgeschützt. Wenn explizit Absorption, Selbstentwicklung, Update, Optimierung oder Iteration von Project Steward angefordert wird, wird zuerst das zukünftige Verhalten, die Funktionsgrenzen, repräsentative Ausgaben, betroffene Dateien und die Verifikationsmethode geliefert und gestoppt; erst nach Bestätigung des Plans durch den Benutzer wird der aktive Skill geändert. Wenn der bestätigte Plan keine Einschränkung auf lokale Änderungen angibt, wird gleichzeitig references/repository-publication.md gelesen; wenn der aktuell getrackte Remote existiert, wird der gesamte Arbeitsbereich auf tatsächliche Auswirkungen verifiziert, mit git add -A werden getrackte Änderungen, nicht getrackte Dateien und bestehende Löschungen gemeinsam committet und in den aktuell getrackten Branch gepusht, und es wird sichergestellt, dass Remote-HEAD und Arbeitsbereich nichts auslassen. Wenn Remote, Authentifizierung, Branch-Schutz, Fork, Verifikationsfehler auftreten oder ein Element nicht gemeinsam veröffentlicht werden kann, wird der vollständige Arbeitsbereich erhalten und an der genauen Grenze angehalten, ohne selektiven Commit.

Bei der Selbstentwicklung von Project Steward müssen die Hauptdatei-Constraints eingehalten werden:

Vor dem Schreiben werden Zeilenanzahl, Zeichenanzahl und die direkten Referenzen der SKILL.md aufgezeichnet, und jeder neuen Regel wird ein eindeutiger aktiver Besitzer zugewiesen.
SKILL.md besitzt nur Routing, Auslösebedingungen, Lesereihenfolge, Berechtigungen, Ausgaben und Stopppositionen; vollständige Methoden, Tabellen, Checklisten und Ausnahmen werden ausschließlich von der entsprechenden Referenzdatei besessen, und die Hauptdatei enthält nur direkte Links.
Nach dem Schreiben darf SKILL.md nicht mehr als 220 Zeilen oder 14.000 Zeichen haben und muss dennoch den gesamten aktiven Funktionsumfang direkt erreichbar halten. Wenn ein neues Routing das Budget überschreitet, müssen alte Details im selben Änderungsvorgang migriert oder zusammengeführt werden.
Wenn bestehende Fähigkeiten, formale Konsumenten und Verifikationen nicht innerhalb des Budgets gehalten werden können, wird das Schreiben gestoppt, neu geplant und nicht als abgeschlossen deklariert.

Änderungsprävention

Zuerst references/change-prevention.md lesen; diese ist verantwortlich für Zielverhalten, einzige aktive Quelle, Einflussdiagramm, finale Schnittstelle, Austrittspfad für alte Implementierungen und Abnahme durch echte Benutzerketten. Je nach Problem werden weitere Referenzen hinzugezogen:

Begrenzte Batches und Backlog-Drain, Wiederherstellung, Neustart, gruppierte Artefakte für dauerhafte Operationen, Warteschlangen oder Scheduler, oder gleichzeitige Aufnahme, Freigabe und Schließung von Sessions und gemeinsam genutzten Ressourcen in zustandsbehafteten Diensten: references/durable-operation-governance.md
Aufgabenstatus, Fortschritt oder automatische Wiederholung: references/task-progress-governance.md
Hochkosten-Ergebnisse, die stufenweise Präsentation, Bestätigung, kontinuierliche automatische Ausführung oder Invalidierung bei Änderungen der Vorgänger erfordern: references/staged-result-governance.md
Wenn dasselbe Ergebnis durch mehrere Spezifikationen, Pläne, Aufgaben oder Forschungsergebnisse ausgedrückt wird und eine Entscheidung über die Evolutionsbeziehung getroffen werden muss, oder wenn abgeleitete Artefakte, semantische Caches, Aufteilung der Arbeitseinheiten, Ressourcenpool-Nutzung oder wiederholte Agent-Orchestrierung im Spiel sind: references/derived-artifact-governance.md
Projekt-CI: Validierungsplan, Ausführungsumgebungs-Cache, Testressourcen-Schichtung, zeitaufwändige Sharding, frühes Fehlschlagen und präzises Wiederholen: references/ci-execution-governance.md
Laufzeitkonfiguration, die gemeinsam genutzte Dienste, Provider, Speicherwurzeln oder Kombinationsgraphen neu erstellt: references/runtime-generation-governance.md
Schwer reproduzierbare, zeitliche, nebenläufige, Backpressure- oder teure vollständige Ketten: references/hard-to-reproduce-diagnostics.md
Externes, persistiertes, modelliertes, Netzwerk- oder Prozess-JSON mit mehrfachem Parsing, Kapazitäts-, atomaren Sharding-, Wiedergabe-Cursor- oder Vertragsambiguitäten: references/structured-data-boundary.md
Modellbeteiligung an Aufgabenbeurteilung, Zustandsausdruck, Laufzeitereignissen oder strukturierten Antworten, die einen Abgleich von Nachrichtenquellen, Rollen, Routing, Zeilenanfragen und Präsentationsverantwortlichkeiten erfordern: references/model-mediated-operation-governance.md
Verwendung von externem Quellcode als einmaligen Startpunkt für ein eigenständiges Produkt oder selektive Übernahme seines erweiterten Ökosystems: references/source-fork-and-ecosystem-adoption.md; bei tatsächlichem Kopieren von Code gleichzeitig references/license-governance.md lesen
Produkterfahrung und Schnittstelle: references/product-experience-governance.md; wenn Design- oder Interaktionsmethoden benötigt werden, zusätzlich references/ux-design.md lesen

Änderungen am Projekt werden nur mit expliziter Autorisierung des Benutzers vorgenommen; wenn nur ein Plan angefordert wird, wird beim Einflussdiagramm, Zielgrenzen, Migrationsreihenfolge und Abnahmevertrag gestoppt.

Ursachenbehebung

Zuerst references/root-cause-remediation.md lesen. Die Diagnose stoppt bei Beweisen, Auswirkungsbereich und endgültiger Reparaturmethode; erst bei der Implementierung werden alle Produzenten, Grenzen und Konsumenten in einem Schritt migriert und die alte Architektur verlassen. Je nach Problem werden weitere Referenzen hinzugezogen:

Die Reparatur übernimmt ein vorheriges umfassendes Audit dieser Aufgabe, oder wenn der Benutzer explizit die Reparatur aller Probleme dieses Audits verlangt, wird das vom vorherigen Audit übergebene Buch als Abschlussvertrag fortgesetzt; vor dem Schreiben wird fix references/change-prevention.md gelesen, nach der letzten relevanten Änderung wird zu references/project-audit.md zurückgekehrt, und basierend auf der ursprünglichen Abdeckung und dem aktuell akzeptierten Vertrag wird ein neues Abdeckungs- und Fundbuch erstellt. Ein einzelner Fehler weitet sich nicht allein aufgrund der Existenz eines nicht zusammenhängenden Audits in der Historie auf diese Kette aus.

Begrenzte Batches und Backlog-Drain, Wiederherstellung von dauerhaften Operationen, Warteschlangen oder Schedulern, oder Session-Aufnahme und Freigabe-Wettbewerb in zustandsbehafteten Diensten: references/durable-operation-governance.md
Aufgabenfortschritt oder Dauerzustand: references/task-progress-governance.md
Nacharbeit aufgrund fehlender stufenweiser Bestätigung, Drift des Bestätigungsobjekts oder fehlerhafter Diffusion von Änderungen: references/staged-result-governance.md
Nacharbeit aufgrund unklarer Beziehungen zwischen mehreren Artefakten, verlorenen Gründen bei der Neugenerierung, vollständiger Neuberechnung, fehlerhafter Cache-Invalidierung, gefährlicher Aufteilung, Ressourcenfehleinschätzung oder Orchestrierungs-Roundtrips: references/derived-artifact-governance.md
Wiederholte langsame Tests, verschwendete Umgebungsvorbereitung, unausgeglichenes Sharding, zu späte plattformübergreifende Vorprüfungen oder unterschiedsloses Wiederholen nach Fehlschlag in der Projekt-CI: references/ci-execution-governance.md
Laufzeitoperationen, die Dienstgenerationen, Hot-Konfigurationstransaktionen oder physische Wurzelwechsel überspannen: references/runtime-generation-governance.md
Schwer reproduzierbare oder schwer beobachtbare Probleme: references/hard-to-reproduce-diagnostics.md
Strukturiertes JSON: Kodierung, Ressourcenbudget, logische Nachrichtenkapazität, atomares Sharding, Wiedergabe-Cursor, Zahlen, Schema oder Fehlersemantik-Abweichungen: references/structured-data-boundary.md
Inkonsistenz zwischen Modellantworten, Aufgabenstatus oder Ergebnisdarstellung und der tatsächlichen Laufzeit, oder die Notwendigkeit, die tatsächlich an das Modell gesendete Anfrage zu lokalisieren: references/model-mediated-operation-governance.md
Besitz von visuellen Ebenen, Transformationen oder Animationen: references/interaction-motion.md; für die Abnahme mit tatsächlichem Laufzeitbild zusätzlich references/implementation-review.md lesen
Tools, Pfad-Aliase, Ausführungsumgebung oder langlaufende Aufgaben: references/user-environment-governance.md
Ereignisse, Versionen, Historie oder Caches verwechseln den geplanten Einflussbereich mit tatsächlichen Änderungsfakten: der Vertrag "Trennung von Planbereich und tatsächlichen Änderungen" aus references/change-prevention.md
Lokale Zustände, Heartbeat- oder Telemetrie-Updates überschreiben oder leeren nicht deklarierte Felder, oder Konsumenten können vollständige Snapshots nicht von lokalen Patches unterscheiden: der Vertrag "Aktiver Projektions-Update" aus references/change-prevention.md
Quellcode, README, Skripte, Tests oder Konfiguration codieren lokale und Deployment-Fakten hart: die Grenze der Projektlaufzeitkonfiguration in references/change-prevention.md; Benutzermaschinen-Fakten gleichzeitig references/user-environment-governance.md lesen
Kohäsion, Kopplung, semantische Redundanz oder God-Module: references/architecture-cohesion-governance.md

Externe Tool-Kompatibilität

references/external-tool-compatibility.md lesen. Wenn die Kompatibilitätsbeziehung öffentliche Verträge, abgeleitete Snapshots oder zusammengesetzte Lieferpakete über mehrere Projektstämme hinweg betrifft, gleichzeitig die Abschnitte "Öffentlicher Vertrag", "Vertragsübernahme-Closure" und "Über-Repository-Liefergrenzen" aus references/change-prevention.md lesen. Die Kompatibilitätsprüfung bleibt schreibgeschützt und meldet entlang der definierten Adapter schichtweise ausführbare Artefakte, Fähigkeitsverträge, Aufruf und Isolation, temporäre Eingaben, Upstream-Leitungsprotokolle, strukturierte Ergebnisse, host-unabhängige Kernverifikation und Benutzerketten; Änderungen am autorisierten Projektstamm werden nur bei expliziter Autorisierung zur Reparatur oder Integration durchgeführt.

Projektforschung und -erklärung

Zuerst references/project-research.md lesen. Nur die zur Beantwortung der aktuellen Frage erforderliche Projektoberfläche lesen; wenn der Benutzer explizit eine vollständige Recherche oder Fähigkeitsübernahme anfordert, wird die Abdeckung erweitert, und gleichzeitig wird references/source-fork-and-ecosystem-adoption.md gelesen, zuerst der ursprüngliche Upstream zurückverfolgt und zwischen direkter Wiederverwendung und Methodenlernen unterschieden; bei Bestätigung der direkten Wiederverwendung von Code oder Ressourcen wird zusätzlich references/license-governance.md gelesen, und Drittanbieter-Ressourcen und Danksagungen werden in das Ziel-README geschrieben. Wenn Effektivität, Fehlerbeispiele und Konfidenz gemessen werden müssen, references/project-effectiveness-review.md lesen; wenn ein überprüfbarer Bericht gespeichert werden muss, references/project-research-report.md lesen. Quellcode-Archive werden zuerst mit scripts/extract_project_archive.ps1 und -DestinationRoot <Zielstamm> in ein separates Verzeichnis entpackt; wenn kein anderer Zielstamm angegeben ist, wird E:\Work\BaiduSyncdisk\Code\Example verwendet. Nachdem das Skript den Projektstamm zurückgegeben hat, sofort references/archive-safety-screening.md lesen und scripts/inspect_extracted_project_safety.py ausführen; nur wenn diese Methode schwerwiegende Risiken feststellt, wird dies in die Benutzerausgabe aufgenommen; andernfalls wird geräuschlos mit der ursprünglichen Forschung fortgefahren.

Projektverzeichnis-Governance

references/repository-directory-governance.md lesen. Zuerst mit scripts/inspect_project_tree.py schreibgeschützte physische und Git-Nachweise erfassen, dann für jeden Kandidatenordner den formalen Produzenten, die Pfadquelle, die Konsumenten und den Lebenszyklus überprüfen; Inspektion, Erklärung und Plan stoppen beim Nachweisbuch; nur bei expliziter Autorisierung zur Bereinigung, Verschiebung oder Archivierung werden genaue Pfade geändert; Löschungen unterliegen weiterhin separater Autorisierung. Wenn die Verschiebung aktiven Quellcode, Modelle, Daten, Materialien, Build- oder Run-Einstiege betrifft, gleichzeitig references/change-prevention.md lesen; wenn alte Pfade, Double-Reads, Synchronisationskopien oder teilweise Migrationen bereits existieren, zusätzlich references/root-cause-remediation.md lesen, einmalige Migration der Konsumenten und Austritt aus dem alten Einstieg.

Projektbaseline und -vorlagen

references/project-template-system.md lesen. Schreibgeschützte Anfragen stoppen bei Inspektion, Plan oder Verifikation; Übernahme (Adopt), Upgrade oder Schreiben von Projektkonfigurationen benötigt explizite Autorisierung und Verifikation des formalen Konsumenten.

Vorlagenentwicklung

references/template-evolution.md lesen. Zuerst nachweisen, dass der Kandidat ein stabiler Standardwert und keine noch fallabhängige Methode ist, dann die Vorlagenversion, Registrierung, Hashs, Dokumentation und Konsumententests synchronisieren.

Produkterfahrung und Schnittstellen-Governance

Zuerst references/product-experience-governance.md lesen, dann gemäß den folgenden festgelegten Einstiegen und Bedingungs-Spezialthemen ausführen:

Schnittstellendiagnose, -bewertung, -optimierung oder -neuerstellung: Fest zu lesen: references/ux-design.md, references/interface-experience-quality.md, references/interface-problem-patterns.md, references/implementation-review.md. Vor Änderungen werden alle relevanten Fenster, Seiten, Panels, Overlays, Hauptzustände und User Journeys eingefroren; das auffälligste lokale Problem eines Screenshots darf nicht als vollständiger Prüfumfang betrachtet werden.
Design von Grund auf oder Änderung der visuellen Richtung: references/design-method.md, references/visual-direction.md, references/surface-registers.md
Layout, Designsystem, Interaktion und Animation: references/layout-responsive.md, references/design-system-alignment.md, references/interface-guidelines.md, references/interaction-motion.md
Originalgetreue Rekonstruktion einer Referenzschnittstelle: references/reference-interface-reconstruction.md
Wenn es sich um eine Desktop-, Tauri/Vue- oder lokale Datei-Arbeitsbereich handelt, entsprechend references/desktop-app-governance.md, references/tauri-vue-governance.md, references/local-file-workspace-governance.md lesen; wenn die Projektform bereits feststeht, darf die Plattformhülle nicht nur aufgrund aktuellen Feedbacks zu Farbe, Abstand oder Text weggelassen werden.
Aufgabenstatus oder Fortschritt: references/task-progress-governance.md

Wenn auf ein bestehendes Layout oder Designsystem zurückgegriffen wird, wird scripts/context.mjs maximal einmal pro Aufgabe ausgeführt; bei originalgetreuer Rekonstruktion einer Referenzschnittstelle übernimmt assets/reference-reconstruction/component-spec.md die Komponentenspezifikation.

Repository-Erstellung und -Veröffentlichung

references/repository-publication.md lesen. Unterscheide zwischen Initialisierung, Commit, Remote-Erstellung, Push, Sichtbarkeit, Prüfung und Deployment; jeder Schritt führt nur die bereits autorisierte Stoppposition aus, und vor und nach dem Zustandswechsel werden die genaue Repository-Identität, der Index, der Branch, der Remote und gleichzeitige Änderungen überprüft.

README und Startseite

Zuerst references/readme-delivery.md lesen, mit einem Lieferbuch werden Git-Grenzen, README, Text, Visuals, Mehrsprachigkeit, Lizenzen, Star History, GitHub Topics, Repository-Metadaten, Verifikation und Stopppositionen überprüft; schreibgeschützte Anfragen stoppen beim selben Buch; nur bei expliziter Anforderung von Optimierung, Umschreibung oder vollständiger Bearbeitung wird implementiert. Anschließend references/content-architecture.md lesen; bei vollständiger Optimierung oder wenn Logo/Hero betroffen sind, references/visual-direction.md lesen, zuerst eine code-first formale Identitätsquellen-Recherche durchführen, dann bei Bedarf references/project-native-hero.md und references/github-readme-canvas.md lesen. Wenn Mehrsprachigkeit, persönliche Einstiegsseite oder Repository-Statusbereich benötigt werden, assets/readme-profile/profile.json lesen, von scripts/readme_header.py mit echten Dateien, Repository-Identität, Lizenz und klar analysierter Projektnavigation verarbeitet. Vollständige README-Optimierung für ein bestehendes öffentliches GitHub-Repository enthält Star History und Topics als standardmäßige Liefergegenstände: Star History mit references/github-star-history.md und references/repository-publication.md, Topics werden über scripts/github_topics.py geschrieben und zurückgelesen; es sei denn, der Benutzer lehnt explizit ab oder das Ziel ist objektiv nicht anwendbar; ein erfolgreiches Ergebnis ohne einen der echten Konsumenten kann die vollständige Lieferung nicht abschließen. Bei Bedarf auswählen:

SVG und Hybrid-Visuals: references/svg-production.md, references/hybrid-svg-production.md
Animation: references/motion-production.md
Plattformgrenzen: references/platform-guidelines.md
Spezifische Diagnose oder Integration von selbst gehosteter Star History: references/github-star-history.md; bei reiner Frage nach Fehlerursache oder aktuellem Zustand schreibgeschützt bleiben; bei der Implementierung präzise Commits und Pushs der Repository-Änderungen durchführen, Workflow manuell ausführen, dann entlang der echten Kette von API, Generator, Ausgabebranch, raw SVG und README-Konsumenten abnehmen

README dient nicht als zweite aktive Quelle für jede interne Governance-Regel; README wird nur bei Selbstentwicklung aktualisiert, die die öffentliche Identität, den Leserpfad, den Haupteinstieg oder die Wartungsnavigation verändert. Nach Abschluss scripts/audit_readme.py ausführen und auf der tatsächlichen Rendering-Oberfläche überprüfen.

Lizenz-Governance

Zuerst references/license-governance.md lesen. Erst nach Bestätigung des spezifischen Plans durch den Benutzer wird references/license-rollout.md gelesen und implementiert; schreibgeschützte Anfragen stoppen bei Inhaltsgrenzen, Drittanbieter-Abhängigkeiten und Planvergleich.

Humanisierte Logs

references/log-audit-standard.md lesen. Entlang eines echten Vorgangs Produktion, Kontext, Speicherung, Lesen und endgültiges Viewer-Ergebnis überprüfen; kein schönes Einzelbeispiel als Ersatz für die vollständige Ereigniskette verwenden.

Benutzerumgebungsprofil und Ausführungsumgebung

references/user-environment-governance.md lesen. Das Profil-Schema wird von assets/user-environment/profile.schema.json verwaltet, deterministische Operationen von scripts/user_environment_profile.py. Inspektion, Plan, Verifikation und Lösung halten die entsprechenden schreibgeschützten oder Konsum-Grenzen ein; apply --write benötigt explizite Autorisierung zum Schreiben des Profils und autorisiert nicht automatisch Installation, Download oder Änderung von Systemeinstellungen.

Projektumfassende Prüfung

references/project-audit.md lesen. Wenn der Benutzer nach dem Fortschritt des Implementierungsplans fragt, wird zuerst basierend auf dem ursprünglichen Plan ein Übereinstimmungsbuch erstellt; nach der Autorisierung zur Reparatur muss eine vollständige neue Überprüfung basierend auf dem ursprünglichen Plan und dem aktuell akzeptierten Vertrag generiert werden, wobei keine alten Abschlussmarkierungen verwendet oder der Planbereich aus vorhandenen Tests abgeleitet wird. Bei einer vollständigen Prüfung wird zuerst basierend auf der Projektform ein Abdeckungsbuch für alle zutreffenden Dimensionen erstellt, dann werden die von diesen Dimensionen geforderten Spezialthemen geladen; der Prüfbereich darf nicht nur auf Basis der bereits gefundenen Probleme nachgefüllt werden. Schreibgeschützte Prüfung führt keine automatische Governance durch. Wenn die Benutzereffektivität bewertet werden muss, wird references/project-effectiveness-review.md hinzugezogen; wenn die Aufgabenerfahrung überprüft werden muss, wird references/task-experience-audit.md hinzugezogen.

Plattformvorlagen-Ressourcen

Lesen Sie bei der Verarbeitung des entsprechenden Projekttyps nach Bedarf:

Desktop-Anwendung: references/desktop-app-governance.md
Tauri v2 + Vue: references/tauri-vue-governance.md
Lokaler Datei-Arbeitsbereich: references/local-file-workspace-governance.md

Diese Ressourcen sind aktive Methoden, nicht gleichbedeutend damit, dass das Projekt bereits eine Vorlage übernommen hat; nur eine explizit übernommene und von einem formalen Konsumenten gelesene .project-steward/project.json konstituiert den Vorlagenstatus des Projekts.

Ausgabe und Abschluss

Die Ausgabe gibt zuerst die Schlussfolgerung, dann den Bereich, Nachweise, Unbekanntes und den nächsten Schritt. Eine Analyse darf nicht wie eine bereits durchgeführte Implementierung geschrieben werden; eine Strukturprüfung darf nicht als bewiesene echte Benutzerkette geschrieben werden; die Verhaltensprüfung der aktuellen Aufgabe darf nicht als bewiesener unabhängiger Kaltstart geschrieben werden.

Wenn ein Einflussdiagramm vorhanden ist, sollte es mindestens Produzenten, Übertragungs- oder Speichergrenzen, Konsumenten, endgültiges Benutzerergebnis, einzige aktive Quelle, Austrittsbedingungen für alte Pfade und Abnahme-Einstieg enthalten. Wenn mehrere historische Ergebnisse betroffen sind, werden nacheinander Hauptursache, Erfolgsmechanismus, Fähigkeitslücken, formale Eigentümer und Verifikationsstufe gemeldet.

Nur wenn der aktive Route, die entsprechende Methode, die formalen Konsumenten, die deterministischen Tests und die autorisierte echte Benutzerkette dieser Runde alle übereinstimmen, wird der Abschluss gemeldet.

Project Steward

Was ist Project Steward?

In Ihrer bevorzugten KI fragen

Dokumentation