Парадокс «слежки»: как история браузера превращается в инструмент самопознания (и планирования будущего а-ля «AI-стратегирование»)

advat · 18.Февраль.2026 12:07:57

Спасибо за отзыв.
Считываю, Дмитрий Николаевич, что Вы схватили ключевую идею: не сбор данных, не обобщение их в “гладкий текст для читателя”, не “объяснения, которые меняют мир”, а, прежде всего, — выдвижение гипотез для самоисследования.

Что в Вашем кейсе особенно ценно лично для меня:

с помощью AI вскрыть “слепые зоны” и получить предупреждение, мол, приглядитесь к тому, что Вам только кажется “самоочевидным”, но не является таковым в практической деятельности;
на основе вскрывшихся “слепых зон”, получить от “тренера” ненавязчивые рекомендации как изменить эту зону в будущем.

Всё это как дополнение к уже известному с “начала времён”:

… Движение Quantified Self зародилось примерно в 2007 году, когда Гэри Вулф и Кевин Келли, редакторы журнала Wired, придумали этот термин. Идея быстро набрала популярность, и в 2011 году состоялась первая конференция Quantified Self. С годами благодаря технологическому прогрессу, в частности появлению носимых устройств и мобильных приложений, людям стало проще собирать данные о различных аспектах своей жизни, таких как сон, физические упражнения, питание и психическое здоровье. …

Данные “о себе любимом” уже давно собираются и анализируются… А вот такое, в плюс к тому, чтобы ещё и синтезируются гипотезы и даются рекомендации— такого мне не известно (но, честно говоря, такого я и не искал).

И ещё. Вот тут у Вас:

Да, всё верно. Как верно и то, что не все задачи следует доверять “внешним LLM”. Ведь Вы и без меня знаете, что можно пользоваться “локалками” без доступа в Интернет. Современные локальные модели вполне себе справляются с небольшими файлами, содержащими “нежные данные” (впрочем, в этом пункте я могу быть предвзят, т.к. опыт мой ограничен моими задачами и моими скромными экспериментами"). При этом, как подсказывает мне Perplexity (ссылку даю ниже), «метрики лучше считать кодом».

И-таки сам себя дополню. Идея-то в общем-то проста:
да, гипотезы, сгенерированные LLM большое подспорье в сравнении с “собирать данные о себе и заносить в таблички”. Однако главный акцент, который я ставлю на своих скромных подходах в том, что не столько “пользуйтесь предложенными решениями”, сколько “учитывайте ограничения предложенных решений и идите дальше”.

Суть: “готовое решение” — возможно и “лучшее известное мне к этому часу ( 2026-02-18T11:22:00Z) решение”, но содержится оно “в одной отдельно взятой голове”.

А вот “взять идею и развить её через множество других голов” (статьи/препринты статей/иные научные публикации не старше одного года") + выйти на текущий локальный оптимум типа SoTA-SoTA — вот это действительно для меня важно.

И первый шаг к этому именно критика “готового решения из одной отдельно взятой головы”.

Далее, как обычно, передаю слово AI-ассистенту — «дополнительный материал» — “справочно от Perplexity” (фрагменты, полный текст здесь):

ActivityWatch: минимальный пайплайн

Этап Какие данные собирать Какие агрегаты считать (детерминированно) Промт для LLM (локальной/внешней) Формат гипотез (фальсифицируемый) Источник

1. Сбор aw-watcher-window (активное окно + заголовок), aw-watcher-afk (активен/неактивен), aw-watcher-web (активная вкладка: title/URL). Пока не считать — только убедиться, что события пишутся и есть временные метки/длительности. Не нужен. Не нужен. Watchers перечислены в доках/описаниях watchers и расширения.

2. Экспорт Экспорт всех buckets или выбранных bucket в JSON (локально). Валидация данных: покрытие по времени (сколько часов “в логе”), доля AFK, пропуски. Не нужен. Не нужен. “Exporting data” + пример GET /api/0/export.

3. Базовые метрики Экспорт JSON за 7 дней (не 1 день, чтобы убрать случайность). 1) Распределение длительностей сессий (медиана, доли <10с, <1м, <5м). 2) Кол-во переключений в час. 3) Топ домены/приложения по времени. 4) Доля “коммуникации” (категория по доменам/приложениям). «Вот агрегаты за 7 дней (таблица). Выдели 5 “слепых зон” и 5 возможных причин; затем предложи 3 гипотезы вмешательства, каждая с: (а) ожидаемый механизм, (б) измеримая метрика, (в) ожидаемое направление изменения, (г) риск/побочный эффект». Гипотеза = {вмешательство; метрика; горизонт (7 дней); ожидаемое изменение направления; критерий “не сработало”}. ActivityWatch предоставляет локальные данные и API/экспорт; далее Вы строите метрики своим кодом.

