Скорее на скрипты развёртывания, но они в Гите

Но явки нужны, да

Тут можно похоливарить, что не обязательно восстановить получится однозначно (единственно верным способом). Это как динозавра из найденных костей собирать )

Но на практике да, просто долго

Ну, тут надо делать линтер на swagger. И ревью )

Да) но можно собрать или понять, что нельзя, потому что нет костей никаких

@GKruglov Если я правильно понял твою задумку, из своего болезненного опыта я бы дополнил:
-- контакты ключевых персон (архитектор, тим лид), особенно если несколько поколений менялось
-- ссылка на compliance, если применимо (а ещё мы не храним информацию о leaver'ах, потому что 152-ФЗ)
-- упоминания о сюрпризах (там есть самописная библиотека, автор в Канаде уже 5 лет, права не оформлены)
-- как выделили ресурс на проект (входит в бюджет проекта X, утвердили на комитете _ссылка)

Не уверен, что это все ещё про дизайн)).

Остальное из списка очень знакомо, плюсую.

Кто этот документ составляет, тот уже не разработчик, а де-факто архитектор сервиса. Вот только зарплату ему почему-то платят как разработчику. Потому и будут саботировать процесс, неявно понимая, что это не их работа такие концептуальные вещи писать.

А ещё иногда там встречаются такие перлы как «список используемых библиотек с указанием версий», и этот список ещё и на согласование отправляется. Ну а что, я однажды выгрузил архитекторам дамп из maven и node_modules (backend + frontend). Что они с этим списком сделали? Ничего хорошего. Включили в какой-то документ на согласование на уровне архитектуры сервиса, который по хорошему нужно было утверждать ещё до начала реализации.

Всем, кому такое нужно, успешно внедряют нормальные системы управления зависимостями (да, я теперь знаю и ненормальные), и отслеживают это все на уровне исходного кода. Аналогично для API видел попытки внедрить и репозитории. Тоже достаточно просто в 80% случаев: кто свой API там не опубликовал, того вызывать нельзя (физически). И далее уже вокруг этого и версионность появляется, и ACL, и оформление красивых документов / карточек сервисов.

Почему не разработчик, как раз разработчик, а не кодер.
Это все базовые требования к middle/senior developer, если он на эти вопросы не может ответить - то что он вообще в индустрии делает?

У разработчика есть зона ответственности. И надо определиться, где заканчивается то, за что он отвечает, и где начинается то, за что отвечает «архитектор». Если внутри продукта используется, например, MySQL, а не MariaDB, это чья зона ответственности? Кто отнимает решение?

Если разработчик — то зачем ему наверх отправлять то, что он имеет право поменять в любой момент?
Если «архитектор» — то зачем программисту об этом писать в бумагах, если не ему это решать?

А почему "зона ответственности" не предполагает "информирования"?

Ответить-то он может и может, но зачем ему этим заниматься? Что ему от этого будет, какая польза в его работе?

Разработчик создает API, но менять его уже не может )

потому что хочется увидеть список библиотек — вот ссылка на git. Читайте. Хочется увидеть архитектуру — а где же был архитектор, когда приглашали на встрече в начале проекта и обсуждали всё это? Когда приглашали на встречи и отделом администрирование/внедрения и рассказывали про это? Хочется увидеть назначение сервиса... ну тут могу лишь отзеркалить, а что архитектор делает на позиции, если не знает, что делает подчинённый ему сервис?

не, бывают переходные случаи, когда отдел архитектуры только-только появляется. Тогда всё это имеет смысл. Но если архитекторы уже 10 лет как есть, и начинают запрашивать такие данные у разработчиков — то что-то идёт не так и не туда.

Ну, вообще вроде бы речь идет не о "запрашивании", а о поддержке в актуальном состоянии.

А поддержка документов о сервисе в актуальном состоянии и должна быть работой архитектора. Это его задача давать отделам компании инструменты для взаимодействия сервисов между собой. Это его задача отражать на бумаге изменения снизу и транслировать вниз изменения сверху в виде ТЗ.

а если разработчик может выкатить новую версию сервиса, в которой меняет API, при этом умудрившись всё согласовать так, что никто не сломался, все постепенно переехали на новую версию, убрать старую версию, поменять принцип разделения данных в кластере, поменять РСУБД на кассандру и ничего не сломалось... значит для работы сервиса достаточно тех инструментов взаимодействия с ним, которые сейчас есть. И внедряя новый инструмент ("карточку сервиса"), нужно его внедрять не "сверху", затребуя у разработчика данные, а "снизу". Показывая, что заполняя эти данные на каком-нибудь централизованном сервисе разработчик облегчает себе жизнь через версионирование / упрощение согласования / централизованную knowledge base / API repo / etc.

* какой может быть плюс от централизованного управления зависимостями? релиз не зарубит ИБ на моменте аудита (найдя в коде third party includes)
* централизованное управление API? не нужно будет согласовывать "дырки" в firewall'е, можно отслеживать использование разных версий API.
* централизованное управление карточками сервисов? автоматическое управление развёртыванием, согласованиями новых ресурсов (серверов), совместных релизов.
* централизованное описание используемых систем в виде компонентной диаграммы? Ну, например, автоматическое управление лицензиями. Автоматическое управление сертификатами со стороны ИБ. Дырки, опять же, если их нужно сверлить между компонентами системы.
предложите такие инструменты разработчикам — и они сами побегут заполнять все необходимые данные и карточки.

Чувствуется персональная боль из прошлого

тяжкое наследие зелёного финтеха

Ну да. У меня как разработчики осознали, что нормальный дизайн решения и дизайн-ревью - экономят время, так начали делать сами и без понуканий.