s-clientkit — тонкий алиас поверх adapterkit.clientkit

Волна 5, задача 2 (Atlas #2710): живой код переехал в adapterkit.clientkit — здесь остались тонкие модули-реэкспорты. Публичная поверхность (всё, что описано ниже) не изменилась; изменился только адрес кода под ней.

Готовый клиент сервиса собирается по декларации, а не пишется заново.

    clientkit                     <- СБОРЩИК (этот кит)
    /        \
authkit-client  browserkit        <- доступ (кто ты) / чеканка (как войти)
    \        /
      netkit                      <- сеть (чем ходить)
         |
      corekit                     <- основание

Один вызов на оба мира

from clientkit import build_from_toml

white  = build_from_toml("examples/white_service.toml",  secrets=os.environ.get)
hidden = build_from_toml("examples/hidden_service.toml", session_store=store)

await white.call("me")      # белый REST с api-ключом
await hidden.call("me")     # скрытый API с сессией и лестницей деградации

Потребитель зовёт одинаково и по поверхности клиента не может отличить один от другого. Разница — в цене:

Обе половины проверяются тестом tests/test_same_call_both_kinds.py — по sys.modules свежего интерпретатора и по счётчику запросов, а не декларацией.

Декларация — данные

ServiceDecl (frozen dataclass) читается из TOML и валидируется при загрузке: белый сервис с рецептом доступа или скрытый без чеканщика — опечатка, о которой надо узнать при сборке, а не ночью в бою. Round-trip decl_to_data ∘ decl_from_data проверяется тестом.

Смотри examples/white_service.toml и examples/hidden_service.toml.

Чего в ките нет

• своего HTTP — «чем ходить» приходит аргументом (RequestPort), умолчание (только netkit; без него — TransportUnavailable с рецептом установки) резолвится лениво;
• своего браузера — чеканка приходит через порт слоя доступа;
• своей таксономии отказов — диагноз ставит corekit.diagnosis.access, та же функция, что у живой пробы и у реестра эндпоинтов.