🚀 Nick Dobos

# ТРАДИЦИОННЫЙ подход: работа со спецификацией
"Реализуй UserService с методами:
 - create(UserDTO $dto): User
 - update(int $id, UserDTO $dto): User
 - delete(int $id): void
 Используй Repository pattern, валидацию через FormRequest,
 events UserCreated/UserUpdated/UserDeleted."

# Результат: точная реализация спеки. Но: правильная ли спека?

# VIBE CODING: работа с результатом
"Мне нужна страница где менеджер видит список пользователей,
 может добавить нового, отредактировать имя/email,
 и отключить аккаунт (не удалить, а именно отключить).
 Сделай это."

# Результат: working prototype. Потом: "вот здесь кнопка не там",
# "добавь поиск", "статус должен быть цветным".
# Итерация через ДЕМО, а не через спеку.

# Когда vibe coding лучше: ранние этапы, прототипы, unclear requirements
# Когда traditional лучше: чёткие требования, refactor существующего

# Промпт для быстрого прототипа (Nick Dobos стиль)

"Мне нужен рабочий прототип за сегодня. НЕ production код —
 рабочая демонстрация.

 Что делает приложение:
 [описание на языке пользователя, не технические детали]

 Стек: Next.js + Tailwind CSS + Supabase
 (или: Laravel + Livewire + Tailwind)

 Приоритет: работает в браузере > качество кода
 НЕ нужно: авторизация, error handling, тесты, документация

 Начни с главной страницы. Я скажу что менять."

# Потом итерируешь через: "вот что не так:"
# - "кнопка должна быть справа"
# - "добавь поиск"
# - "нужен тёмный фон"
# - "убери это поле, оно не нужно"

# Каждая итерация: CC меняет → ты смотришь → следующее замечание

# Базовый промпт для скриншота
"Сделай точно как на этом скриншоте.
 Используй Tailwind CSS.
 React + TypeScript.
 Все интерактивные элементы должны работать."

# Для Figma дизайна
"Вот дизайн из Figma [скриншот].
 Шрифт: Inter (Google Fonts).
 Цвета из скриншота — определи по визуалу.
 Адаптивность: mobile-first."

# Для существующего сайта (референс)
"Хочу страницу похожую на [скриншот чужого сайта].
 Не копируй — вдохновись структурой и расположением.
 Мой контент: [что нужно показать].
 Мой стек: Vue 3 + Tailwind."

# Для эскиза
"Вот мой набросок [фото скетча].
 Реализуй это как веб-страницу.
 Добавь интерактивность по смыслу."

# Что делает скриншот более эффективным:

✓ Обрезать только нужную область (не весь экран с браузером)
✓ Убрать личные данные (replace с placeholder'ами если нужно)
✓ Добавить стрелки/аннотации для неочевидных элементов:
  "→ это dropdown с вариантами"
  "→ здесь поиск должен быть живым"
  "→ этот блок фиксированный при скролле"
✓ Если несколько состояний — дать оба скриншота:
  "Вот состояние по умолчанию и вот после клика на кнопку"
✓ Указать что НЕ нужно реализовывать:
  "Блок с рекламой справа — не нужен"
  "Footer — оставь пустым пока"

# Чего избегать:
✗ Скриншот с очень маленьким текстом (CC может не прочитать)
✗ Слишком большой скриншот целой страницы — лучше разделить на блоки
✗ Тёмные/плохо контрастные изображения

# Стоп-сигналы: пора переходить к structured development

## Признаки технические
✗ Один баг требует изменений в 5+ файлах
  (нет архитектуры, логика разбросана)
✗ CC начинает давать противоречивые решения для похожих задач
  (нет единого стиля, каждый промпт — отдельный мирок)
✗ Добавление новой фичи ломает существующую
  (нет тестов, нет архитектурных invariants)
✗ Нельзя объяснить коллеге как работает ключевая часть
  (ты сам не понимаешь что CC сделал)

## Признаки продуктовые
✗ Реальные пользователи платят деньги (ответственность выросла)
✗ Данные пользователей в production БД
✗ Нужна команда — ещё один человек должен работать с кодом
✗ SLA или договорённости с клиентами о надёжности

## Признаки процессные
✗ Невозможно вернуться на неделю назад (нет git истории с смыслом)
✗ Деплой = "надеюсь что ничего не сломалось"
✗ Починить один баг → появляется два новых

# Промпт для Nick-стиля рефакторинга из vibe в structured

"Этот код был написан как быстрый прототип.
 Теперь это production-приложение.

 Задача: рефакторить по слоям, начиная с [самый критичный модуль].
 НЕ менять функциональность — только структуру.

 Требования для нового кода:
 - Чёткое разделение: controller / service / repository
 - Каждый метод делает одно (SRP)
 - Все зависимости через параметры/DI (не глобальные)
 - Нет логики в контроллерах (только вызовы сервисов)

 Начни с создания интерфейсов и классов — БЕЗ реализации.
 Я утвержу структуру перед тем как начнёшь переносить логику."

# CLAUDE.md — для vibe-проекта (Nick Dobos подход)

## Стек (зафиксировано, не менять без явного запроса)
- Frontend: Next.js + Tailwind CSS
- Backend: Next.js API Routes
- БД: Supabase (PostgreSQL)
- Деплой: Vercel

## Жёсткие запреты (даже в прототипе)
- Никогда не хранить пароли в plaintext
- Никогда не выводить ошибки с stack trace пользователю
- Никогда не делать SQL через template strings (только параметры)
- Env variables для всех секретов — не хардкодить

## Мягкие правила (можно нарушать с пометкой TODO)
- Валидация input — добавить потом, TODO: validate
- Error handling — минимальный, TODO: proper errors
- Тесты — не сейчас, TODO: add tests
- TypeScript типы — any допустим, TODO: proper types

## Приоритет при конфликте решений
1. Работает в браузере прямо сейчас
2. Безопасно (жёсткие запреты выше)
3. Читаемо
4. Оптимально (наименее важно для прототипа)