feat(xrechnung): govern validation profile selection

src/govoplan_xrechnung/backend/manifest.py

@@ -16,7 +16,7 @@ from govoplan_core.core.provider_governance import declared_module_architecture
 
 
 MODULE_ID = "xrechnung"
-MODULE_VERSION = "0.1.19"
+MODULE_VERSION = "0.1.20"
 READ_SCOPE = "xrechnung:validation:read"
 EXECUTE_SCOPE = "xrechnung:validation:execute"
 HANDOFF_SCOPE = "xrechnung:handoff:create"
@@ -71,7 +71,7 @@ manifest = ModuleManifest(
             title="Validate and hand off an inbound XRechnung",
             summary="Verify safe invoice XML with an exact locally pinned KoSIT engine and rule tree, then create a digest-bound handoff only from complete valid evidence.",
             body=(
-                "An administrator must approve an exact XRechnung version, KoSIT validator release, configuration release, configuration-tree digest, engine digest, scenario file, and minimum validation-step count. The connector verifies those artifacts before each run and never downloads rules while processing an invoice. It rejects dangerous XML before invoking Java. Runner exit, bounded output, technical error markers, VARL identity, matched scenario, configured validation-step count, validity flag, and exactly one accept or reject assessment are checked independently. Technical failure or partial reports yield unknown conformance and can never be handed off. A valid handoff binds tenant, source reference, invoice digest, report digest, and profile digest for an owning Procurement or Payments workflow."
+                "An administrator must approve an exact XRechnung version, KoSIT validator release, configuration release, configuration-tree digest, engine digest, scenario file, and minimum validation-step count. A deployment-owned allow-list records approval identity, decision reference, receive-time window, suspension or retirement state, and an optional explicit default; GovOPlaN selects no version itself. The connector verifies those artifacts before each run and never downloads rules while processing an invoice. It rejects dangerous XML before invoking Java. Runner exit, bounded output, technical error markers, VARL identity, matched scenario, configured validation-step count, validity flag, and exactly one accept or reject assessment are checked independently. Technical failure or partial reports yield unknown conformance and can never be handed off. A valid handoff binds tenant, source reference, invoice digest, report digest, and profile digest for an owning Procurement or Payments workflow."
             ),
             layer="configured",
             documentation_types=("admin", "user"),
@@ -93,7 +93,7 @@ manifest = ModuleManifest(
                 "de": {
                     "title": "Eingehende XRechnung prüfen und übergeben",
                     "summary": "Sicheres Rechnungs-XML mit exakt lokal festgelegter KoSIT-Engine und Regelstruktur prüfen und nur aus vollständigem gültigem Nachweis eine prüfsummengebundene Übergabe erzeugen.",
-                    "body": "Administrierende müssen eine exakte XRechnungs-Version, KoSIT-Validator-Version, Konfigurationsversion, Prüfsumme der Konfigurationsstruktur, Engine-Prüfsumme, Szenariodatei und Mindestzahl der Prüfschritte freigeben. Der Konnektor prüft diese Artefakte vor jedem Lauf und lädt während der Rechnungsverarbeitung keine Regeln herunter. Gefährliches XML wird vor dem Java-Aufruf abgewiesen. Prozessende, begrenzte Ausgabe, technische Fehlermarker, VARL-Identität, erkanntes Szenario, konfigurierte Prüfschrittzahl, Gültigkeitskennzeichen und genau eine Annahme- oder Ablehnungsempfehlung werden unabhängig geprüft. Technische Fehler oder Teilberichte ergeben unbekannte Konformität und dürfen niemals übergeben werden. Eine gültige Übergabe bindet Mandant, Quellreferenz, Rechnungsprüfsumme, Berichtsprüfsumme und Profilprüfsumme für einen fachlich verantwortlichen Procurement- oder Payments-Ablauf.",
+                    "body": "Administrierende müssen eine exakte XRechnungs-Version, KoSIT-Validator-Version, Konfigurationsversion, Prüfsumme der Konfigurationsstruktur, Engine-Prüfsumme, Szenariodatei und Mindestzahl der Prüfschritte freigeben. Eine installationsbezogene Positivliste erfasst Freigabestelle, Entscheidungsreferenz, Eingangszeitfenster, Sperrung oder Ausmusterung und einen optional ausdrücklich gesetzten Standard; GovOPlaN wählt selbst keine Version. Der Konnektor prüft die Artefakte vor jedem Lauf und lädt während der Rechnungsverarbeitung keine Regeln herunter. Gefährliches XML wird vor dem Java-Aufruf abgewiesen. Prozessende, begrenzte Ausgabe, technische Fehlermarker, VARL-Identität, erkanntes Szenario, konfigurierte Prüfschrittzahl, Gültigkeitskennzeichen und genau eine Annahme- oder Ablehnungsempfehlung werden unabhängig geprüft. Technische Fehler oder Teilberichte ergeben unbekannte Konformität und dürfen niemals übergeben werden. Eine gültige Übergabe bindet Mandant, Quellreferenz, Rechnungsprüfsumme, Berichtsprüfsumme und Profilprüfsumme für einen fachlich verantwortlichen Procurement- oder Payments-Ablauf.",
                 }
             },
             metadata={
@@ -101,10 +101,12 @@ manifest = ModuleManifest(
                 "prerequisites": [
                     "An exact KoSIT engine and self-contained XRechnung configuration have been installed locally.",
                     "The administrator has approved all artifact digests and the expected validation-step count.",
+                    "The profile is approved for the invoice receive time in the deployment allow-list.",
                     "The owning invoice workflow supplies a stable tenant and source reference.",
                 ],
                 "steps": [
                     "Verify the executable, engine digest, complete configuration-tree digest, and scenario location.",
+                    "Select an explicit allow-listed profile or the deployment's explicitly configured default.",
                     "Reject unsafe or oversized XML, then run the pinned profile with bounded time and output.",
                     "Check technical completeness separately from the report's semantic validity.",
                     "Create a handoff only when the report is complete, formally valid, and accepts the invoice.",