08 — Crew-System (PS-5)

English · Deutsch

Letzte Aktualisierung: 2026-06-04 (D-059: Auto-Crew — Abschnitt Kompositions-Run ergänzt)

Überblick

Das Crew-System ersetzt die in PS-2 hartkodierte Dreier-Crew (Executor + BriefingTreueReviewer + KlarheitReviewer) durch ein konfigurierbares Profil- und Template-System. Jeder Run erhält beim Einreichen einen vollständig eingebetteten CrewSnapshot, der die Reproduzierbarkeit des Runs auch dann garantiert, wenn Profile später geändert oder gelöscht werden.

Kernbegriffe

EvaluationStrategies

Hinweis: Bei Parallel ist die Reihenfolge in ReviewerProfileNames nur dokumentatorisch. Bei Sequential und Priority ist sie signifikant.

System-Profile (Code-Konstanten)

Definiert in Geef.Atelier.Core.Domain.Crew.SystemCrew (read-only, versioniert mit dem Code):

Provider/Modelle Stand Mai 2026 (nach der Umstellung auf die Subscription-CLIs, D-027/D-032): Executor und Anthropic-Reviewer laufen über claude-cli, die übrigen Reviewer über codex-cli. Modell-Pluralismus bleibt gewahrt (Reviewer ≠ Executor-Modell).

System-Templates (vier): klassik (Evaluation Parallel, keine Advisors — reproduziert das ursprüngliche PS-2-Verhalten) sowie die Domain-Templates juristisch (Sequential, Advisor legal-domain-expert), akademisch (Sequential, Advisor academic-rigor-advisor) und marketing (Parallel, keine Advisors).

Alle vier Standard-Templates liefern drei Standard-Grounding-Provider (tavily-basic, run-attachments, learning-retriever-default) und einen Standard-Finalizer (learning-extractor) aus. Einzige Ausnahme ist das learning-evaluation-Template — es enthält weder learning-retriever-default noch learning-extractor (Rekursionsstopp).

Custom-Profile

• Werden in der DB (ReviewerProfiles, ExecutorProfiles, CrewTemplates) gespeichert.
• Name erhält automatisch den Prefix "custom-" (idempotent, kein Doppelpräfix).
• System-Profile sind read-only: Update/Delete wirft InvalidOperationException("System profile is read-only — copy it as a custom variant.").
• API: ICrewService.CreateCustomReviewerProfileAsync(profile).

CrewSnapshot-Format (SchemaVersion 1)

Das folgende Beispiel zeigt die Struktur. Die provider/model-Werte sind illustrativ — die aktuell gültigen System-Werte stehen in der Tabelle „System-Profile" oben; ein realer Snapshot enthält die zum Submit-Zeitpunkt gültigen Werte.

{
  "schemaVersion": 1,
  "templateName": "klassik",
  "executor": {
    "name": "default-executor",
    "displayName": "Default Executor",
    "systemPrompt": "...",
    "provider": "openrouter",
    "model": "anthropic/claude-opus-4.7",
    "maxTokens": null,
    "isSystem": true
  },
  "reviewers": [
    { "name": "briefing-fidelity", "provider": "openrouter", "model": "google/gemini-2.5-flash", ... },
    { "name": "clarity",           "provider": "openrouter", "model": "openai/gpt-5.5-mini",    ... }
  ],
  "evaluationStrategy": "Parallel",
  "convergenceOverride": null,
  "advisors": []
}

Serialisiert mit JsonNamingPolicy.CamelCase. Gespeichert auf Runs.CrewSnapshot (JSONB).

Advisor-Pässe (PS-7)

Advisors sind konsultative LLM-Akteure, die zu definierten Zeitpunkten in der Pipeline ausgeführt werden. Ihr Output fließt als gekennzeichneter Kontext-Block in den Run — der Executor und nachfolgende Reviewer sehen ihn, ohne dass das Geef-SDK-Kern modifiziert werden muss.

AdvisorProfile-Schema

public sealed record AdvisorProfile(
    string Name, string DisplayName, string Description,
    string SystemPrompt, string Provider, string Model, int? MaxTokens,
    AdvisorMode Mode, AdvisorTrigger Trigger, bool IsSystem);

