Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
  patrickandClaude Sonnet 5.5
|
2aa5fef328 |
No files matched your search
@@ -0,0 +1,40 @@
|
||||
:root {
|
||||
--bg: #0B0F17; --card: #131A26; --card2: #18212F; --border: #253044;
|
||||
--fg: #E6EDF7; --muted: #93A1B8; --primary: #3B82F6;
|
||||
}
|
||||
* { box-sizing: border-box; }
|
||||
body { margin: 0; background: var(--bg); color: var(--fg); font-family: ui-sans-serif, system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; }
|
||||
header { position: sticky; top: 0; z-index: 20; background: rgba(11,15,23,.92); backdrop-filter: blur(8px); border-bottom: 1px solid var(--border); padding: 14px 20px; }
|
||||
.row { display: flex; gap: 10px; align-items: center; flex-wrap: wrap; }
|
||||
h1 { font-size: 17px; margin: 0 14px 0 0; letter-spacing: -.01em; }
|
||||
.sub { color: var(--muted); font-size: 12px; }
|
||||
input, select, button { background: var(--card2); color: var(--fg); border: 1px solid var(--border); border-radius: 8px; padding: 7px 10px; font-size: 12px; font-family: inherit; }
|
||||
input:focus, select:focus { outline: 1px solid var(--primary); }
|
||||
button { cursor: pointer; }
|
||||
button:hover { border-color: var(--primary); }
|
||||
button.primary { background: rgba(59,130,246,.14); color: #93BBFB; border-color: rgba(59,130,246,.3); }
|
||||
.stats { display: flex; gap: 14px; font-size: 11px; color: var(--muted); margin-top: 8px; flex-wrap: wrap; }
|
||||
.stats b { color: var(--fg); }
|
||||
.board { display: grid; grid-template-columns: repeat(5, minmax(240px, 1fr)); gap: 12px; padding: 16px 20px 40px; align-items: start; overflow-x: auto; }
|
||||
.col { background: var(--card); border: 1px solid var(--border); border-radius: 12px; min-height: 160px; padding: 10px; }
|
||||
.col.over { border-color: var(--primary); background: #16203042; }
|
||||
.col h2 { font-size: 12px; margin: 2px 4px 10px; display: flex; justify-content: space-between; align-items: center; text-transform: uppercase; letter-spacing: .06em; color: var(--muted); }
|
||||
.count { background: var(--card2); border: 1px solid var(--border); border-radius: 999px; padding: 1px 7px; font-size: 10px; color: var(--fg); }
|
||||
.card { background: var(--card2); border: 1px solid var(--border); border-radius: 10px; padding: 10px; margin-bottom: 8px; cursor: grab; }
|
||||
.card:hover { border-color: #3a4a66; }
|
||||
.card.dragging { opacity: .45; }
|
||||
.card .code { font-family: ui-monospace, SFMono-Regular, Menlo, monospace; font-size: 10px; color: var(--muted); }
|
||||
.card .title { font-size: 13px; margin: 4px 0 7px; line-height: 1.35; }
|
||||
.tag { display: inline-block; font-size: 10px; padding: 2px 7px; border-radius: 999px; background: #202b3d; color: var(--muted); margin-right: 4px; margin-top: 3px; }
|
||||
.tag.blocked { background: rgba(245,158,11,.15); color: #FBBF24; }
|
||||
.tag.ready { background: rgba(34,197,94,.15); color: #4ADE80; }
|
||||
.tag.wave { background: rgba(59,130,246,.14); color: #93BBFB; }
|
||||
dialog { background: var(--card); color: var(--fg); border: 1px solid var(--border); border-radius: 14px; max-width: 860px; width: 94%; padding: 0; }
|
||||
dialog::backdrop { background: rgba(0,0,0,.72); }
|
||||
.dlg-head { padding: 18px 20px; border-bottom: 1px solid var(--border); display: flex; justify-content: space-between; gap: 12px; align-items: flex-start; }
|
||||
.dlg-body { padding: 18px 20px 24px; max-height: 66vh; overflow: auto; }
|
||||
pre { background: #0E1420; border: 1px solid var(--border); border-radius: 10px; padding: 14px; font-size: 11px; line-height: 1.6; white-space: pre-wrap; word-break: break-word; color: #C7D3E5; font-family: ui-monospace, SFMono-Regular, Menlo, monospace; }
|
||||
h3 { font-size: 12px; text-transform: uppercase; letter-spacing: .06em; color: var(--muted); margin: 18px 0 8px; }
|
||||
ul { margin: 0; padding-left: 18px; font-size: 13px; color: #C7D3E5; line-height: 1.6; }
|
||||
.chip { font-family: ui-monospace, Menlo, monospace; font-size: 11px; border: 1px solid var(--border); border-radius: 6px; padding: 2px 6px; margin: 0 4px 4px 0; display: inline-block; color: var(--muted); }
|
||||
.empty { color: #55627a; font-size: 11px; text-align: center; padding: 14px 0; }
|
||||
@@ -0,0 +1,152 @@
|
||||
(function () {
|
||||
var DATA = JSON.parse(document.getElementById('data').textContent);
|
||||
var COLUMNS = ['Backlog', 'Bereit', 'In Arbeit', 'Prüfung', 'Fertig'];
|
||||
var KEY = 'kanban-status-v1:' + location.pathname;
|
||||
var state = {};
|
||||
try { state = JSON.parse(localStorage.getItem(KEY) || '{}') || {}; } catch (e) { state = {}; }
|
||||
var onlyReady = false;
|
||||
|
||||
function statusOf(t) { return state[t.code] || t.status || 'Backlog'; }
|
||||
function isDone(code) { return statusOf(byCode[code] || { code: code }) === 'Fertig'; }
|
||||
var byCode = {};
|
||||
DATA.tickets.forEach(function (t) { byCode[t.code] = t; });
|
||||
|
||||
function ready(t) { return (t.dependsOn || []).every(function (d) { return isDone(d); }); }
|
||||
|
||||
function save() { localStorage.setItem(KEY, JSON.stringify(state)); }
|
||||
|
||||
// Filter befüllen
|
||||
var fEpic = document.getElementById('fEpic'), fRole = document.getElementById('fRole'), fWave = document.getElementById('fWave');
|
||||
DATA.epics.forEach(function (e) { var o = document.createElement('option'); o.value = e.key; o.textContent = e.emoji + ' ' + e.name; fEpic.appendChild(o); });
|
||||
Array.from(new Set(DATA.tickets.map(function (t) { return t.role; }))).sort().forEach(function (r) { var o = document.createElement('option'); o.value = r; o.textContent = r; fRole.appendChild(o); });
|
||||
var maxWave = Math.max.apply(null, DATA.tickets.map(function (t) { return t.wave; }));
|
||||
for (var w = 1; w <= maxWave; w++) { var o = document.createElement('option'); o.value = String(w); o.textContent = 'Welle ' + w; fWave.appendChild(o); }
|
||||
|
||||
function visible() {
|
||||
var q = document.getElementById('q').value.trim().toLowerCase();
|
||||
return DATA.tickets.filter(function (t) {
|
||||
if (fEpic.value && t.epic !== fEpic.value) return false;
|
||||
if (fRole.value && t.role !== fRole.value) return false;
|
||||
if (fWave.value && String(t.wave) !== fWave.value) return false;
|
||||
if (onlyReady && (!ready(t) || statusOf(t) === 'Fertig')) return false;
|
||||
if (q) {
|
||||
var hay = (t.code + ' ' + t.title + ' ' + t.tech + ' ' + t.description).toLowerCase();
|
||||
if (hay.indexOf(q) === -1) return false;
|
||||
}
|
||||
return true;
|
||||
});
|
||||
}
|
||||
|
||||
function render() {
|
||||
var board = document.getElementById('board');
|
||||
board.innerHTML = '';
|
||||
var list = visible();
|
||||
COLUMNS.forEach(function (col) {
|
||||
var el = document.createElement('div');
|
||||
el.className = 'col';
|
||||
el.dataset.col = col;
|
||||
var items = list.filter(function (t) { return statusOf(t) === col; });
|
||||
var h = document.createElement('h2');
|
||||
h.innerHTML = '<span>' + col + '</span><span class="count">' + items.length + '</span>';
|
||||
el.appendChild(h);
|
||||
if (!items.length) { var e = document.createElement('div'); e.className = 'empty'; e.textContent = '– leer –'; el.appendChild(e); }
|
||||
items.forEach(function (t) { el.appendChild(card(t)); });
|
||||
el.addEventListener('dragover', function (ev) { ev.preventDefault(); el.classList.add('over'); });
|
||||
el.addEventListener('dragleave', function () { el.classList.remove('over'); });
|
||||
el.addEventListener('drop', function (ev) {
|
||||
ev.preventDefault(); el.classList.remove('over');
|
||||
var code = ev.dataTransfer.getData('text/plain');
|
||||
if (!code) return;
|
||||
state[code] = col; save(); render();
|
||||
});
|
||||
board.appendChild(el);
|
||||
});
|
||||
stats(list);
|
||||
}
|
||||
|
||||
function card(t) {
|
||||
var d = document.createElement('div');
|
||||
d.className = 'card';
|
||||
d.draggable = true;
|
||||
var blocked = !ready(t);
|
||||
d.innerHTML = '<div class="code">' + t.code + ' · ' + t.estimateDays + ' PT</div>' +
|
||||
'<div class="title">' + esc(t.title) + '</div>' +
|
||||
'<span class="tag wave">Welle ' + t.wave + '</span>' +
|
||||
'<span class="tag">' + t.role + '</span>' +
|
||||
'<span class="tag">' + t.complexity + '</span>' +
|
||||
(blocked ? '<span class="tag blocked">wartet auf ' + t.dependsOn.filter(function (c) { return !isDone(c); }).join(', ') + '</span>' : '<span class="tag ready">startbar</span>');
|
||||
d.addEventListener('dragstart', function (ev) { ev.dataTransfer.setData('text/plain', t.code); d.classList.add('dragging'); });
|
||||
d.addEventListener('dragend', function () { d.classList.remove('dragging'); });
|
||||
d.addEventListener('click', function () { openDlg(t); });
|
||||
return d;
|
||||
}
|
||||
|
||||
function esc(s) { return String(s).replace(/[&<>]/g, function (c) { return { '&': '&', '<': '<', '>': '>' }[c]; }); }
|
||||
|
||||
function stats(list) {
|
||||
var done = DATA.tickets.filter(function (t) { return statusOf(t) === 'Fertig'; });
|
||||
var donePT = done.reduce(function (a, t) { return a + t.estimateDays; }, 0);
|
||||
var readyNow = DATA.tickets.filter(function (t) { return ready(t) && statusOf(t) !== 'Fertig'; }).length;
|
||||
document.getElementById('stats').innerHTML =
|
||||
'<span><b>' + DATA.tickets.length + '</b> Kacheln</span>' +
|
||||
'<span>sichtbar: <b>' + list.length + '</b></span>' +
|
||||
'<span>fertig: <b>' + done.length + '</b> (' + donePT + ' von ' + DATA.totalDays + ' PT)</span>' +
|
||||
'<span>jetzt startbar: <b>' + readyNow + '</b></span>' +
|
||||
'<span>Wellen: <b>' + maxWave + '</b></span>';
|
||||
}
|
||||
|
||||
var dlg = document.getElementById('dlg');
|
||||
var current = null;
|
||||
function openDlg(t) {
|
||||
current = t;
|
||||
document.getElementById('dCode').textContent = t.code + ' · ' + t.epicName;
|
||||
document.getElementById('dTitle').textContent = t.title;
|
||||
document.getElementById('dMeta').innerHTML =
|
||||
'<span class="tag wave">Welle ' + t.wave + '</span><span class="tag">' + t.role + '</span><span class="tag">' + t.complexity + '</span><span class="tag">' + t.estimateDays + ' PT</span><span class="tag">' + statusOf(t) + '</span>';
|
||||
document.getElementById('dDesc').textContent = t.description;
|
||||
chips('dDeps', t.dependsOn);
|
||||
chips('dNext', t.unlocks);
|
||||
items('dAcc', t.akzeptanz);
|
||||
items('dChk', t.pruefungen);
|
||||
document.getElementById('dPrompt').textContent = t.prompt;
|
||||
dlg.showModal();
|
||||
}
|
||||
function chips(id, arr) {
|
||||
var el = document.getElementById(id);
|
||||
el.innerHTML = (arr && arr.length) ? arr.map(function (c) { return '<span class="chip">' + c + (byCode[c] ? ' – ' + esc(byCode[c].title) : '') + '</span>'; }).join('') : '<span class="empty" style="padding:0">keine</span>';
|
||||
}
|
||||
function items(id, arr) {
|
||||
document.getElementById(id).innerHTML = (arr || []).map(function (a) { return '<li>' + esc(a) + '</li>'; }).join('');
|
||||
}
|
||||
document.getElementById('closeBtn').onclick = function () { dlg.close(); };
|
||||
document.getElementById('copyBtn').onclick = function () {
|
||||
if (!current) return;
|
||||
var btn = this;
|
||||
navigator.clipboard.writeText(current.prompt).then(function () {
|
||||
btn.textContent = 'Kopiert ✓';
|
||||
setTimeout(function () { btn.textContent = 'Prompt kopieren'; }, 1800);
|
||||
});
|
||||
};
|
||||
|
||||
document.getElementById('q').addEventListener('input', render);
|
||||
[fEpic, fRole, fWave].forEach(function (s) { s.addEventListener('change', render); });
|
||||
document.getElementById('onlyReady').onclick = function () {
|
||||
onlyReady = !onlyReady;
|
||||
this.style.borderColor = onlyReady ? 'var(--primary)' : 'var(--border)';
|
||||
this.textContent = onlyReady ? 'Filter: nur startbare' : 'Nur startbare';
|
||||
render();
|
||||
};
|
||||
document.getElementById('resetBtn').onclick = function () {
|
||||
if (confirm('Alle lokalen Statusänderungen verwerfen?')) { state = {}; save(); render(); }
|
||||
};
|
||||
document.getElementById('exportBtn').onclick = function () {
|
||||
var rows = [['Code', 'Titel', 'Status']].concat(DATA.tickets.map(function (t) { return [t.code, t.title, statusOf(t)]; }));
|
||||
var csv = rows.map(function (r) { return r.map(function (c) { return '"' + String(c).replace(/"/g, '""') + '"'; }).join(','); }).join('\n');
|
||||
var a = document.createElement('a');
|
||||
a.href = URL.createObjectURL(new Blob(['\ufeff' + csv], { type: 'text/csv;charset=utf-8' }));
|
||||
a.download = 'kanban-stand.csv';
|
||||
a.click();
|
||||
};
|
||||
|
||||
render();
|
||||
})();
|
||||
@@ -0,0 +1,101 @@
|
||||
# Migration-Kanban – lokal abarbeiten
|
||||
|
||||
34 Arbeitskacheln · 9 Epics · 87 Personentage · 13 Wellen.
|
||||
|
||||
Hinweis: Dieses Board leitet sich aus `MIGRATIONSKONZEPT.md` ab und ist die alleinige Quelle für die Big-Bang-Migration von archivmail und archivdms nach NEXARCH 2.0. Es referenziert alle sieben Zielmodule (Core, DMS, Mail, Archive, Workflow, AI, Connect) extern in der Ausgangslage betroffener Tickets, statt Zielfunktionalität zu duplizieren. Grundprinzip: Tenant-/User-Identitätsauflösung vor allem anderen, keine automatische Zusammenführung ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen werden nie zurückgesetzt.
|
||||
Stand: 2026-08-28
|
||||
|
||||
## 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 (`MAP-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** (1 Kacheln): MAP-01
|
||||
- **Welle 2** (1 Kacheln): MAP-02
|
||||
- **Welle 3** (2 Kacheln): MAP-03, COR-01
|
||||
- **Welle 4** (4 Kacheln): MAP-04, COR-05, DOK-01, MAI-01
|
||||
- **Welle 5** (6 Kacheln): COR-02, DOK-02, DOK-04, DOK-05, MAI-02, VAL-04
|
||||
- **Welle 6** (9 Kacheln): COR-03, COR-04, MAI-03, MAI-04, TAR-01, WFL-01, VAL-01, VAL-02, VAL-05
|
||||
- **Welle 7** (3 Kacheln): DOK-03, TAR-02, VAL-03
|
||||
- **Welle 8** (1 Kacheln): CUT-01
|
||||
- **Welle 9** (1 Kacheln): CUT-02
|
||||
- **Welle 10** (2 Kacheln): CUT-03, ROL-01
|
||||
- **Welle 11** (2 Kacheln): CUT-04, ROL-02
|
||||
- **Welle 12** (1 Kacheln): CUT-05
|
||||
- **Welle 13** (1 Kacheln): CUT-06
|
||||
|
||||
Kritischer Pfad (40 PT): MAP-01 → MAP-02 → COR-01 → MAI-01 → MAI-02 → TAR-01 → TAR-02 → CUT-01 → CUT-02 → CUT-03 → CUT-04 → CUT-05 → CUT-06
|
||||
|
||||
Hinweis zum zeitlichen Charakter: Anders als die Modul-Boards ist dieses Board ein **einmaliges Projekt** mit echtem Kalenderbezug (Stichtag), keine Dauerentwicklung. Die späten Wellen (Trockenläufe, Stichtag, Parallelbetrieb) laufen nicht beliebig parallel zu anderen Boards, sondern erst wenn die Zielmodule (Core, DMS, Mail, Archive, Workflow) so weit fertig sind, dass eine Migration überhaupt sinnvoll ist.
|
||||
|
||||
## Produkt-DNA
|
||||
|
||||
### Übernehmen
|
||||
- **Allgemeine Migrationspraxis**: Zwei Trockenläufe vor dem echten Stichtag statt direktem Sprung auf Produktivdaten.
|
||||
- **GoBD-Praxis**: Aufbewahrungsfristen werden nie neu berechnet, nur exakt übernommen.
|
||||
|
||||
### Vermeiden
|
||||
- **Automatischer Merge ohne Freigabe – Risiko der Datenvermischung zweier Kunden.**: Pflicht-Freigabe durch einen Menschen für jede Tenant-/User-Zusammenführung.
|
||||
|
||||
## 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).
|
||||
|
||||
Besonderheit dieses Boards: Migrationsskripte sind Einwegwerkzeuge für den Stichtag, keine Dauersoftware – trotzdem gelten dieselben Qualitätsanforderungen (Tests, Wiederholbarkeit/Idempotenz, keine Secrets im Code), weil ein Fehler hier GoBD-relevante Daten unwiederbringlich beschädigen kann.
|
||||
@@ -0,0 +1,131 @@
|
||||
Code,Titel,Epic,Rolle,Komplexitaet,Aufwand_PT,Welle,Status,Technik,Beschreibung,Haengt_ab_von,Schaltet_frei,Akzeptanzkriterien,Pruefungen
|
||||
MAP-01,Tenant-Export & Slug/Domain-Abgleich,🔗 Tenant- & User-Mapping,Backend,Mittel,3,1,Backlog,"SQL-Export beider tenants-Tabellen, Slug/Domain-Matching-Skript","Export der tenants-Tabellen aus archivmail und archivdms (slug, name, Domain) und automatischer Abgleichsvorschlag per Slug-/Domain-Matching, ergänzt um eine manuell gepflegte Kunden-Zuordnungsliste als Fallback-Quelle.",,MAP-02,"- Beide tenants-Tabellen vollständig exportiert, inkl. slug/name/Domain
|
||||
- Automatischer Abgleichsvorschlag erzeugt Kandidatenliste mit Konfidenzwert
|
||||
- Manuelle Zuordnungsliste kann Konflikte des automatischen Abgleichs übersteuern","1. Export-Vollständigkeit gegen Quelltabellen-Zeilenzahl geprüft
|
||||
2. Stichprobe von 10 bekannten Duplikat-Tenants korrekt vorgeschlagen
|
||||
3. Konflikt zwischen automatischem Vorschlag und manueller Liste wird sichtbar markiert, nicht stillschweigend aufgelöst"
|
||||
MAP-02,Tenant-Migration-Map & Freigabe-Workflow,🔗 Tenant- & User-Mapping,Backend,Mittel,3,2,Backlog,"Freigabe-Oberfläche, tenant_migration_map-Tabelle","Referenztabelle tenant_migration_map (archivmail_tenant_id, archivdms_tenant_id, nexarch_tenant_id) mit Pflicht-Freigabe durch einen Menschen je Zusammenführung, bevor sie für nachgelagerte Migrationsschritte nutzbar wird.",MAP-01,MAP-03 COR-01,"- Jede Zusammenführung erfordert eine explizite, protokollierte menschliche Freigabe
|
||||
- Ohne Freigabe bleibt ein Tenant als unbestätigt markiert und wird von nachgelagerten Schritten nicht verarbeitet
|
||||
- Freigegebene Map ist die einzige Quelle, die andere Migrationsschritte für tenant_id-Umschreibung verwenden","1. Zusammenführung ohne Freigabe wird von einem Testlauf nachweislich zurückgewiesen
|
||||
2. Freigabe-Protokoll enthält Zeitpunkt und freigebende Person
|
||||
3. Nachträgliche Korrektur einer bereits freigegebenen Zuordnung ist möglich und wird protokolliert"
|
||||
MAP-03,User-Export & E-Mail-Abgleich innerhalb Tenant,🔗 Tenant- & User-Mapping,Backend,Mittel,2,3,Backlog,"SQL-Export users-Tabellen, E-Mail-Abgleichsskript je Tenant","Export der users-Tabellen aus beiden Altsystemen und Abgleich per E-Mail-Adresse innerhalb desselben bereits zusammengeführten Tenants – ein Mensch kann in beiden Systemen mit derselben E-Mail, aber unterschiedlicher user_id existieren.",MAP-02,MAP-04,"- Beide users-Tabellen vollständig exportiert
|
||||
- Abgleich erfolgt ausschließlich innerhalb eines bereits freigegebenen Tenants, nicht global
|
||||
- E-Mail-Duplikate über Tenant-Grenzen hinweg werden nicht automatisch zusammengeführt","1. Export-Vollständigkeit gegen Quelltabellen-Zeilenzahl geprüft
|
||||
2. Stichprobe bekannter Doppel-Accounts korrekt erkannt
|
||||
3. Zwei unterschiedliche Tenants mit identischer E-Mail-Adresse bleiben getrennt"
|
||||
MAP-04,User-Migration-Map & Freigabe-Workflow,🔗 Tenant- & User-Mapping,Backend,Mittel,2,4,Backlog,"Freigabe-Oberfläche, user_migration_map-Tabelle","Referenztabelle user_migration_map (archivmail_user_id, archivdms_user_id, nexarch_user_id) mit derselben Pflicht-Freigabe wie bei Tenants, bevor sie für die Core-Benutzer-Migration nutzbar wird.",MAP-03,COR-02 CUT-03,"- Jede Benutzer-Zusammenführung erfordert eine explizite, protokollierte menschliche Freigabe
|
||||
- Ohne Freigabe bleibt ein Benutzer als zwei getrennte Konten migrierbar, statt fälschlich zusammengeführt zu werden
|
||||
- Freigegebene Map ist die einzige Quelle für die Core-Benutzer-Migration (COR-02)","1. Zusammenführung ohne Freigabe wird von einem Testlauf nachweislich zurückgewiesen
|
||||
2. Freigabe-Protokoll enthält Zeitpunkt und freigebende Person
|
||||
3. Stichprobe von 10 freigegebenen Zuordnungen gegen Quelle geprüft"
|
||||
COR-01,Tenant-Datenmodell-Migration,🏛️ Core-Migration,Backend,Mittel,3,3,Backlog,SQL-Migration gegen Core TEN-01 unter Nutzung der Tenant-Map,"Übernahme der zusammengeführten Tenant-Datensätze in Core TEN-01, tenant_id konsequent über die freigegebene Tenant-Map umgeschrieben.",MAP-02,COR-02 COR-05 DOK-01 MAI-01,"- Jeder freigegebene Tenant existiert nach der Migration genau einmal in Core
|
||||
- Keine Tenant-Daten ohne Eintrag in der freigegebenen Tenant-Map werden übernommen
|
||||
- Migration ist wiederholbar (idempotent) gegen dieselbe Quelle","1. Zeilenzahl migrierter Tenants entspricht Anzahl freigegebener Map-Einträge
|
||||
2. Erneuter Lauf gegen bereits migrierte Daten erzeugt keine Duplikate
|
||||
3. Stichprobe von 5 Tenants auf korrekt umgeschriebene tenant_id geprüft"
|
||||
COR-02,Benutzer-Migration inkl. Passwort-Hashes,🏛️ Core-Migration,Backend,Mittel,3,5,Backlog,"SQL-Migration gegen Core IAM-01, bcrypt-Hash-Übernahme ohne Rehash","Übernahme der zusammengeführten Benutzerdatensätze in Core IAM-01 unter Nutzung der User-Map; bcrypt-Passwort-Hashes werden 1:1 übernommen, kein Rehash nötig, da dasselbe Hash-Verfahren in beiden Altsystemen verwendet wird.",MAP-04 COR-01,COR-03 COR-04 WFL-01 VAL-01 VAL-05,"- Jeder freigegebene Benutzer existiert nach der Migration genau einmal in Core
|
||||
- Migrierte Passwort-Hashes funktionieren unverändert beim ersten Login nach der Migration
|
||||
- Benutzer ohne Eintrag in der freigegebenen User-Map werden nicht automatisch zusammengeführt","1. Login-Test mit 5 migrierten Testkonten gegen migrierte Hashes erfolgreich
|
||||
2. Zeilenzahl migrierter Benutzer entspricht Anzahl freigegebener Map-Einträge
|
||||
3. Erneuter Lauf gegen bereits migrierte Daten erzeugt keine Duplikate"
|
||||
COR-03,Rollen- & Rechte-Migration,🏛️ Core-Migration,Backend,Mittel,3,6,Backlog,SQL-Migration gegen Core RBAC-01/RBAC-03,"archivdms besitzt das reifere Rechtemodell (permission_groups, *_grants) und dient als Zielvorlage; archivmail-Textrollen werden auf die passende Core-Rolle gemappt, nicht 1:1 als Freitext übernommen.",COR-02,DOK-03 CUT-01,"- Jede archivdms-Berechtigungsgruppe hat eine eindeutige Core-RBAC-Entsprechung
|
||||
- Jede archivmail-Textrolle ist auf genau eine Core-Rolle gemappt, dokumentiert in einer Mapping-Tabelle
|
||||
- Kein Benutzer verliert oder gewinnt Rechte gegenüber dem Altsystem ohne dokumentierte Begründung","1. Stichprobe von 10 Benutzern: Rechte vor/nach Migration verglichen und Abweichungen dokumentiert
|
||||
2. Rollen-Mapping-Tabelle vollständig, keine unzugeordnete archivmail-Rolle offen
|
||||
3. Zugriffstest mit migriertem Konto bestätigt erwartete Berechtigung"
|
||||
COR-04,LDAP-Feld-Migration,🏛️ Core-Migration,Backend,Einfach,2,6,Backlog,SQL-Migration gegen Core IAM-05,"Übernahme der LDAP-Kopplungsfelder mit archivdms-Feldtiefe (ldap_uid, ldap_synced_at) als Zielschema; archivmail-Konten mit einfacherem source-Feld werden nachträglich angereichert, fehlende Felder bleiben leer bis zur nächsten Synchronisation.",COR-02,CUT-01,"- archivdms-LDAP-Felder vollständig 1:1 übernommen
|
||||
- archivmail-Konten mit LDAP-Bezug sind als solche erkennbar, auch mit unvollständigen Feldern
|
||||
- Fehlende Felder blockieren die Migration des Kontos nicht","1. Stichprobe von 5 LDAP-gebundenen Konten je Altsystem korrekt migriert
|
||||
2. Nächster LDAP-Sync-Lauf ergänzt fehlende Felder ohne Fehler"
|
||||
COR-05,Audit-Log-Zusammenführung,🏛️ Core-Migration,Backend,Mittel,3,4,Backlog,"SQL-Migration gegen Core AUD-01/AUD-02, mechanisches Zusammenführen ohne inhaltliche Änderung","Zusammenführen der audit_log-Tabellen beider Altsysteme in Core; beide nutzen dasselbe Append-only-Trigger-Muster, daher rein mechanisch – historische Einträge behalten ihren originalen Zeitstempel, nur tenant_id/user_id werden über die Mapping-Tabellen umgeschrieben.",COR-01,VAL-04,"- Jeder historische Audit-Eintrag existiert nach der Migration mit unverändertem Zeitstempel und Inhalt
|
||||
- Nur tenant_id/user_id sind über die Mapping-Tabellen umgeschrieben, kein anderes Feld verändert
|
||||
- Append-only-Eigenschaft bleibt nach der Migration erhalten, auch für migrierte Einträge","1. Stichprobe von 20 historischen Einträgen: Inhalt und Zeitstempel exakt mit Quelle verglichen
|
||||
2. Versuch, einen migrierten Eintrag nachträglich zu ändern, wird vom Append-only-Mechanismus abgewiesen
|
||||
3. Ältester und neuester Eintrag je Tenant nach Migration mit Quelle abgeglichen"
|
||||
DOK-01,Dokument- & Revisions-Migration,📁 DMS-Migration,Backend,Hoch,5,4,Backlog,"Objekt-Storage-Kopie für Binärdaten, SQL-Export/Import für Metadaten","Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.",COR-01,DOK-02 DOK-03 DOK-04 DOK-05 TAR-01 WFL-01 VAL-01 VAL-02,"- Jedes Dokument samt aller Revisionen ist nach der Migration vollständig referenzierbar
|
||||
- Binärdaten und Metadaten sind nach der Migration konsistent miteinander verknüpft
|
||||
- Migration ist wiederholbar (idempotent) gegen dieselbe Quelle","1. Stichprobenweiser Hash-Vergleich migrierter Binärdateien gegen Quelle (siehe auch VAL-02)
|
||||
2. Zeilenzahl migrierter Dokumente/Revisionen entspricht Quelle abzüglich bewusst nicht migrierter Kategorien
|
||||
3. Öffnen und Herunterladen einer Stichprobe migrierter Dokumente über NEXARCH erfolgreich"
|
||||
DOK-02,Akten-/Ordnerstruktur-Migration,📁 DMS-Migration,Backend,Einfach,2,5,Backlog,SQL-Migration gegen DMS DOC-09,Übernahme der akten-Tabelle (Ordner-/Aktenstruktur) aus archivdms – strukturell 1:1 auf DMS DOC-09 übertragbar.,DOK-01,CUT-01,"- Jede Akte/jeder Ordner ist nach der Migration mit derselben Hierarchie wie im Altsystem vorhanden
|
||||
- Jedes migrierte Dokument ist der korrekten Akte zugeordnet","1. Stichprobe von 10 Aktenpfaden vor/nach Migration verglichen
|
||||
2. Anzahl Ordner/Akten je Tenant deckungsgleich mit Quelle"
|
||||
DOK-03,ACL-Daten-Migration nach Core-Rechtemodell,📁 DMS-Migration,Backend,Mittel,3,7,Backlog,SQL-Migration gegen Core RBAC-02/RBAC-04,"document_visibility, permission_groups und *_grants aus archivdms wandern inhaltlich in das Core-Rechtemodell, nicht in eine DMS-eigene Struktur – DMS-Tickets referenzieren dafür ausschließlich Core RBAC-02/RBAC-04.",COR-03 DOK-01,CUT-01,"- Jede dokumentbezogene Sichtbarkeitsregel ist nach der Migration im Core-Rechtemodell abgebildet
|
||||
- Kein Dokument ist nach der Migration sichtbarer oder unsichtbarer als im Altsystem ohne dokumentierte Begründung","1. Stichprobe von 10 Dokumenten: Sichtbarkeit vor/nach Migration je betroffenem Benutzer verglichen
|
||||
2. Zugriffstest bestätigt erwartete Sichtbarkeit für migrierte Testkonten"
|
||||
DOK-04,Custom-Fields- & Klassifikationsvorlagen-Migration,📁 DMS-Migration,Backend,Einfach,2,5,Backlog,SQL-Migration gegen DMS MET-02/MET-04,1:1-Übernahme benutzerdefinierter Felder und Klassifikationsvorlagen aus archivdms.,DOK-01,CUT-01,"- Jedes Custom Field und jede Klassifikationsvorlage ist nach der Migration mit identischer Definition vorhanden
|
||||
- Bereits befüllte Feldwerte an migrierten Dokumenten bleiben erhalten","1. Stichprobe von 5 Vorlagen vor/nach Migration verglichen
|
||||
2. Feldwerte einer Stichprobe migrierter Dokumente gegen Quelle geprüft"
|
||||
DOK-05,Freigabelinks-Migration,📁 DMS-Migration,Backend,Einfach,2,5,Backlog,"SQL-Migration gegen DMS DOC-07, Ablauf-Filter","Übernahme aktiver, nicht abgelaufener document_shares (Freigabelinks); bereits abgelaufene Links werden verworfen statt migriert.",DOK-01,CUT-01,"- Nur Freigabelinks mit Ablaufdatum in der Zukunft werden migriert
|
||||
- Migrierte Links funktionieren unverändert mit derselben URL/demselben Token","1. Stichprobe aktiver Links nach Migration erfolgreich aufgerufen
|
||||
2. Abgelaufener Testlink ist nachweislich nicht migriert worden"
|
||||
MAI-01,Postfach-Konfiguration neu anlegen,📧 Mail-Migration,Backend,Mittel,3,4,Backlog,Neuanlage IMAP/POP3/SMTP-Konfiguration ohne Zugangsdaten-Kopie,"Postfach-Konfigurationen aus archivmail werden als Struktur (Server, Ordner, Zuordnung) übernommen, Zugangsdaten jedoch NICHT kopiert – jede Verbindung wird nach der Migration neu angelegt und neu getestet.",COR-01,MAI-02,"- Jede aktive Postfach-Konfiguration ist nach der Migration in Mail IMP-07 strukturell vorhanden
|
||||
- Keine Zugangsdaten sind aus dem Altsystem kopiert worden
|
||||
- Jede neu angelegte Verbindung wird vor Abschluss erfolgreich getestet","1. Verbindungstest für jede migrierte Postfach-Konfiguration erfolgreich
|
||||
2. Stichprobenkontrolle bestätigt: keine Zugangsdaten-Felder in der Migrationsdatenbank befüllt"
|
||||
MAI-02,Nachrichten- & Anhang-Migration,📧 Mail-Migration,Backend,Hoch,5,5,Backlog,"Objekt-Storage-Kopie für Binärdaten, SQL-Export/Import für Referenzen","Übernahme aller Nachrichten und Anhänge (email_refs) aus archivmail nach Mail ARC-01/ARC-04: Binärdaten per Objekt-Storage-Kopie, Referenzen per SQL-Export/Import; das indexed_at-Statusfeld wird verworfen, da der Suchindex komplett neu aufgebaut wird (siehe CUT-05).",MAI-01,MAI-03 MAI-04 TAR-01 VAL-01 VAL-02,"- Jede Nachricht samt Anhängen ist nach der Migration vollständig referenzierbar
|
||||
- Binärdaten und Metadaten sind nach der Migration konsistent miteinander verknüpft
|
||||
- indexed_at-Feld wird nicht übernommen","1. Stichprobenweiser Hash-Vergleich migrierter Anhänge gegen Quelle (siehe auch VAL-02)
|
||||
2. Zeilenzahl migrierter Nachrichten je Tenant deckungsgleich mit Quelle
|
||||
3. Öffnen einer Stichprobe migrierter Nachrichten samt Anhang über NEXARCH erfolgreich"
|
||||
MAI-03,DSGVO-Löschanfragen-Migration,📧 Mail-Migration,Backend,Einfach,2,6,Backlog,SQL-Migration gegen Archive CMP-02,"Offene, unbearbeitete DSGVO-Löschanfragen aus archivmail werden nach Archive CMP-02 migriert; bereits abgeschlossene Anfragen werden nur als historischer Audit-Eintrag übernommen, nicht als aktiver Vorgang.",MAI-02,CUT-01,"- Jede offene Löschanfrage ist nach der Migration als aktiver Vorgang in Archive vorhanden
|
||||
- Jede abgeschlossene Löschanfrage ist als historischer Audit-Eintrag nachvollziehbar, nicht als aktiver Vorgang","1. Zeilenzahl offener Anfragen nach Migration deckungsgleich mit Quelle
|
||||
2. Stichprobe abgeschlossener Anfragen als Audit-Eintrag auffindbar"
|
||||
MAI-04,Reconciliation-Reports-Archivierung,📧 Mail-Migration,Backend,Einfach,1,6,Backlog,SQL-Export gegen Archive BAK-05,"Historische Reconciliation-Reports aus archivmail werden als Nachweis nach Archive BAK-05 archiviert – kein aktiver Datenbestand, rein historischer Beleg.",MAI-02,CUT-01,- Jeder historische Report ist nach der Migration auffindbar und dem korrekten Tenant zugeordnet,1. Stichprobe von 5 Reports vor/nach Migration inhaltlich verglichen
|
||||
TAR-01,Retention-Fristen-Migration ohne Reset,⏳ Archive-Migration,Backend,Hoch,4,6,Backlog,"SQL-Migration gegen Archive RET-01, exakte 1:1-Übernahme von retain_until",Das retain_until-Feld auf Kernobjekten aus beiden Altsystemen wird exakt 1:1 in das generische Retention-Objektmodell (Archive RET-01) übernommen – Fristen dürfen beim Umzug unter keinen Umständen zurückgesetzt oder neu berechnet werden.,DOK-01 MAI-02,TAR-02 VAL-03,"- Jedes Objekt mit retain_until in der Quelle hat nach der Migration exakt dieselbe Frist
|
||||
- Kein Objekt erhält durch die Migration eine neue, vom Migrationsdatum abhängige Frist
|
||||
- Objekte ohne Frist in der Quelle bleiben nach der Migration ohne Frist","1. Stichprobe von 50 Objekten mit Frist in der Zukunft: Frist vor/nach Migration exakt identisch (siehe auch VAL-03)
|
||||
2. Migrationsskript enthält keine Berechnung, die das aktuelle Datum als Ausgangspunkt nutzt"
|
||||
TAR-02,Vier-Augen-Löschworkflow-Migration,⏳ Archive-Migration,Backend,Mittel,2,7,Backlog,SQL-Migration gegen Archive CMP-06,"Offene Löschanfragen aus document_delete_requests (nur archivdms) werden nach Archive CMP-06 migriert; bereits vollzogene Löschungen bleiben nur als Audit-Eintrag bestehen, da das Objekt selbst nicht mehr existiert.",TAR-01,CUT-01,"- Jede offene Löschanfrage ist nach der Migration als aktiver Vorgang im Vier-Augen-Workflow vorhanden
|
||||
- Bereits vollzogene Löschungen sind ausschließlich als Audit-Eintrag nachvollziehbar","1. Zeilenzahl offener Löschanfragen nach Migration deckungsgleich mit Quelle
|
||||
2. Stichprobe vollzogener Löschungen als Audit-Eintrag auffindbar, kein Objekt-Datensatz vorhanden"
|
||||
WFL-01,Workflow-Historie-Migration,🔀 Workflow-Migration,Backend,Mittel,3,6,Backlog,"SQL-Migration gegen Workflow ENG-01/RTE-01, nur abgeschlossene Vorgänge",Abgeschlossene Workflows/Automatisierungen aus archivdms werden als Historie nach Workflow ENG-01/RTE-01 übernommen; laufende Workflow-Instanzen werden NICHT migriert – sie müssen vor dem Stichtag im Altsystem bewusst zu Ende geführt oder abgebrochen werden.,COR-02 DOK-01,CUT-01,"- Jeder abgeschlossene Workflow-Vorgang ist nach der Migration als Historieneintrag auffindbar
|
||||
- Keine laufende Workflow-Instanz wird in einem halb migrierten Zustand übernommen
|
||||
- Liste offener Instanzen zum Stichtag ist vor dem Cutover vollständig abgearbeitet oder bewusst abgebrochen","1. Zeilenzahl abgeschlossener Vorgänge nach Migration deckungsgleich mit Quelle
|
||||
2. Zum geplanten Stichtag-Zeitpunkt sind keine offenen Instanzen in der Processing-Queue des Altsystems mehr vorhanden"
|
||||
VAL-01,Zeilenzahl-Abgleich je Kerntabelle,🔍 Verifikation,QA,Mittel,2,6,Backlog,Automatisiertes Zählskript je Tenant und Kerntabelle,"Automatisierter Abgleich der Zeilenzahl je migrierter Kerntabelle (Dokumente, Mails, Benutzer) alt vs. neu, je Tenant, abzüglich bewusst nicht migrierter Kategorien.",COR-02 DOK-01 MAI-02,CUT-02,"- Für jeden Tenant liegt ein Zeilenzahl-Bericht je Kerntabelle vor
|
||||
- Abweichungen sind entweder erklärt (bewusst nicht migrierte Kategorie) oder als offener Befund markiert","1. Bericht für mindestens 3 Test-Tenants erfolgreich erzeugt
|
||||
2. Absichtlich eingefügte Testabweichung wird vom Skript erkannt"
|
||||
VAL-02,Hash-Vergleich migrierter Binärdateien,🔍 Verifikation,QA,Mittel,2,6,Backlog,Stichprobenweiser Hash-Vergleich Objekt-Storage vs. Quelle,"Stichprobenweiser Hash-Vergleich migrierter Binärdateien (Dokumente, Mail-Anhänge) im Objekt-Storage gegen die Quelle, um bitgenaue Übernahme nachzuweisen.",DOK-01 MAI-02,CUT-02,"- Für eine repräsentative Stichprobe je Tenant liegt ein Hash-Vergleichsbericht vor
|
||||
- Jede Abweichung ist nachvollziehbar dokumentiert und vor Freischaltung geklärt","1. Stichprobe von 100 Dateien je Tenant erfolgreich verglichen
|
||||
2. Absichtlich manipulierte Testdatei wird vom Vergleich erkannt"
|
||||
VAL-03,Retention-Fristen-Verifikation,🔍 Verifikation,QA,Einfach,2,7,Backlog,Stichprobenvergleich retain_until alt vs. neu,"Für eine Stichprobe von Objekten mit retain_until in der Zukunft wird geprüft, dass die Frist nach der Migration exakt identisch mit der Quelle ist.",TAR-01,CUT-02,"- Für jeden Tenant liegt ein Prüfbericht über eine repräsentative Fristen-Stichprobe vor
|
||||
- Jede Abweichung führt automatisch zu einem blockierenden Befund, nicht nur einer Notiz","1. Stichprobe von 50 Objekten je Tenant erfolgreich verglichen
|
||||
2. Absichtlich verschobene Testfrist wird vom Vergleich erkannt"
|
||||
VAL-04,Audit-Log-Kontinuitätsprüfung,🔍 Verifikation,QA,Einfach,2,5,Backlog,"Ältester/neuester Eintrag je Tenant, Lücken-/Zeitverschiebungs-Check","Prüfung, dass ältester und neuester Audit-Log-Eintrag je Tenant nach der Migration mit der Quelle übereinstimmen – keine Lücke, keine Zeitverschiebung.",COR-05,CUT-02,"- Für jeden Tenant liegt ein Kontinuitätsbericht vor
|
||||
- Jede erkannte Lücke oder Zeitverschiebung ist ein blockierender Befund","1. Ältester/neuester Eintrag für 3 Test-Tenants exakt mit Quelle abgeglichen
|
||||
2. Absichtlich entfernter Testeintrag wird als Lücke erkannt"
|
||||
VAL-05,Login-Test mit migrierten Zugangsdaten,🔍 Verifikation,QA,Einfach,1,6,Backlog,Stichprobenweiser Login-Test gegen migrierte Passwort-Hashes,"Login-Test mit migrierten Zugangsdaten für eine Stichprobe von Benutzern je Tenant, um die praktische Funktionsfähigkeit der Benutzer-Migration zu bestätigen.",COR-02,CUT-02,"- Für jeden Tenant ist mindestens ein erfolgreicher Login-Test mit migriertem Konto dokumentiert
|
||||
- Fehlgeschlagene Logins sind vor Freischaltung des Tenants geklärt","1. Login-Test für 5 Testkonten je Altsystem erfolgreich
|
||||
2. Bewusst falsches Testpasswort wird korrekt abgewiesen"
|
||||
CUT-01,Trockenlauf 1 – Entwicklung,🚀 Cutover-Ablauf,Backend,Hoch,4,8,Backlog,"Migrationsskripte gegen anonymisierte Kopie der Produktivdaten, iterativ","Iterativer Testlauf aller Migrationsskripte gegen eine anonymisierte Kopie der Produktivdaten während der Entwicklung – Fehler werden hier gefunden, nicht erst bei der Generalprobe.",COR-03 COR-04 DOK-02 DOK-03 DOK-04 DOK-05 MAI-03 MAI-04 TAR-02 WFL-01,CUT-02,"- Alle Migrationsskripte laufen mindestens einmal vollständig durch, ohne Abbruch
|
||||
- Gefundene Fehler sind vor Übergang zu Trockenlauf 2 behoben
|
||||
- Anonymisierung der Testkopie ist nachweislich wirksam (keine echten Personendaten im Testlauf)","1. Vollständiger Lauf gegen anonymisierte Kopie protokolliert
|
||||
2. Mindestens zwei Iterationen mit dokumentierten Korrekturen durchgeführt"
|
||||
CUT-02,Trockenlauf 2 – Generalprobe,🚀 Cutover-Ablauf,Backend,Hoch,4,9,Backlog,Vollständiger Lauf gegen reale Produktivkopie in isolierter Testumgebung,"Vollständiger Migrationslauf gegen eine reale, aktuelle Kopie beider Produktivdatenbanken in einer isolierten NEXARCH-Testumgebung; Ergebnis wird stichprobenartig gegen die Quelle geprüft (Dokument-/Mail-Anzahl je Tenant, Volltextvergleich, Retention-Fristen-Abgleich).",CUT-01 VAL-01 VAL-02 VAL-03 VAL-04 VAL-05,CUT-03 ROL-01 ROL-02,"- Vollständiger Lauf gegen reale Produktivkopie ohne manuellen Eingriff durchgeführt
|
||||
- Alle Verifikationen aus VAL-01 bis VAL-05 sind für die Generalprobe erfolgreich durchgeführt
|
||||
- Isolierte Testumgebung hat keine Verbindung zu echten Produktivsystemen","1. Generalprobe-Protokoll mit Zeitstempel, Dauer und Ergebnis je Verifikationsschritt abgelegt
|
||||
2. Mindestens ein bewusst eingebauter Testfehler wird von der Verifikation erkannt"
|
||||
CUT-03,Tenant- und User-Mapping final freigeben,🚀 Cutover-Ablauf,Backend,Einfach,1,10,Backlog,Formaler Freigabe-Meilenstein vor dem Stichtag,"Finale, schriftlich festgehaltene Freigabe der Tenant- und User-Migration-Map – spätestens hier, nicht erst am Stichtag selbst.",MAP-04 CUT-02,CUT-04,"- Finale Freigabe ist schriftlich dokumentiert mit Zeitpunkt und freigebender Person
|
||||
- Nach dieser Freigabe werden keine weiteren Änderungen an der Map ohne erneuten Freigabeprozess vorgenommen","1. Freigabedokument liegt vor und ist auffindbar
|
||||
2. Stichprobe bestätigt: Map entspricht dem Stand der Generalprobe (CUT-02)"
|
||||
CUT-04,Stichtag-Durchführung,🚀 Cutover-Ablauf,Backend,Hoch,3,11,Backlog,"Wartungsmodus, finaler Export, Migrationslauf, Verifikation, Freischaltung","Durchführung des eigentlichen Stichtags: Altsysteme in Wartungsmodus (read-only) versetzen, finalen Datenexport ziehen, Migrationsskripte laufen lassen, Verifikation (VAL-01 bis VAL-05) je Tenant durchführen, NEXARCH freischalten.",CUT-03,CUT-05 CUT-06,"- Altsysteme sind für die Dauer der Migration nachweislich im Wartungsmodus
|
||||
- Jeder Tenant wird erst nach erfolgreicher Verifikation freigeschaltet, kein Tenant pauschal
|
||||
- Ablauf ist von Beginn bis Freischaltung lückenlos protokolliert","1. Wartungsmodus-Aktivierung für beide Altsysteme bestätigt
|
||||
2. Verifikationsergebnis je Tenant vor Freischaltung dokumentiert
|
||||
3. Freischaltungszeitpunkt je Tenant protokolliert"
|
||||
CUT-05,Suchindex-Neuaufbau nach Migration,🚀 Cutover-Ablauf,Backend,Mittel,3,12,Backlog,"Vollständige Reindexierung aus migrierten Metadaten, kein Kopieren des alten Manticore-Index","Nach erfolgreicher Migration wird der komplette Suchindex aus den migrierten Metadaten neu aufgebaut – es existiert kein DB-Sync-Table in beiden Altsystemen, der eine Übernahme des alten Manticore-Index erlauben würde.",CUT-04,CUT-06,"- Suchindex enthält nach dem Neuaufbau alle migrierten Dokumente und Mails je Tenant
|
||||
- Suche liefert für eine Stichprobe bekannter Inhalte dieselben Treffer wie im Altsystem","1. Stichprobe von 20 Suchanfragen je Tenant gegen Altsystem-Ergebnis verglichen
|
||||
2. Reindexierungsdauer und Vollständigkeit protokolliert"
|
||||
CUT-06,Parallelbetrieb read-only & Abschaltung Altsysteme,🚀 Cutover-Ablauf,Backend,Mittel,2,13,Backlog,"90 Tage read-only Parallelbetrieb, danach zweite schriftliche Freigabe zur Abschaltung","Altsysteme bleiben nach dem Stichtag für einen definierten Zeitraum (Vorschlag: 90 Tage) lesend erreichbar, für den Fall dass eine Diskrepanz erst nach dem Stichtag auffällt. Abschaltung erfolgt erst nach Ablauf der Frist und einer zweiten, schriftlich festgehaltenen Freigabe.",CUT-04 CUT-05,,"- Altsysteme sind während der Parallelbetriebsfrist ausschließlich lesend erreichbar, keine Schreibzugriffe möglich
|
||||
- Abschaltung erfolgt erst nach Ablauf der Frist UND einer zweiten schriftlichen Freigabe
|
||||
- Während der Frist gemeldete Diskrepanzen sind bis zur Abschaltung bearbeitet oder bewusst zurückgestellt","1. Schreibzugriff auf Altsystem während Parallelbetrieb wird nachweislich abgewiesen
|
||||
2. Zweite Freigabe zur Abschaltung liegt schriftlich vor Abschaltungstermin vor"
|
||||
ROL-01,Rollback-Kriterien definieren,⏪ Rollback,Backend,Einfach,1,10,Backlog,"Dokumentierte, vorab festgelegte Rollback-Schwellenwerte","Klare, vorab festgelegte Kriterien für eine Rollback-Entscheidung (z. B. Verifikation aus VAL-01 bis VAL-05 schlägt für mehr als X % der Tenants fehl), statt Einzelfallentscheidung unter Zeitdruck am Stichtag selbst.",CUT-02,ROL-02,"- Rollback-Schwellenwerte sind schriftlich dokumentiert und vor dem Stichtag freigegeben
|
||||
- Kriterien sind messbar, nicht subjektiv formuliert","1. Kriterien-Dokument liegt vor Stichtag-Termin vor
|
||||
2. Kriterien wurden gegen das Ergebnis der Generalprobe (CUT-02) durchgerechnet"
|
||||
ROL-02,Rollback-Testlauf,⏪ Rollback,Backend,Mittel,2,11,Backlog,"Simulierter Rollback: Wartungsmodus aufheben, Freischaltung zurücknehmen","Testlauf des Rollback-Pfads in der isolierten Testumgebung: Wartungsmodus des Altsystems aufheben, NEXARCH-Freischaltung zurücknehmen – Altsysteme werden am Stichtag nicht gelöscht, nur in Wartungsmodus versetzt, Rollback bedeutet diesen Zustand rückgängig zu machen.",ROL-01 CUT-02,,"- Rollback-Pfad ist in der Testumgebung erfolgreich durchgespielt worden
|
||||
- Nach simuliertem Rollback ist das Altsystem wieder vollständig nutzbar
|
||||
- Dauer des Rollback-Vorgangs ist gemessen und dokumentiert","1. Simulierter Rollback in Testumgebung erfolgreich abgeschlossen
|
||||
2. Nach Rollback ist kein Datenverlust im Altsystem feststellbar"
|
||||
|
File diff suppressed because it is too large.
Load diff
@@ -0,0 +1,50 @@
|
||||
<!DOCTYPE html>
|
||||
<html lang="de">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>Migration Kanban – lokal</title>
|
||||
<link rel="stylesheet" href="../_shared/kanban.css">
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<div class="row">
|
||||
<h1>Migration Kanban <span class="sub">– lokal, offline, ohne Server</span></h1>
|
||||
<input id="q" placeholder="Suche: Code, Titel, Technik …" style="min-width:220px" />
|
||||
<select id="fEpic"><option value="">Alle Epics</option></select>
|
||||
<select id="fRole"><option value="">Alle Rollen</option></select>
|
||||
<select id="fWave"><option value="">Alle Wellen</option></select>
|
||||
<button id="onlyReady">Nur startbare</button>
|
||||
<button id="exportBtn">Stand sichern</button>
|
||||
<button id="resetBtn">Zurücksetzen</button>
|
||||
</div>
|
||||
<div class="stats" id="stats"></div>
|
||||
</header>
|
||||
<div class="board" id="board"></div>
|
||||
|
||||
<dialog id="dlg">
|
||||
<div class="dlg-head">
|
||||
<div>
|
||||
<div class="code" id="dCode" style="font-family:ui-monospace,Menlo,monospace;font-size:11px;color:var(--muted)"></div>
|
||||
<div id="dTitle" style="font-size:18px;font-weight:600;margin-top:4px"></div>
|
||||
<div id="dMeta" style="margin-top:8px"></div>
|
||||
</div>
|
||||
<div class="row">
|
||||
<button class="primary" id="copyBtn">Prompt kopieren</button>
|
||||
<button id="closeBtn">Schließen</button>
|
||||
</div>
|
||||
</div>
|
||||
<div class="dlg-body">
|
||||
<p id="dDesc" style="font-size:13px;color:#C7D3E5;line-height:1.6;margin-top:0"></p>
|
||||
<h3>Baut auf</h3><div id="dDeps"></div>
|
||||
<h3>Schaltet frei</h3><div id="dNext"></div>
|
||||
<h3>Akzeptanzkriterien</h3><ul id="dAcc"></ul>
|
||||
<h3>Prüfungen vor der Abnahme</h3><ul id="dChk"></ul>
|
||||
<h3>Bau-Prompt</h3><pre id="dPrompt"></pre>
|
||||
</div>
|
||||
</dialog>
|
||||
|
||||
<script id="data" type="application/json">{"erzeugtAm": "2026-08-28","totalDays": 87,"epics": [{"key": "MAP","name": "Tenant- & User-Mapping","emoji": "🔗","color": "#DC2626","description": "Identitätsauflösung zwischen archivmail und archivdms: welche Tenants/Benutzer sind dieselbe Organisation/Person, mit Pflicht-Freigabe vor jedem Merge."},{"key": "COR","name": "Core-Migration","emoji": "🏛️","color": "#2563EB","description": "Übernahme von Tenants, Benutzern, Rollen/Rechten, LDAP-Feldern und Audit-Log in NEXARCH Core."},{"key": "DOK","name": "DMS-Migration","emoji": "📁","color": "#059669","description": "Übernahme von Dokumenten, Revisionen, Aktenstruktur, ACLs, Metadaten und Freigabelinks aus archivdms."},{"key": "MAI","name": "Mail-Migration","emoji": "📧","color": "#D97706","description": "Übernahme von Postfach-Konfiguration, Nachrichten, Anhängen, DSGVO-Löschanfragen und Reconciliation-Reports aus archivmail."},{"key": "TAR","name": "Archive-Migration","emoji": "⏳","color": "#B45309","description": "Übernahme von Aufbewahrungsfristen und offenen Vier-Augen-Löschworkflows – der GoBD-kritischste Teil der Migration."},{"key": "WFL","name": "Workflow-Migration","emoji": "🔀","color": "#7C3AED","description": "Übernahme abgeschlossener Workflow-Historie; laufende Instanzen werden bewusst nicht migriert."},{"key": "VAL","name": "Verifikation","emoji": "🔍","color": "#16A34A","description": "Pflichtprüfungen je Tenant vor Freischaltung: Zeilenzahlen, Binär-Hashes, Retention-Fristen, Audit-Kontinuität, Login-Test."},{"key": "CUT","name": "Cutover-Ablauf","emoji": "🚀","color": "#0EA5E9","description": "Trockenläufe, finale Mapping-Freigabe, Stichtag-Durchführung, Reindexierung, Parallelbetrieb und Abschaltung der Altsysteme."},{"key": "ROL","name": "Rollback","emoji": "⏪","color": "#64748B","description": "Rollback-Pfad und -Kriterien, die vor dem Stichtag feststehen müssen, nicht danach improvisiert werden."}],"waves": [{"welle": 1,"codes": ["MAP-01"]},{"welle": 2,"codes": ["MAP-02"]},{"welle": 3,"codes": ["MAP-03","COR-01"]},{"welle": 4,"codes": ["MAP-04","COR-05","DOK-01","MAI-01"]},{"welle": 5,"codes": ["COR-02","DOK-02","DOK-04","DOK-05","MAI-02","VAL-04"]},{"welle": 6,"codes": ["COR-03","COR-04","MAI-03","MAI-04","TAR-01","WFL-01","VAL-01","VAL-02","VAL-05"]},{"welle": 7,"codes": ["DOK-03","TAR-02","VAL-03"]},{"welle": 8,"codes": ["CUT-01"]},{"welle": 9,"codes": ["CUT-02"]},{"welle": 10,"codes": ["CUT-03","ROL-01"]},{"welle": 11,"codes": ["CUT-04","ROL-02"]},{"welle": 12,"codes": ["CUT-05"]},{"welle": 13,"codes": ["CUT-06"]}],"kritischerPfad": {"path": ["MAP-01","MAP-02","COR-01","MAI-01","MAI-02","TAR-01","TAR-02","CUT-01","CUT-02","CUT-03","CUT-04","CUT-05","CUT-06"],"days": 40},"produktDna": {"uebernehmen": [{"produkt": "Allgemeine Migrationspraxis","staerke": "Zwei Trockenläufe vor dem echten Stichtag statt direktem Sprung auf Produktivdaten."},{"produkt": "GoBD-Praxis","staerke": "Aufbewahrungsfristen werden nie neu berechnet, nur exakt übernommen."}],"vermeiden": [{"produkt": "Automatischer Merge ohne Freigabe – Risiko der Datenvermischung zweier Kunden.","ansatz": "Pflicht-Freigabe durch einen Menschen für jede Tenant-/User-Zusammenführung."}]},"epicDna": {"MAP": {"leitsatz": "Kein automatischer Merge ohne Mensch – eine falsche Tenant-Zusammenführung ist ein Compliance-Vorfall, keine Bagatelle.","uebernehmen": ["Slug/Domain-Matching mit gepflegter Kunden-Zuordnungsliste als Fallback statt reinem Freitext-Matching."],"vermeiden": ["Automatisches Zusammenführen von Tenants oder Benutzern ohne schriftliche menschliche Freigabe je Fall."]},"COR": {"leitsatz": "Migrieren, was mechanisch übertragbar ist (Passwort-Hashes, Audit-Historie); neu ausstellen, was Secrets sind (Sessions, API-Keys).","uebernehmen": ["bcrypt-Passwort-Hashes 1:1 übernehmen, kein Rehash nötig.","archivdms-Rechtemodell als reifere Zielvorlage für RBAC."],"vermeiden": ["Keine Migration von Sessions/Tokens/API-Keys – Secrets werden grundsätzlich neu ausgestellt, nicht kopiert."]},"DOK": {"leitsatz": "Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.","uebernehmen": ["Aktenstruktur strukturell 1:1 übernehmbar."],"vermeiden": ["Kein Import des trainierten ML-Klassifikator-Binärmodells – DMS ist Neubau ohne Codeimport."]},"MAI": {"leitsatz": "Zugangsdaten werden nie kopiert, nur neu angelegt und neu getestet.","uebernehmen": ["Nachrichten/Anhänge per Objekt-Storage-Kopie mit Referenz-Rewrite."],"vermeiden": ["Kein Übernehmen von `indexed_at`-Statusfeldern – Suchindex wird nach der Migration komplett neu aufgebaut."]},"TAR": {"leitsatz": "Aufbewahrungsfristen dürfen beim Umzug unter keinen Umständen zurückgesetzt werden – GoBD-Kontinuität ist nicht verhandelbar.","uebernehmen": ["`retain_until`-Werte exakt 1:1 übernehmen, keine Neuberechnung."],"vermeiden": ["Keine stille Neuberechnung von Fristen anhand des Migrationsdatums."]}Line truncated
|
||||
<script src="../_shared/kanban.js"></script>
|
||||
</body>
|
||||
</html>
|
||||
@@ -0,0 +1,55 @@
|
||||
# COR-01 – Tenant-Datenmodell-Migration
|
||||
|
||||
**Epic:** 🏛️ Core-Migration | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Übernahme der zusammengeführten Tenant-Datensätze in Core TEN-01, tenant_id konsequent über die freigegebene Tenant-Map umgeschrieben.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Core TEN-01 unter Nutzung der Tenant-Map
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Migrieren, was mechanisch übertragbar ist (Passwort-Hashes, Audit-Historie); neu ausstellen, was Secrets sind (Sessions, API-Keys).
|
||||
|
||||
**Übernehmen:**
|
||||
- bcrypt-Passwort-Hashes 1:1 übernehmen, kein Rehash nötig.
|
||||
- archivdms-Rechtemodell als reifere Zielvorlage für RBAC.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Migration von Sessions/Tokens/API-Keys – Secrets werden grundsätzlich neu ausgestellt, nicht kopiert.
|
||||
|
||||
**Für genau diese Kachel:** Erster inhaltlicher Migrationsschritt – alle Folgeschritte (Core, DMS, Mail, Archive, Workflow) setzen bereits migrierte Tenants voraus.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAP-02` Tenant-Migration-Map & Freigabe-Workflow – Referenztabelle tenant_migration_map (archivmail_tenant_id, archivdms_tenant_id, nexarch_tenant_id) mit Pflicht-Freigabe durch einen Menschen je Zusammenführung, bevor sie für nachgelagerte Migrationsschritte nutzbar wird.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jeder freigegebene Tenant existiert nach der Migration genau einmal in Core
|
||||
2. Keine Tenant-Daten ohne Eintrag in der freigegebenen Tenant-Map werden übernommen
|
||||
3. Migration ist wiederholbar (idempotent) gegen dieselbe Quelle
|
||||
|
||||
## 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. Zeilenzahl migrierter Tenants entspricht Anzahl freigegebener Map-Einträge
|
||||
2. Erneuter Lauf gegen bereits migrierte Daten erzeugt keine Duplikate
|
||||
3. Stichprobe von 5 Tenants auf korrekt umgeschriebene tenant_id geprüft
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Benutzer-, Rollen- oder Auditdaten – eigene Kacheln (COR-02 ff.).
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,59 @@
|
||||
# COR-02 – Benutzer-Migration inkl. Passwort-Hashes
|
||||
|
||||
**Epic:** 🏛️ Core-Migration | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Übernahme der zusammengeführten Benutzerdatensätze in Core IAM-01 unter Nutzung der User-Map; bcrypt-Passwort-Hashes werden 1:1 übernommen, kein Rehash nötig, da dasselbe Hash-Verfahren in beiden Altsystemen verwendet wird.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Core IAM-01, bcrypt-Hash-Übernahme ohne Rehash
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Migrieren, was mechanisch übertragbar ist (Passwort-Hashes, Audit-Historie); neu ausstellen, was Secrets sind (Sessions, API-Keys).
|
||||
|
||||
**Übernehmen:**
|
||||
- bcrypt-Passwort-Hashes 1:1 übernehmen, kein Rehash nötig.
|
||||
- archivdms-Rechtemodell als reifere Zielvorlage für RBAC.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Migration von Sessions/Tokens/API-Keys – Secrets werden grundsätzlich neu ausgestellt, nicht kopiert.
|
||||
|
||||
**Für genau diese Kachel:** Voraussetzung für nahezu jede weitere Migrationsstufe, die Benutzer referenziert (Rollen, ACLs, Audit).
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAP-04` User-Migration-Map & Freigabe-Workflow – Referenztabelle user_migration_map (archivmail_user_id, archivdms_user_id, nexarch_user_id) mit derselben Pflicht-Freigabe wie bei Tenants, bevor sie für die Core-Benutzer-Migration nutzbar wird.
|
||||
- `COR-01` Tenant-Datenmodell-Migration – Übernahme der zusammengeführten Tenant-Datensätze in Core TEN-01, tenant_id konsequent über die freigegebene Tenant-Map umgeschrieben.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jeder freigegebene Benutzer existiert nach der Migration genau einmal in Core
|
||||
2. Migrierte Passwort-Hashes funktionieren unverändert beim ersten Login nach der Migration
|
||||
3. Benutzer ohne Eintrag in der freigegebenen User-Map werden nicht automatisch zusammengeführt
|
||||
|
||||
## 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. Login-Test mit 5 migrierten Testkonten gegen migrierte Hashes erfolgreich
|
||||
2. Zeilenzahl migrierter Benutzer entspricht Anzahl freigegebener Map-Einträge
|
||||
3. Erneuter Lauf gegen bereits migrierte Daten erzeugt keine Duplikate
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
Ursprünglich war ein Rehash beim Import angedacht – unnötig, da beide Altsysteme bcrypt verwenden; ein Rehash hätte nur unnötiges Risiko für Tippfehler im Migrationsskript bedeutet.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Sessions/Tokens – werden bewusst nicht migriert, siehe CUT-04.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,51 @@
|
||||
# COR-03 – Rollen- & Rechte-Migration
|
||||
|
||||
**Epic:** 🏛️ Core-Migration | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
archivdms besitzt das reifere Rechtemodell (permission_groups, *_grants) und dient als Zielvorlage; archivmail-Textrollen werden auf die passende Core-Rolle gemappt, nicht 1:1 als Freitext übernommen.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Core RBAC-01/RBAC-03
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Migrieren, was mechanisch übertragbar ist (Passwort-Hashes, Audit-Historie); neu ausstellen, was Secrets sind (Sessions, API-Keys).
|
||||
|
||||
**Übernehmen:**
|
||||
- bcrypt-Passwort-Hashes 1:1 übernehmen, kein Rehash nötig.
|
||||
- archivdms-Rechtemodell als reifere Zielvorlage für RBAC.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Migration von Sessions/Tokens/API-Keys – Secrets werden grundsätzlich neu ausgestellt, nicht kopiert.
|
||||
|
||||
**Für genau diese Kachel:** Rechte-Vererbung ist sicherheitskritisch – ein falsches Mapping kann versehentlich Zugriff gewähren oder entziehen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-02` Benutzer-Migration inkl. Passwort-Hashes – Übernahme der zusammengeführten Benutzerdatensätze in Core IAM-01 unter Nutzung der User-Map; bcrypt-Passwort-Hashes werden 1:1 übernommen, kein Rehash nötig, da dasselbe Hash-Verfahren in beiden Altsystemen verwendet wird.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede archivdms-Berechtigungsgruppe hat eine eindeutige Core-RBAC-Entsprechung
|
||||
2. Jede archivmail-Textrolle ist auf genau eine Core-Rolle gemappt, dokumentiert in einer Mapping-Tabelle
|
||||
3. Kein Benutzer verliert oder gewinnt Rechte gegenüber dem Altsystem ohne dokumentierte Begründung
|
||||
|
||||
## 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. Stichprobe von 10 Benutzern: Rechte vor/nach Migration verglichen und Abweichungen dokumentiert
|
||||
2. Rollen-Mapping-Tabelle vollständig, keine unzugeordnete archivmail-Rolle offen
|
||||
3. Zugriffstest mit migriertem Konto bestätigt erwartete Berechtigung
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,50 @@
|
||||
# COR-04 – LDAP-Feld-Migration
|
||||
|
||||
**Epic:** 🏛️ Core-Migration | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Übernahme der LDAP-Kopplungsfelder mit archivdms-Feldtiefe (ldap_uid, ldap_synced_at) als Zielschema; archivmail-Konten mit einfacherem source-Feld werden nachträglich angereichert, fehlende Felder bleiben leer bis zur nächsten Synchronisation.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Core IAM-05
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Migrieren, was mechanisch übertragbar ist (Passwort-Hashes, Audit-Historie); neu ausstellen, was Secrets sind (Sessions, API-Keys).
|
||||
|
||||
**Übernehmen:**
|
||||
- bcrypt-Passwort-Hashes 1:1 übernehmen, kein Rehash nötig.
|
||||
- archivdms-Rechtemodell als reifere Zielvorlage für RBAC.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Migration von Sessions/Tokens/API-Keys – Secrets werden grundsätzlich neu ausgestellt, nicht kopiert.
|
||||
|
||||
**Für genau diese Kachel:** Migrieren, was mechanisch übertragbar ist (Passwort-Hashes, Audit-Historie); neu ausstellen, was Secrets sind (Sessions, API-Keys).
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-02` Benutzer-Migration inkl. Passwort-Hashes – Übernahme der zusammengeführten Benutzerdatensätze in Core IAM-01 unter Nutzung der User-Map; bcrypt-Passwort-Hashes werden 1:1 übernommen, kein Rehash nötig, da dasselbe Hash-Verfahren in beiden Altsystemen verwendet wird.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. archivdms-LDAP-Felder vollständig 1:1 übernommen
|
||||
2. archivmail-Konten mit LDAP-Bezug sind als solche erkennbar, auch mit unvollständigen Feldern
|
||||
3. Fehlende Felder blockieren die Migration des Kontos nicht
|
||||
|
||||
## 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. Stichprobe von 5 LDAP-gebundenen Konten je Altsystem korrekt migriert
|
||||
2. Nächster LDAP-Sync-Lauf ergänzt fehlende Felder ohne Fehler
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,51 @@
|
||||
# COR-05 – Audit-Log-Zusammenführung
|
||||
|
||||
**Epic:** 🏛️ Core-Migration | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Zusammenführen der audit_log-Tabellen beider Altsysteme in Core; beide nutzen dasselbe Append-only-Trigger-Muster, daher rein mechanisch – historische Einträge behalten ihren originalen Zeitstempel, nur tenant_id/user_id werden über die Mapping-Tabellen umgeschrieben.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Core AUD-01/AUD-02, mechanisches Zusammenführen ohne inhaltliche Änderung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Migrieren, was mechanisch übertragbar ist (Passwort-Hashes, Audit-Historie); neu ausstellen, was Secrets sind (Sessions, API-Keys).
|
||||
|
||||
**Übernehmen:**
|
||||
- bcrypt-Passwort-Hashes 1:1 übernehmen, kein Rehash nötig.
|
||||
- archivdms-Rechtemodell als reifere Zielvorlage für RBAC.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Migration von Sessions/Tokens/API-Keys – Secrets werden grundsätzlich neu ausgestellt, nicht kopiert.
|
||||
|
||||
**Für genau diese Kachel:** Audit-Integrität ist ein eigenständiges Compliance-Ziel – die Migration darf die Beweiskraft des Protokolls nicht schwächen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-01` Tenant-Datenmodell-Migration – Übernahme der zusammengeführten Tenant-Datensätze in Core TEN-01, tenant_id konsequent über die freigegebene Tenant-Map umgeschrieben.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jeder historische Audit-Eintrag existiert nach der Migration mit unverändertem Zeitstempel und Inhalt
|
||||
2. Nur tenant_id/user_id sind über die Mapping-Tabellen umgeschrieben, kein anderes Feld verändert
|
||||
3. Append-only-Eigenschaft bleibt nach der Migration erhalten, auch für migrierte Einträge
|
||||
|
||||
## 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. Stichprobe von 20 historischen Einträgen: Inhalt und Zeitstempel exakt mit Quelle verglichen
|
||||
2. Versuch, einen migrierten Eintrag nachträglich zu ändern, wird vom Append-only-Mechanismus abgewiesen
|
||||
3. Ältester und neuester Eintrag je Tenant nach Migration mit Quelle abgeglichen
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,58 @@
|
||||
# CUT-01 – Trockenlauf 1 – Entwicklung
|
||||
|
||||
**Epic:** 🚀 Cutover-Ablauf | **Rolle:** Backend | **Komplexität:** Hoch | **Aufwand:** 4 Personentage | **Welle:** 8
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Iterativer Testlauf aller Migrationsskripte gegen eine anonymisierte Kopie der Produktivdaten während der Entwicklung – Fehler werden hier gefunden, nicht erst bei der Generalprobe.
|
||||
|
||||
**Technische Grundlage:** Migrationsskripte gegen anonymisierte Kopie der Produktivdaten, iterativ
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
**Übernehmen:**
|
||||
- Zwei Trockenläufe vor dem echten Stichtag: einer in Entwicklung, einer als vollständige Generalprobe.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein direkter Sprung von Entwicklung zu Produktiv-Stichtag ohne Generalprobe.
|
||||
|
||||
**Für genau diese Kachel:** Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-03` Rollen- & Rechte-Migration – archivdms besitzt das reifere Rechtemodell (permission_groups, *_grants) und dient als Zielvorlage; archivmail-Textrollen werden auf die passende Core-Rolle gemappt, nicht 1:1 als Freitext übernommen.
|
||||
- `COR-04` LDAP-Feld-Migration – Übernahme der LDAP-Kopplungsfelder mit archivdms-Feldtiefe (ldap_uid, ldap_synced_at) als Zielschema; archivmail-Konten mit einfacherem source-Feld werden nachträglich angereichert, fehlende Felder bleiben leer bis zur nächsten Synchronisation.
|
||||
- `DOK-02` Akten-/Ordnerstruktur-Migration – Übernahme der akten-Tabelle (Ordner-/Aktenstruktur) aus archivdms – strukturell 1:1 auf DMS DOC-09 übertragbar.
|
||||
- `DOK-03` ACL-Daten-Migration nach Core-Rechtemodell – document_visibility, permission_groups und *_grants aus archivdms wandern inhaltlich in das Core-Rechtemodell, nicht in eine DMS-eigene Struktur – DMS-Tickets referenzieren dafür ausschließlich Core RBAC-02/RBAC-04.
|
||||
- `DOK-04` Custom-Fields- & Klassifikationsvorlagen-Migration – 1:1-Übernahme benutzerdefinierter Felder und Klassifikationsvorlagen aus archivdms.
|
||||
- `DOK-05` Freigabelinks-Migration – Übernahme aktiver, nicht abgelaufener document_shares (Freigabelinks); bereits abgelaufene Links werden verworfen statt migriert.
|
||||
- `MAI-03` DSGVO-Löschanfragen-Migration – Offene, unbearbeitete DSGVO-Löschanfragen aus archivmail werden nach Archive CMP-02 migriert; bereits abgeschlossene Anfragen werden nur als historischer Audit-Eintrag übernommen, nicht als aktiver Vorgang.
|
||||
- `MAI-04` Reconciliation-Reports-Archivierung – Historische Reconciliation-Reports aus archivmail werden als Nachweis nach Archive BAK-05 archiviert – kein aktiver Datenbestand, rein historischer Beleg.
|
||||
- `TAR-02` Vier-Augen-Löschworkflow-Migration – Offene Löschanfragen aus document_delete_requests (nur archivdms) werden nach Archive CMP-06 migriert; bereits vollzogene Löschungen bleiben nur als Audit-Eintrag bestehen, da das Objekt selbst nicht mehr existiert.
|
||||
- `WFL-01` Workflow-Historie-Migration – Abgeschlossene Workflows/Automatisierungen aus archivdms werden als Historie nach Workflow ENG-01/RTE-01 übernommen; laufende Workflow-Instanzen werden NICHT migriert – sie müssen vor dem Stichtag im Altsystem bewusst zu Ende geführt oder abgebrochen werden.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Alle Migrationsskripte laufen mindestens einmal vollständig durch, ohne Abbruch
|
||||
2. Gefundene Fehler sind vor Übergang zu Trockenlauf 2 behoben
|
||||
3. Anonymisierung der Testkopie ist nachweislich wirksam (keine echten Personendaten im Testlauf)
|
||||
|
||||
## 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 Lauf gegen anonymisierte Kopie protokolliert
|
||||
2. Mindestens zwei Iterationen mit dokumentierten Korrekturen durchgeführt
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,54 @@
|
||||
# CUT-02 – Trockenlauf 2 – Generalprobe
|
||||
|
||||
**Epic:** 🚀 Cutover-Ablauf | **Rolle:** Backend | **Komplexität:** Hoch | **Aufwand:** 4 Personentage | **Welle:** 9
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Vollständiger Migrationslauf gegen eine reale, aktuelle Kopie beider Produktivdatenbanken in einer isolierten NEXARCH-Testumgebung; Ergebnis wird stichprobenartig gegen die Quelle geprüft (Dokument-/Mail-Anzahl je Tenant, Volltextvergleich, Retention-Fristen-Abgleich).
|
||||
|
||||
**Technische Grundlage:** Vollständiger Lauf gegen reale Produktivkopie in isolierter Testumgebung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
**Übernehmen:**
|
||||
- Zwei Trockenläufe vor dem echten Stichtag: einer in Entwicklung, einer als vollständige Generalprobe.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein direkter Sprung von Entwicklung zu Produktiv-Stichtag ohne Generalprobe.
|
||||
|
||||
**Für genau diese Kachel:** Letzte Gelegenheit, Fehler ohne Risiko für echte Produktivdaten zu finden.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `CUT-01` Trockenlauf 1 – Entwicklung – Iterativer Testlauf aller Migrationsskripte gegen eine anonymisierte Kopie der Produktivdaten während der Entwicklung – Fehler werden hier gefunden, nicht erst bei der Generalprobe.
|
||||
- `VAL-01` Zeilenzahl-Abgleich je Kerntabelle – Automatisierter Abgleich der Zeilenzahl je migrierter Kerntabelle (Dokumente, Mails, Benutzer) alt vs. neu, je Tenant, abzüglich bewusst nicht migrierter Kategorien.
|
||||
- `VAL-02` Hash-Vergleich migrierter Binärdateien – Stichprobenweiser Hash-Vergleich migrierter Binärdateien (Dokumente, Mail-Anhänge) im Objekt-Storage gegen die Quelle, um bitgenaue Übernahme nachzuweisen.
|
||||
- `VAL-03` Retention-Fristen-Verifikation – Für eine Stichprobe von Objekten mit retain_until in der Zukunft wird geprüft, dass die Frist nach der Migration exakt identisch mit der Quelle ist.
|
||||
- `VAL-04` Audit-Log-Kontinuitätsprüfung – Prüfung, dass ältester und neuester Audit-Log-Eintrag je Tenant nach der Migration mit der Quelle übereinstimmen – keine Lücke, keine Zeitverschiebung.
|
||||
- `VAL-05` Login-Test mit migrierten Zugangsdaten – Login-Test mit migrierten Zugangsdaten für eine Stichprobe von Benutzern je Tenant, um die praktische Funktionsfähigkeit der Benutzer-Migration zu bestätigen.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Vollständiger Lauf gegen reale Produktivkopie ohne manuellen Eingriff durchgeführt
|
||||
2. Alle Verifikationen aus VAL-01 bis VAL-05 sind für die Generalprobe erfolgreich durchgeführt
|
||||
3. Isolierte Testumgebung hat keine Verbindung zu echten Produktivsystemen
|
||||
|
||||
## 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. Generalprobe-Protokoll mit Zeitstempel, Dauer und Ergebnis je Verifikationsschritt abgelegt
|
||||
2. Mindestens ein bewusst eingebauter Testfehler wird von der Verifikation erkannt
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,49 @@
|
||||
# CUT-03 – Tenant- und User-Mapping final freigeben
|
||||
|
||||
**Epic:** 🚀 Cutover-Ablauf | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentage | **Welle:** 10
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Finale, schriftlich festgehaltene Freigabe der Tenant- und User-Migration-Map – spätestens hier, nicht erst am Stichtag selbst.
|
||||
|
||||
**Technische Grundlage:** Formaler Freigabe-Meilenstein vor dem Stichtag
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
**Übernehmen:**
|
||||
- Zwei Trockenläufe vor dem echten Stichtag: einer in Entwicklung, einer als vollständige Generalprobe.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein direkter Sprung von Entwicklung zu Produktiv-Stichtag ohne Generalprobe.
|
||||
|
||||
**Für genau diese Kachel:** Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAP-04` User-Migration-Map & Freigabe-Workflow – Referenztabelle user_migration_map (archivmail_user_id, archivdms_user_id, nexarch_user_id) mit derselben Pflicht-Freigabe wie bei Tenants, bevor sie für die Core-Benutzer-Migration nutzbar wird.
|
||||
- `CUT-02` Trockenlauf 2 – Generalprobe – Vollständiger Migrationslauf gegen eine reale, aktuelle Kopie beider Produktivdatenbanken in einer isolierten NEXARCH-Testumgebung; Ergebnis wird stichprobenartig gegen die Quelle geprüft (Dokument-/Mail-Anzahl je Tenant, Volltextvergleich, Retention-Fristen-Abgleich).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Finale Freigabe ist schriftlich dokumentiert mit Zeitpunkt und freigebender Person
|
||||
2. Nach dieser Freigabe werden keine weiteren Änderungen an der Map ohne erneuten Freigabeprozess vorgenommen
|
||||
|
||||
## 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. Freigabedokument liegt vor und ist auffindbar
|
||||
2. Stichprobe bestätigt: Map entspricht dem Stand der Generalprobe (CUT-02)
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,54 @@
|
||||
# CUT-04 – Stichtag-Durchführung
|
||||
|
||||
**Epic:** 🚀 Cutover-Ablauf | **Rolle:** Backend | **Komplexität:** Hoch | **Aufwand:** 3 Personentage | **Welle:** 11
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Durchführung des eigentlichen Stichtags: Altsysteme in Wartungsmodus (read-only) versetzen, finalen Datenexport ziehen, Migrationsskripte laufen lassen, Verifikation (VAL-01 bis VAL-05) je Tenant durchführen, NEXARCH freischalten.
|
||||
|
||||
**Technische Grundlage:** Wartungsmodus, finaler Export, Migrationslauf, Verifikation, Freischaltung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
**Übernehmen:**
|
||||
- Zwei Trockenläufe vor dem echten Stichtag: einer in Entwicklung, einer als vollständige Generalprobe.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein direkter Sprung von Entwicklung zu Produktiv-Stichtag ohne Generalprobe.
|
||||
|
||||
**Für genau diese Kachel:** Der eigentliche Big-Bang-Moment – alles vorher Getestete kommt hier zusammen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `CUT-03` Tenant- und User-Mapping final freigeben – Finale, schriftlich festgehaltene Freigabe der Tenant- und User-Migration-Map – spätestens hier, nicht erst am Stichtag selbst.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Altsysteme sind für die Dauer der Migration nachweislich im Wartungsmodus
|
||||
2. Jeder Tenant wird erst nach erfolgreicher Verifikation freigeschaltet, kein Tenant pauschal
|
||||
3. Ablauf ist von Beginn bis Freischaltung lückenlos 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. Wartungsmodus-Aktivierung für beide Altsysteme bestätigt
|
||||
2. Verifikationsergebnis je Tenant vor Freischaltung dokumentiert
|
||||
3. Freischaltungszeitpunkt je Tenant protokolliert
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Rollback-Durchführung selbst – siehe ROL-02, falls Kriterien greifen.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# CUT-05 – Suchindex-Neuaufbau nach Migration
|
||||
|
||||
**Epic:** 🚀 Cutover-Ablauf | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 12
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Nach erfolgreicher Migration wird der komplette Suchindex aus den migrierten Metadaten neu aufgebaut – es existiert kein DB-Sync-Table in beiden Altsystemen, der eine Übernahme des alten Manticore-Index erlauben würde.
|
||||
|
||||
**Technische Grundlage:** Vollständige Reindexierung aus migrierten Metadaten, kein Kopieren des alten Manticore-Index
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
**Übernehmen:**
|
||||
- Zwei Trockenläufe vor dem echten Stichtag: einer in Entwicklung, einer als vollständige Generalprobe.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein direkter Sprung von Entwicklung zu Produktiv-Stichtag ohne Generalprobe.
|
||||
|
||||
**Für genau diese Kachel:** Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `CUT-04` Stichtag-Durchführung – Durchführung des eigentlichen Stichtags: Altsysteme in Wartungsmodus (read-only) versetzen, finalen Datenexport ziehen, Migrationsskripte laufen lassen, Verifikation (VAL-01 bis VAL-05) je Tenant durchführen, NEXARCH freischalten.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Suchindex enthält nach dem Neuaufbau alle migrierten Dokumente und Mails je Tenant
|
||||
2. Suche liefert für eine Stichprobe bekannter Inhalte dieselben Treffer wie im Altsystem
|
||||
|
||||
## 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. Stichprobe von 20 Suchanfragen je Tenant gegen Altsystem-Ergebnis verglichen
|
||||
2. Reindexierungsdauer und Vollständigkeit protokolliert
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,50 @@
|
||||
# CUT-06 – Parallelbetrieb read-only & Abschaltung Altsysteme
|
||||
|
||||
**Epic:** 🚀 Cutover-Ablauf | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 13
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Altsysteme bleiben nach dem Stichtag für einen definierten Zeitraum (Vorschlag: 90 Tage) lesend erreichbar, für den Fall dass eine Diskrepanz erst nach dem Stichtag auffällt. Abschaltung erfolgt erst nach Ablauf der Frist und einer zweiten, schriftlich festgehaltenen Freigabe.
|
||||
|
||||
**Technische Grundlage:** 90 Tage read-only Parallelbetrieb, danach zweite schriftliche Freigabe zur Abschaltung
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
**Übernehmen:**
|
||||
- Zwei Trockenläufe vor dem echten Stichtag: einer in Entwicklung, einer als vollständige Generalprobe.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein direkter Sprung von Entwicklung zu Produktiv-Stichtag ohne Generalprobe.
|
||||
|
||||
**Für genau diese Kachel:** Big Bang heißt EIN Stichtag für alle – nicht ungetesteter Code gegen Produktivdaten.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `CUT-04` Stichtag-Durchführung – Durchführung des eigentlichen Stichtags: Altsysteme in Wartungsmodus (read-only) versetzen, finalen Datenexport ziehen, Migrationsskripte laufen lassen, Verifikation (VAL-01 bis VAL-05) je Tenant durchführen, NEXARCH freischalten.
|
||||
- `CUT-05` Suchindex-Neuaufbau nach Migration – Nach erfolgreicher Migration wird der komplette Suchindex aus den migrierten Metadaten neu aufgebaut – es existiert kein DB-Sync-Table in beiden Altsystemen, der eine Übernahme des alten Manticore-Index erlauben würde.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Altsysteme sind während der Parallelbetriebsfrist ausschließlich lesend erreichbar, keine Schreibzugriffe möglich
|
||||
2. Abschaltung erfolgt erst nach Ablauf der Frist UND einer zweiten schriftlichen Freigabe
|
||||
3. Während der Frist gemeldete Diskrepanzen sind bis zur Abschaltung bearbeitet oder bewusst zurückgestellt
|
||||
|
||||
## 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. Schreibzugriff auf Altsystem während Parallelbetrieb wird nachweislich abgewiesen
|
||||
2. Zweite Freigabe zur Abschaltung liegt schriftlich vor Abschaltungstermin vor
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,54 @@
|
||||
# DOK-01 – Dokument- & Revisions-Migration
|
||||
|
||||
**Epic:** 📁 DMS-Migration | **Rolle:** Backend | **Komplexität:** Hoch | **Aufwand:** 5 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
|
||||
**Technische Grundlage:** Objekt-Storage-Kopie für Binärdaten, SQL-Export/Import für Metadaten
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.
|
||||
|
||||
**Übernehmen:**
|
||||
- Aktenstruktur strukturell 1:1 übernehmbar.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Import des trainierten ML-Klassifikator-Binärmodells – DMS ist Neubau ohne Codeimport.
|
||||
|
||||
**Für genau diese Kachel:** Größter Datenvolumen-Posten der gesamten Migration – Grundlage für alle weiteren DMS-Migrationsschritte.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-01` Tenant-Datenmodell-Migration – Übernahme der zusammengeführten Tenant-Datensätze in Core TEN-01, tenant_id konsequent über die freigegebene Tenant-Map umgeschrieben.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jedes Dokument samt aller Revisionen ist nach der Migration vollständig referenzierbar
|
||||
2. Binärdaten und Metadaten sind nach der Migration konsistent miteinander verknüpft
|
||||
3. Migration ist wiederholbar (idempotent) gegen dieselbe Quelle
|
||||
|
||||
## 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. Stichprobenweiser Hash-Vergleich migrierter Binärdateien gegen Quelle (siehe auch VAL-02)
|
||||
2. Zeilenzahl migrierter Dokumente/Revisionen entspricht Quelle abzüglich bewusst nicht migrierter Kategorien
|
||||
3. Öffnen und Herunterladen einer Stichprobe migrierter Dokumente über NEXARCH erfolgreich
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- ML-Klassifikator-Binärmodell – wird bewusst nicht migriert, siehe CUT-05-Umfeld / Abschnitt 4 des Migrationskonzepts.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# DOK-02 – Akten-/Ordnerstruktur-Migration
|
||||
|
||||
**Epic:** 📁 DMS-Migration | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Übernahme der akten-Tabelle (Ordner-/Aktenstruktur) aus archivdms – strukturell 1:1 auf DMS DOC-09 übertragbar.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen DMS DOC-09
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.
|
||||
|
||||
**Übernehmen:**
|
||||
- Aktenstruktur strukturell 1:1 übernehmbar.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Import des trainierten ML-Klassifikator-Binärmodells – DMS ist Neubau ohne Codeimport.
|
||||
|
||||
**Für genau diese Kachel:** Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOK-01` Dokument- & Revisions-Migration – Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede Akte/jeder Ordner ist nach der Migration mit derselben Hierarchie wie im Altsystem vorhanden
|
||||
2. Jedes migrierte Dokument ist der korrekten Akte zugeordnet
|
||||
|
||||
## 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. Stichprobe von 10 Aktenpfaden vor/nach Migration verglichen
|
||||
2. Anzahl Ordner/Akten je Tenant deckungsgleich mit Quelle
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,49 @@
|
||||
# DOK-03 – ACL-Daten-Migration nach Core-Rechtemodell
|
||||
|
||||
**Epic:** 📁 DMS-Migration | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 7
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
document_visibility, permission_groups und *_grants aus archivdms wandern inhaltlich in das Core-Rechtemodell, nicht in eine DMS-eigene Struktur – DMS-Tickets referenzieren dafür ausschließlich Core RBAC-02/RBAC-04.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Core RBAC-02/RBAC-04
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.
|
||||
|
||||
**Übernehmen:**
|
||||
- Aktenstruktur strukturell 1:1 übernehmbar.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Import des trainierten ML-Klassifikator-Binärmodells – DMS ist Neubau ohne Codeimport.
|
||||
|
||||
**Für genau diese Kachel:** Sicherheitskritischste DMS-Migrationskachel – falsche ACL-Übernahme kann Dokumente unbeabsichtigt offenlegen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-03` Rollen- & Rechte-Migration – archivdms besitzt das reifere Rechtemodell (permission_groups, *_grants) und dient als Zielvorlage; archivmail-Textrollen werden auf die passende Core-Rolle gemappt, nicht 1:1 als Freitext übernommen.
|
||||
- `DOK-01` Dokument- & Revisions-Migration – Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede dokumentbezogene Sichtbarkeitsregel ist nach der Migration im Core-Rechtemodell abgebildet
|
||||
2. Kein Dokument ist nach der Migration sichtbarer oder unsichtbarer als im Altsystem ohne dokumentierte Begründung
|
||||
|
||||
## 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. Stichprobe von 10 Dokumenten: Sichtbarkeit vor/nach Migration je betroffenem Benutzer verglichen
|
||||
2. Zugriffstest bestätigt erwartete Sichtbarkeit für migrierte Testkonten
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,52 @@
|
||||
# DOK-04 – Custom-Fields- & Klassifikationsvorlagen-Migration
|
||||
|
||||
**Epic:** 📁 DMS-Migration | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
1:1-Übernahme benutzerdefinierter Felder und Klassifikationsvorlagen aus archivdms.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen DMS MET-02/MET-04
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.
|
||||
|
||||
**Übernehmen:**
|
||||
- Aktenstruktur strukturell 1:1 übernehmbar.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Import des trainierten ML-Klassifikator-Binärmodells – DMS ist Neubau ohne Codeimport.
|
||||
|
||||
**Für genau diese Kachel:** Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOK-01` Dokument- & Revisions-Migration – Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jedes Custom Field und jede Klassifikationsvorlage ist nach der Migration mit identischer Definition vorhanden
|
||||
2. Bereits befüllte Feldwerte an migrierten Dokumenten bleiben erhalten
|
||||
|
||||
## Prüfungen vor der Abnahme
|
||||
Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen:
|
||||
1. Stichprobe von 5 Vorlagen vor/nach Migration verglichen
|
||||
2. Feldwerte einer Stichprobe migrierter Dokumente gegen Quelle geprüft
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Trainiertes ML-Klassifikator-Modell selbst – siehe DOK-01, bewusst nicht migriert.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# DOK-05 – Freigabelinks-Migration
|
||||
|
||||
**Epic:** 📁 DMS-Migration | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Übernahme aktiver, nicht abgelaufener document_shares (Freigabelinks); bereits abgelaufene Links werden verworfen statt migriert.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen DMS DOC-07, Ablauf-Filter
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.
|
||||
|
||||
**Übernehmen:**
|
||||
- Aktenstruktur strukturell 1:1 übernehmbar.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Import des trainierten ML-Klassifikator-Binärmodells – DMS ist Neubau ohne Codeimport.
|
||||
|
||||
**Für genau diese Kachel:** Binärdaten per Objekt-Storage-Kopie, Metadaten per SQL-Export – nicht vermischen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOK-01` Dokument- & Revisions-Migration – Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Nur Freigabelinks mit Ablaufdatum in der Zukunft werden migriert
|
||||
2. Migrierte Links funktionieren unverändert mit derselben URL/demselben Token
|
||||
|
||||
## 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. Stichprobe aktiver Links nach Migration erfolgreich aufgerufen
|
||||
2. Abgelaufener Testlink ist nachweislich nicht migriert worden
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,49 @@
|
||||
# MAI-01 – Postfach-Konfiguration neu anlegen
|
||||
|
||||
**Epic:** 📧 Mail-Migration | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Postfach-Konfigurationen aus archivmail werden als Struktur (Server, Ordner, Zuordnung) übernommen, Zugangsdaten jedoch NICHT kopiert – jede Verbindung wird nach der Migration neu angelegt und neu getestet.
|
||||
|
||||
**Technische Grundlage:** Neuanlage IMAP/POP3/SMTP-Konfiguration ohne Zugangsdaten-Kopie
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Zugangsdaten werden nie kopiert, nur neu angelegt und neu getestet.
|
||||
|
||||
**Übernehmen:**
|
||||
- Nachrichten/Anhänge per Objekt-Storage-Kopie mit Referenz-Rewrite.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Übernehmen von `indexed_at`-Statusfeldern – Suchindex wird nach der Migration komplett neu aufgebaut.
|
||||
|
||||
**Für genau diese Kachel:** Erster Schritt der Mail-Migration – Grundlage für Nachrichten-Migration (MAI-02).
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-01` Tenant-Datenmodell-Migration – Übernahme der zusammengeführten Tenant-Datensätze in Core TEN-01, tenant_id konsequent über die freigegebene Tenant-Map umgeschrieben.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede aktive Postfach-Konfiguration ist nach der Migration in Mail IMP-07 strukturell vorhanden
|
||||
2. Keine Zugangsdaten sind aus dem Altsystem kopiert worden
|
||||
3. Jede neu angelegte Verbindung wird vor Abschluss erfolgreich getestet
|
||||
|
||||
## 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. Verbindungstest für jede migrierte Postfach-Konfiguration erfolgreich
|
||||
2. Stichprobenkontrolle bestätigt: keine Zugangsdaten-Felder in der Migrationsdatenbank befüllt
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,54 @@
|
||||
# MAI-02 – Nachrichten- & Anhang-Migration
|
||||
|
||||
**Epic:** 📧 Mail-Migration | **Rolle:** Backend | **Komplexität:** Hoch | **Aufwand:** 5 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Übernahme aller Nachrichten und Anhänge (email_refs) aus archivmail nach Mail ARC-01/ARC-04: Binärdaten per Objekt-Storage-Kopie, Referenzen per SQL-Export/Import; das indexed_at-Statusfeld wird verworfen, da der Suchindex komplett neu aufgebaut wird (siehe CUT-05).
|
||||
|
||||
**Technische Grundlage:** Objekt-Storage-Kopie für Binärdaten, SQL-Export/Import für Referenzen
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Zugangsdaten werden nie kopiert, nur neu angelegt und neu getestet.
|
||||
|
||||
**Übernehmen:**
|
||||
- Nachrichten/Anhänge per Objekt-Storage-Kopie mit Referenz-Rewrite.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Übernehmen von `indexed_at`-Statusfeldern – Suchindex wird nach der Migration komplett neu aufgebaut.
|
||||
|
||||
**Für genau diese Kachel:** Größter Datenvolumen-Posten der Mail-Migration.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAI-01` Postfach-Konfiguration neu anlegen – Postfach-Konfigurationen aus archivmail werden als Struktur (Server, Ordner, Zuordnung) übernommen, Zugangsdaten jedoch NICHT kopiert – jede Verbindung wird nach der Migration neu angelegt und neu getestet.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede Nachricht samt Anhängen ist nach der Migration vollständig referenzierbar
|
||||
2. Binärdaten und Metadaten sind nach der Migration konsistent miteinander verknüpft
|
||||
3. indexed_at-Feld wird nicht übernommen
|
||||
|
||||
## 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. Stichprobenweiser Hash-Vergleich migrierter Anhänge gegen Quelle (siehe auch VAL-02)
|
||||
2. Zeilenzahl migrierter Nachrichten je Tenant deckungsgleich mit Quelle
|
||||
3. Öffnen einer Stichprobe migrierter Nachrichten samt Anhang über NEXARCH erfolgreich
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Suchindex-Aufbau – eigene Kachel CUT-05, kein Kopieren des alten Manticore-Index.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# MAI-03 – DSGVO-Löschanfragen-Migration
|
||||
|
||||
**Epic:** 📧 Mail-Migration | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Offene, unbearbeitete DSGVO-Löschanfragen aus archivmail werden nach Archive CMP-02 migriert; bereits abgeschlossene Anfragen werden nur als historischer Audit-Eintrag übernommen, nicht als aktiver Vorgang.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Archive CMP-02
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Zugangsdaten werden nie kopiert, nur neu angelegt und neu getestet.
|
||||
|
||||
**Übernehmen:**
|
||||
- Nachrichten/Anhänge per Objekt-Storage-Kopie mit Referenz-Rewrite.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Übernehmen von `indexed_at`-Statusfeldern – Suchindex wird nach der Migration komplett neu aufgebaut.
|
||||
|
||||
**Für genau diese Kachel:** DSGVO-Fristen laufen über den Stichtag hinweg weiter – eine verlorene offene Anfrage wäre ein Compliance-Verstoß.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAI-02` Nachrichten- & Anhang-Migration – Übernahme aller Nachrichten und Anhänge (email_refs) aus archivmail nach Mail ARC-01/ARC-04: Binärdaten per Objekt-Storage-Kopie, Referenzen per SQL-Export/Import; das indexed_at-Statusfeld wird verworfen, da der Suchindex komplett neu aufgebaut wird (siehe CUT-05).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede offene Löschanfrage ist nach der Migration als aktiver Vorgang in Archive vorhanden
|
||||
2. Jede abgeschlossene Löschanfrage ist als historischer Audit-Eintrag nachvollziehbar, nicht als aktiver Vorgang
|
||||
|
||||
## 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. Zeilenzahl offener Anfragen nach Migration deckungsgleich mit Quelle
|
||||
2. Stichprobe abgeschlossener Anfragen als Audit-Eintrag auffindbar
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,46 @@
|
||||
# MAI-04 – Reconciliation-Reports-Archivierung
|
||||
|
||||
**Epic:** 📧 Mail-Migration | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Historische Reconciliation-Reports aus archivmail werden als Nachweis nach Archive BAK-05 archiviert – kein aktiver Datenbestand, rein historischer Beleg.
|
||||
|
||||
**Technische Grundlage:** SQL-Export gegen Archive BAK-05
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Zugangsdaten werden nie kopiert, nur neu angelegt und neu getestet.
|
||||
|
||||
**Übernehmen:**
|
||||
- Nachrichten/Anhänge per Objekt-Storage-Kopie mit Referenz-Rewrite.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Kein Übernehmen von `indexed_at`-Statusfeldern – Suchindex wird nach der Migration komplett neu aufgebaut.
|
||||
|
||||
**Für genau diese Kachel:** Zugangsdaten werden nie kopiert, nur neu angelegt und neu getestet.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAI-02` Nachrichten- & Anhang-Migration – Übernahme aller Nachrichten und Anhänge (email_refs) aus archivmail nach Mail ARC-01/ARC-04: Binärdaten per Objekt-Storage-Kopie, Referenzen per SQL-Export/Import; das indexed_at-Statusfeld wird verworfen, da der Suchindex komplett neu aufgebaut wird (siehe CUT-05).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jeder historische Report ist nach der Migration auffindbar und dem korrekten Tenant zugeordnet
|
||||
|
||||
## 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. Stichprobe von 5 Reports vor/nach Migration inhaltlich verglichen
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,56 @@
|
||||
# MAP-01 – Tenant-Export & Slug/Domain-Abgleich
|
||||
|
||||
**Epic:** 🔗 Tenant- & User-Mapping | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 1
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Export der tenants-Tabellen aus archivmail und archivdms (slug, name, Domain) und automatischer Abgleichsvorschlag per Slug-/Domain-Matching, ergänzt um eine manuell gepflegte Kunden-Zuordnungsliste als Fallback-Quelle.
|
||||
|
||||
**Technische Grundlage:** SQL-Export beider tenants-Tabellen, Slug/Domain-Matching-Skript
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein automatischer Merge ohne Mensch – eine falsche Tenant-Zusammenführung ist ein Compliance-Vorfall, keine Bagatelle.
|
||||
|
||||
**Übernehmen:**
|
||||
- Slug/Domain-Matching mit gepflegter Kunden-Zuordnungsliste als Fallback statt reinem Freitext-Matching.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Automatisches Zusammenführen von Tenants oder Benutzern ohne schriftliche menschliche Freigabe je Fall.
|
||||
|
||||
**Für genau diese Kachel:** Dies ist der erste und riskanteste Schritt der gesamten Migration – ohne saubere Tenant-Auflösung sind alle weiteren Schritte auf falscher Grundlage.
|
||||
|
||||
## Ausgangslage
|
||||
Diese Kachel hat keine internen Vorbedingungen und ist sofort startbar.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Beide tenants-Tabellen vollständig exportiert, inkl. slug/name/Domain
|
||||
2. Automatischer Abgleichsvorschlag erzeugt Kandidatenliste mit Konfidenzwert
|
||||
3. Manuelle Zuordnungsliste kann Konflikte des automatischen Abgleichs übersteuern
|
||||
|
||||
## 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-Vollständigkeit gegen Quelltabellen-Zeilenzahl geprüft
|
||||
2. Stichprobe von 10 bekannten Duplikat-Tenants korrekt vorgeschlagen
|
||||
3. Konflikt zwischen automatischem Vorschlag und manueller Liste wird sichtbar markiert, nicht stillschweigend aufgelöst
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
Automatisches Matching allein wurde ursprünglich als ausreichend angesehen – bei Freitext-Firmennamen zu unzuverlässig für GoBD-relevante Daten, deshalb Pflicht-Fallback-Liste.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Freigabe der Zusammenführung selbst (siehe MAP-02) – dieses Ticket liefert nur den Vorschlag.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,57 @@
|
||||
# MAP-02 – Tenant-Migration-Map & Freigabe-Workflow
|
||||
|
||||
**Epic:** 🔗 Tenant- & User-Mapping | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 2
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Referenztabelle tenant_migration_map (archivmail_tenant_id, archivdms_tenant_id, nexarch_tenant_id) mit Pflicht-Freigabe durch einen Menschen je Zusammenführung, bevor sie für nachgelagerte Migrationsschritte nutzbar wird.
|
||||
|
||||
**Technische Grundlage:** Freigabe-Oberfläche, tenant_migration_map-Tabelle
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein automatischer Merge ohne Mensch – eine falsche Tenant-Zusammenführung ist ein Compliance-Vorfall, keine Bagatelle.
|
||||
|
||||
**Übernehmen:**
|
||||
- Slug/Domain-Matching mit gepflegter Kunden-Zuordnungsliste als Fallback statt reinem Freitext-Matching.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Automatisches Zusammenführen von Tenants oder Benutzern ohne schriftliche menschliche Freigabe je Fall.
|
||||
|
||||
**Für genau diese Kachel:** Diese Tabelle ist die feste Referenz, die JEDE weitere Migrationsstufe zum Umschreiben von tenant_id-Fremdschlüsseln verwendet.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAP-01` Tenant-Export & Slug/Domain-Abgleich – Export der tenants-Tabellen aus archivmail und archivdms (slug, name, Domain) und automatischer Abgleichsvorschlag per Slug-/Domain-Matching, ergänzt um eine manuell gepflegte Kunden-Zuordnungsliste als Fallback-Quelle.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede Zusammenführung erfordert eine explizite, protokollierte menschliche Freigabe
|
||||
2. Ohne Freigabe bleibt ein Tenant als unbestätigt markiert und wird von nachgelagerten Schritten nicht verarbeitet
|
||||
3. Freigegebene Map ist die einzige Quelle, die andere Migrationsschritte für tenant_id-Umschreibung verwenden
|
||||
|
||||
## 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. Zusammenführung ohne Freigabe wird von einem Testlauf nachweislich zurückgewiesen
|
||||
2. Freigabe-Protokoll enthält Zeitpunkt und freigebende Person
|
||||
3. Nachträgliche Korrektur einer bereits freigegebenen Zuordnung ist möglich und wird protokolliert
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
Ohne Freigabepflicht könnte eine falsche automatische Zusammenführung zwei Kunden' Daten sichtbar vermischen – ein Compliance-Vorfall, kein Bagatellfehler.
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Pflege der Kunden-Zuordnungsliste selbst – das ist Aufgabe der Geschäftsseite, nicht dieser Kachel (siehe Offene Punkte im Migrationskonzept).
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,54 @@
|
||||
# MAP-03 – User-Export & E-Mail-Abgleich innerhalb Tenant
|
||||
|
||||
**Epic:** 🔗 Tenant- & User-Mapping | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 3
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Export der users-Tabellen aus beiden Altsystemen und Abgleich per E-Mail-Adresse innerhalb desselben bereits zusammengeführten Tenants – ein Mensch kann in beiden Systemen mit derselben E-Mail, aber unterschiedlicher user_id existieren.
|
||||
|
||||
**Technische Grundlage:** SQL-Export users-Tabellen, E-Mail-Abgleichsskript je Tenant
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein automatischer Merge ohne Mensch – eine falsche Tenant-Zusammenführung ist ein Compliance-Vorfall, keine Bagatelle.
|
||||
|
||||
**Übernehmen:**
|
||||
- Slug/Domain-Matching mit gepflegter Kunden-Zuordnungsliste als Fallback statt reinem Freitext-Matching.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Automatisches Zusammenführen von Tenants oder Benutzern ohne schriftliche menschliche Freigabe je Fall.
|
||||
|
||||
**Für genau diese Kachel:** Gleiches Prinzip wie MAP-01, eine Ebene tiefer – Benutzer statt Tenant.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAP-02` Tenant-Migration-Map & Freigabe-Workflow – Referenztabelle tenant_migration_map (archivmail_tenant_id, archivdms_tenant_id, nexarch_tenant_id) mit Pflicht-Freigabe durch einen Menschen je Zusammenführung, bevor sie für nachgelagerte Migrationsschritte nutzbar wird.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Beide users-Tabellen vollständig exportiert
|
||||
2. Abgleich erfolgt ausschließlich innerhalb eines bereits freigegebenen Tenants, nicht global
|
||||
3. E-Mail-Duplikate über Tenant-Grenzen hinweg werden nicht automatisch zusammengeführt
|
||||
|
||||
## 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-Vollständigkeit gegen Quelltabellen-Zeilenzahl geprüft
|
||||
2. Stichprobe bekannter Doppel-Accounts korrekt erkannt
|
||||
3. Zwei unterschiedliche Tenants mit identischer E-Mail-Adresse bleiben getrennt
|
||||
|
||||
## Nicht Bestandteil dieser Kachel
|
||||
Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor:
|
||||
- Freigabe der Zusammenführung selbst (siehe MAP-04).
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,50 @@
|
||||
# MAP-04 – User-Migration-Map & Freigabe-Workflow
|
||||
|
||||
**Epic:** 🔗 Tenant- & User-Mapping | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 4
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Referenztabelle user_migration_map (archivmail_user_id, archivdms_user_id, nexarch_user_id) mit derselben Pflicht-Freigabe wie bei Tenants, bevor sie für die Core-Benutzer-Migration nutzbar wird.
|
||||
|
||||
**Technische Grundlage:** Freigabe-Oberfläche, user_migration_map-Tabelle
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein automatischer Merge ohne Mensch – eine falsche Tenant-Zusammenführung ist ein Compliance-Vorfall, keine Bagatelle.
|
||||
|
||||
**Übernehmen:**
|
||||
- Slug/Domain-Matching mit gepflegter Kunden-Zuordnungsliste als Fallback statt reinem Freitext-Matching.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Automatisches Zusammenführen von Tenants oder Benutzern ohne schriftliche menschliche Freigabe je Fall.
|
||||
|
||||
**Für genau diese Kachel:** Schließt die Identitätsauflösung ab, auf der die gesamte weitere Migration aufbaut.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `MAP-03` User-Export & E-Mail-Abgleich innerhalb Tenant – Export der users-Tabellen aus beiden Altsystemen und Abgleich per E-Mail-Adresse innerhalb desselben bereits zusammengeführten Tenants – ein Mensch kann in beiden Systemen mit derselben E-Mail, aber unterschiedlicher user_id existieren.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede Benutzer-Zusammenführung erfordert eine explizite, protokollierte menschliche Freigabe
|
||||
2. Ohne Freigabe bleibt ein Benutzer als zwei getrennte Konten migrierbar, statt fälschlich zusammengeführt zu werden
|
||||
3. Freigegebene Map ist die einzige Quelle für die Core-Benutzer-Migration (COR-02)
|
||||
|
||||
## 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. Zusammenführung ohne Freigabe wird von einem Testlauf nachweislich zurückgewiesen
|
||||
2. Freigabe-Protokoll enthält Zeitpunkt und freigebende Person
|
||||
3. Stichprobe von 10 freigegebenen Zuordnungen gegen Quelle geprüft
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# ROL-01 – Rollback-Kriterien definieren
|
||||
|
||||
**Epic:** ⏪ Rollback | **Rolle:** Backend | **Komplexität:** Einfach | **Aufwand:** 1 Personentage | **Welle:** 10
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Klare, vorab festgelegte Kriterien für eine Rollback-Entscheidung (z. B. Verifikation aus VAL-01 bis VAL-05 schlägt für mehr als X % der Tenants fehl), statt Einzelfallentscheidung unter Zeitdruck am Stichtag selbst.
|
||||
|
||||
**Technische Grundlage:** Dokumentierte, vorab festgelegte Rollback-Schwellenwerte
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Rollback ist ein vorher festgelegter Pfad, keine Einzelfallentscheidung unter Zeitdruck am Stichtag.
|
||||
|
||||
**Übernehmen:**
|
||||
- Altsysteme bleiben am Stichtag im Wartungsmodus erhalten, nicht gelöscht.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Rollback-Entscheidung ad hoc – klare, vorab festgelegte Kriterien (z. B. Verifikations-Fehlerquote).
|
||||
|
||||
**Für genau diese Kachel:** Rollback-Entscheidungen unter Zeitdruck am echten Stichtag sind der riskanteste Zeitpunkt für Fehlentscheidungen – deshalb vorab festlegen.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `CUT-02` Trockenlauf 2 – Generalprobe – Vollständiger Migrationslauf gegen eine reale, aktuelle Kopie beider Produktivdatenbanken in einer isolierten NEXARCH-Testumgebung; Ergebnis wird stichprobenartig gegen die Quelle geprüft (Dokument-/Mail-Anzahl je Tenant, Volltextvergleich, Retention-Fristen-Abgleich).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Rollback-Schwellenwerte sind schriftlich dokumentiert und vor dem Stichtag freigegeben
|
||||
2. Kriterien sind messbar, nicht subjektiv formuliert
|
||||
|
||||
## 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. Kriterien-Dokument liegt vor Stichtag-Termin vor
|
||||
2. Kriterien wurden gegen das Ergebnis der Generalprobe (CUT-02) durchgerechnet
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,50 @@
|
||||
# ROL-02 – Rollback-Testlauf
|
||||
|
||||
**Epic:** ⏪ Rollback | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 11
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Testlauf des Rollback-Pfads in der isolierten Testumgebung: Wartungsmodus des Altsystems aufheben, NEXARCH-Freischaltung zurücknehmen – Altsysteme werden am Stichtag nicht gelöscht, nur in Wartungsmodus versetzt, Rollback bedeutet diesen Zustand rückgängig zu machen.
|
||||
|
||||
**Technische Grundlage:** Simulierter Rollback: Wartungsmodus aufheben, Freischaltung zurücknehmen
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Rollback ist ein vorher festgelegter Pfad, keine Einzelfallentscheidung unter Zeitdruck am Stichtag.
|
||||
|
||||
**Übernehmen:**
|
||||
- Altsysteme bleiben am Stichtag im Wartungsmodus erhalten, nicht gelöscht.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Rollback-Entscheidung ad hoc – klare, vorab festgelegte Kriterien (z. B. Verifikations-Fehlerquote).
|
||||
|
||||
**Für genau diese Kachel:** Rollback ist ein vorher festgelegter Pfad, keine Einzelfallentscheidung unter Zeitdruck am Stichtag.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `ROL-01` Rollback-Kriterien definieren – Klare, vorab festgelegte Kriterien für eine Rollback-Entscheidung (z. B. Verifikation aus VAL-01 bis VAL-05 schlägt für mehr als X % der Tenants fehl), statt Einzelfallentscheidung unter Zeitdruck am Stichtag selbst.
|
||||
- `CUT-02` Trockenlauf 2 – Generalprobe – Vollständiger Migrationslauf gegen eine reale, aktuelle Kopie beider Produktivdatenbanken in einer isolierten NEXARCH-Testumgebung; Ergebnis wird stichprobenartig gegen die Quelle geprüft (Dokument-/Mail-Anzahl je Tenant, Volltextvergleich, Retention-Fristen-Abgleich).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Rollback-Pfad ist in der Testumgebung erfolgreich durchgespielt worden
|
||||
2. Nach simuliertem Rollback ist das Altsystem wieder vollständig nutzbar
|
||||
3. Dauer des Rollback-Vorgangs ist gemessen und dokumentiert
|
||||
|
||||
## 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 Rollback in Testumgebung erfolgreich abgeschlossen
|
||||
2. Nach Rollback ist kein Datenverlust im Altsystem feststellbar
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,53 @@
|
||||
# TAR-01 – Retention-Fristen-Migration ohne Reset
|
||||
|
||||
**Epic:** ⏳ Archive-Migration | **Rolle:** Backend | **Komplexität:** Hoch | **Aufwand:** 4 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Das retain_until-Feld auf Kernobjekten aus beiden Altsystemen wird exakt 1:1 in das generische Retention-Objektmodell (Archive RET-01) übernommen – Fristen dürfen beim Umzug unter keinen Umständen zurückgesetzt oder neu berechnet werden.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Archive RET-01, exakte 1:1-Übernahme von retain_until
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Aufbewahrungsfristen dürfen beim Umzug unter keinen Umständen zurückgesetzt werden – GoBD-Kontinuität ist nicht verhandelbar.
|
||||
|
||||
**Übernehmen:**
|
||||
- `retain_until`-Werte exakt 1:1 übernehmen, keine Neuberechnung.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine stille Neuberechnung von Fristen anhand des Migrationsdatums.
|
||||
|
||||
**Für genau diese Kachel:** Wichtigster Einzelschritt der gesamten Migration für GoBD-Kontinuität – ein Fehler hier ist ein direkter Compliance-Bruch.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOK-01` Dokument- & Revisions-Migration – Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
- `MAI-02` Nachrichten- & Anhang-Migration – Übernahme aller Nachrichten und Anhänge (email_refs) aus archivmail nach Mail ARC-01/ARC-04: Binärdaten per Objekt-Storage-Kopie, Referenzen per SQL-Export/Import; das indexed_at-Statusfeld wird verworfen, da der Suchindex komplett neu aufgebaut wird (siehe CUT-05).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jedes Objekt mit retain_until in der Quelle hat nach der Migration exakt dieselbe Frist
|
||||
2. Kein Objekt erhält durch die Migration eine neue, vom Migrationsdatum abhängige Frist
|
||||
3. Objekte ohne Frist in der Quelle bleiben nach der Migration ohne Frist
|
||||
|
||||
## 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. Stichprobe von 50 Objekten mit Frist in der Zukunft: Frist vor/nach Migration exakt identisch (siehe auch VAL-03)
|
||||
2. Migrationsskript enthält keine Berechnung, die das aktuelle Datum als Ausgangspunkt nutzt
|
||||
|
||||
## Bekannte Fehler vermeiden
|
||||
Ursprünglich war erwogen worden, Fristen beim Umzug neu zu berechnen, um Datenmodell-Unterschiede zu glätten – verworfen, da genau das einen GoBD-Bruch bedeutet hätte.
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# TAR-02 – Vier-Augen-Löschworkflow-Migration
|
||||
|
||||
**Epic:** ⏳ Archive-Migration | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 7
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Offene Löschanfragen aus document_delete_requests (nur archivdms) werden nach Archive CMP-06 migriert; bereits vollzogene Löschungen bleiben nur als Audit-Eintrag bestehen, da das Objekt selbst nicht mehr existiert.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Archive CMP-06
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Aufbewahrungsfristen dürfen beim Umzug unter keinen Umständen zurückgesetzt werden – GoBD-Kontinuität ist nicht verhandelbar.
|
||||
|
||||
**Übernehmen:**
|
||||
- `retain_until`-Werte exakt 1:1 übernehmen, keine Neuberechnung.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine stille Neuberechnung von Fristen anhand des Migrationsdatums.
|
||||
|
||||
**Für genau diese Kachel:** Aufbewahrungsfristen dürfen beim Umzug unter keinen Umständen zurückgesetzt werden – GoBD-Kontinuität ist nicht verhandelbar.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `TAR-01` Retention-Fristen-Migration ohne Reset – Das retain_until-Feld auf Kernobjekten aus beiden Altsystemen wird exakt 1:1 in das generische Retention-Objektmodell (Archive RET-01) übernommen – Fristen dürfen beim Umzug unter keinen Umständen zurückgesetzt oder neu berechnet werden.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jede offene Löschanfrage ist nach der Migration als aktiver Vorgang im Vier-Augen-Workflow vorhanden
|
||||
2. Bereits vollzogene Löschungen sind ausschließlich als Audit-Eintrag 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. Zeilenzahl offener Löschanfragen nach Migration deckungsgleich mit Quelle
|
||||
2. Stichprobe vollzogener Löschungen als Audit-Eintrag auffindbar, kein Objekt-Datensatz vorhanden
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,50 @@
|
||||
# VAL-01 – Zeilenzahl-Abgleich je Kerntabelle
|
||||
|
||||
**Epic:** 🔍 Verifikation | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Automatisierter Abgleich der Zeilenzahl je migrierter Kerntabelle (Dokumente, Mails, Benutzer) alt vs. neu, je Tenant, abzüglich bewusst nicht migrierter Kategorien.
|
||||
|
||||
**Technische Grundlage:** Automatisiertes Zählskript je Tenant und Kerntabelle
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Stichprobenweiser Hash-Vergleich und Zeilenzahl-Abgleich je Kerntabelle als Mindeststandard.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freischaltung eines Tenants ohne abgeschlossene Verifikation aus reiner Zeitnot.
|
||||
|
||||
**Für genau diese Kachel:** Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-02` Benutzer-Migration inkl. Passwort-Hashes – Übernahme der zusammengeführten Benutzerdatensätze in Core IAM-01 unter Nutzung der User-Map; bcrypt-Passwort-Hashes werden 1:1 übernommen, kein Rehash nötig, da dasselbe Hash-Verfahren in beiden Altsystemen verwendet wird.
|
||||
- `DOK-01` Dokument- & Revisions-Migration – Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
- `MAI-02` Nachrichten- & Anhang-Migration – Übernahme aller Nachrichten und Anhänge (email_refs) aus archivmail nach Mail ARC-01/ARC-04: Binärdaten per Objekt-Storage-Kopie, Referenzen per SQL-Export/Import; das indexed_at-Statusfeld wird verworfen, da der Suchindex komplett neu aufgebaut wird (siehe CUT-05).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Für jeden Tenant liegt ein Zeilenzahl-Bericht je Kerntabelle vor
|
||||
2. Abweichungen sind entweder erklärt (bewusst nicht migrierte Kategorie) oder als offener Befund markiert
|
||||
|
||||
## 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. Bericht für mindestens 3 Test-Tenants erfolgreich erzeugt
|
||||
2. Absichtlich eingefügte Testabweichung wird vom Skript erkannt
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,49 @@
|
||||
# VAL-02 – Hash-Vergleich migrierter Binärdateien
|
||||
|
||||
**Epic:** 🔍 Verifikation | **Rolle:** QA | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Stichprobenweiser Hash-Vergleich migrierter Binärdateien (Dokumente, Mail-Anhänge) im Objekt-Storage gegen die Quelle, um bitgenaue Übernahme nachzuweisen.
|
||||
|
||||
**Technische Grundlage:** Stichprobenweiser Hash-Vergleich Objekt-Storage vs. Quelle
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Stichprobenweiser Hash-Vergleich und Zeilenzahl-Abgleich je Kerntabelle als Mindeststandard.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freischaltung eines Tenants ohne abgeschlossene Verifikation aus reiner Zeitnot.
|
||||
|
||||
**Für genau diese Kachel:** Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `DOK-01` Dokument- & Revisions-Migration – Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
- `MAI-02` Nachrichten- & Anhang-Migration – Übernahme aller Nachrichten und Anhänge (email_refs) aus archivmail nach Mail ARC-01/ARC-04: Binärdaten per Objekt-Storage-Kopie, Referenzen per SQL-Export/Import; das indexed_at-Statusfeld wird verworfen, da der Suchindex komplett neu aufgebaut wird (siehe CUT-05).
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Für eine repräsentative Stichprobe je Tenant liegt ein Hash-Vergleichsbericht vor
|
||||
2. Jede Abweichung ist nachvollziehbar dokumentiert und vor Freischaltung geklärt
|
||||
|
||||
## 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. Stichprobe von 100 Dateien je Tenant erfolgreich verglichen
|
||||
2. Absichtlich manipulierte Testdatei wird vom Vergleich erkannt
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# VAL-03 – Retention-Fristen-Verifikation
|
||||
|
||||
**Epic:** 🔍 Verifikation | **Rolle:** QA | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 7
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Für eine Stichprobe von Objekten mit retain_until in der Zukunft wird geprüft, dass die Frist nach der Migration exakt identisch mit der Quelle ist.
|
||||
|
||||
**Technische Grundlage:** Stichprobenvergleich retain_until alt vs. neu
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Stichprobenweiser Hash-Vergleich und Zeilenzahl-Abgleich je Kerntabelle als Mindeststandard.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freischaltung eines Tenants ohne abgeschlossene Verifikation aus reiner Zeitnot.
|
||||
|
||||
**Für genau diese Kachel:** Direkte Verifikation des GoBD-kritischsten Migrationsschritts (TAR-01).
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `TAR-01` Retention-Fristen-Migration ohne Reset – Das retain_until-Feld auf Kernobjekten aus beiden Altsystemen wird exakt 1:1 in das generische Retention-Objektmodell (Archive RET-01) übernommen – Fristen dürfen beim Umzug unter keinen Umständen zurückgesetzt oder neu berechnet werden.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Für jeden Tenant liegt ein Prüfbericht über eine repräsentative Fristen-Stichprobe vor
|
||||
2. Jede Abweichung führt automatisch zu einem blockierenden Befund, nicht nur einer Notiz
|
||||
|
||||
## 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. Stichprobe von 50 Objekten je Tenant erfolgreich verglichen
|
||||
2. Absichtlich verschobene Testfrist wird vom Vergleich erkannt
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# VAL-04 – Audit-Log-Kontinuitätsprüfung
|
||||
|
||||
**Epic:** 🔍 Verifikation | **Rolle:** QA | **Komplexität:** Einfach | **Aufwand:** 2 Personentage | **Welle:** 5
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Prüfung, dass ältester und neuester Audit-Log-Eintrag je Tenant nach der Migration mit der Quelle übereinstimmen – keine Lücke, keine Zeitverschiebung.
|
||||
|
||||
**Technische Grundlage:** Ältester/neuester Eintrag je Tenant, Lücken-/Zeitverschiebungs-Check
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Stichprobenweiser Hash-Vergleich und Zeilenzahl-Abgleich je Kerntabelle als Mindeststandard.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freischaltung eines Tenants ohne abgeschlossene Verifikation aus reiner Zeitnot.
|
||||
|
||||
**Für genau diese Kachel:** Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-05` Audit-Log-Zusammenführung – Zusammenführen der audit_log-Tabellen beider Altsysteme in Core; beide nutzen dasselbe Append-only-Trigger-Muster, daher rein mechanisch – historische Einträge behalten ihren originalen Zeitstempel, nur tenant_id/user_id werden über die Mapping-Tabellen umgeschrieben.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Für jeden Tenant liegt ein Kontinuitätsbericht vor
|
||||
2. Jede erkannte Lücke oder Zeitverschiebung ist ein blockierender Befund
|
||||
|
||||
## 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. Ältester/neuester Eintrag für 3 Test-Tenants exakt mit Quelle abgeglichen
|
||||
2. Absichtlich entfernter Testeintrag wird als Lücke erkannt
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,48 @@
|
||||
# VAL-05 – Login-Test mit migrierten Zugangsdaten
|
||||
|
||||
**Epic:** 🔍 Verifikation | **Rolle:** QA | **Komplexität:** Einfach | **Aufwand:** 1 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Testerin im Bereich QA und prüfst NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Login-Test mit migrierten Zugangsdaten für eine Stichprobe von Benutzern je Tenant, um die praktische Funktionsfähigkeit der Benutzer-Migration zu bestätigen.
|
||||
|
||||
**Technische Grundlage:** Stichprobenweiser Login-Test gegen migrierte Passwort-Hashes
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
**Übernehmen:**
|
||||
- Stichprobenweiser Hash-Vergleich und Zeilenzahl-Abgleich je Kerntabelle als Mindeststandard.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Freischaltung eines Tenants ohne abgeschlossene Verifikation aus reiner Zeitnot.
|
||||
|
||||
**Für genau diese Kachel:** Kein Tenant wird freigeschaltet, dessen Verifikation nicht schriftlich vorliegt.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-02` Benutzer-Migration inkl. Passwort-Hashes – Übernahme der zusammengeführten Benutzerdatensätze in Core IAM-01 unter Nutzung der User-Map; bcrypt-Passwort-Hashes werden 1:1 übernommen, kein Rehash nötig, da dasselbe Hash-Verfahren in beiden Altsystemen verwendet wird.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Für jeden Tenant ist mindestens ein erfolgreicher Login-Test mit migriertem Konto dokumentiert
|
||||
2. Fehlgeschlagene Logins sind vor Freischaltung des Tenants geklärt
|
||||
|
||||
## 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. Login-Test für 5 Testkonten je Altsystem erfolgreich
|
||||
2. Bewusst falsches Testpasswort wird korrekt abgewiesen
|
||||
|
||||
## Arbeitsweise
|
||||
1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster.
|
||||
2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche.
|
||||
3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test.
|
||||
4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis.
|
||||
5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code.
|
||||
6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen.
|
||||
@@ -0,0 +1,50 @@
|
||||
# WFL-01 – Workflow-Historie-Migration
|
||||
|
||||
**Epic:** 🔀 Workflow-Migration | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 6
|
||||
|
||||
---
|
||||
|
||||
## Rolle
|
||||
Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Migration (einmaliges Big-Bang-Migrationsprojekt: Überführung der beiden produktiven Altsysteme archivmail und archivdms in die sieben NEXARCH-2.0-Module Core, DMS, Mail, Archive und Workflow zu einem gemeinsamen Stichtag), das sich strikt an MIGRATIONSKONZEPT.md hält – Tenant-Identitätsauflösung vor allem anderen, keine automatischen Zusammenführungen ohne menschliche Freigabe, GoBD-Aufbewahrungsfristen dürfen beim Umzug nicht zurückgesetzt werden.
|
||||
Go-Migrationsskripte (net/http, pgx/v5, PostgreSQL, kein ORM) gegen Export-Dumps beider Altsysteme, Objekt-Storage-Kopie für Binärdaten, kein Rehash/Re-Encoding wo Quelle bereits kompatibel ist.
|
||||
Migrationslogik und Datenübernahme. Keine Änderung der Zielsystem-Fachlogik selbst – die entsteht in den jeweiligen Modul-Boards.
|
||||
|
||||
## Auftrag
|
||||
Abgeschlossene Workflows/Automatisierungen aus archivdms werden als Historie nach Workflow ENG-01/RTE-01 übernommen; laufende Workflow-Instanzen werden NICHT migriert – sie müssen vor dem Stichtag im Altsystem bewusst zu Ende geführt oder abgebrochen werden.
|
||||
|
||||
**Technische Grundlage:** SQL-Migration gegen Workflow ENG-01/RTE-01, nur abgeschlossene Vorgänge
|
||||
|
||||
## Produkt-DNA für diesen Bereich
|
||||
> Nur abgeschlossene Historie wandert; ein laufender Workflow wird vor dem Stichtag zu Ende geführt, nicht halb migriert.
|
||||
|
||||
**Übernehmen:**
|
||||
- Abgeschlossene Vorgänge als Historieneintrag übernehmen.
|
||||
|
||||
**Bewusst vermeiden:**
|
||||
- Keine Übernahme laufender Workflow-Instanzen in eine board-fremde Zustandsmaschine.
|
||||
|
||||
**Für genau diese Kachel:** Die Workflow-Zustandsmaschine ist im neuen Board-Modell strukturell neu – ein Import laufender Instanzen wäre technisch nicht sauber abbildbar.
|
||||
|
||||
## Ausgangslage
|
||||
Die folgenden Arbeitspakete sind bereits fertiggestellt und dürfen vorausgesetzt werden. Baue auf ihnen auf, statt Funktionalität zu duplizieren:
|
||||
- `COR-02` Benutzer-Migration inkl. Passwort-Hashes – Übernahme der zusammengeführten Benutzerdatensätze in Core IAM-01 unter Nutzung der User-Map; bcrypt-Passwort-Hashes werden 1:1 übernommen, kein Rehash nötig, da dasselbe Hash-Verfahren in beiden Altsystemen verwendet wird.
|
||||
- `DOK-01` Dokument- & Revisions-Migration – Übernahme aller Dokumente und Datei-Revisionen aus archivdms: Binärdaten per Objekt-Storage-Kopie, zugehörige Metadaten per SQL-Export/Import, konsequent unter der migrierten Tenant-Zuordnung.
|
||||
|
||||
## Akzeptanzkriterien
|
||||
Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind:
|
||||
1. Jeder abgeschlossene Workflow-Vorgang ist nach der Migration als Historieneintrag auffindbar
|
||||
2. Keine laufende Workflow-Instanz wird in einem halb migrierten Zustand übernommen
|
||||
3. Liste offener Instanzen zum Stichtag ist vor dem Cutover vollständig abgearbeitet oder bewusst abgebrochen
|
||||
|
||||
## 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. Zeilenzahl abgeschlossener Vorgänge nach Migration deckungsgleich mit Quelle
|
||||
2. Zum geplanten Stichtag-Zeitpunkt sind keine offenen Instanzen in der Processing-Queue des Altsystems mehr vorhanden
|
||||
|
||||
## 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.
|
||||
Reference in new issue
Block a user