Re-attach heal loop: stale playbook probe, unwritten extra-kit marker, and sbx 0.38 'kit add' refusing kits with setup.startup #320

Summary

Re-attaching to an existing sandbox (./acq run <name>) attempts kit heals on every attach and every attempt fails, with the real sbx error suppressed. Three causes compound; the first is the functional regression, the other two are stale-detection bugs that turn it into every-attach noise.

Environment: quickstart 2242af4, sbx 0.38.0 (c022b146), macOS (Apple Silicon). Sandbox provisioned with the current bundle pin (f5fb8875 / patterns v1.8.0) plus an ACQ_EXTRA_KITS kit. Related: #298 (the 0.38 kit-schema lockstep).

1. sbx 0.38 kit add refuses any kit declaring setup.startup — heal and acq kit update are both broken

Running the exact command a heal warning prints as "Recover with:":

$ sbx kit add <sandbox> <translated-playbook-kit-dir>
ERROR: kit "agentic-coding-playbook" declares setup.startup, which the kit-add
recreate flow does not yet apply; recreate the sandbox from scratch via
`sbx rm` + `sbx create --kit` to use this kit

Every kit in the built-in bundle (and any realistic extra kit) declares startup commands, so under sbx 0.38 all mid-life kit adds are refused. That breaks acq_backend_ensure_kits_applied on the re-attach path and the stale-bundle refresh (acq kit update → ACQ_FORCE_KIT_REAPPLY=1), which re-adds every built-in kit.

acq swallows the error (sbx kit add ... >/dev/null 2>&1, e.g. acq.backends/sbx.sh:491) and prints only a generic warning, so users can't see why it failed.

Suggested handling until sbx implements startup in the kit-add flow ("not yet" in the error suggests it's planned): capture stderr, detect this refusal, and print one clear "sbx ≥ 0.38 can't extend a live sandbox with startup-bearing kits — recreate to extend/refresh" message instead of per-kit warnings with misleading recover commands; have acq kit update fail fast with the same message.

2. The playbook feature-probe predates the tarball delivery — permanently "missing" on current sandboxes

The heal probes playbook presence with test -e "$HOME/.agentic-coding-playbook/.git" (acq.backends/sbx.sh:489). Since the bundle moved playbook delivery from git clone to the REST tarball (patterns v1.8.0, the #203 fix), sandboxes provisioned with the current bundle have ~/.agentic-coding-playbook with no .git (verified in-sandbox). So the probe reports the playbook absent on every re-attach, forever, and acq re-attempts the add each time. Probing for ~/.agentic-coding-playbook/AGENTS.md (what the symlink farm actually consumes) would match both delivery eras.

3. ~/.acq-extra-kits is never written at create — extra kits always look unapplied

The re-attach path decides whether an extra kit is applied by reading ~/.acq-extra-kits (acq.backends/sbx.sh:520), but the only writer is the heal path itself after a successful mid-life add (sbx.sh:530). Sandboxes created with ACQ_EXTRA_KITS never get the marker, so every re-attach re-attempts every extra kit (and under (1), fails). The create path should write the same marker (or presence should derive from recorded provenance).

Repro

export ACQ_EXTRA_KITS=/path/to/any/kit-with-startup-commands
./acq run opencode --name t1 /path/to/repo   # provision normally, detach
./acq run t1                                  # re-attach: "missing the playbook kit",
                                              # extra-kit applies, all warn-fail
sbx kit add t1 <printed-recover-path>         # shows the real setup.startup refusal

Happy to split this into three issues if you'd rather track them separately. (1) may belong upstream with Docker sandboxes — filing here first since acq's UX hides it and items 2–3 are acq's own.