4. Недельный эксперимент Те же источники, но помечаете “неделя A” и “неделя B”. Diff A/B: изменение долей коротких сессий, переключений/час, доли категорий, времени deep work (например >25 мин непрерывно). «Сравни A vs B. Скажи, какие гипотезы получили подтверждение/опровержение, какие новые гипотезы появились. Не делай моральных оценок; только причинные версии и следующий тест». Принимаемость: гипотеза должна быть опровержима по Вашим метрикам; если не опровержима — переписать. Логика “экспорт → метрики → сравнение” опирается на экспорт/REST API ActivityWatch.

Pieces for Developers: минимальный пайплайн

Этап Какие данные собирать Какие агрегаты считать (детерминированно) Промт для LLM (локальной/внешней) Формат гипотез (фальсифицируемый) Источник

1. Сбор контекста Включить PiecesOS и только нужные источники контекста (IDE/браузер и т.п.; принцип — минимально достаточный сбор). На этом этапе — только фиксация “какой класс событий/контекста захватывается” (чтобы не было «пишет всё подряд»). Не нужен. Не нужен. PiecesOS описан как background service, и указано, что capture sources можно включать/выключать.

2. Таймлайн/вопросы “что я делал” Использовать Timeline/LTM как интерфейс recall. Детерминированная часть тут слабее (Pieces делает много “внутри”), поэтому полезно вести внешний “реестр вопросов”: 10 типовых вопросов, которые Вы задаёте ежедневно/еженедельно (одинаково). «Собери 5 повторяющихся паттернов из таймлайна за 7 дней: повторяющиеся темы, типовые “залипания”, места потери контекста. Для каждого — предложи 2 гипотезы вмешательства и метрику, которую можно измерить вне Pieces (в ActivityWatch или вручную)». Гипотеза должна ссылаться на внешнюю проверяемую метрику (например из ActivityWatch) или на счётчик/лог-штамп (число случаев X в день). PiecesOS = база для Timeline через LTM-2.7, поиск по контексту.

3. Ограничение облака Явно разделить “обычные ответы” и Deep Study. Правило безопасности: чувствительные данные не отправлять в режимы, которые уходят в облако. Промт‑правило: «Если нужно Deep Study, сначала редуцируй данные: дай только агрегаты/безопасные выжимки». Фальсификация: любые “глубокие” выводы должны быть перепроверены через внешние метрики/факты. Deep Study “always runs on a dedicated cloud LLM managed by Pieces” — это важно для выбора режима.

Далее то, что для меня представляет как новый заход типа “не ограничивайся известным, делай гибриды из уже известного-опробованного. Не будь рабом одного понравившегося решения”:

Гибрид: ActivityWatch + Pieces (максимум пользы, минимум лишнего)

Цель Берём из ActivityWatch Берём из Pieces Что не берём (осознанно) Как получаем гипотезы и проверяемость Источник

1) Надёжные поведенческие метрики Сырьё “время/переключения/домены/окна”, экспорт JSON через REST API. Ничего (на этом шаге). Не пытаемся просить LLM “посчитать” метрики. Скриптом считаем: доли коротких сессий, переключения/час, доли категорий; это baseline для фальсификации. Экспорт ActivityWatch через API.

2) Смысловой контекст «почему так» Только ссылки на тайм‑слоты/события (чтобы сопоставить с Pieces). Таймлайн/контекст вокруг тех интервалов, где ActivityWatch показывает аномалии (например всплеск переключений, провал фокуса). Не включаем все источники захвата, включаем только нужные (минимизация). Выбираем 3 “аномальных окна” недели по метрикам AW → смотрим в Pieces, что это было по смыслу → формулируем гипотезы причин. PiecesOS: контекст + Timeline/LTM.