public enum AdvisorMode    { Strategic, Critical, DevilsAdvocate, DomainExpert }
public enum AdvisorTrigger { BeforeFirstExecution, BeforeEveryExecution, OnConvergenceFailure }

Trigger-Typen

System-Advisors

Provider/Modell Stand Mai 2026: alle System-Advisors laufen über claude-cli / claude-opus-4-7.

Pipeline-Integration via Decorator

Der AdvisorAwareExecutor (in Infrastructure/Pipeline/) dekoriert IExecutionStep und schiebt sich transparent vor jeden Executor-Aufruf:

AdvisorAwareExecutor.ExecuteAsync(context)
  1. Filtert Advisors nach aktivem Trigger (BeforeFirst nur bei Iteration 1, BeforeEvery immer)
  2. Ruft ProfileBasedAdvisor für jeden passenden Advisor sequenziell auf
  3. Schreibt Output als "[ADVISOR: <name>]\n<text>" in context[AtelierContextKeys.AdvisorBlock]
  4. Persistiert AdvisorConsultation-Record (Tabelle AdvisorConsultations)
  5. Delegiert an den echten IExecutionStep

AtelierPipelineFactory.BuildWithAdvisorContext(snapshot, context) wired den Decorator und stellt sicher, dass der Advisor-Block im IRunContext propagiert wird.

Advisor-Failure-Verhalten

Advisor-LLM-Calls sind nicht best-effort. Eine Exception in ProfileBasedAdvisor bubbled durch AdvisorAwareExecutor und bricht den Run mit Status=Failed ab (D-031(c)). Stiller Weiterlauf würde einen möglicherweise korrumpierten Kontext maskieren.

Convergence-Failure-Retry-Mechanismus

Pipeline → ConvergenceFailedException
  → RunOrchestratorService.TryConvergenceFailureRetryAsync
      1. Prüft RunEntity.AdvisorRetryAttempted — true → eskaliert zu Failed (kein zweiter Retry)
      2. Setzt AdvisorRetryAttempted = true in DB
      3. Aktiviert OnConvergenceFailure-Advisors im nächsten Run-Kontext
      4. Startet Pipeline-Durchlauf erneut (einmalig)
      5. Zweites ConvergenceFailedException → Failed (kein weiterer Retry)

Single-Retry-Cap: RunEntity.AdvisorRetryAttempted (Migration Step11) verhindert Endlos-Schleifen. Multi-Retry mit konfigurierbarer Wiederholungsanzahl ist als Future Work dokumentiert.

DB-Tabellen (Migration Step11AdvisorSystem)

Spalte RunEntity.AdvisorRetryAttempted (bool, nullable) auf Runs-Tabelle.

UI-Komponenten (PS-7)

ProfileEditorForm wurde um ShowAdvisorFields + Mode/Trigger Radio-Groups erweitert (wiederverwendbar für Reviewer, Executor und Advisor).

MCP-Tool

list_advisor_profiles — listet alle Advisor-Profile (System + Custom).

Finalizer-Profile (Step22 / D-044)

Finalizer sind Nachverarbeitungs-Akteure, die nach Abschluss der GEEF-Convergence-Schleife ausgeführt werden (oder, optional, wenn diese scheitert). Sie transformieren oder exportieren den Abschluss-Draft und erzeugen dabei RunArtifact-Datensätze.

FinalizerProfile-Schema

public sealed record FinalizerProfile(
    string Name, string DisplayName, string Description,
    FinalizerType FinalizerType, Dictionary<string, string> Settings,
    bool IsSystem, DateTime CreatedAt, DateTime UpdatedAt);

public enum FinalizerType
{
    FileExport    = 0,
    MetadataEnrich = 1,
    ExternalSink  = 2,
    Transform     = 3,
}

FinalizerType ist nach der Erstellung unveränderlich. Typisierte Settings-Records (FileExportSettings, MetadataEnrichSettings, WebhookSinkSettings, EmailSinkSettings, TransformSettings) kapseln das Dictionary<string,string> Settings für typsicheren Zugriff.

Pipeline-Position

