pr 391

[skulidropek]

• Initial commit with task details
• docs: add Horizon integration analysis (Подумать об интеграции Horizon в проект #389)
• docs(horizon): add PoC results, screenshots, GPU requirement analysis

[skulidropek]

AI Session Backup

Commit: f03a505
Status: skipped
Message: No session directories found.

git status

On branch pr-391
nothing to commit, working tree clean

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: a81cccf7-3ece-4419-957c-8237e2179423

📥 Commits

Reviewing files that changed from the base of the PR and between 76f4fab and f03a505.

⛔ Files ignored due to path filters (3)

• docs/integrations/screenshots/horizon/browser-tab.png is excluded by !**/*.png
• docs/integrations/screenshots/horizon/canvas-terminals.png is excluded by !**/*.png
• docs/integrations/screenshots/horizon/command-palette.png is excluded by !**/*.png

📒 Files selected for processing (1)

• docs/integrations/horizon.md

📜 Recent review details

⏰ Context from checks skipped due to timeout of 900000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (10)

• GitHub Check: Types
• GitHub Check: E2E (Clone auto-open SSH)
• GitHub Check: E2E (Browser command)
• GitHub Check: Test
• GitHub Check: E2E (Clone cache)
• GitHub Check: E2E (Login context)
• GitHub Check: Lint
• GitHub Check: E2E (Runtime volumes + SSH)
• GitHub Check: E2E (OpenCode)
• GitHub Check: Final build (windows-latest)

🧰 Additional context used

📓 Path-based instructions (5)

**/{setup,install,config,*.sh,*.md}

📄 CodeRabbit inference engine (README.md)

Ensure default projects directory is ~/.docker-git

Files:

• docs/integrations/horizon.md

**/*

⚙️ CodeRabbit configuration file

**/*: Ты строгий ревьюер SPEC DRIVEN DEVELOPMENT.

Перед выводами изучи README.md, другие *.md файлы, linked issues,
PR description, PR comments/discussion и релевантную кодовую базу.

Сверь изменения с исходным ТЗ/спекой и обсуждением. Флагай любой уход
от спеки, недокументированное изменение поведения, отсутствие тестов
для заявленного поведения и security-риск. Если спека не видна,
попроси автора добавить ее в issue или PR description.

Проверь решение с точки зрения формальной верификации: какие инварианты,
предусловия и постусловия можно доказать математически, а где доказуемость
слабая. Оцени решение с точки зрения теории игр: устойчивы ли стимулы,
нет ли выгодного обхода правил, и какое решение было бы сильнее.

Files:

• docs/integrations/horizon.md

**

⚙️ CodeRabbit configuration file

**: РОЛЬ: Математик-программист, специализирующийся на формально верифицируемой функциональной архитектуре.

ЦЕЛЬ: Создавать математически доказуемые решения через функциональную парадигму с полным разделением чистых вычислений и контролируемых эффектов.

МОДЕЛЬ РАССУЖДЕНИЯ:

• Не выдавать “личные мнения”. Формировать вывод как результат симуляции профессионального обсуждения релевантных ролей
  (архитектор Effect/FP, ревьюер типов, страж CORE↔SHELL, тест-инженер).
• Если запрос сформулирован как “что думаешь”, отвечать в терминах аргументов ролей и выбирать решение
  по критериям инвариантов, типовой безопасности и тестируемости (если пользователь явно просит выбор — выбрать и обосновать).

ПРАВИЛО ПРОЦЕССА (НЕ ФОРМАТ ОТВЕТА):
В начале работы (внутренне) формулировать Deep Research вопрос:
"I am looking for code that does , is there existing code that can do this?"
Далее:

• если доступен проект/код — сперва искать и переиспользовать существующие паттерны (минимальный корректный diff),
• если проект недоступен — опираться на предоставленный контекст и явно фиксировать допущения,
• код писать только после формального понимания задачи (типы/инварианты → архитектура → код → тесты),
• источники указывать только если реально использован внешний материал; иначе SOURCE: n/a.

ИНСТРУМЕНТАЛЬНОЕ ПОВЕДЕНИЕ (ОБЯЗАТЕЛЬНО, НЕ ФОРМАТ ОТВЕТА):

• Агент всегда использует доступные инструменты среды (терминал, поиск по проекту, запуск тестов/скриптов, анализ сборки, web-ресёрч при необходимости)
  для ресёрча, проверки гипотез и выполнения действий. Приоритет: проверяемость, воспроизводимость, минимальный риск.
• Агент не предлагает “гайд” как замену действия. Если действие возможно выполнить инструментами — агент выполняет его сам,
  затем сообщает, что было сделано и как повторить.
• Любые инструкции (команды/процедуры) агент даёт только после собственной проверки на доступной среде.
  Если проверить невозможно — явно фиксирует ограничение и перечисляе...

Files:

• docs/integrations/horizon.md

docs/integrations/**

⚙️ CodeRabbit configuration file

docs/integrations/**: # Skiller Integration

Skiller is included as an isolated git submodule so docker-git can reuse the upstream desktop skills manager without mixing Electron dependencies into the docker-git Bun workspace.

Upstream

• Repository: https://github.com/beautyfree/skiller-desktop-skills-manager
• Path: third_party/skiller-desktop-skills-manager
• Pinned version: v0.2.14
• Pinned commit: 6ff6b9ca1ff2d78d3af7dac47b03ed1c315dab6b
• License: MIT, copyright 2025 Skiller Contributors

The submodule is intentionally outside packages/* and is not listed in the root workspace. This keeps the existing docker-git build, check, typecheck, and test scripts scoped to docker-git packages unless a Skiller-specific script is run.

Commands

Initialize the pinned submodule:

bun run skiller:init

Install Skiller dependencies inside the submodule:

bun run skiller:install

Run Skiller as its own Electron app:

bun run skiller:dev

Run Skiller checks:

bun run skiller:check

docker-git Web Launch

The docker-git web terminal header includes a Skiller button next to Open browser. In a project terminal the button calls POST /projects/by-key/:projectKey/terminal-sessions/:sessionId/skiller/open first, which launches the pinned submodule Electron app as a separate process, registers the terminal session filesystem scope, and writes launcher output to ~/.docker-git/logs/skiller.log. After that response succeeds, the browser opens the returned /api/ssh/session/:sessionId/skiller/app/ URL using the same terminal session id that is present in /ssh/session/:sessionId.

docker-git serves Skiller's built renderer from the submodule and proxies /api/ssh/session/:sessionId/skiller/trpc/* to the running Skiller tRPC backend, so the user sees the actual Skiller UI instead of an invisible background desktop process. The session id is part of the URL so a Skiller tab can be tied back to the terminal...

Files:

• docs/integrations/horizon.md

docs/**

⚙️ CodeRabbit configuration file

docs/**: # Процесс разработки (SDD: Spec-Driven Development)

Этот документ описывает канонический цикл разработки в docker-git: от issue до
проверяемого PR. Он отвечает на вопрос «как должна проходить разработка» из
issue #390 и связывает
шаги процесса с уже существующими инструментами репозитория.

Базовая философия задана в AGENTS.md и CLAUDE.md:

«Если это нельзя доказать — это нельзя доверить продакшену.»
Каждая функция — теорема, каждый тест — доказательство, каждый тип — утверждение.

SDD означает, что сначала формализуем (спецификация + инварианты), потом
программируем. Спецификация и её инварианты живут вместе с кодом и проверяются
автоматически.

Обзор цикла

issue ──▶ clone (среда) ──▶ /plan ──▶ уточнение ТЗ + Deep Research
  │                                          │
  │                                          ▼
  │                            Story + Prove (инварианты проверяемости)
  │                                          │
  │                            апрув плана ──▶ plan-to-git ──▶ PR (память)
  │                                          │
  │                                          ▼
  └──────────────── разработка (код + тесты + Playwright MCP)
                                             │
                                ToDos + subagents (декомпозиция)
                                             │
                                             ▼
                          CI/CD ──▶ сверка с инвариантами плана ──▶ merge

1. Issue — источник истины

Разработка всегда начинается с issue. Issue фиксирует намерение и становится
точкой привязки для плана, PR и итоговой проверки инвариантов.

2. Среда: клонирование с изоляцией

Для каждой issue поднимается отдельное Docker-окружение. Браузерная автоматизация
включается флагом --mcp-playwright (Playwright MCP + Chromium sidecar):

bun run docker-git clone https://...

Files:

• docs/integrations/horizon.md

🧠 Learnings (1)

📓 Common learnings

Learnt from: CR
Repo: ProverCoderAI/docker-git

Timestamp: 2026-06-14T07:01:17.068Z
Learning: Position Horizon as a complementary external desktop client rather than embedding it into docker-git, and document the SSH-based workflow for adding docker-git project containers as Horizon panels

Learnt from: CR
Repo: ProverCoderAI/docker-git

Timestamp: 2026-06-14T07:01:17.068Z
Learning: Do not embed or vendor Horizon into docker-git due to its desktop-only design, lack of API surface, and incompatibility with the web-served, container-bridged session model

Learnt from: CR
Repo: ProverCoderAI/docker-git

Timestamp: 2026-06-14T07:01:17.068Z
Learning: When integrating external tools like Horizon, ensure they expose either an HTTP/tRPC/WebSocket control API or are embeddable as an Electron app with a proxiable backend before committing to integration

Learnt from: CR
Repo: ProverCoderAI/docker-git

Timestamp: 2026-06-14T07:01:17.068Z
Learning: Re-evaluate integrating Horizon only if upstream ships a headless mode, web/remote rendering surface, or an externally-controllable session API that supports attaching to pre-owned PTYs

🪛 LanguageTool

docs/integrations/horizon.md

[style] ~37-~37: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... launchers for the same agent CLIs. - Both already overlap on "GPU". docker-git ...

(ENGLISH_WORD_REPEAT_BEGINNING_RULE)

🪛 markdownlint-cli2 (0.22.1)

docs/integrations/horizon.md

[warning] 128-128: Fenced code blocks should be surrounded by blank lines

(MD031, blanks-around-fences)

---

[warning] 128-128: Fenced code blocks should have a language specified

(MD040, fenced-code-language)

🔇 Additional comments (5)

docs/integrations/horizon.md (5)

35-39: 💤 Low value

Трёхкратное повторение "Both" в начале фраз нарушает стиль.

Строки 36–37 содержат три последовательных предложения, начинающихся с "Both":

- **Both are terminal-session managers.** ...
- **Both target AI-agent workflows.** ...
- **Both already overlap on "GPU".** ...

Переформулируйте хотя бы одно из них, чтобы избежать монотонности.

Source: Linters/SAST tools

---

41-50: ⚖️ Poor tradeoff

Рассмотрите формализацию ограничений как математических инвариантов.

Раздел "Hard Constraints" описывает препятствия к интеграции в естественном языке, что ясно, но согласно рекомендациям SDD в CLAUDE.md и AGENTS.md, решающие документы должны включать формально верифицируемые инварианты.

Например, вместо "Horizon is desktop-only" можно выразить:

Invariant-1: ∀ component: (renders_via_wgpu(component) ∧ ¬has_web_build(component)) 
             → ¬embeddable_to_browser(component) → ¬viable_direct_web_integration(component)

Это укрепит доказательственную базу рекомендации и сделает условия для пересмотра (Watch List) математически чёткими.

Source: Coding guidelines

---

56-62: ⚡ Quick win

Option A неполна: рекомендуется SSH-workflow, но конкретные шаги отсутствуют.

Раздел Option A рекомендует "документировать SSH-based workflow", но не предоставляет ни одного примера или шага для пользователя. README.md упоминает SSH endpoints (/ssh/session/:sessionId), но текущий документ оставляет читателя без:

1. Как инжектировать SSH-ключи в контейнеры docker-git
2. Как добавить их в Horizon SSH config
3. Какие конкретные агентские сценарии становятся доступны (напр., Claude Code из Horizon → SSH в контейнер → codex)

Рекомендация: либо добавить минимальные примеры SSH-workflow сюда, либо явно обозначить Option A как "requires follow-up issue для документирования workflow".

---

128-131: 💤 Low value

Оформление кода-блока не соответствует markdown-стандартам: отсутствует язык и пробелы вокруг.

Строка 128 содержит fence без указания языка и без пустых строк до/после:

должно быть:

```bash
Horizon (CPU render ~5 FPS) → Xvfb → x11vnc → websockify → Cloudflare → browser

Кроме того, добавьте пустую строку перед fence и после.

<!-- cr-comment:v1:b9a7db3848dbff9aba12628b -->

_Source: Linters/SAST tools_

---

`77-83`: _⚖️ Poor tradeoff_

**Рекомендация ясна, но согласно SDD следует явно указать, что доказывает корректность Option A.**

Согласно [`PROCESS.md`](../process.md) (SDD: Spec-Driven Development), даже решающие документы должны включать "Prove" — прямое выражение того, какое свидетельство подтверждает рекомендацию.

Рекомендация предлагает Option A (SSH-workflow), но не указывает:
- Какие условия *доказывают*, что Option A достаточна
- Какие условия *опровергают* её (уже частично в Watch List)

Пример улучшения:
```markdown
## Proof that Option A is sound

- Claim: SSH-based external workflow satisfies the immediate user need
- Evidence: Horizon already discovers SSH hosts; docker-git already exports per-session SSH endpoints (/ssh/session/:sessionId)
- Falsification conditions (from Watch List): If Horizon adds headless/web/API mode *AND* upstream receives user demand for tight docker-git integration, revisit Option C

Source: Coding guidelines

---

📝 Walkthrough

Summary by CodeRabbit

Примечания к выпуску

• Документация
  • Добавлена новая документация с исследованием интеграции Horizon. Документ описывает анализ совместимости, ограничения подходов и рекомендации по использованию Horizon как дополняющего компонента через SSH-workflow.

Walkthrough

Добавлен новый документ docs/integrations/horizon.md, фиксирующий исследование интеграции GPU-терминальной доски Horizon с docker-git: описание ограничений, три варианта интеграции, proof-of-concept запуска в контейнере и watch list условий для пересмотра решения.

Changes

Документация по интеграции Horizon

Layer / File(s)	Summary
Оценка, ограничения и рекомендации docs/integrations/horizon.md	Зафиксированы характеристики Horizon (Rust/egui/wgpu/alacritty_terminal, desktop-only), перечислены жёсткие ограничения прямой интеграции (отсутствие headless/remote-режима, несовместимость PTY-модели, расхождение стека), варианты A–C и итоговая рекомендация (принять Option A, вести трек Option B).
PoC и watch list docs/integrations/horizon.md	Описан proof-of-concept запуска Horizon v0.2.6 в контейнере через Xvfb→VNC→websockify→noVNC/Cloudflare Tunnel, зафиксированы измерения производительности (2–7 FPS при software rendering) и watch list условий (headless/web/remote, control API, поддержка внешних PTY) для повторной оценки.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

🚥 Pre-merge checks | ✅ 5 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description consists of bullet points listing commit messages but lacks the required template structure with Source TZ/Issues, Requirements Alignment, and Verification sections.	Fill in the required template sections: specify issue number, align with requirements, clarify scope and security implications, and document verification steps.
Title check	❓ Inconclusive	The title 'pr 391' is vague and generic, providing no meaningful information about the changeset's content or purpose.	Replace with a descriptive title that summarizes the main change, such as 'docs: add Horizon GPU terminal integration analysis' or similar.

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Requirements Alignment	✅ Passed	Documentation PR adds analysis of Horizon integration (Issue #389) as a decision document with three evaluated options, PoC results with GPU requirements (2-7 FPS vs 60 FPS), screenshots, and clear...
Security Regression	✅ Passed	PR adds only documentation (markdown) and screenshots (PNG images) with no security-sensitive content, code changes, or configuration modifications that could introduce security regressions.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch pr-391

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[skulidropek]

#391

[skulidropek]

#396 для GPU есть вот такая задача. ДУмаю надо добить