3) Генерация гипотез (LLM) В LLM отдаём только агрегаты и безопасные маркеры (категории/доли/тренды), а не сырые URL/заголовки, если они чувствительные. В LLM отдаём “обезличенные” summaries: темы, тип задач, типовые триггеры (без секретов). Не используем Deep Study, если это чувствительные данные, потому что Deep Study фиксированно облачный. Промт: «На основании (A) агрегатов AW и (B) обезличенных summary из Pieces предложи 5 гипотез, каждая: вмешательство → метрика AW → ожидаемое направление → горизонт 7 дней → критерий провала». Про облачность Deep Study — из Pieces docs.

4) Проверка гипотез (A/B-недели) AW даёт объективный diff A/B по метрикам. Pieces используется для пост‑морем: “что именно изменилось в контексте” и “какие новые триггеры проявились”. Не переносим “оценку полезности” на LLM; LLM только генерит версии. Правило: гипотеза считается принятой/отклонённой только по заранее выбранной метрике AW (или ручному счётчику), а Pieces/LLM — для объяснений и следующей итерации. AW экспорт/данные + Pieces Timeline контекст.

Сходства Различия Польза по выдвижению гипотез Ссылка на источник с обоснованиями

Оба инструмента собирают цифровые следы активности на устройстве (как минимум: контекст работы/временная история), чтобы затем можно было восстановить «что я делал». ActivityWatch — автоматический тайм‑трекер “как я провожу время”, с фокусом на событиях (активное приложение/заголовок окна, активная вкладка/URL через расширения, AFK и т.п.), open source, локальное хранение. В гипотезогенерации ActivityWatch сильнее как “сырьё для диагностики поведения”: легко строить гипотезы вида «у меня фрагментация/переключения/перекос категорий» на основании тайм‑серий и категорий, затем проверять изменением режима работы. ActivityWatch features + privacy: local storage, active app/window title, browser tab URL, categories, watchers.

Оба декларируют локальный/приватный контур как важную ценность (данные об активности не должны “по умолчанию” утекать). Pieces — “память контекста разработки” через PiecesOS (фон-сервис) и LTM‑2.7/Timeline: мониторинг workflow на уровне ОС, захват контекста IDE/браузера/коллаб‑инструментов, разговорный поиск по захваченному контексту; есть управление источниками захвата. В гипотезогенерации Pieces сильнее как “контекст‑память”: гипотезы удобнее формулировать не только про распределение времени, но и про повторяющиеся паттерны работ (какие задачи/решения/ссылки возвращаются, какие follow‑up действия появляются), т.е. гипотезы ближе к «почему я делаю так» и «где теряю контекст». PiecesOS: LTM tracks workflow context; sources can be enabled/disabled; conversational search over captured context.

Оба позволяют построить цикл «наблюдение → интерпретация → гипотезы» при подключении внешнего анализатора (скрипты/LLM/агенты). ActivityWatch подчёркивает “collection of lifedata … without compromising user privacy”, “safe storage … on the user’s local machine” и наличие watchers (расширяемость) + REST API/экспорт JSON через UI/API. Для обязательного требования «выдать гипотезы» ActivityWatch удобен как модуль: метрики/агрегации считаете кодом (детерминированно), LLM (в т.ч. локальная) читает агрегаты и предлагает гипотезы; так проще сохранять эпистемическую дисциплину (LLM не “считает”, а “предполагает”). ActivityWatch README: goal, local storage, watchers; REST API, export JSON (описано в README/архитектуре).

Оба могут быть использованы без “ручного дневника” как минимум для реконструкции активности (таймлайн/история). Pieces явно описывает, что данные LTM обрабатываются и хранятся на устройстве (“processed and stored entirely on your device”), а также что LTM применяет on-device ML фильтрацию секретов/чувствительных данных; при этом отдельная функция Deep Study генерируется на “dedicated cloud LLM managed by Pieces” (это важно для приватности и выбора режима). Для гипотез о самосовершенствовании Pieces полезен, если Ваша задача — не столько “тайм‑баланс”, сколько “когнитивный контекст”: что я делал/читал/обсуждал, как повторяются темы/решения, где возникают провалы передачи контекста; но надо учитывать, что Deep Study по документации выполняется в облаке, т.е. режим приватности зависит от выбранной функции. PiecesOS docs: on-device processing/storage, on-device ML filtering; Deep Study runs on a dedicated cloud LLM managed by Pieces.

