treatment-backend-planner

Treatment Backend Planner

Dies ist ein Planungs-Skill, das für Codex, OpenCode und Claude Code bereitgestellt wird. Erstelle einen handlungsorientierten Entwurf basierend auf überprüften Repository-Evidenzen; ändere im Planungsmodus keinen Anwendungscode und führe keine Migrationen aus, es sei denn, es wird explizit angefordert.

Kontext entdecken und verifizieren

1. Identifiziere das angeforderte Ergebnis, die Akzeptanzkriterien, den Arbeitsbranch, den Zielbranch (falls relevant) und die vorgesehene Bereitstellungsumgebung. Gehe nicht von Branch-Namen wie production oder development aus. Überprüfe git status und Refs, bevor du Vergleiche anstellst. Überschreibe niemals uncommittete Arbeit.
2. Lies die relevanten vorhandenen Produkt-/Geschäftsdokumente (Persisch) und technischen/Qualitätsdokumente (Englisch), wenn verfügbar. Wenn sie fehlen, kennzeichne genau, welche Dokumentation fehlt; erfinde keine Geschäftsanforderungen.
3. Wenn Graphify installiert ist und ein geeigneter aktueller Graph verfügbar ist, verwende optional graphify query, path oder explain zur Orientierung; erfordere Graphify niemals. Wenn Graphify nicht verfügbar oder veraltet ist, durchsuche direkt die relevanten Quellen, Migrationen, Einstellungen und Tests. Behandle Graphen als Hinweise, nicht als Belege.
4. Verifiziere Klassen, Aufrufstellen, Berechtigungen, Datenflüsse, Konfiguration, Datenbank-Constraints und externe Abhängigkeiten im tatsächlichen Quellcode.
5. Bestimme die Python-/Django-/Laufzeitversionen aus der aktiven Projektkonfiguration und den Lock-Dateien. Melde Inkonsistenzen; hardcode keine historischen Framework-Versionen.
6. Verwende für Branch-Vergleiche die tatsächlich benutzerspezifizierten Quell- und Ziel-Refs; unterscheide Commit-Historie von Arbeitsverzeichnis-Änderungen. Hole keine entfernten Refs ohne Berücksichtigung der Benutzerautorisierung/Netzwerkverfügbarkeit.

Architektur- und Änderungsauswirkungs-Review

• Identifiziere die zugehörige App und die Grenzen; vermeide unnötige Abstraktionen oder appübergreifende Kopplungen. Wende SOLID und saubere Schichtung pragmatisch an, nicht mechanisch.
• Verifiziere öffentliche API-Verträge (Routen, Serializer, Feldtypen, Status-/Fehlerformate, Paginierung, Filterung), Kompatibilität mit Frontend/PWA sowie Authentifizierung/Autorisierung/Mandantenisolierung.
• Analysiere ORM-Abfragekosten, N+1, Transaktionen und Locks, Constraints, Nebenläufigkeit, Datenkonsistenz, Migrationsreihenfolge und Rückgängigmachbarkeit.
• Berücksichtige asynchrone und externe Effekte (Celery-Wiederholungen und Idempotenz, transaction.on_commit, Cache-Invalidierung, Elasticsearch/Index-Synchronisation, HTTP-Timeouts und Fehler, SMS-Gateways).
• Analysiere Beobachtbarkeit, Sicherheit und Secrets, Betrieb, Rollout, Rollback, Feature-Flags und Bereitstellungsreihenfolge, soweit relevant.
• Trenne klar zwischen überprüftem aktuellen Verhalten, dokumentiertem beabsichtigtem Verhalten, vorgeschlagener Änderung und offenen Fragen. Identifiziere eindeutig etwaige Abweichungen.
• Berücksichtige Testbarkeit und vorhandene Testinfrastruktur; kein realer Drittanbieter-/SMS-/Celery-Versand in routinemäßigen automatisierten Tests.

Erforderliche Ausgabe

Erstelle einen entscheidungsreifen Plan mit:

1. Umfang, Ziel, Einschränkungen und Akzeptanzkriterien.
2. Belegen und relevanten Quellpfaden sowie Quell-/Zielrevision, falls verwendet.
3. Aktueller Architektur/Datenfluss und vorgeschlagener Architektur/Datenfluss mit Zuordnung der Komponenten.
4. Geordneten Implementierungsschritten, betroffenen öffentlichen Schnittstellen und Kompatibilitätsmaßnahmen.
5. Migrations-/Backfill-Strategie, Fehlerbehandlung, Beobachtbarkeit, Rollout und Rollback (falls zutreffend).
6. Expliziten Unit-/Integrations-/API-/E2E-/Smoke (FireTest)-, Migrations-, Sicherheits- und Leistungsszenarien, proportional zum Risiko.
7. Erforderlichen Dokumentationsaktualisierungen und betroffenen Dokumentationsseiten.
8. Unsicherheiten, Annahmen, Kompromissen und blockierten Entscheidungen; stelle gezielte Fragen nur bei Bedarf.

Skill-Kollaboration

• Wenn treatment-django-engineer dieses Skill aufruft, gib zuerst den Plan zurück; der Engineer ist für Implementierung, Integration und Endberichterstattung verantwortlich.
• Empfehle django-product-documentation, um die betroffene Dokumentation zu aktualisieren, und treatment-backend-testing, um Tests zu implementieren, aber behaupte nicht, dass diese Skills ausgeführt wurden, es sei denn, sie wurden gefunden und tatsächlich aufgerufen/gelesen.
• Wenn ein abhängiges Skill fehlt, dokumentiere die fehlende Abhängigkeit und biete einen nutzbaren Ersatzplan an, ohne seine Regeln zu erfinden.
• Dieses Skill wird nicht automatisch bei jeder trivialen Tippfehler- oder Formatierungsänderung ausgeführt; passe den Planungsaufwand an die Auswirkungen an.

Unverhandelbare Sicherheitsvorkehrungen

Erfinde niemals Bereichsrichtlinien, Datenmodelle, undokumentiertes API-Verhalten oder Testergebnisse. Keine stillen destruktiven Datenbankoperationen, Commits, Bereitstellungen oder Änderungen an nicht zusammenhängenden Dateien. Behaupte keine Abdeckung, Build-, Migrations- oder Integrationserfolge, ohne sie auszuführen und zu messen.