odoo-at-payroll/personalverrechnung/wissensbasis

Wissensbasis „Lexis Briefings Personalrecht" (Lexis360-Exporte)

Kuratierte Wissensbasis aus den LexisNexis-Briefings des Werks Lexis Briefings Personalrecht (Export aus Lexis 360). Zweck:

1. Entwicklungsreferenz neben personalverrechnung/RECHTSQUELLEN-*.md für die Personalverrechnungsmodule (l10n_at_hr_payroll*), und
2. Copilot-Korpus: Aufbau und Frontmatter sind retrieval-gerecht (stabile IDs, maschinenlesbares kb.json), damit künftig ein Frage-Antwort-Copilot darauf aufbauen kann.

Schichten (Lizenz-Entscheidung D1, 2026-09-10)

Schicht	Pfad	Versioniert?	Inhalt
PDF-Exporte	.lexis360/Lexis360_*.pdf	nein (gitignored)	lizensierte Original-PDFs
Layer 1 — Volltexte	.lexis360/md/<slug>.md	nein (gitignored)	vollständiger Extraktionstext + Metadaten-Frontmatter
Katalog	.lexis360/md/_catalog.json	nein (gitignored)	geparste Metadaten aller Quellen (Slug ↔ ID ↔ Stand ↔ Cluster)
Layer 2 — kuratierte Einträge	personalverrechnung/wissensbasis/dokumente/<slug>.md	ja	Kuratierung in eigenen Worten (Schema unten)
Registry	personalverrechnung/wissensbasis/kb.json	ja	generiert aus dem Layer-2-Frontmatter (--registry)

Volltexte sind lizenzierter Inhalt (LexisNexis-Abonnement) und bleiben wie .firecrawl/ lokal + unversioniert. Nur die Kuratierung (eigene Worte, kurze Zitate mit Quellenachweis) wird committet.

Frontmatter-Schema (Layer 2 — verbindlich)

id: lb-atz-07                 # stabil, lb-<cluster>-<nn>, eingefroren
batch: 1                      # Beschaffungs-Batch (manuell je Import)
title: "Altersteilzeit - Überblick"
work: "Lexis Briefings Personalrecht"
chapter: "Beschäftigungsverhältnisse"   # Breadcrumb-Kapitel der Quelle
topic: altersteilzeit          # ASCII-Cluster-Slug (s. Tabelle)
author: "Marek"
stand: 2026-01                 # ISO-Monat des Quell-Stands
source:
  pdf: ".lexis360/Lexis360_altersteilzeit_uberblick.pdf"
  text: ".lexis360/md/altersteilzeit_uberblick.md"
legal_bases: ["AlVG", "AZG § 19e"]      # nur im Quelltext genannte Normen
tags: [altersteilzeit, ams-foerderung]  # ASCII-Slugs, retrieval-freundlich
cross_refs: ["lb-atz-09"]     # verwandte KB-Einträge (dangling = Fehler)

Schlüsselkonvention (Entscheidung D2): strukturelle Schlüssel englisch (konsistent mit kv-catalog.json/chambers.json), Werte deutsch (UTF-8, Umlaute erlaubt). Zwei Ausnahmen: stand (österreichischer Fachbegriff, ISO-Wert YYYY-MM) und topic/tags als ASCII-Slugs. Die Frontmatter ist Single Source of Truth; kb.json wird daraus generiert und schema-validiert (build_lexis_kb.py --registry).

Cluster (Batch 1)

topic-Slug	Name	ID-Präfix	IDs	n
altersteilzeit	Altersteilzeit	atz	lb-atz-01 … 15	15
lehrlinge	Lehrverhältnis / Lehrlinge	leh	lb-leh-01 … 15	15
jugendliche	Jugendarbeit / Jugendschutz	jug	lb-jug-01 … 07	7
ferialpraktikanten	Ferialpraktikanten, Volontäre, Au-pair	pra	lb-pra-01 … 04	4
beschaftigungsformen	Beschäftigungsformen & Abgrenzung	bes	lb-bes-01 … 08	8
teilzeit	Teilzeit & Bildungsteilzeit	tzb	lb-tzb-01 … 06	6

