🛤 Die Eingangskette — Station für Station

◆ SOLL · Urteil · von Hand · wörtlich durchgetragen

Die Eingangskette — das SOLL

Diese Datei ist URTEIL und bleibt von Hand. Sie sagt, welcher Schritt fehlt und warum — und jede Aussage trägt ihr Datum und ihren Urheber. Der Erzeuger 08_OPS/gen_eingangskette.py trägt sie wörtlich in 06_DASHBOARD/konzepte/eingangskette.html; er rechnet hier nichts nach und lässt nichts weg.

⛔ Was hier NICHT hingehört: Messungen. Die stehen in 08_OPS/eingangskette.json, tragen je Punkt eine Uhr und werden erzeugt. Wer hier eine Zahl schreibt, baut die siebte Handfassung dieser Kette — genau das, wogegen diese Seite gebaut ist.

⭐ Der Grund für die Trennung ist eine Hausnarbe (Register #3741, 04./05.10.2026): eine Ablösung, die nur den rechenbaren Teil übernimmt, ist dort ein Verlust, wo das Urteil stand. Also beides — nie vermischt, nie eines ohne das andere.

1 · Warum es diese Seite gibt

Urheber: TOWER#64 · 05.10.2026 · auf JCs ausdrückliches JA

Die Eingangskette war am 05.10.2026 mindestens siebenmal dargestellt, und keine Darstellung war die geltende (die sieben stehen unten in §3). Im Kompendium — der Arbeitsgrundlage — gab es die Stationen überhaupt nicht: konzept_datenfluss.html und konzept_dokumente.html beschreiben das Prinzip, keine zeigte den Weg eines Belegs Punkt für Punkt.

⭐ Und zwei der sieben waren an diesem Tag nachweislich überholt. Das ist der ganze Grund: eine handgeschriebene Kette altert in Tagen. Deshalb ist der IST-Teil dieser Seite erzeugt und läuft im register-nachzug bei jedem Master-Merge mit.

2 · Das Urteil je Station — was fehlt und warum

Urheber: FOLLOW#01 (Messung) · TOWER#64 (Eignerzuteilung) · 04./05.10.2026

Die Kette trägt heute: die Bytes gehen nicht verloren, die Mandantenwand hält, der Router läuft. Sie endet nicht beim Menschen: die drei letzten Stationen — Zuordnung, Sichtbarkeit, Klärung — sind zusammen 9x rot und 2x grün.

In einem Satz: Die Übergabe an TGV ist gesichert, die Ablage ist kanonisch, die automatische Zuordnung ist unvollständig von Entwurf wegen, und die Abarbeitung endet in einem Regal, das niemand liest.

Station 1 · Eingang

Was fehlt: der Mail-Body als Beleg. Wenn der Beleg die Mail selbst ist, ist seine Sicherung nicht verdrahtet; sechs freigegebene Belege existieren nur als Text. Warum: gestundet unter #537 — und der Wächter davor endet mit rc=0, damit er nicht dauerrot jeden Wächter hinter sich verdeckt. ⭐ Das ist die Regel „ein dauerrotes Tor ist ein toter Meldeweg“ richtig angewandt — und es heißt, dass hier ein rc=0 kein Grün ist. (Eigner: STORAGE / #537)

Station 2 · Bytes zuerst

Was fehlt: nichts am laufenden Weg — der Kanon „Bytes zuerst“ hat gehalten. Was offen ist: ein Altbestand ohne Bytes und ein Band, das wächst statt zu schrumpfen. ⛔ Das Zweite ist der ernstere Satz: eine Grundlinie, die nur schrumpfen darf, und die trotzdem wächst, ist kein Bestandsproblem, sondern ein laufender Zufluss. (Eigner: STORAGE für die Heimholung, ABLAGE für das Band)

Station 3 · Ablage

Was gut ist, und es gehört laut gesagt: der Ablage-Skill hätte den Parkpfad in final_path schreiben können, und der Beleg hätte als abgelegt gegolten. Er tut es ausdrücklich nicht und begründet es. Die Ablage der zehn ist deshalb kein eigener Bruch, sondern die korrekte Folge des Bruchs in Station 4.

Was fehlt: das Aggregat sagt nicht, was das Ereignis sagt. Der Ereignistext ist ehrlich (parked), die Liste skills_done ist es nicht (done). ⭐ Dieselbe Sache, zwei Vorzeichen je Schicht — und ein Prüfer zählt Listen, nicht Fließtext. (Eigner: ORCH / ABLAGE)

Station 4 · Zuordnung

⭐⭐ Hier ist die Wurzel, und sie ist eine Entwurfs-Lücke, kein Programmfehler. intake_raw.py:91-98 legt ausdrücklich fest, dass Entität und Mandant nie beim Eingang gesetzt werden, und begründet es: „Ein Zweit-Upload, der die Entität einer bestehenden Zeile setzt, verschiebt einen Beleg über die Mandantenwand — als NEBENWIRKUNG einer Wiederholung, ohne dass jemand es entschieden hätte.“ Der Mandant wandert über Re-Triage oder assign-project — ausdrückliche Handlungen, und das sollen sie bleiben.

⇒ Die Kette ist genau hier zu Ende gedacht und nicht zu Ende gebaut. Das Haus weiß seit dem Eingang, zu welcher Entität jeder Beleg gehört, und schreibt es auf (4.2 ist grün). Niemand liest es (8.2 ist rot). Zwischen „gewusst“ und „entschieden“ fehlt kein Algorithmus, sondern ein Regal und ein Knopf.

Was außerdem fehlt: die Vertraulichkeitsstufe. Prinzip 3 nennt sie Fundament, nicht Add-on; bei fast der Hälfte des Bestandes ist sie leer. ⛔ NULL gilt als streng, also ist das kein Leck, sondern eine Unsichtbarkeit — und beide sehen in einer Zählung gleich aus. (Eigner: BANKING#05 für die zehn, ABLAGE/VERTRAULICH für den Bestand)

Station 5 · ORCH

Was gut ist: ein 500 im Umschlag gilt nicht mehr als Erfolg. Der Fix vom 03.10. hält, live am Bestand nachgemessen.

Was fehlt: der Grund des 500, und er wird an zwei Zeilen weggeworfen. Der Skill antwortet mit detail="<Ausnahmetyp>:<Meldung>"; der Richter im Dispatch liest davon nur statusCode. Im Zweig daneben — für Antworten ohne Umschlag — liest dieselbe Anweisung sehr wohl body.get("error"). ⇒ ⛔ Der Umschlag-Zweig ist der einzige, der den Grund fallen lässt — und er ist derselbe Zweig, der gebaut wurde, um Fehler sichtbar zu machen. Der Fix machte den Fehler sichtbar und seinen Grund unsichtbar. (Eigner: BANKING#05)

Station 6 · Abarbeitung

Was fehlt: ein done trägt kein Maß der Wirkung. Drei Belege mit 0, 4 und 13 Buchungen tragen zeichengleich denselben Satz. ⭐ Der Befund ist nicht „ein Import hat verloren“, sondern: das done-Ereignis kann „es gab nichts zu importieren“ nicht von „der Import hat alles verloren“ unterscheiden. Im gemessenen Fall war es das Harmlose — und dass es das war, wusste FOLLOW#01 aus dem Dateinamen, nicht aus dem Ereignis, das das Haus selbst geschrieben hat. (Eigner: BANKING#05)

Station 7 · Sichtbarkeit

⛔⛔ Der schwerste Bruch der ganzen Kette, und er stand in keinem Auftrag. Das Fenster, durch das KAI offene Belege zeigt, ist 30 Zeilen groß und seit Monaten vollständig belegt — von undatierten Belegen aus Mai bis August. ⭐ Solange diese undatiert bleiben, kann in diesem Werkzeug kein einziger neuer Beleg je erscheinen — nicht die zehn vom 04.10., und nicht der nächste. Der Eingang funktioniert, die Anzeige ist blind.

Und der Mechanismus ist eine Sortierregel, kein Fehler: ORDER BY date_received DESC stellt in Postgres NULLS FIRST. Niemand hat etwas falsch programmiert; die Voreinstellung der Sortierung und ein limit 30 ergeben zusammen ein Fenster, das sich selbst verschließt.

Was außerdem fehlt: der Buchhalter erreicht entitätslose Belege nie — seine Tür ist die Entität. Solange Station 4 rot ist, ist seine Sicht leer, und das betrifft das Monatspaket. (Eigner: TOWER-Ball für das Fenster, BANKING#05 für die Buchhalter-Sicht)

Station 8 · Klärung

⭐⭐ Hier endet die Kette, und zwar in drei Regalen. Das Haus erzeugt den Befund (4.2 grün), parkt den Beleg korrekt (3.2 grün), hält die Wand (7.2 grün) — und legt das Ergebnis dann in drei Regale, von denen eines seit fünf Monaten nicht befüllt wird, eines strukturell leer ist und eines keinen Leser hat.

⛔ Die Kette bricht nicht an einer Maschine, sondern an der Übergabe an den Menschen. (Eigner: KLÄRUNG — TOWER-Ball; inbox_view: KAI)

3 · Die Vorgänger — was gilt, was Archiv ist, was überholt

Urheber: FOLLOW#02 · 05.10.2026 · Auftrag TOWER#64 ⑥

⛔ Nichts davon ist gelöscht. Die Hausregel Kompendium gegen Archiv sieht vor, dass Archiv Inspiration bleibt: aufbewahrt, nicht maßgeblich. Diese Liste sagt nur, welche Rolle jede Darstellung ab heute hat.

⛔ Zwei Korrekturen an der Beauftragung, beide gemessen

① „Archive auspacken ist gebaut, also ist ① überholt“ — gebaut ist nicht live. Der Auftrag führte ①s Eintrag „Archive auspacken fehlt“ als nachweislich falsch, weil ARCHIV#01 es in der Nacht vom 04./05.10. gebaut habe. Gemessen (05.10.2026, gh pr list): die Arbeit liegt im offenen, dienstwirksamen Vorgang #3226 — nicht auf master, nicht ausgeliefert. ⇒ ①s Eintrag ist im Betrieb weiter wahr und wird erst mit Merge und Deploy falsch. ⭐ Die Lehre ist dieselbe wie der Anlass, nur in die andere Richtung: nicht nur die Kette altert in Tagen — ein Urteil ÜBER die Kette altert genauso. „Gebaut“, „gemergt“ und „live“ sind drei Zustände, und nur der dritte macht einen Fehlt-Eintrag falsch.

② „Ein gescanntes PDF ohne Textschicht hat keinen Leseweg“ — am Quelltext widerlegt, am Betrieb ungemessen. Es gibt zwei erklärte Lesewege: 08_OPS/volltext.py liest Seiten ohne Textschicht über eine OCR-Kaskade (ocr_noetig, Vorgabemodell mistral-ocr-latest), und 08_OPS/tgv-skills-service/dispatch.py:440 führt PDF_READ mit tgv-skill-pdf-ocr-fallback. ⛔ Aber: dieser Rückfall ist in 02_SKILLS/_registry.yaml:861 ein n8n-Webhook (tgv-pdf-ocr-fallback), kein lokaler Skill — und ob dieser n8n-Zweig heute lebt, habe ich nicht gemessen. ⇒ Das richtige Wort ist deshalb nicht „überholt“, sondern: der Leseweg ist erklärt, seine Ausführung ist ungemessen, und ein Bein davon hängt an n8n.

⭐ Nachmessung SOUVERAEN#04 · 11.10.2026 · Registerzeile #4050 — jetzt am Betrieb gemessen. Ein Leseweg trägt, das n8n-Bein war tot. ① Die OCR-Kaskade ist live gelaufen: agent_events des Volltext-Lesers tragen zweimal ocr.modell = mistral-ocr-latest, Extraktor pypdf-6.12.2+mistral-ocr-latest — #8519 (28.09., 4 Seiten, 23.941 Zeichen) und #8250 (11.10., 1 Seite, 1.051 Zeichen), beide Status vollstaendig. ② Das n8n-Bein: Workflow zKjQkYKKmSe076KM inaktiv, 0 Läufe, alle drei Rufer inaktiv (n8n-API, 11.10.); der Name stand nie in SKILL_TARGETS. ⛔ Und er hat gebissen — nicht über PDF_READ (dort nur Filter), sondern über agent_orch01/taxonomy.KNOWN_SKILLS, den Skill-Katalog im Orchestrator-Prompt: 14× tgv-pdf-ocr-fallback geplant ⇒ router.unresolved_skill, 8 Belege needs_review (16.–26.09.). Beide Namen gestrichen, Wächter 07_TESTS/souveraen04. ③ Office-Leser: docling-serve läuft seit ITER_54 auf Hetzner (nicht mehr Railway); der Dienst ruft 127.0.0.1:5001. Live: #7520 (pptx, 11.10., 0,05 s Verarbeitung). Ein Kaltstart wie auf Railway fällt dort weg — der Wecker pREuIhe0R0g3cDqi ist mit Absicht aus (ITER_54 Fd5).

4 · Was diese Seite NICHT sagt (R-193)

• Das Urteil oben gilt für die acht Stationen des Belegeingangs — Mail und Upload, Bytes, Ablage, Zuordnung, ORCH, Skills, Sichtbarkeit, Klärung. Über den Finanz-Fluss (fünf Stufen), den Wissens-Fluss (RAG) und den Kontakt-Fluss sagt es nichts; die stehen in konzept_datenfluss.html §2, §4 und §7.
• Die drei Wege A/B/C getrennt (Upload gegen Mail gegen gemeinsam) stehen nur in ②. Die erzeugte Seite zählt die Stationen gemeinsam. Wer die Trennung braucht, liest ② und weiß, dass ihre Zahlen vom 04.09. sind.
• Keine Aussage dieser Datei ist eine Messung. Jede Zahl auf der erzeugten Seite kommt aus 08_OPS/eingangskette.json und trägt dort ihre eigene Uhr.
• Die Eignerzuteilungen sind Zuteilungen von TOWER#64, keine Zusagen der genannten Bahnen.

Letzte Hand-Änderung: 11.10.2026 · SOUVERAEN#04 · Registerzeile #4050 (§3 ② nachgemessen). Vorher: 05.10.2026 · FOLLOW#02 · #3750. Wer diese Datei ändert, ändert ein Urteil — und setzt die Zeile oben auf heute.