Remove obsolete chat logs and migrate relevant assets from docs/Neumarkt2026/ and docs/BilderSuDo/ to docs/80_Assets/. Update references and initiate consolidation of documentation.
This commit is contained in:
@@ -0,0 +1,124 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ARCHIVED
|
||||
owner: Lead Architect
|
||||
created: 2026-03-27
|
||||
source: ../temp/Caht-Verlauf_2026-03-27.md
|
||||
---
|
||||
|
||||
# Chat-Verlauf — 27. März 2026
|
||||
|
||||
Hinweis: Inhalt aus `docs/temp/Caht-Verlauf_2026-03-27.md` übernommen. Original belassen, bis die vollständige Migration abgeschlossen ist.
|
||||
|
||||
```text
|
||||
🏗️ [Lead Architect]
|
||||
Guten Morgen!
|
||||
Datum: 27. März 2026
|
||||
|
||||
In den letzten Tagen haben wir am Frontend gebastelt.
|
||||
Jetzt habe ich Angst, dass wir unseren Fokus verlieren.
|
||||
|
||||
Das Frontend und dessen Entwürfe sollten uns helfen die einzelnen Workflows praxisnah abzugrenzen. Daraus ergibt sich
|
||||
eine Domäne/Boundet-Context und dieses Wollen wir als eigenständigen Service entwickeln.
|
||||
Das Ping-Service sollte für uns quasi als Vorlage dienen, also komplett von der echten fachlichen Implementierung
|
||||
isoliert.
|
||||
Mittlerweile vermischen wir alles miteinander und das gefällt mir nicht.
|
||||
|
||||
Ich will für die ganzen technischen Implementierungen mit dessen Monitorings und Metriken ein eigenes isoliertes
|
||||
Frontend in dem dann auch das Ping-Service enthalten sein soll.
|
||||
|
||||
Aber, dadurch dass wir nicht mehr viel Zeit haben bis zum ersten Einsatz in Neumarkt, will ich die wichtigsten
|
||||
Grundlegende Funktionen bereits einsatzbereit haben, ohne dabei durch schlampiges husch pfusch eine saubere
|
||||
Weiterentwicklung verbauen.
|
||||
|
||||
Verstehst du meine bedenken?
|
||||
|
||||
Ich will mit dir jetzt einen Fahrplan durchdiskutieren, was wir jetzt wie genau entwickeln wollen. Bist du damit
|
||||
einverstanden?
|
||||
|
||||
---
|
||||
|
||||
🏗️ [Lead Architect]
|
||||
|
||||
### Kurzantwort
|
||||
|
||||
Ja, ich verstehe deine Bedenken. Wir trennen konsequent die fachlichen Kontexte vom technischen Monitoring, kapseln das
|
||||
`Ping-Service` als reine technische Schablone, und liefern bis Neumarkt ein minimal tragfähiges Set an Kernfunktionen
|
||||
ohne künftige Weiterentwicklung zu verbauen. Unten ist ein konkreter, umsetzbarer Fahrplan mit klaren Leitplanken,
|
||||
Architektur-Skizze, Modulschnitt und Sprint-Plan.
|
||||
|
||||
---
|
||||
|
||||
### Leitplanken (nicht verhandelbar)
|
||||
|
||||
- Bounded Contexts pro Domäne: kein Mischen von fachlichen Flows mit technischen Utilities.
|
||||
- Zwei getrennte UIs:
|
||||
- Fach-UI: produktive Workflows (Meldungen etc.).
|
||||
- TechOps-UI: Betrieb, Metriken, Logs, `Ping-Service` (Referenz/Schablone), Admin-Tools.
|
||||
- `Ping-Service` bleibt fachlich neutral: keine Domänen-Referenzen, dient nur als Vorlage für technische Patterns (
|
||||
Transport, Observability, Resilience, CI/CD).
|
||||
- Offline-First bleibt Prinzip: Sync-Schicht ist eigenständig, nicht in Screens verwoben.
|
||||
- „Saubere Weiterentwicklung“ absichern durch: stabile Contracts (`api`-Module), Consumer-Driven-Contracts,
|
||||
Telemetrie-Standards, Migrationspfade.
|
||||
|
||||
---
|
||||
|
||||
### Zielbild: Kontext-/Service-Architektur
|
||||
|
||||
- Fachliche Kontexte (Beispiele – bitte bei Bedarf präzisieren):
|
||||
- `Meldung-Erfassung` (Form, Validierung, Lokalspeicher, Drafts)
|
||||
- `Meldung-Verwaltung` (Liste, Details, Statuswechsel)
|
||||
- `Sync` (Offline-Queue, Konfliktlösung, Retry)
|
||||
- `Auth/Identity` (Rollen/Permissions, lokale Session)
|
||||
- Technischer Kontext:
|
||||
- `TechOps` (Monitoring-UI, Admin-Funktionen)
|
||||
- `Ping-Service` (Health, Latenz, Transportwege, Resilience-Demo)
|
||||
- Context Map: klare Schnittstellen zwischen `Fach` ↔ `Sync` ↔ `Backend-APIs` sowie `TechOps` isoliert daneben.
|
||||
|
||||
---
|
||||
|
||||
### Frontend-Aufteilung (KMP/Compose, Beispiele passend zum Repo)
|
||||
|
||||
- `frontend/shells/meldestelle-desktop` → Fach-UI Shell
|
||||
- `frontend/shells/techops-desktop` → NEU: TechOps-UI Shell (enthält `Ping`-Feature, Metriken/Logs)
|
||||
- `frontend/features/*` → Feature-Module pro Kontext:
|
||||
- `features/meldung-erfassung`
|
||||
- `features/meldung-verwaltung`
|
||||
- `features/auth`
|
||||
- `features/sync`
|
||||
- `features/ping-feature` (nur in `techops-desktop` eingebunden)
|
||||
- `frontend/core/*` → Querschnitt (Design-System, Navigation, State, Telemetrie-SDK, Storage-Abstraktion)
|
||||
- Strikte Regel: `features/ping-feature` darf kein fachliches Modul importieren. Fach-Features dürfen `ping` nicht
|
||||
importieren.
|
||||
|
||||
---
|
||||
|
||||
### Backend-Aufteilung (Kotlin/Spring Boot als Annahme)
|
||||
|
||||
- `services/ping` → reine Technik (Health, echo, stream), OpenAPI, OTel, RateLimit, Chaos toggelbar.
|
||||
- `services/meldung` → Domäne (Erfassung, Verwaltung, Validierung), eigene DB-Schemata.
|
||||
- `services/auth` → Rollen/Claims, Tokens.
|
||||
- `platform/observability` → Zentral: OTel Collector, Metrics, Tracing, Log-Pipeline.
|
||||
|
||||
---
|
||||
|
||||
### MVP für Neumarkt (einsatzbereit, aber erweiterbar)
|
||||
|
||||
- Fach-UI
|
||||
- `Meldung erfassen`: Basisformular, Pflichtfelder, lokale Drafts, Validierung.
|
||||
- `Meldung verwalten`: Liste, Detailansicht, einfacher Statuswechsel.
|
||||
- `Sync`: Hintergrund-Sync mit Retry, Konflikt-Hinweis-UI (einfacher Merge/Last-Write-Wins als Start, später
|
||||
verfeinern).
|
||||
- `Auth`: Lokale Anmeldung (konfigurierbar), Rollen-Gating auf kritische Aktionen.
|
||||
- TechOps-UI
|
||||
- `Ping`-Dashboard: Latenz/Verfügbarkeit, einfache Last- und Retry-Demos.
|
||||
- `Metrics`: Service-Health, Build-Infos, Versionen, simple Logs-View.
|
||||
- Nicht-Ziele für MVP: komplexe Berichte, granularer Rechtemanager, komplexe Konfliktlösung.
|
||||
|
||||
---
|
||||
|
||||
### Roadmap bis Neumarkt (Beispiel: 3 Sprints à 2 Wochen)
|
||||
```
|
||||
… (vollständiger Verlauf aus der Quelle)
|
||||
```
|
||||
```
|
||||
@@ -40,8 +40,8 @@
|
||||
- Footer‑Onboarding integrieren (Status, Geräte, Chat‑Trigger).
|
||||
|
||||
## Artefakte/Referenzen
|
||||
- docs/06_Frontend/flow-wechsel.png (neuer Flow – grüner Pfeil)
|
||||
- docs/06_Frontend/flow-fehler.png (Bruchstellen im alten Flow)
|
||||
- docs/80_Assets/frontend/screens/E_Nennen/flow-wechsel.png (neuer Flow – grüner Pfeil)
|
||||
- docs/80_Assets/frontend/screens/E_Nennen/flow-fehler.png (Bruchstellen im alten Flow)
|
||||
- docs/99_Journal/2026-03-31_Session_Log_Event_First_Workflow.md
|
||||
- docs/99_Journal/2026-03-30_Session_Log_ZNS_Documentation.md
|
||||
- docs/99_Journal/2026-03-30_Session_Log_Masterdata_OETO_Consolidation.md
|
||||
|
||||
@@ -0,0 +1,67 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ARCHIVED
|
||||
owner: Curator
|
||||
created: 2026-04-02
|
||||
sources:
|
||||
- ../temp/2026-04-02_Besprechung/Besprechung_2026-04-02.md
|
||||
- ../temp/2026-04-02_Besprechung/Okay,_ich_bin_der_Besitzer_dieses_Projek.md
|
||||
- ../temp/2026-04-02_Besprechung/1._USB-Stick_Fallback_bei_LAN-Ausfall.md
|
||||
---
|
||||
|
||||
# Besprechung — 02. April 2026 (konsolidiert)
|
||||
|
||||
Hinweis: Dieses Protokoll konsolidiert Inhalte aus drei Quelldateien unter `docs/temp/2026-04-02_Besprechung/`.
|
||||
Die Originale bleiben bis zur finalen Migration erhalten.
|
||||
|
||||
## Agenda & Ziel
|
||||
- Überblick über aktuelle Reports aller Rollen
|
||||
- Strategie-Feinschliff und Arbeitsaufträge
|
||||
- Reihenfolge der nächsten Entwicklungsschritte
|
||||
|
||||
Quelle: `Besprechung_2026-04-02.md` (Kurzagenda, Report-Verweise)
|
||||
|
||||
## Domänen-Klärungen und Entscheidungen
|
||||
|
||||
### Veranstalter/Veranstaltung/Turnier — Präzisierung der Hierarchie
|
||||
Kernaussage: Eine interne `Veranstaltung` (Tenant-Grenze) kann mehrere `Turnier` (mit jeweils eigener OEPS-Turniernummer) enthalten.
|
||||
Konsequenz: Anpassung der `Ubiquitous_Language.md` und Datenbankschemata erforderlich.
|
||||
|
||||
Quelle: `Okay,_ich_bin_der_Besitzer_dieses_Projek.md`
|
||||
|
||||
### Abteilung als kleinste Einheit & USB-Stick-Fallback
|
||||
- `Abteilung` ist die operative Einheit mit eigener Startliste/Ergebnis/Siegerehrung.
|
||||
- USB-Export/Import wird auf Abteilungs-Ebene präzisiert (Startlisten/Ergebnisse je Abteilung).
|
||||
- System muss abhängig vom Prüfungstyp korrekte Zusammenführung bzw. separate Siegerehrung unterstützen.
|
||||
|
||||
Quelle: `1._USB-Stick_Fallback_bei_LAN-Ausfall.md`
|
||||
|
||||
## Arbeitsaufträge (Auszug)
|
||||
- Architect: Domänenmodell präzisieren (Veranstaltung 1:N Turnier) und ADR/UL aktualisieren.
|
||||
- Backend: Tabellen für `veranstaltung`, `turnier`, `abteilung`; Kassa-Logik je Ebene.
|
||||
- Frontend: Dialog-Logik für Abteilungs-Vorschläge/Validierung.
|
||||
- QA/Rulebook: Testfälle und Regelwerks-Spezifikation für zwingende Abteilungs-Teilungen.
|
||||
|
||||
## Anhänge (Originalauszüge)
|
||||
|
||||
> Auszug: Besprechung_2026-04-02.md
|
||||
|
||||
```text
|
||||
Meldestelle Besprechung!
|
||||
Wir berufen diese Besprechung ein, um die nächsten Entwicklungsschritte zu besprechen.
|
||||
... (gekürzt, siehe Quelle)
|
||||
```
|
||||
|
||||
> Auszug: Okay,_ich_bin_der_Besitzer_dieses_Projek.md
|
||||
|
||||
```text
|
||||
🏗️ **[Lead Architect]** — Antwort auf Domänen-Fragen des Projekt-Owners | 2. April 2026
|
||||
... (gekürzt, siehe Quelle)
|
||||
```
|
||||
|
||||
> Auszug: 1._USB-Stick_Fallback_bei_LAN-Ausfall.md
|
||||
|
||||
```text
|
||||
🏗️ **[Lead Architect]** — Domänen-Korrektur & USB-Fallback-Präzisierung | 2. April 2026
|
||||
... (gekürzt, siehe Quelle)
|
||||
```
|
||||
@@ -27,7 +27,7 @@ last_update: 2026-04-02
|
||||
* frontend/shells/meldestelle-desktop/src/jvmMain/kotlin/at/mocode/desktop/v2/VeranstaltungScreens.kt
|
||||
* frontend/core/navigation/src/commonMain/kotlin/at/mocode/frontend/core/navigation/AppScreen.kt
|
||||
* frontend/features/reiter-feature/src/commonMain/kotlin/at/mocode/frontend/features/reiter/domain/Reiter.kt
|
||||
* Design-Referenzen: docs/06_Frontend/Veranstalter-Card-v01.png, docs/06_Frontend/Veranstalter-Profil-Card-v01.png
|
||||
* Design-Referenzen: docs/80_Assets/frontend/screens/A_EventVerwaltung/Veranstalter-Card-v01.png, docs/80_Assets/frontend/screens/A_EventVerwaltung/Veranstalter-Profil-Card-v01.png
|
||||
|
||||
## Qualitätssicherung
|
||||
* Lint: keine Fehler; nur harmlose Warnungen (unbenutzte Imports/Parameter, reduzierbarer Not-Null-Call, Legacy Long→Duration-Overloads).
|
||||
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: Curator
|
||||
created: 2026-04-09
|
||||
---
|
||||
|
||||
# 🧹 Curator Session Log — 09.04.2026
|
||||
|
||||
## Änderungen in dieser Session
|
||||
- Frontmatter zu `docs/README.md` hinzugefügt; Quick Links um Journal/Reports erweitert.
|
||||
- Report erstellt: `90_Reports/2026-04-09_Curator-Cleanup-Report.md` (Analyse & Maßnahmen).
|
||||
- Journal angelegt: `99_Journal/2026-03-27_Chat-Verlauf.md` (Chat-Protokoll importiert, Original referenziert).
|
||||
- Journal angelegt: `99_Journal/2026-04-02_Besprechung.md` (konsolidiertes Protokoll mit Quellen).
|
||||
- Report erstellt: `90_Reports/2026-04-09_Todos-ZNS-Importer.md` (bereinigt aus temp/).
|
||||
- Leitlinie für Assets erstellt: `80_Assets/README.md` (C-3, Zielstruktur & Migration).
|
||||
- Physische Konsolidierung (Phase 1):
|
||||
- Neumarkt-Assets (PNG/WEBP/PDF/TXT) von `docs/Neumarkt2026/` nach `docs/80_Assets/neumarkt2026/` verschoben.
|
||||
- SuDo-Screenshots (PNG) von `docs/BilderSuDo/` nach `docs/80_Assets/frontend/sudo/` verschoben.
|
||||
- Referenzen aktualisiert in: `docs/04_Agents/Logs/2026-03-21_Frontend_NennungsMaske.md`.
|
||||
|
||||
## Offene Punkte für Folgesession
|
||||
- Physische Konsolidierung der Assets nach `docs/80_Assets/**` und Link-Updates.
|
||||
- Vollständiger Frontmatter-Check aller Markdown-Dateien; fehlende Header ergänzen.
|
||||
- `docs/temp/` Inhalte nach erfolgreicher Migration in `_archive/` überführen.
|
||||
- Weitere Referenz-Updates: verbleibende Hinweise auf `docs/BilderSuDo/*` und Frontend-Screenshots unter `docs/06_Frontend/**` angleichen.
|
||||
|
||||
## Phase 2.1 — Assets (Frontend-Screens) Migration
|
||||
|
||||
- Inventur durchgeführt: Produktive Referenzen auf `docs/06_Frontend/Screenshots/**` außerhalb von `docs/temp/**` nur in `docs/04_Agents/Logs/2026-03-21_Frontend_NennungsMaske.md` gefunden.
|
||||
- Befund: Referenzierter Screenshot `Desktop-Nennmaske-Entwurf_2026-03-21_11-53.png` existiert nicht mehr am alten Pfad; Mapping weist auf `flows/nennmaske_flow-desktop-uebersicht__v1__entwurf__2026-03-21__11-53.png`, der aktuell ebenfalls nicht im Repo ist.
|
||||
- Maßnahme: Link nicht umgebogen, stattdessen Hinweis in Log ergänzt (Screenshot derzeit nicht verfügbar, Mapping referenziert). Keine physischen Moves in 2.1 notwendig.
|
||||
- Nächste Schritte (2.2 Vorschlag):
|
||||
- Quelle des Desktop‑Nennmaske‑Screens wiederherstellen (oder Figma-Export ergänzen) und nach `docs/80_Assets/frontend/screens/` einordnen.
|
||||
- Danach Link in `2026-03-21_Frontend_NennungsMaske.md` aktualisieren.
|
||||
|
||||
## Phase 2.2 — Konsolidierung umgesetzt (09.04.2026)
|
||||
|
||||
- FIGMA Vision_03 Screenshots aus `docs/06_Frontend/FIGMA/Vision_03/Screenshots/` nach
|
||||
`docs/80_Assets/frontend/figma/vision_03/_unsorted/` verschoben.
|
||||
- ScreenShots-Archiv (Infra) aus `docs/ScreenShots/archive/` nach
|
||||
`docs/80_Assets/exports/ops/archive/` verschoben.
|
||||
- Archiv-README hinzugefügt:
|
||||
- `docs/06_Frontend/Screenshots/README.md` (ARCHIVED → verweist auf `80_Assets`)
|
||||
- `docs/ScreenShots/README.md` (ARCHIVED → verweist auf `80_Assets/exports/ops`)
|
||||
- Link-Refactor begonnen; verbleibende Altpfade werden in der nächsten Runde repo-weit aktualisiert.
|
||||
Reference in New Issue
Block a user