felipevale23/sddkit

/sdd-stack

Eingabe: $ARGUMENTS. Sie führen ein Interview über den Stack und schreiben Dateien erst am Ende, nachdem der Benutzer die Zusammenfassung bestätigt hat.

0. Vor dem Fragen: Fakten ermitteln

Umgebungsfakten sind Ihre Aufgabe, nie eine Frage an den Benutzer. Sehen Sie nach (oder delegieren Sie an einen Unteragenten):

• Manifeste und vorhandenen Code (package.json, pyproject.toml, go.mod, Dockerfile, .github/workflows/, Verzeichnisstruktur);
• .agents/specs/stack.md und architecture.md (falls bereits ausgefüllt und kein --revisieren, zeigen Sie die Zusammenfassung und fragen Sie nur nach dem Fehlenden);
• .specify/memory/constitution.md (bereits getroffene Entscheidungen, z. B. DSGVO, einzelne Datenbank);
• sddkit suggest --json (erkannte Stacks).

Was bereits im Code festgelegt ist, gilt als getroffene Entscheidung, nicht als Frage.

1. Methode

• Skill grilling installiert in .agents/skills/ → folgen Sie seiner Methode (Runden entlang der Grenze des Entscheidungsbaums, jede Frage mit empfohlener Antwort, bis die Grenze leer ist).
• Nicht installiert → gleiches Format: in jeder Runde alle Fragen, deren Vorbedingungen bereits beantwortet sind, nummeriert, jede so:

❓ **Q1 — <Titel>**: <Frage mit 2–4 Optionen und dem Trade-off jeder Option in 1 Zeile>

➡️ <Ihre Empfehlung und das Warum, in 1–2 Zeilen>

Schreiben Sie jede Frage so, dass „ja“ die Empfehlung akzeptiert. Bevorzugen Sie langweilige und ausgereifte Technologie, die das Team bereits kennt, gegenüber dem State of the Art; eine Sprache für das gesamte Projekt, sofern kein starker Grund dagegen spricht; die geringste Anzahl an Komponenten, die den Umfang abdeckt (jeder zusätzliche Service bedeutet Betriebskosten). Wenn die Antwort einer vorherigen oder der Verfassung widerspricht, weisen Sie darauf hin und fragen Sie, welche gilt.

2. Entscheidungsbaum des Stacks

Gehen Sie in dieser Abhängigkeitsreihenfolge vor; überspringen Sie Zweige, die nicht zutreffen (z. B. ohne UI → keine Frontend-Fragen).

