#!/bin/sh
R=/opt/struktur/hermes-architekturpruefung/20260805_195917
cat > "$R/ABSCHLUSSBERICHT.md" <<'EOF'
# Abschlussbericht

## Status und Umfang

Die Architekturprüfung ist auf Basis der vorhandenen technischen Untersuchungsunterlagen abgeschlossen. Es wurden keine Produktivdateien, Konfigurationen, Skills, Sessions, Datenbanken, Container oder Dienste verändert.

## Hauptbefunde

- Persona wird in Hermes Carlo in `agent.personalities` gespeichert und über `display.personality` sowie `agent.system_prompt` aktiviert.
- Der lokale Persona-Editor schreibt diese Felder; `SOUL.md` und Skills werden dabei nicht verändert.
- Hermes Workspace besitzt eine getrennte Konfiguration und übernimmt Carlos Persona nicht automatisch.
- `SOUL.md`, Persona und `carlo-arbeitsweise` enthalten teilweise dieselben Identitäts-, Stil- und Arbeitsregeln.
- Dadurch entsteht semantische Konkurrenz im gemeinsamen Systemkontext; ein technischer Prioritätsmechanismus wurde nicht nachgewiesen.
- Skills haben Personas nicht formal ersetzt. Lokale Regeln wurden jedoch teilweise in Skills verlagert.
- Workspace Profiles sind nicht als automatische Carlo-Personaquelle belegt.
- Der genaue Workspace-Agentenübergang ist aus dem Bundle nicht belastbar belegbar.
- Weitere Bundle-Analyse wird beendet, weil sie für die Architekturentscheidung keinen ausreichenden Zusatznutzen bietet.
- Die bisherigen technischen Berichte bleiben als Untersuchungsunterlagen erhalten.

## Verbindliche Entscheidung

Empfohlen wird Variante C: eine gemeinsame Personaquelle für Hermes Carlo und Hermes Workspace; `SOUL.md` ausschließlich für stabile Identität und dauerhafte Grundprinzipien; Workspace Profiles ausschließlich für technische Arbeits-, Modell-, Tool- und Sessionkonfiguration; Skills ausschließlich für fachliche Fähigkeiten und begrenzte Verfahren.

`carlo-arbeitsweise` soll künftig keine Identitäts-, Stil- oder globalen Antwortformatregeln enthalten.

## Restunsicherheiten

Nicht weiterzuverfolgen sind die exakte interne Bundle-Funktionskette und der vollständige Workspace-Agentenübergang. Diese Unsicherheiten ändern die Architekturentscheidung nicht.
EOF
cat > "$R/ZIELARCHITEKTUR.md" <<'EOF'
# Zielarchitektur

## Festgelegte Variante: C

Carlo und Workspace verwenden eine gemeinsame, eindeutig versionierte Personaquelle. Beide Systeme lesen dieselbe Persona, statt getrennte Kopien oder Skills als Ersatz zu verwenden.

## Zuständigkeiten

| Komponente | Künftige Zuständigkeit |
|---|---|
| Gemeinsame Personaquelle | wechselbare Rolle, Ton, Kommunikationsstil und Arbeitsmodus |
| `SOUL.md` | stabile Identität und dauerhafte Grundprinzipien |
| Workspace Profiles | Modell-, Tool-, Arbeits- und Sessionkonfiguration; keine Identität |
| Skills | fachliche Fähigkeiten, Verfahren und begrenzte Toolabläufe |
| `carlo-arbeitsweise` | nur fachliche und operative Verfahren; keine globale Identität oder Stilvorgaben |

## Begründung

Variante C beseitigt die doppelte Personaablage und ermöglicht konsistente Personawechsel in Carlo und Workspace. Sie bewahrt die native beziehungsweise bereits funktionierende Personaablage in Carlo, lässt Profiles für technische Konfiguration bestehen und begrenzt Skills auf ihren fachlichen Zweck. Die Lösung ist rückrollbar, weil zunächst nur eine gemeinsame Quelle definiert und in isolierten Sessions geprüft wird.

