Skip to content

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, тесты и уже установленные проекты.

Целевое дерево ​

text
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/           # установка и генерация профилей

Зависимости идут в одну сторону:

text
CLI / MCP / hooks -> application -> domain
                         |
                         v
                  infrastructure

Domain не импортирует CLI, MCP, bootstrap, host-adapter или SQLite. CLI и MCP остаются тонкими оболочками над одним application service.

Baseline миграций ​

Нельзя squash'ить цепочку 1.11 на месте: существующим базам она ещё нужна.

  1. Схема v67 и историческая цепочка остаются в линии поддержки 1.11.x.
  2. До переноса кода 2.0 объявляется минимальная версия, с которой обновляет 2.0. Рекомендуемая граница — все выпущенные схемы 1.11.x, а не все схемы за всю историю проекта.
  3. Новая база 2.0 строится из одного канонического baseline и не проигрывает исторические миграции.
  4. От каждой поддерживаемой схемы 1.11.x добавляется один проверенный мост к baseline 2.0.
  5. Модули v2-v67 уходят из обычного import path 2.0 только после публикации границы поддержки и проверки сохранности данных, индексов, FTS, receipts, задач, памяти и решений.

Если нужна поддержка базы старше 1.11, старая цепочка остаётся в явной команде или compatibility-пакете. Обычный старт 2.0 её не импортирует.

Порядок перехода ​

  1. Зафиксировать и опубликовать политику схемы и поддержки 1.11.
  2. Добавить пакет src/tausik и проверки границ импортов.
  3. Переносить вертикальными срезами: backend, application services, gates, CLI, затем hosts и bootstrap.
  4. Временно оставить верхнеуровневые entry point, импортирующие пакет; удалять каждый shim после перехода всех поставляемых потребителей.
  5. Перевести генерацию профилей с копирования отдельных модулей на одно дерево пакета.
  6. Удалить инъекцию плоского каталога в sys.path и compatibility shims.

На каждом шаге исходные тесты и сгенерированные профили импортируют одну и ту же реализацию. Вторая копия кода не считается compatibility layer.

Граница выпуска ​

TAUSIK 1.11 получает экономию токенов и документацию. Он не перемещает runtime модули и не удаляет историю обновлений. Пакетный перенос и baseline миграций — работа 2.0, потому что она намеренно меняет import- и support-контракты.