Merge pull request 'Erkenntnisse aus dem PICTURE-Import festhalten' (#34) from doku/picture-import-erkenntnisse into main

Reviewed-on: #34

docs/status/STATUS.md

@@ -1,7 +1,7 @@
 # Status des Projekts
 
 Kurz und aktuell. Wird bei jedem Merge und jeder Übergabe gepflegt (Skill `sn-uebergabe`). Älteres wandert nach unten
-in „Erledigt" oder wird gelöscht. **Stand: 25.09.2026.**
+in „Erledigt" oder wird gelöscht. **Stand: 28.09.2026.**
 
 ## Aktuelle Phase
 
@@ -17,23 +17,31 @@ Skills sind übernommen, alles QGIS- und Plugin-Spezifische ist entfernt. Kern i
 
 ## Offene Baustellen (priorisiert)
 
-1. **Repo `Projektwissen` in Gitea öffentlich schalten** (Repo → Einstellungen → Sichtbarkeit). Die Organisation ist
+1. **Eingabequalität und Interviewmethode (#28).** Der Import des PICTURE-Bestands zeigt: Der Engpass sind die
+   Ausgangsdaten, nicht der Konverter. Die Befunde in `docs/wissen/picture_import.md` (Abschnitt „Befunde“ und
+   „Weiter“) sind die Grundlage dafür, welche Kerninformationen ein Interview abfragen muss.
+2. **Repo `Projektwissen` in Gitea öffentlich schalten** (Repo → Einstellungen → Sichtbarkeit). Die Organisation ist
    öffentlich, das Repo nicht; ohne das liest `scripts/gitea.py` keine Tickets, und die Skills `sn-ticket` und
    `sn-aufgabe-bearbeiten` laufen ins Leere.
-2. **ADR 0004 (Prozessbibliothek als eigenes Repository) vom Team annehmen lassen**, dann den ersten echten
+3. **ADR 0004 (Prozessbibliothek als eigenes Repository) vom Team annehmen lassen**, dann den ersten echten
    Prozess dort ablegen.
-3. **Glossar um BPMN-/PICTURE-Begriffe ergänzen** und die Flurbereinigungsbegriffe auf das prüfen, was für
+4. **Glossar um BPMN-/PICTURE-Begriffe ergänzen** und die Flurbereinigungsbegriffe auf das prüfen, was für
    Prozesse gebraucht wird.
-4. **Leitfäden vom Team gegenlesen lassen.** `docs/leitfaden/03–05` sind für die Prozessarbeit neu gefasst;
+5. **Leitfäden vom Team gegenlesen lassen.** `docs/leitfaden/03–05` sind für die Prozessarbeit neu gefasst;
    die Beispiele (Issue #12 usw.) sind erfunden und durch echte zu ersetzen, sobald es sie gibt.
-5. **Umgang mit `sn-bpmn` in AG_QGIS klären.** Der Branch `BPMN-Skill` in `AG_QGIS/Projektwissen` ist durch dieses
+6. **Umgang mit `sn-bpmn` in AG_QGIS klären.** Der Branch `BPMN-Skill` in `AG_QGIS/Projektwissen` ist durch dieses
    Repository abgelöst und kann dort nach Absprache gelöscht werden.
-6. **Mit VLN_SN absprechen:** abgesprochener Lesezugriff auf die Repositories (damit Stil und Bausteine nicht neu
+7. **Mit VLN_SN absprechen:** abgesprochener Lesezugriff auf die Repositories (damit Stil und Bausteine nicht neu
    erfunden werden) und Nutzung des Workflow-Systems als Kandidat für das Fernziel „Prozesse ablaufen lassen“. Bis
    dahin nur als Vorbild, siehe `docs/wissen/vln_sn.md`.
 
 ## Erledigt
 
+- 28.09.2026 **PICTURE-Bestand als Import-Modelle in der Prozessbibliothek** (#31, Prozessbibliothek #4): 23
+  Diagramme zurückgewandelt, Status `Import`, Ordner `import-*`. Stresstest: keine Kante durch ein Element; lange
+  Gateway-Fragen werden geschnitten, unbeschriftete Elemente lassen sich keiner Lane zuordnen. Befunde:
+  `docs/wissen/picture_import.md`.
+
 - 25.09.2026 **Bootstrap lokal eingebettet, Stil der AG** (#27): Bootstrap 5.3.8 und Bootstrap Icons 1.13.1
   unter `werkzeuge/bootstrap/`, eigene Regeln in `werkzeuge/stil/ag_prozesse.css`; die BPMN-Vorschau hat jetzt eine
   dunkle Navigationsleiste wie die Anwendungen in VLN_SN und bleibt offline.

docs/wissen/picture_import.md

@@ -69,6 +69,9 @@ schrägen Anschlüsse und keine zu kleinen Anmerkungen** – auch bei 116 Elemen
    die Nachbaraufgabe. Die Beispiele haben nur kurze Fragen, deshalb fiel das bisher nicht auf.
 2. **Datenobjekte stehen in einer einzigen Reihe oben.** Bei 31 Datenobjekten wird das Diagramm über 11 000 breit,
    der Ablauf selbst nur rund 5 800. Ohne Assoziationen stehen sie zudem weit weg von der Aufgabe, zu der sie gehören.
+   **Bewertung nach dem PICTURE-Import (28.09.2026): kein Konverterfehler**, sondern ein Designfehler der
+   Ausgangsmodelle. Dort sind Datenobjekte nicht an Aufgaben gebunden. Gelöst wird das über die
+   Arbeitsschritt-Datenbank, in der jedes Dokument einem Arbeitsschritt gehört. Kein Konverter-Issue.
 3. **Große Prozesse ohne Lanes werden sehr hoch.** Senkrechtes Layout: U3.10 mit 46 Ablaufelementen ist 6 400 hoch.
    PICTURE-Originale sind waagrecht angelegt.
 
@@ -98,7 +101,12 @@ schrägen Anschlüsse und keine zu kleinen Anmerkungen** – auch bei 116 Elemen
 
 ## Weiter
 
-- Befunde 1 bis 3 sind Kandidaten für Konverter-Issues, 4 bis 7 für Issues zur Syntax (Vertrag).
+- **Erkenntnis aus dem Import (28.09.2026):** Der Konverter ist nicht der Engpass, sondern die Ausgangsdaten. Die
+  PICTURE-Modelle haben unbeschriftete Gateways, Sackgassen, lose Elemente und Datenobjekte ohne Bezug. Wer mit
+  wenigen Iterationen zu einem brauchbaren Prozess kommen will, braucht deutlich bessere Eingaben und eine
+  saubere Interviewmethode, die diese Lücken schon beim Erfassen schließt (Issue #28).
+- Befunde 1 und 3 sind Kandidaten für Konverter-Issues, 4 bis 7 für Issues zur Syntax (Vertrag). Befund 2 löst
+  die Arbeitsschritt-Datenbank.
 - Issue #28 (Qualifizierung der Eingabe) und die geplante Arbeitsschritt-Datenbank können auf die Import-Modelle
   zurückgreifen: Die Anmerkungen enthalten viel Fachwissen (Fristen, Rechtsgrundlagen, Werkzeuge,
   Dokumente je Schritt).