IPFS: зависимости и активное содержимое
Проверяемый выпуск зависит не только от текста. Генератор Markdown, темы, шрифты и скрипты могут изменить готовые байты или поведение. В уроке составим профиль зависимостей и отделим воспроизводимость сборки от безопасности исполнения. Это последний технический шаг перед цельным досье публикации.
Зависимости не устанавливаются, сайт не собирается и учебные программы не запускаются. Мы описываем исходники и необходимые фиксации для будущего разрешённого этапа.
От Markdown к HTML
Один исходный Markdown может дать разные HTML-байты при разных версиях генератора, плагинов или настроек. Изменяется структура заголовков, оформление кода, порядок атрибутов либо встроенная дата. Значит, идентичность выпуска определяется готовыми байтами, а воспроизводимость требует достаточного профиля подготовки.
Сохраняем версию инструмента, конфигурацию шаблонов и зависимостей. Lockfile полезен для закрепления пакетов, но не является самостоятельным обещанием воспроизводимости всей среды. Внешние ресурсы, платформенные различия и нестабильные входные данные также могут влиять.
Если генератор вставляет текущее время, повторная подготовка получит другой файл. Для выпуска дата устанавливается редакционно либо исключается из неизменного содержимого. Служебное время выполнения хранится в отчёте, не обязательно внутри каждой страницы.
Локальные и внешние ресурсы
Для собственного статического набора можно включить CSS, шрифты и изображения. Тогда их байты входят в объявленный состав. Внешняя ссылка на CDN сохраняет зависимость от оператора и будущего ответа. Даже фиксированный URL не всегда является неизменным объектом.
Манифест объявляет такие зависимости явно. Если они нужны для полноценного чтения, архив должен учитывать их доступность или иметь допустимый резервный вариант. Пользователь без сети не обязан получить всё только потому, что HTML сохранён.
Клиентский пакет может обращаться к API и изменять отображаемые данные. Проверка его исходных байтов не делает внешний ответ неизменным. Для исторического учебного примера можно сохранить отдельную фикстуру или ясно отметить динамическую часть.
Активное содержание
Корректный CID подтверждает конкретный JavaScript, но не его безопасность. Если код имеет доступ к чувствительным origin или токенам, неизменность только фиксирует эту возможность. Поэтому выпуск проходит редакционный разбор допустимых функций и зависимостей.
В учебном архиве пример кода лучше показывать как текст, пока пользователь сознательно не выбирает отдельное исполнение. Страница урока не должна автоматически запускать кошелёк, обращаться к платёжному API или создавать сетевую транзакцию ради демонстрации.
Если интерактивная демонстрация нужна, её профиль и полномочия задаются отдельно. Нельзя включить новый пакет из внешнего URL и сохранить прежнее утверждение о полном составе выпуска. Такой шаг меняет договор зависимостей.
Схема профиля
{
"releaseId": "course-17-edition-1",
"sourceRevision": "TO_BE_FIXED",
"buildToolVersion": "TO_BE_FIXED",
"lockfile": "TO_BE_ARCHIVED",
"templateProfile": "library-static-v1",
"externalResources": [],
"executionPolicy": "static-reading"
}Метки показывают ещё не выполненные фиксации. Мы не подставляем вымышленный commit или номер установленного пакета. Профиль импорта UnixFS сохранён отдельным документом, потому что сборка файлов и построение блоков являются разными преобразованиями.
Определение static-reading означает выбранную роль текущего примера. Оно не является техническим sandbox само по себе. Реальные браузерные заголовки, origin и содержимое должны обеспечивать соответствующий результат при будущей реализации.
Изменение зависимости
Если обновлена тема, а уроки не изменились, готовый выпуск всё равно может получить новые байты и корень. Это новая редакция представления. В журнале указываем причину, чтобы читатель не пытался найти несуществующую правку текста.
Если исправлена уязвимость скрипта, прежний объект сохраняется у обладателей старой копии. Текущая рекомендация переключается, публикуется пояснение, а архивная политика учитывает риск. Нельзя обещать глобальное обновление всех CID после изменения одного исходного файла.
Смена импортёра также влияет на представление. Нужно различать исходники, готовые файлы, блоковый профиль и способ выдачи. У каждого слоя своя версия и контрольные значения. Такое разложение упрощает диагностику расхождения корня.
Архивирование профиля
Досье хранит достаточные исходники и конфигурации вместе с неизменным выпуском. Для секретных параметров используются обозначения и отдельная процедура доступа. Токен pinning или приватный ключ не становится частью архива сборки.
При зависимостях из открытых репозиториев сохраняем конкретные идентичности, когда они выбраны. Ссылка на main полезна для чтения текущей документации, но не фиксирует историческую реализацию. В этой работе новые пакеты не установлены, поэтому точный локальный профиль исполнения остаётся будущим этапом.
Зависимость изменилась без правки Markdown
В исходном уроке ни одна строка не менялась, но обновился генератор HTML. Он по-другому расставил атрибуты, добавил новую оболочку блока кода или изменил вставленный скрипт. Готовые байты теперь другие; манифест и импортируемое представление также могут измениться. Для библиотеки это новый результат подготовки, даже если редактор считает текст прежним. Поэтому исходная редакция и готовый опубликованный выпуск имеют связанные, но отдельные идентичности.
Чтобы объяснить расхождение, сохраняют версии инструментов, lockfile, конфигурацию преобразования и определённые входы. Текущее время, абсолютный путь компьютера и случайный порядок обхода файлов не должны незаметно попасть в выход, если они не являются намеренной частью формата. При необходимости даты выпуска её устанавливают осознанно один раз. Воспроизводимость требует договорённого поведения, а не только существования репозитория Markdown.
Активная внешняя зависимость создаёт другой риск. HTML может сохранять прежний CID, а внешний скрипт по изменяемому URL — получить новое содержимое. Визуальный или функциональный результат тогда перестаёт быть полностью определённым архивом HTML. Для статического учебного набора полезно включать требуемые файлы либо описывать внешнюю зависимость и ограничения её воспроизведения. Контрольные механизмы веб-платформы применяются по подходящему сценарию, но не заменяют опись всех материалов автоматически.
Наконец, корректно объявленный скрипт может быть нежелательным для исполнения в личном кабинете. Проверка содержания отвечает на вопрос «это именно объявленные байты», а политика активного контента — на вопрос «какие действия им разрешены». Эти решения не смешиваются. Для нашего будущего выпуска источник, готовые файлы, зависимости и размещение активных примеров сохраняются как разные части досье. Так редакция способна подготовить новую версию осознанно и расследовать изменение результата без поиска воображаемой ошибки в самом CID.
Критерий качества
Будущая независимая подготовка должна получить согласованные файлы по профилю, а импорт — согласованный корень. Если один этап расходится, отчёт указывает слой и причину. При этом безопасность активного кода оценивается отдельно от совпадения байтов.
Первичные требования представлены в документации Helia, UnixFS и рекомендациях шлюза. После урока выпуск является управляемым набором исходников, преобразований и готовых объектов. Последняя страница соединит их в полный маршрут библиотеки.