"⚪️ Подход к проектированию #flow Думаю, это достаточно очевидно, но на всякий случай поделюсь своим подходом к созданию софта. Можно условно назвать его ""layered"" - как лук, ибо великаны - они как лук (""Вонючие? Нет! Многослойные"" (ц) Шрек). 👉 Идея в следующем. ▶️ Допустим, делаем некую софтину, которая работает через любой UI (GUI, TUI). Очевидно, что у нее есть некая логика и фейс. ▶️ Я всегда в таком случае выношу логику во внешний слой. Можно сразу делать сервер, потому что даже для локальной утилиты пригодится. Хорошая граница системы получается, к слову. Сервер в утилите может быть in-process, это когда он линкуется внутрь процесса клиента и вызывается не через сокет/порт а прямо в коде. Но логика сервера - полноценная, его одной строчкой можно запустить на отдельном порту, и получить ""бесплатно"" уже 2 клиента к одной и той же логике. ▶️ Следом я делаю стандартную обвязку сервера: фиксируем контракт серверных роутов/ручек/маршрутов (кто как зовет), можно в open API стандарте. Делаем типизированный client для этого api, чтобы все валидировалось и типизировалось ""из коробки"". ▶️ Удобно все раложить в мультирепо - client, server отдельными пакетами. ▶️ Самое важное: следом делаем CLI клиента, который имеет доступ ко всем нужным нам функциям через client пакет. И ВОТ ЭТОТ CLI УПРАВЛЯЕТСЯ АГЕНТОМ на этапе разработки. Вы именно через него будете тестирвоать сценарий работы и основную логику вашей системы. ▶️ Дальше все реализовывается до состояния, когда все работает, под управлением агента. Можно реальные зависимости даже дергать (типа, БД там у вашего сервера реальная, миграцию затестить, экспорты/импорты). В общем, суть в том, что ВСЕ сценарии использования системы гоняются на CLI чере агента. ▶️ По итогу отработки логики с агентом, мы фиксируем успешную работу логики в ВИДЕ ТЕСТОВ e2e типа, я их называю сценариями/business processes. Это тот же сценарий, что исполнял агент, только в виде детерминирвоанного теста. На cli тест сильно проще пишется, не надо чего то тяжелого типа playwright/CDP. ▶️ Поверх живой логики в любой момент можно прикрутить ваш GUI/TUI или Desktop UI / Swift / Electron / Electrobun / Tauri и прочую хрень. Если это сделать ""параллеьно"", то можно будет смотреть в UI как агент ваш сценарий ""проегает"" по системе. ❓ В чем профит? Через cli агенту проще и ГОРАЗДО быстрее добраться до отладки именно логики системы, чтобы все работало ок. Не будет мешать GUI обвязка со своими багами ❓ Проще отладить GUI/TUI зная что логика ""внизу"" уже работает ❓ Проще предусмотреть все в апи чего надо, если вся логика через это апи реализуется. Доделки для GUI скорее в виде вспомогательных ручек, которые удобно для UI отдают инфу. ❓ Так сильно быстрее и надежнее. Вы получаете детерминирвоанные и достаточно быстрые тесты, которые на GUI не завяаны, значит можно исключить chrome binary / playwright и тп. ❓Playwright используем по назначению: для тестирвоания самого ГУЯ. Как то так. Тоже так делаете? @deksden_notes"