Skip to content

agent: #15 [Agent] Import aus Scrivener 3 (.scriv) - #27

Draft
leonatwork wants to merge 1 commit into
mainfrom
agent/bearbeite-github-issue-15-vollst-ndig-un-1021-1555
Draft

leonatwork wants to merge 1 commit into
mainfrom
agent/bearbeite-github-issue-15-vollst-ndig-un-1021-1555

Conversation

@leonatwork

Copy link
Copy Markdown
Owner

Zusammenfassung

Autonome Umsetzung von #15: [Agent] Import aus Scrivener 3 (.scriv)

Verifikation

  • Coder-/Reviewer-Loop: APPROVE nach 3 Runde(n)

  • Tests und Qualitätsprüfungen: siehe Commit und CI-Checks

  • Kein automatischer Merge oder Produktionsdeploy

  • Modell: azure/gpt-6.1-sol; Decision-1 (active): route gpt-5.3-codex, Risiko medium; QS: npm run build && npm test bestanden

  • Art der Änderung (Triage): code; Zweitprüfung: azure/gpt-5.3-codex

  • Kosten (Listenpreis): 5,7 Mio Tokens · 2,54 €

Hinweise der Qualitätsprüfung

  • Review-Hinweis (minor: core/scrivener/rtf.ts:76-86 — Der Platzhalter (\uE000…) zählt für CommonMark weder als Leerraum noch als Satzzeichen. Steht ein ausgezeichnetes Satzzeichen direkt neben einem Tab, NBSP oder Leerraum am Zeilenrand, verliert nur dieses Satzzeichen die Auszeichnung. Beispiele: {\b Hafen.}\tab x, oder ein Tab am Zeilenanfang vor {\i „Zitat“}. Der Grund ist, dass randAnpassen den Marker dort nicht als öffnend bzw. schließend erkennt. Der Text bleibt zeichengleich, AC-2 ist also nur am Rand betroffen. Möglicher Fix: Vor randAnpassen den Platzhalter wie Leerraum behandeln, zum Beispiel in)

Closes #15

…bare Lösung.

Lies zuerst den vollständigen Issue-Thread inklusive aller Kommentare, CLAUDE.md und die relevanten Repository-Regeln. Prüfe vorhandene PRs und aktuellen Code, bevor du Änderungen machst. Leite die verbindlichen Akzeptanzkriterien aus dem Issue ab und dokumentiere nicht erfüllbare oder widersprüchliche Kriterien klar.

Arbeite testgetrieben: Erzeuge Regressionstests, verifiziere ihr korrektes Fehlschlagen vor dem Fix und führe danach die relevanten Tests sowie die vorgeschriebenen Qualitätsprüfungen aus. Ändere nur, was für das Issue erforderlich ist. Arbeite ausschließlich auf dem ausgecheckten Stand von origin/main: checke keine Branches fremder offener PRs aus, cherry-picke nichts daraus und baue nicht auf ihnen auf. Hängt die Lösung von einem noch offenen PR ab, liefere nur deinen eigenen Anteil und dokumentiere die Abhängigkeit im Handover. Keine Produktionsdeployments, keine Änderungen an Produktionsdaten oder Produktions-Supabase und kein --prod. Merge den PR nicht.

Issue: #15
Titel: [Agent] Import aus Scrivener 3 (.scriv)

Beschreibung:
<!-- hermes-agent-form-v1:start -->
## Ziel und Nutzen
Autorinnen, die von Scrivener 3 umsteigen, importieren ein .scriv-Projekt mit Kapiteln, Kurzbeschreibungen (Synopsis) und Notizen, statt alles von Hand zu übertragen.

## Ist-Zustand / Problem
Der Import kennt nur .docx (ImportDialog.tsx, menue.rs). Der Rust-Dialog wählt nur Dateien (extern_dateien.rs). Es gibt keinen RTF-Parser. ImportErgebnis kennt je Kapitel nur titel und text. KapitelPlan.szene, notiz und akt existieren im Modell. #14 (Ordner-Import) ist noch OPEN.

