📡 pinout — дневник сессии
На митапе обсудили концепцию pinout — экосистемы, которая проверяет совместимость сервисов по их спекам (OpenAPI/AsyncAPI) прямо
в CI, без генерации клиентских библиотек. Источник истины — спека в Git. Написали промпт-постановку (intent), провалидировали
план — и пошли работать с ИИ-агентом.
Что сделали за сессию 👇
🧩 Доработали концепт и обоснование
Сформулировали несущий инвариант: сервис конформен своей спеке (доказано его компонентными тестами) ⇒ совместимость спек =
реальная совместимость, а не намерений. Разобрали, почему спека-в-Git выигрывает у генерации либ, и где границы подхода.
🔀 Закрыли развилку дизайна pinout-openapi (синхронные контракты)
- заглушки и сценарии компонентных тестов потребителя выводятся из master-спеки поставщика;
- MVP инструмента = чистая функция «спека потребителя vs master-спека поставщика», симметрично async;
- генерация сценариев от спеки поставщика — доработка скилла component-tests в service-template.
🗺️ Спроектировали по скиллам (vertical slice, ROP, бизнес-логика ≠ I/O): пакет проектирования, компонентные тесты (Gherkin),
канон общего формата отчёта валидаторов. Завели бэклог экосистемы (эпики E0–E4) и план интеграции с координатором графа
pinout-netlist.
📦 Репозитории:
- Концепт → github.com/codemonstersteam/pinout
- AsyncAPI-валидатор → github.com/codemonstersteam/pinout-asyncapi
- OpenAPI-валидатор (новый) → github.com/codemonstersteam/pinout-openapi
- Netlist-координатор (новый) → github.com/codemonstersteam/pinout-netlist
- Методология/скиллы → github.com/ubik-life/service-template
🛠️ Подход к разработке — TDD маленькими инкрементами с ИИ: проектируешь модули, фиксируешь контракты, выдаёшь чёткие задачи.
➡️ На следующем митапе продолжим проектирование инструмента pinout-openapi по бэклогу.
🗓️ Вторник 23 июня, 18:30.
Ссылку на встречу пришлю за 30 мин до встречи
backlog распределенной системы храним в мета-репозитории системы
#codemonsterslog
На митапе обсудили концепцию pinout — экосистемы, которая проверяет совместимость сервисов по их спекам (OpenAPI/AsyncAPI) прямо
в CI, без генерации клиентских библиотек. Источник истины — спека в Git. Написали промпт-постановку (intent), провалидировали
план — и пошли работать с ИИ-агентом.
Что сделали за сессию 👇
🧩 Доработали концепт и обоснование
Сформулировали несущий инвариант: сервис конформен своей спеке (доказано его компонентными тестами) ⇒ совместимость спек =
реальная совместимость, а не намерений. Разобрали, почему спека-в-Git выигрывает у генерации либ, и где границы подхода.
🔀 Закрыли развилку дизайна pinout-openapi (синхронные контракты)
- заглушки и сценарии компонентных тестов потребителя выводятся из master-спеки поставщика;
- MVP инструмента = чистая функция «спека потребителя vs master-спека поставщика», симметрично async;
- генерация сценариев от спеки поставщика — доработка скилла component-tests в service-template.
🗺️ Спроектировали по скиллам (vertical slice, ROP, бизнес-логика ≠ I/O): пакет проектирования, компонентные тесты (Gherkin),
канон общего формата отчёта валидаторов. Завели бэклог экосистемы (эпики E0–E4) и план интеграции с координатором графа
pinout-netlist.
📦 Репозитории:
- Концепт → github.com/codemonstersteam/pinout
- AsyncAPI-валидатор → github.com/codemonstersteam/pinout-asyncapi
- OpenAPI-валидатор (новый) → github.com/codemonstersteam/pinout-openapi
- Netlist-координатор (новый) → github.com/codemonstersteam/pinout-netlist
- Методология/скиллы → github.com/ubik-life/service-template
🛠️ Подход к разработке — TDD маленькими инкрементами с ИИ: проектируешь модули, фиксируешь контракты, выдаёшь чёткие задачи.
➡️ На следующем митапе продолжим проектирование инструмента pinout-openapi по бэклогу.
🗓️ Вторник 23 июня, 18:30.
Ссылку на встречу пришлю за 30 мин до встречи
backlog распределенной системы храним в мета-репозитории системы
#codemonsterslog