DBAdmin/brain/raw/articles/One_file_diary.md

## ✅ Najprostsze i najczęściej polecane podejście

### **Jeden plik `.txt` / `.md` jako dziennik pracy**

To nie żart – to świadomie opisywany i stosowany system.

**Opis systemu (źródło):**  
Autor opisuje prowadzenie **jednego, rosnącego pliku tekstowego**, gdzie każdy dzień to nowa sekcja, a wszystko jest append-only.  
👉 <https://jeffhuang.com/productivity_text_file/> [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

**Dlaczego to działa:**

*   1 plik = zero narzutu
*   grep / search działa błyskawicznie
*   nadaje się idealnie na „co robiłem danego dnia”
*   versioning przez Git (jeśli chcesz)

**Przykład formatu:**

```txt
2026-03-13
- 08:30 analiza błędu ETL
- 09:10 fix indeksu w SQL Server
- 10:05 call z Adrianem
```

***

## ✅ Jeśli chcesz „system”, ale dalej **plain text**

### **Plaintext Productivity**

To nie aplikacja, tylko **metodyka** oparta o pliki tekstowe.

👉 <https://plaintext-productivity.net/> [\[plaintext-...tivity.net\]](https://plaintext-productivity.net/)

Zawiera:

*   work log / journal
*   taski
*   notatki
    Wszystko w `.txt` / `.md`

***

## ✅ Gotowe narzędzie, ale nadal **jeden plik**

### **RedNotebook**

*   open‑source
*   dziennik pracy
*   dane przechowywane jako **plain text**