## Umfang (In Scope)
- Binder aus .scrivx lesen (Draft-Hierarchie und -Reihenfolge)
- Je Textdokument ein Kapitel; content.rtf nach Markdown (Absätze, fett, kursiv)
- Oberste Ordner im Manuskript werden zu Akten, Dokumente darunter zu Kapiteln; Ordner unterhalb der Akt-Ebene werden ignoriert, nur ihre Textdokumente werden Kapitel
- synopsis.txt wird KapitelPlan.szene, notes.rtf wird KapitelPlan.notiz
- ImportErgebnis und importUebernehmen additiv um szene, notiz und akt erweitern
- RTF-Umwandlung und Binder-Parser als reine Funktionen in core/ mit Vitest
- Scrivener 3 auf Mac und Windows
- Ablehnung älterer Pakete (Files/Docs) mit DE/EN-Meldung; Hinweis bei beschädigtem RTF

## Nicht Teil dieses Issues (Out of Scope)
- Scrivener 1 und 2
- Recherche, Papierkorb, Bilder, Fußnoten, Kommentare, Annotationen, Snapshots, Keywords, Labels, Status
- Formatierungen über fett und kursiv hinaus
- Export nach Scrivener
- Eigener Ordner-Dialog (kommt aus #14)

## Fachliche und UX-Entscheidungen
- Geklärt: Text bleibt inhaltlich unverändert (E7), IDs über neueId (E1), szene darf an die KI, notiz nicht (E12)
- Geklärt (Leon): Oberste Ordner als Akte, Dokumente als Kapitel
- Geklärt (Leon): Scrivener 3 auf Mac und Windows, ältere Versionen werden mit Meldung abgelehnt
- Geklärt (Leon): Aufteilung in vier Pakete (RTF, Binder, Modell, Rust/UI)
- Geklärt (Leon): Pakete 1–3 starten vor #14, nur Paket 4 wartet auf #14
- Geklärt (Leon): Ordner unterhalb der Akt-Ebene ignorieren, nur ihre Textdokumente werden Kapitel

## Prüfbare Akzeptanzkriterien
- AC-1: Wenn ich ein .scriv-Paket von Scrivener 3 (Mac oder Windows) wähle, dann zeigt die Vorschau die Textdokumente des Manuskripts als Kapitel in Binder-Reihenfolge.
- AC-2: Fett und kursiv aus dem RTF erscheinen als **…** und *…*. Der übrige Text ist zeichengleich zum RTF-Inhalt.
- AC-3: Die Synopsis eines Dokuments steht nach dem Übernehmen als Kurzbeschreibung (KapitelPlan.szene) im Kapitelplan.
- AC-4: Die Dokumentnotiz steht nach dem Übernehmen als Notiz im Kapitelplan (plan/kapitel/<id>.md).
- AC-5: Recherche und Papierkorb aus Scrivener tauchen nicht als Kapitel auf.
- AC-6: Ein älteres Scrivener-Paket (Files/Docs) wird mit einer verständlichen Meldung in DE und EN abgelehnt, ohne Absturz.
- AC-7: Ein beschädigtes RTF bricht den Import nicht ab. Es erscheint als Hinweis, das Kapitel hat leeren Text.
- AC-8: Oberste Ordner im Manuskript werden zu Akten (KapitelPlan.akt), Dokumente darunter zu Kapiteln. Ordner unterhalb der Akt-Ebene werden ignoriert, nur ihre Textdokumente werden Kapitel. Beides ist per Test abgedeckt.

## QS und Nachweis
- Vitest in core/ mit selbst erstellten Mini-Paketen: Binder, RTF, Synopsis, Notizen, Akt-Zuordnung, Fehlerfälle, Windows-Pfad-Fixtures
- UI-Test für die Vorschau (Paket 4)
- npm test, npm run typecheck, npm run build grün; npm run sperrliste
- Manuell auf dem Mac: echtes Scrivener-3-Projekt importieren (Paket 4)

## Offene Fragen
–

_Automatisch nach dem Formular „Agent-Auftrag“ strukturiert (Hermes-Triage). Die ursprüngliche Beschreibung steht unten unverändert._
<!-- hermes-agent-form-v1:end -->

<details><summary>Ursprüngliche Beschreibung</summary>

<!-- hermes-original:start -->
### Ziel und Nutzen

Als Autorin, die von Scrivener 3 umsteigt, möchte ich ein `.scriv`-Projekt mit Kapiteln, Kurzbeschreibungen und Notizen importieren, damit ich nicht jedes Kapitel und jede Synopsis von Hand übertragen muss.

### Ist-Zustand / Problem

- Der Import kennt nur `.docx` (`src/features/importexport/ImportDialog.tsx:98-102`, Menü `src-tauri/src/menue.rs:102-107`).
- Ein `.scriv`-Projekt ist auf macOS ein Paket, also ein Ordner. Der Rust-Kern kann heute nur einzelne Dateien wählen (`src-tauri/src/extern_dateien.rs:60-96`).
- Im Repo gibt es keinen RTF-Parser. Scrivener speichert Texte und Notizen als RTF.
- `ImportErgebnis` kennt je Kapitel nur `titel` und `text` (`core/docx/importieren.ts:12-16,45-56`). Kurzbeschreibung, Notiz und Akt fehlen dort.
- Ziel-Felder gibt es im Modell: `KapitelPlan.szene` („Kurzbeschreibung“), `KapitelPlan.notiz` (Body von `plan/kapitel/<id>.md`) und `KapitelPlan.akt` (`core/model/types.ts:127-147`; Projektformat in `docs/architektur.md:49`).

### Umfang (In Scope)

- Baut auf dem Ordner-Import aus #14 auf: gleicher Weg über Ordner-Dialog, `ImportErgebnis` und Import-Vorschau.
- Binder aus der `.scrivx`-Datei (XML) lesen: Reihenfolge und Hierarchie unterhalb des Manuskript-Ordners (Draft). Recherche und Papierkorb werden nicht übernommen.
- Je Textdokument im Manuskript ein Kapitel. Text aus `Files/Data/<UUID>/content.rtf` nach Markdown umwandeln (Absätze, fett, kursiv).
- Synopsis (`synopsis.txt`) wird zur Kurzbeschreibung (`KapitelPlan.szene`).
- Dokumentnotizen (`notes.rtf`) werden zur Kapitelnotiz (`KapitelPlan.notiz`).
- Ordner im Manuskript auf Akte abbilden, wenn Leon das so entscheidet (siehe Offen).
- `ImportErgebnis` und `importUebernehmen` additiv um Kurzbeschreibung, Notiz und Akt erweitern.
- RTF-Umwandlung und Binder-Parser als reine Funktionen in `core/` mit Tests.

### Nicht Teil dieses Issues (Out of Scope)

- Scrivener 1 und 2 sowie Scrivener für Windows (siehe Offen).
- Recherche-Ordner, Bilder, Fußnoten, Kommentare, Inline-Annotationen, Snapshots, Keywords, Labels und Status aus Scrivener.
- Formatierungen über fett und kursiv hinaus (Schriftarten, Farben, Einzüge).
- Export nach Scrivener.

### Fachliche und UX-Entscheidungen

- Geklärt (Code): E7: Der Text bleibt inhaltlich unverändert, keine Typografie-Umwandlung. Nur das Format wechselt von RTF zu Markdown.
- Geklärt (Code): E1: Neue Kapitel bekommen IDs über `neueId` (`src/state/slices/importexport.ts:101`).
- Geklärt (Code): E12: Die Kurzbeschreibung (`szene`) darf an die KI, `notiz` nicht. Der Import ändert daran nichts.
- Annahme: Unterstützt wird das Format von Scrivener 3 (`Files/Data/<UUID>/…`). Ältere Pakete (`Files/Docs/…`) werden erkannt und mit einer klaren Meldung abgelehnt.
- Annahme: Ordner ohne eigenen Text werden nicht zu Kapiteln. Ein Ordner mit eigenem Text wird ein Kapitel vor seinen Unterdokumenten.
- Annahme: Mehrere Textdokumente innerhalb eines Kapitel-Ordners werden zu einem Kapitel mit Szenentrennern `* * *` (E3) zusammengefasst, wenn Leon Ordner als Kapitel statt als Akt abbildet.
- Fehlerfall: Ein nicht lesbares RTF wird als Hinweis gemeldet. Das Kapitel erscheint mit leerem Text in der Vorschau.
- Offen (Leon): Wie werden Teile bzw. Ordner abgebildet: oberste Ordner als Akte, Ordner als Kapitel mit Szenen, oder flach?
- Offen (Leon): Nur Scrivener 3, oder auch Scrivener 2 bzw. Windows?

### Prüfbare Akzeptanzkriterien

AC-1: Wenn ich ein `.scriv`-Paket von Scrivener 3 wähle, dann zeigt die Vorschau die Textdokumente des Manuskripts als Kapitel in Binder-Reihenfolge.
AC-2: Fett und kursiv aus dem RTF erscheinen als `**…**` und `*…*`. Der übrige Text ist zeichengleich zum RTF-Inhalt.
AC-3: Die Synopsis eines Dokuments steht nach dem Übernehmen als Kurzbeschreibung im Kapitelplan.
AC-4: Die Dokumentnotiz steht nach dem Übernehmen als Notiz im Kapitelplan (`plan/kapitel/<id>.md`).
AC-5: Recherche und Papierkorb aus Scrivener tauchen nicht als Kapitel auf.
AC-6: Ein älteres Scrivener-Paket wird mit einer verständlichen Meldung in DE und EN abgelehnt, ohne Absturz.
AC-7: Ein beschädigtes RTF bricht den Import nicht ab. Es erscheint als Hinweis.

### QS und Nachweis

- Agent: Vitest in `core/` mit kleinen, selbst erstellten Test-Paketen (eigenes Fixture ohne fremde Manuskripttexte): Binder-Reihenfolge, Hierarchie, RTF-Umwandlung (Absätze, fett, kursiv, Sonderzeichen, Unicode-Escapes), Synopsis, Notizen, Fehlerfälle. UI-Test für die Vorschau. `npm test`, `npm run typecheck` und `npm run build` grün. Rust-Änderungen prüft `cargo test` in der CI auf macOS.
- Manuell auf dem Mac: ein echtes Scrivener-3-Projekt mit Ordnern, Synopsen und Notizen importieren und in der App und in Obsidian prüfen.

### Technischer Kontext und Referenzen

- Relevante Dateien: `core/docx/importieren.ts` (`ImportErgebnis`), `src/state/slices/importexport.ts`, `src/features/importexport/ImportDialog.tsx`, `core/model/types.ts` (`KapitelPlan`, `Akt`), `src-tauri/src/extern_dateien.rs`, `src-tauri/src/menue.rs`.
- Architektur: E1, E3, E7, E12 in `docs/architektur.md`.
- Verwandt: #14 (Import eines Markdown- oder Textordners), Voraussetzung für dieses Issue.

### Sicherheits- und Liefergrenzen

- [X] Das Issue enthält keine Secrets, Tokens, Zugangsdaten oder vertraulichen Manuskript- und Kundendaten.
- [X] Der Agent darf Code und Tests ändern sowie einen Draft-PR öffnen, aber nicht selbst mergen, releasen oder deployen.
- [X] Änderungen an produktiver Infrastruktur oder veröffentlichten Releases sind nicht Teil dieses Auftrags.

_Angelegt von Claude Code im Auftrag von @leonatwork auf Basis einer Code-Analyse (Stand 2026-10-20)._
<!-- hermes-original:end -->

</details>

Zusätzliche Repo-Regeln:
Commits tragen ein DCO-Sign-off (das macht dev-loop automatisch). Auf diesem Server gibt es kein Rust/Tauri: nur TypeScript-Teil (core/, src/) mit npm run build und npm test prüfen, src-tauri nicht bauen. Keine Inhalte aus privaten Manuskripten; Beispiele nur aus fixtures/. Farben nur über Tokens in src/theme/tokens.css, UI nach docs/design/screens, core/ bleibt reines TypeScript, core/ki nutzt nur ProjektLeser.

Reviewer verdict: APPROVE after 3 round(s). Generated by dev-loop (not pushed).

Signed-off-by: leonatwork <leon.11@live.de>
@leonatwork leonatwork mentioned this pull request Oct 21, 2026
3 tasks done
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Agent] Import aus Scrivener 3 (.scriv)

1 participant