38 lines
1.5 KiB
Markdown
38 lines
1.5 KiB
Markdown
# Knowledge-Conduit Generaltest: Schlanker Konzeptentwurf
|
|
|
|
## Ziel
|
|
Der Generaltest soll breit genug fuer robuste Aussagekraft sein, aber klein genug, um nicht die App-Solution aufzublaehen.
|
|
|
|
## Leitplanke fuer diese Solution
|
|
- In dieser Solution werden keine grossen Test-Fixtures abgelegt.
|
|
- Keine massiven Run-Artefakte im Repo.
|
|
- Das Konzept bleibt hier dokumentiert; schwere Testdaten laufen ausserhalb der Solution.
|
|
|
|
## Testidee (fachlich)
|
|
Geprueft werden Kombinationen aus:
|
|
1. Kleine Aenderung vs. grosse Aenderung
|
|
2. Ohne Noise vs. mit Noise
|
|
3. Eine Capability geaendert vs. vier Capabilities geaendert
|
|
4. Inhaltliche Aenderung vs. strukturelle Aenderung
|
|
|
|
## Minimaler Setup-Vorschlag
|
|
- Zwei kleine lokale Test-Repos ausserhalb der Solution
|
|
- Jeweils identische drei Demo-Skills
|
|
- Eine gezielte Verbesserung in genau einem Skill als Drift-Fall
|
|
|
|
## Beispielhafte Szenarioklassen
|
|
1. Small + Clean + 1 Capability
|
|
2. Small + Noise + 4 Capabilities
|
|
3. Large + Clean + 1 Capability
|
|
4. Large + Noise + 4 Capabilities
|
|
|
|
## Abnahmekriterien
|
|
- Der Prozess erkennt kleine und grosse Aenderungen stabil.
|
|
- Noise fuehrt nicht zu unkontrollierten Fehlzuordnungen.
|
|
- 1- und 4-Capability-Faelle bleiben konsistent klassifiziert.
|
|
- Der gezielte Verbesserungsfall wird als plausible qualitative Verbesserung erkannt.
|
|
|
|
## Naechste Schritte
|
|
1. Externen, kleinen Test-Workspace fuer die Ausfuehrung nutzen.
|
|
2. Nur aggregierte Ergebnisse (z. B. Metriken, Zusammenfassung) hierher uebernehmen.
|
|
3. Falls noetig, spaeter einen sehr kleinen Smoke-Test in der Solution behalten.
|