fix(msb): thread the merged kit env onto kit lifecycle commands

[basiliskus]

Summary

On the msb backend, a kit's lifecycle commands ran with only that kit's own environment[]. Interactive sessions already replayed the merged /var/lib/acq/kit-env marker, but commands started by a kit's lifecycle phase — especially background: true startup daemons — did not.

Consequence: the Paseo kit starts paseo daemon from its own startup command, so every agent Paseo later spawns inherited only the Paseo kit's env. A team kit's OPENCODE_CONFIG (team instructions plus a default-deny glab/gh permission layer) was silently missing from those agents, while GITLAB_TOKEN/GITHUB_TOKEN were still present. Silent, and security-relevant.

This PR makes kit environment[] guest-wide for lifecycle commands, with the same last-value-wins ordering sessions already use, and pins guard ownership per kit.

Design

A pre-pass over the full effective kit set computes the merged env before any kit is applied:

path	merged env source
acq_backend_provision	pre-pass over every fetched spec, before the first apply
acq_backend_ensure_kits_applied	same pre-pass; refs resolved in one loop, merged, applied in a second
acq_backend_apply_kit (mid-life)	no full set → falls back to the persisted marker
neither	the kit's own env (pre-change behavior), fail-soft

Why a pre-pass and not a marker read inside _acq_msb_run_commands. The marker is appended inside the same per-kit apply loop that runs commands, so a per-kit read is correct when the env-declaring kit happens to be applied first and silently wrong in the reverse order. Order-independence is asserted in both directions.

Guard ownership is by token, not by name. The non-interactive git guards (GIT_TERMINAL_PROMPT=0, GIT_ASKPASS=/bin/false, SSH_ASKPASS=/bin/false) were previously decided by matching the kit's own env for GIT_TERMINAL_PROMPT. Naively widening the threaded env would let one kit's GIT_TERMINAL_PROMPT=1 disable guards for every kit's commands — the adapter's own comment records that a prompting kit command once hung provision indefinitely. _acq_msb_env_tokens_with_guards_into now strips all guard-name tokens from the merged set unconditionally, re-adds only the owning kit's, then appends acq's defaults unless that kit set GIT_TERMINAL_PROMPT itself. A command can therefore only ever receive its own kit's guard value or the adapter's.

The create-time staged --script-path body got the same treatment. That path is inert today (ADR-0017: a bare --script-path registration is staged on the guest PATH, never auto-run at boot), so this is consistency work, not part of the reported symptom — it keeps the ADR-0017 version-bump re-verification note from becoming a live bug later.

Related Issues

Fixes #515

Conflict note: #504 (ADR-0030, host-authoritative config) rewrites the same kit-env functions and test files, replacing the guest marker with a host-authoritative store. This PR was deliberately built on current main rather than waiting. The marker read is isolated in one named helper (_acq_msb_persisted_kit_env_into) that #504 can repoint, but merge work is expected.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Breaking change (fix or feature that would cause existing functionality to change)

Behavior change worth calling out explicitly: a kit's environment[] now reaches other kits' lifecycle commands. That is the intent, and it widens what an extra or personal kit can influence. Recorded in ADR-0033.

Checklist

• I have read CONTRIBUTING.md
• My commits follow the Conventional Commits format (e.g., feat:, fix:, docs:)
• I have tested my changes locally
• I have updated documentation as needed
• I have not included any secrets, API keys, or sensitive information

Test Results

All run at 58b83de:

check	command	result
offline suite	./scripts/test-acq-bats	1..527, 527 ok / 0 not ok
shell lint	printf '%s\n' acq acq.backends/*.sh scripts/test-acq-lib.sh scripts/test-acq-bats test/bats/*.bats test/bats/helper.bash | xargs -r -n8 shellcheck --severity=warning	rc 0, no findings
markdown lint	npm run lint:md	50 files, 0 errors

Baseline at 187aa57 was 1..518. 527 = 518 + 9 new tests.

New offline coverage (test/bats/79-msb-merged-kit-env.bats, plus two staged-body tests in 73-msb-kits-startup.bats): merged env reaches a background: true daemon and every lifecycle phase; the merged env is identical in both kit application orders; duplicate names resolve last-kit-wins; one kit's GIT_TERMINAL_PROMPT does not strip another kit's guards; two kits declaring the same guard name with different values each keep their own; mid-life kit apply recovers merged env from the marker; the heal path merges with the daemon kit applied first; the staged body carries merged env with per-kit guards.

Each new test was verified to fail before the change and pass after, with the implementation reverted and the tests held constant.

Additional Notes

Known gaps

• No live end-to-end run. No Docker/KVM was available, so the issue's original /proc/<paseo-daemon>/environ reproduction was never executed. Everything is verified at the adapter/argv and staged-body level against the stubbed suite. Per this repo's periodic-re-verification practice, this should be confirmed on a sandbox-capable host before the issue is considered closed.
• Duplicate -e precedence unverified against a live msb. When a kit declares its own GIT_ASKPASS, the command receives both it and acq's /bin/false. main emits the identical order for that input, so this is preserved rather than introduced — but that acq's value wins by flag order is inferred from flag order, not observed at runtime.
• pre-commit / gitleaks were not available locally, so those hooks and the YAML/JSON and file-hygiene checks were not executed; they must pass in CI. Trailing whitespace and EOF newlines were verified manually on every touched file.
• Deliberately not fixed: a merged var can name a path a later kit has not staged yet (e.g. OPENCODE_CONFIG pointing at a file the team kit copies later), converting "no team config" into "possibly broken team config" for that window. This is an ordering/barrier decision, not an env-scoping one, and is the same class as the sbx startup race in fix(sbx): acq run does not wait for kit startup-phase config writes before attach, causing a stale-config race #506. Recorded in ADR-0033's consequences.
• ADR numbering: 0033 was free at branch time, but open PRs claim 0030 (three ways), 0031 and 0032. May need renumbering on merge.

Review focus suggestions

_acq_msb_env_tokens_with_guards_into is the security-relevant core. The _builtin parallel-array bookkeeping in _acq_msb_heal_kit_set gates the provenance write that claims a sandbox carries the current pinned bundle, so a two-loop split there is worth a look. Whether the mid-life marker fallback is the right semantics for acq kit apply is a judgment call rather than a defect.

Note that the new tests assert recorded msb exec argv and generated script text. They prove acq constructs the intended commands; they do not prove msb executes them with the intended final environment.

Rollback

Revert the three commits, or revert the branch merge. No state migration, no persisted format change: the /var/lib/acq/kit-env marker's format and write path are unchanged, so an existing sandbox is unaffected by a revert and keeps working with either version of the adapter.

---

AI-assisted: implemented, reviewed and trimmed by AI agents under human direction, with the human approving each step. An independent fresh-context review agent found one major defect (guard ownership tracked by name, which let a later kit's GIT_TERMINAL_PROMPT value reach another kit's command and skip the askpass guards — a regression against main for that input); it was fixed in eb9284b and re-verified. A subsequent scope review led to the 58b83de trim, which removed ~156 lines of duplicated rationale with the code left provably byte-identical. Human review is still required before merge.

[wz-gsa]

AI-assisted (OpenCode). Ran the live Docker/KVM verification this PR's own "Known gaps" section flagged as missing — real acq create on real msb 0.7.4, not stub-tested.

Test 1: merged env reaches a background: true daemon (the original #515 symptom)

Built two real test kits — a "team" kit declaring environment: {TEAM_MARKER: ...}, and a "daemon" kit with a background: true startup command spawning a long-running shell loop (mirroring Paseo's own daemon pattern). Applied both via acq create, then read the daemon's actual process environment directly from /proc/<pid>/environ — the exact repro mechanism from #515.

Both apply orders tested (team-then-daemon, and reversed daemon-then-team), since the PR description specifically calls out that a per-kit marker read inside the apply loop would be order-dependent:

# daemon's own /proc/<pid>/environ, team kit applied FIRST:
TEAM_MARKER=team-value-123
DAEMON_MARKER=daemon-value-456

# daemon's own /proc/<pid>/environ, REVERSED — daemon kit applied FIRST:
TEAM_MARKER=team-value-123
DAEMON_MARKER=daemon-value-456

Identical in both orders — the merge is genuinely order-independent, and the daemon process genuinely inherits the OTHER kit's env, not just its own.

Test 2: guard-ownership isolation (the regression a fresh-context reviewer caught in eb9284b)

Built a "prompter" kit declaring GIT_TERMINAL_PROMPT=1 as its own intentional override, and a "victim" kit declaring no guard override at all, both as background: true daemons. Tested both apply orders again.

# prompter daemon's own env (either order):
GIT_TERMINAL_PROMPT=1

# victim daemon's own env (either order):
GIT_TERMINAL_PROMPT=0
GIT_ASKPASS=/bin/false
SSH_ASKPASS=/bin/false

The victim kit's commands correctly keep acq's safe defaults regardless of apply order and regardless of the prompter kit's override — no leakage either direction. This directly confirms the fix for the exact failure mode _acq_msb_env_tokens_with_guards_into's own comment warns about.

Net

Both of this PR's self-reported "known gaps" (no live end-to-end run; duplicate--e-precedence inferred rather than observed) are now live-verified for the core merged-env and guard-isolation behavior — not just confirmed at the stubbed/argv-assertion level. I did not test the duplicate--e-flag-precedence-under-live-msb gap specifically (that one's about GIT_ASKPASS appearing twice in one -e list when a kit sets its own); happy to if useful.

Sandboxes created and removed as part of this verification; no persistent state left behind.