24 KiB
24 KiB
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