Projektlogik-Map

Was macht Projektlogik-Map?

Hilft Wartungsentwicklern und KI bei der Beantwortung von: Was wird geändert? Was wird beeinflusst? Was darf nicht kaputtgehen? Wie wird validiert?

Aufgabenbereich wählen

• Erstgenerierung: Aus Anforderungen und Code-Evidenz eine Markdown-Beziehungsmap erstellen. Wenn der Benutzer eine visuelle Ansicht benötigt oder bereits HTML existiert, gleichzeitig oder aktualisierend eine visuelle Karte generieren.
• Inkrementelles Update: Stabile IDs beibehalten, nur geänderte Fakten, Beziehungen, Status und die Karte aktualisieren. Referenzen auf gelöschte Knoten überprüfen.
• Auswirkungsanalyse: Bei einer gegebenen Änderung Eingaben, Konsumenten, Zustände, Ausnahmepfade, Einschränkungen und Validierungen verfolgen; wenn der Benutzer nur eine Analyse wünscht, keine Änderungen umsetzen.

Bevorzugt vorhandene Projektdateien und IDs. Für neue Projekte Standardausgabe als docs/LOGIC_MAP.md; visuelle Version als docs/logic-map.html. Wenn bereits benannte Dateien oder benutzerdefinierte Pfade existieren, diese priorisieren.

Zuerst Evidenz sammeln, dann Beziehungen aufbauen

Projektkonventionen, Anforderungsbaseline, zentrale Einstiegspunkte, Seiten/Arbeitsbereiche, Zustände und Speicher, Geschäftsabläufe, Tests und Veröffentlichungsaufzeichnungen lesen. Entlang der Kernbenutzeraufgaben den nötigen Code lesen, nicht jede Datei des Repositorys exhaustiv durchgehen.

Klar unterscheiden zwischen: Anforderungsversprechen, tatsächlicher Implementierung, automatisierter Prüfevidenz, Laufzeitumgebungsvalidierung, externer Überprüfung. Alte Aufzeichnungen mit Datum und Evidenzbereich versehen; nicht durchgeführte Prüfungen dürfen nicht als bestanden dokumentiert werden.

Schwerpunkte verfolgen:

• Ob mehrere Einstiegspunkte tatsächlich dieselbe Verarbeitungskette teilen und welche welche Schritte umgehen.
• Wer Daten erstellt, besitzt, konsumiert, überschreibt oder freigibt, ob sie persistiert werden oder das System verlassen.
• Wie Abbrüche, leere Daten, Ablehnungen, Zeitüberschreitungen, Analysefehler jeweils enden.
• Ob häufige Aktualisierungen, Batches, Schwellenwerte projektspezifische Invarianten tragen.

Konflikte zwischen Dokumentation und Code separat dokumentieren, nicht zugunsten der Optik harmonisieren. Code-Risiken können in Lücken festgehalten werden, die Aufgabe nicht automatisch auf Reparatur ausweiten.

Nachvollziehbares Modell aufbauen

references/model.md lesen und dessen Knoten-, Beziehungs- und Evidenzfelder nutzen; in Kombination mit den vorhandenen Projekt-IDs vereinfachen oder anpassen.

Zunächst eine einzeilige Definition der Kernaufgabe und deren Hauptkette notieren, dann normale und Ausnahmepfade, seitenübergreifende Zustände, Schnittstellen, Einschränkungen und Validierungen ergänzen. In der Karte sind benachbarte Knoten nicht automatisch verwandt; jede Kante muss Bedeutung und Begründung erklären können.

Standard-Lieferstruktur:

1. Fähigkeitsübersicht: Dem Leser zuerst zeigen, was das Produkt kann. Nach realen Benutzeraufgaben gruppieren; technische Teilkartenanzahl zählt nicht als Fähigkeitsanzahl, nicht auf die fünf Gruppen des Beispiels fixieren.
2. Einzelfähigkeitsablauf: Einstieg, Aktionen, Verarbeitung, Zustände und Ausgänge entfalten, Verzweigungsbedingungen vermerken.
3. Knotenbeschreibung und Evidenz: Verantwortung, direkte Beziehungen, Implementierungsort, Einschränkungen, Validierung und Status.
4. Änderungsauswirkungsindex: Häufige Änderungen den betroffenen Knoten, Dateien und Prüfungen zuordnen.

