forked from Pikaliov/fuze_task
Multimodal fusion research on StripNet+GTA-UAV proxy: - 3 independent fusion tracks: condition-aware (A), token/bottleneck (B), role-aware (C) - Shared interfaces, protocol, dataset audit, baseline benchmarks - Canonical version-chain references to vault (SPEC, ANALYSIS, TRIAGE) - Personalized task plans and decision tables for each researcher - 3 generated DOCX task assignment files with milestones and DoD checklist - Full modality dropout diagnostics and missing-modality robustness requirements - Data contract, benchmark registry, experiment tracking infrastructure Operational documents: - docs/00_project/: MERIDIAN context, protocol, repository reuse guide, experiment specification - docs/01_tasks/: Master assignment + 3 individual researcher tracks + joint integration - docs/02_references/: Core literature, version-chain bases, code maps - docs/03_codebase_guides/: Existing code snapshots from vault - scripts/: gen_task_plans.js (DOCX generation), placeholder infrastructure - vendor_reference/: Snapshots of caption_test, depth_edges_annotate, existing SOFIA/SegModel code - reports/, results/, experiments/: Shared output structure for all 3 researchers 3 DOCX files generated from gen_task_plans.js (Times New Roman 14pt, GOST format): - План_заданий_Павленко_БВ.docx (Condition-Aware track, fusion API owner) - План_заданий_Близно_МВ.docx (Token/Bottleneck track, benchmark owner) - План_заданий_Мороз_ЕС.docx (Role-Aware track, data contract owner) Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
129 lines
5.9 KiB
Markdown
129 lines
5.9 KiB
Markdown
# Регламент совместной работы
|
||
|
||
## 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`
|