Задача: Разработать и запустить сайт

Цель

Разработать и запустить haih.site как основной публичный сайт новой концепции HAIH.

Сайт должен не просто описывать технологии или существующий движок, а наглядно объяснять конечному пользователю новый подход к разработке с AI и давать работающие showcase прямо на сайте, пока отдельная библиотека кейсов на GitHub ещё не оформлена.

Что мы хотим донести

Основная идея:

Не начинай проект с большого движка. Начни с минимальной архитектуры, которая решает текущую задачу, и добавляй следующий слой только тогда, когда он действительно понадобился.

HAIH должен помогать человеку и coding agent дешёво эволюционировать проект: от нескольких статических файлов до сложного типизированного приложения.

Главная ценность — не количество возможностей «из коробки», а стоимость добавления следующей необходимой возможности.

Если задаче достаточно HTML/CSS/JS — не нужны React, база, GraphQL и application server.

Если появилась необходимость хранить данные — добавляется persistence.

Если данные нужно предоставить программным клиентам — появляется API.

Если API нужен frontend — добавляется типизированная клиентская интеграция.

Если нужны пользователи — добавляется auth.

Если нужен полноценный commerce-продукт — архитектура дорастает до него, но проект не должен платить эту цену раньше времени.

Позиционирование

HAIH сейчас следует показывать не как ещё один большой full-stack framework и не как каталог обязательных модулей.

Более точная модель:

минимальная основа + совместимые архитектурные принципы + best practices + законченные вертикальные кейсы для AI-assisted development.

В перспективе это может быть скорее архитектурный протокол, чем единый runtime: разные проекты используют разные части стека, но остаются предсказуемыми и понятными coding agents.

Ключевой принцип:

Use the cheapest architecture that completely solves the requirement.

Каждая новая зависимость должна быть оправдана пользовательской функцией.

Для кого сайт

В первую очередь:

• разработчики, активно использующие Claude Code, Codex, Cursor и другие coding agents;
• solo-разработчики и небольшие команды, которым важно быстро запускать и изменять продукты;
• разработчики, уставшие от избыточной сложности современных full-stack boilerplate;
• люди, которые хотят self-hosted/open-source основу и возможность менять архитектуру под себя;
• авторы собственных решений и кейсов, которыми впоследствии можно делиться с сообществом.

Сайт должен быть понятен человеку, который впервые слышит про HAIH и не знает историю существующего haih-net/agent.

Основное маркетинговое обещание

Не обещать «мы уже реализовали всё».

Показывать:

Start with almost nothing. Add architecture only when your requirements demand it.

И второе обещание:

Дайте coding agent понятные контракты, проверенные примеры и минимальный контекст — и он сможет развивать проект вместе с требованиями.

Пользователь должен после знакомства с сайтом понять:

1. ему не предлагают принять огромный стек заранее;
2. простой проект действительно может оставаться простым;
3. когда требования растут, существуют проверенные пути усложнения;
4. решения проектируются так, чтобы их было удобно понимать, изменять и проверять AI-агенту;
5. showcase — не игрушечные screenshots, а рабочие образцы архитектурных переходов;
6. конечную реализацию пользователь и AI адаптируют под конкретную задачу, а не обязаны устанавливать универсальный модуль.

Почему это важно для AI

Сайт должен отдельно объяснить Agent Experience (AX).

Для coding agent важны:

• минимальный необходимый context;
• предсказуемая структура проекта;
• локальность изменений;
• явные зависимости;
• отсутствие ручного дублирования контрактов;
• типизированные точки соединения компонентов;
• понятные compiler/runtime errors;
• воспроизводимый способ проверки результата;
• готовые кейсы, из которых можно перенести архитектурный принцип в новую задачу.

Сквозная типизация в сложных приложениях должна показываться как feedback loop для AI, например:

Prisma schema
    ↓
Prisma types
    ↓
Pothos
    ↓
GraphQL schema
    ↓
GraphQL Codegen
    ↓
