Архив исходника Broker

Историческая копия до очистки репозитория 2026-10-16. Источник: mallexxx/execution-broker, commit ae92c15d31c8396789765cebf82f7971d6f4cb12, файл docs/work-plan.md. Старые статусы и deployment pins ниже не заменяют актуальную personal/projects/balda/execution-broker.

Broker work plan and release scope

This plan covers Execution Broker's execution infrastructure. Feature completion and release acceptance apply to the capabilities this repository advertises. An unfinished local agent scenario is not a Broker release blocker.

Ownership boundaries

Broker owns disposable worker provisioning, run lifecycle, execution admission, worker-scoped credentials, generic tooling, artifacts and verified cleanup.
Balda/local agents own task orchestration, MCP connections, search, Obsidian, PR review/publication, recurring work and application/device scenarios.
iPad signing/install/unlock/launch belongs to a local agent/project workflow. Broker can supply a build worker and artifacts if that workflow chooses to use them. Physical-device acceptance is not required for a Broker release.
UI reproduction, project-specific red/green tests and PR/CI policy belong to their project workflow. Generic guest execution/artifact transport can be a Broker capability; the particular app's acceptance is separate.
Broker does not introduce Obsidian vault/folder rights or a general Balda MCP permission system. Earlier cross-project proposals were not an approved user access policy and must not be treated as one.

1. Worker isolation and deployment consistency

Keep Docker administrative access in the gateway. Coding workers must not receive a Docker socket/group or ambient host credentials.
Pin the resolved worker image before allocation and reject Broker/gateway drift without leaking undelivered credential leases.
Deploy Broker, gateway, Runner/Callee, workflow/config pins, VM bootstrap and plugin as a consistent accepted set. Preserve a consistent backup and rollback image/config; do not interrupt unrelated active runs.
Verify actual execution evidence, source revision, artifact hashes and cleanup separately from model reports and notification delivery.

2. Generic artifact inputs and retention

Implemented with transactional holds, scoped transfer, durable pre-execution resume and real Docker/Callee restart acceptance. Deploy the matching worker protocol before advertising this capability in the operator stack.

Gate advertised VM/Docker artifact return on success/failure evidence, bounded logs, checksums, authenticated discovery/download, explicit collection errors and documented retention.
Add a run-to-run input contract bound to source run, artifact name and SHA256. Hold source artifacts until their dependent run finishes or explicitly expires.
Accept resumable transfer and reject changed digests with disposable fixtures. Particular device deployments and app-specific signing steps remain outside this generic contract.

3. Runtime tooling and caches

Cache immutable tooling by OS/architecture, tool versions and recipe digest. Keep a separate allowed-repository object cache keyed by repository and commit; seed disposable guest-local checkouts without sharing mutable host worktrees or Git credentials.

3.1. Stack-independent environment provisioning

The declarative profile, package/archive/system backends, scoped verified cache, readiness evidence and generic Go migration are implemented; see tooling. The operator deployment also passed the real macOS VM bootstrap/archive/tunnel and XCTest gate; a separate Linux gate compiles and executes Go with shared /tmp mounted noexec and a private executable run temporary directory. Mid-run environment replacement now uses an explicit operator-authored checkpoint and a separately approved continuation; a separate immutable repository cache seeds guest checkouts by repository/commit. Acceptance and deployment evidence must cover the exact shipped version; source acceptance alone is insufficient.

Define a versioned, declarative tooling profile for Linux and macOS: OS and architecture constraints, tool/SDK versions, approved package or archive sources, integrity checks, install locations, environment and executable readiness probes. Cover Make/C/C++, CMake/Ninja, Python, Node, Rust and JVM projects through generic provisioning backends. Move the current dedicated Go installer into this mechanism. Keep project tool versions independent from the executor's own pinned Node/ACP runtime.
Let the agent inspect repository build manifests and request the required tooling profile before execution. A Makefile defines commands, not the compilers, libraries or SDKs needed to run them. Validate requested tools against operator policy; repository content cannot authorize a new source, privilege or network destination. Provision and run readiness checks before implementation and verification. Report missing or incompatible tools with their required versions and the failed prerequisite.
Install system dependencies while preparing the disposable image or guest. Permit project-local dependencies only within the run's writable workspace and granted network scope. Preserve Linux worker isolation and keep host and golden-image state unchanged. Pin the resolved environment and cache it by platform, versions, package sources and recipe digest; record the actual tool versions in run evidence.
Handle a missing dependency discovered during execution through a bounded, durable environment-change request. Validate any additional approval, save the exact source revision and safe workflow checkpoint, prepare the new immutable environment, and resume idempotently. Reconcile the old worker and credential lease before replacement. Do not replay external mutations or widen the approved task implicitly; stop repeated no-progress rebuilds with a visible failure. Cancellation and restart must retain artifacts and clean both old and replacement resources.
Acceptance: run Make/C or CMake, Python and Node projects on Linux and macOS, plus a Rust or JVM project supplied through a new tooling profile without a Broker code change. Verify a cache hit, version change, missing tool found mid-run, unavailable package source, invalid checksum, denied installation, restart and cancellation. Prove no installation reached the host, executor runtime or shared golden image, and no duplicate side effect occurred.

4. Optional generic remote-action capability

If Broker advertises a configurable remote-action API, implement typed command IDs/arguments, protected credentials, pinned host identity and explicit action scope, plus cancellation and reconciliation after an ambiguous disconnect.
Accept it using disposable managed-host fixtures, including invalid arguments, changed host keys and unknown outcomes. Keep arbitrary host/device workflows in the caller. A local agent may also use its own SSH tooling without Broker.
This future capability is separate from the existing signed fixed host plans and is not required merely because a local iPad scenario uses SSH.

5. Release acceptance for the supported scope

Run source/race/vet/lint, adapter, security, plugin, real worker/artifact/restart and binary-install gates against the exact accepted revision.
Label native and emulated results accurately. Test advertised target platforms; document unsupported/unverified cases instead of inferring support.
Verify the deployed versions and one real conversational run with visible result, retained artifacts, credential settlement and confirmed cleanup. Test failures/outages at the Balda boundary with its own compatible code.
Verify backup/restore for the claimed recovery scope. A same-host drained restore alone does not prove recovery after host or credential-store loss.

External scenario references

iPad deployment and Hermes migration inventory are cross-project reference notes. They do not add device-specific code, search/Obsidian access policy, personal workflow migration or PR publication requirements to Broker. Their scenario-level requirements belong to the local agent/project owner.

8.4 KiB Executable File Raw Blame History