50 changed files with 4981 additions and 0 deletions
@@ -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; }
@@ -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 = '<span>' + col + '</span><span class="count">' + items.length + '</span>';
+      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 = '<div class="code">' + t.code + ' · ' + t.estimateDays + ' PT</div>' +
+      '<div class="title">' + esc(t.title) + '</div>' +
+      '<span class="tag wave">Welle ' + t.wave + '</span>' +
+      '<span class="tag">' + t.role + '</span>' +
+      '<span class="tag">' + t.complexity + '</span>' +
+      (blocked ? '<span class="tag blocked">wartet auf ' + t.dependsOn.filter(function (c) { return !isDone(c); }).join(', ') + '</span>' : '<span class="tag ready">startbar</span>');
+    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 { '&': '&amp;', '<': '&lt;', '>': '&gt;' }[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 =
+      '<span><b>' + DATA.tickets.length + '</b> Kacheln</span>' +
+      '<span>sichtbar: <b>' + list.length + '</b></span>' +
+      '<span>fertig: <b>' + done.length + '</b> (' + donePT + ' von ' + DATA.totalDays + ' PT)</span>' +
+      '<span>jetzt startbar: <b>' + readyNow + '</b></span>' +
+      '<span>Wellen: <b>' + maxWave + '</b></span>';
+  }
+
+  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 =
+      '<span class="tag wave">Welle ' + t.wave + '</span><span class="tag">' + t.role + '</span><span class="tag">' + t.complexity + '</span><span class="tag">' + t.estimateDays + ' PT</span><span class="tag">' + statusOf(t) + '</span>';
+    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 '<span class="chip">' + c + (byCode[c] ? ' – ' + esc(byCode[c].title) : '') + '</span>'; }).join('') : '<span class="empty" style="padding:0">keine</span>';
+  }
+  function items(id, arr) {
+    document.getElementById(id).innerHTML = (arr || []).map(function (a) { return '<li>' + esc(a) + '</li>'; }).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();
+})();
@@ -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.
+
+---
@@ -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).
@@ -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"
@@ -0,0 +1,50 @@
+<!DOCTYPE html>
+<html lang="de">
+<head>
+<meta charset="utf-8" />
+<meta name="viewport" content="width=device-width, initial-scale=1" />
+<title>Workflow Kanban – lokal</title>
+<link rel="stylesheet" href="../_shared/kanban.css">
+</head>
+<body>
+<header>
+  <div class="row">
+    <h1>Workflow Kanban <span class="sub">– lokal, offline, ohne Server</span></h1>
+    <input id="q" placeholder="Suche: Code, Titel, Technik …" style="min-width:220px" />
+    <select id="fEpic"><option value="">Alle Epics</option></select>
+    <select id="fRole"><option value="">Alle Rollen</option></select>
+    <select id="fWave"><option value="">Alle Wellen</option></select>
+    <button id="onlyReady">Nur startbare</button>
+    <button id="exportBtn">Stand sichern</button>
+    <button id="resetBtn">Zurücksetzen</button>
+  </div>
+  <div class="stats" id="stats"></div>
+</header>
+<div class="board" id="board"></div>
+
+<dialog id="dlg">
+  <div class="dlg-head">
+    <div>
+      <div class="code" id="dCode" style="font-family:ui-monospace,Menlo,monospace;font-size:11px;color:var(--muted)"></div>
+      <div id="dTitle" style="font-size:18px;font-weight:600;margin-top:4px"></div>
+      <div id="dMeta" style="margin-top:8px"></div>
+    </div>
+    <div class="row">
+      <button class="primary" id="copyBtn">Prompt kopieren</button>
+      <button id="closeBtn">Schließen</button>
+    </div>
+  </div>
+  <div class="dlg-body">
+    <p id="dDesc" style="font-size:13px;color:#C7D3E5;line-height:1.6;margin-top:0"></p>
+    <h3>Baut auf</h3><div id="dDeps"></div>
+    <h3>Schaltet frei</h3><div id="dNext"></div>
+    <h3>Akzeptanzkriterien</h3><ul id="dAcc"></ul>
+    <h3>Prüfungen vor der Abnahme</h3><ul id="dChk"></ul>
+    <h3>Bau-Prompt</h3><pre id="dPrompt"></pre>
+  </div>
+</dialog>
+
+<script id="data" type="application/json">{"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."}], "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": ["KeineLine truncated
+<script src="../_shared/kanban.js"></script>
+</body>
+</html>
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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: <assignee>` 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.
@@ -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.
@@ -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.
@@ -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:<id>: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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.
@@ -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.