Razbor Bardaka

Разбор Бардака (экспериментальный)

Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю экспериментальный навык «Разбор информационного беспорядка» (обратная связь — @kir-kopylov): <кратко назовите конкретную пользу для текущего запроса>; продолжаю без ожидания.

Не включайте в строку author_github, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

Обзор

Skill превращает свалку (файлы, заметки, закладки, промпты, что угодно) в понятную структуру папок, в которой владелец находит нужное за секунды. Ничего не перекладывает и не удаляет без явного «да».

Общайтесь с владельцем простым языком, без жаргона: «структура папок», а не «таксономия»; «файл-задание», а не «handoff».

Три факта, на которых построен процесс:

1. Названия папок врут. Владелец копил годами; папка «недвижимость» может содержать заметку про объяснение слов. Классифицируйте по лучшему доступному сигналу самого объекта, никогда — по имени папки.
2. Правильная структура живёт в голове владельца, а не в данных. Кластеризация по содержимому даёт «логичную» схему, которой неудобно пользоваться. Ось структуры — то, что владелец ПОМНИТ, когда ищет вещь. Это узнаётся только вопросом и проверяется только на его реальных объектах.
3. Половина смертей таких задач — необратимое действие или сломанная синхронизация. Поэтому до финального «да» — только чтение; перекладка — отдельная фаза с пробой на одном объекте.

Фаза 1 — Разведка (до любых вопросов владельцу)

Сначала инструментами, потом вопросами: разведка обычно снимает половину вопросов и находит жёсткие ограничения.

1. Определите канал доступа к данным. Сначала штатный: файловая система напрямую, экспорт, API, AppleScript. Только если штатного нет — файлы/база приложения (на macOS обычно ~/Library/Containers/<bundle-id>/ или ~/Library/Application Support/). Базу или единый файл-хранилище скопируйте и анализируйте копию; обычную папку с файлами не копируйте — фазы 1–4 только читают.
2. Посчитайте корпус: сколько объектов, сколько текущих папок (если есть), какие типы (текст, картинки, бинарники, ссылки, пустые).
3. Проверьте жёсткие ограничения ДО проектирования структуры:
   • Вложенные папки поддерживаются? (видно в интерфейсе или документации; для баз — по parent-полю в схеме). Плоское хранилище → иерархию эмулировать префиксами имён ПАПОК: «Домен · Подтема». Если папок нет вообще — переименование самих объектов возможно только как отдельно согласованный механизм, показанный на карте.
   • Есть ли синхронизация с облаком или аккаунтом (iCloud/CloudKit, синхронизация браузера, облачный диск)? Синхронизируемое хранилище меняется только штатным механизмом — интерфейс приложения, API, AppleScript. Запись в его файлы/базу напрямую запрещена всегда: порча синка проявляется асинхронно и на других устройствах, «удачная проба» ничего не доказывает.
4. Прочитайте выборку объектов из разных частей корпуса (разных папок, если есть, иначе — разных типов и дат) — она покажет реальный разброс тем и проверит, врут ли имена.

Фаза 2 — Вопросы Владельцу

Проверку проводи внутренне; пользователю не показывай вероятные ответы и карту изменений.

Перед любым вопросом проведи контрфактическую проверку: Представь наиболее вероятные ответы пользователя. Назови, какое решение, действие или часть результата изменит каждый ответ. Если следующий шаг при всех ответах одинаков — вопрос запрещён. Если пользователь уже зафиксировал выбор — запиши его, не открывай заново. Если неизвестное техническое и его можно проверить самостоятельно — проверь, не спрашивай. Задавай только ближайший вопрос, ответ на который реально меняет результат.

Каждый вопрос обязан менять результат; вопросы «для полноты» запрещены. Формат — один вопрос за ход. После ответа заново выберите ближайший вопрос; живые примеры показывайте по одному. Самые важные первыми:

1. Ось поиска: «Когда вы ищете вещь в этой коллекции — что вы о ней помните в первую очередь?» (тему/задачу, тип действия, инструмент, время). Это верхний уровень структуры.
2. Живые примеры (обязательно): подготовьте до 3 реальных объектов из разных частей корпуса и показывайте по одному: «вот это — куда должно лечь?» После каждого ответа проверьте, изменит ли следующий пример структуру; если нет — не спрашивайте. Полученные ответы становятся контрольными проверками результата. Абстрактно спрашивать бесполезно — владелец сам не знает свою ось, пока не увидит конкретную вещь.
3. Судьба дублей и мусора: по умолчанию — отдельный список кандидатов с причинами, ничего не удалять. «Устаревшее» попадает в список только по критерию, который назвал сам владелец; без критерия — не включать.
4. Периметр: что входит в разбор, а что нет (например, история буфера обмена — не сохранённые шаблоны; вложения — не заметки).

«Не знаю» — допустимый ответ: запишите пробел в ASSUMPTIONS.md и отразите обе трактовки в двух вариантах структуры (например, разная ось верхнего уровня в крупном и подробном) — владелец выберет глазами на карте.

Фаза 3 — Раскладка На Бумаге

Всё в отдельной папке проекта (в рабочей директории пользователя, не в Downloads), под git с коммитами после каждого зелёного состояния.

Артефакты:

