From 5dfd19ae9fafe40b4a6750c3d19a61933f5061c6 Mon Sep 17 00:00:00 2001 From: patrick Date: Fri, 6 Nov 2026 23:12:20 +0100 Subject: [PATCH] connect-kanban: Board in main uebernehmen Stand von chore/ai-kanban-security-folgetickets. Die Historie dieses Branches hat keinen gemeinsamen Vorfahren mit main, daher als Snapshot. _shared enthaelt CSS/JS der Kanban-Ansicht (identisch in allen Board-Branches). Co-Authored-By: Claude Sonnet 5.5 --- _shared/kanban.css | 40 + _shared/kanban.js | 152 +++ connect-kanban/DEVLOG.md | 13 + connect-kanban/README.md | 93 ++ connect-kanban/board.csv | 203 ++++ connect-kanban/board.json | 1502 +++++++++++++++++++++++++++++ connect-kanban/kanban.html | 50 + connect-kanban/tickets/API-01.md | 64 ++ connect-kanban/tickets/API-02.md | 63 ++ connect-kanban/tickets/API-03.md | 63 ++ connect-kanban/tickets/DAT-01.md | 65 ++ connect-kanban/tickets/DAT-02.md | 62 ++ connect-kanban/tickets/DAT-03.md | 64 ++ connect-kanban/tickets/DMS2-01.md | 62 ++ connect-kanban/tickets/DMS2-02.md | 65 ++ connect-kanban/tickets/DMS2-03.md | 62 ++ connect-kanban/tickets/ENG-01.md | 69 ++ connect-kanban/tickets/ENG-02.md | 66 ++ connect-kanban/tickets/ENG-03.md | 64 ++ connect-kanban/tickets/ENG-04.md | 63 ++ connect-kanban/tickets/ENG-05.md | 63 ++ connect-kanban/tickets/ENG-06.md | 64 ++ connect-kanban/tickets/ENG-07.md | 58 ++ connect-kanban/tickets/ENG-08.md | 59 ++ connect-kanban/tickets/ENG-10.md | 51 + connect-kanban/tickets/ERP-01.md | 63 ++ connect-kanban/tickets/ERP-02.md | 62 ++ connect-kanban/tickets/ERP-03.md | 63 ++ connect-kanban/tickets/ERP-04.md | 62 ++ connect-kanban/tickets/M365-01.md | 63 ++ connect-kanban/tickets/M365-02.md | 62 ++ connect-kanban/tickets/M365-03.md | 62 ++ connect-kanban/tickets/QA-01.md | 63 ++ connect-kanban/tickets/QA-02.md | 66 ++ connect-kanban/tickets/QA-03.md | 71 ++ connect-kanban/tickets/QA-04.md | 62 ++ connect-kanban/tickets/QA-05.md | 67 ++ connect-kanban/tickets/QA-06.md | 61 ++ connect-kanban/tickets/QA-07.md | 60 ++ connect-kanban/tickets/QA-08.md | 61 ++ connect-kanban/tickets/SEC-01.md | 68 ++ connect-kanban/tickets/SEC-02.md | 62 ++ connect-kanban/tickets/SEC-03.md | 64 ++ connect-kanban/tickets/SEC-04.md | 61 ++ connect-kanban/tickets/SEC-05.md | 62 ++ 45 files changed, 4445 insertions(+) create mode 100644 _shared/kanban.css create mode 100644 _shared/kanban.js create mode 100644 connect-kanban/DEVLOG.md create mode 100644 connect-kanban/README.md create mode 100644 connect-kanban/board.csv create mode 100644 connect-kanban/board.json create mode 100644 connect-kanban/kanban.html create mode 100644 connect-kanban/tickets/API-01.md create mode 100644 connect-kanban/tickets/API-02.md create mode 100644 connect-kanban/tickets/API-03.md create mode 100644 connect-kanban/tickets/DAT-01.md create mode 100644 connect-kanban/tickets/DAT-02.md create mode 100644 connect-kanban/tickets/DAT-03.md create mode 100644 connect-kanban/tickets/DMS2-01.md create mode 100644 connect-kanban/tickets/DMS2-02.md create mode 100644 connect-kanban/tickets/DMS2-03.md create mode 100644 connect-kanban/tickets/ENG-01.md create mode 100644 connect-kanban/tickets/ENG-02.md create mode 100644 connect-kanban/tickets/ENG-03.md create mode 100644 connect-kanban/tickets/ENG-04.md create mode 100644 connect-kanban/tickets/ENG-05.md create mode 100644 connect-kanban/tickets/ENG-06.md create mode 100644 connect-kanban/tickets/ENG-07.md create mode 100644 connect-kanban/tickets/ENG-08.md create mode 100644 connect-kanban/tickets/ENG-10.md create mode 100644 connect-kanban/tickets/ERP-01.md create mode 100644 connect-kanban/tickets/ERP-02.md create mode 100644 connect-kanban/tickets/ERP-03.md create mode 100644 connect-kanban/tickets/ERP-04.md create mode 100644 connect-kanban/tickets/M365-01.md create mode 100644 connect-kanban/tickets/M365-02.md create mode 100644 connect-kanban/tickets/M365-03.md create mode 100644 connect-kanban/tickets/QA-01.md create mode 100644 connect-kanban/tickets/QA-02.md create mode 100644 connect-kanban/tickets/QA-03.md create mode 100644 connect-kanban/tickets/QA-04.md create mode 100644 connect-kanban/tickets/QA-05.md create mode 100644 connect-kanban/tickets/QA-06.md create mode 100644 connect-kanban/tickets/QA-07.md create mode 100644 connect-kanban/tickets/QA-08.md create mode 100644 connect-kanban/tickets/SEC-01.md create mode 100644 connect-kanban/tickets/SEC-02.md create mode 100644 connect-kanban/tickets/SEC-03.md create mode 100644 connect-kanban/tickets/SEC-04.md create mode 100644 connect-kanban/tickets/SEC-05.md diff --git a/_shared/kanban.css b/_shared/kanban.css new file mode 100644 index 00000000..82ee3beb --- /dev/null +++ b/_shared/kanban.css @@ -0,0 +1,40 @@ +:root { + --bg: #0B0F17; --card: #131A26; --card2: #18212F; --border: #253044; + --fg: #E6EDF7; --muted: #93A1B8; --primary: #3B82F6; + } + * { box-sizing: border-box; } + body { margin: 0; background: var(--bg); color: var(--fg); font-family: ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; } + header { position: sticky; top: 0; z-index: 20; background: rgba(11,15,23,.92); backdrop-filter: blur(8px); border-bottom: 1px solid var(--border); padding: 14px 20px; } + .row { display: flex; gap: 10px; align-items: center; flex-wrap: wrap; } + h1 { font-size: 17px; margin: 0 14px 0 0; letter-spacing: -.01em; } + .sub { color: var(--muted); font-size: 12px; } + input, select, button { background: var(--card2); color: var(--fg); border: 1px solid var(--border); border-radius: 8px; padding: 7px 10px; font-size: 12px; font-family: inherit; } + input:focus, select:focus { outline: 1px solid var(--primary); } + button { cursor: pointer; } + button:hover { border-color: var(--primary); } + button.primary { background: rgba(59,130,246,.14); color: #93BBFB; border-color: rgba(59,130,246,.3); } + .stats { display: flex; gap: 14px; font-size: 11px; color: var(--muted); margin-top: 8px; flex-wrap: wrap; } + .stats b { color: var(--fg); } + .board { display: grid; grid-template-columns: repeat(5, minmax(240px, 1fr)); gap: 12px; padding: 16px 20px 40px; align-items: start; overflow-x: auto; } + .col { background: var(--card); border: 1px solid var(--border); border-radius: 12px; min-height: 160px; padding: 10px; } + .col.over { border-color: var(--primary); background: #16203042; } + .col h2 { font-size: 12px; margin: 2px 4px 10px; display: flex; justify-content: space-between; align-items: center; text-transform: uppercase; letter-spacing: .06em; color: var(--muted); } + .count { background: var(--card2); border: 1px solid var(--border); border-radius: 999px; padding: 1px 7px; font-size: 10px; color: var(--fg); } + .card { background: var(--card2); border: 1px solid var(--border); border-radius: 10px; padding: 10px; margin-bottom: 8px; cursor: grab; } + .card:hover { border-color: #3a4a66; } + .card.dragging { opacity: .45; } + .card .code { font-family: ui-monospace, SFMono-Regular, Menlo, monospace; font-size: 10px; color: var(--muted); } + .card .title { font-size: 13px; margin: 4px 0 7px; line-height: 1.35; } + .tag { display: inline-block; font-size: 10px; padding: 2px 7px; border-radius: 999px; background: #202b3d; color: var(--muted); margin-right: 4px; margin-top: 3px; } + .tag.blocked { background: rgba(245,158,11,.15); color: #FBBF24; } + .tag.ready { background: rgba(34,197,94,.15); color: #4ADE80; } + .tag.wave { background: rgba(59,130,246,.14); color: #93BBFB; } + dialog { background: var(--card); color: var(--fg); border: 1px solid var(--border); border-radius: 14px; max-width: 860px; width: 94%; padding: 0; } + dialog::backdrop { background: rgba(0,0,0,.72); } + .dlg-head { padding: 18px 20px; border-bottom: 1px solid var(--border); display: flex; justify-content: space-between; gap: 12px; align-items: flex-start; } + .dlg-body { padding: 18px 20px 24px; max-height: 66vh; overflow: auto; } + pre { background: #0E1420; border: 1px solid var(--border); border-radius: 10px; padding: 14px; font-size: 11px; line-height: 1.6; white-space: pre-wrap; word-break: break-word; color: #C7D3E5; font-family: ui-monospace, SFMono-Regular, Menlo, monospace; } + h3 { font-size: 12px; text-transform: uppercase; letter-spacing: .06em; color: var(--muted); margin: 18px 0 8px; } + ul { margin: 0; padding-left: 18px; font-size: 13px; color: #C7D3E5; line-height: 1.6; } + .chip { font-family: ui-monospace, Menlo, monospace; font-size: 11px; border: 1px solid var(--border); border-radius: 6px; padding: 2px 6px; margin: 0 4px 4px 0; display: inline-block; color: var(--muted); } + .empty { color: #55627a; font-size: 11px; text-align: center; padding: 14px 0; } diff --git a/_shared/kanban.js b/_shared/kanban.js new file mode 100644 index 00000000..33fe51ac --- /dev/null +++ b/_shared/kanban.js @@ -0,0 +1,152 @@ +(function () { + var DATA = JSON.parse(document.getElementById('data').textContent); + var COLUMNS = ['Backlog', 'Bereit', 'In Arbeit', 'Prüfung', 'Fertig']; + var KEY = 'kanban-status-v1:' + location.pathname; + var state = {}; + try { state = JSON.parse(localStorage.getItem(KEY) || '{}') || {}; } catch (e) { state = {}; } + var onlyReady = false; + + function statusOf(t) { return state[t.code] || t.status || 'Backlog'; } + function isDone(code) { return statusOf(byCode[code] || { code: code }) === 'Fertig'; } + var byCode = {}; + DATA.tickets.forEach(function (t) { byCode[t.code] = t; }); + + function ready(t) { return (t.dependsOn || []).every(function (d) { return isDone(d); }); } + + function save() { localStorage.setItem(KEY, JSON.stringify(state)); } + + // Filter befüllen + var fEpic = document.getElementById('fEpic'), fRole = document.getElementById('fRole'), fWave = document.getElementById('fWave'); + DATA.epics.forEach(function (e) { var o = document.createElement('option'); o.value = e.key; o.textContent = e.emoji + ' ' + e.name; fEpic.appendChild(o); }); + Array.from(new Set(DATA.tickets.map(function (t) { return t.role; }))).sort().forEach(function (r) { var o = document.createElement('option'); o.value = r; o.textContent = r; fRole.appendChild(o); }); + var maxWave = Math.max.apply(null, DATA.tickets.map(function (t) { return t.wave; })); + for (var w = 1; w <= maxWave; w++) { var o = document.createElement('option'); o.value = String(w); o.textContent = 'Welle ' + w; fWave.appendChild(o); } + + function visible() { + var q = document.getElementById('q').value.trim().toLowerCase(); + return DATA.tickets.filter(function (t) { + if (fEpic.value && t.epic !== fEpic.value) return false; + if (fRole.value && t.role !== fRole.value) return false; + if (fWave.value && String(t.wave) !== fWave.value) return false; + if (onlyReady && (!ready(t) || statusOf(t) === 'Fertig')) return false; + if (q) { + var hay = (t.code + ' ' + t.title + ' ' + t.tech + ' ' + t.description).toLowerCase(); + if (hay.indexOf(q) === -1) return false; + } + return true; + }); + } + + function render() { + var board = document.getElementById('board'); + board.innerHTML = ''; + var list = visible(); + COLUMNS.forEach(function (col) { + var el = document.createElement('div'); + el.className = 'col'; + el.dataset.col = col; + var items = list.filter(function (t) { return statusOf(t) === col; }); + var h = document.createElement('h2'); + h.innerHTML = '' + col + '' + items.length + ''; + el.appendChild(h); + if (!items.length) { var e = document.createElement('div'); e.className = 'empty'; e.textContent = '– leer –'; el.appendChild(e); } + items.forEach(function (t) { el.appendChild(card(t)); }); + el.addEventListener('dragover', function (ev) { ev.preventDefault(); el.classList.add('over'); }); + el.addEventListener('dragleave', function () { el.classList.remove('over'); }); + el.addEventListener('drop', function (ev) { + ev.preventDefault(); el.classList.remove('over'); + var code = ev.dataTransfer.getData('text/plain'); + if (!code) return; + state[code] = col; save(); render(); + }); + board.appendChild(el); + }); + stats(list); + } + + function card(t) { + var d = document.createElement('div'); + d.className = 'card'; + d.draggable = true; + var blocked = !ready(t); + d.innerHTML = '
' + t.code + ' · ' + t.estimateDays + ' PT
' + + '
' + esc(t.title) + '
' + + 'Welle ' + t.wave + '' + + '' + t.role + '' + + '' + t.complexity + '' + + (blocked ? 'wartet auf ' + t.dependsOn.filter(function (c) { return !isDone(c); }).join(', ') + '' : 'startbar'); + d.addEventListener('dragstart', function (ev) { ev.dataTransfer.setData('text/plain', t.code); d.classList.add('dragging'); }); + d.addEventListener('dragend', function () { d.classList.remove('dragging'); }); + d.addEventListener('click', function () { openDlg(t); }); + return d; + } + + function esc(s) { return String(s).replace(/[&<>]/g, function (c) { return { '&': '&', '<': '<', '>': '>' }[c]; }); } + + function stats(list) { + var done = DATA.tickets.filter(function (t) { return statusOf(t) === 'Fertig'; }); + var donePT = done.reduce(function (a, t) { return a + t.estimateDays; }, 0); + var readyNow = DATA.tickets.filter(function (t) { return ready(t) && statusOf(t) !== 'Fertig'; }).length; + document.getElementById('stats').innerHTML = + '' + DATA.tickets.length + ' Kacheln' + + 'sichtbar: ' + list.length + '' + + 'fertig: ' + done.length + ' (' + donePT + ' von ' + DATA.totalDays + ' PT)' + + 'jetzt startbar: ' + readyNow + '' + + 'Wellen: ' + maxWave + ''; + } + + var dlg = document.getElementById('dlg'); + var current = null; + function openDlg(t) { + current = t; + document.getElementById('dCode').textContent = t.code + ' · ' + t.epicName; + document.getElementById('dTitle').textContent = t.title; + document.getElementById('dMeta').innerHTML = + 'Welle ' + t.wave + '' + t.role + '' + t.complexity + '' + t.estimateDays + ' PT' + statusOf(t) + ''; + document.getElementById('dDesc').textContent = t.description; + chips('dDeps', t.dependsOn); + chips('dNext', t.unlocks); + items('dAcc', t.akzeptanz); + items('dChk', t.pruefungen); + document.getElementById('dPrompt').textContent = t.prompt; + dlg.showModal(); + } + function chips(id, arr) { + var el = document.getElementById(id); + el.innerHTML = (arr && arr.length) ? arr.map(function (c) { return '' + c + (byCode[c] ? ' – ' + esc(byCode[c].title) : '') + ''; }).join('') : 'keine'; + } + function items(id, arr) { + document.getElementById(id).innerHTML = (arr || []).map(function (a) { return '
  • ' + esc(a) + '
    • '; }).join(''); + } + document.getElementById('closeBtn').onclick = function () { dlg.close(); }; + document.getElementById('copyBtn').onclick = function () { + if (!current) return; + var btn = this; + navigator.clipboard.writeText(current.prompt).then(function () { + btn.textContent = 'Kopiert ✓'; + setTimeout(function () { btn.textContent = 'Prompt kopieren'; }, 1800); + }); + }; + + document.getElementById('q').addEventListener('input', render); + [fEpic, fRole, fWave].forEach(function (s) { s.addEventListener('change', render); }); + document.getElementById('onlyReady').onclick = function () { + onlyReady = !onlyReady; + this.style.borderColor = onlyReady ? 'var(--primary)' : 'var(--border)'; + this.textContent = onlyReady ? 'Filter: nur startbare' : 'Nur startbare'; + render(); + }; + document.getElementById('resetBtn').onclick = function () { + if (confirm('Alle lokalen Statusänderungen verwerfen?')) { state = {}; save(); render(); } + }; + document.getElementById('exportBtn').onclick = function () { + var rows = [['Code', 'Titel', 'Status']].concat(DATA.tickets.map(function (t) { return [t.code, t.title, statusOf(t)]; })); + var csv = rows.map(function (r) { return r.map(function (c) { return '"' + String(c).replace(/"/g, '""') + '"'; }).join(','); }).join('\n'); + var a = document.createElement('a'); + a.href = URL.createObjectURL(new Blob(['\ufeff' + csv], { type: 'text/csv;charset=utf-8' })); + a.download = 'kanban-stand.csv'; + a.click(); + }; + + render(); +})(); diff --git a/connect-kanban/DEVLOG.md b/connect-kanban/DEVLOG.md new file mode 100644 index 00000000..9ec75265 --- /dev/null +++ b/connect-kanban/DEVLOG.md @@ -0,0 +1,13 @@ +# connect-kanban – Dev Log + +## 2026-09-12 21:36 – 21:39 (2m) +**Beschreibung:** Claude Code Session +**Projekt:** flutter_app + +### Commits +Keine Commits in dieser Session. + +### Geänderte Dateien +Keine Änderungen ermittelbar. + +--- diff --git a/connect-kanban/README.md b/connect-kanban/README.md new file mode 100644 index 00000000..190d6301 --- /dev/null +++ b/connect-kanban/README.md @@ -0,0 +1,93 @@ +# Connect-Kanban – lokal abarbeiten + +32 Arbeitskacheln · 7 Epics · 85 Personentage · 7 Wellen (inkl. Welle 7: Threat-Model-Nachtrag 2026-09-12 — ENG-07, ENG-08). + +Hinweis: Dieses Board baut vollständig auf NEXARCH Core auf (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur. LDAP/SSO sind Core-Sache (IAM-05/IAM-06), Scanner-Anbindung ist DMS/Mail-Sache, hier ausschließlich externe Drittsystem-Konnektoren. + +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** (10 Kacheln): ENG-02, ENG-03, ENG-04, ENG-06, ERP-01, ERP-02, DAT-01, DMS2-01, DMS2-03, API-03 +- **Welle 3** (10 Kacheln): ENG-05, ERP-03, ERP-04, DAT-02, M365-01, DMS2-02, API-01, QA-02, QA-04, QA-06 +- **Welle 4** (4 Kacheln): DAT-03, M365-02, M365-03, API-02 +- **Welle 5** (1 Kachel): QA-03 +- **Welle 6** (1 Kachel): QA-05 + +Kritischer Pfad (16 PT): ENG-01 → DAT-01 → DAT-02 → DAT-03 → QA-03 → QA-05 + +## Produkt-DNA + +### Übernehmen +- **Zapier/n8n**: Connector-Plugin-Modell mit austauschbaren Adaptern statt fest verdrahteter Drittsystem-Logik – Kernidee dieses Boards, bewusst schlanker ohne visuellen Workflow-Builder. +- **Airbyte**: Sync-Job-Konzept mit Retry und Fehlerbehandlung als Vorbild für robuste, wiederholbare Imports/Exports. + +### Vermeiden +- **Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock.**: Jeder Connector ist offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – was die Oberfläche kann, kann auch die offene Schnittstelle. +- **Zapier/n8n – voller grafischer Workflow-Builder.**: Nur die Kernidee austauschbarer Adapter, kein eigenes Prozessmodellierungswerkzeug – das übernimmt bei Bedarf NEXARCH Workflow. + +## Arbeitsregeln + +Je Kachel ein eigener Branch, schrittweise committen, Branch pushen, dann anhalten. +Kein Merge und kein Deploy ohne ausdrückliche Freigabe. + +Code-Struktur: Hauptdateien/Entry-Points klein halten, Fachlogik in eigene Module/Dateien auslagern. Vor dem Anlegen einer neuen Funktions-/Modul-Datei prüfen, ob dieselbe Funktionalität nicht schon in einem anderen Modul (auch modulübergreifend, z. B. Core) existiert — keine doppelten Funktionsdateien, ein Modul/Board referenziert das andere extern statt Code zu kopieren (gleiches Prinzip wie bei den Konsolidierungen IAM/Archive/Workflow/AI/API/UI-Shell, siehe nexarch-state.json). diff --git a/connect-kanban/board.csv b/connect-kanban/board.csv new file mode 100644 index 00000000..4a200422 --- /dev/null +++ b/connect-kanban/board.csv @@ -0,0 +1,203 @@ +Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen +ENG-01,Connector-Plugin-Modell,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,1,Fertig,"Plugin-Schnittstelle, Go-Interface, Registrierung","Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.",,ENG-02 ENG-03 ENG-04 ENG-06 ERP-01 ERP-02 DAT-01 DMS2-01 DMS2-03 API-03,"Neuer Connector lässt sich ohne Codeänderung an der Engine registrieren +Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz +Connector-Metadaten (Name, Version, unterstützte Operationen) sind abrufbar","Zwei Testconnectoren parallel registriert und einzeln ansprechbar +Deregistrierung entfernt Connector vollständig +Fehlerhafter Connector wird beim Laden abgewiesen, Engine bleibt lauffähig" +ENG-02,"Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt)",🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,2,Fertig,"Verschlüsselte Speicherung, OAuth2-Client, PostgreSQL","Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.",ENG-01,M365-01 API-01 QA-04 QA-07 QA-02 ENG-07,"Zugangsdaten sind ausschließlich verschlüsselt gespeichert +OAuth-Token-Erneuerung läuft automatisiert ohne Nutzereingriff +Widerruf einer Verbindung entfernt zugehörige Zugangsdaten vollständig","Datenbankinhalt der Zugangsdaten-Tabelle ist ohne Schlüssel nicht lesbar +Ablaufender OAuth-Token wird vor Ablauf erneuert +Widerruf im Test entfernt Zugangsdaten nachweislich" +ENG-03,Sync-Job-Verwaltung (periodische Imports/Exports),🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,2,Fertig,"Postgres-Jobqueue, periodische Ausführung","Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.",ENG-01,ENG-05 QA-02 ENG-08,"Sync-Job ist mit Zeitplan konfigurierbar +Laufender Job überlebt einen Dienst-Neustart +Manuelles Anstoßen eines Jobs außerhalb des Zeitplans möglich","Zeitplan im Test korrekt eingehalten +Neustart des Dienstes mit laufendem Job geprüft +Manueller Anstoß erzeugt genau einen zusätzlichen Lauf" +ENG-04,Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem),🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,2,Fertig,"Mapping-Konfiguration, Schema-Validierung",Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.,ENG-01,API-01 QA-02,"Feld-Mapping ist ohne Codeänderung konfigurierbar +Ungültiges Mapping wird beim Speichern abgewiesen +Pflichtfeld ohne Zuordnung wird vor Ausführung gemeldet","Ungültiges Mapping im Test abgewiesen +Fehlendes Pflichtfeld-Mapping verhindert Sync-Start +Geändertes Mapping wirkt erst auf nachfolgende Läufe" +ENG-05,Fehlerbehandlung & Retry bei Drittsystem-Ausfällen,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,3,3,Fertig,"Retry mit Backoff, Fehlerprotokoll, Postgres-Jobqueue","Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.",ENG-03,API-02 QA-02 ENG-08,"Fehlgeschlagener Sync-Job wird mit Backoff automatisch wiederholt +Dauerhafter Ausfall führt nach Grenzwert zu klarem Fehlerstatus statt Endlosschleife +Fehlerprotokoll je Lauf ist einsehbar","Simulierter Drittsystem-Ausfall löst Retry mit Backoff aus +Abbruchgrenze im Test erreicht und Status korrekt gesetzt +Fehlerprotokoll enthält Ursache und Zeitpunkt" +ENG-06,Connector-Audit-Kopplung (Core AUD),🔌 Connector-Engine & Grundgerüst,Backend,Einfach,2,2,Fertig,Audit-Ereignis-Kopplung,"Kopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.",ENG-01,QA-02,"Jede sicherheitsrelevante Connector-Aktion erzeugt einen Audit-Eintrag im Core-Audit-Log +Audit-Eintrag enthält Person, Zeitpunkt und betroffenen Connector +Fehlende Audit-Kopplung verhindert die Aktion nicht, wird aber protokolliert","Verbindung anlegen erzeugt nachweisbaren Audit-Eintrag +Zugangsdaten ändern erzeugt nachweisbaren Audit-Eintrag +Ausfall des Audit-Dienstes blockiert Connector-Betrieb nicht" +ERP-01,ERP-Connector-Grundgerüst,📈 ERP/CRM-Anbindung,Backend,Mittel,3,2,Fertig,"ERP-Connector, REST/SOAP-Client","Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).",ENG-01,ERP-03 ERP-04,"Verbindung zu einem Test-ERP-System lässt sich aufbauen und prüfen +Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar +Verbindungsfehler wird klar gemeldet statt stillem Abbruch","Verbindungsaufbau gegen Test-ERP-System erfolgreich geprüft +Lese- und Schreiboperation im Test erfolgreich +Simulierter Verbindungsfehler wird korrekt gemeldet" +ERP-02,CRM-Connector-Grundgerüst,📈 ERP/CRM-Anbindung,Backend,Mittel,3,2,Fertig,"CRM-Connector, REST-Client","Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.",ENG-01,ERP-03 QA-03,"Verbindung zu einem Test-CRM-System lässt sich aufbauen und prüfen +Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar +Verbindungsfehler wird klar gemeldet statt stillem Abbruch","Verbindungsaufbau gegen Test-CRM-System erfolgreich geprüft +Lese- und Schreiboperation im Test erfolgreich +Simulierter Verbindungsfehler wird korrekt gemeldet" +ERP-03,Stammdaten-Abgleich (Kunden/Lieferanten),📈 ERP/CRM-Anbindung,Backend,Mittel,3,3,Fertig,"Sync-Logik, Konfliktbehandlung",Automatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.,ERP-01 ERP-02,QA-03,"Neuer Stammdatensatz im Drittsystem erscheint nach Sync in NEXARCH +Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben +Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung","Neuanlage im Test-ERP nach Sync in NEXARCH sichtbar +Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt statt Datenverlust +Zeitplan-gesteuerter Lauf im Test erfolgreich" +ERP-04,Beleg-/Dokumentexport an ERP,📈 ERP/CRM-Anbindung,Backend,Mittel,3,3,Fertig,"Dokumentexport, Feld-Mapping",Export von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.,ERP-01,QA-03,"Beleg lässt sich mit zugeordneten Metadaten an das ERP exportieren +Fehlgeschlagener Export wird über die Fehlerbehandlung erneut versucht +Bereits exportierter Beleg wird nicht doppelt übertragen","Testbeleg im ERP nach Export mit korrekten Metadaten auffindbar +Simulierter Exportfehler löst Retry aus +Doppelversand im Test ausgeschlossen" +DAT-01,DATEV-Format-Export (Belege/Buchungsstapel),🧾 DATEV-Anbindung,Backend,Mittel,3,2,Fertig,"DATEV-Exportformat, Buchungsstapel-Struktur",Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.,ENG-01 RET-05,DAT-02 DAT-03,"Export erzeugt gültige DATEV-Exportdatei aus Testbelegen +Pflichtfelder des DATEV-Formats werden vollständig befüllt oder der Export klar abgewiesen +Exportierter Buchungsstapel ist eindeutig einem Zeitraum zugeordnet +Exportiertes Objekt (Buchungsstapel) wird bei Archive RET-05 mit der GoBD-Aufbewahrungsklasse registriert, statt unregistriert im Dateisystem zu liegen","Erzeugte Exportdatei besteht Formatprüfung gegen DATEV-Spezifikation +Fehlendes Pflichtfeld führt zu klarer Abweisung statt fehlerhaftem Export +Zeitraumzuordnung im Test korrekt +Export eines Testbuchungsstapels erzeugt nachweisbar eine Registrierung bei Archive RET-05" +DAT-02,DATEV-Konnektor (Schnittstellen-Protokoll),🧾 DATEV-Anbindung,Backend,Komplex,4,3,Fertig,"DATEV-Schnittstellenprotokoll, Übertragungslogik","Konnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.",DAT-01,DAT-03,"Übertragung an ein Test-DATEV-Zielsystem gelingt protokollkonform +Fehlgeschlagene Übertragung wird über die Fehlerbehandlung erneut versucht +Übertragungsstatus ist je Lauf nachvollziehbar","Protokollkonforme Übertragung im Test gegen Referenzsystem geprüft +Simulierter Übertragungsfehler löst Retry aus +Übertragungsstatus im Test korrekt und nachvollziehbar" +DAT-03,DATEV-Export-Oberfläche & Protokoll,🧾 DATEV-Anbindung,Frontend,Einfach,2,4,Fertig,"React/Next.js-Oberfläche, Exportprotokoll-Ansicht",Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.,DAT-01 DAT-02 SHL-01,QA-03,"Export lässt sich über die Oberfläche mit Zeitraum-Auswahl anstoßen +Exportprotokoll ist je Lauf einsehbar +Fehlgeschlagener Export ist in der Oberfläche klar erkennbar","Export-Anstoß im Test aus der Oberfläche erfolgreich +Protokollansicht zeigt reale Testläufe korrekt an +Fehlgeschlagener Testlauf ist visuell klar unterscheidbar" +M365-01,Microsoft-Graph-API-Anbindung (Auth/Basis),☁️ Microsoft 365-Anbindung,Backend,Mittel,3,3,Fertig,"Microsoft Graph API, OAuth2",Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.,ENG-02,M365-02 M365-03,"Authentifizierung gegen Microsoft Graph im Test erfolgreich +Zugangsdaten werden über die Connect-Credential-Verwaltung gespeichert +Abgelaufene Berechtigung wird erkannt und klar gemeldet","OAuth2-Anmeldung im Test gegen Microsoft-Testmandant erfolgreich +Testaufruf einer Graph-API-Basisoperation erfolgreich +Simulierter Berechtigungsablauf wird korrekt erkannt und gemeldet" +M365-02,SharePoint/OneDrive-Dokumentabgleich,☁️ Microsoft 365-Anbindung,Backend,Mittel,3,4,Fertig,"SharePoint/OneDrive-API, Sync-Logik",Abgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.,M365-01,QA-03,"Dokument aus SharePoint/OneDrive erscheint nach Sync in NEXARCH mit Metadaten +Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben +Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung","Testdokument aus SharePoint nach Sync in NEXARCH korrekt vorhanden +Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt +Zeitplan-gesteuerter Lauf im Test erfolgreich" +M365-03,Outlook-Kalender-Kopplung (Fristen/Wiedervorlage),☁️ Microsoft 365-Anbindung,Backend,Mittel,3,4,Fertig,"Outlook-Kalender-API, Fristen-Kopplung",Kopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.,M365-01,QA-03,"Frist/Wiedervorlage erscheint als Kalendereintrag in Outlook +Änderung der Frist in NEXARCH aktualisiert den Kalendereintrag +Gelöschte Frist entfernt den zugehörigen Kalendereintrag","Testfrist im Test-Outlook-Kalender korrekt sichtbar +Friständerung im Test korrekt im Kalender nachgezogen +Löschung im Test entfernt Kalendereintrag vollständig" +DMS2-01,"Standardisiertes Export-/Import-Format (offen, dokumentiert)",🔄 Andere-DMS-Interoperabilität,Backend,Mittel,3,2,Fertig,"Offenes Austauschformat, Schema-Dokumentation",Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.,ENG-01,DMS2-02 QA-03,"Format ist vollständig dokumentiert und ohne NEXARCH-Werkzeug lesbar +Export enthält Dokument, Metadaten und Versionsbezug +Format-Validierung weist fehlerhafte Dateien ab","Exportierte Testdatei extern ohne NEXARCH-Werkzeug lesbar geprüft +Enthaltene Metadaten im Test vollständig und korrekt +Fehlerhafte Testdatei wird bei Validierung abgewiesen" +DMS2-02,Import-Assistent für Drittsystem-Exporte,🔄 Andere-DMS-Interoperabilität,Fullstack,Mittel,3,3,Fertig,"Import-Assistent mit Mapping-Vorschau-Oberfläche (Next.js/React), Backend-Parser für Drittsystem-Exportformate","Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.",DMS2-01 SHL-01,QA-03,"Testexport eines gängigen Drittsystems lässt sich einlesen +Feld-Mapping wird vorgeschlagen und ist vor Import änderbar +Import-Ergebnis mit Erfolgs-/Fehlerzahl ist einsehbar +Mapping-Vorschau ist eine bedienbare Oberfläche (nicht nur eine API-Antwort), in der Feldzuordnungen vor dem Import angepasst werden können","Testexport eines Drittsystems im Test erfolgreich eingelesen +Manuelle Mapping-Korrektur im Test übernommen +Import-Protokoll zeigt korrekte Erfolgs-/Fehlerzahl +Mapping-Vorschau im Browser bedient: Zuordnung geändert, Import mit geänderter Zuordnung ausgeführt" +DMS2-03,Externe-Backup-Ziel-Anbindung,🔄 Andere-DMS-Interoperabilität,Backend,Mittel,3,2,Fertig,"Backup-Ziel-Connector, verschlüsselte Übertragung",Anbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) für den verschlüsselten Export von Dokumentbeständen.,ENG-01,QA-03,"Backup-Ziel lässt sich über das Connector-Plugin-Modell einrichten +Export an das Backup-Ziel erfolgt verschlüsselt +Fehlgeschlagener Backup-Export wird über die Fehlerbehandlung erneut versucht","Verbindungsaufbau zu Test-Backup-Ziel im Test erfolgreich +Übertragung im Test nachweislich verschlüsselt +Simulierter Übertragungsfehler löst Retry aus" +API-01,Connect-Konfigurationsoberfläche (Connectoren einrichten),🖥️ Connect-Oberfläche,Frontend,Mittel,3,3,Fertig,"Next.js/React, Connector-Einrichtungsformulare","Oberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.",ENG-02 ENG-04 SHL-01,,"Connector lässt sich vollständig über die Oberfläche einrichten, ohne Konfigurationsdatei +Zugangsdaten werden nur maskiert angezeigt, nie im Klartext +Feld-Mapping ist über die Oberfläche bearbeitbar","Vollständige Einrichtung eines Testconnectors über die Oberfläche erfolgreich +Zugangsdaten in der Oberfläche im Test nachweislich maskiert +Mapping-Änderung über die Oberfläche im Test korrekt übernommen" +API-02,Verbindungsstatus-Übersicht & Diagnose,🖥️ Connect-Oberfläche,Frontend,Einfach,2,4,Fertig,"Next.js/React, Statusanzeige","Übersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.",ENG-05 SHL-01,,"Verbindungsstatus je Connector ist auf einen Blick erkennbar +Letzter Sync-Lauf mit Ergebnis ist einsehbar +Fehlerdiagnose zeigt die Ursache aus dem Fehlerprotokoll","Statusanzeige im Test korrekt für erfolgreichen und fehlgeschlagenen Lauf +Diagnoseansicht zeigt reale Testfehler nachvollziehbar an +Aktualisierung nach neuem Sync-Lauf im Test korrekt" +API-03,Externe Webhook-Abonnements (nutzt Core API-07),🖥️ Connect-Oberfläche,Backend,Mittel,3,2,Fertig,Core-Webhook-Registry-Anbindung,"Abonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.",ENG-01,,"Connector kann ein Webhook-Ereignis über die Core-Webhook-Registry abonnieren +Zugestelltes Ereignis löst die zugeordnete Connector-Aktion aus +Abbestellen entfernt das Abonnement vollständig","Testabonnement über Core-Webhook-Registry im Test erfolgreich registriert +Testereignis löst im Test die erwartete Connector-Aktion aus +Abbestellung im Test vollständig entfernt" +QA-01,Teststrategie Connect,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,1,Fertig,"Testkorpus, Teststrategie-Dokument","Teststrategie für Connect: Testkorpus aus realen Drittsystem-Antworten (ERP, CRM, DATEV, Microsoft Graph), Testarten je Ausbaustufe, Freigabekriterien.",,,"Teststrategie ist dokumentiert und für alle Epics anwendbar +Testkorpus enthält reale Beispieldaten je angebundenem Drittsystemtyp +Freigabekriterien je Prüfgate sind eindeutig benannt +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 liegt vollständig vor und wurde geprüft +Testkorpus im Test auf Vollständigkeit je Systemtyp geprüft +Freigabekriterien im Test auf Eindeutigkeit geprüft" +QA-02,Prüfgate Connector-Engine,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,3,Fertig,"Prüfprotokoll, automatisierte Tests","Verbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).",ENG-06 ENG-02 ENG-03 ENG-04 ENG-05,QA-05,"Alle Akzeptanzkriterien der ENG-Kacheln sind geprüft und protokolliert +Automatisierte Tests der ENG-Kacheln laufen fehlerfrei +Prüfprotokoll ist abgelegt und nachlesbar","Vollständiger Testlauf über alle ENG-Kacheln durchgeführt und protokolliert +Fehlerinjektion (Drittsystem-Ausfall) im Test korrekt behandelt +Audit-Kopplung im Test nachweislich vollständig" +QA-03,Prüfgate ERP/DATEV/M365,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,5,Fertig,"Prüfprotokoll, automatisierte Tests","Verbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.",ERP-04 DAT-03 M365-03 ERP-02 ERP-03 M365-02 DMS2-01 DMS2-02 DMS2-03,QA-05,"Alle Akzeptanzkriterien der ERP-, DAT- und M365-Kacheln sind geprüft und protokolliert +Automatisierte Tests laufen fehlerfrei gegen Testsysteme +Prüfprotokoll ist abgelegt und nachlesbar +Alle Akzeptanzkriterien der DMS2-Kacheln (Interoperabilität mit Drittsystemen) sind ebenfalls geprüft und protokolliert","Vollständiger Testlauf über ERP-, DAT- und M365-Kacheln durchgeführt und protokolliert +Mindestens ein echter Testlauf je Drittsystemtyp durchgeführt +Fehlerbehandlung bei simuliertem Ausfall je Systemtyp geprüft" +QA-04,Sicherheitsprüfung Drittsystem-Credentials,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,3,Fertig,"Sicherheitsprüfung, Penetrationstest-Checkliste","Gezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.",ENG-02,QA-05,"Verschlüsselung der Zugangsdaten besteht die Sicherheitsprüfung +Zugriff auf Zugangsdaten ist auf berechtigte Rollen beschränkt +Schlüsselverwaltung folgt dokumentierten Sicherheitsvorgaben","Verschlüsselungsprüfung gegen Datenbankinhalt durchgeführt und protokolliert +Zugriffsprüfung mit unberechtigter Rolle im Test abgewiesen +Schlüsselrotation im Test ohne Datenverlust durchgeführt" +QA-05,Abnahme-Prüfung Connect,✅ Prüfungen & Qualitätssicherung,Backend,Einfach,2,6,Fertig,Abnahmeprotokoll,"Abschließende Abnahme-Prüfung von NEXARCH Connect über alle Epics hinweg, Freigabe zur Nutzung durch andere Module.",QA-02 QA-03 QA-04 QA-06 QA-07 QA-08,,"Alle vorgelagerten Prüfgates sind abgeschlossen und protokolliert +Zusammenspiel aller Connectoren im Gesamttest geprüft +Abnahmeprotokoll ist abgelegt und nachlesbar","Gesamttest über alle Connectoren durchgeführt und protokolliert +Zusammenspiel mit Core-Webhook-Registry im Test geprüft +Abnahmeprotokoll vollständig und nachvollziehbar abgelegt" +QA-06,Schnittstellen-Vertragstests,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,3,Fertig,"Vertragstests (Consumer-Driven Contracts), CI-Pipeline","Vertragstests für externe Webhook-Abonnements (API-03) – anders als bei internen Modul-zu-Modul-Schnittstellen sind hier externe Drittsysteme die Konsumenten, ein Breaking Change trifft Kunden direkt, nicht nur ein anderes NEXARCH-Modul.",API-03,QA-05,"Vertragstests decken das Webhook-Abonnement-Format vollständig ab +Absichtlich brechender Schema-Wechsel lässt Tests fehlschlagen +Tests laufen automatisiert in der CI","Testlauf gegen aktuellen Stand grün +Simulierte Breaking Change erkannt +CI-Integration nachgewiesen" +QA-07,Last- & Leistungstest,✅ Prüfungen & Qualitätssicherung,Backend,Mittel,3,6,Fertig,"Lastgenerator, Messprotokoll","Lasttest für Connect unter realistischer Last aus mehreren gleichzeitig synchronisierenden Connector-Instanzen (ERP, DATEV, M365) – insbesondere Credential-Verwaltung (ENG-02) und Sync-Job-Queue unter Last.",ENG-02,QA-05,"Definierte Ziel-Latenz für Credential-Abruf unter Last mehrerer gleichzeitiger Connector-Instanzen eingehalten +Sync-Job-Queue verarbeitet viele gleichzeitig eingereihte Jobs ohne Verklemmung oder Doppelverarbeitung +Rate-Limiting gegenüber Drittsystemen bleibt unter Mehrinstanz-Last korrekt eingehalten","Lasttest mit simulierten parallelen Sync-Jobs mehrerer Connector-Typen durchgeführt, Ergebnis dokumentiert +Test auf Doppelverarbeitung/Verklemmung der Job-Queue unter Last +Rate-Limit-Verhalten gegenüber Drittsystemen bei mehreren gleichzeitigen Connector-Instanzen geprüft" +QA-08,Barrierefreiheits-Audit,✅ Prüfungen & Qualitätssicherung,QA,Mittel,3,5,Fertig,"Prüfwerkzeuge, Bildschirmleser","Unabhängige Prüfung aller Connect-Oberflächen (DATEV-Export-Oberfläche, Import-Assistent, Connect-Konfigurationsoberfläche, Verbindungsstatus-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.",DAT-03 DMS2-02 API-01 API-02,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" +ENG-07,Drittsystem-Zugangsdaten über Core-Tenant-KEK-Hierarchie verschlüsseln,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,2,7,Fertig,"Envelope-Encryption (Tenant-KEK aus Core API-10), PostgreSQL, Go","ENG-02 speichert Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys) verschlüsselt, ohne festzulegen, mit welchem Schlüssel. Analog zu DMS `IAM-19` müssen diese Zugangsdaten über den Tenant-KEK aus der Core-Schlüsselhierarchie (API-10) verschlüsselt werden statt über ein separates, eigenes Verschlüsselungsschema – sonst entsteht neben der zentralen Schlüsselverwaltung ein zweiter, unabhängig zu härtender Verschlüsselungspfad für hochsensible Zugangsdaten.",ENG-02,,"Drittsystem-Zugangsdaten (OAuth-Tokens, API-Keys) sind in der Datenbank ausschließlich verschlüsselt über den Tenant-KEK des jeweiligen Mandanten gespeichert +Ein direkter Lesezugriff auf die Zugangsdaten-Tabelle liefert keinen verwertbaren Klartext +Bestehende Connector-Authentifizierung aus ENG-02 funktioniert nach der Umstellung unverändert","Test: Zugangsdaten in der Datenbank direkt auslesen, prüfen dass nur Chiffrat sichtbar ist +Regressionstest: Connector-Verbindungsaufbau (ERP/DATEV/M365/DMS2) funktioniert nach Umstellung auf Tenant-KEK-Verschlüsselung weiterhin +Test: Entschlüsselung schlägt fehl, wenn der falsche Tenant-KEK verwendet wird (kein Cross-Tenant-Zugriff auf Drittsystem-Credentials)" +ENG-08,Ressourcenlimits & Rate-Limiting für Drittsystem-Sync-Jobs,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,2,7,Fertig,"Postgres-Jobqueue, Rate-Limiting, Ressourcenlimits (Zeit/Datenmenge)","ENG-03 verwaltet periodische Sync-Jobs, ENG-05 behandelt Fehler bei Drittsystem-Ausfällen mit Retry/Backoff, ohne Obergrenzen für Laufzeit oder Datenmenge je Sync-Lauf festzulegen. Ein fehlerhaft konfigurierter oder kompromittierter Connector (z. B. ein Drittsystem, das ungewöhnlich große Antworten liefert oder in einer Retry-Schleife hängen bleibt) kann sonst Ressourcen auf Kosten anderer Mandanten/Connectoren binden. Harte Obergrenzen je Sync-Lauf definieren (max. Laufzeit, max. übertragene Datenmenge, max. Anzahl Retry-Versuche als Abbruchgrenze aus ENG-05) sowie Rate-Limiting für ausgehende Anfragen an ein einzelnes Drittsystem.",ENG-03 ENG-05,,"Jeder Sync-Job hat konfigurierbare Obergrenzen für Laufzeit und übertragene Datenmenge +Die Abbruchgrenze für Retry-Versuche aus ENG-05 wird durchgesetzt, ein Job endet nach Erreichen der Grenze kontrolliert statt endlos zu wiederholen +Ausgehende Anfragen an ein einzelnes Drittsystem sind ratenbegrenzt, sodass ein einzelner Connector nicht das gesamte Sync-System für andere Connectoren/Mandanten blockiert","Test: Sync-Job, der die Laufzeit-/Datenmengenobergrenze überschreitet, wird kontrolliert abgebrochen +Test: Retry-Abbruchgrenze aus ENG-05 wird nach der konfigurierten Anzahl Versuche tatsächlich durchgesetzt +Lasttest: ein Connector mit Drittsystem-Fehlverhalten blockiert nicht die Sync-Jobs anderer Connectoren/Mandanten" +ENG-10,Modul-weiter Kill-Switch und Ausfallisolation für Connect,🔌 Connector-Engine & Grundgerüst,Backend,Mittel,2,8,Fertig,,,,,Kill-Switch per Umgebungsvariable; Totalausfall ohne Auswirkung auf andere Module; Einzel-Connector-Ausfall blockiert nicht den Rest,Kill-Switch-Test; Smoke-Test anderer Module nach hartem Prozess-Kill; Ausfall-Connector-Test +SEC-01,Echte Authentifizierung und verifizierter Tenant-Kontext für Connect-APIs,🔒 Sicherheit,Backend,Hoch,3,8,Backlog,"JWT-Verifikation (Core-Token), Go net/http Middleware, RBAC-Policy-Prüfung gegen Core","Security-Review-Finding K1 (kritisch): Connect-APIs prüfen nur `X-User-Id != """"`, Tenant kommt unverifiziert aus `X-Tenant-Slug`. `statusapi.WithPolicy()` existiert, wird aber nicht verdrahtet. Fundstellen: `statusapi.go:57-70`, `dms2importapi.go:41-54`, `datevapi.go:30-43`, `main.go:48-49`. Echte AuthN analog DMS-Vorbild (`moduleauth/middleware.go:72`) einführen.",,,"Jeder Connect-API-Aufruf verlangt ein gültiges, kryptografisch verifiziertes Core-Token; ein Request ohne gültiges Token wird mit 401 abgewiesen +Tenant- und User-Kontext werden ausschließlich aus dem verifizierten Token abgeleitet; X-User-Id/X-Tenant-Slug haben keinen Einfluss mehr, wenn sie vom Tokeninhalt abweichen +statusapi.WithPolicy() ist vor jeder Fach-API verdrahtet; unzureichende RBAC-Berechtigung führt zu 403 +Angriff mit gefälschtem X-Tenant-Slug-Header auf fremde Mandantendaten ist nach der Umstellung nachweislich blockiert","Angriff real nachstellen: curl mit gefälschtem X-Tenant-Slug liefert vor dem Fix fremde Mandantendaten über /connectors/status +Gleicher Angriff gegen POST /dms2/import/execute legt vor dem Fix Import-Lauf im Namen des fremden Mandanten an +Nach dem Fix: gleicher Request ohne gültiges Token bzw. mit gefälschtem Slug wird mit 401/403 abgewiesen +Regressionstest: legitimer Request mit gültigem Token funktioniert unverändert +Test: RBAC-Policy-Verweigerung löst 403 aus" +SEC-02,Entpack-Limit gegen Zip-Bomben im DMS2-Import,🔒 Sicherheit,Backend,Mittel,1,8,Backlog,"Go archive/zip, Streaming-Lese-Limits","Security-Review-Finding H12 (hoch): `io.ReadAll(rc)` ohne Limit in `readZipEntry` (`dms2import/parse.go:219-225`) und analog in `dmsexchange.go:1966-1973`. Das 200-MiB-Limit in `dms2importapi.go:26` gilt nur für die komprimierte Größe, `UncompressedSize64` wird nie geprüft (Zip-Bomb-Risiko).",,,"readZipEntry prüft UncompressedSize64 je Eintrag und kumulativ gegen feste Obergrenzen +Gleiches Limit gilt im analogen Entpack-Muster in dmsexchange.go +Überschreitung bricht den Import mit klarer Fehlermeldung ab statt abzustürzen +Limits greifen streaming während des Lesens, nicht erst nach vollständigem Entpacken","Angriff real nachstellen: Test-Zip (~10 MiB komprimiert) entpackt vor dem Fix unbegrenzt auf mehrere GiB +Nach dem Fix: gleicher Testfall bricht vor übermäßigem Speicherverbrauch mit Fehlermeldung ab +Regressionstest: normales Import-Zip innerhalb der Limits wird weiterhin korrekt eingelesen +Grenzfalltest: Zip knapp unter/über dem Limit liefert erwartetes Verhalten" +SEC-03,Append-only-Schutz für Connect-Protokolltabellen,🔒 Sicherheit,Backend,Mittel,2,8,Backlog,"PostgreSQL REVOKE/GRANT, Trigger-Funktion","Security-Review-Finding H15 (hoch): keine der 12 Migrationen unter `connect/migrations/` erzwingt Append-only auf Protokolltabellen (`datev_exports`, `dms2_import_runs`, `connect_audit_outbox`); Code macht UPDATE/DELETE (`syncjob.go:258`, `audittrail.go:1120`, `credential.go:793`). Etabliertes Muster aus Core AUD-07/DMS VER-08/Workflow ENG-07 übernehmen.",,,"REVOKE UPDATE/DELETE von der Anwendungsrolle auf datev_exports, dms2_import_runs, connect_audit_outbox +Trigger weist versuchten UPDATE/DELETE ab und protokolliert den Versuch +INSERT funktioniert unverändert, inkl. Sequence-GRANT bei BIGSERIAL +Betroffene Codepfade (syncjob.go, audittrail.go, credential.go) funktionieren ohne Schreibversuch auf geschützte Felder","Vor der Migration: direktes UPDATE/DELETE mit Anwendungsrolle gelingt nachweislich +Nach der Migration: gleicher Versuch wird abgewiesen, Trigger protokolliert die Warnung +Regressionstest: INSERT in alle drei Tabellen funktioniert unverändert inkl. Sequence-Vergabe +Regressionstest: angepasste Codepfade (syncjob, audittrail, credential) funktionieren fachlich weiterhin korrekt" +SEC-04,Fremdsystem-Antwortkörper vor Speicherung in last_error filtern,🔒 Sicherheit,Backend,Niedrig,1,8,Backlog,"Go, Muster-/Regex-Filterung","Security-Review-Finding M16 (mittel): bis zu 1 MiB Fremdsystem-Antwortkörper ungefiltert in `last_error`, lesbar über `statusapi.go:102`. Fundstellen: `datevtransfer.go:676-682`, `m365connector.go:112`, `backupconnector.go:101,139`. Kann Secrets enthalten (z. B. AWS StringToSign/AccessKeyID).",,,"Fremdsystem-Antwortkörper wird vor Speicherung in last_error auf sicherheitsrelevante Muster geprüft und diese werden entfernt/redigiert +Nur diagnostisch relevante Kurzfassung wird persistiert, keine vollständige Rohantwort +Kurzfassung bleibt für Fehlerdiagnose über die Status-API nachvollziehbar","Vor dem Fix: simulierter Fehlerfall mit AWS-artiger Antwort landet ungefiltert in last_error und ist über Status-API lesbar +Nach dem Fix: sicherheitsrelevante Angaben sind in der Kurzfassung nicht mehr enthalten +Regressionstest: normaler Fehlerfall liefert weiterhin diagnostisch brauchbare Kurzfassung +Test für alle drei Fundstellen einzeln (DATEV-Transfer, M365, Backup-Connector)" +SEC-05,Tenant-Bindung der Connect-Store-Methoden (IDOR-Härtung),🔒 Sicherheit,Backend,Mittel,2,8,Backlog,"Go, pgx/v5, PostgreSQL, Signaturänderung","Security-Review-Finding M17 (mittel): tenant-ungebundene Store-Methoden mit `WHERE id=$1` ohne Tenant-Filter, latentes IDOR-Risiko. Fundstellen: `syncjob.go:109-122,191-269`, `datevtransfer/store.go:935-1001`, `erpexport/store.go:1424-1490`.",,,"Betroffene Store-Methoden nehmen Tenant-Parameter als zwingenden Bestandteil der Signatur entgegen +WHERE-Klausel ist um AND tenant_slug=$2 ergänzt +Alle Aufrufer sind angepasst, Projekt compiliert fehlerfrei +Zugriff mit id eines fremden Mandanten liefert kein Ergebnis","Vor dem Fix: Store-Methode mit id von Mandant A und Tenant-Kontext von Mandant B liefert fremden Datensatz +Nach dem Fix: gleicher Aufruf liefert kein Ergebnis bei nicht passendem tenant_slug +Regressionstest: Aufruf mit korrekt zueinander passendem id/tenant_slug liefert erwarteten Datensatz, für alle drei Stores +Build-Test: Projekt compiliert fehlerfrei, kein Aufrufer ohne Tenant-Parameter" diff --git a/connect-kanban/board.json b/connect-kanban/board.json new file mode 100644 index 00000000..ccea50cd --- /dev/null +++ b/connect-kanban/board.json @@ -0,0 +1,1502 @@ +{ + "erzeugtAm": "2026-08-26", + "totalDays": 85, + "epics": [ + { + "key": "ENG", + "name": "Connector-Engine & Grundgerüst", + "emoji": "🔌", + "color": "#0369A1", + "description": "Connector-Plugin-Modell, Credential-Verwaltung, Sync-Job-Verwaltung, Feld-Mapping, Fehlerbehandlung/Retry und Audit-Kopplung." + }, + { + "key": "ERP", + "name": "ERP/CRM-Anbindung", + "emoji": "📈", + "color": "#B45309", + "description": "ERP- und CRM-Connector-Grundgerüst, Stammdaten-Abgleich und Beleg-/Dokumentexport." + }, + { + "key": "DAT", + "name": "DATEV-Anbindung", + "emoji": "🧾", + "color": "#7C3AED", + "description": "DATEV-Format-Export, Konnektor-Protokoll und Export-Oberfläche." + }, + { + "key": "M365", + "name": "Microsoft 365-Anbindung", + "emoji": "☁️", + "color": "#14B8A6", + "description": "Microsoft-Graph-Anbindung, SharePoint/OneDrive-Dokumentabgleich und Outlook-Kalender-Kopplung." + }, + { + "key": "DMS2", + "name": "Andere-DMS-Interoperabilität", + "emoji": "🔄", + "color": "#92400E", + "description": "Offenes Export-/Import-Format, Import-Assistent für Drittsystem-Exporte und externe Backup-Ziel-Anbindung." + }, + { + "key": "API", + "name": "Connect-Oberfläche", + "emoji": "🖥️", + "color": "#4338CA", + "description": "Konfigurationsoberfläche für Connectoren, Verbindungsstatus-Diagnose und externe Webhook-Abonnements." + }, + { + "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": "SEC", + "name": "Sicherheit", + "emoji": "🔒", + "color": "#DC2626", + "description": "Behebung verifizierter Security-Review-Befunde: Authentifizierung, Ressourcenschutz, Append-only-Protokollierung, Datenminimierung, Tenant-Isolation." + } + ], + "waves": [ + { + "welle": 1, + "codes": [ + "ENG-01", + "QA-01" + ] + }, + { + "welle": 2, + "codes": [ + "ENG-02", + "ENG-03", + "ENG-04", + "ENG-06", + "ERP-01", + "ERP-02", + "DAT-01", + "DMS2-01", + "DMS2-03", + "API-03" + ] + }, + { + "welle": 3, + "codes": [ + "ENG-05", + "ERP-03", + "ERP-04", + "DAT-02", + "M365-01", + "DMS2-02", + "API-01", + "QA-02", + "QA-04", + "QA-06" + ] + }, + { + "welle": 4, + "codes": [ + "DAT-03", + "M365-02", + "M365-03", + "API-02" + ] + }, + { + "welle": 5, + "codes": [ + "QA-03" + ] + }, + { + "welle": 6, + "codes": [ + "QA-05", + "QA-07" + ] + }, + { + "welle": 7, + "codes": [ + "ENG-07", + "ENG-08" + ] + }, + { + "welle": 8, + "codes": [ + "SEC-01", + "SEC-02", + "SEC-03", + "SEC-04", + "SEC-05" + ] + } + ], + "kritischerPfad": { + "path": [ + "ENG-01", + "DAT-01", + "DAT-02", + "DAT-03", + "QA-03", + "QA-05" + ], + "days": 16 + }, + "produktDna": { + "uebernehmen": [ + { + "produkt": "Zapier/n8n", + "staerke": "Connector-Plugin-Modell mit austauschbaren Adaptern statt fest verdrahteter Drittsystem-Logik – Kernidee dieses Boards, bewusst schlanker ohne visuellen Workflow-Builder." + }, + { + "produkt": "Airbyte", + "staerke": "Sync-Job-Konzept mit Retry und Fehlerbehandlung als Vorbild für robuste, wiederholbare Imports/Exports." + } + ], + "vermeiden": [ + { + "produkt": "Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock.", + "ansatz": "Jeder Connector ist offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – was die Oberfläche kann, kann auch die offene Schnittstelle." + }, + { + "produkt": "Zapier/n8n – voller grafischer Workflow-Builder.", + "ansatz": "Nur die Kernidee austauschbarer Adapter, kein eigenes Prozessmodellierungswerkzeug – das übernimmt bei Bedarf NEXARCH Workflow." + } + ] + }, + "epicDna": { + "ENG": { + "leitsatz": "Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.", + "uebernehmen": [ + "Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.", + "Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.", + "Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt." + ], + "vermeiden": [ + "Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.", + "Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar." + ] + }, + "ERP": { + "leitsatz": "Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.", + "uebernehmen": [ + "Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.", + "Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration." + ], + "vermeiden": [ + "Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.", + "Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert." + ] + }, + "DAT": { + "leitsatz": "DATEV-Export so verlässlich wie ein Airbyte-Sync-Job, mit offen dokumentiertem Format statt Blackbox-Konnektor.", + "uebernehmen": [ + "Airbyte: Retry und Fehlerbehandlung bei Exportläufen, damit ein fehlgeschlagener Export nicht stillschweigend verloren geht.", + "Vollständiges Exportprotokoll je Lauf, damit jeder DATEV-Export nachvollziehbar bleibt." + ], + "vermeiden": [ + "Kein Vendor-Lock durch proprietäres DATEV-Werkzeug – das Exportformat bleibt offen dokumentiert und ohne Herstellerwerkzeug nachvollziehbar.", + "Keine stille Fehlklassifizierung von Belegen – Abweichungen werden im Protokoll sichtbar." + ] + }, + "M365": { + "leitsatz": "Microsoft-365-Anbindung als austauschbarer Connector wie bei Zapier/n8n, nicht als tief verdrahtete Speziallösung.", + "uebernehmen": [ + "Zapier/n8n: Microsoft Graph als ein Connector unter vielen, austauschbar über dieselbe Plugin-Schnittstelle.", + "Airbyte: Sync-Job mit Retry für SharePoint/OneDrive-Dokumentabgleich." + ], + "vermeiden": [ + "Keine Sonderbehandlung von Microsoft 365 außerhalb des allgemeinen Connector-Modells – gleiche Credential-Verwaltung, gleiche Sync-Job-Logik.", + "Kein Vendor-Lock – der Connector bleibt ersetzbar, ohne dass NEXARCH Connect an Microsoft-Werkzeuge gebunden ist." + ] + }, + "DMS2": { + "leitsatz": "Offener Austausch mit anderen DMS-Systemen wie bei einem dokumentierten Airbyte-Konnektor, kein geschlossenes Migrationswerkzeug.", + "uebernehmen": [ + "Airbyte: offen dokumentiertes Austauschformat als Vorbild für Export/Import zwischen DMS-Systemen.", + "Zapier/n8n: der Import-Assistent bleibt ein austauschbarer Adapter, kein Einwegwerkzeug." + ], + "vermeiden": [ + "Kein proprietäres, geschlossenes Migrationsformat – offen dokumentiert und ohne Herstellerwerkzeug lesbar.", + "Keine Backup-Ziel-Anbindung mit Herstellerbindung – Zugangsdaten und Protokoll bleiben austauschbar." + ] + }, + "API": { + "leitsatz": "Eine schlanke Konfigurationsoberfläche für Connectoren wie bei Zapier/n8n, kein visueller Workflow-Builder.", + "uebernehmen": [ + "Zapier/n8n: übersichtliche Verbindungs-Einrichtung und Statusanzeige je Connector, ohne grafischen Workflow-Builder.", + "Airbyte: klare Diagnoseansicht bei fehlgeschlagenen Sync-Läufen." + ], + "vermeiden": [ + "Kein eigener Workflow-Builder – die Oberfläche konfiguriert Connectoren, sie modelliert keine Prozesse.", + "Keine eigene Webhook-Infrastruktur – die Oberfläche nutzt ausschließlich die zentrale Core-Webhook-Registry (API-07)." + ] + }, + "QA": { + "leitsatz": "Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.", + "uebernehmen": [ + "Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.", + "Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik." + ], + "vermeiden": [ + "Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.", + "Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf." + ] + } + }, + "tickets": [ + { + "code": "ENG-01", + "title": "Connector-Plugin-Modell", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Plugin-Schnittstelle, Go-Interface, Registrierung", + "description": "Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.", + "dependsOn": [], + "akzeptanz": [ + "Neuer Connector lässt sich ohne Codeänderung an der Engine registrieren", + "Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz", + "Connector-Metadaten (Name, Version, unterstützte Operationen) sind abrufbar" + ], + "pruefungen": [ + "Zwei Testconnectoren parallel registriert und einzeln ansprechbar", + "Deregistrierung entfernt Connector vollständig", + "Fehlerhafter Connector wird beim Laden abgewiesen, Engine bleibt lauffähig" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 1, + "unlocks": [ + "ENG-02", + "ENG-03", + "ENG-04", + "ENG-06", + "ERP-01", + "ERP-02", + "DAT-01", + "DMS2-01", + "DMS2-03", + "API-03" + ], + "prompt": "# ENG-01 – Connector-Plugin-Modell\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 1\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nPlugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n**Technische Grundlage:** Plugin-Schnittstelle, Go-Interface, Registrierung\n\n## Produkt-DNA für diesen Bereich\n> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.\n\n**Übernehmen:**\n- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.\n- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.\n- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.\n\n**Bewusst vermeiden:**\n- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.\n- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.\n\n**Für genau diese Kachel:** Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Ausgangslage\nDiese Kachel hat keine Vorbedingungen und ist sofort startbar.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Neuer Connector lässt sich ohne Codeänderung an der Engine registrieren\n2. Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz\n3. Connector-Metadaten (Name, Version, unterstützte Operationen) sind abrufbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Zwei Testconnectoren parallel registriert und einzeln ansprechbar\n2. Deregistrierung entfernt Connector vollständig\n3. Fehlerhafter Connector wird beim Laden abgewiesen, Engine bleibt lauffähig\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-02` Verbindungs-Credential-Verwaltung\n- `ENG-03` Sync-Job-Verwaltung\n- `ENG-04` Feld-Mapping-Konfiguration\n- `ENG-06` Connector-Audit-Kopplung\n- `ERP-01` ERP-Connector-Grundgerüst\n- `DAT-01` DATEV-Format-Export\n- `DMS2-01` Standardisiertes Export-/Import-Format\n- `API-03` Externe Webhook-Abonnements\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-01: 01 connector plugin modell`\n- Branch: `feature/eng-01-01-connector-plugin-modell`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-02", + "title": "Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt)", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Verschlüsselte Speicherung, OAuth2-Client, PostgreSQL", + "description": "Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Zugangsdaten sind ausschließlich verschlüsselt gespeichert", + "OAuth-Token-Erneuerung läuft automatisiert ohne Nutzereingriff", + "Widerruf einer Verbindung entfernt zugehörige Zugangsdaten vollständig" + ], + "pruefungen": [ + "Datenbankinhalt der Zugangsdaten-Tabelle ist ohne Schlüssel nicht lesbar", + "Ablaufender OAuth-Token wird vor Ablauf erneuert", + "Widerruf im Test entfernt Zugangsdaten nachweislich" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 2, + "unlocks": [ + "M365-01", + "API-01", + "QA-04", + "QA-07", + "QA-02", + "ENG-07" + ], + "prompt": "# ENG-02 – Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt)\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVerwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n\n**Technische Grundlage:** Verschlüsselte Speicherung, OAuth2-Client, PostgreSQL\n\n## Produkt-DNA für diesen Bereich\n> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.\n\n**Übernehmen:**\n- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.\n- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.\n- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.\n\n**Bewusst vermeiden:**\n- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.\n- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.\n\n**Für genau diese Kachel:** Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `IAM-09` API-Token & Service-Accounts\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Zugangsdaten sind ausschließlich verschlüsselt gespeichert\n2. OAuth-Token-Erneuerung läuft automatisiert ohne Nutzereingriff\n3. Widerruf einer Verbindung entfernt zugehörige Zugangsdaten vollständig\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Datenbankinhalt der Zugangsdaten-Tabelle ist ohne Schlüssel nicht lesbar\n2. Ablaufender OAuth-Token wird vor Ablauf erneuert\n3. Widerruf im Test entfernt Zugangsdaten nachweislich\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `M365-01` Microsoft-Graph-API-Anbindung (nutzt diese Verwaltung)\n- `API-01` Connect-Konfigurationsoberfläche\n- `QA-04` Sicherheitsprüfung Drittsystem-Credentials\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-02: 02 verbindungs credential verwaltung oauth api keys verschluesselt`\n- Branch: `feature/eng-02-02-verbindungs-credential-verwaltung-oauth-api-keys-verschluesselt`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-03", + "title": "Sync-Job-Verwaltung (periodische Imports/Exports)", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Postgres-Jobqueue, periodische Ausführung", + "description": "Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Sync-Job ist mit Zeitplan konfigurierbar", + "Laufender Job überlebt einen Dienst-Neustart", + "Manuelles Anstoßen eines Jobs außerhalb des Zeitplans möglich" + ], + "pruefungen": [ + "Zeitplan im Test korrekt eingehalten", + "Neustart des Dienstes mit laufendem Job geprüft", + "Manueller Anstoß erzeugt genau einen zusätzlichen Lauf" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 2, + "unlocks": [ + "ENG-05", + "QA-02", + "ENG-08" + ], + "prompt": "# ENG-03 – Sync-Job-Verwaltung (periodische Imports/Exports)\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVerwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.\n\n**Technische Grundlage:** Postgres-Jobqueue, periodische Ausführung\n\n## Produkt-DNA für diesen Bereich\n> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.\n\n**Übernehmen:**\n- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.\n- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.\n- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.\n\n**Bewusst vermeiden:**\n- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.\n- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.\n\n**Für genau diese Kachel:** Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Sync-Job ist mit Zeitplan konfigurierbar\n2. Laufender Job überlebt einen Dienst-Neustart\n3. Manuelles Anstoßen eines Jobs außerhalb des Zeitplans möglich\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Zeitplan im Test korrekt eingehalten\n2. Neustart des Dienstes mit laufendem Job geprüft\n3. Manueller Anstoß erzeugt genau einen zusätzlichen Lauf\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen\n- `API-02` Verbindungsstatus-Übersicht & Diagnose\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-03: 03 sync job verwaltung periodische imports exports`\n- Branch: `feature/eng-03-03-sync-job-verwaltung-periodische-imports-exports`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-04", + "title": "Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem)", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Mapping-Konfiguration, Schema-Validierung", + "description": "Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Feld-Mapping ist ohne Codeänderung konfigurierbar", + "Ungültiges Mapping wird beim Speichern abgewiesen", + "Pflichtfeld ohne Zuordnung wird vor Ausführung gemeldet" + ], + "pruefungen": [ + "Ungültiges Mapping im Test abgewiesen", + "Fehlendes Pflichtfeld-Mapping verhindert Sync-Start", + "Geändertes Mapping wirkt erst auf nachfolgende Läufe" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 2, + "unlocks": [ + "API-01", + "QA-02" + ], + "prompt": "# ENG-04 – Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem)\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nKonfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.\n\n**Technische Grundlage:** Mapping-Konfiguration, Schema-Validierung\n\n## Produkt-DNA für diesen Bereich\n> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.\n\n**Übernehmen:**\n- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.\n- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.\n- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.\n\n**Bewusst vermeiden:**\n- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.\n- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.\n\n**Für genau diese Kachel:** Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Feld-Mapping ist ohne Codeänderung konfigurierbar\n2. Ungültiges Mapping wird beim Speichern abgewiesen\n3. Pflichtfeld ohne Zuordnung wird vor Ausführung gemeldet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Ungültiges Mapping im Test abgewiesen\n2. Fehlendes Pflichtfeld-Mapping verhindert Sync-Start\n3. Geändertes Mapping wirkt erst auf nachfolgende Läufe\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `API-01` Connect-Konfigurationsoberfläche (Oberfläche für dieses Mapping)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-04: 04 feld mapping konfiguration nexarch drittsystem`\n- Branch: `feature/eng-04-04-feld-mapping-konfiguration-nexarch-drittsystem`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-05", + "title": "Fehlerbehandlung & Retry bei Drittsystem-Ausfällen", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Retry mit Backoff, Fehlerprotokoll, Postgres-Jobqueue", + "description": "Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.", + "dependsOn": [ + "ENG-03" + ], + "akzeptanz": [ + "Fehlgeschlagener Sync-Job wird mit Backoff automatisch wiederholt", + "Dauerhafter Ausfall führt nach Grenzwert zu klarem Fehlerstatus statt Endlosschleife", + "Fehlerprotokoll je Lauf ist einsehbar" + ], + "pruefungen": [ + "Simulierter Drittsystem-Ausfall löst Retry mit Backoff aus", + "Abbruchgrenze im Test erreicht und Status korrekt gesetzt", + "Fehlerprotokoll enthält Ursache und Zeitpunkt" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 3, + "unlocks": [ + "API-02", + "QA-02", + "ENG-08" + ], + "prompt": "# ENG-05 – Fehlerbehandlung & Retry bei Drittsystem-Ausfällen\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nFehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.\n\n**Technische Grundlage:** Retry mit Backoff, Fehlerprotokoll, Postgres-Jobqueue\n\n## Produkt-DNA für diesen Bereich\n> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.\n\n**Übernehmen:**\n- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.\n- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.\n- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.\n\n**Bewusst vermeiden:**\n- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.\n- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.\n\n**Für genau diese Kachel:** Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-03` Sync-Job-Verwaltung (periodische Imports/Exports) – Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Fehlgeschlagener Sync-Job wird mit Backoff automatisch wiederholt\n2. Dauerhafter Ausfall führt nach Grenzwert zu klarem Fehlerstatus statt Endlosschleife\n3. Fehlerprotokoll je Lauf ist einsehbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Simulierter Drittsystem-Ausfall löst Retry mit Backoff aus\n2. Abbruchgrenze im Test erreicht und Status korrekt gesetzt\n3. Fehlerprotokoll enthält Ursache und Zeitpunkt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `API-02` Verbindungsstatus-Übersicht & Diagnose (zeigt dieses Protokoll an)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-05: 05 fehlerbehandlung retry bei drittsystem ausfaellen`\n- Branch: `feature/eng-05-05-fehlerbehandlung-retry-bei-drittsystem-ausfaellen`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-06", + "title": "Connector-Audit-Kopplung (Core AUD)", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Audit-Ereignis-Kopplung", + "description": "Kopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Jede sicherheitsrelevante Connector-Aktion erzeugt einen Audit-Eintrag im Core-Audit-Log", + "Audit-Eintrag enthält Person, Zeitpunkt und betroffenen Connector", + "Fehlende Audit-Kopplung verhindert die Aktion nicht, wird aber protokolliert" + ], + "pruefungen": [ + "Verbindung anlegen erzeugt nachweisbaren Audit-Eintrag", + "Zugangsdaten ändern erzeugt nachweisbaren Audit-Eintrag", + "Ausfall des Audit-Dienstes blockiert Connector-Betrieb nicht" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 2, + "unlocks": [ + "QA-02" + ], + "prompt": "# ENG-06 – Connector-Audit-Kopplung (Core AUD)\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nKopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.\n\n**Technische Grundlage:** Audit-Ereignis-Kopplung\n\n## Produkt-DNA für diesen Bereich\n> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.\n\n**Übernehmen:**\n- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.\n- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.\n- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.\n\n**Bewusst vermeiden:**\n- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.\n- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.\n\n**Für genau diese Kachel:** Kopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `AUD-01` Zentrales Audit-Log-Modell\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jede sicherheitsrelevante Connector-Aktion erzeugt einen Audit-Eintrag im Core-Audit-Log\n2. Audit-Eintrag enthält Person, Zeitpunkt und betroffenen Connector\n3. Fehlende Audit-Kopplung verhindert die Aktion nicht, wird aber protokolliert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Verbindung anlegen erzeugt nachweisbaren Audit-Eintrag\n2. Zugangsdaten ändern erzeugt nachweisbaren Audit-Eintrag\n3. Ausfall des Audit-Dienstes blockiert Connector-Betrieb nicht\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-02` Prüfgate Connector-Engine\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-06: 06 connector audit kopplung core aud`\n- Branch: `feature/eng-06-06-connector-audit-kopplung-core-aud`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ERP-01", + "title": "ERP-Connector-Grundgerüst", + "epic": "ERP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "ERP-Connector, REST/SOAP-Client", + "description": "Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Verbindung zu einem Test-ERP-System lässt sich aufbauen und prüfen", + "Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar", + "Verbindungsfehler wird klar gemeldet statt stillem Abbruch" + ], + "pruefungen": [ + "Verbindungsaufbau gegen Test-ERP-System erfolgreich geprüft", + "Lese- und Schreiboperation im Test erfolgreich", + "Simulierter Verbindungsfehler wird korrekt gemeldet" + ], + "status": "Fertig", + "epicName": "ERP/CRM-Anbindung", + "epicEmoji": "📈", + "wave": 2, + "unlocks": [ + "ERP-03", + "ERP-04" + ], + "prompt": "# ERP-01 – ERP-Connector-Grundgerüst\n\n**Epic:** 📈 ERP/CRM-Anbindung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nConnector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).\n\n**Technische Grundlage:** ERP-Connector, REST/SOAP-Client\n\n## Produkt-DNA für diesen Bereich\n> Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.\n\n**Übernehmen:**\n- Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.\n- Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration.\n\n**Bewusst vermeiden:**\n- Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.\n- Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert.\n\n**Für genau diese Kachel:** Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Verbindung zu einem Test-ERP-System lässt sich aufbauen und prüfen\n2. Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar\n3. Verbindungsfehler wird klar gemeldet statt stillem Abbruch\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Verbindungsaufbau gegen Test-ERP-System erfolgreich geprüft\n2. Lese- und Schreiboperation im Test erfolgreich\n3. Simulierter Verbindungsfehler wird korrekt gemeldet\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ERP-03` Stammdaten-Abgleich\n- `ERP-04` Beleg-/Dokumentexport an ERP\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ERP-01: 01 erp connector grundgeruest`\n- Branch: `feature/erp-01-01-erp-connector-grundgeruest`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ERP-02", + "title": "CRM-Connector-Grundgerüst", + "epic": "ERP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "CRM-Connector, REST-Client", + "description": "Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Verbindung zu einem Test-CRM-System lässt sich aufbauen und prüfen", + "Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar", + "Verbindungsfehler wird klar gemeldet statt stillem Abbruch" + ], + "pruefungen": [ + "Verbindungsaufbau gegen Test-CRM-System erfolgreich geprüft", + "Lese- und Schreiboperation im Test erfolgreich", + "Simulierter Verbindungsfehler wird korrekt gemeldet" + ], + "status": "Fertig", + "epicName": "ERP/CRM-Anbindung", + "epicEmoji": "📈", + "wave": 2, + "unlocks": [ + "ERP-03", + "QA-03" + ], + "prompt": "# ERP-02 – CRM-Connector-Grundgerüst\n\n**Epic:** 📈 ERP/CRM-Anbindung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nConnector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.\n\n**Technische Grundlage:** CRM-Connector, REST-Client\n\n## Produkt-DNA für diesen Bereich\n> Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.\n\n**Übernehmen:**\n- Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.\n- Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration.\n\n**Bewusst vermeiden:**\n- Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.\n- Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert.\n\n**Für genau diese Kachel:** Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Verbindung zu einem Test-CRM-System lässt sich aufbauen und prüfen\n2. Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar\n3. Verbindungsfehler wird klar gemeldet statt stillem Abbruch\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Verbindungsaufbau gegen Test-CRM-System erfolgreich geprüft\n2. Lese- und Schreiboperation im Test erfolgreich\n3. Simulierter Verbindungsfehler wird korrekt gemeldet\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ERP-03` Stammdaten-Abgleich\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ERP-02: 02 crm connector grundgeruest`\n- Branch: `feature/erp-02-02-crm-connector-grundgeruest`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ERP-03", + "title": "Stammdaten-Abgleich (Kunden/Lieferanten)", + "epic": "ERP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Sync-Logik, Konfliktbehandlung", + "description": "Automatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.", + "dependsOn": [ + "ERP-01", + "ERP-02" + ], + "akzeptanz": [ + "Neuer Stammdatensatz im Drittsystem erscheint nach Sync in NEXARCH", + "Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben", + "Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung" + ], + "pruefungen": [ + "Neuanlage im Test-ERP nach Sync in NEXARCH sichtbar", + "Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt statt Datenverlust", + "Zeitplan-gesteuerter Lauf im Test erfolgreich" + ], + "status": "Fertig", + "epicName": "ERP/CRM-Anbindung", + "epicEmoji": "📈", + "wave": 3, + "unlocks": [ + "QA-03" + ], + "prompt": "# ERP-03 – Stammdaten-Abgleich (Kunden/Lieferanten)\n\n**Epic:** 📈 ERP/CRM-Anbindung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAutomatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.\n\n**Technische Grundlage:** Sync-Logik, Konfliktbehandlung\n\n## Produkt-DNA für diesen Bereich\n> Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.\n\n**Übernehmen:**\n- Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.\n- Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration.\n\n**Bewusst vermeiden:**\n- Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.\n- Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert.\n\n**Für genau diese Kachel:** Automatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ERP-01` ERP-Connector-Grundgerüst – Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).\n- `ERP-02` CRM-Connector-Grundgerüst – Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Neuer Stammdatensatz im Drittsystem erscheint nach Sync in NEXARCH\n2. Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben\n3. Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Neuanlage im Test-ERP nach Sync in NEXARCH sichtbar\n2. Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt statt Datenverlust\n3. Zeitplan-gesteuerter Lauf im Test erfolgreich\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ERP-04` Beleg-/Dokumentexport an ERP\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ERP-03: 03 stammdaten abgleich kunden lieferanten`\n- Branch: `feature/erp-03-03-stammdaten-abgleich-kunden-lieferanten`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ERP-04", + "title": "Beleg-/Dokumentexport an ERP", + "epic": "ERP", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Dokumentexport, Feld-Mapping", + "description": "Export von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.", + "dependsOn": [ + "ERP-01" + ], + "akzeptanz": [ + "Beleg lässt sich mit zugeordneten Metadaten an das ERP exportieren", + "Fehlgeschlagener Export wird über die Fehlerbehandlung erneut versucht", + "Bereits exportierter Beleg wird nicht doppelt übertragen" + ], + "pruefungen": [ + "Testbeleg im ERP nach Export mit korrekten Metadaten auffindbar", + "Simulierter Exportfehler löst Retry aus", + "Doppelversand im Test ausgeschlossen" + ], + "status": "Fertig", + "epicName": "ERP/CRM-Anbindung", + "epicEmoji": "📈", + "wave": 3, + "unlocks": [ + "QA-03" + ], + "prompt": "# ERP-04 – Beleg-/Dokumentexport an ERP\n\n**Epic:** 📈 ERP/CRM-Anbindung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nExport von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.\n\n**Technische Grundlage:** Dokumentexport, Feld-Mapping\n\n## Produkt-DNA für diesen Bereich\n> Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.\n\n**Übernehmen:**\n- Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.\n- Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration.\n\n**Bewusst vermeiden:**\n- Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.\n- Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert.\n\n**Für genau diese Kachel:** Export von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ERP-01` ERP-Connector-Grundgerüst – Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Beleg lässt sich mit zugeordneten Metadaten an das ERP exportieren\n2. Fehlgeschlagener Export wird über die Fehlerbehandlung erneut versucht\n3. Bereits exportierter Beleg wird nicht doppelt übertragen\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testbeleg im ERP nach Export mit korrekten Metadaten auffindbar\n2. Simulierter Exportfehler löst Retry aus\n3. Doppelversand im Test ausgeschlossen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-03` Prüfgate ERP/DATEV/M365\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ERP-04: 04 beleg dokumentexport an erp`\n- Branch: `feature/erp-04-04-beleg-dokumentexport-an-erp`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "DAT-01", + "title": "DATEV-Format-Export (Belege/Buchungsstapel)", + "epic": "DAT", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "DATEV-Exportformat, Buchungsstapel-Struktur", + "description": "Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.", + "dependsOn": [ + "ENG-01", + "RET-05" + ], + "akzeptanz": [ + "Export erzeugt gültige DATEV-Exportdatei aus Testbelegen", + "Pflichtfelder des DATEV-Formats werden vollständig befüllt oder der Export klar abgewiesen", + "Exportierter Buchungsstapel ist eindeutig einem Zeitraum zugeordnet", + "Exportiertes Objekt (Buchungsstapel) wird bei Archive RET-05 mit der GoBD-Aufbewahrungsklasse registriert, statt unregistriert im Dateisystem zu liegen" + ], + "pruefungen": [ + "Erzeugte Exportdatei besteht Formatprüfung gegen DATEV-Spezifikation", + "Fehlendes Pflichtfeld führt zu klarer Abweisung statt fehlerhaftem Export", + "Zeitraumzuordnung im Test korrekt", + "Export eines Testbuchungsstapels erzeugt nachweisbar eine Registrierung bei Archive RET-05" + ], + "status": "Fertig", + "epicName": "DATEV-Anbindung", + "epicEmoji": "🧾", + "wave": 2, + "unlocks": [ + "DAT-02", + "DAT-03" + ], + "prompt": "# DAT-01 – DATEV-Format-Export (Belege/Buchungsstapel)\n\n**Epic:** 🧾 DATEV-Anbindung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nExport von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.\n\n**Technische Grundlage:** DATEV-Exportformat, Buchungsstapel-Struktur\n\n## Produkt-DNA für diesen Bereich\n> DATEV-Export so verlässlich wie ein Airbyte-Sync-Job, mit offen dokumentiertem Format statt Blackbox-Konnektor.\n\n**Übernehmen:**\n- Airbyte: Retry und Fehlerbehandlung bei Exportläufen, damit ein fehlgeschlagener Export nicht stillschweigend verloren geht.\n- Vollständiges Exportprotokoll je Lauf, damit jeder DATEV-Export nachvollziehbar bleibt.\n\n**Bewusst vermeiden:**\n- Kein Vendor-Lock durch proprietäres DATEV-Werkzeug – das Exportformat bleibt offen dokumentiert und ohne Herstellerwerkzeug nachvollziehbar.\n- Keine stille Fehlklassifizierung von Belegen – Abweichungen werden im Protokoll sichtbar.\n\n**Für genau diese Kachel:** Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n- Setzt voraus (externes Archive-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/): `RET-05` Modul-Adapter-Schnittstelle – exportierte GoBD-relevante Buchungsstapel werden hier mit Aufbewahrungsklasse registriert, statt unregistriert im Dateisystem zu liegen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Export erzeugt gültige DATEV-Exportdatei aus Testbelegen\n2. Pflichtfelder des DATEV-Formats werden vollständig befüllt oder der Export klar abgewiesen\n3. Exportierter Buchungsstapel ist eindeutig einem Zeitraum zugeordnet\n4. Exportiertes Objekt (Buchungsstapel) wird bei Archive RET-05 mit der GoBD-Aufbewahrungsklasse registriert, statt unregistriert im Dateisystem zu liegen\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Erzeugte Exportdatei besteht Formatprüfung gegen DATEV-Spezifikation\n2. Fehlendes Pflichtfeld führt zu klarer Abweisung statt fehlerhaftem Export\n3. Zeitraumzuordnung im Test korrekt\n\n4. Export eines Testbuchungsstapels erzeugt nachweisbar eine Registrierung bei Archive RET-05\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `DAT-02` DATEV-Konnektor (Schnittstellen-Protokoll)\n- `DAT-03` DATEV-Export-Oberfläche & Protokoll\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `DAT-01: 01 datev format export belege buchungsstapel`\n- Branch: `feature/dat-01-01-datev-format-export-belege-buchungsstapel`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "DAT-02", + "title": "DATEV-Konnektor (Schnittstellen-Protokoll)", + "epic": "DAT", + "featureIds": [], + "role": "Backend", + "complexity": "Komplex", + "estimateDays": 4, + "tech": "DATEV-Schnittstellenprotokoll, Übertragungslogik", + "description": "Konnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.", + "dependsOn": [ + "DAT-01" + ], + "akzeptanz": [ + "Übertragung an ein Test-DATEV-Zielsystem gelingt protokollkonform", + "Fehlgeschlagene Übertragung wird über die Fehlerbehandlung erneut versucht", + "Übertragungsstatus ist je Lauf nachvollziehbar" + ], + "pruefungen": [ + "Protokollkonforme Übertragung im Test gegen Referenzsystem geprüft", + "Simulierter Übertragungsfehler löst Retry aus", + "Übertragungsstatus im Test korrekt und nachvollziehbar" + ], + "status": "Fertig", + "epicName": "DATEV-Anbindung", + "epicEmoji": "🧾", + "wave": 3, + "unlocks": [ + "DAT-03" + ], + "prompt": "# DAT-02 – DATEV-Konnektor (Schnittstellen-Protokoll)\n\n**Epic:** 🧾 DATEV-Anbindung | **Rolle:** Backend | **Komplexität:** Komplex | **Aufwand:** 4 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nKonnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.\n\n**Technische Grundlage:** DATEV-Schnittstellenprotokoll, Übertragungslogik\n\n## Produkt-DNA für diesen Bereich\n> DATEV-Export so verlässlich wie ein Airbyte-Sync-Job, mit offen dokumentiertem Format statt Blackbox-Konnektor.\n\n**Übernehmen:**\n- Airbyte: Retry und Fehlerbehandlung bei Exportläufen, damit ein fehlgeschlagener Export nicht stillschweigend verloren geht.\n- Vollständiges Exportprotokoll je Lauf, damit jeder DATEV-Export nachvollziehbar bleibt.\n\n**Bewusst vermeiden:**\n- Kein Vendor-Lock durch proprietäres DATEV-Werkzeug – das Exportformat bleibt offen dokumentiert und ohne Herstellerwerkzeug nachvollziehbar.\n- Keine stille Fehlklassifizierung von Belegen – Abweichungen werden im Protokoll sichtbar.\n\n**Für genau diese Kachel:** Konnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `DAT-01` DATEV-Format-Export (Belege/Buchungsstapel) – Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Übertragung an ein Test-DATEV-Zielsystem gelingt protokollkonform\n2. Fehlgeschlagene Übertragung wird über die Fehlerbehandlung erneut versucht\n3. Übertragungsstatus ist je Lauf nachvollziehbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Protokollkonforme Übertragung im Test gegen Referenzsystem geprüft\n2. Simulierter Übertragungsfehler löst Retry aus\n3. Übertragungsstatus im Test korrekt und nachvollziehbar\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `DAT-03` DATEV-Export-Oberfläche & Protokoll\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `DAT-02: 02 datev konnektor schnittstellen protokoll`\n- Branch: `feature/dat-02-02-datev-konnektor-schnittstellen-protokoll`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "DAT-03", + "title": "DATEV-Export-Oberfläche & Protokoll", + "epic": "DAT", + "featureIds": [], + "role": "Frontend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "React/Next.js-Oberfläche, Exportprotokoll-Ansicht", + "description": "Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.", + "dependsOn": [ + "DAT-01", + "DAT-02", + "SHL-01" + ], + "akzeptanz": [ + "Export lässt sich über die Oberfläche mit Zeitraum-Auswahl anstoßen", + "Exportprotokoll ist je Lauf einsehbar", + "Fehlgeschlagener Export ist in der Oberfläche klar erkennbar" + ], + "pruefungen": [ + "Export-Anstoß im Test aus der Oberfläche erfolgreich", + "Protokollansicht zeigt reale Testläufe korrekt an", + "Fehlgeschlagener Testlauf ist visuell klar unterscheidbar" + ], + "status": "Fertig", + "epicName": "DATEV-Anbindung", + "epicEmoji": "🧾", + "wave": 4, + "unlocks": [ + "QA-03" + ], + "prompt": "# DAT-03 – DATEV-Export-Oberfläche & Protokoll\n\n**Epic:** 🧾 DATEV-Anbindung | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nOberfläche und Bedienbarkeit. Keine Geschäftslogik, die serverseitig gehört.\n\n## Auftrag\nOberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.\n\n**Technische Grundlage:** React/Next.js-Oberfläche, Exportprotokoll-Ansicht\n\n## Produkt-DNA für diesen Bereich\n> DATEV-Export so verlässlich wie ein Airbyte-Sync-Job, mit offen dokumentiertem Format statt Blackbox-Konnektor.\n\n**Übernehmen:**\n- Airbyte: Retry und Fehlerbehandlung bei Exportläufen, damit ein fehlgeschlagener Export nicht stillschweigend verloren geht.\n- Vollständiges Exportprotokoll je Lauf, damit jeder DATEV-Export nachvollziehbar bleibt.\n\n**Bewusst vermeiden:**\n- Kein Vendor-Lock durch proprietäres DATEV-Werkzeug – das Exportformat bleibt offen dokumentiert und ohne Herstellerwerkzeug nachvollziehbar.\n- Keine stille Fehlklassifizierung von Belegen – Abweichungen werden im Protokoll sichtbar.\n\n**Für genau diese Kachel:** Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `DAT-01` DATEV-Format-Export (Belege/Buchungsstapel) – Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.\n- `DAT-02` DATEV-Konnektor (Schnittstellen-Protokoll) – Konnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Export lässt sich über die Oberfläche mit Zeitraum-Auswahl anstoßen\n2. Exportprotokoll ist je Lauf einsehbar\n3. Fehlgeschlagener Export ist in der Oberfläche klar erkennbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Export-Anstoß im Test aus der Oberfläche erfolgreich\n2. Protokollansicht zeigt reale Testläufe korrekt an\n3. Fehlgeschlagener Testlauf ist visuell klar unterscheidbar\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-03` Prüfgate ERP/DATEV/M365\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `DAT-03: 03 datev export oberflaeche protokoll`\n- Branch: `feature/dat-03-03-datev-export-oberflaeche-protokoll`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "M365-01", + "title": "Microsoft-Graph-API-Anbindung (Auth/Basis)", + "epic": "M365", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Microsoft Graph API, OAuth2", + "description": "Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.", + "dependsOn": [ + "ENG-02" + ], + "akzeptanz": [ + "Authentifizierung gegen Microsoft Graph im Test erfolgreich", + "Zugangsdaten werden über die Connect-Credential-Verwaltung gespeichert", + "Abgelaufene Berechtigung wird erkannt und klar gemeldet" + ], + "pruefungen": [ + "OAuth2-Anmeldung im Test gegen Microsoft-Testmandant erfolgreich", + "Testaufruf einer Graph-API-Basisoperation erfolgreich", + "Simulierter Berechtigungsablauf wird korrekt erkannt und gemeldet" + ], + "status": "Fertig", + "epicName": "Microsoft 365-Anbindung", + "epicEmoji": "☁️", + "wave": 3, + "unlocks": [ + "M365-02", + "M365-03" + ], + "prompt": "# M365-01 – Microsoft-Graph-API-Anbindung (Auth/Basis)\n\n**Epic:** ☁️ Microsoft 365-Anbindung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nBasis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.\n\n**Technische Grundlage:** Microsoft Graph API, OAuth2\n\n## Produkt-DNA für diesen Bereich\n> Microsoft-365-Anbindung als austauschbarer Connector wie bei Zapier/n8n, nicht als tief verdrahtete Speziallösung.\n\n**Übernehmen:**\n- Zapier/n8n: Microsoft Graph als ein Connector unter vielen, austauschbar über dieselbe Plugin-Schnittstelle.\n- Airbyte: Sync-Job mit Retry für SharePoint/OneDrive-Dokumentabgleich.\n\n**Bewusst vermeiden:**\n- Keine Sonderbehandlung von Microsoft 365 außerhalb des allgemeinen Connector-Modells – gleiche Credential-Verwaltung, gleiche Sync-Job-Logik.\n- Kein Vendor-Lock – der Connector bleibt ersetzbar, ohne dass NEXARCH Connect an Microsoft-Werkzeuge gebunden ist.\n\n**Für genau diese Kachel:** Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Authentifizierung gegen Microsoft Graph im Test erfolgreich\n2. Zugangsdaten werden über die Connect-Credential-Verwaltung gespeichert\n3. Abgelaufene Berechtigung wird erkannt und klar gemeldet\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. OAuth2-Anmeldung im Test gegen Microsoft-Testmandant erfolgreich\n2. Testaufruf einer Graph-API-Basisoperation erfolgreich\n3. Simulierter Berechtigungsablauf wird korrekt erkannt und gemeldet\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `M365-02` SharePoint/OneDrive-Dokumentabgleich\n- `M365-03` Outlook-Kalender-Kopplung\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `M365-01: 01 microsoft graph api anbindung auth basis`\n- Branch: `feature/m365-01-01-microsoft-graph-api-anbindung-auth-basis`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "M365-02", + "title": "SharePoint/OneDrive-Dokumentabgleich", + "epic": "M365", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "SharePoint/OneDrive-API, Sync-Logik", + "description": "Abgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.", + "dependsOn": [ + "M365-01" + ], + "akzeptanz": [ + "Dokument aus SharePoint/OneDrive erscheint nach Sync in NEXARCH mit Metadaten", + "Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben", + "Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung" + ], + "pruefungen": [ + "Testdokument aus SharePoint nach Sync in NEXARCH korrekt vorhanden", + "Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt", + "Zeitplan-gesteuerter Lauf im Test erfolgreich" + ], + "status": "Fertig", + "epicName": "Microsoft 365-Anbindung", + "epicEmoji": "☁️", + "wave": 4, + "unlocks": [ + "QA-03" + ], + "prompt": "# M365-02 – SharePoint/OneDrive-Dokumentabgleich\n\n**Epic:** ☁️ Microsoft 365-Anbindung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAbgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.\n\n**Technische Grundlage:** SharePoint/OneDrive-API, Sync-Logik\n\n## Produkt-DNA für diesen Bereich\n> Microsoft-365-Anbindung als austauschbarer Connector wie bei Zapier/n8n, nicht als tief verdrahtete Speziallösung.\n\n**Übernehmen:**\n- Zapier/n8n: Microsoft Graph als ein Connector unter vielen, austauschbar über dieselbe Plugin-Schnittstelle.\n- Airbyte: Sync-Job mit Retry für SharePoint/OneDrive-Dokumentabgleich.\n\n**Bewusst vermeiden:**\n- Keine Sonderbehandlung von Microsoft 365 außerhalb des allgemeinen Connector-Modells – gleiche Credential-Verwaltung, gleiche Sync-Job-Logik.\n- Kein Vendor-Lock – der Connector bleibt ersetzbar, ohne dass NEXARCH Connect an Microsoft-Werkzeuge gebunden ist.\n\n**Für genau diese Kachel:** Abgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `M365-01` Microsoft-Graph-API-Anbindung (Auth/Basis) – Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Dokument aus SharePoint/OneDrive erscheint nach Sync in NEXARCH mit Metadaten\n2. Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben\n3. Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testdokument aus SharePoint nach Sync in NEXARCH korrekt vorhanden\n2. Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt\n3. Zeitplan-gesteuerter Lauf im Test erfolgreich\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-03` Prüfgate ERP/DATEV/M365\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `M365-02: 02 sharepoint onedrive dokumentabgleich`\n- Branch: `feature/m365-02-02-sharepoint-onedrive-dokumentabgleich`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "M365-03", + "title": "Outlook-Kalender-Kopplung (Fristen/Wiedervorlage)", + "epic": "M365", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Outlook-Kalender-API, Fristen-Kopplung", + "description": "Kopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.", + "dependsOn": [ + "M365-01" + ], + "akzeptanz": [ + "Frist/Wiedervorlage erscheint als Kalendereintrag in Outlook", + "Änderung der Frist in NEXARCH aktualisiert den Kalendereintrag", + "Gelöschte Frist entfernt den zugehörigen Kalendereintrag" + ], + "pruefungen": [ + "Testfrist im Test-Outlook-Kalender korrekt sichtbar", + "Friständerung im Test korrekt im Kalender nachgezogen", + "Löschung im Test entfernt Kalendereintrag vollständig" + ], + "status": "Fertig", + "epicName": "Microsoft 365-Anbindung", + "epicEmoji": "☁️", + "wave": 4, + "unlocks": [ + "QA-03" + ], + "prompt": "# M365-03 – Outlook-Kalender-Kopplung (Fristen/Wiedervorlage)\n\n**Epic:** ☁️ Microsoft 365-Anbindung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nKopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.\n\n**Technische Grundlage:** Outlook-Kalender-API, Fristen-Kopplung\n\n## Produkt-DNA für diesen Bereich\n> Microsoft-365-Anbindung als austauschbarer Connector wie bei Zapier/n8n, nicht als tief verdrahtete Speziallösung.\n\n**Übernehmen:**\n- Zapier/n8n: Microsoft Graph als ein Connector unter vielen, austauschbar über dieselbe Plugin-Schnittstelle.\n- Airbyte: Sync-Job mit Retry für SharePoint/OneDrive-Dokumentabgleich.\n\n**Bewusst vermeiden:**\n- Keine Sonderbehandlung von Microsoft 365 außerhalb des allgemeinen Connector-Modells – gleiche Credential-Verwaltung, gleiche Sync-Job-Logik.\n- Kein Vendor-Lock – der Connector bleibt ersetzbar, ohne dass NEXARCH Connect an Microsoft-Werkzeuge gebunden ist.\n\n**Für genau diese Kachel:** Kopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `M365-01` Microsoft-Graph-API-Anbindung (Auth/Basis) – Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Frist/Wiedervorlage erscheint als Kalendereintrag in Outlook\n2. Änderung der Frist in NEXARCH aktualisiert den Kalendereintrag\n3. Gelöschte Frist entfernt den zugehörigen Kalendereintrag\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testfrist im Test-Outlook-Kalender korrekt sichtbar\n2. Friständerung im Test korrekt im Kalender nachgezogen\n3. Löschung im Test entfernt Kalendereintrag vollständig\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-03` Prüfgate ERP/DATEV/M365\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `M365-03: 03 outlook kalender kopplung fristen wiedervorlage`\n- Branch: `feature/m365-03-03-outlook-kalender-kopplung-fristen-wiedervorlage`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "DMS2-01", + "title": "Standardisiertes Export-/Import-Format (offen, dokumentiert)", + "epic": "DMS2", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Offenes Austauschformat, Schema-Dokumentation", + "description": "Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Format ist vollständig dokumentiert und ohne NEXARCH-Werkzeug lesbar", + "Export enthält Dokument, Metadaten und Versionsbezug", + "Format-Validierung weist fehlerhafte Dateien ab" + ], + "pruefungen": [ + "Exportierte Testdatei extern ohne NEXARCH-Werkzeug lesbar geprüft", + "Enthaltene Metadaten im Test vollständig und korrekt", + "Fehlerhafte Testdatei wird bei Validierung abgewiesen" + ], + "status": "Fertig", + "epicName": "Andere-DMS-Interoperabilität", + "epicEmoji": "🔄", + "wave": 2, + "unlocks": [ + "DMS2-02", + "QA-03" + ], + "prompt": "# DMS2-01 – Standardisiertes Export-/Import-Format (offen, dokumentiert)\n\n**Epic:** 🔄 Andere-DMS-Interoperabilität | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nOffen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.\n\n**Technische Grundlage:** Offenes Austauschformat, Schema-Dokumentation\n\n## Produkt-DNA für diesen Bereich\n> Offener Austausch mit anderen DMS-Systemen wie bei einem dokumentierten Airbyte-Konnektor, kein geschlossenes Migrationswerkzeug.\n\n**Übernehmen:**\n- Airbyte: offen dokumentiertes Austauschformat als Vorbild für Export/Import zwischen DMS-Systemen.\n- Zapier/n8n: der Import-Assistent bleibt ein austauschbarer Adapter, kein Einwegwerkzeug.\n\n**Bewusst vermeiden:**\n- Kein proprietäres, geschlossenes Migrationsformat – offen dokumentiert und ohne Herstellerwerkzeug lesbar.\n- Keine Backup-Ziel-Anbindung mit Herstellerbindung – Zugangsdaten und Protokoll bleiben austauschbar.\n\n**Für genau diese Kachel:** Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Format ist vollständig dokumentiert und ohne NEXARCH-Werkzeug lesbar\n2. Export enthält Dokument, Metadaten und Versionsbezug\n3. Format-Validierung weist fehlerhafte Dateien ab\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Exportierte Testdatei extern ohne NEXARCH-Werkzeug lesbar geprüft\n2. Enthaltene Metadaten im Test vollständig und korrekt\n3. Fehlerhafte Testdatei wird bei Validierung abgewiesen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `DMS2-02` Import-Assistent für Drittsystem-Exporte\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `DMS2-01: 01 standardisiertes export import format offen dokumentiert`\n- Branch: `feature/dms2-01-01-standardisiertes-export-import-format-offen-dokumentiert`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "DMS2-02", + "title": "Import-Assistent für Drittsystem-Exporte", + "epic": "DMS2", + "featureIds": [], + "role": "Fullstack", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Import-Assistent mit Mapping-Vorschau-Oberfläche (Next.js/React), Backend-Parser für Drittsystem-Exportformate", + "description": "Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.", + "dependsOn": [ + "DMS2-01", + "SHL-01" + ], + "akzeptanz": [ + "Testexport eines gängigen Drittsystems lässt sich einlesen", + "Feld-Mapping wird vorgeschlagen und ist vor Import änderbar", + "Import-Ergebnis mit Erfolgs-/Fehlerzahl ist einsehbar", + "Mapping-Vorschau ist eine bedienbare Oberfläche (nicht nur eine API-Antwort), in der Feldzuordnungen vor dem Import angepasst werden können" + ], + "pruefungen": [ + "Testexport eines Drittsystems im Test erfolgreich eingelesen", + "Manuelle Mapping-Korrektur im Test übernommen", + "Import-Protokoll zeigt korrekte Erfolgs-/Fehlerzahl", + "Mapping-Vorschau im Browser bedient: Zuordnung geändert, Import mit geänderter Zuordnung ausgeführt" + ], + "status": "Fertig", + "epicName": "Andere-DMS-Interoperabilität", + "epicEmoji": "🔄", + "wave": 3, + "unlocks": [ + "QA-03" + ], + "prompt": "# DMS2-02 – Import-Assistent für Drittsystem-Exporte\n\n**Epic:** 🔄 Andere-DMS-Interoperabilität | **Rolle:** Fullstack | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAssistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.\n\n**Technische Grundlage:** Import-Assistent mit Mapping-Vorschau-Oberfläche (Next.js/React), Backend-Parser für Drittsystem-Exportformate\n\n## Produkt-DNA für diesen Bereich\n> Offener Austausch mit anderen DMS-Systemen wie bei einem dokumentierten Airbyte-Konnektor, kein geschlossenes Migrationswerkzeug.\n\n**Übernehmen:**\n- Airbyte: offen dokumentiertes Austauschformat als Vorbild für Export/Import zwischen DMS-Systemen.\n- Zapier/n8n: der Import-Assistent bleibt ein austauschbarer Adapter, kein Einwegwerkzeug.\n\n**Bewusst vermeiden:**\n- Kein proprietäres, geschlossenes Migrationsformat – offen dokumentiert und ohne Herstellerwerkzeug lesbar.\n- Keine Backup-Ziel-Anbindung mit Herstellerbindung – Zugangsdaten und Protokoll bleiben austauschbar.\n\n**Für genau diese Kachel:** Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `DMS2-01` Standardisiertes Export-/Import-Format (offen, dokumentiert) – Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Testexport eines gängigen Drittsystems lässt sich einlesen\n2. Feld-Mapping wird vorgeschlagen und ist vor Import änderbar\n3. Import-Ergebnis mit Erfolgs-/Fehlerzahl ist einsehbar\n4. Mapping-Vorschau ist eine bedienbare Oberfläche (nicht nur eine API-Antwort), in der Feldzuordnungen vor dem Import angepasst werden können\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testexport eines Drittsystems im Test erfolgreich eingelesen\n2. Manuelle Mapping-Korrektur im Test übernommen\n3. Import-Protokoll zeigt korrekte Erfolgs-/Fehlerzahl\n4. Mapping-Vorschau im Browser bedient: Zuordnung geändert, Import mit geänderter Zuordnung ausgeführt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-02` Prüfgate Connector-Engine\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `DMS2-02: 02 import assistent fuer drittsystem exporte`\n- Branch: `feature/dms2-02-02-import-assistent-fuer-drittsystem-exporte`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "DMS2-03", + "title": "Externe-Backup-Ziel-Anbindung", + "epic": "DMS2", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Backup-Ziel-Connector, verschlüsselte Übertragung", + "description": "Anbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) für den verschlüsselten Export von Dokumentbeständen.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Backup-Ziel lässt sich über das Connector-Plugin-Modell einrichten", + "Export an das Backup-Ziel erfolgt verschlüsselt", + "Fehlgeschlagener Backup-Export wird über die Fehlerbehandlung erneut versucht" + ], + "pruefungen": [ + "Verbindungsaufbau zu Test-Backup-Ziel im Test erfolgreich", + "Übertragung im Test nachweislich verschlüsselt", + "Simulierter Übertragungsfehler löst Retry aus" + ], + "status": "Fertig", + "epicName": "Andere-DMS-Interoperabilität", + "epicEmoji": "🔄", + "wave": 2, + "unlocks": [ + "QA-03" + ], + "prompt": "# DMS2-03 – Externe-Backup-Ziel-Anbindung\n\n**Epic:** 🔄 Andere-DMS-Interoperabilität | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAnbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) für den verschlüsselten Export von Dokumentbeständen.\n\n**Technische Grundlage:** Backup-Ziel-Connector, verschlüsselte Übertragung\n\n## Produkt-DNA für diesen Bereich\n> Offener Austausch mit anderen DMS-Systemen wie bei einem dokumentierten Airbyte-Konnektor, kein geschlossenes Migrationswerkzeug.\n\n**Übernehmen:**\n- Airbyte: offen dokumentiertes Austauschformat als Vorbild für Export/Import zwischen DMS-Systemen.\n- Zapier/n8n: der Import-Assistent bleibt ein austauschbarer Adapter, kein Einwegwerkzeug.\n\n**Bewusst vermeiden:**\n- Kein proprietäres, geschlossenes Migrationsformat – offen dokumentiert und ohne Herstellerwerkzeug lesbar.\n- Keine Backup-Ziel-Anbindung mit Herstellerbindung – Zugangsdaten und Protokoll bleiben austauschbar.\n\n**Für genau diese Kachel:** Anbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) über das bestehende Connector-Plugin-Modell, statt einer festverdrahteten Backup-Lösung – ein neues Ziel lässt sich als weiterer Connector ergänzen, ohne den Kern anzufassen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Backup-Ziel lässt sich über das Connector-Plugin-Modell einrichten\n2. Export an das Backup-Ziel erfolgt verschlüsselt\n3. Fehlgeschlagener Backup-Export wird über die Fehlerbehandlung erneut versucht\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Verbindungsaufbau zu Test-Backup-Ziel im Test erfolgreich\n2. Übertragung im Test nachweislich verschlüsselt\n3. Simulierter Übertragungsfehler löst Retry aus\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-04` Sicherheitsprüfung Drittsystem-Credentials\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `DMS2-03: 03 externe backup ziel anbindung`\n- Branch: `feature/dms2-03-03-externe-backup-ziel-anbindung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "API-01", + "title": "Connect-Konfigurationsoberfläche (Connectoren einrichten)", + "epic": "API", + "featureIds": [], + "role": "Frontend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Next.js/React, Connector-Einrichtungsformulare", + "description": "Oberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.", + "dependsOn": [ + "ENG-02", + "ENG-04", + "SHL-01" + ], + "akzeptanz": [ + "Connector lässt sich vollständig über die Oberfläche einrichten, ohne Konfigurationsdatei", + "Zugangsdaten werden nur maskiert angezeigt, nie im Klartext", + "Feld-Mapping ist über die Oberfläche bearbeitbar" + ], + "pruefungen": [ + "Vollständige Einrichtung eines Testconnectors über die Oberfläche erfolgreich", + "Zugangsdaten in der Oberfläche im Test nachweislich maskiert", + "Mapping-Änderung über die Oberfläche im Test korrekt übernommen" + ], + "status": "Fertig", + "epicName": "Connect-Oberfläche", + "epicEmoji": "🖥️", + "wave": 3, + "unlocks": [], + "prompt": "# API-01 – Connect-Konfigurationsoberfläche (Connectoren einrichten)\n\n**Epic:** 🖥️ Connect-Oberfläche | **Rolle:** Frontend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nOberfläche und Bedienbarkeit. Keine Geschäftslogik, die serverseitig gehört.\n\n## Auftrag\nOberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.\n\n**Technische Grundlage:** Next.js/React, Connector-Einrichtungsformulare\n\n## Produkt-DNA für diesen Bereich\n> Eine schlanke Konfigurationsoberfläche für Connectoren wie bei Zapier/n8n, kein visueller Workflow-Builder.\n\n**Übernehmen:**\n- Zapier/n8n: übersichtliche Verbindungs-Einrichtung und Statusanzeige je Connector, ohne grafischen Workflow-Builder.\n- Airbyte: klare Diagnoseansicht bei fehlgeschlagenen Sync-Läufen.\n\n**Bewusst vermeiden:**\n- Kein eigener Workflow-Builder – die Oberfläche konfiguriert Connectoren, sie modelliert keine Prozesse.\n- Keine eigene Webhook-Infrastruktur – die Oberfläche nutzt ausschließlich die zentrale Core-Webhook-Registry (API-07).\n\n**Für genau diese Kachel:** Oberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n- `ENG-04` Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem) – Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Connector lässt sich vollständig über die Oberfläche einrichten, ohne Konfigurationsdatei\n2. Zugangsdaten werden nur maskiert angezeigt, nie im Klartext\n3. Feld-Mapping ist über die Oberfläche bearbeitbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Vollständige Einrichtung eines Testconnectors über die Oberfläche erfolgreich\n2. Zugangsdaten in der Oberfläche im Test nachweislich maskiert\n3. Mapping-Änderung über die Oberfläche im Test korrekt übernommen\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `API-02` Verbindungsstatus-Übersicht & Diagnose\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `API-01: 01 connect konfigurationsoberflaeche connectoren einrichten`\n- Branch: `feature/api-01-01-connect-konfigurationsoberflaeche-connectoren-einrichten`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "API-02", + "title": "Verbindungsstatus-Übersicht & Diagnose", + "epic": "API", + "featureIds": [], + "role": "Frontend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Next.js/React, Statusanzeige", + "description": "Übersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.", + "dependsOn": [ + "ENG-05", + "SHL-01" + ], + "akzeptanz": [ + "Verbindungsstatus je Connector ist auf einen Blick erkennbar", + "Letzter Sync-Lauf mit Ergebnis ist einsehbar", + "Fehlerdiagnose zeigt die Ursache aus dem Fehlerprotokoll" + ], + "pruefungen": [ + "Statusanzeige im Test korrekt für erfolgreichen und fehlgeschlagenen Lauf", + "Diagnoseansicht zeigt reale Testfehler nachvollziehbar an", + "Aktualisierung nach neuem Sync-Lauf im Test korrekt" + ], + "status": "Fertig", + "epicName": "Connect-Oberfläche", + "epicEmoji": "🖥️", + "wave": 4, + "unlocks": [], + "prompt": "# API-02 – Verbindungsstatus-Übersicht & Diagnose\n\n**Epic:** 🖥️ Connect-Oberfläche | **Rolle:** Frontend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 4\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nOberfläche und Bedienbarkeit. Keine Geschäftslogik, die serverseitig gehört.\n\n## Auftrag\nÜbersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.\n\n**Technische Grundlage:** Next.js/React, Statusanzeige\n\n## Produkt-DNA für diesen Bereich\n> Eine schlanke Konfigurationsoberfläche für Connectoren wie bei Zapier/n8n, kein visueller Workflow-Builder.\n\n**Übernehmen:**\n- Zapier/n8n: übersichtliche Verbindungs-Einrichtung und Statusanzeige je Connector, ohne grafischen Workflow-Builder.\n- Airbyte: klare Diagnoseansicht bei fehlgeschlagenen Sync-Läufen.\n\n**Bewusst vermeiden:**\n- Kein eigener Workflow-Builder – die Oberfläche konfiguriert Connectoren, sie modelliert keine Prozesse.\n- Keine eigene Webhook-Infrastruktur – die Oberfläche nutzt ausschließlich die zentrale Core-Webhook-Registry (API-07).\n\n**Für genau diese Kachel:** Übersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen – Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.\n- Core `SHL-01` UI-Shell & Design-System (zentral) – zentrales Design-System mit WCAG-AA, i18n-Rahmen und Theming; Modul-Oberflächen erben diese Eigenschaften strukturell statt sie einzeln zu bauen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Verbindungsstatus je Connector ist auf einen Blick erkennbar\n2. Letzter Sync-Lauf mit Ergebnis ist einsehbar\n3. Fehlerdiagnose zeigt die Ursache aus dem Fehlerprotokoll\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Statusanzeige im Test korrekt für erfolgreichen und fehlgeschlagenen Lauf\n2. Diagnoseansicht zeigt reale Testfehler nachvollziehbar an\n3. Aktualisierung nach neuem Sync-Lauf im Test korrekt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-02` Prüfgate Connector-Engine\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `API-02: 02 verbindungsstatus uebersicht diagnose`\n- Branch: `feature/api-02-02-verbindungsstatus-uebersicht-diagnose`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "API-03", + "title": "Externe Webhook-Abonnements (nutzt Core API-07)", + "epic": "API", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Core-Webhook-Registry-Anbindung", + "description": "Abonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.", + "dependsOn": [ + "ENG-01" + ], + "akzeptanz": [ + "Connector kann ein Webhook-Ereignis über die Core-Webhook-Registry abonnieren", + "Zugestelltes Ereignis löst die zugeordnete Connector-Aktion aus", + "Abbestellen entfernt das Abonnement vollständig" + ], + "pruefungen": [ + "Testabonnement über Core-Webhook-Registry im Test erfolgreich registriert", + "Testereignis löst im Test die erwartete Connector-Aktion aus", + "Abbestellung im Test vollständig entfernt" + ], + "status": "Fertig", + "epicName": "Connect-Oberfläche", + "epicEmoji": "🖥️", + "wave": 2, + "unlocks": [], + "prompt": "# API-03 – Externe Webhook-Abonnements (nutzt Core API-07)\n\n**Epic:** 🖥️ Connect-Oberfläche | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAbonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.\n\n**Technische Grundlage:** Core-Webhook-Registry-Anbindung\n\n## Produkt-DNA für diesen Bereich\n> Eine schlanke Konfigurationsoberfläche für Connectoren wie bei Zapier/n8n, kein visueller Workflow-Builder.\n\n**Übernehmen:**\n- Zapier/n8n: übersichtliche Verbindungs-Einrichtung und Statusanzeige je Connector, ohne grafischen Workflow-Builder.\n- Airbyte: klare Diagnoseansicht bei fehlgeschlagenen Sync-Läufen.\n\n**Bewusst vermeiden:**\n- Kein eigener Workflow-Builder – die Oberfläche konfiguriert Connectoren, sie modelliert keine Prozesse.\n- Keine eigene Webhook-Infrastruktur – die Oberfläche nutzt ausschließlich die zentrale Core-Webhook-Registry (API-07).\n\n**Für genau diese Kachel:** Abonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-07` Zentrale Webhook-Registry & Zustellung\n- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Connector kann ein Webhook-Ereignis über die Core-Webhook-Registry abonnieren\n2. Zugestelltes Ereignis löst die zugeordnete Connector-Aktion aus\n3. Abbestellen entfernt das Abonnement vollständig\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testabonnement über Core-Webhook-Registry im Test erfolgreich registriert\n2. Testereignis löst im Test die erwartete Connector-Aktion aus\n3. Abbestellung im Test vollständig entfernt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-02` Prüfgate Connector-Engine\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `API-03: 03 externe webhook abonnements nutzt core api 07`\n- Branch: `feature/api-03-03-externe-webhook-abonnements-nutzt-core-api-07`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-01", + "title": "Teststrategie Connect", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Testkorpus, Teststrategie-Dokument", + "description": "Teststrategie für Connect: Testkorpus aus realen Drittsystem-Antworten (ERP, CRM, DATEV, Microsoft Graph), Testarten je Ausbaustufe, Freigabekriterien.", + "dependsOn": [], + "akzeptanz": [ + "Teststrategie ist dokumentiert und für alle Epics anwendbar", + "Testkorpus enthält reale Beispieldaten je angebundenem Drittsystemtyp", + "Freigabekriterien je Prüfgate sind eindeutig benannt", + "Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01" + ], + "pruefungen": [ + "Teststrategie-Dokument liegt vollständig vor und wurde geprüft", + "Testkorpus im Test auf Vollständigkeit je Systemtyp geprüft", + "Freigabekriterien im Test auf Eindeutigkeit geprüft" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 1, + "unlocks": [], + "prompt": "# QA-01 – Teststrategie Connect\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 1\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nTeststrategie für Connect: Testkorpus aus realen Drittsystem-Antworten (ERP, CRM, DATEV, Microsoft Graph), Testarten je Ausbaustufe, Freigabekriterien.\n\n**Technische Grundlage:** Testkorpus, Teststrategie-Dokument\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.\n- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.\n\n**Für genau diese Kachel:** Teststrategie für Connect: Testkorpus aus realen Drittsystem-Antworten (ERP, CRM, DATEV, Microsoft Graph), Testarten je Ausbaustufe, Freigabekriterien.\n\n## Ausgangslage\nDiese Kachel hat keine Vorbedingungen und ist sofort startbar.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Teststrategie ist dokumentiert und für alle Epics anwendbar\n2. Testkorpus enthält reale Beispieldaten je angebundenem Drittsystemtyp\n3. Freigabekriterien je Prüfgate sind eindeutig benannt\n\n4. Pflichttests für sicherheitsrelevanten Code (Tenant-Scoping, Zugriffsprüfung, Auth-nahe Logik) sind als verbindliches Merge-Gate verankert – kein Merge auf solchen Code ohne Test, analog Core QA-01\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Teststrategie-Dokument liegt vollständig vor und wurde geprüft\n2. Testkorpus im Test auf Vollständigkeit je Systemtyp geprüft\n3. Freigabekriterien im Test auf Eindeutigkeit geprüft\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-02` Prüfgate Connector-Engine\n- `QA-03` Prüfgate ERP/DATEV/M365\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-01: 01 teststrategie connect`\n- Branch: `feature/qa-01-01-teststrategie-connect`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-02", + "title": "Prüfgate Connector-Engine", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Prüfprotokoll, automatisierte Tests", + "description": "Verbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).", + "dependsOn": [ + "ENG-06", + "ENG-02", + "ENG-03", + "ENG-04", + "ENG-05" + ], + "akzeptanz": [ + "Alle Akzeptanzkriterien der ENG-Kacheln sind geprüft und protokolliert", + "Automatisierte Tests der ENG-Kacheln laufen fehlerfrei", + "Prüfprotokoll ist abgelegt und nachlesbar" + ], + "pruefungen": [ + "Vollständiger Testlauf über alle ENG-Kacheln durchgeführt und protokolliert", + "Fehlerinjektion (Drittsystem-Ausfall) im Test korrekt behandelt", + "Audit-Kopplung im Test nachweislich vollständig" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 3, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-02 – Prüfgate Connector-Engine\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVerbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).\n\n**Technische Grundlage:** Prüfprotokoll, automatisierte Tests\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.\n- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.\n\n**Für genau diese Kachel:** Verbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-06` Connector-Audit-Kopplung (Core AUD) – Kopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.\n- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n- `ENG-03` Sync-Job-Verwaltung (periodische Imports/Exports) – Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.\n- `ENG-04` Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem) – Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.\n- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen – Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle Akzeptanzkriterien der ENG-Kacheln sind geprüft und protokolliert\n2. Automatisierte Tests der ENG-Kacheln laufen fehlerfrei\n3. Prüfprotokoll ist abgelegt und nachlesbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Vollständiger Testlauf über alle ENG-Kacheln durchgeführt und protokolliert\n2. Fehlerinjektion (Drittsystem-Ausfall) im Test korrekt behandelt\n3. Audit-Kopplung im Test nachweislich vollständig\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-05` Abnahme-Prüfung Connect\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-02: 02 pruefgate connector engine`\n- Branch: `feature/qa-02-02-pruefgate-connector-engine`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-03", + "title": "Prüfgate ERP/DATEV/M365", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Prüfprotokoll, automatisierte Tests", + "description": "Verbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.", + "dependsOn": [ + "ERP-04", + "DAT-03", + "M365-03", + "ERP-02", + "ERP-03", + "M365-02", + "DMS2-01", + "DMS2-02", + "DMS2-03" + ], + "akzeptanz": [ + "Alle Akzeptanzkriterien der ERP-, DAT- und M365-Kacheln sind geprüft und protokolliert", + "Automatisierte Tests laufen fehlerfrei gegen Testsysteme", + "Prüfprotokoll ist abgelegt und nachlesbar", + "Alle Akzeptanzkriterien der DMS2-Kacheln (Interoperabilität mit Drittsystemen) sind ebenfalls geprüft und protokolliert" + ], + "pruefungen": [ + "Vollständiger Testlauf über ERP-, DAT- und M365-Kacheln durchgeführt und protokolliert", + "Mindestens ein echter Testlauf je Drittsystemtyp durchgeführt", + "Fehlerbehandlung bei simuliertem Ausfall je Systemtyp geprüft" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 5, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-03 – Prüfgate ERP/DATEV/M365\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVerbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.\n\n**Technische Grundlage:** Prüfprotokoll, automatisierte Tests\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.\n- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.\n\n**Für genau diese Kachel:** Verbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ERP-04` Beleg-/Dokumentexport an ERP – Export von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.\n- `DAT-03` DATEV-Export-Oberfläche & Protokoll – Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.\n- `M365-03` Outlook-Kalender-Kopplung (Fristen/Wiedervorlage) – Kopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.\n- `ERP-02` CRM-Connector-Grundgerüst – Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.\n- `ERP-03` Stammdaten-Abgleich (Kunden/Lieferanten) – Automatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.\n- `M365-02` SharePoint/OneDrive-Dokumentabgleich – Abgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.\n- `DMS2-01` Standardisiertes Export-/Import-Format (offen, dokumentiert) – Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.\n- `DMS2-02` Import-Assistent für Drittsystem-Exporte – Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.\n- `DMS2-03` Externe-Backup-Ziel-Anbindung – Anbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) für den verschlüsselten Export von Dokumentbeständen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle Akzeptanzkriterien der ERP-, DAT- und M365-Kacheln sind geprüft und protokolliert\n2. Automatisierte Tests laufen fehlerfrei gegen Testsysteme\n3. Prüfprotokoll ist abgelegt und nachlesbar\n4. Alle Akzeptanzkriterien der DMS2-Kacheln (Interoperabilität mit Drittsystemen) sind ebenfalls geprüft und protokolliert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Vollständiger Testlauf über ERP-, DAT- und M365-Kacheln durchgeführt und protokolliert\n2. Mindestens ein echter Testlauf je Drittsystemtyp durchgeführt\n3. Fehlerbehandlung bei simuliertem Ausfall je Systemtyp geprüft\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-05` Abnahme-Prüfung Connect\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-03: 03 pruefgate erp datev m365`\n- Branch: `feature/qa-03-03-pruefgate-erp-datev-m365`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-04", + "title": "Sicherheitsprüfung Drittsystem-Credentials", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Sicherheitsprüfung, Penetrationstest-Checkliste", + "description": "Gezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.", + "dependsOn": [ + "ENG-02" + ], + "akzeptanz": [ + "Verschlüsselung der Zugangsdaten besteht die Sicherheitsprüfung", + "Zugriff auf Zugangsdaten ist auf berechtigte Rollen beschränkt", + "Schlüsselverwaltung folgt dokumentierten Sicherheitsvorgaben" + ], + "pruefungen": [ + "Verschlüsselungsprüfung gegen Datenbankinhalt durchgeführt und protokolliert", + "Zugriffsprüfung mit unberechtigter Rolle im Test abgewiesen", + "Schlüsselrotation im Test ohne Datenverlust durchgeführt" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 3, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-04 – Sicherheitsprüfung Drittsystem-Credentials\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nGezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.\n\n**Technische Grundlage:** Sicherheitsprüfung, Penetrationstest-Checkliste\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.\n- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.\n\n**Für genau diese Kachel:** Gezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Verschlüsselung der Zugangsdaten besteht die Sicherheitsprüfung\n2. Zugriff auf Zugangsdaten ist auf berechtigte Rollen beschränkt\n3. Schlüsselverwaltung folgt dokumentierten Sicherheitsvorgaben\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Verschlüsselungsprüfung gegen Datenbankinhalt durchgeführt und protokolliert\n2. Zugriffsprüfung mit unberechtigter Rolle im Test abgewiesen\n3. Schlüsselrotation im Test ohne Datenverlust durchgeführt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `QA-05` Abnahme-Prüfung Connect\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-04: 04 sicherheitspruefung drittsystem credentials`\n- Branch: `feature/qa-04-04-sicherheitspruefung-drittsystem-credentials`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-05", + "title": "Abnahme-Prüfung Connect", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Einfach", + "estimateDays": 2, + "tech": "Abnahmeprotokoll", + "description": "Abschließende Abnahme-Prüfung von NEXARCH Connect über alle Epics hinweg, Freigabe zur Nutzung durch andere Module.", + "dependsOn": [ + "QA-02", + "QA-03", + "QA-04", + "QA-06", + "QA-07", + "QA-08" + ], + "akzeptanz": [ + "Alle vorgelagerten Prüfgates sind abgeschlossen und protokolliert", + "Zusammenspiel aller Connectoren im Gesamttest geprüft", + "Abnahmeprotokoll ist abgelegt und nachlesbar" + ], + "pruefungen": [ + "Gesamttest über alle Connectoren durchgeführt und protokolliert", + "Zusammenspiel mit Core-Webhook-Registry im Test geprüft", + "Abnahmeprotokoll vollständig und nachvollziehbar abgelegt" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 6, + "unlocks": [], + "prompt": "# QA-05 – Abnahme-Prüfung Connect\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nAbschließende Abnahme-Prüfung von NEXARCH Connect über alle Epics hinweg, Freigabe zur Nutzung durch andere Module.\n\n**Technische Grundlage:** Abnahmeprotokoll\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.\n- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.\n\n**Für genau diese Kachel:** Abschließende Abnahme-Prüfung von NEXARCH Connect über alle Epics hinweg, Freigabe zur Nutzung durch andere Module.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `QA-02` Prüfgate Connector-Engine – Verbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).\n- `QA-03` Prüfgate ERP/DATEV/M365 – Verbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.\n- `QA-04` Sicherheitsprüfung Drittsystem-Credentials – Gezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.\n- `QA-06` Schnittstellen-Vertragstests – Vertragstests für externe Webhook-Abonnements (API-03) – anders als bei internen Modul-zu-Modul-Schnittstellen sind hier externe Drittsysteme die Konsumenten, ein Breaking Change trifft Kunden direkt, nicht nur ein anderes NEXARCH-Modul.\n- `QA-07` Last- & Leistungstest – Lasttest für Connect unter realistischer Last aus mehreren gleichzeitig synchronisierenden Connector-Instanzen (ERP, DATEV, M365) – insbesondere Credential-Verwaltung (ENG-02) und Sync-Job-Queue unter Last.\n- `QA-08` Barrierefreiheits-Audit – Unabhängige Prüfung aller Connect-Oberflächen (DATEV-Export-Oberfläche, Import-Assistent, Connect-Konfigurationsoberfläche, Verbindungsstatus-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle vorgelagerten Prüfgates sind abgeschlossen und protokolliert\n2. Zusammenspiel aller Connectoren im Gesamttest geprüft\n3. Abnahmeprotokoll ist abgelegt und nachlesbar\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Gesamttest über alle Connectoren durchgeführt und protokolliert\n2. Zusammenspiel mit Core-Webhook-Registry im Test geprüft\n3. Abnahmeprotokoll vollständig und nachvollziehbar abgelegt\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Keine weiteren offenen Punkte.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-05: 05 abnahme pruefung connect`\n- Branch: `feature/qa-05-05-abnahme-pruefung-connect`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-06", + "title": "Schnittstellen-Vertragstests", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Vertragstests (Consumer-Driven Contracts), CI-Pipeline", + "description": "Vertragstests für externe Webhook-Abonnements (API-03) – anders als bei internen Modul-zu-Modul-Schnittstellen sind hier externe Drittsysteme die Konsumenten, ein Breaking Change trifft Kunden direkt, nicht nur ein anderes NEXARCH-Modul.", + "dependsOn": [ + "API-03" + ], + "akzeptanz": [ + "Vertragstests decken das Webhook-Abonnement-Format vollständig ab", + "Absichtlich brechender Schema-Wechsel lässt Tests fehlschlagen", + "Tests laufen automatisiert in der CI" + ], + "pruefungen": [ + "Testlauf gegen aktuellen Stand grün", + "Simulierte Breaking Change erkannt", + "CI-Integration nachgewiesen" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 3, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-06 – Schnittstellen-Vertragstests\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nVertragstests für externe Webhook-Abonnements (API-03) – anders als bei internen Modul-zu-Modul-Schnittstellen sind hier externe Drittsysteme die Konsumenten, ein Breaking Change trifft Kunden direkt, nicht nur ein anderes NEXARCH-Modul.\n\n**Technische Grundlage:** Vertragstests (Consumer-Driven Contracts), CI-Pipeline\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Fester Vertragskorpus für das Webhook-Abonnement-Format, an dem Kompatibilität wiederholbar geprüft wird.\n- Nachgewiesene Erkennung von Breaking Changes als Freigabevoraussetzung, bevor ein externes Drittsystem betroffen ist.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n- Keine Prüfung nur gegen Mock-Antworten ohne Abgleich mit dem tatsächlich ausgelieferten Webhook-Format.\n\n**Für genau diese Kachel:** Bei externen Webhook-Konsumenten (Drittsysteme, nicht andere NEXARCH-Module) ist ein unangekündigter Breaking Change besonders teuer – der Kunde merkt es erst, wenn sein System nicht mehr reagiert, nicht durch einen internen CI-Fehlschlag bei uns.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `API-03` Externe Webhook-Abonnements (nutzt Core API-07) – Abonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Vertragstests decken das Webhook-Abonnement-Format vollständig ab\n2. Absichtlich brechender Schema-Wechsel lässt Tests fehlschlagen\n3. Tests laufen automatisiert in der CI\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Testlauf gegen aktuellen Stand grün\n2. Simulierte Breaking Change erkannt\n3. CI-Integration nachgewiesen\n\n## Nicht Bestandteil dieser Kachel\n- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-06: schnittstellen-vertragstests`\n- Branch: `feature/qa-06-schnittstellen-vertragstests`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-07", + "title": "Last- & Leistungstest", + "epic": "QA", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Lastgenerator, Messprotokoll", + "description": "Lasttest für Connect unter realistischer Last aus mehreren gleichzeitig synchronisierenden Connector-Instanzen (ERP, DATEV, M365) – insbesondere Credential-Verwaltung (ENG-02) und Sync-Job-Queue unter Last.", + "dependsOn": [ + "ENG-02" + ], + "akzeptanz": [ + "Definierte Ziel-Latenz für Credential-Abruf unter Last mehrerer gleichzeitiger Connector-Instanzen eingehalten", + "Sync-Job-Queue verarbeitet viele gleichzeitig eingereihte Jobs ohne Verklemmung oder Doppelverarbeitung", + "Rate-Limiting gegenüber Drittsystemen bleibt unter Mehrinstanz-Last korrekt eingehalten" + ], + "pruefungen": [ + "Lasttest mit simulierten parallelen Sync-Jobs mehrerer Connector-Typen durchgeführt, Ergebnis dokumentiert", + "Test auf Doppelverarbeitung/Verklemmung der Job-Queue unter Last", + "Rate-Limit-Verhalten gegenüber Drittsystemen bei mehreren gleichzeitigen Connector-Instanzen geprüft" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 6, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-07 – Last- & Leistungstest\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.\nGo-Backend (net/http, pgx/v5, PostgreSQL, kein ORM), bcrypt, Postgres-Jobqueue statt Redis, Next.js/React/TypeScript-Frontend, natives systemd-Deployment. Multi-Tenancy Modell A.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nLasttest für Connect unter realistischer Last aus mehreren gleichzeitig synchronisierenden Connector-Instanzen (ERP, DATEV, M365) – insbesondere Credential-Verwaltung (ENG-02) und Sync-Job-Queue unter Last.\n\n**Technische Grundlage:** Lastgenerator, Messprotokoll\n\n## Produkt-DNA für diesen Bereich\n> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.\n\n**Übernehmen:**\n- Nachgewiesene Prüfergebnisse als Freigabevoraussetzung, wie in allen anderen Boards.\n\n**Bewusst vermeiden:**\n- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.\n\n**Für genau diese Kachel:** Connect spricht mehrere Drittsysteme gleichzeitig an – ohne Lasttest bleibt unklar, ob Credential-Verwaltung und Job-Queue das verkraften, ohne Rate-Limits von ERP/DATEV/M365 zu verletzen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt) – Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Definierte Ziel-Latenz für Credential-Abruf unter Last mehrerer gleichzeitiger Connector-Instanzen eingehalten\n2. Sync-Job-Queue verarbeitet viele gleichzeitig eingereihte Jobs ohne Verklemmung oder Doppelverarbeitung\n3. Rate-Limiting gegenüber Drittsystemen bleibt unter Mehrinstanz-Last korrekt eingehalten\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Lasttest mit simulierten parallelen Sync-Jobs mehrerer Connector-Typen durchgeführt, Ergebnis dokumentiert\n2. Test auf Doppelverarbeitung/Verklemmung der Job-Queue unter Last\n3. Rate-Limit-Verhalten gegenüber Drittsystemen bei mehreren gleichzeitigen Connector-Instanzen geprüft\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- (keine direkt abhängigen Kacheln bekannt)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `QA-07: last leistungstest`\n- Branch: `feature/qa-07-last-leistungstest`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "QA-08", + "title": "Barrierefreiheits-Audit", + "epic": "QA", + "featureIds": [], + "role": "QA", + "complexity": "Mittel", + "estimateDays": 3, + "tech": "Prüfwerkzeuge, Bildschirmleser", + "description": "Unabhängige Prüfung aller Connect-Oberflächen (DATEV-Export-Oberfläche, Import-Assistent, Connect-Konfigurationsoberfläche, Verbindungsstatus-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.", + "dependsOn": [ + "DAT-03", + "DMS2-02", + "API-01", + "API-02" + ], + "akzeptanz": [ + "Keine kritischen Verstöße offen", + "Manueller Bildschirmleser-Durchlauf dokumentiert", + "Restbefunde sind mit Frist eingeplant" + ], + "pruefungen": [ + "Automatisierte Prüfung über alle Hauptseiten", + "Vollständiger Ablauf ohne Maus durchgeführt", + "Auditbericht abgelegt" + ], + "status": "Fertig", + "epicName": "Prüfungen & Qualitätssicherung", + "epicEmoji": "✅", + "wave": 5, + "unlocks": [ + "QA-05" + ], + "prompt": "# QA-08 – Barrierefreiheits-Audit\n\n**Epic:** ✅ Prüfungen & Qualitätssicherung | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5\n\n---\n\n## Rolle\nDu bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele).\nUnabhängige Prüfung gegen die dokumentierten Akzeptanzkriterien – kein Wiederholen der Entwicklertests.\n\n## Auftrag\nUnabhängige Prüfung aller Connect-Oberflächen (DATEV-Export-Oberfläche, Import-Assistent, Connect-Konfigurationsoberfläche, Verbindungsstatus-Übersicht) gegen WCAG 2.1 AA mit Werkzeugen und manuellem Durchlauf, gegen die von Core SHL-01 geerbten Basis-Komponenten sowie modulspezifische Ergänzungen.\n\n**Technische Grundlage:** Prüfwerkzeuge, Bildschirmleser\n\n## Produkt-DNA für diesen Bereich\n> Barrierefreiheit ist Grundeigenschaft der Core-SHL-01-Basis, keine Nachrüstung je Modul – dieses Audit prüft, ob Connect sie tatsächlich geerbt statt umgangen hat.\n\n**Übernehmen:**\n- Core SHL-01: WCAG 2.1 AA als verbindliche Eigenschaft der Basis-Komponenten.\n\n**Bewusst vermeiden:**\n- Kein eigenes, modulspezifisches Barrierefreiheits-Konzept parallel zu SHL-01.\n\n**Für genau diese Kachel:** Ohne dieses Audit bleibt offen, ob Connect-Oberflächen die von SHL-01 geerbten WCAG-Eigenschaften tatsächlich nutzen oder lokal umgehen.\n\n## Ausgangslage\nDie folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:\n- `DAT-03` DATEV-Export-Oberfläche & Protokoll – Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.\n- `DMS2-02` Import-Assistent für Drittsystem-Exporte – Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.\n- `API-01` Connect-Konfigurationsoberfläche (Connectoren einrichten) – Oberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.\n- `API-02` Verbindungsstatus-Übersicht & Diagnose – Übersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.\n- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `SHL-01` UI-Shell & Design-System – liefert die WCAG-2.1-AA-Basis-Komponenten, gegen die alle oben genannten Oberflächen geprüft werden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Keine kritischen Verstöße offen\n2. Manueller Bildschirmleser-Durchlauf dokumentiert\n3. Restbefunde sind mit Frist eingeplant\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Automatisierte Prüfung über alle Hauptseiten\n2. Vollständiger Ablauf ohne Maus durchgeführt\n3. Auditbericht abgelegt\n\n## Bekannte Fehler vermeiden\nWCAG war ursprünglich nur in DMS und Mail als eigene Kachel geplant – Connect hätte ungeprüft geblieben, obwohl die Oberflächen dieselbe Core-SHL-01-Basis nutzen. Audit deshalb als eigene Kachel je Board, analog DMS QA-11 und Mail QA-08.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- Core `SHL-01` WCAG-Basis-Komponenten selbst (diese Kachel prüft nur die Nutzung).\n- Behebung gefundener Verstöße in den jeweiligen Frontend-Kacheln.\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n" + }, + { + "code": "ENG-07", + "title": "Drittsystem-Zugangsdaten über Core-Tenant-KEK-Hierarchie verschlüsseln", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Envelope-Encryption (Tenant-KEK aus Core API-10), PostgreSQL, Go", + "description": "ENG-02 speichert Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys) verschlüsselt, ohne festzulegen, mit welchem Schlüssel. Analog zu DMS `IAM-19` müssen diese Zugangsdaten über den Tenant-KEK aus der Core-Schlüsselhierarchie (API-10) verschlüsselt werden statt über ein separates, eigenes Verschlüsselungsschema – sonst entsteht neben der zentralen Schlüsselverwaltung ein zweiter, unabhängig zu härtender Verschlüsselungspfad für hochsensible Zugangsdaten.", + "dependsOn": [ + "ENG-02" + ], + "akzeptanz": [ + "Drittsystem-Zugangsdaten (OAuth-Tokens, API-Keys) sind in der Datenbank ausschließlich verschlüsselt über den Tenant-KEK des jeweiligen Mandanten gespeichert", + "Ein direkter Lesezugriff auf die Zugangsdaten-Tabelle liefert keinen verwertbaren Klartext", + "Bestehende Connector-Authentifizierung aus ENG-02 funktioniert nach der Umstellung unverändert" + ], + "pruefungen": [ + "Test: Zugangsdaten in der Datenbank direkt auslesen, prüfen dass nur Chiffrat sichtbar ist", + "Regressionstest: Connector-Verbindungsaufbau (ERP/DATEV/M365/DMS2) funktioniert nach Umstellung auf Tenant-KEK-Verschlüsselung weiterhin", + "Test: Entschlüsselung schlägt fehl, wenn der falsche Tenant-KEK verwendet wird (kein Cross-Tenant-Zugriff auf Drittsystem-Credentials)" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 7, + "unlocks": [], + "prompt": "# ENG-07 – Drittsystem-Zugangsdaten über Core-Tenant-KEK-Hierarchie verschlüsseln\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 7\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nENG-02 speichert Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys) verschlüsselt, ohne festzulegen, mit welchem Schlüssel. Analog zu DMS `IAM-19` müssen diese Zugangsdaten über den Tenant-KEK aus der Core-Schlüsselhierarchie (API-10) verschlüsselt werden statt über ein separates, eigenes Verschlüsselungsschema – sonst entsteht neben der zentralen Schlüsselverwaltung ein zweiter, unabhängig zu härtender Verschlüsselungspfad für hochsensible Zugangsdaten.\n\n**Technische Grundlage:** Envelope-Encryption (Tenant-KEK aus Core API-10), PostgreSQL, Go\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Zitadel: Föderations-/Drittsystem-Credentials werden über dieselbe zentrale Schlüsselverwaltung geschützt wie andere sensible Tenant-Daten.\n\n**Bewusst vermeiden:**\n- Airbyte (verbreitetes Anti-Muster bei Connector-Plattformen) – Connector-Credentials teils in einem separaten, eigenen Secret-Store statt der zentralen Schlüsselverwaltung der Plattform.: genau eine Schlüsselhierarchie für alle sensiblen Tenant-Daten, kein zweiter Pfad für Connector-Zugangsdaten.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ENG-02.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Drittsystem-Zugangsdaten (OAuth-Tokens, API-Keys) sind in der Datenbank ausschließlich verschlüsselt über den Tenant-KEK des jeweiligen Mandanten gespeichert\n2. Ein direkter Lesezugriff auf die Zugangsdaten-Tabelle liefert keinen verwertbaren Klartext\n3. Bestehende Connector-Authentifizierung aus ENG-02 funktioniert nach der Umstellung unverändert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Zugangsdaten in der Datenbank direkt auslesen, prüfen dass nur Chiffrat sichtbar ist\n2. Regressionstest: Connector-Verbindungsaufbau (ERP/DATEV/M365/DMS2) funktioniert nach Umstellung auf Tenant-KEK-Verschlüsselung weiterhin\n3. Test: Entschlüsselung schlägt fehl, wenn der falsche Tenant-KEK verwendet wird (kein Cross-Tenant-Zugriff auf Drittsystem-Credentials)\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Connect-Board, 2026-09-12), analog zu DMS-Finding `IAM-19`: ein separates Verschlüsselungsschema für Connector-Credentials wäre ein zweiter, unabhängig zu prüfender Sicherheitsmechanismus statt der Wiederverwendung der bereits gehärteten Core-Schlüsselhierarchie.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-07: drittsystem-zugangsdaten-ber-core-tenant-kek-hierarchie-verschl-sseln`\n- Branch: `feature/eng-07-drittsystem-zugangsdaten-ber-core-tenant-kek-hierarchie-verschl-sseln`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-08", + "title": "Ressourcenlimits & Rate-Limiting für Drittsystem-Sync-Jobs", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Postgres-Jobqueue, Rate-Limiting, Ressourcenlimits (Zeit/Datenmenge)", + "description": "ENG-03 verwaltet periodische Sync-Jobs, ENG-05 behandelt Fehler bei Drittsystem-Ausfällen mit Retry/Backoff, ohne Obergrenzen für Laufzeit oder Datenmenge je Sync-Lauf festzulegen. Ein fehlerhaft konfigurierter oder kompromittierter Connector (z. B. ein Drittsystem, das ungewöhnlich große Antworten liefert oder in einer Retry-Schleife hängen bleibt) kann sonst Ressourcen auf Kosten anderer Mandanten/Connectoren binden. Harte Obergrenzen je Sync-Lauf definieren (max. Laufzeit, max. übertragene Datenmenge, max. Anzahl Retry-Versuche als Abbruchgrenze aus ENG-05) sowie Rate-Limiting für ausgehende Anfragen an ein einzelnes Drittsystem.", + "dependsOn": [ + "ENG-03", + "ENG-05" + ], + "akzeptanz": [ + "Jeder Sync-Job hat konfigurierbare Obergrenzen für Laufzeit und übertragene Datenmenge", + "Die Abbruchgrenze für Retry-Versuche aus ENG-05 wird durchgesetzt, ein Job endet nach Erreichen der Grenze kontrolliert statt endlos zu wiederholen", + "Ausgehende Anfragen an ein einzelnes Drittsystem sind ratenbegrenzt, sodass ein einzelner Connector nicht das gesamte Sync-System für andere Connectoren/Mandanten blockiert" + ], + "pruefungen": [ + "Test: Sync-Job, der die Laufzeit-/Datenmengenobergrenze überschreitet, wird kontrolliert abgebrochen", + "Test: Retry-Abbruchgrenze aus ENG-05 wird nach der konfigurierten Anzahl Versuche tatsächlich durchgesetzt", + "Lasttest: ein Connector mit Drittsystem-Fehlverhalten blockiert nicht die Sync-Jobs anderer Connectoren/Mandanten" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 7, + "unlocks": [], + "prompt": "# ENG-08 – Ressourcenlimits & Rate-Limiting für Drittsystem-Sync-Jobs\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 7\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nENG-03 verwaltet periodische Sync-Jobs, ENG-05 behandelt Fehler bei Drittsystem-Ausfällen mit Retry/Backoff, ohne Obergrenzen für Laufzeit oder Datenmenge je Sync-Lauf festzulegen. Ein fehlerhaft konfigurierter oder kompromittierter Connector (z. B. ein Drittsystem, das ungewöhnlich große Antworten liefert oder in einer Retry-Schleife hängen bleibt) kann sonst Ressourcen auf Kosten anderer Mandanten/Connectoren binden. Harte Obergrenzen je Sync-Lauf definieren (max. Laufzeit, max. übertragene Datenmenge, max. Anzahl Retry-Versuche als Abbruchgrenze aus ENG-05) sowie Rate-Limiting für ausgehende Anfragen an ein einzelnes Drittsystem.\n\n**Technische Grundlage:** Postgres-Jobqueue, Rate-Limiting, Ressourcenlimits (Zeit/Datenmenge)\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Airbyte: Sync-Job mit klar begrenzter Retry-Logik und definierten Abbruchbedingungen als Vorbild.\n\n**Bewusst vermeiden:**\n- Zapier/n8n (verbreitetes Anti-Muster) – Connector-Jobs ohne harte Obergrenze können bei Drittsystem-Fehlverhalten unbegrenzt Ressourcen binden.: harte, konfigurierbare Obergrenzen je Sync-Lauf von Anfang an, nicht erst nach einem Vorfall nachgerüstet.\n\n## Ausgangslage\nSetzt auf folgenden bereits fertigen Kacheln auf: ENG-03, ENG-05.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder Sync-Job hat konfigurierbare Obergrenzen für Laufzeit und übertragene Datenmenge\n2. Die Abbruchgrenze für Retry-Versuche aus ENG-05 wird durchgesetzt, ein Job endet nach Erreichen der Grenze kontrolliert statt endlos zu wiederholen\n3. Ausgehende Anfragen an ein einzelnes Drittsystem sind ratenbegrenzt, sodass ein einzelner Connector nicht das gesamte Sync-System für andere Connectoren/Mandanten blockiert\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Test: Sync-Job, der die Laufzeit-/Datenmengenobergrenze überschreitet, wird kontrolliert abgebrochen\n2. Test: Retry-Abbruchgrenze aus ENG-05 wird nach der konfigurierten Anzahl Versuche tatsächlich durchgesetzt\n3. Lasttest: ein Connector mit Drittsystem-Fehlverhalten blockiert nicht die Sync-Jobs anderer Connectoren/Mandanten\n\n## Bekannte Fehler vermeiden\n\nThreat-Model-Finding (Connect-Board, 2026-09-12): unbegrenzte Sync-Jobs gegenüber Drittsystemen sind ein Denial-of-Service-Vektor sowohl gegen die eigene Jobqueue (Ressourcenbindung) als auch potenziell gegen das angebundene Drittsystem (unkontrollierte Anfragerate).\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `ENG-03` Sync-Job-Verwaltung (periodische Imports/Exports)\n- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-08: ressourcenlimits-rate-limiting-f-r-drittsystem-sync-jobs`\n- Branch: `feature/eng-08-ressourcenlimits-rate-limiting-f-r-drittsystem-sync-jobs`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "ENG-10", + "title": "Modul-weiter Kill-Switch und Ausfallisolation für Connect", + "epic": "ENG", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Umgebungsvariable als Kill-Switch, Prozess-/Ressourcentrennung", + "description": "Connect als Ganzes per Umgebungsvariable abschaltbar; Ausfall eines Connectors oder von Connect insgesamt darf andere Module nicht beeintraechtigen.", + "dependsOn": [ + "ENG-05", + "ENG-08", + "M365-01" + ], + "akzeptanz": [ + "Kill-Switch schaltet Connect als Ganzes ab", + "Totalausfall ohne Auswirkung auf andere Module", + "Einzel-Connector-Ausfall blockiert nicht den Rest von Connect" + ], + "pruefungen": [ + "Kill-Switch-Test", + "Smoke-Test anderer Module nach hartem Prozess-Kill", + "Ausfall-Connector-Test" + ], + "status": "Fertig", + "epicName": "Connector-Engine & Grundgerüst", + "epicEmoji": "🔌", + "wave": 8, + "unlocks": [], + "prompt": "# ENG-10 – Modul-weiter Kill-Switch und Ausfallisolation für Connect\n\n**Epic:** 🔌 Connector-Engine & Grundgerüst | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.\n\n## Auftrag\nNutzeranfrage (2026-09-27): Connect soll abschaltbar sein, ODER ohne Abschaltung den Gesamtbetrieb der übrigen Module nicht stören können — konkretes Beispiel: Ausfall/Fehlkonfiguration von Microsoft Graph (M365-01) darf DMS/Mail/Workflow/AI/Core nicht beeinträchtigen.\n\nZwei Teile:\n1. **Kill-Switch:** Connect als Ganzes per Umgebungsvariable abschaltbar (Standard: aktueller Stand beibehalten, dokumentieren was Standard ist). Ohne Schalter kein aktiver Codepfad/Port — etabliertes Muster aus INT-18/INT-19.\n2. **Ausfallisolation:** Ein Ausfall eines einzelnen Connectors (z. B. M365 durch Netzwerk-/Auth-Fehler) oder von Connect insgesamt darf keine anderen Module beeinträchtigen — kein geteilter Prozess, kein geteilter kritischer Ressourcen-Pool, Fehler bleiben im Connect-Modul lokal (aufbauend auf ENG-05 Retry/Backoff und ENG-08 Ressourcenlimits/Rate-Limiting, die bereits Einzel-Connector-Isolation *innerhalb* von Connect herstellen — hier geht es um die Grenze *zwischen* Connect und den anderen Modulen).\n\n**Technische Grundlage:** Umgebungsvariable als Kill-Switch (analog INT-18/INT-19), Prozess-/Ressourcentrennung (Connect läuft als eigener Dienst/Prozess, keine geteilten In-Process-Zustände mit anderen Modulen — das ist durch die Multi-Modul-Architektur dieser Session ohnehin bereits so; hier real nachweisen statt nur annehmen).\n\n## Ausgangslage\n- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen (fertig)\n- `ENG-08` Ressourcenlimits & Rate-Limiting für Drittsystem-Sync-Jobs (fertig, PR #220 gemergt)\n- `M365-01` Microsoft-Graph-API-Anbindung (fertig, PR #223, noch nicht gemergt) — dient als konkreter Testfall für diese Kachel\n- Etabliertes Kill-Switch-Muster: `NEXARCH_MOBILE_CAPTURE_ENABLED` (INT-19), SMTP-Gateway-Schalter (INT-18)\n\n## Akzeptanzkriterien\n1. Eine Umgebungsvariable schaltet Connect als Ganzes ab; ohne Aktivierung ist kein Connect-Codepfad/Port erreichbar\n2. Ein simulierter Totalausfall von Connect (Prozess/Dienst beendet oder Kill-Switch aus) hat nachweislich keine Auswirkung auf DMS/Mail/Workflow/AI/Core (deren Tests/Smoke-Läufe bleiben unverändert grün)\n3. Ein simulierter Ausfall eines einzelnen Connectors (z. B. M365 nicht erreichbar/falsch konfiguriert) blockiert nicht den Rest von Connect (andere Connectoren/Sync-Jobs laufen weiter) — Nachweis über den bereits bestehenden ENG-05/ENG-08-Mechanismus, hier nur die modulübergreifende Grenze zusätzlich geprüft\n\n## Prüfungen vor der Abnahme\n1. Kill-Switch aus: Connect-Endpunkte nicht erreichbar, andere Module unbeeinträchtigt (echter Smoke-Test ohne Connect)\n2. Connect-Prozess während laufendem Gesamtbetrieb hart beendet: `gesamt-token-smoke.sh` (ohne Connect-Anteile) bleibt grün\n3. M365-Connector mit absichtlich ungültigen Zugangsdaten/nicht erreichbarem Endpunkt: Connect insgesamt bleibt bedienbar, Fehler bleibt auf den M365-Connector begrenzt\n\n## Nicht Bestandteil dieser Kachel\n- Neue Retry-/Limit-Logik (bereits in ENG-05/ENG-08 vorhanden, hier nur grenzübergreifend nachgewiesen)\n- Rollout/Deploy auf Host 131\n\n## Arbeitsweise\n1. Lies zuerst ENG-05, ENG-08 und den bestehenden Kill-Switch-Code aus INT-18/INT-19, halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `ENG-10: connect kill-switch und ausfallisolation`\n- Branch: `feature/eng-10-connect-kill-switch-ausfallisolation`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-01", + "title": "Echte Authentifizierung und verifizierter Tenant-Kontext für Connect-APIs", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Hoch", + "estimateDays": 3, + "tech": "JWT-Verifikation (Core-Token), Go net/http Middleware, RBAC-Policy-Prüfung gegen Core", + "description": "Security-Review-Finding K1 (kritisch): Connect-APIs prüfen nur `X-User-Id != \"\"`, Tenant kommt unverifiziert aus `X-Tenant-Slug`. `statusapi.WithPolicy()` existiert, wird aber nicht verdrahtet. Fundstellen: `statusapi.go:57-70`, `dms2importapi.go:41-54`, `datevapi.go:30-43`, `main.go:48-49`. Echte AuthN analog DMS-Vorbild (`moduleauth/middleware.go:72`) einführen.", + "dependsOn": [], + "akzeptanz": [ + "Jeder Connect-API-Aufruf verlangt ein gültiges, kryptografisch verifiziertes Core-Token; ein Request ohne gültiges Token wird mit 401 abgewiesen", + "Tenant- und User-Kontext werden ausschließlich aus dem verifizierten Token abgeleitet; X-User-Id/X-Tenant-Slug haben keinen Einfluss mehr, wenn sie vom Tokeninhalt abweichen", + "statusapi.WithPolicy() ist vor jeder Fach-API verdrahtet; unzureichende RBAC-Berechtigung führt zu 403", + "Angriff mit gefälschtem X-Tenant-Slug-Header auf fremde Mandantendaten ist nach der Umstellung nachweislich blockiert" + ], + "pruefungen": [ + "Angriff real nachstellen: curl mit gefälschtem X-Tenant-Slug liefert vor dem Fix fremde Mandantendaten über /connectors/status", + "Gleicher Angriff gegen POST /dms2/import/execute legt vor dem Fix Import-Lauf im Namen des fremden Mandanten an", + "Nach dem Fix: gleicher Request ohne gültiges Token bzw. mit gefälschtem Slug wird mit 401/403 abgewiesen", + "Regressionstest: legitimer Request mit gültigem Token funktioniert unverändert", + "Test: RBAC-Policy-Verweigerung löst 403 aus" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 8, + "unlocks": [], + "prompt": "# SEC-01 – Echte Authentifizierung und verifizierter Tenant-Kontext für Connect-APIs\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Hoch | **Aufwand:** 3 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main-Branch, Fable 5.1) hat festgestellt: `connect/internal/statusapi/statusapi.go:57-70`, `connect/internal/dms2importapi/dms2importapi.go:41-54` und `connect/internal/datevapi/datevapi.go:30-43` prüfen jeweils nur, ob der Header `X-User-Id` nicht leer ist. Der Mandant wird unverifiziert aus dem Header `X-Tenant-Slug` übernommen. `connect/cmd/connect-app/main.go:48-49` registriert diese Handler ohne Authentifizierungs-Middleware. `statusapi.WithPolicy()` (RBAC-Prüfung gegen Core) existiert im Code bereits, wird aber in `main.go` nirgends aufgerufen.\n\nDamit ist jeder beliebige Mandant per Header fälschbar:\n- `curl -H 'X-User-Id: a' -H 'X-Tenant-Slug: ' /connectors/status` liefert Sync-Status inkl. `last_error` eines fremden Mandanten.\n- `POST /dms2/import/execute` mit fremdem `X-Tenant-Slug` überschreibt aktive Field-Mappings fremder Mandanten und legt Import-Läufe im Namen des fremden Mandanten an (Vergiftung des GoBD-Protokolls).\n- `GET` auf `dms2_import_runs` fremder Mandanten per ID ist ohne Berechtigungsprüfung möglich.\n\nDas DMS-Modul hat dieses Problem bereits korrekt gelöst: `dms/internal/moduleauth/middleware.go:72` verifiziert das JWT kryptografisch und leitet Tenant/User erst danach aus dem geprüften Token ab, statt aus einem vom Aufrufer gesetzten Header.\n\n**Technische Grundlage:** JWT-Verifikation (Core-Token), Go net/http Middleware, RBAC-Policy-Prüfung gegen Core\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- DMS-Modul (`moduleauth/middleware.go`): Tenant- und User-Kontext werden ausschließlich aus einem kryptografisch verifizierten Core-Token abgeleitet, nie aus einem vom Client gesetzten Header.\n\n**Bewusst vermeiden:**\n- Vertrauen in unverifizierte Request-Header als Sicherheitsgrenze — das aktuelle Connect-Verhalten ist genau dieses Anti-Muster.\n\n## Ausgangslage\nSetzt auf der bestehenden Core-Token-Infrastruktur und dem DMS-Vorbild `moduleauth` auf. `statusapi.WithPolicy()` ist bereits vorhanden und ungenutzt.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Jeder Connect-API-Aufruf (`statusapi`, `dms2importapi`, `datevapi` und alle weiteren Fach-APIs in `connect/cmd/connect-app/main.go`) verlangt ein gültiges, kryptografisch verifiziertes Core-Token; ein Request ohne gültiges Token wird mit 401 abgewiesen.\n2. Tenant- und User-Kontext werden ausschließlich aus dem verifizierten Token abgeleitet; die Header `X-User-Id` und `X-Tenant-Slug` haben keinen Einfluss mehr auf den verwendeten Tenant, wenn sie vom Tokeninhalt abweichen.\n3. `statusapi.WithPolicy()` ist in `main.go` tatsächlich vor jeder Fach-API verdrahtet; ein Aufruf ohne ausreichende RBAC-Berechtigung wird mit 403 abgewiesen.\n4. Ein Angriff mit gefälschtem `X-Tenant-Slug`-Header auf fremde Mandantendaten (Status, Field-Mappings, Import-Läufe) ist nach der Umstellung nachweislich blockiert.\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Angriff vor der Fix-Umsetzung real nachstellen: `curl -H 'X-User-Id: a' -H 'X-Tenant-Slug: ' /connectors/status` gegen eine Testinstanz ausführen und dokumentieren, dass fremde Mandantendaten (inkl. `last_error`) tatsächlich zurückkommen.\n2. Denselben Angriff gegen `POST /dms2/import/execute` mit fremdem `X-Tenant-Slug` nachstellen und dokumentieren, dass vor dem Fix ein Import-Lauf im Namen des fremden Mandanten angelegt wird.\n3. Nach der Umsetzung denselben Request ohne gültiges Core-Token bzw. mit gefälschtem `X-Tenant-Slug` wiederholen und nachweisen, dass er mit 401/403 abgewiesen wird und keine fremden Daten mehr liefert.\n4. Regressionstest: ein legitimer Request mit gültigem Core-Token und korrektem Tenant funktioniert nach der Umstellung unverändert für `statusapi`, `dms2importapi` und `datevapi`.\n5. Test: RBAC-Policy-Verweigerung (`WithPolicy()`) löst bei unzureichender Rolle tatsächlich 403 aus.\n\n## Bekannte Fehler vermeiden\n\nSecurity-Review-Finding K1 (kritisch, main-Branch, Fable 5.1): Connect-APIs prüfen nur `X-User-Id != \"\"`, Tenant kommt unverifiziert aus `X-Tenant-Slug`. `statusapi.WithPolicy()` existiert, wird aber nicht verdrahtet. Fundstellen: `connect/internal/statusapi/statusapi.go:57-70`, `connect/internal/dms2importapi/dms2importapi.go:41-54`, `connect/internal/datevapi/datevapi.go:30-43`, `connect/cmd/connect-app/main.go:48-49`.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SEC-05` Tenant-Bindung der Store-Methoden (IDOR-Härtung)\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster, insbesondere `dms/internal/moduleauth/middleware.go`.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-01: authentifizierung-und-tenant-kontext-fuer-connect-apis`\n- Branch: `feature/sec-01-authentifizierung-und-tenant-kontext-fuer-connect-apis`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-02", + "title": "Entpack-Limit gegen Zip-Bomben im DMS2-Import", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 1, + "tech": "Go archive/zip, Streaming-Lese-Limits", + "description": "Security-Review-Finding H12 (hoch): `io.ReadAll(rc)` ohne Limit in `readZipEntry` (`dms2import/parse.go:219-225`) und analog in `dmsexchange.go:1966-1973`. Das 200-MiB-Limit in `dms2importapi.go:26` gilt nur für die komprimierte Größe, `UncompressedSize64` wird nie geprüft (Zip-Bomb-Risiko).", + "dependsOn": [], + "akzeptanz": [ + "readZipEntry prüft UncompressedSize64 je Eintrag und kumulativ gegen feste Obergrenzen", + "Gleiches Limit gilt im analogen Entpack-Muster in dmsexchange.go", + "Überschreitung bricht den Import mit klarer Fehlermeldung ab statt abzustürzen", + "Limits greifen streaming während des Lesens, nicht erst nach vollständigem Entpacken" + ], + "pruefungen": [ + "Angriff real nachstellen: Test-Zip (~10 MiB komprimiert) entpackt vor dem Fix unbegrenzt auf mehrere GiB", + "Nach dem Fix: gleicher Testfall bricht vor übermäßigem Speicherverbrauch mit Fehlermeldung ab", + "Regressionstest: normales Import-Zip innerhalb der Limits wird weiterhin korrekt eingelesen", + "Grenzfalltest: Zip knapp unter/über dem Limit liefert erwartetes Verhalten" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 8, + "unlocks": [], + "prompt": "# SEC-02 – Entpack-Limit gegen Zip-Bomben im DMS2-Import\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 1 Personentag | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main-Branch, Fable 5.1) hat festgestellt: `connect/internal/dms2import/parse.go:219-225` (Funktion `readZipEntry`) liest jeden Zip-Eintrag per `io.ReadAll(rc)` ohne Begrenzung ein — sowohl für das Manifest (Aufruf in Zeile 65) als auch für jedes einzelne Originaldokument (Aufruf in Zeile 140). `connect/internal/dmsexchange/dmsexchange.go:1966-1973` zeigt dasselbe Muster.\n\nDas bestehende 200-MiB-Limit in `connect/internal/dms2importapi/dms2importapi.go:26` begrenzt nur die komprimierte Dateigröße des Uploads. `UncompressedSize64` aus dem Zip-Header wird nirgends geprüft. Ein präpariertes Zip von wenigen MiB (z. B. 10 MiB) kann beim Entpacken auf mehrere GiB anwachsen (Zip-Bomb) und den Prozess per Speichererschöpfung (OOM) zum Absturz bringen. In Kombination mit dem in SEC-01 beschriebenen Fehlen der Authentifizierung ist dieser Angriff aktuell unauthentifiziert auslösbar.\n\n**Technische Grundlage:** Go `archive/zip`, Streaming-Lese-Limits, `connect/internal/dms2import/parse.go`, `connect/internal/dmsexchange/dmsexchange.go`\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Allgemeines Härtungsmuster für Datei-Uploads: Grenzwerte sowohl auf die komprimierte als auch auf die entpackte Größe, pro Eintrag und kumulativ über das gesamte Archiv.\n\n**Bewusst vermeiden:**\n- Sich allein auf die komprimierte Dateigröße als Schutzmaßnahme zu verlassen — das ist exakt die aktuelle Lücke.\n\n## Ausgangslage\nSetzt auf dem bestehenden DMS2-Import-Parser (`dms2import`) und dem Backup-Austauschformat (`dmsexchange`) auf; beide teilen das verwundbare Entpack-Muster.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. `readZipEntry` in `connect/internal/dms2import/parse.go` prüft vor und während des Entpackens sowohl `UncompressedSize64` des jeweiligen Zip-Eintrags als auch die kumulierte entpackte Gesamtgröße des Archivs gegen feste Obergrenzen.\n2. Das gleiche Limit gilt für das analoge Entpack-Muster in `connect/internal/dmsexchange/dmsexchange.go:1966-1973`.\n3. Wird ein Einzel- oder Gesamtlimit überschritten, bricht der Import mit einer klaren Fehlermeldung ab, statt den Entpackvorgang fortzusetzen oder den Prozess abstürzen zu lassen.\n4. Die Limits greifen bereits während des Lesens (streaming, z. B. über `io.LimitReader` bzw. zählendes Lesen), nicht erst nach vollständigem Entpacken eines Eintrags.\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Angriff vor der Fix-Umsetzung real nachstellen: ein Test-Zip mit stark komprimierbarem Inhalt (z. B. Nullbytes) erzeugen, das bei ca. 10 MiB komprimiert auf mehrere GiB entpackt, und dokumentieren, dass der aktuelle Code unbegrenzt entpackt (Speicherverbrauch messen oder Abbruch durch OOM-Killer protokollieren).\n2. Nach der Umsetzung denselben Testfall wiederholen und nachweisen, dass der Import vor Erreichen übermäßigen Speicherverbrauchs mit einer klaren Fehlermeldung abbricht.\n3. Regressionstest: ein normales, legitimes Import-Zip innerhalb der Limits wird weiterhin korrekt eingelesen.\n4. Grenzfalltest: ein Zip knapp unterhalb und knapp oberhalb des konfigurierten Limits liefert das erwartete Verhalten (Erfolg bzw. Abbruch).\n\n## Bekannte Fehler vermeiden\n\nSecurity-Review-Finding H12 (hoch, main-Branch, Fable 5.1): `io.ReadAll(rc)` ohne Limit in `readZipEntry` (`connect/internal/dms2import/parse.go:219-225`, Aufrufe Zeile 65 und 140) und analog in `connect/internal/dmsexchange/dmsexchange.go:1966-1973`. Das 200-MiB-Limit in `dms2importapi.go:26` gilt nur für die komprimierte Größe, nicht für `UncompressedSize64`.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SEC-01` Authentifizierung der Connect-APIs\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-02: entpack-limit-gegen-zip-bomben-im-dms2-import`\n- Branch: `feature/sec-02-entpack-limit-gegen-zip-bomben-im-dms2-import`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-03", + "title": "Append-only-Schutz für Connect-Protokolltabellen", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "PostgreSQL REVOKE/GRANT, Trigger-Funktion", + "description": "Security-Review-Finding H15 (hoch): keine der 12 Migrationen unter `connect/migrations/` erzwingt Append-only auf Protokolltabellen (`datev_exports`, `dms2_import_runs`, `connect_audit_outbox`); Code macht UPDATE/DELETE (`syncjob.go:258`, `audittrail.go:1120`, `credential.go:793`). Etabliertes Muster aus Core AUD-07/DMS VER-08/Workflow ENG-07 übernehmen.", + "dependsOn": [], + "akzeptanz": [ + "REVOKE UPDATE/DELETE von der Anwendungsrolle auf datev_exports, dms2_import_runs, connect_audit_outbox", + "Trigger weist versuchten UPDATE/DELETE ab und protokolliert den Versuch", + "INSERT funktioniert unverändert, inkl. Sequence-GRANT bei BIGSERIAL", + "Betroffene Codepfade (syncjob.go, audittrail.go, credential.go) funktionieren ohne Schreibversuch auf geschützte Felder" + ], + "pruefungen": [ + "Vor der Migration: direktes UPDATE/DELETE mit Anwendungsrolle gelingt nachweislich", + "Nach der Migration: gleicher Versuch wird abgewiesen, Trigger protokolliert die Warnung", + "Regressionstest: INSERT in alle drei Tabellen funktioniert unverändert inkl. Sequence-Vergabe", + "Regressionstest: angepasste Codepfade (syncjob, audittrail, credential) funktionieren fachlich weiterhin korrekt" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 8, + "unlocks": [], + "prompt": "# SEC-03 – Append-only-Schutz für Connect-Protokolltabellen\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main-Branch, Fable 5.1) hat festgestellt: Keine der 12 Migrationen unter `connect/migrations/` richtet ein DB-seitiges Append-only für Protokolltabellen ein (kein `REVOKE UPDATE/DELETE` von der Anwendungsrolle, kein Trigger, der nachträgliche Änderungen verweigert). Betroffen sind insbesondere `datev_exports` (10-jährige GoBD-Aufbewahrungspflicht), `dms2_import_runs` und `connect_audit_outbox`.\n\nDer Anwendungscode selbst führt derzeit UPDATE/DELETE direkt auf Protokolltabellen aus: `connect/internal/syncjob/syncjob.go:258`, `connect/internal/audittrail/audittrail.go:1120`, `connect/internal/credential/credential.go:793`. Ohne DB-seitige Durchsetzung kann jeder Code- oder Rechtepfad, der Schreibzugriff auf diese Tabellen erhält (auch versehentlich oder über einen künftigen Bug), GoBD-pflichtige Exportprotokolle und Audit-Einträge nachträglich verändern oder löschen — ein Verstoß gegen die Unveränderbarkeitspflicht und ein Nachweisproblem im Streitfall.\n\nCore AUD-07, DMS VER-08 und Workflow ENG-07 haben dieses Muster bereits etabliert: `REVOKE UPDATE, DELETE` von der Anwendungsrolle auf die Protokolltabelle, ein Trigger, der dennoch versuchte Änderungen mit `RAISE WARNING` abweist, sowie (bei `BIGSERIAL`-Primärschlüsseln) ein passendes `GRANT` auf die zugehörige Sequence, damit INSERT weiterhin funktioniert.\n\n**Technische Grundlage:** PostgreSQL `REVOKE`/`GRANT`, Trigger-Funktion mit `RAISE WARNING`/`RAISE EXCEPTION`, Migrationen unter `connect/migrations/`\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Core AUD-07 / DMS VER-08 / Workflow ENG-07: DB-seitiges Append-only für alle GoBD- und audit-relevanten Protokolltabellen, nicht nur anwendungsseitige Disziplin.\n\n**Bewusst vermeiden:**\n- Sich auf anwendungsseitige Konventionen (\"der Code macht einfach kein UPDATE auf dieser Tabelle\") statt auf eine erzwingende DB-Schranke zu verlassen.\n\n## Ausgangslage\nSetzt auf dem in Core AUD-07, DMS VER-08 und Workflow ENG-07 etablierten Append-only-Muster auf; dieses wird eins zu eins für Connect übernommen, nicht neu erfunden.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Für `datev_exports`, `dms2_import_runs` und `connect_audit_outbox` ist der Anwendungsrolle per `REVOKE` das Recht auf UPDATE und DELETE entzogen.\n2. Ein Trigger auf diesen Tabellen weist einen dennoch versuchten UPDATE/DELETE zuverlässig ab und protokolliert den Versuch (`RAISE WARNING` bzw. `RAISE EXCEPTION`, analog zum etablierten Muster).\n3. INSERT auf diese Tabellen funktioniert nach der Umstellung unverändert, inklusive korrektem Sequence-GRANT für `BIGSERIAL`-Primärschlüssel.\n4. Die bestehenden Codepfade, die aktuell UPDATE/DELETE auf diese Tabellen ausführen (`syncjob.go:258`, `audittrail.go:1120`, `credential.go:793`), sind so angepasst, dass sie ohne Schreibversuch auf die geschützten Felder funktionieren (z. B. über neue Zeilen statt Änderung bestehender Zeilen), oder es ist dokumentiert, warum der jeweilige Pfad korrekt entfernt werden konnte.\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Vor der Migration: nachweisen, dass ein direktes UPDATE/DELETE auf `datev_exports`, `dms2_import_runs` bzw. `connect_audit_outbox` mit der Anwendungsrolle tatsächlich gelingt (Angriff/Ist-Zustand real nachstellen).\n2. Nach der Migration: denselben UPDATE/DELETE-Versuch wiederholen und nachweisen, dass er von der Datenbank abgewiesen wird und der Trigger die Warnung protokolliert.\n3. Regressionstest: INSERT neuer Zeilen in alle drei Tabellen funktioniert nach der Migration unverändert, inklusive Sequence-Vergabe.\n4. Regressionstest: die angepassten Codepfade in `syncjob.go`, `audittrail.go` und `credential.go` funktionieren nach der Umstellung fachlich weiterhin korrekt (z. B. Sync-Job-Status-Historie, Audit-Trail, Credential-Widerruf).\n\n## Bekannte Fehler vermeiden\n\nSecurity-Review-Finding H15 (hoch, main-Branch, Fable 5.1): keine der 12 Migrationen unter `connect/migrations/` erzwingt Append-only auf Protokolltabellen; Code macht UPDATE/DELETE auf `datev_exports`, `dms2_import_runs`, `connect_audit_outbox` (`syncjob.go:258`, `audittrail.go:1120`, `credential.go:793`). Etabliertes Gegenmuster: Core AUD-07, DMS VER-08, Workflow ENG-07.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SEC-01` Authentifizierung der Connect-APIs\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster, insbesondere die Append-only-Migrationen von Core AUD-07, DMS VER-08 und Workflow ENG-07.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-03: append-only-schutz-fuer-connect-protokolltabellen`\n- Branch: `feature/sec-03-append-only-schutz-fuer-connect-protokolltabellen`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-04", + "title": "Fremdsystem-Antwortkörper vor Speicherung in last_error filtern", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Niedrig", + "estimateDays": 1, + "tech": "Go, Muster-/Regex-Filterung", + "description": "Security-Review-Finding M16 (mittel): bis zu 1 MiB Fremdsystem-Antwortkörper ungefiltert in `last_error`, lesbar über `statusapi.go:102`. Fundstellen: `datevtransfer.go:676-682`, `m365connector.go:112`, `backupconnector.go:101,139`. Kann Secrets enthalten (z. B. AWS StringToSign/AccessKeyID).", + "dependsOn": [], + "akzeptanz": [ + "Fremdsystem-Antwortkörper wird vor Speicherung in last_error auf sicherheitsrelevante Muster geprüft und diese werden entfernt/redigiert", + "Nur diagnostisch relevante Kurzfassung wird persistiert, keine vollständige Rohantwort", + "Kurzfassung bleibt für Fehlerdiagnose über die Status-API nachvollziehbar" + ], + "pruefungen": [ + "Vor dem Fix: simulierter Fehlerfall mit AWS-artiger Antwort landet ungefiltert in last_error und ist über Status-API lesbar", + "Nach dem Fix: sicherheitsrelevante Angaben sind in der Kurzfassung nicht mehr enthalten", + "Regressionstest: normaler Fehlerfall liefert weiterhin diagnostisch brauchbare Kurzfassung", + "Test für alle drei Fundstellen einzeln (DATEV-Transfer, M365, Backup-Connector)" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 8, + "unlocks": [], + "prompt": "# SEC-04 – Fremdsystem-Antwortkörper vor Speicherung in last_error filtern\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Niedrig | **Aufwand:** 1 Personentag | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main-Branch, Fable 5.1) hat festgestellt: `connect/internal/datevtransfer/datevtransfer.go:676-682`, `connect/internal/m365connector.go:112` und `connect/internal/backupconnector.go:101,139` speichern bei Fehlern den Antwortkörper des jeweiligen Fremdsystems bis zu einer Größe von 1 MiB ungefiltert im Feld `last_error`. Dieses Feld ist über `connect/internal/statusapi/statusapi.go:102` per Status-API auslesbar.\n\nAntwortkörper von Fremdsystemen (insbesondere S3-kompatiblen Backup-Zielen) können sicherheitsrelevante Details enthalten, z. B. eine AWS-Fehlermeldung mit `StringToSign` und `AccessKeyID`. Dadurch kann ein Fehlerfall dazu führen, dass Zugangsdaten- oder Signaturmaterial über eine regulär erreichbare Status-API lesbar wird — verschärft durch SEC-01, solange die Status-API nicht ordentlich authentifiziert ist.\n\n**Technische Grundlage:** Go, Muster-/Regex-Filterung sicherheitsrelevanter Textstellen, `connect/internal/datevtransfer/datevtransfer.go`, `connect/internal/m365connector.go`, `connect/internal/backupconnector.go`\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Fehlerdiagnose bleibt möglich (Kurzfassung mit HTTP-Status, Fehlertyp, Zeitpunkt), aber ohne rohen Fremdsystem-Antwortkörper im gespeicherten Fehlerfeld.\n\n**Bewusst vermeiden:**\n- Rohe, ungefilterte Antwortkörper externer Systeme als Diagnosehilfe zu speichern — das aktuelle Verhalten ist genau dieses Anti-Muster.\n\n## Ausgangslage\nSetzt auf den bestehenden Fehlerbehandlungspfaden in `datevtransfer`, `m365connector` und `backupconnector` auf.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. An allen drei Fundstellen (`datevtransfer.go:676-682`, `m365connector.go:112`, `backupconnector.go:101,139`) wird der Fremdsystem-Antwortkörper vor dem Schreiben nach `last_error` auf sicherheitsrelevante Muster geprüft (u. a. AWS-Signaturdetails wie `StringToSign`/`AccessKeyID`/`Signature`, Authorization-Header-Inhalte, Tokens, Secrets) und diese Muster werden entfernt oder redigiert.\n2. Es wird nur eine diagnostisch relevante Kurzfassung persistiert (z. B. HTTP-Status, Fehlertyp, gekürzter/redigierter Textausschnitt), keine vollständige 1-MiB-Rohantwort mehr.\n3. Die Kurzfassung bleibt für die Fehlerdiagnose über die Status-API nachvollziehbar (Ursache und Zeitpunkt weiterhin erkennbar).\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Vor dem Fix: einen Fehlerfall gegen ein Test-Backup-Ziel simulieren, dessen Antwort eine AWS-artige Fehlermeldung mit `StringToSign`/`AccessKeyID` enthält, und nachweisen, dass diese Angaben aktuell unverändert in `last_error` landen und über die Status-API auslesbar sind.\n2. Nach dem Fix: denselben Testfall wiederholen und nachweisen, dass die sicherheitsrelevanten Angaben in der gespeicherten Kurzfassung nicht mehr enthalten sind.\n3. Regressionstest: ein normaler Fehlerfall ohne sicherheitsrelevante Inhalte liefert weiterhin eine für die Diagnose brauchbare Kurzfassung (Ursache, Zeitpunkt erkennbar).\n4. Test für alle drei Fundstellen einzeln durchführen (DATEV-Transfer, M365-Connector, Backup-Connector), nicht nur für eine.\n\n## Bekannte Fehler vermeiden\n\nSecurity-Review-Finding M16 (mittel, main-Branch, Fable 5.1): bis zu 1 MiB Fremdsystem-Antwortkörper ungefiltert in `last_error`, lesbar über `statusapi.go:102`. Fundstellen: `datevtransfer.go:676-682`, `m365connector.go:112`, `backupconnector.go:101,139`.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SEC-01` Authentifizierung der Connect-APIs\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-04: fremdsystem-antwortkoerper-vor-speicherung-in-last-error-filtern`\n- Branch: `feature/sec-04-fremdsystem-antwortkoerper-vor-speicherung-in-last-error-filtern`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + }, + { + "code": "SEC-05", + "title": "Tenant-Bindung der Connect-Store-Methoden (IDOR-Härtung)", + "epic": "SEC", + "featureIds": [], + "role": "Backend", + "complexity": "Mittel", + "estimateDays": 2, + "tech": "Go, pgx/v5, PostgreSQL, Signaturänderung", + "description": "Security-Review-Finding M17 (mittel): tenant-ungebundene Store-Methoden mit `WHERE id=$1` ohne Tenant-Filter, latentes IDOR-Risiko. Fundstellen: `syncjob.go:109-122,191-269`, `datevtransfer/store.go:935-1001`, `erpexport/store.go:1424-1490`.", + "dependsOn": [], + "akzeptanz": [ + "Betroffene Store-Methoden nehmen Tenant-Parameter als zwingenden Bestandteil der Signatur entgegen", + "WHERE-Klausel ist um AND tenant_slug=$2 ergänzt", + "Alle Aufrufer sind angepasst, Projekt compiliert fehlerfrei", + "Zugriff mit id eines fremden Mandanten liefert kein Ergebnis" + ], + "pruefungen": [ + "Vor dem Fix: Store-Methode mit id von Mandant A und Tenant-Kontext von Mandant B liefert fremden Datensatz", + "Nach dem Fix: gleicher Aufruf liefert kein Ergebnis bei nicht passendem tenant_slug", + "Regressionstest: Aufruf mit korrekt zueinander passendem id/tenant_slug liefert erwarteten Datensatz, für alle drei Stores", + "Build-Test: Projekt compiliert fehlerfrei, kein Aufrufer ohne Tenant-Parameter" + ], + "status": "Backlog", + "epicName": "Sicherheit", + "epicEmoji": "🔒", + "wave": 8, + "unlocks": [], + "prompt": "# SEC-05 – Tenant-Bindung der Connect-Store-Methoden (IDOR-Härtung)\n\n**Epic:** 🔒 Sicherheit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8\n\n---\n\n## Rolle\nDu bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.\nServerseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.\n\n## Auftrag\nSecurity-Review (main-Branch, Fable 5.1) hat festgestellt: mehrere Store-Methoden filtern nur nach `id`, ohne den Mandanten in der WHERE-Klausel zu erzwingen: `connect/internal/syncjob/syncjob.go:109-122,191-269`, `connect/internal/datevtransfer/store.go:935-1001`, `connect/internal/erpexport/store.go:1424-1490`. Diese Methoden sind aktuell nicht über HTTP erreichbar, stellen aber ein latentes IDOR-Risiko dar: sobald eine künftige API-Route eine dieser Methoden direkt mit einer vom Aufrufer kommenden `id` aufruft, kann ein Mandant per erratener oder sequentieller ID auf die Sync-Job-, DATEV-Transfer- oder ERP-Export-Datensätze eines fremden Mandanten zugreifen.\n\nLösung laut Review: den Tenant-Parameter in der Methodensignatur erzwingen (Compile-Zeit-Änderung, kein optionales Flag), sodass die WHERE-Klausel in jeder dieser Methoden um `AND tenant_slug=$2` ergänzt wird und ein Aufruf ohne Tenant-Parameter nicht mehr compiliert.\n\n**Technische Grundlage:** Go, pgx/v5, PostgreSQL, Signaturänderung der betroffenen Store-Methoden\n\n## Produkt-DNA für diesen Bereich\n**Übernehmen:**\n- Multi-Tenancy Modell A: jede datensatzbezogene Store-Methode erzwingt den Tenant-Filter über die Methodensignatur, nicht als optionalen, vergessbaren Parameter.\n\n**Bewusst vermeiden:**\n- Store-Methoden, die allein über `id` filtern und sich auf den Aufrufer verlassen, den richtigen Tenant korrekt mitzugeben — genau das aktuelle Muster.\n\n## Ausgangslage\nSetzt auf den bestehenden Store-Implementierungen von `syncjob`, `datevtransfer` und `erpexport` auf; ändert ausschließlich deren Methodensignaturen und WHERE-Klauseln, keine Fachlogik.\n\n## Akzeptanzkriterien\nDie Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:\n1. Alle betroffenen Methoden (`syncjob.go:109-122,191-269`, `datevtransfer/store.go:935-1001`, `erpexport/store.go:1424-1490`) nehmen einen Tenant-Parameter (z. B. `tenantSlug string`) als zwingenden Bestandteil der Signatur entgegen.\n2. Die SQL-WHERE-Klausel jeder dieser Methoden ist um `AND tenant_slug=$2` (bzw. entsprechenden Parameter) ergänzt.\n3. Alle bestehenden Aufrufer dieser Methoden im Repository sind so angepasst, dass sie den jeweils korrekten, aus dem verifizierten Kontext stammenden Tenant übergeben; das Projekt compiliert fehlerfrei.\n4. Ein Zugriffsversuch mit `id` eines fremden Mandanten und dem eigenen Tenant-Parameter liefert kein Ergebnis (bzw. \"nicht gefunden\") statt der fremden Daten.\n\n## Prüfungen vor der Abnahme\nFühre jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:\n1. Vor dem Fix: einen Testdatensatz für Mandant A anlegen, danach mit `id` dieses Datensatzes und Tenant-Kontext von Mandant B die jeweilige Store-Methode direkt aufrufen und nachweisen, dass der fremde Datensatz aktuell zurückgegeben wird.\n2. Nach dem Fix: denselben Aufruf wiederholen und nachweisen, dass kein Ergebnis mehr zurückkommt, wenn `id` und `tenant_slug` nicht zusammenpassen.\n3. Regressionstest: Aufruf mit korrektem, zueinander passendem `id` und `tenant_slug` liefert weiterhin den erwarteten Datensatz, für alle drei betroffenen Stores (`syncjob`, `datevtransfer`, `erpexport`).\n4. Build-Test: das Projekt compiliert nach der Signaturänderung fehlerfrei; kein verbliebener Aufrufer ruft eine der geänderten Methoden ohne Tenant-Parameter auf.\n\n## Bekannte Fehler vermeiden\n\nSecurity-Review-Finding M17 (mittel, main-Branch, Fable 5.1): tenant-ungebundene Store-Methoden mit `WHERE id=$1` ohne Tenant-Filter, latentes IDOR-Risiko. Fundstellen: `syncjob.go:109-122,191-269`, `datevtransfer/store.go:935-1001`, `erpexport/store.go:1424-1490`.\n\n## Nicht Bestandteil dieser Kachel\nDiese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:\n- `SEC-01` Authentifizierung der Connect-APIs\n\n## Arbeitsweise\n1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.\n2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.\n3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.\n4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.\n5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.\n6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.\n\n## Abschluss\n- Commit-Nachricht: `SEC-05: tenant-bindung-der-connect-store-methoden-idor-haertung`\n- Branch: `feature/sec-05-tenant-bindung-der-connect-store-methoden-idor-haertung`\n- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.\n- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.\n" + } + ] +} diff --git a/connect-kanban/kanban.html b/connect-kanban/kanban.html new file mode 100644 index 00000000..0f01a544 --- /dev/null +++ b/connect-kanban/kanban.html @@ -0,0 +1,50 @@ + + + + + +Connect Kanban – lokal + + + +
    +
    +

    Connect Kanban – lokal, offline, ohne Server

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

    +

    Baut auf

    +

    Schaltet frei

    +

    Akzeptanzkriterien

      +

      Prüfungen vor der Abnahme

        +

        Bau-Prompt

        
