07 · Workflow · Audit → Fix → Approve → Push¶

Зачем этот файл¶

Все 26 версий v4.4.0 → v4.5.0 шли через одинаковый цикл: audit → fix → approve → commit → push. Без формализации этот цикл воспроизводился по памяти и иногда нарушался (commit без апрува = разочарование CEO + потенциальный rollback).

Этот файл фиксирует процедуру as durable rule. Любая Claude-сессия должна следовать этому workflow без вариаций.

4 призмы методология¶

При запуске аудита через 4 призмы — каждая призма = отдельная фаза с собственным циклом audit-fix-approve-push.

Призма 1 · UI Kit (структурный аудит)¶

Что проверяет: - Соответствие canonical классам (feedback_dont_change_approved_components.md) - Дубли (например .tier-l1 vs .tier-pill-l1) - Inline styles (мигрировать в page-isolated класс если > 5 мест) - Header canonical v3.2 (77px / cube 44 / wordmark 17.5 / subline 14) - Spacing / typography / colors из tokens (не hardcoded) - Symmetry rule v4.4.12 (4 уровня)

Эталон: audit-2026-05-07-stage-3-academy.md (Призма 1 пример).

Призма 2 · Light theme¶

Что проверяет: - Каждый экран в обеих темах через Chrome MCP - Контраст и читаемость (нет white-on-white) - Hover states (bg + color оба) - Footer контекст (UI-app cream / marketing dark) - Premium artifacts (light surface + gold preserved)

Эталон: audit-2026-05-07-light-theme.md.

Призма 3 · Англицизмы¶

Что проверяет: - Запрещённые термины (см. feedback_no_anglicisms.md): sprint / scope / refactor / boilerplate / MVP / hero / viewport / anti-pattern / LTV - Branding immutable (продукты / tier-коды / тех маркеры) — оставить - UI кнопки / описания / статусы — переводить

Промпт: «проверь экран X на англицизмы».

Призма 4 · EN перевод (после Призм 1-3)¶

Что проверяет: - i18n keys coverage в HTML - data-i18n атрибуты на всех translatable text - Native EN качество (не machine translation) - Date / number / currency формат locale-correct - MutationObserver на динамических элементах

Project plan: project_native_en_localization.md (4 этапа · ~$1.5K Upwork).

Каждая призма = отдельный цикл¶

НЕ объединять призмы в один большой commit. Между призмами — checkpoint CEO.

Cycle audit-fix-approve-push (durable)¶

Из feedback_audit_fix_workflow.md (CEO 2026-05-07):

1. Audit фаза (Призма N) → отчёт-документ в /claude/
2. CEO утверждает план фиксов (выбирает порядок / варианты)
3. Claude делает фиксы локально (НЕ commit!)
4. Claude verify через Chrome MCP / preview server (computed style + zoom screenshot)
5. Claude отчитывается CEO визуально + замеры
6. CEO ревью → апрув / правки
7. (если правки → Claude правит → шаг 5)
8. После апрува → Claude commit + push в GitLab
9. ROOT_LOG entry в /claude/ROOT_LOG.md
10. Следующая фаза → шаг 1

Правило железобетонное¶

До апрува CEO — НЕТ commit. НЕТ push.

Локальные правки накапливаются в working tree. Если CEO решит прервать — fixes уже сохранены, можно делать quick closure отдельно.

CEO часто делает 2-4 итерации ревизий после первого показа — это нормально. День 18 lesson-viewer прошёл через 4 итерации (база → вариант B → вариант A → mirror UX). Не паниковать.

Audit-report template¶

См. полный template в 09-audit-checklist.md § Sample audit-report.

Базовая структура:

# AUDIT · [Product] · Призма [N] · YYYY-MM-DD

## Контекст
- Продукт: [имя]
- Экранов: [N]
- Призма: [1/2/3/4]

## Метод
[Как проверял — Chrome MCP / computed / visual]

## Findings (по экранам)
[10 экранов с findings each]

## Cross-cutting issues
[Системные проблемы]

## План фиксов
[HIGH / MED / LOW priority]

## Decision needed CEO
[Конкретный вопрос с вариантами + рекомендация]

