7.4 KiB
Принципы изменения и проверки системы
Ожидаемый результат определяется задачей пользователя. Сопровождение сохраняет ответственность подсистем, безопасность, точность данных и проверяемость результата. OpenSpec остаётся необязательным средством согласования; исторические свидетельства не становятся обязательной процедурой новой задачи.
Выбор реализации
Связное поведение принадлежит ответственной подсистеме. Существующая возможность используется повторно, если сохраняет нужный смысл и инварианты. Новая граница оправдана самостоятельной ответственностью, общей потребностью нескольких потребителей либо необходимостью отделить доступ и целостность данных.
Простота оценивается по ясности всей системы и стоимости сопровождения, а не по размеру изменения. Предполагаемая будущая возможность сама по себе не оправдывает новую подсистему. Упрощение сохраняет валидацию, доступность, обработку ошибок и защиту от потери данных.
Dependencies
При выборе внешней зависимости учитываются текущая потребность, совместимость, поддержка, безопасность и стоимость сопровождения. Использование принятой платформы может быть проще собственной реализации; зависимость ради одной воображаемой будущей возможности не является самостоятельной потребностью. Новый сервис или общая инфраструктура должны решать актуальную задачу.
Risk-based testing
Изменения безопасности и приватности, денежных расчётов, целостности данных, миграций, конкурентного доступа, публичного контракта, критического сценария и подтверждённой регрессии требуют автоматической проверки соответствующего риска на наблюдаемой потребителем границе.
Статические проверки не доказывают финансовую или функциональную корректность. Покрытие frontend служит ограничителем регрессий; для backend общего числового порога нет. Проверки поведения библиотеки или проценты сами по себе не заменяют проверку собственного инварианта системы.
Проверка результата
Результат оценивается по исходной задаче: сохранены ли смысл данных и контракты, правильно ли разграничен доступ, учтены ли ошибки и доступность интерфейса. При изменении HTTP-контракта backend обновляет публичный OpenAPI, а frontend проверяет соответствие generated types полученному snapshot согласно OpenAPI contract flow. Общего CI сейчас нет.
Успешная проверка применима к тому состоянию системы и тем предпосылкам, на которых выполнена. При их изменении старое свидетельство не доказывает новый результат. Автоматическое исправление материалов и проверка без их изменения — разные действия.
Влияние на документацию входит в оценку результата: описанные понятия, сценарии, решения и ограничения обновляются вместе с системой. Отсутствие влияния может быть обоснованным результатом. Отчёт о поставке различает выполненное, проверенное и остающиеся ограничения; количество формальных отметок не заменяет смысловую проверку.
Guardrails и local gates
Автоматические проверки гарантируют только свойства, охваченные их областью. Смысловые требования — например, правильный владелец данных, авторизация, локализация и полезность выбранных проверок — требуют отдельной оценки. Предпочтение между равноценными вариантами отличается от обязательного инварианта. Новая автоматизация оправдана реальным риском или повторяющимся дефектом; её наличие само по себе не является целью.
UI-решения
Ожидаемые экраны, состояния, взаимодействия и поведение на разных размерах экрана определяются пользовательским сценарием. Каталог и дизайн-система показывают существующую визуальную основу. Неоднозначный вариант можно оценить по конкретному примеру до реализации. Успешная сборка каталога не доказывает доступность и визуальное соответствие.
Изменение опасного контракта
Для публичного контракта, безопасности, данных, платежей и труднообратимого изменения существенная неопределённость разрешается до применения решения. Для миграции важны условия отката, сохранность уже созданных данных и проверка восстановления. Порядок разрешения конфликтов знаний описан в контексте системы.