fuze_task/docs/00_project/02_TEAM_WORKFLOW.md

Регламент совместной работы

1. Принцип

У команды три архитектурных трека, но одна кодовая и экспериментальная система. Каждый сотрудник отвечает за собственную гипотезу и одновременно за один общий слой проекта.

2. Распределение ответственности

Область	Driver	Обязательные reviewers
Fusion API и registry	Павленко	Близно, Мороз
Dataset и modality validation	Мороз	Павленко, Близно
Training/eval benchmark	Близно	Павленко, Мороз
Condition-aware module	Павленко	Мороз
Token/bottleneck module	Близно	Павленко
Role-aware module	Мороз	Близно
Общая experiment matrix	Близно	все
Финальная архитектурная оценка	все	все

3. Этапы

Gate 0. Environment audit

• Проверить локальные пути двух внешних проектов.
• Зафиксировать путь GTA-UAV RGB, captions, pair JSON и annotations.
• Проверить checkpoint StripNet.
• Выполнить чтение обязательного пакета.
• Создать reports/joint/ENVIRONMENT_AUDIT.md.

Gate 1. Interface freeze

До реализации архитектур команда совместно утверждает:

1. Формат segmentation: IDs/embedding или probabilities.
2. Формат CHM/depth и normalization.
3. Text encoder, уровни captions и output dimension.
4. FusionModelBase API.
5. Common diagnostics keys.
6. Baseline config и output directory convention.

Результат: reports/joint/INTERFACE_DECISION.md. Изменения после freeze требуют записи причины и влияния на все три варианта.

Gate 2. RGB-only baseline

• Один общий StripNet-only run.
• Один общий dataloader.
• Один общий evaluation script.
• Smoke run на малом subset.
• Полный baseline минимум на seed 42, затем финальный baseline на 42/123/456.

Без подтверждённого baseline реализация fusion не переходит к полным запускам.

Gate 3. Independent implementation behind common API

Каждый сотрудник реализует свой модуль в отдельной feature branch. Разрешены разные внутренние операторы, но входы, выходы, loss и logging одинаковы.

Gate 4. Pair review

Reviewer проверяет:

• shape contract;
• отсутствие cross-view leakage;
• корректность masks;
• identity/residual path;
• вычислительную сложность;
• диагностируемость вклада модальностей;
• тесты и gin config.

Gate 5. Smoke comparison

Все три модуля запускаются:

• на одном subset;
• с одним seed;
• на одинаковом числе batches;
• с одинаковым optimizer/loss;
• с logging peak VRAM и latency.

Цель: найти ошибки интеграции, а не выбрать победителя.

Gate 6. Full experiment matrix

После smoke comparison выполняются primary runs и выбранные ablations по общему protocol.

Gate 7. Joint decision

Команда совместно заполняет decision table. Архитектура не выбирается по одному лучшему run. Учитываются mean, variance, compute, стабильность и интерпретируемость вклада модальностей.

4. Git workflow

Действие	Правило
Branch	один трек на feature branch
Commit	один логический change set
PR	содержит design link, config, tests и ожидаемые shapes
Review	минимум один назначенный reviewer, общие API требуют двух
Merge	только после тестов и smoke forward
Experiment tag	FUS-{family}-{variant}-s{seed}

5. Ежедневная синхронизация

Короткая запись в reports/joint/WORKLOG.md:

Поле	Содержание
Сделано	конкретный код, анализ или run
Проверено	tests, shapes, metrics
Решение	принятое архитектурное решение
Блокер	что мешает и кто помогает
Следующий шаг	один проверяемый результат

6. Правила разрешения конфликтов

1. Общий protocol имеет приоритет над удобством отдельной реализации.
2. Если архитектуре нужен иной input contract, сначала готовится RFC с влиянием на все варианты.
3. Если два варианта требуют несовместимых изменений, адаптация помещается внутрь variant module, а общий batch сохраняется.
4. Изменение метрики после просмотра результатов запрещено без отдельной записи причины.
5. Любой найденный data leakage немедленно останавливает затронутые runs.

7. Обязательные совместные документы

• ENVIRONMENT_AUDIT.md
• INTERFACE_DECISION.md
• BASELINE_REPORT.md
• WORKLOG.md
• EXPERIMENT_STATUS.md
• FINAL_COMPARISON.md
• DECISION_RECORD.md