# Knowledge Curator – read-only dry-run 0.3.0

Der Curator liest ausschließlich vorhandene `ObsidianDocument`-,
`ObsidianChunk`-, `HAS_CHUNK`- und `NEXT`-Daten. Er schreibt weder nach
Neo4j noch in Dateien und verwendet weder Graphiti noch OpenRouter oder ein
LLM.

Versionen:

- Curator: `knowledge-curator-ro/0.3.0`
- Normalisierung: `kc-norm-v3`

Batch-2-Härtungen:

- Überschriften, Titelwiederholungen und unvollständige Fragmente werden nicht
  als reguläre Claims ausgegeben.
- `DocumentMetadata`, `DocumentScope`, `FactStatusModel` und die temporäre
  `CandidateGroup` werden getrennt modelliert.
- Zusammengesetzte Graphiti-, Fact-Status- und Regelgruppen werden im Dry-Run
  aufgeteilt; `CandidateGroup` ist kein fachlicher Endkandidat.
- Historische/session-rekonstruierte Inhalte bleiben `reported`/unverified.
- `review_v2.py --audit-consistency` prüft Evidence, Begründung, Entscheidung
  und Korrektur-JSON und erzeugt ausschließlich Warnungen.
- `review_v2.py --reextract-batch2 --source-json -` führt eine nicht persistierende
  Re-Extraction bereits lesend abgefragter Chunks aus; kein neuer Review-Batch
  wird angelegt.

Credentials werden ausschließlich aus `NEO4J_URI`, `NEO4J_USER` und
`NEO4J_PASSWORD` gelesen. Es gibt keinen Passwort-Fallback und kein
Passwort-Logging.

Live-Dry-Run:

```bash
NEO4J_URI=... NEO4J_USER=... NEO4J_PASSWORD=... python3 curator.py
```

Nur die Testmatrix ohne Neo4j-Verbindung:

```bash
python3 curator.py --offline-tests
```

Die Ausgabe enthält ausschließlich Kandidaten und Vorschläge. Automatische
`current`- oder `verified`-Zuweisungen sind absichtlich ausgeschlossen.

## Erster menschlicher Review-Pilot

Review-Batch 1 vorbereiten:

```bash
NEO4J_URI=... NEO4J_USER=... NEO4J_PASSWORD=... \
python3 review_pilot.py --prepare-batch
```

Die Vorbereitung aktualisiert ausschließlich die lokale
`review_pilot.db` und erzeugt `review_batch_1.md`. Neo4j wird dabei nur
gelesen.

Review starten:

```bash
python3 review_pilot.py --review
```

Standardmäßig werden nur die zehn Kandidaten mit `review_batch=1` angezeigt.
Mit `--all` werden alle nicht entschiedenen Kandidaten angezeigt.

Bedienung: `a` approved_for_pilot, `r` rejected, `c` needs_more_context,
`d` duplicate, `t/s/p/o/m/n/z/e` für Typ-, Subject-, Predicate-, Object-,
Modalitäts-, Polaritäts-, Zeit- oder Evidenzfehler, `v` für vollständige
Chunk-Evidence, `x` für den vollständigen Dokumentkontext, `k` zum
Überspringen und `q` zum Beenden.

Jede echte Entscheidung verlangt Begründung, Reviewer und wird mit Dauer in
`review_decisions` sowie `review_audit` protokolliert. Überspringen und
Beenden sind unterbrechbar; bereits gespeicherte Entscheidungen werden beim
nächsten Lauf nicht erneut angezeigt.

`approved_for_pilot` ist keine Wahrheit, kein `current`/`verified` und keine
Freigabe für Neo4j-Schreibzugriffe. Die lokale SQLite-Datei ist der einzige
persistente Review-Schreibpfad.

## Re-Extraction nach Reviewrunde 1

Die zehn abgeschlossenen menschlichen Entscheidungen werden als
Regressionserwartungen verwendet. Der alte Run bleibt unverändert. Ein neuer
read-only Lauf und Review-Batch 2 werden erzeugt mit:

```bash
NEO4J_URI=... NEO4J_USER=... NEO4J_PASSWORD=... \
python3 review_v2.py --reextract-reviewed
```

Die neuen lokalen Kandidaten erhalten einen neuen Run-Key. `KnowledgeRule`
und `KnowledgeRuleGroup` werden getrennt behandelt; Projektabgrenzungen sind
`DocumentScope`, Dokumentrevisionen `DocumentVersion` und Änderungen
`KnowledgeEvent`. Batch 2 wird in `review_batch_2.md` vorbereitet, aber nicht
automatisch reviewed.

## Automatische Pipeline-Review

Die produktive Pipeline läuft unter `/opt/struktur/obsidian-knowledge-pipeline/`
mit `knowledge-pipeline/1.1.0`. Der Backlog-Optimizer klassifiziert nur
nachweisbare Duplikate, technische Boilerplate und unvollständige Fragmente
append-only. Sensible, widersprüchliche oder unklare Kandidaten bleiben in der
menschlichen Review. Es werden weder `current`/`verified` automatisch gesetzt
noch Truth-Items aus dieser Optimierung erzeugt. Die Migration wird durch
`backlog_final_audit.py` und die JSON-/Markdown-Auswertungen dokumentiert.

## Minimal Human Review

`minimal_review_analysis.py` analysiert den aktuellen Reviewrest read-only.
`minimal_review_cli.py` bietet Clusteranzeige, append-only Gruppenentscheidungen,
Regelvorschläge und die begrenzte sichere Migration technischer Inhalte.
Aktuell verbleiben 7.775 Fälle; 18 Cluster decken 67 Kandidaten ab, 1.633
Fälle sind sensibel. Keine Zukunftsregel wird ohne explizite Freigabe aktiviert.

## Lokale AI-Abschlussauflösung

`ai_review_resolver.py` schließt gruppierte Reviewkandidaten mit versionierten,
konservativen Codex-Regeln ab. Der Resolver liest Originaldatei, Evidence und
Provenienz, protokolliert einen positiven und einen kritischen Prüfdurchgang
und setzt nur terminale Routingstatus wie `exploratory_source_only`,
`sensitive_quarantine`, `historical_report_only`, `technical_context_only`
oder `fast_index_only`.

Er verwendet keine externe Modell-API, schreibt weder Neo4j noch
`truth_items` und setzt niemals automatisch `current`, `verified` oder
`superseded`. Der Pipeline-Service führt Router und Resolver nach jedem Lauf
aus; Routineentscheidungen werden nicht an Carlo delegiert.