20 KiB
Ablaufprotokoll der Versuchsdurchführung
Zeitraum: 25.–26. August 2026
Untersuchungsgegenstand: c-entron ERP-Suite, eingefrorener Snapshot 79c1142
Zweck dieses Dokuments: Grundlage für den Ergebnisteil der Arbeit (Kapitel 5 und 6).
Festgehalten wird, wie Prompt und Versuchsaufbau schrittweise entstanden sind, welche Läufe durchgeführt wurden und welche Erkenntnisse sich daraus ergeben haben. Der methodisch wesentliche Punkt: Der Versuchsaufbau ist nicht vorab fertig gewesen, sondern an den Läufen gewachsen. Jede Änderung geht auf eine konkrete Beobachtung zurück. Diese Kopplung ist hier dokumentiert, damit im Ergebnisteil nachvollziehbar bleibt, welche Messung unter welchen Bedingungen entstand.
1. Ausgangslage
Zu Beginn lagen vor:
- ein Initial-Prompt (
Versuche/Versuch_01/01_Prompt.md) mit der Analyseanweisung nach ISO/IEC/IEEE 29148, abgestimmt auf die RRE-Methodenkette aus Kapitel 4 - ein Skill
run-experiment(Version 1.0.0), der den Prompt als Headless-Lauf ausführt und ein Messprotokoll schreibt - die Codebasis als eigenständiges Git-Repository mit aktivem GitHub-Remote
Nicht vorhanden waren: eine belastbare Isolationsstrategie, eine Definition der zu erhebenden Messgrößen über Tokens und Dauer hinaus, und jede Vorstellung davon, wie stark Läufe unter gleichen Bedingungen streuen.
2. Chronologie in fünf Phasen
Phase 1 – Erster Lauf und die Entdeckung der Werkzeugkonfiguration (12:29–13:00)
Der erste Lauf offenbarte sofort ein Grundproblem: Das Codebasis-Verzeichnis enthielt genau die
Dinge, die die Versuchsbedingung „keine Agentendateien, keine MCP-Server" ausschließt – eine
CLAUDE.md mit 201 Zeilen Projektkontext, AGENTS.md, drei projektspezifische Subagenten,
34 Skill-Definitionen, sechs Slash-Commands, elf Serena-Memories und einen aktiven MCP-Server.
Diese Dateien wurden vor dem Lauf gelöscht und danach per git restore zurückgesetzt.
Ergebnis: 96 Anforderungen, 13,1 Mio. Tokens, 36 Permission-Denials (32 × Bash,
4 × PowerShell). Der Lauf war unter --permission-mode acceptEdits gestartet – dieser Modus
erlaubt Dateibearbeitungen, aber keine Shell-Ausführung. Der Agent wich auf Read, Grep und Glob
aus; Verzeichnisinventuren und Dateizählungen standen ihm nicht zur Verfügung. Von rund 85
Business-Logic-Modulen blieben 55 bis 60 unanalysiert.
Auslöser für die erste große Skill-Änderung.
Phase 2 – Werkzeugfreigabe, Isolation und der eingefrorene Snapshot (13:49–15:00)
Zwei Entscheidungen fielen zusammen:
Shell-Zugriff wird Standard. --allowedTools "Bash" "PowerShell" mit einer Denylist von 33
Einträgen für schreibende und bauende Kommandos. Die Read-only-Eigenschaft der Codebasis wird
weiterhin über den Vorher/Nachher-Vergleich per git status nachgewiesen; die Denylist senkt das
Risiko, ersetzt die Verifikation aber nicht.
Isolation über --safe-mode – und die Erkenntnis, dass das nicht reicht. Ein Kontrolltest
belegte: --safe-mode unterdrückt zuverlässig das Vorladen von CLAUDE.md als
Systemanweisung – ohne das Flag zitiert der Agent deren Inhalt, mit dem Flag antwortet er
„NICHTS VORGELADEN". Es verhindert jedoch nicht, dass der Agent diese Dateien mit
Shell-Zugriff selbst liest. Im Smoke-Test tat er genau das.
Konsequenz: Die KI-Konfigurationen wurden dauerhaft aus der Codebasis entfernt (Commit
79c1142, 92 Dateien), das GitHub-Remote entkoppelt und der Stand als Versuchssnapshot
eingefroren. Damit ist die Bedingung „keine Agentendateien" eine Eigenschaft des Untersuchungs-
gegenstands und muss nicht pro Lauf hergestellt werden.
Lauf 2 brach nach 24 Minuten mit einem API-Transportfehler ab („The response stopped
arriving"), nachdem vier von sieben Artefakten geschrieben waren. Kein Konfigurationsproblem –
permission_denials war 0.
Lauf 3 lief vollständig durch: 106 Anforderungen, 11,5 Mio. Tokens, 0 Denials, 23:40 statt 31:31. Schneller, sparsamer und ergiebiger als Lauf 1 – die Werkzeugfreigabe schien sich in jeder Dimension auszuzahlen.
Phase 3 – Der Varianzbefund (15:05–19:31)
Lauf 4 unter identischer Konfiguration lieferte 55 Anforderungen – knapp die Hälfte von Lauf 3 – bei höheren Kosten. Der Agent hatte diesmal keinen einzigen Subagenten gestartet und stattdessen 147 eigene Turns absolviert.
Das war der Wendepunkt der Reihe. Die naheliegende Erklärung – die Subagentenzahl bestimmt den Ertrag – hielt der nächsten Messung nicht stand: Lauf 5 startete 14 Subagenten und lieferte 325 Anforderungen bei 52,7 Mio. Tokens; Lauf 6 startete ebenfalls 7 wie Lauf 3, lieferte aber 189 statt 106 Anforderungen bei dreifachem Verbrauch.
Nicht die Anzahl der Subagenten erklärt die Streuung, sondern die Freiheit, die Analyse überhaupt selbst zu zerlegen.
Um das zu prüfen, wurde der Modus solo eingeführt: Task, Agent und Workflow gesperrt,
sodass keine Delegation möglich ist. Ein Verifikationstest bestätigte die Sperre (spawned: 0,
Antwort „KEINE SUBAGENTEN MOEGLICH") und deckte dabei auf, dass der Agent nach der Sperre von
Task/Agent auf Workflow auswich – dieses Werkzeug orchestriert ebenfalls Subagenten und
musste ergänzt werden.
Fünf Solo-Läufe (42, 82, 60, 73, 67 Anforderungen) gegen neun Builtin-Läufe ergaben:
V1 (solo) |
V1b (builtin) |
|
|---|---|---|
| Anforderungen | 42 – 82 (Faktor 2,0) | 55 – 325 (Faktor 5,9) |
| Tokens | 4,4 – 12,6 Mio. (Faktor 2,9) | 11,5 – 52,7 Mio. (Faktor 4,6) |
| Median Tokens | 5,1 Mio. | 30,1 Mio. |
Zentraler Befund der Reihe. Die selbstgewählte Zerlegung in Subagenten ist die dominierende Störgröße. Wird sie unterbunden, halbiert sich die Streuung mehr als, und der Verbrauch sinkt um Faktor 6.
Phase 4 – Modellvergleich und die Grenzen der Steuerbarkeit (19:59–23:10)
Um zu prüfen, ob die Streuung modellabhängig ist, wurde dieselbe Bedingung mit zwei weiteren Modellen wiederholt.
Opus 5, solo, fünf Läufe: 71 – 182 Anforderungen (Median 114), 13,6 – 24,9 Mio. Tokens (Median 22,8). Gegenüber Sonnet: 1,7-mal mehr Anforderungen bei 4,5-fachem Verbrauch, also rund das 2,7-fache an Tokens je Anforderung. Die Streuung blieb im selben Rahmen – der Modellwechsel verschiebt das Niveau, nicht die Stabilität.
Fable 5, solo, Effort max, zwei Läufe: 207 und 148 Anforderungen bei 24,2 und 31,1 Mio.
Tokens – der höchste Solo-Verbrauch der Reihe, vom nominell sparsamsten Modell. Die
Thinking-Tokens (35.220 und 39.609) übertreffen jeden der 21 Vorläufe deutlich; der bisherige
Höchstwert lag bei 24.179. Das spricht für den Effort als Treiber, ist aber nicht beweisbar,
weil Modell und Effort gleichzeitig gewechselt wurden.
Fable 5, builtin – ein Fehlschlag mit Erkenntniswert. --model claude-fable-5 steuerte nur
den Hauptagenten. Die 13 Subagenten liefen auf claude-opus-5[1m], dem Standardmodell aus
den Sitzungseinstellungen. Auf sie entfielen 136,7 von 150,3 Mio. Tokens – 91 %. Eine
Gegenprüfung über alle 24 Läufe grenzte den Fall eindeutig ein: Sonnet und Opus werden an
Subagenten durchgereicht, Fable nicht.
Konsequenz: Bei Modus builtin ist das Modell nicht allein durch das Flag festgelegt. Der
Abgleich der tatsächlich eingesetzten Modelle wurde zur Pflichtprüfung.
Phase 5 – Nachbereitung und Ausrichtung auf die Arbeit (26.08.)
Nach Abschluss der Läufe wurden Struktur und Dokumentation konsolidiert: Umstellung der Kostenangabe auf Tokenverbrauch, Ordnerstruktur nach Bedingungen, maschinelle Auswertung der erzeugten Anforderungen, Sicherung des Untersuchungsgegenstands im Arbeitsrepository sowie die Trennung von Analyseanweisung (Prompt) und Prozessvorgabe (Skill).
3. Entwicklung des Prompts
Der Prompt blieb inhaltlich über alle 24 Läufe unverändert – der SHA-256
1B0DB06B…3C02FF ist in jedem Protokoll dokumentiert. Alle 24 Läufe sind damit
Wiederholungsmessungen desselben Prompts, keine Iterationen im Sinne von Kapitel 4.
Erst nach Abschluss der Läufe wurde er überarbeitet (2026-08-26):
| Änderung | Grund |
|---|---|
Metadaten Werkzeugkonfiguration und Modell entfernt |
Beschreiben den Lauf, nicht die Analyse; gehören ins Messprotokoll |
| Satz „Es stehen weder spezialisierte Agenten noch MCP-Server zur Verfügung" entfernt | Bindet den Prompt an eine Werkzeugkonfiguration; wird zur Laufzeit als Werkzeugkontext beigestellt |
Feld Übernahmewürdigkeit ergänzt (übernehmen/Workaround/Sonderfall/veraltet) |
Der Evaluationsrahmen (Kap. 4.3) bewertet diese Dimension; bislang steckte sie halb im Feld Status und war nicht auswertbar |
Pflichteigenschaft Redundanzfreiheit ergänzt |
Ergänzt das vorhandene Feld Konsolidierung um die ausdrückliche Abgrenzungsprüfung |
| Konsistenzcheck erweitert | Prüft nun auch fehlende Übernahmewürdigkeit und nicht markierte Doubletten |
Damit ist der Prompt werkzeug- und modellneutral und von jedem LLM verwendbar – eine Voraussetzung für den in Kapitel 4 geplanten LLM-Querschnitt.
4. Entwicklung des Versuchsaufbaus (Skill)
17 Versionen in zwei Tagen. Jede geht auf eine konkrete Beobachtung zurück:
| Version | Änderung | Auslöser |
|---|---|---|
| 1.0.0 | Ausgangsfassung | – |
| 2.0.0 | Shell-Zugriff + Denylist; Isolation über eingefrorenen Snapshot | 36 Denials in Lauf 1; --safe-mode allein unzureichend |
| 2.0.1 | before.txt leerwertsicher schreiben |
Bei sauberem Root schrieb PowerShell die Datei nicht und ließ alten Inhalt stehen – der Vergleich meldete eine Abweichung, die es nicht gab |
| 2.1.0 | Modell wird vor jedem Lauf erfragt | Das Modell wurde bis dahin ad hoc gewählt |
| 2.1.1 | Warnung zur Snapshot-Prüfung | Ein verkürzter Regex sprach auf echte Produktdateien an (ClaudeCodeChatModelClient.cs) |
| 3.0.0 | Agentenmodus als Pflichtparameter (solo/builtin/custom) |
Subagenten-Einsatz schwankte zwischen 0 und 14 und war die dominierende Störgröße |
| 3.1.0 | Parallelfähigkeit; Steuerdateien nach _meta im Laufverzeichnis |
Geteilte Scratchpad-Dateien hätten sich zwischen parallelen Läufen überschrieben |
| 3.2.0 | Modell und Version im Verzeichnisnamen; Workflow mitgesperrt |
Im Verifikationstest wich der Agent auf Workflow aus |
| 3.3.0 | Subagenten-Prompts werden protokolliert | Die selbstgewählte Zerlegung war nur als Zahl sichtbar, nicht inhaltlich |
| 3.4.0 | Effort als dritter Pflichtparameter | Der Denkaufwand wurde nur aus der Sitzung geerbt und nirgends dokumentiert |
| 3.5.0 | Berichtete Aufwandsgröße ist der Tokenverbrauch statt USD | USD-Beträge hängen an Preisliste und Modellwahl und veralten |
| 3.6.0 | Verschachtelte Subagenten verifiziert und dokumentiert | Unbelegt, ob tiefere Ebenen in die Tokensumme einfließen – Kontrolltest belegte es |
| 3.7.0 | Effort im Verzeichnisnamen | Erster max-Block; gleichnamige Verzeichnisse hätten verschiedene Bedingungen bezeichnet |
| 3.8.0 | Pflichtprüfung der tatsächlich eingesetzten Modelle | Fable-Lauf: 91 % des Verbrauchs auf einem nicht angeforderten Modell |
| 3.9.0 | Pflichtabschnitt „Gefundene Anforderungen" | Protokolle maßen nur Aufwand, nicht Ertrag |
| 3.10.0 | Bedingungen als Ordnerstruktur statt im Dateinamen | Der Name wuchs mit jeder Variable und war kaum noch lesbar |
| 4.0.0 | Zweiteilung Prozess/Werkzeugadapter; V1 = solo, V1b = builtin; Evaluationsrahmen verankert |
Ausrichtung auf Kapitel 4 der Arbeit |
Beobachtung für die Diskussion: Zehn der sechzehn Änderungen gehen auf Messfehler oder Fehlannahmen zurück, die erst im Betrieb sichtbar wurden – nicht auf Planungslücken im klassischen Sinn. Ein Versuchsaufbau für agentische LLM-Werkzeuge lässt sich offenbar nicht vollständig vorab spezifizieren.
5. Durchgeführte Läufe
24 Läufe, 745,2 Mio. Tokens, 3.287 erzeugte Anforderungen. Ein Lauf schlug fehl (Nr. 2, API-Transportfehler).
| # | Zeit | Modell | Modus | Effort | Subagenten | Denials | Turns | Tokens | Anforderungen |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 12:29 | sonnet-5 | builtin | high | 8 | 36 | 43 | 13.052.010 | 96 |
| 2 | 13:49 | sonnet-5 | builtin | high | 6 | 0 | 8 | 16.655.125 | 89 (Abbruch) |
| 3 | 14:29 | sonnet-5 | builtin | high | 7 | 0 | 69 | 11.516.200 | 106 |
| 4 | 15:05 | sonnet-5 | builtin | high | 0 | 0 | 147 | 27.562.244 | 55 |
| 5 | 15:35 | sonnet-5 | builtin | high | 14 | 1 | 31 | 52.713.542 | 325 |
| 6 | 16:35 | sonnet-5 | builtin | high | 7 | 0 | 29 | 32.568.122 | 189 |
| 7 | 17:31 | sonnet-5 | solo | high | 0 | 0 | 68 | 4.357.855 | 42 |
| 8 | 17:31 | sonnet-5 | solo | high | 0 | 0 | 107 | 12.598.503 | 82 |
| 9 | 18:04 | sonnet-5 | solo | high | 0 | 0 | 72 | 5.659.692 | 60 |
| 10 | 18:04 | sonnet-5 | solo | high | 0 | 0 | 77 | 4.591.733 | 73 |
| 11 | 18:04 | sonnet-5 | solo | high | 0 | 0 | 67 | 5.050.595 | 67 |
| 12 | 18:29 | sonnet-5 | builtin | high | 19 (9 versch.) | 2 | 94 | 55.167.397 | 246 |
| 13 | 18:29 | sonnet-5 | builtin | high | 8 | 1 | 84 | 42.204.257 | 238 |
| 14 | 18:29 | sonnet-5 | builtin | high | 20 (6) | 0 | 23 | 40.787.325 | 113 |
| 15 | 18:29 | sonnet-5 | builtin | high | 21 (3) | 0 | 15 | 44.713.674 | 145 |
| 16 | 18:29 | sonnet-5 | builtin | high | 18 (6) | 0 | 33 | 65.101.243 | 239 |
| 17 | 19:59 | opus-5 | solo | high | 0 | 0 | 116 | 13.560.381 | 71 |
| 18 | 19:59 | opus-5 | solo | high | 0 | 1 | 195 | 22.759.401 | 119 |
| 19 | 19:59 | opus-5 | solo | high | 0 | 1 | 177 | 24.860.083 | 114 |
| 20 | 20:00 | opus-5 | solo | high | 0 | 0 | 145 | 24.280.282 | 182 |
| 21 | 20:00 | opus-5 | solo | high | 0 | 0 | 131 | 19.751.531 | 109 |
| 22 | 21:09 | fable-5 | solo | max | 0 | 1 | 152 | 24.225.555 | 207 |
| 23 | 21:09 | fable-5 | solo | max | 0 | 0 | 162 | 31.073.793 | 148 |
| 24 | 22:07 | fable-5 | builtin | high | 13 | 0 | 28 | 150.340.866 | 172 |
Die Läufe 7–8, 9–11, 12–16, 17–21 und 22–23 liefen jeweils parallel. Wanduhrzeiten dieser Läufe sind dadurch verzerrt und nicht für Laufzeitvergleiche verwendbar; Tokenverbrauch, Anforderungsanzahl und Denials bleiben unverzerrt.
6. Befunde
6.1 Die Anforderungsanzahl ist kein Qualitätsmaß
Vier Läufe unter identischer Bedingung (Nr. 3, 4, 5, 6) ergaben 106, 55, 325 und 189 Anforderungen – Faktor 5,9. Der Unterschied zwischen Lauf 1 (ohne Shell, 96) und Lauf 3 (mit Shell, 106) liegt vollständig innerhalb dieser Streuung. Jede Aussage der Form „Konfiguration X liefert mehr Anforderungen" ist ohne Wiederholungsläufe wertlos.
6.2 Die einzige robuste Wirkung der Werkzeugkonfiguration ist die Denial-Zahl
36 Denials ohne Shell-Zugriff, 0 mit. Das ist eine direkte Eigenschaft der Konfiguration und keine Zufallsgröße. Alle anderen Kennzahlen streuen zu stark.
6.3 Die selbstgewählte Zerlegung dominiert alles
solo gegen builtin: Streuung Faktor 2,0 gegen 5,9 bei den Anforderungen, Medianverbrauch
5,1 gegen 30,1 Mio. Tokens. Der Effekt gilt modellunabhängig – die Opus-Reihe zeigt dieselbe
Stabilität im Solo-Modus.
Bemerkenswert ist die Gegenläufigkeit von Turns und Delegation: Lauf 15 delegierte am stärksten
(21 Subagenten) und brauchte die wenigsten eigenen Turns (15); Lauf 4 delegierte gar nicht und
brauchte 147. num_turns zählt nur den Hauptagenten und ist deshalb kein Aufwandsmaß.
6.4 Verschachtelte Delegation ist der Normalfall, nicht die Ausnahme
In vier von fünf Läufen des Blocks 12–16 erreichte die Delegation Tiefe 2, mit 3 bis 9 von
Subagenten gestarteten Subagenten. Ein Kontrolltest belegte, dass deren Tokens vollständig in
modelUsage einfließen – ihre Prompts dagegen liegen in nicht persistierten Transkripten
und sind nicht rekonstruierbar. Die Prompt-Erfassung ist in diesen Läufen systematisch
unvollständig, die Verbrauchsmessung nicht.
6.5 Modellstärke und Ertrag
| Reihe | Anforderungen (Median) | Tokens (Median) | Tokens je Anforderung |
|---|---|---|---|
| Sonnet 5, solo, high | 67 | 5,1 Mio. | ~76.000 |
| Opus 5, solo, high | 114 | 22,8 Mio. | ~200.000 |
| Fable 5, solo, max | 178 | 27,6 Mio. | ~155.000 |
Der Mehrertrag stärkerer Modelle wird mit überproportionalem Verbrauch erkauft. Die Anforderungsanzahl misst allerdings nur Menge; die Belegqualität ist davon unabhängig zu betrachten.
6.6 Regelkonformität – der Agent verfehlt teilweise die eigenen Vorgaben
Die maschinelle Auswertung prüft die Artefakte gegen die Vorgaben des Prompts. Zwei Beispiele:
- Lauf 11 (Sonnet, solo): 5 von 31 risikorelevanten Anforderungen tragen weder einen
PRIMÄR-Beleg noch die Kennzeichnung[HYPOTHESE], obwohl der Prompt das für Sicherheits-, Abrechnungs- und Berechtigungsthemen ausdrücklich verlangt. Primärbelegquote 62,7 %. - Lauf 24 (Fable/Opus, builtin): alle 58 risikorelevanten Anforderungen gedeckt, Primärbelegquote 100 %, Median 2 Belege je Anforderung.
Diese Prüfung wäre von Hand nicht leistbar und liefert eine inhaltliche Vergleichsgröße, die unabhängig vom Mengengerüst ist.
6.7 Werkzeugtechnische Befunde
| Befund | Beleg |
|---|---|
--safe-mode unterdrückt das Vorladen von Projektanweisungen, nicht das Lesen |
Kontrolltest: ohne Flag zitiert der Agent CLAUDE.md, mit Flag „NICHTS VORGELADEN"; mit Shell liest er sie dennoch |
| Gesperrte Werkzeuge erzeugen keine Denials | In allen 12 Solo-Läufen 0 Denials auf Task/Agent/Workflow – das Modell plant von vornherein ohne sie |
--model steuert nur den Hauptagenten |
Lauf 24: 91 % des Verbrauchs auf nicht angefordertem Modell |
| Der Effort steht nicht im Ergebnisobjekt | Nur über das Session-Transkript belegbar |
duration_ms ist bei starker Nebenläufigkeit unbrauchbar |
Lauf 5: 09:37 gemeldet, 43:01 tatsächlich |
| Ein Lauf schrieb außerhalb von Codebasis und Laufverzeichnis | Lauf 13 legte drei Arbeitsdateien in C:\DEV\ an; nur weil die Denylist das Aufräumen blockierte, wurde es sichtbar |
Der letzte Punkt ist methodisch der unangenehmste: Die etablierte Prüfung „Root unverändert" deckt ausschließlich die Codebasis ab. Schreibvorgänge in andere Verzeichnisse bleiben unbemerkt.
7. Grenzen und offene Punkte
Nicht geklärt: Ob der Verbrauchssprung im Fable-Block vom Modell oder vom Effort kommt –
beide Variablen wechselten gleichzeitig. Ein Fable-Block auf high oder ein Sonnet-Block auf
max würde die Frage entscheiden.
Nicht durchgeführt: Die Stakeholder-Validierung nach Kapitel 4.3. Alle Aussagen dieses Protokolls beruhen auf maschinell erhebbaren Größen. Ob die erzeugten Anforderungen sachlich korrekt sind, ist damit ausdrücklich nicht gezeigt.
Nicht abgedeckt: Versuch 2 (Agentendateien) und Versuch 3 (MCP-Server). Der Skill ist darauf
vorbereitet (Modus custom), die Agentendefinitionen existieren aber noch nicht.
Offene Aufräumarbeiten: Drei Streudateien in C:\DEV\ aus Lauf 13; die Erweiterung der
Nachlaufprüfung um Streudateien außerhalb des Laufverzeichnisses.
Einschränkung der Zeitmessung: 18 der 24 Läufe liefen parallel. Für belastbare Laufzeitvergleiche wären serielle Wiederholungen nötig. Eine Teilauswertung zeigt bei den Solo-Läufen einen messbaren Kontentionseffekt: bei zwei gleichzeitigen Läufen 114–176 Sekunden je Million Tokens, bei drei gleichzeitigen 185–233 – nicht überlappende Bereiche trotz kleiner Stichprobe.
8. Verweise
- Messprotokolle je Lauf:
Versuche/Versuch_01/<ModellID>/<Modus>/<Effort>/<Laufverzeichnis>/Protokoll.md - Rohdaten:
RawResult.jsonje Lauf, unverändert erhalten - Exakt gesendeter Prompt je Lauf:
_meta/combined_prompt.md - Subagenten-Prompts:
_meta/subagenten.md - Maschinelle Anforderungsauswertung:
_meta/anforderungen.mdund.json - Prozessvorgabe:
.claude/skills/run-experiment/SKILL.md(Version 4.0.0, mit Änderungshistorie) - Nachweis des Untersuchungsgegenstands:
Versuche/Versuch_01/_Codebasis-Nachweis.md - Struktur- und Umbenennungshistorie:
Versuche/Versuch_01/_Umbenennung_*.md,_Umstrukturierung_2026-08-26.md