Sonnet + Archspec: от плана до дефектов

01 / Прогон Sonnet: карта артефактов

Sonnet 4.6 + Archspec: task_2 · 780cd6a → task_3 · 7a6f26a. В бенчмарке: план 9/10, код 8/10, чеклист ≈93%, результат частичный. Это оценки опубликованного ревью, а не новая оценка этой шпаргалки. Карточка прогона ↗

Кликайте узлы: Source открывает файл на GitHubОткрыть отдельно ↗

Артефакт	Что в нём	Открыть пример
SERVICE_MAP.yaml	У сервиса: обязанности, API, события, дедуп, путь записи, тесты рисков	Карта task-service ↗ · Карта matching ↗
archplan.md	Contract Slice, вопросы, proto/YAML patch, fan-out, владельцы, EC, ревью, DoD	Полный план ↗
codingplan.md	Таблица соответствия и порядок реализации	План задач ↗
ARCHITECTURE.md + Mermaid	Документация сервиса, полученная из карты	Описание ↗ · Sequence ↗
ADR-001	JWT-идентификация запланирована; реализация отложена	Решение / статус ↗
implement-notes.md	Самоотчёт: 15/15 EC, validate green, review CLEAN	Самоотчёт ↗
code-review.md	Внешнее ревью: дефекты, соответствие и оценки	Разбор реализации ↗

02 / Как читать план за минуту

Раздел	Вопрос к нему	Конкретный ответ
Contract Slice ↗	Какие старые правила нельзя нарушить?	Outbox, один владелец статуса, дедуп notification; старый task_id не подходит для повторов
Open Questions ↗	Какие решения уже приняты?	В полном плане city_id required; ноль кандидатов в scope; worker_id должен быть из JWT
YAML Patch ↗	Что меняем в картах?	Четыре сервиса: task, matching, notification, gateway
Fan-Out Trace ↗	Все ли подписчики учтены?	offer.declined → matching; match.found → task + notification; match.exhausted → task
State-Ownership Map ↗	Кто имеет право менять состояние?	Task и счётчик — task-service; попытка — matching; дедуп уведомлений — notification
Edge Cases Register ↗	Как риск попадёт в тест?	15 записей EC со ссылками path::TestName
Conformance Table ↗	Как план связан с реализацией?	Элемент archplan → Coding Task → Test

# Фрагмент формы codingplan, сокращённый для чтения
| Archplan Element            | Coding Task   | Test                         |
| CreateAttemptPendingIfAbsent| Task 8 (repo) | TestEC008_DuplicateOfferDeclined |
| city_id on Task             | Task 1 + 2    | TestEC006_CreateTaskMissingCityID |

03 / Требование → код → тест

Два дефекта ранжирования в task_3Открыть отдельно ↗

Требование / обещание	Фактический код	Почему зелёные проверки не помогли
Рейтинг первичен ↗	Расстояние пересортировывает весь список ↗	В SortCandidatesByGeo рейтинг не передан; Score результата не заполняется
Расстояние только при равных рейтингах	Тест равных расстояний ↗	Тест проверяет worker_id при равном расстоянии; сравнения рейтинг × расстояние нет
Один namespace city_id	city-msk ↗ / moscow ↗	Поле есть и тип string совпал; значения между сервисами несовместимы
worker_id из JWT ↗	body.WorkerID ↗	README утверждает token identity, но ADR Planned и обработчик показывают отложенную реализацию
client_id обязателен для уведомления	При пустом client_id — warning ↗	Самоотчёт обещает EC-010; в HandleMatchFound пустой ID не возвращает ошибку

04 / Что процесс улучшил и что осталось

Удержалось в коде	Доказательство
Событийное переназначение и outbox	DeclineAndPublish ↗ · SubscribeOfferDeclined ↗
Ключ (task_id, attempt), новый match_id	Репозиторий попыток ↗
Переиспользование снапшота кандидатов	Повторный путь ↗
Лимит: три переназначения после первого оффера	Проверка до инкремента ↗
Оффер исполнителю и лог уведомления клиенту	HandleMatchFound ↗

Снапшот — отдельный компромисс Sonnet: повторный подбор дешёвый, но рейтинг, верификация и геоданные остаются такими, какими были при первом подборе. Это выбранная реализация, а не единственный способ выполнить задачу. Обсуждение снапшота ↗