Оба допускают настройку того, что именно захватывать (в AW — через набор watchers/категории; в Pieces — через enable/disable источников). ActivityWatch — прямо про “time spent” и “behavioral trends”; Pieces — про “workflow context”, “timeline events and summaries”, “conversational search” и “grounded assistance” по историческому контексту. Выбор для гипотез зависит от типа гипотез: (а) «поведенческие/временные» (переключения, доли категорий, глубина фокуса) — проще на ActivityWatch; (б) «контекстно‑смысловые» (повторяющиеся проблемы/решения/референсы/следующие шаги) — проще на Pieces. ActivityWatch “behavioral trends”, categories, browser extensions. + Pieces “workflow events and summaries”, “grounded assistance”, Timeline.

Дважды “перепроверенный LLM”, но не выверенный мной список источников:

Wolf, Gary. (2011-03-03). What is The Quantified Self? Quantified Self.
Опорная цитата: “Kevin Kelly and I founded The Quantified Self in 2007.” URL: https://quantifiedself.com/blog/what-is-the-quantified-self/

Carmichael, Alexandra. (2011-01-12). Announcing: The First Quantified Self Conference, May 28-29. Quantified Self.
Опорная цитата: “the first Quantified Self Conference … to be held May 28-29, 2011 …” Опорная цитата: “gather, inspire, and learn from each other … self-tracking projects”. URL: https://quantifiedself.com/blog/announcing-the-first-quantified-self-conference-may-28-29/

Pieces for Developers Documentation. (n.d.). Understanding PiecesOS | Pieces Docs.
Опорная цитата: “PiecesOS is a background service that runs on your machine.”
Опорная цитата: “The data captured by LTM is processed and stored entirely on your device …”
Опорная цитата: “Deep Study always runs on a dedicated cloud LLM managed by Pieces … subject to change.”
Опорная цитата: “enable or disable specific sources … for data capture”.
URL: https://docs.pieces.app/products/core-dependencies/pieces-os

ActivityWatch Documentation. (n.d.). Privacy Policy.
Опорная цитата: “All data is stored locally on your device.”
Опорная цитата: “We, the developers of ActivityWatch, do not have access to your data.”
Опорная цитата: “ActivityWatch does not transmit your data to any external servers.”
URL: https://docs.activitywatch.net/en/latest/privacy.html

Этап	Какие данные собирать	Какие агрегаты считать (детерминированно)	Промт для LLM (локальной/внешней)	Формат гипотез (фальсифицируемый)	Источник
1. Сбор	aw-watcher-window (активное окно + заголовок), aw-watcher-afk (активен/неактивен), aw-watcher-web (активная вкладка: title/URL).	Пока не считать — только убедиться, что события пишутся и есть временные метки/длительности.	Не нужен.	Не нужен.	Watchers перечислены в доках/описаниях watchers и расширения.
2. Экспорт	Экспорт всех buckets или выбранных bucket в JSON (локально).	Валидация данных: покрытие по времени (сколько часов “в логе”), доля AFK, пропуски.	Не нужен.	Не нужен.	“Exporting data” + пример GET `/api/0/export`.
3. Базовые метрики	Экспорт JSON за 7 дней (не 1 день, чтобы убрать случайность).	1) Распределение длительностей сессий (медиана, доли <10с, <1м, <5м). 2) Кол-во переключений в час. 3) Топ домены/приложения по времени. 4) Доля “коммуникации” (категория по доменам/приложениям).	«Вот агрегаты за 7 дней (таблица). Выдели 5 “слепых зон” и 5 возможных причин; затем предложи 3 гипотезы вмешательства, каждая с: (а) ожидаемый механизм, (б) измеримая метрика, (в) ожидаемое направление изменения, (г) риск/побочный эффект».	Гипотеза = {вмешательство; метрика; горизонт (7 дней); ожидаемое изменение направления; критерий “не сработало”}.	ActivityWatch предоставляет локальные данные и API/экспорт; далее Вы строите метрики своим кодом.
4. Недельный эксперимент	Те же источники, но помечаете “неделя A” и “неделя B”.	Diff A/B: изменение долей коротких сессий, переключений/час, доли категорий, времени deep work (например >25 мин непрерывно).	«Сравни A vs B. Скажи, какие гипотезы получили подтверждение/опровержение, какие новые гипотезы появились. Не делай моральных оценок; только причинные версии и следующий тест».	Принимаемость: гипотеза должна быть опровержима по Вашим метрикам; если не опровержима — переписать.	Логика “экспорт → метрики → сравнение” опирается на экспорт/REST API ActivityWatch.

