## Цель системы Система предназначена для входящих заметок (в основном голосовых из Telegram), которые бот: 1. **структурирует** в Markdown по шаблону, без домыслов 2. проставляет **минимально нужные свойства (properties / frontmatter)** 3. сохраняет так, чтобы потом было удобно: * быстро разбирать входящие * вытаскивать задачи * фильтровать/искать через Dataview * поддерживать порядок без ручной рутины --- ## Структура папок и имена файлов ### Папки Входящие из Telegram идут по дням: ``` 00_Входящие/Telegram/YYYY-MM-DD/ ``` Пример: ``` 00_Входящие/Telegram/2026-01-31/ ``` ### Имена файлов * без нумерации * без времени * максимально короткое, понятное Если имя уже занято, бот добавляет суффикс: * `Название.md` * `Название (2).md` * `Название (3).md` --- ## Базовый шаблон заметки (Markdown) > Важно: бот **не добавляет новые факты**. Только структурирование. ```md --- title: "" summary: "" type: voice source: telegram created: 2026-01-31 18:45 inbox: true status: new kind: [note] action_required: false confidence: 0.85 tags: [бот, обсидиан, ai] --- > [!quote]- Исходник (транскрипция) > ## Резюме (бот заполняет 1–3 предложения) ## Пункты и детали - ## Задачи - [ ] > [!tip] Комментарий / команда для ИИ > ``` ### Правило “пустой строки” для диктовки В самом низу есть блок: ```md > [!tip] Комментарий / команда для ИИ > ``` После `>` оставляется пустая строка, чтобы можно было сразу кликнуть и диктовать без Enter. --- ## Свойства (frontmatter): что значит каждое и как заполняется ### Обязательные (всегда присутствуют) #### `title` **Что:** человеко-понятный заголовок заметки (3–8 слов) **Зачем:** удобно ориентироваться в списке файлов/таблицах Dataview **Как:** коротко, по смыслу, без лишних слов Пример: ```yaml title: "Ротация ухода за собакой в боте" ``` #### `summary` **Что:** краткая "смысловая метка" одной фразой (не 3 предложения) **Зачем:** быстро понять, стоит ли открывать заметку; видеть повторы тем **Как:** 1 фраза, максимум 10-12 слов, БЕЗ точки в конце, нейтрально, без перечисления деталей Пример: ```yaml summary: "идея расширения логики ухода за собакой" ``` #### `type` **Что:** формат входа (форма контента) **Enum:** `voice | text | image | link | chat | mixed | forwarded` **Как:** для телеграм-голосовых обычно `voice`, для пересланных сообщений — `forwarded` #### `source` **Что:** откуда пришло **Пример:** `telegram` (в будущем можно добавить `manual`, `browser`, `chatgpt` и т.д.) #### `created` **Что:** дата/время создания (без таймзоны) **Формат:** `YYYY-MM-DD HH:MM` #### `inbox` **Что:** входит ли заметка в очередь “входящих” **Enum:** `true/false` > Жёсткое правило: > Если `status: done` ⇒ `inbox: false` #### `status` **Что:** стадия обработки входящей заметки **Enum:** `new | processing | done` * `new` — ещё не разбирал * `processing` — взял в работу (разбираешь/уточняешь/в процессе) * `done` — разбор завершён, заметка не требует внимания > `done` означает: заметка как входящая закрыта. > Если внутри были задачи — они либо выполнены, либо вынесены/решены так, что эта заметка больше не требует внимания. #### `kind` **Что:** смысловой класс заметки (может быть несколько) **Важно:** `kind` **всегда массив**, даже если один элемент **Enum:** `[note | idea | task | problem | review | reference | decision]` Примеры: ```yaml kind: [note] kind: [idea] kind: [idea, task] kind: [problem, task] kind: [reference] # справочная информация (инструкции, мануалы) kind: [decision] # зафиксированные решения ``` Правило: * если бот не уверен → `kind: [note]` #### `action_required` **Что:** есть ли потенциальные действия, которые надо сделать **Enum:** `true/false` * `true` — если в тексте есть явные действия/планы/поручения * `false` — если это просто мысль/обзор/наблюдение без “надо сделать” #### `confidence` **Что:** оценка уверенности ИИ в корректном понимании/структурировании **Диапазон:** `0.0–1.0` **Статус:** экспериментально, оставляем пока **Правило low confidence:** Если `confidence < 0.6` → бот автоматически добавляет раздел `## Неясно` с пояснениями #### `tags` **Что:** теги для быстрых срезов **Формат:** массив, 0–3 тега **Допускается:** смешанные RU/EN (например, `ai`) **Правило:** лучше 0 тегов, чем плохие теги Пример: ```yaml tags: [бот, обсидиан, ai] ``` --- ### Условные (добавляются только при необходимости) #### `energy` **Что:** сколько “сил” нужно на выполнение (если есть действия) **Enum:** `low | medium | high` **Правило:** поле `energy` появляется **только если** `action_required: true` Если `action_required: false` → `energy` **отсутствует** Пример: ```yaml action_required: true energy: low ``` #### `priority` (на будущее, не обязательно включать сейчас) **Enum:** `low | medium | high` **Добавлять только если** в исходнике явно звучит срочность/важность (“срочно”, “до завтра”, “важно”). #### `link` (убрали из базового шаблона) Не используется как property по умолчанию. Если ссылки реально есть — они остаются в тексте заметки (внутри пунктов/деталей). --- ## Правила генерации секций в тексте ### `## Резюме` * 1–3 предложения * без домыслов * отражает суть входящего ### `## Пункты и детали` * буллеты с ключевыми деталями (3–7 пунктов обычно достаточно) * без излишней воды ### `## Задачи` * раздел добавляется **только если** в исходнике есть явные действия * формат чекбоксов Obsidian: ```md - [ ] сделать то-то ``` ### `## Неясно` Раздел добавляется **только если** в исходнике есть неоднозначности/пробелы. * каждый пункт: цитата “…” + что непонятно --- ## Логика работы с `status` и `inbox` (памятка) ### После создания (ботом) Обычно: ```yaml inbox: true status: new ``` ### Когда ты начал разбирать Ты вручную ставишь: ```yaml status: processing ``` `inbox` остаётся `true`. ### Когда разбор закончен Ты вручную ставишь: ```yaml status: done inbox: false ``` --- ## Рекомендации по “чистоте данных” (чтобы не развалилось) 1. Не использовать эмодзи в YAML (`status: 📥 inbox` — не делаем). Эмодзи можно показывать в Dataview/оформлении, но не хранить. 2. Не плодить значения enums. Если хочешь расширить — делай осознанно и добавляй в этот мануал. 3. `kind` всегда массив. Иначе потом будет боль в запросах и коде. 4. Лучше отсутствие поля, чем “none/na”. Особенно для `energy`. --- ## (Опционально) Мини-правила для бота, чтобы не гадил **Tags:** максимум 3, если не уверен — не добавлять. **Kind:** выбирать из фиксированного списка; если сомневается — `[note]`. **Status:** бот всегда ставит `new` (а `processing/done` ставит пользователь вручную). **Energy:** только если `action_required: true`. --- ## Идеи на будущее (не для текущей реализации) ### Тегирование задач по контексту Если задач много или они связаны с разными проектами, можно добавить контекстные теги: ```md ## Задачи - [ ] #проект/бот Доделать обработку изображений - [ ] #личное Записаться к врачу - [ ] #работа Подготовить отчёт ``` Это позволит позже фильтровать задачи по контексту через Dataview. **Статус:** Не реализовано, обсудить при необходимости. --- ## Наброски промптов для агентов (коротко) ### Промпт: “структурируй входящую заметку” * запрещено добавлять факты * язык оригинала * YAML + секции * условные поля по правилам * исходник в свёрнутом callout сразу после YAML * комментарий-callout внизу с пустой строкой ### Промпт: “обнови статус” * `processing` ставит пользователь * `done` ⇒ `inbox: false` --- Да, ты прав 👍🙂 В мануале я **не дописал “зачем именно блок Комментарий” и как ты хочешь его использовать**, плюс есть ещё пару нюансов из нашего чата, которые лучше добавить как “доп. сноски/примечания”, чтобы агентам было проще не додумывать. Ниже — **дополнение к мануалу** (можешь просто вставить в конец документа отдельным разделом). --- ## Дополнение к мануалу — важные контекстные примечания 🧠 ### 1) Зачем нужен блок “Комментарий / команда для ИИ” Этот блок — не “заметки для себя”, а **управляющая команда на будущую дообработку**. **Сценарий, который ты описывал:** * Ты открываешь заметку на телефоне/компе. * Внизу в блоке “Комментарий / команда для ИИ” **диктуешь инструкцию** (без лишних действий вроде Enter). * Потом отдельный агент/скрипт/бот может: * прочитать этот блок, * выполнить указания (перенести/переформатировать/вынести задачи/переименовать/разложить по папкам), * и (опционально) очистить комментарий или пометить, что команда выполнена. **Примеры команд, которые ты имел в виду:** * "Перемести эту заметку в папку проекта X" * "Вынеси из текста задачи в чекбоксы" * "Оформи пункты аккуратно, сделай кратче" * "Раздели на 2 заметки: идея и задачи" * "Переименуй заголовок более понятно" * "Извлеки ссылки в отдельную заметку с названием 'Ресурсы по теме X'" * "Добавь эту идею в существующую заметку 'Название'" * "Создай событие в календаре на основе упомянутой даты" 📌 Это важно для агентов: блок "Комментарий" — **точка управления пайплайном**, а не просто поле "поболтать". --- ### 2) Почему “Исходник” именно свёрнутый и именно сразу после свойств Ты отказался от отдельного RAW-файла, потому что он будет **валяться и захламлять**. Поэтому исходник хранится: * в этом же файле, * **свернут по умолчанию**, * **сразу после frontmatter**, чтобы: * его легко нашёл агент (предсказуемое место), * он не мешал внизу (там у тебя “Комментарий / команда для ИИ”). --- ### 3) `title` / `summary` / `## Резюме` — это три разных слоя Чтобы агенты не путали: * `title` — короткое имя заметки для навигации (3–8 слов, можно “редакторски” переформулировать, но без новых фактов). * `summary` — **одна фраза**, “смысловой слепок”, не список деталей. * `## Резюме` — 1–3 предложения **для человека** (нормальное краткое резюме заметки). 📌 Важно: `summary` НЕ должен превращаться в “тег” и НЕ обязан быть уникальным. --- ### 4) Мульти-смысл в одной голосовухе: мы решили это через `kind` + `## Задачи` Ты заранее сказал, что в одной голосовой часто будет “всё сразу” (идея + задачи + проблема). Поэтому: * `kind` **может быть списком**: `[idea, task, problem]` * задачи вытаскиваются в `## Задачи` (чекбоксы) * “главный смысл” насильно выбирать не требуется (чтобы не страдать) --- ### 5) Про экономию токенов: где реально экономить, а где нет Мы обсуждали, что: * **лишняя пара YAML-полей почти не влияет** на стоимость, * стоимость жрёт **объём текста** (транскрипция, длинные буллеты, длинные резюме), * поэтому архитектурно выгоднее: * держать “стабильный минимум” полей, * а условные поля добавлять только по смыслу (это и чище, и не дороже). --- ### 6) Почему мы не храним эмодзи в YAML Идея “📥 inbox / 🟢 low” выглядит красиво, но мы решили: * **данные должны быть чистые** (иначе код/фильтры хрупкие), * эмодзи делаем в Dataview/визуализации, а не в свойствах. --- ### 7) Правило про `energy` Ты утвердил жёстко: * если `action_required: false` → поля `energy` **нет вообще** * никаких `none / na / irrelevant` --- ### 8) Теги: допускаем смешанные RU/EN, но ограничиваем шум Ты выбрал: * теги могут быть рус/англ вперемешку ✅ * лучше ограничить в будущем: **0–3 тега** * (опционально) потом можно ввести whitelist, чтобы не расползались варианты написания --- ### 9) Статусы: кто ставит и что означает Ключевое (чтобы агент не “улучшал” самовольно): * бот всегда создаёт `status: new` * `processing` и `done` ставит **пользователь вручную** * правило: `status: done` ⇒ `inbox: false` И смысл `done` ты задал как: * “заметка больше не требует внимания” * если там были задачи — значит они либо закрыты, либо вынесены так, что входящая закрыта --- ### 10) Имена файлов: почему без нумерации Ты специально отказался от нумерации, потому что: * при переносе по папкам номера становятся мусором * порядок не критичен (5–10 заметок в день ты переваришь) * защиту от дублей делаем суффиксом `(2)`. --- ## (Опционально) Мини-пояснение для будущего: “второй проход” обработки 🔁 Блок “Комментарий / команда для ИИ” можно использовать как триггер для **повторной обработки** заметки: * первый проход: бот структурирует и сохраняет * второй проход: ты добавляешь команду в комментарий * агент выполняет и приводит к финальному виду (перемещение, дробление на заметки, задачи в проекты и т.д.) Это прямо совпадает с твоей идеей “дальше запускать ИИшку и дообрабатывать по команде”. ---