diff --git a/_shared/kanban.css b/_shared/kanban.css new file mode 100644 index 00000000..82ee3beb --- /dev/null +++ b/_shared/kanban.css @@ -0,0 +1,40 @@ +:root { + --bg: #0B0F17; --card: #131A26; --card2: #18212F; --border: #253044; + --fg: #E6EDF7; --muted: #93A1B8; --primary: #3B82F6; + } + * { box-sizing: border-box; } + body { margin: 0; background: var(--bg); color: var(--fg); font-family: ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; } + header { position: sticky; top: 0; z-index: 20; background: rgba(11,15,23,.92); backdrop-filter: blur(8px); border-bottom: 1px solid var(--border); padding: 14px 20px; } + .row { display: flex; gap: 10px; align-items: center; flex-wrap: wrap; } + h1 { font-size: 17px; margin: 0 14px 0 0; letter-spacing: -.01em; } + .sub { color: var(--muted); font-size: 12px; } + input, select, button { background: var(--card2); color: var(--fg); border: 1px solid var(--border); border-radius: 8px; padding: 7px 10px; font-size: 12px; font-family: inherit; } + input:focus, select:focus { outline: 1px solid var(--primary); } + button { cursor: pointer; } + button:hover { border-color: var(--primary); } + button.primary { background: rgba(59,130,246,.14); color: #93BBFB; border-color: rgba(59,130,246,.3); } + .stats { display: flex; gap: 14px; font-size: 11px; color: var(--muted); margin-top: 8px; flex-wrap: wrap; } + .stats b { color: var(--fg); } + .board { display: grid; grid-template-columns: repeat(5, minmax(240px, 1fr)); gap: 12px; padding: 16px 20px 40px; align-items: start; overflow-x: auto; } + .col { background: var(--card); border: 1px solid var(--border); border-radius: 12px; min-height: 160px; padding: 10px; } + .col.over { border-color: var(--primary); background: #16203042; } + .col h2 { font-size: 12px; margin: 2px 4px 10px; display: flex; justify-content: space-between; align-items: center; text-transform: uppercase; letter-spacing: .06em; color: var(--muted); } + .count { background: var(--card2); border: 1px solid var(--border); border-radius: 999px; padding: 1px 7px; font-size: 10px; color: var(--fg); } + .card { background: var(--card2); border: 1px solid var(--border); border-radius: 10px; padding: 10px; margin-bottom: 8px; cursor: grab; } + .card:hover { border-color: #3a4a66; } + .card.dragging { opacity: .45; } + .card .code { font-family: ui-monospace, SFMono-Regular, Menlo, monospace; font-size: 10px; color: var(--muted); } + .card .title { font-size: 13px; margin: 4px 0 7px; line-height: 1.35; } + .tag { display: inline-block; font-size: 10px; padding: 2px 7px; border-radius: 999px; background: #202b3d; color: var(--muted); margin-right: 4px; margin-top: 3px; } + .tag.blocked { background: rgba(245,158,11,.15); color: #FBBF24; } + .tag.ready { background: rgba(34,197,94,.15); color: #4ADE80; } + .tag.wave { background: rgba(59,130,246,.14); color: #93BBFB; } + dialog { background: var(--card); color: var(--fg); border: 1px solid var(--border); border-radius: 14px; max-width: 860px; width: 94%; padding: 0; } + dialog::backdrop { background: rgba(0,0,0,.72); } + .dlg-head { padding: 18px 20px; border-bottom: 1px solid var(--border); display: flex; justify-content: space-between; gap: 12px; align-items: flex-start; } + .dlg-body { padding: 18px 20px 24px; max-height: 66vh; overflow: auto; } + pre { background: #0E1420; border: 1px solid var(--border); border-radius: 10px; padding: 14px; font-size: 11px; line-height: 1.6; white-space: pre-wrap; word-break: break-word; color: #C7D3E5; font-family: ui-monospace, SFMono-Regular, Menlo, monospace; } + h3 { font-size: 12px; text-transform: uppercase; letter-spacing: .06em; color: var(--muted); margin: 18px 0 8px; } + ul { margin: 0; padding-left: 18px; font-size: 13px; color: #C7D3E5; line-height: 1.6; } + .chip { font-family: ui-monospace, Menlo, monospace; font-size: 11px; border: 1px solid var(--border); border-radius: 6px; padding: 2px 6px; margin: 0 4px 4px 0; display: inline-block; color: var(--muted); } + .empty { color: #55627a; font-size: 11px; text-align: center; padding: 14px 0; } diff --git a/_shared/kanban.js b/_shared/kanban.js new file mode 100644 index 00000000..33fe51ac --- /dev/null +++ b/_shared/kanban.js @@ -0,0 +1,152 @@ +(function () { + var DATA = JSON.parse(document.getElementById('data').textContent); + var COLUMNS = ['Backlog', 'Bereit', 'In Arbeit', 'Prüfung', 'Fertig']; + var KEY = 'kanban-status-v1:' + location.pathname; + var state = {}; + try { state = JSON.parse(localStorage.getItem(KEY) || '{}') || {}; } catch (e) { state = {}; } + var onlyReady = false; + + function statusOf(t) { return state[t.code] || t.status || 'Backlog'; } + function isDone(code) { return statusOf(byCode[code] || { code: code }) === 'Fertig'; } + var byCode = {}; + DATA.tickets.forEach(function (t) { byCode[t.code] = t; }); + + function ready(t) { return (t.dependsOn || []).every(function (d) { return isDone(d); }); } + + function save() { localStorage.setItem(KEY, JSON.stringify(state)); } + + // Filter befüllen + var fEpic = document.getElementById('fEpic'), fRole = document.getElementById('fRole'), fWave = document.getElementById('fWave'); + DATA.epics.forEach(function (e) { var o = document.createElement('option'); o.value = e.key; o.textContent = e.emoji + ' ' + e.name; fEpic.appendChild(o); }); + Array.from(new Set(DATA.tickets.map(function (t) { return t.role; }))).sort().forEach(function (r) { var o = document.createElement('option'); o.value = r; o.textContent = r; fRole.appendChild(o); }); + var maxWave = Math.max.apply(null, DATA.tickets.map(function (t) { return t.wave; })); + for (var w = 1; w <= maxWave; w++) { var o = document.createElement('option'); o.value = String(w); o.textContent = 'Welle ' + w; fWave.appendChild(o); } + + function visible() { + var q = document.getElementById('q').value.trim().toLowerCase(); + return DATA.tickets.filter(function (t) { + if (fEpic.value && t.epic !== fEpic.value) return false; + if (fRole.value && t.role !== fRole.value) return false; + if (fWave.value && String(t.wave) !== fWave.value) return false; + if (onlyReady && (!ready(t) || statusOf(t) === 'Fertig')) return false; + if (q) { + var hay = (t.code + ' ' + t.title + ' ' + t.tech + ' ' + t.description).toLowerCase(); + if (hay.indexOf(q) === -1) return false; + } + return true; + }); + } + + function render() { + var board = document.getElementById('board'); + board.innerHTML = ''; + var list = visible(); + COLUMNS.forEach(function (col) { + var el = document.createElement('div'); + el.className = 'col'; + el.dataset.col = col; + var items = list.filter(function (t) { return statusOf(t) === col; }); + var h = document.createElement('h2'); + h.innerHTML = '' + col + '' + items.length + ''; + el.appendChild(h); + if (!items.length) { var e = document.createElement('div'); e.className = 'empty'; e.textContent = '– leer –'; el.appendChild(e); } + items.forEach(function (t) { el.appendChild(card(t)); }); + el.addEventListener('dragover', function (ev) { ev.preventDefault(); el.classList.add('over'); }); + el.addEventListener('dragleave', function () { el.classList.remove('over'); }); + el.addEventListener('drop', function (ev) { + ev.preventDefault(); el.classList.remove('over'); + var code = ev.dataTransfer.getData('text/plain'); + if (!code) return; + state[code] = col; save(); render(); + }); + board.appendChild(el); + }); + stats(list); + } + + function card(t) { + var d = document.createElement('div'); + d.className = 'card'; + d.draggable = true; + var blocked = !ready(t); + d.innerHTML = '
' + t.code + ' · ' + t.estimateDays + ' PT
' + + '
' + esc(t.title) + '
' + + 'Welle ' + t.wave + '' + + '' + t.role + '' + + '' + t.complexity + '' + + (blocked ? 'wartet auf ' + t.dependsOn.filter(function (c) { return !isDone(c); }).join(', ') + '' : 'startbar'); + d.addEventListener('dragstart', function (ev) { ev.dataTransfer.setData('text/plain', t.code); d.classList.add('dragging'); }); + d.addEventListener('dragend', function () { d.classList.remove('dragging'); }); + d.addEventListener('click', function () { openDlg(t); }); + return d; + } + + function esc(s) { return String(s).replace(/[&<>]/g, function (c) { return { '&': '&', '<': '<', '>': '>' }[c]; }); } + + function stats(list) { + var done = DATA.tickets.filter(function (t) { return statusOf(t) === 'Fertig'; }); + var donePT = done.reduce(function (a, t) { return a + t.estimateDays; }, 0); + var readyNow = DATA.tickets.filter(function (t) { return ready(t) && statusOf(t) !== 'Fertig'; }).length; + document.getElementById('stats').innerHTML = + '' + DATA.tickets.length + ' Kacheln' + + 'sichtbar: ' + list.length + '' + + 'fertig: ' + done.length + ' (' + donePT + ' von ' + DATA.totalDays + ' PT)' + + 'jetzt startbar: ' + readyNow + '' + + 'Wellen: ' + maxWave + ''; + } + + var dlg = document.getElementById('dlg'); + var current = null; + function openDlg(t) { + current = t; + document.getElementById('dCode').textContent = t.code + ' · ' + t.epicName; + document.getElementById('dTitle').textContent = t.title; + document.getElementById('dMeta').innerHTML = + 'Welle ' + t.wave + '' + t.role + '' + t.complexity + '' + t.estimateDays + ' PT' + statusOf(t) + ''; + document.getElementById('dDesc').textContent = t.description; + chips('dDeps', t.dependsOn); + chips('dNext', t.unlocks); + items('dAcc', t.akzeptanz); + items('dChk', t.pruefungen); + document.getElementById('dPrompt').textContent = t.prompt; + dlg.showModal(); + } + function chips(id, arr) { + var el = document.getElementById(id); + el.innerHTML = (arr && arr.length) ? arr.map(function (c) { return '' + c + (byCode[c] ? ' – ' + esc(byCode[c].title) : '') + ''; }).join('') : 'keine'; + } + function items(id, arr) { + document.getElementById(id).innerHTML = (arr || []).map(function (a) { return '
  • ' + esc(a) + '
    • '; }).join(''); + } + document.getElementById('closeBtn').onclick = function () { dlg.close(); }; + document.getElementById('copyBtn').onclick = function () { + if (!current) return; + var btn = this; + navigator.clipboard.writeText(current.prompt).then(function () { + btn.textContent = 'Kopiert ✓'; + setTimeout(function () { btn.textContent = 'Prompt kopieren'; }, 1800); + }); + }; + + document.getElementById('q').addEventListener('input', render); + [fEpic, fRole, fWave].forEach(function (s) { s.addEventListener('change', render); }); + document.getElementById('onlyReady').onclick = function () { + onlyReady = !onlyReady; + this.style.borderColor = onlyReady ? 'var(--primary)' : 'var(--border)'; + this.textContent = onlyReady ? 'Filter: nur startbare' : 'Nur startbare'; + render(); + }; + document.getElementById('resetBtn').onclick = function () { + if (confirm('Alle lokalen Statusänderungen verwerfen?')) { state = {}; save(); render(); } + }; + document.getElementById('exportBtn').onclick = function () { + var rows = [['Code', 'Titel', 'Status']].concat(DATA.tickets.map(function (t) { return [t.code, t.title, statusOf(t)]; })); + var csv = rows.map(function (r) { return r.map(function (c) { return '"' + String(c).replace(/"/g, '""') + '"'; }).join(','); }).join('\n'); + var a = document.createElement('a'); + a.href = URL.createObjectURL(new Blob(['\ufeff' + csv], { type: 'text/csv;charset=utf-8' })); + a.download = 'kanban-stand.csv'; + a.click(); + }; + + render(); +})(); diff --git a/workflow-kanban/DEVLOG.md b/workflow-kanban/DEVLOG.md new file mode 100644 index 00000000..fa7ca4cc --- /dev/null +++ b/workflow-kanban/DEVLOG.md @@ -0,0 +1,57 @@ +# workflow-kanban – Dev Log + +## 2026-08-26 12:47 – 12:49 (2m) +**Beschreibung:** Claude Code Session +**Projekt:** dms-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:53 – 12:54 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** workflow-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 12:55 – 12:55 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** workflow-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 23:25 – 23:26 (1m) +**Beschreibung:** Claude Code Session +**Projekt:** nexarch + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- +## 2026-08-26 23:31 – 23:32 (0m) +**Beschreibung:** Claude Code Session +**Projekt:** workflow-kanban + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- diff --git a/workflow-kanban/README.md b/workflow-kanban/README.md new file mode 100644 index 00000000..8fa9f068 --- /dev/null +++ b/workflow-kanban/README.md @@ -0,0 +1,98 @@ +# Workflow-Kanban – lokal abarbeiten + +35 Arbeitskacheln · 6 Epics · 91 Personentage · 8 Wellen (inkl. Welle 8: Threat-Model-Nachtrag 2026-09-12 — VOR-06, ENG-06, ENG-07). + +Hinweis: Dieses Board ist die alleinige Quelle für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing. DMS-Board referenziert dieses Board extern in der Ausgangslage betroffener Tickets. Benachrichtigungsversand selbst liegt im Core-Board (CFG-02..04), nicht hier. +Modul-Adapter ist bidirektional: ENG-02 für Push (Registrierung durch DMS/Mail), VOR-04 für Pull (Rückkanal, damit DMS/Mail Workflow-Daten im eigenen Kontext anzeigen können). +Hinweis: Alle Oberflächen-Tickets in diesem Board bauen auf der zentralen UI-Shell & Design-System aus NEXARCH Core auf (siehe ../core-kanban/, `SHL-01`) — kein eigenes Design-System in diesem Board. +Stand: 2026-08-26 + +## Weg 1 – Sofort loslegen (empfohlen) + +`kanban.html` per Doppelklick im Browser öffnen. Kein Server, kein Internet, keine Installation. + +- Kacheln per Drag & Drop zwischen Backlog → Bereit → In Arbeit → Prüfung → Fertig ziehen +- Der Stand wird im Browser gespeichert (localStorage) und bleibt nach dem Schließen erhalten +- Filter nach Epic, Rolle, Welle, Volltext sowie „Nur startbare“ (alle Vorgänger auf Fertig) +- Klick auf eine Kachel öffnet Details inkl. vollem Bau-Prompt und „Prompt kopieren“ +- „Stand sichern“ exportiert den aktuellen Status als CSV + +Hinweis: Der Stand hängt an Browser und Profil. Für Teamarbeit Weg 2 oder 3 nutzen. + +## Weg 2 – Import in ein vorhandenes Werkzeug + +`board.csv` (UTF-8 mit BOM, Komma-getrennt) importieren: + +| Werkzeug | Weg | +| --- | --- | +| Trello | Board → Menü → Mehr → CSV importieren (Power-Up) | +| Jira | Einstellungen → System → Externes Importieren → CSV, Spalte „Status“ auf den Workflow mappen | +| GitHub Projects | Projekt → … → Import, oder per `gh` CLI aus `board.json` | +| Notion | Datenbank → … → Merge with CSV | +| Linear / Asana / ClickUp | jeweils CSV-Import, Spalten wie oben zuordnen | + +Spalten: Code, Titel, Epic, Rolle, Komplexitaet, Aufwand_PT, Welle, Status, Technik, +Beschreibung, Haengt_ab_von, Schaltet_frei, Akzeptanzkriterien, Pruefungen. + +## Weg 3 – Dateibasiert in der Entwicklungsumgebung + +Der Ordner `tickets/` enthält für jede Kachel eine Markdown-Datei (`ENG-01.md` …). +Jede Datei ist ein vollständiger Bau-Prompt – Auftrag, Produkt-DNA, Ausgangslage, +Akzeptanzkriterien, Prüfungen und Abschlussregeln. + +- **Obsidian**: Ordner als Vault öffnen, Community-Plugin „Kanban“ installieren, Spalten anlegen und die Notizen einsortieren. +- **VS Code**: Ordner öffnen, Erweiterung „Todo Tree“ oder „Markdown Kanban“ nutzen. +- **Coding-Assistent**: Dateiöffnen, Inhalt kopieren, als Auftrag übergeben. Ein Prompt = eine Kachel = ein Branch. + +## Weg 4 – Eigenes Board im Netzwerk (Team) + +Selbst gehostet, jeweils mit CSV-Import: + +```bash +# Focalboard +docker run -d -p 8000:8000 --name focalboard mattermost/focalboard + +# Planka +docker run -d -p 3010:1337 --name planka ghcr.io/plankanban/planka:latest + +# Vikunja +docker run -d -p 3456:3456 --name vikunja vikunja/vikunja +``` + +Danach `board.csv` importieren. + +## Reihenfolge der Arbeit + +Die Wellen geben an, was parallel laufen darf. Eine Kachel ist startbar, +sobald alle Kacheln unter „Hängt ab von“ auf Fertig stehen. + +- **Welle 1** (2 Kacheln): ENG-01, QA-01 +- **Welle 2** (5 Kacheln): ENG-02, ENG-03, ENG-04, ENG-05, TSK-01 +- **Welle 3** (5 Kacheln): APR-01, TSK-02, RTE-01, QA-02, VOR-01 +- **Welle 4** (9 Kacheln): APR-02, APR-03, APR-04, TSK-03, TSK-04, RTE-02, RTE-03, VOR-02, VOR-03 +- **Welle 5** (5 Kacheln): TSK-05, RTE-04, QA-03, VOR-04, VOR-05 +- **Welle 6** (2 Kacheln): QA-04, QA-06 +- **Welle 7** (1 Kachel): QA-05 + +Kritischer Pfad (19 PT): ENG-01 → ENG-02 → RTE-01 → RTE-02 → RTE-04 → QA-04 → QA-05 + +## Produkt-DNA + +### Übernehmen +- **Alfresco**: Echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik – Kernidee dieses Boards. +- **Camunda/Zeebe**: Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse, leichtgewichtig gedacht statt BPMN-Vollausbau. +- **Trello/Linear**: Einfache, schnelle Aufgaben-Oberfläche als Vorbild – kein Schwergewicht. +- **Alfresco**: Akten-/Vorgangskonzept mit klarer Statuslogik als Vorbild für die digitale Akte (VOR-01..VOR-05). +- **ecoDMS**: Klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet (VOR-03). + +### Vermeiden +- **Alfresco – Ressourcen-Overhead und Konfigurationskomplexität der Plattform.**: Schlanker Go-Dienst mit Postgres-Jobqueue statt Java-Anwendungsserver und zusätzlicher Message-Queue-Infrastruktur. +- **Camunda/Zeebe – voller BPMN-Modellierungsapparat.**: Ein lesbares, versionierbares Prozessdefinitionsformat statt grafischem Modellierungswerkzeug. +- **Kein zweites, konkurrierendes Aktenmodell parallel in DMS.**: Die Akte lebt ausschließlich in Workflow, DMS und Mail zeigen sie nur über die Rückkanal-API (VOR-04) an. + +## Arbeitsregeln + +Je Kachel ein eigener Branch, schrittweise committen, Branch pushen, dann anhalten. +Kein Merge und kein Deploy ohne ausdrückliche Freigabe. + +Code-Struktur: Hauptdateien/Entry-Points klein halten, Fachlogik in eigene Module/Dateien auslagern. Vor dem Anlegen einer neuen Funktions-/Modul-Datei prüfen, ob dieselbe Funktionalität nicht schon in einem anderen Modul (auch modulübergreifend, z. B. Core) existiert — keine doppelten Funktionsdateien, ein Modul/Board referenziert das andere extern statt Code zu kopieren (gleiches Prinzip wie bei den Konsolidierungen IAM/Archive/Workflow/AI/API/UI-Shell, siehe nexarch-state.json). diff --git a/workflow-kanban/board.csv b/workflow-kanban/board.csv new file mode 100644 index 00000000..a154c81d --- /dev/null +++ b/workflow-kanban/board.csv @@ -0,0 +1,240 @@ +Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen +ENG-01,Workflow-Engine & Zustandsmodell,🔀 Workflow-Engine,Backend,Komplex,4,1,Fertig,"Zustandsautomat, PostgreSQL, pgx/v5","Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.",,ENG-02 ENG-03 ENG-04 ENG-05 APR-01 TSK-01,"Zustände und zulässige Übergänge sind je Prozesstyp definierbar +Unzulässiger Übergang wird abgewiesen +Laufende Instanz überlebt einen Neustart","Unzulässiger Übergang wird im Test abgewiesen +Gleichzeitige Übergänge zweier Nutzer erzeugen keinen Fehlzustand +Neustart des Dienstes mit laufender Instanz geprüft" +ENG-02,Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger),🔀 Workflow-Engine,Backend,Mittel,3,2,Fertig,"REST-Schnittstelle, Adapter-Registrierung","Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.",ENG-01,APR-01 QA-02 QA-06 RTE-01 VOR-01 QA-07 ENG-06,"Modul kann Objekttyp und Trigger ohne Codeänderung an der Engine registrieren +Registrierung ist versionierbar und rückrollbar +Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz","Testadapter aus fiktivem DMS- und Mail-Modul beide korrekt registriert +Doppelte Registrierung wird abgewiesen +Deregistrierung entfernt zugehörige Trigger vollständig" +ENG-03,"Prozessdefinitions-Format (deklarativ, versionierbar)",🔀 Workflow-Engine,Backend,Mittel,3,2,Fertig,"YAML/JSON-Prozessdefinition, Schema-Validierung","Lesbares Konfigurationsformat für Prozessdefinitionen: Zustände, Übergänge, Bedingungen, Zuständigkeiten. Jede Definition ist versioniert.",ENG-01,QA-02,"Prozessdefinition ist ohne Codeänderung änderbar +Ungültige Definition wird beim Laden abgewiesen +Ältere Version bleibt für laufende Instanzen gültig","Schema-Validierung gegen fehlerhafte Definition getestet +Versionswechsel während laufender Instanz verändert deren Verhalten nicht rückwirkend +Rollback auf Vorgängerversion funktioniert" +ENG-04,Workflow-Instanz-Historie & Nachvollziehbarkeit,🔀 Workflow-Engine,Backend,Mittel,3,2,Fertig,"Append-only Protokolltabelle, PostgreSQL","Vollständiges, unveränderliches Protokoll jedes Instanzschritts: Person, Zeitpunkt, Zustand, Begründung.",ENG-01,QA-02 ENG-07,"Jeder Übergang wird protokolliert +Protokoll ist nicht nachträglich veränderbar +Historie ist je Instanz vollständig abrufbar","Manipulationsversuch am Protokoll schlägt fehl +Historie einer Beispielinstanz enthält alle Schritte in korrekter Reihenfolge +Abfrage großer Historien bleibt performant" +ENG-05,Fehlerbehandlung & Retry bei Workflow-Schritten,🔀 Workflow-Engine,Backend,Mittel,3,2,Fertig,"Postgres-Jobqueue, Backoff-Strategie","Wiederholungslogik mit Backoff für fehlgeschlagene Workflow-Schritte, Dead-Letter-Pfad für dauerhaft fehlschlagende Instanzen.",ENG-01,QA-02,"Fehlgeschlagener Schritt wird automatisch wiederholt +Dauerhaft fehlschlagender Schritt landet in einem einsehbaren Fehlerzustand +Retry ist idempotent","Simulierter Fehlerfall löst korrekte Wiederholung aus +Dead-Letter-Instanz ist auffindbar und manuell neu anstoßbar +Mehrfacher Retry erzeugt keine doppelte Wirkung" +APR-01,Freigabe-Postfach & Genehmigungsansicht (Backend),✅ Genehmigungen & Freigaben,Backend,Mittel,3,3,Fertig,"PostgreSQL, REST-Schnittstelle","Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.",ENG-01 ENG-02,APR-02 APR-03 APR-04,"Offene Genehmigungsaufgaben sind je Nutzer abrufbar +Entscheidung ist genau einmal möglich +Entscheidung ist mit Begründung protokollierbar","Bereits entschiedene Aufgabe lässt sich nicht doppelt entscheiden +Parallelentscheidung zweier Nutzer erzeugt keinen Fehlzustand +Entscheidung erscheint korrekt in der Instanz-Historie (ENG-04)" +APR-02,Vier-Augen-Freigabe (generisches Muster),✅ Genehmigungen & Freigaben,Backend,Mittel,3,4,Fertig,Regelbasierte Zweitprüfung,"Generisches Muster für Freigaben, die eine zweite, unabhängige Bestätigung erfordern – modulunabhängig konfigurierbar.",APR-01,QA-03,"Zweitprüfer darf nicht mit dem Ersteller identisch sein +Freigabe ist erst nach zwei unabhängigen Bestätigungen wirksam +Konfiguration ist je Prozesstyp aktivierbar","Ersteller kann eigene Freigabe nicht zweitbestätigen +Fehlende Zweitbestätigung blockiert die Wirkung nachweislich +Aktivierung für neuen Prozesstyp ohne Codeänderung getestet" +APR-03,Genehmigungs-Oberfläche,✅ Genehmigungen & Freigaben,Frontend,Mittel,3,4,Fertig,"React/Next.js, TypeScript","Persönliche Freigabeliste mit Vorschau des betroffenen Objekts, Kommentarfeld und den Aktionen Freigeben, Ablehnen, Zurückgeben.",APR-01 SHL-01,,"Offene Freigaben sind gebündelt sichtbar +Ablehnung erfordert eine Begründung +Entscheidung ist per Tastatur möglich","Ansicht bei 200 offenen Aufgaben bleibt nutzbar +Doppelte Entscheidung wird in der Oberfläche verhindert +Tastaturbedienung für alle drei Aktionen geprüft" +APR-04,Delegation & Vertretungsregeln bei Abwesenheit,✅ Genehmigungen & Freigaben,Backend,Einfach,2,4,Fertig,"Vertretungsmodell, Zeitraumlogik","Vertretungsregel je Nutzer und Zeitraum, sodass Genehmigungsaufgaben automatisch an eine Vertretung gehen.",APR-01,,"Vertretung ist zeitlich begrenzt konfigurierbar +Aufgabe geht während der Abwesenheit automatisch an die Vertretung +Rückkehr beendet die Vertretung automatisch +Selbst-Vertretung (Genehmiger setzt sich selbst als Vertretung ein, um APR-02 Vier-Augen-Prinzip zu umgehen) wird verhindert","Aufgabe während aktiver Vertretung landet nachweislich bei der Vertretung +Überlappende Vertretungsregeln werden eindeutig aufgelöst +Ende der Vertretung wirkt ohne manuellen Eingriff +Missbrauchstest: Genehmiger versucht, sich selbst als Vertretung einzutragen und eigene Anfrage über die Vertretung freizugeben – wird abgelehnt" +TSK-01,Aufgabenmodell & Zuweisung,"⏱️ Aufgaben, Fristen & Eskalation",Backend,Mittel,3,2,Fertig,"PostgreSQL, Aufgabenmodell","Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.",ENG-01,TSK-02 TSK-04 VOR-03,"Aufgabe ist Person oder Gruppe zuweisbar +Zuweisung an Gruppe erzeugt genau eine Aufgabe +Aufgabe ist mit beliebigem Modul-Objekt verknüpfbar","Zuweisung an Gruppe erzeugt im Test genau eine Aufgabe +Verknüpfung mit Testobjekt aus fiktivem Modul funktioniert +Tenant-Isolation der Aufgabentabellen durch Negativtest belegt" +TSK-02,Fristen & Kalenderlogik,"⏱️ Aufgaben, Fristen & Eskalation",Backend,Mittel,3,3,Fertig,"Kalenderlogik, Zeitzonenbehandlung","Fälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.",TSK-01,TSK-03 TSK-04,"Fälligkeit berücksichtigt Arbeitstage +Wochenenden und Feiertage verschieben die Fälligkeit korrekt +Zeitzonenwechsel verschiebt Fälligkeit nicht fälschlich","Fristberechnung über Wochenende und Feiertage geprüft +Zeitzonenwechsel-Testfall bestanden +Grenzfall Fälligkeit an einem Feiertag korrekt behandelt" +TSK-03,Erinnerungen & Eskalationsregeln,"⏱️ Aufgaben, Fristen & Eskalation",Backend,Mittel,3,4,Fertig,"Postgres-Jobqueue, zeitgesteuerte Jobs","Automatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.",TSK-02,TSK-05 QA-03,"Erinnerungszeitpunkte sind konfigurierbar +Eskalation erfolgt nach definierter Regel bei Fristablauf +Erledigte Aufgabe löst keine Eskalation mehr aus","Zeitraffer-Test über simulierte Fristen bestanden +Erledigte Aufgabe vor Fristablauf löst nachweislich keine Eskalation aus +Wiederholter Joblauf bleibt idempotent" +TSK-04,Aufgaben-Oberfläche,"⏱️ Aufgaben, Fristen & Eskalation",Frontend,Mittel,3,4,Fertig,"React/Next.js, TypeScript","Aufgabenliste mit Fälligkeit, Priorität und Filter, angelehnt an das einfache, schnelle Bedienmodell von Trello/Linear. Zusätzlich eine Kanban-Ansicht (Spalten nach Status, z. B. Offen/In Bearbeitung/Erledigt) — Drag & Drop einer Aufgabe in eine andere Spalte aktualisiert ihren Status über TSK-01.",TSK-01 TSK-02 SHL-01,,"Überfällige Aufgaben sind klar gekennzeichnet +Liste ist nach Fälligkeit und Priorität filterbar +Ansicht bleibt bei 200 Aufgaben nutzbar +Kanban-Ansicht zeigt Spalten nach Aufgabenstatus, Drag & Drop zwischen Spalten schreibt den neuen Status über TSK-01 zurück +Kanban-Ansicht zeigt ausschließlich Aufgaben des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet","Filterkombination gegen Testdatensatz geprüft +Überfällig-Kennzeichnung bei Fristüberschreitung im Test korrekt +Performance bei 200 Aufgaben gemessen +Verschieben einer Aufgabe per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über TSK-01 +Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Aufgaben des aktuell aktiven Mandanten" +TSK-05,Eskalations-Benachrichtigung (ruft Core-Dispatcher),"⏱️ Aufgaben, Fristen & Eskalation",Backend,Einfach,2,5,Fertig,REST-Aufruf an Core-Dispatcher,"Eskalation nach Fristablauf löst eine Benachrichtigung aus, indem der Core-Benachrichtigungs-Dispatcher aufgerufen wird – kein eigener Versandweg.",TSK-03,QA-03,"Eskalation ruft den Core-Dispatcher mit korrektem Ereignistyp auf +Fehlschlag des Dispatcher-Aufrufs bricht die Eskalation nicht ab +Keine Doppelbenachrichtigung bei mehrfachem Joblauf","Testaufruf gegen simulierten Core-Dispatcher erfolgreich +Nichterreichbarkeit des Dispatchers führt zu protokolliertem Fehler statt Absturz +Wiederholter Joblauf erzeugt keinen doppelten Aufruf" +RTE-01,"Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig)",🔁 Regelbasiertes Routing,Backend,Mittel,3,3,Fertig,"Regelwerk-Datenmodell, PostgreSQL","Generisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.",ENG-02,RTE-02 RTE-03,"Regeln sind priorisierbar +Bedingungen sind modulunabhängig formulierbar +Regel ist versionierbar und rückrollbar","Regelpriorität im Test korrekt angewendet +Testregel aus fiktivem DMS- und Mail-Adapter beide korrekt abgebildet +Rollback auf Vorgängerversion einer Regel funktioniert" +RTE-02,Routing-Engine-Ausführung,🔁 Regelbasiertes Routing,Backend,Mittel,3,4,Fertig,Regel-Ausführungs-Engine,"Ausführung des Regelwerks gegen eingehende Objekte: erste zutreffende Regel nach Priorität gewinnt, sonst Klärungskorb.",RTE-01,RTE-04,"Nicht zuordenbare Objekte landen in einem Klärungskorb +Jede Weiterleitung ist nachvollziehbar protokolliert +Regeländerung wirkt ohne Neustart","Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft +Kein Testobjekt geht bei fehlender Regel verloren +Regeländerung zur Laufzeit ohne Neustart wirksam getestet" +RTE-03,Routing-Regel-Editor (Oberfläche),🔁 Regelbasiertes Routing,Frontend,Mittel,3,4,Fertig,"React/Next.js, TypeScript","Oberfläche zum Anlegen, Priorisieren und Testen von Routing-Regeln.",RTE-01 SHL-01,,"Regeln sind in der Oberfläche priorisierbar +Regeländerung ist ohne Codeänderung möglich +Regel kann vor Aktivierung getestet werden","Priorisierung per Drag & Drop im Test funktionsfähig +Testlauf einer Regel vor Aktivierung möglich +Ungültige Bedingungseingabe wird abgewiesen" +RTE-04,Testlauf/Simulation von Routing-Regeln,🔁 Regelbasiertes Routing,Backend,Einfach,2,5,Fertig,"Simulationsmodus, Testkorpus","Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.",RTE-02,QA-04 RTE-05 QA-07,"Simulation verändert keine echten Daten +Simulationsergebnis zeigt erwartete gegen tatsächliche Zuordnung +Simulation ist gegen beliebigen Testkorpus ausführbar","Simulationslauf hinterlässt keine Spuren in Produktivdaten +Abweichung zwischen erwarteter und tatsächlicher Zuordnung wird korrekt gemeldet +Simulation mit leerem Testkorpus bricht nicht ab" +QA-01,Teststrategie Workflow,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Fertig,"Teststrategie, Testdatenbestand","Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen Testdatenbestand für Engine, Genehmigungen, Aufgaben und Routing aufbauen.",,,"Teststrategie deckt Engine, Genehmigungen, Aufgaben und Routing ab +Testdatenbestand ist realistisch und anonymisiert +Verantwortlichkeit je Testebene ist dokumentiert +Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01","Teststrategie-Dokument gegen alle vier Bereiche geprüft +Testdatenbestand enthält keine echten Personendaten +Zweite Person kann Teststrategie ohne Rückfragen anwenden" +QA-02,Prüfgate Engine & Adapter,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,3,Fertig,"Integrationstests, Zeitraffer","Prüfgate für Zustandsautomat, Modul-Adapter-Schnittstelle und Fehlerbehandlung.",ENG-05 ENG-02 ENG-03 ENG-04,QA-05,"Alle Zustandsübergänge sind mindestens einmal durchlaufen +Adapter-Registrierung ist gegen zwei fiktive Module geprüft +Fehlerbehandlung und Retry sind nachgewiesen","Unzulässiger Übergang wird in jedem Testlauf abgewiesen +Zwei fiktive Modul-Adapter gleichzeitig registriert und geprüft +Simulierter Fehlerfall löst nachweislich korrekten Retry aus" +QA-03,Prüfgate Genehmigungen & Aufgaben,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,5,Fertig,"Prozesstests, Zeitraffer","Prüfgate für Vier-Augen-Freigabe, Fristen und Eskalationsregeln.",APR-02 TSK-03 APR-04 TSK-05,QA-05,"Vier-Augen-Freigabe ist gegen Missbrauchsversuch geprüft +Fristen und Eskalationen lösen korrekt aus +Alle Genehmigungspfade sind mindestens einmal durchlaufen","Ersteller kann eigene Freigabe im Test nicht zweitbestätigen +Zeitraffer-Test über simulierte Fristen bestanden +Eskalationspfad bis zum Dispatcher-Aufruf nachvollzogen" +QA-04,Prüfgate Routing,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Fertig,"Regeltests, Testkorpus","Prüfgate für Routing-Regel-Modell, Ausführung und Simulation.",RTE-04 RTE-05,QA-05,"Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft +Klärungskorb fängt jedes nicht zuordenbare Objekt auf +Simulation weicht nicht von echter Ausführung ab","Testkorpus mit bekannten Erwartungswerten vollständig durchlaufen +Kein Testobjekt im Klärungskorb verloren +Simulationsergebnis stimmt mit echter Ausführung überein" +QA-05,Abnahme- & Compliance-Prüfung Workflow,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,7,Fertig,Abnahmeprotokoll,"Abschließende Abnahmeprüfung über Engine, Genehmigungen, Aufgaben und Routing hinweg, mit abgelegtem Protokoll.",QA-02 QA-03 QA-04 QA-06 QA-07 QA-08,,"Alle Einzelprüfgates sind bestanden und referenziert +Abnahmeprotokoll ist abgelegt und nachlesbar +Offene Punkte sind explizit benannt, nicht stillschweigend übergangen","Abnahmeprotokoll gegen alle drei Prüfgates abgeglichen +Protokoll enthält Zielwert, Messwert und Bewertung je Kriterium +Zweite Person kann Abnahme anhand des Protokolls nachvollziehen" +VOR-01,Akte/Vorgang-Objektmodell,📁 Akte & Vorgang,Backend,Mittel,3,3,Fertig,"PostgreSQL, Modul-Adapter (ENG-02)","Vorgang/Akte als eigenständiger Objekttyp – Status (offen/in Bearbeitung/geschlossen), Aktenzeichen, Verantwortlicher, Liste referenzierter Fremdobjekte (Typ + ID + Herkunfts-Board, z. B. „DMS-Dokument #123“ oder „Mail-Nachricht #456“) über den bestehenden Modul-Adapter.",ENG-02,VOR-02 VOR-03 VOR-04 VOR-05,"Akte kann Objekte aus mehreren Modulen gleichzeitig referenzieren, ohne deren Rohdaten zu duplizieren +Statuswechsel ist nachvollziehbar protokolliert +Aktenzeichen ist pro Tenant eindeutig und konfigurierbar (Format)","Akte mit Referenzen auf ein fiktives DMS-Objekt und ein fiktives Mail-Objekt gleichzeitig angelegt und geprüft +Statuswechsel im Test erzeugt Protokolleintrag mit Person und Zeitpunkt +Zwei Akten desselben Tenants mit identischem Aktenzeichen werden im Test abgewiesen" +VOR-02,Vermerke/Notizen an Akte/Vorgang,📁 Akte & Vorgang,Backend,Einfach,2,4,Fertig,"PostgreSQL, unveränderliche Einträge","Freitext-Vermerke an einer Akte, jeweils mit Autor und Zeitstempel, unveränderlich nach dem Speichern (Ergänzung statt Bearbeitung, wie ein Aktenvermerk in der Realität).",VOR-01,VOR-04 VOR-05,"Vermerk ist nach dem Speichern nicht mehr veränderbar, nur neue Vermerke ergänzbar +Autor und Zeitstempel sind Pflichtfelder +Vermerke sind chronologisch sortiert abrufbar","Versuch, einen gespeicherten Vermerk zu ändern, wird im Test abgewiesen +Vermerk ohne Autor oder Zeitstempel wird im Test abgewiesen +Abruf mehrerer Vermerke liefert im Test chronologische Reihenfolge" +VOR-03,Wiedervorlage (Akte/Objekt-Terminverknüpfung),📁 Akte & Vorgang,Backend,Mittel,3,4,Fertig,"TSK-Engine, PostgreSQL","Wiedervorlage-Termin an eine Akte oder ein einzelnes referenziertes Objekt (auch ohne vollständige Akte) hängen, nutzt die bestehende TSK-Engine (Aufgabenmodell/Fristen/Erinnerungen) für Fälligkeit und Benachrichtigung.",VOR-01 TSK-01,VOR-04 VOR-05,"Wiedervorlage kann sowohl an eine ganze Akte als auch an ein einzelnes Objekt gehängt werden +Fälliger Termin erzeugt eine Aufgabe über TSK-01/TSK-02 +Erledigte Wiedervorlage ist von offener unterscheidbar, keine Löschung der Historie","Wiedervorlage an Akte und Wiedervorlage an Einzelobjekt im Test jeweils erfolgreich angelegt +Fälliger Termin erzeugt im Test genau eine Aufgabe über die TSK-Engine +Als erledigt markierte Wiedervorlage bleibt im Test in der Historie sichtbar und unterscheidbar von offenen" +VOR-04,Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte,📁 Akte & Vorgang,Backend,Mittel,3,5,Fertig,"REST-Schnittstelle, read-only","Read-only API, über die ein Modul (DMS/Mail) für eine gegebene Objekt-Referenz (Typ+ID) abfragt: gehört das zu einer Akte, welche Vermerke/offenen Wiedervorlagen gibt es.",VOR-01 VOR-02 VOR-03,QA-06 VOR-06,"Abfrage nach Objekt-Referenz liefert Akte, Vermerke und offene Wiedervorlagen in einem Aufruf +Antwortzeit ist für den Einsatz in einer Dokument-/Mail-Detailansicht ausreichend kurz (keine spürbare Verzögerung beim Laden) +API respektiert Berechtigungen – nur Vermerke/Akten sichtbar, für die der anfragende Nutzer berechtigt ist +Abfrage ist zwingend tenant-gescoped – Tenant-Filter sitzt in der Query-/Repository-Schicht, nicht als nachgelagerter Filter (siehe SICHERHEITSKONZEPT.md); Objekte anderer Mandanten sind selbst bei geratener/falscher Objekt-Referenz nie sichtbar","Abfrage einer bekannten Objekt-Referenz liefert im Test Akte, Vermerke und offene Wiedervorlagen in einem Aufruf +Antwortzeit im Test unter der für Detailansichten festgelegten Schwelle gemessen +Abfrage mit nicht berechtigtem Nutzer liefert im Test keine fremden Akte-/Vermerkdaten +Abfrage mit Objekt-Referenz eines fremden Mandanten liefert im Test keine Daten, auch wenn die Referenz-ID gültig/erratbar ist" +VOR-05,Akten-Übersicht (Workflow-eigene Oberfläche),📁 Akte & Vorgang,Frontend,Mittel,3,5,Fertig,Next.js/React/TypeScript,"Eigenständige Übersicht aller Akten im Workflow-Modul selbst (Liste, Filter nach Status/Verantwortlichem, Detailansicht mit Vermerken/verknüpften Objekten). Für Fälle, in denen man direkt in Workflow arbeitet statt über DMS/Mail einzusteigen. Zusätzlich eine Kanban-Ansicht für Wiedervorlagen mit Drag & Drop zwischen Statusspalten.",VOR-01 VOR-02 VOR-03 SHL-01,,"Liste aller Akten ist nach Status und Verantwortlichem filterbar +Detailansicht zeigt Vermerke, Wiedervorlagen und verknüpfte Objekte einer Akte vollständig an +Übersicht funktioniert unabhängig davon, ob der Zugriff über DMS/Mail oder direkt in Workflow erfolgt +Kanban-Ansicht für Wiedervorlagen zeigt Spalten nach Fälligkeit/Status, Drag & Drop zwischen Spalten schreibt den neuen Status über VOR-03 zurück +Kanban-Ansicht zeigt ausschließlich Wiedervorlagen des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet","Filter nach Status und Verantwortlichem liefert im Test korrekte Teilmengen +Detailansicht einer Testakte zeigt im Test Vermerke, Wiedervorlagen und verknüpfte Objekte vollständig +Akte mit Referenzen aus mehreren Modulen wird im Test korrekt dargestellt +Verschieben einer Wiedervorlage per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über VOR-03 +Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Wiedervorlagen des aktuell aktiven Mandanten" +QA-06,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,6,Fertig,"Vertragstests (Consumer-Driven Contracts), CI-Pipeline","Vertragstests für die beiden von DMS/Mail konsumierten Schnittstellen – Push-Registrierung (ENG-02 Modul-Adapter) und Pull-Rückkanal (VOR-04 Rückkanal-API für Akte/Vermerke/Wiedervorlage). Beide Richtungen müssen gegen Breaking Changes abgesichert sein, nicht nur eine.",VOR-04 ENG-02,QA-05,"Vertragstests decken ENG-02 (Push) und VOR-04 (Pull) beide ab +Absichtlich brechender Schema-Wechsel an jeder der beiden Schnittstellen lässt Tests fehlschlagen +Tests laufen automatisiert in der CI","Testlauf gegen aktuellen Stand grün +Simulierte Breaking Change an beiden Schnittstellen einzeln erkannt +CI-Integration nachgewiesen" +RTE-05,KI-gestützte Routing-Vorschläge (Kopplung AI WFS-02),🔁 Regelbasiertes Routing,Backend,Mittel,3,6,Fertig,"HTTP-Client gegen AI-Vorschlags-API (WFS-02), Fallback auf regelbasiertes Routing","Vor einer regelbasierten Routing-Entscheidung optional einen KI-Vorschlag von NEXARCH AI (WFS-02) abrufen und dem Bearbeiter als Empfehlung anzeigen – die regelbasierte Engine bleibt die maßgebliche Entscheidungsinstanz, KI liefert nur einen Vorschlag.",RTE-04,QA-04,"Routing-Ansicht zeigt bei aktiviertem AI-Modul einen KI-Vorschlag zusätzlich zur regelbasierten Entscheidung an +Ist das AI-Modul nicht aktiviert oder nicht erreichbar, funktioniert das regelbasierte Routing unverändert ohne Vorschlag (fail open, kein Blockieren) +Ein KI-Vorschlag wird niemals automatisch übernommen – Bearbeiter muss ihn aktiv bestätigen","Test gegen echte AI-Testinstanz: Vorschlag wird korrekt angezeigt und nachvollziehbar begründet +Test: AI-Endpunkt nicht erreichbar – regelbasiertes Routing läuft unverändert weiter, keine Fehlermeldung im Regelpfad +Test: KI-Vorschlag wird nicht bestätigt – Routing folgt der regelbasierten Entscheidung, nicht dem Vorschlag" +QA-07,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,7,Fertig,"Lastgenerator, Messprotokoll","Lasttest für Workflow unter realistischer Last aus DMS und Mail gleichzeitig – insbesondere Modul-Adapter-Ereignispfad (ENG-02), Genehmigungs-Engine (APR) und Routing (RTE) unter Last.",ENG-02 RTE-04,QA-05,"Definierte Ziel-Latenz für die Ereigniszustellung (ENG-02) unter Last aus zwei Modulen eingehalten +Genehmigungs-Engine bleibt unter simulierter Mehrfach-Zustellung korrekt (keine doppelten Freigaben, keine verlorenen Anfragen) +Regelbasiertes Routing bleibt unter Last korrekt und deterministisch","Lasttest mit simulierten parallelen Ereignissen aus DMS und Mail durchgeführt, Ergebnis dokumentiert +Test auf doppelte/verlorene Genehmigungsanfragen unter Last +Routing-Determinismus unter Last geprüft (gleiche Eingabe, gleiches Ergebnis)" +QA-08,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,6,Fertig,"Prüfwerkzeuge, Bildschirmleser","Unabhängige Prüfung aller Workflow-Oberflächen (Genehmigungs-Oberfläche, Aufgaben-Oberfläche, Routing-Regel-Editor, Akten-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.",APR-03 TSK-04 RTE-03 VOR-05,QA-05,"Keine kritischen Verstöße offen +Manueller Bildschirmleser-Durchlauf dokumentiert +Restbefunde sind mit Frist eingeplant","Automatisierte Prüfung über alle Hauptseiten +Vollständiger Ablauf ohne Maus durchgeführt +Auditbericht abgelegt" +VOR-06,Tenant-Kontext-Validierung im Rückkanal (DMS/Mail-Abfrage),📁 Akte & Vorgang,Backend,Mittel,2,8,Fertig,"Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go","VOR-04 ist eine Read-only-API, über die DMS/Mail für eine Objekt-Referenz abfragen, ob sie zu einer Akte gehört, inklusive Vermerken und Wiedervorlagen. Ohne eigene Validierung würde Workflow dem vom aufrufenden Modul übergebenen Tenant-Kontext blind vertrauen und könnte dadurch Akte-Daten eines fremden Mandanten herausgeben, obwohl Workflow selbst korrekt mandantengetrennt ist. VOR-04 validiert den mitgelieferten Nutzer-Tenant-Kontext unabhängig gegen die Core-Registry und gegen den Tenant der angefragten Akte, bevor Vermerke/Wiedervorlagen zurückgegeben werden.",VOR-04,,"Jede VOR-04-Anfrage trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter +Workflow validiert, dass der übergebene Tenant-Kontext zum Tenant der angefragten Akte passt, unabhängig vom Service-Credential-Scope des aufrufenden Moduls +Eine Anfrage mit falschem/fremdem Tenant-Kontext wird abgelehnt und protokolliert, statt Daten preiszugeben","Test: VOR-04-Anfrage mit korrektem Nutzer-Tenant-Kontext liefert erwartete Akte-Daten +Test: VOR-04-Anfrage mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt +Integrationstest über DMS DOC-13 → VOR-04 mit zwei verschiedenen Tenants, prüft Isolation" +ENG-06,Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail,🔀 Workflow-Engine,Backend,Mittel,2,8,Fertig,"Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go","ENG-02 nimmt Objekttyp- und Auslöser-Ereignis-Registrierungen von DMS und Mail entgegen. Analog zu Archive `RET-12` muss jede Registrierung den mitgelieferten Tenant-Kontext unabhängig gegen die Core-Registry (TEN-01) validieren, statt der Angabe des registrierenden Moduls zu vertrauen.",ENG-02,,"Jede Objekttyp-/Ereignis-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird +Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert +Bestehende, korrekte Registrierungsabläufe aus ENG-02 funktionieren unverändert","Test: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen +Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt +Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig" +ENG-07,Technische Durchsetzung Append-only für das Instanzschritt-Protokoll,🔀 Workflow-Engine,Backend,Einfach,2,8,Fertig,"PostgreSQL (REVOKE/Trigger), Go","ENG-04 konzipiert ein vollständiges, unveränderliches Protokoll jedes Instanzschritts, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` und DMS `VER-08` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.",ENG-04,,"Die vom Workflow-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen +Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert +Bestehende ENG-04-Funktionalität (Schreiben/Lesen neuer Einträge) bleibt unverändert nutzbar","Testet UPDATE/DELETE gegen die Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung +Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird +Regressionstest: normales Schreiben/Lesen von Protokolleinträgen funktioniert weiterhin" +ENG-09,Workflow-Trigger nach Upload und Auto-Regel,🔀 Workflow-Engine,Backend,Mittel,3,9,Fertig,"Modul-Adapter-Ereigniskanal, Postgres-Jobqueue, Migration Workflow-Schema","Ereignisvertrag und Verarbeitung: ein DMS-Ereignis (Upload, Auto-Regel, Metadatenaenderung) erzeugt ueber den Modul-Adapter genau eine Aufgabe/Genehmigung je Mandant, dedupliziert und tenant-gebunden.",ENG-02 VOR-04,,"Der Ereignisvertrag ist festgelegt und wird ueber den Modul-Adapter (ENG-02) registriert; Service-Authentifizierung und Tenant-Bindung +Eine mandantenweite Zuordnung von Ereignis und Bedingung zu Aufgabe/Genehmigungslauf ist konfigurierbar; genau eine Aufgabe je Ereignis, Dedup, Nachzustellung nach Ausfall +Aufgaben entstehen nur fuer berechtigte Rollen; Dokumentverweis nur ueber Modul-Rueckkanal mit Tenant-Kontext, Cross-Tenant wird abgelehnt","Doppelzustellung desselben Ereignisses ergibt genau eine Aufgabe, Reihenfolge/Wiederholung nach Ausfall getestet +Ausfall des Workflow-Moduls: DMS laeuft weiter, Nachzustellung ohne Verlust/Dubletten +Cross-Tenant negativ: falscher Mandant/fremde Dokument-ID wird abgelehnt und protokolliert" +ENG-11,Workflow-App: gebündelter Diensteinstiegspunkt (cmd/workflow-app),🔀 Workflow-Engine,Backend,Mittel,2,9,Fertig,"net/http.ServeMux, pgxpool, Umgebungsvariablen fuer DSN/Listen-Adresse","Buendelt alle bestehenden Workflow-API-Pakete (approvalapi, backchannelapi, caseoverviewapi, routingruleapi, taskapi, moduleadapter, escalationnotify, routingsuggestapi-Client) zu einem einzigen startbaren Dienst cmd/workflow-app, analog connect/cmd/connect-app.",ENG-02 ENG-09 TSK-05,,"cmd/workflow-app startet einen einzigen HTTP-Dienst, der alle bestehenden Workflow-API-Pakete unter ihren jeweiligen Routen bereitstellt +DSN und Listen-Adresse ausschliesslich ueber Umgebungsvariablen, keine Zugangsdaten im Code +Fehlende Pflicht-Umgebungsvariable fuehrt zu klarer Fehlermeldung beim Start, nicht zu einem stillen Absturz +Dienst startet real auf Host 204 und beantwortet mindestens einen Endpunkt je eingebundenem API-Paket","Realer Start auf Host 204 mit Wegwerf-DB, mindestens ein Aufruf je eingebundenem API-Paket erfolgreich +Fehlende Pflicht-Umgebungsvariable: Dienst beendet sich mit klarer Fehlermeldung, kein Port offen +Bestehende Modul-Testsuite bleibt unveraendert gruen" +SEC-01,Echte Authentifizierungsmiddleware vor allen Fach-API-Handlern (Approver-Impersonation über X-User-Id),🔒 Sicherheit,Backend,Mittel,3,10,Backlog,"Echte Authentifizierungsmiddleware (analog DMS moduleauth-Muster), Go, net/http.ServeMux-Middleware-Kette","Security-Review (main, 2026-10, Fable 5.1): approvalapi/caseapi/caseoverviewapi/routingruleapi/backchannelapi lesen den Akteur ungeprüft aus dem rohen X-User-Id-Header, cmd/workflow-app registriert sie ohne Auth-Middleware. Angriff: fremde Freigaben im Namen anderer Nutzer erteilen, Akten/Routing-Regeln/Rückkanal-Daten über gefälschten Header manipulieren bzw. lesen.",APR-01 APR-02 VOR-01 RTE-01 VOR-04 ENG-11,,"Jeder Fach-API-Handler (approvalapi, caseapi, caseoverviewapi, routingruleapi, backchannelapi) verlangt ein verifiziertes Session- oder Modul-Token, bevor er die Anfrage verarbeitet +Der Akteur wird ausschließlich aus dem verifizierten Token abgeleitet, ein roher X-User-Id-Header ohne gültiges Token wird ignoriert bzw. die Anfrage abgelehnt +Eine Anfrage ohne gültiges Token oder mit manipuliertem X-User-Id-Header eines anderen Nutzers wird mit 401/403 abgewiesen, bevor Fachlogik erreicht wird +Bestehende, korrekt authentifizierte Abläufe über alle fünf betroffenen Handler-Pakete funktionieren unverändert","Angriff vor Umsetzung reproduziert: fremde X-User-Id erteilt Freigabe im Namen eines anderen Nutzers +Nach Umsetzung: derselbe Angriff gegen alle fünf Handler-Pakete wird mit 401/403 blockiert +Regressionstest: Nutzer mit gültigem Token kann weiterhin eigene Freigaben/Akten/Routing-Regeln/Rückkanal-Daten bearbeiten bzw. lesen" +SEC-02,Vier-Augen-Prinzip tatsächlich verdrahten und fail-closed statt fail-open,🔒 Sicherheit,Backend,Mittel,2,10,Backlog,"Go, bestehendes dualcheck-Paket aus APR-02, PostgreSQL","Security-Review: dualcheck-Paket aus APR-02 ist nirgends in den echten Genehmigungspfad eingebunden (grep liefert 0 Treffer außerhalb eigener Tests), approval.Create prüft nicht assignee != requestedBy, dualcheck.go liefert bei DB-Fehler fail-open (false, nil) statt zu blockieren.",APR-01 APR-02,,"approval.Create bzw. der Genehmigungspfad ruft für vier-augen-pflichtige Prozesstypen tatsächlich dualcheck auf +Eine Selbstfreigabe (assignee == requestedBy) wird im echten Genehmigungspfad abgelehnt +dualcheck.go blockiert bei Datenbankfehler die Freigabe (fail-closed) statt sie durchzulassen +Bestehende APR-01/APR-02-Funktionalität für nicht vier-augen-pflichtige Prozesstypen bleibt unverändert nutzbar","Vor Umsetzung: Selbstfreigabe über echten Pfad gelingt, da dualcheck nicht eingebunden ist +Vor Umsetzung: simulierter DB-Fehler in dualcheck führt zu fail-open +Nach Umsetzung: Selbstfreigabe über echten Pfad wird abgelehnt +Nach Umsetzung: simulierter DB-Fehler blockiert die Freigabe" +SEC-03,"Routing-Regel-Schreibzugriff auf Verantwortliche beschränken, Rückkanal mit Service-Token-Pflicht",🔒 Sicherheit,Backend,Mittel,2,10,Backlog,"Rollenmodell (Admin-/Routing-Verantwortliche-Rolle), created_by-Spalte, Service-Token-Prüfung (analog moduleadapter), Go, PostgreSQL-Migration","Security-Review: routingruleapi lässt POST/PUT jedem authentifizierten Nutzer zu, keine created_by-Spalte; backchannelapi prüft X-Service-Token beim Rückkanal nicht. Angriff: beliebiger Nutzer schreibt Routing-Regeln um bzw. liest Rückkanal-Daten ohne Service-Authentifizierung.",RTE-01 RTE-02 VOR-04 SEC-01,,"POST/PUT auf Routing-Regeln ist nur für Nutzer mit Admin-/Routing-Verantwortliche-Rolle möglich +Jede angelegte/geänderte Routing-Regel speichert den handelnden Nutzer in einer created_by-Spalte +GET /objects/{module}/{type}/{id}/context verlangt ein gültiges X-Service-Token, bevor die bestehende Slug-/Responsible-Prüfung greift","Vor Umsetzung: gewöhnlicher Nutzer ohne Rolle ändert Routing-Regel erfolgreich +Vor Umsetzung: Rückkanal liefert Daten ohne X-Service-Token +Nach Umsetzung: gewöhnlicher Nutzer wird abgewiesen, Nutzer mit Rolle kann weiterhin ändern, created_by ist gesetzt +Nach Umsetzung: Rückkanal ohne gültiges Token abgewiesen, mit Token funktioniert bestehende Prüfung weiterhin" +SEC-04,Tenant-gebundener Dedupe-Key gegen Dedupe-Key-Vergiftung durch abgelehnte Fremd-Tenant-Events,🔒 Sicherheit,Backend,Mittel,2,10,Backlog,"PostgreSQL-Migration (UNIQUE(tenant_slug, dedupe_key) statt globalem Unique-Index), Go","Security-Review: moduleadapter/events.go belegt den global-uniquen dedupe_key auch bei abgelehnten Fremd-Tenant-Events (ON CONFLICT DO NOTHING), Handler liefert trotzdem 202. Angriff: vorhersagbarer Dedupe-Key mit falschem Tenant-Kontext blockiert künftige legitime Events mit demselben Key stillschweigend.",ENG-02 ENG-09,,"dedupe_key ist nur innerhalb eines Tenants eindeutig (UNIQUE(tenant_slug, dedupe_key)), nicht global +Ein wegen falschem Tenant-Kontext abgelehntes Event belegt den Dedupe-Key nicht dauerhaft +Ein legitimes Event mit zuvor fremd-belegtem Dedupe-Key wird nach der Korrektur korrekt verarbeitet +Bestehende Dedup-Funktionalität innerhalb eines Tenants bleibt unverändert korrekt","Vor Umsetzung: fremd-Tenant-Event mit vorhersagbarem Key blockiert nachfolgendes legitimes Event +Nach Umsetzung: legitimes Event erzeugt nachweislich die erwartete Aufgabe/Genehmigung +Regressionstest: zwei Tenants mit identischem Dedupe-Key-Schema werden unabhängig korrekt verarbeitet +Regressionstest: doppelte Zustellung innerhalb eines Tenants erzeugt weiterhin genau eine Aufgabe" +SEC-05,Rohe Datenbankfehler im moduleadapter-Handler normalisieren,🔒 Sicherheit,Backend,Einfach,1,10,Backlog,"Fehlernormalisierung analog apierror.Normalize-Muster aus Core, Go",Security-Review: moduleadapter/handler.go gibt an drei Stellen rohe pgx-Fehlermeldungen (Constraint-/Schema-Details) direkt an den Client zurück.,ENG-02,,"Alle drei Fehlerstellen in moduleadapter/handler.go geben eine normalisierte Fehlermeldung aus, nicht err.Error() roh +Interne Details (Constraint-/Tabellen-/Spaltennamen, SQL-Fragmente) erscheinen in keiner HTTP-Antwort dieser drei Stellen +Der tatsächliche Fehler bleibt serverseitig im Log vollständig erhalten +Bestehendes Fehlerverhalten für Clients (korrekter HTTP-Statuscode) bleibt erhalten","Vor Umsetzung: provozierter DB-Fehler an allen drei Stellen zeigt rohe pgx-Meldung in der HTTP-Antwort +Nach Umsetzung: HTTP-Antwort enthält keine internen Details mehr +Serverseitiges Log enthält weiterhin die vollständige Originalfehlermeldung +Regressionstest: normale fehlerfreie Aufrufe funktionieren unverändert" +SEC-06,Technische Durchsetzung Append-only für verbleibende Workflow-Protokolltabellen,🔒 Sicherheit,Backend,Mittel,2,10,Backlog,"PostgreSQL (REVOKE/Trigger, inkl. Sequence-GRANT bei BIGSERIAL), Go, analog ENG-07/Core AUD-07/DMS VER-08","Security-Review: workflow_instance_history/case_notes haben Trigger ohne REVOKE (unvollständig), approval_tasks/dualcheck_confirmations/routing_decisions sind komplett ungesichert (kein Trigger, kein REVOKE).",ENG-07 APR-01 APR-02 RTE-02 VOR-02,,"workflow_instance_history und case_notes erhalten zusätzlich zum Trigger ein REVOKE UPDATE/DELETE von der Anwendungsrolle +approval_tasks, dualcheck_confirmations, routing_decisions erhalten REVOKE UPDATE/DELETE und einen Trigger mit RAISE WARNING, inkl. Sequence-GRANT bei BIGSERIAL +Die Anwendungsrolle kann bei keiner der fünf Tabellen Protokolleinträge verändern oder löschen +Bestehende INSERT/SELECT-Funktionalität aller fünf Tabellen bleibt unverändert nutzbar","Vor Umsetzung: UPDATE/DELETE-Test gegen alle fünf Tabellen zeigt, welche davon tatsächlich veränderbar sind +Nach Umsetzung: Rechteverweigerung bei allen fünf Tabellen +Änderungsversuch wird bei allen fünf Tabellen selbst sichtbar protokolliert +Regressionstest: normales Schreiben/Lesen inkl. BIGSERIAL-Sequence-Nutzung funktioniert weiterhin" diff --git a/workflow-kanban/board.json b/workflow-kanban/board.json new file mode 100644 index 00000000..0f0fb82e --- /dev/null +++ b/workflow-kanban/board.json @@ -0,0 +1,1664 @@ +{ + "erzeugtAm": "2026-08-26", + "totalDays": 91, + "epics": [ + { + "key": "ENG", + "name": "Workflow-Engine", + "emoji": "🔀", + "color": "#4338CA", + "description": "Zustandsautomat, Modul-Adapter-Schnittstelle, deklaratives Prozessdefinitions-Format, Instanz-Historie und Fehlerbehandlung." + }, + { + "key": "APR", + "name": "Genehmigungen & Freigaben", + "emoji": "✅", + "color": "#0D9488", + "description": "Freigabe-Postfach, Vier-Augen-Freigabe, Genehmigungs-Oberfläche und Delegation bei Abwesenheit." + }, + { + "key": "TSK", + "name": "Aufgaben, Fristen & Eskalation", + "emoji": "⏱️", + "color": "#C2410C", + "description": "Aufgabenmodell, Fristen mit Kalenderlogik, Erinnerungen/Eskalationsregeln und die Aufgaben-Oberfläche." + }, + { + "key": "RTE", + "name": "Regelbasiertes Routing", + "emoji": "🔁", + "color": "#BE185D", + "description": "Modulunabhängiges Routing-Regel-Modell, Ausführungs-Engine, Regel-Editor und Simulation." + }, + { + "key": "QA", + "name": "Prüfungen & Qualitätssicherung", + "emoji": "✅", + "color": "#16A34A", + "description": "Teststrategie und verbindliche Prüfgates je Ausbaustufe. Ein Gate schließt eine Ausbaustufe ab." + }, + { + "key": "VOR", + "name": "Akte & Vorgang", + "emoji": "📁", + "color": "#92400E", + "description": "Akte/Vorgang-Objektmodell, Vermerke, Wiedervorlage und Rückkanal-API für DMS/Mail sowie Workflow-eigene Akten-Übersicht." + }, + { + "key": "SEC", + "name": "Sicherheit", + "emoji": "🔒", + "color": "#B91C1C", + "description": "Verifizierte Security-Befunde aus Code-Reviews und deren technische Behebung." + } + ], + "waves": [ + { + "welle": 1, + "codes": [ + "ENG-01", + "QA-01" + ] + }, + { + "welle": 2, + "codes": [ + "ENG-02", + "ENG-03", + "ENG-04", + "ENG-05", + "TSK-01" + ] + }, + { + "welle": 3, + "codes": [ + "APR-01", + "TSK-02", + "RTE-01", + "QA-02", + "VOR-01" + ] + }, + { + "welle": 4, + "codes": [ + "APR-02", + "APR-03", + "APR-04", + "TSK-03", + "TSK-04", + "RTE-02", + "RTE-03", + "VOR-02", + "VOR-03" + ] + }, + { + "welle": 5, + "codes": [ + "TSK-05", + "RTE-04", + "QA-03", + "VOR-04", + "VOR-05" + ] + }, + { + "welle": 6, + "codes": [ + "QA-04", + "QA-06", + "RTE-05" + ] + }, + { + "welle": 7, + "codes": [ + "QA-05", + "QA-07" + ] + }, + { + "welle": 8, + "codes": [ + "VOR-06", + "ENG-06", + "ENG-07" + ] + } + ], + "kritischerPfad": { + "path": [ + "ENG-01", + "ENG-02", + "RTE-01", + "RTE-02", + "RTE-04", + "QA-04", + "QA-05" + ], + "days": 19 + }, + "produktDna": { + "uebernehmen": [ + { + "produkt": "Alfresco", + "staerke": "Echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik – Kernidee dieses Boards." + }, + { + "produkt": "Camunda/Zeebe", + "staerke": "Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse, leichtgewichtig gedacht statt BPMN-Vollausbau." + }, + { + "produkt": "Trello/Linear", + "staerke": "Einfache, schnelle Aufgaben-Oberfläche als Vorbild – kein Schwergewicht." + } + ], + "vermeiden": [ + { + "produkt": "Alfresco – Ressourcen-Overhead und Konfigurationskomplexität der Plattform.", + "ansatz": "Schlanker Go-Dienst mit Postgres-Jobqueue statt Java-Anwendungsserver und zusätzlicher Message-Queue-Infrastruktur." + }, + { + "produkt": "Camunda/Zeebe – voller BPMN-Modellierungsapparat.", + "ansatz": "Ein lesbares, versionierbares Prozessdefinitionsformat statt grafischem Modellierungswerkzeug." + } + ] + }, + "epicDna": { + "ENG": { + "leitsatz": "Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.", + "uebernehmen": [ + "Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.", + "Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.", + "Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt." + ], + "vermeiden": [ + "Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.", + "Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start." + ] + }, + "APR": { + "leitsatz": "Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.", + "uebernehmen": [ + "Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.", + "Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.", + "Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit." + ], + "vermeiden": [ + "Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.", + "Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen." + ] + }, + "TSK": { + "leitsatz": "Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.", + "uebernehmen": [ + "Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.", + "Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.", + "Fristen mit Arbeitstagslogik statt naiver Kalendertage." + ], + "vermeiden": [ + "Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.", + "Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben." + ] + }, + "RTE": { + "leitsatz": "Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.", + "uebernehmen": [ + "paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.", + "Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.", + "Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert." + ], + "vermeiden": [ + "Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.", + "Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell." + ] + }, + "QA": { + "leitsatz": "Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.", + "uebernehmen": [ + "Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.", + "Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung." + ], + "vermeiden": [ + "Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.", + "Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen." + ] + } + }, + "tickets": [ + { + "code": "ENG-01", + "title": "Workflow-Engine & Zustandsmodell", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Komplex", + "estimateDays": 4, + "tech": "Zustandsautomat, PostgreSQL, pgx/v5", + "description": "Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.", + "dependsOn": [], + "akzeptanz": [ + "Zustände und zulässige Übergänge sind je Prozesstyp definierbar", + "Unzulässiger Übergang wird abgewiesen", + "Laufende Instanz überlebt einen Neustart" + ], + "pruefungen": [ + "Unzulässiger Übergang wird im Test abgewiesen", + "Gleichzeitige Übergänge zweier Nutzer erzeugen keinen Fehlzustand", + "Neustart des Dienstes mit laufender Instanz geprüft" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 1, + "unlocks": [ + "ENG-02", + "ENG-03", + "ENG-04", + "ENG-05", + "APR-01", + "TSK-01" + ], + "prompt": "# ENG-01 – Workflow-Engine & Zustandsmodell\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 1\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nZustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.\n\n**Technische Grundlage:** Zustandsautomat, PostgreSQL, pgx/v5\n\n## Produkt-DNA für diesen Bereich\n> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.\n\n**Übernehmen:**\n- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.\n- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.\n- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.\n\n**Bewusst vermeiden:**\n- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.\n- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.\n\n**Für genau diese Kachel:** Der Zustandsautomat ist die Grundvoraussetzung, damit DMS und Mail keine eigene Workflow-Logik bauen müssen.\n\n## Ausgangslage\nDiese Kachel hat keine Vorbedingungen und ist sofort startbar.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Zustände und zulässige Übergänge sind je Prozesstyp definierbar\n2. Unzulässiger Übergang wird abgewiesen\n3. Laufende Instanz überlebt einen Neustart\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Unzulässiger Übergang wird im Test abgewiesen\n2. Gleichzeitige Übergänge zweier Nutzer erzeugen keinen Fehlzustand\n3. Neustart des Dienstes mit laufender Instanz geprüft\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger)\n- `ENG-03` Prozessdefinitions-Format (deklarativ, versionierbar)\n- `ENG-04` Workflow-Instanz-Historie & Nachvollziehbarkeit\n- `ENG-05` Fehlerbehandlung & Retry bei Workflow-Schritten\n- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend)\n- `TSK-01` Aufgabenmodell & Zuweisung\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-01: workflow engine zustandsmodell`\n- Branch: `feature/eng-01-workflow-engine-zustandsmodell`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-02", + "title": "Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger)", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "REST-Schnittstelle, Adapter-Registrierung", + "description": "Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Modul kann Objekttyp und Trigger ohne Codeänderung an der Engine registrieren", + "Registrierung ist versionierbar und rückrollbar", + "Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz" + ], + "pruefungen": [ + "Testadapter aus fiktivem DMS- und Mail-Modul beide korrekt registriert", + "Doppelte Registrierung wird abgewiesen", + "Deregistrierung entfernt zugehörige Trigger vollständig" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 2, + "unlocks": [ + "APR-01", + "QA-02", + "QA-06", + "RTE-01", + "VOR-01", + "QA-07", + "ENG-06" + ], + "prompt": "# ENG-02 – Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger)\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSchnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.\n\n**Technische Grundlage:** REST-Schnittstelle, Adapter-Registrierung\n\n## Produkt-DNA für diesen Bereich\n> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.\n\n**Übernehmen:**\n- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.\n- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.\n- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.\n\n**Bewusst vermeiden:**\n- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.\n- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.\n\n**Für genau diese Kachel:** Ohne diese Schnittstelle müsste jedes Modul die Engine selbst verstehen – der Adapter kehrt das um.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Modul kann Objekttyp und Trigger ohne Codeänderung an der Engine registrieren\n2. Registrierung ist versionierbar und rückrollbar\n3. Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testadapter aus fiktivem DMS- und Mail-Modul beide korrekt registriert\n2. Doppelte Registrierung wird abgewiesen\n3. Deregistrierung entfernt zugehörige Trigger vollständig\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend)\n- `RTE-01` Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig)\n- `QA-02` Prüfgate Engine & Adapter\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-02: modul adapter schnittstelle dms mail registrieren objekttypen trigger`\n- Branch: `feature/eng-02-modul-adapter-schnittstelle-dms-mail-registrieren-objekttypen-trigger`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-03", + "title": "Prozessdefinitions-Format (deklarativ, versionierbar)", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "YAML/JSON-Prozessdefinition, Schema-Validierung", + "description": "Lesbares Konfigurationsformat für Prozessdefinitionen: Zustände, Übergänge, Bedingungen, Zuständigkeiten. Jede Definition ist versioniert.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Prozessdefinition ist ohne Codeänderung änderbar", + "Ungültige Definition wird beim Laden abgewiesen", + "Ältere Version bleibt für laufende Instanzen gültig" + ], + "pruefungen": [ + "Schema-Validierung gegen fehlerhafte Definition getestet", + "Versionswechsel während laufender Instanz verändert deren Verhalten nicht rückwirkend", + "Rollback auf Vorgängerversion funktioniert" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 2, + "unlocks": [ + "QA-02" + ], + "prompt": "# ENG-03 – Prozessdefinitions-Format (deklarativ, versionierbar)\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nLesbares Konfigurationsformat für Prozessdefinitionen: Zustände, Übergänge, Bedingungen, Zuständigkeiten. Jede Definition ist versioniert.\n\n**Technische Grundlage:** YAML/JSON-Prozessdefinition, Schema-Validierung\n\n## Produkt-DNA für diesen Bereich\n> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.\n\n**Übernehmen:**\n- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.\n- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.\n- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.\n\n**Bewusst vermeiden:**\n- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.\n- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.\n\n**Für genau diese Kachel:** Ein lesbares Format statt eines grafischen Modellierers hält die Einstiegshürde niedrig.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Prozessdefinition ist ohne Codeänderung änderbar\n2. Ungültige Definition wird beim Laden abgewiesen\n3. Ältere Version bleibt für laufende Instanzen gültig\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Schema-Validierung gegen fehlerhafte Definition getestet\n2. Versionswechsel während laufender Instanz verändert deren Verhalten nicht rückwirkend\n3. Rollback auf Vorgängerversion funktioniert\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-03: prozessdefinitions format deklarativ versionierbar`\n- Branch: `feature/eng-03-prozessdefinitions-format-deklarativ-versionierbar`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-04", + "title": "Workflow-Instanz-Historie & Nachvollziehbarkeit", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Append-only Protokolltabelle, PostgreSQL", + "description": "Vollständiges, unveränderliches Protokoll jedes Instanzschritts: Person, Zeitpunkt, Zustand, Begründung.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Jeder Übergang wird protokolliert", + "Protokoll ist nicht nachträglich veränderbar", + "Historie ist je Instanz vollständig abrufbar" + ], + "pruefungen": [ + "Manipulationsversuch am Protokoll schlägt fehl", + "Historie einer Beispielinstanz enthält alle Schritte in korrekter Reihenfolge", + "Abfrage großer Historien bleibt performant" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 2, + "unlocks": [ + "QA-02", + "ENG-07" + ], + "prompt": "# ENG-04 – Workflow-Instanz-Historie & Nachvollziehbarkeit\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVollständiges, unveränderliches Protokoll jedes Instanzschritts: Person, Zeitpunkt, Zustand, Begründung.\n\n**Technische Grundlage:** Append-only Protokolltabelle, PostgreSQL\n\n## Produkt-DNA für diesen Bereich\n> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.\n\n**Übernehmen:**\n- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.\n- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.\n- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.\n\n**Bewusst vermeiden:**\n- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.\n- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.\n\n**Für genau diese Kachel:** Nachvollziehbarkeit ist Voraussetzung für jede spätere Prüfung – nicht nachrüstbar.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder Übergang wird protokolliert\n2. Protokoll ist nicht nachträglich veränderbar\n3. Historie ist je Instanz vollständig abrufbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Manipulationsversuch am Protokoll schlägt fehl\n2. Historie einer Beispielinstanz enthält alle Schritte in korrekter Reihenfolge\n3. Abfrage großer Historien bleibt performant\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-04: workflow instanz historie nachvollziehbarkeit`\n- Branch: `feature/eng-04-workflow-instanz-historie-nachvollziehbarkeit`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-05", + "title": "Fehlerbehandlung & Retry bei Workflow-Schritten", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Postgres-Jobqueue, Backoff-Strategie", + "description": "Wiederholungslogik mit Backoff für fehlgeschlagene Workflow-Schritte, Dead-Letter-Pfad für dauerhaft fehlschlagende Instanzen.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Fehlgeschlagener Schritt wird automatisch wiederholt", + "Dauerhaft fehlschlagender Schritt landet in einem einsehbaren Fehlerzustand", + "Retry ist idempotent" + ], + "pruefungen": [ + "Simulierter Fehlerfall löst korrekte Wiederholung aus", + "Dead-Letter-Instanz ist auffindbar und manuell neu anstoßbar", + "Mehrfacher Retry erzeugt keine doppelte Wirkung" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 2, + "unlocks": [ + "QA-02" + ], + "prompt": "# ENG-05 – Fehlerbehandlung & Retry bei Workflow-Schritten\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nWiederholungslogik mit Backoff für fehlgeschlagene Workflow-Schritte, Dead-Letter-Pfad für dauerhaft fehlschlagende Instanzen.\n\n**Technische Grundlage:** Postgres-Jobqueue, Backoff-Strategie\n\n## Produkt-DNA für diesen Bereich\n> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.\n\n**Übernehmen:**\n- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.\n- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.\n- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.\n\n**Bewusst vermeiden:**\n- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.\n- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.\n\n**Für genau diese Kachel:** Fehlerbehandlung gehört ins Fundament der Engine, nicht in jede einzelne Prozessdefinition.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Fehlgeschlagener Schritt wird automatisch wiederholt\n2. Dauerhaft fehlschlagender Schritt landet in einem einsehbaren Fehlerzustand\n3. Retry ist idempotent\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Simulierter Fehlerfall löst korrekte Wiederholung aus\n2. Dead-Letter-Instanz ist auffindbar und manuell neu anstoßbar\n3. Mehrfacher Retry erzeugt keine doppelte Wirkung\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-02` Prüfgate Engine & Adapter\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-05: fehlerbehandlung retry bei workflow schritten`\n- Branch: `feature/eng-05-fehlerbehandlung-retry-bei-workflow-schritten`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "APR-01", + "title": "Freigabe-Postfach & Genehmigungsansicht (Backend)", + "epic": "APR", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "PostgreSQL, REST-Schnittstelle", + "description": "Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.", + "dependsOn": [ + "ENG-01", + "ENG-02" + ], + "akzeptanz": [ + "Offene Genehmigungsaufgaben sind je Nutzer abrufbar", + "Entscheidung ist genau einmal möglich", + "Entscheidung ist mit Begründung protokollierbar" + ], + "pruefungen": [ + "Bereits entschiedene Aufgabe lässt sich nicht doppelt entscheiden", + "Parallelentscheidung zweier Nutzer erzeugt keinen Fehlzustand", + "Entscheidung erscheint korrekt in der Instanz-Historie (ENG-04)" + ], + "status": "Fertig", + "epicName": "Genehmigungen & Freigaben", + "epicEmoji": "✅", + "wave": 3, + "unlocks": [ + "APR-02", + "APR-03", + "APR-04" + ], + "prompt": "# APR-01 – Freigabe-Postfach & Genehmigungsansicht (Backend)\n\n**Epic:** ✅ Genehmigungen & Freigaben | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nServerseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.\n\n**Technische Grundlage:** PostgreSQL, REST-Schnittstelle\n\n## Produkt-DNA für diesen Bereich\n> Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.\n\n**Übernehmen:**\n- Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.\n- Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit.\n\n**Bewusst vermeiden:**\n- Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.\n- Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen.\n\n**Für genau diese Kachel:** paperless-ngx, Docspell und ecoDMS haben keine echte Freigabe – hier entsteht der Mehrwert gegenüber allen Vorbildern.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.\n- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Offene Genehmigungsaufgaben sind je Nutzer abrufbar\n2. Entscheidung ist genau einmal möglich\n3. Entscheidung ist mit Begründung protokollierbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Bereits entschiedene Aufgabe lässt sich nicht doppelt entscheiden\n2. Parallelentscheidung zweier Nutzer erzeugt keinen Fehlzustand\n3. Entscheidung erscheint korrekt in der Instanz-Historie (ENG-04)\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `APR-02` Vier-Augen-Freigabe (generisches Muster)\n- `APR-03` Genehmigungs-Oberfläche\n- `APR-04` Delegation & Vertretungsregeln bei Abwesenheit\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `APR-01: freigabe postfach genehmigungsansicht backend`\n- Branch: `feature/apr-01-freigabe-postfach-genehmigungsansicht-backend`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "APR-02", + "title": "Vier-Augen-Freigabe (generisches Muster)", + "epic": "APR", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Regelbasierte Zweitprüfung", + "description": "Generisches Muster für Freigaben, die eine zweite, unabhängige Bestätigung erfordern – modulunabhängig konfigurierbar.", + "dependsOn": [ + "APR-01" + ], + "akzeptanz": [ + "Zweitprüfer darf nicht mit dem Ersteller identisch sein", + "Freigabe ist erst nach zwei unabhängigen Bestätigungen wirksam", + "Konfiguration ist je Prozesstyp aktivierbar" + ], + "pruefungen": [ + "Ersteller kann eigene Freigabe nicht zweitbestätigen", + "Fehlende Zweitbestätigung blockiert die Wirkung nachweislich", + "Aktivierung für neuen Prozesstyp ohne Codeänderung getestet" + ], + "status": "Fertig", + "epicName": "Genehmigungen & Freigaben", + "epicEmoji": "✅", + "wave": 4, + "unlocks": [ + "QA-03" + ], + "prompt": "# APR-02 – Vier-Augen-Freigabe (generisches Muster)\n\n**Epic:** ✅ Genehmigungen & Freigaben | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nGenerisches Muster für Freigaben, die eine zweite, unabhängige Bestätigung erfordern – modulunabhängig konfigurierbar.\n\n**Technische Grundlage:** Regelbasierte Zweitprüfung\n\n## Produkt-DNA für diesen Bereich\n> Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.\n\n**Übernehmen:**\n- Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.\n- Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit.\n\n**Bewusst vermeiden:**\n- Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.\n- Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen.\n\n**Für genau diese Kachel:** Ein generisches Muster verhindert, dass jedes Modul eine eigene Vier-Augen-Logik erfindet.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend) – Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Zweitprüfer darf nicht mit dem Ersteller identisch sein\n2. Freigabe ist erst nach zwei unabhängigen Bestätigungen wirksam\n3. Konfiguration ist je Prozesstyp aktivierbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Ersteller kann eigene Freigabe nicht zweitbestätigen\n2. Fehlende Zweitbestätigung blockiert die Wirkung nachweislich\n3. Aktivierung für neuen Prozesstyp ohne Codeänderung getestet\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-03` Prüfgate Genehmigungen & Aufgaben\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `APR-02: vier augen freigabe generisches muster`\n- Branch: `feature/apr-02-vier-augen-freigabe-generisches-muster`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "APR-03", + "title": "Genehmigungs-Oberfläche", + "epic": "APR", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "React/Next.js, TypeScript", + "description": "Persönliche Freigabeliste mit Vorschau des betroffenen Objekts, Kommentarfeld und den Aktionen Freigeben, Ablehnen, Zurückgeben.", + "dependsOn": [ + "APR-01", + "SHL-01" + ], + "akzeptanz": [ + "Offene Freigaben sind gebündelt sichtbar", + "Ablehnung erfordert eine Begründung", + "Entscheidung ist per Tastatur möglich" + ], + "pruefungen": [ + "Ansicht bei 200 offenen Aufgaben bleibt nutzbar", + "Doppelte Entscheidung wird in der Oberfläche verhindert", + "Tastaturbedienung für alle drei Aktionen geprüft" + ], + "status": "Fertig", + "epicName": "Genehmigungen & Freigaben", + "epicEmoji": "✅", + "wave": 4, + "unlocks": [], + "prompt": "# APR-03 – Genehmigungs-Oberfläche\n\n**Epic:** ✅ Genehmigungen & Freigaben | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nOberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.\n\n## Auftrag\nPersönliche Freigabeliste mit Vorschau des betroffenen Objekts, Kommentarfeld und den Aktionen Freigeben, Ablehnen, Zurückgeben.\n\n**Technische Grundlage:** React/Next.js, TypeScript\n\n## Produkt-DNA für diesen Bereich\n> Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.\n\n**Übernehmen:**\n- Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.\n- Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit.\n\n**Bewusst vermeiden:**\n- Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.\n- Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen.\n\n**Für genau diese Kachel:** Trello/Linear als Vorbild: einfach und schnell bedienbar, kein Schulungsaufwand.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend) – Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Offene Freigaben sind gebündelt sichtbar\n2. Ablehnung erfordert eine Begründung\n3. Entscheidung ist per Tastatur möglich\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Ansicht bei 200 offenen Aufgaben bleibt nutzbar\n2. Doppelte Entscheidung wird in der Oberfläche verhindert\n3. Tastaturbedienung für alle drei Aktionen geprüft\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `APR-03: genehmigungs oberflaeche`\n- Branch: `feature/apr-03-genehmigungs-oberflaeche`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "APR-04", + "title": "Delegation & Vertretungsregeln bei Abwesenheit", + "epic": "APR", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Vertretungsmodell, Zeitraumlogik", + "description": "Vertretungsregel je Nutzer und Zeitraum, sodass Genehmigungsaufgaben automatisch an eine Vertretung gehen.", + "dependsOn": [ + "APR-01" + ], + "akzeptanz": [ + "Vertretung ist zeitlich begrenzt konfigurierbar", + "Aufgabe geht während der Abwesenheit automatisch an die Vertretung", + "Rückkehr beendet die Vertretung automatisch", + "Selbst-Vertretung (Genehmiger setzt sich selbst als Vertretung ein, um APR-02 Vier-Augen-Prinzip zu umgehen) wird verhindert" + ], + "pruefungen": [ + "Aufgabe während aktiver Vertretung landet nachweislich bei der Vertretung", + "Überlappende Vertretungsregeln werden eindeutig aufgelöst", + "Ende der Vertretung wirkt ohne manuellen Eingriff", + "Missbrauchstest: Genehmiger versucht, sich selbst als Vertretung einzutragen und eigene Anfrage über die Vertretung freizugeben – wird abgelehnt" + ], + "status": "Fertig", + "epicName": "Genehmigungen & Freigaben", + "epicEmoji": "✅", + "wave": 4, + "unlocks": [], + "prompt": "# APR-04 – Delegation & Vertretungsregeln bei Abwesenheit\n\n**Epic:** ✅ Genehmigungen & Freigaben | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVertretungsregel je Nutzer und Zeitraum, sodass Genehmigungsaufgaben automatisch an eine Vertretung gehen.\n\n**Technische Grundlage:** Vertretungsmodell, Zeitraumlogik\n\n## Produkt-DNA für diesen Bereich\n> Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.\n\n**Übernehmen:**\n- Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.\n- Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit.\n\n**Bewusst vermeiden:**\n- Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.\n- Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen.\n\n**Für genau diese Kachel:** Eskalation ohne Vertretungsregelung blockiert jeden Urlaub. Beides gehört zusammen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend) – Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Vertretung ist zeitlich begrenzt konfigurierbar\n2. Aufgabe geht während der Abwesenheit automatisch an die Vertretung\n3. Rückkehr beendet die Vertretung automatisch\n4. Selbst-Vertretung (Genehmiger setzt sich selbst als Vertretung ein, um APR-02 Vier-Augen-Prinzip zu umgehen) wird verhindert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Aufgabe während aktiver Vertretung landet nachweislich bei der Vertretung\n2. Überlappende Vertretungsregeln werden eindeutig aufgelöst\n3. Ende der Vertretung wirkt ohne manuellen Eingriff\n4. Missbrauchstest: Genehmiger versucht, sich selbst als Vertretung einzutragen und eigene Anfrage über die Vertretung freizugeben – wird abgelehnt\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `APR-04: delegation vertretungsregeln bei abwesenheit`\n- Branch: `feature/apr-04-delegation-vertretungsregeln-bei-abwesenheit`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "TSK-01", + "title": "Aufgabenmodell & Zuweisung", + "epic": "TSK", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "PostgreSQL, Aufgabenmodell", + "description": "Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Aufgabe ist Person oder Gruppe zuweisbar", + "Zuweisung an Gruppe erzeugt genau eine Aufgabe", + "Aufgabe ist mit beliebigem Modul-Objekt verknüpfbar" + ], + "pruefungen": [ + "Zuweisung an Gruppe erzeugt im Test genau eine Aufgabe", + "Verknüpfung mit Testobjekt aus fiktivem Modul funktioniert", + "Tenant-Isolation der Aufgabentabellen durch Negativtest belegt" + ], + "status": "Fertig", + "epicName": "Aufgaben, Fristen & Eskalation", + "epicEmoji": "⏱️", + "wave": 2, + "unlocks": [ + "TSK-02", + "TSK-04", + "VOR-03" + ], + "prompt": "# TSK-01 – Aufgabenmodell & Zuweisung\n\n**Epic:** ⏱️ Aufgaben, Fristen & Eskalation | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.\n\n**Technische Grundlage:** PostgreSQL, Aufgabenmodell\n\n## Produkt-DNA für diesen Bereich\n> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.\n\n**Übernehmen:**\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.\n- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.\n- Fristen mit Arbeitstagslogik statt naiver Kalendertage.\n\n**Bewusst vermeiden:**\n- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.\n- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.\n\n**Für genau diese Kachel:** Das Aufgabenmodell trägt sowohl Genehmigungen als auch eigenständige Fristen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Aufgabe ist Person oder Gruppe zuweisbar\n2. Zuweisung an Gruppe erzeugt genau eine Aufgabe\n3. Aufgabe ist mit beliebigem Modul-Objekt verknüpfbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Zuweisung an Gruppe erzeugt im Test genau eine Aufgabe\n2. Verknüpfung mit Testobjekt aus fiktivem Modul funktioniert\n3. Tenant-Isolation der Aufgabentabellen durch Negativtest belegt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `TSK-02` Fristen & Kalenderlogik\n- `TSK-04` Aufgaben-Oberfläche\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `TSK-01: aufgabenmodell zuweisung`\n- Branch: `feature/tsk-01-aufgabenmodell-zuweisung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "TSK-02", + "title": "Fristen & Kalenderlogik", + "epic": "TSK", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Kalenderlogik, Zeitzonenbehandlung", + "description": "Fälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.", + "dependsOn": [ + "TSK-01" + ], + "akzeptanz": [ + "Fälligkeit berücksichtigt Arbeitstage", + "Wochenenden und Feiertage verschieben die Fälligkeit korrekt", + "Zeitzonenwechsel verschiebt Fälligkeit nicht fälschlich" + ], + "pruefungen": [ + "Fristberechnung über Wochenende und Feiertage geprüft", + "Zeitzonenwechsel-Testfall bestanden", + "Grenzfall Fälligkeit an einem Feiertag korrekt behandelt" + ], + "status": "Fertig", + "epicName": "Aufgaben, Fristen & Eskalation", + "epicEmoji": "⏱️", + "wave": 3, + "unlocks": [ + "TSK-03", + "TSK-04" + ], + "prompt": "# TSK-02 – Fristen & Kalenderlogik\n\n**Epic:** ⏱️ Aufgaben, Fristen & Eskalation | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nFälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.\n\n**Technische Grundlage:** Kalenderlogik, Zeitzonenbehandlung\n\n## Produkt-DNA für diesen Bereich\n> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.\n\n**Übernehmen:**\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.\n- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.\n- Fristen mit Arbeitstagslogik statt naiver Kalendertage.\n\n**Bewusst vermeiden:**\n- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.\n- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.\n\n**Für genau diese Kachel:** Kalendertage erzeugen in der Praxis dauerhaft falsche Fälligkeiten – Arbeitstage sind Pflicht.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `TSK-01` Aufgabenmodell & Zuweisung – Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Fälligkeit berücksichtigt Arbeitstage\n2. Wochenenden und Feiertage verschieben die Fälligkeit korrekt\n3. Zeitzonenwechsel verschiebt Fälligkeit nicht fälschlich\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Fristberechnung über Wochenende und Feiertage geprüft\n2. Zeitzonenwechsel-Testfall bestanden\n3. Grenzfall Fälligkeit an einem Feiertag korrekt behandelt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `TSK-03` Erinnerungen & Eskalationsregeln\n- `TSK-04` Aufgaben-Oberfläche\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `TSK-02: fristen kalenderlogik`\n- Branch: `feature/tsk-02-fristen-kalenderlogik`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "TSK-03", + "title": "Erinnerungen & Eskalationsregeln", + "epic": "TSK", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Postgres-Jobqueue, zeitgesteuerte Jobs", + "description": "Automatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.", + "dependsOn": [ + "TSK-02" + ], + "akzeptanz": [ + "Erinnerungszeitpunkte sind konfigurierbar", + "Eskalation erfolgt nach definierter Regel bei Fristablauf", + "Erledigte Aufgabe löst keine Eskalation mehr aus" + ], + "pruefungen": [ + "Zeitraffer-Test über simulierte Fristen bestanden", + "Erledigte Aufgabe vor Fristablauf löst nachweislich keine Eskalation aus", + "Wiederholter Joblauf bleibt idempotent" + ], + "status": "Fertig", + "epicName": "Aufgaben, Fristen & Eskalation", + "epicEmoji": "⏱️", + "wave": 4, + "unlocks": [ + "TSK-05", + "QA-03" + ], + "prompt": "# TSK-03 – Erinnerungen & Eskalationsregeln\n\n**Epic:** ⏱️ Aufgaben, Fristen & Eskalation | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAutomatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.\n\n**Technische Grundlage:** Postgres-Jobqueue, zeitgesteuerte Jobs\n\n## Produkt-DNA für diesen Bereich\n> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.\n\n**Übernehmen:**\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.\n- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.\n- Fristen mit Arbeitstagslogik statt naiver Kalendertage.\n\n**Bewusst vermeiden:**\n- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.\n- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.\n\n**Für genau diese Kachel:** Eskalation ist ein reines Regelwerk hier, der Versand selbst bleibt beim Core-Dispatcher.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `TSK-02` Fristen & Kalenderlogik – Fälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Erinnerungszeitpunkte sind konfigurierbar\n2. Eskalation erfolgt nach definierter Regel bei Fristablauf\n3. Erledigte Aufgabe löst keine Eskalation mehr aus\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Zeitraffer-Test über simulierte Fristen bestanden\n2. Erledigte Aufgabe vor Fristablauf löst nachweislich keine Eskalation aus\n3. Wiederholter Joblauf bleibt idempotent\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `TSK-05` Eskalations-Benachrichtigung (ruft Core-Dispatcher)\n- `QA-03` Prüfgate Genehmigungen & Aufgaben\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `TSK-03: erinnerungen eskalationsregeln`\n- Branch: `feature/tsk-03-erinnerungen-eskalationsregeln`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "TSK-04", + "title": "Aufgaben-Oberfläche", + "epic": "TSK", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "React/Next.js, TypeScript", + "description": "Aufgabenliste mit Fälligkeit, Priorität und Filter, angelehnt an das einfache, schnelle Bedienmodell von Trello/Linear. Zusätzlich eine Kanban-Ansicht (Spalten nach Status, z. B. Offen/In Bearbeitung/Erledigt) — Drag & Drop einer Aufgabe in eine andere Spalte aktualisiert ihren Status über TSK-01.", + "dependsOn": [ + "TSK-01", + "TSK-02", + "SHL-01" + ], + "akzeptanz": [ + "Überfällige Aufgaben sind klar gekennzeichnet", + "Liste ist nach Fälligkeit und Priorität filterbar", + "Ansicht bleibt bei 200 Aufgaben nutzbar", + "Kanban-Ansicht zeigt Spalten nach Aufgabenstatus, Drag & Drop zwischen Spalten schreibt den neuen Status über TSK-01 zurück", + "Kanban-Ansicht zeigt ausschließlich Aufgaben des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet" + ], + "pruefungen": [ + "Filterkombination gegen Testdatensatz geprüft", + "Überfällig-Kennzeichnung bei Fristüberschreitung im Test korrekt", + "Performance bei 200 Aufgaben gemessen", + "Verschieben einer Aufgabe per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über TSK-01", + "Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Aufgaben des aktuell aktiven Mandanten" + ], + "status": "Fertig", + "epicName": "Aufgaben, Fristen & Eskalation", + "epicEmoji": "⏱️", + "wave": 4, + "unlocks": [], + "prompt": "# TSK-04 – Aufgaben-Oberfläche\n\n**Epic:** ⏱️ Aufgaben, Fristen & Eskalation | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nOberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.\n\n## Auftrag\nAufgabenliste mit Fälligkeit, Priorität und Filter, angelehnt an das einfache, schnelle Bedienmodell von Trello/Linear. Zusätzlich eine Kanban-Ansicht (Spalten nach Status, z. B. Offen/In Bearbeitung/Erledigt) — Drag & Drop einer Aufgabe in eine andere Spalte aktualisiert ihren Status über TSK-01.\n\n**Technische Grundlage:** React/Next.js, TypeScript\n\n## Produkt-DNA für diesen Bereich\n> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.\n\n**Übernehmen:**\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.\n- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.\n- Fristen mit Arbeitstagslogik statt naiver Kalendertage.\n\n**Bewusst vermeiden:**\n- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.\n- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.\n\n**Für genau diese Kachel:** Trello/Linear als UI-Vorbild: schnelle Übersicht ohne Schwergewicht.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `TSK-01` Aufgabenmodell & Zuweisung – Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.\n- `TSK-02` Fristen & Kalenderlogik – Fälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Überfällige Aufgaben sind klar gekennzeichnet\n2. Liste ist nach Fälligkeit und Priorität filterbar\n3. Ansicht bleibt bei 200 Aufgaben nutzbar\n4. Kanban-Ansicht zeigt Spalten nach Aufgabenstatus, Drag & Drop zwischen Spalten schreibt den neuen Status über TSK-01 zurück\n5. Kanban-Ansicht zeigt ausschließlich Aufgaben des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Filterkombination gegen Testdatensatz geprüft\n2. Überfällig-Kennzeichnung bei Fristüberschreitung im Test korrekt\n3. Performance bei 200 Aufgaben gemessen\n4. Verschieben einer Aufgabe per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über TSK-01\n5. Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Aufgaben des aktuell aktiven Mandanten\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `TSK-04: aufgaben oberflaeche`\n- Branch: `feature/tsk-04-aufgaben-oberflaeche`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "TSK-05", + "title": "Eskalations-Benachrichtigung (ruft Core-Dispatcher)", + "epic": "TSK", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "REST-Aufruf an Core-Dispatcher", + "description": "Eskalation nach Fristablauf löst eine Benachrichtigung aus, indem der Core-Benachrichtigungs-Dispatcher aufgerufen wird – kein eigener Versandweg.", + "dependsOn": [ + "TSK-03" + ], + "akzeptanz": [ + "Eskalation ruft den Core-Dispatcher mit korrektem Ereignistyp auf", + "Fehlschlag des Dispatcher-Aufrufs bricht die Eskalation nicht ab", + "Keine Doppelbenachrichtigung bei mehrfachem Joblauf" + ], + "pruefungen": [ + "Testaufruf gegen simulierten Core-Dispatcher erfolgreich", + "Nichterreichbarkeit des Dispatchers führt zu protokolliertem Fehler statt Absturz", + "Wiederholter Joblauf erzeugt keinen doppelten Aufruf" + ], + "status": "Fertig", + "epicName": "Aufgaben, Fristen & Eskalation", + "epicEmoji": "⏱️", + "wave": 5, + "unlocks": [ + "QA-03" + ], + "prompt": "# TSK-05 – Eskalations-Benachrichtigung (ruft Core-Dispatcher)\n\n**Epic:** ⏱️ Aufgaben, Fristen & Eskalation | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nEskalation nach Fristablauf löst eine Benachrichtigung aus, indem der Core-Benachrichtigungs-Dispatcher aufgerufen wird – kein eigener Versandweg.\n\n**Technische Grundlage:** REST-Aufruf an Core-Dispatcher\n\n## Produkt-DNA für diesen Bereich\n> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.\n\n**Übernehmen:**\n- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.\n- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.\n- Fristen mit Arbeitstagslogik statt naiver Kalendertage.\n\n**Bewusst vermeiden:**\n- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.\n- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.\n\n**Für genau diese Kachel:** Kein eigenes Benachrichtigungssystem – der Core-Dispatcher (CFG-02) übernimmt Versand und Kanäle.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `TSK-03` Erinnerungen & Eskalationsregeln – Automatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.\n- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `CFG-02` Benachrichtigungs-Dispatcher (Core-Service für Module).\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Eskalation ruft den Core-Dispatcher mit korrektem Ereignistyp auf\n2. Fehlschlag des Dispatcher-Aufrufs bricht die Eskalation nicht ab\n3. Keine Doppelbenachrichtigung bei mehrfachem Joblauf\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testaufruf gegen simulierten Core-Dispatcher erfolgreich\n2. Nichterreichbarkeit des Dispatchers führt zu protokolliertem Fehler statt Absturz\n3. Wiederholter Joblauf erzeugt keinen doppelten Aufruf\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `TSK-05: eskalations benachrichtigung ruft core dispatcher`\n- Branch: `feature/tsk-05-eskalations-benachrichtigung-ruft-core-dispatcher`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "RTE-01", + "title": "Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig)", + "epic": "RTE", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Regelwerk-Datenmodell, PostgreSQL", + "description": "Generisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.", + "dependsOn": [ + "ENG-02" + ], + "akzeptanz": [ + "Regeln sind priorisierbar", + "Bedingungen sind modulunabhängig formulierbar", + "Regel ist versionierbar und rückrollbar" + ], + "pruefungen": [ + "Regelpriorität im Test korrekt angewendet", + "Testregel aus fiktivem DMS- und Mail-Adapter beide korrekt abgebildet", + "Rollback auf Vorgängerversion einer Regel funktioniert" + ], + "status": "Fertig", + "epicName": "Regelbasiertes Routing", + "epicEmoji": "🔁", + "wave": 3, + "unlocks": [ + "RTE-02", + "RTE-03" + ], + "prompt": "# RTE-01 – Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig)\n\n**Epic:** 🔁 Regelbasiertes Routing | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nGenerisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.\n\n**Technische Grundlage:** Regelwerk-Datenmodell, PostgreSQL\n\n## Produkt-DNA für diesen Bereich\n> Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.\n\n**Übernehmen:**\n- paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.\n- Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.\n- Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert.\n\n**Bewusst vermeiden:**\n- Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.\n- Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell.\n\n**Für genau diese Kachel:** Ein modulunabhängiges Modell verhindert doppelte Routing-Logik in DMS und Mail.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Regeln sind priorisierbar\n2. Bedingungen sind modulunabhängig formulierbar\n3. Regel ist versionierbar und rückrollbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Regelpriorität im Test korrekt angewendet\n2. Testregel aus fiktivem DMS- und Mail-Adapter beide korrekt abgebildet\n3. Rollback auf Vorgängerversion einer Regel funktioniert\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `RTE-02` Routing-Engine-Ausführung\n- `RTE-03` Routing-Regel-Editor (Oberfläche)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `RTE-01: routing regel modell bedingungen aktionen modulunabhaengig`\n- Branch: `feature/rte-01-routing-regel-modell-bedingungen-aktionen-modulunabhaengig`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "RTE-02", + "title": "Routing-Engine-Ausführung", + "epic": "RTE", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Regel-Ausführungs-Engine", + "description": "Ausführung des Regelwerks gegen eingehende Objekte: erste zutreffende Regel nach Priorität gewinnt, sonst Klärungskorb.", + "dependsOn": [ + "RTE-01" + ], + "akzeptanz": [ + "Nicht zuordenbare Objekte landen in einem Klärungskorb", + "Jede Weiterleitung ist nachvollziehbar protokolliert", + "Regeländerung wirkt ohne Neustart" + ], + "pruefungen": [ + "Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft", + "Kein Testobjekt geht bei fehlender Regel verloren", + "Regeländerung zur Laufzeit ohne Neustart wirksam getestet" + ], + "status": "Fertig", + "epicName": "Regelbasiertes Routing", + "epicEmoji": "🔁", + "wave": 4, + "unlocks": [ + "RTE-04" + ], + "prompt": "# RTE-02 – Routing-Engine-Ausführung\n\n**Epic:** 🔁 Regelbasiertes Routing | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAusführung des Regelwerks gegen eingehende Objekte: erste zutreffende Regel nach Priorität gewinnt, sonst Klärungskorb.\n\n**Technische Grundlage:** Regel-Ausführungs-Engine\n\n## Produkt-DNA für diesen Bereich\n> Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.\n\n**Übernehmen:**\n- paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.\n- Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.\n- Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert.\n\n**Bewusst vermeiden:**\n- Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.\n- Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell.\n\n**Für genau diese Kachel:** Der Klärungskorb verhindert, dass ein Dokument beim Routing verloren geht.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `RTE-01` Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig) – Generisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Nicht zuordenbare Objekte landen in einem Klärungskorb\n2. Jede Weiterleitung ist nachvollziehbar protokolliert\n3. Regeländerung wirkt ohne Neustart\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft\n2. Kein Testobjekt geht bei fehlender Regel verloren\n3. Regeländerung zur Laufzeit ohne Neustart wirksam getestet\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `RTE-04` Testlauf/Simulation von Routing-Regeln\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `RTE-02: routing engine ausfuehrung`\n- Branch: `feature/rte-02-routing-engine-ausfuehrung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "RTE-03", + "title": "Routing-Regel-Editor (Oberfläche)", + "epic": "RTE", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "React/Next.js, TypeScript", + "description": "Oberfläche zum Anlegen, Priorisieren und Testen von Routing-Regeln.", + "dependsOn": [ + "RTE-01", + "SHL-01" + ], + "akzeptanz": [ + "Regeln sind in der Oberfläche priorisierbar", + "Regeländerung ist ohne Codeänderung möglich", + "Regel kann vor Aktivierung getestet werden" + ], + "pruefungen": [ + "Priorisierung per Drag & Drop im Test funktionsfähig", + "Testlauf einer Regel vor Aktivierung möglich", + "Ungültige Bedingungseingabe wird abgewiesen" + ], + "status": "Fertig", + "epicName": "Regelbasiertes Routing", + "epicEmoji": "🔁", + "wave": 4, + "unlocks": [], + "prompt": "# RTE-03 – Routing-Regel-Editor (Oberfläche)\n\n**Epic:** 🔁 Regelbasiertes Routing | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nOberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.\n\n## Auftrag\nOberfläche zum Anlegen, Priorisieren und Testen von Routing-Regeln.\n\n**Technische Grundlage:** React/Next.js, TypeScript\n\n## Produkt-DNA für diesen Bereich\n> Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.\n\n**Übernehmen:**\n- paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.\n- Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.\n- Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert.\n\n**Bewusst vermeiden:**\n- Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.\n- Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell.\n\n**Für genau diese Kachel:** Regeln müssen von Fachanwendern pflegbar sein, nicht nur von Entwicklerinnen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `RTE-01` Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig) – Generisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Regeln sind in der Oberfläche priorisierbar\n2. Regeländerung ist ohne Codeänderung möglich\n3. Regel kann vor Aktivierung getestet werden\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Priorisierung per Drag & Drop im Test funktionsfähig\n2. Testlauf einer Regel vor Aktivierung möglich\n3. Ungültige Bedingungseingabe wird abgewiesen\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `RTE-03: routing regel editor oberflaeche`\n- Branch: `feature/rte-03-routing-regel-editor-oberflaeche`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "RTE-04", + "title": "Testlauf/Simulation von Routing-Regeln", + "epic": "RTE", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Simulationsmodus, Testkorpus", + "description": "Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.", + "dependsOn": [ + "RTE-02" + ], + "akzeptanz": [ + "Simulation verändert keine echten Daten", + "Simulationsergebnis zeigt erwartete gegen tatsächliche Zuordnung", + "Simulation ist gegen beliebigen Testkorpus ausführbar" + ], + "pruefungen": [ + "Simulationslauf hinterlässt keine Spuren in Produktivdaten", + "Abweichung zwischen erwarteter und tatsächlicher Zuordnung wird korrekt gemeldet", + "Simulation mit leerem Testkorpus bricht nicht ab" + ], + "status": "Fertig", + "epicName": "Regelbasiertes Routing", + "epicEmoji": "🔁", + "wave": 5, + "unlocks": [ + "QA-04", + "RTE-05", + "QA-07" + ], + "prompt": "# RTE-04 – Testlauf/Simulation von Routing-Regeln\n\n**Epic:** 🔁 Regelbasiertes Routing | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSimulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.\n\n**Technische Grundlage:** Simulationsmodus, Testkorpus\n\n## Produkt-DNA für diesen Bereich\n> Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.\n\n**Übernehmen:**\n- paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.\n- Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.\n- Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert.\n\n**Bewusst vermeiden:**\n- Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.\n- Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell.\n\n**Für genau diese Kachel:** Simulation vor scharfer Anwendung verhindert Fehlrouting im Produktivbetrieb.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `RTE-02` Routing-Engine-Ausführung – Ausführung des Regelwerks gegen eingehende Objekte: erste zutreffende Regel nach Priorität gewinnt, sonst Klärungskorb.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Simulation verändert keine echten Daten\n2. Simulationsergebnis zeigt erwartete gegen tatsächliche Zuordnung\n3. Simulation ist gegen beliebigen Testkorpus ausführbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Simulationslauf hinterlässt keine Spuren in Produktivdaten\n2. Abweichung zwischen erwarteter und tatsächlicher Zuordnung wird korrekt gemeldet\n3. Simulation mit leerem Testkorpus bricht nicht ab\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-04` Prüfgate Routing\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `RTE-04: testlauf simulation von routing regeln`\n- Branch: `feature/rte-04-testlauf-simulation-von-routing-regeln`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-01", + "title": "Teststrategie Workflow", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Teststrategie, Testdatenbestand", + "description": "Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen Testdatenbestand für Engine, Genehmigungen, Aufgaben und Routing aufbauen.", + "dependsOn": [], + "akzeptanz": [ + "Teststrategie deckt Engine, Genehmigungen, Aufgaben und Routing ab", + "Testdatenbestand ist realistisch und anonymisiert", + "Verantwortlichkeit je Testebene ist dokumentiert", + "Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01" + ], + "pruefungen": [ + "Teststrategie-Dokument gegen alle vier Bereiche geprüft", + "Testdatenbestand enthält keine echten Personendaten", + "Zweite Person kann Teststrategie ohne Rückfragen anwenden" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 1, + "unlocks": [], + "prompt": "# QA-01 – Teststrategie Workflow\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 1\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nFestlegen, was auf welcher Ebene geprüft wird, und einen realistischen Testdatenbestand für Engine, Genehmigungen, Aufgaben und Routing aufbauen.\n\n**Technische Grundlage:** Teststrategie, Testdatenbestand\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.\n- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.\n\n**Für genau diese Kachel:** Die Teststrategie legt fest, was auf welcher Ebene geprüft wird, bevor die erste Prüfung läuft.\n\n## Ausgangslage\nDiese Kachel hat keine Vorbedingungen und ist sofort startbar.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Teststrategie deckt Engine, Genehmigungen, Aufgaben und Routing ab\n2. Testdatenbestand ist realistisch und anonymisiert\n3. Verantwortlichkeit je Testebene ist dokumentiert\n\n4. Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Teststrategie-Dokument gegen alle vier Bereiche geprüft\n2. Testdatenbestand enthält keine echten Personendaten\n3. Zweite Person kann Teststrategie ohne Rückfragen anwenden\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-01: teststrategie workflow`\n- Branch: `feature/qa-01-teststrategie-workflow`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-02", + "title": "Prüfgate Engine & Adapter", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Integrationstests, Zeitraffer", + "description": "Prüfgate für Zustandsautomat, Modul-Adapter-Schnittstelle und Fehlerbehandlung.", + "dependsOn": [ + "ENG-05", + "ENG-02", + "ENG-03", + "ENG-04" + ], + "akzeptanz": [ + "Alle Zustandsübergänge sind mindestens einmal durchlaufen", + "Adapter-Registrierung ist gegen zwei fiktive Module geprüft", + "Fehlerbehandlung und Retry sind nachgewiesen" + ], + "pruefungen": [ + "Unzulässiger Übergang wird in jedem Testlauf abgewiesen", + "Zwei fiktive Modul-Adapter gleichzeitig registriert und geprüft", + "Simulierter Fehlerfall löst nachweislich korrekten Retry aus" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 3, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-02 – Prüfgate Engine & Adapter\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPrüfgate für Zustandsautomat, Modul-Adapter-Schnittstelle und Fehlerbehandlung.\n\n**Technische Grundlage:** Integrationstests, Zeitraffer\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.\n- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.\n\n**Für genau diese Kachel:** Engine und Adapter sind das Fundament – ein Fehler hier wirkt in jedem späteren Prozess.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-05` Fehlerbehandlung & Retry bei Workflow-Schritten – Wiederholungslogik mit Backoff für fehlgeschlagene Workflow-Schritte, Dead-Letter-Pfad für dauerhaft fehlschlagende Instanzen.\n- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.\n- `ENG-03` Prozessdefinitions-Format (deklarativ, versionierbar) – Lesbares Konfigurationsformat für Prozessdefinitionen: Zustände, Übergänge, Bedingungen, Zuständigkeiten. Jede Definition ist versioniert.\n- `ENG-04` Workflow-Instanz-Historie & Nachvollziehbarkeit – Vollständiges, unveränderliches Protokoll jedes Instanzschritts: Person, Zeitpunkt, Zustand, Begründung.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle Zustandsübergänge sind mindestens einmal durchlaufen\n2. Adapter-Registrierung ist gegen zwei fiktive Module geprüft\n3. Fehlerbehandlung und Retry sind nachgewiesen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Unzulässiger Übergang wird in jedem Testlauf abgewiesen\n2. Zwei fiktive Modul-Adapter gleichzeitig registriert und geprüft\n3. Simulierter Fehlerfall löst nachweislich korrekten Retry aus\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-05` Abnahme- & Compliance-Prüfung Workflow\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-02: pruefgate engine adapter`\n- Branch: `feature/qa-02-pruefgate-engine-adapter`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-03", + "title": "Prüfgate Genehmigungen & Aufgaben", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Prozesstests, Zeitraffer", + "description": "Prüfgate für Vier-Augen-Freigabe, Fristen und Eskalationsregeln.", + "dependsOn": [ + "APR-02", + "TSK-03", + "APR-04", + "TSK-05" + ], + "akzeptanz": [ + "Vier-Augen-Freigabe ist gegen Missbrauchsversuch geprüft", + "Fristen und Eskalationen lösen korrekt aus", + "Alle Genehmigungspfade sind mindestens einmal durchlaufen" + ], + "pruefungen": [ + "Ersteller kann eigene Freigabe im Test nicht zweitbestätigen", + "Zeitraffer-Test über simulierte Fristen bestanden", + "Eskalationspfad bis zum Dispatcher-Aufruf nachvollzogen" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 5, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-03 – Prüfgate Genehmigungen & Aufgaben\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPrüfgate für Vier-Augen-Freigabe, Fristen und Eskalationsregeln.\n\n**Technische Grundlage:** Prozesstests, Zeitraffer\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.\n- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.\n\n**Für genau diese Kachel:** Genehmigungen und Aufgaben sind die sichtbarsten Nutzerpfade – hier zählt Sorgfalt am meisten.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `APR-02` Vier-Augen-Freigabe (generisches Muster) – Generisches Muster für Freigaben, die eine zweite, unabhängige Bestätigung erfordern – modulunabhängig konfigurierbar.\n- `TSK-03` Erinnerungen & Eskalationsregeln – Automatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.\n- `APR-04` Delegation & Vertretungsregeln bei Abwesenheit – Vertretungsregel je Nutzer und Zeitraum, sodass Genehmigungsaufgaben automatisch an eine Vertretung gehen.\n- `TSK-05` Eskalations-Benachrichtigung (ruft Core-Dispatcher) – Eskalation nach Fristablauf löst eine Benachrichtigung aus, indem der Core-Benachrichtigungs-Dispatcher aufgerufen wird – kein eigener Versandweg.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Vier-Augen-Freigabe ist gegen Missbrauchsversuch geprüft\n2. Fristen und Eskalationen lösen korrekt aus\n3. Alle Genehmigungspfade sind mindestens einmal durchlaufen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Ersteller kann eigene Freigabe im Test nicht zweitbestätigen\n2. Zeitraffer-Test über simulierte Fristen bestanden\n3. Eskalationspfad bis zum Dispatcher-Aufruf nachvollzogen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-05` Abnahme- & Compliance-Prüfung Workflow\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-03: pruefgate genehmigungen aufgaben`\n- Branch: `feature/qa-03-pruefgate-genehmigungen-aufgaben`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-04", + "title": "Prüfgate Routing", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Regeltests, Testkorpus", + "description": "Prüfgate für Routing-Regel-Modell, Ausführung und Simulation.", + "dependsOn": [ + "RTE-04", + "RTE-05" + ], + "akzeptanz": [ + "Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft", + "Klärungskorb fängt jedes nicht zuordenbare Objekt auf", + "Simulation weicht nicht von echter Ausführung ab" + ], + "pruefungen": [ + "Testkorpus mit bekannten Erwartungswerten vollständig durchlaufen", + "Kein Testobjekt im Klärungskorb verloren", + "Simulationsergebnis stimmt mit echter Ausführung überein" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 6, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-04 – Prüfgate Routing\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPrüfgate für Routing-Regel-Modell, Ausführung und Simulation.\n\n**Technische Grundlage:** Regeltests, Testkorpus\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.\n- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.\n\n**Für genau diese Kachel:** Fehlrouting ist teuer und schwer zu bemerken – deshalb ein eigenes Gate.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `RTE-04` Testlauf/Simulation von Routing-Regeln – Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.\n- `RTE-05` KI-gestützte Routing-Vorschläge (Kopplung AI WFS-02) – Vor einer regelbasierten Routing-Entscheidung optional einen KI-Vorschlag von NEXARCH AI (WFS-02) abrufen und dem Bearbeiter als Empfehlung anzeigen – die regelbasierte Engine bleibt die maßgebliche Entscheidungsinstanz, KI liefert nur einen Vorschlag.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft\n2. Klärungskorb fängt jedes nicht zuordenbare Objekt auf\n3. Simulation weicht nicht von echter Ausführung ab\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testkorpus mit bekannten Erwartungswerten vollständig durchlaufen\n2. Kein Testobjekt im Klärungskorb verloren\n3. Simulationsergebnis stimmt mit echter Ausführung überein\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-05` Abnahme- & Compliance-Prüfung Workflow\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-04: pruefgate routing`\n- Branch: `feature/qa-04-pruefgate-routing`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-05", + "title": "Abnahme- & Compliance-Prüfung Workflow", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Abnahmeprotokoll", + "description": "Abschließende Abnahmeprüfung über Engine, Genehmigungen, Aufgaben und Routing hinweg, mit abgelegtem Protokoll.", + "dependsOn": [ + "QA-02", + "QA-03", + "QA-04", + "QA-06", + "QA-07", + "QA-08" + ], + "akzeptanz": [ + "Alle Einzelprüfgates sind bestanden und referenziert", + "Abnahmeprotokoll ist abgelegt und nachlesbar", + "Offene Punkte sind explizit benannt, nicht stillschweigend übergangen" + ], + "pruefungen": [ + "Abnahmeprotokoll gegen alle drei Prüfgates abgeglichen", + "Protokoll enthält Zielwert, Messwert und Bewertung je Kriterium", + "Zweite Person kann Abnahme anhand des Protokolls nachvollziehen" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 7, + "unlocks": [], + "prompt": "# QA-05 – Abnahme- & Compliance-Prüfung Workflow\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 7\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAbschließende Abnahmeprüfung über Engine, Genehmigungen, Aufgaben und Routing hinweg, mit abgelegtem Protokoll.\n\n**Technische Grundlage:** Abnahmeprotokoll\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.\n- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.\n\n**Für genau diese Kachel:** Die Abnahme bündelt alle Einzelprüfungen zu einer belastbaren Freigabeentscheidung.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `QA-02` Prüfgate Engine & Adapter – Prüfgate für Zustandsautomat, Modul-Adapter-Schnittstelle und Fehlerbehandlung.\n- `QA-03` Prüfgate Genehmigungen & Aufgaben – Prüfgate für Vier-Augen-Freigabe, Fristen und Eskalationsregeln.\n- `QA-04` Prüfgate Routing – Prüfgate für Routing-Regel-Modell, Ausführung und Simulation.\n- `QA-06` Schnittstellen-Vertragstests – Vertragstests für die beiden von DMS/Mail konsumierten Schnittstellen – Push-Registrierung (ENG-02 Modul-Adapter) und Pull-Rückkanal (VOR-04 Rückkanal-API für Akte/Vermerke/Wiedervorlage). Beide Richtungen müssen gegen Breaking Changes abgesichert sein, nicht nur eine.\n- `QA-07` Last- & Leistungstest – Lasttest für Workflow unter realistischer Last aus DMS und Mail gleichzeitig – insbesondere Modul-Adapter-Ereignispfad (ENG-02), Genehmigungs-Engine (APR) und Routing (RTE) unter Last.\n- `QA-08` Barrierefreiheits-Audit – Unabhängige Prüfung aller Workflow-Oberflächen (Genehmigungs-Oberfläche, Aufgaben-Oberfläche, Routing-Regel-Editor, Akten-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle Einzelprüfgates sind bestanden und referenziert\n2. Abnahmeprotokoll ist abgelegt und nachlesbar\n3. Offene Punkte sind explizit benannt, nicht stillschweigend übergangen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Abnahmeprotokoll gegen alle drei Prüfgates abgeglichen\n2. Protokoll enthält Zielwert, Messwert und Bewertung je Kriterium\n3. Zweite Person kann Abnahme anhand des Protokolls nachvollziehen\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-05: abnahme compliance pruefung workflow`\n- Branch: `feature/qa-05-abnahme-compliance-pruefung-workflow`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "VOR-01", + "title": "Akte/Vorgang-Objektmodell", + "epic": "VOR", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "PostgreSQL, Modul-Adapter (ENG-02)", + "description": "Vorgang/Akte als eigenständiger Objekttyp – Status (offen/in Bearbeitung/geschlossen), Aktenzeichen, Verantwortlicher, Liste referenzierter Fremdobjekte (Typ + ID + Herkunfts-Board, z. B. „DMS-Dokument #123“ oder „Mail-Nachricht #456“) über den bestehenden Modul-Adapter.", + "dependsOn": [ + "ENG-02" + ], + "akzeptanz": [ + "Akte kann Objekte aus mehreren Modulen gleichzeitig referenzieren, ohne deren Rohdaten zu duplizieren", + "Statuswechsel ist nachvollziehbar protokolliert", + "Aktenzeichen ist pro Tenant eindeutig und konfigurierbar (Format)" + ], + "pruefungen": [ + "Akte mit Referenzen auf ein fiktives DMS-Objekt und ein fiktives Mail-Objekt gleichzeitig angelegt und geprüft", + "Statuswechsel im Test erzeugt Protokolleintrag mit Person und Zeitpunkt", + "Zwei Akten desselben Tenants mit identischem Aktenzeichen werden im Test abgewiesen" + ], + "status": "Fertig", + "epicName": "Akte & Vorgang", + "epicEmoji": "📁", + "wave": 3, + "unlocks": [ + "VOR-02", + "VOR-03", + "VOR-04", + "VOR-05" + ], + "prompt": "# VOR-01 – Akte/Vorgang-Objektmodell\n\n**Epic:** 📁 Akte & Vorgang | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVorgang/Akte als eigenständiger Objekttyp – Status (offen/in Bearbeitung/geschlossen), Aktenzeichen, Verantwortlicher, Liste referenzierter Fremdobjekte (Typ + ID + Herkunfts-Board, z. B. „DMS-Dokument #123“ oder „Mail-Nachricht #456“) über den bestehenden Modul-Adapter.\n\n**Technische Grundlage:** PostgreSQL, Modul-Adapter (ENG-02)\n\n## Produkt-DNA für diesen Bereich\n> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.\n\n**Übernehmen:**\n- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.\n- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.\n- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.\n\n**Bewusst vermeiden:**\n- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).\n- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).\n\n**Für genau diese Kachel:** Das Objektmodell ist die Grundvoraussetzung für Vermerke, Wiedervorlage, Rückkanal-API und Akten-Übersicht.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Akte kann Objekte aus mehreren Modulen gleichzeitig referenzieren, ohne deren Rohdaten zu duplizieren\n2. Statuswechsel ist nachvollziehbar protokolliert\n3. Aktenzeichen ist pro Tenant eindeutig und konfigurierbar (Format)\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Akte mit Referenzen auf ein fiktives DMS-Objekt und ein fiktives Mail-Objekt gleichzeitig angelegt und geprüft\n2. Statuswechsel im Test erzeugt Protokolleintrag mit Person und Zeitpunkt\n3. Zwei Akten desselben Tenants mit identischem Aktenzeichen werden im Test abgewiesen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `VOR-02` Vermerke/Notizen an Akte/Vorgang\n- `VOR-03` Wiedervorlage (Akte/Objekt-Terminverknüpfung)\n- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte\n- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `VOR-01: akte vorgang objektmodell`\n- Branch: `feature/vor-01-akte-vorgang-objektmodell`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "VOR-02", + "title": "Vermerke/Notizen an Akte/Vorgang", + "epic": "VOR", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "PostgreSQL, unveränderliche Einträge", + "description": "Freitext-Vermerke an einer Akte, jeweils mit Autor und Zeitstempel, unveränderlich nach dem Speichern (Ergänzung statt Bearbeitung, wie ein Aktenvermerk in der Realität).", + "dependsOn": [ + "VOR-01" + ], + "akzeptanz": [ + "Vermerk ist nach dem Speichern nicht mehr veränderbar, nur neue Vermerke ergänzbar", + "Autor und Zeitstempel sind Pflichtfelder", + "Vermerke sind chronologisch sortiert abrufbar" + ], + "pruefungen": [ + "Versuch, einen gespeicherten Vermerk zu ändern, wird im Test abgewiesen", + "Vermerk ohne Autor oder Zeitstempel wird im Test abgewiesen", + "Abruf mehrerer Vermerke liefert im Test chronologische Reihenfolge" + ], + "status": "Fertig", + "epicName": "Akte & Vorgang", + "epicEmoji": "📁", + "wave": 4, + "unlocks": [ + "VOR-04", + "VOR-05" + ], + "prompt": "# VOR-02 – Vermerke/Notizen an Akte/Vorgang\n\n**Epic:** 📁 Akte & Vorgang | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nFreitext-Vermerke an einer Akte, jeweils mit Autor und Zeitstempel, unveränderlich nach dem Speichern (Ergänzung statt Bearbeitung, wie ein Aktenvermerk in der Realität).\n\n**Technische Grundlage:** PostgreSQL, unveränderliche Einträge\n\n## Produkt-DNA für diesen Bereich\n> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.\n\n**Übernehmen:**\n- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.\n- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.\n- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.\n\n**Bewusst vermeiden:**\n- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).\n- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).\n\n**Für genau diese Kachel:** Vermerke sind der klassische Aktenvermerk – unveränderlich, damit die Akte als Nachweis taugt.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `VOR-01` Akte/Vorgang-Objektmodell – Vorgang/Akte als eigenständiger Objekttyp mit Status, Aktenzeichen, Verantwortlichem und referenzierten Fremdobjekten.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Vermerk ist nach dem Speichern nicht mehr veränderbar, nur neue Vermerke ergänzbar\n2. Autor und Zeitstempel sind Pflichtfelder\n3. Vermerke sind chronologisch sortiert abrufbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Versuch, einen gespeicherten Vermerk zu ändern, wird im Test abgewiesen\n2. Vermerk ohne Autor oder Zeitstempel wird im Test abgewiesen\n3. Abruf mehrerer Vermerke liefert im Test chronologische Reihenfolge\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `VOR-03` Wiedervorlage (Akte/Objekt-Terminverknüpfung)\n- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte\n- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `VOR-02: vermerke notizen an akte vorgang`\n- Branch: `feature/vor-02-vermerke-notizen-an-akte-vorgang`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "VOR-03", + "title": "Wiedervorlage (Akte/Objekt-Terminverknüpfung)", + "epic": "VOR", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "TSK-Engine, PostgreSQL", + "description": "Wiedervorlage-Termin an eine Akte oder ein einzelnes referenziertes Objekt (auch ohne vollständige Akte) hängen, nutzt die bestehende TSK-Engine (Aufgabenmodell/Fristen/Erinnerungen) für Fälligkeit und Benachrichtigung.", + "dependsOn": [ + "VOR-01", + "TSK-01" + ], + "akzeptanz": [ + "Wiedervorlage kann sowohl an eine ganze Akte als auch an ein einzelnes Objekt gehängt werden", + "Fälliger Termin erzeugt eine Aufgabe über TSK-01/TSK-02", + "Erledigte Wiedervorlage ist von offener unterscheidbar, keine Löschung der Historie" + ], + "pruefungen": [ + "Wiedervorlage an Akte und Wiedervorlage an Einzelobjekt im Test jeweils erfolgreich angelegt", + "Fälliger Termin erzeugt im Test genau eine Aufgabe über die TSK-Engine", + "Als erledigt markierte Wiedervorlage bleibt im Test in der Historie sichtbar und unterscheidbar von offenen" + ], + "status": "Fertig", + "epicName": "Akte & Vorgang", + "epicEmoji": "📁", + "wave": 4, + "unlocks": [ + "VOR-04", + "VOR-05" + ], + "prompt": "# VOR-03 – Wiedervorlage (Akte/Objekt-Terminverknüpfung)\n\n**Epic:** 📁 Akte & Vorgang | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nWiedervorlage-Termin an eine Akte oder ein einzelnes referenziertes Objekt (auch ohne vollständige Akte) hängen, nutzt die bestehende TSK-Engine (Aufgabenmodell/Fristen/Erinnerungen) für Fälligkeit und Benachrichtigung.\n\n**Technische Grundlage:** TSK-Engine, PostgreSQL\n\n## Produkt-DNA für diesen Bereich\n> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.\n\n**Übernehmen:**\n- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.\n- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.\n- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.\n\n**Bewusst vermeiden:**\n- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).\n- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).\n\n**Für genau diese Kachel:** Die Wiedervorlage bildet die Papierakten-Tradition digital nach, mit TSK als Fristen- und Erinnerungsmotor.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `VOR-01` Akte/Vorgang-Objektmodell – Vorgang/Akte als eigenständiger Objekttyp mit Status, Aktenzeichen, Verantwortlichem und referenzierten Fremdobjekten.\n- `TSK-01` Aufgabenmodell & Zuweisung – Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Wiedervorlage kann sowohl an eine ganze Akte als auch an ein einzelnes Objekt gehängt werden\n2. Fälliger Termin erzeugt eine Aufgabe über TSK-01/TSK-02\n3. Erledigte Wiedervorlage ist von offener unterscheidbar, keine Löschung der Historie\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Wiedervorlage an Akte und Wiedervorlage an Einzelobjekt im Test jeweils erfolgreich angelegt\n2. Fälliger Termin erzeugt im Test genau eine Aufgabe über die TSK-Engine\n3. Als erledigt markierte Wiedervorlage bleibt im Test in der Historie sichtbar und unterscheidbar von offenen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte\n- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche)\n- `TSK-02` Fristen & Kalenderlogik\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `VOR-03: wiedervorlage akte objekt terminverknuepfung`\n- Branch: `feature/vor-03-wiedervorlage-akte-objekt-terminverknuepfung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "VOR-04", + "title": "Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte", + "epic": "VOR", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "REST-Schnittstelle, read-only", + "description": "Read-only API, über die ein Modul (DMS/Mail) für eine gegebene Objekt-Referenz (Typ+ID) abfragt: gehört das zu einer Akte, welche Vermerke/offenen Wiedervorlagen gibt es.", + "dependsOn": [ + "VOR-01", + "VOR-02", + "VOR-03" + ], + "akzeptanz": [ + "Abfrage nach Objekt-Referenz liefert Akte, Vermerke und offene Wiedervorlagen in einem Aufruf", + "Antwortzeit ist für den Einsatz in einer Dokument-/Mail-Detailansicht ausreichend kurz (keine spürbare Verzögerung beim Laden)", + "API respektiert Berechtigungen – nur Vermerke/Akten sichtbar, für die der anfragende Nutzer berechtigt ist", + "Abfrage ist zwingend tenant-gescoped – Tenant-Filter sitzt in der Query-/Repository-Schicht, nicht als nachgelagerter Filter (siehe SICHERHEITSKONZEPT.md); Objekte anderer Mandanten sind selbst bei geratener/falscher Objekt-Referenz nie sichtbar" + ], + "pruefungen": [ + "Abfrage einer bekannten Objekt-Referenz liefert im Test Akte, Vermerke und offene Wiedervorlagen in einem Aufruf", + "Antwortzeit im Test unter der für Detailansichten festgelegten Schwelle gemessen", + "Abfrage mit nicht berechtigtem Nutzer liefert im Test keine fremden Akte-/Vermerkdaten", + "Abfrage mit Objekt-Referenz eines fremden Mandanten liefert im Test keine Daten, auch wenn die Referenz-ID gültig/erratbar ist" + ], + "status": "Fertig", + "epicName": "Akte & Vorgang", + "epicEmoji": "📁", + "wave": 5, + "unlocks": [ + "QA-06", + "VOR-06" + ], + "prompt": "# VOR-04 – Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte\n\n**Epic:** 📁 Akte & Vorgang | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nRead-only API, über die ein Modul (DMS/Mail) für eine gegebene Objekt-Referenz (Typ+ID) abfragt: gehört das zu einer Akte, welche Vermerke/offenen Wiedervorlagen gibt es.\n\n**Technische Grundlage:** REST-Schnittstelle, read-only\n\n## Produkt-DNA für diesen Bereich\n> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.\n\n**Übernehmen:**\n- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.\n- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.\n- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.\n\n**Bewusst vermeiden:**\n- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).\n- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).\n\n**Für genau diese Kachel:** Ohne diesen Rückkanal wären Workflow-Daten für die Anwender unsichtbar, da Workflow selbst keine Rohdaten (Dokumentinhalte/Mailinhalte) hält, nur Verweise.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `VOR-01` Akte/Vorgang-Objektmodell – Vorgang/Akte als eigenständiger Objekttyp mit Status, Aktenzeichen, Verantwortlichem und referenzierten Fremdobjekten.\n- `VOR-02` Vermerke/Notizen an Akte/Vorgang – Freitext-Vermerke mit Autor und Zeitstempel, unveränderlich nach dem Speichern.\n- `VOR-03` Wiedervorlage (Akte/Objekt-Terminverknüpfung) – Wiedervorlage-Termin an Akte oder Einzelobjekt, nutzt die TSK-Engine für Fälligkeit und Benachrichtigung.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Abfrage nach Objekt-Referenz liefert Akte, Vermerke und offene Wiedervorlagen in einem Aufruf\n2. Antwortzeit ist für den Einsatz in einer Dokument-/Mail-Detailansicht ausreichend kurz (keine spürbare Verzögerung beim Laden)\n3. API respektiert Berechtigungen – nur Vermerke/Akten sichtbar, für die der anfragende Nutzer berechtigt ist\n4. Abfrage ist zwingend tenant-gescoped – Tenant-Filter sitzt in der Query-/Repository-Schicht, nicht als nachgelagerter Filter (siehe SICHERHEITSKONZEPT.md); Objekte anderer Mandanten sind selbst bei geratener/falscher Objekt-Referenz nie sichtbar\n\n## Bekannte Fehler vermeiden\nEin rein einseitiger Modul-Adapter (nur Registrierung/Push) macht Workflow-Daten für Anwender im Ursprungsmodul unsichtbar – DMS/Mail brauchen einen Lesezugriff, keinen Umweg über eine separate Workflow-Oberfläche, sonst wird die Information faktisch nicht genutzt.\nTenant-Filter als nachgelagerter Filter statt in der Query selbst war ein realer Fehler in archivmail (siehe known-issues-archivmail.md #7) – bei einer modulübergreifenden Rückkanal-API mit Objekt-Referenzen aus fremden Systemen ist das Risiko einer falsch zusammengesetzten Referenz besonders hoch, deshalb Tenant-Scoping hier ausdrücklich als eigenes Akzeptanzkriterium, nicht nur implizit über \"Berechtigungen\" mitgemeint.\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Abfrage einer bekannten Objekt-Referenz liefert im Test Akte, Vermerke und offene Wiedervorlagen in einem Aufruf\n2. Antwortzeit im Test unter der für Detailansichten festgelegten Schwelle gemessen\n3. Abfrage mit nicht berechtigtem Nutzer liefert im Test keine fremden Akte-/Vermerkdaten\n4. Abfrage mit Objekt-Referenz eines fremden Mandanten liefert im Test keine Daten, auch wenn die Referenz-ID gültig/erratbar ist\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche)\n- Anzeige-Oberfläche in DMS – siehe externes DMS-Board `DOC-13`\n- Anzeige-Oberfläche in Mail – siehe externes Mail-Board `UX-09`\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `VOR-04: rueckkanal api workflow status vermerke fuer verlinkte objekte`\n- Branch: `feature/vor-04-rueckkanal-api-workflow-status-vermerke-fuer-verlinkte-objekte`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "VOR-05", + "title": "Akten-Übersicht (Workflow-eigene Oberfläche)", + "epic": "VOR", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Next.js/React/TypeScript", + "description": "Eigenständige Übersicht aller Akten im Workflow-Modul selbst (Liste, Filter nach Status/Verantwortlichem, Detailansicht mit Vermerken/verknüpften Objekten). Für Fälle, in denen man direkt in Workflow arbeitet statt über DMS/Mail einzusteigen. Zusätzlich eine Kanban-Ansicht für Wiedervorlagen mit Drag & Drop zwischen Statusspalten.", + "dependsOn": [ + "VOR-01", + "VOR-02", + "VOR-03", + "SHL-01" + ], + "akzeptanz": [ + "Liste aller Akten ist nach Status und Verantwortlichem filterbar", + "Detailansicht zeigt Vermerke, Wiedervorlagen und verknüpfte Objekte einer Akte vollständig an", + "Übersicht funktioniert unabhängig davon, ob der Zugriff über DMS/Mail oder direkt in Workflow erfolgt", + "Kanban-Ansicht für Wiedervorlagen zeigt Spalten nach Fälligkeit/Status, Drag & Drop zwischen Spalten schreibt den neuen Status über VOR-03 zurück", + "Kanban-Ansicht zeigt ausschließlich Wiedervorlagen des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet" + ], + "pruefungen": [ + "Filter nach Status und Verantwortlichem liefert im Test korrekte Teilmengen", + "Detailansicht einer Testakte zeigt im Test Vermerke, Wiedervorlagen und verknüpfte Objekte vollständig", + "Akte mit Referenzen aus mehreren Modulen wird im Test korrekt dargestellt", + "Verschieben einer Wiedervorlage per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über VOR-03", + "Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Wiedervorlagen des aktuell aktiven Mandanten" + ], + "status": "Fertig", + "epicName": "Akte & Vorgang", + "epicEmoji": "📁", + "wave": 5, + "unlocks": [], + "prompt": "# VOR-05 – Akten-Übersicht (Workflow-eigene Oberfläche)\n\n**Epic:** 📁 Akte & Vorgang | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nOberfläche greift ausschließlich über bestehende Schnittstellen zu. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nEigenständige Übersicht aller Akten im Workflow-Modul selbst (Liste, Filter nach Status/Verantwortlichem, Detailansicht mit Vermerken/verknüpften Objekten). Zusätzlich eine Kanban-Ansicht speziell für Wiedervorlagen (Spalten nach Fälligkeit/Status, z. B. Offen/Diese Woche/Überfällig/Erledigt) — Drag & Drop einer Wiedervorlage in eine andere Spalte aktualisiert ihren Status über VOR-03. Für Fälle, in denen man direkt in Workflow arbeitet statt über DMS/Mail einzusteigen.\n\n**Technische Grundlage:** Next.js/React/TypeScript\n\n## Produkt-DNA für diesen Bereich\n> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.\n\n**Übernehmen:**\n- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.\n- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.\n- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.\n\n**Bewusst vermeiden:**\n- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).\n- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).\n\n**Für genau diese Kachel:** Die eigene Oberfläche ergänzt den Rückkanal (VOR-04) für den Fall, dass direkt in Workflow gearbeitet wird.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `VOR-01` Akte/Vorgang-Objektmodell – Vorgang/Akte als eigenständiger Objekttyp mit Status, Aktenzeichen, Verantwortlichem und referenzierten Fremdobjekten.\n- `VOR-02` Vermerke/Notizen an Akte/Vorgang – Freitext-Vermerke mit Autor und Zeitstempel, unveränderlich nach dem Speichern.\n- `VOR-03` Wiedervorlage (Akte/Objekt-Terminverknüpfung) – Wiedervorlage-Termin an Akte oder Einzelobjekt, nutzt die TSK-Engine für Fälligkeit und Benachrichtigung.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Liste aller Akten ist nach Status und Verantwortlichem filterbar\n2. Detailansicht zeigt Vermerke, Wiedervorlagen und verknüpfte Objekte einer Akte vollständig an\n3. Übersicht funktioniert unabhängig davon, ob der Zugriff über DMS/Mail oder direkt in Workflow erfolgt\n4. Kanban-Ansicht für Wiedervorlagen zeigt Spalten nach Fälligkeit/Status, Drag & Drop zwischen Spalten schreibt den neuen Status über VOR-03 zurück\n5. Kanban-Ansicht zeigt ausschließlich Wiedervorlagen des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Filter nach Status und Verantwortlichem liefert im Test korrekte Teilmengen\n2. Detailansicht einer Testakte zeigt im Test Vermerke, Wiedervorlagen und verknüpfte Objekte vollständig\n3. Akte mit Referenzen aus mehreren Modulen wird im Test korrekt dargestellt\n4. Verschieben einer Wiedervorlage per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über VOR-03\n5. Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Wiedervorlagen des aktuell aktiven Mandanten\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Anzeige-Oberfläche in DMS – siehe externes DMS-Board `DOC-13`\n- Anzeige-Oberfläche in Mail – siehe externes Mail-Board `UX-09`\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `VOR-05: akten uebersicht workflow eigene oberflaeche`\n- Branch: `feature/vor-05-akten-uebersicht-workflow-eigene-oberflaeche`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-06", + "title": "Schnittstellen-Vertragstests", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Vertragstests (Consumer-Driven Contracts), CI-Pipeline", + "description": "Vertragstests für die beiden von DMS/Mail konsumierten Schnittstellen – Push-Registrierung (ENG-02 Modul-Adapter) und Pull-Rückkanal (VOR-04 Rückkanal-API für Akte/Vermerke/Wiedervorlage). Beide Richtungen müssen gegen Breaking Changes abgesichert sein, nicht nur eine.", + "dependsOn": [ + "VOR-04", + "ENG-02" + ], + "akzeptanz": [ + "Vertragstests decken ENG-02 (Push) und VOR-04 (Pull) beide ab", + "Absichtlich brechender Schema-Wechsel an jeder der beiden Schnittstellen lässt Tests fehlschlagen", + "Tests laufen automatisiert in der CI" + ], + "pruefungen": [ + "Testlauf gegen aktuellen Stand grün", + "Simulierte Breaking Change an beiden Schnittstellen einzeln erkannt", + "CI-Integration nachgewiesen" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 6, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-06 – Schnittstellen-Vertragstests\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVertragstests für die beiden von DMS/Mail konsumierten Schnittstellen – Push-Registrierung (ENG-02 Modul-Adapter) und Pull-Rückkanal (VOR-04 Rückkanal-API für Akte/Vermerke/Wiedervorlage). Beide Richtungen müssen gegen Breaking Changes abgesichert sein, nicht nur eine.\n\n**Technische Grundlage:** Vertragstests (Consumer-Driven Contracts), CI-Pipeline\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Vertragskorpus je Schnittstelle, an dem Kompatibilität wiederholbar geprüft wird.\n- Nachgewiesene Erkennung von Breaking Changes als Freigabevoraussetzung, wie es verbindliche Schnittstellenverträge verlangen.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur auf dem Entwicklungsrechner mit einer Handvoll Beispielaufrufen.\n\n**Für genau diese Kachel:** Zwei Konsumrichtungen, zwei Bruchstellen: Push- und Pull-Schnittstelle müssen einzeln gegen Breaking Changes abgesichert werden, nicht nur die zuletzt geänderte.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.\n- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte – Read-only API, über die ein Modul (DMS/Mail) für eine gegebene Objekt-Referenz (Typ+ID) abfragt: gehört das zu einer Akte, welche Vermerke/offenen Wiedervorlagen gibt es.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Vertragstests decken ENG-02 (Push) und VOR-04 (Pull) beide ab\n2. Absichtlich brechender Schema-Wechsel an jeder der beiden Schnittstellen lässt Tests fehlschlagen\n3. Tests laufen automatisiert in der CI\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testlauf gegen aktuellen Stand grün\n2. Simulierte Breaking Change an beiden Schnittstellen einzeln erkannt\n3. CI-Integration nachgewiesen\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-06: schnittstellen-vertragstests`\n- Branch: `feature/qa-06-schnittstellen-vertragstests`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "RTE-05", + "title": "KI-gestützte Routing-Vorschläge (Kopplung AI WFS-02)", + "epic": "RTE", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "HTTP-Client gegen AI-Vorschlags-API (WFS-02), Fallback auf regelbasiertes Routing", + "description": "Vor einer regelbasierten Routing-Entscheidung optional einen KI-Vorschlag von NEXARCH AI (WFS-02) abrufen und dem Bearbeiter als Empfehlung anzeigen – die regelbasierte Engine bleibt die maßgebliche Entscheidungsinstanz, KI liefert nur einen Vorschlag.", + "dependsOn": [ + "RTE-04" + ], + "akzeptanz": [ + "Routing-Ansicht zeigt bei aktiviertem AI-Modul einen KI-Vorschlag zusätzlich zur regelbasierten Entscheidung an", + "Ist das AI-Modul nicht aktiviert oder nicht erreichbar, funktioniert das regelbasierte Routing unverändert ohne Vorschlag (fail open, kein Blockieren)", + "Ein KI-Vorschlag wird niemals automatisch übernommen – Bearbeiter muss ihn aktiv bestätigen" + ], + "pruefungen": [ + "Test gegen echte AI-Testinstanz: Vorschlag wird korrekt angezeigt und nachvollziehbar begründet", + "Test: AI-Endpunkt nicht erreichbar – regelbasiertes Routing läuft unverändert weiter, keine Fehlermeldung im Regelpfad", + "Test: KI-Vorschlag wird nicht bestätigt – Routing folgt der regelbasierten Entscheidung, nicht dem Vorschlag" + ], + "status": "Fertig", + "epicName": "Regelbasiertes Routing", + "epicEmoji": "🔁", + "wave": 6, + "unlocks": [ + "QA-04" + ], + "prompt": "# RTE-05 – KI-gestützte Routing-Vorschläge (Kopplung AI WFS-02)\n\n**Epic:** 🔁 Regelbasiertes Routing | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVor einer regelbasierten Routing-Entscheidung optional einen KI-Vorschlag von NEXARCH AI (WFS-02) abrufen und dem Bearbeiter als Empfehlung anzeigen – die regelbasierte Engine bleibt die maßgebliche Entscheidungsinstanz, KI liefert nur einen Vorschlag.\n\n**Technische Grundlage:** HTTP-Client gegen AI-Vorschlags-API (WFS-02), Fallback auf regelbasiertes Routing\n\n## Produkt-DNA für diesen Bereich\n> Regeln entscheiden, KI schlägt vor. Der Mensch bleibt in der Verantwortung.\n\n**Übernehmen:**\n- Vorschlagscharakter klar von Entscheidung getrennt – analog zur Vier-Augen-Freigabe bei APR-Kacheln, wo Vorschläge nie automatisch verbindlich werden.\n\n**Bewusst vermeiden:**\n- Keine automatische Übernahme von KI-Vorschlägen als Entscheidung. Das würde Nachvollziehbarkeit und Verantwortlichkeit des Routings untergraben.\n\n**Für genau diese Kachel:** AI WFS-02 liefert die Vorschlags-API, aber ohne diese Kachel hätte niemand im Workflow-Board sie konsumiert – der Vorschlag bliebe ungenutzt.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `RTE-04` Testlauf/Simulation von Routing-Regeln – Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.\n\nSetzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/ai-kanban/):\n- `WFS-02` Vorschlags-API (Kopplung Workflow-Board Modul-Adapter) – Schnittstelle, über die das Workflow-Board Vorschläge für Routing-Entscheidungen abruft.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Routing-Ansicht zeigt bei aktiviertem AI-Modul einen KI-Vorschlag zusätzlich zur regelbasierten Entscheidung an\n2. Ist das AI-Modul nicht aktiviert oder nicht erreichbar, funktioniert das regelbasierte Routing unverändert ohne Vorschlag (fail open, kein Blockieren)\n3. Ein KI-Vorschlag wird niemals automatisch übernommen – Bearbeiter muss ihn aktiv bestätigen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test gegen echte AI-Testinstanz: Vorschlag wird korrekt angezeigt und nachvollziehbar begründet\n2. Test: AI-Endpunkt nicht erreichbar – regelbasiertes Routing läuft unverändert weiter, keine Fehlermeldung im Regelpfad\n3. Test: KI-Vorschlag wird nicht bestätigt – Routing folgt der regelbasierten Entscheidung, nicht dem Vorschlag\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine direkt abhängigen Kacheln bekannt)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `RTE-05: ki gestützte routing vorschläge kopplung ai wfs 02`\n- Branch: `feature/rte-05-ki-gestützte-routing-vorschläge-kopplung-ai-wfs-02`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-07", + "title": "Last- & Leistungstest", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Lastgenerator, Messprotokoll", + "description": "Lasttest für Workflow unter realistischer Last aus DMS und Mail gleichzeitig – insbesondere Modul-Adapter-Ereignispfad (ENG-02), Genehmigungs-Engine (APR) und Routing (RTE) unter Last.", + "dependsOn": [ + "ENG-02", + "RTE-04" + ], + "akzeptanz": [ + "Definierte Ziel-Latenz für die Ereigniszustellung (ENG-02) unter Last aus zwei Modulen eingehalten", + "Genehmigungs-Engine bleibt unter simulierter Mehrfach-Zustellung korrekt (keine doppelten Freigaben, keine verlorenen Anfragen)", + "Regelbasiertes Routing bleibt unter Last korrekt und deterministisch" + ], + "pruefungen": [ + "Lasttest mit simulierten parallelen Ereignissen aus DMS und Mail durchgeführt, Ergebnis dokumentiert", + "Test auf doppelte/verlorene Genehmigungsanfragen unter Last", + "Routing-Determinismus unter Last geprüft (gleiche Eingabe, gleiches Ergebnis)" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 7, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-07 – Last- & Leistungstest\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 7\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nLasttest für Workflow unter realistischer Last aus DMS und Mail gleichzeitig – insbesondere Modul-Adapter-Ereignispfad (ENG-02), Genehmigungs-Engine (APR) und Routing (RTE) unter Last.\n\n**Technische Grundlage:** Lastgenerator, Messprotokoll\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Nachgewiesene Prüfergebnisse als Freigabevoraussetzung, wie in allen anderen Boards.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n\n**Für genau diese Kachel:** Workflow wird von zwei Modulen gleichzeitig getriggert (DMS und Mail) – ohne Lasttest bleibt unklar, ob Genehmigungs- und Routing-Pfad das verkraften.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n- `RTE-04` Testlauf/Simulation von Routing-Regeln – Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Definierte Ziel-Latenz für die Ereigniszustellung (ENG-02) unter Last aus zwei Modulen eingehalten\n2. Genehmigungs-Engine bleibt unter simulierter Mehrfach-Zustellung korrekt (keine doppelten Freigaben, keine verlorenen Anfragen)\n3. Regelbasiertes Routing bleibt unter Last korrekt und deterministisch\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Lasttest mit simulierten parallelen Ereignissen aus DMS und Mail durchgeführt, Ergebnis dokumentiert\n2. Test auf doppelte/verlorene Genehmigungsanfragen unter Last\n3. Routing-Determinismus unter Last geprüft (gleiche Eingabe, gleiches Ergebnis)\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine direkt abhängigen Kacheln bekannt)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-07: last leistungstest`\n- Branch: `feature/qa-07-last-leistungstest`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-08", + "title": "Barrierefreiheits-Audit", + "epic": "QA", + "featureIds": [], + "role": "QA", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Prüfwerkzeuge, Bildschirmleser", + "description": "Unabhängige Prüfung aller Workflow-Oberflächen (Genehmigungs-Oberfläche, Aufgaben-Oberfläche, Routing-Regel-Editor, Akten-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.", + "dependsOn": [ + "APR-03", + "TSK-04", + "RTE-03", + "VOR-05" + ], + "akzeptanz": [ + "Keine kritischen Verstöße offen", + "Manueller Bildschirmleser-Durchlauf dokumentiert", + "Restbefunde sind mit Frist eingeplant" + ], + "pruefungen": [ + "Automatisierte Prüfung über alle Hauptseiten", + "Vollständiger Ablauf ohne Maus durchgeführt", + "Auditbericht abgelegt" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 6, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-08 – Barrierefreiheits-Audit\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Workflow (modulübergreifende Genehmigungs-, Aufgaben- und Routing-Engine).\nUnabhängige Prüfung gegen die dokumentierten Akzeptanzkriterien – kein Wiederholen der Entwicklertests.\n\n## Auftrag\nUnabhängige Prüfung aller Workflow-Oberflächen (Genehmigungs-Oberfläche, Aufgaben-Oberfläche, Routing-Regel-Editor, Akten-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.\n\n**Technische Grundlage:** Prüfwerkzeuge, Bildschirmleser\n\n## Produkt-DNA für diesen Bereich\n> Barrierefreiheit ist Grundeigenschaft der Core-SHL-01-Basis, keine Nachrüstung je Modul – dieses Audit prüft, ob Workflow sie tatsächlich geerbt statt umgangen hat.\n\n**Übernehmen:**\n- Core SHL-01: WCAG 2.1 AA als verbindliche Eigenschaft der Basis-Komponenten.\n\n**Bewusst vermeiden:**\n- Kein eigenes, modulspezifisches Barrierefreiheits-Konzept parallel zu SHL-01.\n\n**Für genau diese Kachel:** Ohne dieses Audit bleibt offen, ob Workflow-Oberflächen die von SHL-01 geerbten WCAG-Eigenschaften tatsächlich nutzen oder lokal umgehen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `APR-03` Genehmigungs-Oberfläche – Persönliche Freigabeliste mit Vorschau des betroffenen Objekts, Kommentarfeld und den Aktionen Freigeben, Ablehnen, Zurückgeben.\n- `TSK-04` Aufgaben-Oberfläche – Aufgabenliste mit Fälligkeit, Priorität und Filter, angelehnt an das einfache, schnelle Bedienmodell von Trello/Linear. Zusätzlich eine Kanban-Ansicht (Spalten nach Status, z. B. Offen/In Bearbeitung/Erledigt) — Drag & Drop einer Aufgabe in eine andere Spalte aktualisiert ihren Status über TSK-01.\n- `RTE-03` Routing-Regel-Editor (Oberfläche) – Oberfläche zum Anlegen, Priorisieren und Testen von Routing-Regeln.\n- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche) – Eigenständige Übersicht aller Akten im Workflow-Modul selbst (Liste, Filter nach Status/Verantwortlichem, Detailansicht mit Vermerken/verknüpften Objekten). Für Fälle, in denen man direkt in Workflow arbeitet statt über DMS/Mail einzusteigen. Zusätzlich eine Kanban-Ansicht für Wiedervorlagen mit Drag & Drop zwischen Statusspalten.\n- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System – liefert die WCAG-2.1-AA-Basis-Komponenten, gegen die alle oben genannten Oberflächen geprüft werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Keine kritischen Verstöße offen\n2. Manueller Bildschirmleser-Durchlauf dokumentiert\n3. Restbefunde sind mit Frist eingeplant\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Automatisierte Prüfung über alle Hauptseiten\n2. Vollständiger Ablauf ohne Maus durchgeführt\n3. Auditbericht abgelegt\n\n## Bekannte Fehler vermeiden\nWCAG war ursprünglich nur in DMS und Mail als eigene Kachel geplant – Workflow hätte ungeprüft geblieben, obwohl die Oberflächen dieselbe Core-SHL-01-Basis nutzen. Audit deshalb als eigene Kachel je Board, analog DMS QA-11 und Mail QA-08.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Core `SHL-01` WCAG-Basis-Komponenten selbst (diese Kachel prüft nur die Nutzung).\n- Behebung gefundener Verstöße in den jeweiligen Frontend-Kacheln.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n" + }, + { + "code": "VOR-06", + "title": "Tenant-Kontext-Validierung im Rückkanal (DMS/Mail-Abfrage)", + "epic": "VOR", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go", + "description": "VOR-04 ist eine Read-only-API, über die DMS/Mail für eine Objekt-Referenz abfragen, ob sie zu einer Akte gehört, inklusive Vermerken und Wiedervorlagen. Ohne eigene Validierung würde Workflow dem vom aufrufenden Modul übergebenen Tenant-Kontext blind vertrauen und könnte dadurch Akte-Daten eines fremden Mandanten herausgeben, obwohl Workflow selbst korrekt mandantengetrennt ist. VOR-04 validiert den mitgelieferten Nutzer-Tenant-Kontext unabhängig gegen die Core-Registry und gegen den Tenant der angefragten Akte, bevor Vermerke/Wiedervorlagen zurückgegeben werden.", + "dependsOn": [ + "VOR-04" + ], + "akzeptanz": [ + "Jede VOR-04-Anfrage trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter", + "Workflow validiert, dass der übergebene Tenant-Kontext zum Tenant der angefragten Akte passt, unabhängig vom Service-Credential-Scope des aufrufenden Moduls", + "Eine Anfrage mit falschem/fremdem Tenant-Kontext wird abgelehnt und protokolliert, statt Daten preiszugeben" + ], + "pruefungen": [ + "Test: VOR-04-Anfrage mit korrektem Nutzer-Tenant-Kontext liefert erwartete Akte-Daten", + "Test: VOR-04-Anfrage mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt", + "Integrationstest über DMS DOC-13 → VOR-04 mit zwei verschiedenen Tenants, prüft Isolation" + ], + "status": "Fertig", + "epicName": "Akte & Vorgang", + "epicEmoji": "📁", + "wave": 8, + "unlocks": [], + "prompt": "# VOR-06 – Tenant-Kontext-Validierung im Rückkanal (DMS/Mail-Abfrage)\n\n**Epic:** 📁 Akte & Vorgang | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVOR-04 ist eine Read-only-API, über die DMS/Mail für eine Objekt-Referenz abfragen, ob sie zu einer Akte gehört, inklusive Vermerken und Wiedervorlagen. Ohne eigene Validierung würde Workflow dem vom aufrufenden Modul übergebenen Tenant-Kontext blind vertrauen und könnte dadurch Akte-Daten eines fremden Mandanten herausgeben, obwohl Workflow selbst korrekt mandantengetrennt ist. VOR-04 validiert den mitgelieferten Nutzer-Tenant-Kontext unabhängig gegen die Core-Registry und gegen den Tenant der angefragten Akte, bevor Vermerke/Wiedervorlagen zurückgegeben werden.\n\n**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der anfragenden Quelle.\n\n**Bewusst vermeiden:**\n- Keycloak – Vertrauen in vom Client mitgelieferte Claims ohne serverseitige Gegenprüfung führte zu Eskalationsfällen.: Workflow verifiziert den Tenant-Kontext jeder VOR-04-Anfrage selbst, statt der Angabe des anfragenden Moduls zu vertrauen.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: VOR-04.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jede VOR-04-Anfrage trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter\n2. Workflow validiert, dass der übergebene Tenant-Kontext zum Tenant der angefragten Akte passt, unabhängig vom Service-Credential-Scope des aufrufenden Moduls\n3. Eine Anfrage mit falschem/fremdem Tenant-Kontext wird abgelehnt und protokolliert, statt Daten preiszugeben\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: VOR-04-Anfrage mit korrektem Nutzer-Tenant-Kontext liefert erwartete Akte-Daten\n2. Test: VOR-04-Anfrage mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt\n3. Integrationstest über DMS DOC-13 → VOR-04 mit zwei verschiedenen Tenants, prüft Isolation\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Workflow-Board, 2026-09-12), analog zu DMS-Finding `INT-16`/Mail-Finding `INT-11`: physische Tenant-Trennung (Core Modell C) schützt nur innerhalb eines Moduls — ein Rückkanal ohne eigene Tenant-Validierung kann diese Isolation modulübergreifend aufweichen.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `VOR-06: tenant-kontext-validierung-im-r-ckkanal-dms-mail-abfrage`\n- Branch: `feature/vor-06-tenant-kontext-validierung-im-r-ckkanal-dms-mail-abfrage`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-06", + "title": "Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go", + "description": "ENG-02 nimmt Objekttyp- und Auslöser-Ereignis-Registrierungen von DMS und Mail entgegen. Analog zu Archive `RET-12` muss jede Registrierung den mitgelieferten Tenant-Kontext unabhängig gegen die Core-Registry (TEN-01) validieren, statt der Angabe des registrierenden Moduls zu vertrauen.", + "dependsOn": [ + "ENG-02" + ], + "akzeptanz": [ + "Jede Objekttyp-/Ereignis-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird", + "Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert", + "Bestehende, korrekte Registrierungsabläufe aus ENG-02 funktionieren unverändert" + ], + "pruefungen": [ + "Test: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen", + "Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt", + "Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 8, + "unlocks": [], + "prompt": "# ENG-06 – Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nENG-02 nimmt Objekttyp- und Auslöser-Ereignis-Registrierungen von DMS und Mail entgegen. Analog zu Archive `RET-12` muss jede Registrierung den mitgelieferten Tenant-Kontext unabhängig gegen die Core-Registry (TEN-01) validieren, statt der Angabe des registrierenden Moduls zu vertrauen.\n\n**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der meldenden Quelle.\n\n**Bewusst vermeiden:**\n- Keycloak – Vertrauen in vom Client mitgelieferte Claims ohne serverseitige Gegenprüfung führte zu Eskalationsfällen.: Workflow verifiziert den Tenant-Kontext jeder eingehenden Registrierung selbst gegen die Core-Registry.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ENG-02.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jede Objekttyp-/Ereignis-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird\n2. Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert\n3. Bestehende, korrekte Registrierungsabläufe aus ENG-02 funktionieren unverändert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen\n2. Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt\n3. Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Workflow-Board, 2026-09-12), analog zu Archive-Finding `RET-12`: Workflow ist die Senke für Objekttyp-Registrierungen aus zwei anderen Modulen — ohne eigene Validierung würde ein Fehler oder eine Kompromittierung in DMS/Mail unmittelbar durchschlagen.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-06: unabh-ngige-tenant-validierung-bei-objekttyp-registrierung-durch-dms-mail`\n- Branch: `feature/eng-06-unabh-ngige-tenant-validierung-bei-objekttyp-registrierung-durch-dms-mail`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-07", + "title": "Technische Durchsetzung Append-only für das Instanzschritt-Protokoll", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "PostgreSQL (REVOKE/Trigger), Go", + "description": "ENG-04 konzipiert ein vollständiges, unveränderliches Protokoll jedes Instanzschritts, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` und DMS `VER-08` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.", + "dependsOn": [ + "ENG-04" + ], + "akzeptanz": [ + "Die vom Workflow-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen", + "Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert", + "Bestehende ENG-04-Funktionalität (Schreiben/Lesen neuer Einträge) bleibt unverändert nutzbar" + ], + "pruefungen": [ + "Testet UPDATE/DELETE gegen die Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung", + "Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird", + "Regressionstest: normales Schreiben/Lesen von Protokolleinträgen funktioniert weiterhin" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 8, + "unlocks": [], + "prompt": "# ENG-07 – Technische Durchsetzung Append-only für das Instanzschritt-Protokoll\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nENG-04 konzipiert ein vollständiges, unveränderliches Protokoll jedes Instanzschritts, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` und DMS `VER-08` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.\n\n**Technische Grundlage:** PostgreSQL (REVOKE/Trigger), Go\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- archivdms (positives Muster): sicherheitsrelevante Entscheidungen technisch statt nur konventionell absichern.\n\n**Bewusst vermeiden:**\n- Keycloak – Admin-Events sind konfigurierbar/löschbar.: Unveränderlichkeit ist eine Datenbank-Garantie, keine Anwendungs-Konvention.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ENG-04.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Die vom Workflow-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen\n2. Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert\n3. Bestehende ENG-04-Funktionalität (Schreiben/Lesen neuer Einträge) bleibt unverändert nutzbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testet UPDATE/DELETE gegen die Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung\n2. Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird\n3. Regressionstest: normales Schreiben/Lesen von Protokolleinträgen funktioniert weiterhin\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Workflow-Board, 2026-09-12), Analogie zu Core-Finding #5/`AUD-07` und DMS `VER-08`: 'unveränderlich' ohne technische Durchsetzung ist nur ein Versprechen des Anwendungscodes.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-04` Workflow-Instanz-Historie & Nachvollziehbarkeit\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-07: technische-durchsetzung-append-only-f-r-das-instanzschritt-protokoll`\n- Branch: `feature/eng-07-technische-durchsetzung-append-only-f-r-das-instanzschritt-protokoll`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-09", + "title": "Workflow-Trigger nach Upload und Auto-Regel", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Modul-Adapter-Ereigniskanal, Postgres-Jobqueue, Migration Workflow-Schema", + "description": "Ereignisvertrag und Verarbeitung: ein DMS-Ereignis (Upload, Auto-Regel, Metadatenaenderung) erzeugt ueber den Modul-Adapter genau eine Aufgabe/Genehmigung je Mandant, dedupliziert und tenant-gebunden.", + "dependsOn": [ + "ENG-02", + "VOR-04" + ], + "akzeptanz": [ + "Der Ereignisvertrag ist festgelegt und wird ueber den Modul-Adapter (ENG-02) registriert; Service-Authentifizierung und Tenant-Bindung", + "Eine mandantenweite Zuordnung von Ereignis und Bedingung zu Aufgabe/Genehmigungslauf ist konfigurierbar; genau eine Aufgabe je Ereignis, Dedup, Nachzustellung nach Ausfall", + "Aufgaben entstehen nur fuer berechtigte Rollen; Dokumentverweis nur ueber Modul-Rueckkanal mit Tenant-Kontext, Cross-Tenant wird abgelehnt" + ], + "pruefungen": [ + "Doppelzustellung desselben Ereignisses ergibt genau eine Aufgabe, Reihenfolge/Wiederholung nach Ausfall getestet", + "Ausfall des Workflow-Moduls: DMS laeuft weiter, Nachzustellung ohne Verlust/Dubletten", + "Cross-Tenant negativ: falscher Mandant/fremde Dokument-ID wird abgelehnt und protokolliert" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 9, + "unlocks": [], + "prompt": "# ENG-09 – Workflow-Trigger nach Upload und Auto-Regel\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 9\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.\nTechstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell C (eine Datenbank je Mandant, siehe SKALIERUNGSKONZEPT.md Abschnitt 4).\n\n## Auftrag\npaperless-ngx löst Workflows aus Ereignissen aus (z. B. Dokument hinzugefügt, Dokument aktualisiert). Das DMS hat Auto-Regeln (MET-05), aber keinen Weg, aus einem Ereignis eine Aufgabe oder Genehmigung im Workflow-Modul zu erzeugen. Der Modul-Adapter (ENG-02) kennt Trigger als Konzept; ein konkreter Ereigniskanal vom DMS in das Workflow-Modul fehlt.\n\nEinen Ereignisvertrag und die Verarbeitung im Workflow-Modul bauen: Ein Ereignis des DMS (Dokument hochgeladen, Auto-Regel angewendet, Metadatenfeld geändert) erzeugt genau eine Aufgabe oder einen Genehmigungslauf gemäß mandantenweiter Zuordnung.\n\n**Technische Grundlage:** Workflow `ENG-02` (Modul-Adapter, Registrierung von Objekttypen und Triggern), `VOR-04` (Rückkanal), Postgres-Jobqueue, Migration im Workflow-Schema\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Ereignisgesteuerte Automatisierung wie bei paperless-ngx, aber mandantengebunden und nachweisbar.\n\n**Bewusst vermeiden:**\n- Keine Dokumentinhalte im Ereignis: nur IDs, Mandant, Ereignistyp und Zeitpunkt; Inhalte holt das Workflow-Modul bei Bedarf über den Modul-Rückkanal mit Tenant-Kontext.\n- Keine Doppelaufgaben: dasselbe Ereignis erzeugt genau eine Aufgabe (Idempotenz, Zustellung mindestens einmal mit Deduplizierung).\n- Keine Kopplung der Verfügbarkeit: fällt das Workflow-Modul aus, arbeitet das DMS weiter und die Ereignisse werden später zugestellt.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ENG-02, VOR-04.\nBezug: DMS `MET-05` (Auto-Regeln), DMS `INT-13` (Workflow-Anbindung, noch nicht gebaut), DMS `INT-16` (Tenant-Kontext in Rückkanälen), `VERGLEICHSANALYSE-QUELLSYSTEME.md` (Wurzelverzeichnis), Quelle [P3] (paperless-ngx: Workflows).\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Der Ereignisvertrag ist festgelegt (Ereignistypen, minimaler Payload aus IDs, Mandant und Zeitpunkt, Version) und wird über den Modul-Adapter (ENG-02) registriert; das Workflow-Modul nimmt Ereignisse mit Service-Authentifizierung und Tenant-Bindung an\n2. Eine mandantenweite Zuordnung von Ereignis und Bedingung zu Aufgabe oder Genehmigungslauf ist konfigurierbar; dasselbe Ereignis erzeugt genau eine Aufgabe, Wiederholungen werden dedupliziert, Ausfall führt zu späterer Zustellung\n3. Aufgaben entstehen nur für berechtigte Rollen; der Verweis auf das Dokument läuft ausschließlich über den Modul-Rückkanal mit Tenant-Kontext, kein Ereignis aus einem anderen Mandanten wird verarbeitet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Doppelzustellung desselben Ereignisses ergibt genau eine Aufgabe; Reihenfolge und Wiederholung nach Ausfall sind getestet\n2. Ausfall des Workflow-Moduls: das DMS läuft weiter, Ereignisse werden nach Wiederanlauf ohne Verlust und ohne Dubletten zugestellt\n3. Cross-Tenant negativ: Ereignis mit falschem Mandanten oder fremder Dokument-ID wird abgelehnt und protokolliert\n\n## Nicht Bestandteil dieser Kachel\n- Ein Workflow-Designer oder Regeleditor in der Oberfläche\n- Der DMS-seitige Sender der Ereignisse (DMS `INT-13`)\n- Auswertung von Dokumentinhalten im Workflow-Modul\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-09: workflow-trigger nach upload und auto-regel`\n- Branch: `feature/eng-09-workflow-trigger-nach-upload-und-auto-regel`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-11", + "title": "Workflow-App: gebündelter Diensteinstiegspunkt (cmd/workflow-app)", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "net/http.ServeMux, pgxpool, Umgebungsvariablen fuer DSN/Listen-Adresse", + "description": "Buendelt alle bestehenden Workflow-API-Pakete (approvalapi, backchannelapi, caseoverviewapi, routingruleapi, taskapi, moduleadapter, escalationnotify, routingsuggestapi-Client) zu einem einzigen startbaren Dienst cmd/workflow-app, analog connect/cmd/connect-app.", + "dependsOn": [ + "ENG-02", + "ENG-09", + "TSK-05" + ], + "akzeptanz": [ + "cmd/workflow-app startet einen einzigen HTTP-Dienst, der alle bestehenden Workflow-API-Pakete unter ihren jeweiligen Routen bereitstellt", + "DSN und Listen-Adresse ausschliesslich ueber Umgebungsvariablen, keine Zugangsdaten im Code", + "Fehlende Pflicht-Umgebungsvariable fuehrt zu klarer Fehlermeldung beim Start, nicht zu einem stillen Absturz", + "Dienst startet real auf Host 204 und beantwortet mindestens einen Endpunkt je eingebundenem API-Paket" + ], + "pruefungen": [ + "Realer Start auf Host 204 mit Wegwerf-DB, mindestens ein Aufruf je eingebundenem API-Paket erfolgreich", + "Fehlende Pflicht-Umgebungsvariable: Dienst beendet sich mit klarer Fehlermeldung, kein Port offen", + "Bestehende Modul-Testsuite bleibt unveraendert gruen" + ], + "status": "Fertig", + "epicName": "Workflow-Engine", + "epicEmoji": "🔀", + "wave": 9, + "unlocks": [], + "prompt": "# ENG-11 – Workflow-App: gebündelter Diensteinstiegspunkt (cmd/workflow-app)\n\n**Epic:** 🔀 Workflow-Engine | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 9\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing).\n\n## Auftrag\nBei der Vorbereitung des 131-Rollouts wurde real festgestellt: Workflow hat keinen `cmd/`-Diensteinstiegspunkt, der einen Port öffnet — nur Test-Fixtures und CI-Gate-CLIs. Die API-Handler-Pakete (`approvalapi`, `backchannelapi`, `caseoverviewapi`, `routingruleapi`, `taskapi`, `eventtrigger`/`moduleadapter`-HTTP-Server, `escalationnotify`, `routingsuggestapi`-Client-Aufrufer) sind reine Bibliotheken ohne bündelnden Dienst. Verbinde sie zu einem einzigen startbaren `cmd/workflow-app`, analog zu `connect/cmd/connect-app`.\n\n**Technische Grundlage:** `net/http.ServeMux`, `pgxpool`, Umgebungsvariablen für DSN/Listen-Adresse (analog `connect-app`).\n\n## Produkt-DNA für diesen Bereich\n> Ein Dienst pro Modul, alle HTTP-Handler-Pakete darin registriert — kein Diensteinstiegspunkt pro Feature.\n\n## Ausgangslage\nReferenzmuster: `connect/cmd/connect-app/main.go` (DSN aus `NEXARCH_CONNECT_APP_TENANT_DSN`, Listen-Adresse aus `NEXARCH_CONNECT_APP_LISTEN_ADDR`, Kill-Switch-Check aus ENG-10 ganz am Anfang). Alle bereits fertigen Workflow-API-Pakete: `approvalapi`, `backchannelapi`, `caseoverviewapi`, `routingruleapi`, `taskapi`, `moduleadapter` (Event-Empfang aus ENG-09), `escalationnotify`/`notifyclient` (TSK-05), `routingsuggestapi`-Client (WFS-02, Aufrufseite für RTE-05 falls schon vorhanden).\n\n## Akzeptanzkriterien\n1. `cmd/workflow-app` startet einen einzigen HTTP-Dienst, der alle bestehenden Workflow-API-Pakete unter ihren jeweiligen Routen bereitstellt\n2. DSN und Listen-Adresse ausschließlich über Umgebungsvariablen, keine Zugangsdaten im Code\n3. Fehlende Pflicht-Umgebungsvariable führt zu klarer Fehlermeldung beim Start, nicht zu einem stillen Absturz\n4. Dienst startet real auf Host 204 und beantwortet mindestens einen Endpunkt je eingebundenem API-Paket\n\n## Prüfungen vor der Abnahme\n1. Realer Start auf Host 204 mit Wegwerf-DB, mindestens ein Aufruf je eingebundenem API-Paket erfolgreich\n2. Fehlende Pflicht-Umgebungsvariable: Dienst beendet sich mit klarer Fehlermeldung, kein Port offen\n3. Bestehende Modul-Testsuite bleibt unverändert grün (keine Regression durch das neue `cmd/`-Paket)\n\n## Nicht Bestandteil dieser Kachel\n- Neue Fachlogik/Endpunkte (nur Zusammenführung bestehender Pakete)\n- Rollout/Deploy auf Host 131 (separater, späterer Schritt nach Freigabe)\n- Kill-Switch (bereits anderswo, falls für Workflow gewünscht: eigenes Folgeticket analog ENG-10)\n\n## Arbeitsweise\n1. Lies zuerst `connect/cmd/connect-app/main.go` als Referenzmuster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-11: workflow-app gebuendelter diensteinstiegspunkt`\n- Branch: `feature/eng-11-workflow-app-diensteinstiegspunkt`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-01", + "title": "Echte Authentifizierungsmiddleware vor allen Fach-API-Handlern (Approver-Impersonation über X-User-Id)", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Echte Authentifizierungsmiddleware (analog DMS moduleauth-Muster), Go, net/http.ServeMux-Middleware-Kette", + "description": "Security-Review (main, 2026-10, Fable 5.1): approvalapi/caseapi/caseoverviewapi/routingruleapi/backchannelapi lesen den Akteur ungeprüft aus dem rohen X-User-Id-Header, cmd/workflow-app registriert sie ohne Auth-Middleware. Angriff: fremde Freigaben im Namen anderer Nutzer erteilen, Akten/Routing-Regeln/Rückkanal-Daten über gefälschten Header manipulieren bzw. lesen.", + "dependsOn": [ + "APR-01", + "APR-02", + "VOR-01", + "RTE-01", + "VOR-04", + "ENG-11" + ], + "akzeptanz": [ + "Jeder Fach-API-Handler (approvalapi, caseapi, caseoverviewapi, routingruleapi, backchannelapi) verlangt ein verifiziertes Session- oder Modul-Token, bevor er die Anfrage verarbeitet", + "Der Akteur wird ausschließlich aus dem verifizierten Token abgeleitet, ein roher X-User-Id-Header ohne gültiges Token wird ignoriert bzw. die Anfrage abgelehnt", + "Eine Anfrage ohne gültiges Token oder mit manipuliertem X-User-Id-Header eines anderen Nutzers wird mit 401/403 abgewiesen, bevor Fachlogik erreicht wird", + "Bestehende, korrekt authentifizierte Abläufe über alle fünf betroffenen Handler-Pakete funktionieren unverändert" + ], + "pruefungen": [ + "Angriff vor Umsetzung reproduziert: fremde X-User-Id erteilt Freigabe im Namen eines anderen Nutzers", + "Nach Umsetzung: derselbe Angriff gegen alle fünf Handler-Pakete wird mit 401/403 blockiert", + "Regressionstest: Nutzer mit gültigem Token kann weiterhin eigene Freigaben/Akten/Routing-Regeln/Rückkanal-Daten bearbeiten bzw. lesen" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 10, + "unlocks": [], + "prompt": "# SEC-01 – Echte Authentifizierungsmiddleware vor allen Fach-API-Handlern (Approver-Impersonation über X-User-Id)\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 10\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main, 2026-10, Fable 5.1) hat verifiziert: `workflow/internal/approvalapi/handler.go:28-37` (identisch `caseapi/caseapi.go:28-37`, `caseoverviewapi/caseoverviewapi.go:36-44`, `routingruleapi/handler.go:46-55`, `backchannelapi/backchannelapi.go:32-36`) liest den Akteur ungeprüft aus dem rohen `X-User-Id`-Header. `workflow/cmd/workflow-app/main.go:119-123` registriert diese Handler ohne Auth-Middleware davor – nur `moduleadapter` prüft ein Service-Token. `approval.Decide` (`workflow/internal/approval/approval.go:198`) prüft lediglich `task.Assignee == actor`, wobei `actor` direkt aus dem Header stammt.\n\nAngriffsszenario: `GET /approvals` mit beliebigem `X-User-Id` listet die offenen Aufgaben dieses Nutzers; `X-User-Id: ` plus `POST /approvals/{id}/decide {\"decision\":\"approved\"}` erteilt eine Freigabe im Namen eines fremden Nutzers – die Historie protokolliert dabei den gefälschten Akteur, nicht den tatsächlichen Angreifer. Derselbe Weg erlaubt das Anlegen/Schließen von Akten, das Umschreiben von Routing-Regeln und das Lesen von Rückkanal-Daten (Vermerke, potenziell Art.-9-Daten).\n\n**Technische Grundlage:** Echte Authentifizierungsmiddleware (analog DMS `moduleauth`-Muster), Go, `net/http.ServeMux`-Middleware-Kette\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- DMS `moduleauth`-Muster: Identität des Akteurs kommt aus einem verifizierten Session-/Modul-Token, nie aus einem rohen Client-Header.\n\n**Bewusst vermeiden:**\n- Kein Vertrauen in clientgesteuerte Header als Identitätsquelle, auch nicht übergangsweise.\n\n## Ausgangslage\nBetrifft bereits fertiggestellte Kacheln: APR-01, APR-02, VOR-01, RTE-01, VOR-04, ENG-11. Die Handler-Pakete existieren und laufen produktiv über `cmd/workflow-app`; es wird keine neue Fachlogik gebaut, sondern eine Middleware vorgeschaltet.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder Fach-API-Handler (`approvalapi`, `caseapi`, `caseoverviewapi`, `routingruleapi`, `backchannelapi`) verlangt ein verifiziertes Session- oder Modul-Token, bevor er die Anfrage verarbeitet\n2. Der Akteur (`X-User-Id`-Äquivalent) wird ausschließlich aus dem verifizierten Token abgeleitet, ein roher `X-User-Id`-Header ohne gültiges Token wird ignoriert bzw. die Anfrage abgelehnt\n3. Eine Anfrage ohne gültiges Token oder mit manipuliertem `X-User-Id`-Header bei gültigem Token eines anderen Nutzers wird mit 401/403 abgewiesen, bevor Fachlogik (z. B. `approval.Decide`) erreicht wird\n4. Bestehende, korrekt authentifizierte Abläufe über alle fünf betroffenen Handler-Pakete funktionieren unverändert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Reproduziere den Angriff vor der Umsetzung: `GET /approvals` und `POST /approvals/{id}/decide` mit beliebigem/fremdem `X-User-Id` ohne gültiges Token – dokumentiere, dass die Freigabe im Namen des fremden Nutzers tatsächlich gelingt\n2. Nach Umsetzung: denselben Angriff gegen alle fünf Handler-Pakete (`approvalapi`, `caseapi`, `caseoverviewapi`, `routingruleapi`, `backchannelapi`) wiederholen und nachweisen, dass er jetzt mit 401/403 blockiert wird, bevor Fachlogik ausgeführt wird\n3. Regressionstest: ein Nutzer mit gültigem Token kann weiterhin eigene Freigaben entscheiden, eigene Akten anlegen/schließen, Routing-Regeln lesen, Rückkanal-Daten für berechtigte Objekte abrufen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SEC-03` Rollenbeschränkung für Routing-Regel-Schreibzugriff und Service-Token-Pflicht im Rückkanal (setzt auf dieser Middleware auf, fügt aber eine zusätzliche Rollenprüfung hinzu)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster (insbesondere DMS `moduleauth`).\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-01: echte-authentifizierungsmiddleware-vor-allen-fach-api-handlern`\n- Branch: `feature/sec-01-echte-authentifizierungsmiddleware-vor-allen-fach-api-handlern`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-02", + "title": "Vier-Augen-Prinzip tatsächlich verdrahten und fail-closed statt fail-open", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Go, bestehendes dualcheck-Paket aus APR-02, PostgreSQL", + "description": "Security-Review: dualcheck-Paket aus APR-02 ist nirgends in den echten Genehmigungspfad eingebunden (grep liefert 0 Treffer außerhalb eigener Tests), approval.Create prüft nicht assignee != requestedBy, dualcheck.go liefert bei DB-Fehler fail-open (false, nil) statt zu blockieren.", + "dependsOn": [ + "APR-01", + "APR-02" + ], + "akzeptanz": [ + "approval.Create bzw. der Genehmigungspfad ruft für vier-augen-pflichtige Prozesstypen tatsächlich dualcheck auf", + "Eine Selbstfreigabe (assignee == requestedBy) wird im echten Genehmigungspfad abgelehnt", + "dualcheck.go blockiert bei Datenbankfehler die Freigabe (fail-closed) statt sie durchzulassen", + "Bestehende APR-01/APR-02-Funktionalität für nicht vier-augen-pflichtige Prozesstypen bleibt unverändert nutzbar" + ], + "pruefungen": [ + "Vor Umsetzung: Selbstfreigabe über echten Pfad gelingt, da dualcheck nicht eingebunden ist", + "Vor Umsetzung: simulierter DB-Fehler in dualcheck führt zu fail-open", + "Nach Umsetzung: Selbstfreigabe über echten Pfad wird abgelehnt", + "Nach Umsetzung: simulierter DB-Fehler blockiert die Freigabe" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 10, + "unlocks": [], + "prompt": "# SEC-02 – Vier-Augen-Prinzip tatsächlich verdrahten und fail-closed statt fail-open\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 10\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main, 2026-10, Fable 5.1) hat verifiziert: `grep \"dualcheck\\.\"` außerhalb des eigenen Pakets/Tests liefert 0 Treffer – das in APR-02 konzipierte Vier-Augen-Paket `dualcheck` ist nirgends in den tatsächlichen Genehmigungspfad eingebunden. `approval.Create` (`workflow/internal/approval/approval.go:111-135`) prüft nicht, ob `assignee != requestedBy`, sodass eine Selbstfreigabe technisch möglich ist, obwohl APR-02 genau das ausschließen sollte. Zusätzlich liefert `dualcheck.go:51-57` bei jedem Datenbankfehler `false, nil` zurück (fail-open) – bei einer Störung (z. B. kurzer DB-Hänger) reicht dann eine einzige Bestätigung statt zwei, ohne dass dies auffällt.\n\n**Technische Grundlage:** Go, bestehendes `dualcheck`-Paket aus APR-02, PostgreSQL\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- APR-02: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – hier tatsächlich in den Ausführungspfad einbinden statt nur als ungenutztes Paket vorzuhalten.\n\n**Bewusst vermeiden:**\n- Kein fail-open bei sicherheitsrelevanten Prüfungen: eine Störung darf eine Kontrolle nie abschwächen, sondern muss sie verschärfen (blockieren statt durchlassen).\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: APR-01, APR-02. Das `dualcheck`-Paket existiert bereits vollständig inklusive eigener Tests, es fehlt ausschließlich die Verdrahtung in `approval.Create`/`approval.Decide` und die Korrektur des Fehlerfalls.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. `approval.Create` bzw. der Genehmigungspfad ruft für als vier-augen-pflichtig konfigurierte Prozesstypen tatsächlich `dualcheck` auf, nicht nur der Testcode\n2. Eine Freigabe, bei der `assignee == requestedBy` (Selbstfreigabe), wird im echten Genehmigungspfad abgelehnt, nicht nur in Unit-Tests des `dualcheck`-Pakets isoliert\n3. `dualcheck.go:51-57` liefert bei einem Datenbankfehler nicht mehr `false, nil`, sondern blockiert die Freigabe (fail-closed) und meldet den Fehler nachvollziehbar\n4. Bestehende APR-01/APR-02-Funktionalität für nicht vier-augen-pflichtige Prozesstypen bleibt unverändert nutzbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Reproduziere vor der Umsetzung: Selbstfreigabe über den echten `approval.Create`/`Decide`-Pfad (nicht über isolierte `dualcheck`-Tests) gelingt, da `dualcheck` nicht eingebunden ist\n2. Simuliere einen Datenbankfehler in `dualcheck` vor der Umsetzung und dokumentiere, dass dies zu `false, nil` (fail-open, einzige Bestätigung reicht) führt\n3. Nach Umsetzung: denselben Selbstfreigabe-Versuch über den echten Pfad wiederholen, erwarte Ablehnung\n4. Nach Umsetzung: denselben simulierten Datenbankfehler wiederholen, erwarte Blockade der Freigabe statt Durchlass\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SEC-01` Authentifizierungsmiddleware (Vorbedingung für eine verlässliche Akteur-Identität, auf der die Vier-Augen-Prüfung aufbaut)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-02: vier-augen-prinzip-tatsaechlich-verdrahten-und-fail-closed`\n- Branch: `feature/sec-02-vier-augen-prinzip-tatsaechlich-verdrahten-und-fail-closed`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-03", + "title": "Routing-Regel-Schreibzugriff auf Verantwortliche beschränken, Rückkanal mit Service-Token-Pflicht", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Rollenmodell (Admin-/Routing-Verantwortliche-Rolle), created_by-Spalte, Service-Token-Prüfung (analog moduleadapter), Go, PostgreSQL-Migration", + "description": "Security-Review: routingruleapi lässt POST/PUT jedem authentifizierten Nutzer zu, keine created_by-Spalte; backchannelapi prüft X-Service-Token beim Rückkanal nicht. Angriff: beliebiger Nutzer schreibt Routing-Regeln um bzw. liest Rückkanal-Daten ohne Service-Authentifizierung.", + "dependsOn": [ + "RTE-01", + "RTE-02", + "VOR-04", + "SEC-01" + ], + "akzeptanz": [ + "POST/PUT auf Routing-Regeln ist nur für Nutzer mit Admin-/Routing-Verantwortliche-Rolle möglich", + "Jede angelegte/geänderte Routing-Regel speichert den handelnden Nutzer in einer created_by-Spalte", + "GET /objects/{module}/{type}/{id}/context verlangt ein gültiges X-Service-Token, bevor die bestehende Slug-/Responsible-Prüfung greift" + ], + "pruefungen": [ + "Vor Umsetzung: gewöhnlicher Nutzer ohne Rolle ändert Routing-Regel erfolgreich", + "Vor Umsetzung: Rückkanal liefert Daten ohne X-Service-Token", + "Nach Umsetzung: gewöhnlicher Nutzer wird abgewiesen, Nutzer mit Rolle kann weiterhin ändern, created_by ist gesetzt", + "Nach Umsetzung: Rückkanal ohne gültiges Token abgewiesen, mit Token funktioniert bestehende Prüfung weiterhin" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 10, + "unlocks": [], + "prompt": "# SEC-03 – Routing-Regel-Schreibzugriff auf Verantwortliche beschränken, Rückkanal mit Service-Token-Pflicht\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 10\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main, 2026-10, Fable 5.1) hat zwei verwandte Lücken verifiziert:\n\n1. `workflow/internal/routingruleapi/handler.go:37-43`: POST/PUT auf Routing-Regeln liegt nur hinter `requireUser` (jeder authentifizierte Nutzer, keine Rollenprüfung), `userID` wird dabei ignoriert, es gibt keine `created_by`-Spalte (`routingrule.go:145-148`). `routingengine.go:45` liest die Regeln live beim Routing – jeder authentifizierte Nutzer kann also beliebige Routing-Regeln umschreiben und damit z. B. Genehmigungen/Akten an sich selbst umleiten lassen, ohne dass nachvollziehbar ist, wer die Regel geändert hat.\n2. `backchannelapi/backchannelapi.go:28`: `GET /objects/{module}/{type}/{id}/context` läuft ohne Prüfung des `X-Service-Token`; `backchannel.go:87-115` prüft nur den eigenen Slug plus `Responsible == X-User-Id`, was wegen SEC-01 ebenfalls aus einem rohen Header stammt.\n\n**Technische Grundlage:** Rollenmodell (Admin-/Routing-Verantwortliche-Rolle), `created_by`-Spalte, Service-Token-Prüfung (analog `moduleadapter`), Go, PostgreSQL-Migration\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- RTE-01 bis RTE-04: Routing bleibt modulunabhängig und regelbasiert konfigurierbar – hier wird nur die Schreibberechtigung verengt, nicht die Funktionalität.\n\n**Bewusst vermeiden:**\n- Keine implizite Annahme, dass „authentifiziert“ gleich „berechtigt, Routing-Regeln zu ändern“ ist.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: RTE-01, RTE-02, VOR-04, SEC-01 (liefert die verifizierte Akteur-Identität, auf der diese Rollenprüfung erst verlässlich aufbauen kann).\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. POST/PUT auf Routing-Regeln ist nur für Nutzer mit einer Admin-/Routing-Verantwortliche-Rolle möglich, ein Nutzer ohne diese Rolle wird abgewiesen\n2. Jede angelegte/geänderte Routing-Regel speichert den tatsächlich handelnden Nutzer in einer `created_by`-Spalte (Migration ergänzt)\n3. `GET /objects/{module}/{type}/{id}/context` (Rückkanal) verlangt ein gültiges `X-Service-Token`, eine Anfrage ohne oder mit ungültigem Token wird abgewiesen, bevor die bestehende Slug-/Responsible-Prüfung greift\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Reproduziere vor der Umsetzung: ein gewöhnlicher authentifizierter Nutzer ohne besondere Rolle kann eine Routing-Regel per POST/PUT ändern\n2. Reproduziere vor der Umsetzung: `GET /objects/{module}/{type}/{id}/context` ohne `X-Service-Token` liefert dennoch Rückkanal-Daten\n3. Nach Umsetzung: derselbe gewöhnliche Nutzer wird bei Routing-Regel-Änderung abgewiesen, ein Nutzer mit der neuen Rolle kann weiterhin ändern, und `created_by` ist in der DB nachweisbar gesetzt\n4. Nach Umsetzung: dieselbe Rückkanal-Anfrage ohne gültiges `X-Service-Token` wird abgewiesen, mit gültigem Token und bestehender Slug-/Responsible-Prüfung funktioniert sie weiterhin\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SEC-01` Authentifizierungsmiddleware (Vorbedingung für eine verlässliche Akteur-Identität)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-03: routing-regel-schreibzugriff-beschraenken-rueckkanal-service-token-pflicht`\n- Branch: `feature/sec-03-routing-regel-schreibzugriff-beschraenken-rueckkanal-service-token-pflicht`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-04", + "title": "Tenant-gebundener Dedupe-Key gegen Dedupe-Key-Vergiftung durch abgelehnte Fremd-Tenant-Events", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "PostgreSQL-Migration (UNIQUE(tenant_slug, dedupe_key) statt globalem Unique-Index), Go", + "description": "Security-Review: moduleadapter/events.go belegt den global-uniquen dedupe_key auch bei abgelehnten Fremd-Tenant-Events (ON CONFLICT DO NOTHING), Handler liefert trotzdem 202. Angriff: vorhersagbarer Dedupe-Key mit falschem Tenant-Kontext blockiert künftige legitime Events mit demselben Key stillschweigend.", + "dependsOn": [ + "ENG-02", + "ENG-09" + ], + "akzeptanz": [ + "dedupe_key ist nur innerhalb eines Tenants eindeutig (UNIQUE(tenant_slug, dedupe_key)), nicht global", + "Ein wegen falschem Tenant-Kontext abgelehntes Event belegt den Dedupe-Key nicht dauerhaft", + "Ein legitimes Event mit zuvor fremd-belegtem Dedupe-Key wird nach der Korrektur korrekt verarbeitet", + "Bestehende Dedup-Funktionalität innerhalb eines Tenants bleibt unverändert korrekt" + ], + "pruefungen": [ + "Vor Umsetzung: fremd-Tenant-Event mit vorhersagbarem Key blockiert nachfolgendes legitimes Event", + "Nach Umsetzung: legitimes Event erzeugt nachweislich die erwartete Aufgabe/Genehmigung", + "Regressionstest: zwei Tenants mit identischem Dedupe-Key-Schema werden unabhängig korrekt verarbeitet", + "Regressionstest: doppelte Zustellung innerhalb eines Tenants erzeugt weiterhin genau eine Aufgabe" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 10, + "unlocks": [], + "prompt": "# SEC-04 – Tenant-gebundener Dedupe-Key gegen Dedupe-Key-Vergiftung durch abgelehnte Fremd-Tenant-Events\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 10\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main, 2026-10, Fable 5.1) hat verifiziert: `workflow/internal/moduleadapter/events.go:64-68` belegt den `dedupe_key` global-unique (Migration `0013:13`, `ON CONFLICT DO NOTHING`) auch dann, wenn das Event wegen falschem Tenant-Kontext abgelehnt wird. Der Handler liefert trotz Ablehnung 202 zurück (`handler.go:167`).\n\nAngriffsszenario: Ein Angreifer kennt oder errät das Dedupe-Key-Schema (z. B. `dms:document::created`) und sendet ein Event mit diesem Key, aber falschem/fremdem Tenant-Kontext. Das Event wird fachlich abgelehnt, belegt aber den global-uniquen Key dauerhaft. Ein später eintreffendes, legitimes Event desselben Keys aus dem korrekten Tenant wird dann durch `ON CONFLICT DO NOTHING` stillschweigend verworfen – die zugehörige Genehmigung/Aufgabe entsteht nie, ohne dass dies auffällt (der ursprüngliche Absender erhielt ja 202).\n\n**Technische Grundlage:** PostgreSQL-Migration (`UNIQUE(tenant_slug, dedupe_key)` statt globalem Unique-Index), Go\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- ENG-09: Dedup bleibt mandantengebunden, wie es die übrige Tenant-Isolation des Moduls vorsieht – ein globaler Unique-Index ist hier ein Implementierungsfehler, keine bewusste Entscheidung.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ENG-02, ENG-09.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. `dedupe_key` ist nur innerhalb eines Tenants eindeutig (`UNIQUE(tenant_slug, dedupe_key)`), nicht global\n2. Ein wegen falschem/fremdem Tenant-Kontext abgelehntes Event belegt den Dedupe-Key nicht dauerhaft (weder global noch für den eigentlichen Tenant)\n3. Ein legitimes Event, dessen Dedupe-Key zuvor von einem abgelehnten Fremd-Tenant-Event „belegt“ wurde, wird nach der Korrektur korrekt verarbeitet und erzeugt die erwartete Aufgabe/Genehmigung\n4. Bestehende Dedup-Funktionalität innerhalb eines Tenants (ENG-09: genau eine Aufgabe je Ereignis) bleibt unverändert korrekt\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Reproduziere vor der Umsetzung: Event mit vorhersagbarem Dedupe-Key und falschem Tenant-Kontext senden (wird abgelehnt), danach dasselbe Event mit korrektem Tenant-Kontext senden – dokumentiere, dass die zugehörige Aufgabe/Genehmigung nicht entsteht\n2. Nach Umsetzung: denselben Ablauf wiederholen – das legitime Event mit korrektem Tenant-Kontext erzeugt jetzt nachweislich die Aufgabe/Genehmigung\n3. Regressionstest: zwei Tenants mit identischem Dedupe-Key-Schema senden jeweils ein legitimes Event – beide werden unabhängig korrekt verarbeitet, kein Cross-Tenant-Konflikt\n4. Regressionstest: doppelte Zustellung desselben legitimen Events innerhalb eines Tenants erzeugt weiterhin genau eine Aufgabe (ENG-09-Verhalten bleibt erhalten)\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-09` Workflow-Trigger nach Upload und Auto-Regel (bleibt fachlich unverändert, nur die Dedup-Eindeutigkeit wird korrigiert)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-04: tenant-gebundener-dedupe-key-gegen-dedupe-key-vergiftung`\n- Branch: `feature/sec-04-tenant-gebundener-dedupe-key-gegen-dedupe-key-vergiftung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-05", + "title": "Rohe Datenbankfehler im moduleadapter-Handler normalisieren", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 1, + "tech": "Fehlernormalisierung analog apierror.Normalize-Muster aus Core, Go", + "description": "Security-Review: moduleadapter/handler.go gibt an drei Stellen rohe pgx-Fehlermeldungen (Constraint-/Schema-Details) direkt an den Client zurück.", + "dependsOn": [ + "ENG-02" + ], + "akzeptanz": [ + "Alle drei Fehlerstellen in moduleadapter/handler.go geben eine normalisierte Fehlermeldung aus, nicht err.Error() roh", + "Interne Details (Constraint-/Tabellen-/Spaltennamen, SQL-Fragmente) erscheinen in keiner HTTP-Antwort dieser drei Stellen", + "Der tatsächliche Fehler bleibt serverseitig im Log vollständig erhalten", + "Bestehendes Fehlerverhalten für Clients (korrekter HTTP-Statuscode) bleibt erhalten" + ], + "pruefungen": [ + "Vor Umsetzung: provozierter DB-Fehler an allen drei Stellen zeigt rohe pgx-Meldung in der HTTP-Antwort", + "Nach Umsetzung: HTTP-Antwort enthält keine internen Details mehr", + "Serverseitiges Log enthält weiterhin die vollständige Originalfehlermeldung", + "Regressionstest: normale fehlerfreie Aufrufe funktionieren unverändert" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 10, + "unlocks": [], + "prompt": "# SEC-05 – Rohe Datenbankfehler im moduleadapter-Handler normalisieren\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentag | **Welle:** 10\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main, 2026-10, Fable 5.1) hat verifiziert: `workflow/internal/moduleadapter/handler.go:67,91,159` ruft `writeError(400, err.Error())` auf und gibt damit rohe pgx-Fehlermeldungen (inklusive Constraint-Namen, Spalten- und Schema-Details) direkt an den aufrufenden Client zurück. Das liefert einem Angreifer Informationen über die interne Datenbankstruktur (Tabellennamen, Constraints, Typen), die für gezieltere Folgeangriffe nutzbar sind.\n\n**Technische Grundlage:** Fehlernormalisierung analog `apierror.Normalize`-Muster aus Core, Go\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Core `apierror.Normalize`-Muster: interne Fehlerdetails nie an den Client, nur eine normalisierte, für den Client verständliche Fehlermeldung.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ENG-02.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle drei Fehlerstellen in `moduleadapter/handler.go` (Zeilen 67, 91, 159) geben bei einem Datenbankfehler eine normalisierte Fehlermeldung aus, nicht `err.Error()` roh\n2. Interne Details (Constraint-Namen, Tabellen-/Spaltennamen, SQL-Fragmente) erscheinen in keiner HTTP-Antwort dieser drei Stellen\n3. Der tatsächliche, unveränderte Fehler bleibt serverseitig im Log vollständig erhalten (keine Informationsverlust fürs Debugging, nur fürs Client-Response)\n4. Bestehendes Fehlerverhalten für Clients (korrekter HTTP-Statuscode, erkennbarer Fehlerfall) bleibt erhalten\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Reproduziere vor der Umsetzung: provoziere an allen drei Stellen je einen Datenbankfehler (z. B. Constraint-Verletzung) und dokumentiere die rohe pgx-Fehlermeldung in der HTTP-Antwort\n2. Nach Umsetzung: denselben Fehler an allen drei Stellen erneut provozieren, HTTP-Antwort enthält keine Constraint-/Tabellen-/Spaltennamen mehr\n3. Prüfe serverseitiges Log desselben Fehlerfalls: vollständige Originalfehlermeldung ist dort weiterhin auffindbar\n4. Regressionstest: normale, fehlerfreie Aufrufe von `moduleadapter` funktionieren unverändert\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Fehlernormalisierung an anderen Workflow-API-Paketen außerhalb von `moduleadapter` (nicht Teil dieses Befunds)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster (insbesondere Core `apierror.Normalize`).\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-05: rohe-datenbankfehler-im-moduleadapter-handler-normalisieren`\n- Branch: `feature/sec-05-rohe-datenbankfehler-im-moduleadapter-handler-normalisieren`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-06", + "title": "Technische Durchsetzung Append-only für verbleibende Workflow-Protokolltabellen", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "PostgreSQL (REVOKE/Trigger, inkl. Sequence-GRANT bei BIGSERIAL), Go, analog ENG-07/Core AUD-07/DMS VER-08", + "description": "Security-Review: workflow_instance_history/case_notes haben Trigger ohne REVOKE (unvollständig), approval_tasks/dualcheck_confirmations/routing_decisions sind komplett ungesichert (kein Trigger, kein REVOKE).", + "dependsOn": [ + "ENG-07", + "APR-01", + "APR-02", + "RTE-02", + "VOR-02" + ], + "akzeptanz": [ + "workflow_instance_history und case_notes erhalten zusätzlich zum Trigger ein REVOKE UPDATE/DELETE von der Anwendungsrolle", + "approval_tasks, dualcheck_confirmations, routing_decisions erhalten REVOKE UPDATE/DELETE und einen Trigger mit RAISE WARNING, inkl. Sequence-GRANT bei BIGSERIAL", + "Die Anwendungsrolle kann bei keiner der fünf Tabellen Protokolleinträge verändern oder löschen", + "Bestehende INSERT/SELECT-Funktionalität aller fünf Tabellen bleibt unverändert nutzbar" + ], + "pruefungen": [ + "Vor Umsetzung: UPDATE/DELETE-Test gegen alle fünf Tabellen zeigt, welche davon tatsächlich veränderbar sind", + "Nach Umsetzung: Rechteverweigerung bei allen fünf Tabellen", + "Änderungsversuch wird bei allen fünf Tabellen selbst sichtbar protokolliert", + "Regressionstest: normales Schreiben/Lesen inkl. BIGSERIAL-Sequence-Nutzung funktioniert weiterhin" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 10, + "unlocks": [], + "prompt": "# SEC-06 – Technische Durchsetzung Append-only für verbleibende Workflow-Protokolltabellen\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 10\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nENG-07 hat das Muster „REVOKE UPDATE/DELETE von der App-Rolle + Trigger mit RAISE WARNING“ bereits für `workflow_instance_history` etabliert. Security-Review (main, 2026-10, Fable 5.1) hat verifiziert, dass dieses Muster bei weiteren Workflow-Protokolltabellen fehlt oder unvollständig ist:\n\n- `workflow_instance_history`, `case_notes`: nur Trigger vorhanden, kein REVOKE – die Anwendungsrolle kann Einträge trotz Trigger-Versuch technisch weiterhin per UPDATE/DELETE verändern, sofern der Trigger umgangen oder nicht konsequent ausgelöst wird; ohne REVOKE ist der Schutz unvollständig durchgesetzt.\n- `approval_tasks`, `dualcheck_confirmations`, `routing_decisions`: komplett ungesichert – weder Trigger noch REVOKE. Jede dieser Tabellen protokolliert sicherheitsrelevante Entscheidungen (wer hat was freigegeben/bestätigt/geroutet), die nachträglich unbemerkt veränderbar sind.\n\n**Technische Grundlage:** PostgreSQL (REVOKE/Trigger, inkl. Sequence-GRANT bei BIGSERIAL), Go, analog ENG-07/Core `AUD-07`/DMS `VER-08`\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- ENG-07/archivdms (positives Muster): sicherheitsrelevante Entscheidungen technisch statt nur konventionell absichern – hier konsequent auf alle verbleibenden Protokolltabellen übertragen.\n\n**Bewusst vermeiden:**\n- Kein Trigger ohne REVOKE und kein REVOKE ohne Trigger – beide Bestandteile sind zusammen nötig, ein Teilschutz gilt nicht als erfüllt.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ENG-07 (liefert das Referenzmuster), APR-01, APR-02, RTE-02, VOR-02.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. `workflow_instance_history` und `case_notes` erhalten zusätzlich zum bestehenden Trigger ein REVOKE UPDATE/DELETE von der Anwendungsrolle\n2. `approval_tasks`, `dualcheck_confirmations`, `routing_decisions` erhalten jeweils REVOKE UPDATE/DELETE von der Anwendungsrolle sowie einen Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert (RAISE WARNING), inklusive Sequence-GRANT, sofern eine BIGSERIAL-Spalte betroffen ist\n3. Die Anwendungsrolle kann bei keiner der fünf Tabellen Protokolleinträge nachweislich verändern oder löschen\n4. Bestehende Schreib-/Lesefunktionalität (INSERT/SELECT) aller fünf Tabellen bleibt unverändert nutzbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Teste UPDATE/DELETE mit der Anwendungsrolle gegen jede der fünf Tabellen einzeln vor der Umsetzung – dokumentiere, welche davon tatsächlich erfolgreich verändert/gelöscht werden können\n2. Nach Umsetzung: denselben Test gegen alle fünf Tabellen wiederholen, erwarte Rechteverweigerung bei allen fünf\n3. Prüfe, dass der Änderungsversuch bei allen fünf Tabellen selbst sichtbar protokolliert wird (Trigger-Warnung)\n4. Regressionstest: normales Schreiben/Lesen (INSERT/SELECT, inkl. BIGSERIAL-Sequence-Nutzung) funktioniert bei allen fünf Tabellen weiterhin\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-07` Technische Durchsetzung Append-only für das Instanzschritt-Protokoll (liefert das Referenzmuster, bleibt selbst unverändert)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster, insbesondere die ENG-07-Migration als Vorlage.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-06: technische-durchsetzung-append-only-fuer-verbleibende-protokolltabellen`\n- Branch: `feature/sec-06-technische-durchsetzung-append-only-fuer-verbleibende-protokolltabellen`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + } + ] +} diff --git a/workflow-kanban/kanban.html b/workflow-kanban/kanban.html new file mode 100644 index 00000000..fc9fa7a9 --- /dev/null +++ b/workflow-kanban/kanban.html @@ -0,0 +1,50 @@ + + + + + +Workflow Kanban – lokal + + + +
    +
    +

    Workflow Kanban – lokal, offline, ohne Server

    + + + + + + + +
    +
    +
    +
    + + +
    +
    +
    +
    +
    +
    +
    + + +
    +
    +
    +

    +

    Baut auf

    +

    Schaltet frei

    +

    Akzeptanzkriterien

      +

      Prüfungen vor der Abnahme

        +

        Bau-Prompt

        
+  
        
+        
+
+
+
+
+
diff --git a/workflow-kanban/tickets/APR-01.md b/workflow-kanban/tickets/APR-01.md
new file mode 100644
index 00000000..cb26eed1
--- /dev/null
+++ b/workflow-kanban/tickets/APR-01.md
@@ -0,0 +1,66 @@
+# APR-01 – Freigabe-Postfach & Genehmigungsansicht (Backend)
+
+**Epic:** ✅ Genehmigungen & Freigaben  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.
+
+**Technische Grundlage:** PostgreSQL, REST-Schnittstelle
+
+## Produkt-DNA für diesen Bereich
+> Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.
+
+**Übernehmen:**
+- Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.
+- Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit.
+
+**Bewusst vermeiden:**
+- Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.
+- Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen.
+
+**Für genau diese Kachel:** paperless-ngx, Docspell und ecoDMS haben keine echte Freigabe – hier entsteht der Mehrwert gegenüber allen Vorbildern.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.
+- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Offene Genehmigungsaufgaben sind je Nutzer abrufbar
+2. Entscheidung ist genau einmal möglich
+3. Entscheidung ist mit Begründung protokollierbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Bereits entschiedene Aufgabe lässt sich nicht doppelt entscheiden
+2. Parallelentscheidung zweier Nutzer erzeugt keinen Fehlzustand
+3. Entscheidung erscheint korrekt in der Instanz-Historie (ENG-04)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `APR-02` Vier-Augen-Freigabe (generisches Muster)
+- `APR-03` Genehmigungs-Oberfläche
+- `APR-04` Delegation & Vertretungsregeln bei Abwesenheit
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `APR-01: freigabe postfach genehmigungsansicht backend`
+- Branch: `feature/apr-01-freigabe-postfach-genehmigungsansicht-backend`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/APR-02.md b/workflow-kanban/tickets/APR-02.md
new file mode 100644
index 00000000..36aaeefe
--- /dev/null
+++ b/workflow-kanban/tickets/APR-02.md
@@ -0,0 +1,63 @@
+# APR-02 – Vier-Augen-Freigabe (generisches Muster)
+
+**Epic:** ✅ Genehmigungen & Freigaben  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Generisches Muster für Freigaben, die eine zweite, unabhängige Bestätigung erfordern – modulunabhängig konfigurierbar.
+
+**Technische Grundlage:** Regelbasierte Zweitprüfung
+
+## Produkt-DNA für diesen Bereich
+> Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.
+
+**Übernehmen:**
+- Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.
+- Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit.
+
+**Bewusst vermeiden:**
+- Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.
+- Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen.
+
+**Für genau diese Kachel:** Ein generisches Muster verhindert, dass jedes Modul eine eigene Vier-Augen-Logik erfindet.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend) – Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Zweitprüfer darf nicht mit dem Ersteller identisch sein
+2. Freigabe ist erst nach zwei unabhängigen Bestätigungen wirksam
+3. Konfiguration ist je Prozesstyp aktivierbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Ersteller kann eigene Freigabe nicht zweitbestätigen
+2. Fehlende Zweitbestätigung blockiert die Wirkung nachweislich
+3. Aktivierung für neuen Prozesstyp ohne Codeänderung getestet
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-03` Prüfgate Genehmigungen & Aufgaben
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `APR-02: vier augen freigabe generisches muster`
+- Branch: `feature/apr-02-vier-augen-freigabe-generisches-muster`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/APR-03.md b/workflow-kanban/tickets/APR-03.md
new file mode 100644
index 00000000..972f5807
--- /dev/null
+++ b/workflow-kanban/tickets/APR-03.md
@@ -0,0 +1,63 @@
+# APR-03 – Genehmigungs-Oberfläche
+
+**Epic:** ✅ Genehmigungen & Freigaben  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
+
+## Auftrag
+Persönliche Freigabeliste mit Vorschau des betroffenen Objekts, Kommentarfeld und den Aktionen Freigeben, Ablehnen, Zurückgeben.
+
+**Technische Grundlage:** React/Next.js, TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.
+
+**Übernehmen:**
+- Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.
+- Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit.
+
+**Bewusst vermeiden:**
+- Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.
+- Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen.
+
+**Für genau diese Kachel:** Trello/Linear als Vorbild: einfach und schnell bedienbar, kein Schulungsaufwand.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend) – Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Offene Freigaben sind gebündelt sichtbar
+2. Ablehnung erfordert eine Begründung
+3. Entscheidung ist per Tastatur möglich
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Ansicht bei 200 offenen Aufgaben bleibt nutzbar
+2. Doppelte Entscheidung wird in der Oberfläche verhindert
+3. Tastaturbedienung für alle drei Aktionen geprüft
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `APR-03: genehmigungs oberflaeche`
+- Branch: `feature/apr-03-genehmigungs-oberflaeche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/APR-04.md b/workflow-kanban/tickets/APR-04.md
new file mode 100644
index 00000000..fa06fd69
--- /dev/null
+++ b/workflow-kanban/tickets/APR-04.md
@@ -0,0 +1,64 @@
+# APR-04 – Delegation & Vertretungsregeln bei Abwesenheit
+
+**Epic:** ✅ Genehmigungen & Freigaben  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Vertretungsregel je Nutzer und Zeitraum, sodass Genehmigungsaufgaben automatisch an eine Vertretung gehen.
+
+**Technische Grundlage:** Vertretungsmodell, Zeitraumlogik
+
+## Produkt-DNA für diesen Bereich
+> Genehmigungen mit dem Ernst von Alfrescos Vier-Augen-Prinzip, ohne dessen Konfigurationskomplexität.
+
+**Übernehmen:**
+- Alfresco: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – nicht für jeden Anwendungsfall neu gebaut.
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche als Vorbild für die Genehmigungsansicht – kein Schwergewicht.
+- Delegation und Vertretungsregeln als Bestandteil des Modells, nicht als Sonderfall bei Abwesenheit.
+
+**Bewusst vermeiden:**
+- Alfresco – kein grafischer Prozessdesigner als Voraussetzung für eine einfache Vier-Augen-Regel.
+- Keine modulspezifische Genehmigungslogik in DMS oder Mail – ein zentraler Adapter für alle Objekttypen.
+
+**Für genau diese Kachel:** Eskalation ohne Vertretungsregelung blockiert jeden Urlaub. Beides gehört zusammen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend) – Serverseitiges Modell für Genehmigungsaufgaben: Zuständigkeit, Status, Entscheidung, Bezug zum Workflow-Schritt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Vertretung ist zeitlich begrenzt konfigurierbar
+2. Aufgabe geht während der Abwesenheit automatisch an die Vertretung
+3. Rückkehr beendet die Vertretung automatisch
+4. Selbst-Vertretung (Genehmiger setzt sich selbst als Vertretung ein, um APR-02 Vier-Augen-Prinzip zu umgehen) wird verhindert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Aufgabe während aktiver Vertretung landet nachweislich bei der Vertretung
+2. Überlappende Vertretungsregeln werden eindeutig aufgelöst
+3. Ende der Vertretung wirkt ohne manuellen Eingriff
+4. Missbrauchstest: Genehmiger versucht, sich selbst als Vertretung einzutragen und eigene Anfrage über die Vertretung freizugeben – wird abgelehnt
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `APR-04: delegation vertretungsregeln bei abwesenheit`
+- Branch: `feature/apr-04-delegation-vertretungsregeln-bei-abwesenheit`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-01.md b/workflow-kanban/tickets/ENG-01.md
new file mode 100644
index 00000000..c9be3c2c
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-01.md
@@ -0,0 +1,67 @@
+# ENG-01 – Workflow-Engine & Zustandsmodell
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Komplex  |  **Aufwand:** 4 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.
+
+**Technische Grundlage:** Zustandsautomat, PostgreSQL, pgx/v5
+
+## Produkt-DNA für diesen Bereich
+> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.
+
+**Übernehmen:**
+- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.
+- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.
+- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.
+- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.
+
+**Für genau diese Kachel:** Der Zustandsautomat ist die Grundvoraussetzung, damit DMS und Mail keine eigene Workflow-Logik bauen müssen.
+
+## Ausgangslage
+Diese Kachel hat keine Vorbedingungen und ist sofort startbar.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Zustände und zulässige Übergänge sind je Prozesstyp definierbar
+2. Unzulässiger Übergang wird abgewiesen
+3. Laufende Instanz überlebt einen Neustart
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Unzulässiger Übergang wird im Test abgewiesen
+2. Gleichzeitige Übergänge zweier Nutzer erzeugen keinen Fehlzustand
+3. Neustart des Dienstes mit laufender Instanz geprüft
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger)
+- `ENG-03` Prozessdefinitions-Format (deklarativ, versionierbar)
+- `ENG-04` Workflow-Instanz-Historie & Nachvollziehbarkeit
+- `ENG-05` Fehlerbehandlung & Retry bei Workflow-Schritten
+- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend)
+- `TSK-01` Aufgabenmodell & Zuweisung
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-01: workflow engine zustandsmodell`
+- Branch: `feature/eng-01-workflow-engine-zustandsmodell`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-02.md b/workflow-kanban/tickets/ENG-02.md
new file mode 100644
index 00000000..700ebd4a
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-02.md
@@ -0,0 +1,65 @@
+# ENG-02 – Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger)
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.
+
+**Technische Grundlage:** REST-Schnittstelle, Adapter-Registrierung
+
+## Produkt-DNA für diesen Bereich
+> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.
+
+**Übernehmen:**
+- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.
+- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.
+- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.
+- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.
+
+**Für genau diese Kachel:** Ohne diese Schnittstelle müsste jedes Modul die Engine selbst verstehen – der Adapter kehrt das um.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Modul kann Objekttyp und Trigger ohne Codeänderung an der Engine registrieren
+2. Registrierung ist versionierbar und rückrollbar
+3. Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Testadapter aus fiktivem DMS- und Mail-Modul beide korrekt registriert
+2. Doppelte Registrierung wird abgewiesen
+3. Deregistrierung entfernt zugehörige Trigger vollständig
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `APR-01` Freigabe-Postfach & Genehmigungsansicht (Backend)
+- `RTE-01` Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig)
+- `QA-02` Prüfgate Engine & Adapter
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-02: modul adapter schnittstelle dms mail registrieren objekttypen trigger`
+- Branch: `feature/eng-02-modul-adapter-schnittstelle-dms-mail-registrieren-objekttypen-trigger`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-03.md b/workflow-kanban/tickets/ENG-03.md
new file mode 100644
index 00000000..981cf63e
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-03.md
@@ -0,0 +1,62 @@
+# ENG-03 – Prozessdefinitions-Format (deklarativ, versionierbar)
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Lesbares Konfigurationsformat für Prozessdefinitionen: Zustände, Übergänge, Bedingungen, Zuständigkeiten. Jede Definition ist versioniert.
+
+**Technische Grundlage:** YAML/JSON-Prozessdefinition, Schema-Validierung
+
+## Produkt-DNA für diesen Bereich
+> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.
+
+**Übernehmen:**
+- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.
+- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.
+- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.
+- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.
+
+**Für genau diese Kachel:** Ein lesbares Format statt eines grafischen Modellierers hält die Einstiegshürde niedrig.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Prozessdefinition ist ohne Codeänderung änderbar
+2. Ungültige Definition wird beim Laden abgewiesen
+3. Ältere Version bleibt für laufende Instanzen gültig
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Schema-Validierung gegen fehlerhafte Definition getestet
+2. Versionswechsel während laufender Instanz verändert deren Verhalten nicht rückwirkend
+3. Rollback auf Vorgängerversion funktioniert
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-03: prozessdefinitions format deklarativ versionierbar`
+- Branch: `feature/eng-03-prozessdefinitions-format-deklarativ-versionierbar`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-04.md b/workflow-kanban/tickets/ENG-04.md
new file mode 100644
index 00000000..7016d813
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-04.md
@@ -0,0 +1,62 @@
+# ENG-04 – Workflow-Instanz-Historie & Nachvollziehbarkeit
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Vollständiges, unveränderliches Protokoll jedes Instanzschritts: Person, Zeitpunkt, Zustand, Begründung.
+
+**Technische Grundlage:** Append-only Protokolltabelle, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.
+
+**Übernehmen:**
+- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.
+- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.
+- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.
+- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.
+
+**Für genau diese Kachel:** Nachvollziehbarkeit ist Voraussetzung für jede spätere Prüfung – nicht nachrüstbar.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Übergang wird protokolliert
+2. Protokoll ist nicht nachträglich veränderbar
+3. Historie ist je Instanz vollständig abrufbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Manipulationsversuch am Protokoll schlägt fehl
+2. Historie einer Beispielinstanz enthält alle Schritte in korrekter Reihenfolge
+3. Abfrage großer Historien bleibt performant
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-04: workflow instanz historie nachvollziehbarkeit`
+- Branch: `feature/eng-04-workflow-instanz-historie-nachvollziehbarkeit`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-05.md b/workflow-kanban/tickets/ENG-05.md
new file mode 100644
index 00000000..b6530c0c
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-05.md
@@ -0,0 +1,63 @@
+# ENG-05 – Fehlerbehandlung & Retry bei Workflow-Schritten
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Wiederholungslogik mit Backoff für fehlgeschlagene Workflow-Schritte, Dead-Letter-Pfad für dauerhaft fehlschlagende Instanzen.
+
+**Technische Grundlage:** Postgres-Jobqueue, Backoff-Strategie
+
+## Produkt-DNA für diesen Bereich
+> Eine deklarative Zustandsmaschine wie bei Camunda/Zeebe, leichtgewichtig gedacht statt BPMN-Vollausbau.
+
+**Übernehmen:**
+- Alfresco: echte Prozess-Engine mit deklarativen Prozessdefinitionen statt fest verdrahteter Freigabelogik.
+- Camunda/Zeebe: das Konzept deklarativer Zustandsmaschinen für Geschäftsprozesse – Zustände, Übergänge, Zuständigkeiten als Konfiguration, nicht als Code.
+- Vollständige Instanz-Historie mit Person, Zeitpunkt und Begründung je Schritt, damit jeder Prozessverlauf nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Alfresco – Ressourcen-Overhead und Konfigurationskomplexität: schlanker Go-Dienst mit Postgres-Jobqueue statt schwergewichtigem Anwendungsserver.
+- Camunda/Zeebe – kein grafischer BPMN-Modellierer und keine Vollausbau-Notation als Voraussetzung. Ein lesbares, versionierbares Konfigurationsformat genügt für den Start.
+
+**Für genau diese Kachel:** Fehlerbehandlung gehört ins Fundament der Engine, nicht in jede einzelne Prozessdefinition.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Fehlgeschlagener Schritt wird automatisch wiederholt
+2. Dauerhaft fehlschlagender Schritt landet in einem einsehbaren Fehlerzustand
+3. Retry ist idempotent
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Simulierter Fehlerfall löst korrekte Wiederholung aus
+2. Dead-Letter-Instanz ist auffindbar und manuell neu anstoßbar
+3. Mehrfacher Retry erzeugt keine doppelte Wirkung
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-02` Prüfgate Engine & Adapter
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-05: fehlerbehandlung retry bei workflow schritten`
+- Branch: `feature/eng-05-fehlerbehandlung-retry-bei-workflow-schritten`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-06.md b/workflow-kanban/tickets/ENG-06.md
new file mode 100644
index 00000000..decd9526
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-06.md
@@ -0,0 +1,58 @@
+# ENG-06 – Unabhängige Tenant-Validierung bei Objekttyp-Registrierung durch DMS/Mail
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-02 nimmt Objekttyp- und Auslöser-Ereignis-Registrierungen von DMS und Mail entgegen. Analog zu Archive `RET-12` muss jede Registrierung den mitgelieferten Tenant-Kontext unabhängig gegen die Core-Registry (TEN-01) validieren, statt der Angabe des registrierenden Moduls zu vertrauen.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der meldenden Quelle.
+
+**Bewusst vermeiden:**
+- Keycloak – Vertrauen in vom Client mitgelieferte Claims ohne serverseitige Gegenprüfung führte zu Eskalationsfällen.: Workflow verifiziert den Tenant-Kontext jeder eingehenden Registrierung selbst gegen die Core-Registry.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede Objekttyp-/Ereignis-Registrierung aus DMS/Mail wird gegen die Core-Registry auf Tenant-Gültigkeit geprüft, bevor sie übernommen wird
+2. Eine Registrierung mit einem nicht existierenden oder falschem Tenant-Kontext wird abgelehnt und protokolliert
+3. Bestehende, korrekte Registrierungsabläufe aus ENG-02 funktionieren unverändert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: Registrierung mit gültigem, existierendem Tenant-Kontext wird übernommen
+2. Test: Registrierung mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+3. Regressionstest: normaler DMS-/Mail-Registrierungsablauf bleibt funktionsfähig
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Workflow-Board, 2026-09-12), analog zu Archive-Finding `RET-12`: Workflow ist die Senke für Objekttyp-Registrierungen aus zwei anderen Modulen — ohne eigene Validierung würde ein Fehler oder eine Kompromittierung in DMS/Mail unmittelbar durchschlagen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-06: unabh-ngige-tenant-validierung-bei-objekttyp-registrierung-durch-dms-mail`
+- Branch: `feature/eng-06-unabh-ngige-tenant-validierung-bei-objekttyp-registrierung-durch-dms-mail`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-07.md b/workflow-kanban/tickets/ENG-07.md
new file mode 100644
index 00000000..62cfdbfe
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-07.md
@@ -0,0 +1,58 @@
+# ENG-07 – Technische Durchsetzung Append-only für das Instanzschritt-Protokoll
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-04 konzipiert ein vollständiges, unveränderliches Protokoll jedes Instanzschritts, setzt „unveränderlich“ aber nur konventionell um. Analog zu Core `AUD-07` und DMS `VER-08` technisch erzwingen: der Anwendungs-Datenbankrolle werden UPDATE-/DELETE-Rechte auf die Protokolltabelle entzogen (nur INSERT/SELECT), ergänzt um einen Datenbank-Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert.
+
+**Technische Grundlage:** PostgreSQL (REVOKE/Trigger), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- archivdms (positives Muster): sicherheitsrelevante Entscheidungen technisch statt nur konventionell absichern.
+
+**Bewusst vermeiden:**
+- Keycloak – Admin-Events sind konfigurierbar/löschbar.: Unveränderlichkeit ist eine Datenbank-Garantie, keine Anwendungs-Konvention.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-04.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Die vom Workflow-Prozess verwendete Datenbankrolle kann Protokolleinträge nachweislich weder verändern noch löschen
+2. Ein Änderungsversuch wird von der Datenbank abgelehnt und selbst protokolliert
+3. Bestehende ENG-04-Funktionalität (Schreiben/Lesen neuer Einträge) bleibt unverändert nutzbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Testet UPDATE/DELETE gegen die Protokolltabelle mit der Anwendungsrolle, erwartet Rechteverweigerung
+2. Prüft, dass der Ablehnungsversuch selbst sichtbar protokolliert wird
+3. Regressionstest: normales Schreiben/Lesen von Protokolleinträgen funktioniert weiterhin
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Workflow-Board, 2026-09-12), Analogie zu Core-Finding #5/`AUD-07` und DMS `VER-08`: 'unveränderlich' ohne technische Durchsetzung ist nur ein Versprechen des Anwendungscodes.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-04` Workflow-Instanz-Historie & Nachvollziehbarkeit
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-07: technische-durchsetzung-append-only-f-r-das-instanzschritt-protokoll`
+- Branch: `feature/eng-07-technische-durchsetzung-append-only-f-r-das-instanzschritt-protokoll`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-09.md b/workflow-kanban/tickets/ENG-09.md
new file mode 100644
index 00000000..dd745a3f
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-09.md
@@ -0,0 +1,60 @@
+# ENG-09 – Workflow-Trigger nach Upload und Auto-Regel
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell C (eine Datenbank je Mandant, siehe SKALIERUNGSKONZEPT.md Abschnitt 4).
+
+## Auftrag
+paperless-ngx löst Workflows aus Ereignissen aus (z. B. Dokument hinzugefügt, Dokument aktualisiert). Das DMS hat Auto-Regeln (MET-05), aber keinen Weg, aus einem Ereignis eine Aufgabe oder Genehmigung im Workflow-Modul zu erzeugen. Der Modul-Adapter (ENG-02) kennt Trigger als Konzept; ein konkreter Ereigniskanal vom DMS in das Workflow-Modul fehlt.
+
+Einen Ereignisvertrag und die Verarbeitung im Workflow-Modul bauen: Ein Ereignis des DMS (Dokument hochgeladen, Auto-Regel angewendet, Metadatenfeld geändert) erzeugt genau eine Aufgabe oder einen Genehmigungslauf gemäß mandantenweiter Zuordnung.
+
+**Technische Grundlage:** Workflow `ENG-02` (Modul-Adapter, Registrierung von Objekttypen und Triggern), `VOR-04` (Rückkanal), Postgres-Jobqueue, Migration im Workflow-Schema
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Ereignisgesteuerte Automatisierung wie bei paperless-ngx, aber mandantengebunden und nachweisbar.
+
+**Bewusst vermeiden:**
+- Keine Dokumentinhalte im Ereignis: nur IDs, Mandant, Ereignistyp und Zeitpunkt; Inhalte holt das Workflow-Modul bei Bedarf über den Modul-Rückkanal mit Tenant-Kontext.
+- Keine Doppelaufgaben: dasselbe Ereignis erzeugt genau eine Aufgabe (Idempotenz, Zustellung mindestens einmal mit Deduplizierung).
+- Keine Kopplung der Verfügbarkeit: fällt das Workflow-Modul aus, arbeitet das DMS weiter und die Ereignisse werden später zugestellt.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-02, VOR-04.
+Bezug: DMS `MET-05` (Auto-Regeln), DMS `INT-13` (Workflow-Anbindung, noch nicht gebaut), DMS `INT-16` (Tenant-Kontext in Rückkanälen), `VERGLEICHSANALYSE-QUELLSYSTEME.md` (Wurzelverzeichnis), Quelle [P3] (paperless-ngx: Workflows).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Der Ereignisvertrag ist festgelegt (Ereignistypen, minimaler Payload aus IDs, Mandant und Zeitpunkt, Version) und wird über den Modul-Adapter (ENG-02) registriert; das Workflow-Modul nimmt Ereignisse mit Service-Authentifizierung und Tenant-Bindung an
+2. Eine mandantenweite Zuordnung von Ereignis und Bedingung zu Aufgabe oder Genehmigungslauf ist konfigurierbar; dasselbe Ereignis erzeugt genau eine Aufgabe, Wiederholungen werden dedupliziert, Ausfall führt zu späterer Zustellung
+3. Aufgaben entstehen nur für berechtigte Rollen; der Verweis auf das Dokument läuft ausschließlich über den Modul-Rückkanal mit Tenant-Kontext, kein Ereignis aus einem anderen Mandanten wird verarbeitet
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Doppelzustellung desselben Ereignisses ergibt genau eine Aufgabe; Reihenfolge und Wiederholung nach Ausfall sind getestet
+2. Ausfall des Workflow-Moduls: das DMS läuft weiter, Ereignisse werden nach Wiederanlauf ohne Verlust und ohne Dubletten zugestellt
+3. Cross-Tenant negativ: Ereignis mit falschem Mandanten oder fremder Dokument-ID wird abgelehnt und protokolliert
+
+## Nicht Bestandteil dieser Kachel
+- Ein Workflow-Designer oder Regeleditor in der Oberfläche
+- Der DMS-seitige Sender der Ereignisse (DMS `INT-13`)
+- Auswertung von Dokumentinhalten im Workflow-Modul
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-09: workflow-trigger nach upload und auto-regel`
+- Branch: `feature/eng-09-workflow-trigger-nach-upload-und-auto-regel`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/ENG-11.md b/workflow-kanban/tickets/ENG-11.md
new file mode 100644
index 00000000..78834846
--- /dev/null
+++ b/workflow-kanban/tickets/ENG-11.md
@@ -0,0 +1,49 @@
+# ENG-11 – Workflow-App: gebündelter Diensteinstiegspunkt (cmd/workflow-app)
+
+**Epic:** 🔀 Workflow-Engine  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 9
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing).
+
+## Auftrag
+Bei der Vorbereitung des 131-Rollouts wurde real festgestellt: Workflow hat keinen `cmd/`-Diensteinstiegspunkt, der einen Port öffnet — nur Test-Fixtures und CI-Gate-CLIs. Die API-Handler-Pakete (`approvalapi`, `backchannelapi`, `caseoverviewapi`, `routingruleapi`, `taskapi`, `eventtrigger`/`moduleadapter`-HTTP-Server, `escalationnotify`, `routingsuggestapi`-Client-Aufrufer) sind reine Bibliotheken ohne bündelnden Dienst. Verbinde sie zu einem einzigen startbaren `cmd/workflow-app`, analog zu `connect/cmd/connect-app`.
+
+**Technische Grundlage:** `net/http.ServeMux`, `pgxpool`, Umgebungsvariablen für DSN/Listen-Adresse (analog `connect-app`).
+
+## Produkt-DNA für diesen Bereich
+> Ein Dienst pro Modul, alle HTTP-Handler-Pakete darin registriert — kein Diensteinstiegspunkt pro Feature.
+
+## Ausgangslage
+Referenzmuster: `connect/cmd/connect-app/main.go` (DSN aus `NEXARCH_CONNECT_APP_TENANT_DSN`, Listen-Adresse aus `NEXARCH_CONNECT_APP_LISTEN_ADDR`, Kill-Switch-Check aus ENG-10 ganz am Anfang). Alle bereits fertigen Workflow-API-Pakete: `approvalapi`, `backchannelapi`, `caseoverviewapi`, `routingruleapi`, `taskapi`, `moduleadapter` (Event-Empfang aus ENG-09), `escalationnotify`/`notifyclient` (TSK-05), `routingsuggestapi`-Client (WFS-02, Aufrufseite für RTE-05 falls schon vorhanden).
+
+## Akzeptanzkriterien
+1. `cmd/workflow-app` startet einen einzigen HTTP-Dienst, der alle bestehenden Workflow-API-Pakete unter ihren jeweiligen Routen bereitstellt
+2. DSN und Listen-Adresse ausschließlich über Umgebungsvariablen, keine Zugangsdaten im Code
+3. Fehlende Pflicht-Umgebungsvariable führt zu klarer Fehlermeldung beim Start, nicht zu einem stillen Absturz
+4. Dienst startet real auf Host 204 und beantwortet mindestens einen Endpunkt je eingebundenem API-Paket
+
+## Prüfungen vor der Abnahme
+1. Realer Start auf Host 204 mit Wegwerf-DB, mindestens ein Aufruf je eingebundenem API-Paket erfolgreich
+2. Fehlende Pflicht-Umgebungsvariable: Dienst beendet sich mit klarer Fehlermeldung, kein Port offen
+3. Bestehende Modul-Testsuite bleibt unverändert grün (keine Regression durch das neue `cmd/`-Paket)
+
+## Nicht Bestandteil dieser Kachel
+- Neue Fachlogik/Endpunkte (nur Zusammenführung bestehender Pakete)
+- Rollout/Deploy auf Host 131 (separater, späterer Schritt nach Freigabe)
+- Kill-Switch (bereits anderswo, falls für Workflow gewünscht: eigenes Folgeticket analog ENG-10)
+
+## Arbeitsweise
+1. Lies zuerst `connect/cmd/connect-app/main.go` als Referenzmuster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `ENG-11: workflow-app gebuendelter diensteinstiegspunkt`
+- Branch: `feature/eng-11-workflow-app-diensteinstiegspunkt`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/QA-01.md b/workflow-kanban/tickets/QA-01.md
new file mode 100644
index 00000000..3e3329cd
--- /dev/null
+++ b/workflow-kanban/tickets/QA-01.md
@@ -0,0 +1,61 @@
+# QA-01 – Teststrategie Workflow
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Festlegen, was auf welcher Ebene geprüft wird, und einen realistischen Testdatenbestand für Engine, Genehmigungen, Aufgaben und Routing aufbauen.
+
+**Technische Grundlage:** Teststrategie, Testdatenbestand
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.
+- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.
+
+**Für genau diese Kachel:** Die Teststrategie legt fest, was auf welcher Ebene geprüft wird, bevor die erste Prüfung läuft.
+
+## Ausgangslage
+Diese Kachel hat keine Vorbedingungen und ist sofort startbar.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Teststrategie deckt Engine, Genehmigungen, Aufgaben und Routing ab
+2. Testdatenbestand ist realistisch und anonymisiert
+3. Verantwortlichkeit je Testebene ist dokumentiert
+
+4. Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Teststrategie-Dokument gegen alle vier Bereiche geprüft
+2. Testdatenbestand enthält keine echten Personendaten
+3. Zweite Person kann Teststrategie ohne Rückfragen anwenden
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-01: teststrategie workflow`
+- Branch: `feature/qa-01-teststrategie-workflow`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/QA-02.md b/workflow-kanban/tickets/QA-02.md
new file mode 100644
index 00000000..0c815b2c
--- /dev/null
+++ b/workflow-kanban/tickets/QA-02.md
@@ -0,0 +1,65 @@
+# QA-02 – Prüfgate Engine & Adapter
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Prüfgate für Zustandsautomat, Modul-Adapter-Schnittstelle und Fehlerbehandlung.
+
+**Technische Grundlage:** Integrationstests, Zeitraffer
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.
+- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.
+
+**Für genau diese Kachel:** Engine und Adapter sind das Fundament – ein Fehler hier wirkt in jedem späteren Prozess.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-05` Fehlerbehandlung & Retry bei Workflow-Schritten – Wiederholungslogik mit Backoff für fehlgeschlagene Workflow-Schritte, Dead-Letter-Pfad für dauerhaft fehlschlagende Instanzen.
+- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.
+- `ENG-03` Prozessdefinitions-Format (deklarativ, versionierbar) – Lesbares Konfigurationsformat für Prozessdefinitionen: Zustände, Übergänge, Bedingungen, Zuständigkeiten. Jede Definition ist versioniert.
+- `ENG-04` Workflow-Instanz-Historie & Nachvollziehbarkeit – Vollständiges, unveränderliches Protokoll jedes Instanzschritts: Person, Zeitpunkt, Zustand, Begründung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Zustandsübergänge sind mindestens einmal durchlaufen
+2. Adapter-Registrierung ist gegen zwei fiktive Module geprüft
+3. Fehlerbehandlung und Retry sind nachgewiesen
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Unzulässiger Übergang wird in jedem Testlauf abgewiesen
+2. Zwei fiktive Modul-Adapter gleichzeitig registriert und geprüft
+3. Simulierter Fehlerfall löst nachweislich korrekten Retry aus
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme- & Compliance-Prüfung Workflow
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-02: pruefgate engine adapter`
+- Branch: `feature/qa-02-pruefgate-engine-adapter`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/QA-03.md b/workflow-kanban/tickets/QA-03.md
new file mode 100644
index 00000000..2b420c0d
--- /dev/null
+++ b/workflow-kanban/tickets/QA-03.md
@@ -0,0 +1,65 @@
+# QA-03 – Prüfgate Genehmigungen & Aufgaben
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Prüfgate für Vier-Augen-Freigabe, Fristen und Eskalationsregeln.
+
+**Technische Grundlage:** Prozesstests, Zeitraffer
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.
+- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.
+
+**Für genau diese Kachel:** Genehmigungen und Aufgaben sind die sichtbarsten Nutzerpfade – hier zählt Sorgfalt am meisten.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `APR-02` Vier-Augen-Freigabe (generisches Muster) – Generisches Muster für Freigaben, die eine zweite, unabhängige Bestätigung erfordern – modulunabhängig konfigurierbar.
+- `TSK-03` Erinnerungen & Eskalationsregeln – Automatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.
+- `APR-04` Delegation & Vertretungsregeln bei Abwesenheit – Vertretungsregel je Nutzer und Zeitraum, sodass Genehmigungsaufgaben automatisch an eine Vertretung gehen.
+- `TSK-05` Eskalations-Benachrichtigung (ruft Core-Dispatcher) – Eskalation nach Fristablauf löst eine Benachrichtigung aus, indem der Core-Benachrichtigungs-Dispatcher aufgerufen wird – kein eigener Versandweg.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Vier-Augen-Freigabe ist gegen Missbrauchsversuch geprüft
+2. Fristen und Eskalationen lösen korrekt aus
+3. Alle Genehmigungspfade sind mindestens einmal durchlaufen
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Ersteller kann eigene Freigabe im Test nicht zweitbestätigen
+2. Zeitraffer-Test über simulierte Fristen bestanden
+3. Eskalationspfad bis zum Dispatcher-Aufruf nachvollzogen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme- & Compliance-Prüfung Workflow
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-03: pruefgate genehmigungen aufgaben`
+- Branch: `feature/qa-03-pruefgate-genehmigungen-aufgaben`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/QA-04.md b/workflow-kanban/tickets/QA-04.md
new file mode 100644
index 00000000..43f8dd91
--- /dev/null
+++ b/workflow-kanban/tickets/QA-04.md
@@ -0,0 +1,63 @@
+# QA-04 – Prüfgate Routing
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Prüfgate für Routing-Regel-Modell, Ausführung und Simulation.
+
+**Technische Grundlage:** Regeltests, Testkorpus
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.
+- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.
+
+**Für genau diese Kachel:** Fehlrouting ist teuer und schwer zu bemerken – deshalb ein eigenes Gate.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RTE-04` Testlauf/Simulation von Routing-Regeln – Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.
+- `RTE-05` KI-gestützte Routing-Vorschläge (Kopplung AI WFS-02) – Vor einer regelbasierten Routing-Entscheidung optional einen KI-Vorschlag von NEXARCH AI (WFS-02) abrufen und dem Bearbeiter als Empfehlung anzeigen – die regelbasierte Engine bleibt die maßgebliche Entscheidungsinstanz, KI liefert nur einen Vorschlag.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft
+2. Klärungskorb fängt jedes nicht zuordenbare Objekt auf
+3. Simulation weicht nicht von echter Ausführung ab
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Testkorpus mit bekannten Erwartungswerten vollständig durchlaufen
+2. Kein Testobjekt im Klärungskorb verloren
+3. Simulationsergebnis stimmt mit echter Ausführung überein
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme- & Compliance-Prüfung Workflow
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-04: pruefgate routing`
+- Branch: `feature/qa-04-pruefgate-routing`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/QA-05.md b/workflow-kanban/tickets/QA-05.md
new file mode 100644
index 00000000..fc78f812
--- /dev/null
+++ b/workflow-kanban/tickets/QA-05.md
@@ -0,0 +1,66 @@
+# QA-05 – Abnahme- & Compliance-Prüfung Workflow
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Abschließende Abnahmeprüfung über Engine, Genehmigungen, Aufgaben und Routing hinweg, mit abgelegtem Protokoll.
+
+**Technische Grundlage:** Abnahmeprotokoll
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Prozessabläufen, an dem Engine, Genehmigungen, Aufgaben und Routing wiederholbar geprüft werden.
+- Nachgewiesene Zeitraffer-Tests für Fristen und Eskalationen als Freigabevoraussetzung.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur auf dem Entwicklungsrechner mit drei Musterprozessen.
+
+**Für genau diese Kachel:** Die Abnahme bündelt alle Einzelprüfungen zu einer belastbaren Freigabeentscheidung.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `QA-02` Prüfgate Engine & Adapter – Prüfgate für Zustandsautomat, Modul-Adapter-Schnittstelle und Fehlerbehandlung.
+- `QA-03` Prüfgate Genehmigungen & Aufgaben – Prüfgate für Vier-Augen-Freigabe, Fristen und Eskalationsregeln.
+- `QA-04` Prüfgate Routing – Prüfgate für Routing-Regel-Modell, Ausführung und Simulation.
+- `QA-06` Schnittstellen-Vertragstests – Vertragstests für die beiden von DMS/Mail konsumierten Schnittstellen – Push-Registrierung (ENG-02 Modul-Adapter) und Pull-Rückkanal (VOR-04 Rückkanal-API für Akte/Vermerke/Wiedervorlage). Beide Richtungen müssen gegen Breaking Changes abgesichert sein, nicht nur eine.
+- `QA-07` Last- & Leistungstest – Lasttest für Workflow unter realistischer Last aus DMS und Mail gleichzeitig – insbesondere Modul-Adapter-Ereignispfad (ENG-02), Genehmigungs-Engine (APR) und Routing (RTE) unter Last.
+- `QA-08` Barrierefreiheits-Audit – Unabhängige Prüfung aller Workflow-Oberflächen (Genehmigungs-Oberfläche, Aufgaben-Oberfläche, Routing-Regel-Editor, Akten-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Einzelprüfgates sind bestanden und referenziert
+2. Abnahmeprotokoll ist abgelegt und nachlesbar
+3. Offene Punkte sind explizit benannt, nicht stillschweigend übergangen
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Abnahmeprotokoll gegen alle drei Prüfgates abgeglichen
+2. Protokoll enthält Zielwert, Messwert und Bewertung je Kriterium
+3. Zweite Person kann Abnahme anhand des Protokolls nachvollziehen
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-05: abnahme compliance pruefung workflow`
+- Branch: `feature/qa-05-abnahme-compliance-pruefung-workflow`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/QA-06.md b/workflow-kanban/tickets/QA-06.md
new file mode 100644
index 00000000..2deac85e
--- /dev/null
+++ b/workflow-kanban/tickets/QA-06.md
@@ -0,0 +1,62 @@
+# QA-06 – Schnittstellen-Vertragstests
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Vertragstests für die beiden von DMS/Mail konsumierten Schnittstellen – Push-Registrierung (ENG-02 Modul-Adapter) und Pull-Rückkanal (VOR-04 Rückkanal-API für Akte/Vermerke/Wiedervorlage). Beide Richtungen müssen gegen Breaking Changes abgesichert sein, nicht nur eine.
+
+**Technische Grundlage:** Vertragstests (Consumer-Driven Contracts), CI-Pipeline
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Vertragskorpus je Schnittstelle, an dem Kompatibilität wiederholbar geprüft wird.
+- Nachgewiesene Erkennung von Breaking Changes als Freigabevoraussetzung, wie es verbindliche Schnittstellenverträge verlangen.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur auf dem Entwicklungsrechner mit einer Handvoll Beispielaufrufen.
+
+**Für genau diese Kachel:** Zwei Konsumrichtungen, zwei Bruchstellen: Push- und Pull-Schnittstelle müssen einzeln gegen Breaking Changes abgesichert werden, nicht nur die zuletzt geänderte.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.
+- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte – Read-only API, über die ein Modul (DMS/Mail) für eine gegebene Objekt-Referenz (Typ+ID) abfragt: gehört das zu einer Akte, welche Vermerke/offenen Wiedervorlagen gibt es.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Vertragstests decken ENG-02 (Push) und VOR-04 (Pull) beide ab
+2. Absichtlich brechender Schema-Wechsel an jeder der beiden Schnittstellen lässt Tests fehlschlagen
+3. Tests laufen automatisiert in der CI
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Testlauf gegen aktuellen Stand grün
+2. Simulierte Breaking Change an beiden Schnittstellen einzeln erkannt
+3. CI-Integration nachgewiesen
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-06: schnittstellen-vertragstests`
+- Branch: `feature/qa-06-schnittstellen-vertragstests`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/QA-07.md b/workflow-kanban/tickets/QA-07.md
new file mode 100644
index 00000000..8bbf05b6
--- /dev/null
+++ b/workflow-kanban/tickets/QA-07.md
@@ -0,0 +1,61 @@
+# QA-07 – Last- & Leistungstest
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Lasttest für Workflow unter realistischer Last aus DMS und Mail gleichzeitig – insbesondere Modul-Adapter-Ereignispfad (ENG-02), Genehmigungs-Engine (APR) und Routing (RTE) unter Last.
+
+**Technische Grundlage:** Lastgenerator, Messprotokoll
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Nachgewiesene Prüfergebnisse als Freigabevoraussetzung, wie in allen anderen Boards.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+
+**Für genau diese Kachel:** Workflow wird von zwei Modulen gleichzeitig getriggert (DMS und Mail) – ohne Lasttest bleibt unklar, ob Genehmigungs- und Routing-Pfad das verkraften.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.
+- `RTE-04` Testlauf/Simulation von Routing-Regeln – Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Definierte Ziel-Latenz für die Ereigniszustellung (ENG-02) unter Last aus zwei Modulen eingehalten
+2. Genehmigungs-Engine bleibt unter simulierter Mehrfach-Zustellung korrekt (keine doppelten Freigaben, keine verlorenen Anfragen)
+3. Regelbasiertes Routing bleibt unter Last korrekt und deterministisch
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Lasttest mit simulierten parallelen Ereignissen aus DMS und Mail durchgeführt, Ergebnis dokumentiert
+2. Test auf doppelte/verlorene Genehmigungsanfragen unter Last
+3. Routing-Determinismus unter Last geprüft (gleiche Eingabe, gleiches Ergebnis)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine direkt abhängigen Kacheln bekannt)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-07: last leistungstest`
+- Branch: `feature/qa-07-last-leistungstest`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/QA-08.md b/workflow-kanban/tickets/QA-08.md
new file mode 100644
index 00000000..527dfe15
--- /dev/null
+++ b/workflow-kanban/tickets/QA-08.md
@@ -0,0 +1,61 @@
+# QA-08 – Barrierefreiheits-Audit
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** QA  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Workflow (modulübergreifende Genehmigungs-, Aufgaben- und Routing-Engine).
+Unabhängige Prüfung gegen die dokumentierten Akzeptanzkriterien – kein Wiederholen der Entwicklertests.
+
+## Auftrag
+Unabhängige Prüfung aller Workflow-Oberflächen (Genehmigungs-Oberfläche, Aufgaben-Oberfläche, Routing-Regel-Editor, Akten-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.
+
+**Technische Grundlage:** Prüfwerkzeuge, Bildschirmleser
+
+## Produkt-DNA für diesen Bereich
+> Barrierefreiheit ist Grundeigenschaft der Core-SHL-01-Basis, keine Nachrüstung je Modul – dieses Audit prüft, ob Workflow sie tatsächlich geerbt statt umgangen hat.
+
+**Übernehmen:**
+- Core SHL-01: WCAG 2.1 AA als verbindliche Eigenschaft der Basis-Komponenten.
+
+**Bewusst vermeiden:**
+- Kein eigenes, modulspezifisches Barrierefreiheits-Konzept parallel zu SHL-01.
+
+**Für genau diese Kachel:** Ohne dieses Audit bleibt offen, ob Workflow-Oberflächen die von SHL-01 geerbten WCAG-Eigenschaften tatsächlich nutzen oder lokal umgehen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `APR-03` Genehmigungs-Oberfläche – Persönliche Freigabeliste mit Vorschau des betroffenen Objekts, Kommentarfeld und den Aktionen Freigeben, Ablehnen, Zurückgeben.
+- `TSK-04` Aufgaben-Oberfläche – Aufgabenliste mit Fälligkeit, Priorität und Filter, angelehnt an das einfache, schnelle Bedienmodell von Trello/Linear. Zusätzlich eine Kanban-Ansicht (Spalten nach Status, z. B. Offen/In Bearbeitung/Erledigt) — Drag & Drop einer Aufgabe in eine andere Spalte aktualisiert ihren Status über TSK-01.
+- `RTE-03` Routing-Regel-Editor (Oberfläche) – Oberfläche zum Anlegen, Priorisieren und Testen von Routing-Regeln.
+- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche) – Eigenständige Übersicht aller Akten im Workflow-Modul selbst (Liste, Filter nach Status/Verantwortlichem, Detailansicht mit Vermerken/verknüpften Objekten). Für Fälle, in denen man direkt in Workflow arbeitet statt über DMS/Mail einzusteigen. Zusätzlich eine Kanban-Ansicht für Wiedervorlagen mit Drag & Drop zwischen Statusspalten.
+- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System – liefert die WCAG-2.1-AA-Basis-Komponenten, gegen die alle oben genannten Oberflächen geprüft werden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Keine kritischen Verstöße offen
+2. Manueller Bildschirmleser-Durchlauf dokumentiert
+3. Restbefunde sind mit Frist eingeplant
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Automatisierte Prüfung über alle Hauptseiten
+2. Vollständiger Ablauf ohne Maus durchgeführt
+3. Auditbericht abgelegt
+
+## Bekannte Fehler vermeiden
+WCAG war ursprünglich nur in DMS und Mail als eigene Kachel geplant – Workflow hätte ungeprüft geblieben, obwohl die Oberflächen dieselbe Core-SHL-01-Basis nutzen. Audit deshalb als eigene Kachel je Board, analog DMS QA-11 und Mail QA-08.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Core `SHL-01` WCAG-Basis-Komponenten selbst (diese Kachel prüft nur die Nutzung).
+- Behebung gefundener Verstöße in den jeweiligen Frontend-Kacheln.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
diff --git a/workflow-kanban/tickets/RTE-01.md b/workflow-kanban/tickets/RTE-01.md
new file mode 100644
index 00000000..ca922d14
--- /dev/null
+++ b/workflow-kanban/tickets/RTE-01.md
@@ -0,0 +1,64 @@
+# RTE-01 – Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig)
+
+**Epic:** 🔁 Regelbasiertes Routing  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Generisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.
+
+**Technische Grundlage:** Regelwerk-Datenmodell, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.
+
+**Übernehmen:**
+- paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.
+- Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.
+- Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert.
+
+**Bewusst vermeiden:**
+- Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.
+- Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell.
+
+**Für genau diese Kachel:** Ein modulunabhängiges Modell verhindert doppelte Routing-Logik in DMS und Mail.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Regeln sind priorisierbar
+2. Bedingungen sind modulunabhängig formulierbar
+3. Regel ist versionierbar und rückrollbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Regelpriorität im Test korrekt angewendet
+2. Testregel aus fiktivem DMS- und Mail-Adapter beide korrekt abgebildet
+3. Rollback auf Vorgängerversion einer Regel funktioniert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RTE-02` Routing-Engine-Ausführung
+- `RTE-03` Routing-Regel-Editor (Oberfläche)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `RTE-01: routing regel modell bedingungen aktionen modulunabhaengig`
+- Branch: `feature/rte-01-routing-regel-modell-bedingungen-aktionen-modulunabhaengig`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/RTE-02.md b/workflow-kanban/tickets/RTE-02.md
new file mode 100644
index 00000000..600c3bba
--- /dev/null
+++ b/workflow-kanban/tickets/RTE-02.md
@@ -0,0 +1,63 @@
+# RTE-02 – Routing-Engine-Ausführung
+
+**Epic:** 🔁 Regelbasiertes Routing  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Ausführung des Regelwerks gegen eingehende Objekte: erste zutreffende Regel nach Priorität gewinnt, sonst Klärungskorb.
+
+**Technische Grundlage:** Regel-Ausführungs-Engine
+
+## Produkt-DNA für diesen Bereich
+> Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.
+
+**Übernehmen:**
+- paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.
+- Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.
+- Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert.
+
+**Bewusst vermeiden:**
+- Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.
+- Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell.
+
+**Für genau diese Kachel:** Der Klärungskorb verhindert, dass ein Dokument beim Routing verloren geht.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RTE-01` Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig) – Generisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Nicht zuordenbare Objekte landen in einem Klärungskorb
+2. Jede Weiterleitung ist nachvollziehbar protokolliert
+3. Regeländerung wirkt ohne Neustart
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Regelwerk gegen Testkorpus mit erwarteter Zuordnung geprüft
+2. Kein Testobjekt geht bei fehlender Regel verloren
+3. Regeländerung zur Laufzeit ohne Neustart wirksam getestet
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `RTE-04` Testlauf/Simulation von Routing-Regeln
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `RTE-02: routing engine ausfuehrung`
+- Branch: `feature/rte-02-routing-engine-ausfuehrung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/RTE-03.md b/workflow-kanban/tickets/RTE-03.md
new file mode 100644
index 00000000..2ef7e867
--- /dev/null
+++ b/workflow-kanban/tickets/RTE-03.md
@@ -0,0 +1,63 @@
+# RTE-03 – Routing-Regel-Editor (Oberfläche)
+
+**Epic:** 🔁 Regelbasiertes Routing  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
+
+## Auftrag
+Oberfläche zum Anlegen, Priorisieren und Testen von Routing-Regeln.
+
+**Technische Grundlage:** React/Next.js, TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.
+
+**Übernehmen:**
+- paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.
+- Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.
+- Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert.
+
+**Bewusst vermeiden:**
+- Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.
+- Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell.
+
+**Für genau diese Kachel:** Regeln müssen von Fachanwendern pflegbar sein, nicht nur von Entwicklerinnen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RTE-01` Routing-Regel-Modell (Bedingungen/Aktionen, modulunabhängig) – Generisches Regel-Modell mit Bedingungen (Typ, Tag, Metadaten) und Aktionen (Route an Prozess/Person), unabhängig vom aufrufenden Modul.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Regeln sind in der Oberfläche priorisierbar
+2. Regeländerung ist ohne Codeänderung möglich
+3. Regel kann vor Aktivierung getestet werden
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Priorisierung per Drag & Drop im Test funktionsfähig
+2. Testlauf einer Regel vor Aktivierung möglich
+3. Ungültige Bedingungseingabe wird abgewiesen
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `RTE-03: routing regel editor oberflaeche`
+- Branch: `feature/rte-03-routing-regel-editor-oberflaeche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/RTE-04.md b/workflow-kanban/tickets/RTE-04.md
new file mode 100644
index 00000000..6845e607
--- /dev/null
+++ b/workflow-kanban/tickets/RTE-04.md
@@ -0,0 +1,63 @@
+# RTE-04 – Testlauf/Simulation von Routing-Regeln
+
+**Epic:** 🔁 Regelbasiertes Routing  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.
+
+**Technische Grundlage:** Simulationsmodus, Testkorpus
+
+## Produkt-DNA für diesen Bereich
+> Regelbasiertes Routing wie paperless-ngx' Zuordnungsregeln, aber modulunabhängig auf Prozesse statt nur auf Tags angewendet.
+
+**Übernehmen:**
+- paperless-ngx: Regelwerk für automatische Zuordnung, hier auf Objekttyp, Bedingung und Aktion verallgemeinert.
+- Camunda/Zeebe: leichtgewichtige, deklarative Bedingungs-/Aktions-Logik statt vollständiger Business-Rules-Engine.
+- Testlauf/Simulation vor scharfer Anwendung einer Regel – Fehlrouting wird sichtbar, bevor es passiert.
+
+**Bewusst vermeiden:**
+- Kein grafischer Regel-Designer mit Zertifizierungskurs wie bei schwergewichtigen BRE-Produkten.
+- Keine modulspezifische Routing-Logik in DMS oder Mail – ein zentrales, modulunabhängiges Regel-Modell.
+
+**Für genau diese Kachel:** Simulation vor scharfer Anwendung verhindert Fehlrouting im Produktivbetrieb.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RTE-02` Routing-Engine-Ausführung – Ausführung des Regelwerks gegen eingehende Objekte: erste zutreffende Regel nach Priorität gewinnt, sonst Klärungskorb.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Simulation verändert keine echten Daten
+2. Simulationsergebnis zeigt erwartete gegen tatsächliche Zuordnung
+3. Simulation ist gegen beliebigen Testkorpus ausführbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Simulationslauf hinterlässt keine Spuren in Produktivdaten
+2. Abweichung zwischen erwarteter und tatsächlicher Zuordnung wird korrekt gemeldet
+3. Simulation mit leerem Testkorpus bricht nicht ab
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-04` Prüfgate Routing
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `RTE-04: testlauf simulation von routing regeln`
+- Branch: `feature/rte-04-testlauf-simulation-von-routing-regeln`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/RTE-05.md b/workflow-kanban/tickets/RTE-05.md
new file mode 100644
index 00000000..ae435a43
--- /dev/null
+++ b/workflow-kanban/tickets/RTE-05.md
@@ -0,0 +1,63 @@
+# RTE-05 – KI-gestützte Routing-Vorschläge (Kopplung AI WFS-02)
+
+**Epic:** 🔁 Regelbasiertes Routing  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 6
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Vor einer regelbasierten Routing-Entscheidung optional einen KI-Vorschlag von NEXARCH AI (WFS-02) abrufen und dem Bearbeiter als Empfehlung anzeigen – die regelbasierte Engine bleibt die maßgebliche Entscheidungsinstanz, KI liefert nur einen Vorschlag.
+
+**Technische Grundlage:** HTTP-Client gegen AI-Vorschlags-API (WFS-02), Fallback auf regelbasiertes Routing
+
+## Produkt-DNA für diesen Bereich
+> Regeln entscheiden, KI schlägt vor. Der Mensch bleibt in der Verantwortung.
+
+**Übernehmen:**
+- Vorschlagscharakter klar von Entscheidung getrennt – analog zur Vier-Augen-Freigabe bei APR-Kacheln, wo Vorschläge nie automatisch verbindlich werden.
+
+**Bewusst vermeiden:**
+- Keine automatische Übernahme von KI-Vorschlägen als Entscheidung. Das würde Nachvollziehbarkeit und Verantwortlichkeit des Routings untergraben.
+
+**Für genau diese Kachel:** AI WFS-02 liefert die Vorschlags-API, aber ohne diese Kachel hätte niemand im Workflow-Board sie konsumiert – der Vorschlag bliebe ungenutzt.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `RTE-04` Testlauf/Simulation von Routing-Regeln – Simulation eines Regelwerks gegen einen Testkorpus, ohne die Regel scharf zu schalten.
+
+Setzt voraus (externes Board, siehe /home/sysops/Dokumente/Scripte/nexarch/ai-kanban/):
+- `WFS-02` Vorschlags-API (Kopplung Workflow-Board Modul-Adapter) – Schnittstelle, über die das Workflow-Board Vorschläge für Routing-Entscheidungen abruft.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Routing-Ansicht zeigt bei aktiviertem AI-Modul einen KI-Vorschlag zusätzlich zur regelbasierten Entscheidung an
+2. Ist das AI-Modul nicht aktiviert oder nicht erreichbar, funktioniert das regelbasierte Routing unverändert ohne Vorschlag (fail open, kein Blockieren)
+3. Ein KI-Vorschlag wird niemals automatisch übernommen – Bearbeiter muss ihn aktiv bestätigen
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test gegen echte AI-Testinstanz: Vorschlag wird korrekt angezeigt und nachvollziehbar begründet
+2. Test: AI-Endpunkt nicht erreichbar – regelbasiertes Routing läuft unverändert weiter, keine Fehlermeldung im Regelpfad
+3. Test: KI-Vorschlag wird nicht bestätigt – Routing folgt der regelbasierten Entscheidung, nicht dem Vorschlag
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine direkt abhängigen Kacheln bekannt)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `RTE-05: ki gestützte routing vorschläge kopplung ai wfs 02`
+- Branch: `feature/rte-05-ki-gestützte-routing-vorschläge-kopplung-ai-wfs-02`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/SEC-01.md b/workflow-kanban/tickets/SEC-01.md
new file mode 100644
index 00000000..4314f10a
--- /dev/null
+++ b/workflow-kanban/tickets/SEC-01.md
@@ -0,0 +1,57 @@
+# SEC-01 – Echte Authentifizierungsmiddleware vor allen Fach-API-Handlern (Approver-Impersonation über X-User-Id)
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main, 2026-10, Fable 5.1) hat verifiziert: `workflow/internal/approvalapi/handler.go:28-37` (identisch `caseapi/caseapi.go:28-37`, `caseoverviewapi/caseoverviewapi.go:36-44`, `routingruleapi/handler.go:46-55`, `backchannelapi/backchannelapi.go:32-36`) liest den Akteur ungeprüft aus dem rohen `X-User-Id`-Header. `workflow/cmd/workflow-app/main.go:119-123` registriert diese Handler ohne Auth-Middleware davor – nur `moduleadapter` prüft ein Service-Token. `approval.Decide` (`workflow/internal/approval/approval.go:198`) prüft lediglich `task.Assignee == actor`, wobei `actor` direkt aus dem Header stammt.
+
+Angriffsszenario: `GET /approvals` mit beliebigem `X-User-Id` listet die offenen Aufgaben dieses Nutzers; `X-User-Id: ` plus `POST /approvals/{id}/decide {"decision":"approved"}` erteilt eine Freigabe im Namen eines fremden Nutzers – die Historie protokolliert dabei den gefälschten Akteur, nicht den tatsächlichen Angreifer. Derselbe Weg erlaubt das Anlegen/Schließen von Akten, das Umschreiben von Routing-Regeln und das Lesen von Rückkanal-Daten (Vermerke, potenziell Art.-9-Daten).
+
+**Technische Grundlage:** Echte Authentifizierungsmiddleware (analog DMS `moduleauth`-Muster), Go, `net/http.ServeMux`-Middleware-Kette
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- DMS `moduleauth`-Muster: Identität des Akteurs kommt aus einem verifizierten Session-/Modul-Token, nie aus einem rohen Client-Header.
+
+**Bewusst vermeiden:**
+- Kein Vertrauen in clientgesteuerte Header als Identitätsquelle, auch nicht übergangsweise.
+
+## Ausgangslage
+Betrifft bereits fertiggestellte Kacheln: APR-01, APR-02, VOR-01, RTE-01, VOR-04, ENG-11. Die Handler-Pakete existieren und laufen produktiv über `cmd/workflow-app`; es wird keine neue Fachlogik gebaut, sondern eine Middleware vorgeschaltet.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Fach-API-Handler (`approvalapi`, `caseapi`, `caseoverviewapi`, `routingruleapi`, `backchannelapi`) verlangt ein verifiziertes Session- oder Modul-Token, bevor er die Anfrage verarbeitet
+2. Der Akteur (`X-User-Id`-Äquivalent) wird ausschließlich aus dem verifizierten Token abgeleitet, ein roher `X-User-Id`-Header ohne gültiges Token wird ignoriert bzw. die Anfrage abgelehnt
+3. Eine Anfrage ohne gültiges Token oder mit manipuliertem `X-User-Id`-Header bei gültigem Token eines anderen Nutzers wird mit 401/403 abgewiesen, bevor Fachlogik (z. B. `approval.Decide`) erreicht wird
+4. Bestehende, korrekt authentifizierte Abläufe über alle fünf betroffenen Handler-Pakete funktionieren unverändert
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Reproduziere den Angriff vor der Umsetzung: `GET /approvals` und `POST /approvals/{id}/decide` mit beliebigem/fremdem `X-User-Id` ohne gültiges Token – dokumentiere, dass die Freigabe im Namen des fremden Nutzers tatsächlich gelingt
+2. Nach Umsetzung: denselben Angriff gegen alle fünf Handler-Pakete (`approvalapi`, `caseapi`, `caseoverviewapi`, `routingruleapi`, `backchannelapi`) wiederholen und nachweisen, dass er jetzt mit 401/403 blockiert wird, bevor Fachlogik ausgeführt wird
+3. Regressionstest: ein Nutzer mit gültigem Token kann weiterhin eigene Freigaben entscheiden, eigene Akten anlegen/schließen, Routing-Regeln lesen, Rückkanal-Daten für berechtigte Objekte abrufen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SEC-03` Rollenbeschränkung für Routing-Regel-Schreibzugriff und Service-Token-Pflicht im Rückkanal (setzt auf dieser Middleware auf, fügt aber eine zusätzliche Rollenprüfung hinzu)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster (insbesondere DMS `moduleauth`).
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SEC-01: echte-authentifizierungsmiddleware-vor-allen-fach-api-handlern`
+- Branch: `feature/sec-01-echte-authentifizierungsmiddleware-vor-allen-fach-api-handlern`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/SEC-02.md b/workflow-kanban/tickets/SEC-02.md
new file mode 100644
index 00000000..13878914
--- /dev/null
+++ b/workflow-kanban/tickets/SEC-02.md
@@ -0,0 +1,56 @@
+# SEC-02 – Vier-Augen-Prinzip tatsächlich verdrahten und fail-closed statt fail-open
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main, 2026-10, Fable 5.1) hat verifiziert: `grep "dualcheck\."` außerhalb des eigenen Pakets/Tests liefert 0 Treffer – das in APR-02 konzipierte Vier-Augen-Paket `dualcheck` ist nirgends in den tatsächlichen Genehmigungspfad eingebunden. `approval.Create` (`workflow/internal/approval/approval.go:111-135`) prüft nicht, ob `assignee != requestedBy`, sodass eine Selbstfreigabe technisch möglich ist, obwohl APR-02 genau das ausschließen sollte. Zusätzlich liefert `dualcheck.go:51-57` bei jedem Datenbankfehler `false, nil` zurück (fail-open) – bei einer Störung (z. B. kurzer DB-Hänger) reicht dann eine einzige Bestätigung statt zwei, ohne dass dies auffällt.
+
+**Technische Grundlage:** Go, bestehendes `dualcheck`-Paket aus APR-02, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- APR-02: Vier-Augen-Freigabe als generisches, modulunabhängiges Muster – hier tatsächlich in den Ausführungspfad einbinden statt nur als ungenutztes Paket vorzuhalten.
+
+**Bewusst vermeiden:**
+- Kein fail-open bei sicherheitsrelevanten Prüfungen: eine Störung darf eine Kontrolle nie abschwächen, sondern muss sie verschärfen (blockieren statt durchlassen).
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: APR-01, APR-02. Das `dualcheck`-Paket existiert bereits vollständig inklusive eigener Tests, es fehlt ausschließlich die Verdrahtung in `approval.Create`/`approval.Decide` und die Korrektur des Fehlerfalls.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. `approval.Create` bzw. der Genehmigungspfad ruft für als vier-augen-pflichtig konfigurierte Prozesstypen tatsächlich `dualcheck` auf, nicht nur der Testcode
+2. Eine Freigabe, bei der `assignee == requestedBy` (Selbstfreigabe), wird im echten Genehmigungspfad abgelehnt, nicht nur in Unit-Tests des `dualcheck`-Pakets isoliert
+3. `dualcheck.go:51-57` liefert bei einem Datenbankfehler nicht mehr `false, nil`, sondern blockiert die Freigabe (fail-closed) und meldet den Fehler nachvollziehbar
+4. Bestehende APR-01/APR-02-Funktionalität für nicht vier-augen-pflichtige Prozesstypen bleibt unverändert nutzbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Reproduziere vor der Umsetzung: Selbstfreigabe über den echten `approval.Create`/`Decide`-Pfad (nicht über isolierte `dualcheck`-Tests) gelingt, da `dualcheck` nicht eingebunden ist
+2. Simuliere einen Datenbankfehler in `dualcheck` vor der Umsetzung und dokumentiere, dass dies zu `false, nil` (fail-open, einzige Bestätigung reicht) führt
+3. Nach Umsetzung: denselben Selbstfreigabe-Versuch über den echten Pfad wiederholen, erwarte Ablehnung
+4. Nach Umsetzung: denselben simulierten Datenbankfehler wiederholen, erwarte Blockade der Freigabe statt Durchlass
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SEC-01` Authentifizierungsmiddleware (Vorbedingung für eine verlässliche Akteur-Identität, auf der die Vier-Augen-Prüfung aufbaut)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SEC-02: vier-augen-prinzip-tatsaechlich-verdrahten-und-fail-closed`
+- Branch: `feature/sec-02-vier-augen-prinzip-tatsaechlich-verdrahten-und-fail-closed`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/SEC-03.md b/workflow-kanban/tickets/SEC-03.md
new file mode 100644
index 00000000..1dbb4319
--- /dev/null
+++ b/workflow-kanban/tickets/SEC-03.md
@@ -0,0 +1,58 @@
+# SEC-03 – Routing-Regel-Schreibzugriff auf Verantwortliche beschränken, Rückkanal mit Service-Token-Pflicht
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main, 2026-10, Fable 5.1) hat zwei verwandte Lücken verifiziert:
+
+1. `workflow/internal/routingruleapi/handler.go:37-43`: POST/PUT auf Routing-Regeln liegt nur hinter `requireUser` (jeder authentifizierte Nutzer, keine Rollenprüfung), `userID` wird dabei ignoriert, es gibt keine `created_by`-Spalte (`routingrule.go:145-148`). `routingengine.go:45` liest die Regeln live beim Routing – jeder authentifizierte Nutzer kann also beliebige Routing-Regeln umschreiben und damit z. B. Genehmigungen/Akten an sich selbst umleiten lassen, ohne dass nachvollziehbar ist, wer die Regel geändert hat.
+2. `backchannelapi/backchannelapi.go:28`: `GET /objects/{module}/{type}/{id}/context` läuft ohne Prüfung des `X-Service-Token`; `backchannel.go:87-115` prüft nur den eigenen Slug plus `Responsible == X-User-Id`, was wegen SEC-01 ebenfalls aus einem rohen Header stammt.
+
+**Technische Grundlage:** Rollenmodell (Admin-/Routing-Verantwortliche-Rolle), `created_by`-Spalte, Service-Token-Prüfung (analog `moduleadapter`), Go, PostgreSQL-Migration
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- RTE-01 bis RTE-04: Routing bleibt modulunabhängig und regelbasiert konfigurierbar – hier wird nur die Schreibberechtigung verengt, nicht die Funktionalität.
+
+**Bewusst vermeiden:**
+- Keine implizite Annahme, dass „authentifiziert“ gleich „berechtigt, Routing-Regeln zu ändern“ ist.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: RTE-01, RTE-02, VOR-04, SEC-01 (liefert die verifizierte Akteur-Identität, auf der diese Rollenprüfung erst verlässlich aufbauen kann).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. POST/PUT auf Routing-Regeln ist nur für Nutzer mit einer Admin-/Routing-Verantwortliche-Rolle möglich, ein Nutzer ohne diese Rolle wird abgewiesen
+2. Jede angelegte/geänderte Routing-Regel speichert den tatsächlich handelnden Nutzer in einer `created_by`-Spalte (Migration ergänzt)
+3. `GET /objects/{module}/{type}/{id}/context` (Rückkanal) verlangt ein gültiges `X-Service-Token`, eine Anfrage ohne oder mit ungültigem Token wird abgewiesen, bevor die bestehende Slug-/Responsible-Prüfung greift
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Reproduziere vor der Umsetzung: ein gewöhnlicher authentifizierter Nutzer ohne besondere Rolle kann eine Routing-Regel per POST/PUT ändern
+2. Reproduziere vor der Umsetzung: `GET /objects/{module}/{type}/{id}/context` ohne `X-Service-Token` liefert dennoch Rückkanal-Daten
+3. Nach Umsetzung: derselbe gewöhnliche Nutzer wird bei Routing-Regel-Änderung abgewiesen, ein Nutzer mit der neuen Rolle kann weiterhin ändern, und `created_by` ist in der DB nachweisbar gesetzt
+4. Nach Umsetzung: dieselbe Rückkanal-Anfrage ohne gültiges `X-Service-Token` wird abgewiesen, mit gültigem Token und bestehender Slug-/Responsible-Prüfung funktioniert sie weiterhin
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SEC-01` Authentifizierungsmiddleware (Vorbedingung für eine verlässliche Akteur-Identität)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SEC-03: routing-regel-schreibzugriff-beschraenken-rueckkanal-service-token-pflicht`
+- Branch: `feature/sec-03-routing-regel-schreibzugriff-beschraenken-rueckkanal-service-token-pflicht`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/SEC-04.md b/workflow-kanban/tickets/SEC-04.md
new file mode 100644
index 00000000..2697c132
--- /dev/null
+++ b/workflow-kanban/tickets/SEC-04.md
@@ -0,0 +1,55 @@
+# SEC-04 – Tenant-gebundener Dedupe-Key gegen Dedupe-Key-Vergiftung durch abgelehnte Fremd-Tenant-Events
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main, 2026-10, Fable 5.1) hat verifiziert: `workflow/internal/moduleadapter/events.go:64-68` belegt den `dedupe_key` global-unique (Migration `0013:13`, `ON CONFLICT DO NOTHING`) auch dann, wenn das Event wegen falschem Tenant-Kontext abgelehnt wird. Der Handler liefert trotz Ablehnung 202 zurück (`handler.go:167`).
+
+Angriffsszenario: Ein Angreifer kennt oder errät das Dedupe-Key-Schema (z. B. `dms:document::created`) und sendet ein Event mit diesem Key, aber falschem/fremdem Tenant-Kontext. Das Event wird fachlich abgelehnt, belegt aber den global-uniquen Key dauerhaft. Ein später eintreffendes, legitimes Event desselben Keys aus dem korrekten Tenant wird dann durch `ON CONFLICT DO NOTHING` stillschweigend verworfen – die zugehörige Genehmigung/Aufgabe entsteht nie, ohne dass dies auffällt (der ursprüngliche Absender erhielt ja 202).
+
+**Technische Grundlage:** PostgreSQL-Migration (`UNIQUE(tenant_slug, dedupe_key)` statt globalem Unique-Index), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- ENG-09: Dedup bleibt mandantengebunden, wie es die übrige Tenant-Isolation des Moduls vorsieht – ein globaler Unique-Index ist hier ein Implementierungsfehler, keine bewusste Entscheidung.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-02, ENG-09.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. `dedupe_key` ist nur innerhalb eines Tenants eindeutig (`UNIQUE(tenant_slug, dedupe_key)`), nicht global
+2. Ein wegen falschem/fremdem Tenant-Kontext abgelehntes Event belegt den Dedupe-Key nicht dauerhaft (weder global noch für den eigentlichen Tenant)
+3. Ein legitimes Event, dessen Dedupe-Key zuvor von einem abgelehnten Fremd-Tenant-Event „belegt“ wurde, wird nach der Korrektur korrekt verarbeitet und erzeugt die erwartete Aufgabe/Genehmigung
+4. Bestehende Dedup-Funktionalität innerhalb eines Tenants (ENG-09: genau eine Aufgabe je Ereignis) bleibt unverändert korrekt
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Reproduziere vor der Umsetzung: Event mit vorhersagbarem Dedupe-Key und falschem Tenant-Kontext senden (wird abgelehnt), danach dasselbe Event mit korrektem Tenant-Kontext senden – dokumentiere, dass die zugehörige Aufgabe/Genehmigung nicht entsteht
+2. Nach Umsetzung: denselben Ablauf wiederholen – das legitime Event mit korrektem Tenant-Kontext erzeugt jetzt nachweislich die Aufgabe/Genehmigung
+3. Regressionstest: zwei Tenants mit identischem Dedupe-Key-Schema senden jeweils ein legitimes Event – beide werden unabhängig korrekt verarbeitet, kein Cross-Tenant-Konflikt
+4. Regressionstest: doppelte Zustellung desselben legitimen Events innerhalb eines Tenants erzeugt weiterhin genau eine Aufgabe (ENG-09-Verhalten bleibt erhalten)
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-09` Workflow-Trigger nach Upload und Auto-Regel (bleibt fachlich unverändert, nur die Dedup-Eindeutigkeit wird korrigiert)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SEC-04: tenant-gebundener-dedupe-key-gegen-dedupe-key-vergiftung`
+- Branch: `feature/sec-04-tenant-gebundener-dedupe-key-gegen-dedupe-key-vergiftung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/SEC-05.md b/workflow-kanban/tickets/SEC-05.md
new file mode 100644
index 00000000..59018227
--- /dev/null
+++ b/workflow-kanban/tickets/SEC-05.md
@@ -0,0 +1,53 @@
+# SEC-05 – Rohe Datenbankfehler im moduleadapter-Handler normalisieren
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 1 Personentag  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main, 2026-10, Fable 5.1) hat verifiziert: `workflow/internal/moduleadapter/handler.go:67,91,159` ruft `writeError(400, err.Error())` auf und gibt damit rohe pgx-Fehlermeldungen (inklusive Constraint-Namen, Spalten- und Schema-Details) direkt an den aufrufenden Client zurück. Das liefert einem Angreifer Informationen über die interne Datenbankstruktur (Tabellennamen, Constraints, Typen), die für gezieltere Folgeangriffe nutzbar sind.
+
+**Technische Grundlage:** Fehlernormalisierung analog `apierror.Normalize`-Muster aus Core, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Core `apierror.Normalize`-Muster: interne Fehlerdetails nie an den Client, nur eine normalisierte, für den Client verständliche Fehlermeldung.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle drei Fehlerstellen in `moduleadapter/handler.go` (Zeilen 67, 91, 159) geben bei einem Datenbankfehler eine normalisierte Fehlermeldung aus, nicht `err.Error()` roh
+2. Interne Details (Constraint-Namen, Tabellen-/Spaltennamen, SQL-Fragmente) erscheinen in keiner HTTP-Antwort dieser drei Stellen
+3. Der tatsächliche, unveränderte Fehler bleibt serverseitig im Log vollständig erhalten (keine Informationsverlust fürs Debugging, nur fürs Client-Response)
+4. Bestehendes Fehlerverhalten für Clients (korrekter HTTP-Statuscode, erkennbarer Fehlerfall) bleibt erhalten
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Reproduziere vor der Umsetzung: provoziere an allen drei Stellen je einen Datenbankfehler (z. B. Constraint-Verletzung) und dokumentiere die rohe pgx-Fehlermeldung in der HTTP-Antwort
+2. Nach Umsetzung: denselben Fehler an allen drei Stellen erneut provozieren, HTTP-Antwort enthält keine Constraint-/Tabellen-/Spaltennamen mehr
+3. Prüfe serverseitiges Log desselben Fehlerfalls: vollständige Originalfehlermeldung ist dort weiterhin auffindbar
+4. Regressionstest: normale, fehlerfreie Aufrufe von `moduleadapter` funktionieren unverändert
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Fehlernormalisierung an anderen Workflow-API-Paketen außerhalb von `moduleadapter` (nicht Teil dieses Befunds)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster (insbesondere Core `apierror.Normalize`).
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SEC-05: rohe-datenbankfehler-im-moduleadapter-handler-normalisieren`
+- Branch: `feature/sec-05-rohe-datenbankfehler-im-moduleadapter-handler-normalisieren`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/SEC-06.md b/workflow-kanban/tickets/SEC-06.md
new file mode 100644
index 00000000..9c75b562
--- /dev/null
+++ b/workflow-kanban/tickets/SEC-06.md
@@ -0,0 +1,59 @@
+# SEC-06 – Technische Durchsetzung Append-only für verbleibende Workflow-Protokolltabellen
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 10
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-07 hat das Muster „REVOKE UPDATE/DELETE von der App-Rolle + Trigger mit RAISE WARNING“ bereits für `workflow_instance_history` etabliert. Security-Review (main, 2026-10, Fable 5.1) hat verifiziert, dass dieses Muster bei weiteren Workflow-Protokolltabellen fehlt oder unvollständig ist:
+
+- `workflow_instance_history`, `case_notes`: nur Trigger vorhanden, kein REVOKE – die Anwendungsrolle kann Einträge trotz Trigger-Versuch technisch weiterhin per UPDATE/DELETE verändern, sofern der Trigger umgangen oder nicht konsequent ausgelöst wird; ohne REVOKE ist der Schutz unvollständig durchgesetzt.
+- `approval_tasks`, `dualcheck_confirmations`, `routing_decisions`: komplett ungesichert – weder Trigger noch REVOKE. Jede dieser Tabellen protokolliert sicherheitsrelevante Entscheidungen (wer hat was freigegeben/bestätigt/geroutet), die nachträglich unbemerkt veränderbar sind.
+
+**Technische Grundlage:** PostgreSQL (REVOKE/Trigger, inkl. Sequence-GRANT bei BIGSERIAL), Go, analog ENG-07/Core `AUD-07`/DMS `VER-08`
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- ENG-07/archivdms (positives Muster): sicherheitsrelevante Entscheidungen technisch statt nur konventionell absichern – hier konsequent auf alle verbleibenden Protokolltabellen übertragen.
+
+**Bewusst vermeiden:**
+- Kein Trigger ohne REVOKE und kein REVOKE ohne Trigger – beide Bestandteile sind zusammen nötig, ein Teilschutz gilt nicht als erfüllt.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-07 (liefert das Referenzmuster), APR-01, APR-02, RTE-02, VOR-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. `workflow_instance_history` und `case_notes` erhalten zusätzlich zum bestehenden Trigger ein REVOKE UPDATE/DELETE von der Anwendungsrolle
+2. `approval_tasks`, `dualcheck_confirmations`, `routing_decisions` erhalten jeweils REVOKE UPDATE/DELETE von der Anwendungsrolle sowie einen Trigger, der jeden Änderungsversuch ablehnt und selbst protokolliert (RAISE WARNING), inklusive Sequence-GRANT, sofern eine BIGSERIAL-Spalte betroffen ist
+3. Die Anwendungsrolle kann bei keiner der fünf Tabellen Protokolleinträge nachweislich verändern oder löschen
+4. Bestehende Schreib-/Lesefunktionalität (INSERT/SELECT) aller fünf Tabellen bleibt unverändert nutzbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Teste UPDATE/DELETE mit der Anwendungsrolle gegen jede der fünf Tabellen einzeln vor der Umsetzung – dokumentiere, welche davon tatsächlich erfolgreich verändert/gelöscht werden können
+2. Nach Umsetzung: denselben Test gegen alle fünf Tabellen wiederholen, erwarte Rechteverweigerung bei allen fünf
+3. Prüfe, dass der Änderungsversuch bei allen fünf Tabellen selbst sichtbar protokolliert wird (Trigger-Warnung)
+4. Regressionstest: normales Schreiben/Lesen (INSERT/SELECT, inkl. BIGSERIAL-Sequence-Nutzung) funktioniert bei allen fünf Tabellen weiterhin
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-07` Technische Durchsetzung Append-only für das Instanzschritt-Protokoll (liefert das Referenzmuster, bleibt selbst unverändert)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster, insbesondere die ENG-07-Migration als Vorlage.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `SEC-06: technische-durchsetzung-append-only-fuer-verbleibende-protokolltabellen`
+- Branch: `feature/sec-06-technische-durchsetzung-append-only-fuer-verbleibende-protokolltabellen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/TSK-01.md b/workflow-kanban/tickets/TSK-01.md
new file mode 100644
index 00000000..cb23a6ff
--- /dev/null
+++ b/workflow-kanban/tickets/TSK-01.md
@@ -0,0 +1,64 @@
+# TSK-01 – Aufgabenmodell & Zuweisung
+
+**Epic:** ⏱️ Aufgaben, Fristen & Eskalation  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.
+
+**Technische Grundlage:** PostgreSQL, Aufgabenmodell
+
+## Produkt-DNA für diesen Bereich
+> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.
+
+**Übernehmen:**
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.
+- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.
+- Fristen mit Arbeitstagslogik statt naiver Kalendertage.
+
+**Bewusst vermeiden:**
+- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.
+- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.
+
+**Für genau diese Kachel:** Das Aufgabenmodell trägt sowohl Genehmigungen als auch eigenständige Fristen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Workflow-Engine & Zustandsmodell – Zustandsautomat für Workflow-Instanzen: Zustände, Übergänge, Zuständigkeiten. Grundlage für alle weiteren Workflow-Kacheln.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Aufgabe ist Person oder Gruppe zuweisbar
+2. Zuweisung an Gruppe erzeugt genau eine Aufgabe
+3. Aufgabe ist mit beliebigem Modul-Objekt verknüpfbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Zuweisung an Gruppe erzeugt im Test genau eine Aufgabe
+2. Verknüpfung mit Testobjekt aus fiktivem Modul funktioniert
+3. Tenant-Isolation der Aufgabentabellen durch Negativtest belegt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `TSK-02` Fristen & Kalenderlogik
+- `TSK-04` Aufgaben-Oberfläche
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `TSK-01: aufgabenmodell zuweisung`
+- Branch: `feature/tsk-01-aufgabenmodell-zuweisung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/TSK-02.md b/workflow-kanban/tickets/TSK-02.md
new file mode 100644
index 00000000..9ac6d79c
--- /dev/null
+++ b/workflow-kanban/tickets/TSK-02.md
@@ -0,0 +1,64 @@
+# TSK-02 – Fristen & Kalenderlogik
+
+**Epic:** ⏱️ Aufgaben, Fristen & Eskalation  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Fälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.
+
+**Technische Grundlage:** Kalenderlogik, Zeitzonenbehandlung
+
+## Produkt-DNA für diesen Bereich
+> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.
+
+**Übernehmen:**
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.
+- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.
+- Fristen mit Arbeitstagslogik statt naiver Kalendertage.
+
+**Bewusst vermeiden:**
+- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.
+- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.
+
+**Für genau diese Kachel:** Kalendertage erzeugen in der Praxis dauerhaft falsche Fälligkeiten – Arbeitstage sind Pflicht.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TSK-01` Aufgabenmodell & Zuweisung – Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Fälligkeit berücksichtigt Arbeitstage
+2. Wochenenden und Feiertage verschieben die Fälligkeit korrekt
+3. Zeitzonenwechsel verschiebt Fälligkeit nicht fälschlich
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Fristberechnung über Wochenende und Feiertage geprüft
+2. Zeitzonenwechsel-Testfall bestanden
+3. Grenzfall Fälligkeit an einem Feiertag korrekt behandelt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `TSK-03` Erinnerungen & Eskalationsregeln
+- `TSK-04` Aufgaben-Oberfläche
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `TSK-02: fristen kalenderlogik`
+- Branch: `feature/tsk-02-fristen-kalenderlogik`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/TSK-03.md b/workflow-kanban/tickets/TSK-03.md
new file mode 100644
index 00000000..5d2ea5d3
--- /dev/null
+++ b/workflow-kanban/tickets/TSK-03.md
@@ -0,0 +1,64 @@
+# TSK-03 – Erinnerungen & Eskalationsregeln
+
+**Epic:** ⏱️ Aufgaben, Fristen & Eskalation  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Automatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.
+
+**Technische Grundlage:** Postgres-Jobqueue, zeitgesteuerte Jobs
+
+## Produkt-DNA für diesen Bereich
+> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.
+
+**Übernehmen:**
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.
+- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.
+- Fristen mit Arbeitstagslogik statt naiver Kalendertage.
+
+**Bewusst vermeiden:**
+- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.
+- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.
+
+**Für genau diese Kachel:** Eskalation ist ein reines Regelwerk hier, der Versand selbst bleibt beim Core-Dispatcher.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TSK-02` Fristen & Kalenderlogik – Fälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Erinnerungszeitpunkte sind konfigurierbar
+2. Eskalation erfolgt nach definierter Regel bei Fristablauf
+3. Erledigte Aufgabe löst keine Eskalation mehr aus
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Zeitraffer-Test über simulierte Fristen bestanden
+2. Erledigte Aufgabe vor Fristablauf löst nachweislich keine Eskalation aus
+3. Wiederholter Joblauf bleibt idempotent
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `TSK-05` Eskalations-Benachrichtigung (ruft Core-Dispatcher)
+- `QA-03` Prüfgate Genehmigungen & Aufgaben
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `TSK-03: erinnerungen eskalationsregeln`
+- Branch: `feature/tsk-03-erinnerungen-eskalationsregeln`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/TSK-04.md b/workflow-kanban/tickets/TSK-04.md
new file mode 100644
index 00000000..163877d9
--- /dev/null
+++ b/workflow-kanban/tickets/TSK-04.md
@@ -0,0 +1,68 @@
+# TSK-04 – Aufgaben-Oberfläche
+
+**Epic:** ⏱️ Aufgaben, Fristen & Eskalation  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Oberfläche und Zustandsführung. Alle Daten ausschließlich über die öffentliche Schnittstelle beziehen.
+
+## Auftrag
+Aufgabenliste mit Fälligkeit, Priorität und Filter, angelehnt an das einfache, schnelle Bedienmodell von Trello/Linear. Zusätzlich eine Kanban-Ansicht (Spalten nach Status, z. B. Offen/In Bearbeitung/Erledigt) — Drag & Drop einer Aufgabe in eine andere Spalte aktualisiert ihren Status über TSK-01.
+
+**Technische Grundlage:** React/Next.js, TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.
+
+**Übernehmen:**
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.
+- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.
+- Fristen mit Arbeitstagslogik statt naiver Kalendertage.
+
+**Bewusst vermeiden:**
+- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.
+- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.
+
+**Für genau diese Kachel:** Trello/Linear als UI-Vorbild: schnelle Übersicht ohne Schwergewicht.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TSK-01` Aufgabenmodell & Zuweisung – Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.
+- `TSK-02` Fristen & Kalenderlogik – Fälligkeitsberechnung mit Arbeitstagslogik statt naiver Kalendertage, inklusive Wochenenden und Feiertagen.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Überfällige Aufgaben sind klar gekennzeichnet
+2. Liste ist nach Fälligkeit und Priorität filterbar
+3. Ansicht bleibt bei 200 Aufgaben nutzbar
+4. Kanban-Ansicht zeigt Spalten nach Aufgabenstatus, Drag & Drop zwischen Spalten schreibt den neuen Status über TSK-01 zurück
+5. Kanban-Ansicht zeigt ausschließlich Aufgaben des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Filterkombination gegen Testdatensatz geprüft
+2. Überfällig-Kennzeichnung bei Fristüberschreitung im Test korrekt
+3. Performance bei 200 Aufgaben gemessen
+4. Verschieben einer Aufgabe per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über TSK-01
+5. Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Aufgaben des aktuell aktiven Mandanten
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `TSK-04: aufgaben oberflaeche`
+- Branch: `feature/tsk-04-aufgaben-oberflaeche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/TSK-05.md b/workflow-kanban/tickets/TSK-05.md
new file mode 100644
index 00000000..1d6a7af2
--- /dev/null
+++ b/workflow-kanban/tickets/TSK-05.md
@@ -0,0 +1,63 @@
+# TSK-05 – Eskalations-Benachrichtigung (ruft Core-Dispatcher)
+
+**Epic:** ⏱️ Aufgaben, Fristen & Eskalation  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Eskalation nach Fristablauf löst eine Benachrichtigung aus, indem der Core-Benachrichtigungs-Dispatcher aufgerufen wird – kein eigener Versandweg.
+
+**Technische Grundlage:** REST-Aufruf an Core-Dispatcher
+
+## Produkt-DNA für diesen Bereich
+> Aufgaben und Fristen so einfach wie bei Trello/Linear, mit der Eskalationslogik einer echten Prozess-Engine dahinter.
+
+**Übernehmen:**
+- Trello/Linear: einfache, schnelle Aufgaben-Oberfläche – Zuweisung, Fälligkeit, Priorität ohne Schwergewicht.
+- Alfresco: Eskalation und Vertretungsregelung als Bestandteil des Modells, nicht als Sonderfall.
+- Fristen mit Arbeitstagslogik statt naiver Kalendertage.
+
+**Bewusst vermeiden:**
+- Keine Benachrichtigungsflut – Eskalation ruft den Core-Dispatcher (CFG-02) auf, statt einen eigenen Versandweg zu bauen.
+- Kein eigenes Kalender- oder Feiertagssystem je Modul – eine zentrale Kalenderlogik für alle Aufgaben.
+
+**Für genau diese Kachel:** Kein eigenes Benachrichtigungssystem – der Core-Dispatcher (CFG-02) übernimmt Versand und Kanäle.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `TSK-03` Erinnerungen & Eskalationsregeln – Automatische Erinnerung vor Fälligkeit und Eskalationsregel bei Fristablauf, konfigurierbar je Prozesstyp.
+- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `CFG-02` Benachrichtigungs-Dispatcher (Core-Service für Module).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Eskalation ruft den Core-Dispatcher mit korrektem Ereignistyp auf
+2. Fehlschlag des Dispatcher-Aufrufs bricht die Eskalation nicht ab
+3. Keine Doppelbenachrichtigung bei mehrfachem Joblauf
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Testaufruf gegen simulierten Core-Dispatcher erfolgreich
+2. Nichterreichbarkeit des Dispatchers führt zu protokolliertem Fehler statt Absturz
+3. Wiederholter Joblauf erzeugt keinen doppelten Aufruf
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `TSK-05: eskalations benachrichtigung ruft core dispatcher`
+- Branch: `feature/tsk-05-eskalations-benachrichtigung-ruft-core-dispatcher`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/VOR-01.md b/workflow-kanban/tickets/VOR-01.md
new file mode 100644
index 00000000..7cb64728
--- /dev/null
+++ b/workflow-kanban/tickets/VOR-01.md
@@ -0,0 +1,66 @@
+# VOR-01 – Akte/Vorgang-Objektmodell
+
+**Epic:** 📁 Akte & Vorgang  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Vorgang/Akte als eigenständiger Objekttyp – Status (offen/in Bearbeitung/geschlossen), Aktenzeichen, Verantwortlicher, Liste referenzierter Fremdobjekte (Typ + ID + Herkunfts-Board, z. B. „DMS-Dokument #123“ oder „Mail-Nachricht #456“) über den bestehenden Modul-Adapter.
+
+**Technische Grundlage:** PostgreSQL, Modul-Adapter (ENG-02)
+
+## Produkt-DNA für diesen Bereich
+> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.
+
+**Übernehmen:**
+- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.
+- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.
+- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.
+
+**Bewusst vermeiden:**
+- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).
+- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).
+
+**Für genau diese Kachel:** Das Objektmodell ist die Grundvoraussetzung für Vermerke, Wiedervorlage, Rückkanal-API und Akten-Übersicht.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-02` Modul-Adapter-Schnittstelle (DMS/Mail registrieren Objekttypen & Trigger) – Schnittstelle, über die DMS und Mail eigene Objekttypen und Auslöser-Ereignisse bei der Workflow-Engine registrieren, ohne dass die Engine modulspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Akte kann Objekte aus mehreren Modulen gleichzeitig referenzieren, ohne deren Rohdaten zu duplizieren
+2. Statuswechsel ist nachvollziehbar protokolliert
+3. Aktenzeichen ist pro Tenant eindeutig und konfigurierbar (Format)
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Akte mit Referenzen auf ein fiktives DMS-Objekt und ein fiktives Mail-Objekt gleichzeitig angelegt und geprüft
+2. Statuswechsel im Test erzeugt Protokolleintrag mit Person und Zeitpunkt
+3. Zwei Akten desselben Tenants mit identischem Aktenzeichen werden im Test abgewiesen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `VOR-02` Vermerke/Notizen an Akte/Vorgang
+- `VOR-03` Wiedervorlage (Akte/Objekt-Terminverknüpfung)
+- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte
+- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `VOR-01: akte vorgang objektmodell`
+- Branch: `feature/vor-01-akte-vorgang-objektmodell`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/VOR-02.md b/workflow-kanban/tickets/VOR-02.md
new file mode 100644
index 00000000..978b5780
--- /dev/null
+++ b/workflow-kanban/tickets/VOR-02.md
@@ -0,0 +1,65 @@
+# VOR-02 – Vermerke/Notizen an Akte/Vorgang
+
+**Epic:** 📁 Akte & Vorgang  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Freitext-Vermerke an einer Akte, jeweils mit Autor und Zeitstempel, unveränderlich nach dem Speichern (Ergänzung statt Bearbeitung, wie ein Aktenvermerk in der Realität).
+
+**Technische Grundlage:** PostgreSQL, unveränderliche Einträge
+
+## Produkt-DNA für diesen Bereich
+> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.
+
+**Übernehmen:**
+- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.
+- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.
+- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.
+
+**Bewusst vermeiden:**
+- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).
+- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).
+
+**Für genau diese Kachel:** Vermerke sind der klassische Aktenvermerk – unveränderlich, damit die Akte als Nachweis taugt.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `VOR-01` Akte/Vorgang-Objektmodell – Vorgang/Akte als eigenständiger Objekttyp mit Status, Aktenzeichen, Verantwortlichem und referenzierten Fremdobjekten.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Vermerk ist nach dem Speichern nicht mehr veränderbar, nur neue Vermerke ergänzbar
+2. Autor und Zeitstempel sind Pflichtfelder
+3. Vermerke sind chronologisch sortiert abrufbar
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Versuch, einen gespeicherten Vermerk zu ändern, wird im Test abgewiesen
+2. Vermerk ohne Autor oder Zeitstempel wird im Test abgewiesen
+3. Abruf mehrerer Vermerke liefert im Test chronologische Reihenfolge
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `VOR-03` Wiedervorlage (Akte/Objekt-Terminverknüpfung)
+- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte
+- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `VOR-02: vermerke notizen an akte vorgang`
+- Branch: `feature/vor-02-vermerke-notizen-an-akte-vorgang`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/VOR-03.md b/workflow-kanban/tickets/VOR-03.md
new file mode 100644
index 00000000..4affbe4e
--- /dev/null
+++ b/workflow-kanban/tickets/VOR-03.md
@@ -0,0 +1,66 @@
+# VOR-03 – Wiedervorlage (Akte/Objekt-Terminverknüpfung)
+
+**Epic:** 📁 Akte & Vorgang  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Wiedervorlage-Termin an eine Akte oder ein einzelnes referenziertes Objekt (auch ohne vollständige Akte) hängen, nutzt die bestehende TSK-Engine (Aufgabenmodell/Fristen/Erinnerungen) für Fälligkeit und Benachrichtigung.
+
+**Technische Grundlage:** TSK-Engine, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.
+
+**Übernehmen:**
+- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.
+- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.
+- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.
+
+**Bewusst vermeiden:**
+- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).
+- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).
+
+**Für genau diese Kachel:** Die Wiedervorlage bildet die Papierakten-Tradition digital nach, mit TSK als Fristen- und Erinnerungsmotor.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `VOR-01` Akte/Vorgang-Objektmodell – Vorgang/Akte als eigenständiger Objekttyp mit Status, Aktenzeichen, Verantwortlichem und referenzierten Fremdobjekten.
+- `TSK-01` Aufgabenmodell & Zuweisung – Aufgaben mit Zuständigkeit (Person oder Gruppe), Priorität und Bezug zu Dokument oder Workflow-Schritt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Wiedervorlage kann sowohl an eine ganze Akte als auch an ein einzelnes Objekt gehängt werden
+2. Fälliger Termin erzeugt eine Aufgabe über TSK-01/TSK-02
+3. Erledigte Wiedervorlage ist von offener unterscheidbar, keine Löschung der Historie
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Wiedervorlage an Akte und Wiedervorlage an Einzelobjekt im Test jeweils erfolgreich angelegt
+2. Fälliger Termin erzeugt im Test genau eine Aufgabe über die TSK-Engine
+3. Als erledigt markierte Wiedervorlage bleibt im Test in der Historie sichtbar und unterscheidbar von offenen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte
+- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche)
+- `TSK-02` Fristen & Kalenderlogik
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `VOR-03: wiedervorlage akte objekt terminverknuepfung`
+- Branch: `feature/vor-03-wiedervorlage-akte-objekt-terminverknuepfung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/VOR-04.md b/workflow-kanban/tickets/VOR-04.md
new file mode 100644
index 00000000..65ff8385
--- /dev/null
+++ b/workflow-kanban/tickets/VOR-04.md
@@ -0,0 +1,73 @@
+# VOR-04 – Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte
+
+**Epic:** 📁 Akte & Vorgang  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Read-only API, über die ein Modul (DMS/Mail) für eine gegebene Objekt-Referenz (Typ+ID) abfragt: gehört das zu einer Akte, welche Vermerke/offenen Wiedervorlagen gibt es.
+
+**Technische Grundlage:** REST-Schnittstelle, read-only
+
+## Produkt-DNA für diesen Bereich
+> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.
+
+**Übernehmen:**
+- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.
+- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.
+- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.
+
+**Bewusst vermeiden:**
+- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).
+- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).
+
+**Für genau diese Kachel:** Ohne diesen Rückkanal wären Workflow-Daten für die Anwender unsichtbar, da Workflow selbst keine Rohdaten (Dokumentinhalte/Mailinhalte) hält, nur Verweise.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `VOR-01` Akte/Vorgang-Objektmodell – Vorgang/Akte als eigenständiger Objekttyp mit Status, Aktenzeichen, Verantwortlichem und referenzierten Fremdobjekten.
+- `VOR-02` Vermerke/Notizen an Akte/Vorgang – Freitext-Vermerke mit Autor und Zeitstempel, unveränderlich nach dem Speichern.
+- `VOR-03` Wiedervorlage (Akte/Objekt-Terminverknüpfung) – Wiedervorlage-Termin an Akte oder Einzelobjekt, nutzt die TSK-Engine für Fälligkeit und Benachrichtigung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Abfrage nach Objekt-Referenz liefert Akte, Vermerke und offene Wiedervorlagen in einem Aufruf
+2. Antwortzeit ist für den Einsatz in einer Dokument-/Mail-Detailansicht ausreichend kurz (keine spürbare Verzögerung beim Laden)
+3. API respektiert Berechtigungen – nur Vermerke/Akten sichtbar, für die der anfragende Nutzer berechtigt ist
+4. Abfrage ist zwingend tenant-gescoped – Tenant-Filter sitzt in der Query-/Repository-Schicht, nicht als nachgelagerter Filter (siehe SICHERHEITSKONZEPT.md); Objekte anderer Mandanten sind selbst bei geratener/falscher Objekt-Referenz nie sichtbar
+
+## Bekannte Fehler vermeiden
+Ein rein einseitiger Modul-Adapter (nur Registrierung/Push) macht Workflow-Daten für Anwender im Ursprungsmodul unsichtbar – DMS/Mail brauchen einen Lesezugriff, keinen Umweg über eine separate Workflow-Oberfläche, sonst wird die Information faktisch nicht genutzt.
+Tenant-Filter als nachgelagerter Filter statt in der Query selbst war ein realer Fehler in archivmail (siehe known-issues-archivmail.md #7) – bei einer modulübergreifenden Rückkanal-API mit Objekt-Referenzen aus fremden Systemen ist das Risiko einer falsch zusammengesetzten Referenz besonders hoch, deshalb Tenant-Scoping hier ausdrücklich als eigenes Akzeptanzkriterium, nicht nur implizit über "Berechtigungen" mitgemeint.
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Abfrage einer bekannten Objekt-Referenz liefert im Test Akte, Vermerke und offene Wiedervorlagen in einem Aufruf
+2. Antwortzeit im Test unter der für Detailansichten festgelegten Schwelle gemessen
+3. Abfrage mit nicht berechtigtem Nutzer liefert im Test keine fremden Akte-/Vermerkdaten
+4. Abfrage mit Objekt-Referenz eines fremden Mandanten liefert im Test keine Daten, auch wenn die Referenz-ID gültig/erratbar ist
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `VOR-05` Akten-Übersicht (Workflow-eigene Oberfläche)
+- Anzeige-Oberfläche in DMS – siehe externes DMS-Board `DOC-13`
+- Anzeige-Oberfläche in Mail – siehe externes Mail-Board `UX-09`
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `VOR-04: rueckkanal api workflow status vermerke fuer verlinkte objekte`
+- Branch: `feature/vor-04-rueckkanal-api-workflow-status-vermerke-fuer-verlinkte-objekte`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/VOR-05.md b/workflow-kanban/tickets/VOR-05.md
new file mode 100644
index 00000000..b2c184c9
--- /dev/null
+++ b/workflow-kanban/tickets/VOR-05.md
@@ -0,0 +1,71 @@
+# VOR-05 – Akten-Übersicht (Workflow-eigene Oberfläche)
+
+**Epic:** 📁 Akte & Vorgang  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Workflow (zentrales, modulübergreifendes Modul für Genehmigungsprozesse, Aufgaben/Fristen und regelbasiertes Routing), das DMS und Mail über eine Modul-Adapter-Schnittstelle nutzen, statt jeweils eigene Workflow-Logik zu bauen.
+Techstack: Go-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.
+Oberfläche greift ausschließlich über bestehende Schnittstellen zu. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Eigenständige Übersicht aller Akten im Workflow-Modul selbst (Liste, Filter nach Status/Verantwortlichem, Detailansicht mit Vermerken/verknüpften Objekten). Zusätzlich eine Kanban-Ansicht speziell für Wiedervorlagen (Spalten nach Fälligkeit/Status, z. B. Offen/Diese Woche/Überfällig/Erledigt) — Drag & Drop einer Wiedervorlage in eine andere Spalte aktualisiert ihren Status über VOR-03. Für Fälle, in denen man direkt in Workflow arbeitet statt über DMS/Mail einzusteigen.
+
+**Technische Grundlage:** Next.js/React/TypeScript
+
+## Produkt-DNA für diesen Bereich
+> Alfresco-Aktenkonzept mit Statuslogik, ecoDMS-Wiedervorlage aus der Papierakten-Tradition digital nachgebildet – gebündelt in einem Vorgang, der Objekte aus mehreren Modulen referenziert statt sie zu duplizieren.
+
+**Übernehmen:**
+- Alfresco: Akten-/Vorgangskonzept mit klarer Statuslogik (offen/in Bearbeitung/geschlossen) statt loser Dokumentsammlung.
+- ecoDMS: klassische Wiedervorlage-Funktion aus der Papierakten-Tradition, digital nachgebildet – Termin, Fälligkeit, Erledigt-Markierung.
+- Modulübergreifende Bündelung über Referenzen (ENG-02), nicht über Duplizierung von Rohdaten aus DMS oder Mail.
+
+**Bewusst vermeiden:**
+- Kein zweites, konkurrierendes Aktenmodell parallel in DMS – die Akte lebt ausschließlich hier in Workflow, DMS und Mail zeigen sie nur an (siehe DOC-13, UX-09).
+- Kein Duplizieren von Dokumentinhalten oder Mailinhalten in Workflow – nur Verweise über den Modul-Adapter (ENG-02).
+
+**Für genau diese Kachel:** Die eigene Oberfläche ergänzt den Rückkanal (VOR-04) für den Fall, dass direkt in Workflow gearbeitet wird.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `VOR-01` Akte/Vorgang-Objektmodell – Vorgang/Akte als eigenständiger Objekttyp mit Status, Aktenzeichen, Verantwortlichem und referenzierten Fremdobjekten.
+- `VOR-02` Vermerke/Notizen an Akte/Vorgang – Freitext-Vermerke mit Autor und Zeitstempel, unveränderlich nach dem Speichern.
+- `VOR-03` Wiedervorlage (Akte/Objekt-Terminverknüpfung) – Wiedervorlage-Termin an Akte oder Einzelobjekt, nutzt die TSK-Engine für Fälligkeit und Benachrichtigung.
+- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Liste aller Akten ist nach Status und Verantwortlichem filterbar
+2. Detailansicht zeigt Vermerke, Wiedervorlagen und verknüpfte Objekte einer Akte vollständig an
+3. Übersicht funktioniert unabhängig davon, ob der Zugriff über DMS/Mail oder direkt in Workflow erfolgt
+4. Kanban-Ansicht für Wiedervorlagen zeigt Spalten nach Fälligkeit/Status, Drag & Drop zwischen Spalten schreibt den neuen Status über VOR-03 zurück
+5. Kanban-Ansicht zeigt ausschließlich Wiedervorlagen des aktuellen Mandanten – Tenant-Filter läuft serverseitig, nicht nur clientseitig ausgeblendet
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Filter nach Status und Verantwortlichem liefert im Test korrekte Teilmengen
+2. Detailansicht einer Testakte zeigt im Test Vermerke, Wiedervorlagen und verknüpfte Objekte vollständig
+3. Akte mit Referenzen aus mehreren Modulen wird im Test korrekt dargestellt
+4. Verschieben einer Wiedervorlage per Drag & Drop in der Kanban-Ansicht ändert im Test nachweislich den Status über VOR-03
+5. Kanban-Ansicht mit Testdaten aus zwei Mandanten zeigt im Test nur die Wiedervorlagen des aktuell aktiven Mandanten
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Anzeige-Oberfläche in DMS – siehe externes DMS-Board `DOC-13`
+- Anzeige-Oberfläche in Mail – siehe externes Mail-Board `UX-09`
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `VOR-05: akten uebersicht workflow eigene oberflaeche`
+- Branch: `feature/vor-05-akten-uebersicht-workflow-eigene-oberflaeche`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/workflow-kanban/tickets/VOR-06.md b/workflow-kanban/tickets/VOR-06.md
new file mode 100644
index 00000000..7cc133d3
--- /dev/null
+++ b/workflow-kanban/tickets/VOR-06.md
@@ -0,0 +1,58 @@
+# VOR-06 – Tenant-Kontext-Validierung im Rückkanal (DMS/Mail-Abfrage)
+
+**Epic:** 📁 Akte & Vorgang  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Workflow (Workflow-Engine, Genehmigungen & Freigaben, Aufgaben/Fristen & Eskalation, regelbasiertes Routing, Akte & Vorgang), das sich an Alfresco (Prozess-Engine), Camunda/Zeebe (Konzept) und Trello/Linear (Aufgaben-UI) orientiert.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+VOR-04 ist eine Read-only-API, über die DMS/Mail für eine Objekt-Referenz abfragen, ob sie zu einer Akte gehört, inklusive Vermerken und Wiedervorlagen. Ohne eigene Validierung würde Workflow dem vom aufrufenden Modul übergebenen Tenant-Kontext blind vertrauen und könnte dadurch Akte-Daten eines fremden Mandanten herausgeben, obwohl Workflow selbst korrekt mandantengetrennt ist. VOR-04 validiert den mitgelieferten Nutzer-Tenant-Kontext unabhängig gegen die Core-Registry und gegen den Tenant der angefragten Akte, bevor Vermerke/Wiedervorlagen zurückgegeben werden.
+
+**Technische Grundlage:** Service-Credentials (Core API-02), Tenant-Registry-Abgleich (Core TEN-01), Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Casbin: Autorisierungsentscheidung bleibt zentral und unabhängig von der anfragenden Quelle.
+
+**Bewusst vermeiden:**
+- Keycloak – Vertrauen in vom Client mitgelieferte Claims ohne serverseitige Gegenprüfung führte zu Eskalationsfällen.: Workflow verifiziert den Tenant-Kontext jeder VOR-04-Anfrage selbst, statt der Angabe des anfragenden Moduls zu vertrauen.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: VOR-04.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede VOR-04-Anfrage trägt den Tenant-Kontext des ursprünglich anfragenden Nutzers als Pflichtparameter
+2. Workflow validiert, dass der übergebene Tenant-Kontext zum Tenant der angefragten Akte passt, unabhängig vom Service-Credential-Scope des aufrufenden Moduls
+3. Eine Anfrage mit falschem/fremdem Tenant-Kontext wird abgelehnt und protokolliert, statt Daten preiszugeben
+
+## Prüfungen vor der Abnahme
+Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
+1. Test: VOR-04-Anfrage mit korrektem Nutzer-Tenant-Kontext liefert erwartete Akte-Daten
+2. Test: VOR-04-Anfrage mit manipuliertem/fremdem Tenant-Kontext wird abgelehnt
+3. Integrationstest über DMS DOC-13 → VOR-04 mit zwei verschiedenen Tenants, prüft Isolation
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Workflow-Board, 2026-09-12), analog zu DMS-Finding `INT-16`/Mail-Finding `INT-11`: physische Tenant-Trennung (Core Modell C) schützt nur innerhalb eines Moduls — ein Rückkanal ohne eigene Tenant-Validierung kann diese Isolation modulübergreifend aufweichen.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `VOR-04` Rückkanal-API: Workflow-Status & Vermerke für verlinkte Objekte
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `VOR-06: tenant-kontext-validierung-im-r-ckkanal-dms-mail-abfrage`
+- Branch: `feature/vor-06-tenant-kontext-validierung-im-r-ckkanal-dms-mail-abfrage`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.