6.2 KiB
Проверка дизайна перед реализацией
Проверено 11.11.2026. Это проверка согласованности спецификации, не подтверждение работоспособности ещё не созданной платформы. Можно начинать P0–P2; поддержка DSH и account modes требует проверок из roadmap
Исправленные противоречия и пробелы
| Проблема | Принятое решение |
|---|---|
| Неясно, что меняем в DSH | Собственный UI и внутренние границы; public plugin API сохраняем в проверенном профиле — DSH |
| Совместимость обещана без версии/проверки | Manifest metadata + отдельный compatibility report; gate публикации — каталог |
| Подписка приравнивалась к универсальному API-доступу | Отдельная матрица provider/auth/deployment; gated modes — плагины |
| Resume менял неизменяемый ExecutionSpec | Checkpoint и ответ вынесены в AttemptContext; retry нового Run меняет runId/specDigest — исполнение |
| Run и Attempt могли иметь два источника истины | Общая транзакционная область Platform DB; engine mapping в Execution DB — модель |
| Потерянный ответ claim мог занять второй слот | claimRequestId, восстановление assignments и fencing — Runner API |
| Длинная задача переживала срок execution token | Heartbeat обновляет токен до общего deadline; терминальный replay отдельно от новых записей — Runner API |
| ResultManifest и input/output отсутствовали в схемах | Добавлены схемы результата, Assignment, input/output refs и примеры — контракты |
| Расписание не определяло ревизию, DST и переполнение | Pinned revision, preview/pause, skip/queue, bounded coalesce — API |
| Timeout, ожидание ввода и отмена имели неоднозначные исходы | Deadline общий для Run; подтверждение остановки отличает failed/cancelled от interrupted — исполнение |
| Mobile подразумевал полный локальный runtime | JS-клиент управляет Runner; desktop имеет sidecar — roadmap |
| Схема формы смешивалась со схемами протокола | Ограниченный UI profile отдельно от служебного JSON Schema — UI |
Gate перед выпуском соответствующей функции
| Проверка | Когда обязательна | Что фиксируем |
|---|---|---|
| DSH baseline | P0, до публикации runtime | Exact commit, lock, image digest, load/run/cancel/dispose и plugin compatibility report |
| Provider account integration | P5, до включения конкретного mode | Регистрация/допуск интеграции, способ входа, размещение credentials, ограничения подписки, conformance |
| Runtime и SDK контракты | P0–P1 | OpenAPI, generated types, одинаковые fixtures JS/Go, межресурсные инварианты |
| KMS/S3 и секреты | P3, до real credentials | Выбранные реализации, ротация, backup/restore, изоляция tenant |
| Недоверенные публичные плагины | P2 до открытия исполнения публичного кода | Политика модерации, sandbox/trust profile и процедура отзыва версии |
| Собственный Runner | P4 до допуска пула | Protocol conformance плюс явное подтверждение владельцем trust policy |
| Нагрузка и восстановление | P7 до эксплуатационных обещаний | Нагрузочный профиль, реальные SLO, restore rehearsal |
Выбор лицензии Invest Harness остаётся решением владельца проекта; публичный репозиторий не заменяет разрешение на распространение. Версии библиотек и deploy images закрепляются в реализации, а не остаются плавающими ссылками из документа
Первый вертикальный срез
Автор публикует DSH harness, один совместимый plugin и template с config/input/output schemas. Пользователь создаёт ревизию через форму, связывает тестовый provider и запускает тот же состав локально и на одном Runner. Сохраняются события и валидный результат. Повтор POST Run и claim не создаёт дубликаты; чужой tenant не читает результат; cancel останавливает процесс; потеря lease запрещает позднюю запись; credentials отсутствуют в snapshot и логах
Машиночитаемые схемы здесь задают основу протокола, но не полный SDK. До реализации endpoint его request/response и ошибки переносятся в OpenAPI и проверяются контрактными fixtures. Проверки JSON Schema не доказывают корректность OAuth, sandbox или финансовых действий внутри harness