Embedded bbox-init binary prevents use as a Go module dependency

[JAORMX]

Problem

internal/infra/vm/initbin/embed.go uses //go:embed bbox-init to embed the pre-compiled guest init binary. This binary is built by task build-init and is .gitignored — it is not tracked in the repository.

When external projects (e.g. bumblebee) depend on github.com/stacklok/brood-box as a Go module, the module proxy serves the package without the bbox-init file, causing a hard compilation failure:

.../brood-box@v0.0.14/internal/infra/vm/initbin/embed.go:11:12: pattern bbox-init: no matching files found

The dependency chain that pulls this in for library consumers is:

pkg/runtime → pkg/sandbox → internal/infra/vm → internal/infra/vm/initbin (embed)

There is no way for a downstream consumer to compile against brood-box without a local replace directive pointing at a checkout where bbox-init has been pre-built.

Proposed solutions

Option A — Build tag guard (recommended)

Split embed.go into two files with a build tag:

• embed_full.go (//go:build bbox_full): contains the real //go:embed bbox-init directive
• embed_stub.go (//go:build !bbox_full): exports var Binary []byte as an empty slice

The bbox CLI would build with -tags bbox_full (wired into Taskfile.yaml). Library consumers compile with the default stub — they never need the embedded binary at compile time since they don't run VMs directly.

Option B — Commit a minimal placeholder

Check in a small placeholder file named bbox-init (e.g. a minimal static binary or even a few bytes). The Go module proxy would then serve a compilable package. task build-init overwrites the placeholder with the real binary before building the bbox CLI.

Context

This was discovered while upgrading bumblebee from brood-box v0.0.5 to v0.0.14. Previously this was masked by a replace directive pointing at the local checkout.