[2026-10-15] eagle: personal/projects/balda/execution-broker.md personal/projects/balda/setup.md work/projects/vscode-migration/tech-design-xcode-build-server.md work/projects/vscode-migration/xcode-build-server.md
This commit is contained in:
Alexey Martemyanov committed
1 parent
a364f53bbb
commit
703faeb9b4
4 files changed
+11
-12
No files matched your search
@@ -37,13 +37,14 @@ Generic webhook в текущем Balda запускает изолирован
|
||||
|
||||
Telegram approval bot получает вопрос только для явно выбранных сессий; иначе вопрос принадлежит исходной беседе. В текущем контуре `telegram_approvals.timeout_seconds=1800`: окно ответа — 30 минут. `min_run_ttl_seconds=3600` требует для новых запусков выбранных сессий общий TTL не меньше часа; более короткий запрос получает `approval_window_too_short` до admission. TTL включает очередь, планирование, ожидание ответа и исполнение; исходный deadline остаётся жёсткой границей и при появлении вопроса не продлевается. Сообщение сначала отправляется без кнопок, message ID сохраняется в state, затем публикуются controls. Рестарт завершает прерванную публикацию или renewal без повторного callback. Устаревшая копия очищается при callback до сохранения update cursor. Ответ владельца передаётся через bound `execution_respond`; модель не подменяет его. `execution_retry` сохраняет точный task, Story, revision, executor и действительное одобрение; новый scope требует нового решения. Для environment checkpoint используется `execution_reconfigure`; обычный retry таких runs запрещён.
|
||||
|
||||
Managed lifecycle и native wait restart проверены на актуальном upstream. Реальный conversational run с моделью и доставкой в исходную беседу остаётся незавершённым gate. Авторизация Codex работает; отдельный ephemeral запрос подтверждает генерацию модели, но не доставку результата в Mattermost. Существующие сессии принимают новый capability snapshot через обычный `/reset`; обновление само их не сбрасывает.
|
||||
Managed lifecycle и native wait restart проверены на развёрнутом Balda. Реальный conversational smoke прошёл: модель использовала исходные Story/Task, подтвердила observer/recovery waits, дождалась фактического Telegram-ответа владельца и получила `succeeded`, `cleanup=done`. Все шесть артефактов скачаны с проверкой SHA256; единственный итоговый ответ подтверждён через Mattermost API в исходной беседе, оставшиеся waits отменены. Приватные доказательства: `state/balda-channel-context-20261015/`. Отдельный outage/restart в ходе реальной модельной беседы ещё не проверен. Существующие сессии принимают новый capability snapshot через обычный `/reset`; обновление само их не сбрасывает.
|
||||
|
||||
## Проверки
|
||||
|
||||
- Полные race/vet Broker на macOS ARM64 и Linux ARM64; Callee adapter, source/binary govulncheck — 0 reachable vulnerabilities, secret scan — без находок.
|
||||
- Развёрнутый Balda source `046cc9c9`: полный race, lint и architecture gate; SQLite/PostgreSQL migration regressions, оба migration validators, managed plugin lifecycle и native wait restart. Существующий Codex thread продолжился с исправленным Mattermost-контекстом.
|
||||
- Production service acceptance: настоящий Callee Human → restart Broker/Prism → resume → шесть артефактов с проверенными SHA256 и provenance Git cache → `succeeded`, `cleanup=done`; Task и Story закрыты.
|
||||
- Реальная Balda-сессия: исправленный Mattermost-контекст → durable waits → Broker smoke → фактический Telegram approval → шесть скачанных артефактов с проверенными SHA256 → `cleanup=done` → итог в исходной Mattermost-беседе. Доставка и отсутствие дубликата подтверждены readonly API.
|
||||
- Настоящая macOS VM: verified Go archive через scoped tunnel, `tooling.json`, один XCTest без ошибок и сохранённый xcresult; восемь артефактов с проверенными SHA256, включая `repository.json`, VM cleanup подтверждён.
|
||||
- Реальные Make/C, Python, Node и JVM проекты на macOS и Linux; Docker builder/Runner/Callee cache hit и изменение Node SDK; durable смена окружения с двумя рестартами и одним выполнением внешнего действия; отдельная проверка реального `go run` при `/tmp noexec`.
|
||||
- Artifact input transfer/restart/cleanup и установка из Linux ARM64 release archive без исходников и Go прошли.
|
||||
@@ -55,7 +56,7 @@ Managed lifecycle и native wait restart проверены на актуаль
|
||||
|
||||
| Область | Что остаётся |
|
||||
| --- | --- |
|
||||
| Balda boundary | Подтвердить conversational run и outage/restart с видимым результатом в исходной беседе |
|
||||
| Balda boundary | Conversational Human → artifacts → cleanup → исходная беседа подтверждён; остаётся отдельный outage/restart внутри реальной модельной беседы |
|
||||
| Платформы | Native AMD64 acceptance; штатная Linux AMD64 эмуляция остаётся непринятой, отдельный QEMU не заменяет native gate |
|
||||
| Recovery | Потеря хоста/Keychain не проверена; подтверждён только drained backup/restore на том же хосте |
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ Eagle работает на том же Mac в `balda-mm-eagle`; Compose, config
|
||||
|
||||
В этой версии generic webhooks выполняют изолированные задания. Они не продолжают исходную сессию. Старые `routes.*.path`, `envelope.target`, `key_from_body`, `mode` и `fallback_to` удалены из конфигурации; listener задаётся через `balda.http`. Сейчас он слушает loopback `127.0.0.1:8095`.
|
||||
|
||||
Плагин rc32 использует `balda.state` и штатный `balda.session.wait`: наблюдатель вооружается до Start/retry и возвращается в исходную сессию. Managed lifecycle и restart-контракт проверены; conversational acceptance с реальной моделью ещё открыт. Старые callbacks Broker на `:8090` приостановлены, недоставленные cursors сохранены. Native wait acceptance не является подтверждением доставки сообщения провайдером.
|
||||
Плагин rc32 использует `balda.state` и штатный `balda.session.wait`: наблюдатель вооружается до Start/retry и возвращается в исходную сессию. Managed lifecycle и restart-контракт проверены. Реальный conversational smoke с моделью, фактическим Telegram Human ответом, шестью проверенными артефактами, `cleanup=done` и единственным итоговым сообщением в исходной Mattermost-беседе прошёл; Story/Task закрыты и waits отменены. Отдельный outage/restart внутри реальной модельной беседы ещё не проверен. Старые callbacks Broker на `:8090` приостановлены, недоставленные cursors сохранены. Native wait acceptance не является подтверждением доставки сообщения провайдером.
|
||||
|
||||
Оба инстанса имеют также одинаковые пять глобальных Codex skills и одинаковую Codex tool policy; различий не найдено. Обновление плагина выполнено штатной переустановкой из нового operator source с сохранением `plugin-data/execution-broker`, старых revisions/catalog snapshots и содержимого прежнего marketplace. Существующие сессии не сбрасывались.
|
||||
|
||||
|
||||
@@ -31,11 +31,10 @@ Add an opt-in VS Code setup to the repository: a workspace file and a few script
|
||||
|
||||
**What a developer gets**
|
||||
- Completion, jump-to-definition, references and live errors for app, test and package code, on macOS or iOS. One platform is chosen per worktree and can be switched.
|
||||
- Tasks to build any scheme and run unit tests; errors and failed tests show in the Problems panel.
|
||||
- Tasks to build any scheme and run unit tests; errors and failed tests show in the Problems panel. launch.json/tasks.json aren‘t committed.
|
||||
- Debugging with breakpoints:
|
||||
- the macOS app, launched from the editor;
|
||||
- the iOS app on a simulator, by running the app and then attaching.
|
||||
- **Shared with Xcode.** Builds and the index live in the worktree's usual Xcode DerivedData folder. Whatever Xcode built or indexed is ready in VS Code, and the other way round.
|
||||
- the iOS app on a simulator: one launch builds, installs and starts the app, and attaches the debugger.
|
||||
- Optional background indexing of worktrees while no editor is open.
|
||||
|
||||
**How it works**
|
||||
@@ -43,13 +42,13 @@ Add an opt-in VS Code setup to the repository: a workspace file and a few script
|
||||
- Builds and tests go through `xcodebuild` with the same settings Xcode uses.
|
||||
- The build server is installed locally by a script that builds it from source at a pinned commit of our fork (see below).
|
||||
|
||||
**The build server needed fixes.** On our workspace it gave no results in test files, broke on the DMG/App Store variants and took hours to index. Four small changes fix this (see Appendix), and a worktree now indexes in about 5 minutes. They're general improvements, so we'll offer them upstream. We don't depend on upstream accepting them: we fork the build server into a DuckDuckGo repository, keep our changes there and pull upstream changes manually after reviewing them.
|
||||
**The build server needed fixes.** On our workspace it gave no results in test files, broke on the DMG/App Store variants and took hours to index. Four small changes fix this (see Appendix), and a worktree now indexes in about 5 minutes. They're general improvements, so we'll open a PR for the upstream. We don't depend on upstream accepting them: we fork the build server into a DuckDuckGo repository, keep our changes there and pull upstream changes manually after reviewing them.
|
||||
|
||||
**Steps**
|
||||
1. Fork sourcekit-xcode-bsp into a DuckDuckGo repository with our changes.
|
||||
2. Land the setup in the repository, plus a short README.
|
||||
3. Offer the changes upstream as PRs.
|
||||
4. A few early adopters on macOS and iOS try it for a couple of weeks; then we decide whether to announce it more widely.
|
||||
4. Document the setup in the [Apple Documentation](https://app.asana.com/1/137249556945/project/1202500774821704/list/1203980668089483) project and in the onboarding docs.
|
||||
|
||||
### Pros
|
||||
|
||||
@@ -57,14 +56,13 @@ Add an opt-in VS Code setup to the repository: a workspace file and a few script
|
||||
- **Same build as Xcode.** swift-build reads the projects, so per-configuration settings and dependencies, resources, macros and plugins behave like in Xcode.
|
||||
- **Nothing to maintain in the app code.** No lint rules or checks to keep the setup working.
|
||||
- **Both platforms**, so it doesn't add a gap between macOS and iOS.
|
||||
- **No cost for Xcode users**, and those who use both tools share one build and one index.
|
||||
- **No cost for Xcode users.** Builds and the index live in the worktree's usual Xcode DerivedData folder, so those who use both tools share one build and one index: whatever Xcode built or indexed is ready in VS Code, and the other way round.
|
||||
|
||||
### Cons
|
||||
|
||||
- **A young third-party tool** (version 0.1.0, "early-stage" by its authors) that we fork and maintain ourselves.
|
||||
- **Some rough edges:**
|
||||
- one platform per worktree at a time;
|
||||
- iOS debugging is two steps (run, then attach);
|
||||
- the first index of a new worktree takes ~5 minutes.
|
||||
- **Someone has to own it.** I will; the setup is small (a workspace file and ~6 scripts), and it's documented.
|
||||
- **Maintenance as Xcode, swift-build and the build server move.** Xcode updates or upstream changes can need updates to the fork or the setup. Mitigation: the people who use the setup do the updates, mostly with AI agents (the setup is small and has a README and tests). Xcode-only users and CI never depend on it.
|
||||
|
||||
@@ -23,7 +23,7 @@ An alternative to the [[projects/vscode-migration/tech-design-spm-browser-packag
|
||||
- `xcode_derived_data.py` — Xcode's DerivedData folder for the worktree (MD5 → 28 letters; honors a custom location).
|
||||
- `sourcekit-xcode-bsp.sh` — `argv` of buildServer.json. Editor's server stops a running background indexer and waits for it; the indexer's server refuses to start next to an editor's. Pid files in `.build/bsp/`, checked to be sourcekit processes.
|
||||
- `xcodebuild.sh <build|test> <scheme> [destination]` — Debug into Xcode's DerivedData with Xcode's settings (no `-derivedDataPath`: passing it changes build parameters and makes Xcode and VS Code rebuild after each other). `DDG_WORKTREE_CACHE=1`: `.build/xcodebuild` + shared CAS with `/^wt` `/^dd` maps. `.build/products` → products folder. xcbeautify + raw `path:line: error:` lines for failed tests.
|
||||
- `simulator.sh [--build-only|--no-build] [device]` — builds iOS Browser for a concrete simulator, installs, `simctl launch --wait-for-debugger`, pid to `.build/simulator.pid`.
|
||||
- `simulator.sh [--build-only|--no-build] [device]` — builds iOS Browser for a concrete simulator, installs, `simctl launch --wait-for-debugger`, writes `process attach --pid N` to `.build/simulator-attach.lldb`.
|
||||
- `index-in-background.py [--all] [--if-idle]` — headless indexing; `background-indexing.sh install` = launchd agent every 30 min.
|
||||
- `install-build-server.sh` + `sourcekit-xcode-bsp.patch` + `sourcekit-xcode-bsp.Package.resolved` — reproducible build of the patched BSP.
|
||||
|
||||
@@ -38,7 +38,7 @@ An alternative to the [[projects/vscode-migration/tech-design-spm-browser-packag
|
||||
7. **CAS doesn't help the language server** (prepare-for-index doesn't cache; cold vs warm the same).
|
||||
8. **Index shared with Xcode works:** with Xcode's DerivedData layout (index store = `Index.noindex/DataStore`, `INDEX_REGULAR_BUILD_*` = `Build/…`), units written by an xcodebuild build count as up to date: after building `macOS Browser`, indexing skipped all app files (2,150 files left vs 3,972). BSP prepares in `Index.noindex/SourceKitBuild` so it never shares a build DB with an open Xcode.
|
||||
9. **Xcode-compatible builds:** `xcodebuild` without `-derivedDataPath` and the wrapper don't rebuild after each other (no-op 26–31 s). With `-derivedDataPath` pointing to the same folder they do.
|
||||
10. **iOS simulator:** generic destination fails (`fix_libswiftWebkit_simulator.sh` needs `TARGET_DEVICE_OS_VERSION`) → build for a concrete simulator. Debugging: `simctl launch --wait-for-debugger` + lldb-dap attach by **pid** works (breakpoint in `AppDelegate`). lldb-dap with `attachCommands` or with `program` + pid never stops at breakpoints (CLI lldb does) → launch config uses `${command:pickProcess}` (newest first). VS Code substitutes variables before `preLaunchTask`, so run the task first.
|
||||
10. **iOS simulator:** generic destination fails (`fix_libswiftWebkit_simulator.sh` needs `TARGET_DEVICE_OS_VERSION`) → build for a concrete simulator. Debugging in one launch: `preLaunchTask` runs `simulator.sh` (launch `--wait-for-debugger`, writes the attach command), the config attaches with `attachCommands: command source .build/simulator-attach.lldb` (read at attach time, after the task). Earlier failures of `attachCommands`/`program` were caused by the wrong `sourceMap` (10a), not by lldb-dap.
|
||||
10a. **Gray breakpoints in VS Code (macOS app):** the launch configs had `sourceMap` `/^wt → worktree` for all builds. lldb also applies it in reverse when setting breakpoints, so `<worktree>/…/File.swift` became `/^wt/…/File.swift`, which regular (Xcode-mode) debug info doesn't contain → "no locations". Fix: no `sourceMap`; `xcodebuild.sh` writes `.build/debug.lldbinit` per build (source map only for `DDG_WORKTREE_CACHE=1`), launch configs `command source` it in `initCommands`. Confirmed fixed in VS Code 2026-10-15.
|
||||
11. Index sharing between worktrees: rejected (absolute paths + mtime-based staleness).
|
||||
12. `workspace/_pollIndex` isn't in release sourcekit-lsp → indexer waits for "Indexing" progress end + 60 s quiet; gives up after 5 min without progress.
|
||||
|
||||
Reference in new issue
Block a user