diff --git a/README.md b/README.md
index f31b2d9..f2e67bd 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,5 @@
 # data_engineer_fasrpost
 
 # Запуск
-```docker compose up -d```
\ No newline at end of file
+```cp .env.example .env```
+```docker compose up -d```
diff --git a/tasks/1.md b/tasks/1.md
deleted file mode 100644
index 162ea0b..0000000
--- a/tasks/1.md
+++ /dev/null
@@ -1,32 +0,0 @@
-1. Спроектировать схему БД 
-я здесь вижу 2 варианта развития
-1) сделать одну таблицу в которой будет:
-    - id пользователя
-    - время выполненного дйствия
-    - enum из различный действия (бэку не нужно лишний раз искать id действия, чтобы закрепить его в таблице логов)
-    - (отдельная таблица для действий будет лишней)
-    - (бэку необходимо знать и контролировать все действия, а таблица будет лишь означать изменение данных извне, которое будет либо бесполезной, либо опасной, когда бэк не найдёт нужное действие)
-2) разбить на несколько таблиц:
-    - таблица логов аккаунта
-    - таблица работы с темой
-    - таблица работы с сообщениями
-
-- 1 вариант - 
-    1) ускоренная разработка из-за отсутсвия необходимости задумываться над подтягиванием данных из других таблиц (join, lazy_loading, selectin)
-    2) простота работы с данными: SQL запросы намного проще, более удобный перенос в csv
-- 2 вариант -
-    1) БД более подготовлена к изменению или усложенению архитектуры
-    2) повышение эффективности за счёт меньшего количества столбцов
-
-в ТЗ не было речи про дальнейшую судьбу этой БД, так что я пойду на 1 вариант
-
-```
-CREATE TABLE public.log (
-    id integer NOT NULL,
-    user_id integer NOT NULL,
-    datetime timestamp with time zone NOT NULL,
-    action public.useractions NOT NULL,
-    object_id integer,
-    response smallint NOT NULL
-);
-```
\ No newline at end of file
diff --git a/tasks/2.md b/tasks/2.md
deleted file mode 100644
index e69de29..0000000