## Status checklist
- [ ] Audit closed
- [ ] CEO approved fix plan
- [ ] Fixes applied
- [ ] CEO approved visual
- [ ] Commit + push
- [ ] ROOT_LOG entry

CEO approval gate¶

Триггеры от CEO для перехода к commit¶

Однозначно push¶

«апрув»
«апрув для commit»
«делай commit»
«commit X» / «commit v4.X.Y»
«фиксируем · push»

Closed visually, можно идти к bump+commit¶

«фиксируем»
«фиксируем всё»
«супер»
«идеально»
«отлично»
«сейчас идеально, фиксируй»

После этих триггеров можно начинать closure (bump + CHANGELOG + memory + commit + push).

НЕ закрыто, продолжать iterate¶

«нужны правки: X»
«сделай ещё»
«не работает Y»
«попробуй Z»

Нейтральный, спросить подтверждение¶

«это нормально»
«ОК» (без «фиксируем»)
«норм»
«сойдёт»

В этих случаях — спросить «делаем commit?» перед push.

Anti-pattern interpretations¶

❌ Молчание = апрув (не самопроизвольно интерпретировать)
❌ Общая похвала «отличная работа» без явного «фиксируем» = closure
❌ «Хорошо звучит» = делать (это feedback на план, не апрув на work)

Когда не уверен — спросить¶

«Делать closure (commit + push) или есть правки?»

Лучше спросить лишний раз чем сделать unauthorized push.

Visual proof протокол (новое v4.5.0)¶

Перед показом CEO любого fix — обязательная триада:

1 · Screenshot¶

Через Chrome MCP computer:screenshot действие на browser tab. Full page для overview / region для focus.

// Screenshot full
mcp__Claude_in_Chrome__computer({ action: 'screenshot', tabId: X })

// Screenshot region (zoom)
mcp__Claude_in_Chrome__computer({ action: 'zoom', region: [x1,y1,x2,y2], tabId: X })

2 · Zoom (если нужна детализация)¶

Конкретный элемент / hover state / типографика.

3 · Computed style для критических свойств¶

Через Chrome MCP javascript_tool:

const el = document.querySelector('.X');
const s = getComputedStyle(el);
JSON.stringify({
  bg: s.backgroundColor,
  color: s.color,
  hovered: el.matches(':hover')
})

Antipattern¶

❌ Доверять «считаю что должно работать» / «по документации это так»
✅ Только реальный computed + visual proof

Пример провала Phase 1 v4.4.17: заявил CEO «footer dark работает» на основе computed rgb(14,13,11). Не сделал screenshot. На самом деле визуально выглядел dark — но я неверно прочитал warm dark color на jpeg как cream. CEO ругался «5 раз тебе писал».

Memory protocol¶

3 трека memory¶

`feedback_*` — корректировки от CEO¶

Что не делать / что делать. Долгоживущие правила.

Когда писать новый: - CEO дал явное правило («запиши это», «фиксируем», «на будущее») - Появился новый canonical pattern (после CEO утвердил) - Найдена новая anti-pattern после ошибки

Структура:

---
name: ...
description: одна строка для MEMORY.md (~150 chars)
type: feedback
originSessionId: ...
---
[Rule body]

## Why
[Контекст почему правило · цитата CEO если есть]

## How to apply
[Конкретные шаги или паттерн применения]

## Re-entry якорь (опционально)
«прочти контекст X» → этот файл

`project_*` — состояние ongoing работ¶

Закрытые этапы / открытые pending / status проектов.

Когда писать новый: - Закрыта призма / большая работа - Открыт новый проект (с timeline) - Появился pending action с deadline

Структура: аналогично feedback, но добавить: - Status: active / closed / paused - Stakeholders (Артём / Виктория / Свят / external) - Timeline / milestones - Closed precedents (если применимо)

`reference_*` — указатели на внешние ресурсы¶

Memory один раз создан и не меняется (URL / file paths / external systems).

Когда обновлять existing¶

Правило расширилось (добавить в How to apply)
Изменился контекст (status: active → closed)
Появился новый precedent для existing rule (добавить в case examples)

Memory hierarchy при conflict¶

