second commit, initializing content
This commit is contained in:
Dominik Schäfer
@@ -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
|
||||
Reference in New Issue
Block a user