83 lines
7.3 KiB
Markdown
83 lines
7.3 KiB
Markdown
# Принципы изменения и проверки системы
|
|
|
|
Ожидаемый результат определяется задачей пользователя. Сопровождение сохраняет
|
|
ответственность подсистем, безопасность, точность данных и проверяемость результата.
|
|
OpenSpec остаётся [необязательным средством согласования](openspec-authority-and-lifecycle.md);
|
|
исторические свидетельства не становятся обязательной процедурой новой задачи.
|
|
|
|
## Выбор реализации
|
|
|
|
Связное поведение принадлежит ответственной подсистеме. Существующая возможность
|
|
используется повторно, если сохраняет нужный смысл и инварианты. Новая граница
|
|
оправдана самостоятельной ответственностью, общей потребностью нескольких
|
|
потребителей либо необходимостью отделить доступ и целостность данных.
|
|
|
|
Простота оценивается по ясности всей системы и стоимости сопровождения,
|
|
а не по размеру изменения. Предполагаемая будущая возможность сама по себе
|
|
не оправдывает новую подсистему. Упрощение сохраняет валидацию, доступность,
|
|
обработку ошибок и защиту от потери данных.
|
|
|
|
## Dependencies
|
|
|
|
При выборе внешней зависимости учитываются текущая потребность, совместимость,
|
|
поддержка, безопасность и стоимость сопровождения. Использование принятой
|
|
платформы может быть проще собственной реализации; зависимость ради одной
|
|
воображаемой будущей возможности не является самостоятельной потребностью.
|
|
Новый сервис или общая инфраструктура должны решать актуальную задачу.
|
|
|
|
## Risk-based testing
|
|
|
|
Изменения безопасности и приватности, денежных расчётов, целостности данных,
|
|
миграций, конкурентного доступа, публичного контракта, критического сценария
|
|
и подтверждённой регрессии требуют автоматической проверки соответствующего
|
|
риска на наблюдаемой потребителем границе.
|
|
|
|
Статические проверки не доказывают финансовую или функциональную корректность.
|
|
Покрытие frontend служит ограничителем регрессий; для backend общего числового
|
|
порога нет. Проверки поведения библиотеки или проценты сами по себе не заменяют
|
|
проверку собственного инварианта системы.
|
|
|
|
## Проверка результата
|
|
|
|
Результат оценивается по исходной задаче: сохранены ли смысл данных и контракты,
|
|
правильно ли разграничен доступ, учтены ли ошибки и доступность интерфейса.
|
|
Проверки приложений и документации дополняются
|
|
[согласованием HTTP-контракта](runtime-openapi-verification.md), если он меняется.
|
|
Общего CI сейчас нет.
|
|
|
|
Успешная проверка применима к тому состоянию системы и тем предпосылкам,
|
|
на которых выполнена. При их изменении старое свидетельство не доказывает
|
|
новый результат. Автоматическое исправление материалов и проверка без их
|
|
изменения — разные действия.
|
|
|
|
[Влияние на документацию](documentation.md#обновление-вместе-с-кодом) входит
|
|
в оценку результата: описанные понятия, сценарии, решения и ограничения
|
|
обновляются вместе с системой. Отсутствие влияния может быть обоснованным
|
|
результатом. Отчёт о поставке различает выполненное, проверенное и остающиеся
|
|
ограничения; количество формальных отметок не заменяет смысловую проверку.
|
|
|
|
## Guardrails и local gates
|
|
|
|
Автоматические проверки гарантируют только свойства, охваченные их областью.
|
|
Смысловые требования — например, правильный владелец данных, авторизация,
|
|
локализация и полезность выбранных проверок — требуют отдельной оценки.
|
|
Предпочтение между равноценными вариантами отличается от обязательного
|
|
инварианта. Новая автоматизация оправдана реальным риском или повторяющимся
|
|
дефектом; её наличие само по себе не является целью.
|
|
|
|
## UI-решения
|
|
|
|
Ожидаемые экраны, состояния, взаимодействия и поведение на разных размерах
|
|
экрана определяются пользовательским сценарием. [Каталог](ui-catalog.md)
|
|
и [дизайн-система](design-system.md) показывают существующую визуальную основу.
|
|
Неоднозначный вариант можно оценить по конкретному примеру до реализации.
|
|
Успешная сборка каталога не доказывает доступность и визуальное соответствие.
|
|
|
|
## Изменение опасного контракта
|
|
|
|
Для публичного контракта, безопасности, данных, платежей и труднообратимого
|
|
изменения существенная неопределённость разрешается до применения решения.
|
|
Для миграции важны условия отката, сохранность уже созданных данных и проверка
|
|
восстановления. Порядок разрешения конфликтов знаний описан в
|
|
[контексте системы](agent-token-efficiency.md#источники-и-конфликты).
|