👉 <https://rednotebook.app/>  
(ujęty w zestawieniu plain‑text tools) [\[github.com\]](https://github.com/tehtbl/awesome-note-taking)

***

## ✅ Developer‑friendly (pewnie najbliżej Twojego stylu)

### **Obsidian / VS Code + 1 plik Markdown**

Nie jako „system notatek”, tylko **jeden plik `worklog.md`**.

Obsidian:
👉 <https://obsidian.md>  
VS Code:
👉 <https://code.visualstudio.com/>

Markdown = plain text  
Możesz:

*   trzymać to w repo
*   robić commit per dzień
*   mieć pełną historię

***

## ✅ Hardcore / UNIX‑style

### **Org‑mode (Emacs) – jeden plik `worklog.org`**

Jeśli lubisz minimalizm + automatyzację:

*   timestamps
*   clock-in / clock-out
*   wszystko w jednym pliku

👉 <https://orgmode.org/>

***

## 🔍 TL;DR – jeśli chcesz tylko **link**

Najbliżej Twojego opisu:

*   **<https://jeffhuang.com/productivity_text_file/>** – dokładnie „logowanie tego co się robi w jednym pliku tekstowym” [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

***

## 1. Czym **jest** system jednego pliku tekstowego

To **append‑only dziennik pracy**, w którym:

*   **wszystkie działania** (zadania, spotkania, decyzje, problemy)
*   są zapisywane **chronologicznie**
*   w **jednym pliku tekstowym** (`.txt` albo `.md`)
*   bez przenoszenia danych między narzędziami

Autor systemu wprost opisuje, że *porzucił task managery, notatniki i aplikacje* na rzecz **jednego pliku**, który rośnie w czasie i jest głównym źródłem prawdy. [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

To **nie jest TODO‑lista**, tylko **dziennik operacyjny**.

***

## 2. Fundamentalne zasady (najważniejsza część)

### ✅ 1. Jeden plik = jedno źródło prawdy

Nie ma:

*   osobnych notatek
*   osobnych tasków
*   osobnych dzienników

Wszystko trafia do **tego samego pliku**. [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

***

### ✅ 2. Chronologia ważniejsza niż struktura

Wpisy są:

*   dzienne
*   liniowe
*   nieprzenoszone wstecz

Autor podkreśla, że **nie reorganizuje historii** — nowy dzień = nowa sekcja, dopisywana na koniec pliku. [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

***

### ✅ 3. Append‑only (brak „sprzątania”)

*   stare wpisy **nie są kasowane**
*   zakończone taski **zostają**
*   plik jest **historią pracy**, nie tylko listą zadań

To kluczowa różnica względem Jira / Todoist / Notion. [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

***

## 3. Minimalny, kanoniczny format

Najczęściej stosowany (i opisany w źródle) format wygląda tak:

```txt
2026-03-13
- 08:30 analiza błędu ETL (INC0783182)
- 09:05 poprawka indeksu na tbl_orders
- 10:00 sync z zespołem
- 11:40 decyzja: rollback joba nocnego
```

Ważne:

*   **data = nagłówek**
*   **jedna linia = jedno zdarzenie**
*   wpisy są „co zrobiłem”, nie „co planuję” [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

***

## 4. Jak wygląda typowy dzień pracy w tym systemie

Zgodnie z opisem autora: [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

1.  **Na koniec dnia**
    *   dopisujesz listę rzeczy zaplanowanych na jutro (z kalendarza)
2.  **W trakcie dnia**
    *   dopisujesz kolejne linie
3.  **Nic nie „odhaczasz”**
    *   fakt wykonania = wpis w logu

Czyli:

*   kalendarz → plan
*   plik tekstowy → rzeczywistość

***

## 5. Dlaczego to działa (technicznie, nie psychologicznie)

Źródła wskazują na konkretne zalety: [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/), [\[plaintext-...tivity.net\]](https://plaintext-productivity.net/)

### 🔹 Zero kontekstu narzędzia

*   nie „zarządzasz systemem”
*   tylko zapisujesz fakty

### 🔹 Pełna przeszukiwalność

*   `Ctrl+F`
*   `grep`
*   `ripgrep`

### 🔹 Audyt i retrospekcja

Masz:

*   historię decyzji
*   historię problemów
*   historię realnej pracy (nie planów)

***

## 6. Wariant „inżynierski” (często stosowany)

Chociaż źródła opisują ideę, **praktycy** (dev / infra / DB) bardzo często łączą to z:

*   **Markdown (`worklog.md`)**
*   **Git**
*   commit = dzień pracy

To nadal **jeden plik**, tylko z wersjonowaniem (to jest rozszerzenie idei, nie sprzeczne z nią).

***

## 7. Czego TEN system **nie robi** (i to jest celowe)

Na podstawie opisu źródeł: [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

*   ❌ nie priorytetyzuje
*   ❌ nie przypomina
*   ❌ nie liczy czasu
*   ❌ nie optymalizuje workflow

To **dziennik operacyjny**, nie system zarządzania.

***

## 8. Dla kogo to jest szczególnie dobre

Z opisu i praktyki:

*   DBA / SRE
*   DevOps
*   Backend
*   ETL / Data
*   Osoby pracujące incydentowo

Czyli dokładnie **styl pracy, który masz** (incydenty, debug, decyzje, retry, rollback).

***

## 9. Najważniejsza myśl na koniec

> „To nie plik jest systemem.  
> Systemem jest nawyk zapisywania faktów w jednym miejscu.”

— sens podejścia Jeffa Huanga [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)

# praktyczny szablon workloga pod DBA / ETL
***

# 📘 `worklog.md` — DBA / ETL

```md
# WORKLOG

==================================================
2026-03-13 (Fri)
==================================================

## Plan dnia (z kalendarza)
- [ ] Monitoring nocnych jobów ETL
- [ ] Analiza INC0783182
- [ ] Sync z zespołem EU One

## Operacje / faktyczne działania
08:25  Sprawdzenie statusu nocnych jobów (Airflow)
08:40  Job `etl_orders_delta` FAILED – timeout na source
08:55  Analiza execution plan (SQL Server)
09:20  Dodany indeks NONCLUSTERED na dbo.orders(order_date)
09:32  Re-run joba – SUCCESS

## Incydenty / problemy
- INC0783182
  - Objaw: timeout ETL po deployu
  - Przyczyna: brak indeksu po migracji
  - Działanie: hotfix (indeks)
  - Status: ✅ zamknięty

## Decyzje techniczne
- ✅ zostawić indeks permanentnie
- ❌ nie zwiększać timeoutu ETL (root cause fixed)

## Zmiany w danych / DB
- dbo.orders
  - dodany indeks: IX_orders_order_date
  - impact: +15% write cost (akceptowalne)

## Ryzyka / follow‑up
- [ ] sprawdzić inne joby zależne od dbo.orders
- [ ] dodać check indeksów do pipeline CI

## Notatki luźne
- Po deployu schema diff nie wykrył brakującego indeksu
- Do omówienia na retro

--------------------------------------------------
```

***

## 🔑 Dlaczego ten szablon działa (DBA/ETL‑specific)

### 1. **Rozdziela plan od rzeczywistości**

*   `Plan dnia` = intencja
*   `Operacje` = fakty  
    To bardzo ważne przy audycie i retrospekcjach.

***

### 2. **Incydenty mają własne miejsce**

Nie giną w strumieniu:

```md
## Incydenty / problemy
```

To ułatwia:

*   pisanie post‑mortem
*   raportowanie
*   przypominanie „dlaczego coś zmieniliśmy”

***

### 3. **Decyzje techniczne są jawne**

To jest złoto po 3 miesiącach:

```md
## Decyzje techniczne
```

Nie „co zrobiłem”, tylko **dlaczego**.

***

### 4. **Zmiany w DB są logowane jak changelog**

Sekcja:

```md
## Zmiany w danych / DB
```

To zastępuje:

*   osobne notatki
*   pamięć zespołową
*   „kto dodał ten indeks?!”

***

## ✅ Minimalna wersja (jeśli chcesz ultra‑lean)

Jeśli wolisz **jeszcze prostsze**:

```md
2026-03-13
08:40 job etl_orders_delta FAILED – timeout
09:20 analiza execution plan
09:32 dodany indeks IX_orders_order_date
09:40 rerun job – OK
DECYZJA: nie zwiększamy timeoutu
```

To nadal **pełnoprawny system**.

***

## ✅ Wariant „hardcore DBA”

Dodatkowe prefiksy (opcjonalne):

```txt
[INC] INC0783182 timeout ETL
[SQL] execution plan scan on dbo.orders
[FIX] added IX_orders_order_date
[DEC] no timeout increase
[RISK] other jobs depend on orders
```

Potem:

```bash
grep "\[INC\]" worklog.md
grep "\[DEC\]" worklog.md
```

***

## ✅ Jak używać (ważne, ale krótkie)

*   **jeden plik**
*   **codziennie nowa sekcja**
*   **nie poprawiasz historii**
*   **piszesz fakty, nie opisy literackie**


***

### 📊 Diagram: Worklog DBA / ETL (one‑file system)

```mermaid
flowchart TD
    A[Start dnia] --> B["Plan dnia<br/>(z kalendarza)"]
    B --> C[Operacje / faktyczne działania]
    
    C --> D{Czy wystąpił problem?}
    
    D -- Nie --> E[Kontynuacja pracy]
    E --> C
    
    D -- Tak --> F[Incydent / Problem]
    F --> G["Analiza techniczna<br/>(SQL / ETL / Infra)"]
    
    G --> H{Decyzja techniczna}
    
    H --> I["Fix / Zmiana w DB<br/>(indeks, config, kod)"]
    I --> J[Re-run / Weryfikacja]
    
    J --> K{Sukces?}
    K -- Tak --> L[Zamknięcie incydentu]
    K -- Nie --> G
    
    L --> M[Log decyzji<br/>i zmian w DB]
    M --> N[Follow-up / Ryzyka]
    
    N --> O[Koniec dnia]
```

***

### 🧠 Jak czytać ten diagram (krótko)

*   **Plan dnia** → tylko intencja
*   **Operacje** → faktyczne działania (logowane linia po linii)
*   **Incydent** → osobna ścieżka (nie ginie w logu)
*   **Decyzja techniczna** → jawna, zapisana
*   **Zmiany w DB** → traktowane jak changelog
*   **Follow‑up** → rzeczy do sprawdzenia później

Wszystko trafia do **jednego pliku tekstowego**, w kolejnych sekcjach dnia.

***

### ✅ Wersja uproszczona (jeśli chcesz do README)



Pewnie — poniżej masz dopasowany diagram Mermaid **pod SQL Server + Airflow**, z typowymi ścieżkami: **DAG run → staging → transformy w SQL Server → walidacja → publikacja**, a przy awarii: **triage w Airflow logs + metryki/alerty + ServiceNow + działania DBA**. Dodałem też miejsca na logowanie w Twoim **worklogu**.

W diagramie uwzględniłem, że:

*   Airflow ma **logi per task/DAG** (np. w bucketach / Composer) jak w runbookach, [\[EU Analyti...k (EUANAP) | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/197919037/EU+Analytics+Platform+Runbook+EUANAP)
*   Monitorowanie/alertowanie po stronie DB jest standardowo podpinane pod **Splunk** (zgodnie z „MS SQL – Monitoring Standards”), [\[MS SQL - M...Standards | PDF\]](https://mydnb.sharepoint.com/sites/theHub-Technology/Documents%20Database%20Management/MS%20SQL%20-%20Monitoring%20Standards.pdf?web=1)
*   W runbooku „Shipping 2.0” jest przykład, że monitorowanie jest realizowane przez **Airflow DAG monitor + email na failure**. [\[Shipping 2.0 | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/271386232/Shipping+2.0)

***

## 🧩 Diagram: Worklog + Airflow + SQL Server (DBA/ETL)



***

### 💡 Mini-legenda (żeby było „DBA-friendly”)

*   **Airflow logs**: miejsce startu triage (per task), często przechowywane centralnie (np. bucket/Composer). [\[EU Analyti...k (EUANAP) | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/197919037/EU+Analytics+Platform+Runbook+EUANAP)
*   **Splunk**: typowe narzędzie enterprise do monitoringu/alertów SQL Server (metryki, progi, routing). [\[MS SQL - M...Standards | PDF\]](https://mydnb.sharepoint.com/sites/theHub-Technology/Documents%20Database%20Management/MS%20SQL%20-%20Monitoring%20Standards.pdf?web=1)
*   **Airflow DAG monitor + email na failure**: częsty model alertowania dla pipeline’ów. [\[Shipping 2.0 | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/271386232/Shipping+2.0)

***
Pewnie — poniżej masz dopasowany diagram Mermaid **pod SQL Server + Airflow**, z typowymi ścieżkami: **DAG run → staging → transformy w SQL Server → walidacja → publikacja**, a przy awarii: **triage w Airflow logs + metryki/alerty + ServiceNow + działania DBA**. Dodałem też miejsca na logowanie w Twoim **worklogu**.

W diagramie uwzględniłem, że:

*   Airflow ma **logi per task/DAG** (np. w bucketach / Composer) jak w runbookach, [\[EU Analyti...k (EUANAP) | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/197919037/EU+Analytics+Platform+Runbook+EUANAP)
*   Monitorowanie/alertowanie po stronie DB jest standardowo podpinane pod **Splunk** (zgodnie z „MS SQL – Monitoring Standards”), [\[MS SQL - M...Standards | PDF\]](https://mydnb.sharepoint.com/sites/theHub-Technology/Documents%20Database%20Management/MS%20SQL%20-%20Monitoring%20Standards.pdf?web=1)
*   W runbooku „Shipping 2.0” jest przykład, że monitorowanie jest realizowane przez **Airflow DAG monitor + email na failure**. [\[Shipping 2.0 | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/271386232/Shipping+2.0)

***

## 🧩 Diagram: Worklog + Airflow + SQL Server (DBA/ETL)

```mermaid
flowchart TD
    A[Start dnia] --> WL1[Worklog\nPlan dnia\nDAG-i / okna / incydenty]

    WL1 --> AF0[Airflow Scheduler]
    AF0 --> AF1[Trigger DAG]
    AF1 --> AF2{Stan DAG}

    AF2 -- SUCCESS --> OK0[Worklog\nDAG OK\nczas + dag_id + run_id]

    AF2 -- FAILED --> TRI0[Triage\nAirflow task logs]
    TRI0 --> TRI1[Worklog\nINC / Problem\nDAG + task + error]

    TRI0 --> L1[Airflow Logs]
    L1 --> TRI2{Typ błędu}

    AF1 --> STG[Staging / Landing]
    STG --> LOAD[Load step\nBCP / SSIS / Python]
    LOAD --> MSSQL["(SQL Server)"]

    MSSQL --> TSQL[Transformacje T-SQL]
    TSQL --> DQ[Data Quality Checks]
    DQ --> PUB[Publish / downstream]
    PUB --> OK0

    TRI2 -- DB --> DB0[SQL Diagnostics]
    DB0 --> DB1[Waits / Locks / IO / TempDB]
    DB1 --> DB2{Akcja}

    DB2 -- Hotfix --> FIX1[DB Fix\nIndex / Stats / Config]
    DB2 -- Mitigation --> FIX2[Mitigation\nRollback / Disable step]
    DB2 -- Escalate --> SN0[ServiceNow / ECC]

    TRI2 -- ETL --> ETL0[ETL Diagnostics]
    ETL0 --> ETL1[Schema / Source / Timeout]
    ETL1 --> ETL2{Akcja}

    ETL2 -- Retry --> RERUN[Rerun DAG]
    ETL2 -- Fix --> CODEFIX[Fix DAG / Operator]
    ETL2 -- Escalate --> SN0

    FIX1 --> RERUN
    FIX2 --> RERUN
    CODEFIX --> RERUN
    RERUN --> AF2

    FIX1 --> WL2[Worklog\nZmiany w DB]
    FIX2 --> WL3[Worklog\nDecyzje techniczne]
    CODEFIX --> WL4[Worklog\nZmiany ETL]
    SN0 --> WL5[Worklog\nTicket INC/CHG]

    WL2 --> END[Koniec dnia]
    WL3 --> END
    WL4 --> END
    WL5 --> END
```

***

### 💡 Mini-legenda (żeby było „DBA-friendly”)

*   **Airflow logs**: miejsce startu triage (per task), często przechowywane centralnie (np. bucket/Composer).
*   **Splunk**: typowe narzędzie enterprise do monitoringu/alertów SQL Server (metryki, progi, routing).
*   **Airflow DAG monitor + email na failure**: częsty model alertowania dla pipeline’ów.
***

Pewnie — poniżej masz **w pełni działający SKILL do OpenClaw** (folder skill‑a z `SKILL.md` + szablony) oraz **wersję README‑ready** do wrzucenia do repo/`skills/`.

Oparłem format o to, jak OpenClaw rozumie skills: **katalog z plikiem `SKILL.md` (YAML frontmatter + instrukcje)** oraz to, gdzie OpenClaw skills ładuje i jaka jest precedencja (`<workspace>/skills` → `~/.openclaw/skills` → bundled).\
Dodałem też notkę o bezpieczeństwie i *exec approvals* (gdybyś kiedyś chciał dopiąć `exec`), zgodnie z dokumentacją OpenClaw. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills) [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/exec-approvals), [\[openclaw-d....amcp.site\]](https://openclaw-docs.amcp.site/en/tools/exec)

***

# 1) SKILL: `dba-etl-worklog` (gotowy katalog)

## Struktura katalogu (wrzuć do `skills/dba-etl-worklog/`)

```text
skills/
  dba-etl-worklog/
    SKILL.md
    templates/
      day.md
      airflow-sqlserver-flow.mmd
```

> Lokalizacje, które OpenClaw skanuje na skills: `Bundled`, `~/.openclaw/skills`, `<workspace>/skills` — a workspace ma najwyższy priorytet. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)

***

## `skills/dba-etl-worklog/SKILL.md`

> To jest “serce” skill‑a: YAML frontmatter + instrukcje operacyjne dla agenta.

````md
---
name: dba-etl-worklog
version: 1.0.0
description: "One-file Worklog dla DBA/ETL (SQL Server + Airflow): twórz dzienną sekcję, dopisuj wpisy, prowadź incydenty, decyzje, zmiany DB i generuj diagram Mermaid."
trigger: "worklog|log pracy|dziennik pracy|dba worklog|etl worklog|airflow worklog|sql server worklog|wpis do workloga|sekcja workloga|diagram airflow sqlserver"
tools: [filesystem]
author: "Paweł Domański"
---

# DBA/ETL Worklog (SQL Server + Airflow)

## Cel
Utrzymuj jeden plik (domyślnie `worklog.md`) jako źródło prawdy: plan dnia + faktyczne operacje + incydenty + decyzje + zmiany DB + follow-up.
Skill ma:
1) tworzyć dzienną sekcję (jeśli nie istnieje),
2) dopisywać wpisy do właściwej sekcji,
3) utrzymywać porządek (append-only, bez przepisywania historii),
4) generować diagram Mermaid dla Airflow + SQL Server.

## Zasady bezpieczeństwa (twarde)
- NIE zapisuj sekretów: haseł, connection stringów, tokenów, pełnych danych wrażliwych.
- Wpisuj identyfikatory i referencje: `INC...`, `CHG...`, `dag_id`, `run_id`, `task_id`, nazwy tabel/indeksów, ale bez sekretów.
- Ten skill używa tylko `filesystem` (read/write). Nie uruchamiaj komend powłoki.

## Pliki
- Główny plik workloga: `./worklog.md` (w katalogu roboczym/workspace).
- Szablon dnia: `templates/day.md`
- Diagram Mermaid: `templates/airflow-sqlserver-flow.mmd`

## Jak działa (procedura)
### 1) Ustal ścieżkę workloga
Domyślnie: `worklog.md` w root workspace.
Jeśli użytkownik poda inną ścieżkę (np. `notes/worklog.md`) – użyj jej.

### 2) Jeśli `worklog.md` nie istnieje – utwórz
Utwórz plik i wstaw nagłówek:
- `# WORKLOG`
- krótka notka “append-only”
- pusta linia

### 3) Zapewnienie dziennej sekcji
Dla bieżącej daty (format: `YYYY-MM-DD`) sprawdź czy istnieje blok:

==================================================
YYYY-MM-DD (Day)
==================================================

Jeśli nie istnieje:
- wczytaj `templates/day.md`,
- podstaw `{{DATE}}` i `{{DOW}}`,
- dopisz na koniec `worklog.md`.

### 4) Dopisywanie wpisów
W zależności od intencji użytkownika dopisz do jednej z sekcji:
- `## Operacje / faktyczne działania`  → wpisy z godziną (HH:MM)
- `## Incydenty / problemy`            → wpisy INC/Problem
- `## Decyzje techniczne`              → decyzje i uzasadnienie
- `## Zmiany w danych / DB`            → indeksy, stats, config, hotfix
- `## Ryzyka / follow-up`              → checkboxy `[ ]`
- `## Notatki luźne`                   → kontekst

Zasada dopisywania:
- Nie edytuj starych dni.
- Dopisuj na końcu właściwej sekcji w aktualnym dniu.
- Jeśli w sekcji nie ma jeszcze treści – dopisz jako pierwszą linię.

### 5) Generowanie diagramu Mermaid (Airflow + SQL Server)
Jeśli użytkownik prosi o diagram:
- wczytaj `templates/airflow-sqlserver-flow.mmd`,
- zwróć go w wiadomości (README-ready),
- opcjonalnie wstaw do `worklog.md` pod sekcją `## Diagram` (jeżeli user chce mieć w pliku).

WAŻNE: Mermaid parsing
- Nie używaj cudzysłowów w labelach węzłów.
- Zamiast `<br/>` używaj `\n` w labelach.

## Odpowiedzi (format)
- Gdy tworzysz/aktualizujesz plik: napisz co zmieniłeś i gdzie (ścieżka).
- Gdy generujesz diagram: zwróć gotowy blok ```mermaid ... ```.

## Przykładowe polecenia użytkownika (obsługuj)
- "stwórz dzisiejszą sekcję workloga"
- "dopisz: 09:20 dodany indeks IX_orders_order_date"
- "dodaj incydent INC0783182: timeout na tasku load_orders"
- "zapisz decyzję: nie zwiększamy timeoutu, fixujemy indeks"
- "wygeneruj diagram airflow + sql server"
````

***

## `skills/dba-etl-worklog/templates/day.md`

```md
==================================================
{{DATE}} ({{DOW}})
==================================================

## Plan dnia (z kalendarza)
- [ ] Monitoring DAG-ów / okna ładowań
- [ ] Priorytetowe incydenty (INC/CHG)
- [ ] Review: failure/retry z nocy

## Operacje / faktyczne działania
<!-- format: HH:MM  opis -->
<!-- 08:25  Sprawdzenie statusu DAG X -->
<!-- 09:20  Analiza execution plan / index -->

## Incydenty / problemy
<!-- format:
- INCxxxxx
  - Objaw:
  - Przyczyna:
  - Działanie:
  - Status: ✅/🟡/❌
  - Airflow: dag_id/run_id/task_id
  - SQL: instance/db/object
-->

## Decyzje techniczne
<!-- format:
- ✅/❌ decyzja + krótki powód
-->

## Zmiany w danych / DB
<!-- format:
- db.schema.object
  - zmiana:
  - impact:
-->

## Ryzyka / follow-up
- [ ] ...

## Notatki luźne
- ...
```

***

## `skills/dba-etl-worklog/templates/airflow-sqlserver-flow.mmd` (diagram)

To jest **Twoja poprawiona, parsująca się wersja**, bez `"` i z `\n` zamiast `<br/>`.



***

# 2) README‑ready (gotowe do wklejenia do repo)

Poniżej masz kompletną sekcję README (opis + instalacja + użycie + diagram).

## `README.md`

````md
# DBA/ETL Worklog (OpenClaw Skill)

Skill do OpenClaw, który pomaga prowadzić **jeden plik workloga** (`worklog.md`) dla DBA/ETL z naciskiem na **SQL Server + Airflow**:
- tworzy dzienną sekcję (YYYY-MM-DD),
- dopisuje wpisy do właściwych sekcji (operacje, incydenty, decyzje, zmiany DB),
- generuje diagram Mermaid (Airflow → SQL Server → triage → fix → rerun).

## Instalacja

OpenClaw ładuje skills z kilku lokalizacji, m.in. z katalogu workspace:  
`<workspace>/skills` (najwyższy priorytet) oraz `~/.openclaw/skills`.  
Precedencja: workspace → `~/.openclaw/skills` → bundled.  
Szczegóły: docs OpenClaw. 

1. Skopiuj katalog:
   - `skills/dba-etl-worklog/`
   do:
   - `<workspace>/skills/dba-etl-worklog/`

2. Upewnij się, że w środku jest `SKILL.md` oraz `templates/`.

## Użycie (przykłady)

- **Utwórz dzisiejszą sekcję:**
  > "stwórz dzisiejszą sekcję workloga"

- **Dopisz operację:**
  > "dopisz: 09:20 dodany indeks IX_orders_order_date"

- **Zapisz incydent:**
  > "dodaj incydent INC0783182: timeout na tasku load_orders (dag_id=etl_orders, task_id=load_orders)"

- **Zapisz decyzję:**
  > "zapisz decyzję: nie zwiększamy timeoutu, fixujemy indeks"

- **Wygeneruj diagram:**
  > "wygeneruj diagram airflow + sql server"

## Diagram (Mermaid)

```mermaid
flowchart TD
    A[Start dnia] --> WL1[Worklog\nPlan dnia\nDAG-i / okna / incydenty]

    WL1 --> AF0[Airflow Scheduler]
    AF0 --> AF1[Trigger DAG]
    AF1 --> AF2{Stan DAG}

    AF2 -- SUCCESS --> OK0[Worklog\nDAG OK\nczas + dag_id + run_id]

    AF2 -- FAILED --> TRI0[Triage\nAirflow task logs]
    TRI0 --> TRI1[Worklog\nINC / Problem\nDAG + task + error]

    TRI0 --> L1[Airflow Logs]
    L1 --> TRI2{Typ błędu}

    AF1 --> STG[Staging / Landing]
    STG --> LOAD[Load step\nBCP / SSIS / Python]
    LOAD --> MSSQL[(SQL Server)]

    MSSQL --> TSQL[Transformacje T-SQL]
    TSQL --> DQ[Data Quality Checks]
    DQ --> PUB[Publish / downstream]
    PUB --> OK0

    TRI2 -- DB --> DB0[SQL Diagnostics]
    DB0 --> DB1[Waits / Locks / IO / TempDB]
    DB1 --> DB2{Akcja}

    DB2 -- Hotfix --> FIX1[DB Fix\nIndex / Stats / Config]
    DB2 -- Mitigation --> FIX2[Mitigation\nRollback / Disable step]
    DB2 -- Escalate --> SN0[ServiceNow / ECC]

    TRI2 -- ETL --> ETL0[ETL Diagnostics]
    ETL0 --> ETL1[Schema / Source / Timeout]
    ETL1 --> ETL2{Akcja}

    ETL2 -- Retry --> RERUN[Rerun DAG]
    ETL2 -- Fix --> CODEFIX[Fix DAG / Operator]
    ETL2 -- Escalate --> SN0[ServiceNow / ECC]

    FIX1 --> RERUN
    FIX2 --> RERUN
    CODEFIX --> RERUN
    RERUN --> AF2

    FIX1 --> WL2[Worklog\nZmiany w DB]
    FIX2 --> WL3[Worklog\nDecyzje techniczne]
    CODEFIX --> WL4[Worklog\nZmiany ETL]
    SN0 --> WL5[Worklog\nTicket INC/CHG]

    WL2 --> END[Koniec dnia]
    WL3 --> END
    WL4 --> END
    WL5 --> END
````

## Notka: exec / allowlista (opcjonalnie)

Ten skill domyślnie używa tylko `filesystem`.
Jeśli kiedyś dopniesz `exec` (np. do `git commit`), to pamiętaj o mechanizmie **exec approvals**:
komendy na hoście przechodzą przez politykę + allowlistę + (opcjonalnie) prompt użytkownika. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/exec-approvals), [\[openclaw-d....amcp.site\]](https://openclaw-docs.amcp.site/en/tools/exec)

```

---

# 3) (Opcjonalnie) Wersja “tool-first” z `exec` (tylko jeśli chcesz)
Jeżeli zechcesz, mogę od razu przygotować wariant skill‑a, który:
- potrafi `git status` / `git commit -am "worklog: YYYY-MM-DD"` (po zatwierdzeniu),
- ale **wymaga** ogarnięcia `exec approvals` i allowlisty na host‑exec zgodnie z dokumentacją. 


Jasne — dodaję sub‑funkcję **„Podsumuj dzień”** do Twojego skill‑a `dba-etl-worklog`. Poniżej masz **konkretne zmiany do wklejenia** (aktualizacja `SKILL.md` + aktualizacja szablonu dnia). Skill dalej jest w formacie **katalog + `SKILL.md` z YAML frontmatter**, zgodnie z tym jak OpenClaw ładuje i rozumie skills. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)

***

## 1) Aktualizacja `SKILL.md` — dodaj sub‑funkcję „Podsumuj dzień”

W pliku `skills/dba-etl-worklog/SKILL.md`:

### A) (Opcjonalnie) rozbuduj `trigger`

Dodaj do istniejącego `trigger` frazy, żeby skill łatwo się aktywował:

```yaml
trigger: "worklog|log pracy|dziennik pracy|dba worklog|etl worklog|airflow worklog|sql server worklog|wpis do workloga|sekcja workloga|diagram airflow sqlserver|podsumuj dzień|podsumowanie dnia|daily summary|summary worklog"
```

> Skill nadal pozostaje w standardowym układzie: YAML frontmatter + instrukcje w `SKILL.md`. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)

***

### B) Dodaj nową sekcję w instrukcjach (wklej w `SKILL.md` pod „Jak działa (procedura)”)

Wklej ten blok (np. po punkcie „5) Generowanie diagramu Mermaid…”):

```md
### 6) Sub-funkcja: Podsumuj dzień
Aktywuj, gdy użytkownik poprosi o:
- "Podsumuj dzień"
- "Zrób podsumowanie dnia z workloga"
- "Daily summary" / "Summary worklog"
- "Podsumuj dzisiejszy worklog"

#### Wejście
- ścieżka do workloga (domyślnie `./worklog.md`)
- data: domyślnie dzisiejsza (YYYY-MM-DD); jeśli user poda inną datę, użyj jej

#### Krok po kroku (deterministycznie)
1) Wczytaj `worklog.md`.
2) Wytnij tylko sekcję dnia:
   - start = linia z separatorem i datą:
     `==================================================`
     `YYYY-MM-DD (...)`
     `==================================================`
   - koniec = następna taka sekcja albo EOF.
3) Z parsowanej sekcji wyciągnij dane źródłowe:
   - Operacje: linie zaczynające się od `HH:MM` oraz/lub krótkie wpisy operacyjne.
   - Incydenty: bloki zaczynające się od `- INC` (lub `- Problem`) wraz z podpunktami.
   - Decyzje: linie w `## Decyzje techniczne` (np. zaczynające się od ✅/❌).
   - Zmiany DB: wpisy pod `## Zmiany w danych / DB` (obiekt + zmiana + impact).
   - Follow-up: checkboxy `- [ ]` z `## Ryzyka / follow-up` (tylko otwarte).
4) Zbuduj streszczenie (bez “fantazjowania”):
   - 5–10 bulletów “Najważniejsze” na podstawie Operacji/Incydentów/Decyzji/Zmian.
   - Wypisz incydenty z: id + status (jeśli jest) + 1-liniowy opis.
   - Wypisz decyzje (✅/❌) bez rozbudowy ponad to, co w logu.
   - Wypisz zmiany DB (obiekt → zmiana).
   - Wypisz otwarte follow-up (`- [ ] ...`).
   - (Opcjonalnie) policz ilości: liczba operacji (HH:MM), liczba incydentów, liczba otwartych follow-up — to wolno policzyć, bo wynika z tekstu.
5) Zwróć wynik użytkownikowi w formacie README/Slack-friendly.

#### Format wyjścia (zawsze taki sam)
**Podsumowanie dnia: YYYY-MM-DD**
Najważniejsze:
- ...
Incydenty:
- INCxxxxx — status: (jeśli w logu) — krótko
Decyzje:
- ✅/❌ ...
Zmiany DB:
- db.schema.object — zmiana
Otwarte follow-up:
- [ ] ...
Statystyki (opcjonalnie, zliczone z logu):
- Operacje: N
- Incydenty: N
- Follow-up otwarte: N

#### Zapis do pliku (opcjonalny)
Jeżeli użytkownik chce, dopisz pod bieżącym dniem sekcję:
`## Podsumowanie dnia (auto)`
i wstaw tam wygenerowany blok.
Nie nadpisuj starego podsumowania — dopisz kolejne z timestampem lub nadpisz tylko jeśli user tego wymaga.
```

***

## 2) Aktualizacja szablonu dnia `templates/day.md`

Dodaj na końcu szablonu (lub po „Notatki luźne”) sekcję na auto‑summary:

```md
## Podsumowanie dnia (auto)
<!-- generowane przez funkcję "Podsumuj dzień" -->
```

Pełny fragment do wklejenia (koniec pliku):

```md
## Notatki luźne
- ...

## Podsumowanie dnia (auto)
<!-- generowane przez funkcję "Podsumuj dzień" -->
```

***

## 3) README‑ready: dopisz krótki opis funkcji

Do Twojego `README.md` (sekcja „Użycie”) dodaj:

```md
### Podsumuj dzień
Generuje krótkie podsumowanie z dziennej sekcji workloga:
- najważniejsze (5–10 bulletów),
- incydenty (INC + status),
- decyzje,
- zmiany DB,
- otwarte follow-up (checkboxy).

Przykład:
> "Podsumuj dzień"
> "Podsumuj 2026-03-13 z workloga"
```

***

### Dlaczego to jest zgodne z OpenClaw

*   Trzymasz wszystko w **jednym skill folderze** i sterujesz zachowaniem przez instrukcje w `SKILL.md` (YAML frontmatter + opis procedur) — to dokładnie model skills w OpenClaw. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)

***

Jeśli chcesz, od razu mogę dopisać w tej sub‑funkcji jeszcze **regułę “tagowania”** (np. `[AIRFLOW]`, `[SQL]`, `[INC]`, `[DEC]`) i wtedy “Podsumuj dzień” robi jeszcze lepsze grupowanie (bez LLM‑owego zgadywania), ale na razie powyższe działa już bardzo solidnie w trybie plain‑text.



Super — dokładamy **regułę tagowania**, tak żeby „Podsumuj dzień” mógł **parsować i grupować** wpisy deterministycznie (bez zgadywania). Przy okazji trzymamy się dobrej praktyki: **tagi jako key/value i najlepiej lowercase**, bo w części systemów są case‑sensitive i rekomendacja jest „lowercase wherever possible”. 

Poniżej masz **gotowe fragmenty do wklejenia** do `skills/dba-etl-worklog/SKILL.md` + małą aktualizację `templates/day.md`.

***

## 1) `SKILL.md` — dodaj “Reguła tagowania” (nowa sekcja)

Wklej tę sekcję w `SKILL.md` np. **przed** „### 6) Sub-funkcja: Podsumuj dzień”:

```md
## Reguła tagowania (dla Podsumuj dzień)

### Cel
Ułatwić automatyczne grupowanie wpisów w dziennym podsumowaniu: Airflow vs SQL Server vs DQ vs Incydenty itd.

### Format tagów (2 warstwy)

#### A) Tag prefiksowy (czytelny, szybki)
Na początku linii wpisu:
- pojedynczy tag: `[AIRFLOW] ...`
- wiele tagów: `[AIRFLOW][ETL] ...` albo `[AIRFLOW] [ETL] ...`

Dozwolone tagi (prefiksowe):
- `[AIRFLOW]` / `[DAG]` / `[TASK]`
- `[SQL]` / `[MSSQL]` / `[DB]`
- `[ETL]` / `[SSIS]`
- `[DQ]`
- `[INC]` / `[CHG]`
- `[DEC]`
- `[RISK]`
- `[MEET]`
- `[NOTE]`

Normalizacja:
- W podsumowaniu traktuj tagi jako **case-insensitive** i normalizuj do lowercase (np. AIRFLOW → airflow).
  (Tagi mogą być case-sensitive w niektórych systemach, zalecane jest lowercase nazw i wartości.) 

#### B) Tagi key=value (strukturalne, do filtrów i statystyk)
Dopisuj na końcu lub w środku wpisu:
- `dag=etl_orders run_id=manual__2026-03-13T08:40 task=load_orders`
- `db=prod01 database=sales object=dbo.orders`
- `ticket=INC0783182 env=prod`

Zasady:
- klucze i wartości najlepiej lowercase (case może mieć znaczenie) 
- bez spacji wokół `=`
- separacja spacją
- wartości bez wrażliwych danych (brak haseł / connection stringów)

### Minimalne przykłady wpisów
- `[AIRFLOW][ETL] 08:40 DAG failed task timeout dag=etl_orders task=load_orders run_id=scheduled__... ticket=INC0783182`
- `[SQL] 09:20 dodany indeks IX_orders_order_date db=prod01 database=sales object=dbo.orders`
- `[DQ] 09:35 rowcount mismatch source vs stage dag=etl_orders task=dq_orders`
- `[DEC] ✅ nie zwiększamy timeoutu; fixujemy indeks ticket=INC0783182`
- `[RISK] - [ ] dodać check indeksów do CI dag=etl_orders`
```

***

## 2) `SKILL.md` — modyfikacja sub-funkcji “Podsumuj dzień” (parsowanie tagów)

W sekcji „### 6) Sub-funkcja: Podsumuj dzień” **podmień** punkt 3) na wersję “tag-aware” (albo dopisz jako 3a/3b):

```md
3) Z parsowanej sekcji wyciągnij dane źródłowe + tagi:
   - Każdą linię spróbuj zinterpretować jako:
     a) prefiks tagów: `[TAG]` / `[TAG][TAG]` / `[TAG] [TAG]`
     b) pary key=value (np. dag=..., task=..., ticket=...)
   - Znormalizuj tagi do lowercase (AIRFLOW → airflow), bo tagi mogą być case-sensitive; zalecane lowercase nazw/wartości. 
   - Klasyfikacja wpisu:
     * jeśli ma tag `inc` lub zawiera `INC\d+` → Incydenty
     * jeśli ma tag `dec` lub zaczyna się od `✅/❌` w sekcji decyzji → Decyzje
     * jeśli ma tag `sql`/`mssql`/`db` lub jest w sekcji zmian DB → Zmiany DB
     * jeśli ma tag `airflow`/`dag`/`task` → Airflow
     * jeśli ma tag `dq` → DQ
     * jeśli ma tag `risk` lub jest checkbox `- [ ]` → Follow-up
   - Zachowaj też metadane key=value:
     * ticket=..., dag=..., run_id=..., task=..., db=..., database=..., object=..., env=...

4) Zbuduj streszczenie (tag-first, bez fantazjowania):
   - Najważniejsze: 5–10 bulletów, preferuj wpisy z tagami `inc`, `airflow`, `sql`, `dec`, `dq`.
   - Dodaj sekcję "Rozkład wg tagów" (opcjonalnie) z licznikami:
     airflow: N, sql: N, dq: N, inc: N, dec: N, risk(open): N
     (licz tylko z tekstu)
```

***

## 3) `SKILL.md` — format wyjścia “Podsumuj dzień” (dodaj tagi w podsumowaniu)

W części „#### Format wyjścia (zawsze taki sam)” dopisz po „Najważniejsze” nową mini-sekcję:

```md
Rozkład wg tagów (z logu):
- airflow: N
- sql: N
- dq: N
- inc: N
- dec: N
- follow-up(open): N
```

I (opcjonalnie) w “Najważniejsze” dopuszczaj prefiks tagów w bulletach, np.:

*   `[airflow] ...`
*   `[sql] ...`

***

## 4) `templates/day.md` — dodaj przykłady tagowanych wpisów (żebyś pisał konsekwentnie)

W `templates/day.md` pod sekcją `## Operacje / faktyczne działania` podmień komentarze na takie:

```md
## Operacje / faktyczne działania
<!-- format: [TAG][TAG] HH:MM opis key=value ... -->
<!-- [AIRFLOW][ETL] 08:40 DAG failed task timeout dag=etl_orders task=load_orders run_id=scheduled__... ticket=INC0783182 -->
<!-- [SQL] 09:20 dodany indeks IX_orders_order_date db=prod01 database=sales object=dbo.orders -->
<!-- [DQ] 09:35 rowcount mismatch source vs stage dag=etl_orders task=dq_orders -->
```

Pod `## Ryzyka / follow-up` dodaj przykład:

```md
## Ryzyka / follow-up
- [ ] [RISK] dodać check indeksów do CI dag=etl_orders
```

***

## Dlaczego lowercase / key=value?

Bo „tagi” w różnych systemach bywają **case-sensitive** i rekomendacja jest, żeby używać lowercase dla nazw i wartości, plus model key/value jest standardem.   
My robimy kompromis: **Ty możesz pisać prefiksowe tagi dużymi literami dla czytelności**, a “Podsumuj dzień” i tak **normalizuje** do lowercase w podsumowaniu. 
***

Jeśli chcesz, mogę też dopisać **regułę priorytetu** (np. `[INC]` zawsze pierwsze w “Najważniejsze”, potem `[DEC]`, `[SQL]`, `[AIRFLOW]`, `[DQ]`) i wtedy “Podsumuj dzień” będzie jeszcze bardziej “opsowy” (SRE‑style).