docs: добавлен текст документов для контрибьюетеров и плана развития

docs/CONTRIBUTORS.md

@@ -0,0 +1,110 @@
+# Участники разработки
+
+## Правовые аспекты и требования к контрибуторам
+
+Настоящий документ устанавливает требования и процедуры для участников разработки программного изделия (ПИ) «Ъ» (компонент «Токенизатор») в рамках Проекта «Твердь».
+
+---
+
+### 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. Конфиденциальность и безопасность
+
+* Участники разработки обязаны соблюдать требования конфиденциальности в отношении деталей реализации, касающихся безопасности.
+* Обсуждение уязвимостей и вопросов безопасности должно проводиться в установленном порядке.
+* Запрещается внесение изменений, которые могут компрометировать безопасность системы или создавать векторы атак.
+
+---
+
+### Примечания
+
+* Настоящий документ может быть дополнен в соответствии с требованиями проекта и стандартами безопасной разработки.
+* Все участники разработки должны быть ознакомлены с требованиями данного документа перед началом работы над проектом.
+