diff --git a/.gitignore b/.gitignore index 6dab269..d2fb464 100644 --- a/.gitignore +++ b/.gitignore @@ -71,3 +71,9 @@ yarn-error.log* # Misc .cache/ + +# Secrets (NICHT im Klartext committen!) +.secrets +*.token.json +remarkable_token.json +orgmylife.db diff --git a/.secrets b/.secrets deleted file mode 100644 index 98f22c0..0000000 --- a/.secrets +++ /dev/null @@ -1,21 +0,0 @@ -# Tokens fuer API-Zugriffe (NICHT committen!) -# Diese Datei steht in .gitignore - -# GitLab: Bestellsystem-Repos (read_api fuer Inventar, POM-Analyse etc.) -# https://git.tech.rz.db.de/bestellsystem1 -GITLAB_TOKEN_BESTELLSYSTEM=glpat-4hLnqiONvqxLOGB8AvgerW86MQp1OnpuOAk.01.0z0kt1fdf - -# GitLab: Dieses Audit-Projekt (write fuer Push) -# https://git.tech.rz.db.de/AndreKnie/project-audit -GITLAB_TOKEN_AUDIT=glpat-my1E6DY1HykjnMuSm5mMYG86MQp1OjFnNTcK.01.1006v7db9 - -# Jira -JIRA_TOKEN=NTMwMjQ0MzY2NzQ0OkpIZBEiwwYfES+c80xqOpsjVdpx -JIRA_TOKEN_SAB=ODc5OTA4NzEwOTA3OtYXcOwp6DF0w2jIqUtpZy08wP6L - -# Confluence -CONFLUENCE_TOKEN=MjM0Mzc4ODEyNTkxOlFySnuOOXbzsYdRjrXrSVFR4fRK -CONFLUENCE_SAB=NTcwMTk3NjY0MzQ5Ov5N/ZnglAroOMcDmrlLQGrsyrae - -# OrgMyLife -ORGMYLIFE_API_SECRET !Z5l5vUcm!&qfhUuE=Nf \ No newline at end of file diff --git a/README.md b/README.md index cb797e3..4c5be45 100644 --- a/README.md +++ b/README.md @@ -1,293 +1,40 @@ -# Wissensdatenbank ETL-Pipeline +# Monorepo -## Worum geht es? (in einfach) +Zentrales Repository für alle Projekte, organisiert nach Arbeitskontext. -Dies ist die **zentrale Wissenssammlung** fuer den 1st-Level-Support und Chatbots rund um -DB InfraGO. Wir **sammeln hier das Wissen** aus vielen Quellen (Confluence, Webseiten, -PDFs), pruefen es und legen es **versioniert im Git-Repo** ab. Damit ist dieses Repo die -**Single Source of Truth**: Wenn etwas hier steht und freigegeben ist, gilt es - und genau -das lesen die Chatbots. - -**Was ist „ETL"?** Drei einfache Schritte, die bei jeder Aufnahme passieren: - -1. **Extract = Sammeln.** Wissen aus den Quellen holen (Confluence-Seiten, Webseiten, PDFs). -2. **Transform = Aufbereiten.** In einheitliches Markdown umwandeln, mit Schlagworten/Scope - versehen und vertrauliche Inhalte herausfiltern. -3. **Load = Ablegen.** Das geprueefte Wissen versioniert nach `data/processed/` schreiben - - die zentrale Wahrheit, aus der Chatbots/Vektor-DB lesen. - -Kurz: **Quellen rein → aufbereiten/pruefen → als Single Source of Truth ablegen.** - -## Ziel - -Klar definieren, **welches Wissen in Chatbots darf und welches nicht.** Wissen wird bei -der Aufnahme speziell verarbeitet und bereitgestellt, sodass Chatbots es nutzen koennen. -Klassifikation nach Scope: - -- **allgemein** – darf intern **und** extern genutzt werden; nicht toolspezifisch - (z.B. Regulierung/INB, Kundeninformationen). -- **intern** – nur DB InfraGO intern. -- **extern** – public im Internet bzw. fuer EVUs/EIUs. - -Technisch eine **ETL-Pipeline fuer LLM/RAG**: holt Wissen aus Confluence, Webseiten und -PDFs, klassifiziert es nach Scope, filtert vertrauliche Inhalte und gibt nur geprueftes -Wissen frei (`data/processed//...` = Feed fuer die Vektor-DB). - -> Architektur & vollstaendiger Wissensfluss inkl. Diagramme: -> [`.kiro/steering/architecture.md`](.kiro/steering/architecture.md) -> · Manuelle Einrichtungsschritte: [`docs/SETUP.md`](docs/SETUP.md) - -## Denkmodell +## Struktur ``` -Domaene -> Scope (intern|extern|allgemein) -> Tool -> Dokument(e) +bahn/ ← DB InfraGO Projekte (10 Repos, untouched remotes) +dhive/ ← dhive GmbH Projekte +privat/ ← Persönliche Projekte +shared/ ← Kontextübergreifende Tools und Infrastruktur ``` -- **Domaene**: fachlicher Bereich (jedes Tool ist eigene Domaene; `regulierung`, `kundeninfo` fuer allgemeines Wissen). -- **Scope**: `intern` | `extern` | `allgemein` (allgemein gilt fuer intern UND extern). -- **Tool**: eine Fachanwendung aus dem 1st-Level-Support (Katalog automatisch aus Seite 428909879). -- **Strategie pro Quelle** – siehe Tabelle unten. +## Kontexte -### Strategien (Verarbeitung pro Quelle) +| Kontext | Inhalt | Repos | +|---------|--------|-------| +| **bahn** | DB InfraGO | aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp, Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit, Projekt-KIQ-HP, teamlandkarte-mcp | +| **dhive** | dhive GmbH | Jury-Voting | +| **privat** | Persönlich | CV, NoteGraph (→ Redo geplant) | +| **shared** | Übergreifend | AI-Orchestrator, OrgMyLife, power_skills_and_more, tools/monorepo-cli, references/symphony | -| Strategie | Was sie tut | Wichtige Options | -|-----------|-------------|------------------| -| `confluence_page` | genau diese eine Seite | `scope` (auch `intern,extern`), `incremental`, `attachments` | -| `confluence_tree` | Seite inkl. Unterseiten | `max_depth` (-1=alle, 0=nur Seite), `incremental`, `attachments` | -| `confluence_faq` | FAQs aus Tabellen | `incremental` | -| `crawler` | Webseite: Index → Detailseiten | `detail_pattern`, `selector`, `max_pages` | -| `sitemap` | Detailseiten aus (gz-)Sitemap | `sitemap_url`, `url_pattern`, `limit`, `incremental` | -| `gitlab_md` | Markdown-Dateien aus einem GitLab-Repo | `ref`, `path`, `max_depth` (Token: `GITLAB_TOKEN`) | -| `file` | Dateien (md/pdf) aus dem Repo-Ordner `files/` | `max_depth` | -| `pdf` | PDFs einer Seite → Markdown (1→n) | `split: headings\|pages`, `heading_pattern`, `keep_raw`, `redact` | - -### Confluence-Anhaenge (eingebundene PDFs) - -Bei `confluence_page`/`confluence_tree` werden **eingebundene PDF-Anhaenge** -(`view-file`/`viewpdf`-Makros) automatisch geparst und als **eigene Dokumente** im -selben Feed abgelegt (Frontmatter `kind: attachment`, `parent_url` zeigt auf die Seite). -Scope/Domain/Owner werden von der Seite geerbt. Inkrementell ueber die Attachment-Version -(unveraenderter Anhang -> kein Re-Parse). Default an, pro Quelle ueber -`options: { attachments: false }` abschaltbar. - -Bilder werden nicht binaer uebernommen; der **alt-Text/Dateiname** bleibt als -`[Bild: ...]` im Markdown - gibt dem RAG Kontext ohne Volumen. Datei-Embeds ohne -Parsing-Pfad (z.B. Office-Docs) tauchen als `[Anhang: ...]`-Marker im Seitentext auf. - -### Mehrere Quellen pro Tool - -Ein Tool kann beliebig viele, gemischte Quellen haben – einfach weitere Eintraege -unter `sources:` anhaengen (z.B. mehrere Confluence-Quellen mit `max_depth`, eine -interne und eine externe Seite, oder zusaetzlich eine FAQ-Seite). Siehe die Tools -`pathos` (mehrere Quellen inkl. `confluence_faq` und `intern,extern`) und `nur`. - -### intern vs. extern – wie wird klassifiziert? - -Es gibt **keine Inhaltstrennung innerhalb einer Seite** mehr. Klassifiziert wird pro -Tool und pro Quelle: - -**Tool-`scope`** (in `config/tools.yaml`): - -| Tool-`scope` | Bedeutung | -|--------------|-----------| -| `intern` | alles intern (Default, restriktiv – z.B. Salesforce, NuR) | -| `extern` | alles extern | -| `allgemein` | gilt fuer intern UND extern | -| `mixed` | Tool hat Quellen mit **unterschiedlichem** Scope (z.B. eine interne und eine externe Seite) | - -**Source-`scope`** (pro Quelle, gilt fuer die ganze Seite): -- `intern` | `extern` | `allgemein` -- `"intern,extern"` → die Seite wird fuer **beide** Scopes genutzt (dupliziert). - -Quellen ohne eigenen `scope` erben den Tool-Scope (bei `mixed` => intern). -**Wichtig:** Hat ein Tool gemischtes Wissen, braucht es im Zweifel **zwei Seiten** -(eine interne, eine externe) als zwei Quellen – statt einer gemischten Seite. - -Allgemeines, tool-uebergreifendes Wissen steht separat in **`config/general.yaml`**. - -Der Tool-Katalog wird **initial** mit `scripts/bootstrap_tools.py` erzeugt und danach -**manuell** in `config/tools.yaml` gepflegt. Uebersicht aller Quellen: GitLab-Pages-Seite -**„Wissensquellen"** (`config.html`, geparst aus tools.yaml/general.yaml/approvals.yaml). - -## Neues Wissen hinzufuegen (Workflow) - -Jedes Wissen hat **owners** (intern Verantwortliche, Accountability) und einen -**contact** (herausgebbare Kontaktadresse, Default `einfachbahn@deutschebahn.com`). -Beide stehen im Frontmatter jedes Dokuments und auf der Pages-Seite, damit klar ist, -wer verantwortlich ist und an wen man sich wenden darf. - -1. **Issue anlegen** mit der Vorlage „Neues Wissen" (`.gitlab/issue_templates/`): - Tool/Domaene, **Quellen je Zeile** (`URL | Strategie | Scope`), **Verantwortliche** - (`owners`) und optional **Kontakt** (Default `einfachbahn@deutschebahn.com`). -2. **Reviewer uebernimmt** die Angaben nach `config/tools.yaml` bzw. `config/general.yaml` - (neuer Tool-/Quellen-Eintrag inkl. `owners:`) – per GitLab Web-IDE (Variante A) oder - manuell (Variante B). -3. **Merge Request** öffnen. Die **MR-Freigabe ist das Quality Gate** (4-Augen, via - `CODEOWNERS` + Protected Branch). -4. **Vorschau** im MR: den `preview`-Job manuell starten und `PREVIEW_ONLY` auf - Tool-Id/Domaene/URL der neuen Quelle setzen. Er verarbeitet nur diese Quelle und - stellt die erzeugten Markdowns als Job-Artefakt bereit. Lokal alternativ - `python -m src.main --only "" --data preview`. -5. **Merge** → der ETL-Schedule verarbeitet die Quelle (stuendlich Mo–Fr, inkrementell) und - committet das Wissen; die Vektor-DB liest direkt aus `data/processed//...`. - -## Freigabe-Prozess - -``` -MR mergen (Mensch) -> ETL: Extract -> Transform -> Auto-Filter -> data/processed/ -> Vektor-DB -``` - -- **Freigabe = Merge Request (Mensch, das eigentliche Gate):** Wer eine Quelle - (Link + Strategie + Scope) in `config/tools.yaml`/`general.yaml` eintraegt, stellt einen - MR. Beim **Merge** (4-Augen via `CODEOWNERS` + Protected Branch) wird entschieden, - welche Quelle mit welchem Scope aufgenommen wird. Danach laeuft der ETL automatisch. -- **Auto-Filter im ETL (Sicherheitsnetz, kein Freigabe-Knopf):** setzt pro Dokument - `review_status` – standardmaessig **approved**: - - `approved` -> `data/processed/...` (**direkt live**, sobald gemergt + ETL gelaufen) - - `pending` -> `data/staging/pending/` (Blacklist-Treffer, Scope-Warnung, oder - Inhalt < 50 Zeichen – Grund im Frontmatter `review_notes`) - - `trusted: true` (z.B. INB) bleibt trotz Treffer approved; `redact: false` schaltet - die Redaction pro Quelle ab. -- **`config/approvals.yaml` (nachtraegliche Korrektur):** hebt einzelne - `pending`-Dokumente per URL oder `hash:` doch auf `approved`. - Kein Schritt, den jedes Dokument durchlaeuft. Den Hash zeigt die Pages-Seite (Detail-Fenster). -- **Vektor-DB liest direkt aus `data/processed///`** (implementiert): - Nur freigegebenes Wissen liegt dort, der Scope steckt im Ordnerpfad **und** im - Frontmatter (inkl. `owners`/`contact`). Kein separater Export-/Ingestion-Schritt – - `processed/` IST der Feed. Der externe Index nimmt nur `extern/` + `allgemein/`. -- **`data/_meta.json`**: globale Statusdatei fuer nachgelagerte Systeme mit - `last_run` (letzter ETL-Lauf), `last_change` (wann sich der Bestand zuletzt - inhaltlich/metadatenseitig geaendert hat), `documents`, `by_scope` und einer - `content_signature`. Ein Index-/RAG-Consumer kann daran erkennen, ob ein erneutes - Einlesen ueberhaupt noetig ist. -- **`data/_index.json`**: dokument-genauer Katalog des gesamten Bestands. - Pro Voll-Dokument: `domain`/`tool`/`scope`, `url`, `path`, `content_hash`, - `last_updated` und - falls vorhanden - die zugehoerigen `chunks` (Anzahl + Pfad) - und `attachments` (Anhang-Dokumente: Name + Pfad). Anhang-Dokumente haben zudem - `kind: "attachment"` und `parent_url`. Aggregate: `documents_total`, - `chunks_total`, `attachments_total`, `by_domain` (mit `documents`/`chunks`/`attachments`), - `by_scope`. So sieht ein Anschliesser auf einen Blick, was pro Domaene/Tool wo liegt - und welche Dokumente zusaetzlich als Chunks oder Anhaenge vorliegen (z.B. INB = - Voll-Dokument **und** Chunks; pathOS-Seite = Voll-Dokument **und** Anhang-PDF). - Deterministisch (kein Zeitstempel) -> aendert sich nur bei echten Bestandsaenderungen. -- **`data/run_log.jsonl`**: append-only **Lauf-Historie** (1 JSON-Zeile je ETL-Lauf): - Zeitstempel, verarbeitete Dokumente, Status-Counts und **Fehler je Quelle** - (z.B. fehlgeschlagene Confluence-Abrufe). Auf die letzten 500 Laeufe gekappt. So sieht - man - auch historisch - ob ein Lauf sauber durchlief, ohne die fluechtigen CI-Job-Logs - zu durchsuchen. Die Uebersichtsseite zeigt zusaetzlich eine kompakte Health-Zeile - („N Dok verarbeitet, M Quellen mit Fehler") in der Fusszeile. - -### Wo liegt das final freigegebene Wissen? - -Ausschliesslich unter **`data/processed///[/]`** im Repo -(versioniert, = Single Source of Truth). `pending`-Dokumente liegen in -`data/staging/pending/` und werden zur **Transparenz ebenfalls committet** (auf der -Pages-Seite einsehbar). Der Audit-Trail steht in `data/review_report.json` und in -der Git-Historie. - -## Lokal testen +## Tools ```bash -python3 -m venv .venv -source .venv/bin/activate -pip install -r requirements.txt - -ruff check src tests # Lint -python -m pytest -q # Offline-Tests -python -m src.main --config config/tools.yaml --data data # Live-Lauf -python -m src.chunk --data data # Chunks erzeugen (offline, optional) +# CLI-Tool für Monorepo-Verwaltung +cd shared/tools/monorepo-cli +pip install -e . +ctx-guard --help ``` -## Confluence aktivieren +## Sicherheit -```bash -export CONFLUENCE_URL="https://arija-confluence.jaas.service.deutschebahn.com" -export CONFLUENCE_TOKEN="" # Bearer-PAT (Server/DC) -pip install atlassian-python-api -``` +- Secrets werden via git-crypt verschlüsselt (pro Kontext eigener Schlüssel) +- `.secrets` ist in `.gitignore` — niemals committen +- Zugriffskontrolle via `shared/config/access-config.yaml` -Ohne Credentials werden Confluence-Quellen sauber uebersprungen. +## Föderation -## Betrieb (GitLab CI) - -- `quality`-Stage: `ruff` (Lint) + `gitleaks` (Secret-Scan) bei jedem Push/MR. -- `etl`-Stage: **stuendlich Mo–Fr 8–17 Uhr** (Cron `0 8-17 * * 1-5`), baut Wissen, - committet `data/` nach `main` (per `GIT_PUSH_TOKEN`); der Commit loest automatisch - einen `pages`-Refresh aus. -- `pages`-Stage: baut `public/` (Uebersicht, Hilfe, Chatbot-Anschluss, Wissensquellen) - fuer GitLab Pages auf `main`. -- `preview`-Job (MR, manuell): verarbeitet eine neue/geaenderte Quelle via - `--only` und stellt die erzeugten Markdowns als Job-Artefakt bereit (zum Pruefen - vor dem Merge). `PREVIEW_ONLY` beim Start auf Tool-Id/Domaene/URL setzen. -- **Kundeninfos inkrementell**: `incremental: true` crawlt nur NEUE Detailseiten und - ueberschreibt vorhandene nicht – Re-Runs bleiben schnell. -- **Confluence inkrementell**: `options: { incremental: true }` prueft pro Seite die - Confluence-Versionsnummer (`source_version` im Frontmatter). Unveraenderte Seiten - werden uebersprungen, nur geaenderte/neue Seiten neu verarbeitet – spart API-Last. -- **Re-Tagging bei Metadaten-Aenderung**: Aenderst du in `tools.yaml`/`general.yaml` - nur `tags`/`owners`/`contact` einer Quelle, weicht deren `meta_fingerprint` - (im Frontmatter) vom gespeicherten ab. Der naechste inkrementelle Lauf passt dann - die bestehenden Dateien dieser Quelle in-place an (nur Frontmatter, kein erneuter - Download/API-Call). -- **Scope-Wechsel**: Aenderst du den `scope` einer Quelle, wird die Seite neu - verarbeitet und an `data/processed//...` geschrieben; die alte Ablage - wird nach erfolgreichem Schreiben **automatisch geloescht** (domaenen-intern, damit - eine URL, die legitim unter mehreren Domaenen liegt – z.B. eine pathOS-Seite auch - unter `web` – nicht versehentlich entfernt wird). -- **Domain-Umbenennung**: Die neue Ablage entsteht automatisch, die alte Domain-Ablage - bleibt aber stehen (domaenenuebergreifendes Loeschen waere wegen geteilter URLs - unsicher). Den alten `data/processed///`-Ordner daher bei einer - Domain-Umbenennung manuell loeschen. -- CI/CD-Variablen: `GIT_PUSH_TOKEN`, `CONFLUENCE_URL`, `CONFLUENCE_TOKEN` (Masked). -- `scm-info.yaml`: Pflichtdatei fuer DB-GitLab-Compliance. - -## Konfiguration - -- `config/tools.yaml` – Tools, Domaenen, Quellen, Strategien, Scopes, Tags -- `config/filter_rules.json` – Blacklist-Keywords, Regex-Redaction -- `config/chunking.yaml` – gemeinsame Chunk-Defaults (pro Quelle ueber `options.chunk` ueberschreibbar) - -### Chunking (optional, Default aus) - -Grosse, stark gegliederte Dokumente (v.a. **INB**) werden zusaetzlich zur Voll-Datei in -**Chunks entlang der Ueberschriften** zerlegt – ein **abgeleitetes, jederzeit neu -erzeugbares** Artefakt unter `data/chunks////`. Das Voll-Dokument -in `data/processed/` bleibt unangetastet (Parent-Document-Muster): ein Anschliesser waehlt -Voll-Dokument, Chunks oder beides. Es werden bewusst nur **deterministische, embedding-freie** -Strategien angeboten (`headings | faq | recursive`); semantisches Chunking gehoert in die -Vektor-DB des Anschliessers. Jeder Chunk bekommt eine kurze **Contextual-Retrieval**-Zeile -(`> Kontext: > `). Aktivierung pro Quelle via `options: { chunk: headings }`. - -**Inkrementell (kein Voll-Rebuild):** Chunking laeuft am Ende jedes ETL-Laufs automatisch -mit (`src.main`) und ist Teil von `data/`. Pro Dokument wird nur dann neu gechunkt, wenn -sich der **Inhalt** (`parent_hash`) ODER die **wirksamen Optionen/Strategie** -(`chunk_fingerprint`) geaendert haben - sonst wird das Dokument uebersprungen (keine -Datei-Aenderung, kein Git-Churn). Aenderst du also bei einer Quelle z.B. `chunk_level` -oder von `headings` auf `recursive`, werden **nur die Dokumente dieser Ablage** neu -erzeugt. Wird `chunk` wieder auf `off` gestellt oder ein Voll-Dokument geloescht, werden -die zugehoerigen Chunks automatisch entfernt. - -**Feinsteuerung (Default aus, pro Quelle ueberschreibbar):** - -- `chunk_min_doc_chars`: Dokumente unter dieser Zeichenzahl bleiben **ganz** (kleine - FAQ-/How-to-Seiten muessen nicht zwingend gechunkt werden). -- `chunk_kind`: chunkt nur Dokumente mit passendem `kind` (`""` = alle; `attachment` = - nur Anhang-PDFs; `document` = nur Voll-Seiten). - -Beispiel **pathOS** (an der Tool-Tree-Quelle in `config/tools.yaml`): grosse Anhang-PDFs -(z.B. EVU-Schnittstellen-Doku, 2,8 MB) werden gechunkt, Seiten und FAQs bleiben ganz. - -```yaml -options: - incremental: true - chunk: headings - chunk_kind: attachment # nur Anhang-PDFs chunken - chunk_min_doc_chars: 3000 # < 3k Zeichen bleiben ganz (~750 Token) -``` - -## Version & Changelog - -Aktuelle Version steht in **`VERSION`** (SemVer), die Historie in **`CHANGELOG.md`** -(Format „Keep a Changelog"). Beides wird auf der GitLab-Pages-Seite **„Changelog"** -angezeigt (Version auch in der Navigationsleiste). Pflege-Regeln: -`.kiro/steering/changelog-versioning.md`. +Bahn-Team, dhive-Team und private Repos können als eigenständige Team-Repos synchronisiert werden (Hub-and-Spoke). Konfiguration: `shared/config/team-repos.yaml`. diff --git a/SPEC-NoteGraph.md b/SPEC-NoteGraph.md deleted file mode 100644 index 0134bf9..0000000 --- a/SPEC-NoteGraph.md +++ /dev/null @@ -1,402 +0,0 @@ -SPEC.md -1. Executive Summary -Product / Initiative Name - -Note-Graph - -Interviewed Stakeholder Role - -Owner, sponsor, project lead, and implementation orchestrator (“AI conductor”) - -Product Type - -New product - -Goal in One Sentence - -Create a personal knowledge infrastructure that enables reliable access to all notes, thoughts, decisions, and contextual information at any time in order to improve memory, prioritization, and project continuity. - -Short Business Context - -The stakeholder operates across many parallel projects, domains, meetings, and customer contexts. Information currently exists across handwritten notes, PDFs, meeting artifacts, task systems, Confluence spaces, and AI-generated summaries. The current process relies heavily on memory and chronological note-taking, causing information loss, weak follow-up tracking, and fragmented context retrieval. - -Primary Target Users -Primary: Single knowledge worker / project orchestrator -Future potential: Extended collaborative usage (currently out of scope) -Core Functional Scope Summary - -The system shall: - -consolidate notes and knowledge artifacts from multiple formats and sources, -support flexible tagging and contextual relationships, -preserve historical context and traceability, -enable fast contextual retrieval, -connect notes with tasks, people, projects, and decisions, -support gradual AI-assisted enrichment, -maintain portability and data ownership. -In Scope -Personal knowledge management -Cross-project contextual search -Flexible labels/tags -Relationships between notes, projects, people, tasks, and decisions -Integration of handwritten notes and document-based sources -Offline-capable note capture -Mobile access -Traceability between tasks and source context -Export and publication workflows -AI-assisted enrichment and retrieval -Out of Scope -Full project management platform -CRM functionality -Team collaboration platform -Chat/messaging system -Calendar replacement -Complex automation workflows -Autonomous AI agents -Advanced graph visualization in first phase -Semantic contradiction detection in first phase -Main Open Questions -Degree of automation vs manual curation -How granular note segmentation should become in practice -How historical relationship changes should be surfaced to users -Scope of AI-generated suggestions in early versions -Exact publication/export workflows -Main Acceptance Indicators -Relevant information can be retrieved during meetings. -Meeting preparation becomes significantly easier. -Contextual information can be found reliably across projects and time. -Tasks remain traceable to their originating notes and decisions. -2. Goal -One-Sentence Goal - -Provide a durable, searchable, context-aware personal knowledge system that acts as an external memory and decision-support environment. - -Detailed Goal - -The system shall centralize fragmented knowledge sources and allow the stakeholder to: - -capture ideas quickly, -retain project continuity, -retrieve relevant context rapidly, -preserve historical relationships, -connect operational tasks with their originating discussions and decisions, -maintain structure despite frequent context switching. -Business Value -Reduced information loss -Better prioritization -Faster meeting preparation -Improved continuity across projects -Reduced cognitive load -Better follow-through on decisions and tasks -Long-term retention of institutional and personal knowledge -Intended Outcome for Users and Organization - -Users should be able to trust the system as a reliable external memory and operational context assistant. - -3. Stakeholder Context -Respondent Role -Owner -Sponsor -Project lead -Implementation orchestrator (“AI conductor”) -Perspective Represented - -Single stakeholder representing both business and implementation direction. - -Relevant Organizational or Customer Context - -The stakeholder works across multiple projects, domains, customers, and meeting contexts with heterogeneous documentation ecosystems. - -Whether This Spec Reflects One Interview Only - -Yes. This specification reflects a single interview. - -4. Target Users -User Groups -Primary User - -Knowledge worker managing many parallel projects and information streams. - -Potential Future Users - -Additional collaborators or project participants (currently out of scope). - -User Context - -Users frequently: - -switch contexts, -attend meetings, -create handwritten and digital notes, -consume large document collections, -derive tasks from discussions, -revisit historical decisions. -User Needs - -Users need to: - -retrieve information quickly, -preserve context, -avoid forgetting commitments, -connect ideas across projects, -maintain operational continuity, -understand historical decisions. -Pain Points -Media breaks between tools and formats -Difficulty finding information later -Fragmented storage locations -Reliance on memory -Missing conversion from notes to tasks -Weak cross-project traceability -Loss of contextual continuity -Important Differences Between Groups - -No differentiated user groups are currently defined. - -5. Current Situation / Current Process -Current Process - -Information currently exists across: - -handwritten meeting notes, -PDFs, -Confluence spaces, -task management tools, -AI-assisted document search tools, -digital note collections. - -Meeting notes are often incrementally extended over time and searched manually using: - -project names, -dates, -people, -remembered context. -Existing Workarounds -Manual search -AI-assisted document retrieval -Chronological note accumulation -Personal memory and contextual recall -Main Gaps, Bottlenecks, and Failure Points -Media discontinuity -Information fragmentation -Weak traceability -Missing task extraction -Incomplete prioritization -Context loss across projects -Inability to reliably recover ideas generated in unrelated contexts -What Should Remain Unchanged -Existing working style should remain largely compatible. -Notes may continue to originate from different tools and formats. -6. Functional Scope -Main Capabilities - -The system shall: - -ingest and organize knowledge artifacts, -support contextual relationships, -preserve historical information, -enable retrieval across projects and time, -support flexible tagging and labeling, -connect operational tasks to source knowledge, -support gradual AI-assisted enrichment. -Key User Interactions - -Users shall be able to: - -capture notes quickly, -associate notes with multiple projects, -associate notes with people and topics, -split notes into smaller contextual fragments, -search by content, project, person, or time, -review historical decisions, -export or publish derived content, -revisit unresolved items. -Major Functional Areas -Knowledge capture -Knowledge organization -Search and retrieval -Relationship management -Task traceability -Historical context management -AI-assisted enrichment -Export/publication support -Role-Based Differences in Usage - -No differentiated role behavior currently defined. - -Relevant Triggers, Inputs, Outputs, and Outcomes -Inputs -Handwritten notes -PDFs -Markdown files -Office documents -Meeting artifacts -AI-generated summaries -Outputs -Search results -Structured contextual views -Exported content -Task references -Meeting preparation material -Outcomes -Faster information access -Improved continuity -Better prioritization -Reduced forgotten tasks and decisions -7. Business Rules -Notes may belong to multiple projects simultaneously. -Relationships between entities may evolve over time. -Historical assignments and timestamps must remain preserved. -Original notes and source information must not be lost. -Tasks must remain traceable to originating notes or decisions. -Structured relationships and free-form associations must coexist. -Offline capture capability is required. -Mobile access is required. -Users must retain control over AI-generated enrichments or suggestions. -Relationship interpretation may change over time without overwriting historical truth. -8. Business Objects / Functional Data Objects -Note - -Represents a captured thought, meeting artifact, observation, or written content. - -Thought Fragment - -Represents a smaller extracted or separable unit derived from a larger note. - -Project - -Represents a business or operational context grouping related knowledge. - -Person - -Represents individuals connected to notes, tasks, meetings, or decisions. - -Task - -Represents actionable follow-up work derived from notes or decisions. - -Decision - -Represents an explicitly recorded outcome or conclusion. - -Source Document - -Represents imported or referenced material such as PDFs, Office documents, or AI-generated summaries. - -Label / Tag - -Represents flexible classification and contextual grouping metadata. - -Relationship - -Represents contextual connections between business objects. - -Time Context - -Represents historical assignment and chronological relevance. - -9. In Scope -Personal knowledge graph functionality -Multi-project note association -Flexible tagging and labeling -Contextual relationships -Historical traceability -Search by text, project, person, and time -Mobile access -Offline usage -Handwritten note integration -AI-assisted retrieval and enrichment -Export and publishing workflows -Task traceability to source context -Gradual enrichment through review/question workflows -10. Out of Scope -Enterprise collaboration platform -Full project management suite -CRM capabilities -Messaging/chat platform -Calendar replacement -Autonomous AI workflows -Complex process automation -Advanced graph visualizations in first release -Automatic contradiction analysis in first release -Fully automated prioritization -11. Requirements -Knowledge Capture -The system shall allow users to capture notes quickly. -The system shall support offline note capture. -The system shall support mobile access. -The system shall support handwritten note integration. -The system shall support importing external document sources. -Knowledge Organization -The system shall allow notes to belong to multiple projects simultaneously. -The system shall support labels and tags. -The system shall support both structured and free-form relationships. -The system shall allow users to split notes into smaller contextual fragments. -The system shall preserve relationships between fragmented content and original source notes. -Search and Retrieval -The system shall provide full-text search. -The system shall support contextual retrieval across projects and relationships. -The system shall support search by people. -The system shall support search by project. -The system shall support time-based navigation and retrieval. -The system shall allow users to retrieve meeting-relevant information quickly. -Task Traceability -The system shall support linking tasks to source notes or decisions. -The system shall preserve the origin context of tasks. -The system shall support identifying missing task metadata such as priorities or deadlines. -Historical Integrity -The system shall preserve original notes and timestamps. -The system shall preserve historical relationship assignments over time. -The system shall allow contextual relationships to evolve without losing historical information. -AI Assistance -The system shall support AI-assisted search and summarization. -The system shall support AI-assisted enrichment and categorization. -The system shall support gradual future expansion of AI capabilities. -The system shall support review or quiz-style interactions for knowledge enrichment. -Portability and Ownership -The system shall support export of information and derived content. -The system shall minimize dependency on proprietary structures. -The system shall preserve user data ownership. -The system shall support long-term portability and migration. -12. Open Questions / Items to Clarify -Desired level of automatic relationship generation -Exact workflow for exporting/publishing to external systems -Preferred granularity for note fragmentation -Scope of AI-generated task extraction -Desired review cadence for enrichment workflows -Long-term collaboration requirements -Definition of archival versus active information -Rules for conflict resolution between changing contextual assignments -13. Risks and Ambiguities -Excessive maintenance effort may reduce adoption. -Weak search quality could undermine trust in the system. -Too many manual steps may interrupt workflows. -Incorrect AI-generated relationships may reduce confidence. -Information overload may reduce usability. -Overly rigid structures may conflict with real-world usage patterns. -Insufficient offline support may limit operational usefulness. -Lack of clear contextual boundaries may create organizational confusion. -Future migration requirements may conflict with short-term optimizations. -14. Acceptance Perspective - -The product will be considered successful if: - -users can reliably retrieve relevant information during meetings, -meeting preparation becomes significantly easier, -contextual information can be recovered across projects and time, -tasks remain traceable to their origin, -users trust the system as an external memory, -the system reduces forgotten follow-ups and lost context, -users can maintain organization despite frequent context switching, -knowledge remains portable and under user control. -15. Glossary -Original Term English Explanation Notes / Context -Notiz-Graph Note graph / knowledge graph system Working title of the product -KI-Dirigent AI orchestrator Stakeholder role coordinating AI-supported workflows -Confluence Knowledge collaboration platform Existing documentation source -NotebookLM AI-supported document knowledge tool Existing AI-generated summary source -Labels Context labels Used for structured assignment -Tags Flexible metadata tags Used for contextual classification -Todo-App Task management application External task system -Medienbruch Media discontinuity Fragmentation between formats/tools -Gedächtnisstütze Memory aid Contextual reminder mechanism \ No newline at end of file diff --git a/orgmylife.db b/orgmylife.db deleted file mode 100644 index c05aa35..0000000 Binary files a/orgmylife.db and /dev/null differ diff --git a/remarkable_token.json b/remarkable_token.json deleted file mode 100644 index 4e87c91..0000000 --- a/remarkable_token.json +++ /dev/null @@ -1 +0,0 @@ -{"device_id": "b34feb7e-2c5f-4308-a657-a20a24547171", "device_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdXRoMC11c2VyaWQiOiJhdXRoMHw2NjBkNzM2NWEyZDYzZjBmMmIyOGIwNGIiLCJkZXZpY2UtZGVzYyI6ImRlc2t0b3AtbGludXgiLCJkZXZpY2UtaWQiOiJiMzRmZWI3ZS0yYzVmLTQzMDgtYTY1Ny1hMjBhMjQ1NDcxNzEiLCJpYXQiOjE3NzkzNDc1OTEsImlzcyI6InJNIFdlYkFwcCIsImp0aSI6ImNrMHRUUkZvVXhzPSIsIm5iZiI6MTc3OTM0NzU5MSwic3ViIjoick0gRGV2aWNlIFRva2VuIn0.29K8KBvJynjJyDRpnd36LvcG8-wXwA7MBweaXE0ocmY"} \ No newline at end of file diff --git a/shared/knowledge-store/.gitkeep b/shared/knowledge-store/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/shared/mcp-servers/.gitkeep b/shared/mcp-servers/.gitkeep deleted file mode 100644 index e69de29..0000000 diff --git a/shared/powers/.gitkeep b/shared/powers/.gitkeep deleted file mode 100644 index e69de29..0000000