Skip to content

glossary.md

Latest commit

 

History

History
189 lines (127 loc) · 8.41 KB

glossary.md

File metadata and controls

189 lines (127 loc) · 8.41 KB

📖 Глоссарий проекта Super Valera

Версия: 1.0 Дата создания: 26.10.2025 Тип документа: Reference (HOW) Цель: Единая терминология для всего проекта

🏗️ Фундаментальная терминология проекта

ПРОЕКТ (Project) = Super Valera Repository

Определение: Open-source Ruby on Rails репозиторий для создания AI-powered ботов для автосервисов.

Цель: Предоставить пользователям возможность запускать и создавать своих AI-powered ботов.

Целевая аудитория проекта:

  • Пользователи проекта - владельцы автосервисов, запускающие своего бота
  • Контрибьюторы - разработчики, улучшающие проект
  • Разработчики проекта - команда, развивающая репозиторий

Примеры использования:

  • "Скачать проект и запустить локально"
  • "Контрибьютить в проект"
  • "Документация проекта"

ПРОДУКТ (Product) = AI Bot Instance

Определение: AI-powered Telegram бот для консультаций и записи на автосервис (экземпляр, созданный на основе проекта).

Задача: Увеличить прибыль владельцев автосервисов через автоматизацию консультаций и записи.

Целевая аудитория продукта:

  • Клиенты автосервиса - владельцы автомобилей с повреждениями
  • Страховые клиенты - ОСАГО/КАСКО
  • Клиенты покраски/полировки

Примеры использования:

  • "Целевая аудитория продукта - клиенты автосервиса"
  • "Product Constitution - требования к продукту"
  • "Бизнес-цели продукта"

Ключевое различие

ПРОЕКТ → используют владельцы автосервисов (чтобы запустить бота) ПРОДУКТ → используют клиенты автосервиса (чтобы записаться на ремонт)

🎯 Термины документации и требований

User Story (Пользовательская история)

Определение: Описание функции с точки зрения пользователя в формате "As a... I want... So that...".

Когда используется:

  • Новые функции и фичи
  • Интеграции с внешними сервисами
  • Улучшения пользовательского опыта

Где находится: docs/requirements/user-stories/US-XXX-название.md

TDD (Technical Design Document)

Определение: Техническая спецификация с описанием архитектуры, компонентов, плана реализации и рисков.

Когда используется:

  • После одобрения User Story
  • Для детального планирования реализации
  • Как руководство для разработчиков

Где находится: docs/requirements/tsd/TSD-XXX-название.md

FLOW (Процесс разработки)

Определение: Стандартный процесс от идеи к коду в 3-5 часов через User Story + Technical Design.

Фазы:

  1. Phase 1: User Story Creation (1-2 часа) - что нужно пользователю
  2. Phase 2: Technical Design (2-3 часа) - как технически реализовать
  3. Phase 3: Implementation (сразу) - разработка по плану

Где определено: FLOW.md

WHY документ (Архитектурные решения)

Определение: Документ, объясняющий архитектурные решения, принципы и рациональность выбора.

Примеры:

Правило: WHY информация хранится в architecture/decisions.md и constitution.md, не дублируется в HOW документах.

HOW документ (Практические инструкции)

Определение: Документ с практическими инструкциями, командами и примерами для разработки.

Примеры:

🔄 Процесс и статусы

User Acceptance Criteria (UAC)

Определение: Критерии, по которым пользователь будет оценивать, готова ли функция.

Типы:

  • Functional: Функциональные требования
  • Performance: Требования к производительности
  • Non-Functional: Нефункциональные требования (UI/UX, доступность)

Definition of Done (DoD)

Определение: Чек-лист критериев, которые должны быть выполнены перед завершением задачи.

Примеры:

  • ✅ Code review пройден
  • ✅ Тесты написаны и проходят
  • ✅ Documentation обновлена
  • ✅ Commits в git с ясными сообщениями

Implementation Plan (План реализации)

Определение: Детальный план фаз и задач для реализации функции.

Где находится: TDD документ, раздел "Implementation Plan"

🏗️ Критичные архитектурные принципы

Dialogue-Only Interaction

КРИТИЧНЫЙ ПРИНЦИП: Взаимодействие пользователя с системой ТОЛЬКО через естественный язык, БЕЗ кнопок, меню или других UI элементов.

AI-First Approach

КРИТИЧНЫЙ ПРИНЦИП: AI является основным интерфейсом для взаимодействия, управления и решения задач.

System-First Logic Approach

Логика взаимодействия и управления поведением бота определяется через system prompts, а не через код.

Источник: Product Constitution

📊 Метрики KPI

Time to First Code

Определение: Время от идеи до первого написанного кода. Целевое значение: < 5 часов

Feature Completion Rate

Определение: Процент функций, полностью реализованных согласно требованиям. Целевое значение: > 95%

Iteration Speed

Определение: Время от одобрения требований до готовой функции. Целевое значение: 1-2 дня на функцию

📚 Ключевые документы

Документ Путь Тип
Product Constitution docs/product/constitution.md WHY
Architecture Decisions architecture/decisions.md WHY
CLAUDE.md CLAUDE.md HOW
FLOW docs/FLOW.md HOW
Требования docs/requirements/README.md HOW

Последнее обновление: 26.10.2025 Версия: 1.0