[barbatdev]

Problem

On workshop hosts, gs sync failed at gentle-shell setup (isolated home):

go: github.com/Gentleman-Programming/engram/cmd/engram@...: missing .../cmd/engram/go.mod
Error: execute install pipeline: install beta engram from main: exit status 1

gentle-ai's beta channel installs Engram from the pre-v3 module path, which no longer exists since engram moved to /v3. gentle-ai skips that install when GENTLE_AI_ENGRAM_BIN is set, but gs relied on the calling shell exporting it (zsh/cortex-dotfiles.zsh). A shell opened before the dotfiles update, or a host that doesn't load them, passed nothing. And gs sync pulls the dotfiles at the end, so the run that brings the fix never applies it.

Fix

cmd_sync now exports GENTLE_AI_ENGRAM_BIN pointing at the Engram it just built, before gentle-ai sync and gentle-shell --isolated setup. If the variable is already set in the environment, that value is kept.

Tests

• tests/gs_test.sh: with the variable unset, both steps get the built binary (saw this test fail before the fix).
• tests/gs_test.sh: an explicit value is kept.
• Full suite: 37 passing.

🤖 Generated with Claude Code

https://claude.ai/code/session_01A9D7phtzRBjJGKsHtaiVWj

[barbatdev]

Post-merge QA (glm)

Lens: requirements + adversarial. The merge does what the PR promised: cmd_sync exports GENTLE_AI_ENGRAM_BIN pointing at the Engram gs just built, before gentle-ai sync and gentle-shell isolated setup, and keeps a value already present in the environment. The docs (docs/gs-sync.md) were updated consistently with #116's text, and tests/gs_test.sh adds both the unset-env and explicit-value cases, including restoring the stubs afterwards. No production behavior change beyond the export; no acceptance gap found.

No findings.

Verdict: clean

[barbatdev]

Post-merge QA (deepseek)

Lens: evidence + test design. The export of GENTLE_AI_ENGRAM_BIN now happens inside cmd_sync, after $bin/engram is built and after the ~/.local/bin symlink is refreshed, and before both gentle-ai sync and gentle-shell --isolated setup - the two steps named in the reported failure. The added tests are real evidence for that claim: they replace the node and gentle-ai stubs with variants that record the variable, run the sync with env -u GENTLE_AI_ENGRAM_BIN, and assert both recorded lines equal the freshly built path; a second case asserts an explicit value is kept. The scripts run under set -euo pipefail and a failed engram go install already marks the sync INCOMPLETE with a non-zero exit, so the export cannot leave a successful run pointing at a binary that was never built. The remaining gap is the kept-value branch: it is asserted to win, but never validated, and the same audit trail records a stale v1 binary living at ~/go/bin/engram on one host.

Question (1)

• A pre-set GENTLE_AI_ENGRAM_BIN is trusted without a version check (bin/gs:478): export GENTLE_AI_ENGRAM_BIN="${GENTLE_AI_ENGRAM_BIN:-$bin/engram}" keeps whatever the environment already carries, and the merged docs state 'A value already set in the environment wins'. The fix(engram): stop startup provisioning from downgrading Engram v3 #115 audit log in the same repository records that agent-gentle still has a v1 engram at ~/go/bin/engram, so a host that points the variable there keeps gentle-ai on v1 - the exact downgrade this commit is meant to prevent - while gs sync reports success and the documented check (engram version reports 3.x after gs sync) is what the maintainer has to notice by hand. No test covers a set-but-stale value; both new cases only prove an explicit value is propagated. Is keeping the override unvalidated the intended behaviour, or should the kept value be verified as the binary gs just built (or at least a 3.x) before it wins?

Verdict: clean