Deal/docs/superpowers/specs/2026-09-11-source-attachments-вопросы.md

Открытые вопросы: вложения источников (media → Storage) и просмотр исходника

Дата: 2026-09-11. Статус: часть требует живого внешнего контура (Telegram API) для проверки.

1. Что уже готово (не требует решений)

• Единый контракт источника несёт вложения: SourceContent.Data: IReadOnlyList<DataRef> — ссылки на объекты Storage-сервиса (DataRef.Id/Ref/Kind/MimeType/...).
• Контракт входящего потока (src/contracts/sources.proto, PushSource) передаёт DataRefProto/ContactRefProto — источник может прислать вложения сразу со ссылками.
• Storage-сервис (src/storage-service/Deal.Storage, storage.proto) умеет Upload/Download/Stat/Delete, сам определяет kind/mimeType/размеры (контент-снифинг), бэкенд — MinIO.
• Ядро хранит SourceContent карточки (в т.ч. Data) и отдаёт его в CardDto.content и через GET /api/cards/{id}/source (extension-point ISourceContentProvider + SourceContentResolver).
• Фронт рендерит вложения: SourceContentView.vue (image/video/audio/document/archive по kind), ссылки и контакты — списками.

2. Проблемная часть (требует живого Telegram)

Извлечение и выгрузка медиа из Telegram не проверяемы офлайн:

1. Медиа-сообщения сейчас отбрасываются. TlMessageMapper.ToMessage (src/telegram-service/Deal.Telegram/Telegram/TlMessageMapper.cs) принимает только Message с непустым message (текстом). Посты с одним вложением и подписью (media + caption) не попадают в поток вообще. Нужно: определять Message.media, читать caption, тип/размеры/длительность.
2. Скачивание и выгрузка. Требуется client.DownloadMedia(...) (WTelegram) → поток → StorageService.Upload(meta + data) → DataRefProto. В telegram-сервисе нет gRPC-клиента Storage и соответствующей конфигурации в compose (endpoint/токен). Проверить можно только с реальным Telegram-аккаунтом и живым MinIO.
3. Подпись без текста. Даже если вложение извлечено, в посте может не быть текста: нужен ли такой пост «карточкой» (сейчас PipelineIngestService пропускает записи без Content.Text)? Предлагается принимать запись, если есть текст или вложения/ссылки/контакты, а классификацию медиа-онли строить по подписи (caption) и метаданным. Требуется подтверждение продуктовой логики.
4. Просмотр исходника из другого контура. «Открыть исходник» для remote-источников (Telegram — это лишь один из них) требует провайдера ISourceContentProvider, который ходит по gRPC к сервису-владельцу источника (новый RPC, например ReadSource(dialogId, msgId)), возвращая текст/медиа. Это тоже живой Telegram.

3. Предлагаемый план (после подтверждения)

1. TelegramMessage расширить моделью TelegramAttachment (caption, fileName, mimeType, size, width, height, durationSec, Task<Stream> Open(cancellationToken)), заполнять в TlMessageMapper из Message.media/Document/Photo.
2. В telegram-сервисе добавить StorageClient (gRPC, Deal.Grpc.Storage) + SourceAttachmentUploader: загрузка каждого вложения → DataRefProto.
3. DialogProtoMapper.ToSourceRequest(message, dataRefs) — прокинуть content.data и caption.
4. PipelineIngestService: принимать запись при непустом тексте или непустых Data/Links/Contacts (нужно продуктовое решение по п.2.3).
5. ISourceContentProvider для kind="telegram" — gRPC-провайдер к telegram-сервису (RPC ReadSource).
6. Настройки: endpoint/токен Storage в deploy/compose.dev.yml/compose.prod.yml для telegram-сервиса.

4. Что нужно от владельца

• А) Делать ли медиа-сообщения без текста карточками (по подписи/метаданным), или пропускать?
• Б) Для проверки вложений нужны живые Telegram api_id/api_hash и работающий MinIO — будет ли прогон на вашей стороне, или реализуем «слепо» с юнит-тестами на фейковой сессии и фейковом Storage?
• В) Нужен ли remote-просмотр исходника (ReadSource) в этом объёме, или достаточно того, что содержимое хранится в карточке?

Пока эти пункты не закрыты, они вынесены в backlog.md (TD-STORE-ATTACH, TD-SOURCE-PROVIDER), а generic-часть (контракт, Storage-сервис, хранение, API, рендер) реализована.