+  
        
+        
+
+
+
+
+
diff --git a/connect-kanban/tickets/API-01.md b/connect-kanban/tickets/API-01.md
new file mode 100644
index 00000000..33e670c8
--- /dev/null
+++ b/connect-kanban/tickets/API-01.md
@@ -0,0 +1,64 @@
+# API-01 – Connect-Konfigurationsoberfläche (Connectoren einrichten)
+
+**Epic:** 🖥️ Connect-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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 Bedienbarkeit. Keine Geschäftslogik, die serverseitig gehört.
+
+## Auftrag
+Oberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.
+
+**Technische Grundlage:** Next.js/React, Connector-Einrichtungsformulare
+
+## Produkt-DNA für diesen Bereich
+> Eine schlanke Konfigurationsoberfläche für Connectoren wie bei Zapier/n8n, kein visueller Workflow-Builder.
+
+**Übernehmen:**
+- Zapier/n8n: übersichtliche Verbindungs-Einrichtung und Statusanzeige je Connector, ohne grafischen Workflow-Builder.
+- Airbyte: klare Diagnoseansicht bei fehlgeschlagenen Sync-Läufen.
+
+**Bewusst vermeiden:**
+- Kein eigener Workflow-Builder – die Oberfläche konfiguriert Connectoren, sie modelliert keine Prozesse.
+- Keine eigene Webhook-Infrastruktur – die Oberfläche nutzt ausschließlich die zentrale Core-Webhook-Registry (API-07).
+
+**Für genau diese Kachel:** Oberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.
+
+## 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.
+- `ENG-04` Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem) – Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.
+- 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. Connector lässt sich vollständig über die Oberfläche einrichten, ohne Konfigurationsdatei
+2. Zugangsdaten werden nur maskiert angezeigt, nie im Klartext
+3. Feld-Mapping ist über die Oberfläche bearbeitbar
+
+## 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. Vollständige Einrichtung eines Testconnectors über die Oberfläche erfolgreich
+2. Zugangsdaten in der Oberfläche im Test nachweislich maskiert
+3. Mapping-Änderung über die Oberfläche im Test korrekt übernommen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-02` Verbindungsstatus-Übersicht & Diagnose
+
+## 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: `API-01: 01 connect konfigurationsoberflaeche connectoren einrichten`
+- Branch: `feature/api-01-01-connect-konfigurationsoberflaeche-connectoren-einrichten`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/API-02.md b/connect-kanban/tickets/API-02.md
new file mode 100644
index 00000000..94b980de
--- /dev/null
+++ b/connect-kanban/tickets/API-02.md
@@ -0,0 +1,63 @@
+# API-02 – Verbindungsstatus-Übersicht & Diagnose
+
+**Epic:** 🖥️ Connect-Oberfläche  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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 Bedienbarkeit. Keine Geschäftslogik, die serverseitig gehört.
+
+## Auftrag
+Übersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.
+
+**Technische Grundlage:** Next.js/React, Statusanzeige
+
+## Produkt-DNA für diesen Bereich
+> Eine schlanke Konfigurationsoberfläche für Connectoren wie bei Zapier/n8n, kein visueller Workflow-Builder.
+
+**Übernehmen:**
+- Zapier/n8n: übersichtliche Verbindungs-Einrichtung und Statusanzeige je Connector, ohne grafischen Workflow-Builder.
+- Airbyte: klare Diagnoseansicht bei fehlgeschlagenen Sync-Läufen.
+
+**Bewusst vermeiden:**
+- Kein eigener Workflow-Builder – die Oberfläche konfiguriert Connectoren, sie modelliert keine Prozesse.
+- Keine eigene Webhook-Infrastruktur – die Oberfläche nutzt ausschließlich die zentrale Core-Webhook-Registry (API-07).
+
+**Für genau diese Kachel:** Übersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.
+
+## 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 Drittsystem-Ausfällen – Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.
+- 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. Verbindungsstatus je Connector ist auf einen Blick erkennbar
+2. Letzter Sync-Lauf mit Ergebnis ist einsehbar
+3. Fehlerdiagnose zeigt die Ursache aus dem Fehlerprotokoll
+
+## 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. Statusanzeige im Test korrekt für erfolgreichen und fehlgeschlagenen Lauf
+2. Diagnoseansicht zeigt reale Testfehler nachvollziehbar an
+3. Aktualisierung nach neuem Sync-Lauf im Test korrekt
+
+## 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 Connector-Engine
+
+## 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: `API-02: 02 verbindungsstatus uebersicht diagnose`
+- Branch: `feature/api-02-02-verbindungsstatus-uebersicht-diagnose`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/API-03.md b/connect-kanban/tickets/API-03.md
new file mode 100644
index 00000000..d59a4659
--- /dev/null
+++ b/connect-kanban/tickets/API-03.md
@@ -0,0 +1,63 @@
+# API-03 – Externe Webhook-Abonnements (nutzt Core API-07)
+
+**Epic:** 🖥️ Connect-Oberfläche  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Abonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.
+
+**Technische Grundlage:** Core-Webhook-Registry-Anbindung
+
+## Produkt-DNA für diesen Bereich
+> Eine schlanke Konfigurationsoberfläche für Connectoren wie bei Zapier/n8n, kein visueller Workflow-Builder.
+
+**Übernehmen:**
+- Zapier/n8n: übersichtliche Verbindungs-Einrichtung und Statusanzeige je Connector, ohne grafischen Workflow-Builder.
+- Airbyte: klare Diagnoseansicht bei fehlgeschlagenen Sync-Läufen.
+
+**Bewusst vermeiden:**
+- Kein eigener Workflow-Builder – die Oberfläche konfiguriert Connectoren, sie modelliert keine Prozesse.
+- Keine eigene Webhook-Infrastruktur – die Oberfläche nutzt ausschließlich die zentrale Core-Webhook-Registry (API-07).
+
+**Für genau diese Kachel:** Abonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `API-07` Zentrale Webhook-Registry & Zustellung
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Connector kann ein Webhook-Ereignis über die Core-Webhook-Registry abonnieren
+2. Zugestelltes Ereignis löst die zugeordnete Connector-Aktion aus
+3. Abbestellen entfernt das Abonnement vollständig
+
+## 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. Testabonnement über Core-Webhook-Registry im Test erfolgreich registriert
+2. Testereignis löst im Test die erwartete Connector-Aktion aus
+3. Abbestellung im Test vollständig entfernt
+
+## 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 Connector-Engine
+
+## 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: `API-03: 03 externe webhook abonnements nutzt core api 07`
+- Branch: `feature/api-03-03-externe-webhook-abonnements-nutzt-core-api-07`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/DAT-01.md b/connect-kanban/tickets/DAT-01.md
new file mode 100644
index 00000000..51686a56
--- /dev/null
+++ b/connect-kanban/tickets/DAT-01.md
@@ -0,0 +1,65 @@
+# DAT-01 – DATEV-Format-Export (Belege/Buchungsstapel)
+
+**Epic:** 🧾 DATEV-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.
+
+**Technische Grundlage:** DATEV-Exportformat, Buchungsstapel-Struktur
+
+## Produkt-DNA für diesen Bereich
+> DATEV-Export so verlässlich wie ein Airbyte-Sync-Job, mit offen dokumentiertem Format statt Blackbox-Konnektor.
+
+**Übernehmen:**
+- Airbyte: Retry und Fehlerbehandlung bei Exportläufen, damit ein fehlgeschlagener Export nicht stillschweigend verloren geht.
+- Vollständiges Exportprotokoll je Lauf, damit jeder DATEV-Export nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Kein Vendor-Lock durch proprietäres DATEV-Werkzeug – das Exportformat bleibt offen dokumentiert und ohne Herstellerwerkzeug nachvollziehbar.
+- Keine stille Fehlklassifizierung von Belegen – Abweichungen werden im Protokoll sichtbar.
+
+**Für genau diese Kachel:** Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+- Setzt voraus (externes Archive-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/archive-kanban/): `RET-05` Modul-Adapter-Schnittstelle – exportierte GoBD-relevante Buchungsstapel werden hier mit Aufbewahrungsklasse registriert, statt unregistriert im Dateisystem zu liegen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Export erzeugt gültige DATEV-Exportdatei aus Testbelegen
+2. Pflichtfelder des DATEV-Formats werden vollständig befüllt oder der Export klar abgewiesen
+3. Exportierter Buchungsstapel ist eindeutig einem Zeitraum zugeordnet
+4. Exportiertes Objekt (Buchungsstapel) wird bei Archive RET-05 mit der GoBD-Aufbewahrungsklasse registriert, statt unregistriert im Dateisystem zu liegen
+## 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. Erzeugte Exportdatei besteht Formatprüfung gegen DATEV-Spezifikation
+2. Fehlendes Pflichtfeld führt zu klarer Abweisung statt fehlerhaftem Export
+3. Zeitraumzuordnung im Test korrekt
+
+4. Export eines Testbuchungsstapels erzeugt nachweisbar eine Registrierung bei Archive RET-05
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `DAT-02` DATEV-Konnektor (Schnittstellen-Protokoll)
+- `DAT-03` DATEV-Export-Oberfläche & Protokoll
+
+## 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: `DAT-01: 01 datev format export belege buchungsstapel`
+- Branch: `feature/dat-01-01-datev-format-export-belege-buchungsstapel`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/DAT-02.md b/connect-kanban/tickets/DAT-02.md
new file mode 100644
index 00000000..73265c1c
--- /dev/null
+++ b/connect-kanban/tickets/DAT-02.md
@@ -0,0 +1,62 @@
+# DAT-02 – DATEV-Konnektor (Schnittstellen-Protokoll)
+
+**Epic:** 🧾 DATEV-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Komplex  |  **Aufwand:** 4 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Konnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.
+
+**Technische Grundlage:** DATEV-Schnittstellenprotokoll, Übertragungslogik
+
+## Produkt-DNA für diesen Bereich
+> DATEV-Export so verlässlich wie ein Airbyte-Sync-Job, mit offen dokumentiertem Format statt Blackbox-Konnektor.
+
+**Übernehmen:**
+- Airbyte: Retry und Fehlerbehandlung bei Exportläufen, damit ein fehlgeschlagener Export nicht stillschweigend verloren geht.
+- Vollständiges Exportprotokoll je Lauf, damit jeder DATEV-Export nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Kein Vendor-Lock durch proprietäres DATEV-Werkzeug – das Exportformat bleibt offen dokumentiert und ohne Herstellerwerkzeug nachvollziehbar.
+- Keine stille Fehlklassifizierung von Belegen – Abweichungen werden im Protokoll sichtbar.
+
+**Für genau diese Kachel:** Konnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `DAT-01` DATEV-Format-Export (Belege/Buchungsstapel) – Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Übertragung an ein Test-DATEV-Zielsystem gelingt protokollkonform
+2. Fehlgeschlagene Übertragung wird über die Fehlerbehandlung erneut versucht
+3. Übertragungsstatus ist je Lauf nachvollziehbar
+
+## 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. Protokollkonforme Übertragung im Test gegen Referenzsystem geprüft
+2. Simulierter Übertragungsfehler löst Retry aus
+3. Übertragungsstatus im Test korrekt und nachvollziehbar
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `DAT-03` DATEV-Export-Oberfläche & Protokoll
+
+## 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: `DAT-02: 02 datev konnektor schnittstellen protokoll`
+- Branch: `feature/dat-02-02-datev-konnektor-schnittstellen-protokoll`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/DAT-03.md b/connect-kanban/tickets/DAT-03.md
new file mode 100644
index 00000000..63401c56
--- /dev/null
+++ b/connect-kanban/tickets/DAT-03.md
@@ -0,0 +1,64 @@
+# DAT-03 – DATEV-Export-Oberfläche & Protokoll
+
+**Epic:** 🧾 DATEV-Anbindung  |  **Rolle:** Frontend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Frontend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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 Bedienbarkeit. Keine Geschäftslogik, die serverseitig gehört.
+
+## Auftrag
+Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.
+
+**Technische Grundlage:** React/Next.js-Oberfläche, Exportprotokoll-Ansicht
+
+## Produkt-DNA für diesen Bereich
+> DATEV-Export so verlässlich wie ein Airbyte-Sync-Job, mit offen dokumentiertem Format statt Blackbox-Konnektor.
+
+**Übernehmen:**
+- Airbyte: Retry und Fehlerbehandlung bei Exportläufen, damit ein fehlgeschlagener Export nicht stillschweigend verloren geht.
+- Vollständiges Exportprotokoll je Lauf, damit jeder DATEV-Export nachvollziehbar bleibt.
+
+**Bewusst vermeiden:**
+- Kein Vendor-Lock durch proprietäres DATEV-Werkzeug – das Exportformat bleibt offen dokumentiert und ohne Herstellerwerkzeug nachvollziehbar.
+- Keine stille Fehlklassifizierung von Belegen – Abweichungen werden im Protokoll sichtbar.
+
+**Für genau diese Kachel:** Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `DAT-01` DATEV-Format-Export (Belege/Buchungsstapel) – Export von Belegen und Buchungsstapeln im DATEV-Format aus NEXARCH-Dokumenten und -Metadaten.
+- `DAT-02` DATEV-Konnektor (Schnittstellen-Protokoll) – Konnektor, der den Export im DATEV-Format über das offizielle Schnittstellenprotokoll an DATEV-Systeme überträgt.
+- 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. Export lässt sich über die Oberfläche mit Zeitraum-Auswahl anstoßen
+2. Exportprotokoll ist je Lauf einsehbar
+3. Fehlgeschlagener Export ist in der Oberfläche klar erkennbar
+
+## 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. Export-Anstoß im Test aus der Oberfläche erfolgreich
+2. Protokollansicht zeigt reale Testläufe korrekt an
+3. Fehlgeschlagener Testlauf ist visuell klar unterscheidbar
+
+## 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 ERP/DATEV/M365
+
+## 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: `DAT-03: 03 datev export oberflaeche protokoll`
+- Branch: `feature/dat-03-03-datev-export-oberflaeche-protokoll`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/DMS2-01.md b/connect-kanban/tickets/DMS2-01.md
new file mode 100644
index 00000000..ef13d318
--- /dev/null
+++ b/connect-kanban/tickets/DMS2-01.md
@@ -0,0 +1,62 @@
+# DMS2-01 – Standardisiertes Export-/Import-Format (offen, dokumentiert)
+
+**Epic:** 🔄 Andere-DMS-Interoperabilität  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.
+
+**Technische Grundlage:** Offenes Austauschformat, Schema-Dokumentation
+
+## Produkt-DNA für diesen Bereich
+> Offener Austausch mit anderen DMS-Systemen wie bei einem dokumentierten Airbyte-Konnektor, kein geschlossenes Migrationswerkzeug.
+
+**Übernehmen:**
+- Airbyte: offen dokumentiertes Austauschformat als Vorbild für Export/Import zwischen DMS-Systemen.
+- Zapier/n8n: der Import-Assistent bleibt ein austauschbarer Adapter, kein Einwegwerkzeug.
+
+**Bewusst vermeiden:**
+- Kein proprietäres, geschlossenes Migrationsformat – offen dokumentiert und ohne Herstellerwerkzeug lesbar.
+- Keine Backup-Ziel-Anbindung mit Herstellerbindung – Zugangsdaten und Protokoll bleiben austauschbar.
+
+**Für genau diese Kachel:** Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Format ist vollständig dokumentiert und ohne NEXARCH-Werkzeug lesbar
+2. Export enthält Dokument, Metadaten und Versionsbezug
+3. Format-Validierung weist fehlerhafte Dateien 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. Exportierte Testdatei extern ohne NEXARCH-Werkzeug lesbar geprüft
+2. Enthaltene Metadaten im Test vollständig und korrekt
+3. Fehlerhafte Testdatei wird bei Validierung abgewiesen
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `DMS2-02` Import-Assistent für Drittsystem-Exporte
+
+## 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: `DMS2-01: 01 standardisiertes export import format offen dokumentiert`
+- Branch: `feature/dms2-01-01-standardisiertes-export-import-format-offen-dokumentiert`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/DMS2-02.md b/connect-kanban/tickets/DMS2-02.md
new file mode 100644
index 00000000..50df3474
--- /dev/null
+++ b/connect-kanban/tickets/DMS2-02.md
@@ -0,0 +1,65 @@
+# DMS2-02 – Import-Assistent für Drittsystem-Exporte
+
+**Epic:** 🔄 Andere-DMS-Interoperabilität  |  **Rolle:** Fullstack  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.
+
+**Technische Grundlage:** Import-Assistent mit Mapping-Vorschau-Oberfläche (Next.js/React), Backend-Parser für Drittsystem-Exportformate
+
+## Produkt-DNA für diesen Bereich
+> Offener Austausch mit anderen DMS-Systemen wie bei einem dokumentierten Airbyte-Konnektor, kein geschlossenes Migrationswerkzeug.
+
+**Übernehmen:**
+- Airbyte: offen dokumentiertes Austauschformat als Vorbild für Export/Import zwischen DMS-Systemen.
+- Zapier/n8n: der Import-Assistent bleibt ein austauschbarer Adapter, kein Einwegwerkzeug.
+
+**Bewusst vermeiden:**
+- Kein proprietäres, geschlossenes Migrationsformat – offen dokumentiert und ohne Herstellerwerkzeug lesbar.
+- Keine Backup-Ziel-Anbindung mit Herstellerbindung – Zugangsdaten und Protokoll bleiben austauschbar.
+
+**Für genau diese Kachel:** Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `DMS2-01` Standardisiertes Export-/Import-Format (offen, dokumentiert) – Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.
+- 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. Testexport eines gängigen Drittsystems lässt sich einlesen
+2. Feld-Mapping wird vorgeschlagen und ist vor Import änderbar
+3. Import-Ergebnis mit Erfolgs-/Fehlerzahl ist einsehbar
+4. Mapping-Vorschau ist eine bedienbare Oberfläche (nicht nur eine API-Antwort), in der Feldzuordnungen vor dem Import angepasst werden können
+
+## 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. Testexport eines Drittsystems im Test erfolgreich eingelesen
+2. Manuelle Mapping-Korrektur im Test übernommen
+3. Import-Protokoll zeigt korrekte Erfolgs-/Fehlerzahl
+4. Mapping-Vorschau im Browser bedient: Zuordnung geändert, Import mit geänderter Zuordnung ausgeführt
+
+## 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 Connector-Engine
+
+## 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: `DMS2-02: 02 import assistent fuer drittsystem exporte`
+- Branch: `feature/dms2-02-02-import-assistent-fuer-drittsystem-exporte`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/DMS2-03.md b/connect-kanban/tickets/DMS2-03.md
new file mode 100644
index 00000000..3d074cef
--- /dev/null
+++ b/connect-kanban/tickets/DMS2-03.md
@@ -0,0 +1,62 @@
+# DMS2-03 – Externe-Backup-Ziel-Anbindung
+
+**Epic:** 🔄 Andere-DMS-Interoperabilität  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Anbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) für den verschlüsselten Export von Dokumentbeständen.
+
+**Technische Grundlage:** Backup-Ziel-Connector, verschlüsselte Übertragung
+
+## Produkt-DNA für diesen Bereich
+> Offener Austausch mit anderen DMS-Systemen wie bei einem dokumentierten Airbyte-Konnektor, kein geschlossenes Migrationswerkzeug.
+
+**Übernehmen:**
+- Airbyte: offen dokumentiertes Austauschformat als Vorbild für Export/Import zwischen DMS-Systemen.
+- Zapier/n8n: der Import-Assistent bleibt ein austauschbarer Adapter, kein Einwegwerkzeug.
+
+**Bewusst vermeiden:**
+- Kein proprietäres, geschlossenes Migrationsformat – offen dokumentiert und ohne Herstellerwerkzeug lesbar.
+- Keine Backup-Ziel-Anbindung mit Herstellerbindung – Zugangsdaten und Protokoll bleiben austauschbar.
+
+**Für genau diese Kachel:** Anbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) über das bestehende Connector-Plugin-Modell, statt einer festverdrahteten Backup-Lösung – ein neues Ziel lässt sich als weiterer Connector ergänzen, ohne den Kern anzufassen.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Backup-Ziel lässt sich über das Connector-Plugin-Modell einrichten
+2. Export an das Backup-Ziel erfolgt verschlüsselt
+3. Fehlgeschlagener Backup-Export wird über die Fehlerbehandlung erneut versucht
+
+## 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. Verbindungsaufbau zu Test-Backup-Ziel im Test erfolgreich
+2. Übertragung im Test nachweislich verschlüsselt
+3. Simulierter Übertragungsfehler löst Retry aus
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-04` Sicherheitsprüfung Drittsystem-Credentials
+
+## 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: `DMS2-03: 03 externe backup ziel anbindung`
+- Branch: `feature/dms2-03-03-externe-backup-ziel-anbindung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-01.md b/connect-kanban/tickets/ENG-01.md
new file mode 100644
index 00000000..42d313a3
--- /dev/null
+++ b/connect-kanban/tickets/ENG-01.md
@@ -0,0 +1,69 @@
+# ENG-01 – Connector-Plugin-Modell
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 1
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+**Technische Grundlage:** Plugin-Schnittstelle, Go-Interface, Registrierung
+
+## Produkt-DNA für diesen Bereich
+> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.
+
+**Übernehmen:**
+- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.
+- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.
+- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.
+
+**Bewusst vermeiden:**
+- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.
+- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.
+
+**Für genau diese Kachel:** Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Ausgangslage
+Diese Kachel hat keine Vorbedingungen und ist sofort startbar.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Neuer Connector lässt sich ohne Codeänderung an der Engine registrieren
+2. Fehlende Registrierung führt zu klarer Fehlermeldung statt Absturz
+3. Connector-Metadaten (Name, Version, unterstützte Operationen) sind 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. Zwei Testconnectoren parallel registriert und einzeln ansprechbar
+2. Deregistrierung entfernt Connector vollständig
+3. Fehlerhafter Connector wird beim Laden abgewiesen, Engine bleibt lauffähig
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-02` Verbindungs-Credential-Verwaltung
+- `ENG-03` Sync-Job-Verwaltung
+- `ENG-04` Feld-Mapping-Konfiguration
+- `ENG-06` Connector-Audit-Kopplung
+- `ERP-01` ERP-Connector-Grundgerüst
+- `DAT-01` DATEV-Format-Export
+- `DMS2-01` Standardisiertes Export-/Import-Format
+- `API-03` Externe Webhook-Abonnements
+
+## 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: 01 connector plugin modell`
+- Branch: `feature/eng-01-01-connector-plugin-modell`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-02.md b/connect-kanban/tickets/ENG-02.md
new file mode 100644
index 00000000..cb3d54c5
--- /dev/null
+++ b/connect-kanban/tickets/ENG-02.md
@@ -0,0 +1,66 @@
+# ENG-02 – Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt)
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.
+
+**Technische Grundlage:** Verschlüsselte Speicherung, OAuth2-Client, PostgreSQL
+
+## Produkt-DNA für diesen Bereich
+> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.
+
+**Übernehmen:**
+- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.
+- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.
+- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.
+
+**Bewusst vermeiden:**
+- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.
+- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.
+
+**Für genau diese Kachel:** Verwaltung von Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys), verschlüsselt gespeichert und je Connector-Instanz zugeordnet.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `IAM-09` API-Token & Service-Accounts
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Zugangsdaten sind ausschließlich verschlüsselt gespeichert
+2. OAuth-Token-Erneuerung läuft automatisiert ohne Nutzereingriff
+3. Widerruf einer Verbindung entfernt zugehörige Zugangsdaten vollständig
+
+## 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. Datenbankinhalt der Zugangsdaten-Tabelle ist ohne Schlüssel nicht lesbar
+2. Ablaufender OAuth-Token wird vor Ablauf erneuert
+3. Widerruf im Test entfernt Zugangsdaten nachweislich
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `M365-01` Microsoft-Graph-API-Anbindung (nutzt diese Verwaltung)
+- `API-01` Connect-Konfigurationsoberfläche
+- `QA-04` Sicherheitsprüfung Drittsystem-Credentials
+
+## 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: 02 verbindungs credential verwaltung oauth api keys verschluesselt`
+- Branch: `feature/eng-02-02-verbindungs-credential-verwaltung-oauth-api-keys-verschluesselt`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-03.md b/connect-kanban/tickets/ENG-03.md
new file mode 100644
index 00000000..43e2b46f
--- /dev/null
+++ b/connect-kanban/tickets/ENG-03.md
@@ -0,0 +1,64 @@
+# ENG-03 – Sync-Job-Verwaltung (periodische Imports/Exports)
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.
+
+**Technische Grundlage:** Postgres-Jobqueue, periodische Ausführung
+
+## Produkt-DNA für diesen Bereich
+> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.
+
+**Übernehmen:**
+- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.
+- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.
+- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.
+
+**Bewusst vermeiden:**
+- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.
+- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.
+
+**Für genau diese Kachel:** Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Sync-Job ist mit Zeitplan konfigurierbar
+2. Laufender Job überlebt einen Dienst-Neustart
+3. Manuelles Anstoßen eines Jobs außerhalb des Zeitplans 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. Zeitplan im Test korrekt eingehalten
+2. Neustart des Dienstes mit laufendem Job geprüft
+3. Manueller Anstoß erzeugt genau einen zusätzlichen Lauf
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen
+- `API-02` Verbindungsstatus-Übersicht & Diagnose
+
+## 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: 03 sync job verwaltung periodische imports exports`
+- Branch: `feature/eng-03-03-sync-job-verwaltung-periodische-imports-exports`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-04.md b/connect-kanban/tickets/ENG-04.md
new file mode 100644
index 00000000..156e0538
--- /dev/null
+++ b/connect-kanban/tickets/ENG-04.md
@@ -0,0 +1,63 @@
+# ENG-04 – Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem)
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.
+
+**Technische Grundlage:** Mapping-Konfiguration, Schema-Validierung
+
+## Produkt-DNA für diesen Bereich
+> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.
+
+**Übernehmen:**
+- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.
+- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.
+- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.
+
+**Bewusst vermeiden:**
+- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.
+- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.
+
+**Für genau diese Kachel:** Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Feld-Mapping ist ohne Codeänderung konfigurierbar
+2. Ungültiges Mapping wird beim Speichern abgewiesen
+3. Pflichtfeld ohne Zuordnung wird vor Ausführung gemeldet
+
+## 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. Ungültiges Mapping im Test abgewiesen
+2. Fehlendes Pflichtfeld-Mapping verhindert Sync-Start
+3. Geändertes Mapping wirkt erst auf nachfolgende Läufe
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-01` Connect-Konfigurationsoberfläche (Oberfläche für dieses Mapping)
+
+## 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: 04 feld mapping konfiguration nexarch drittsystem`
+- Branch: `feature/eng-04-04-feld-mapping-konfiguration-nexarch-drittsystem`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-05.md b/connect-kanban/tickets/ENG-05.md
new file mode 100644
index 00000000..798361b4
--- /dev/null
+++ b/connect-kanban/tickets/ENG-05.md
@@ -0,0 +1,63 @@
+# ENG-05 – Fehlerbehandlung & Retry bei Drittsystem-Ausfällen
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.
+
+**Technische Grundlage:** Retry mit Backoff, Fehlerprotokoll, Postgres-Jobqueue
+
+## Produkt-DNA für diesen Bereich
+> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.
+
+**Übernehmen:**
+- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.
+- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.
+- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.
+
+**Bewusst vermeiden:**
+- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.
+- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.
+
+**Für genau diese Kachel:** Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-03` Sync-Job-Verwaltung (periodische Imports/Exports) – Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Fehlgeschlagener Sync-Job wird mit Backoff automatisch wiederholt
+2. Dauerhafter Ausfall führt nach Grenzwert zu klarem Fehlerstatus statt Endlosschleife
+3. Fehlerprotokoll je Lauf ist einsehbar
+
+## 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 Drittsystem-Ausfall löst Retry mit Backoff aus
+2. Abbruchgrenze im Test erreicht und Status korrekt gesetzt
+3. Fehlerprotokoll enthält Ursache und Zeitpunkt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `API-02` Verbindungsstatus-Übersicht & Diagnose (zeigt dieses Protokoll an)
+
+## 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: 05 fehlerbehandlung retry bei drittsystem ausfaellen`
+- Branch: `feature/eng-05-05-fehlerbehandlung-retry-bei-drittsystem-ausfaellen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-06.md b/connect-kanban/tickets/ENG-06.md
new file mode 100644
index 00000000..7f232d36
--- /dev/null
+++ b/connect-kanban/tickets/ENG-06.md
@@ -0,0 +1,64 @@
+# ENG-06 – Connector-Audit-Kopplung (Core AUD)
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Einfach  |  **Aufwand:** 2 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Kopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.
+
+**Technische Grundlage:** Audit-Ereignis-Kopplung
+
+## Produkt-DNA für diesen Bereich
+> Ein Connector-Plugin-Modell wie bei Zapier/n8n, bewusst schlanker – kein visueller Workflow-Builder, nur austauschbare Adapter.
+
+**Übernehmen:**
+- Zapier/n8n: das Konzept austauschbarer Connector-Plugins mit klar definierter Schnittstelle statt fest verdrahteter Drittsystem-Logik.
+- Airbyte: Sync-Job mit Retry und Fehlerbehandlung als Vorbild für robuste periodische Imports/Exports.
+- Jeder Connector offen dokumentiert und ohne Herstellerwerkzeug ersetzbar – Linie aus der DMS-Produkt-DNA fortgeführt.
+
+**Bewusst vermeiden:**
+- Zapier/n8n – kein grafischer Workflow-Builder mit eigener Ausführungs-Engine als Voraussetzung. Die Kernidee austauschbarer Adapter genügt.
+- Proprietäre, geschlossene iPaaS-Plattformen mit Vendor-Lock – jeder Connector bleibt offen dokumentiert und ersetzbar.
+
+**Für genau diese Kachel:** Kopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- Setzt voraus (externes Core-Board, siehe /home/sysops/Dokumente/Scripte/nexarch/core-kanban/): `AUD-01` Zentrales Audit-Log-Modell
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jede sicherheitsrelevante Connector-Aktion erzeugt einen Audit-Eintrag im Core-Audit-Log
+2. Audit-Eintrag enthält Person, Zeitpunkt und betroffenen Connector
+3. Fehlende Audit-Kopplung verhindert die Aktion nicht, wird aber protokolliert
+
+## 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. Verbindung anlegen erzeugt nachweisbaren Audit-Eintrag
+2. Zugangsdaten ändern erzeugt nachweisbaren Audit-Eintrag
+3. Ausfall des Audit-Dienstes blockiert Connector-Betrieb nicht
+
+## 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 Connector-Engine
+
+## 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: 06 connector audit kopplung core aud`
+- Branch: `feature/eng-06-06-connector-audit-kopplung-core-aud`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-07.md b/connect-kanban/tickets/ENG-07.md
new file mode 100644
index 00000000..9125627d
--- /dev/null
+++ b/connect-kanban/tickets/ENG-07.md
@@ -0,0 +1,58 @@
+# ENG-07 – Drittsystem-Zugangsdaten über Core-Tenant-KEK-Hierarchie verschlüsseln
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-02 speichert Zugangsdaten für Drittsysteme (OAuth-Tokens, API-Keys) verschlüsselt, ohne festzulegen, mit welchem Schlüssel. Analog zu DMS `IAM-19` müssen diese Zugangsdaten über den Tenant-KEK aus der Core-Schlüsselhierarchie (API-10) verschlüsselt werden statt über ein separates, eigenes Verschlüsselungsschema – sonst entsteht neben der zentralen Schlüsselverwaltung ein zweiter, unabhängig zu härtender Verschlüsselungspfad für hochsensible Zugangsdaten.
+
+**Technische Grundlage:** Envelope-Encryption (Tenant-KEK aus Core API-10), PostgreSQL, Go
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Zitadel: Föderations-/Drittsystem-Credentials werden über dieselbe zentrale Schlüsselverwaltung geschützt wie andere sensible Tenant-Daten.
+
+**Bewusst vermeiden:**
+- Airbyte (verbreitetes Anti-Muster bei Connector-Plattformen) – Connector-Credentials teils in einem separaten, eigenen Secret-Store statt der zentralen Schlüsselverwaltung der Plattform.: genau eine Schlüsselhierarchie für alle sensiblen Tenant-Daten, kein zweiter Pfad für Connector-Zugangsdaten.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-02.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Drittsystem-Zugangsdaten (OAuth-Tokens, API-Keys) sind in der Datenbank ausschließlich verschlüsselt über den Tenant-KEK des jeweiligen Mandanten gespeichert
+2. Ein direkter Lesezugriff auf die Zugangsdaten-Tabelle liefert keinen verwertbaren Klartext
+3. Bestehende Connector-Authentifizierung aus ENG-02 funktioniert nach der Umstellung 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: Zugangsdaten in der Datenbank direkt auslesen, prüfen dass nur Chiffrat sichtbar ist
+2. Regressionstest: Connector-Verbindungsaufbau (ERP/DATEV/M365/DMS2) funktioniert nach Umstellung auf Tenant-KEK-Verschlüsselung weiterhin
+3. Test: Entschlüsselung schlägt fehl, wenn der falsche Tenant-KEK verwendet wird (kein Cross-Tenant-Zugriff auf Drittsystem-Credentials)
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Connect-Board, 2026-09-12), analog zu DMS-Finding `IAM-19`: ein separates Verschlüsselungsschema für Connector-Credentials wäre ein zweiter, unabhängig zu prüfender Sicherheitsmechanismus statt der Wiederverwendung der bereits gehärteten Core-Schlüsselhierarchie.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-02` Verbindungs-Credential-Verwaltung (OAuth/API-Keys, verschlüsselt)
+
+## 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: drittsystem-zugangsdaten-ber-core-tenant-kek-hierarchie-verschl-sseln`
+- Branch: `feature/eng-07-drittsystem-zugangsdaten-ber-core-tenant-kek-hierarchie-verschl-sseln`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-08.md b/connect-kanban/tickets/ENG-08.md
new file mode 100644
index 00000000..c093c298
--- /dev/null
+++ b/connect-kanban/tickets/ENG-08.md
@@ -0,0 +1,59 @@
+# ENG-08 – Ressourcenlimits & Rate-Limiting für Drittsystem-Sync-Jobs
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 7
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+ENG-03 verwaltet periodische Sync-Jobs, ENG-05 behandelt Fehler bei Drittsystem-Ausfällen mit Retry/Backoff, ohne Obergrenzen für Laufzeit oder Datenmenge je Sync-Lauf festzulegen. Ein fehlerhaft konfigurierter oder kompromittierter Connector (z. B. ein Drittsystem, das ungewöhnlich große Antworten liefert oder in einer Retry-Schleife hängen bleibt) kann sonst Ressourcen auf Kosten anderer Mandanten/Connectoren binden. Harte Obergrenzen je Sync-Lauf definieren (max. Laufzeit, max. übertragene Datenmenge, max. Anzahl Retry-Versuche als Abbruchgrenze aus ENG-05) sowie Rate-Limiting für ausgehende Anfragen an ein einzelnes Drittsystem.
+
+**Technische Grundlage:** Postgres-Jobqueue, Rate-Limiting, Ressourcenlimits (Zeit/Datenmenge)
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Airbyte: Sync-Job mit klar begrenzter Retry-Logik und definierten Abbruchbedingungen als Vorbild.
+
+**Bewusst vermeiden:**
+- Zapier/n8n (verbreitetes Anti-Muster) – Connector-Jobs ohne harte Obergrenze können bei Drittsystem-Fehlverhalten unbegrenzt Ressourcen binden.: harte, konfigurierbare Obergrenzen je Sync-Lauf von Anfang an, nicht erst nach einem Vorfall nachgerüstet.
+
+## Ausgangslage
+Setzt auf folgenden bereits fertigen Kacheln auf: ENG-03, ENG-05.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Sync-Job hat konfigurierbare Obergrenzen für Laufzeit und übertragene Datenmenge
+2. Die Abbruchgrenze für Retry-Versuche aus ENG-05 wird durchgesetzt, ein Job endet nach Erreichen der Grenze kontrolliert statt endlos zu wiederholen
+3. Ausgehende Anfragen an ein einzelnes Drittsystem sind ratenbegrenzt, sodass ein einzelner Connector nicht das gesamte Sync-System für andere Connectoren/Mandanten blockiert
+
+## 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: Sync-Job, der die Laufzeit-/Datenmengenobergrenze überschreitet, wird kontrolliert abgebrochen
+2. Test: Retry-Abbruchgrenze aus ENG-05 wird nach der konfigurierten Anzahl Versuche tatsächlich durchgesetzt
+3. Lasttest: ein Connector mit Drittsystem-Fehlverhalten blockiert nicht die Sync-Jobs anderer Connectoren/Mandanten
+
+## Bekannte Fehler vermeiden
+
+Threat-Model-Finding (Connect-Board, 2026-09-12): unbegrenzte Sync-Jobs gegenüber Drittsystemen sind ein Denial-of-Service-Vektor sowohl gegen die eigene Jobqueue (Ressourcenbindung) als auch potenziell gegen das angebundene Drittsystem (unkontrollierte Anfragerate).
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ENG-03` Sync-Job-Verwaltung (periodische Imports/Exports)
+- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen
+
+## 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-08: ressourcenlimits-rate-limiting-f-r-drittsystem-sync-jobs`
+- Branch: `feature/eng-08-ressourcenlimits-rate-limiting-f-r-drittsystem-sync-jobs`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ENG-10.md b/connect-kanban/tickets/ENG-10.md
new file mode 100644
index 00000000..7f3a176b
--- /dev/null
+++ b/connect-kanban/tickets/ENG-10.md
@@ -0,0 +1,51 @@
+# ENG-10 – Modul-weiter Kill-Switch und Ausfallisolation für Connect
+
+**Epic:** 🔌 Connector-Engine & Grundgerüst  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+
+## Auftrag
+Nutzeranfrage (2026-09-27): Connect soll abschaltbar sein, ODER ohne Abschaltung den Gesamtbetrieb der übrigen Module nicht stören können — konkretes Beispiel: Ausfall/Fehlkonfiguration von Microsoft Graph (M365-01) darf DMS/Mail/Workflow/AI/Core nicht beeinträchtigen.
+
+Zwei Teile:
+1. **Kill-Switch:** Connect als Ganzes per Umgebungsvariable abschaltbar (Standard: aktueller Stand beibehalten, dokumentieren was Standard ist). Ohne Schalter kein aktiver Codepfad/Port — etabliertes Muster aus INT-18/INT-19.
+2. **Ausfallisolation:** Ein Ausfall eines einzelnen Connectors (z. B. M365 durch Netzwerk-/Auth-Fehler) oder von Connect insgesamt darf keine anderen Module beeinträchtigen — kein geteilter Prozess, kein geteilter kritischer Ressourcen-Pool, Fehler bleiben im Connect-Modul lokal (aufbauend auf ENG-05 Retry/Backoff und ENG-08 Ressourcenlimits/Rate-Limiting, die bereits Einzel-Connector-Isolation *innerhalb* von Connect herstellen — hier geht es um die Grenze *zwischen* Connect und den anderen Modulen).
+
+**Technische Grundlage:** Umgebungsvariable als Kill-Switch (analog INT-18/INT-19), Prozess-/Ressourcentrennung (Connect läuft als eigener Dienst/Prozess, keine geteilten In-Process-Zustände mit anderen Modulen — das ist durch die Multi-Modul-Architektur dieser Session ohnehin bereits so; hier real nachweisen statt nur annehmen).
+
+## Ausgangslage
+- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen (fertig)
+- `ENG-08` Ressourcenlimits & Rate-Limiting für Drittsystem-Sync-Jobs (fertig, PR #220 gemergt)
+- `M365-01` Microsoft-Graph-API-Anbindung (fertig, PR #223, noch nicht gemergt) — dient als konkreter Testfall für diese Kachel
+- Etabliertes Kill-Switch-Muster: `NEXARCH_MOBILE_CAPTURE_ENABLED` (INT-19), SMTP-Gateway-Schalter (INT-18)
+
+## Akzeptanzkriterien
+1. Eine Umgebungsvariable schaltet Connect als Ganzes ab; ohne Aktivierung ist kein Connect-Codepfad/Port erreichbar
+2. Ein simulierter Totalausfall von Connect (Prozess/Dienst beendet oder Kill-Switch aus) hat nachweislich keine Auswirkung auf DMS/Mail/Workflow/AI/Core (deren Tests/Smoke-Läufe bleiben unverändert grün)
+3. Ein simulierter Ausfall eines einzelnen Connectors (z. B. M365 nicht erreichbar/falsch konfiguriert) blockiert nicht den Rest von Connect (andere Connectoren/Sync-Jobs laufen weiter) — Nachweis über den bereits bestehenden ENG-05/ENG-08-Mechanismus, hier nur die modulübergreifende Grenze zusätzlich geprüft
+
+## Prüfungen vor der Abnahme
+1. Kill-Switch aus: Connect-Endpunkte nicht erreichbar, andere Module unbeeinträchtigt (echter Smoke-Test ohne Connect)
+2. Connect-Prozess während laufendem Gesamtbetrieb hart beendet: `gesamt-token-smoke.sh` (ohne Connect-Anteile) bleibt grün
+3. M365-Connector mit absichtlich ungültigen Zugangsdaten/nicht erreichbarem Endpunkt: Connect insgesamt bleibt bedienbar, Fehler bleibt auf den M365-Connector begrenzt
+
+## Nicht Bestandteil dieser Kachel
+- Neue Retry-/Limit-Logik (bereits in ENG-05/ENG-08 vorhanden, hier nur grenzübergreifend nachgewiesen)
+- Rollout/Deploy auf Host 131
+
+## Arbeitsweise
+1. Lies zuerst ENG-05, ENG-08 und den bestehenden Kill-Switch-Code aus INT-18/INT-19, 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-10: connect kill-switch und ausfallisolation`
+- Branch: `feature/eng-10-connect-kill-switch-ausfallisolation`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ERP-01.md b/connect-kanban/tickets/ERP-01.md
new file mode 100644
index 00000000..d67d3f86
--- /dev/null
+++ b/connect-kanban/tickets/ERP-01.md
@@ -0,0 +1,63 @@
+# ERP-01 – ERP-Connector-Grundgerüst
+
+**Epic:** 📈 ERP/CRM-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).
+
+**Technische Grundlage:** ERP-Connector, REST/SOAP-Client
+
+## Produkt-DNA für diesen Bereich
+> Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.
+
+**Übernehmen:**
+- Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.
+- Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration.
+
+**Bewusst vermeiden:**
+- Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.
+- Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert.
+
+**Für genau diese Kachel:** Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Verbindung zu einem Test-ERP-System lässt sich aufbauen und prüfen
+2. Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar
+3. Verbindungsfehler wird klar gemeldet statt stillem Abbruch
+
+## 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. Verbindungsaufbau gegen Test-ERP-System erfolgreich geprüft
+2. Lese- und Schreiboperation im Test erfolgreich
+3. Simulierter Verbindungsfehler wird korrekt gemeldet
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ERP-03` Stammdaten-Abgleich
+- `ERP-04` Beleg-/Dokumentexport an ERP
+
+## 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: `ERP-01: 01 erp connector grundgeruest`
+- Branch: `feature/erp-01-01-erp-connector-grundgeruest`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ERP-02.md b/connect-kanban/tickets/ERP-02.md
new file mode 100644
index 00000000..10ca8fc1
--- /dev/null
+++ b/connect-kanban/tickets/ERP-02.md
@@ -0,0 +1,62 @@
+# ERP-02 – CRM-Connector-Grundgerüst
+
+**Epic:** 📈 ERP/CRM-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 2
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.
+
+**Technische Grundlage:** CRM-Connector, REST-Client
+
+## Produkt-DNA für diesen Bereich
+> Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.
+
+**Übernehmen:**
+- Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.
+- Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration.
+
+**Bewusst vermeiden:**
+- Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.
+- Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert.
+
+**Für genau diese Kachel:** Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-01` Connector-Plugin-Modell – Plugin-Schnittstelle, über die einzelne Drittsystem-Connectoren (ERP, CRM, DATEV, M365, andere DMS, Backup-Ziele) registriert werden, ohne dass die Engine connectorspezifisches Wissen braucht.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Verbindung zu einem Test-CRM-System lässt sich aufbauen und prüfen
+2. Basisoperationen (Lesen/Schreiben) sind über das Connector-Plugin-Modell nutzbar
+3. Verbindungsfehler wird klar gemeldet statt stillem Abbruch
+
+## 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. Verbindungsaufbau gegen Test-CRM-System erfolgreich geprüft
+2. Lese- und Schreiboperation im Test erfolgreich
+3. Simulierter Verbindungsfehler wird korrekt gemeldet
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ERP-03` Stammdaten-Abgleich
+
+## 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: `ERP-02: 02 crm connector grundgeruest`
+- Branch: `feature/erp-02-02-crm-connector-grundgeruest`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ERP-03.md b/connect-kanban/tickets/ERP-03.md
new file mode 100644
index 00000000..b0fb0496
--- /dev/null
+++ b/connect-kanban/tickets/ERP-03.md
@@ -0,0 +1,63 @@
+# ERP-03 – Stammdaten-Abgleich (Kunden/Lieferanten)
+
+**Epic:** 📈 ERP/CRM-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Automatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.
+
+**Technische Grundlage:** Sync-Logik, Konfliktbehandlung
+
+## Produkt-DNA für diesen Bereich
+> Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.
+
+**Übernehmen:**
+- Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.
+- Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration.
+
+**Bewusst vermeiden:**
+- Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.
+- Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert.
+
+**Für genau diese Kachel:** Automatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ERP-01` ERP-Connector-Grundgerüst – Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).
+- `ERP-02` CRM-Connector-Grundgerüst – Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Neuer Stammdatensatz im Drittsystem erscheint nach Sync in NEXARCH
+2. Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben
+3. Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung
+
+## 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. Neuanlage im Test-ERP nach Sync in NEXARCH sichtbar
+2. Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt statt Datenverlust
+3. Zeitplan-gesteuerter Lauf im Test erfolgreich
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `ERP-04` Beleg-/Dokumentexport an ERP
+
+## 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: `ERP-03: 03 stammdaten abgleich kunden lieferanten`
+- Branch: `feature/erp-03-03-stammdaten-abgleich-kunden-lieferanten`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/ERP-04.md b/connect-kanban/tickets/ERP-04.md
new file mode 100644
index 00000000..0148d8c1
--- /dev/null
+++ b/connect-kanban/tickets/ERP-04.md
@@ -0,0 +1,62 @@
+# ERP-04 – Beleg-/Dokumentexport an ERP
+
+**Epic:** 📈 ERP/CRM-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Export von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.
+
+**Technische Grundlage:** Dokumentexport, Feld-Mapping
+
+## Produkt-DNA für diesen Bereich
+> Stammdaten- und Belegaustausch mit ERP/CRM wie bei Airbyte-Sync-Jobs – nachvollziehbar, wiederholbar, mit Fehlerprotokoll.
+
+**Übernehmen:**
+- Airbyte: Sync-Job-Konzept mit Retry und Fehlerbehandlung für Stammdaten- und Belegabgleich.
+- Zapier/n8n: austauschbare Connector-Plugins je Zielsystem statt einer monolithischen ERP-Integration.
+
+**Bewusst vermeiden:**
+- Kein proprietäres, geschlossenes Austauschformat je ERP-Hersteller – offen dokumentierte Feld-Mappings.
+- Keine stille Datenüberschreibung bei Konflikten – Abgleich bleibt nachvollziehbar und protokolliert.
+
+**Für genau diese Kachel:** Export von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ERP-01` ERP-Connector-Grundgerüst – Connector-Grundgerüst für die Anbindung gängiger ERP-Systeme: Verbindungsaufbau, Basisoperationen (Lesen/Schreiben von Stammdaten und Belegen).
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Beleg lässt sich mit zugeordneten Metadaten an das ERP exportieren
+2. Fehlgeschlagener Export wird über die Fehlerbehandlung erneut versucht
+3. Bereits exportierter Beleg wird nicht doppelt übertragen
+
+## 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. Testbeleg im ERP nach Export mit korrekten Metadaten auffindbar
+2. Simulierter Exportfehler löst Retry aus
+3. Doppelversand im Test ausgeschlossen
+
+## 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 ERP/DATEV/M365
+
+## 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: `ERP-04: 04 beleg dokumentexport an erp`
+- Branch: `feature/erp-04-04-beleg-dokumentexport-an-erp`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/M365-01.md b/connect-kanban/tickets/M365-01.md
new file mode 100644
index 00000000..044f629c
--- /dev/null
+++ b/connect-kanban/tickets/M365-01.md
@@ -0,0 +1,63 @@
+# M365-01 – Microsoft-Graph-API-Anbindung (Auth/Basis)
+
+**Epic:** ☁️ Microsoft 365-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.
+
+**Technische Grundlage:** Microsoft Graph API, OAuth2
+
+## Produkt-DNA für diesen Bereich
+> Microsoft-365-Anbindung als austauschbarer Connector wie bei Zapier/n8n, nicht als tief verdrahtete Speziallösung.
+
+**Übernehmen:**
+- Zapier/n8n: Microsoft Graph als ein Connector unter vielen, austauschbar über dieselbe Plugin-Schnittstelle.
+- Airbyte: Sync-Job mit Retry für SharePoint/OneDrive-Dokumentabgleich.
+
+**Bewusst vermeiden:**
+- Keine Sonderbehandlung von Microsoft 365 außerhalb des allgemeinen Connector-Modells – gleiche Credential-Verwaltung, gleiche Sync-Job-Logik.
+- Kein Vendor-Lock – der Connector bleibt ersetzbar, ohne dass NEXARCH Connect an Microsoft-Werkzeuge gebunden ist.
+
+**Für genau diese Kachel:** Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.
+
+## 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.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Authentifizierung gegen Microsoft Graph im Test erfolgreich
+2. Zugangsdaten werden über die Connect-Credential-Verwaltung gespeichert
+3. Abgelaufene Berechtigung wird erkannt und klar gemeldet
+
+## 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. OAuth2-Anmeldung im Test gegen Microsoft-Testmandant erfolgreich
+2. Testaufruf einer Graph-API-Basisoperation erfolgreich
+3. Simulierter Berechtigungsablauf wird korrekt erkannt und gemeldet
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `M365-02` SharePoint/OneDrive-Dokumentabgleich
+- `M365-03` Outlook-Kalender-Kopplung
+
+## 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: `M365-01: 01 microsoft graph api anbindung auth basis`
+- Branch: `feature/m365-01-01-microsoft-graph-api-anbindung-auth-basis`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/M365-02.md b/connect-kanban/tickets/M365-02.md
new file mode 100644
index 00000000..7c0394ad
--- /dev/null
+++ b/connect-kanban/tickets/M365-02.md
@@ -0,0 +1,62 @@
+# M365-02 – SharePoint/OneDrive-Dokumentabgleich
+
+**Epic:** ☁️ Microsoft 365-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Abgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.
+
+**Technische Grundlage:** SharePoint/OneDrive-API, Sync-Logik
+
+## Produkt-DNA für diesen Bereich
+> Microsoft-365-Anbindung als austauschbarer Connector wie bei Zapier/n8n, nicht als tief verdrahtete Speziallösung.
+
+**Übernehmen:**
+- Zapier/n8n: Microsoft Graph als ein Connector unter vielen, austauschbar über dieselbe Plugin-Schnittstelle.
+- Airbyte: Sync-Job mit Retry für SharePoint/OneDrive-Dokumentabgleich.
+
+**Bewusst vermeiden:**
+- Keine Sonderbehandlung von Microsoft 365 außerhalb des allgemeinen Connector-Modells – gleiche Credential-Verwaltung, gleiche Sync-Job-Logik.
+- Kein Vendor-Lock – der Connector bleibt ersetzbar, ohne dass NEXARCH Connect an Microsoft-Werkzeuge gebunden ist.
+
+**Für genau diese Kachel:** Abgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `M365-01` Microsoft-Graph-API-Anbindung (Auth/Basis) – Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Dokument aus SharePoint/OneDrive erscheint nach Sync in NEXARCH mit Metadaten
+2. Änderungskonflikt wird erkannt und nicht stillschweigend überschrieben
+3. Abgleich läuft nach Zeitplan über die Sync-Job-Verwaltung
+
+## 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. Testdokument aus SharePoint nach Sync in NEXARCH korrekt vorhanden
+2. Gleichzeitige Änderung auf beiden Seiten erzeugt erkennbaren Konflikt
+3. Zeitplan-gesteuerter Lauf im Test erfolgreich
+
+## 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 ERP/DATEV/M365
+
+## 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: `M365-02: 02 sharepoint onedrive dokumentabgleich`
+- Branch: `feature/m365-02-02-sharepoint-onedrive-dokumentabgleich`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/M365-03.md b/connect-kanban/tickets/M365-03.md
new file mode 100644
index 00000000..dc3784b5
--- /dev/null
+++ b/connect-kanban/tickets/M365-03.md
@@ -0,0 +1,62 @@
+# M365-03 – Outlook-Kalender-Kopplung (Fristen/Wiedervorlage)
+
+**Epic:** ☁️ Microsoft 365-Anbindung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 4
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Kopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.
+
+**Technische Grundlage:** Outlook-Kalender-API, Fristen-Kopplung
+
+## Produkt-DNA für diesen Bereich
+> Microsoft-365-Anbindung als austauschbarer Connector wie bei Zapier/n8n, nicht als tief verdrahtete Speziallösung.
+
+**Übernehmen:**
+- Zapier/n8n: Microsoft Graph als ein Connector unter vielen, austauschbar über dieselbe Plugin-Schnittstelle.
+- Airbyte: Sync-Job mit Retry für SharePoint/OneDrive-Dokumentabgleich.
+
+**Bewusst vermeiden:**
+- Keine Sonderbehandlung von Microsoft 365 außerhalb des allgemeinen Connector-Modells – gleiche Credential-Verwaltung, gleiche Sync-Job-Logik.
+- Kein Vendor-Lock – der Connector bleibt ersetzbar, ohne dass NEXARCH Connect an Microsoft-Werkzeuge gebunden ist.
+
+**Für genau diese Kachel:** Kopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `M365-01` Microsoft-Graph-API-Anbindung (Auth/Basis) – Basis-Anbindung an Microsoft Graph: Authentifizierung über OAuth2 und grundlegende API-Aufrufe als Voraussetzung für SharePoint/OneDrive- und Outlook-Anbindung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Frist/Wiedervorlage erscheint als Kalendereintrag in Outlook
+2. Änderung der Frist in NEXARCH aktualisiert den Kalendereintrag
+3. Gelöschte Frist entfernt den zugehörigen Kalendereintrag
+
+## 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. Testfrist im Test-Outlook-Kalender korrekt sichtbar
+2. Friständerung im Test korrekt im Kalender nachgezogen
+3. Löschung im Test entfernt Kalendereintrag vollständig
+
+## 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 ERP/DATEV/M365
+
+## 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: `M365-03: 03 outlook kalender kopplung fristen wiedervorlage`
+- Branch: `feature/m365-03-03-outlook-kalender-kopplung-fristen-wiedervorlage`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/QA-01.md b/connect-kanban/tickets/QA-01.md
new file mode 100644
index 00000000..fd1d4d37
--- /dev/null
+++ b/connect-kanban/tickets/QA-01.md
@@ -0,0 +1,63 @@
+# QA-01 – Teststrategie Connect
+
+**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 Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Teststrategie für Connect: Testkorpus aus realen Drittsystem-Antworten (ERP, CRM, DATEV, Microsoft Graph), Testarten je Ausbaustufe, Freigabekriterien.
+
+**Technische Grundlage:** Testkorpus, Teststrategie-Dokument
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.
+- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.
+
+**Für genau diese Kachel:** Teststrategie für Connect: Testkorpus aus realen Drittsystem-Antworten (ERP, CRM, DATEV, Microsoft Graph), Testarten je Ausbaustufe, Freigabekriterien.
+
+## 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 ist dokumentiert und für alle Epics anwendbar
+2. Testkorpus enthält reale Beispieldaten je angebundenem Drittsystemtyp
+3. Freigabekriterien je Prüfgate sind eindeutig benannt
+
+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 liegt vollständig vor und wurde geprüft
+2. Testkorpus im Test auf Vollständigkeit je Systemtyp geprüft
+3. Freigabekriterien im Test auf Eindeutigkeit geprüft
+
+## 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 Connector-Engine
+- `QA-03` Prüfgate ERP/DATEV/M365
+
+## 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: 01 teststrategie connect`
+- Branch: `feature/qa-01-01-teststrategie-connect`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/QA-02.md b/connect-kanban/tickets/QA-02.md
new file mode 100644
index 00000000..ab7b3113
--- /dev/null
+++ b/connect-kanban/tickets/QA-02.md
@@ -0,0 +1,66 @@
+# QA-02 – Prüfgate Connector-Engine
+
+**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 Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Verbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).
+
+**Technische Grundlage:** Prüfprotokoll, automatisierte Tests
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.
+- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.
+
+**Für genau diese Kachel:** Verbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ENG-06` Connector-Audit-Kopplung (Core AUD) – Kopplung aller Connector-Aktionen (Verbindung angelegt, Sync ausgeführt, Zugangsdaten geändert) an das zentrale Core-Audit-Log.
+- `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.
+- `ENG-03` Sync-Job-Verwaltung (periodische Imports/Exports) – Verwaltung periodisch ausgeführter Sync-Jobs (Import/Export) je Connector-Instanz: Zeitplan, letzter Lauf, nächster Lauf.
+- `ENG-04` Feld-Mapping-Konfiguration (NEXARCH ↔ Drittsystem) – Konfigurierbares Feld-Mapping zwischen NEXARCH-Datenmodell und Drittsystem-Feldern je Connector-Instanz.
+- `ENG-05` Fehlerbehandlung & Retry bei Drittsystem-Ausfällen – Fehlerbehandlung für Sync-Jobs bei Drittsystem-Ausfällen: Retry mit Backoff, Fehlerprotokoll, Abbruchgrenze.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Akzeptanzkriterien der ENG-Kacheln sind geprüft und protokolliert
+2. Automatisierte Tests der ENG-Kacheln laufen fehlerfrei
+3. Prüfprotokoll ist abgelegt und nachlesbar
+
+## 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. Vollständiger Testlauf über alle ENG-Kacheln durchgeführt und protokolliert
+2. Fehlerinjektion (Drittsystem-Ausfall) im Test korrekt behandelt
+3. Audit-Kopplung im Test nachweislich vollständig
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme-Prüfung Connect
+
+## 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: 02 pruefgate connector engine`
+- Branch: `feature/qa-02-02-pruefgate-connector-engine`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/QA-03.md b/connect-kanban/tickets/QA-03.md
new file mode 100644
index 00000000..5698cf8c
--- /dev/null
+++ b/connect-kanban/tickets/QA-03.md
@@ -0,0 +1,71 @@
+# QA-03 – Prüfgate ERP/DATEV/M365
+
+**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 Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Verbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.
+
+**Technische Grundlage:** Prüfprotokoll, automatisierte Tests
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.
+- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.
+
+**Für genau diese Kachel:** Verbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `ERP-04` Beleg-/Dokumentexport an ERP – Export von Belegen/Dokumenten aus NEXARCH an das angebundene ERP-System inklusive Metadaten.
+- `DAT-03` DATEV-Export-Oberfläche & Protokoll – Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.
+- `M365-03` Outlook-Kalender-Kopplung (Fristen/Wiedervorlage) – Kopplung von NEXARCH-Fristen und Wiedervorlagen mit dem Outlook-Kalender über die Microsoft-Graph-Anbindung.
+- `ERP-02` CRM-Connector-Grundgerüst – Connector-Grundgerüst für die Anbindung gängiger CRM-Systeme: Verbindungsaufbau, Basisoperationen für Kontakte/Kunden.
+- `ERP-03` Stammdaten-Abgleich (Kunden/Lieferanten) – Automatisierter Abgleich von Kunden- und Lieferantenstammdaten zwischen NEXARCH und angebundenem ERP/CRM.
+- `M365-02` SharePoint/OneDrive-Dokumentabgleich – Abgleich von Dokumenten zwischen NEXARCH und SharePoint/OneDrive über die Microsoft-Graph-Anbindung.
+- `DMS2-01` Standardisiertes Export-/Import-Format (offen, dokumentiert) – Offen dokumentiertes Export-/Import-Format für Dokumente und Metadaten zur Interoperabilität mit anderen DMS-Systemen.
+- `DMS2-02` Import-Assistent für Drittsystem-Exporte – Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.
+- `DMS2-03` Externe-Backup-Ziel-Anbindung – Anbindung externer Backup-Ziele (z. B. S3-kompatibler Speicher) für den verschlüsselten Export von Dokumentbeständen.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle Akzeptanzkriterien der ERP-, DAT- und M365-Kacheln sind geprüft und protokolliert
+2. Automatisierte Tests laufen fehlerfrei gegen Testsysteme
+3. Prüfprotokoll ist abgelegt und nachlesbar
+4. Alle Akzeptanzkriterien der DMS2-Kacheln (Interoperabilität mit Drittsystemen) sind ebenfalls geprüft und protokolliert
+
+## 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. Vollständiger Testlauf über ERP-, DAT- und M365-Kacheln durchgeführt und protokolliert
+2. Mindestens ein echter Testlauf je Drittsystemtyp durchgeführt
+3. Fehlerbehandlung bei simuliertem Ausfall je Systemtyp geprüft
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme-Prüfung Connect
+
+## 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: 03 pruefgate erp datev m365`
+- Branch: `feature/qa-03-03-pruefgate-erp-datev-m365`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/QA-04.md b/connect-kanban/tickets/QA-04.md
new file mode 100644
index 00000000..25be6f2a
--- /dev/null
+++ b/connect-kanban/tickets/QA-04.md
@@ -0,0 +1,62 @@
+# QA-04 – Sicherheitsprüfung Drittsystem-Credentials
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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
+Gezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.
+
+**Technische Grundlage:** Sicherheitsprüfung, Penetrationstest-Checkliste
+
+## Produkt-DNA für diesen Bereich
+> Prüfen heißt messen. Behauptungen ohne Messprotokoll gelten nicht als erledigt.
+
+**Übernehmen:**
+- Fester Testkorpus aus echten Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.
+- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.
+
+**Für genau diese Kachel:** Gezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.
+
+## 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.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Verschlüsselung der Zugangsdaten besteht die Sicherheitsprüfung
+2. Zugriff auf Zugangsdaten ist auf berechtigte Rollen beschränkt
+3. Schlüsselverwaltung folgt dokumentierten Sicherheitsvorgaben
+
+## 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. Verschlüsselungsprüfung gegen Datenbankinhalt durchgeführt und protokolliert
+2. Zugriffsprüfung mit unberechtigter Rolle im Test abgewiesen
+3. Schlüsselrotation im Test ohne Datenverlust durchgeführt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `QA-05` Abnahme-Prüfung Connect
+
+## 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: 04 sicherheitspruefung drittsystem credentials`
+- Branch: `feature/qa-04-04-sicherheitspruefung-drittsystem-credentials`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/QA-05.md b/connect-kanban/tickets/QA-05.md
new file mode 100644
index 00000000..1435bb37
--- /dev/null
+++ b/connect-kanban/tickets/QA-05.md
@@ -0,0 +1,67 @@
+# QA-05 – Abnahme-Prüfung Connect
+
+**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 Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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 Abnahme-Prüfung von NEXARCH Connect über alle Epics hinweg, Freigabe zur Nutzung durch andere Module.
+
+**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 Drittsystem-Antworten (ERP, DATEV, Microsoft Graph), an dem Connectoren wiederholbar geprüft werden.
+- Nachgewiesene Fehlerinjektion (Drittsystem-Ausfall, Timeout) als Freigabevoraussetzung für Retry-Logik.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur gegen Mock-Antworten ohne mindestens einen echten Drittsystem-Testlauf.
+
+**Für genau diese Kachel:** Abschließende Abnahme-Prüfung von NEXARCH Connect über alle Epics hinweg, Freigabe zur Nutzung durch andere Module.
+
+## 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 Connector-Engine – Verbindliches Prüfgate für die Connector-Engine (Plugin-Modell, Credential-Verwaltung, Sync-Jobs, Mapping, Fehlerbehandlung, Audit-Kopplung).
+- `QA-03` Prüfgate ERP/DATEV/M365 – Verbindliches Prüfgate für ERP/CRM-, DATEV- und Microsoft-365-Anbindung.
+- `QA-04` Sicherheitsprüfung Drittsystem-Credentials – Gezielte Sicherheitsprüfung der Drittsystem-Credential-Verwaltung: Verschlüsselung, Zugriffskontrolle, Schlüsselverwaltung.
+- `QA-06` Schnittstellen-Vertragstests – Vertragstests für externe Webhook-Abonnements (API-03) – anders als bei internen Modul-zu-Modul-Schnittstellen sind hier externe Drittsysteme die Konsumenten, ein Breaking Change trifft Kunden direkt, nicht nur ein anderes NEXARCH-Modul.
+- `QA-07` Last- & Leistungstest – Lasttest für Connect unter realistischer Last aus mehreren gleichzeitig synchronisierenden Connector-Instanzen (ERP, DATEV, M365) – insbesondere Credential-Verwaltung (ENG-02) und Sync-Job-Queue unter Last.
+- `QA-08` Barrierefreiheits-Audit – Unabhängige Prüfung aller Connect-Oberflächen (DATEV-Export-Oberfläche, Import-Assistent, Connect-Konfigurationsoberfläche, Verbindungsstatus-Ü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 vorgelagerten Prüfgates sind abgeschlossen und protokolliert
+2. Zusammenspiel aller Connectoren im Gesamttest geprüft
+3. Abnahmeprotokoll ist abgelegt und nachlesbar
+
+## 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. Gesamttest über alle Connectoren durchgeführt und protokolliert
+2. Zusammenspiel mit Core-Webhook-Registry im Test geprüft
+3. Abnahmeprotokoll vollständig und nachvollziehbar abgelegt
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Keine weiteren offenen Punkte.
+
+## 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: 05 abnahme pruefung connect`
+- Branch: `feature/qa-05-05-abnahme-pruefung-connect`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/QA-06.md b/connect-kanban/tickets/QA-06.md
new file mode 100644
index 00000000..25934cc4
--- /dev/null
+++ b/connect-kanban/tickets/QA-06.md
@@ -0,0 +1,61 @@
+# QA-06 – Schnittstellen-Vertragstests
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 3
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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 externe Webhook-Abonnements (API-03) – anders als bei internen Modul-zu-Modul-Schnittstellen sind hier externe Drittsysteme die Konsumenten, ein Breaking Change trifft Kunden direkt, nicht nur ein anderes NEXARCH-Modul.
+
+**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 für das Webhook-Abonnement-Format, an dem Kompatibilität wiederholbar geprüft wird.
+- Nachgewiesene Erkennung von Breaking Changes als Freigabevoraussetzung, bevor ein externes Drittsystem betroffen ist.
+
+**Bewusst vermeiden:**
+- Keine Freigabe auf Zuruf. Jedes Prüfgate hinterlässt ein abgelegtes, nachlesbares Protokoll.
+- Keine Prüfung nur gegen Mock-Antworten ohne Abgleich mit dem tatsächlich ausgelieferten Webhook-Format.
+
+**Für genau diese Kachel:** Bei externen Webhook-Konsumenten (Drittsysteme, nicht andere NEXARCH-Module) ist ein unangekündigter Breaking Change besonders teuer – der Kunde merkt es erst, wenn sein System nicht mehr reagiert, nicht durch einen internen CI-Fehlschlag bei uns.
+
+## Ausgangslage
+Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
+- `API-03` Externe Webhook-Abonnements (nutzt Core API-07) – Abonnieren externer Systemereignisse über Webhooks, die die zentrale Core-Webhook-Registry zustellt – Connect registriert lediglich Abonnements, betreibt keine eigene Zustellung.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Vertragstests decken das Webhook-Abonnement-Format vollständig ab
+2. Absichtlich brechender Schema-Wechsel 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 erkannt
+3. CI-Integration nachgewiesen
+
+## Nicht Bestandteil dieser Kachel
+- Alles, was nicht in den Akzeptanzkriterien steht. Keine vorauseilende Umsetzung späterer Anforderungen.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-06: schnittstellen-vertragstests`
+- Branch: `feature/qa-06-schnittstellen-vertragstests`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/QA-07.md b/connect-kanban/tickets/QA-07.md
new file mode 100644
index 00000000..ab785cd3
--- /dev/null
+++ b/connect-kanban/tickets/QA-07.md
@@ -0,0 +1,60 @@
+# QA-07 – Last- & Leistungstest
+
+**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 Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele), das vollständig auf der REST-API-Infrastruktur, dem Rate-Limiting, der Webhook-Zustellung, der Token-Verwaltung und dem Audit-Log von NEXARCH Core aufbaut, statt eigene Infrastruktur dafür zu bauen.
+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 Connect unter realistischer Last aus mehreren gleichzeitig synchronisierenden Connector-Instanzen (ERP, DATEV, M365) – insbesondere Credential-Verwaltung (ENG-02) und Sync-Job-Queue 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:** Connect spricht mehrere Drittsysteme gleichzeitig an – ohne Lasttest bleibt unklar, ob Credential-Verwaltung und Job-Queue das verkraften, ohne Rate-Limits von ERP/DATEV/M365 zu verletzen.
+
+## 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.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Definierte Ziel-Latenz für Credential-Abruf unter Last mehrerer gleichzeitiger Connector-Instanzen eingehalten
+2. Sync-Job-Queue verarbeitet viele gleichzeitig eingereihte Jobs ohne Verklemmung oder Doppelverarbeitung
+3. Rate-Limiting gegenüber Drittsystemen bleibt unter Mehrinstanz-Last korrekt eingehalten
+
+## 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 Sync-Jobs mehrerer Connector-Typen durchgeführt, Ergebnis dokumentiert
+2. Test auf Doppelverarbeitung/Verklemmung der Job-Queue unter Last
+3. Rate-Limit-Verhalten gegenüber Drittsystemen bei mehreren gleichzeitigen Connector-Instanzen geprüft
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- (keine direkt abhängigen Kacheln bekannt)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
+
+## Abschluss
+- Commit-Nachricht: `QA-07: last leistungstest`
+- Branch: `feature/qa-07-last-leistungstest`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/QA-08.md b/connect-kanban/tickets/QA-08.md
new file mode 100644
index 00000000..181b6b64
--- /dev/null
+++ b/connect-kanban/tickets/QA-08.md
@@ -0,0 +1,61 @@
+# QA-08 – Barrierefreiheits-Audit
+
+**Epic:** ✅ Prüfungen & Qualitätssicherung  |  **Rolle:** QA  |  **Komplexität:** Mittel  |  **Aufwand:** 3 Personentage  |  **Welle:** 5
+
+---
+
+## Rolle
+Du bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Connect (Modul für externe Systemanbindungen: ERP/CRM, DATEV, Microsoft 365, Interoperabilität mit anderen DMS-Systemen und externe Backup-Ziele).
+Unabhängige Prüfung gegen die dokumentierten Akzeptanzkriterien – kein Wiederholen der Entwicklertests.
+
+## Auftrag
+Unabhängige Prüfung aller Connect-Oberflächen (DATEV-Export-Oberfläche, Import-Assistent, Connect-Konfigurationsoberfläche, Verbindungsstatus-Ü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 Connect 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 Connect-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:
+- `DAT-03` DATEV-Export-Oberfläche & Protokoll – Oberfläche zum Anstoßen von DATEV-Exporten sowie Einsicht in Exportprotokolle und Übertragungsstatus.
+- `DMS2-02` Import-Assistent für Drittsystem-Exporte – Assistent, der Exporte aus gängigen Drittsystem-DMS einliest, Feld-Mapping vorschlägt und den Import durchführt.
+- `API-01` Connect-Konfigurationsoberfläche (Connectoren einrichten) – Oberfläche zum Einrichten und Konfigurieren von Connectoren: Verbindung anlegen, Zugangsdaten hinterlegen, Feld-Mapping bearbeiten.
+- `API-02` Verbindungsstatus-Übersicht & Diagnose – Übersicht über alle eingerichteten Verbindungen mit Status, letztem Sync-Lauf und Diagnoseinformationen bei Fehlern.
+- 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 – Connect hätte ungeprüft geblieben, obwohl die Oberflächen dieselbe Core-SHL-01-Basis nutzen. Audit deshalb als eigene Kachel je Board, analog DMS QA-11 und Mail QA-08.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- Core `SHL-01` WCAG-Basis-Komponenten selbst (diese Kachel prüft nur die Nutzung).
+- Behebung gefundener Verstöße in den jeweiligen Frontend-Kacheln.
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
+2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
+3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
+4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
+5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
+6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
diff --git a/connect-kanban/tickets/SEC-01.md b/connect-kanban/tickets/SEC-01.md
new file mode 100644
index 00000000..d5f592c1
--- /dev/null
+++ b/connect-kanban/tickets/SEC-01.md
@@ -0,0 +1,68 @@
+# SEC-01 – Echte Authentifizierung und verifizierter Tenant-Kontext für Connect-APIs
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Hoch  |  **Aufwand:** 3 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main-Branch, Fable 5.1) hat festgestellt: `connect/internal/statusapi/statusapi.go:57-70`, `connect/internal/dms2importapi/dms2importapi.go:41-54` und `connect/internal/datevapi/datevapi.go:30-43` prüfen jeweils nur, ob der Header `X-User-Id` nicht leer ist. Der Mandant wird unverifiziert aus dem Header `X-Tenant-Slug` übernommen. `connect/cmd/connect-app/main.go:48-49` registriert diese Handler ohne Authentifizierungs-Middleware. `statusapi.WithPolicy()` (RBAC-Prüfung gegen Core) existiert im Code bereits, wird aber in `main.go` nirgends aufgerufen.
+
+Damit ist jeder beliebige Mandant per Header fälschbar:
+- `curl -H 'X-User-Id: a' -H 'X-Tenant-Slug: ' /connectors/status` liefert Sync-Status inkl. `last_error` eines fremden Mandanten.
+- `POST /dms2/import/execute` mit fremdem `X-Tenant-Slug` überschreibt aktive Field-Mappings fremder Mandanten und legt Import-Läufe im Namen des fremden Mandanten an (Vergiftung des GoBD-Protokolls).
+- `GET` auf `dms2_import_runs` fremder Mandanten per ID ist ohne Berechtigungsprüfung möglich.
+
+Das DMS-Modul hat dieses Problem bereits korrekt gelöst: `dms/internal/moduleauth/middleware.go:72` verifiziert das JWT kryptografisch und leitet Tenant/User erst danach aus dem geprüften Token ab, statt aus einem vom Aufrufer gesetzten Header.
+
+**Technische Grundlage:** JWT-Verifikation (Core-Token), Go net/http Middleware, RBAC-Policy-Prüfung gegen Core
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- DMS-Modul (`moduleauth/middleware.go`): Tenant- und User-Kontext werden ausschließlich aus einem kryptografisch verifizierten Core-Token abgeleitet, nie aus einem vom Client gesetzten Header.
+
+**Bewusst vermeiden:**
+- Vertrauen in unverifizierte Request-Header als Sicherheitsgrenze — das aktuelle Connect-Verhalten ist genau dieses Anti-Muster.
+
+## Ausgangslage
+Setzt auf der bestehenden Core-Token-Infrastruktur und dem DMS-Vorbild `moduleauth` auf. `statusapi.WithPolicy()` ist bereits vorhanden und ungenutzt.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Jeder Connect-API-Aufruf (`statusapi`, `dms2importapi`, `datevapi` und alle weiteren Fach-APIs in `connect/cmd/connect-app/main.go`) verlangt ein gültiges, kryptografisch verifiziertes Core-Token; ein Request ohne gültiges Token wird mit 401 abgewiesen.
+2. Tenant- und User-Kontext werden ausschließlich aus dem verifizierten Token abgeleitet; die Header `X-User-Id` und `X-Tenant-Slug` haben keinen Einfluss mehr auf den verwendeten Tenant, wenn sie vom Tokeninhalt abweichen.
+3. `statusapi.WithPolicy()` ist in `main.go` tatsächlich vor jeder Fach-API verdrahtet; ein Aufruf ohne ausreichende RBAC-Berechtigung wird mit 403 abgewiesen.
+4. Ein Angriff mit gefälschtem `X-Tenant-Slug`-Header auf fremde Mandantendaten (Status, Field-Mappings, Import-Läufe) ist nach der Umstellung nachweislich blockiert.
+
+## 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. Angriff vor der Fix-Umsetzung real nachstellen: `curl -H 'X-User-Id: a' -H 'X-Tenant-Slug: ' /connectors/status` gegen eine Testinstanz ausführen und dokumentieren, dass fremde Mandantendaten (inkl. `last_error`) tatsächlich zurückkommen.
+2. Denselben Angriff gegen `POST /dms2/import/execute` mit fremdem `X-Tenant-Slug` nachstellen und dokumentieren, dass vor dem Fix ein Import-Lauf im Namen des fremden Mandanten angelegt wird.
+3. Nach der Umsetzung denselben Request ohne gültiges Core-Token bzw. mit gefälschtem `X-Tenant-Slug` wiederholen und nachweisen, dass er mit 401/403 abgewiesen wird und keine fremden Daten mehr liefert.
+4. Regressionstest: ein legitimer Request mit gültigem Core-Token und korrektem Tenant funktioniert nach der Umstellung unverändert für `statusapi`, `dms2importapi` und `datevapi`.
+5. Test: RBAC-Policy-Verweigerung (`WithPolicy()`) löst bei unzureichender Rolle tatsächlich 403 aus.
+
+## Bekannte Fehler vermeiden
+
+Security-Review-Finding K1 (kritisch, main-Branch, Fable 5.1): Connect-APIs prüfen nur `X-User-Id != ""`, Tenant kommt unverifiziert aus `X-Tenant-Slug`. `statusapi.WithPolicy()` existiert, wird aber nicht verdrahtet. Fundstellen: `connect/internal/statusapi/statusapi.go:57-70`, `connect/internal/dms2importapi/dms2importapi.go:41-54`, `connect/internal/datevapi/datevapi.go:30-43`, `connect/cmd/connect-app/main.go:48-49`.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SEC-05` Tenant-Bindung der Store-Methoden (IDOR-Härtung)
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster, insbesondere `dms/internal/moduleauth/middleware.go`.
+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: authentifizierung-und-tenant-kontext-fuer-connect-apis`
+- Branch: `feature/sec-01-authentifizierung-und-tenant-kontext-fuer-connect-apis`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/SEC-02.md b/connect-kanban/tickets/SEC-02.md
new file mode 100644
index 00000000..f89dbe2d
--- /dev/null
+++ b/connect-kanban/tickets/SEC-02.md
@@ -0,0 +1,62 @@
+# SEC-02 – Entpack-Limit gegen Zip-Bomben im DMS2-Import
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 1 Personentag  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main-Branch, Fable 5.1) hat festgestellt: `connect/internal/dms2import/parse.go:219-225` (Funktion `readZipEntry`) liest jeden Zip-Eintrag per `io.ReadAll(rc)` ohne Begrenzung ein — sowohl für das Manifest (Aufruf in Zeile 65) als auch für jedes einzelne Originaldokument (Aufruf in Zeile 140). `connect/internal/dmsexchange/dmsexchange.go:1966-1973` zeigt dasselbe Muster.
+
+Das bestehende 200-MiB-Limit in `connect/internal/dms2importapi/dms2importapi.go:26` begrenzt nur die komprimierte Dateigröße des Uploads. `UncompressedSize64` aus dem Zip-Header wird nirgends geprüft. Ein präpariertes Zip von wenigen MiB (z. B. 10 MiB) kann beim Entpacken auf mehrere GiB anwachsen (Zip-Bomb) und den Prozess per Speichererschöpfung (OOM) zum Absturz bringen. In Kombination mit dem in SEC-01 beschriebenen Fehlen der Authentifizierung ist dieser Angriff aktuell unauthentifiziert auslösbar.
+
+**Technische Grundlage:** Go `archive/zip`, Streaming-Lese-Limits, `connect/internal/dms2import/parse.go`, `connect/internal/dmsexchange/dmsexchange.go`
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Allgemeines Härtungsmuster für Datei-Uploads: Grenzwerte sowohl auf die komprimierte als auch auf die entpackte Größe, pro Eintrag und kumulativ über das gesamte Archiv.
+
+**Bewusst vermeiden:**
+- Sich allein auf die komprimierte Dateigröße als Schutzmaßnahme zu verlassen — das ist exakt die aktuelle Lücke.
+
+## Ausgangslage
+Setzt auf dem bestehenden DMS2-Import-Parser (`dms2import`) und dem Backup-Austauschformat (`dmsexchange`) auf; beide teilen das verwundbare Entpack-Muster.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. `readZipEntry` in `connect/internal/dms2import/parse.go` prüft vor und während des Entpackens sowohl `UncompressedSize64` des jeweiligen Zip-Eintrags als auch die kumulierte entpackte Gesamtgröße des Archivs gegen feste Obergrenzen.
+2. Das gleiche Limit gilt für das analoge Entpack-Muster in `connect/internal/dmsexchange/dmsexchange.go:1966-1973`.
+3. Wird ein Einzel- oder Gesamtlimit überschritten, bricht der Import mit einer klaren Fehlermeldung ab, statt den Entpackvorgang fortzusetzen oder den Prozess abstürzen zu lassen.
+4. Die Limits greifen bereits während des Lesens (streaming, z. B. über `io.LimitReader` bzw. zählendes Lesen), nicht erst nach vollständigem Entpacken eines Eintrags.
+
+## 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. Angriff vor der Fix-Umsetzung real nachstellen: ein Test-Zip mit stark komprimierbarem Inhalt (z. B. Nullbytes) erzeugen, das bei ca. 10 MiB komprimiert auf mehrere GiB entpackt, und dokumentieren, dass der aktuelle Code unbegrenzt entpackt (Speicherverbrauch messen oder Abbruch durch OOM-Killer protokollieren).
+2. Nach der Umsetzung denselben Testfall wiederholen und nachweisen, dass der Import vor Erreichen übermäßigen Speicherverbrauchs mit einer klaren Fehlermeldung abbricht.
+3. Regressionstest: ein normales, legitimes Import-Zip innerhalb der Limits wird weiterhin korrekt eingelesen.
+4. Grenzfalltest: ein Zip knapp unterhalb und knapp oberhalb des konfigurierten Limits liefert das erwartete Verhalten (Erfolg bzw. Abbruch).
+
+## Bekannte Fehler vermeiden
+
+Security-Review-Finding H12 (hoch, main-Branch, Fable 5.1): `io.ReadAll(rc)` ohne Limit in `readZipEntry` (`connect/internal/dms2import/parse.go:219-225`, Aufrufe Zeile 65 und 140) und analog in `connect/internal/dmsexchange/dmsexchange.go:1966-1973`. Das 200-MiB-Limit in `dms2importapi.go:26` gilt nur für die komprimierte Größe, nicht für `UncompressedSize64`.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SEC-01` Authentifizierung der Connect-APIs
+
+## 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: entpack-limit-gegen-zip-bomben-im-dms2-import`
+- Branch: `feature/sec-02-entpack-limit-gegen-zip-bomben-im-dms2-import`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/SEC-03.md b/connect-kanban/tickets/SEC-03.md
new file mode 100644
index 00000000..776fefaa
--- /dev/null
+++ b/connect-kanban/tickets/SEC-03.md
@@ -0,0 +1,64 @@
+# SEC-03 – Append-only-Schutz für Connect-Protokolltabellen
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main-Branch, Fable 5.1) hat festgestellt: Keine der 12 Migrationen unter `connect/migrations/` richtet ein DB-seitiges Append-only für Protokolltabellen ein (kein `REVOKE UPDATE/DELETE` von der Anwendungsrolle, kein Trigger, der nachträgliche Änderungen verweigert). Betroffen sind insbesondere `datev_exports` (10-jährige GoBD-Aufbewahrungspflicht), `dms2_import_runs` und `connect_audit_outbox`.
+
+Der Anwendungscode selbst führt derzeit UPDATE/DELETE direkt auf Protokolltabellen aus: `connect/internal/syncjob/syncjob.go:258`, `connect/internal/audittrail/audittrail.go:1120`, `connect/internal/credential/credential.go:793`. Ohne DB-seitige Durchsetzung kann jeder Code- oder Rechtepfad, der Schreibzugriff auf diese Tabellen erhält (auch versehentlich oder über einen künftigen Bug), GoBD-pflichtige Exportprotokolle und Audit-Einträge nachträglich verändern oder löschen — ein Verstoß gegen die Unveränderbarkeitspflicht und ein Nachweisproblem im Streitfall.
+
+Core AUD-07, DMS VER-08 und Workflow ENG-07 haben dieses Muster bereits etabliert: `REVOKE UPDATE, DELETE` von der Anwendungsrolle auf die Protokolltabelle, ein Trigger, der dennoch versuchte Änderungen mit `RAISE WARNING` abweist, sowie (bei `BIGSERIAL`-Primärschlüsseln) ein passendes `GRANT` auf die zugehörige Sequence, damit INSERT weiterhin funktioniert.
+
+**Technische Grundlage:** PostgreSQL `REVOKE`/`GRANT`, Trigger-Funktion mit `RAISE WARNING`/`RAISE EXCEPTION`, Migrationen unter `connect/migrations/`
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Core AUD-07 / DMS VER-08 / Workflow ENG-07: DB-seitiges Append-only für alle GoBD- und audit-relevanten Protokolltabellen, nicht nur anwendungsseitige Disziplin.
+
+**Bewusst vermeiden:**
+- Sich auf anwendungsseitige Konventionen ("der Code macht einfach kein UPDATE auf dieser Tabelle") statt auf eine erzwingende DB-Schranke zu verlassen.
+
+## Ausgangslage
+Setzt auf dem in Core AUD-07, DMS VER-08 und Workflow ENG-07 etablierten Append-only-Muster auf; dieses wird eins zu eins für Connect übernommen, nicht neu erfunden.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Für `datev_exports`, `dms2_import_runs` und `connect_audit_outbox` ist der Anwendungsrolle per `REVOKE` das Recht auf UPDATE und DELETE entzogen.
+2. Ein Trigger auf diesen Tabellen weist einen dennoch versuchten UPDATE/DELETE zuverlässig ab und protokolliert den Versuch (`RAISE WARNING` bzw. `RAISE EXCEPTION`, analog zum etablierten Muster).
+3. INSERT auf diese Tabellen funktioniert nach der Umstellung unverändert, inklusive korrektem Sequence-GRANT für `BIGSERIAL`-Primärschlüssel.
+4. Die bestehenden Codepfade, die aktuell UPDATE/DELETE auf diese Tabellen ausführen (`syncjob.go:258`, `audittrail.go:1120`, `credential.go:793`), sind so angepasst, dass sie ohne Schreibversuch auf die geschützten Felder funktionieren (z. B. über neue Zeilen statt Änderung bestehender Zeilen), oder es ist dokumentiert, warum der jeweilige Pfad korrekt entfernt werden konnte.
+
+## 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. Vor der Migration: nachweisen, dass ein direktes UPDATE/DELETE auf `datev_exports`, `dms2_import_runs` bzw. `connect_audit_outbox` mit der Anwendungsrolle tatsächlich gelingt (Angriff/Ist-Zustand real nachstellen).
+2. Nach der Migration: denselben UPDATE/DELETE-Versuch wiederholen und nachweisen, dass er von der Datenbank abgewiesen wird und der Trigger die Warnung protokolliert.
+3. Regressionstest: INSERT neuer Zeilen in alle drei Tabellen funktioniert nach der Migration unverändert, inklusive Sequence-Vergabe.
+4. Regressionstest: die angepassten Codepfade in `syncjob.go`, `audittrail.go` und `credential.go` funktionieren nach der Umstellung fachlich weiterhin korrekt (z. B. Sync-Job-Status-Historie, Audit-Trail, Credential-Widerruf).
+
+## Bekannte Fehler vermeiden
+
+Security-Review-Finding H15 (hoch, main-Branch, Fable 5.1): keine der 12 Migrationen unter `connect/migrations/` erzwingt Append-only auf Protokolltabellen; Code macht UPDATE/DELETE auf `datev_exports`, `dms2_import_runs`, `connect_audit_outbox` (`syncjob.go:258`, `audittrail.go:1120`, `credential.go:793`). Etabliertes Gegenmuster: Core AUD-07, DMS VER-08, Workflow ENG-07.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SEC-01` Authentifizierung der Connect-APIs
+
+## Arbeitsweise
+1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster, insbesondere die Append-only-Migrationen von Core AUD-07, DMS VER-08 und Workflow ENG-07.
+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: append-only-schutz-fuer-connect-protokolltabellen`
+- Branch: `feature/sec-03-append-only-schutz-fuer-connect-protokolltabellen`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/SEC-04.md b/connect-kanban/tickets/SEC-04.md
new file mode 100644
index 00000000..47407463
--- /dev/null
+++ b/connect-kanban/tickets/SEC-04.md
@@ -0,0 +1,61 @@
+# SEC-04 – Fremdsystem-Antwortkörper vor Speicherung in last_error filtern
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Niedrig  |  **Aufwand:** 1 Personentag  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main-Branch, Fable 5.1) hat festgestellt: `connect/internal/datevtransfer/datevtransfer.go:676-682`, `connect/internal/m365connector.go:112` und `connect/internal/backupconnector.go:101,139` speichern bei Fehlern den Antwortkörper des jeweiligen Fremdsystems bis zu einer Größe von 1 MiB ungefiltert im Feld `last_error`. Dieses Feld ist über `connect/internal/statusapi/statusapi.go:102` per Status-API auslesbar.
+
+Antwortkörper von Fremdsystemen (insbesondere S3-kompatiblen Backup-Zielen) können sicherheitsrelevante Details enthalten, z. B. eine AWS-Fehlermeldung mit `StringToSign` und `AccessKeyID`. Dadurch kann ein Fehlerfall dazu führen, dass Zugangsdaten- oder Signaturmaterial über eine regulär erreichbare Status-API lesbar wird — verschärft durch SEC-01, solange die Status-API nicht ordentlich authentifiziert ist.
+
+**Technische Grundlage:** Go, Muster-/Regex-Filterung sicherheitsrelevanter Textstellen, `connect/internal/datevtransfer/datevtransfer.go`, `connect/internal/m365connector.go`, `connect/internal/backupconnector.go`
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Fehlerdiagnose bleibt möglich (Kurzfassung mit HTTP-Status, Fehlertyp, Zeitpunkt), aber ohne rohen Fremdsystem-Antwortkörper im gespeicherten Fehlerfeld.
+
+**Bewusst vermeiden:**
+- Rohe, ungefilterte Antwortkörper externer Systeme als Diagnosehilfe zu speichern — das aktuelle Verhalten ist genau dieses Anti-Muster.
+
+## Ausgangslage
+Setzt auf den bestehenden Fehlerbehandlungspfaden in `datevtransfer`, `m365connector` und `backupconnector` auf.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. An allen drei Fundstellen (`datevtransfer.go:676-682`, `m365connector.go:112`, `backupconnector.go:101,139`) wird der Fremdsystem-Antwortkörper vor dem Schreiben nach `last_error` auf sicherheitsrelevante Muster geprüft (u. a. AWS-Signaturdetails wie `StringToSign`/`AccessKeyID`/`Signature`, Authorization-Header-Inhalte, Tokens, Secrets) und diese Muster werden entfernt oder redigiert.
+2. Es wird nur eine diagnostisch relevante Kurzfassung persistiert (z. B. HTTP-Status, Fehlertyp, gekürzter/redigierter Textausschnitt), keine vollständige 1-MiB-Rohantwort mehr.
+3. Die Kurzfassung bleibt für die Fehlerdiagnose über die Status-API nachvollziehbar (Ursache und Zeitpunkt weiterhin erkennbar).
+
+## 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. Vor dem Fix: einen Fehlerfall gegen ein Test-Backup-Ziel simulieren, dessen Antwort eine AWS-artige Fehlermeldung mit `StringToSign`/`AccessKeyID` enthält, und nachweisen, dass diese Angaben aktuell unverändert in `last_error` landen und über die Status-API auslesbar sind.
+2. Nach dem Fix: denselben Testfall wiederholen und nachweisen, dass die sicherheitsrelevanten Angaben in der gespeicherten Kurzfassung nicht mehr enthalten sind.
+3. Regressionstest: ein normaler Fehlerfall ohne sicherheitsrelevante Inhalte liefert weiterhin eine für die Diagnose brauchbare Kurzfassung (Ursache, Zeitpunkt erkennbar).
+4. Test für alle drei Fundstellen einzeln durchführen (DATEV-Transfer, M365-Connector, Backup-Connector), nicht nur für eine.
+
+## Bekannte Fehler vermeiden
+
+Security-Review-Finding M16 (mittel, main-Branch, Fable 5.1): bis zu 1 MiB Fremdsystem-Antwortkörper ungefiltert in `last_error`, lesbar über `statusapi.go:102`. Fundstellen: `datevtransfer.go:676-682`, `m365connector.go:112`, `backupconnector.go:101,139`.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SEC-01` Authentifizierung der Connect-APIs
+
+## 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: fremdsystem-antwortkoerper-vor-speicherung-in-last-error-filtern`
+- Branch: `feature/sec-04-fremdsystem-antwortkoerper-vor-speicherung-in-last-error-filtern`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
diff --git a/connect-kanban/tickets/SEC-05.md b/connect-kanban/tickets/SEC-05.md
new file mode 100644
index 00000000..453a5ed8
--- /dev/null
+++ b/connect-kanban/tickets/SEC-05.md
@@ -0,0 +1,62 @@
+# SEC-05 – Tenant-Bindung der Connect-Store-Methoden (IDOR-Härtung)
+
+**Epic:** 🔒 Sicherheit  |  **Rolle:** Backend  |  **Komplexität:** Mittel  |  **Aufwand:** 2 Personentage  |  **Welle:** 8
+
+---
+
+## Rolle
+Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Connect (Connector-Engine & Grundgerüst, ERP/CRM-, DATEV-, Microsoft-365-Anbindung, Andere-DMS-Interoperabilität), das vollständig auf NEXARCH Core aufbaut (REST-Grundgerüst, Rate-Limiting, OpenAPI, Webhook-Zustellung, Token-Verwaltung, Audit) — keine eigene API-Infrastruktur.
+Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche.
+
+## Auftrag
+Security-Review (main-Branch, Fable 5.1) hat festgestellt: mehrere Store-Methoden filtern nur nach `id`, ohne den Mandanten in der WHERE-Klausel zu erzwingen: `connect/internal/syncjob/syncjob.go:109-122,191-269`, `connect/internal/datevtransfer/store.go:935-1001`, `connect/internal/erpexport/store.go:1424-1490`. Diese Methoden sind aktuell nicht über HTTP erreichbar, stellen aber ein latentes IDOR-Risiko dar: sobald eine künftige API-Route eine dieser Methoden direkt mit einer vom Aufrufer kommenden `id` aufruft, kann ein Mandant per erratener oder sequentieller ID auf die Sync-Job-, DATEV-Transfer- oder ERP-Export-Datensätze eines fremden Mandanten zugreifen.
+
+Lösung laut Review: den Tenant-Parameter in der Methodensignatur erzwingen (Compile-Zeit-Änderung, kein optionales Flag), sodass die WHERE-Klausel in jeder dieser Methoden um `AND tenant_slug=$2` ergänzt wird und ein Aufruf ohne Tenant-Parameter nicht mehr compiliert.
+
+**Technische Grundlage:** Go, pgx/v5, PostgreSQL, Signaturänderung der betroffenen Store-Methoden
+
+## Produkt-DNA für diesen Bereich
+**Übernehmen:**
+- Multi-Tenancy Modell A: jede datensatzbezogene Store-Methode erzwingt den Tenant-Filter über die Methodensignatur, nicht als optionalen, vergessbaren Parameter.
+
+**Bewusst vermeiden:**
+- Store-Methoden, die allein über `id` filtern und sich auf den Aufrufer verlassen, den richtigen Tenant korrekt mitzugeben — genau das aktuelle Muster.
+
+## Ausgangslage
+Setzt auf den bestehenden Store-Implementierungen von `syncjob`, `datevtransfer` und `erpexport` auf; ändert ausschließlich deren Methodensignaturen und WHERE-Klauseln, keine Fachlogik.
+
+## Akzeptanzkriterien
+Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
+1. Alle betroffenen Methoden (`syncjob.go:109-122,191-269`, `datevtransfer/store.go:935-1001`, `erpexport/store.go:1424-1490`) nehmen einen Tenant-Parameter (z. B. `tenantSlug string`) als zwingenden Bestandteil der Signatur entgegen.
+2. Die SQL-WHERE-Klausel jeder dieser Methoden ist um `AND tenant_slug=$2` (bzw. entsprechenden Parameter) ergänzt.
+3. Alle bestehenden Aufrufer dieser Methoden im Repository sind so angepasst, dass sie den jeweils korrekten, aus dem verifizierten Kontext stammenden Tenant übergeben; das Projekt compiliert fehlerfrei.
+4. Ein Zugriffsversuch mit `id` eines fremden Mandanten und dem eigenen Tenant-Parameter liefert kein Ergebnis (bzw. "nicht gefunden") statt der fremden Daten.
+
+## 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. Vor dem Fix: einen Testdatensatz für Mandant A anlegen, danach mit `id` dieses Datensatzes und Tenant-Kontext von Mandant B die jeweilige Store-Methode direkt aufrufen und nachweisen, dass der fremde Datensatz aktuell zurückgegeben wird.
+2. Nach dem Fix: denselben Aufruf wiederholen und nachweisen, dass kein Ergebnis mehr zurückkommt, wenn `id` und `tenant_slug` nicht zusammenpassen.
+3. Regressionstest: Aufruf mit korrektem, zueinander passendem `id` und `tenant_slug` liefert weiterhin den erwarteten Datensatz, für alle drei betroffenen Stores (`syncjob`, `datevtransfer`, `erpexport`).
+4. Build-Test: das Projekt compiliert nach der Signaturänderung fehlerfrei; kein verbliebener Aufrufer ruft eine der geänderten Methoden ohne Tenant-Parameter auf.
+
+## Bekannte Fehler vermeiden
+
+Security-Review-Finding M17 (mittel, main-Branch, Fable 5.1): tenant-ungebundene Store-Methoden mit `WHERE id=$1` ohne Tenant-Filter, latentes IDOR-Risiko. Fundstellen: `syncjob.go:109-122,191-269`, `datevtransfer/store.go:935-1001`, `erpexport/store.go:1424-1490`.
+
+## Nicht Bestandteil dieser Kachel
+Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
+- `SEC-01` Authentifizierung der Connect-APIs
+
+## 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-05: tenant-bindung-der-connect-store-methoden-idor-haertung`
+- Branch: `feature/sec-05-tenant-bindung-der-connect-store-methoden-idor-haertung`
+- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy.
+- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.
-- 
2.47.3