Что изменилось в 1.8
Страница для того, кто обновляется. Но прежде чем читать, что сломается, стоит знать, ради чего.
Что такое 1.8, в трёх пунктах
🧠 Общая база знаний — один файл на человека, а не на проект. Паттерн, тупик и конвенция больше не умирают вместе с проектом, который их узнал. --global кладёт знание туда, где его найдёт следующий проект; поиск читает оба хранилища. Разбор целиком: knowledge-store.md.
⏱ Конец серверной сессии. «Сессия» была двумя вещами — непрерывностью работы и гигиеной контекста агента. Разделение починило тихий отказ: отсутствие сессии больше не означает безлимитную ёмкость.
📦 Состояние команды едет в git. Задачи, решения и память — в читаемом дереве tausik/, возвращаются командой tausik sync.
Дальше — шесть ломающих изменений с миграцией, каждое с ответом на вопрос «касается ли это меня», и затем остальное новое.
Полный список правок: CHANGELOG.ru.md.
ЛОМАЮЩИЕ ИЗМЕНЕНИЯ
1. Классификатор снят с решения о публикации: decide больше НИКОГДА не публикует наружу сам
Было. tausik decide прогонял текст через классификатор, и если тот считал решение «общим», страница уезжала в Notion автоматически.
Стало. Видимость определяет автор, всегда:
| Команда | Куда попадает |
|---|---|
tausik decide "..." | только этот проект |
tausik decide "..." --global | локальная общая база знаний |
tausik brain move --to-brain <id> | наружу — и только так |
Почему ломающее, а не гигиена. Дефект был не в том, что эвристика иногда ошибалась, а в том, что решение о публикации принимала она, а не человек. Классификатор судил по текстовым маркерам и уже отправил наружу ШЕСТЬ внутренних решений — среди них решение об отмене плана 2.0 и решение о сроке релиза. Каждая сессия добавляла страницы.
Миграция. Ничего делать не нужно, но проверьте: если ваш рабочий процесс опирался на то, что решения появляются в Notion сами, теперь их надо публиковать явно. Уже опубликованные страницы остаются на месте — 1.8 ничего не удаляет снаружи.
Проверить, что вас это касается: вы видели страницы в Notion, которых не создавали руками.
2. Общая база знаний переехала из ~/.tausik/ в ~/.tausik-knowledge/
Было. ~/.tausik/knowledge.db. Стало. ~/.tausik-knowledge/knowledge.db; переопределяется $TAUSIK_HOME.
Почему. Выбор ~/.tausik был дефектом, доказанным измерением. Обнаружение проекта (find_tausik_dir) идёт вверх по дереву каталогов и ищет РОВНО имя .tausik. Значит каталог общей базы в домашней папке становился «проектом» для всего, что лежит под ней: из любого каталога без своего .tausik TAUSIK считал проектом домашнюю папку. Прецедент был рядом — brain всегда жил в ~/.tausik-brain, вне зоны поиска.
Миграция: ничего делать не нужно. База подхватывается со старого адреса при первом же обращении — adopt_legacy_store_if_present КОПИРУЕТ её в новое место. Копирует, а не переносит: в старом каталоге могло лежать что-то ещё, а удалять внутри чужой домашней папки — решение хозяина, не наше. Подхват срабатывает только когда в новом месте базы ещё нет, поэтому существующую он не затирает.
Одно исключение, и оно ваше. Если задана переменная TAUSIK_HOME, подхват НЕ выполняется вовсе: явно названный адрес — это адрес, и тянуть в него данные, на которые вызывающий не показывал, фреймворк не станет. В этом случае перенос за вами:
mkdir -p "$TAUSIK_HOME"
mv ~/.tausik/knowledge.db "$TAUSIK_HOME/knowledge.db"⚠️ Не создавайте ~/.tausik/ заново — см. взаимодействие с изменением 3. Старый каталог, оставшийся после подхвата, можно удалить руками; пока он есть, он продолжает притворяться проектом для всего, что лежит под домашней папкой.
Проверить: ls ~/.tausik-knowledge/knowledge.db — файл на месте.
3. Трастовые тиры конфигурации: project-тир может только УЖЕСТОЧАТЬ
Было. Гейт, отключённый в .tausik/config.json, оставался отключённым. Стало. Project-тир может только ужесточать надзор, не ослаблять. Такое отключение ИГНОРИРУЕТСЯ, гейт снова работает включённым, а tausik doctor называет отклонённый ключ поимённо.
Миграция. Перенесите послабление в доверенный тир:
# вариант A — пользовательский тир
$EDITOR ~/.tausik/config.json
# вариант B — управляемый тир (для организации)
export TAUSIK_MANAGED_CONFIG=/etc/tausik/config.json⚠️ ВЗАИМОДЕЙСТВИЕ С ИЗМЕНЕНИЕМ 2, названное здесь потому, что иначе его обнаружат на практике. Вариант A создаёт каталог ~/.tausik/ — то есть ровно тот каталог, из-за которого делали изменение 2. Обнаружение проекта снова начнёт считать домашнюю папку проектом для любого запуска из каталога, у которого нет своего .tausik выше по дереву.
Если это про вас, используйте переменную окружения вместо файла в домашней папке — она не создаёт каталог:
export TAUSIK_USER_CONFIG=~/.config/tausik/config.jsonЛибо вариант B, который каталог в ~ не создаёт вовсе.
Проверить, что вас это касается: tausik doctor — строка про отклонённый ключ конфигурации.
4. Схема квитанции verify: v1/v2 → v3
Было. Квитанция несла files_hash — непрозрачный отпечаток, который можно сравнить, но нельзя прочитать. Стало. tausik-receipt/v3 добавляет files (список путей), gate_signature (подпись набора гейтов) и подписанный expires_at.
Что со старыми квитанциями. Квитанции v1 и v2 остаются криптографически ВАЛИДНЫМИ, и прежний путь закрытия задачи (поиск свежего прогона) принимает их как раньше. Но предъявить такую квитанцию по новому хендлу нельзя: она не называет ни того, что покрыла, ни того, какие гейты отработали. Отказ перечисляет недостающие поля поимённо.
Область квитанции v1 по-прежнему читается как непроверенная, а не как полная.
Миграция. Внешним читателям квитанций — обработать три новых поля. Своих действий не требуется: первый же tausik verify выпускает v3.
Подробности: receipts.md.
5. Прогон verify без объявленной области больше ничего не сертифицирует
Было. tausik verify --task X, запущенный до того, как задача объявила relevant_files, записывал зелёный результат по ПУСТОМУ набору файлов — и этот зелёный оставался пригодным весь срок жизни кэша.
Стало. Необъявленная область считается «неизвестной», а не «проверенной пустотой». Прогон с пустой областью по-прежнему записывается и остаётся наблюдаемым, но переиспользовать его для закрытия задачи нельзя.
Почему это ломающее, а не просто ужесточение. Два свойства сложились в дыру. gate_runner ПРОПУСКАЕТ областные гейты, когда файлы не объявлены, — значит прогон не доказал ничего ни про один файл; а compute_files_hash([]) возвращает устойчивый маркер пустоты, который не сдвигает ни одна правка, — значит зелёный никогда не протухал. Последовательность verify → правка → task done проходила QG-2 по зелёному, взятому ДО правки. Отказ выставлен ПЕРЕД опцией task_done.auto_verify, а не после неё: .tausik/config.json едет вместе с репозиторием и не является безопасным местом для обхода.
Миграция. Чтобы закрыться по зелёному verify, задача обязана объявить relevant_files:
tausik verify --task <slug> --relevant-files <пути...>Закрытие по необъявленной области теперь блокируется, и сообщение называет именно эту причину, а не просит ещё один tausik verify, который всё равно не мог бы помочь. Полный прогон tausik verify без --task не затронут — он никогда не кэшировался.
Касается ли вас? Вы зовёте tausik verify --task без --relevant-files либо полагаетесь на task_done.auto_verify.
6. TAUSIK_HOME проверяется, и часть расположений теперь отвергается
Было. TAUSIK_HOME принимался как есть — abspath(expanduser(...)) и больше ничего. Общая база знаний могла лежать в любом каталоге.
Стало. Расположение проверяется до открытия хранилища. Сетевой путь (UNC либо подключённый или примонтированный сетевой том) и каталог облачной синхронизации (OneDrive, включая OneDrive - Компания; Dropbox; Google Drive; iCloud; Яндекс.Диск; дерево ~/Library/CloudStorage/ на macOS) — ОТКАЗ. Хранилище, которое git УЖЕ ОТСЛЕЖИВАЕТ, — отказ. Хранилище, просто лежащее внутри git-дерева, НЕ отвергается: ему создаётся собственный .gitignore, — потому что отказ здесь забраковал бы расположение по умолчанию у каждого, кто держит домашний каталог в репозитории дотфайлов.
Почему это ЛОМАЮЩЕЕ, а не гигиена. Оно отвергает установку, работавшую вчера, и снять отказ можете только вы. Хранилище пишется БЕЗ редактирования, и всё записанное обоснование этого — что оно не покидает эту машину. Это свойство не кода, а КАТАЛОГА, и его называет эта переменная. ~/OneDrive находится внутри домашней папки, поэтому «оно в моём доме» оставалось правдой, а вывод из этого тихо переставал ею быть.
Миграция. Направьте TAUSIK_HOME в локальный каталог вне синхронизируемого дерева и перенесите хранилище:
tausik doctor # покажет, куда он разрешается сейчас
tausik knowledge export <dir> # СНАЧАЛА со старого расположения
TAUSIK_HOME=<новый-локальный-каталог> tausik knowledge restore <dir>Если отказ называет ОТСЛЕЖИВАНИЕ git, хранилище уже попало в коммит: снимите его с учёта средствами git и вынесите TAUSIK_HOME за пределы репозитория. Правило игнорирования не убирает то, что уже в индексе.
Касается ли вас? Вы задали TAUSIK_HOME внутри OneDrive, Dropbox, Google Drive, iCloud или похожего клиента; на сетевую шару либо подключённый диск; или knowledge.db закоммичен в репозиторий. Если TAUSIK_HOME не задан, значение по умолчанию ~/.tausik-knowledge не затронуто — если только сам домашний каталог не лежит в синхронизируемом дереве.
Что нового
Общая база знаний — один файл на человека, а не на проект
Главное в 1.8, и до этой страницы оно доходило только косвенно — через ломающее изменение 2, где сказано, что база ПЕРЕЕХАЛА. Переехало то, что в 1.8 и появилось.
Что было. Паттерн, тупик и конвенция жили внутри одного проекта и умирали вместе с ним. Следующий проект начинал с нуля, а человек, работающий с тремя заказчиками, трижды заново узнавал одно и то же.
Что стало. Есть общее хранилище — ~/.tausik-knowledge/knowledge.db, один файл на человека:
tausik memory add pattern "Заголовок" "Текст" --global # положить в общее
tausik search "запрос" # ищет и там, и там--globalкладёт знание в общую базу либо падает, сказав об этом — молча в проект не свалится.- Поиск и блок знаний при старте сессии читают общую базу наравне с проектной.
- У хранилища есть бэкап, и он остаётся на этой машине.
- Старый TAUSIK, встретив базу новее своей схемы, отказывается работать, а не угадывает формат.
- Строки больше не хранят, от какого заказчика пришли:
origin_projectдержит меткуbasename@отпечатоквместо абсолютного корня проекта. Существующие строки переписываются при первом открытии, действий не требуется.
Чего у неё нет и это намеренно. Хранилище пишется БЕЗ редактирования — ровно поэтому оно не покидает машину, и ровно поэтому TAUSIK_HOME теперь проверяется (ломающее изменение 6). Кладите в общее то, что верно ВЕЗДЕ; фактам об ЭТОМ проекте место в проектной памяти.
Остальное
- Хендл прогона verify.
tausik verify --task <slug>печатает<run_id>.<nonce>;task done --verify-handleпредъявляет его вместо того, чтобы сервер искал свежую строку. Отказ теперь говорит по существу («файлы, которые покрывает квитанция, изменились»), а не «промах кэша». Одноразовый, срок годности час, проверяется по живым файлам и живому конфигу гейтов. Приём SEP-2567 «explicit state handles». См. receipts.md. Прежнее поведение сохранено: без--verify-handleвсё работает как раньше. - «Сессия» разделена на две вещи — непрерывность работы и гигиену контекста агента. Отсутствие сессии больше не означает «безлимитная ёмкость»: гейт на 200 вызовов перестал молча пропускать. Handoff больше не требует открытой сессии. См. sessions.md.
- Notion стал необязательным по факту, а не по флагу — см. изменение 1.
Смотрите также
- upgrade.md — общая процедура обновления.
- config-trust-tiers.md — тиры конфигурации целиком.
- knowledge-store.md — общая база знаний целиком: чем отличается от проектной и что куда класть.
- receipts.md — квитанции и хендлы.
- sessions.md — две половины сессии.