Контекст и проблема¶

Контекст¶

LLM и технические специалисты хорошо производят структурированный текст, Markdown, код, требования, диаграммы и архитектурные обсуждения. Превращение этого материала в профессиональный deliverable по-прежнему часто требует ручного копирования в Word, Google Docs или другой редактор документов.

Диаграммы - типичная точка разрыва. Mermaid sequence или C4-набросок живёт рядом с исходником в Git, затем его приходится перерисовывать или экспортировать в слайд или Word. Опубликованный PDF расходится с исходником. Docs-as-code workflow ломается на последней миле.

Поэтому исходный продукт сосредоточился на портативном пути:

портативный Markdown
-> diagrams-as-code
-> профессиональный рендеринг
-> PDF

Markdown остаётся источником истины. Продукт опирается на портативные стандарты: GFM / Markdown, Mermaid, иконки архитектуры, совместимые с Iconify, YAML front matter, обычные ссылки на изображения/ассеты и позднее потенциально LaTeX. Содержимое должно оставаться совместимым с Git / GitHub, VS Code / Cursor, MkDocs, инструментами Mermaid и обычным Markdown-тулингом.

Проблема¶

Две проблемы наложились друг на друга.

1. Последняя миля публикации¶

У профессионалов уже есть исходный материал. Им не нужно ещё одно место, где печатать. Им нужен надёжный способ:

сохранить Markdown как рабочий формат;
рендерить диаграммы без проприетарного холста;
получить профессиональный PDF, совпадающий с исходником;
не дать одной сломанной диаграмме обрушить весь документ;
делать это без загрузки конфиденциальных черновиков в workspace, которым они не управляют.

Сырые заметки со встреч и транскрипты делают последнюю милю дороже. Эксперту всё равно приходится превращать сырой исходник в ADR, пакет требований, резюме или предложение. Эта работа повторяющаяся, её легко сделать чуть неправильно и трудно проверить.

2. Гравитация workspace¶

В ходе разработки продукта естественным расширением SaaS казалось проприетарное облачное хранилище документов: workspace, document management, более широкий редактор. Этот путь поставил бы DocCompile в конкуренцию за то, где живут документы - против Notion, Confluence, GitBook, Google Docs и собственного Git-репозитория пользователя.

Это неверная борьба для этого продукта. У технических пользователей уже есть дом для документов. Стоимость переключения высока. Workspace также тянет архитектуру к постоянному хранению документов, что конфликтует с позицией local-first по приватности.

Стратегический разворот¶

Решение:

Не владеть документом. Владеть трансформацией.

DocCompile не должен конкурировать за место, где живут документы. Он должен конкурировать за момент, когда сырой исходный материал становится корректным профессиональным артефактом.

Возможные persistence и выходные sinks остаются там, где пользователь уже работает: локальные файлы, портативные пакеты, Git-репозитории, CLI, загрузки и позднее API / интеграции.

Интересная инженерная задача - не вызов LLM. Это построение контролируемой системы компиляции вокруг него: контракты, свидетельства, валидация, ремонт, границы стоимости и измеримое качество.