У нас уже стоит задача превратить все [tndt-34] в tndt-34, делать из этого одноразовую команду и при выкатке помнить какую запускать очень такое себе. Логично чтобы эта и подобные задачи решались в post_deploy цели, как сейчас накатываются миграции. Это фактически как миграции, но работают не с чистым SQL, а с доменной областью через сервисы (поэтому должны писаться более осторожно с пониманием, что эти сервисы могут и исчезнуть). А значит это должна быть параллельная миграциям система.

На текущей момент нужно реализовать две такие миграции:

• замена ссылок, которые мы сейчас от балды оформляем на рабочие (когда они будут работать)
• простановка всем задачам справочников. Не всех конечно, а тех, у которых есть явное дефолтное значение, например тип можно не проставлять, а вот этап должен быть проставлен в соответствие с закрытостью задачи)
• в будущем будут миграции уже заполненных справочников в новые структуры.

Вобще сначала в системе появляется справочник, потом пм ручками его настраивает, а потом запускать команду, это уже не post_deploy, так что может эту задачу так не решить