670 lines
24 KiB
Markdown
670 lines
24 KiB
Markdown
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 |