## Abgrenzung

Es wird keine Persona in `SOUL.md` kopiert. Profiles werden nicht zu einer zweiten Personaquelle. Skills dürfen keine dauerhaften Identitäts-, Stil- oder globalen Antwortformatregeln enthalten.

## Nicht Bestandteil dieses Auftrags

Keine Dateien, Konfigurationen oder produktiven Personas wurden geändert.
EOF
cat > "$R/MIGRATIONSPLAN.md" <<'EOF'
# Migrationsplan

Konzeptioneller Plan; keine Umsetzung in diesem Auftrag.

## Schritte

1. Alle betroffenen Dateien und Konfigurationen vollständig sichern: Carlo-Konfiguration, `SOUL.md`, Persona-Editor, Carlo-Skills, Workspace-Konfiguration, Profile und relevante Sessions. Erfolg: prüfbare Backups und Hashliste.
2. Ein Regelinventar aus `SOUL.md`, der Persona und `carlo-arbeitsweise` erstellen. Jede Regel erhält Quelle, Zweck, Reichweite und Konfliktklasse.
3. Jede Regel genau einer Zielquelle zuordnen: Kernidentität zu `SOUL.md`, wechselbare Rolle und Stil zur Persona, Technik und Session zu Profiles, Fachverfahren zu Skills.
4. Die gemeinsame Personaquelle für Carlo und Workspace definieren, einschließlich Schema, Versionsstand, Aktivierungsweg und Rückfallwert.
5. Eine isolierte Testpersona und eine isolierte Testkonfiguration anlegen; keine produktive Persona aktivieren.
6. Carlo getrennt testen: Laden einer neuen Session, Personawechsel, Rückkehr zur Standardpersona und Verhalten bei fehlender Quelle.
7. Workspace getrennt testen: Profilwechsel, Übergabe der gemeinsamen Persona, neue Session und Verhalten bei nicht verfügbarer Personaquelle.
8. `carlo-arbeitsweise` regelweise auf fachliche Arbeitsverfahren reduzieren; Identitäts-, Stil- und globale Antwortformatregeln entfernen oder zur Persona beziehungsweise `SOUL.md` verschieben.
9. Carlo und Workspace gemeinsam gegen dieselbe Testpersona prüfen; Abweichungen zwischen Anzeige, Konfiguration und Laufzeit dokumentieren.
10. Erst nach Abnahme, Hashvergleich und dokumentiertem Rollback produktive Persona aktivieren.

## Backups und Rollback

Vor jeder produktiven Änderung werden Backups und SHA-256-Werte erstellt. Bei abweichendem Prompt, fehlender Persona, Sessionfehler, Profile-Konflikt oder Skill-Regression: Aktivierung stoppen, Backups zurückspielen, alte Personaquelle wiederherstellen und die Testsession verwerfen.

## Abnahmekriterien

- Eine Personaquelle ist eindeutig führend.
- `SOUL.md` enthält nur stabile Identität und Grundprinzipien.
- Profiles enthalten keine Identitätsregeln.
- Skills enthalten keine globale Persona- oder Stilsteuerung.
- Carlo und Workspace laden dieselbe Testpersona reproduzierbar.
- Neue Sessions und bestehende Sessions sind getrennt bewertet.
- Rollback wurde isoliert erfolgreich ausgeführt.

## Stop-Kriterien

Keine produktive Aktivierung bei unklarer führender Quelle, fehlendem Hashvergleich, abweichendem Prompt, nicht reproduzierbarem Personawechsel, Sessionfehlern oder unerwarteter Skillwirkung.
EOF
sha256sum "$R/ABSCHLUSSBERICHT.md" "$R/ZIELARCHITEKTUR.md" "$R/MIGRATIONSPLAN.md"