Разработчики / Engineering ownership

Текущий цикл · v0.25.0

Люди, которые отвечают за качество системы.

TK Labs развивается не как набор отдельных экранов, а как единая рабочая платформа. Здесь зафиксированы реальные зоны ответственности: backend, отказоустойчивость, AI-системы, продуктовая архитектура и качество релизов.

Backend

Cloudflare · D1 · Durable Objects

Надёжность

Fallback · recovery · readiness

AI systems

Erma · routing · tools

Продукт

Workspace · interface · flows

01 / Ownership

Зоны ответственности

Каждое направление имеет понятного владельца. Это снижает размытость решений и помогает быстрее разбирать ошибки, деградации и спорные изменения.

TK portrait
Владелец направления

01 / TK LAB

TK

Backend, качество и отказоустойчивость

TK отвечает за backend-платформу TK Labs, качество релизов и способность системы продолжать работу при сбоях внешних сервисов.

Отвечает за

  • Backend и Cloudflare Worker runtime
  • Отказоустойчивость, fallback-маршруты и восстановление
  • CI/CD, release gates и production-проверки
  • Авторизация, D1, Durable Objects и серверные политики
  • Производительность, наблюдаемость и разбор инцидентов
THOMAS TM portrait
Владелец направления

02 / TK LAB

THOMAS TM

Product architecture и AI systems

THOMAS TM отвечает за продуктовую архитектуру, поведение AI-систем и целостность пользовательского опыта от модели до интерфейса.

Отвечает за

  • Архитектура продукта и рабочие сценарии
  • Модельные маршруты, Erma и Agent workflows
  • Информационная архитектура и интерфейсные системы
  • Функциональное направление и качество взаимодействия
  • Связь AI-возможностей с понятным продуктовым результатом

02 / Release discipline

Как мы выпускаем изменения

Отказоустойчивость начинается до production. Каждый патч должен пройти одинаковую последовательность проверки, безопасной деградации и наблюдения после выкладки.

Открыть статусИстория релизов
  1. 01ПроверитьTypeScript, lint, unit и integration-контракты должны остановить несовместимое изменение до сборки.
  2. 02СобратьProduction Worker собирается воспроизводимо из lockfile и проходит performance budget и dry-run.
  3. 03Деградировать безопасноСбой внешней модели не должен уничтожать запрос, локальные данные или весь интерфейс.
  4. 04Проверить productionReadiness endpoint и smoke-test подтверждают, что развернулась нужная версия и обязательные bindings доступны.
  5. 05РазобратьОшибки получают request ID, понятную классификацию и путь к восстановлению без раскрытия секретов.

03 / Reliability model

Инженерные принципы

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

Bounded failure

Один provider или один экран не должен обрушать всю рабочую среду.

Last known good

Кэш и сохранённое состояние используются только с явной маркировкой stale и ограниченным сроком.

Release evidence

Версия, cache namespace, документация и production-проверка обновляются одним патчем.

Clear ownership

Backend и отказоустойчивость имеют конкретного владельца, а не распределены абстрактно между всей командой.

04 / System map

Карта инженерной системы

Основные слои TK Labs и ответственность за их устойчивую совместную работу.

Edge runtimeCloudflare Worker, bindings, Durable Objects и D1TK
AI routingNVIDIA, Clodex, fallback policy и Erma modesTK × THOMAS
WorkspaceChat, Flow, artifacts, local archive и VaultTHOMAS × TK
Release systemCI, smoke tests, cache bump и production validationTK

TK LAB / Engineering

Качество — часть архитектуры.

Мы рассматриваем отказоустойчивость, backend и интерфейс как одну систему. Поэтому новые функции не считаются готовыми, пока для них не определены ограничения, fallback-поведение, проверка и владелец.

Открыть статусДокументация