Обновить документацию и интеграционную модель хоста под runtime hostScript

[flancer64]

Контекст

В библиотечном контексте github-flows уже введена модель двух подготовительных шагов runtime:

• hostScript — host-side pre-launch step;
• setupScript — container-side startup step.

В github-flows-app operational-документация и текущая integration story пока в основном описывают старую схему:

• профиль использует только setupScript;
• GitHub token монтируется как статический secret file;
• host-side pre-launch preparation как отдельный шаг явно не описан.

Нужно привести хост-приложение в соответствие с новой runtime-моделью хотя бы на уровне документации и, при необходимости, продукта.

Задача

Обновить github-flows-app так, чтобы repository-level docs и product-level integration story были согласованы с моделью hostScript.

Если для этого нужны изменения в коде приложения или интеграционной логике, их нужно определить и зафиксировать. Если достаточно только product/docs updates, это нужно явно показать в результате.

Что нужно сделать

1. Обновить host-facing documentation

Проверить и обновить как минимум:

• docs/runtime-dependency.md
• docs/overview.md
• docs/workspace.md
• docs/setup/ubuntu/auth.md
• docs/setup/ubuntu/docker.md
• другие docs/setup/*, если они описывают profile execution, secrets или container startup

Нужно:

• различить hostScript и setupScript;
• показать, как хост участвует в host-side pre-launch preparation;
• обновить profile examples там, где они сейчас показывают только setupScript;
• описать сценарий с execution-scoped token/file, подготавливаемым до запуска контейнера, если этот сценарий признан целевым.

2. Проверить application/runtime boundary

Нужно явно проверить, не конфликтуют ли новые формулировки с текущей boundary-моделью приложения, где runtime library владеет profile selection и isolated launch semantics.

Если модель остаётся такой же, это нужно отразить в docs:

• host supplies environment and infrastructure;
• runtime owns profile semantics;
• host-side hostScript support не превращает приложение в workflow engine.

3. Оценить необходимость product/code changes

Нужно определить, поддерживает ли текущее приложение новую модель только документально или для неё нужны реальные изменения в коде/интеграции.

Если нужны изменения, зафиксировать их явно:

• где именно в приложении или его integration layer должен появиться host-side pre-launch step;
• какие конфигурационные данные нужны для этого шага;
• как должны обрабатываться execution-scoped access artifacts;
• какие security constraints обязательны.

Если кодовые изменения выходят за рамки этой задачи, это нужно перечислить как follow-up scope, а не оставлять неявным.

4. Проверить security и secret handling

Особенно важно проверить, что обновлённая документация не оставляет двусмысленности в отношении:

• long-lived host secrets;
• execution-scoped generated tokens/files;
• workspace visibility;
• cleanup temporary artifacts после run.

Ограничения

• Не менять библиотечный контекст github-flows в этом issue.
• Если задача затрагивает код, изменения должны относиться только к github-flows-app.
• Если код менять не требуется, это должно быть явно подтверждено по итогам проверки.

Критерии приёмки

Задача считается выполненной, если:

• host docs в github-flows-app больше не описывают setupScript как единственный preparation step;
• примеры профилей и auth/setup docs согласованы с моделью hostScript;
• application/runtime boundary изложен без противоречий;
• отдельно зафиксировано, нужны ли product/code changes для реальной поддержки новой модели.

Что нужно указать в итоговом отчёте

В комментарии или PR summary нужно указать:

• какие документы были обновлены;
• какие продуктовые или кодовые изменения потребовались или не потребовались;
• как теперь в github-flows-app описан сценарий host-side pre-launch preparation;
• какие follow-up задачи остаются после этого изменения.

[adsm-agentess]

Issue belongs to github-flows-app and requests repository-scoped changes to host-facing documentation and, if needed, the application integration layer.

The requested work is clear enough to route without further clarification:

• the affected documentation areas are named explicitly;
• the expected host/runtime boundary check is stated explicitly;
• the issue asks for an implementation-side determination when documentation alone is insufficient.

Admission decision: adsm:accepted.

Implementation should keep the mounted context authoritative, especially the documented boundary that the host provides environment and infrastructure while runtime semantics remain owned by @teqfw/github-flows.

[adsm-agentess]

Verification diagnostic

State: adsm:needs-human

Reason:

Finalization cannot proceed safely because the latest Pull Request validation result marked adsm:verified for head 8b150bf563ee47fe6cad97ff6d0129938edcb2b8, but Pull Request #5 was merged from head 5f870cd7884716febcae8e0c58ddf15380cecdf5 after an additional merge-from-main commit. The required verified-head match is missing, so closing issue #4 would finalize work without current verification evidence.

Next step:

Human review is required before the verification workflow can continue.