docs: update requirements v4 – KI simplified to OpenAI-compatible endpoint, Q-15/Q-16 resolved, no local model deployment
This commit is contained in:
Agent Zero
+43
-43
@@ -2,8 +2,8 @@
|
||||
|
||||
**Project:** web-cad – Web-basiertes 2D-CAD für Event-Bestuhlungspläne
|
||||
**Phase:** 1 (Intake)
|
||||
**Date:** 2026-06-19 (updated v3)
|
||||
**Status:** Draft v3 – ready for user review
|
||||
**Date:** 2026-06-19 (updated v4)
|
||||
**Status:** Draft v4 – ready for user review
|
||||
|
||||
---
|
||||
|
||||
@@ -179,8 +179,8 @@ Das Ziel von **web-cad** ist eine web-basierte 2D-CAD-Anwendung, die:
|
||||
| F-AI-09 | **Mehrschritt-Operationen:** Der KI Copilot kann komplexe, mehrschrittige Operationen ausführen (z. B. "Erstelle einen rechteckigen Raum 20x30m und bestuhle ihn mit 10 Reihen à 15 Stühlen") | KI führt alle Teilschritte korrekt aus; Zwischenergebnisse sind sichtbar; Gesamtoperation ist korrekt |
|
||||
| F-AI-10 | **Fehlerbehandlung & Feedback:** Der KI Copilot gibt klare Fehlermeldungen bei missverständlichen oder nicht ausführbaren Anweisungen und fragt nach | KI gibt verständliche Fehlermeldungen; fragt bei Mehrdeutigkeit nach; schlägt Alternativen vor |
|
||||
| F-AI-11 | **Undo für KI-Operationen:** Alle KI-gesteuerten Operationen können rückgängig gemacht werden | KI-Operationen appearieren in der Undo-Historie; können einzeln oder als Gruppe rückgängig gemacht werden |
|
||||
| F-AI-12 | **KI-Modell konfigurierbar:** Das verwendete KI-Modell kann vom Admin konfiguriert werden (lokal oder remote, Modell-Auswahl) | Admin kann KI-Backend in Einstellungen konfigurieren; Wechsel zwischen lokal/remote ist möglich |
|
||||
| F-AI-13 | **Open-Source KI-Backend:** KI-Backend verwendet Open-Source-Modelle/APIs (Ollama, vLLM, llama.cpp mit Llama/Qwen/DeepSeek-Modellen) | KI funktioniert mit Open-Source-Modellen; keine proprietäre Abhängigkeit |
|
||||
| F-AI-12 | **KI-Modell konfigurierbar:** Das verwendete KI-Modell kann vom Admin über eine OpenAI-kompatible API-URL und API-Key konfiguriert werden (base_url + api_key in Settings) | Admin kann API-URL und API-Key in Einstellungen eintragen; KI-Backend ist nach Konfiguration funktionsfähig |
|
||||
| F-AI-13 | **OpenAI-kompatibler Endpoint:** KI wird über einen OpenAI-kompatiblen API-Endpoint angebunden – funktioniert mit OpenAI, OpenRouter, Ollama (OpenAI-Compat-Modus), vLLM (OpenAI-Compat-Modus) etc. | KI funktioniert mit jedem OpenAI-kompatiblen Endpoint; kein lokales Modell-Deployment nötig; User bringt eigenen Endpoint mit |
|
||||
| F-AI-14 | **Function Calling / Tool Use:** KI-Backend verwendet Function Calling / Tool Use Pattern – CAD-Operationen sind als Functions registriert, die das LLM aufrufen kann | LLM generiert Function Calls; Functions werden ausgeführt; Ergebnisse an LLM zurückgegeben; CAD-Zustand aktualisiert |
|
||||
| F-AI-15 | **Sicherheits-Guardrails:** KI Copilot kann keine destruktiven Operationen ohne Bestätigung ausführen (z. B. "Lösche alles") | Destruktive Befehle erfordern Bestätigung; Safety-Checks sind implementiert |
|
||||
|
||||
@@ -233,22 +233,22 @@ Basierend auf Recherche (Stand 2025/2026). Alle Empfehlungen verwenden **ausschl
|
||||
| **Persistenz** | Server-seitige Persistenz der CRDT-Dokumente | Single Source of Truth; Versionshistorie; Offline-Sync bei Reconnect | y-leveldb (MIT), IndexedDB client-side |
|
||||
| **Skalierung** | WebSocket-Server mit Pub/Sub pro Raum (Zeichnung) | Mehrere Zeichnungen parallel; isolierte Räume; horizontale Skalierung möglich | Redis Pub/Sub (BSD) für Multi-Server-Skalierung |
|
||||
|
||||
### 4.4 KI-Copilot-Architektur (Open Source)
|
||||
### 4.4 KI-Copilot-Architektur (OpenAI-kompatibler Endpoint)
|
||||
|
||||
| Aspekt | Empfehlung | Begründung | Open-Source-Verfügbarkeit |
|
||||
|---|---|---|---|
|
||||
| **KI-Backend** | Ollama (MIT) oder vLLM (Apache-2.0) als lokaler Model-Server | Läuft auf eigenem Server; keine Cloud-Abhängigkeit; volle Kontrolle | Ollama (MIT), vLLM (Apache-2.0) |
|
||||
| **KI-Modelle** | Llama 3/4 (Llama License), Qwen 2.5 (Apache-2.0), DeepSeek (MIT) | Open-Source LLMs mit Function-Calling-Unterstützung | Verschiedene OSS-Modelle verfügbar |
|
||||
| **Function Calling** | LLM Function Calling / Tool Use Pattern | CAD-Operationen werden als Functions registriert; LLM ruft Functions auf; Ergebnisse zurück an LLM | Standard-Pattern, framework-unabhängig |
|
||||
| **KI-Transport** | REST-API oder WebSocket zwischen Frontend und KI-Backend | Frontend sendet KI-Anfrage; Backend leitet an LLM weiter; LLM generiert Function Calls; Backend führt aus | Express/Fastify (MIT) oder FastAPI (MIT) |
|
||||
| **CAD-Function-Registry** | Zentrales Verzeichnis aller CAD-Operationen als aufrufbare Functions | LLM kann nur registrierte Functions aufrufen;安全; erweiterbar durch Plugins | Custom Implementation (MIT) |
|
||||
| **Context Injection** | Aktueller CAD-Zustand (Zeichnung, Selektion, Layer, Zoom) wird als Context an LLM gesendet | LLM hat Kontext; kann kontextbezogene Antworten geben | Custom Implementation |
|
||||
| **Guardrails** | Safety-Layer für destruktive Operationen | Verhindert ungewolltes Löschen; erfordert Bestätigung | Custom Implementation |
|
||||
| Aspekt | Empfehlung | Begründung |
|
||||
|---|---|---|
|
||||
| **KI-Anbindung** | OpenAI-kompatibler API-Endpoint (user-provided) | User bringt eigenen Endpoint mit (OpenAI, OpenRouter, Ollama OpenAI-Compat, vLLM OpenAI-Compat, etc.); kein lokales Modell-Deployment nötig |
|
||||
| **Konfiguration** | base_url + api_key in Admin-Settings | Admin trägt API-URL und API-Key ein; KI ist nach Konfiguration sofort funktionsfähig |
|
||||
| **Function Calling** | LLM Function Calling / Tool Use Pattern | CAD-Operationen werden als Functions registriert; LLM ruft Functions auf; Ergebnisse zurück an LLM |
|
||||
| **KI-Transport** | Backend leitet KI-Anfragen an konfigurierten OpenAI-kompatiblen Endpoint weiter | Frontend sendet KI-Anfrage an CAD-Backend; Backend leitet an externen API-Endpoint weiter; LLM generiert Function Calls; Backend führt aus |
|
||||
| **CAD-Function-Registry** | Zentrales Verzeichnis aller CAD-Operationen als aufrufbare Functions | LLM kann nur registrierte Functions aufrufen; sicher; erweiterbar durch Plugins |
|
||||
| **Context Injection** | Aktueller CAD-Zustand (Zeichnung, Selektion, Layer, Zoom) wird als Context an LLM gesendet | LLM hat Kontext; kann kontextbezogene Antworten geben |
|
||||
| **Guardrails** | Safety-Layer für destruktive Operationen | Verhindert ungewolltes Löschen; erfordert Bestätigung |
|
||||
|
||||
**Architektur-Pattern:**
|
||||
```
|
||||
User Input (Text/Sprache)
|
||||
→ KI-Backend (Ollama/vLLM)
|
||||
→ CAD-Backend leitet an OpenAI-kompatiblen API-Endpoint weiter
|
||||
→ LLM generiert Function Call (z. B. draw_line(x1, y1, x2, y2))
|
||||
→ CAD-Function-Registry führt Function aus
|
||||
→ Canvas aktualisiert sich
|
||||
@@ -265,7 +265,7 @@ User Input (Text/Sprache)
|
||||
| NF-OSS-03 | **Lizenz-Kompatibilität:** Alle Abhängigkeiten sind untereinander lizenzkompatibel | Lizenz-Kompatibilitätsanalyse durchgeführt; keine Konflikte |
|
||||
| NF-OSS-04 | **DXF-Bibliothek:** Open-Source DXF-Parser/Writer verwenden (z. B. dxf-parser, dxf-writer in JS oder Rust) | DXF-Import/Export funktioniert mit Open-Source-Library |
|
||||
| NF-OSS-05 | **DWG-Bibliothek (Optional):** Falls DWG-Import unterstützt wird, Open-Source-Library verwenden (z. B. libredwg, GNU GPL) | DWG-Import funktioniert mit Open-Source-Library; keine kommerziellen Bibliotheken |
|
||||
| NF-OSS-06 | **KI-Modelle:** Verwendete KI-Modelle sind Open Source (Llama, Qwen, DeepSeek etc.) | Keine proprietären KI-APIs als Abhängigkeit; lokale Modelle möglich |
|
||||
| NF-OSS-06 | **KI-Anbindung offen:** KI wird über einen OpenAI-kompatiblen API-Endpoint angebunden; kein proprietäres KI-Modell fest codiert | Jeder OpenAI-kompatible Endpoint funktioniert (OpenAI, OpenRouter, Ollama, vLLM); User wählt seinen eigenen Provider |
|
||||
|
||||
### 4.6 Sicherheit
|
||||
|
||||
@@ -285,7 +285,7 @@ User Input (Text/Sprache)
|
||||
| NF-DEP-02 | **Coolify-Deployment:** Deployment via Coolify ist möglich | Coolify-kompatible Konfiguration vorhanden; Deployment-Dokumentation erstellt |
|
||||
| NF-DEP-03 | **Umgebungs-Konfiguration:** Konfiguration über Umgebungsvariablen | Keine fest codierten Credentials; alle Secrets über Env-Variablen |
|
||||
| NF-DEP-04 | **Datenbank:** SQLite als Standard-Datenbank (entschieden, siehe Q-03); Datenbank-Schicht ist abstrahiert für spätere Migration | SQLite funktioniert; Schema definiert; Migration zu PostgreSQL möglich |
|
||||
| NF-DEP-05 | **KI-Backend-Deployment:** KI-Backend (Ollama/vLLM) läuft als separater Container | KI-Backend ist in docker-compose.yml definiert; Kommunikation mit CAD-Backend funktioniert |
|
||||
| NF-DEP-05 | **KI-Anbindung:** KI wird über externen OpenAI-kompatiblen API-Endpoint angebunden – kein separater KI-Container nötig | KI-API-URL und API-Key werden über Umgebungsvariablen konfiguriert; keine lokale KI-Infrastruktur erforderlich |
|
||||
|
||||
### 4.8 Plattform & Browser-Kompatibilität
|
||||
|
||||
@@ -314,7 +314,7 @@ User Input (Text/Sprache)
|
||||
13. **SQLite als Standard-Datenbank:** SQLite wird als Standard-Datenbank verwendet; Datenbank-Schicht ist abstrahiert für spätere Migration zu PostgreSQL/MySQL.
|
||||
14. **API-First-Design:** Die Software ist API-first designed; das Backend ist ein API-Server, die UI ist ein API-Client. Dadurch ist die Software an andere Systeme anhängbar.
|
||||
15. **KI Copilot als Kern-Feature:** Der KI Copilot ist von Anfang an in die Core-Architektur integriert – kein Afterthought. CAD-Operationen sind als Functions registriert, die vom LLM aufgerufen werden können.
|
||||
16. **Open-Source KI-Backend:** KI-Backend verwendet Open-Source-Modelle (Llama, Qwen, DeepSeek) via Ollama oder vLLM; keine proprietären KI-APIs als Abhängigkeit.
|
||||
16. **OpenAI-kompatibler KI-Endpoint:** KI wird über einen OpenAI-kompatiblen API-Endpoint angebunden (user-provided); kein lokales Modell-Deployment. User bringt eigenen Endpoint mit (OpenAI, OpenRouter, Ollama OpenAI-Compat, vLLM OpenAI-Compat, etc.).
|
||||
17. **Function Calling als KI-Pattern:** Das LLM verwendet Function Calling / Tool Use, um CAD-Operationen auszulösen. Das LLM generiert keine direkten Canvas-Befehle, sondern ruft registrierte Functions auf.
|
||||
18. **Modularität:** Core, Plugins, KI-Backend und UI sind lose gekoppelte Module mit definierten Schnittstellen.
|
||||
|
||||
@@ -349,6 +349,8 @@ User Input (Text/Sprache)
|
||||
| Q-01 | Soll die Anwendung Open Source oder Closed Source sein? Welche Lizenz? | Open Source | ✅ **Entschieden:** Software wird als Open Source lizenziert (AGPL-3.0 empfohlen für Copyleft-Schutz, MIT als Alternative). Nur komplett offene Komponenten werden verwendet. |
|
||||
| Q-02 | Welche Authentifizierungsmethode wird bevorzugt? | E-Mail/Passwort | ✅ **Entschieden:** E-Mail/Passwort als Authentifizierung. Keine OAuth2/OIDC/SSO in der initialen Version. SSO kann später als Plugin nachgerüstet werden. |
|
||||
| Q-03 | Welche Datenbank soll verwendet werden? | SQLite | ✅ **Entschieden:** SQLite als Standard-Datenbank. Datenbank-Schicht ist abstrahiert für spätere Migration. Software ist API-first/modular designed für Integration mit anderer Software. |
|
||||
| Q-15 | Soll das KI-Backend lokal oder remote laufen? | Remote (OpenAI-kompatibel) | ✅ **Entschieden:** KI wird remote über einen OpenAI-kompatiblen API-Endpoint angebunden. Kein lokales Modell-Deployment (kein Ollama, kein vLLM lokal). User bringt eigenen Endpoint mit. |
|
||||
| Q-16 | Welche KI-Modellgröße ist akzeptabel? | User-Sache | ✅ **Entschieden:** Modellgröße ist nicht unsere Concern – der User bringt seinen eigenen Endpoint mit. Wir binden nur einen OpenAI-kompatiblen API-Call ein. |
|
||||
|
||||
---
|
||||
|
||||
@@ -367,8 +369,6 @@ User Input (Text/Sprache)
|
||||
| Q-12 | Welche Maßeinheiten sollen unterstützt werden (metrisch, imperial, beides)? | Niedrig | Bemaßungs-Logic, UI |
|
||||
| Q-13 | AGPL-3.0 oder MIT als Lizenz? | Niedrig | Lizenz-Datei, Copyleft vs. Permissive |
|
||||
| Q-14 | Soll der KI Copilot Spracheingabe (Voice) von Anfang an unterstützen oder erst später? | Niedrig | UI-Design, Web Speech API Integration |
|
||||
| Q-15 | Soll das KI-Backend lokal (Ollama auf Server) oder remote (externer API-Provider) laufen? | Mittel | Deployment-Architektur, Performance, Kosten |
|
||||
| Q-16 | Welche KI-Modellgröße ist akzeptabel (z. B. 7B, 13B, 70B Parameter)? | Mittel | Performance, Hardware-Anforderungen, Antwortzeit |
|
||||
|
||||
---
|
||||
|
||||
@@ -429,7 +429,7 @@ User Input (Text/Sprache)
|
||||
- **Mehrschritt-Operationen:** Für komplexe Befehle (z. B. "Erstelle einen Raum und bestuhle ihn") kann das LLM eine Sequenz von Function Calls generieren, die nacheinander ausgeführt werden.
|
||||
- **Guardrails / Safety:** Ein Safety-Layer prüft jeden Function Call vor der Ausführung. Destruktive Operationen (Löschen aller Elemente, Überschreiben ganzer Zeichnungen) erfordern explizite User-Bestätigung.
|
||||
|
||||
**Empfehlung:** Ollama (MIT) als KI-Backend mit Qwen 2.5 (Apache-2.0) oder Llama (Llama License) als primäres Modell. Function Calling Pattern mit zentraler CAD-Function-Registry. Context Injection für Kontext-Verständnis. Guardrails für Safety.
|
||||
**Empfehlung:** OpenAI-kompatibler API-Endpoint (user-provided) als KI-Anbindung. Function Calling Pattern mit zentraler CAD-Function-Registry. Context Injection für Kontext-Verständnis. Guardrails für Safety. Kein lokales Modell-Deployment – der User bringt seinen eigenen Endpoint mit (OpenAI, OpenRouter, Ollama OpenAI-Compat, vLLM OpenAI-Compat, etc.).
|
||||
|
||||
**Quellen:**
|
||||
- cadcenterhyderabad.com: AutoCAD 2027 AI Features
|
||||
@@ -455,8 +455,8 @@ User Input (Text/Sprache)
|
||||
| **PDF-Generierung** | pdf-lib (MIT) oder jsPDF (MIT) | MIT |
|
||||
| **SVG-Verarbeitung** | Native Browser-API oder svg.js (MIT) | MIT |
|
||||
| **Auth** | bcrypt (Apache) oder argon2 (MIT/CDDL) | Open Source |
|
||||
| **KI-Backend** | Ollama (MIT) oder vLLM (Apache-2.0) | MIT/Apache |
|
||||
| **KI-Modell** | Qwen 2.5 (Apache-2.0) oder Llama 3/4 (Llama License) oder DeepSeek (MIT) | Open Source |
|
||||
| **KI-Anbindung** | OpenAI-kompatibler API-Endpoint (user-provided) – funktioniert mit OpenAI, OpenRouter, Ollama (OpenAI-Compat), vLLM (OpenAI-Compat) | User-provided |
|
||||
| **KI-Client** | OpenAI SDK (MIT) oder native fetch/axios | MIT |
|
||||
| **API-Dokumentation** | OpenAPI/Swagger (Apache-2.0) | Apache |
|
||||
| **Containerisierung** | Docker (Apache 2.0) | Open Source |
|
||||
| **Deployment** | Coolify (AGPL-3.0) | Open Source |
|
||||
@@ -482,8 +482,8 @@ User Input (Text/Sprache)
|
||||
| Browser-Speicherlimit | Sehr große Projekte können Browser-Speicherlimit überschreiten | Lazy-Loading; Kompression; IndexedDB für Persistenz |
|
||||
| Plugin-System-Komplexität | Universelles Plugin-System kann Core-Stabilität gefährden | Plugin-Isolation (Sandbox/try-catch); Plugin-Manifest mit deklarativen Abhängigkeiten |
|
||||
| KI-Fehlerhafte Befehle | LLM könnte fehlerhafte oder unerwartete Function Calls generieren | Guardrails; Function-Validation vor Ausführung; Bestätigung für destruktive Operationen |
|
||||
| KI-Latenz | LLM-Inferenz kann mehrere Sekunden dauern, besonders auf lokaler Hardware | Streaming-Responses; Fortschrittsanzeige; Modellgröße wählbar (7B für Speed, 70B für Qualität) |
|
||||
| KI-Hardware-Anforderungen | Lokale KI-Modelle benötigen GPU/RAM | Ollama mit quantisierten Modellen (4-bit/8-bit); remote API als Fallback |
|
||||
| KI-Latenz | LLM-Inferenz beim externen API-Provider kann mehrere Sekunden dauern | Streaming-Responses; Fortschrittsanzeige; Timeout-Handling;Fallback auf manuelle Bedienung |
|
||||
| KI-API-Verfügbarkeit | Externer KI-API-Endpoint kann nicht erreichbar sein (Netzwerk, Wartung, Rate-Limit) | Klare Fehlermeldungen; Retry-Logik; CAD bleibt ohne KI voll nutzbar |
|
||||
| KI-Kontext-Größe | CAD-Zustand kann groß sein (viele Elemente); LLM-Context-Limit begrenzt | Context-Summary statt vollständiger Zeichnung; nur relevante Ausschnitte senden |
|
||||
|
||||
---
|
||||
@@ -492,14 +492,14 @@ User Input (Text/Sprache)
|
||||
|
||||
| Aspekt | Erwartung |
|
||||
|---|---|
|
||||
| **Containerisierung** | Docker (Dockerfile + docker-compose.yml) – CAD-Backend, KI-Backend, Frontend |
|
||||
| **Containerisierung** | Docker (Dockerfile + docker-compose.yml) – CAD-Backend + Frontend (2 Container) |
|
||||
| **Orchestrierung** | Coolify auf coolify-01 (46.225.91.159) |
|
||||
| **Domain** | TBD – z. B. cad.media-on.de |
|
||||
| **SSL** | Let's Encrypt via Coolify/Traefik |
|
||||
| **Datenbank** | SQLite (Standard); Datenbank-Schicht abstrahiert für Migration |
|
||||
| **KI-Backend** | Ollama oder vLLM als separater Container; GPU empfohlen (nicht zwingend) |
|
||||
| **KI-Anbindung** | OpenAI-kompatibler API-Endpoint (extern) – kein separater KI-Container; API-URL + API-Key über Umgebungsvariablen |
|
||||
| **WebSocket-Server** | Separater Container oder integriert; WebSocket-Proxy via Traefik |
|
||||
| **Persistenz** | Docker-Volume für Datenbank, Datei-Storage und KI-Modelle |
|
||||
| **Persistenz** | Docker-Volume für Datenbank und Datei-Storage (Grundrisse, Bibliothek) |
|
||||
| **Skalierung** | Initiale Version: Einzelner Server; später horizontal skalierbar |
|
||||
|
||||
---
|
||||
@@ -606,28 +606,28 @@ Basierend auf Recherche (Scan2CAD Review, Autodesk Produktseiten, Softonic Revie
|
||||
## 13. Handoff
|
||||
|
||||
### Requirements Status
|
||||
- **Draft v3 erstellt:** Ja (2026-06-19)
|
||||
- **Entschiedene Fragen:** Q-01 (Open Source) ✅, Q-02 (E-Mail/Passwort) ✅, Q-03 (SQLite + API-first/modular) ✅
|
||||
- **Draft v4 erstellt:** Ja (2026-06-19)
|
||||
- **Entschiedene Fragen:** Q-01 (Open Source) ✅, Q-02 (E-Mail/Passwort) ✅, Q-03 (SQLite + API-first) ✅, Q-15 (Remote/OpenAI-kompatibel) ✅, Q-16 (User-Sache) ✅
|
||||
- **Testbare Anforderungen:** Ja – alle funktionalen und nicht-funktionalen Anforderungen haben konkrete Akzeptanzkriterien
|
||||
- **Akzeptanzkriterien konkret:** Ja
|
||||
- **Assumptions:** 18 dokumentiert (erweitert um KI Copilot, API-First, SQLite, Modularität)
|
||||
- **Non-Goals:** 17 dokumentiert (angepasst – KI ist nun Kern-Feature, kein Non-Goal mehr; autonomes KI-Zeichnen ist Non-Goal)
|
||||
- **Offene Fragen:** 9 (0 hoch, 4 mittel, 5 niedrig priorisiert)
|
||||
- **AutoCAD Web Referenz:** Vollständige Feature-Analyse inkl. Limitierungen und Vergleich (erweitert um KI Copilot und API-First Vergleich)
|
||||
- **Open-Source-Stack:** Vollständiger Stack mit Lizenzen (erweitert um KI-Backend und KI-Modelle)
|
||||
- **KI Copilot:** 15 detaillierte Anforderungen (F-AI-01 bis F-AI-15) mit Function Calling Pattern, Guardrails, Open-Source-Backend
|
||||
- **Assumptions:** 18 dokumentiert (erweitert um OpenAI-kompatiblen KI-Endpoint)
|
||||
- **Non-Goals:** 17 dokumentiert
|
||||
- **Offene Fragen:** 7 (0 hoch, 3 mittel, 4 niedrig priorisiert)
|
||||
- **AutoCAD Web Referenz:** Vollständige Feature-Analyse inkl. Limitierungen und Vergleich
|
||||
- **Open-Source-Stack:** Vollständiger Stack mit Lizenzen (KI-Anbindung: OpenAI-kompatibler Endpoint, user-provided)
|
||||
- **KI Copilot:** 15 detaillierte Anforderungen (F-AI-01 bis F-AI-15) mit Function Calling Pattern, Guardrails, OpenAI-kompatibler Endpoint
|
||||
- **Integration/Modularität:** 8 Anforderungen (F-INT-01 bis F-INT-08) für API-first, REST-API, Webhooks, Headless-Modus
|
||||
- **Plugin-System:** 8 Anforderungen (F-EXT-01 bis F-EXT-08) für universelle Erweiterbarkeit
|
||||
|
||||
### Ready for Architecture
|
||||
- **Ja** – alle hoch-priorisierten Fragen geklärt; Architektur-Phase kann starten
|
||||
- KI-Copilot-Architektur ist als Core-Feature definiert mit Function Calling Pattern
|
||||
- **Ja** – alle hoch- und mittel-priorisierten Fragen geklärt; Architektur-Phase kann starten
|
||||
- KI-Copilot-Architektur: OpenAI-kompatibler API-Endpoint + Function Calling + CAD-Function-Registry
|
||||
- API-First-Design ist als Architektur-Vorgabe definiert
|
||||
- Verbleibende offene Fragen (Q-04 bis Q-16) sind mittel/niedrig priorisiert und können während oder nach der Architektur-Phase geklärt werden
|
||||
- Deployment: 2 Docker-Container (CAD-Backend + Frontend); KI ist externer API-Call
|
||||
- Verbleibende offene Fragen (Q-04 bis Q-14) sind mittel/niedrig priorisiert und können während oder nach der Architektur-Phase geklärt werden
|
||||
- Technologie-Empfehlungen stehen als Architektur-Vorgaben bereit
|
||||
|
||||
### Empfohlene nächste Schritte
|
||||
1. User-Review der aktualisierten requirements.md (v3)
|
||||
2. Optional: Beantwortung von Q-15 (KI lokal vs. remote) und Q-16 (KI-Modellgröße)
|
||||
3. Freigabe für Architektur-Phase (Phase 2)
|
||||
4. Delegation an Solution Architect mit Vorgaben: Open-Source-Stack, KI-Copilot-Function-Calling, API-First, Plugin-System
|
||||
1. User-Review der aktualisierten requirements.md (v4)
|
||||
2. Freigabe für Architektur-Phase (Phase 2)
|
||||
3. Delegation an Solution Architect mit Vorgaben: Open-Source-Stack, KI-Copilot (OpenAI-kompatibler Endpoint + Function Calling), API-First, Plugin-System, 2 Container
|
||||
|
||||
@@ -2,8 +2,8 @@
|
||||
|
||||
**Project:** web-cad – Web-basiertes 2D-CAD für Event-Bestuhlungspläne
|
||||
**Phase:** 1 (Intake)
|
||||
**Date:** 2026-06-19 (updated v3)
|
||||
**Status:** Draft v3 – ready for user review
|
||||
**Date:** 2026-06-19 (updated v4)
|
||||
**Status:** Draft v4 – ready for user review
|
||||
|
||||
---
|
||||
|
||||
@@ -179,8 +179,8 @@ Das Ziel von **web-cad** ist eine web-basierte 2D-CAD-Anwendung, die:
|
||||
| F-AI-09 | **Mehrschritt-Operationen:** Der KI Copilot kann komplexe, mehrschrittige Operationen ausführen (z. B. "Erstelle einen rechteckigen Raum 20x30m und bestuhle ihn mit 10 Reihen à 15 Stühlen") | KI führt alle Teilschritte korrekt aus; Zwischenergebnisse sind sichtbar; Gesamtoperation ist korrekt |
|
||||
| F-AI-10 | **Fehlerbehandlung & Feedback:** Der KI Copilot gibt klare Fehlermeldungen bei missverständlichen oder nicht ausführbaren Anweisungen und fragt nach | KI gibt verständliche Fehlermeldungen; fragt bei Mehrdeutigkeit nach; schlägt Alternativen vor |
|
||||
| F-AI-11 | **Undo für KI-Operationen:** Alle KI-gesteuerten Operationen können rückgängig gemacht werden | KI-Operationen appearieren in der Undo-Historie; können einzeln oder als Gruppe rückgängig gemacht werden |
|
||||
| F-AI-12 | **KI-Modell konfigurierbar:** Das verwendete KI-Modell kann vom Admin konfiguriert werden (lokal oder remote, Modell-Auswahl) | Admin kann KI-Backend in Einstellungen konfigurieren; Wechsel zwischen lokal/remote ist möglich |
|
||||
| F-AI-13 | **Open-Source KI-Backend:** KI-Backend verwendet Open-Source-Modelle/APIs (Ollama, vLLM, llama.cpp mit Llama/Qwen/DeepSeek-Modellen) | KI funktioniert mit Open-Source-Modellen; keine proprietäre Abhängigkeit |
|
||||
| F-AI-12 | **KI-Modell konfigurierbar:** Das verwendete KI-Modell kann vom Admin über eine OpenAI-kompatible API-URL und API-Key konfiguriert werden (base_url + api_key in Settings) | Admin kann API-URL und API-Key in Einstellungen eintragen; KI-Backend ist nach Konfiguration funktionsfähig |
|
||||
| F-AI-13 | **OpenAI-kompatibler Endpoint:** KI wird über einen OpenAI-kompatiblen API-Endpoint angebunden – funktioniert mit OpenAI, OpenRouter, Ollama (OpenAI-Compat-Modus), vLLM (OpenAI-Compat-Modus) etc. | KI funktioniert mit jedem OpenAI-kompatiblen Endpoint; kein lokales Modell-Deployment nötig; User bringt eigenen Endpoint mit |
|
||||
| F-AI-14 | **Function Calling / Tool Use:** KI-Backend verwendet Function Calling / Tool Use Pattern – CAD-Operationen sind als Functions registriert, die das LLM aufrufen kann | LLM generiert Function Calls; Functions werden ausgeführt; Ergebnisse an LLM zurückgegeben; CAD-Zustand aktualisiert |
|
||||
| F-AI-15 | **Sicherheits-Guardrails:** KI Copilot kann keine destruktiven Operationen ohne Bestätigung ausführen (z. B. "Lösche alles") | Destruktive Befehle erfordern Bestätigung; Safety-Checks sind implementiert |
|
||||
|
||||
@@ -233,22 +233,22 @@ Basierend auf Recherche (Stand 2025/2026). Alle Empfehlungen verwenden **ausschl
|
||||
| **Persistenz** | Server-seitige Persistenz der CRDT-Dokumente | Single Source of Truth; Versionshistorie; Offline-Sync bei Reconnect | y-leveldb (MIT), IndexedDB client-side |
|
||||
| **Skalierung** | WebSocket-Server mit Pub/Sub pro Raum (Zeichnung) | Mehrere Zeichnungen parallel; isolierte Räume; horizontale Skalierung möglich | Redis Pub/Sub (BSD) für Multi-Server-Skalierung |
|
||||
|
||||
### 4.4 KI-Copilot-Architektur (Open Source)
|
||||
### 4.4 KI-Copilot-Architektur (OpenAI-kompatibler Endpoint)
|
||||
|
||||
| Aspekt | Empfehlung | Begründung | Open-Source-Verfügbarkeit |
|
||||
|---|---|---|---|
|
||||
| **KI-Backend** | Ollama (MIT) oder vLLM (Apache-2.0) als lokaler Model-Server | Läuft auf eigenem Server; keine Cloud-Abhängigkeit; volle Kontrolle | Ollama (MIT), vLLM (Apache-2.0) |
|
||||
| **KI-Modelle** | Llama 3/4 (Llama License), Qwen 2.5 (Apache-2.0), DeepSeek (MIT) | Open-Source LLMs mit Function-Calling-Unterstützung | Verschiedene OSS-Modelle verfügbar |
|
||||
| **Function Calling** | LLM Function Calling / Tool Use Pattern | CAD-Operationen werden als Functions registriert; LLM ruft Functions auf; Ergebnisse zurück an LLM | Standard-Pattern, framework-unabhängig |
|
||||
| **KI-Transport** | REST-API oder WebSocket zwischen Frontend und KI-Backend | Frontend sendet KI-Anfrage; Backend leitet an LLM weiter; LLM generiert Function Calls; Backend führt aus | Express/Fastify (MIT) oder FastAPI (MIT) |
|
||||
| **CAD-Function-Registry** | Zentrales Verzeichnis aller CAD-Operationen als aufrufbare Functions | LLM kann nur registrierte Functions aufrufen;安全; erweiterbar durch Plugins | Custom Implementation (MIT) |
|
||||
| **Context Injection** | Aktueller CAD-Zustand (Zeichnung, Selektion, Layer, Zoom) wird als Context an LLM gesendet | LLM hat Kontext; kann kontextbezogene Antworten geben | Custom Implementation |
|
||||
| **Guardrails** | Safety-Layer für destruktive Operationen | Verhindert ungewolltes Löschen; erfordert Bestätigung | Custom Implementation |
|
||||
| Aspekt | Empfehlung | Begründung |
|
||||
|---|---|---|
|
||||
| **KI-Anbindung** | OpenAI-kompatibler API-Endpoint (user-provided) | User bringt eigenen Endpoint mit (OpenAI, OpenRouter, Ollama OpenAI-Compat, vLLM OpenAI-Compat, etc.); kein lokales Modell-Deployment nötig |
|
||||
| **Konfiguration** | base_url + api_key in Admin-Settings | Admin trägt API-URL und API-Key ein; KI ist nach Konfiguration sofort funktionsfähig |
|
||||
| **Function Calling** | LLM Function Calling / Tool Use Pattern | CAD-Operationen werden als Functions registriert; LLM ruft Functions auf; Ergebnisse zurück an LLM |
|
||||
| **KI-Transport** | Backend leitet KI-Anfragen an konfigurierten OpenAI-kompatiblen Endpoint weiter | Frontend sendet KI-Anfrage an CAD-Backend; Backend leitet an externen API-Endpoint weiter; LLM generiert Function Calls; Backend führt aus |
|
||||
| **CAD-Function-Registry** | Zentrales Verzeichnis aller CAD-Operationen als aufrufbare Functions | LLM kann nur registrierte Functions aufrufen; sicher; erweiterbar durch Plugins |
|
||||
| **Context Injection** | Aktueller CAD-Zustand (Zeichnung, Selektion, Layer, Zoom) wird als Context an LLM gesendet | LLM hat Kontext; kann kontextbezogene Antworten geben |
|
||||
| **Guardrails** | Safety-Layer für destruktive Operationen | Verhindert ungewolltes Löschen; erfordert Bestätigung |
|
||||
|
||||
**Architektur-Pattern:**
|
||||
```
|
||||
User Input (Text/Sprache)
|
||||
→ KI-Backend (Ollama/vLLM)
|
||||
→ CAD-Backend leitet an OpenAI-kompatiblen API-Endpoint weiter
|
||||
→ LLM generiert Function Call (z. B. draw_line(x1, y1, x2, y2))
|
||||
→ CAD-Function-Registry führt Function aus
|
||||
→ Canvas aktualisiert sich
|
||||
@@ -265,7 +265,7 @@ User Input (Text/Sprache)
|
||||
| NF-OSS-03 | **Lizenz-Kompatibilität:** Alle Abhängigkeiten sind untereinander lizenzkompatibel | Lizenz-Kompatibilitätsanalyse durchgeführt; keine Konflikte |
|
||||
| NF-OSS-04 | **DXF-Bibliothek:** Open-Source DXF-Parser/Writer verwenden (z. B. dxf-parser, dxf-writer in JS oder Rust) | DXF-Import/Export funktioniert mit Open-Source-Library |
|
||||
| NF-OSS-05 | **DWG-Bibliothek (Optional):** Falls DWG-Import unterstützt wird, Open-Source-Library verwenden (z. B. libredwg, GNU GPL) | DWG-Import funktioniert mit Open-Source-Library; keine kommerziellen Bibliotheken |
|
||||
| NF-OSS-06 | **KI-Modelle:** Verwendete KI-Modelle sind Open Source (Llama, Qwen, DeepSeek etc.) | Keine proprietären KI-APIs als Abhängigkeit; lokale Modelle möglich |
|
||||
| NF-OSS-06 | **KI-Anbindung offen:** KI wird über einen OpenAI-kompatiblen API-Endpoint angebunden; kein proprietäres KI-Modell fest codiert | Jeder OpenAI-kompatible Endpoint funktioniert (OpenAI, OpenRouter, Ollama, vLLM); User wählt seinen eigenen Provider |
|
||||
|
||||
### 4.6 Sicherheit
|
||||
|
||||
@@ -285,7 +285,7 @@ User Input (Text/Sprache)
|
||||
| NF-DEP-02 | **Coolify-Deployment:** Deployment via Coolify ist möglich | Coolify-kompatible Konfiguration vorhanden; Deployment-Dokumentation erstellt |
|
||||
| NF-DEP-03 | **Umgebungs-Konfiguration:** Konfiguration über Umgebungsvariablen | Keine fest codierten Credentials; alle Secrets über Env-Variablen |
|
||||
| NF-DEP-04 | **Datenbank:** SQLite als Standard-Datenbank (entschieden, siehe Q-03); Datenbank-Schicht ist abstrahiert für spätere Migration | SQLite funktioniert; Schema definiert; Migration zu PostgreSQL möglich |
|
||||
| NF-DEP-05 | **KI-Backend-Deployment:** KI-Backend (Ollama/vLLM) läuft als separater Container | KI-Backend ist in docker-compose.yml definiert; Kommunikation mit CAD-Backend funktioniert |
|
||||
| NF-DEP-05 | **KI-Anbindung:** KI wird über externen OpenAI-kompatiblen API-Endpoint angebunden – kein separater KI-Container nötig | KI-API-URL und API-Key werden über Umgebungsvariablen konfiguriert; keine lokale KI-Infrastruktur erforderlich |
|
||||
|
||||
### 4.8 Plattform & Browser-Kompatibilität
|
||||
|
||||
@@ -314,7 +314,7 @@ User Input (Text/Sprache)
|
||||
13. **SQLite als Standard-Datenbank:** SQLite wird als Standard-Datenbank verwendet; Datenbank-Schicht ist abstrahiert für spätere Migration zu PostgreSQL/MySQL.
|
||||
14. **API-First-Design:** Die Software ist API-first designed; das Backend ist ein API-Server, die UI ist ein API-Client. Dadurch ist die Software an andere Systeme anhängbar.
|
||||
15. **KI Copilot als Kern-Feature:** Der KI Copilot ist von Anfang an in die Core-Architektur integriert – kein Afterthought. CAD-Operationen sind als Functions registriert, die vom LLM aufgerufen werden können.
|
||||
16. **Open-Source KI-Backend:** KI-Backend verwendet Open-Source-Modelle (Llama, Qwen, DeepSeek) via Ollama oder vLLM; keine proprietären KI-APIs als Abhängigkeit.
|
||||
16. **OpenAI-kompatibler KI-Endpoint:** KI wird über einen OpenAI-kompatiblen API-Endpoint angebunden (user-provided); kein lokales Modell-Deployment. User bringt eigenen Endpoint mit (OpenAI, OpenRouter, Ollama OpenAI-Compat, vLLM OpenAI-Compat, etc.).
|
||||
17. **Function Calling als KI-Pattern:** Das LLM verwendet Function Calling / Tool Use, um CAD-Operationen auszulösen. Das LLM generiert keine direkten Canvas-Befehle, sondern ruft registrierte Functions auf.
|
||||
18. **Modularität:** Core, Plugins, KI-Backend und UI sind lose gekoppelte Module mit definierten Schnittstellen.
|
||||
|
||||
@@ -349,6 +349,8 @@ User Input (Text/Sprache)
|
||||
| Q-01 | Soll die Anwendung Open Source oder Closed Source sein? Welche Lizenz? | Open Source | ✅ **Entschieden:** Software wird als Open Source lizenziert (AGPL-3.0 empfohlen für Copyleft-Schutz, MIT als Alternative). Nur komplett offene Komponenten werden verwendet. |
|
||||
| Q-02 | Welche Authentifizierungsmethode wird bevorzugt? | E-Mail/Passwort | ✅ **Entschieden:** E-Mail/Passwort als Authentifizierung. Keine OAuth2/OIDC/SSO in der initialen Version. SSO kann später als Plugin nachgerüstet werden. |
|
||||
| Q-03 | Welche Datenbank soll verwendet werden? | SQLite | ✅ **Entschieden:** SQLite als Standard-Datenbank. Datenbank-Schicht ist abstrahiert für spätere Migration. Software ist API-first/modular designed für Integration mit anderer Software. |
|
||||
| Q-15 | Soll das KI-Backend lokal oder remote laufen? | Remote (OpenAI-kompatibel) | ✅ **Entschieden:** KI wird remote über einen OpenAI-kompatiblen API-Endpoint angebunden. Kein lokales Modell-Deployment (kein Ollama, kein vLLM lokal). User bringt eigenen Endpoint mit. |
|
||||
| Q-16 | Welche KI-Modellgröße ist akzeptabel? | User-Sache | ✅ **Entschieden:** Modellgröße ist nicht unsere Concern – der User bringt seinen eigenen Endpoint mit. Wir binden nur einen OpenAI-kompatiblen API-Call ein. |
|
||||
|
||||
---
|
||||
|
||||
@@ -367,8 +369,6 @@ User Input (Text/Sprache)
|
||||
| Q-12 | Welche Maßeinheiten sollen unterstützt werden (metrisch, imperial, beides)? | Niedrig | Bemaßungs-Logic, UI |
|
||||
| Q-13 | AGPL-3.0 oder MIT als Lizenz? | Niedrig | Lizenz-Datei, Copyleft vs. Permissive |
|
||||
| Q-14 | Soll der KI Copilot Spracheingabe (Voice) von Anfang an unterstützen oder erst später? | Niedrig | UI-Design, Web Speech API Integration |
|
||||
| Q-15 | Soll das KI-Backend lokal (Ollama auf Server) oder remote (externer API-Provider) laufen? | Mittel | Deployment-Architektur, Performance, Kosten |
|
||||
| Q-16 | Welche KI-Modellgröße ist akzeptabel (z. B. 7B, 13B, 70B Parameter)? | Mittel | Performance, Hardware-Anforderungen, Antwortzeit |
|
||||
|
||||
---
|
||||
|
||||
@@ -429,7 +429,7 @@ User Input (Text/Sprache)
|
||||
- **Mehrschritt-Operationen:** Für komplexe Befehle (z. B. "Erstelle einen Raum und bestuhle ihn") kann das LLM eine Sequenz von Function Calls generieren, die nacheinander ausgeführt werden.
|
||||
- **Guardrails / Safety:** Ein Safety-Layer prüft jeden Function Call vor der Ausführung. Destruktive Operationen (Löschen aller Elemente, Überschreiben ganzer Zeichnungen) erfordern explizite User-Bestätigung.
|
||||
|
||||
**Empfehlung:** Ollama (MIT) als KI-Backend mit Qwen 2.5 (Apache-2.0) oder Llama (Llama License) als primäres Modell. Function Calling Pattern mit zentraler CAD-Function-Registry. Context Injection für Kontext-Verständnis. Guardrails für Safety.
|
||||
**Empfehlung:** OpenAI-kompatibler API-Endpoint (user-provided) als KI-Anbindung. Function Calling Pattern mit zentraler CAD-Function-Registry. Context Injection für Kontext-Verständnis. Guardrails für Safety. Kein lokales Modell-Deployment – der User bringt seinen eigenen Endpoint mit (OpenAI, OpenRouter, Ollama OpenAI-Compat, vLLM OpenAI-Compat, etc.).
|
||||
|
||||
**Quellen:**
|
||||
- cadcenterhyderabad.com: AutoCAD 2027 AI Features
|
||||
@@ -455,8 +455,8 @@ User Input (Text/Sprache)
|
||||
| **PDF-Generierung** | pdf-lib (MIT) oder jsPDF (MIT) | MIT |
|
||||
| **SVG-Verarbeitung** | Native Browser-API oder svg.js (MIT) | MIT |
|
||||
| **Auth** | bcrypt (Apache) oder argon2 (MIT/CDDL) | Open Source |
|
||||
| **KI-Backend** | Ollama (MIT) oder vLLM (Apache-2.0) | MIT/Apache |
|
||||
| **KI-Modell** | Qwen 2.5 (Apache-2.0) oder Llama 3/4 (Llama License) oder DeepSeek (MIT) | Open Source |
|
||||
| **KI-Anbindung** | OpenAI-kompatibler API-Endpoint (user-provided) – funktioniert mit OpenAI, OpenRouter, Ollama (OpenAI-Compat), vLLM (OpenAI-Compat) | User-provided |
|
||||
| **KI-Client** | OpenAI SDK (MIT) oder native fetch/axios | MIT |
|
||||
| **API-Dokumentation** | OpenAPI/Swagger (Apache-2.0) | Apache |
|
||||
| **Containerisierung** | Docker (Apache 2.0) | Open Source |
|
||||
| **Deployment** | Coolify (AGPL-3.0) | Open Source |
|
||||
@@ -482,8 +482,8 @@ User Input (Text/Sprache)
|
||||
| Browser-Speicherlimit | Sehr große Projekte können Browser-Speicherlimit überschreiten | Lazy-Loading; Kompression; IndexedDB für Persistenz |
|
||||
| Plugin-System-Komplexität | Universelles Plugin-System kann Core-Stabilität gefährden | Plugin-Isolation (Sandbox/try-catch); Plugin-Manifest mit deklarativen Abhängigkeiten |
|
||||
| KI-Fehlerhafte Befehle | LLM könnte fehlerhafte oder unerwartete Function Calls generieren | Guardrails; Function-Validation vor Ausführung; Bestätigung für destruktive Operationen |
|
||||
| KI-Latenz | LLM-Inferenz kann mehrere Sekunden dauern, besonders auf lokaler Hardware | Streaming-Responses; Fortschrittsanzeige; Modellgröße wählbar (7B für Speed, 70B für Qualität) |
|
||||
| KI-Hardware-Anforderungen | Lokale KI-Modelle benötigen GPU/RAM | Ollama mit quantisierten Modellen (4-bit/8-bit); remote API als Fallback |
|
||||
| KI-Latenz | LLM-Inferenz beim externen API-Provider kann mehrere Sekunden dauern | Streaming-Responses; Fortschrittsanzeige; Timeout-Handling;Fallback auf manuelle Bedienung |
|
||||
| KI-API-Verfügbarkeit | Externer KI-API-Endpoint kann nicht erreichbar sein (Netzwerk, Wartung, Rate-Limit) | Klare Fehlermeldungen; Retry-Logik; CAD bleibt ohne KI voll nutzbar |
|
||||
| KI-Kontext-Größe | CAD-Zustand kann groß sein (viele Elemente); LLM-Context-Limit begrenzt | Context-Summary statt vollständiger Zeichnung; nur relevante Ausschnitte senden |
|
||||
|
||||
---
|
||||
@@ -492,14 +492,14 @@ User Input (Text/Sprache)
|
||||
|
||||
| Aspekt | Erwartung |
|
||||
|---|---|
|
||||
| **Containerisierung** | Docker (Dockerfile + docker-compose.yml) – CAD-Backend, KI-Backend, Frontend |
|
||||
| **Containerisierung** | Docker (Dockerfile + docker-compose.yml) – CAD-Backend + Frontend (2 Container) |
|
||||
| **Orchestrierung** | Coolify auf coolify-01 (46.225.91.159) |
|
||||
| **Domain** | TBD – z. B. cad.media-on.de |
|
||||
| **SSL** | Let's Encrypt via Coolify/Traefik |
|
||||
| **Datenbank** | SQLite (Standard); Datenbank-Schicht abstrahiert für Migration |
|
||||
| **KI-Backend** | Ollama oder vLLM als separater Container; GPU empfohlen (nicht zwingend) |
|
||||
| **KI-Anbindung** | OpenAI-kompatibler API-Endpoint (extern) – kein separater KI-Container; API-URL + API-Key über Umgebungsvariablen |
|
||||
| **WebSocket-Server** | Separater Container oder integriert; WebSocket-Proxy via Traefik |
|
||||
| **Persistenz** | Docker-Volume für Datenbank, Datei-Storage und KI-Modelle |
|
||||
| **Persistenz** | Docker-Volume für Datenbank und Datei-Storage (Grundrisse, Bibliothek) |
|
||||
| **Skalierung** | Initiale Version: Einzelner Server; später horizontal skalierbar |
|
||||
|
||||
---
|
||||
@@ -606,28 +606,28 @@ Basierend auf Recherche (Scan2CAD Review, Autodesk Produktseiten, Softonic Revie
|
||||
## 13. Handoff
|
||||
|
||||
### Requirements Status
|
||||
- **Draft v3 erstellt:** Ja (2026-06-19)
|
||||
- **Entschiedene Fragen:** Q-01 (Open Source) ✅, Q-02 (E-Mail/Passwort) ✅, Q-03 (SQLite + API-first/modular) ✅
|
||||
- **Draft v4 erstellt:** Ja (2026-06-19)
|
||||
- **Entschiedene Fragen:** Q-01 (Open Source) ✅, Q-02 (E-Mail/Passwort) ✅, Q-03 (SQLite + API-first) ✅, Q-15 (Remote/OpenAI-kompatibel) ✅, Q-16 (User-Sache) ✅
|
||||
- **Testbare Anforderungen:** Ja – alle funktionalen und nicht-funktionalen Anforderungen haben konkrete Akzeptanzkriterien
|
||||
- **Akzeptanzkriterien konkret:** Ja
|
||||
- **Assumptions:** 18 dokumentiert (erweitert um KI Copilot, API-First, SQLite, Modularität)
|
||||
- **Non-Goals:** 17 dokumentiert (angepasst – KI ist nun Kern-Feature, kein Non-Goal mehr; autonomes KI-Zeichnen ist Non-Goal)
|
||||
- **Offene Fragen:** 9 (0 hoch, 4 mittel, 5 niedrig priorisiert)
|
||||
- **AutoCAD Web Referenz:** Vollständige Feature-Analyse inkl. Limitierungen und Vergleich (erweitert um KI Copilot und API-First Vergleich)
|
||||
- **Open-Source-Stack:** Vollständiger Stack mit Lizenzen (erweitert um KI-Backend und KI-Modelle)
|
||||
- **KI Copilot:** 15 detaillierte Anforderungen (F-AI-01 bis F-AI-15) mit Function Calling Pattern, Guardrails, Open-Source-Backend
|
||||
- **Assumptions:** 18 dokumentiert (erweitert um OpenAI-kompatiblen KI-Endpoint)
|
||||
- **Non-Goals:** 17 dokumentiert
|
||||
- **Offene Fragen:** 7 (0 hoch, 3 mittel, 4 niedrig priorisiert)
|
||||
- **AutoCAD Web Referenz:** Vollständige Feature-Analyse inkl. Limitierungen und Vergleich
|
||||
- **Open-Source-Stack:** Vollständiger Stack mit Lizenzen (KI-Anbindung: OpenAI-kompatibler Endpoint, user-provided)
|
||||
- **KI Copilot:** 15 detaillierte Anforderungen (F-AI-01 bis F-AI-15) mit Function Calling Pattern, Guardrails, OpenAI-kompatibler Endpoint
|
||||
- **Integration/Modularität:** 8 Anforderungen (F-INT-01 bis F-INT-08) für API-first, REST-API, Webhooks, Headless-Modus
|
||||
- **Plugin-System:** 8 Anforderungen (F-EXT-01 bis F-EXT-08) für universelle Erweiterbarkeit
|
||||
|
||||
### Ready for Architecture
|
||||
- **Ja** – alle hoch-priorisierten Fragen geklärt; Architektur-Phase kann starten
|
||||
- KI-Copilot-Architektur ist als Core-Feature definiert mit Function Calling Pattern
|
||||
- **Ja** – alle hoch- und mittel-priorisierten Fragen geklärt; Architektur-Phase kann starten
|
||||
- KI-Copilot-Architektur: OpenAI-kompatibler API-Endpoint + Function Calling + CAD-Function-Registry
|
||||
- API-First-Design ist als Architektur-Vorgabe definiert
|
||||
- Verbleibende offene Fragen (Q-04 bis Q-16) sind mittel/niedrig priorisiert und können während oder nach der Architektur-Phase geklärt werden
|
||||
- Deployment: 2 Docker-Container (CAD-Backend + Frontend); KI ist externer API-Call
|
||||
- Verbleibende offene Fragen (Q-04 bis Q-14) sind mittel/niedrig priorisiert und können während oder nach der Architektur-Phase geklärt werden
|
||||
- Technologie-Empfehlungen stehen als Architektur-Vorgaben bereit
|
||||
|
||||
### Empfohlene nächste Schritte
|
||||
1. User-Review der aktualisierten requirements.md (v3)
|
||||
2. Optional: Beantwortung von Q-15 (KI lokal vs. remote) und Q-16 (KI-Modellgröße)
|
||||
3. Freigabe für Architektur-Phase (Phase 2)
|
||||
4. Delegation an Solution Architect mit Vorgaben: Open-Source-Stack, KI-Copilot-Function-Calling, API-First, Plugin-System
|
||||
1. User-Review der aktualisierten requirements.md (v4)
|
||||
2. Freigabe für Architektur-Phase (Phase 2)
|
||||
3. Delegation an Solution Architect mit Vorgaben: Open-Source-Stack, KI-Copilot (OpenAI-kompatibler Endpoint + Function Calling), API-First, Plugin-System, 2 Container
|
||||
|
||||
Reference in New Issue
Block a user