[barbatdev]

• Export GENTLE_SHELL_NO_AUTO_SETUP=1 so gentle-shell startup does not reinstall Engram v1.
• Export PNPM_HOME so pnpm add -g does not fail with ERR_PNPM_NO_GLOBAL_BIN_DIR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01A9D7phtzRBjJGKsHtaiVWj

[barbatdev]

Post-merge QA (glm)

Lens: requirements + adversarial. QA for merge 371f3d4, which carries both #115 (startup auto-setup opt-out + PNPM_HOME) and #114 (docs: Pi package commands pass through gs; same help-text hunk in bin/gs). The zsh exports default GENTLE_SHELL_NO_AUTO_SETUP=1 as documented, with the tradeoff and opt-out written down in docs/gs-sync.md; the PNPM_HOME guard only acts when the directory exists and prepends it to PATH; scripts/test-engram-auto-setup.sh greps the exports at line start and checks defaults plus both overrides in a clean zsh. #114's help-text addition matches the described passthrough behavior. Both PRs' promises are reflected in the merged content; verdict clean.

Suggestion (1)

• Guard test does not cover the new PNPM_HOME export (scripts/test-engram-auto-setup.sh:10): The script asserts defaults and overrides for GENTLE_AI_CHANNEL and GENTLE_SHELL_NO_AUTO_SETUP only. The same merge adds the conditional PNPM_HOME export to the same file; an assertion (set when ~/.local/share/pnpm exists, unset otherwise) would pin that behavior the same way.

Verdict: clean

[barbatdev]

Post-merge QA (deepseek)

Lens: evidence + test design. The merged commit adds the GENTLE_SHELL_NO_AUTO_SETUP default, a PNPM_HOME default, the gs install/list usage text and a small zsh-export test. The auto-setup guard has direct evidence: scripts/test-engram-auto-setup.sh evaluates the real export lines in a clean zsh -f and covers default, opt-out and channel override. The PNPM_HOME half of the same change has no evidence at all - the test's export extraction is a hardcoded allowlist that names only the two Gentle exports - and the export itself is gated on the directory already existing, which is the state the PR body describes as failing. The usage-text addition matches the merged dispatch (gs install ... falls through to *) cmd_launch -> --isolated install, and routes to gs run inside a gentle-shell checkout), so the documented caveat is accurate.

Suggestion (1)

• The hardcoded export allowlist hides new exports from the test (scripts/test-engram-auto-setup.sh:11): grep -E '^export (GENTLE_AI_CHANNEL|GENTLE_SHELL_NO_AUTO_SETUP)=' limits the test to two names, so any other export added to the Gentle-ai region later is silently out of scope - PNPM_HOME is the existing example. Test conditions worth adding: extract every export inside the region (or assert the extracted set equals the expected set) so a new export fails until it has a case; explicit cases for PNPM_HOME unset with the directory present, PNPM_HOME unset with it absent, and PNPM_HOME already exported, asserting both the variable value and the PATH prepend.

Question (1)

• PNPM_HOME default is untested and never fires when the directory is absent (zsh/cortex-dotfiles.zsh:39): scripts/test-engram-auto-setup.sh extracts only ^export (GENTLE_AI_CHANNEL|GENTLE_SHELL_NO_AUTO_SETUP)= from the profile (line 11 of that script), so the PNPM_HOME block added in this same commit is never executed by any check in the repository - scripts/test-engram-auto-setup.sh is the only test the PR adds, and it cannot see this export. Separately, the block requires [[ -d "$HOME/.local/share/pnpm" ]], so on a host where that directory does not exist yet PNPM_HOME stays unset, which is precisely the ERR_PNPM_NO_GLOBAL_BIN_DIR state the PR body says this fixes. Nothing merged shows which host state the export repairs, so the claim 'pnpm add -g does not fail' is unverified for the failing case.

Verdict: clean