Этап	Какие данные собирать	Какие агрегаты считать (детерминированно)	Промт для LLM (локальной/внешней)	Формат гипотез (фальсифицируемый)	Источник
1. Сбор контекста	Включить PiecesOS и только нужные источники контекста (IDE/браузер и т.п.; принцип — минимально достаточный сбор).	На этом этапе — только фиксация “какой класс событий/контекста захватывается” (чтобы не было «пишет всё подряд»).	Не нужен.	Не нужен.	PiecesOS описан как background service, и указано, что capture sources можно включать/выключать.
2. Таймлайн/вопросы “что я делал”	Использовать Timeline/LTM как интерфейс recall.	Детерминированная часть тут слабее (Pieces делает много “внутри”), поэтому полезно вести внешний “реестр вопросов”: 10 типовых вопросов, которые Вы задаёте ежедневно/еженедельно (одинаково).	«Собери 5 повторяющихся паттернов из таймлайна за 7 дней: повторяющиеся темы, типовые “залипания”, места потери контекста. Для каждого — предложи 2 гипотезы вмешательства и метрику, которую можно измерить вне Pieces (в ActivityWatch или вручную)».	Гипотеза должна ссылаться на внешнюю проверяемую метрику (например из ActivityWatch) или на счётчик/лог-штамп (число случаев X в день).	PiecesOS = база для Timeline через LTM-2.7, поиск по контексту.
3. Ограничение облака	Явно разделить “обычные ответы” и Deep Study.	Правило безопасности: чувствительные данные не отправлять в режимы, которые уходят в облако.	Промт‑правило: «Если нужно Deep Study, сначала редуцируй данные: дай только агрегаты/безопасные выжимки».	Фальсификация: любые “глубокие” выводы должны быть перепроверены через внешние метрики/факты.	Deep Study “always runs on a dedicated cloud LLM managed by Pieces” — это важно для выбора режима.

Цель	Берём из ActivityWatch	Берём из Pieces	Что не берём (осознанно)	Как получаем гипотезы и проверяемость	Источник
1) Надёжные поведенческие метрики	Сырьё “время/переключения/домены/окна”, экспорт JSON через REST API.	Ничего (на этом шаге).	Не пытаемся просить LLM “посчитать” метрики.	Скриптом считаем: доли коротких сессий, переключения/час, доли категорий; это baseline для фальсификации.	Экспорт ActivityWatch через API.
2) Смысловой контекст «почему так»	Только ссылки на тайм‑слоты/события (чтобы сопоставить с Pieces).	Таймлайн/контекст вокруг тех интервалов, где ActivityWatch показывает аномалии (например всплеск переключений, провал фокуса).	Не включаем все источники захвата, включаем только нужные (минимизация).	Выбираем 3 “аномальных окна” недели по метрикам AW → смотрим в Pieces, что это было по смыслу → формулируем гипотезы причин.	PiecesOS: контекст + Timeline/LTM.
3) Генерация гипотез (LLM)	В LLM отдаём только агрегаты и безопасные маркеры (категории/доли/тренды), а не сырые URL/заголовки, если они чувствительные.	В LLM отдаём “обезличенные” summaries: темы, тип задач, типовые триггеры (без секретов).	Не используем Deep Study, если это чувствительные данные, потому что Deep Study фиксированно облачный.	Промт: «На основании (A) агрегатов AW и (B) обезличенных summary из Pieces предложи 5 гипотез, каждая: вмешательство → метрика AW → ожидаемое направление → горизонт 7 дней → критерий провала».	Про облачность Deep Study — из Pieces docs.
4) Проверка гипотез (A/B-недели)	AW даёт объективный diff A/B по метрикам.	Pieces используется для пост‑морем: “что именно изменилось в контексте” и “какие новые триггеры проявились”.	Не переносим “оценку полезности” на LLM; LLM только генерит версии.	Правило: гипотеза считается принятой/отклонённой только по заранее выбранной метрике AW (или ручному счётчику), а Pieces/LLM — для объяснений и следующей итерации.	AW экспорт/данные + Pieces Timeline контекст.