1. Produkt: was es ist (Web-App, API, mobile App, Desktop, CLI, Bibliothek, Worker), wer es nutzt, erwartete Skalierung (Benutzer, Daten, Spitzen), Einschränkungen (DSGVO, offline, Kosten, Termin).
2. Team: Sprachen, die das Team beherrscht; wer wird warten.
3. Form: monolithisch modular, Monorepo mit Paketen oder getrennten Diensten; was asynchron sein muss.
4. Sprache und Laufzeitumgebung (Hauptversion): z. B. TypeScript/Node 22, Python 3.12.
5. Frontend (falls UI vorhanden): Framework (React/Next, Vue/Nuxt, Svelte, Astro…), Rendering (SPA, SSR, statisch), Komponentenbibliothek und Style (MUI, shadcn+Tailwind…), Server-Status (TanStack Query…), i18n, Barrierefreiheit.
6. Mobil/Desktop (falls vorhanden): nativ, React Native/Expo, Flutter, Tauri, Electron.
7. Backend/API: Framework (Express, Fastify, NestJS, Hono, FastAPI, Django…), Stil (REST, GraphQL, tRPC), Verträge und Validierung (Zod, Pydantic, OpenAPI). 7b. Paradigma des Backends (nur wenn Backend vorhanden; niemals für das Frontend, das der Framework-Sprache folgt):
   • Stil: OOP mit SOLID (Entitäten mit Invarianten, Dienste abhängig von Schnittstellen), funktional (reine Funktionen, unveränderliche Daten, Effekte an den Rändern) oder pragmatisch (einfache Module, Abstraktion nur bei 2+ Implementierungen – der Standard von ponytail).
   • Architektur: einfache Schichten (Controller → Service → Repository), Clean/Hexagonal (Domain ohne Framework-Abhängigkeit, Ports und Adapter) oder DDD (Bounded Contexts, Aggregate). Empfehlen Sie das Einfachste, das die Domäne aushält: Clean/DDD nur bei reichen Geschäftsregeln.
   • Welche Ordner sind Backend (z. B. server/**, services/**, modules/**). Dadurch wird das Paradigma auf das Backend beschränkt.
8. Daten: Datenbank (PostgreSQL, MySQL, MongoDB, SQLite), ORM/Zugriff (Prisma, Drizzle, SQLAlchemy…), Migrationen, Cache.
9. Asynchron: Warteschlange/Jobs (BullMQ, Celery, pg-boss…), Ereignisse, Echtzeit (WebSocket/SSE).
10. Authentifizierung und Autorisierung: Anbieter oder eigen, Sessions/JWT, Rollen/Berechtigungen.
11. Externe Integrationen: Zahlungen (PIX…), E-Mail, KI (Anthropic SDK…), MCP.
12. Hosting und Betrieb: wo es läuft (Vercel, VPS mit Docker, verwaltete Cloud), Umgebungen, Geheimnisse, Observability (Logs, Fehler, Metriken).
13. Qualität: Tests (Unit, Integration, e2e mit Playwright), Lint/Format, Typecheck, CI (GitHub Actions), Commits (Conventional Commits/commitlint).

3. Bestätigung

Wenn die Grenze leer ist, zeigen Sie die Zusammenfassung in einer Tabelle (Schicht · Auswahl · Version · Warum · Verworfene Alternative) und fragen Sie: „Schließen wir so ab?“. Schreiben Sie nichts vor dem „Ja“.

4. Speichern

1. .agents/specs/stack.md: Ersetzen Sie den Inhalt (einschließlich des Markers [AUSFÜLLEN]) durch:
   • ## Pro Komponente — jede Schicht mit Technologie, Hauptversion und den wichtigsten Bibliotheken mit Paketnamen (z. B. react, @prisma/client, bullmq, fastapi): sddkit verwendet diese Namen, um Rollen und Skills vorzuschlagen;
   • ## Infrastruktur — Datenbank, Warteschlange, Cache, Hosting, CI, Observability;
   • ## Entscheidungen — jede relevante Wahl mit Begründung und verworfener Alternative (heutiges Datum).
2. .agents/specs/architecture.md: Füllen Sie den Abschnitt ## Übersicht aus (Komponenten und wie sie kommunizieren; ein Mermaid-Diagramm, wenn mehr als 2 Teile vorhanden) und entfernen Sie [AUSFÜLLEN]. Falls bereits Code vorhanden ist, füllen Sie auch ## Code-Landkarte aus (eine Zeile pro Bereich: Eingabe, Hauptordner, Tests). Die übrigen Abschnitte bleiben für später, wenn Code vorhanden ist.
3. Paradigma des Backends (falls in 7b entschieden und nicht „pragmatisch“):
   • .agents/specs/coding-standards.md: Abschnitt ## Backend — Paradigma mit Stil, Architektur, Backend-Ordnern, 3–5 konkreten Regeln mit je einem kurzen Beispiel und dem Werkzeug, das die Regeln durchsetzt (unten). Machen Sie deutlich, dass das Frontend nicht diesem Abschnitt folgt.
   • Speicher für sddkit, damit der Agent den Gültigkeitsbereich in jeder Sitzung kennt:

     sddkit memory add "Paradigma <Stil>/<Architektur> nur im Backend (<Ordner>); im Frontend folgen Sie der Framework-Sprache" -t paradigma
     sddkit memory add "Im Backend überschreibt der Abschnitt 'Backend — Paradigma' aus coding-standards.md das ponytail bezüglich Schnittstellen und Schichten" -t paradigma
     sddkit memory add "<wichtigste konkrete Regel>" -t paradigma-backend --paths "<Backend-Ordner>"
     

   • Skills (optional im Katalog, nur von den Backend-Rollen api, data, event-module, queue-worker geladen): OOP/SOLID → sddkit add solid; Clean/Hexagonal → sddkit add clean-architecture; DDD → sddkit add domain-driven-design. Funktional: es gibt kein allgemein gutes Skill; die Regeln in coding-standards.md und der Lint übernehmen.
   • Deterministische Durchsetzung (Lint beschränkt auf Backend-Ordner; wird die erste Setup-Aufgabe von /sdd-feature, falls noch kein Code vorhanden):
     • Schichten/Clean/Hexagonal/DDD: dependency-cruiser oder eslint-plugin-boundaries (TypeScript), import-linter (Python) – die Domäne importiert weder Infrastruktur noch Framework;
     • funktional in TypeScript: eslint-plugin-functional in einem ESLint-Block mit files: ["<Backend-Ordner>"] (keine Klassen, keine Mutation, kein let);
     • OOP: es gibt keinen Linter, der OOP erzwingt; verwenden Sie die Regeln für Schichten von oben und die Code-Review.
4. Verfassung: Falls unverhandelbare Einschränkungen aufgetaucht sind (z. B. „PostgreSQL ist die einzige Quelle der Wahrheit“), schlagen Sie den Text vor und empfehlen Sie /speckit-constitution – bearbeiten Sie die Verfassung nicht direkt.
5. Sagen Sie dem Benutzer, im Terminal auszuführen:

   sddkit init        # liest den deklarierten Stack und bietet Rollen und Skills dafür an (nichts Vorhandenes wird gelöscht)
   sddkit doctor
   

Abschlussbericht (≤ 8 Zeilen)

Stack entschieden, 1 Zeile pro Schicht · Paradigma des Backends und seine Durchsetzung · geschriebene Dateien · vorgeschlagene Einschränkungen für die Verfassung · nächster Schritt (sddkit init, dann /sdd-feature).