При conflict между memory files — приоритет: 1. Latest by date — newer feedback overrides older (CEO передумал) 2. More specific — узкий rule перевешивает общий 3. CEO явный — «Я хочу X» побеждает inferred preference 4. Closed precedent — feedback_*_canonical.md имеют high authority 5. Active project — текущий project_* перевешивает старые feedback

MEMORY.md index¶

Каждый memory file должен иметь one-line entry в MEMORY.md:

- [Title](filename.md) — one-line hook (~150 chars max)

MEMORY.md всегда подгружен в context. Лимит ~200 строк (после truncated).

Versioning · patch / minor / major¶

Из feedback_design_system_workflow_v41.md:

Patch (4.5.X)¶

Точечный fix одного файла playbook / one CSS rule
Поведение не меняется
Обратная совместимость гарантирована
Примеры:
Опечатка в spec
Цвет border поправлен
Padding card изменён на 24px (если был 25)

Minor (4.X.0)¶

Новый компонент / новый pattern / новый раздел playbook
Обратная совместимость сохранена
Примеры:
Добавлен .eco-sidebar-link (новый класс)
Добавлен 05-patterns.md AI-Diagnostic section
Добавлен новый эталонный экран (6-й)

Major (X.0.0)¶

Пересмотр архитектуры
Breaking rename canonical классов
Примеры:
Header canonical v4 заменяет v3 (breaking)
Token system пересмотрен (новые имена)
Removed legacy class

Bump procedure (manual)¶

Артём не перенёс _deploy/scripts/version-bump.py, поэтому bump делается вручную:

# 1. Edit VERSION (новая SemVer)
echo "4.5.0" > VERSION

# 2. Edit CHANGELOG.md (добавить блок)
# ## [4.5.0] · 2026-05-06 · краткое описание

# 3. (опционально) Edit ui-kit/ui-kit-v4.2.md если spec обновился
# Добавить раздел / изменить правило / pointer на playbook

# 4. (опционально) Update memory
# Создать новый feedback_X.md / обновить existing

# 5. Bump query на CSS / JS links в HTML (если CSS правил)
sed -i '' 's/v=4\.4\.17/v=4.5.0/g' ecosystem-prototype/**/*.html

# 6. Commit + push
git add -A
git commit -m "v4.5.0: описание"
git push origin master

# 7. Если push отклонён (Артём правит nginx параллельно)
git pull --rebase origin master
git push origin master

CI auto-deploy на https://design.goldjaxe.ai/ через ~30 сек (CI runner с тегом design.goldjaxe.ai).

Privacy-lint НЕ запускать¶

/claude/scripts/lint-privacy.py — для TEAM-вики. Design-system repo НЕ имеет приватных markers, скрипт не подходит. См. /claude/CLAUDE.md.

ROOT_LOG.md entry¶

После push — обязательная запись в /claude/ROOT_LOG.md:

[YYYY-MM-DD HH:MM] · vX.Y.Z · короткое описание

**Что закрыто:**
- [тема 1]
- [тема 2]

**Memory обновлено:**
- [файл 1]
- [файл 2]

**Commit:** [hash]
**Push:** [hash → branch]
**CI status:** OK / pending / failed

Типы операций¶

bump — version bump только
audit-fix — после Призмы N
canonical — новый эталон утверждён
cleanup — refactor / удаление dead code
migration — token / class rename
lint-both — после lint-privacy run на TEAM-вики
cross-query — cross-wiki query filing
split-ingest — после Split-Ingest mixed файла

Cold start checklist для новой сессии¶

Если CEO открыл новую сессию по дизайн-теме:

Прочитать MEMORY.md (auto-loaded)
По первому сообщению определить тему → найти триггер в 10-reentry-anchors.md
Если дизайн-related → ОБЯЗАТЕЛЬНО SEMANTIC-CORE.md + relevant playbook раздел
Если user дал триггер «прочти контекст X» → fast-track к этому файлу
Если task = audit → 09-audit-checklist.md + методология 4 призм
Если task = fix → 07-workflow.md (этот файл) + не commit без апрува

Когда читать¶

Перед каждым commit/push — обязательно (5 мин освежить)
Перед запуском аудита нового продукта — обязательно
При onboarding нового подрядчика — обязательно
При сомнении «это апрув или нет» — таблица CEO triggers
При создании нового memory — раздел Memory protocol