302 lines
17 KiB
Markdown
302 lines
17 KiB
Markdown
# Roadmap
|
||
|
||
Zentrale Liste aller offenen Vorhaben. Sie löst die beiden „Vorgeschlagene
|
||
Reihenfolge"-Abschnitte in der [Bestandsaufnahme](Bestandsaufnahme-2026-07.md) und im
|
||
[Konzepte-Dokument](Konzepte-Backup-Finanz-Analyse.md) ab — die bleiben als Befund bzw.
|
||
Konzept bestehen, gepflegt wird nur noch hier.
|
||
|
||
Kürzel (S4, K2, T4, F-A1, …) verweisen auf die Bestandsaufnahme.
|
||
|
||
---
|
||
|
||
## A — Beschlossen (aus dem OpenAlice-Vergleich, Juli 2026)
|
||
|
||
Hintergrund: Konzeptvergleich mit [OpenAlice](https://github.com/TraderAlice/OpenAlice)
|
||
(AGPL-3.0 — Konzepte übernehmen ja, Code nein). Übernommen werden Taskboard,
|
||
Staging-Freigabe, Audit-Log und das Skill-Modell. Die Inbox-Idee entfällt zugunsten
|
||
der geplanten Matrix-Migration (A5).
|
||
|
||
### A1 — Taskboard
|
||
|
||
Aufgaben als Markdown-Dateien mit YAML-Frontmatter im `SharedWorkspace`:
|
||
`title`, `status` (`backlog | todo | in_progress | done | canceled`), `priority`,
|
||
`assignee`, optional `when` (`at` | `every` | `cron` **mit Zeitzone**).
|
||
|
||
- **Scanner statt Delay-Schleifen**: Ein Takt (~60 s) prüft, was fällig ist.
|
||
Persistiert werden nur Last-Fired-Marker — ein fehlgeschlagener Lauf bleibt der
|
||
einzige Versuch für diesen Termin, kein automatischer Retry-Sturm.
|
||
- **Assignee bestimmt die Ausführung**: `@new` = frischer Lauf ohne Historie,
|
||
`@<agent>` = bestehender Agent mit seinem Kontext, `@human` = wartet auf uns.
|
||
Das ersetzt das implizite `UseChatContext`-Flag (T7) durch eine explizite Angabe
|
||
am Auftrag.
|
||
- **Agenten-Tool**: `task_create`, `task_list`, `task_update`, `task_comment`.
|
||
Agent-zu-Agent-Delegation läuft künftig über Tasks statt über rekursives
|
||
`send_message`.
|
||
- **Migration**: Die improvisierten `coordination/*.md`-Dateien der Agenten
|
||
(task_*, status_*, broadcast) gehen im Taskboard auf.
|
||
|
||
**Detailbauplan** (aus dem Fünf-Repo-Vergleich, Juli 2026 beschlossen):
|
||
|
||
- Status zusätzlich mit **`in_review`**; im Frontmatter **`require_approval`**
|
||
(Task gilt erst nach Review als done) und **`acceptance`** (Abnahmekriterien,
|
||
gegen die das Ergebnis geprüft wird).
|
||
- **Task-Typen `approval` und `human_input`** — ein Mensch ist einfach ein
|
||
Assignee; seine Antwort ist das Task-Ergebnis und Input für Folgetasks.
|
||
- **Atomares Claiming**: Die DB verhindert, dass zwei Läufe denselben Task
|
||
ziehen. Der Scanner arbeitet mit **Claim-before-run** (at-most-once — ein
|
||
doppelter Tick findet den Claim bereits vergeben) und
|
||
**Startup-Reconciliation**: Beim Start wird Soll (Frontmatter) gegen Ist
|
||
(Marker/Claims) abgeglichen, verpasste Läufe werden erkannt statt still
|
||
übersprungen.
|
||
- **`blocked_by`-Abhängigkeiten** mit Auto-Dispatch: Wird der letzte Blocker
|
||
fertig, wird der wartende Task automatisch angestoßen. Meldet ein Agent einen
|
||
Blocker, fällt der Task und der Zuständige (Lead/Benutzer) wird benachrichtigt
|
||
(**Blocker-Eskalation**).
|
||
- **Reopen-/Feedback-Semantik**: Ergebnis + Kritik gehen per `task_comment` an
|
||
denselben Agenten zur Nachbesserung zurück, statt einen neuen Task von vorn
|
||
zu beginnen.
|
||
|
||
Damit erledigt oder aufgegangen:
|
||
|
||
| Punkt | Warum |
|
||
|---|---|
|
||
| F-A5 Task-Queue | das Taskboard **ist** die Queue |
|
||
| F-A4 Run-Historie | Läufe werden am Task verknüpft und persistiert |
|
||
| B8 Rekursion `send_message` | Delegation über Tasks ist strukturell zyklenfrei |
|
||
| B6 `Task.Delay`-Überlauf | Scanner-Modell kennt keine langen Delays |
|
||
| B7 Cron in Lokalzeit | Frontmatter-`when` ist zeitzonen-explizit |
|
||
| T7 `RunAsync` vs. `ChatAsync` | Assignee-Semantik beantwortet die Frage |
|
||
|
||
Verzahnung: Das Marktkalender-Flag (`onlyWhenMarketOpen`, siehe C1) gehört ins
|
||
Frontmatter, nicht in einen eigenen Mechanismus.
|
||
|
||
Konzept-Doc: [Taskboard-Konzept](Taskboard-Konzept.md) (Dateiformat,
|
||
Wahrheitsaufteilung Datei/DB, Scanner-Verhalten, Invarianten, Migration).
|
||
|
||
### A2 — Staging-Freigabe für irreversible Aktionen (F-A1 + S4)
|
||
|
||
Konzept-Doc: [Staging-Konzept](Staging-Konzept.md).
|
||
|
||
Irreversible Aktionen (Mail senden, X posten, DB-Schreibzugriff, Datei löschen,
|
||
perspektivisch Orders) werden **gestaged statt ausgeführt**: Vorschlag → Review im
|
||
Hauptfenster → Freigabe/Ablehnung. Pro Tool/Aktion konfigurierbar:
|
||
`auto | approve | deny`.
|
||
|
||
Das bisher wirkungslose `PermissionGate` (S4) wird dabei zum zentralen
|
||
Durchsetzungspunkt ausgebaut: Policy-Prüfung, Staging-Entscheidung und Audit-Hook
|
||
(A3) an einer Stelle statt ad-hoc in jedem Tool. S4 wird nicht separat bearbeitet,
|
||
sondern geht hier auf.
|
||
|
||
Ergänzungen (Juli 2026 beschlossen):
|
||
|
||
- **Plan-Freeze**: Freigegeben wird ein eingefrorener, konkreter Aufruf — Tool,
|
||
Aktion und exakte Argumente zum Zeitpunkt des Stagings. Ausgeführt wird genau
|
||
das Eingefrorene; jede nachträgliche Änderung ist eine neue Freigabe.
|
||
- **Approval-Records**: Jede Entscheidung (Freigabe wie Ablehnung) wird als
|
||
Datensatz im Audit-Log (A3) verankert — wer, wann, was, mit welchem Ergebnis.
|
||
|
||
Sicherheitswirkung: Eine Prompt-Injection (K2) kann dann nur noch einen Vorschlag
|
||
erzeugen, keine Ausführung.
|
||
|
||
### A3 — Audit-Log (F-A2)
|
||
|
||
Konzept-Doc: [Audit-Konzept](Audit-Konzept.md).
|
||
|
||
Jeder Tool-Aufruf wird protokolliert: Agent, Lauf/Session, Zeitstempel, Argumente,
|
||
Ergebnis-Status. Append-only (JSONL oder SQLite-Tabelle auf dem vorhandenen
|
||
`SqliteStorage`).
|
||
|
||
Designregeln (aus dem OpenAlice-Provenance-Konzept):
|
||
|
||
- Herkunft wird **von der Engine gestempelt**, nie vom Agenten behauptet.
|
||
- Einträge sind unveränderlich; Korrekturen sind neue Einträge.
|
||
- Unbekannte Herkunft wird als unbekannt markiert, nicht geraten.
|
||
- Worker-Typ (Modell/Engine) und verantwortliche Session sind getrennte Begriffe.
|
||
|
||
Ergänzung (Juli 2026 beschlossen) — **Receipts**: Jeder abgeschlossene Task/Lauf
|
||
erhält einen Abschluss-Beleg mit Ergebnis-Verweis, Schritten, Tokens und Kosten
|
||
(Verknüpfung `RunUsage` ↔ Task). Damit fällt C7 („Kosten pro Ergebnis")
|
||
weitgehend als Abfallprodukt ab.
|
||
|
||
Das Audit-Log ist zugleich das Fundament für das Ergebnisregister (C7) und die
|
||
Tool-Fehlerquote aus der Leistungsanalyse.
|
||
|
||
### A4 — Skill-/Toolset-Modell (ersetzt T6)
|
||
|
||
Dreischichtig statt „alles immer im System-Prompt":
|
||
|
||
1. **Dauerhafter Kern** — Identity, Soul, unveränderliche Regeln. Schlank, damit der
|
||
Prompt-Cache (T1) stabil bleibt.
|
||
2. **Nachladbare Skills/Toolsets** — fachliche Abläufe und selten genutzte Tools
|
||
werden erst auf Anforderung geladen (`list_toolsets` → `load_toolset`).
|
||
3. **Selbstkorrigierende Tool-Fehler** — Fehlermeldungen nennen die gültigen
|
||
Parameter/Aktionen, statt das Modell raten zu lassen.
|
||
|
||
Mechanik (Juli 2026 beschlossen, nach GoClaw-Vorbild): Skills liegen als
|
||
`SKILL.md` mit Frontmatter (`name`, `description`) im Instanz- bzw.
|
||
Agenten-Verzeichnis. Bei wenigen Skills werden die Kurzbeschreibungen inline in
|
||
den Prompt eingebettet, bei vielen gibt es stattdessen ein `skill_search`-Tool.
|
||
Änderungen an Skill-Dateien werden per Hot-Reload übernommen.
|
||
|
||
Dazu Hermes' Selbstverbesserungs-Idee: **Agenten dürfen Skills aus Erfahrung
|
||
selbst schreiben** (das AgentEditor-Tool ist die Vorstufe). Wichtig: Ein Skill
|
||
ist Prompt-Input — agentengeschriebene Skills werden erst nach Freigabe (A2)
|
||
aktiv, sonst wäre das ein Injection-Kanal in künftige Läufe.
|
||
|
||
### A5 — Matrix/Element-Migration
|
||
|
||
Beschlossene Richtung: Die Kommunikation (Benachrichtigungen, Berichte, Chat mit
|
||
Agenten) wird auf Element/Matrix umgestellt.
|
||
|
||
- Ersetzt die im OpenAlice-Vergleich erwogene Inbox — Berichte landen in
|
||
Matrix-Räumen.
|
||
- Der Tool-Kandidat **Notify** entfällt und geht hierin auf.
|
||
- Betroffen: Telegram-Tool (Rolle klären), WebView-Chat (bleibt er Haupt-UI?),
|
||
Streaming K4 (Matrix streamt nicht — nach dieser Entscheidung neu bewerten).
|
||
|
||
Scope ist noch unbestimmt — braucht ein eigenes Konzept-Doc, bevor es in die
|
||
Reihenfolge eingeordnet wird.
|
||
|
||
### A6 — MySQL-Replikations-Spiegel (optional)
|
||
|
||
Beschlossen Juli 2026. **SQLite bleibt die einzige Wahrheit** — gearbeitet wird
|
||
ausschließlich auf der Instanz-DB. MySQL ist ein reiner, nachgelagerter Spiegel:
|
||
Er empfängt nur INSERT/UPDATE/DELETE vom Replikator; die App liest im Betrieb
|
||
**nie** daraus. Einziger Lesezweck: Wiederherstellung, falls die SQLite korrupt
|
||
ist — daneben steht der Spiegel externen Auswertungen (Dashboards, Ad-hoc-SQL)
|
||
offen, ohne die Agenten-Maschine zu berühren.
|
||
|
||
Leitplanken:
|
||
|
||
- **Outbox-Muster** an der vorhandenen Schreib-Warteschlange von `SqliteStorage`:
|
||
Replikations-Einträge lokal puffern, idempotente Upserts nach MySQL.
|
||
Nie blockierend — ist MySQL nicht erreichbar, staut die Outbox und holt auf.
|
||
- Mehrere Instanzen replizieren in denselben Spiegel; Zeilen tragen `instance_id`.
|
||
- **Restore-Pfad (Spiegel → frische SQLite) muss existieren und getestet sein** —
|
||
gleiche Regel wie beim Backup: ein ungeprüftes Restore ist eine Vermutung.
|
||
- Kein Koordinationspunkt: Claiming, Locks, Taskboard-Zustand bleiben lokal.
|
||
Die Regel „nur der Replikator schreibt, niemand liest im Betrieb" gehört ins
|
||
Konzept-Doc.
|
||
- Sicherheit: TLS zur Datenbank, Zugangsdaten über `SecretProtector`;
|
||
Output-Scrubbing der Tool-Ergebnisse wird wichtiger, weil Kontext-Daten
|
||
künftig auch im Spiegel liegen.
|
||
- Ergänzt das ZIP-Backup, ersetzt es nicht — Identity/Soul, Settings, Workspace
|
||
und Telegram-Session bleiben Sache des Instanz-Backups.
|
||
|
||
**Voraussetzung — Historie-Umzug:** `ChatHistory.json` zieht in die Instanz-DB um
|
||
(aktive Tabelle + Archiv-Tabelle mit FTS5-Volltextindex und `history_search`-Tool,
|
||
siehe K6 in Abschnitt B). Das löst
|
||
nebenbei B10 (O(n²)-Schreiblast) und gibt K6 seine Form; erst danach schützt der
|
||
Spiegel auch die Historie. Zeitlich passt A6 zu dem Server, der ggf. mit A5
|
||
(Matrix) ohnehin dazukommt.
|
||
|
||
---
|
||
|
||
## B — Offen aus der Bestandsaufnahme
|
||
|
||
| Punkt | Was | Stand |
|
||
|---|---|---|
|
||
| T4 | Proaktiv statt reaktiv kompaktieren | offen, unverändert |
|
||
| K2-Rest | Untrusted Content als Daten rahmen (`<untrusted_content>`) | A2 nimmt die Schärfe; die Rahmung selbst bleibt nötig |
|
||
| K4 | Streaming | **zurückgestellt** bis A5 entschieden ist |
|
||
| K6 | Historie **archivieren + durchsuchbar machen** (FTS5-Index, `history_search`-Tool) statt nur rotieren | beschlossen; Teil des Historie-Umzugs (Voraussetzung von A6) |
|
||
| Memory-Flush vor Compaction | Bevor der ContextCompactor zusammenfasst, bekommt der Agent ein eng begrenztes Fenster, Dauerhaftes per `memory_store` zu sichern — sonst wirft die Compaction Wissen weg | beschlossen (GoClaw-Muster) |
|
||
| Memory-Auto-Injection | Relevante Memory-Abstracts werden automatisch eingeblendet (Relevanzschwelle, Deckel ~200 Tokens), **in die Nutzernachricht, nie in den System-Prompt** (Prompt-Cache T1) | beschlossen; löst den offenen Punkt „Automatische Einblendung" im [Memory-Konzept](Memory-Konzept.md) |
|
||
| Output-Scrubbing | Bekannte Secret-Werte (Register des `SecretProtector`) werden zentral aus **allen** Tool-Ergebnissen maskiert, bevor sie in Kontext, Historie oder Spiegel (A6) gelangen | beschlossen; schließt die Lücke, die S3 nur für URLs schloss |
|
||
| Hygiene-Paket | B9 (`index_Count`-Race), B11/T8 (`max_tokens` setzen), B13 (`instanceId`-Inkonsistenz), F-A6-Rest (UI zum Setzen/Rotieren der Secrets) | Kleinbugs, in einem Aufwasch. B10 geht im Historie-Umzug (A6) auf |
|
||
|
||
Erledigt seit der letzten Fortschreibung: B4 vollständig (Preise kommen live vom
|
||
`/models`-Endpunkt, unbekannte Modelle werden sichtbar gemeldet).
|
||
|
||
### B-DC — Deploymentcenter-Anbindung
|
||
|
||
WatchDog und LicenseLabrador sind durch das
|
||
[Deploymentcenter](Deploymentcenter-Integration.md) ersetzt: eine Adresse, ein Token,
|
||
und dazu Update-Prüfung, Fehler-Stream und Bugtracker. Watchdog läuft wieder pro
|
||
Instanz (ein Monitor je Instanz, mit Gesundheitsprüfungen und angekündigtem Ende).
|
||
|
||
Offen:
|
||
|
||
| Punkt | Was | Bemerkung |
|
||
|---|---|---|
|
||
| DC1 | Oberfläche „Fehler melden" | Client vorhanden, Schaltfläche fehlt |
|
||
| DC2 | Agenten-Tool für den Bugtracker | macht den Claim/Lease-Workflow des Deploymentcenters nutzbar |
|
||
| DC3 | Release-Strecke: `pack-and-deploy` mit `<Version>` aufrufen, dann `update-agent` | ohne Release hat die Update-Prüfung nichts zu finden. Versionsnummer selbst ist erledigt (`Directory.Build.props` → `ReleaseInfo`) |
|
||
| DC4 | SDK als Git-Submodul unter `external/` statt Cross-Repo-Pfad | betrifft auch die CI |
|
||
| DC5 | Betreiber: Evaluator-Cron einrichten, Token ausstellen, `parent_source` pflegen | **ohne den Cron ist die Überwachung wertlos** |
|
||
|
||
---
|
||
|
||
## C — Offen aus dem Finanz-/Analyse-Konzept
|
||
|
||
Punkte 1–2 von dort (atomares Schreiben, Backup/Restore inkl. UI) sind umgesetzt.
|
||
|
||
| # | Was | Bemerkung |
|
||
|---|---|---|
|
||
| C1 | Marktkalender (`onlyWhenMarketOpen` + `MarketCalendar`-Tool) | Scheduler-Teil gehört ins Taskboard-Frontmatter (A1) |
|
||
| C2 | `Indicators`-Tool — deterministische Berechnung | Qualität hoch, Tokens runter |
|
||
| C3 | Datenaktualität erzwingen (`maxAgeSeconds`) | |
|
||
| C4 | Termine & Fundamentaldaten (Earnings, EDGAR, Wirtschaftskalender) | |
|
||
| C5 | Bestandsregister (Positionen) | Grundlage für C7/C8 |
|
||
| C6 | Nachrichten-Entdopplung (`SeenItems`) | |
|
||
| C7 | Ergebnisregister (Stufe 2, „Kosten pro Ergebnis") | fällt weitgehend aus den A3-Receipts ab |
|
||
| C8 | Falsifizierbare Aussagen + Auflösung, Brier-Score (Stufe 3) | braucht C5, C7 und einen Auflösungs-Task (A1) |
|
||
|
||
---
|
||
|
||
## D — Toolkandidaten (unbeschlossen)
|
||
|
||
WebSearch, Http (generisch mit Allowlist), Shell (sandboxed), Git, Vision.
|
||
Notify ist gestrichen — geht in A5 auf.
|
||
|
||
---
|
||
|
||
## Vorgeschlagene Reihenfolge
|
||
|
||
| # | Vorhaben | Begründung |
|
||
|---|---|---|
|
||
| 1 | A1 Taskboard | Fundament; löst sechs bestehende Punkte auf einmal |
|
||
| 2 | A3 Audit-Log | klein, sofort nützlich; muss vor A2 da sein, damit Freigaben protokolliert werden |
|
||
| 3 | A2 Staging-Freigabe | größter Sicherheitsgewinn; Voraussetzung für unbeaufsichtigten Betrieb |
|
||
| 4 | C1 Marktkalender | spart sofort Kosten; nutzt A1-Frontmatter |
|
||
| 5 | A4 Skills/Toolsets | Token-Hebel, Cache-stabil |
|
||
| 6 | C2 Indicators | Qualität + Kosten |
|
||
| 7 | C7 + C8 Ergebnisregister, Aussagen | das eigentliche Leistungsmaß; braucht A3 |
|
||
| — | Hygiene-Paket (B) | zwischendurch, unabhängig |
|
||
| — | Historie-Umzug in die Instanz-DB | löst B10 + K6; Voraussetzung für A6 |
|
||
| — | A6 MySQL-Spiegel | nach dem Historie-Umzug; natürliches Zuhause auf dem A5-Server |
|
||
| — | A5 Matrix | eigenes Konzept-Doc zuerst; Scope klären, dann einordnen |
|
||
|
||
Leitlinie der Reihung: erst Nachvollziehbarkeit und Kontrolle (Audit, Staging),
|
||
dann Fähigkeiten — ein Agent, der unbeaufsichtigt läuft, braucht zuerst Bremsen,
|
||
dann PS.
|
||
|
||
---
|
||
|
||
## Umsetzung mit Opus 4.6 — Einstufung
|
||
|
||
Die Entwicklung erfolgt mit Opus 4.6. Die meisten Vorhaben sind damit gut
|
||
machbar, sofern die hier notierten Vorgaben mitgegeben werden. Zwei Stellen
|
||
berühren Nebenläufigkeits-Invarianten bzw. Engine-Querschnitte — sie sind für
|
||
Opus 5 / Fable markiert oder durch eine Architektur-Vorgabe entschärft.
|
||
|
||
| Vorhaben | Einstufung | Vorgabe / Begründung |
|
||
|---|---|---|
|
||
| A1: Dateiformat, Frontmatter-Parsing, `task_*`-Tool, Migration | 4.6 | klar spezifizierbar, gut testbar |
|
||
| A1: **Scanner-Kern** (atomares Claiming, Auto-Dispatch, Reconciliation) | ⚠️ **Opus 5 / Fable** | At-most-once-Semantik, Claim-CAS und das Zusammenspiel mit den seit B2 serialisierten Chat-Läufen sind genau die Fehlerklasse, die hier schon einmal schiefging. Falls doch 4.6: erst Konzept-Doc, Umsetzung strikt dagegen, Property-Tests für die Invarianten („nie zwei Claims auf einen Task", „kein Dispatch bei offenem Blocker", „doppelter Tick = ein Lauf") |
|
||
| A2: Gate, Policy, Staging-Queue, Review-UI, Approval-Records | 4.6 | mit der folgenden Architektur-Vorgabe |
|
||
| A2: **Fortsetzung nach Freigabe** | 4.6 nur mit Vorgabe | **Kein pausierter, im Speicher gehaltener Lauf.** Vorgabe: Der Lauf endet beim Staging regulär — das Tool liefert „zur Freigabe vorgelegt" als Ergebnis, der Agent schließt ab. Die Freigabe erzeugt einen Folge-Task (A1), der den Agenten mit dem **eingefrorenen** Aufruf weckt. Echtes Suspend/Resume eines laufenden `ChatAsync` wäre Fable-Terrain — und ist mit dieser Vereinfachung unnötig |
|
||
| A3: Audit-Log + Receipts | 4.6 | append-only, klares Schema, keine Nebenläufigkeitsfallen |
|
||
| A4: Skills | 4.6 | `FileSystemWatcher` mit Debounce (~500 ms); agentengeschriebene Skills erst nach Freigabe aktiv (siehe A4) |
|
||
| Memory-Flush vor Compaction | 4.6 mit Anleitung | Harte Grenzen: max. 3–5 Schritte, einziges Tool `memory_store`, Timeout, günstiges Modell (wie T3), höchstens einmal je Compaction-Zyklus. Vorsicht: Der ContextCompactor hatte B1/B14 — die bestehenden Paarungs-Tests müssen unverändert grün bleiben |
|
||
| Memory-Auto-Injection | 4.6 | in die Nutzernachricht, nie in den System-Prompt (sonst verfällt der Prompt-Cache T1); Deckel ~200 Tokens |
|
||
| Output-Scrubbing | 4.6 | ein zentraler Filter an der Stelle, wo Tool-Ergebnisse in den Kontext gelangen (`ExecuteToolCallAsync`); Werte aus dem Secret-Register |
|
||
| Historie-Umzug + FTS5 + `history_search` | 4.6 | Migration nur nach frischem Backup; alte JSON-Dateien erst nach verifiziertem Import löschen |
|
||
| A6: MySQL-Spiegel | 4.6 mit Anleitung | Outbox mit Wasserzeichen, idempotente Upserts, nie blockieren; der getestete Restore-Pfad ist Teil der Definition of Done |
|
||
| C1 Marktkalender, C2 Indicators | 4.6 | reine Fachlogik, deterministisch testbar |
|
||
|
||
Generell: Neue Subsysteme (Scanner, Staging, Audit, Replikator) kommen mit Tests
|
||
nach der [Teststrategie](Teststrategie.md) — die Invarianten-Tests sind bei den
|
||
markierten Punkten kein Nice-to-have, sondern die Absicherung dafür, dass ein
|
||
schwächeres Modell sie umsetzen darf.
|