64 lines
5.1 KiB
Markdown
64 lines
5.1 KiB
Markdown
# Product
|
|
|
|
## Register
|
|
|
|
product
|
|
|
|
## Users
|
|
|
|
Системные администраторы, DevOps- и хостинг-инженеры, которые массово мигрируют
|
|
почтовые ящики между IMAP-серверами (source → destination). Контекст использования —
|
|
рабочая сессия миграции: пользователь заводит задачу, добавляет десятки аккаунтов
|
|
(в т.ч. импортом из CSV), запускает копирование и следит за живым прогрессом по
|
|
тысячам писем на аккаунт. Работают с плотными таблицами, читают счётчики
|
|
Copied / Skipped / Errors и статусы, ждут точности и предсказуемости, а не «красоты».
|
|
|
|
_(Выведено из README и кода; пользователь был недоступен при уточнении — подтвердить/скорректировать.)_
|
|
|
|
## Product Purpose
|
|
|
|
Однобинарный Go-сервер (встраивает React-SPA), который **копирует** содержимое
|
|
IMAP-ящиков между аккаунтами: неразрушающе (только APPEND, ничего не удаляет),
|
|
с дедупликацией по Message-ID, идемпотентно и с возобновляемостью. Успех =
|
|
инженер запускает миграцию, видит достоверный прогресс в реальном времени, а
|
|
повторный запуск честно скипает уже перенесённое и показывает ровно то, что
|
|
произошло в этом прогоне. Ценность — доверие к цифрам и отсутствие сюрпризов
|
|
на больших объёмах.
|
|
|
|
## Brand Personality
|
|
|
|
Три слова: **технично, точно, спокойно**. Голос — инструмент оператора, а не
|
|
маркетинговый продукт: краткие подписи, честные статусы, никакого хайпа.
|
|
Эмоциональная цель — уверенность и контроль. Интерфейс должен читаться как
|
|
приборная панель / консоль: плотная информация, монохром с одним функциональным
|
|
акцентом, состояние системы всегда очевидно.
|
|
|
|
## Anti-references
|
|
|
|
- Яркие SaaS-лендинги с hero-метриками, градиентным текстом и карточками-плитками.
|
|
- «Дружелюбные» дашборды в стиле генеративного AI: cream/paper-фон, скруглённые
|
|
пастельные карточки, иконка+заголовок+текст в бесконечной сетке.
|
|
- Любой декор ради декора (glassmorphism, тени-свечения без функции).
|
|
- Разреженные «воздушные» лейауты — здесь плотность данных это фича, а не проблема.
|
|
|
|
## Design Principles
|
|
|
|
1. **Числам верят.** Счётчики и статусы обязаны быть достоверны и однозначны;
|
|
визуальная неоднозначность статуса — это баг, а не косметика.
|
|
2. **Плотность — это уважение к оператору.** Компактные таблицы и моноширинные
|
|
табличные цифры важнее «воздуха».
|
|
3. **Один акцент, одна семантика.** Янтарь = внимание/действие; зелёный = успех;
|
|
красный = ошибка; жёлтый = ожидание. Цвет всегда несёт смысл.
|
|
4. **Состояние системы всегда видно.** Прогресс, скип, ошибка и последняя причина
|
|
сбоя должны переживать перезагрузку страницы и не теряться.
|
|
5. **Спокойная инженерная сдержанность.** Никакого хайпа и лишнего движения;
|
|
анимация только там, где отражает реальный процесс.
|
|
|
|
## Accessibility & Inclusion
|
|
|
|
Базовый уровень: читаемый контраст (цель — WCAG AA для основного текста, особенно
|
|
приглушённого `--fg-dim` на тёмных панелях), корректный `prefers-reduced-motion`
|
|
для live-прогресса, различимость статусов не только цветом (иконка/подпись рядом
|
|
с цветом для дальтоников). Формальной сертификации не требуется — инструмент для
|
|
узкого технического круга, но контраст и reduced-motion соблюдаем осознанно.
|