fix: respect bun projects in wb test

[exKAZUu]

Summary

• Resolve YARN and BUN placeholders using the target project package manager instead of the runtime that launched wb.
• Keep Bun-project wb test e2e startup commands on bun --bun run, including nested wb concurrently, migrations, buildIfNeeded, and Playwright commands.
• Preserve yarn run behavior for Yarn projects and avoid generating bun --bun run run ... for BUN run ... inputs.
• Remove inherited NO_COLOR when wb test forces color output, avoiding repeated runtime warnings in test logs.

Why

Running the local wb test implementation across repositories from self-host-utils/scripts/process-repos.sh exposed moti-ai failing before its tests could run because the generated e2e command called yarn wb ... in a Bun project where mise had no Yarn version configured. The placeholder normalization should follow the target project, not the process used to launch wb.

Testing

• yarn workspace @willbooster/wb build
• Cross-repo sweep with local packages/wb/bin/index.js test over repos listed in /Users/exkazuu/ghq/github.com/WillBooster/self-host-utils/scripts/process-repos.sh, excluding ai-game-builder
• Reran moti-ai after the fix; the original Yarn shim failure disappeared and the command reached app e2e assertions using Bun commands
• yarn check-for-ai
• bunx @willbooster/agent-skills@latest check-pr-ci

Notes

Other sweep failures were target repo state or app test failures, including missing checkouts, missing installs, missing environment variables, and app-level assertion failures. Review feedback has been addressed and unresolved review threads are clear.

[gemini-code-assist]

Code Review

This pull request refactors script normalization in run.ts to use project-specific Bun availability and updates test.ts to manage color environment variables. The review identifies a redundant conditional check in test.ts because the variable is guaranteed to be truthy. Furthermore, the implementation in test.ts violates the repository style guide by using process.env instead of project.env.

[exKAZUu]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the script normalization logic in packages/wb to use project-specific package manager settings instead of the global runtime environment. It also modifies environment variable handling in the test command. Review feedback identifies a missed replacement of packageManagerWithRun with projectPackageManagerWithRun which maintains an unintended runtime dependency, a potential regression where the run command is omitted for Yarn projects, and a resulting unused import that should be cleaned up.

[exKAZUu]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the wb package to use project-specific properties for determining Bun availability and package manager commands, replacing global runtime checks. Specifically, it introduces projectPackageManagerWithRun within normalizeScript and updates environment variable handling in the test command. A review comment suggests simplifying the string replacement logic for YARN run to eliminate redundant checks, aligning with the repository's goal of minimizing code complexity.

[exKAZUu]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the wb package to use project.isBunAvailable instead of the global isRunningOnBun utility, ensuring that package manager commands are determined based on the project's specific configuration. It also modifies environment variable handling in the test command by deleting NO_COLOR. A review comment suggests refactoring the script normalization logic to prevent potential double 'run' commands and to reduce redundancy by consistently using the newly introduced projectPackageManagerWithRun variable.

[exKAZUu]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the test command to explicitly remove the NO_COLOR environment variable and refactors the script normalization logic in packages/wb/src/scripts/run.ts. The refactoring replaces global runtime utility calls with project-specific properties, specifically using project.isBunAvailable to determine the appropriate package manager command. I have no feedback to provide.