Decadal

Сделайте ветку dev
пусть облако веток задач будет вокруг дева: каждая ветка тестируется по отдельности, а после тестируется их совместимость между собой (я так понял, это и есть причина, по которой нельзя тестировать ветку без подтягивания изменений из мастера).
После фидбека QA по dev-ветке сливать dev в мастер.
А еще лучше сделать dev->stage->master.
На деве тестить слитые ветки, на stage - целые релизы.

в классе миграции:
$this->execute('CREATE SEQUENCE ....');

Просто SQL командой ?

да, а почему бы и нет? Это особенность pg. Вы ж не будете их делать например в mysql - значит, и разработчикам yii незачем делать из них метод класса Migration

array_merge

Пользуйтесь документацией, там действительно много чего есть.

foreach ($menu as $key => $menuItem)
в этом месте ваша ссылка теряется.
$menuItem здесь временная переменная, изменение которой ничего не даст.
попробуйте &$menuItem написать прямо в цикле

Faker

Давайте начнем с того, что база данных это не про ООП. База данных это то, что выросло из примитивных файликов на жёстком диске, куда выплёвывается всякая разная информация, родившаяся во время работы с программой.
БД ставит себе цель работать очень быстро с гигантскими объемами данных. БД имеет свою фишечку по красоте собственного устройства, называется нормализацией.
Если вы будете пришивать ко всему, что увидите, ООП, очень скоро заметите что время разработки просто упрется в бесконечность.

А теперь касательно вашего примера: у вас есть класс который называется юзер. В него попадают данные после запроса всех юзеров - и он с ними работает. А потом в него попадают данные после запроса юзеров, поставивших лайки - он работает и с ними.
Все. Это потолок, шедевр, ООП тут сделало свою работу. Можете кодить спокойно дальше.
Пока не узнали что модель юзера может меняться в зависимости от ситуации, и где-то вам понадобится модель юзера с моделью аватарки внутри, а где-то - с моделью аватарки и ещё и моделью токена...
Пока что все хорошо.

Да, вполне используют, и она развивается. Уже был дан релиз и выпущена версия 1.0.

По своим ощущениям: в сравнении с express писать кода было на порядок меньше, но очень подвела местная ORM Waterline. Отказывайтесь от нее, устанавливайте sails-migrations (если с реляционными БД работаете) и... разрабатывайте. Довольно приятная штука.

В форме регистрации во fronted в поле 'email' уже сохранено имя: 'admin' и под ним ' 'Email is not a valid email address'.

это довольно логично работает. Разве что сохранилось поле с логином не туда, но это вроде вопрос к Chrome.

Если пробовать зарегистрировать какой-нибудь email, то все равно выдаёт такую ошибку.

но... на вашем скрине как раз успешная регистрация?

и теперь даже выйти нельзя.

у вас только выйти и нельзя.
Измените в контроллере, в правилах доступа

[
                        'actions' => ['logout'],
                        'allow' => true,
                        'roles' => ['?'], // вот тут должно быть ['@']
                    ],

Ограничивайте его на стороне приложения, это логика приложения. База хранит данные и их связи между собой, но не производит валидации их типов.
Ну, если очень надо, просто задайте тип enum и перечислите там все возможные варианты
Есть ещё один вариант:

CREATE TRIGGER trigger_name BEFORE INSERT ON table
FOR EACH ROW
BEGIN
    IF New.activity>8 THEN
    SIGNAL SQLSTATE '10000'
        SET MESSAGE_TEXT = 'check constraint on table failed during insert';
    END IF;
END;

CREATE TRIGGER trigger_upd_name BEFORE UPDATE ON table
FOR EACH ROW
BEGIN
    IF New.activity>8 THEN
    SIGNAL SQLSTATE '10000'
        SET MESSAGE_TEXT = 'check constraint on table failed during update';
    END IF;
END;

strip_tags