hide-internal-doc-chunks in den rag-backfill-Verteiler haengen
Der Lauf `hideInternalDocChunks` war seit 0bafeff gebaut und getestet, aber nicht verdrahtet: der Auftragsname war dem Verteiler unbekannt, und der Rueckfall am Ende haette ihn still durch `backfillChunkLanguage` ersetzt -- also einen falschen Lauf ohne Fehlermeldung geliefert.
- src/index.ts: Einfuhr + Verteiler-Zweig VOR dem Rueckfall, Kopf-Kommentar der Auftrags-Liste um die Signatur ergaenzt. - package.json: `hideInternalDocChunks.core.test.mjs` in die Testkette.
Verify: Bau gruen; Testkette gruen und die neue Reihe belegt in der Ausgabe (`hideInternalDocChunks.core: 56 passed, 0 failed`). Flip-Probe gegen das kompilierte dist/index.js gefahren: mit dem Zweig HINTER dem Rueckfall landet `hide-internal-doc-chunks` in `backfillChunkLanguage` -- die Reihenfolge ist damit gemessen, nicht behauptet. Der Uebersetzer faengt es NICHT (der Zweig ist zwar unerreichbar, bricht den Bau aber nicht).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013DW1XRFQDrDUNPyT6mdAoB
Neurag
deterministische Bestands-Korrektur der Sprach-Beschriftung von collection-Abschnitten
Der Schreibweg liest die Sprache seit 1a32d05 ab statt sie zu raten — es kommt also nichts Falsches mehr dazu. Dieser Lauf raeumt den Altbestand: er setzt `metadata.language` aus dem Ursprungs-Datensatz neu und UEBERSCHREIBT dabei. `backfillChunkLanguage` fragt `$exists:false` und traegt nur Fehlendes nach — ein solcher Lauf liesse genau den Schaden stehen (84,5 % Widerspruch zum `Locale:` des Datensatzes).
Ausloesen: rag-backfill / "relabel-collection-language" { apply?, batchSize?, maxBatches?, startAfterId?, sourceIds?, maxUnsetRatio? } Ohne `apply` ein reiner Trockenlauf.
Gemessen (Produktion, rein lesend, 2026-08-22): - Text-Weg gegen Dokument-Weg entschieden, nicht geraten: 3 Fenster, 2 Quellen, 6.000 Abschnitte — 5.977/5.977 Uebereinstimmung, 0 Widersprueche; 23 ohne `Locale:` im Text (geteilte Datensaetze), die das Dokument trotzdem aufloest. Also: Dokument ist die Quelle, Text nur Rueckfall. - Auf den zwei Riesenquellen (96,6 % des Bestandes) ueber 60.000 Abschnitte: 0 unset, 0 skip, 93,1 % korrigiert oder gefuellt.
Zwei Befunde, die im Auftrag nicht standen: - `metadata.documentId` ist eine ZEICHENKETTE, `_sourceDocument` eine ObjectId. Der im Auftrag genannte Mengen-Lookup ueber `documentId` liefert typ-bedingt null Treffer OHNE Fehler (0 von 2.000 gegen 2.000 von 2.000) — der Lauf haette daraus "keine Sprache" gelesen und auf 14,6 Mio Dokumenten geloescht. - Die Entfern-Regel gilt nicht ueberall: die Loesch-Menge sind die prosa-nahen Mandanten-Modelle (WikiPages Median 2.204 Zeichen, Contents 2.989), wo franc die richtige Mechanik ist und kein `Locale:` gerendert wird. Deshalb im Betrieb ueber `sourceIds` beschraenken; die Loesch-Bremse (maxUnsetRatio, Vorgabe 5 %) bricht einen unbeschraenkten Lauf ab, BEVOR er schreibt.
Entscheidung und Schleife liegen boot-frei im Kern, damit Trockenlauf und Ernstfall dieselbe Schleife fahren. 69 Proben, in `npm test` aufgenommen.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Fixrag
internal-Riegel im laufenden Abgleich — interne Seiten wurden endkunden-sichtbar
`incrementalSync` schrieb `consumerVisible: source.consumerVisible || false`, waehrend sein Zwilling `structuredDataChunker.ts:125` seit dem 2026-05-26 (`758d69e`, "wiki-internal leak fix") den Riegel `&& doc.internal !== true` traegt. Der Abgleich ist der LAUFENDE Schreiber (alle 30/60/120 min je Quelle): eine interne Wiki-Seite, die nach der Erst-Indizierung bearbeitet wurde, lief durch den Weg ohne Riegel und wurde dabei endkunden-sichtbar.
Gemessen (Produktion, rein lesend, 2026-08-22): 18 von 18 Wiki-Seiten mit `internal: true` haben endkunden-sichtbare Abschnitte — 46 aktive Abschnitte ueber zwei Mandanten, kein einziger korrekt verborgen. Alle 18 Seiten sind NACH der Haertung des Zwillings entstanden (aelteste 2026-07-22), die Ursache ist also dieser Weg und nicht Alt-Bestand. Direkter Beleg: Seite 6a82e86536b34963d60a2b78 traegt `internal: true` seit 11:53:54Z, ihr Abschnitt wurde am 2026-08-18T12:30:04Z neu geschrieben — sichtbar.
Zweiter Zwilling geprueft: die Objekt-Literale sind sonst feldgleich. Die Abweichung bei `_customerID` ist begruendet (globale Quellen erben den Stempel des Rebuilds, incrementalSync.ts:51-70), also kein zweiter Befund.
⚠ Der Bestand heilt hierdurch NICHT: beide Zwillinge ueberspringen Abschnitte mit unveraendertem `textHash`, und der Schluessel enthaelt `consumerVisible` nicht — eine reine Flag-Aenderung loest also weder hier noch im Rebuild ein Neuschreiben aus. Die 46 brauchen einen eigenen Korrektur-Lauf; Abbild liegt unter .claude/reports/rueckroll-abbilder/.
Verify: Flip-Probe gegen den gebauten Ausdruck beidseitig (internal:true unter sichtbarer Quelle true→false), zwei Negativ-Kontrollen unveraendert (ohne `internal` bleibt sichtbar; Quelle consumerVisible:false bleibt unsichtbar), 6/6 gruen; Ausdruck jetzt identisch mit dem Zwilling; Regression 29/29.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015yTiSkb8SH9siwzkjmMDHT