Typed frontend
    ↓
tsc / tests

Но нельзя создавать впечатление, что весь этот стек обязателен каждому проекту.

Showcase как центральная часть сайта

Пока отдельная база showcase/cases на GitHub не оформлена, реализовать принципиальные showcase непосредственно на haih.site.

Showcase должны демонстрировать не список технологий, а разные разумные архитектурные состояния и переходы между ними.

Каждый showcase должен отвечать на вопросы:

• какая была задача;
• почему текущей архитектуры достаточно или уже недостаточно;
• какое новое требование появилось;
• что именно добавили;
• почему не добавили больше;
• как выглядит структура проекта;
• какие зависимости появились;
• как проверить результат;
• что из этого кейса может перенести AI в другой проект.

Showcase 1. Статический сайт

Задача: корпоративный сайт / landing / документационная страница без динамических данных.

Минимальная архитектура:

HTML / CSS / JS / assets
+ Docker Compose
+ Traefik

Никакой БД, GraphQL, auth, React и application server.

Главный тезис: если достаточно статики — движок не нужен.

Показать, насколько дёшево AI может менять такой проект.

Showcase 2. Обособленный API

Задача: сервис, который предоставляет программный API и вообще не нуждается в собственном frontend.

Показать API-first проект как самостоятельное конечное состояние, а не как недоделанный web-сайт.

Варианты развития:

API only

или при необходимости persistence:

PostgreSQL
+ Prisma
+ API

Показать, что UI не является обязательным слоем системы.

Showcase 3. Статический сайт + небольшая динамическая функция

Задача: например, форма обратной связи.

Не превращать ради неё весь сайт в full-stack application.

Показать минимальный переход:

static site
+ small endpoint/service

Если сообщения можно сразу отправлять во внешний сервис — БД не добавлять.

Это важный кейс против overengineering.

Showcase 4. Сайт с persistence

Задача: данные уже необходимо сохранять: заявки, каталог, записи или другой доменный объект.

Добавить:

PostgreSQL
+ Prisma

Показать Prisma как источник типизированной модели данных и объяснить, почему persistence появился именно на этом этапе.

API и сложный frontend добавлять только если задача действительно этого требует.

Showcase 5. Типизированный API поверх данных

Задача: сохранёнными данными должны пользоваться несколько клиентов или frontend должен работать с полноценным API.

Добавить, например:

PostgreSQL
+ Prisma
+ Pothos
+ GraphQL

Показать связь типов Prisma и GraphQL и минимизацию ручного glue-кода.

Showcase 6. Полноценное типизированное web-приложение

Задача: появляется интерактивный frontend, работающий с собственным API.

Архитектура развивается до:

PostgreSQL
+ Prisma
+ Pothos / GraphQL
+ GraphQL Codegen
+ client
+ UI

Показать сквозной контракт database → server → API → frontend и автоматическую проверку изменений компилятором.

Frontend framework не позиционировать как обязательный. Выбор React/другого решения должен быть следствием задачи.

Showcase 7. Пользовательское приложение с авторизацией

Задача: появляются персональные данные, аккаунты или закрытые операции.

Только теперь добавить auth/session/permissions.

Показать, что авторизация — не обязательная инфраструктура каждого сайта, а ответ на конкретное требование.

Продемонстрировать прохождение identity/permissions через API и UI без разрушения предыдущей архитектуры.

Showcase 8. Полноценный интернет-магазин

Задача: реальный сложный продукт.

Должны появиться необходимые доменные части, например:

• каталог товаров;
• категории;
• карточка товара;
• поиск/фильтрация, если оправданы требованиями;
• корзина;
• пользователь/покупатель;
• оформление заказа;
• заказы и их состояния;
• административное управление товарами и заказами;
• изображения/файлы;
• интеграция оплаты как отдельный архитектурный шаг;
• необходимые фоновые процессы/уведомления.

