VoidVolker

Документация по самому проекту и его архитектуре в частности. Заказчик ставит задачу, на основе этой задачи разрабатывается ТЗ, а на основе ТЗ - частное ТЗ со всеми деталями проекта, в том числе и архитектурой. Вот вам несколько примеров:
Вот ещё один отличный пример: описание структуры JSON - https://www.json.org/json-ru.html

Тут все ответы одновременно верные, не верные и противоречащие самой задаче.

1. "Ничего не изменилось" противоречит концепции самой задачи: по условиям задачи уже что-то изменилось. Ничего не изменилось в дизайне странице. Изменился объём страницы и увеличилось потребление трафика, а так же объём вычислительных ресурсов необходимых для обработки данной страницы.
   
2. Расходы снизились, т.к. после пересборки и деплоя проекта запустился механизм очистки кэша предыдущей версии проекта и которая занимала больший объём, чем текущая. Расходы увеличились, потому что объём проекта увеличился.
   
3. Скорость - аналогично: проект пересобрался чуток по-другому из-за других хэшей в названиях файлов, которые архиватор пережал чуть более эффективно. Или сжатие страниц не использовалась и скорость отображения страниц замедлилась.
   
4. Износ НЖМД относится к пункту 2, т.к. это часть расходов на обслуживание сервера.
   
5. Электропитание - то же самое: больше байт для обработки - больше затраты на электричество, архиватор сжал эффективнее - меньше байт, меньше затраты.
   
6. Так же и с уязвимостью: дополнительные 43 байта привели к возможности использовать атаку при переполнении буфера в такой странице памяти (ну, условно, конечно). Или наоборот избавили.
   
7. По любому пункту выше (и даже ниже) можно получить как взыскание, так и премию.
   
8. То же самое с выбросами: пользователи получили замедление страницы и со злости очень активно и экспрессивно высказались в адрес владельцев и разработчиков сайта, что привело к более активному дыханию и дополнительным выбросам. Ну или наоборот - пользователи уснули в ожидании загрузки страницы и меньше надышали.
   

Даже формулировка вопроса включает в себя вообще все ответы: к чему могло привести? Это событие могло привести вообще абсолютно к чему угодно - хоть к коллапсу и взрыву сверхновой звезды на другом конце вселенной через миллиард или триллион лет. Так что если отвечать именно на этот вопрос, то да, все ответы верные.

Как именно вы проверяли вес файлов и чем и как сравнивали их содержимое? Есть два варианта: возможно вы спутали размер файла и место занимаемое на диске, показываемые в свойствах файла - это разные вещи. На диске файл занимает больше место, т.к. под файл выделяется место кластерами, а размер кластера фиксирован для раздела и может быть разным, и соответственно в разных ОС и в разных ФС он может быть разным. Второй вариант - разные переводы строк в разных ОС. Гит умеет подменять и в разных ОС размер и хэш файлов будет отличаться из-за разных принятых переводов строк в ОС или настроек гита.

Искать, читать, анализировать, исследовать, делать выводы. Какие тут еще могут быть варианты-то? Ну, кроме варианта напрячь кого-то, а самому пойти пить чай/кофе с пончиками. Логика плюс научный метод в помощь.
В целом же, касательно задачи именно декомпозиции есть следующие основные подходы: сверху вниз, снизу вверх и совмещённый - часть делается сверху, часть снизу. Берёте листочек бумаги и рисуете на нём все элементы вашей задачи и вообще всё, что по ней известно. Ваша задача - это ведь не просто одно слово какое-то или фраза какая-то, а что-то типа "если на входе А - то на выходе Б, если В - то Г". Далее рисуете связи между ними - что, к чему, куда и как. Вот вам и готов первый уровень декомпозиции. Если что-то неизвестно или висит в воздухе - ничего страшного, значит надо просто изучить вопрос глубже, собрать дополнительные данные и прочее. И далее повторяете в таком же духе. Берёте один элемент и делите его на составляющие таким же способом.
Еще один тоже достаточно неплохой подход: слева рисуете исходные данные - то, что у вас есть, а справа результат - то, что должно получиться в итоге. Вот где-то между ними и есть решение. Рисуем стрелочку слева направо и думаем - что это за стрелочка? Как она работает? Что она делает такого, чтобы получился нужный результат? В центре рисуем известные части/элементы сей головоломки и потихоньку создаём между ними связи в процессе размышлений и исследований.
Реальные примеры декомпозиции:

Ну, самый простой ЯП - это Форт. Проще уже некуда: просто слова разделённые пробелами. Известный мне рекорд минимальной реализации: 254 занятых байта из 256 байт оперативной памяти в каком-то МК и целых два свободных байта для использования. И SciTE-Ru в качестве IDE - он очень гибкий, плагины, множество поддерживаемых ЯП, огромная куча настроек, автоматизация и прочее. В общем, почти как VSCode - только шустрый нативный интерфейс без браузерных движков и жаваскрипта.
А если что-то более сложное - то C# и .Net 4.7.

Добро пожаловать в реальный мир вычислений чисел с плавающей запятой с погрешностью! Если вам нужны точные вычисления - используйте тип decimal или аналогичный для вашего ЯП.
https://habr.com/ru/articles/266023/
https://learn.microsoft.com/ru-ru/office/troublesh...
https://0.30000000000000004.com/

Вам следует описать конкретно, что именно у вас не получается. В целом ваша задача состоит из следующих подзадач:

1. Арендовать сервер
   
2. Арендовать домен
   
3. Подключить сервер к домену
   
4. Сделать дополнительные настройки на сервере в соответствии с требованиями вашего приложения
   
5. Разместить приложение на сервере
   
6. Запустить приложение
   

Дык VLC же есть, прям первая ссылка в гугле на биндинг: https://github.com/videolan/libvlcsharp
Да даже если не можете найти конкретно либу или вот VLC биндинг завести, то что мешает тупо в командной строке запускать любой бесплатный плеер для воспроизведения/записи?

Просто отформатируйте код в нормальный вид - это не просто так придумали, а для удобства. Кроме того, вам IDE даже точное место ошибки показывает - выделяет красным и подчеркивает. Что именно тут непонятного?

Как построенн язык программирования, например: Как понять, как устроенны ключевые слова; Препроцессорные процессы: define, include и др.; - Я правильно понимаю, нужно опустится на ещё более низкий уровень до ассемблера? - Ассемлер является той фундаментальной сущностью в программировании (не считая машинный код, который и так человек не должен понимать)?

Абсолютное большинство ЯП имеют во-первых - стандарт, где описывается вся его логика, а во-вторых открытый исходный код(либо имеется открытая реализация) и где можно изучить все детали реализации.

Возможно достичь понимания работы программ не физически, а программно. (Я не знаю как это точно сказать.) То есть не как в комп’ютере выполняется программа, а как работает отдельная сущность - программа? - И вообще это возможно, либо я просто многое чего хочу от жизни?

Любая программа - это просто алгоритм. Так что смотрим что делает программа и спокойно разбираем её алгоритм. А если есть исходный код - то вообще все полностью можно разобрать.

Ну и вообщем, какие-то фундаментальные знания - на чём базуется/построенна програмированние и IT, тоже не помешало. Например рекомендуют SICP почитать, правильно ли я тогда пойду или это не то. Если да, можете ещё набросать ваши варианты? Буду признателен.

Фундамент - бинарная логика. Над ней - процессорные инструкции или машинный код. Далее - ассемблер, минимально простая абстракция для составления инструкций для процессора. Следующий этаж - язык программирования высокого уровня, который в своем составе имеет какой-то типовой набор абстракций (переменные, функции, операции с памятью, блоки и разные типы данных), функций и алгоритмов для более человечного описания алгоритмов и для работы с данными. ЯП бывают разные и решают проблему в какой-то определенной области или для какой-то цели. Также существуют предметно/проблемно-ориентированные ЯП (DSL - domain-specific language) - более узкие решения. Дальше - стандартные и дополнительные библиотеки для упрощения работы с определенными данными, алгоритмами и прочее. Выше лежат фреймворки реализующие какой-то определенный каркас/функционал для реализации программ/алгоритмов для решения задач в рамках какой-то специфической области.