[barbatdev]

Summary

• gs help now shows that Pi package commands pass through to the isolated home: gs install npm:<pkg> (e.g. npm:pi-claude-bridge) and gs list.
• Notes the caveat: inside a gentle-shell clone or worktree, gs routes them through gs run with that checkout as --package-root.

Why

pi install npm:pi-claude-bridge installs into ~/.pi, so the bridge never shows up in gentle-shell. gs install ... already forwards to gentle-shell --isolated install ... (the *) cmd_launch branch) and installs into ~/.gentle-shell/agent, but the help only said gs [pi args...].

Verification

• gs list from ~ lists npm:pi-claude-bridge under ~/.gentle-shell/agent/npm/....
• tests/gs_test.sh and tests/gs_official_test.py pass.

🤖 Generated with Claude Code

https://claude.ai/code/session_01A9D7phtHFYfszv6WKeXbiU

[barbatdev]

Fleet review (glm)

Lens: requirements + adversarial. Docs-only change to the gs usage text, documenting the existing pass-through of Pi subcommands (gs install npm:<pkg>, gs list) to the isolated home, plus the caveat that inside a gentle-shell clone/worktree they route through gs run with the checkout as --package-root. No linked issue; the behavior described (*) cmd_launch forwarding) is stated as pre-existing in the PR body, and the diff touches only the heredoc help block, so no runtime behavior changes. The text is consistent with the caveat and matches the surrounding help formatting and indentation. No blocking findings; no concrete failure scenario exists for a comment-only diff.

No findings.

Verdict: ready to merge

[barbatdev]

Fleet review (deepseek)

Lens: evidence + test design. Docs-only change to the usage() block of bin/gs: it adds lines to the gs [pi args...] entry stating that Pi subcommands pass through to the isolated home (gs install npm:<pkg>, gs list) and that inside a gentle-shell checkout they are routed through gs run instead. Checked against the current head of bin/gs: the claim holds — the *) cmd_launch "$@" branch (bin/gs:627) execs gentle-shell.mjs --isolated "$@" (bin/gs:613) outside a gentle-shell checkout and falls back to cmd_run with --package-root inside one (bin/gs:605-608, bin/gs:291). The existing help test only asserts that gs sync appears (tests/gs_official_test.py:70-74), so the new lines break nothing. Only evidence gaps remain: the passthrough contract the help now documents is not covered by any automated test, and the workshop caveat names the mechanism without stating what it changes for an install. Neither is a merge blocker for a help-text edit.

Suggestion (2)

• The documented gs install / gs list passthrough has no automated evidence (bin/gs:23): The help text now states a contract (Pi subcommands go to the isolated home), but the only help assertion in tests/gs_official_test.py:70-74 checks for the string gs sync, and the general forwarding test (tests/gs_official_test.py:58-63) uses --model a b x, not a package subcommand. The PR's verification is a manual terminal observation (gs list from ~), which cannot be reproduced from the PR. Missing test condition: run the default-launch path with install npm:pi-claude-bridge and assert the stub records the install npm:pi-claude-bridge argument alongside --isolated; and assert --help output contains the new gs install / gs list lines so this documented contract cannot silently regress.
• Workshop caveat states the mechanism, not what it changes for an install (bin/gs:25): "or they go through gs run" (bin/gs:25-26) tells the reader the code path but not the consequence: the same gs install inside a gentle-shell checkout reaches gentle-shell.mjs --isolated --package-root <checkout> install ... (bin/gs:291 vs bin/gs:613), so the package lands with that checkout as its package root rather than plain ~/.gentle-shell/agent. For a reader deciding where the bridge will show up, that is the part they need. Also note the adjacent wrap reads oddly in the rendered help (gs list. Run them outside a / gentle-shell checkout).

Verdict: ready to merge

[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. Documentation-only change to the gs usage block (shares merge commit 371f3d4 with #115). The added lines describe real behaviour of the merged script: gs install npm:<pkg> and gs list fall through to *) cmd_launch, which execs node <shell>/bin/gentle-shell.mjs --isolated ..., and cmd_launch routes to cmd_run when the current checkout is a gentle-shell package - exactly the caveat the text states. No code path changes, so there is nothing to regress; the only gap is that no test pins the usage text and the new command name differs from the existing gs ls by one character.

Suggestion (1)

• gs list and the existing gs ls differ by one character in the same help page (bin/gs:23): The new lines document gs list (Pi packages, pass-through to the isolated home) while the same usage block documents gs ls for worktrees; the dispatch table confirms both are live and mean different things (ls) cmd_ls vs the *) cmd_launch fallback). A one-character typo silently runs the other command with no hint. Placing the two entries next to each other, or stating the contrast explicitly ('gs ls lists worktrees; gs list lists Pi packages'), removes the ambiguity without changing behaviour.

Verdict: clean