Этот showcase должен показать, что минималистичный подход не ограничивается лендингами: из той же системы принципов можно эволюционно получить полноценное production-oriented приложение.

При этом важно визуально/архитектурно показать происхождение сложности: каждый новый слой существует потому, что его потребовало конкретное бизнес-требование.

Показывать не только состояния, но и переходы

Showcase желательно связать в визуальный граф, а не линейную лестницу.

Пример:

                  ┌→ small endpoint
static website ───┤
                  └→ persistence → API → typed web app → auth → commerce

API service ─────────→ persistence
        └────────────→ agent/client integrations

Главная мысль: нет обязательного конечного стека.

Пользователь может остановиться в любой точке, если она полностью решает задачу.

Что должен делать каждый showcase на самом сайте

Не ограничиваться текстовым описанием.

По возможности каждый showcase должен быть работающим примером:

• открыть результат;
• посмотреть архитектуру/структуру;
• увидеть используемые компоненты;
• увидеть diff или последовательность изменений относительно предыдущего состояния;
• прочитать краткое объяснение архитектурного решения;
• увидеть способ проверки;
• получить инструкцию/prompt/context, с которыми coding agent может воспроизвести или адаптировать решение.

В дальнейшем эти материалы можно вынести/синхронизировать с отдельными GitHub cases.

Предлагаемая структура главной страницы

Hero

Очень коротко объяснить отличие HAIH.

Не «ещё один AI framework», а идея минимальной эволюционной архитектуры для разработки вместе с coding agents.

Основной CTA должен вести к работающим showcase.

Проблема

Современные boilerplate/framework часто заставляют проект платить за сложность заранее.

AI дополнительно платит за неё контекстом и количеством связей, которые должен понять.

Принцип

Start minimal. Add only what the next requirement needs.

Показать визуальную эволюцию от static до сложного приложения.

Live showcase

Центральный раздел сайта с описанными выше кейсами.

AI / AX

Объяснить, почему архитектура специально оптимизируется под coding agents: context, locality, types, compiler feedback, tests, cases.

Best practices / Cases

Объяснить модель базы знаний: не навязывать одну конечную реализацию, а собирать проверенные архитектурные решения и законченные вертикальные изменения.

Open source / Participate

Объяснить будущий community loop:

requirement
→ minimal solution
→ verified case
→ AI reuse
→ new projects
→ new cases

Приглашать пробовать подход, адаптировать кейсы и публиковать собственные решения.

Чего сейчас не обещать

• не позиционировать HAIH как готовую универсальную SaaS-платформу;
• не делать акцент на продаже/монетизации;
• не обещать огромный marketplace готовых модулей, которого пока нет;
• не создавать впечатление, что Prisma/Pothos/Apollo/React обязательны;
• не переносить на новый продукт весь feature list старого haih-net/agent;
• не говорить, что существует единственно правильная архитектура;
• не перегружать главную техническими деталями раньше, чем пользователь понял ценность.

Критерий результата сайта

Новый посетитель без знания истории HAIH должен после просмотра сайта понять:

«Я могу начать с минимального проекта. Когда появится новое требование, AI сможет взять проверенный кейс, добавить только необходимую архитектуру и проверить результат. Мне не нужно заранее принимать огромный framework и тащить в проект функциональность, которой у меня нет».

После понимания этой идеи пользователь должен иметь возможность сразу открыть живой showcase, увидеть её на реальном проекте и получить достаточно информации, чтобы попробовать аналогичный подход самостоятельно.

Цель распространения

На текущем этапе оптимизировать сайт под понимание идеи, эксперименты и участие, а не под продажи.

Желаемый цикл:

посетитель
→ понимает принцип
→ смотрит живой case
→ пробует подход
→ адаптирует решение с AI
→ делится собственным case/best practice
→ следующий пользователь получает ещё один проверенный путь

Сайт должен стать первой публичной демонстрацией этой модели и временно выполнять роль витрины/базы ключевых showcase до появления полноценного открытого каталога кейсов.