Die Übersicht kann Nebenbeziehungen auslassen, aber das vollständige Modell oder die Knotenbeschreibung müssen diese wiederherstellen können. Die Anforderungsdokumentation bleibt für Anforderungsentscheidungen zuständig; die Karte erstellt keine separate Anforderungsbaseline.

HTML-Visualisierung

Bei Bedarf an HTML references/visual.md lesen. Bei konkretem Referenzbedarf zusätzlich references/wechat-example.html ansehen; es ist ein Beispiel eines implementierten Projekts, keine allgemeingültige Tatsache oder feste Layoutvorlage.

Knoten und semantische Kanten teilen sich eine gemeinsame Datenquelle. Ansichtskoordinaten, Routing, Theme separat verwalten; Markdown und HTML verwenden dieselben IDs. Einfache Projekte können direkt eine kleine Datenstruktur pflegen, ohne zwingend einen Generator oder eine Grafikbibliothek einzuführen.

Bereits bestätigte visuelle Ausrichtung des Benutzers beibehalten. Standardmäßig zentrierte Breitenbegrenzung, Fähigkeitsübersicht als Einstieg, Navigation durch Einzelfähigkeitsabläufe, Erläuterungen unterhalb der Karte sowie Hell- und Dunkelthem. Knotenanzahl und Aufteilung in Teilkarten durch die Inhaltsdichte bestimmt.

Nicht die WeChat-spezifischen Begriffe, Größenbereiche, unvalidierte Status oder manuellen Koordinaten des Beispiels in andere Projekte kopieren. Produkt-Wurzelgruppierungen, die nur der Darstellungsstruktur dienen, klar kennzeichnen, nicht als neue Geschäftsfunktion behandeln.

Validierung und Auslieferung

Inhalt und Struktur:

• IDs eindeutig; Kantenenden existieren; jede Kernfähigkeit hat einen Aufrufpunkt; gelöschte Knoten keine hängenden Referenzen.
• Include-, Datenfluss-, Abhängigkeits-, Einschränkungs- und Validierungsbeziehungen haben eigene Semantik, nicht als Ausführungsreihenfolge vermischt.
• Speicherlebenszyklus, Ausnahmeausgänge, Implementierungsorte und Status durch Evidenz belegbar.
• Selbst einmal eine konkrete Änderung fragen, z. B. „Was beeinflusst eine Änderung des Layouts?“ – die Karte sollte zu den betroffenen Zuständen, Konsumenten und Validierungen führen.

Für die visuelle Version zusätzlich tatsächlich im Browser überprüfen:

• Die Übersicht zeigt alle Hauptfähigkeiten gleichzeitig, Text lesbar, Pfeile durchdringen keine Knoten oder Texte.
• Einzelne Fähigkeitsabläufe nacheinander öffnen, Aufruf, querverweisende Beziehungen, Auswahlstatus, Abwahl prüfen.
• Hell- und Dunkelmodus in Text, Knoten, Verbindungen, Pfeilen und Erläuterungen prüfen; Screenshots erfassen.
• Vollständigkeit der Übersicht bei Ziel-Desktop-Auflösung prüfen; bei schmalen Fenstern lesbare Schriftgröße erhalten, Scrollen in der Karte oder Aufteilung in Teilkarten erlauben.

Statische Syntax- oder Strukturprüfungen ersetzen keine visuelle Prüfung. Wenn kein Browser verfügbar ist, die Datei ausliefern und die nicht durchgeführten Prüfungen klar angeben; keine alten Screenshots als aktuelles Ergebnis ausgeben.

Auslieferungslink, wesentliche Beziehungsänderungen, tatsächliche Prüfergebnisse und verbleibende Lücken bereitstellen. Arbeit gemäß den Git-Konventionen des Projekts speichern; keine eigenmächtige Veröffentlichung als Website oder Installation eines globalen Skills.