Finalizer laufen sequenziell in der in CrewTemplate.FinalizerProfileNames festgelegten Reihenfolge, nachdem die Convergence-Schleife beendet wurde. Das Flag CrewTemplate.RunFinalizersOnMaxAttempts steuert, ob Finalizer auch bei einem Convergence-Failure (Max-Attempts überschritten) ausgeführt werden.

RunArtifact-Entity

Jede Finalizer-Ausführung hinterlässt einen RunArtifact-Datensatz:

System-Finalizer-Profile (17)

DB-Tabellen (Migration Step22)

Neue Spalten in bestehenden Tabellen:

UI-Komponenten (Step22)

Der CrewTemplateEditor wurde um einen FinalizerPicker und den RunFinalizersOnMaxAttempts-Toggle erweitert.

MCP-Tools (Step22)

• list_run_artifacts — listet alle Artefakte, die für einen bestimmten Run erzeugt wurden.
• download_run_artifact — lädt ein bestimmtes Run-Artefakt herunter (Owner-Check + Path-Containment erzwungen).

API-Pfade

Template-basierter Submit (Standard)

await runService.SubmitRunAsync(
    briefingText: "...",
    configJson:   "{}",
    crewTemplateName: "klassik");  // null → Standard "klassik"

Custom-Crew-Submit

var spec = new CrewSpec(
    ExecutorProfileName:  "custom-my-executor",
    ReviewerProfileNames: ["briefing-fidelity", "custom-my-reviewer"],
    EvaluationStrategy:   EvaluationStrategy.Sequential,
    ConvergenceOverride:  new ConvergencePolicyOverride(MaxIterations: 3, null, null, null));

await runService.SubmitRunAsync("...", "{}", customCrew: spec);

MCP-Tools

• list_crew_templates — listet alle Templates (System + Custom).
• list_reviewer_profiles — listet alle Reviewer-Profile (System + Custom).
• list_advisor_profiles — listet alle Advisor-Profile (System + Custom).
• list_grounding_provider_profiles — listet alle Grounding-Provider-Profile.
• list_run_artifacts — listet alle Artefakte, die für einen bestimmten Run erzeugt wurden.
• download_run_artifact — lädt ein bestimmtes Run-Artefakt herunter (Owner-Check + Path-Containment erzwungen).
• submit_request — erweitert um crew_template und custom_crew (JSON-String).

Vollständige Tool-Liste (15 Tools): siehe 09-endpoint-reference.md und die Projekt-README.

Grounding-Provider-Profile (D-036 / D-040 / D-051)

Grounding-Provider reichern das Briefing vor der GEEF-Ausführungsschleife mit externem Kontext an.

Provider-Typen

SSRF-Schutz (url-fetch)

Die UrlSafetyValidator-Komponente wird vor jedem HTTP-Request beim url-fetch-Provider ausgeführt:

