second commit, initializing content
This commit is contained in:
Dominik Schäfer
@@ -1,682 +1,79 @@
|
||||
Ja bau mir eine fertige Tabelle, ich würde gerne die Infos selbst verwalten und daher dann ein
|
||||
eigenes Dashboard lokal haben dafür.
|
||||
|
||||
└─ ▾ Tool calls (5)
|
||||
├─ ● Skill View("product-price-monitor") (0.1s)
|
||||
├─ ● Skill View("xlsx") (0.2s)
|
||||
├─ ● Skill View("google-workspace") (0.2s)
|
||||
├─ ● Execute Code("from hermes_tools import web_search print(web_search('best bitc…") (0.1s)
|
||||
└─ ● Execute Code("from hermes_tools import web_search print(web_search('self host…") (0.1s)
|
||||
|
||||
┊ Ja — ich kann dir dafür direkt eine saubere lokale Tabellenstruktur bauen, die sich gut in ein
|
||||
eigenes Dashboard übernehmen lässt.
|
||||
|
||||
Ich würde dir dafür nicht nur eine „Kaufliste“, sondern ein kleines Datenmodell empfehlen mit drei
|
||||
Tabellen:
|
||||
|
||||
1) transaktionen
|
||||
|
||||
Alle Käufe, Verkäufe und Transfers
|
||||
|
||||
Spalten:
|
||||
|
||||
• id
|
||||
• datum_zeit
|
||||
• typ — Kauf / Verkauf / Transfer_in / Transfer_out
|
||||
• asset — z. B. BTC
|
||||
• menge_btc
|
||||
• preis_eur
|
||||
• gebuehren_eur
|
||||
• gesamtwert_eur
|
||||
• plattform
|
||||
• wallet_von
|
||||
• wallet_zu
|
||||
• txid
|
||||
• notiz
|
||||
|
||||
2) wallets
|
||||
|
||||
Deine Börsen, Wallets, Adressen
|
||||
|
||||
Spalten:
|
||||
|
||||
• wallet_id
|
||||
• name
|
||||
• typ — Exchange / Hardware Wallet / Software Wallet
|
||||
• adresse
|
||||
• notiz
|
||||
|
||||
3) bestand
|
||||
|
||||
Eine Übersicht, die sich aus den Transaktionen berechnet
|
||||
|
||||
Spalten:
|
||||
|
||||
• asset
|
||||
• gesamt_menge
|
||||
• durchschnittskauf
|
||||
• aktueller_kurs
|
||||
• aktueller_wert
|
||||
• realisiert
|
||||
• unrealisiert
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Fertige Vorlage für CSV / Excel
|
||||
|
||||
Du kannst diese Struktur direkt als CSV verwenden:
|
||||
|
||||
─ csv
|
||||
id,datum_zeit,typ,asset,menge_btc,preis_eur,gebuehren_eur,gesamtwert_eur,plattform,wallet_von,wall
|
||||
et_zu,txid,notiz
|
||||
1,2024-01-15 14:30:00,Kauf,BTC,0.050000,40000,5,2005,Bitpanda,,,,"Erster Kauf"
|
||||
2,2024-03-10 09:15:00,Transfer_out,BTC,0.010000,,,,"Bitpanda","Bitpanda","Ledger","","Auszahlung
|
||||
aufs Ledger"
|
||||
3,2024-03-10 09:45:00,Transfer_in,BTC,0.010000,,,,"Ledger","Bitpanda","Ledger","","Eingang auf
|
||||
Ledger"
|
||||
4,2024-06-01 18:00:00,Verkauf,BTC,0.020000,65000,8,1308,Kraken,,,,"Teilverkauf"
|
||||
|
||||
Und für Wallets:
|
||||
|
||||
─ csv
|
||||
wallet_id,name,typ,adresse,notiz
|
||||
1,Bitpanda,Exchange,,Börsenkonto
|
||||
2,Ledger,Hardware Wallet,bc1...,Cold Storage
|
||||
3,Kraken,Exchange,,Verkaufskonto
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Für dein lokales Dashboard würde ich empfehlen
|
||||
|
||||
Wenn du es wirklich lokal selbst verwalten willst:
|
||||
|
||||
• Excel / LibreOffice für den Start
|
||||
• oder Google Sheets nur als Zwischenlösung
|
||||
• für ein echtes Dashboard später:
|
||||
• Python + SQLite + Streamlit
|
||||
• oder Python + DuckDB + Plotly
|
||||
• oder Notion/Airtable nur wenn du cloud okay findest
|
||||
|
||||
Mein Favorit für lokal:
|
||||
SQLite als Datenbank + Streamlit als Dashboard
|
||||
|
||||
Dann kannst du:
|
||||
|
||||
• Käufe/Verkäufe eingeben
|
||||
• aktuellen BTC-Bestand sehen
|
||||
• Wertentwicklung visualisieren
|
||||
• Transfers zwischen Wallets nachverfolgen
|
||||
• später Steuerberichte exportieren
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Ich kann dir direkt als Nächstes eines von drei Dingen bauen:
|
||||
|
||||
1. eine fertige Excel/CSV-Vorlage
|
||||
2. ein SQLite-Schema für dein lokales Dashboard
|
||||
3. ein komplettes Streamlit-Dashboard-Gerüst
|
||||
|
||||
Wenn du willst, mache ich dir im nächsten Schritt direkt:
|
||||
ein sauberes Dashboard-Datenmodell mit Tabellen, Feldern und Beispielinhalten, so dass du es 1:1
|
||||
lokal umsetzen kannst.
|
||||
|
||||
───
|
||||
|
||||
❯ Excel würde am Anfang reichen, später sollte es importiert werden können in ein sqlite Dashboard.
|
||||
|
||||
▾ Todo (0/1) · incomplete · 1 still pending
|
||||
[>] Create an Excel-friendly BTC tracking template with future SQLite import compatibility
|
||||
|
||||
└─ ▾ Tool calls (2)
|
||||
├─ ● Todo("planning 1 task(s)") (0.0s)
|
||||
└─ ● Execute Code("from openpyxl import Workbook from openpyxl.styles import Font,…") (0.0s)
|
||||
|
||||
┊ Klar — für deinen Start ist Excel die richtige Wahl, wenn du später in ein SQLite-Dashboard
|
||||
importieren willst.
|
||||
|
||||
Ich habe dir dafür die Struktur festgelegt, die am besten importierbar bleibt:
|
||||
|
||||
Empfohlene Excel-Arbeitsmappe
|
||||
|
||||
Blatt 1: Transaktionen
|
||||
|
||||
Eine Zeile = ein Vorgang.
|
||||
|
||||
Spalten:
|
||||
|
||||
• id
|
||||
• datum_zeit
|
||||
• typ
|
||||
• asset
|
||||
• menge_btc
|
||||
• preis_eur
|
||||
• gebuehren_eur
|
||||
• gesamtwert_eur
|
||||
• plattform
|
||||
• wallet_von
|
||||
• wallet_zu
|
||||
• txid
|
||||
• notiz
|
||||
|
||||
Werte für typ:
|
||||
|
||||
• Kauf
|
||||
• Verkauf
|
||||
• Transfer_in
|
||||
• Transfer_out
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Blatt 2: Wallets
|
||||
|
||||
Für Börsen, Hardware Wallets und Adressen.
|
||||
|
||||
Spalten:
|
||||
|
||||
• wallet_id
|
||||
• name
|
||||
• typ
|
||||
• adresse
|
||||
• notiz
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Blatt 3: Anleitung
|
||||
|
||||
Kurzhinweise zur Pflege, damit du später sauber importieren kannst.
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Wichtig für späteren SQLite-Import
|
||||
|
||||
Damit der Import später einfach wird:
|
||||
|
||||
• pro Zeile nur eine Transaktion
|
||||
• keine zusammengeführten Zellen
|
||||
• keine leeren Zwischenzeilen
|
||||
• Datumsformat einheitlich
|
||||
• z. B. 2024-01-15 14:30:00
|
||||
• Typwerte immer gleich schreiben
|
||||
• BTC-Mengen mit Dezimalpunkt oder konsistentem Format
|
||||
• Wallets separat pflegen, nicht nur im Freitext
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Sinnvolle Erweiterungen für später
|
||||
|
||||
Wenn du das Dashboard ausbaust, kannst du noch ergänzen:
|
||||
|
||||
• kurs_usd
|
||||
• gebuehren_asset
|
||||
• exchange_rate_eur_usd
|
||||
• quelle
|
||||
• steuerrelevant
|
||||
• status
|
||||
• verknuepfte_txid
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Meine Empfehlung für deinen Workflow
|
||||
|
||||
1. Jetzt Excel pflegen
|
||||
2. Daten sauber halten
|
||||
3. Später 1:1 in SQLite importieren
|
||||
4. Dashboard darauf aufbauen
|
||||
|
||||
Wenn du möchtest, mache ich dir im nächsten Schritt direkt eine konkrete Excel-Vorlage als
|
||||
tabellarischen Aufbau zum Kopieren hier im Chat — also so, dass du sie sofort in Excel einfügen
|
||||
kannst.
|
||||
|
||||
Und wenn du willst, kann ich dir auch gleich die SQLite-Zieltabelle dazu entwerfen, damit Excel und
|
||||
Dashboard exakt zusammenpassen.
|
||||
|
||||
───
|
||||
|
||||
❯ kannst du python befehle ausführen, damit du das gesammelte Wissen in ein Softwareprojekt Ordner
|
||||
unter bitcoin-programm, wo ich alles dokumentiere und das projekt lebt. Kann ich das bei mir
|
||||
erstellen oder kann ich die Verwaltung dir überlassen auf gitea, ich kann dir token geben.
|
||||
Automatische Deployments sind mit Github Runner auf dem TrueNAS oder auf dem VPS wo Hermes lebt
|
||||
möglich. Tailscale Netzwerk ist schon vorhanden, damit das allen Nutzern im System klar ist. Ich kann
|
||||
dann anfangen die Daten rauszusuchen und einzutragen, wenn ich soweit bin. Ich würde gerne auch eine
|
||||
To Do liste mit Kalender haben, sodass ich an jeden Tag meine "Termine" habe, wie arbeiten halt.
|
||||
Verbunden mit iCloud Kalender oder Google Calender.
|
||||
|
||||
▾ Todo (0/3) · incomplete · 3 still pending/in_progress
|
||||
[>] Create an Excel-friendly BTC tracking template with future SQLite import compatibility
|
||||
[ ] Decide local vs Gitea management workflow for bitcoin-program project
|
||||
[ ] Design TODO/calendar integration with iCloud or Google Calendar
|
||||
|
||||
└─ ▾ Tool calls (4)
|
||||
├─ ● Skill View("blackfrost-gitea") (0.2s)
|
||||
├─ ● Skill View("hermes-agent") (0.2s)
|
||||
├─ ● Skill View("github-repo-management") (0.2s)
|
||||
└─ ● Todo("updating 3 task(s)") (0.0s)
|
||||
|
||||
┊ Ja — das geht, und das ist sogar ein sehr guter Weg.
|
||||
|
||||
Kurzantwort
|
||||
|
||||
• Ja, ich kann dir Python-basiert beim Aufbauen helfen
|
||||
• Ja, wir können das als Projektordner bitcoin-programm sauber dokumentieren
|
||||
• Ja, du kannst das auch selbst lokal erstellen
|
||||
• Ja, Gitea-Verwaltung ist möglich
|
||||
• Ja, du kannst mir dafür einen Token geben
|
||||
• Ja, ein späterer Import nach SQLite ist sinnvoll
|
||||
• Ja, Kalender + To-do ist gut machbar, inkl. iCloud oder Google Calendar
|
||||
|
||||
Meine Empfehlung
|
||||
|
||||
Für den Start würde ich es so aufziehen:
|
||||
|
||||
Phase 1: lokal auf deinem Rechner
|
||||
|
||||
• Projektordner bitcoin-programm
|
||||
• Excel-Datei als Hauptdatenquelle
|
||||
• Markdown-Doku für Regeln, Struktur, Felder, Workflows
|
||||
• später Import nach SQLite
|
||||
|
||||
Phase 2: Git/Gitea als Versionsverwaltung
|
||||
|
||||
• wenn du willst, kann das Projekt in Gitea leben
|
||||
• Dokumentation, Tabellenvorlagen, Skripte, später App-Code
|
||||
• du behältst die Datenhoheit
|
||||
• ich kann dir helfen, die Repo-Struktur zu definieren
|
||||
|
||||
Phase 3: Dashboard
|
||||
|
||||
• SQLite als Datenbasis
|
||||
• lokales Dashboard
|
||||
• später Import aus Excel/CSV
|
||||
• Views für:
|
||||
• Bestand
|
||||
• Käufe
|
||||
• Verkäufe
|
||||
• Transfers
|
||||
• Wertentwicklung
|
||||
• offene Aufgaben / fehlende Daten
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Zu deinem Wunsch mit Kalender
|
||||
|
||||
Das ist sehr sinnvoll. Ich würde es trennen in:
|
||||
|
||||
A) To-do-Liste
|
||||
|
||||
Für alles, was du noch zusammentragen musst:
|
||||
|
||||
• Transaktionen suchen
|
||||
• Wallet-Adressen sammeln
|
||||
• Börsen-Exports ziehen
|
||||
• Gebühren notieren
|
||||
• TxIDs ergänzen
|
||||
|
||||
B) Kalender
|
||||
|
||||
Für wiederkehrende oder konkrete Termine:
|
||||
|
||||
• Datenpflege
|
||||
• Monatsabschluss
|
||||
• Steuer-Check
|
||||
• Portfolio-Review
|
||||
• Erinnerungen an fehlende Einträge
|
||||
|
||||
Integration möglich mit:
|
||||
|
||||
• Google Calendar
|
||||
• iCloud Kalender
|
||||
|
||||
Wenn du willst, können wir später automatisch:
|
||||
|
||||
• Aufgaben aus einer Liste in Kalendertermine umwandeln
|
||||
• oder Kalendereinträge als wiederkehrende Review-Termine erzeugen
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Wichtiger Punkt zu Tokens und Gitea
|
||||
|
||||
Du kannst mir Tokens geben, aber bitte nur, wenn wir das hier sauber und kontrolliert tun.
|
||||
Wenn wir tatsächlich auf Gitea schreiben sollen, kann ich das machen — aber ich würde vorher genau
|
||||
festlegen:
|
||||
|
||||
• welches Repo
|
||||
• welche Dateien
|
||||
• ob nur Dokumentation oder auch Code
|
||||
• welche Rechte der Token hat
|
||||
|
||||
Zu den Deployments
|
||||
|
||||
Verstanden:
|
||||
|
||||
• GitHub Runner auf TrueNAS möglich
|
||||
• VPS mit Hermes möglich
|
||||
• Tailscale ist schon vorhanden
|
||||
|
||||
Das ist gut, weil wir damit später zwischen:
|
||||
|
||||
• lokalem Arbeiten
|
||||
• automatischem Deploy
|
||||
• Zugriff aus dem Heimnetz / Tailscale
|
||||
• Repo-gestützter Dokumentation
|
||||
|
||||
sauber aufbauen können.
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Was ich dir als Nächstes vorschlage
|
||||
|
||||
Ich kann dir jetzt direkt eines von drei Dingen erstellen:
|
||||
|
||||
1. Projektstruktur für bitcoin-programm
|
||||
• Ordner
|
||||
• Dateien
|
||||
• Doku-Aufbau
|
||||
• Importpfad für SQLite
|
||||
|
||||
2. Excel-Vorlage als importfreundliches Schema
|
||||
• Tabellenblätter
|
||||
• Spalten
|
||||
• Beispielzeilen
|
||||
• Regeln für spätere Automatisierung
|
||||
|
||||
3. Konzept für To-do + Kalender
|
||||
• welche Listen
|
||||
• welche Kalenderkategorien
|
||||
• Google/iCloud-Anbindung
|
||||
• Erinnerungslogik
|
||||
|
||||
Wenn du willst, mache ich dir im nächsten Schritt direkt eine konkrete Projektstruktur für
|
||||
bitcoin-programm mit Ordnernamen und Dateien, so dass du sofort loslegen kannst.
|
||||
|
||||
───
|
||||
|
||||
❯ Ja erstmal 1., dann 2., dann 3.
|
||||
|
||||
▾ Todo (0/3) · incomplete · 3 still pending/in_progress
|
||||
[>] Create an Excel-friendly BTC tracking template with future SQLite import compatibility
|
||||
[>] Define bitcoin-programm project structure and documentation layout
|
||||
[ ] Design TODO/calendar integration with iCloud or Google Calendar
|
||||
|
||||
└─ ▾ Tool calls (1) ~6 tokens
|
||||
└─ ● Todo("updating 3 task(s)") (0.0s)
|
||||
|
||||
┊ Alles klar — ich gehe der Reihe nach vor.
|
||||
|
||||
1) Projektstruktur für bitcoin-programm
|
||||
|
||||
Ich würde das Projekt so aufbauen, dass es einfach startbar, gut dokumentiert und später leicht
|
||||
importierbar bleibt.
|
||||
|
||||
Empfohlene Ordnerstruktur
|
||||
bitcoin-programm
|
||||
|
||||
Lokales Projekt zur strukturierten Erfassung und Verwaltung von:
|
||||
|
||||
• To-dos
|
||||
• Kalendereinträgen
|
||||
• Dokumentation
|
||||
• später: Bitcoin-Transaktionen und Auswertungen
|
||||
|
||||
Ziel
|
||||
|
||||
Das Projekt dient als zentrales Arbeitsverzeichnis für persönliche Verwaltung und spätere Automatisierung.
|
||||
|
||||
Geplant ist:
|
||||
|
||||
• eine einfache Eingabemaske für To-dos und Kalendertermine
|
||||
• CSV als einfache Zwischen- und Exportform
|
||||
• später ein SQLite-Backend für Auswertung und Dashboard
|
||||
• optional Sync mit Google Calendar oder iCloud Kalender
|
||||
|
||||
Aktueller Fokus
|
||||
|
||||
Der aktuelle Fokus liegt auf:
|
||||
|
||||
1. Dokumentation
|
||||
2. To-do-Erfassung
|
||||
3. Kalender-Erfassung
|
||||
4. saubere Datenstruktur für späteren Import nach SQLite
|
||||
|
||||
Bitcoin-Tracking kann später ergänzt werden.
|
||||
|
||||
Projektstruktur
|
||||
|
||||
Empfohlene Struktur:
|
||||
|
||||
─ text
|
||||
bitcoin-programm/
|
||||
├─ README.md
|
||||
├─ docs/
|
||||
│ ├─ 00_overview.md
|
||||
│ ├─ 01_data_model.md
|
||||
│ ├─ 02_excel_workflow.md
|
||||
│ ├─ 03_sqlite_plan.md
|
||||
│ ├─ 04_calendar_todo.md
|
||||
│ └─ 05_import_rules.md
|
||||
├─ data/
|
||||
│ ├─ raw/
|
||||
│ │ ├─ transactions/
|
||||
│ │ ├─ exports/
|
||||
│ │ └─ screenshots/
|
||||
│ ├─ processed/
|
||||
│ └─ backup/
|
||||
├─ templates/
|
||||
│ ├─ bitcoin_tracking_template.xlsx
|
||||
│ ├─ transactions.csv
|
||||
│ ├─ wallets.csv
|
||||
│ └─ todo_calendar_template.csv
|
||||
├─ data/
|
||||
├─ templates/
|
||||
├─ scripts/
|
||||
│ ├─ import_excel_to_sqlite.py
|
||||
│ ├─ validate_transactions.py
|
||||
│ ├─ normalize_wallets.py
|
||||
│ └─ build_dashboard.py
|
||||
├─ sqlite/
|
||||
│ ├─ schema.sql
|
||||
│ ├─ seed.sql
|
||||
│ └─ migrations/
|
||||
├─ dashboard/
|
||||
│ ├─ streamlit_app.py
|
||||
│ └─ assets/
|
||||
└─ notes/
|
||||
├─ decisions.md
|
||||
├─ open_questions.md
|
||||
└─ changelog.md
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Was wohin gehört
|
||||
|
||||
README.md
|
||||
|
||||
Kurzer Einstieg:
|
||||
|
||||
• was das Projekt ist
|
||||
• wie man es benutzt
|
||||
• wie Excel, SQLite und Dashboard zusammenhängen
|
||||
|
||||
docs/
|
||||
|
||||
Hier dokumentierst du das Wissen:
|
||||
|
||||
• Datenmodell
|
||||
• Arbeitsweise
|
||||
• Regeln für Transaktionen
|
||||
• Importregeln
|
||||
• Kalender-/To-do-Konzept
|
||||
|
||||
data/raw/
|
||||
|
||||
Originaldaten, unverändert:
|
||||
|
||||
• Börsenexports
|
||||
• Wallet-Exports
|
||||
• Screenshots
|
||||
• CSVs von Plattformen
|
||||
|
||||
data/processed/
|
||||
|
||||
Bereinigte Daten:
|
||||
|
||||
• vereinheitlichte CSVs
|
||||
• transformierte Exporte
|
||||
• validierte Datensätze
|
||||
|
||||
templates/
|
||||
|
||||
Vorlagen:
|
||||
|
||||
• Excel-Datei
|
||||
• CSV-Vorlagen
|
||||
• To-do-/Kalender-Templates
|
||||
|
||||
scripts/
|
||||
|
||||
Python-Skripte für:
|
||||
|
||||
• Import
|
||||
• Validierung
|
||||
• Normalisierung
|
||||
• Dashboard-Aufbau
|
||||
|
||||
sqlite/
|
||||
|
||||
Alles rund um die spätere Datenbank:
|
||||
|
||||
• Schema
|
||||
• Seed-Daten
|
||||
• Migrationen
|
||||
|
||||
dashboard/
|
||||
|
||||
Später dein lokales UI:
|
||||
|
||||
• Streamlit oder anderes leichtes Frontend
|
||||
• Charts
|
||||
• Bestand
|
||||
• Transaktionsliste
|
||||
• Filter
|
||||
|
||||
notes/
|
||||
|
||||
Für laufende Entscheidungen:
|
||||
|
||||
• was wurde festgelegt
|
||||
• was ist offen
|
||||
• was ändert sich später
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
2) Excel-Vorlage
|
||||
|
||||
Die Excel-Datei sollte so aufgebaut sein, dass sie fast 1:1 als CSV in SQLite übernommen werden
|
||||
kann.
|
||||
|
||||
Blatt 1: Transaktionen
|
||||
|
||||
Pflichtfelder:
|
||||
|
||||
• id
|
||||
• datum_zeit
|
||||
• typ
|
||||
• asset
|
||||
• menge
|
||||
• preis_eur
|
||||
• gebuehren_eur
|
||||
• gesamtwert_eur
|
||||
• plattform
|
||||
• wallet_von
|
||||
• wallet_zu
|
||||
• txid
|
||||
• notiz
|
||||
|
||||
Blatt 2: Wallets
|
||||
|
||||
• wallet_id
|
||||
• name
|
||||
• typ
|
||||
• adresse
|
||||
• notiz
|
||||
|
||||
Blatt 3: Todo
|
||||
|
||||
• id
|
||||
• titel
|
||||
• status
|
||||
• faellig_am
|
||||
• prioritaet
|
||||
• notiz
|
||||
|
||||
Blatt 4: Kalender
|
||||
|
||||
• id
|
||||
• datum
|
||||
• uhrzeit
|
||||
• titel
|
||||
• kategorie
|
||||
• wiederholung
|
||||
• notiz
|
||||
|
||||
Blatt 5: Anleitung
|
||||
|
||||
Kurze Regeln:
|
||||
|
||||
• pro Zeile genau ein Vorgang
|
||||
• Datumsformat immer gleich
|
||||
• keine freien Mischfelder
|
||||
• Transaktionen und Wallets getrennt halten
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
3) To-do + Kalender mit iCloud oder Google Calendar
|
||||
|
||||
Ich würde das in zwei Ebenen aufteilen:
|
||||
|
||||
Ebene A: interne Aufgabenliste
|
||||
|
||||
Für alles, was du selbst pflegst:
|
||||
|
||||
• Transaktionsdaten sammeln
|
||||
• Wallets auflisten
|
||||
• Börsenexports exportieren
|
||||
• TxIDs ergänzen
|
||||
• Gebühren prüfen
|
||||
• doppelte Einträge bereinigen
|
||||
|
||||
Ebene B: Kalendertermine
|
||||
|
||||
Für alles, was zeitlich gebunden ist:
|
||||
|
||||
• Monatsreview
|
||||
• Wochenreview
|
||||
• Steuer-Check
|
||||
• Datenpflege-Slot
|
||||
• Kurs-/Portfolio-Review
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Integration mit Kalender
|
||||
Option 1: Google Calendar
|
||||
|
||||
Gut für:
|
||||
|
||||
• einfache API-Anbindung
|
||||
• später Automatisierung
|
||||
• Sync auf vielen Geräten
|
||||
|
||||
Option 2: iCloud Kalender
|
||||
|
||||
Gut für:
|
||||
|
||||
• Apple-Ökosystem
|
||||
• native Nutzung auf iPhone/Mac
|
||||
• persönliche Termine
|
||||
|
||||
Empfehlung
|
||||
|
||||
Wenn du automatisieren willst, ist Google Calendar meist einfacher.
|
||||
Wenn du primär Apple nutzt, kann iCloud sinnvoller sein.
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Mein Vorschlag für die Praxis
|
||||
Phase 1
|
||||
|
||||
• Projektordner anlegen
|
||||
• Excel-Vorlage erstellen
|
||||
• Dokumentation starten
|
||||
|
||||
Phase 2
|
||||
|
||||
• erste Transaktionen sammeln
|
||||
• To-dos eintragen
|
||||
• Kalendertermine definieren
|
||||
|
||||
Phase 3
|
||||
|
||||
• SQLite-Schema aufsetzen
|
||||
• Excel-Import bauen
|
||||
• Dashboard starten
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Wenn du willst, mache ich im nächsten Schritt direkt Punkt 2 als fertige Excel-Struktur zum Kopieren
|
||||
— also mit konkreten Spaltennamen und Beispielzeilen für jedes Blatt.
|
||||
|
||||
· /copy
|
||||
|
||||
· sent OSC52 copy sequence (terminal support required)
|
||||
|
||||
· /copy
|
||||
|
||||
· sent OSC52 copy sequence (terminal support required)
|
||||
|
||||
|
||||
─ ready │ gpt 5.4 mini none │ 40.6k/272k │ [██░░░░░░░░] 15% │ 1h 4m │ ✓ 17m 48s │ voice off ─ {"title
|
||||
bitcoin-finanzen ❯
|
||||
|
||||
├─ dashboard/
|
||||
└─ notes/
|
||||
|
||||
Datenprinzip
|
||||
|
||||
• Rohdaten werden getrennt von Verarbeitung gespeichert
|
||||
• CSV-Dateien dienen als einfache Austausch- und Importform
|
||||
• SQLite wird später als strukturierte Datenbasis genutzt
|
||||
• Kalender- und To-do-Daten bleiben nachvollziehbar und versionierbar
|
||||
|
||||
Bedienung
|
||||
|
||||
Geplant ist eine lokale Eingabemaske, mit der Einträge einfacher gepflegt werden können als direkt über CSV.
|
||||
|
||||
Ziele der Maske:
|
||||
|
||||
• Pflichtfelder
|
||||
• Dropdowns für feste Werte
|
||||
• weniger Tippfehler
|
||||
• saubere CSV-Ausgabe
|
||||
• später einfache Anbindung an SQLite
|
||||
|
||||
Langfristige Erweiterung
|
||||
|
||||
Später sollen möglich sein:
|
||||
|
||||
• Kalender-Synchronisation
|
||||
• Wiederholungen
|
||||
• Erinnerungen
|
||||
• Dashboard-Ansicht
|
||||
• Bitcoin-Tracking
|
||||
• Auswertung und Filter
|
||||
|
||||
Hinweise
|
||||
|
||||
Dieses Repo ist bewusst schlank gehalten und wächst schrittweise mit den Anforderungen.
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
|
||||
Überblick
|
||||
|
||||
Dieses Projekt ist ein lokales Arbeits- und Dokumentationsprojekt für persönliche Organisation.
|
||||
|
||||
Zweck
|
||||
|
||||
Das Projekt soll folgende Bereiche abdecken:
|
||||
|
||||
• To-dos
|
||||
• Kalendertermine
|
||||
• Projektdokumentation
|
||||
• später Bitcoin-Tracking
|
||||
• später SQLite-basierte Auswertung
|
||||
|
||||
Leitprinzipien
|
||||
|
||||
1. Daten sauber strukturieren
|
||||
2. Eingaben einfach halten
|
||||
3. CSV als Zwischenformat nutzbar machen
|
||||
4. später SQL-Backend ergänzen
|
||||
5. lokale Kontrolle behalten
|
||||
|
||||
Arbeitsweise
|
||||
|
||||
Es gibt zwei Ebenen:
|
||||
|
||||
1. Erfassung
|
||||
|
||||
Neue Einträge werden über eine Eingabemaske erfasst.
|
||||
|
||||
2. Speicherung
|
||||
|
||||
Die Daten werden in CSV abgelegt und später in SQLite überführt.
|
||||
|
||||
Zielbild
|
||||
|
||||
Am Ende soll das Projekt enthalten:
|
||||
|
||||
• eine einfache Eingabemaske
|
||||
• eine saubere Dokumentation
|
||||
• exportierbare Daten
|
||||
• ein lokales Dashboard
|
||||
• Kalenderanbindung
|
||||
• To-do-Verwaltung
|
||||
• später Bitcoin-Verwaltung
|
||||
|
||||
Status
|
||||
|
||||
Der Fokus liegt aktuell auf Dokumentation, Kalender und To-do.
|
||||
Bitcoin-Tracking wird später ergänzt.
|
||||
|
||||
|
||||
@@ -0,0 +1,101 @@
|
||||
|
||||
To-do- und Kalenderkonzept
|
||||
|
||||
Ziel
|
||||
|
||||
Dieses Projekt soll eine einfache Möglichkeit bieten, Aufgaben und Termine zentral zu erfassen.
|
||||
|
||||
To-do-Felder
|
||||
|
||||
Empfohlene Felder:
|
||||
|
||||
• id
|
||||
• titel
|
||||
• beschreibung
|
||||
• kategorie
|
||||
• prioritaet
|
||||
• status
|
||||
• faellig_am
|
||||
• wiederholen
|
||||
• notiz
|
||||
|
||||
Kalender-Felder
|
||||
|
||||
Empfohlene Felder:
|
||||
|
||||
• id
|
||||
• titel
|
||||
• datum
|
||||
• uhrzeit
|
||||
• dauer_min
|
||||
• kalender
|
||||
• kategorie
|
||||
• erinnerung_min
|
||||
• wiederholen
|
||||
• notiz
|
||||
|
||||
Dropdown-Werte
|
||||
|
||||
Priorität
|
||||
|
||||
• Niedrig
|
||||
• Mittel
|
||||
• Hoch
|
||||
|
||||
Status
|
||||
|
||||
• Offen
|
||||
• In Arbeit
|
||||
• Wartet
|
||||
• Erledigt
|
||||
|
||||
Wiederholen
|
||||
|
||||
• Nein
|
||||
• Täglich
|
||||
• Wöchentlich
|
||||
• Monatlich
|
||||
|
||||
Kalender
|
||||
|
||||
• Arbeit
|
||||
• Privat
|
||||
• Bitcoin
|
||||
• Todo
|
||||
|
||||
Kategorie
|
||||
|
||||
• Allgemein
|
||||
• Dokumentation
|
||||
• Erinnerung
|
||||
• Termin
|
||||
• Aufgabe
|
||||
• Sonstiges
|
||||
|
||||
Eingaberegeln
|
||||
|
||||
• Pflichtfelder müssen ausgefüllt sein
|
||||
• freie Texte nur dort, wo sie sinnvoll sind
|
||||
• Datum und Uhrzeit strikt getrennt
|
||||
• Wiederholungen nur aus erlaubten Werten
|
||||
• Kalenderziel muss auswählbar sein
|
||||
|
||||
Workflow
|
||||
|
||||
1. Eintrag über Maske anlegen
|
||||
2. Daten als CSV speichern
|
||||
3. später nach SQLite importieren
|
||||
4. optional an Google Calendar oder iCloud übergeben
|
||||
|
||||
Ziel der Maske
|
||||
|
||||
Die Maske soll die Pflege einfacher machen als direkte CSV-Bearbeitung.
|
||||
|
||||
Spätere Erweiterung
|
||||
|
||||
• Filter
|
||||
• Suchfunktion
|
||||
• Wiederholungslogik
|
||||
• Kalender-Sync
|
||||
• Erinnerungen
|
||||
• Dashboard-Auswertung
|
||||
|
||||
@@ -0,0 +1,670 @@
|
||||
Ja — ich schreibe dir die Dateien. Vorher aber die wichtige Antwort zu deinem Token:
|
||||
|
||||
Wo du Gitea-Tokens sicher hinterlegst
|
||||
|
||||
Für Hermes gehört ein Gitea-Token nicht ins Repo, sondern in die profilbezogene .env oder in eine getrennte Secrets-Datei deines
|
||||
Hermes-Profils.
|
||||
|
||||
Für dieses Profil
|
||||
|
||||
Dein aktives Profil ist:
|
||||
/opt/data/profiles/bitcoin-finanzen/
|
||||
|
||||
Dort wäre der sichere Ort typischerweise:
|
||||
|
||||
• /opt/data/profiles/bitcoin-finanzen/.env
|
||||
|
||||
oder
|
||||
|
||||
• die von Hermes verwaltete Profile-Umgebung, falls dort schon ein Secret-Store aktiv ist
|
||||
|
||||
Wichtige Regel
|
||||
|
||||
• nicht ins Git-Repo committen
|
||||
• nicht in README, Docs oder SQL-Dateien schreiben
|
||||
• nicht im Chat lassen
|
||||
|
||||
Zu deiner Vermutung
|
||||
|
||||
Ja, es kann sein, dass bereits irgendwo ein Gitea-Token liegt — aber ich kann das nicht blind annehmen.
|
||||
Wenn du willst, kann ich als Nächstes gezielt nachsehen, ob im aktiven Profil oder in der Hermes-Konfiguration bereits ein Token oder ein
|
||||
Secret-Mechanismus existiert, und dir dann sagen, wo genau du ihn hinterlegen solltest.
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Jetzt die Dateien
|
||||
|
||||
Unten sind die Texte, die ich dir für dein Repo vorschlage.
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
README.md
|
||||
|
||||
bitcoin-programm
|
||||
|
||||
Lokales Projekt zur strukturierten Erfassung und Verwaltung von:
|
||||
|
||||
• To-dos
|
||||
• Kalendereinträgen
|
||||
• Dokumentation
|
||||
• später: Bitcoin-Transaktionen und Auswertungen
|
||||
|
||||
Ziel
|
||||
|
||||
Das Projekt dient als zentrales Arbeitsverzeichnis für persönliche Verwaltung und spätere Automatisierung.
|
||||
|
||||
Geplant ist:
|
||||
|
||||
• eine einfache Eingabemaske für To-dos und Kalendertermine
|
||||
• CSV als einfache Zwischen- und Exportform
|
||||
• später ein SQLite-Backend für Auswertung und Dashboard
|
||||
• optional Sync mit Google Calendar oder iCloud Kalender
|
||||
|
||||
Aktueller Fokus
|
||||
|
||||
Der aktuelle Fokus liegt auf:
|
||||
|
||||
1. Dokumentation
|
||||
2. To-do-Erfassung
|
||||
3. Kalender-Erfassung
|
||||
4. saubere Datenstruktur für späteren Import nach SQLite
|
||||
|
||||
Bitcoin-Tracking kann später ergänzt werden.
|
||||
|
||||
Projektstruktur
|
||||
|
||||
Empfohlene Struktur:
|
||||
|
||||
─ text
|
||||
bitcoin-programm/
|
||||
├─ README.md
|
||||
├─ docs/
|
||||
├─ data/
|
||||
├─ templates/
|
||||
├─ scripts/
|
||||
├─ sqlite/
|
||||
├─ dashboard/
|
||||
└─ notes/
|
||||
|
||||
Datenprinzip
|
||||
|
||||
• Rohdaten werden getrennt von Verarbeitung gespeichert
|
||||
• CSV-Dateien dienen als einfache Austausch- und Importform
|
||||
• SQLite wird später als strukturierte Datenbasis genutzt
|
||||
• Kalender- und To-do-Daten bleiben nachvollziehbar und versionierbar
|
||||
|
||||
Bedienung
|
||||
|
||||
Geplant ist eine lokale Eingabemaske, mit der Einträge einfacher gepflegt werden können als direkt über CSV.
|
||||
|
||||
Ziele der Maske:
|
||||
|
||||
• Pflichtfelder
|
||||
• Dropdowns für feste Werte
|
||||
• weniger Tippfehler
|
||||
• saubere CSV-Ausgabe
|
||||
• später einfache Anbindung an SQLite
|
||||
|
||||
Langfristige Erweiterung
|
||||
|
||||
Später sollen möglich sein:
|
||||
|
||||
• Kalender-Synchronisation
|
||||
• Wiederholungen
|
||||
• Erinnerungen
|
||||
• Dashboard-Ansicht
|
||||
• Bitcoin-Tracking
|
||||
• Auswertung und Filter
|
||||
|
||||
Hinweise
|
||||
|
||||
Dieses Repo ist bewusst schlank gehalten und wächst schrittweise mit den Anforderungen.
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
docs/00_overview.md
|
||||
|
||||
Überblick
|
||||
|
||||
Dieses Projekt ist ein lokales Arbeits- und Dokumentationsprojekt für persönliche Organisation.
|
||||
|
||||
Zweck
|
||||
|
||||
Das Projekt soll folgende Bereiche abdecken:
|
||||
|
||||
• To-dos
|
||||
• Kalendertermine
|
||||
• Projektdokumentation
|
||||
• später Bitcoin-Tracking
|
||||
• später SQLite-basierte Auswertung
|
||||
|
||||
Leitprinzipien
|
||||
|
||||
1. Daten sauber strukturieren
|
||||
2. Eingaben einfach halten
|
||||
3. CSV als Zwischenformat nutzbar machen
|
||||
4. später SQL-Backend ergänzen
|
||||
5. lokale Kontrolle behalten
|
||||
|
||||
Arbeitsweise
|
||||
|
||||
Es gibt zwei Ebenen:
|
||||
|
||||
1. Erfassung
|
||||
|
||||
Neue Einträge werden über eine Eingabemaske erfasst.
|
||||
|
||||
2. Speicherung
|
||||
|
||||
Die Daten werden in CSV abgelegt und später in SQLite überführt.
|
||||
|
||||
Zielbild
|
||||
|
||||
Am Ende soll das Projekt enthalten:
|
||||
|
||||
• eine einfache Eingabemaske
|
||||
• eine saubere Dokumentation
|
||||
• exportierbare Daten
|
||||
• ein lokales Dashboard
|
||||
• Kalenderanbindung
|
||||
• To-do-Verwaltung
|
||||
• später Bitcoin-Verwaltung
|
||||
|
||||
Status
|
||||
|
||||
Der Fokus liegt aktuell auf Dokumentation, Kalender und To-do.
|
||||
Bitcoin-Tracking wird später ergänzt.
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
docs/01_requirements.md
|
||||
|
||||
Anforderungen
|
||||
|
||||
Hauptziel
|
||||
|
||||
Das Projekt soll eine einfache und verlässliche Verwaltung von To-dos und Kalenderterminen ermöglichen.
|
||||
|
||||
Funktionale Anforderungen
|
||||
|
||||
To-dos
|
||||
|
||||
• To-dos sollen über eine Eingabemaske erfasst werden
|
||||
• Pflichtfelder müssen vorhanden sein
|
||||
• feste Werte sollen per Dropdown gewählt werden
|
||||
• die Daten sollen als CSV exportierbar sein
|
||||
|
||||
Kalender
|
||||
|
||||
• Kalendertermine sollen über eine Eingabemaske erfasst werden
|
||||
• Datum und Uhrzeit müssen wählbar sein
|
||||
• Terminarten sollen per Dropdown auswählbar sein
|
||||
• Wiederholungen sollen unterstützt werden
|
||||
• Erinnerungen sollen vorbereitet sein
|
||||
|
||||
docs/01_requirements.md
|
||||
|
||||
Anforderungen
|
||||
|
||||
Hauptziel
|
||||
|
||||
Das Projekt soll eine einfache und verlässliche Verwaltung von To-dos und Kalenderterminen ermöglichen.
|
||||
|
||||
Funktionale Anforderungen
|
||||
|
||||
To-dos
|
||||
|
||||
• To-dos sollen über eine Eingabemaske erfasst werden
|
||||
• Pflichtfelder müssen vorhanden sein
|
||||
• feste Werte sollen per Dropdown gewählt werden
|
||||
• die Daten sollen als CSV exportierbar sein
|
||||
|
||||
Kalender
|
||||
|
||||
• Kalendertermine sollen über eine Eingabemaske erfasst werden
|
||||
• Datum und Uhrzeit müssen wählbar sein
|
||||
• Terminarten sollen per Dropdown auswählbar sein
|
||||
• Wiederholungen sollen unterstützt werden
|
||||
• Erinnerungen sollen vorbereitet sein
|
||||
|
||||
Datenhaltung
|
||||
|
||||
• CSV als Zwischenspeicher
|
||||
• später SQLite als Datenbasis
|
||||
• klare Trennung von Rohdaten und verarbeiteten Daten
|
||||
|
||||
Nicht-funktionale Anforderungen
|
||||
|
||||
• lokale Nutzung ohne Cloud-Zwang
|
||||
• später synchronisierbar mit Google Calendar oder iCloud
|
||||
• leicht verständlich und wartbar
|
||||
• importfreundlich für SQLite
|
||||
• dokumentierbar und versionierbar
|
||||
|
||||
UI-Anforderungen
|
||||
|
||||
Die Eingabemaske soll enthalten:
|
||||
|
||||
• Pflichtfelder
|
||||
• Dropdowns
|
||||
• Datumsauswahl
|
||||
• Uhrzeitauswahl
|
||||
• Textfelder für Notizen
|
||||
• klare Trennung zwischen To-do und Kalender
|
||||
|
||||
Datenqualität
|
||||
|
||||
• einheitliche Schreibweisen
|
||||
• feste Statuswerte
|
||||
• saubere Datumsformate
|
||||
• keine freien Sonderformate in Pflichtfeldern
|
||||
• keine Mischfelder für unterschiedliche Datentypen
|
||||
|
||||
Priorität
|
||||
|
||||
Aktuell ist Priorität:
|
||||
|
||||
1. Dokumentation
|
||||
2. To-do
|
||||
3. Kalender
|
||||
4. Eingabemaske
|
||||
5. SQLite
|
||||
6. Sync
|
||||
7. spätere Erweiterungen
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
docs/02_todo_calendar.md
|
||||
|
||||
To-do- und Kalenderkonzept
|
||||
|
||||
Ziel
|
||||
|
||||
Dieses Projekt soll eine einfache Möglichkeit bieten, Aufgaben und Termine zentral zu erfassen.
|
||||
|
||||
To-do-Felder
|
||||
|
||||
Empfohlene Felder:
|
||||
|
||||
• id
|
||||
• titel
|
||||
• beschreibung
|
||||
• kategorie
|
||||
• prioritaet
|
||||
• status
|
||||
• faellig_am
|
||||
• wiederholen
|
||||
• notiz
|
||||
|
||||
Kalender-Felder
|
||||
|
||||
Empfohlene Felder:
|
||||
|
||||
• id
|
||||
• titel
|
||||
• datum
|
||||
• uhrzeit
|
||||
• dauer_min
|
||||
• kalender
|
||||
• kategorie
|
||||
• erinnerung_min
|
||||
• wiederholen
|
||||
• notiz
|
||||
|
||||
Dropdown-Werte
|
||||
|
||||
Priorität
|
||||
|
||||
• Niedrig
|
||||
• Mittel
|
||||
• Hoch
|
||||
|
||||
Status
|
||||
|
||||
• Offen
|
||||
• In Arbeit
|
||||
• Wartet
|
||||
• Erledigt
|
||||
|
||||
Wiederholen
|
||||
|
||||
• Nein
|
||||
• Täglich
|
||||
• Wöchentlich
|
||||
• Monatlich
|
||||
|
||||
Kalender
|
||||
|
||||
• Arbeit
|
||||
• Privat
|
||||
• Bitcoin
|
||||
• Todo
|
||||
|
||||
Kategorie
|
||||
|
||||
• Allgemein
|
||||
• Dokumentation
|
||||
• Erinnerung
|
||||
• Termin
|
||||
• Aufgabe
|
||||
• Sonstiges
|
||||
|
||||
Eingaberegeln
|
||||
|
||||
• Pflichtfelder müssen ausgefüllt sein
|
||||
• freie Texte nur dort, wo sie sinnvoll sind
|
||||
• Datum und Uhrzeit strikt getrennt
|
||||
• Wiederholungen nur aus erlaubten Werten
|
||||
• Kalenderziel muss auswählbar sein
|
||||
|
||||
Workflow
|
||||
|
||||
1. Eintrag über Maske anlegen
|
||||
2. Daten als CSV speichern
|
||||
3. später nach SQLite importieren
|
||||
4. optional an Google Calendar oder iCloud übergeben
|
||||
|
||||
Ziel der Maske
|
||||
|
||||
Die Maske soll die Pflege einfacher machen als direkte CSV-Bearbeitung.
|
||||
|
||||
Spätere Erweiterung
|
||||
|
||||
• Filter
|
||||
• Suchfunktion
|
||||
• Wiederholungslogik
|
||||
• Kalender-Sync
|
||||
• Erinnerungen
|
||||
• Dashboard-Auswertung
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
|
||||
on
|
||||
• Wiederholungen
|
||||
• Erinnerungen
|
||||
• Dashboard-Ansicht
|
||||
• Bitcoin-Tracking
|
||||
• Auswertung und Filter
|
||||
|
||||
Hinweise
|
||||
|
||||
Dieses Repo ist bewusst schlank gehalten und wächst schrittweise mit den Anforderungen.
|
||||
|
||||
---
|
||||
## `docs/00_overview.md`
|
||||
```md
|
||||
# Überblick
|
||||
Dieses Projekt ist ein lokales Arbeits- und Dokumentationsprojekt für persönliche Organisation.
|
||||
## Zweck
|
||||
Das Projekt soll folgende Bereiche abdecken:
|
||||
- To-dos
|
||||
- Kalendertermine
|
||||
- Projektdokumentation
|
||||
- später Bitcoin-Tracking
|
||||
- später SQLite-basierte Auswertung
|
||||
## Leitprinzipien
|
||||
1. Daten sauber strukturieren
|
||||
2. Eingaben einfach halten
|
||||
3. CSV als Zwischenformat nutzbar machen
|
||||
4. später SQL-Backend ergänzen
|
||||
5. lokale Kontrolle behalten
|
||||
## Arbeitsweise
|
||||
Es gibt zwei Ebenen:
|
||||
### 1. Erfassung
|
||||
Neue Einträge werden über eine Eingabemaske erfasst.
|
||||
### 2. Speicherung
|
||||
Die Daten werden in CSV abgelegt und später in SQLite überführt.
|
||||
## Zielbild
|
||||
Am Ende soll das Projekt enthalten:
|
||||
- eine einfache Eingabemaske
|
||||
- eine saubere Dokumentation
|
||||
- exportierbare Daten
|
||||
- ein lokales Dashboard
|
||||
- Kalenderanbindung
|
||||
- To-do-Verwaltung
|
||||
- später Bitcoin-Verwaltung
|
||||
## Status
|
||||
Der Fokus liegt aktuell auf Dokumentation, Kalender und To-do.
|
||||
Bitcoin-Tracking wird später ergänzt.
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
docs/01_requirements.md
|
||||
|
||||
Anforderungen
|
||||
|
||||
Hauptziel
|
||||
|
||||
Das Projekt soll eine einfache und verlässliche Verwaltung von To-dos und Kalenderterminen ermöglichen.
|
||||
|
||||
Funktionale Anforderungen
|
||||
|
||||
To-dos
|
||||
|
||||
• To-dos sollen über eine Eingabemaske erfasst werden
|
||||
• Pflichtfelder müssen vorhanden sein
|
||||
• feste Werte sollen per Dropdown gewählt werden
|
||||
• die Daten sollen als CSV exportierbar sein
|
||||
|
||||
Kalender
|
||||
|
||||
• Kalendertermine sollen über eine Eingabemaske erfasst werden
|
||||
• Datum und Uhrzeit müssen wählbar sein
|
||||
• Terminarten sollen per Dropdown auswählbar sein
|
||||
• Wiederholungen sollen unterstützt werden
|
||||
• Erinnerungen sollen vorbereitet sein
|
||||
|
||||
Datenhaltung
|
||||
|
||||
• CSV als Zwischenspeicher
|
||||
• später SQLite als Datenbasis
|
||||
• klare Trennung von Rohdaten und verarbeiteten Daten
|
||||
|
||||
Nicht-funktionale Anforderungen
|
||||
|
||||
• lokale Nutzung ohne Cloud-Zwang
|
||||
• später synchronisierbar mit Google Calendar oder iCloud
|
||||
• leicht verständlich und wartbar
|
||||
• importfreundlich für SQLite
|
||||
• dokumentierbar und versionierbar
|
||||
|
||||
UI-Anforderungen
|
||||
|
||||
Die Eingabemaske soll enthalten:
|
||||
|
||||
• Pflichtfelder
|
||||
• Dropdowns
|
||||
• Datumsauswahl
|
||||
• Uhrzeitauswahl
|
||||
• Textfelder für Notizen
|
||||
• klare Trennung zwischen To-do und Kalender
|
||||
|
||||
Datenqualität
|
||||
|
||||
• einheitliche Schreibweisen
|
||||
• feste Statuswerte
|
||||
• saubere Datumsformate
|
||||
• keine freien Sonderformate in Pflichtfeldern
|
||||
• keine Mischfelder für unterschiedliche Datentypen
|
||||
|
||||
Priorität
|
||||
|
||||
Aktuell ist Priorität:
|
||||
|
||||
1. Dokumentation
|
||||
2. To-do
|
||||
3. Kalender
|
||||
4. Eingabemaske
|
||||
5. SQLite
|
||||
6. Sync
|
||||
7. spätere Erweiterungen
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
docs/02_todo_calendar.md
|
||||
|
||||
To-do- und Kalenderkonzept
|
||||
|
||||
Ziel
|
||||
|
||||
Dieses Projekt soll eine einfache Möglichkeit bieten, Aufgaben und Termine zentral zu erfassen.
|
||||
|
||||
To-do-Felder
|
||||
|
||||
Empfohlene Felder:
|
||||
|
||||
• id
|
||||
• titel
|
||||
• beschreibung
|
||||
• kategorie
|
||||
• prioritaet
|
||||
• status
|
||||
• faellig_am
|
||||
• wiederholen
|
||||
• notiz
|
||||
|
||||
Kalender-Felder
|
||||
|
||||
Empfohlene Felder:
|
||||
|
||||
• id
|
||||
• titel
|
||||
• datum
|
||||
• uhrzeit
|
||||
• dauer_min
|
||||
• kalender
|
||||
• kategorie
|
||||
• erinnerung_min
|
||||
• wiederholen
|
||||
• notiz
|
||||
|
||||
Dropdown-Werte
|
||||
|
||||
Priorität
|
||||
|
||||
• Niedrig
|
||||
• Mittel
|
||||
• Hoch
|
||||
|
||||
Status
|
||||
|
||||
• Offen
|
||||
• In Arbeit
|
||||
• Wartet
|
||||
• Erledigt
|
||||
|
||||
Wiederholen
|
||||
|
||||
• Nein
|
||||
• Täglich
|
||||
• Wöchentlich
|
||||
• Monatlich
|
||||
|
||||
Kalender
|
||||
|
||||
• Arbeit
|
||||
• Privat
|
||||
• Bitcoin
|
||||
• Todo
|
||||
|
||||
Kategorie
|
||||
|
||||
• Allgemein
|
||||
• Dokumentation
|
||||
• Erinnerung
|
||||
• Termin
|
||||
• Aufgabe
|
||||
• Sonstiges
|
||||
|
||||
Eingaberegeln
|
||||
|
||||
• Pflichtfelder müssen ausgefüllt sein
|
||||
• freie Texte nur dort, wo sie sinnvoll sind
|
||||
• Datum und Uhrzeit strikt getrennt
|
||||
• Wiederholungen nur aus erlaubten Werten
|
||||
• Kalenderziel muss auswählbar sein
|
||||
|
||||
Workflow
|
||||
|
||||
1. Eintrag über Maske anlegen
|
||||
2. Daten als CSV speichern
|
||||
3. später nach SQLite importieren
|
||||
4. optional an Google Calendar oder iCloud übergeben
|
||||
|
||||
Ziel der Maske
|
||||
|
||||
Die Maske soll die Pflege einfacher machen als direkte CSV-Bearbeitung.
|
||||
|
||||
Spätere Erweiterung
|
||||
|
||||
• Filter
|
||||
• Suchfunktion
|
||||
• Wiederholungslogik
|
||||
• Kalender-Sync
|
||||
• Erinnerungen
|
||||
• Dashboard-Auswertung
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
sqlite/schema.sql
|
||||
|
||||
─ sql
|
||||
PRAGMA foreign_keys = ON;
|
||||
CREATE TABLE IF NOT EXISTS todo (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
titel TEXT NOT NULL,
|
||||
beschreibung TEXT,
|
||||
kategorie TEXT NOT NULL DEFAULT 'Allgemein',
|
||||
prioritaet TEXT NOT NULL DEFAULT 'Mittel',
|
||||
status TEXT NOT NULL DEFAULT 'Offen',
|
||||
faellig_am TEXT,
|
||||
wiederholen TEXT NOT NULL DEFAULT 'Nein',
|
||||
notiz TEXT,
|
||||
created_at TEXT NOT NULL DEFAULT (datetime('now')),
|
||||
updated_at TEXT NOT NULL DEFAULT (datetime('now'))
|
||||
);
|
||||
CREATE TABLE IF NOT EXISTS calendar_event (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
titel TEXT NOT NULL,
|
||||
datum TEXT NOT NULL,
|
||||
uhrzeit TEXT NOT NULL,
|
||||
dauer_min INTEGER NOT NULL DEFAULT 60,
|
||||
kalender TEXT NOT NULL DEFAULT 'Privat',
|
||||
kategorie TEXT NOT NULL DEFAULT 'Sonstiges',
|
||||
erinnerung_min INTEGER NOT NULL DEFAULT 30,
|
||||
wiederholen TEXT NOT NULL DEFAULT 'Nein',
|
||||
notiz TEXT,
|
||||
created_at TEXT NOT NULL DEFAULT (datetime('now')),
|
||||
updated_at TEXT NOT NULL DEFAULT (datetime('now'))
|
||||
);
|
||||
CREATE TABLE IF NOT EXISTS settings (
|
||||
key TEXT PRIMARY KEY,
|
||||
value TEXT NOT NULL
|
||||
);
|
||||
CREATE INDEX IF NOT EXISTS idx_todo_faellig_am ON todo(faellig_am);
|
||||
CREATE INDEX IF NOT EXISTS idx_todo_status ON todo(status);
|
||||
CREATE INDEX IF NOT EXISTS idx_calendar_event_datum ON calendar_event(datum);
|
||||
CREATE INDEX IF NOT EXISTS idx_calendar_event_kalender ON calendar_event(kalender);
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Zur Gitea-Token-Frage nochmal konkret
|
||||
|
||||
Wenn du willst, sollten wir den Token nicht im Repo und auch nicht in normalen Projektdateien speichern, sondern in einem Profil-Secret.
|
||||
|
||||
Wahrscheinlich sinnvoll:
|
||||
|
||||
• Hermes-Profil .env
|
||||
• oder ein lokales Secret-File im Profil
|
||||
• anschließend Zugriff nur über die Shell-Umgebung
|
||||
|
||||
Wenn du möchtest, kann ich als Nächstes:
|
||||
|
||||
1. prüfen, ob es in diesem Profil schon einen Gitea-Token gibt
|
||||
2. dir sagen, wo du ihn sauber ablegen kannst
|
||||
3. dann das Repo-Layout auf Gitea aktualisieren
|
||||
|
||||
────────────────────────────────────
|
||||
|
||||
Nächster sinnvoller Schritt
|
||||
@@ -0,0 +1,37 @@
|
||||
─ sql
|
||||
PRAGMA foreign_keys = ON;
|
||||
CREATE TABLE IF NOT EXISTS todo (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
titel TEXT NOT NULL,
|
||||
beschreibung TEXT,
|
||||
kategorie TEXT NOT NULL DEFAULT 'Allgemein',
|
||||
prioritaet TEXT NOT NULL DEFAULT 'Mittel',
|
||||
status TEXT NOT NULL DEFAULT 'Offen',
|
||||
faellig_am TEXT,
|
||||
wiederholen TEXT NOT NULL DEFAULT 'Nein',
|
||||
notiz TEXT,
|
||||
created_at TEXT NOT NULL DEFAULT (datetime('now')),
|
||||
updated_at TEXT NOT NULL DEFAULT (datetime('now'))
|
||||
);
|
||||
CREATE TABLE IF NOT EXISTS calendar_event (
|
||||
id INTEGER PRIMARY KEY AUTOINCREMENT,
|
||||
titel TEXT NOT NULL,
|
||||
datum TEXT NOT NULL,
|
||||
uhrzeit TEXT NOT NULL,
|
||||
dauer_min INTEGER NOT NULL DEFAULT 60,
|
||||
kalender TEXT NOT NULL DEFAULT 'Privat',
|
||||
kategorie TEXT NOT NULL DEFAULT 'Sonstiges',
|
||||
erinnerung_min INTEGER NOT NULL DEFAULT 30,
|
||||
wiederholen TEXT NOT NULL DEFAULT 'Nein',
|
||||
notiz TEXT,
|
||||
created_at TEXT NOT NULL DEFAULT (datetime('now')),
|
||||
updated_at TEXT NOT NULL DEFAULT (datetime('now'))
|
||||
);
|
||||
CREATE TABLE IF NOT EXISTS settings (
|
||||
key TEXT PRIMARY KEY,
|
||||
value TEXT NOT NULL
|
||||
);
|
||||
CREATE INDEX IF NOT EXISTS idx_todo_faellig_am ON todo(faellig_am);
|
||||
CREATE INDEX IF NOT EXISTS idx_todo_status ON todo(status);
|
||||
CREATE INDEX IF NOT EXISTS idx_calendar_event_datum ON calendar_event(datum);
|
||||
CREATE INDEX IF NOT EXISTS idx_calendar_event_kalender ON calendar_event(kalender);
|
||||
|
||||
Reference in New Issue
Block a user