Frontmatter-topic = beschreibender ASCII-Slug (linke Spalte), das ID-Präfix (atz, leh, …) nur im id selbst; das Tool prüft die Konsistenz beider (--registry). Neue Cluster erweitern TOPIC_TO_PREFIX/CLUSTERS im Tool.

IDs werden beim ersten --extract vergeben und danach eingefroren (load_previous_ids()); neue Dokumente hängen hinten an, Nummern ausscheidender Dokumente werden nie wiederverwendet. Dateiname eines Layer-2-Eintrags = Layer-1-Slug (Lexis-Export-Stil: Umlaute fallen, werden nicht transliteriert — uberblick, beschaftigung).

Kurationskonventionen (verbindlich)

1. Sprache: deutsch, Fachsprache wie im Original; Metadaten-Werte UTF-8. topic/tags ASCII.
2. Eigene Worte: Kuratierung ist keine Volltextkopie (Lizenz!). Wörtliche Zitate nur kurz und mit Stand gekennzeichnet.
3. Werte immer mit Stand. Stammt der Wert aus einem Briefing mit älterem Stand (z. B. Lehrlinge 2024-03, 2025-08), so ist „(Stand YYYY-MM)" am Wert zu führen. Niemals Werte aus Trainingswissen ergänzen — nur aus dem Quelltext oder aus Batch-1-Dokumenten mit neuerem Stand (dann mit ID belegt).
4. Statusmarken wie in RECHTSQUELLEN: ✅ verifiziert · ⚠ plausibel, Detailverifikation offen · ❓ bewusst offen. §-Zitate nur, wenn die Quelle sie nennt; sonst ⚠ mit Verifikationshinweis (RIS).
5. Dokumentstruktur: # <Titel> → Quellzeile (Werk, Autor, Stand, ID) → ## Zusammenfassung → ## Kernwerte & Fristen (Stand YYYY-MM) (Tabelle) → ## Rechtsgrundlagen → ## Payroll-Relevanz (Odoo) → ## Verweise.
6. Payroll-Relevanz benennt Odoo-19-Anknüpfungspunkte (hr_payroll-Engine, Work Entries, hr.rule.parameter, SV-BG-Handling, Meldewesen) als Hinweise für die Umsetzung, nicht als Spec.
7. Verweise: KB-IDs verwandter Briefings (Breadcrumb-Verweise der Quelle beachten) + Projektdateien (RECHTSQUELLEN-*.md).
8. Export-Artefakte ignorieren: Footer „Page n", „Erstellt von …", abgeschnittene Querverweise nicht rekonstruieren; vermerken, wenn eine Verweisstelle im Export unvollständig ist.
9. Vorbild/Qualitätsmaßstab: dokumente/altersteilzeit_uberblick.md.

Update-Zyklus (neue Lexis360-Batches)

1. Neue PDFs nach .lexis360/ kopieren (Export-Namenskonvention Lexis360_<slug>.pdf beibehalten).
2. In tools/build_lexis_kb.py die Konstante BATCH hochsetzen, dann --extract ausführen: Layer 1 + Katalog neu; bestehende IDs bleiben fix, neue Dokumente erhalten neue IDs + neue Batch-Nummer.
3. Neue Layer-2-Einträge kuratieren (Konventionen oben).
4. --registry (generiert/validiert kb.json), danach --check (Layer-1↔Layer-2-Vollständigkeit, Quelldateien vorhanden).
5. INDEX.md aktualisieren, personalverrechnung/RUNBOOK.md und .agents/MEMORY.md pflegen.

Copilot-Konsum

kb.json listet jeden Eintrag mit ID, Titel, Stand, Cluster, Rechtsgrundlagen, Tags und Pfaden auf Layer 1/Layer 2. Für Retrieval/Skills: Eintrag = Chunk-Einheit; id als Zitatchlüssel; stand für Aktualitätsfilter; cross_refs für Graph-Nachbarschaft. Die Volltexte (Layer 1) sind lokal vorhanden, aber nicht Teil des Versionskontroll-Korpus — ein Copilot-Deployment braucht daher einen separaten, lizenzkonformen Bereitstellungspfad für Layer 1 (❓ offen).