commit-component

name	commit-component
description	Формирует коммит по docs/ai/commits.md для текущих незакоммиченных изменений в triplex-next — проверяет git status, формирует сообщение в формате "TRIPLEX-XXX Описание", делает коммит. Запускается только по явной просьбе пользователя.

commit-component

Делает коммит текущих изменений по конвенциям docs/ai/commits.md.

Когда запускать

Только когда пользователь явно попросил коммитить. В memory пользователя есть правило «не создавать коммиты без запроса» — его нельзя нарушать. Если есть малейшее сомнение — спроси.

Воркфлоу

1. Проверка состояния

Запусти параллельно:

git status              # без -uall — на больших репах ест память
git diff                # текущие unstaged изменения
git diff --staged       # staged изменения
git log -5 --oneline    # стиль последних коммитов
git rev-parse --abbrev-ref HEAD   # текущая ветка

Имя ветки должно быть в формате TRIPLEX-XXX-краткое-описание (см. docs/ai/commits.md). Извлеки TRIPLEX-XXX для коммита.

2. Анализ изменений

Раздели изменения на категории:

• Затронутые компоненты (src/components/{Name}/...)
• Stories (stories/...)
• Тесты (src/components/{Name}/__tests__/...)
• Документация (docs/ai/..., *-ai.md, release notes)
• Конфиги (eslint, vitest, storybook, ci)

Определи характер:

• Add — новый компонент / новый prop / новая story
• Update — изменение существующего поведения
• Fix — багфикс
• Refactor — рефакторинг без изменения публичного API (типичный AI refactoring)
• Docs — только документация / AI.md / release notes

3. Release notes — обязательная проверка

Это шаг-гейт: не переходи к коммиту, не ответив на вопрос про release notes.

Определи, менялось ли публичное поведение компонента. Release notes нужны не только при breaking change, а при любом изменении публичного API или наблюдаемого поведения (см. раздел «Release notes» в docs/ai/commits.md):

• новый или удалённый prop, изменение типа/значения по умолчанию;
• изменение того, что компонент рендерит или как себя ведёт при тех же props (например, автоматический rel="noopener" для target="_blank", смена уровня логирования, изменение фокуса/клавиатуры/overlay-поведения);
• багфикс, который меняет наблюдаемое поведение.

Release notes не нужны для изменений только в stories / тестах / документации и для рефакторинга без изменения публичного API.

Если release notes нужны:

1. Найди текущую версию: ls stories/release-notes/v1/ — бери файл с наибольшей версией (или уточни у пользователя, если готовится новая версия).
2. Убедись, что запись уже добавлена в stories/release-notes/v1/<версия>.mdx в формате из docs/ai/commits.md (компоненты — в алфавитном порядке; breaking change — в секцию «Ломающие изменения»).
3. Если записи нет — останови коммит и сообщи пользователю, предложи добавить release notes. Не коммить изменение публичного поведения без release notes.
4. Файл release notes должен попасть в тот же коммит, что и изменение компонента.

Если сомневаешься, публичное ли это изменение — спроси пользователя, а не пропускай.

4. Проверка безопасности

Никогда не коммить:

• __screenshots__/*.png если изменения локальные (macOS) — pre-commit hook должен заблокировать, но проверь сам.
• .env* файлы.
• node_modules/, dist/, storybook-static/ — должны быть в .gitignore.
• Случайно сгенерированные временные файлы (*.log, tmp.*, IDE-specific).

Если в git status видишь подозрительный файл — спроси пользователя, не добавляй автоматически. Если файл не должен трекаться — предложи добавить в .gitignore.

5. Формат сообщения

TRIPLEX-XXX Краткое описание (≤72 символа)

Если нужно уточнение — двоеточие:

TRIPLEX-XXX Component: уточнение

Примеры:

TRIPLEX-901 Добавить компонент Badge с темами и размерами
TRIPLEX-912 Button: исправить стиль фокуса в теме Link
TRIPLEX-844 List: AI refactoring + unit-тесты на ListItem
TRIPLEX-844 List: добавить List-ai.md и Storybook examples

Правила:

• Первая строка ≤72 символов.
• Тело — опционально, для сложных изменений.
• Язык — русский или английский, не смешивать.
• Фокус — на «что» и «почему», не на «как».
• Не добавляй Co-Authored-By: Claude для этого проекта (в docs/ai/commits.md не предусмотрено).

6. Стейджинг и коммит

git add <конкретные файлы>     # не git add -A / git add .
git commit -m "TRIPLEX-XXX ..."

Никогда не используй:

• git add -A или git add . — может добавить sensitive/temp файлы.
• --no-verify — обходит linter/husky, нарушает требования проекта.
• --amend без явной просьбы пользователя.

7. Pre-commit hook

husky + lint-staged запустят eslint --fix и prettier --write на staged-файлах автоматически. Если упало:

1. Прочитай ошибку — это не автофиксимое ESLint-нарушение.
2. Не используй --no-verify. Исправь руками.
3. Пере-stage: git add <files>.
4. Создай новый коммит (не amend — амендить значит переписать предыдущий, который при упавшем хуке не создался; но если коммит был частично создан, амендить может потерять работу).

8. После коммита

git status   # подтверди успех
git log -1 --oneline

Покажи пользователю:

• Хеш коммита и одну строку сообщения.
• Что попало в коммит (список файлов).

Не пушь автоматически. Push — только по отдельной явной просьбе.

Жёсткие ограничения

• Не запускай без явного запроса пользователя на коммит.
• Не коммить, если есть несохранённые/неотревьюенные изменения, о которых пользователь может не знать. Если файлов в git status больше, чем ожидалось — сначала спроси.
• Не коммить, если упали проверки (tsc errors, failing tests). Сначала чини, потом коммит.
• Не коммить изменение публичного поведения без release notes (см. шаг 3). Если запись в stories/release-notes/v1/<версия>.mdx отсутствует — остановись и сообщи пользователю.
• Не делай несколько коммитов за один запуск без подтверждения. Один запуск = один коммит, если иное не оговорено.
• Не пушь. Push — отдельный шаг по отдельной просьбе.

Если что-то странное в git status

Не пытайся «привести в порядок» автоматически. Покажи git status пользователю и спроси, как поступить:

• Незнакомые untracked файлы — может быть work-in-progress, который пользователь не закончил.
• Изменения в файлах, которые не имеют отношения к задаче — могут быть случайными правками.
• Состояние rebase/merge in progress — не вмешивайся, сообщи пользователю.

Что включает «один коммит»

Связные изменения по одной задаче. Для типичной Phase 1 итерации по компоненту — это:

• Правки в src/components/{Name}/
• Тесты в src/components/{Name}/__tests__/
• Stories в stories/.../{Name}/
• src/components/{Name}/{Name}-ai.md
• Обновление docs/ai/ROADMAP.md (галочки)
• При изменении публичного поведения (не только breaking change) — stories/release-notes/v1/<версия>.mdx (см. шаг 3)

Всё это укладывается в один коммит TRIPLEX-XXX {Name}: AI-Ready или аналогичный.