Денис Пабло

Ход мыслей такой:
https://www.google.com/search?q=радиус+эллипса
https://ru.onlinemschool.com/math/formula/ellipse/
Радиус эллипсa R - отрезок, соединяющий центр эллипсa О с точкой на эллипсе.
R = a*b / sqrt((a*sin(φ))^2+(b*cos(φ))^2)
где φ - угол между радиусом и большой осью
a - большая полуось эллипса
b - малая полуось эллипса

В вашем случае φ легко найти через арктангенс, полуоси известны заранее.
Зная центр эллипса, φ и R, легко найдём координаты точки пересечения эллипса с радиусом.
Стоп, но нам нужна не эта точка, потому что окружность имеет ненулевой радиус r. Не будем решать задачу математически точно, обойдёмся грубум приближением. Для этого возьмём R1=R-r. И посчитаем координаты центра окружности на основании R1, φ и центра эллипса. Это будет сносно работать, если эллипс не слишком вытянутый, а окружность не слишком большая.

Можно. Для этого достаточно проксировать запрос через свой сервер, который добавит нужные заголовки и удалит не нужные. Также можно написать браузерное расширение, фоновый процесс расширений может делать запросы игнорируя CORS.

1) в репозитории у Вас получился скорее скелетон, а не пакет фреймворка, у папки шаблонов должно быть осознанное предназначение, нп. приветствующая страница, папка public тоже обычно отсутствует
2) именование интерфейсов как iSomething морально устарело и неправильно по PSR (для классов тоже, там был класс reCaptcha)
3) тесты должны отражать тесты на функционал фреймворка, пока там заглушки
4) непонятен слой Promises, под ним там видно много классов, которые отвечают за разные вещи, стоило бы их структурировать, приставка extreme тоже не отражает предназначение классов
5) странно видеть в core класс рекапчи, это типично клиентская задача и фреймворк не должен ее решать
6) сейчас есть тенденция подключать сторонние orm во фреймворк, потому что проектирование абстракций для базы с нуля это огромная работа

Вообще это очень обширная тема, в которую стоит погрузиться. Прежде всего нужно понимать, что помимо Unit тестов есть ещё и другие тесты.

Unit тесты нужны для тестирования кода-бизнес логики. Они выполняются быстро, не лезут в базу и в целом гарантируют вам что бизнес логика соответствует вашим требованиям, что методы класса возвращают то, что от них ждут.

В целом - это позволяет вам гарантировать, что ваш код работает ожидаемо, даже когда вы внедрили новую фичу. Всё работает без ошибок. Если вы не используете тесты - вам придётся надеются на Бога или проверять все самому)))

Использование тестов оправдывается на большом и долгосрочном проекте, а так как большинство проектов растут, то желательно Unit тесты писать всегда. Даже когда лень) Это вам поможет в будущем. По тестам можно понять как всё работает.

Так же тесты можно запускать командой, но можно и настроить автоматический деплой на сервер (CI CD). Например, вы запаливаете новую фичу пушите её на гитхаб. Там запускается сборка и тестирование. Если тестирование прошло автоматически - то ваш проект (с новой фичей) выкладывается на продакшн. А если есть ошибка - все прерывается.

Как и сказал выше - это обширная тема, в которую стоит погрузиться!)

Вот пример тестов одного из модуля. Можете посмотреть.

Подозреваю, что ошибка где-то здесь

$CorePromise->setConfig(new Configuration());

$this->promise = new ExtremeCorePromise($CorePromise);
if ($this->promise->getConfig()->getPromise()->getDatabases()->getMySQL()->getEnabled()) {
    $this->DB = new DB(new MySQL($this));
}

Так как вы в качестве конфига передаёте новый экземпляр класса без самих данных. Трудно понять, что у вас не так. Я вижу, что для работы с БД вы используете свои классы. Как всё это реализовано останься только догадываться.

Так же, возможно, что-то не так в фильтрации условия и работы метода:
$Core->getDB()->getRow("...");