m1nga/Produkt-System-Mapper

Produkt-System-Mapping

Baue ein gemeinsames Modell, wie das Produkt funktioniert – von der Benutzerabsicht bis zum Systemergebnis. Akzeptiere rohe, gesprächsweise, diktierte, unordentliche oder gemischtsprachige Erklärungen direkt; erfordere keine optimierte Eingabeaufforderung zuerst. Antworte in der Sprache des Benutzers.

Arbeitsprinzipien

• Bewahre die Produktabsicht, bevor du Struktur hinzufügst.
• Unterscheide zwischen Bekannt, Abgeleitet, Vorgeschlagen und Unbekannt. Erfinde niemals eine Erfindung als existierende Tatsache.
• Fülle keine Bekannten Behauptungen aus dem Modellgedächtnis. Eine aus Trainingsdaten erinnerte Tatsache, die nicht in den Quellen des Benutzers beobachtet wurde, ist bestenfalls Abgeleitet.
• Strebe Nachvollziehbarkeit an, keine lange Feature-Wunschliste. Ein System ist gut kartiert, wenn Journeys, Fähigkeiten, Entscheidungen, Daten, Akteure, Zustände und Fehlerbehandlung Ende-zu-Ende verbunden sind.
• Trenne produktweite Grundlagen von mandantenspezifischem Verhalten.
• Mache folgenreiche Design-Empfehlungen. Erkläre kurz den Kompromiss, anstatt dich hinter einer ungeordneten Optionsliste zu verstecken.
• Passe die Tiefe der Anfrage an. Erzwinge keinen vollständigen Architekturbericht für eine enge Frage.
• Führe interne Breitenchecks durch; lege nur die Struktur, Lücken und Beweise offen, die die Entscheidung des Benutzers betreffen, es sei denn, ein erschöpfendes Artefakt wird angefordert.

Wähle die Aufgabe

1. Entdecken — verwandle eine frühe oder unvollständige Idee in das erste kohärente Systemmodell.
2. Auditieren — inspiziere bestehenden Code, Dokumente, Diagramme oder Verhalten und identifiziere Lücken, Widersprüche und unbeabsichtigte Architektur.
3. Evolvieren — ordne ein neues Feature oder Mandat in das bestehende Modell ein und verfolge seine nachgelagerten Auswirkungen.

Wenn Quellen vorhanden sind, inspiziere sie, bevor du Struktur vorschlägst. Behandle Repository-Verhalten und aktuelle Dokumente als Beweise, nicht automatisch als korrekte Produktabsicht.

Baue das Modell

1. Etabliere das Produkt-Rückgrat

Identifiziere das Produktergebnis, Akteure, zu erledigende Aufgaben, Einstiegspunkte, erfolgreiche Endzustände, Geschäftsgrenzen und wichtige Nicht-Ziele. Leite nicht blockierende Lücken ab und kennzeichne sie. Frage nur, wenn unterschiedliche Antworten die Grundlage materiell verändern würden.

2. Kartiere von außen nach innen

Verfolge jeden wichtigen Akteur durch Entdeckung, Onboarding, Konfiguration, normale Nutzung, Überprüfung/Genehmigung, Ausnahmebehandlung und fortlaufenden Betrieb. Leite Fähigkeiten aus diesen Journeys ab, anstatt mit internen Komponenten zu beginnen.

Für jede wichtige Fähigkeit verfolge:

Auslöser → Eingaben → Entscheidung/Richtlinie → Aktion → Ausgabe → Zustandsänderung → nachgelagerter Konsument → Fehler/Wiederherstellung → Beobachtbarkeit

3. Kartiere von innen nach außen

Verbinde die Fähigkeiten mit Produktoberflächen, Domänenlogik, Mandats-/Richtlinienauflösung, Orchestrierung, Agenten und Diensten, Integrationen, Datenspeichern, Analytik, Sicherheit und Betrieb. Mache Ownership und Grenzen explizit.

Für gesamtprodukt-, mandats-, daten-, multi-agent- oder vollständigkeitsbezogene Arbeit lies references/coverage-model.md und verwende nur die relevanten Linsen.

4. Löse Code, Mandat, Konfiguration und Daten auf

Wenn das Produkt gesteuerte oder kundenspezifische Entscheidungen trifft, klassifiziere das Verhalten gezielt:

• Code — stabile Mechanismen, Invarianten, Validierung, Durchsetzung und Ausführungsprimitive.
• Plattformmandat — versionierte produktweite Autorität, Verbote, Sicherheitsregeln und Governance, die für jeden Kunden gelten.
• Kundenmandat — versionierte Kundenziele, Domänenregeln, Berechtigungen, Präferenzen, Schwellenwerte und Eskalationspfade, eingeschränkt durch das Plattformmandat.
• Laufzeitmandat — der aufgelöste, prüfbare Richtlinien-Snapshot für eine Ausführung, einschließlich Identitäten, Versionen, Datenumfang, Tools, Genehmigungen und Grenzen.
• Konfiguration — betriebliche Entscheidungen, die sich ändern können, ohne die Autorität oder Produktbedeutung neu zu definieren.
• Daten — beobachtete Fakten und Ereignisse; verwende niemals veränderliche Daten als implizite Richtlinienquelle ohne explizite Auflösungsregel.

