Руководство по смарт-контрактам с деплоем, API и FAQ

Подготовь Markdown-документ формата docs/IMPLEMENTATION.md по набору смарт-контрактов [НАЗВАНИЕ_КОМПАНИИ].

Вход:
- [НАЗВАНИЕ_КОМПАНИИ]
- [SMART_CONTRACT_CODEBASE]
- [EXISTING_DOCUMENTATION]
- [DEVELOPER_FEEDBACK]
- [UTILITY_ТОКЕНА]
- [ЦЕЛЕВОЕ_СООБЩЕСТВО_РАЗРАБОТЧИКОВ]

Ничего не меняй в коде. Нужно только описание, инструкции и ссылки на файлы. Любые предположения о бизнес-логике помечай словом «предположение». Если [DEVELOPER_FEEDBACK] пуст, FAQ построй на типичных вопросах для обнаруженной платформы.

Структура документа должна строго идти в таком порядке:
1. Title:
   - [НАЗВАНИЕ_КОМПАНИИ] и имя набора контрактов.
2. Одностраничное резюме:
   - 3–5 ключевых возможностей.
3. Быстрая проверка окружения:
   - автоматически определи платформу, язык, минимальные версии компилятора, SDK и CLI;
   - перечисли сторонние библиотеки с версиями;
   - добавь команды сборки и предположенную среду, например Unix shell и версию Node.js.
4. Components & API Reference:
   - 3–5 главных модулей или контрактов;
   - для каждого: путь к файлу, назначение, ключевые public/external функции, события, важные переменные и поведение;
   - интегрируй релевантные фрагменты из [EXISTING_DOCUMENTATION] и явно пометь, что взято оттуда.
5. Deployment & Integration Guide:
   - prerequisites, env vars, ключи, ноды, версии;
   - пошаговые команды для локальной среды, сборки, тестов, деплоя и проверки деплоя;
   - примеры вызовов через CLI, ethers.js, web3, forge или аналогичные инструменты;
   - параметры конструктора, миграции и газ-оценки либо способ их оценки.
6. Use Cases:
   - 3–5 подробных сценариев;
   - для каждого: цель, шаги с командами, ожидаемые события, транзакции и изменения состояния.
7. Testing & CI:
   - как запускать существующие тесты;
   - какие минимальные тесты и интеграции стоит добавить.
8. Security Considerations:
   - основные риски, известные уязвимости, права доступа, апгрейды, аудит и ограничения.
9. FAQ:
   - минимум 6 Q&A при наличии входных вопросов, иначе минимум 3.
10. Weakest Assumption + How to Verify:
   - одно самое слабое предположение;
   - пошаговая проверка командами, тестами и условиями.
11. Common Omission:
   - одно частое упущение в документации смарт-контрактов;
   - конкретная рекомендация, как его исправить здесь.
12. Referenced Files:
   - список файлов и путей в формате path -> краткое описание.

Ограничения:
- Пиши технически, кратко и по-русски.
- Используй Markdown-заголовки, списки и блоки кода только там, где это повышает ясность.
- Не задавай уточняющих вопросов и не добавляй новые функции в систему.