Principle

Projektuj pod zaniedbanie

Przetrwa tygodnie ciszy. Starzeje się z wdziękiem. Nigdy nie obarcza użytkownika winą przy powrocie.

Najbardziej niezawodnym predyktorem tego, czy system wiedzy przetrwa, jest to, czy toleruje nieobecność. Większość nie. Wymagają codziennej uwagi, kumulują poczucie winy w ciszy i żądają rytuału odzysku, żeby do nich wrócić. Wygrywa ten system, który możesz ignorować przez miesiąc i nadal znajdziesz go użytecznym.

Zasada

KMS musi być zaprojektowany przy założeniu, że użytkownik będzie go zaniedbywał. Nie „a co, jeśli użytkownik nie nadąży" — kiedy. System pozostaje użyteczny przez zaniedbanie, po powrocie wydobywa to, co zwietrzałe, i nigdy nie żąda wyczyszczenia zaległości jako ceny ponownego wejścia.

Dlaczego to ma znaczenie

Życie się dzieje. Wakacje, intensywne tygodnie pracy, choroba, zmiana skupienia. Systemy, które karzą za nieobecność, zostają porzucone przy pierwszej dłuższej nieobecności i nigdy nie są ponownie adoptowane. Systemy, które przetrwają nieobecność, stają się długoterminową infrastrukturą.

Asymetria jest brutalna: KMS wymagający codziennej obsługi traci użytkownika na zawsze przy pierwszej dwutygodniowej przerwie. KMS wymagający zerowej obsługi jest używany latami. Różnica w możliwościach jest mała. Różnica w przetrwaniu jest totalna.

Jak to działa

Pięć konkretnych ruchów:

  1. Żadnych narastających zobowiązań. Żadnej „rosnącej kolejki do przeglądu" ani „cotygodniowego skrótu, który musisz przeczytać". System wyciąga to, co istotne, na żądanie; nic nie czeka na przerobienie.
  2. Auto-starzenie stanu. Elementy w warstwie stanu, których nikt nie dotykał przez N dni, zostają auto-archiwizowane (z odzyskiwalnym śladem), a nie dodawane do zaległości „starych elementów".
  3. Podsumowanie przy powrocie. Gdy użytkownik otwiera system po ciszy, pierwszym, co wydobywa się na wierzch, jest jednozdaniowe „oto, co się zmieniło / co jest zwietrzałe / co zignorować" — generowane na żądanie, a nie czekające w kolejce.
  4. Żadnej mechaniki serii. Żadnego poczucia winy typu „nie zaglądałeś od X dni". System się tym nie przejmuje.
  5. Kumulacja nie zależy od użytkownika. Automatyczna kompilacja działa niezależnie od tego, czy użytkownik się pojawi. Wiedza jest destylowana, linkowana i wynoszona nawet, jeśli jedynym wejściem przez miesiąc był pojedynczy e-mail.

W prymitywach Claude

  • Subagenci uruchamiają okresowe sprawdzenia starzenia/archiwizacji na harmonogramie (cron, GitHub Actions lub zadanie Trigger.dev).
  • Umiejętności jak re-entry-summary produkują notatkę nadrabiającą na żądanie — nigdy proaktywnie.
  • CLAUDE.md wyraźnie zakazuje wzorców obarczania winą („nigdy nie mów użytkownikowi, że jest w tyle"; „nigdy nie prezentuj zaległości jako kolejki do wyczyszczenia").

Gdzie to widziałem

Umiejętność check-inu w osobistym KMS-ie jest zbudowana na tej zasadzie — otwiera się podsumowaniem przy powrocie, nigdy zaległościami. Dashboard klientów w zespołowym KMS-ie robi to samo w skali zespołu: zwietrzałe sygnały są archiwizowane, zamiast wiecznie się ukazywać. Wzorzec przeciwny (aplikacja kalendarza, która wynosi każde zaniedbane zadanie) jest tym, co przekonuje ludzi, że „nie są wystarczająco zdyscyplinowani" dla systemów wiedzy.

Czytanie pod prąd

To sprawia, że system czuje się mniej „potężnie" — mniej dashboardów, brak serii, brak dopaminy z aplikacji produktywnościowych. Dobrze. Systemy, które się kumulują, to te, których nie zauważasz, że używasz, bo niczego od ciebie nie żądają.

Related principles

Rev. 2026-04-18