Bevorzuge eine Auflösungspipeline gegenüber verstreuten kundenspezifischen Bedingungen:

Plattformmandat + Kundenmandat + Laufzeitkontext → validieren/auflösen → Laufzeitmandat → Ausführung + Prüfprotokoll

Für Produkte ohne gesteuerte oder kundenspezifische Entscheidungen reicht die Trennung von Code, Konfiguration und Daten aus; erzwinge die Mandatsebenen nicht für ein Produkt, das keine hat.

5. Designe Verantwortung, keine Agentensammlung

Führe einen Agenten nur ein, wo unabhängiger Kontext, Tools, Autorität, Bewertung, Skalierung oder Fehlerisolierung dies rechtfertigen. Verwende andernfalls deterministischen Code, einen Dienst, einen Workflow-Schritt oder eine menschliche Entscheidung.

Gib jeder Agenten-/Dienst-/Menschenrolle einen Vertrag: Zweck, Auslöser, Eingaben, erlaubte Daten und Tools, Entscheidungsautorität, Ausgaben, Zustand, Übergaben, Timeout-/Fehlerverhalten, Bewertung und Eigentümer. Markiere zirkuläre Übergaben, duplizierte Autorität, versteckten gemeinsamen Zustand und nicht zugeordnete Ergebnisse.

6. Fordere Vollständigkeit heraus

Führe die relevanten Coverage-Pässe aus der Referenz durch. Mindestens:

• Verfolge jede primäre Journey zu Fähigkeiten und Systemeigentümern.
• Verfolge jede wichtige Entscheidung zu Mandatsautorität, Beweisen und Prüfbarkeit.
• Verfolge erfasste Daten zu Zustimmung, Herkunft, Aufbewahrung, Konsumenten, Analyse und Löschung.
• Verfolge Happy Paths, behebbare Fehler, nicht behebbare Fehler und menschliche Eskalation.
• Überprüfe Mandantenisolierung, Berechtigungen, Beobachtbarkeit, Versionierung, Rollback, Kosten und betriebliches Eigentum.
• Trenne Startanforderungen von späterer Erweiterbarkeit; tarne Spekulation nicht als MVP-Umfang.

Liefere das Ergebnis

Führe mit dem klarsten aktuellen Modell und der folgenreichsten Entscheidung. Verwende die kleinste nützliche Mischung aus Prosa, Tabellen, Diagrammen und Listen.

Für eine Gesamtsystemanfrage normalerweise bereitstellen:

1. Produkt-Rückgrat und Umfang.
2. End-to-End-Journey- und Fähigkeitskarte.
3. Systemebenen und wichtige Grenzen.
4. Mandats- und Datenarchitektur.
5. Agenten-/Dienst-/Menschen-Betriebsmodell.
6. Kritische übergreifende Anforderungen und Fehlerpfade.
7. Entscheidungen, Annahmen, Unbekannte und Widersprüche.
8. Sequenzierte Lieferpakete und unabhängig zuweisbare Arbeitspakete.

Jedes Arbeitspaket sollte sein Ergebnis, Abhängigkeiten, Eigentümertyp, betroffene Schnittstellen, Abnahmenachweise und noch zu treffende Entscheidungen nennen. Erzeuge keine Agenten nur, weil die Architektur sie nennt; delegiere nur, wenn der Benutzer nach Ausführung oder Agentenarbeit fragt.

Wenn du ein lebendes Architektur-Artefakt pflegst, aktualisiere die bestehende Quelle der Wahrheit, anstatt ein konkurrierendes Dokument zu erstellen. Bewahre den Entscheidungsverlauf und zeige, was sich geändert hat. Halte das Artefakt im Projekt des Benutzers, nicht innerhalb dieses Skill-Pakets; wenn keine Datei geschrieben werden kann, gib das vollständige Artefakt als kopierbaren Text aus.

Abschlusscheck

Überprüfe vor dem Abschluss, ob das Ergebnis:

1. Beantwortet, wie das Produkt Wert schafft, nicht nur, wie Komponenten verbunden sind.
2. Aktuelle Beweise von Empfehlungen trennt.
3. Jede kritische Journey und Entscheidung Ende-zu-Ende nachvollziehbar macht.
4. Sinnvolle Lücken offenlegt, anstatt unmögliche Sicherheit zu beanspruchen.
5. Mit Entscheidungen oder ausführbaren nächsten Arbeiten endet, nicht mit Architekturtheater.