86 lines
3.4 KiB
Markdown
86 lines
3.4 KiB
Markdown
# Plán: /todo skill a unifikace /note, /remind, /keep
|
|
|
|
## Cíl
|
|
Prozkoumat všechny možné architektonické přístupy k vytvoření `/todo` skillu a případné unifikaci s existujícími skilly `/note`, `/remind`, `/keep`. Žádná implementace dokud plán není schválen.
|
|
|
|
## Fáze 1: Brainstorming alternativních přístupů
|
|
|
|
### 1.1 Event-sourcing / append-only log
|
|
- Místo CRUD v SQLite: každá akce je immutable event (`TaskCreated`, `TaskCompleted`, `TaskDeleted`)
|
|
- Aktuální stav se materializuje z event logu
|
|
- Výhody: audit trail, undo/redo, distribuovaná synchronizace
|
|
- Nevýhody: komplexita, overkill pro osobní asistenta
|
|
|
|
### 1.2 File-based s Git history
|
|
- Každý úkol = jeden markdown file v `tasks/` directory
|
|
- Git commit = historie změn
|
|
- Výhody: lidsky čitelné, diff-friendly, Git jako audit trail
|
|
- Nevýhody: pomalé listování, race conditions při paralelním zápisu, složité vyhledávání
|
|
|
|
### 1.3 SQLite + JSONB flex schema
|
|
- Jedna tabulka `items` s `data JSONB` sloupcem
|
|
- Každý typ (note, todo, reminder, keep) má vlastní schema uvnitř JSON
|
|
- Výhody: extrémní flexibilita, žádné ALTER TABLE migrace
|
|
- Nevýhody: ztráta typové bezpečnosti, složité dotazy, SQLite JSONB je relativně nové
|
|
|
|
### 1.4 Graph-based (RDF / knowledge graph)
|
|
- Úkoly a poznámky jako uzly v grafu, vztahy jako hrany
|
|
- "úkol X souvisí s poznámkou Y", "úkol Z závisí na úkolu W"
|
|
- Výhody: bohaté vztahy mezi entitami
|
|
- Nevýhody: obrovská komplexita, žádný jednoduchý CLI
|
|
|
|
### 1.5 Hybrid: SQLite + Markdown export
|
|
- Primární storage SQLite (rychlé dotazy, fulltext search)
|
|
- Periodický export do markdown (čitelnost, Git backup)
|
|
- Výhody: kombinuje výhody obou světů
|
|
- Nevýhody: duplicitní data, synchronizační problém
|
|
|
|
### 1.6 Plugin architektura
|
|
- Jeden core skill `/item` s rozhraním
|
|
- `/note`, `/todo`, `/remind`, `/keep` jako pluginy registrující se do core
|
|
- Výhody: extensibility, čisté separation of concerns
|
|
- Nevýhody: potřebuje plugin API v nanobot frameworku (neexistuje)
|
|
|
|
### 1.7 CLI-first s TUI
|
|
- Místo chat-based: terminal UI (např. `taskwarrior`, `todo.txt`)
|
|
- Nanobot jen wrapper volající externí CLI
|
|
- Výhody: battle-tested tools, offline použití
|
|
- Nevýhody: závislost na externím toolu, méně integrace s LLM
|
|
|
|
## Fáze 2: Hlubší analýza 3 nejslibnějších variant
|
|
|
|
Z fáze 1 vybrat 3 varianty pro detailní pro/contra:
|
|
- Varianta C z předchozí analýzy (konvergence / thin wrapper)
|
|
- Varianta 1.3 (SQLite + JSONB flex schema)
|
|
- Varianta 1.5 (hybrid SQLite + Markdown)
|
|
|
|
Pro každou variantu:
|
|
- Datový model (ER diagram / schema)
|
|
- Příkazová struktura (všechny subcommands)
|
|
- Migrace z existujících skillů
|
|
- Testovací strategie
|
|
- Maintenance overhead
|
|
- User experience flow
|
|
|
|
## Fáze 3: Rozhodovací kritéria a scoring
|
|
|
|
Definovat vážená kritéria:
|
|
- Jednoduchost implementace (30%)
|
|
- Jednoduchost použití (25%)
|
|
- Extensibility (15%)
|
|
- Data integrity / reliability (15%)
|
|
- Performance (10%)
|
|
- Aesthetics / "feels right" (5%)
|
|
|
|
Každá varianta dostane skóre 1-5 v každém kritériu.
|
|
|
|
## Fáze 4: Finální doporučení
|
|
|
|
Na základě scoringu vybrat vítěznou variantu.
|
|
Popis: proč právě tato, co se stane s existujícími skilly, roadmap implementace.
|
|
|
|
## Omezení
|
|
- Žádná implementace dokud plán není explicitně schválen
|
|
- Analýza musí být kompletní — žádné "to se vyřeší později"
|
|
- Každá varianta musí mít konkrétní pro/contra, ne obecné fráze
|