test(tui): stop /prd's healthy-cwd control from launching a real engine - #273
Merged
Conversation
`/prd` hands the published PRD to an installed engine to author, and engineStatus() decides "installed" purely by walking PATH. The healthy-cwd control was the only test in the file that got far enough to reach that handoff — its siblings all use a cwd where createPrd() throws first — so on a machine with `claude` on PATH it really did launch Claude and block until it finished authoring. That cost 420s of the suite's 479s, spent real tokens on every run, and gave a different result depending on who ran it: under a second on CI, where no engine is installed, seven minutes on a developer's machine. Give the child an empty directory as its whole PATH so no engine resolves. node is spawned via process.execPath, so nothing else in the child cares. The test's existing assertions are all about publishing, which happens before the handoff, so none of them move. Also assert the no-engine branch is the one taken, so this cannot quietly regress: with a stub `claude` on PATH the test fails on that assertion. Suite: 479s -> 70s. 1306 tests, 1303 pass, 0 fail, 3 skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ThreatCrush Security Scan87 finding(s) HIGH/CRITICAL: 50 | MEDIUM: 37
…and 37 more. Full results in the Security tab. Snippets are redacted; ThreatCrush never prints matched credential material. |
ralyodio
marked this pull request as ready for review
August 3, 2026 16:51
Merged
ralyodio
added a commit
that referenced
this pull request
Aug 3, 2026
Three commits have been sitting unreleased on main, two of them the same trap seen from both ends: an install that succeeds into the wrong home. #272 install.sh refuses `sudo curl … | sh` up front, before the download, instead of writing the payload into /root/.moshcode where the user who typed the command cannot read it. #274 `dns` escalates itself per command rather than telling the operator to `sudo moshcode …` — advice that was right for dns and dangerous for `update`, which self-updates through the installer and so reinstalls into root's home. #273 the /prd healthy-cwd test no longer launches a real engine; the suite went from 479s to ~70s. Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
One test was 420s of the suite's 479s.
/prdhands the published PRD to an installed engine to author, andengineStatus()decides "installed" purely by walkingPATH:TUI /prd still publishes a PRD in a healthy cwdis the only test in the file that gets that far — every sibling uses a cwd wherecreatePrd()throws first. So on a machine withclaudeonPATHit launched Claude for real and blocked until it finished authoring a PRD.That means the test:
A test whose behaviour flips on whether the person running it happens to have Claude installed isn't testing anything.
The fix
Hand the child an empty directory as its whole
PATH, so no engine resolves.nodeis spawned viaprocess.execPath(absolute), so nothing else in the child cares.Every existing assertion is about publishing, which completes before the handoff — none of them move.
Guarding the regression
Added two assertions pinning the no-engine branch. Verified they bite: with a stub
claudeonPATH, the test fails withResult
1306 tests, 1303 pass, 0 fail, 3 skipped— same 3 skips asmain.One correction
I earlier reported that
npm testhangs unless stdin is redirected. That was wrong.npm testnow completes in 85s with no redirect; the only issue was ever this test pushing the run past my timeout.🤖 Generated with Claude Code