dexter/DBAdmin

Fork 0

Files

T

Paweł Domański c36ead5db0 Jun 9, 2026, 3:59 PM

2026-06-09 13:59:59 +00:00

35 KiB

Raw Blame History

✅ 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]

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:

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]

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]

✅ 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]

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]

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]

✅ 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]

✅ 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]

3. Minimalny, kanoniczny format

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

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]

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

Zgodnie z opisem autora: [jeffhuang.com]

Na koniec dnia
- dopisujesz listę rzeczy zaplanowanych na jutro (z kalendarza)
W trakcie dnia
- dopisujesz kolejne linie
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], [plaintext-...tivity.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]

❌ 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]

praktyczny szablon workloga pod DBA / ETL

📘 `worklog.md` — DBA / ETL

# 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:

## 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:

## Decyzje techniczne

Nie „co zrobiłem”, tylko dlaczego.

4. Zmiany w DB są logowane jak changelog

Sekcja:

## 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:

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):

[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:

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)

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]
Monitorowanie/alertowanie po stronie DB jest standardowo podpinane pod Splunk (zgodnie z „MS SQL – Monitoring Standards”), [MS SQL - M...Standards | PDF]
W runbooku „Shipping 2.0” jest przykład, że monitorowanie jest realizowane przez Airflow DAG monitor + email na failure. [Shipping 2.0 | Confluence]

🧩 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]
Splunk: typowe narzędzie enterprise do monitoringu/alertów SQL Server (metryki, progi, routing). [MS SQL - M...Standards | PDF]
Airflow DAG monitor + email na failure: częsty model alertowania dla pipeline’ów. [Shipping 2.0 | Confluence]

W diagramie uwzględniłem, że:

Airflow ma logi per task/DAG (np. w bucketach / Composer) jak w runbookach, [EU Analyti...k (EUANAP) | Confluence]
Monitorowanie/alertowanie po stronie DB jest standardowo podpinane pod Splunk (zgodnie z „MS SQL – Monitoring Standards”), [MS SQL - M...Standards | PDF]
W runbooku „Shipping 2.0” jest przykład, że monitorowanie jest realizowane przez Airflow DAG monitor + email na failure. [Shipping 2.0 | Confluence]

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

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] [docs.openclaw.ai], [openclaw-d....amcp.site]

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

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

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]

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

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

---
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`

==================================================
{{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`

# 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], [openclaw-d....amcp.site]


---

# 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]

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…”):

### 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:

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

Pełny fragment do wklejenia (koniec pliku):

## 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:

### 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]

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ń”:

## 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):

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ę:

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:

## 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:

## 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).

35 KiB Raw Blame History Unescape Escape

✅ Najprostsze i najczęściej polecane podejście

Jeden plik .txt / .md jako dziennik pracy

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

Plaintext Productivity

✅ Gotowe narzędzie, ale nadal jeden plik

RedNotebook

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

Obsidian / VS Code + 1 plik Markdown

✅ Hardcore / UNIX‑style

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

🔍 TL;DR – jeśli chcesz tylko link

1. Czym jest system jednego pliku tekstowego

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

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

✅ 2. Chronologia ważniejsza niż struktura

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

3. Minimalny, kanoniczny format

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

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

🔹 Zero kontekstu narzędzia

🔹 Pełna przeszukiwalność

🔹 Audyt i retrospekcja

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

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

8. Dla kogo to jest szczególnie dobre

9. Najważniejsza myśl na koniec

praktyczny szablon workloga pod DBA / ETL

📘 worklog.md — DBA / ETL

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

1. Rozdziela plan od rzeczywistości

2. Incydenty mają własne miejsce

3. Decyzje techniczne są jawne

4. Zmiany w DB są logowane jak changelog

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

✅ Wariant „hardcore DBA”

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

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

🧠 Jak czytać ten diagram (krótko)

✅ Wersja uproszczona (jeśli chcesz do README)

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

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

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

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

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

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

skills/dba-etl-worklog/SKILL.md

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

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

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

README.md

Notka: exec / allowlista (opcjonalnie)

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

2) Aktualizacja szablonu dnia templates/day.md

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

Dlaczego to jest zgodne z OpenClaw

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

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

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

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

Dlaczego lowercase / key=value?

35 KiB

Raw Blame History

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

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

📘 `worklog.md` — DBA / ETL

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

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

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

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

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

`README.md`

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

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

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

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

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

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