# Перечень материалов для технического аудита

По ТЗ на полный технический аудит ПО. Минимально достаточный и расширенный набор без лишнего.

---

## 1. Минимально необходимый набор (без него аудит поверхностный)

### 1.1 Исходный код

- Репозиторий(и): GitHub / GitLab / Bitbucket / self-hosted
- Актуальная основная ветка
- История коммитов (не squashed snapshot)

👉 Нужно для: архитектуры, качества кода, техдолга, рисков поддержки

---

### 1.2 Описание продукта (коротко)

1–2 страницы или устно:

- назначение системы
- ключевые сценарии
- критичность для бизнеса
- предполагаемые нагрузки
- **кто основной пользователь** (роль, не persona)
- **что считается критическим отказом**

👉 Нужно для: корректной бизнес-интерпретации рисков и классификации Critical / High

---

### 1.3 Стек и окружение

- Языки, фреймворки
- БД, брокеры, кеши
- Среды: prod / stage / dev
- Где и как хостится

👉 Нужно для: оценки масштабируемости и эксплуатационных рисков

---

### 1.4 Процессы сборки и деплоя

- CI/CD (скрипты, YAML)
- Как выпускаются релизы
- Как откатываются

👉 Нужно для: оценки операционных рисков

---

## 2. Очень желательно (резко повышает ценность аудита)

### 2.1 Архитектурные материалы

- Диаграммы (если есть)
- ADR (Architecture Decision Records)
- Объяснение «почему сделано так»

👉 Позволяет отличить **осознанное решение** от **техдолга**

---

### 2.2 Документация

- README
- инструкции запуска
- API-контракты
- онбординг для разработчиков

👉 Нужно для оценки bus-factor и рисков передачи проекта

---

### 2.3 Тесты

- Наличие / типы
- Отчёты о покрытии (если есть)

---

### 2.4 Зависимости и лицензии

- lock-файлы
- private / forked зависимости

👉 Нужно для юридических и эксплуатационных рисков

---

## 3. По безопасности (если допустимо)

⚠️ **Без доступа к прод-секретам**

**Ограничение:** Аудит безопасности проводится на уровне дизайна и кода, без penetration testing и активных атак. (Защищает от завышенных ожиданий.)

- способ хранения секретов
- auth / roles / permissions
- работа с персональными данными
- результаты прошлых security-аудитов (если были)

---

## 4. Эксплуатация и реальность

### 4.1 Инциденты

- известные падения
- «больные места»
- что боитесь трогать

👉 Очень ценно: показывает реальные риски, а не теоретические

---

### 4.2 Метрики (если есть)

- latency
- error rate
- нагрузка
- cost drivers

### 4.3 Ручные операционные процедуры

- наличие runbooks, чек-листов, ручных шагов (если есть)
- ответ «нет» — тоже полезный сигнал

---

## 5. Границы аудита (обязательно зафиксировать заранее)

Нужно **явно**:

- что **не проверять**
- на чём **не фокусироваться**
- критические зоны (если есть)

Это защищает обе стороны.

---

## 6. Что НЕ нужно

- ❌ доступ к продакшену
- ❌ права на изменение кода
- ❌ идеальная документация
- ❌ «всё переписать» как цель

---

## 7. Итог

> Для оценки программы нужен доступ к коду, понимание назначения продукта, стека и процессов доставки, плюс любые материалы, которые объясняют **почему система устроена именно так**. Всё остальное — усиливает точность, но не является обязательным.

---

## 8. Следующие шаги

- [ ] Составить чеклист передачи материалов аудитору
- [ ] Оценить объём и сроки аудита по продукту
- [ ] Сформулировать NDA / scope для внешнего исполнителя

**Вопрос:** Аудит предполагается **внутренний** или **внешний**?

---

## Приложение: готовность papa-yu

| Материал | Статус | Где |
|----------|--------|-----|
| Репозиторий | ✅ | Локально / при публикации |
| Основная ветка + история | ✅ | `main` |
| Описание продукта | ✅ | `README.md`, `docs/` |
| Стек | ✅ | `package.json`, `Cargo.toml`, `tauri.conf.json` |
| CI/CD | ✅ | `.github/workflows/` |
| Документация | ✅ | `docs/`, `IMPLEMENTATION_STATUS_ABC.md` |
| Тесты | ✅ | `cargo test`, golden traces |
| Зависимости | ✅ | `Cargo.lock`, `package-lock.json` |
| Безопасность (без секретов) | ⚠️ | `docs/` — частично, SSRF/fetch |
| Инциденты / метрики | ❌ | Отсутствуют формализованно, известны на уровне команды |