Сходства	Различия	Польза по выдвижению гипотез	Ссылка на источник с обоснованиями
Оба инструмента собирают цифровые следы активности на устройстве (как минимум: контекст работы/временная история), чтобы затем можно было восстановить «что я делал».	ActivityWatch — автоматический тайм‑трекер “как я провожу время”, с фокусом на событиях (активное приложение/заголовок окна, активная вкладка/URL через расширения, AFK и т.п.), open source, локальное хранение.	В гипотезогенерации ActivityWatch сильнее как “сырьё для диагностики поведения”: легко строить гипотезы вида «у меня фрагментация/переключения/перекос категорий» на основании тайм‑серий и категорий, затем проверять изменением режима работы.	ActivityWatch features + privacy: local storage, active app/window title, browser tab URL, categories, watchers.
Оба декларируют локальный/приватный контур как важную ценность (данные об активности не должны “по умолчанию” утекать).	Pieces — “память контекста разработки” через PiecesOS (фон-сервис) и LTM‑2.7/Timeline: мониторинг workflow на уровне ОС, захват контекста IDE/браузера/коллаб‑инструментов, разговорный поиск по захваченному контексту; есть управление источниками захвата.	В гипотезогенерации Pieces сильнее как “контекст‑память”: гипотезы удобнее формулировать не только про распределение времени, но и про повторяющиеся паттерны работ (какие задачи/решения/ссылки возвращаются, какие follow‑up действия появляются), т.е. гипотезы ближе к «почему я делаю так» и «где теряю контекст».	PiecesOS: LTM tracks workflow context; sources can be enabled/disabled; conversational search over captured context.
Оба позволяют построить цикл «наблюдение → интерпретация → гипотезы» при подключении внешнего анализатора (скрипты/LLM/агенты).	ActivityWatch подчёркивает “collection of lifedata … without compromising user privacy”, “safe storage … on the user’s local machine” и наличие watchers (расширяемость) + REST API/экспорт JSON через UI/API.	Для обязательного требования «выдать гипотезы» ActivityWatch удобен как модуль: метрики/агрегации считаете кодом (детерминированно), LLM (в т.ч. локальная) читает агрегаты и предлагает гипотезы; так проще сохранять эпистемическую дисциплину (LLM не “считает”, а “предполагает”).	ActivityWatch README: goal, local storage, watchers; REST API, export JSON (описано в README/архитектуре).
Оба могут быть использованы без “ручного дневника” как минимум для реконструкции активности (таймлайн/история).	Pieces явно описывает, что данные LTM обрабатываются и хранятся на устройстве (“processed and stored entirely on your device”), а также что LTM применяет on-device ML фильтрацию секретов/чувствительных данных; при этом отдельная функция Deep Study генерируется на “dedicated cloud LLM managed by Pieces” (это важно для приватности и выбора режима).	Для гипотез о самосовершенствовании Pieces полезен, если Ваша задача — не столько “тайм‑баланс”, сколько “когнитивный контекст”: что я делал/читал/обсуждал, как повторяются темы/решения, где возникают провалы передачи контекста; но надо учитывать, что Deep Study по документации выполняется в облаке, т.е. режим приватности зависит от выбранной функции.	PiecesOS docs: on-device processing/storage, on-device ML filtering; Deep Study runs on a dedicated cloud LLM managed by Pieces.
Оба допускают настройку того, что именно захватывать (в AW — через набор watchers/категории; в Pieces — через enable/disable источников).	ActivityWatch — прямо про “time spent” и “behavioral trends”; Pieces — про “workflow context”, “timeline events and summaries”, “conversational search” и “grounded assistance” по историческому контексту.	Выбор для гипотез зависит от типа гипотез: (а) «поведенческие/временные» (переключения, доли категорий, глубина фокуса) — проще на ActivityWatch; (б) «контекстно‑смысловые» (повторяющиеся проблемы/решения/референсы/следующие шаги) — проще на Pieces.	ActivityWatch “behavioral trends”, categories, browser extensions. + Pieces “workflow events and summaries”, “grounded assistance”, Timeline.

Парадокс «слежки»: как история браузера превращается в инструмент самопознания (и планирования будущего а-ля «AI-стратегирование»)

ActivityWatch: минимальный пайплайн

Pieces for Developers: минимальный пайплайн

Гибрид: ActivityWatch + Pieces (максимум пользы, минимум лишнего)