• Schema-Check: Nur http und https. Alle anderen (file://, ftp://, custom) → blockiert.
• DNS-Auflösung: Jeder Hostname wird via Dns.GetHostAddressesAsync aufgelöst; alle resultierenden IPs werden geprüft (nicht nur die erste).
• IPv4-Blockliste: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 (Link-Local + Cloud-Metadata), 0.0.0.0/8, 100.64.0.0/10, 224.0.0.0/4
• IPv6-Blockliste: ::1, fc00::/7, fe80::/10, ff00::/8, 64:ff9b::/96, IPv4-mapped IPv6 (entpackt und erneut geprüft)
• Redirect-Kette: Max. 3 Hops; jede Redirect-Ziel-IP wird erneut gegen die vollständige Blockliste geprüft.
• Timeout: 10 Sekunden hard-cap pro Request; Response-Body auf 5 MB begrenzt.

Blockierte oder fehlgeschlagene URLs werden übersprungen (Warnung geloggt, in Source-Citation vermerkt); der Run selbst wird nicht abgebrochen.

KI-Refinement

Jeder Grounding-Provider kann optional mit einem KI-Refinement-Pass konfiguriert werden. Nach dem Fetch läuft — wenn konfiguriert — ein LLM über die Rohergebnisse.

Konfiguration (flache Keys in ProviderSettings):

Modi:

• Filter (Standard): Jede Quelle wird einzeln behalten oder verworfen. Attribution bleibt 1:1 erhalten.
• Synthesize: Alle Quellen werden zu einem kohärenten Text zusammengefasst ([n]-Referenzen). Originalquellen bleiben als Referenz-Anhang erhalten.

Graceful Degradation: Ist der Refinement-Anbieter inaktiv oder schlägt der LLM-Call fehl, werden die Rohergebnisse unverändert durchgereicht. Der Run wird nicht abgebrochen. Die Grounding-Visualisierung zeigt einen Hinweis.

System-Profil tavily-news: Neu — Tavily-Newssuche (topic=news, recencyDays=7) mit Filter-Refinement via google/gemini-2.0-flash-lite. Geeignet für zeitkritische Themen.

System-Profil tavily-refined: Sofort nutzbares Demo-Profil — Tavily Advanced mit Filter-Refinement via google/gemini-2.0-flash-lite.

Reviewer-Name-Migration

Migration Step10 benennt historische Findings.ReviewerName-Werte um. ReviewerDisplay.ToDisplay() enthält beide Varianten als Fallback.

Systemtrennung (Namespace)

• Core/Domain/Crew/ — alle Domain-Records (keine Infrastruktur-Abhängigkeit).
• Core/Domain/Crew/SystemPrompts.cs — System-Prompt-Texte (lang, gehören semantisch zu System-Profilen).
• Infrastructure/Pipeline/ProfileBasedReviewer.cs / ProfileBasedExecutor.cs — Geef-SDK-Adapter.
• Application/Crew/CrewService.cs + CrewSnapshotBuilder.cs — orchestriert Repo-Lookups + Snapshot-Konstruktion.

PS-6 — UI-Pfade und Konventionen

Routing-Map

UI-Komponenten

Name-Constraints

Pattern ^[a-z0-9\-]+$, max 64 Zeichen — gilt für alle Profile- und Template-Namen (Custom-Prefix exkl.). Form-Validierung via DataAnnotations.RegularExpression. Service-Layer ist idempotent bzgl. custom--Prefix.

Template Studio (D-043)

Das Template Studio unter /crew/studio ist ein KI-gestützter Wizard, der für eine beschriebene Aufgabe eine vollständige Crew-Konfiguration vorschlägt. Der Nutzer kann jeden Vorschlag im Edit-Step prüfen und bearbeiten, bevor er in die DB materialisiert wird.

Wizard-Schritte

Analyse-Pipeline (AnalyzeAsync)

TemplateStudioService.AnalyzeAsync verwandelt die Freitext-Aufgabenbeschreibung in eine persistierte TemplateStudioAnalysis, die den Review- und Edit-Step speist. Die Pipeline:

1. Modell-Auflösung — wählt das Meta-LLM in der Reihenfolge: expliziter Pro-Analyse-Override → persistierter Studio-Default (StudioSettings) → appsettings-Default (TemplateStudioOptions).
2. Kontext-Aufbau (parallel, budgetiert) — lädt alle Crew-Listen (Templates, Executors, Reviewer, Advisors, Grounding-Provider, Finalizer) und ruft die Modell-Kataloge aller Provider parallel unter einem 20-Sekunden-Budget ab. Ein langsamer oder nicht erreichbarer Provider liefert keine Modelle, statt die gesamte Analyse zu blockieren; empfohlene Modelle werden zuerst gelistet, damit das LLM gültige IDs wählt.
3. Meta-LLM-Aufruf (Timeout-gedeckelt) — ruft das Modell mit dem über tool_choice erzwungenen Tool submit_template_proposal auf. Ein Hard-Cap (TemplateStudioOptions.AnalysisTimeoutSeconds) wandelt einen hängenden Provider in eine TimeoutException mit Retry-Hinweis. Eine Antwort ohne Tool-Aufruf löst eine InvalidOperationException aus.
4. Vorschlags-Parsing — ParseProposal liest das Tool-Call-JSON in MatchedExistingTemplates, eine StudioRecommendation (use_existing / adapt_existing / create_new), das ProposedTemplate sowie die Liste der ProposedProfile-Records (jeweils mit feldbezogenen LLM-Begründungen).
5. Defaults & Clamping — ApplyDefaults füllt leere Provider/Modell/MaxTokens pro Profiltyp aus StudioDefaults. ClampMaxTokens erzwingt den MinMaxTokens-Floor für generierende Profile (Executor, Reviewer, Advisor) und setzt null für Grounding-/Finalizer-Profile (keine eigene LLM-Generierung).
6. Deduplizierung — ProfileSimilarityService.FindSimilarAsync verwirft vorgeschlagene Profile, die einem bestehenden zu ähnlich sind (Ähnlichkeit über Name + Prompt, TemplateStudioOptions.SimilarityThreshold).
7. Kosten & Persistierung — Input-/Output-Tokens werden über IPricingCatalog bepreist; die vollständige Analyse (inkl. Kosten in EUR) wird über ITemplateStudioAnalysisRepository gespeichert und zurückgegeben. ListRecentAnalysesAsync stellt die Historie bereit (siehe StudioAnalysisHistoryList).

StudioEditStep — Feld-Parität (D-043)

Der Edit-Step exponiert das vollständige Feld-Set für das Template und jeden Profil-Slot:

Template-Felder: DisplayName, Description, EvaluationStrategy (Dropdown), EvaluationStrategyReasoning (read-only, vom LLM)

Pro Profil-Slot (Executor / Reviewer × N / Advisor × N / GroundingProvider × N / Finalizer × N):

• UseExisting / CreateNew Toggle — bestehendes Profil per Name wählen oder neues Profil inline konfigurieren
• CreateNew-Felder: Name (kebab-case), DisplayName, Description, Provider, Modell (ModelSelector), MaxTokens, System-Prompt
• Reviewer-spezifisch: ReviewerFocus (optional)
• Advisor-spezifisch: AdvisorMode (Strategic / Critical / DevilsAdvocate), AdvisorTrigger (BeforeFirstExecution / BeforeEveryExecution / OnConvergenceFailure)
• GroundingProvider-spezifisch: GroundingProviderType (Tavily / VectorStore), Typ-spezifische Einstellungen (API-Key oder Collection-Name)
• Finalizer-spezifisch: FinalizerType (FileExport / MetadataEnrich / ExternalSink / Transform), Typ-spezifische Einstellungen
• Reasoning-Anzeige: LLM-Begründungen pro Feld, read-only (aus analyze_template_proposal)
• Field-Helps: Englische Inline-Hinweise für jedes Feld (StudioFieldHelps.cs)

Schlüssel-Komponenten

Materialisierung (atomar, D-043/7)

TemplateStudioService.MaterializeAsync kapselt alle DB-Schreibvorgänge in einer einzelnen EF-Core-Transaktion (IAtomicTransactionFactory) und gibt ein MaterializationResult zurück (finaler Template-Name, angelegte Profil-Namen, Warnungen).

Validierung vor der Transaktion:

• ValidateNotSystemProfiles — vorgeschlagene Profil-Namen dürfen nicht mit system-reservierten Namen kollidieren.
• ValidateReviewerCount — das Template muss mindestens einen Reviewer tragen.
• ValidateAvailabilityAsync — prüft das Modell jedes generierenden Profils gegen den Provider-Katalog; eine Abweichung erzeugt eine nicht-blockierende Warnung (das Modell fehlt evtl. nur im Live-Katalog), keinen Abbruch.

Transaktions-Ablauf: Begin → Profile anlegen (Executor, Reviewer, Advisor, GroundingProvider, Finalizer) via CreateProfileAsync → Template anlegen via CreateTemplateAsync → MarkMaterializedAsync (markiert den Analyse-Datensatz als verbraucht) → Commit. Jeder Fehler löst ein explizites Rollback aus — kein halb-materialisierter Zustand.

Name-Mapping: CreateCustom*Async präfixiert jeden neuen Profil-Namen idempotent mit custom-. MaterializeAsync merkt sich das Mapping alt→final, und ApplyProfileNameMapping schreibt alle Template-Referenzen (Executor, Reviewer, Advisors, Grounding-Provider, Finalizer) auf die tatsächlich gespeicherten Namen um, bevor das Template angelegt wird. Namen, die bereits auf bestehende Profile zeigen, bleiben unverändert. Die Evaluation-Strategie wird normalisiert (NormalizeEvaluationStrategy, Default Sequential).

Finalizer-Vorschläge erscheinen in der LLM-Analyse-Ausgabe des Studios; CreateProfileAsync behandelt den Finalizer-Zweig; StudioEditStep stellt den Finalizer-Slot-Abschnitt neben den übrigen Profil-Slots bereit.

Kontinuierlicher Lernzyklus (D-054)

Architektur

NORMALER RUN  →  Finalizer „learning-extractor" (opt-in)
   ├─ Guard: run.Kind == Learning → return       (Rekursions-Stopp #1)
   ├─ Schwelle: ≥ 2 Iterationen ODER Major+-Finding
   ├─ Strukturierte Fakten → LearningEntry (Proposed)
   └─ FIRE-AND-FORGET: SubmitRunAsync(crew=learning-evaluation, Kind=Learning)

LEARNING-RUN  (Kind=Learning, Crew „learning-evaluation")
   ├─ Executor kondensiert Kandidat
   ├─ 3 strenge Reviewer (AbortOnCritical=true, MaxIterations=2)
   └─ Finalizer „learning-publisher" (RunFinalizersOnMaxAttempts=true)
        ├─ Guard: run.Kind != Learning → return   (Rekursions-Stopp #2)
        ├─ Konvergenz  → Embedding berechnen, Approved, in Store schreiben
        └─ Nicht-Konv. → Rejected, nichts geschrieben

SPÄTERER RUN  →  Grounding „learning-retrieval"
   ├─ Embedding-Suche über Approved-Learnings
   ├─ Domänen-Boost: finalScore = similarity × (sameDomain ? boost : penalty)
   ├─ Kuratiertes Wissen (vector-store) schlägt Learnings per Provider-Reihenfolge
   └─ SourceCitation: learning://{id}

RunKind-Enum

Standard = 0 (Standard) / Learning = 1 / CrewComposition = 2. In RunEntity.Kind geführt, durch SubmitRunRequest.Kind und IRunPersistenceService.CreateRunAsync durchgereicht. Der Orchestrator dispatcht alle drei Arten identisch; das Kind gatet Finalizer-Wächter und Rekursionsstopps.

LearningEntry-Lebenszyklus

Proposed (Extractor) → Approved (Publisher + Embedding) oder Rejected (Publisher, nichts gespeichert). Manuelles Override über /crew/learnings (Owner-Check).

System-Profile (Migration Step30)

Auto-Crew: Kompositions-Run

Ein Kompositions-Run (RunKind.CrewComposition = 2) ist ein vollständiger GEEF-Run, der die GEEF-Evaluierungsschleife nutzt, um eine neue Crew zu komponieren. GEEF-on-GEEF: die Meta-Crew crew-composer durchläuft Draft → Critique → Refine → Converge und materialisiert das Ergebnis anschließend über den crew-materializer-Finalizer. Siehe D-059 im Decisions-Log.

Was ein Kompositions-Run ist

Der Single-Pass-Meta-LLM-Aufruf des Template Studios (D-038) produzierte Crews ohne Selbstkorrektur. Ein Kompositions-Run ersetzt diesen Aufruf durch eine echte GEEF-Pipeline: die Crew crew-composer verfeinert ein CrewSpecArtifact-JSON iterativ bis zur Konvergenz; danach wandelt der CrewMaterializeFinalizerExecutor das konvergierte Spec in echte DB-Datensätze um.

Einstiegspunkt: /crew/studio (eigenständige Komposition, ChainToTaskRun = false als Standard). Der Nutzer gibt eine Aufgabenbeschreibung ein; das Studio reicht einen RunKind.CrewComposition-Run ein und zeigt den Fortschritt via SignalR.

Die 5 Reviewer von crew-composer

Der deterministische CrewSpecValidatorReviewer erzeugt Findings ohne LLM-Call und ist das primäre strukturelle Gate. Die vier LLM-Reviewer laufen in der Parallel-Strategie.

ConvergenceOverride: MaxIterations = 4, AbortOnCritical = false (damit Validator-Critical-Findings korrigiert werden können, statt einen Abbruch auszulösen), StagnationThreshold = 3.

CrewSpecArtifact-Schema

Der CrewComposerExecutor erzwingt den Tool-Call submit_crew_spec — kein Freitext-Output. Das resultierende JSON folgt diesem Schema:

{
  "mode": "existing-template | composed | new",
  "reuse": "<Template-Name oder null>",
  "executor": {
    "name": "...", "provider": "...", "model": "...",
    "systemPrompt": "...", "maxTokens": null
  },
  "reviewers": [
    { "name": "...", "provider": "...", "model": "...",
      "systemPrompt": "...", "focus": "..." }
  ],
  "advisors": [
    { "name": "...", "mode": "Strategic|Critical|DevilsAdvocate|DomainExpert",
      "trigger": "BeforeFirstExecution|BeforeEveryExecution|OnConvergenceFailure",
      "systemPrompt": "..." }
  ],
  "grounding": ["<Profilname>", "..."],
  "finalizers": ["<Profilname>", "..."],
  "evaluationStrategy": "Parallel | Sequential | FailFast | Priority",
  "convergenceOverride": null
}

Modus-Semantik:

• existing-template — bestehendes Template per Name wiederverwenden (reuse-Feld); keine DB-Schreibvorgänge.
• composed — neues Template auf Basis des reuse-Templates mit Änderungen zusammensetzen.
• new — vollständig neues Template aus den Spec-Feldern anlegen; alle Profile müssen vollständig spezifiziert sein.

Das reuse-Feld kodiert das Dedup-Ergebnis: findet CrewMaterializeFinalizerExecutor in CrewTemplateEmbeddings ein Template mit Cosine-Similarity ≥ 0,90, wird der Modus auf existing-template downgegradet und reuse auf den gematchten Template-Namen gesetzt.

Schritte des CrewMaterializeFinalizerExecutor

Läuft nach Konvergenz des Kompositions-Runs (FinalizerType.CrewMaterialize = 6):

1. Parse — liest das CrewSpecArtifact-JSON aus dem ArtifactText der letzten Iteration.
2. Validate — strukturelle Prüfung: Pflichtfelder vorhanden, reviewers-Anzahl ≥ 1, Provider-Namen im System aktiv.
3. Dedup — berechnet ein Embedding des Specs, fragt CrewTemplateEmbeddings auf Cosine-Similarity ab; überschreitet ein bestehendes Template die 0,90-Schwelle, wird der Modus auf existing-template downgegradet (keine neuen DB-Datensätze).
4. Materialize — für Modi composed / new: legt Profile (Executor, Reviewer × N, Advisor × N, GroundingProvider × N, Finalizer × N) und das Crew-Template in einer einzigen EF-Core-Transaktion an (analog TemplateStudioService.MaterializeAsync).
5. Embed — berechnet ein Embedding des neuen Templates und schreibt es in CrewTemplateEmbeddings für künftige Dedup-Prüfungen.
6. Task-Run verketten — wenn ChainToTaskRun = true und der Kompositions-Run ein Seed-Briefing enthält, wird ein neuer RunKind.Standard-Run mit der materialisierten Crew und dem ursprünglichen Briefing eingereicht.

ParentCompositionRunId-Audit-Link

Wird ein Task-Run aus einem Kompositions-Run verkettet, wird Runs.ParentCompositionRunId auf die ID des Kompositions-Runs gesetzt. Das ergibt einen vollständigen Audit-Trail: ausgehend von einem beliebigen Task-Run lässt sich über ParentCompositionRunId der Kompositions-Run nachvollziehen, der seine Crew erzeugt hat.

Wächter (Guards)

• LearningExtractFinalizerExecutor: if (run.Kind == RunKind.CrewComposition) return Ok; — aus Kompositions-Runs werden keine Learnings extrahiert.
• CrewMaterializeFinalizerExecutor: der verkettete Run ist stets RunKind.Standard; verschachtelte Komposition ist nicht möglich.
• CrewComposerExecutor: nur für Kind == CrewComposition aktiv; andere Run-Arten werden abgewiesen.