From 703faeb9b41ef64ada1bd74eafe2656caf2837a4 Mon Sep 17 00:00:00 2001 From: Alexey Martemyanov Date: Thu, 15 Oct 2026 12:41:49 +0600 Subject: [PATCH] [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 --- personal/projects/balda/execution-broker.md | 5 +++-- personal/projects/balda/setup.md | 2 +- .../tech-design-xcode-build-server.md | 12 +++++------- work/projects/vscode-migration/xcode-build-server.md | 4 ++-- 4 files changed, 11 insertions(+), 12 deletions(-) diff --git a/personal/projects/balda/execution-broker.md b/personal/projects/balda/execution-broker.md index ab4cdcd4..c6fc7375 100644 --- a/personal/projects/balda/execution-broker.md +++ b/personal/projects/balda/execution-broker.md @@ -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 на том же хосте | diff --git a/personal/projects/balda/setup.md b/personal/projects/balda/setup.md index 08eca3c7..b58a9da5 100755 --- a/personal/projects/balda/setup.md +++ b/personal/projects/balda/setup.md @@ -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. Существующие сессии не сбрасывались. diff --git a/work/projects/vscode-migration/tech-design-xcode-build-server.md b/work/projects/vscode-migration/tech-design-xcode-build-server.md index a21abd7d..42319b52 100644 --- a/work/projects/vscode-migration/tech-design-xcode-build-server.md +++ b/work/projects/vscode-migration/tech-design-xcode-build-server.md @@ -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. diff --git a/work/projects/vscode-migration/xcode-build-server.md b/work/projects/vscode-migration/xcode-build-server.md index 72b3c6dc..b4d2bab2 100644 --- a/work/projects/vscode-migration/xcode-build-server.md +++ b/work/projects/vscode-migration/xcode-build-server.md @@ -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 [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 `/…/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.