Files
upload-platform/docs/sonnet-architecture-review-response.md

3.9 KiB
Raw Permalink Blame History

Ответ Sonnet по архитектуре

Важная поправка к вводным

Промпт устарел относительно реального кода.

  • zip/list_zip_files.js не использует глобальную fflate — реально вызывает parseZip() из parse_zip.js, собственный ZIP-парсер без внешних зависимостей.
  • Защита от path traversal и лимит вложенности 20 реальны, но находятся в list_zip_files.js (safeEntryParts, depth), а не в парсинге через fflate.
  • index.html:37 всё ещё грузит static/vendor/fflate.min.js с комментарием «ZIP-парсер использует global fflate» — это мёртвый код и ложный комментарий, fflate фактически не импортируется.
  • В add_file_with_dedup.js есть логика maxFileBytes/maxSessionBytes, но config.json содержит только allowedExt; лимиты сейчас нигде не задаются, код неактивен.

1. Архитектура

Направление верное: initFilePicker(config) с построением DOM внутри, конфигом для allowedExt/labels/layout, onChange и destroy соответствует цели «одна строка встраивания».

Переусложнение: бандл esbuild/rollup с вшитым fflate решает несуществующую проблему. Внешней зависимости fflate в JS-коде нет, есть только мёртвый script-тег. Нужен клинап, а не сборка ради вшивания отсутствующей зависимости.

Реальные жёсткие связи:

  • абсолютный путь импорта /upload-frontend/...;
  • захардкоженные подписи в <thead>.

2. Более простой вариант

Оставить ES-модули без сборщика. Добавить в конфиг basePath или import map вместо хардкода /upload-frontend/..., чтобы интегратор (drhider) мог использовать произвольный route.

Подписи и колонки вынести в labels/layout.

Отдельно удалить мёртвый fflate script-тег и неактивные maxFileBytes/maxSessionBytes, если они не используются picker-only конфигом.

3. Custom Element

Бандл не нужен. Custom Element пока не делать: для единственного известного интегратора (drhider) достаточно фабричной функции.

Custom Element имеет смысл добавить при появлении второго реального потребителя, которому нужен декларативный <file-picker>.

4. Риски

  • Главный риск — план основан на неверной предпосылке о глобальной fflate-зависимости.
  • Нужно проверить защиту от ZIP-бомб: parse_zip.js разбирает central directory и делает inflateRaw без очевидной проверки итогового размера entry.
  • Совместимость с managed Flask (drhider) реально блокируется абсолютным route /upload-frontend/...; это главная связь для исправления.

Краткий вывод

Начать с basePath/import map, конфигурируемых labels/layout и удаления мёртвого fflate/неактивных лимитов. Не добавлять пока сборщик и Custom Element.