LICENSE enthielt bisher nur einen kurzen Erklaerungstext zur Doppellizenz,
weshalb GitHub-Linguist die Datei als 'Unknown' eingestuft hat. LICENSE
ist jetzt identisch mit LICENSE-APACHE (voller Apache-2.0-Lizenztext).
LICENSE-APACHE und LICENSE-MIT bleiben fuer die Doppellizenz erhalten;
die Erklaerung dazu steht in README.md (Abschnitt Lizenz) und NOTICE.
- Alle 132 plugin.json + marketplace.json (outer und alle 132 Plugin-Eintraege)
einheitlich auf 62.0.0.
- Doku-Stand-Marker angeglichen: README.md, SKILLS.md, ASSET_INDEX.md
(war auf v61.2.0) und testakten/README.md (war auf v61.2.1).
- CHANGELOG-Eintrag fuer v62.0.0 ergaenzt.
Inhaltlich identisch mit v61.2.2; signalisiert Abschluss der v61-Reihe.
Externer Beitrag von @Devdorado: 18 Plugin-Manifeste bekommen die im Root-README ohnehin erklaerte Doppellizenz Apache-2.0 OR MIT explizit ins plugin.json. Inhaltlich keine Aenderung; macht die Lizenzangabe pro Plugin sichtbar (relevant fuer Einzelinstallation/Fork). Beamtenrecht v61.1.1 wird damit mitabgedeckt.
* feat(testakten): neue Akte gesellschaftsgruender KI/Krypto-Startup Berlin
Drei Gruender wollen ein KI/Krypto-Startup in Berlin gruenden:
NeuroChain Labs. Sie diskutieren per WhatsApp und E-Mail UG vs.
GmbH, Musterprotokoll vs. individuelle Satzung, Stammkapital,
Sacheinlage Domain und Repository, Vesting mit Angel-Investor,
Lizenzvertrag, Transparenzregister, Gewerbeanmeldung, MiCAR und
KI-Verordnung sowie die ersten 100 Tage.
Inhalt:
- 14 Aktenstuecke (Markdown) mit WhatsApp-Chat, E-Mails, Workshop-
Protokoll, Termsheet, Notarbriefing, Vergleichstabelle Muster-
protokoll vs. individuelle Satzung, Sacheinlage-Pruefvermerk,
Vesting-Mechanik, Steuerberater-Warnung, Geschaeftsfuehrer-
Bestellung, Transparenzregister, Behoerden-Anmeldungen, MiCAR/
BaFin/KI-VO-Vorabklaerung und 100-Tage-Plan
- 6 E-Mails (.eml) Pfaffenrode/Vermeulen/Jonas/Aylin/Eichbaum/Mira
- 2 CSV-Tabellen (Cap Table, Kostenaufstellung)
- Gesamt-PDF (111 KB, 22 Quelldateien)
- READMEs aktualisiert (testakten/README.md, Plugin-READMEs,
Skills-Index, Sofort-Download-Sections)
Korrektes Deutsch mit Umlauten ae oe ue ss im Inhalt, Slug ASCII.
Validatoren: validate-plugin-structure OK, validate-testakten-
gesamt-pdf OK (141 Testakten), validate-yaml-frontmatter OK.
* fix(readmes): sofort-download-sektion regeneriert nach rebase
- Sofort-Download-Sektion fuer 23 Plugin-READMEs aktualisiert (neue Akte NeuroChain Labs)
- veralteten plugin-testakten-section-Block aus 6 READMEs entfernt
- Validator OK
Bisher haben zwei Generator-Skripte parallel die gleichen Testakten in
jede Plugin-README eingefuegt:
- scripts/inject-plugin-sofort-download-section.py
-> Sektion '## Sofort-Downloads' mit Plugin-ZIP + Akten-Tabelle (PDF+ZIP)
- scripts/inject-plugin-testakten-section.py
-> Sektion '## Demonstrations-Akten' mit derselben Akten-Tabelle (PDF+ZIP)
Ergebnis: 117 von 132 Plugin-READMEs listeten ihre Testakten zweimal
direkt untereinander (z.B. gesellschaftsgruender/README.md).
Konsolidierung:
- Altes Skript scripts/inject-plugin-testakten-section.py entfernt.
- Alle <!-- BEGIN plugin-testakten-section --> Bloecke aus den READMEs entfernt.
- Sofort-Downloads-Sektion regeneriert (idempotent, Marker unveraendert).
Validator: validate-plugin-structure OK.
* fix(testakten): umlaute ae/oe/ue zu ä/ö/ü mit hunspell-validierung
Hunspell-basierter Umlaut-Fixer (de_DE) ersetzt nur dort, wo:
- die Umlaut-Variante ein gueltiges deutsches Wort ist
- das ASCII-Original kein gueltiges Wort ist
- das Token kein bekannter Eigenname ist (Roeschen, Vellbruck,
Bochstaedt, Sauer, Eppendorfer, Pellbach, Tannenberg etc.)
Schutzregionen werden ausgenommen: URLs, Markdown-Links, Inline-Code,
Code-Blöcke, HTML-Kommentare, YAML-Frontmatter (nur Dateianfang),
Dateipfade.
Städtenamen-Korrektur via Hardcoded-Map (Koeln->Köln,
Muenchen->München, Saarbruecken->Saarbrücken etc.).
Stichproben:
- Geschaeftsjahr -> Geschäftsjahr
- Geschaeftsfuehrer -> Geschäftsführer
- Kuenstliche -> Künstliche
- ueber/fuer/zurueck/ermaechtigt/erhoehen etc.
- Roeschen/Vellbruck/Bochstaedt unverändert (Eigennamen)
Slugs (Verzeichnis-/Dateinamen) bleiben ASCII. Markdown-H1-Vorschau-
Zeilen referenzieren weiterhin ASCII-Dateinamen.
Validator: validate-plugin-structure OK.
630 Dateien geändert, ~17.200 Ersetzungen.
* fix(testakten): SHA256-Digest 6d7712ae statt 6d7712ä in WM-DOK-0002
Codex-Reviewer P2 (PR #209): Der Umlaut-Normalisierungs-Lauf hatte das
Hex-Token 'ae' im sha256_kurz-Feld faelschlich zu 'ä' umgewandelt. Da
SHA-256 ein Hex-String ist (nur 0-9 a-f), bricht der Umlaut jede
Hash-/Duplikat-Pruefung. ASCII-Digest wiederhergestellt.
Restliches CSV bleibt unveraendert; alle anderen sha256_kurz-Felder waren
nicht betroffen (mit grep verifiziert).
---------
Co-authored-by: Claude <noreply@anthropic.com>
Drei Stand-Marker (SKILLS.md, README.md, ASSET_INDEX.md) auf v59.0.0 nachgezogen — alle 130 plugin.json sind bereits auf 59.0.0 (Codex PR #201), aber drei Uebersichts-Marker hingen hinterher (v58.0.0/v58.1.0). Sonstige Sanity-Checks gruen: 130 Plugins FS=MP, 139 Testakten FS=README, beide Validatoren OK.
Codex-Finding auf PR #199:
Der Verweis legw-rmap-einstieg-und-eignung war nicht nur im zentralen
Router, sondern auch im Schritt 5 jedes der 16 Ressort-Skills enthalten.
Im normalen Nutzungsablauf (Auftragsaufnahme -> Router -> Ressort-Skill)
landete der Nutzer trotzdem im toten Link.
Fix: einheitliche Umbiegung auf legw-rmap-grundlagen (didaktischer
Einstieg) mit Hinweis auf legw-rmap-anschluss-an-legw als Rueckkopplung.
Betroffen: legw-ressort-{aa, bmas, bmbfsfj, bmds, bmf, bmftr, bmg, bmi,
bmjv, bmleh, bmukn, bmv, bmvg, bmwe, bmwsb, bmz}.
Validatoren gruen.
P1 nkr-aufgabe-und-kompetenz-nkrg:
- Paragraf 1 NKRG: NKR ist beim Bundesministerium der Justiz (BMJ) eingerichtet, Dienstsitz Berlin, unabhaengig nach Abs. 2; nicht beim Bundeskanzleramt
- Paragraf 2 NKRG: Erfuellungsaufwand-Definition (gesamter messbarer Zeitaufwand und Kosten, SKM-Methodik)
- Paragraf 3 NKRG: Zusammensetzung (10 Mitglieder, Vorschlag BMJ, Berufung Bundespraesident, 5 Jahre, Vorsitz und Geschaeftsstelle beim BMJ)
- Paragraf 4 Abs. 3 NKRG / Paragraf 9 NKRG ergaenzt
- Pitfall-Eintrag zur veralteten Kanzleramts-Annahme
P2 nkr-zusammenarbeit-mit-bundesregierung-und-ressorts:
- Stufe 4 Eskalation an das BMJ (institutionelle Anbindung NKR nach Paragraf 1 und Paragraf 3 NKRG), nicht primaer an das Bundeskanzleramt
- Trade-off-Matrix und Rechtsrahmen entsprechend aktualisiert
P2 nkr-digitalcheck-und-onlinezugangsgesetz-ozg:
- Digitalcheck gilt nach Paragraf 4 Abs. 3 i.V.m. Paragraf 9 NKRG ab dem 1. Januar 2023, nicht ab 2022
- Beschreibung und Rechtsrahmen entsprechend praezisiert
P2 verl-rueckruf-fehlerbeitrag-spaet-erkannt:
- DDG Paragraf 8 Abs. 1: Sperrungsanspruch nur gegen Diensteanbieter, die Informationen in einem Kommunikationsnetz uebermitteln oder Zugang vermitteln (Mere Conduit) - nicht gegen Hosting- und Datenbankanbieter
- Hinweis ergaenzt: gegen Hosting / Datenbank greift DSA Art. 6 i.V.m. den allgemeinen Gesetzen
Validierung gruen (validate-plugin-structure OK, validate-yaml-frontmatter 0 Fehler, 0 Warnungen).
Rechtsgrundlagen am amtlichen Text von gesetze-im-internet.de verifiziert.
Konsistenzcheck der Repo-Uebersichten ergab zwei kleine Drift-Korrekturen: README.md "112 Plugins" zu "130 Plugins" und ASSET_INDEX.md Stand v57.0.0 zu v58.0.0. Plugin-Anzahl FS/Marketplace, Testakten-Anzahl FS/README und Plugin-README-Stichproben durchgehend konsistent.
Korrektur des vorherigen Fixes aus PR #192: Die WLAN-Sondervorschrift
steht in § 7 Abs. 2 DDG, nicht in § 8. § 8 DDG ist der Anspruch auf
Sperrung bei Rechtsverletzung an geistigem Eigentum.
- § 7 Abs. 1 DDG: Verweis auf DSA Art. 4-8 (beschraenkte Verantwortlichkeit)
- § 7 Abs. 2 DDG: WLAN-Sondervorschrift (keine Behoerdenpflicht zu
Registrierung oder Passwortabfrage)
- § 8 DDG: Anspruch auf Sperrung bei Rechtsverletzung; Subsidiaritaet;
Zumutbarkeit und Verhaeltnismaessigkeit; Kostenerstattung nur bei
vorsaetzlichem Zusammenwirken; Verpflichtungen aus gerichtlichen/
behoerdlichen Anordnungen bleiben nach § 8 Abs. 4 DDG unberuehrt.
Quelle: amtlicher Wortlaut unter gesetze-im-internet.de/ddg.
Klotzkette