# Участники разработки

## Правовые аспекты и требования к контрибуторам

Настоящий документ устанавливает требования и процедуры для участников разработки программного изделия (ПИ) «Ъ» (компонент «Токенизатор») в рамках Проекта «Твердь».

---

### 1. Общие положения

Разработка ПИ ведется в соответствии с требованиями к безопасной разработке (SDL) и направлена на создание детерминированного системного программного обеспечения, предназначенного для сертификации на отсутствие недекларированных возможностей (НДВ).

### 2. Требования к участникам разработки

#### 2.1. Квалификационные требования

Участники разработки должны обладать:

* **Технической компетентностью:** Знание языка программирования Rust, понимание принципов компиляторостроения, лексического анализа и обработки формальных грамматик.
* **Безопасностью разработки:** Понимание принципов безопасной разработки программного обеспечения, знание методов защиты от внедрения уязвимостей.
* **Специализацией:** Опыт работы с системами, требующими сертификации, понимание специфики разработки для архитектур семейства «Эльбрус» и x86.

#### 2.2. Обязательства участников

* Соблюдение принципов безопасной разработки (SDL) на всех этапах жизненного цикла программного обеспечения.
* Обеспечение прослеживаемости всех изменений кода и документации.
* Строгое следование установленным стандартам кодирования и архитектурным решениям проекта.
* Гарантирование отсутствия недекларированных возможностей в реализуемом коде.

### 3. Процедура внесения изменений

#### 3.1. Подготовка изменений

* Все изменения должны быть задокументированы с указанием мотивации и области применения.
* Изменения должны сопровождаться соответствующими тестами, обеспечивающими верификацию функциональности.
* Код должен соответствовать требованиям `no_std` окружения и не использовать внешние динамические библиотеки.

#### 3.2. Процесс ревью

* Все изменения проходят обязательное ревью кода с фокусом на безопасность и соответствие требованиям проекта.
* Особое внимание уделяется проверке отсутствия потенциальных векторов атак и скрытых возможностей.
* Изменения, затрагивающие критичные компоненты (токенизатор, обработка UTF-8, грамматика), требуют расширенного ревью.

#### 3.3. Требования к коммитам

* Коммиты должны содержать четкое описание внесенных изменений.
* Ссылки на соответствующие задачи и требования технического задания.
* Информация о влиянии изменений на безопасность и детерминизм системы.

### 4. Области ответственности

#### 4.1. Модули проекта

| Модуль | Область ответственности | Критичность |
| :--- | :--- | :--- |
| `tokenizer.rs` | Основной лексический анализатор | Высокая |
| `token.rs` | Определения типов токенов | Высокая |
| `grammar.rs` | Правила и константы грамматики | Высокая |
| `dfa.rs` | Состояния детерминированного конечного автомата | Высокая |
| `utf8.rs` | Обработка UTF-8 последовательностей | Высокая |
| `position.rs` | Отслеживание позиций токенов | Средняя |
| `error.rs` | Обработка ошибок | Средняя |
| `comment.rs` | Обработка комментариев | Низкая |

#### 4.2. Тестирование

* Все новые функции должны сопровождаться соответствующими тестами.
* Особое внимание уделяется тестам для кириллических идентификаторов и обработки UTF-8.
* Интеграционные тесты должны покрывать критические сценарии использования.

### 5. Контроль качества кода

#### 5.1. Статический анализ

* Код должен проходить статический анализ без ошибок и предупреждений.
* Использование механизмов строгой типизации языка Rust для обеспечения безопасности на этапе компиляции.
* Соблюдение принципов `no_std` разработки.

#### 5.2. Проверка безопасности

* Анализ на наличие потенциальных уязвимостей безопасности.
* Проверка отсутствия недекларированных возможностей.
* Верификация детерминизма реализуемых алгоритмов.

### 6. Документирование

#### 6.1. Требования к документации

* Все публичные функции и структуры должны содержать документацию в формате Rust doc.
* Изменения в грамматике языка должны отражаться в файле `docs/grammar.md`.
* Критические архитектурные решения должны документироваться отдельно.

#### 6.2. Обновление документации

* Документация должна обновляться синхронно с изменениями кода.
* Изменения в API должны быть задокументированы с указанием причин и миграционных путей.

### 7. Конфиденциальность и безопасность

* Участники разработки обязаны соблюдать требования конфиденциальности в отношении деталей реализации, касающихся безопасности.
* Обсуждение уязвимостей и вопросов безопасности должно проводиться в установленном порядке.
* Запрещается внесение изменений, которые могут компрометировать безопасность системы или создавать векторы атак.

---

### Примечания

* Настоящий документ может быть дополнен в соответствии с требованиями проекта и стандартами безопасной разработки.
* Все участники разработки должны быть ознакомлены с требованиями данного документа перед началом работы над проектом.