feat: implement legacy shop management system and add task documentation files

Final control/11/TASK.md

@@ -0,0 +1,78 @@
+### Задача 11. Рефакторинг системы управления интернет-магазином
+
+**Контекст**
+
+Вам достался legacy-код системы управления интернет-магазином, расположенный в файле `legacy_shop.py`. 
+
+Код является абсолютно **монолитным**: вся логика (регистрация пользователей, авторизация, корзина, оформление заказов, расчёт доставки для разных городов, применение промокодов и админ-отчёты) написана сплошным линейным потоком внутри интерактивного CLI-интерфейса. В программе **нет ни одной функции и ни одного класса**. При этом код содержит огромное количество дублирования логики (copy-paste), нарушает стандарты PEP 8, не имеет обработки ошибок и сложен в поддержке.
+
+---
+
+**Ваша задача:**
+
+Провести полный рефакторинг этого кода, разделив его на модули, применив объектно-ориентированное программирование (ООП) и исправив стиль кодирования.
+
+#### Шаг 1. Анализ и исправление стиля (PEP 8)
+- Приведите весь код в соответствие со стандартами **PEP 8**:
+  - Устраните отсутствие пробелов вокруг операторов (например, `x=y+z`).
+  - Исправьте именование переменных на `snake_case`.
+  - Уберите «волшебные числа» и жестко захардкоженные пароли (например, пароль админа), вынеся их в константы или конфигурацию.
+
+#### Шаг 2. Декомпозиция логики в функции
+- Найдите все повторяющиеся и логически обособленные куски кода и вынесите их в отдельные переиспользуемые функции с понятными названиями.
+- **Особое внимание уделите:**
+  - Валидации полей при регистрации пользователя (сейчас проверки скопированы для каждого поля отдельно).
+  - Расчету стоимости доставки (уберите дублирование формул для 10+ городов, обобщите логику).
+  - Применению промокодов (уберите длинный `if-elif` блок, заменив его на структуру данных/словарь соответствий или единую формулу).
+  - Валидации чисел при вводе количества товаров и цен.
+
+#### Шаг 3. Проектирование ООП-архитектуры
+#### Шаг 3. Проектирование ООП-архитектуры
+- Вместо хранения сырых словарей (`dict`) и глобальных переменных спроектируйте систему классов. **Создавайте классы там, где они действительно выгодны** (например, там, где необходимо инкапсулировать состояние, защитить данные от некорректного изменения или связать данные с поведением). Подумайте, для каких сущностей достаточно простых структур данных/функций, а для каких необходимы полноценные классы:
+  - `Product` — модель товара (id, название, категория, цена, остаток на складе, sku, производитель).
+  - `User` — модель пользователя. Подумайте над наследованием: например, выделите базовый класс `User` и наследников `Customer` (клиент) и `Admin` (администратор) с разным уровнем прав, если это упростит разграничение доступа.
+  - `Cart` — корзина покупателя, управляющая добавлением товаров, изменением количества и подсчетом промежуточного итога (здесь класс выгоден для управления состоянием).
+  - `Order` — заказ пользователя (детали доставки, примененная скидка, стоимость доставки, итоговая сумма, статус).
+  - `Database` — сервис для работы с файлами базы данных (`users.json`, `products.json`, `orders.json`). Должен инкапсулировать логику чтения и записи.
+  - `Shop` — центральный сервис-фасад, координирующий бизнес-логику магазина.
+
+#### Шаг 4. Создание модульной файловой структуры
+Разделите проект на логические части и файлы. Итоговая структура должна выглядеть следующим образом:
+```
+shop/
+├── __init__.py
+├── models/
+│   ├── __init__.py
+│   ├── product.py
+│   ├── user.py
+│   ├── order.py
+│   └── cart.py
+├── services/
+│   ├── __init__.py
+│   ├── shop.py
+│   └── database.py
+├── utils/
+│   ├── __init__.py
+│   └── validators.py
+└── main.py
+```
+- В `main.py` должен остаться только запуск приложения и минималистичный интерактивный CLI-интерфейс, вызывающий методы класса `Shop`.
+
+#### Шаг 5. Качество кода и надежность
+- Добавьте осмысленные docstring'и ко всем классам, методам и модулям.
+- Используйте аннотации типов (type hints) для аргументов функций и возвращаемых значений.
+- Добавьте обработку исключений (`try-except`) в места взаимодействия с файловой системой (загрузка/сохранение БД) и при вводе некорректных данных пользователем.
+- **Проверка стиля кода**: Для проверки соответствия стандартам стиля запустите линтер `flake8` в корне проекта:
+  ```bash
+  flake8 shop/
+  ```
+
+---
+
+**Критерии оценки:**
+
+1. **Работоспособность**: после рефакторинга весь функционал приложения (от регистрации до админских отчетов) должен работать точно так же, как в исходном файле.
+2. **Чистота кода**: отсутствие дублирования логики (DRY), понятные имена переменных и методов. **Команда `flake8 shop/` не должна выводить никаких предупреждений или ошибок.**
+3. **Качество ООП**: грамотное распределение ответственности между классами, использование инкапсуляции (скрытие внутренних данных), осмысленное применение ООП.
+4. **Модульность**: логичное разделение кода по файлам в папке `shop/`.
+