Мобильные источники и цвет
Расширять совместимость HEIC/HEIF и других источников без изменения WebP-контракта выдачи.
Базовая платформа уже существует: File API, версии, среды, прямая загрузка, вебхуки, SDK, Workspace и обработка форматов. Дальше приоритет у технической глубины, совместимости и поведения под реальной нагрузкой.
File ID, версии, права доступа и правила выдачи остаются стабильной границей для приложения. Внутреннее хранение, каталог и обработчики можно развивать без переноса бизнес-модели клиента.
Замена содержимого, новые форматы и внутренние изменения не должны заставлять клиента менять идентификатор.
Создание, замена, история и удаление должны иметь одинаковую семантику во всех клиентах и SDK.
Клиент должен понимать, что можно повторить, что заблокировано политикой и что требует нового действия.
Приоритет — загрузка, замена, приватная и публичная выдача, Range/HEAD/ETag, идемпотентность и поведение при сетевых сбоях.
Зафиксировать безопасный рабочий диапазон одновременных загрузок и понятное поведение при нехватке ресурсов.
Проверять latency, Range-запросы, ETag, закрытые ссылки и публичную выдачу на реальных размерах файлов.
Идемпотентность и повтор после сетевого сбоя должны быть одинаково понятны в HTTP API и SDK.
Распознавание по содержимому, ограниченные по ресурсам анализаторы и fail-closed поведение остаются общей основой. Поддержка расширяется там, где она нужна реальным клиентам.
Расширять совместимость HEIC/HEIF и других источников без изменения WebP-контракта выдачи.
Добавлять свойства и форматы только там, где их можно доказать безопасно и воспроизводимо.
Неизвестный формат должен сохраняться как обычный файл с теми же версиями, доступом и выдачей.
Центр интеграции, документация и SDK должны описывать один и тот же контракт и одинаково вести разработчика через серверную загрузку, прямую загрузку и вебхуки.
Node.js и PHP получают новые возможности только вместе с понятным HTTP-контрактом и примерами.
Первый файл не должен требовать знания внутренних сущностей Pulse Media.
Подпись, повторные попытки и типы событий должны оставаться совместимыми при развитии платформы.
Local Storage и SQLite остаются рабочей конфигурацией, пока измерения не показывают обратное. Нужны понятные пределы по загрузкам, File API, выдаче, обработке, scanner и росту каталога.
Несколько экземпляров, серверная база данных, объектное хранилище или распределённая выдача имеют смысл, когда текущий предел становится реальной проблемой. File API при этом должен остаться тем же.
Убирать предположения об одном writer только при требованиях по пропускной способности или доступности.
Переезд от SQLite должен решать измеримую проблему, а не менять API ради архитектурной моды.
Система хранения может измениться без смены File ID, версий и правил выдачи.
File API и SDK совместимы, ошибки понятны, поддерживаемые форматы имеют честные границы, рабочий диапазон архитектуры измерен, а независимое приложение может пройти путь от ключа до production-нагрузки без специальных обходов.