English | Русский
Пакетная архитектура TAUSIK 2.0
Зачем это нужно
В TAUSIK 1.11 внутри scripts/ находятся 563 файла, 502 из них — прямо в корне. Backend занимает 71 корневой модуль. Цепочка миграций состоит из 34 файлов backend_migrations_v*.py и 2 541 строки для версий схемы до v67.
Это контракт старой поставки, а не спроектированная граница пакетов. Bootstrap копирует scripts/ в профиль каждого хоста, а несколько entry point добавляют плоский каталог в sys.path. Перемещение файлов в 1.11 одновременно сломает bootstrap, hooks, MCP-imports, тесты и уже установленные проекты.
Целевое дерево
src/tausik/
├── cli/ # argparse и терминальный вывод
├── application/ # use cases ProjectService и quality gates
│ ├── tasks/
│ ├── knowledge/
│ ├── verification/
│ └── skills/
├── domain/ # типы и правила без SQLite, CLI и host-imports
├── infrastructure/
│ ├── db/ # SQLite repositories и текущая схема
│ │ └── migrations/ # baseline 2.0 и поддерживаемые upgrade-мосты
│ ├── providers/ # адаптеры Codex, Kilo и будущих провайдеров
│ └── supply_chain/ # подписи, receipts и publication boundaries
├── gates/ # реестр, runners и выбор затронутых тестов
├── hosts/ # тонкие host-adapters; каноническое поведение выше
└── bootstrap/ # установка и генерация профилейЗависимости идут в одну сторону:
CLI / MCP / hooks -> application -> domain
|
v
infrastructureDomain не импортирует CLI, MCP, bootstrap, host-adapter или SQLite. CLI и MCP остаются тонкими оболочками над одним application service.
Baseline миграций
Нельзя squash'ить цепочку 1.11 на месте: существующим базам она ещё нужна.
- Схема v67 и историческая цепочка остаются в линии поддержки 1.11.x.
- До переноса кода 2.0 объявляется минимальная версия, с которой обновляет 2.0. Рекомендуемая граница — все выпущенные схемы 1.11.x, а не все схемы за всю историю проекта.
- Новая база 2.0 строится из одного канонического baseline и не проигрывает исторические миграции.
- От каждой поддерживаемой схемы 1.11.x добавляется один проверенный мост к baseline 2.0.
- Модули v2-v67 уходят из обычного import path 2.0 только после публикации границы поддержки и проверки сохранности данных, индексов, FTS, receipts, задач, памяти и решений.
Если нужна поддержка базы старше 1.11, старая цепочка остаётся в явной команде или compatibility-пакете. Обычный старт 2.0 её не импортирует.
Порядок перехода
- Зафиксировать и опубликовать политику схемы и поддержки 1.11.
- Добавить пакет
src/tausikи проверки границ импортов. - Переносить вертикальными срезами: backend, application services, gates, CLI, затем hosts и bootstrap.
- Временно оставить верхнеуровневые entry point, импортирующие пакет; удалять каждый shim после перехода всех поставляемых потребителей.
- Перевести генерацию профилей с копирования отдельных модулей на одно дерево пакета.
- Удалить инъекцию плоского каталога в
sys.pathи compatibility shims.
На каждом шаге исходные тесты и сгенерированные профили импортируют одну и ту же реализацию. Вторая копия кода не считается compatibility layer.
Граница выпуска
TAUSIK 1.11 получает экономию токенов и документацию. Он не перемещает runtime модули и не удаляет историю обновлений. Пакетный перенос и baseline миграций — работа 2.0, потому что она намеренно меняет import- и support-контракты.