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

Не хочется вдаваться в дискуссию. По-дефотлу вы правы. Но на практике можно выстроить структуру, в которой прегенерируемый код не будет ломать сервисы. Потому что, по сути, будут генерироваться только интерфейсы с объектами передачи данных, а изменения в них так или иначе всегда приводят к изменениям в коде, а иногда и к редизайну.

Но такой подход сложный, для его реализации нужны соотв навыки и воля.

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

не выпускать релиз в ПРОМ)

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

Поэтому архитектор софтовый должен быть в команде(-ах), а не «проявлять власть сверху»

вопрос не во власти, а в соблюдении стандартов, подготовки артефактов. Если не заполняют - значит не нужен, и ни на что не влияет.

Либо влияет на то, что не влияет на жизнь человека, от которого требуют заполнения :)

Поэтому архитектор софтовый должен быть в команде(-ах), а не «проявлять власть сверху»

Согласен. И такой архитектор должен транслировать в команды необходимость стандартов, практик и всего остального.

Поэтому архитектор софтовый должен быть в команде(-ах), а не «проявлять власть сверху»

Вот софтовый архитектор и должен отвечать за дизайн своих сервисов и за документирование.

Но должна быть возможность "посмотреть сверху" в целях аудита, ну и плюс онбординг

ключевое, значит нужно сделать так чтобы влияло на результат его работы)

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

Кстати, паяльник в итоге вставляют архитектору обычно, потому мы помним про "не_мешайте_просто_херачить" на всех уровнях

Проджекту же