В плане локального менеджера закладок появилась SQLite. Сам выбор выглядит разумно: один пользователь, небольшая база, ничего не нужно разворачивать на сервере. Но по названию базы ещё нельзя понять, что произойдёт при повторном сохранении ссылки и переживут ли изменения перезапуск приложения.
Такие вопросы стоит разобрать до кода. Для этого я сделал Research First Builder — скилл для ИИ‑агента и небольшую проверяющую программу. Он задаёт порядок работы: изучить похожие реализации, объяснить решения, составить план, написать приложение и записать проверки. Ниже разберу один реальный запуск из репозитория и покажу, какую работу этот порядок помогает проверить.
Что именно искал агент
В отчёте Bookmarks задача ограничена локальным приложением: URL, название, необязательные теги, поиск, редактирование и удаление. Пользователь один. Облако, аккаунты, Docker и отдельная сборка фронтенда не нужны.
Для исследования выбраны linkding, Buku и Shaarli. Они решают похожую задачу, но устроены по‑разному. Поэтому агент смотрел отдельные механизмы: обработку тегов, хранение URL и запись изменений. Переносить целиком архитектуру одного из этих продуктов в маленькую утилиту было бы странно — требования у них шире.
Отчёт запуска доступен в репозитории RFB. Разберём два решения из него.
Какие правила тегов брать из linkding
В изученной версии парсера удаляются пустые значения, убираются повторы без учёта регистра, преобразуются пробелы внутри тегов и сортируется результат.
Если перенести всё сразу, «Machine Learning» может превратиться в тег с дефисом. Для интерфейса новой утилиты принято другое правило: убрать пустые значения и дубли, но сохранить внутренние пробелы и первое написание. Два варианта регистра считаются одним тегом.
Здесь важно различать исходник и решение для своего приложения. Исходник показывает поведение linkding. Требования новой программы определяют, что из него брать. В отчёте нужны обе части; одной ссылки на известный репозиторий мало.
Что взять из Buku для SQLite
В схеме Buku URL имеет ограничение UNIQUE. В операции вставки используется параметризованный запрос, а в обычном режиме выполняется commit.
Для закладок это даёт два отдельных решения: хранить данные локально в SQLite и не разрешать повторную запись того же значения URL. Второе можно проверить маленьким примером на стандартной библиотеке Python:
import sqlite3 db = sqlite3.connect(":memory:") db.execute("CREATE TABLE bookmarks (url TEXT NOT NULL UNIQUE)") db.execute("INSERT INTO bookmarks VALUES (?)", ("https://example.com",)) db.commit() try: db.execute("INSERT INTO bookmarks VALUES (?)", ("https://example.com",)) except sqlite3.IntegrityError: print("Повторный URL отклонён") print("Записей:", db.execute("SELECT COUNT(*) FROM bookmarks").fetchone()[0]) db.close()
При выполнении получаем сообщение об отклонённом повторе и одну запись в таблице. Эта проверка отвечает на вопрос о UNIQUE. База здесь в памяти, поэтому сохранность после перезапуска нужно проверять отдельно, уже на файловой базе приложения. Нормализацию адресов ограничение тоже не делает: значения с завершающим слешем и без него могут остаться разными.
Как решение связывается с планом
RFB сохраняет исследование в RESEARCH.md, план — в PLAN.md, проверки — в VERIFICATION.md. В evidence.json записаны связи: источник, наблюдение, решение, шаг плана и проверка. По такой цепочке можно добраться от требования к конкретному месту в исходнике и к результату теста.
Решение получает один из исходов: ADOPT — берём сейчас, REJECT — не подходит этой задаче, DEFER — возвращаемся при новом требовании. В отчёте закладок файловый жизненный цикл Shaarli не перенесли в новую Python‑программу. Это отказ от конкретного механизма, а не оценка надёжности всего Shaarli: нижележащую атомарность его записи в том исследовании не проверяли.
У простой задачи может быть и результат NO‑PATTERN. Например, учебный фильтр JSON Lines в RFB обходится прямым кодом стандартной библиотеки. Исследование не должно заставлять утилиту обзаводиться архитектурой только ради красивого плана.
Где заканчивается проверяющая программа
rfb.py проверяет согласованность записей: разорванные связи, решения без нужных оснований, обязательные проверки и привязку к версии файлов. Саму разработку выполняет агент. Программа не читает репозитории за него, не ходит в сеть и не запускает команды из записанного JSON.
Отсюда понятная граница: если агент написал неверный вывод или сохранил неподлинный результат теста, структура отчёта может остаться правильной. Важные выводы и выполненные команды нужно проверять по содержанию. Снимок файлов также охватывает только то, что в него включили.
В локальной версии ed7e5cd3 повторно прошли тесты и проверки материалов трёх учебных реализаций. Полный запуск Bookmarks описан отдельно и использовал явное чтение файла скилла. Эти результаты не означают, что проверены все приложения и способы обнаружения скилла. Матрица совместимости и границы проверки вынесены в документацию репозитория.
С чего начать на своём проекте
Можно сначала попросить research‑only: агент исследует задачу и подготовит решения, но код пока не пишет. Для проверки материалов нужен Python 3.11 или новее. Один из способов установки через пакет требует Node.js 22.20 или новее; варианты описаны в README на русском.
Первый запрос лучше ограничить одним спорным механизмом. В случае закладок — хранением и уникальностью URL. После исследования откройте источник, решение и предложенный тест. Так становится понятно, какой именно вопрос агент закрыл, ещё до реализации всего приложения.
Сравнительного эксперимента, который доказал бы ускорение разработки с RFB, пока нет. Сейчас самый полезный результат — возможность проверить несколько решений по оставленным материалам. Исходники инструмента открыты: замечания к механизму проверки можно обсуждать по конкретному коду и отчёту.