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