• inventory.csv — каждый объект: стабильный идентификатор (id из базы, полный путь или URL — сырой локатор живёт только здесь), текущая папка (если есть), имя, тип, дата, выдержка. Полные тексты — в items/<file_id>.txt, только для текстовых объектов; file_id — производное безопасное имя файла (короткий hash или slug от идентификатора), а не сырой путь/URL: слэши и двоеточия в имени ломают запись или уводят файл из папки items/.
• Два варианта структуры: крупный (≤10 папок) и подробный (10–20, через префиксы «Домен · Подтема»). Для каждой папки — критерий включения одной строкой + счётчик.
• mapping.csv — КАЖДЫЙ объект приписан к папке в обоих вариантах. Без пустых мест.
• kill_list.csv — дубли (точные и почти-копии: file (1).ext, одинаковые URL, итерации одной вещи — новейшая как основная, ранние в список, выбор пометить как допущение), устаревшее (только по критерию владельца), нечитаемое. С причинами. Объекты остаются в mapping.
• Проверочный скрипт: количество в mapping = количеству в inventory; пустых папок нет; живые примеры владельца легли туда, куда он сказал.

Правила классификации:

• Ось — как владелец ИЩЕТ и ИСПОЛЬЗУЕТ, не буквальное содержание (промпт-приём «решай как первокурсник» лежит в «Учёбе», потому что применяется там).
• Сигнал для классификации: текст — содержимое; бинарники — тип, метаданные, беглый просмотр; ссылки — URL и заголовок. Имя объекта — подсказка, не истина.
• Объекты без явной темы (приёмы, стили, мета) → свой домен, не размазывать по «Прочее».
• Сомнение между двумя папками → решить по ответам владельца на живых примерах и оси поиска; если сигнала нет — выбрать один следующий вопрос или положить объект в более крупный домен, записав допущение в ASSUMPTIONS.md.
• Большой корпус — батчами по ~30 с записью на диск после каждого, чтобы не держать всё в голове.

Повторный разбор той же коллекции: не пересчитывайте всё — сверьте живой корпус с прошлым mapping.csv, классифицируйте только новое, удалённое выкиньте из артефактов, прошлые решения не трогайте. Так сохраняются ручные правки владельца.

Фаза 4 — Наглядная Карта (до любых перемещений)

Владелец должен УВИДЕТЬ будущую раскладку и утвердить её глазами. Сделайте интерактивную HTML-карту (домены → папки-аккордеоны → объекты с пометкой «из какой старой папки», метки «новый»/«дубль» с причиной, поиск) и продублируйте скелет структуры текстом прямо в ответе. Явно скажите: «это предложение, в хранилище ничего не тронуто».

Фаза 5 — Перекладка (только после явного «да» на конкретный вариант)

«Да» может прозвучать в той же сессии, где показана карта, — этого достаточно; без «да» не начинать никогда.

0. Гейт актуальности: свежая резервная копия хранилища + сверка живого корпуса с inventory. Появившееся с момента снимка — доклассифицировать (или спросить владельца) ДО перемещений; иначе «каждый объект приписан» уже неправда.
1. Выберите механизм: для синхронизируемых хранилищ — только интерфейс приложения или официальный API/AppleScript; для локальных без синхронизации — допустима и прямая работа с файлами/базой, но гипотезу безопасности проверяйте пробой, а до пробы считайте её ложной.
2. Проба на одном объекте: переместите ОДИН; перезапустите приложение (если объекты живут в приложении) или обновите листинг; проверьте — объект на месте, не задвоился, а при наличии синхронизации изменение дошло до облака (веб-версия или второе устройство, если доступны; иначе — статус/логи синка после полного цикла).
3. Проба красная → стоп: не пробуйте молча другой механизм, откатите единственный объект тем же способом, доложите владельцу.
4. Проба зелёная → остальное батчами со сверкой после каждого.
5. Удаление старых пустых папок и объектов из kill-list — только после того, как владелец видел состав списка на карте; точные дубли и «устаревшее/почти-копии» подтверждаются отдельными «да».

Если работа передаётся в другую сессию — соберите файл-задание (цель, done-критерии, запреты, пути, проба-гейт, контрольные примеры) рядом с артефактами.

Границы

• Не верить названиям папок; объект судить по его лучшему доступному сигналу.
• Не удалять и не редактировать объекты без отдельного «да» на просмотренный владельцем список.
• Не писать напрямую в файлы/базы синхронизируемых хранилищ — ни в работе, ни «на пробу».
• Не заполнять пробелы догадками («скорее всего», «обычно») — спросить или пометить пробел.
• Не выдавать один «правильный» вариант структуры — минимум два, выбор за владельцем.
• Не начинать перекладку, пока владелец не увидел карту и не сказал явное «да» конкретному варианту.
• Не для чистки диска ради места, не для задач и обязательств (vtoroy-mozg), не для переименования по шаблону.

Definition Of Done

Владелец видел карту, выбрал вариант, проверочный скрипт зелёный (всё посчитано, ничего не потерялось, контрольные примеры на месте) — и либо перекладка выполнена с пробой-гейтом, либо владелец осознанно остановился на «раскладке на бумаге».

Опрос После Использования

Опрос задаётся один раз — после сдачи карты владельцу или после завершения перекладки (что случилось последним), не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

Опрос по skill:
1. Что в этом использовании razbor-bardaka было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/razbor-bardaka/usage-feedback.jsonl — лучше через bundled script:

python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет в JSONL redaction_applied и redaction_types. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

Логирование Сбоев

Перед выполнением прочитайте локальный known-exceptions.yaml как список уже известных случаев и применяйте подходящее do_next_time без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в ~/.codex/skill-runs/<skill-name>/exception-log.jsonl.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите unknown. Raw logs не коммитить.