Eine Local-First-Desktop-App für KI-Design innerhalb ihrer festen Produktregeln ändern

## Bei widersprüchlichen Anweisungsdateien dem Agenten-Leitfaden folgen Lies diese Datei, bevor du Änderungen vornimmst. Andere Anweisungsdateien für Agenten im Repository können hinter dem aktuellen Plan zurückliegen; wo sie dieser Datei widersprechen, hat diese Datei Vorrang. Interne Entwurfsdokumente wie ein Visionsdokument, ein Grundsatzdokument oder der aktuelle Releaseplan sind nützlicher Zusatzkontext, sofern sie in deinem Checkout vorhanden sind. Das Verzeichnis der internen Dokumente ist per gitignore ausgeschlossen; deshalb halten Maintainer Pläne, Übergaben und Recherchen lokal, während öffentlichen Mitwirkenden davon möglicherweise nichts vorliegt. - Blockiere die Arbeit öffentlicher Mitwirkender niemals mit Dateien, die nur Maintainer sehen können. - Zitiere in einem öffentlichen Review-Kommentar niemals einen Pfad unterhalb des per gitignore ausgeschlossenen Dokumentationsverzeichnisses, es sei denn, diese Datei existiert auch im öffentlichen Checkout. - Wenn diese Dokumente fehlen, stütze dich auf diese Datei, auf öffentliche Issues und Pull Requests sowie auf die README. ## Jedes Design als lange Sitzung mit eigenem Arbeitsbereich behandeln Das Produkt ist kein Generator für einzelne Prompts. Jede Arbeitseinheit ist eine langlaufende Agentensitzung, die von einem echten Arbeitsbereich auf dem Rechner der Nutzerin oder des Nutzers getragen wird, und der Agent kann Dateien lesen und bearbeiten, berechtigungspflichtige Befehle ausführen, strukturierte Fragen stellen, Artefakte in der Vorschau anzeigen, Anpassungsregler bereitstellen, Bilder erzeugen, sofern das konfigurierte Modell dies unterstützt, und Designsystem-Dokumente erstellen. - Ein Design besitzt einen Arbeitsbereich. Es gibt keine Trennung in versiegelt und offen: Das Dateisystem des Arbeitsbereichs ist die Quelle der Wahrheit für Artefakte und Assets. - Der Agent bearbeitet Quelldateien im Arbeitsbereich; die Vorschau-Laufzeitumgebung rendert diese Quellen zu einem anzeigbaren Dokument; Exporter wandeln das gerenderte Dokument oder das Quelldokument in Standardausgaben wie HTML, PDF, PPTX, ZIP oder Markdown um. - Halte genau eine kanonische Quell-Einstiegsdatei für das aktuelle Format vor (zum Beispiel eine JSX-Komponentendatei) und reserviere die eigenständige HTML-Datei für Exporte oder Altbestände im Arbeitsbereich. - Bewährte Mechaniken von Programmieragenten zu übernehmen ist ausdrücklich gewollt; die Produktgrenze verläuft so, dass fachspezifische Werkzeuge und das Local-First-Arbeitsbereichsmodell das sind, was du darauf aufsetzt. ## Die festen Regeln einhalten: keine gebündelten Modelle, nur eigene Schlüssel Dies sind Verpflichtungen des Projekts, keine Vorlieben. Gib sie nicht der Bequemlichkeit halber auf. 1. Keine mitgelieferten Modell-Laufzeitumgebungen. Liefere keine Inferenz-Engines, Sprachinterpreter, Browser-Binärdateien oder Modellgewichte im Installationsprogramm aus. Nutze Systeminstallationen oder einen bedarfsgesteuerten Download mit für die Nutzenden sichtbarer Zustimmung. 2. Ausschließlich eigene Schlüssel der Nutzenden. Standardmäßig kein gehostetes Konto, keine über einen Proxy geleitete API und keine Telemetrie. Zugangsdaten der Nutzenden bleiben in einer für Menschen lesbaren lokalen Konfiguration. 3. Local-First-Speicherung. Sitzungen liegen als Sitzungsdateien vor, an die ausschließlich angehängt wird, ergänzt um echte Arbeitsbereichsdateien. Vorhandene Daten in der alten eingebetteten Datenbank dürfen migriert werden, aber lege dort keine neuen Tabellen für Sitzungen, Chatverlauf, Kommentare, Snapshots oder Designdateien an. 4. Jedes Design hat einen Arbeitsbereich. Nichts Wichtiges darf ausschließlich innerhalb eines Sitzungsdatensatzes existieren. 5. Alles, was ausgeliefert, mitgeliefert, gelinkt, von Anwendungscode importiert oder an Nutzende verteilt wird, muss unter einer permissiven Lizenz stehen und mit der Projektlizenz vereinbar sein. Weise in dieser Menge Copyleft-Assets, quelloffen-eingeschränkte, proprietäre und lizenzrechtlich unklare Assets von Dritten zurück. Werkzeuge für CI und Releases, die ausschließlich im Arbeitsablauf laufen, dürfen Copyleft-Lizenzen verwenden, solange sie nicht als Fremdcode ins Repository aufgenommen, mitgeliefert, gelinkt oder in das Produkt kopiert werden; dokumentiere die Gründe und beschränke ihre Ausgabe auf gewöhnliche Metadaten oder Manifeste. 6. Lade schwergewichtige Funktionen erst bei Bedarf. Exporter, Web-Erfassung, Gerüstvorlagen, Skills, Referenz-Assets und Bilderzeugung müssen bei Bedarf geladen werden und nicht beim Start der Anwendung. 7. Nutze zuerst die Grundbausteine des zugrunde liegenden Agenten-Frameworks wieder. Es verantwortet Sitzungen, eingebaute Werkzeuge, die Shell-Ausführung, das Streaming von Ereignissen, das Modellregister, die Anbieterregistrierung und Fähigkeitsdaten, sofern nicht ein fachspezifischer Bedarf etwas anderes belegt. 8. Referenzdaten sind Daten, kein Modellgedächtnis. Entnimm Marken- und Stilwerte dem Designdokument des Arbeitsbereichs, Nutzerdateien, offiziellen Assets oder veröffentlichten Quellen. Erfinde niemals Markenfarben oder Spezifikationen aus dem Gedächtnis. 9. Änderungen sollen kompatibel, aktualisierbar, schlank und elegant bleiben und sollen der detaillierten Grundsatz-Checkliste des Projekts folgen, sofern eine solche vorhanden ist. ## Beim Bau von Websites KI-lesbare Dateien wie llms.txt anlegen Wenn du eine Website, Projekt-Startseite, Produktseite, persönliche Seite, Dokumentationsseite, ein Blog oder eine öffentliche Projektseite erstellst oder aktualisierst, nimm KI-Sichtbarkeit standardmäßig in den Lieferumfang auf, sofern die Nutzerin oder der Nutzer nicht ausdrücklich darauf verzichtet. - Füge eine Datei `/llms.txt` mit einer knappen Markdown-Übersicht über die Website, die Autorin, den Autor oder die Organisation, die wichtigsten Seiten, kanonische Projekt- oder Produktbeschreibungen und Links zu maschinenlesbaren Ressourcen hinzu. - Füge eine Datei `/llms-full.txt` hinzu, wenn die Website genug inhaltlich substanzielle öffentliche Inhalte hat, um eine ausführlichere, für KI lesbare Kontextdatei zu rechtfertigen. - Konfiguriere `robots.txt` bewusst: Erlaube Such- und Abruf-Crawler, die KI-Systemen helfen, öffentliche Inhalte zu zitieren oder abzurufen, und behandle Trainings-Crawler als eigene Richtlinienentscheidung. - Pflege `sitemap.xml` und stelle sicher, dass sie die wichtigen öffentlichen Seiten abdeckt. Weise auf die Einreichung bei den Webmaster-Werkzeugen hin, wenn das relevant ist. - Füge dort, wo es nützlich ist, passende strukturierte JSON-LD-Daten hinzu, etwa Typen für Person, Organisation, Website, Artikel, Softwareanwendung, FAQ oder kreatives Werk. - Bevorzuge saubere maschinenlesbare Endpunkte in Markdown oder JSON für wichtige Entitäten wie Profile, Projekte, Beiträge, Dokumentation, Releases, FAQs und Produktdaten. - Halte die Inhalte wahrheitsgemäß, mit Quellen belegt und frei von Spam. Ziel ist es, KI-Systemen zu helfen, tatsächlich vorhandene Inhalte korrekt zu verstehen und zu zitieren, und nicht, minderwertiges Füllmaterial zu erzeugen. ## Alle Modellaufrufe und Werkzeuge über das gemeinsame Agenten-Framework führen - Baue auf dem gemeinsamen Agenten-Framework und seiner Modellabstraktionsschicht auf statt auf einem selbstgebauten Gegenstück. - Verwende die eingebauten Werkzeuge des Frameworks für Lese-, Schreib-, Bearbeitungs-, Shell-, Grep-, Such- und Auflistungsoperationen, statt parallele Varianten zu schreiben. - Leite jeden Werkzeugaufruf durch den Werkzeugaufruf-Hook des Frameworks und die Berechtigungsoberfläche der Anwendung. - Lies die Modellfähigkeiten aus den Modellbeschreibungsfeldern des Frameworks, etwa akzeptierte Eingabetypen, Unterstützung für Schlussfolgern, Kosten, Kontextfenster und maximale Ausgabetoken. Codiere Fähigkeitstabellen nicht fest ein. - Registriere eigene Anbieter über die Anbieterregistrierungs-API des Frameworks. Baue keine parallele Anbieter-SDK-Schicht. - Alle Modellaufrufe laufen über die Modellabstraktion des Frameworks. Importiere Hersteller-SDKs nicht direkt im Anwendungscode. ## Sitzungen in Append-only-Dateien und Designs im Arbeitsbereich speichern - Ein Design ist eine Sitzung. Der Sitzungsverlauf liegt unterhalb des Nutzerdatenverzeichnisses der Anwendung als Sitzungsdateien, an die ausschließlich angehängt wird. - Design-Quelldateien, erzeugtes Markup und erzeugte Stile, Assets, Exporte sowie die Agenten- und Designdokumente auf Ebene des Arbeitsbereichs liegen im Arbeitsbereich der Nutzenden, nicht in einer Anwendungsdatenbank. - Die Einstellungen des Arbeitsbereichs liegen in einer versionierten Einstellungsdatei, die ein explizites Feld für die Schemaversion enthält. - Die persönliche lokale Einstellungsdatei gilt pro Nutzerin bzw. Nutzer und muss per gitignore ausgeschlossen bleiben. - Die alte eingebettete Datenbank ist zu migrierender Datenbestand, nicht das aktuelle Speichermodell. Erweitere sie nicht um neuen Funktionszustand. ## Nur die eingebauten Werkzeuge und wenige Design-Werkzeuge nutzen Die Werkzeugoberfläche besteht aus den eingebauten Werkzeugen des Frameworks plus einer kurzen Liste fachspezifischer Werkzeuge: - `ask(questions)` stellt strukturierte Fragen dar und wartet auf die Nutzerin oder den Nutzer. - `scaffold(kind, path)` kopiert eine kuratierte Startvorlage in den Arbeitsbereich. - `skill(name)` lädt Skill-Text bei Bedarf aus einem Manifest. - `preview(path)` rendert Artefakte und liefert Konsolenfehler, Asset-Fehler, eine DOM-Gliederung, Metriken und Bildschirmfotos für Modelle mit Bildverständnis zurück. - `gen_image(prompt, path)` schreibt erzeugte Bilder auf die Festplatte, wenn Fähigkeit und Anbieterkonfiguration dies zulassen. - `tweaks(blocks)` deklariert bearbeitbare Bedienelemente über Dateien hinweg. - `todos(items)` zeigt den Aufgabenstatus bei komplexen Zügen an. - `done(path)` beendet einen Zug nach einer Selbstprüfung in der Vorschau. Führe keinen Prüf-Subagenten, kein Werkzeug zum Erfassen von Codeschnipseln, kein eigenes Shell-Werkzeug, kein eigenes Werkzeug zum Auflisten von Dateien und kein vom Agenten geschriebenes Arbeitsgedächtnis wieder ein, solange sich der Plan nicht ändert. ## Die vier Arten von Design-Ressourcen getrennt halten Das Designdokument folgt der veröffentlichten Spezifikation und kann sowohl Eingabe als auch Ausgabe sein. Von Agenten erzeugte Arbeiten über mehrere Bildschirme hinweg wahren die visuelle Konsistenz, indem dieses Dokument aktualisiert wird, sobald neue Tokens entstehen. Eingebaute Referenzsysteme müssen Urhebernennung, Quelle, Lizenzmetadaten und einen Hinweis „nicht affiliiert“ mitführen, und eingebaute Skills verwenden das Standardformat für Skill-Dateien. Manifeste für Skills und Gerüstvorlagen müssen Lizenz- und Quellenmetadaten mitführen. Die vier Ressourcenarten sind nicht austauschbar: - Markdown-Skills sind Methodenregeln. Sie sagen dem Agenten, wie er arbeiten soll; sie kopieren keine Dateien in einen Arbeitsbereich. - Referenz-Designsysteme sind schreibgeschützt und werden namentlich als Skill geladen. Bearbeite sie nicht für ein Projekt; übertrage die Entscheidungen, die du übernimmst, in das Designdokument des Arbeitsbereichs. - Gerüstvorlagen sind konkrete Start- und Quell-Assets, die in den Arbeitsbereich kopiert werden. Sie dürfen in jedem Textformat vorliegen, solange das Manifest sie genau beschreibt. - Schnipsel aus Design-Skills sind kopierbare Komponentenmuster, die über das virtuelle Dateisystem bereitgestellt werden. Sie sind Quellschnipsel, keine Methodenregeln und keine maßgebliche Markeninstanz. Das Designdokument des Arbeitsbereichs ist der projektspezifische Staffelstab. Sobald es existiert, ist es für das aktuelle Design maßgeblich, und erzeugte Arbeiten sollen es bewahren oder reparieren, statt es als eine weitere Voreinstellung zu behandeln. ## Startvorlagen wie Produktcode prüfen und Dateiendungen passend halten - Behandle Start- und Gerüst-Assets als Produktcode, nicht als Füllmaterial für Prompts. Prüfe die tatsächlichen Dateiinhalte ebenso wie das Manifest, bevor du eine Voreinstellung änderst oder hinzufügst. - Halte Quellformat und Dateiendung in Übereinstimmung. Vollständige HTML-Dokumente gehören in `.html`-Dateien, Komponenten-Startvorlagen in die Komponentenendung, Stilschnipsel in `.css`. Das Kopierwerkzeug soll die Endung der Quelle beibehalten, das Asset selbst muss trotzdem korrekt benannt und beschrieben sein. - Eingebaute HTML-Startvorlagen müssen in sich geschlossen und in der aktuellen Laufzeitumgebung in der Vorschau darstellbar sein. Füge Gerüst-Assets keine CDN- oder Laufzeitskripte von Dritten hinzu. Wenn eine Startvorlage Laufzeitverhalten benötigt, verwende lokales einfaches HTML, CSS und JavaScript oder eine von der Anwendung bereitgestellte, bei Bedarf geladene Abhängigkeit mit klarem Lizenzweg. - Vermeide schwache Platzhaltertexte wie „Titel der Präsentation“, „Seiteninhalt“, „Dies ersetzen“ oder „Punkt eins“. Verwende neutrale, brauchbare Beispielinhalte und mache die offensichtlichen Austauschstellen über die deklarierten Anpassungsvorgaben der Startvorlage zugänglich. - Manifestbeschreibungen müssen angeben, in welchem Format eine Startvorlage vorliegt, und müssen endungsempfindliche Assets ausdrücklich benennen, besonders Dateien, die ein Agent sonst unter der falschen Endung kopieren könnte. - Wenn du den Verzeichnisbaum der Gerüstvorlagen anfasst, prüfe auf Abweichungen zwischen Endung und Inhalt, auf externe Netzwerk-URLs, veraltete Platzhaltertexte und auseinandergelaufene Manifeste. Ergänze oder aktualisiere gezielte Tests für Gerüstvorlagen und Laufzeitumgebung, wenn die Änderung Kopierpfade, die Klassifizierung in der Vorschau oder das Verhalten von Werkzeugen betrifft. ## Bei den gewählten Werkzeugen bleiben und Versionen aus der Lockfile lesen - Ein Paketmanager für das gesamte Repository. Mische niemals einen zweiten hinzu. - Verwende den im Repository gewählten Build-Orchestrator, das eine Werkzeug für Linting und Formatierung sowie die festgelegten Ausführungswerkzeuge für Unittests und für End-to-End-Tests, statt Alternativen einzuführen. - TypeScript im strikten Modus mit wortgetreuer Modulsyntax und Bundler-Auflösung. Kein `any`. - Conventional Commits für Commit-Nachrichten und ein Changeset-Werkzeug für die Versionierung. Bearbeite den Changelog nicht von Hand. Lege die Version der Laufzeitumgebung sowohl in der Versionsdatei als auch im Feld engines fest. - Die genauen Paketversionen stehen in den Manifesten und in der Lockdatei. Lies diese Dateien, statt veralteter Dokumentation zu vertrauen. - Die Entscheidungen für das Frontend sind bereits gefallen: die gewählte Ansichtsbibliothek und das gewählte Build-Werkzeug, Utility-CSS mit CSS-Variablen, eine leichtgewichtige Zustandsbibliothek, barrierefreie Grundbausteine ohne eigenes Erscheinungsbild, gekapselt im gemeinsamen Oberflächenpaket, ein Symbolsatz, native Formulare mit Formulardaten und CSS-Übergänge für Animationen. Führe keine konkurrierenden Bibliotheken für Zustand, Animation oder Komponenten ein. - Die Rahmenoberfläche der Anwendung muss die Tokens des gemeinsamen Oberflächenpakets verwenden. Erzeugte Designquellen und Exporte dürfen ihr eigenes visuelles System definieren. - Das Repository teilt die Anwendungshülle, den Agentenkern, die Anbieteranbindung, die Vorschau-Laufzeitumgebung, die gemeinsame Oberfläche, die Artefaktschemata, die Exporter, die Vorlagen und die gemeinsamen Typen in getrennte Pakete auf. Lege Code in dem Paket ab, das für das jeweilige Anliegen zuständig ist. ## Für größere Aufgaben eine Plandatei schreiben und Änderungen eng halten - Lies bei nicht trivialer Architektur- oder Produktarbeit das Visionsdokument, das Grundsatzdokument und das Dokument zum aktuellen Plan, sofern sie lokal vorhanden sind; andernfalls stütze dich auf diese Datei und die öffentliche Diskussion. - Schreibe eine dauerhafte lokale Plandatei für Aufgaben, die mehr als etwa fünf Werkzeugaufrufe oder mehr als drei Dateien umfassen. Erzeuge bei kleinen, direkten Korrekturen keinen Planungsaufwand. - Verwende getrennte Arbeitsbäume für parallele oder nicht zusammenhängende Funktionsarbeit. Mische nicht zwei unabhängige Branches in einem Checkout. - Prüfe die Recherche-Warteschlange, bevor du die Sandbox, Inline-Kommentare, Anpassungsregler, Exporter, Framework-Fähigkeiten, Gerüstvorlagen, Skills oder Referenz-Assets anfasst, sofern diese Datei lokal vorhanden ist. - Halte Änderungen eng umgrenzt und vermeide nebenbei durchgeführte Refaktorierungen. - Prüfe vor dem Hinzufügen einer ausgelieferten oder zur Laufzeit benötigten Abhängigkeit deren Lizenz, Installationsgröße, Alternativen und ob sie eine Peer-Abhängigkeit sein kann. Dokumentiere bei Werkzeugen, die nur im Arbeitsablauf laufen, warum sie nicht mitgeliefert werden und ob ihre Ausgabe die verteilten Artefakte beeinflusst. - Ergänze oder aktualisiere die Abdeckung durch Unittests bei Funktionsarbeit und weite die Tests aus, wenn du Migrationen, Berechtigungen, Werkzeug-Hooks oder gemeinsame Verträge änderst. - Bevorzuge ein Manifest plus Verzweigungslogik gegenüber einer Registrierung, bis zwei echte Aufrufer mehr benötigen. - Kommentiere nur dort, wo der Grund die nächste Person, die den Code pflegt, überraschen würde. ## Befehle nach vier Berechtigungsstufen behandeln und Blockiergründe zeigen Es gibt ein einziges Berechtigungsmodell mit ansteigenden Stufen: - Stufe 0: Lese- und Schreibzugriffe lokal im Arbeitsbereich, einfache Dateibefehle und nur lesende Versionskontrollbefehle dürfen ohne Unterbrechung laufen. - Stufe 1: Installationen, Build-Befehle, nicht lokale Netzwerkabrufe und Befehle außerhalb des Arbeitsverzeichnisses fragen einmal nach und dürfen danach auf die Erlaubnisliste gesetzt werden. - Stufe 2: Veröffentlichen, Pushen, Rechteausweitung und andere Befehle mit großer Schadensreichweite fragen jedes Mal nach. - Stufe 3: Zerstörerische Systembefehle, das direkte Weiterleiten eines heruntergeladenen Skripts in eine Shell und Schreibzugriffe auf Systemverzeichnisse werden ohne ausdrückliche Aufhebung blockiert. Verbirg blockierte Werkzeugaufrufe nicht. Zeige den Befehl, den Pfad, die Stufe und den Grund für die Blockierung. ## Keine Anbieter-SDKs direkt importieren und kein Tracking ohne Zustimmung einbauen - Abhängigkeitsverzeichnisse, Build-Ausgaben, Umgebungsdateien, erzeugte Release-Artefakte oder private lokale Dateien in die Versionskontrolle aufnehmen. - SDKs von Modellherstellern im Anwendungscode importieren oder Tests schreiben, die das Modell auf Ebene des Hersteller-SDK nachbilden. Bilde stattdessen an der Grenze zum Kern oder zum Framework nach. - Tracking, Analysefunktionen, Kontoabläufe, Cloud-Synchronisierung oder automatische Aktualisierung ohne einen ausdrücklichen Zustimmungsablauf hinzufügen. - Nutzerpfade fest einprogrammieren. Beachte die Verzeichniskonventionen der Plattform, die Pfad-APIs der Anwendung und die Wurzelverzeichnisse der Arbeitsbereiche. - Neuen Funktionszustand für Sitzungs- oder Designdaten hinzufügen, der auf der alten Datenbank aufsetzt. - Eine schwerere Gruppierungsabstraktion oberhalb des Arbeitsbereichs einführen. Mehrere Sitzungen dürfen sich einen Arbeitsbereich teilen, aber in der Seitenleiste werden Sitzungen aufgelistet. - Sitzungsverzweigung, Rückgängigmachen und Zurücksetzen von Versionen, Unterstützung für externe Werkzeugserver oder die Installation von Community-Skills bereitstellen, solange sich der Plan nicht ändert. - Rohe Konsolenaufrufe im Hauptprozess, im Kern, in den Anbietern, in den Exportern oder in gemeinsamen Paketen verwenden. Nutze den Logger des Projekts.