chore: willboosterify this repo

.cursor/rules/general.mdc

@@ -15,22 +15,23 @@ alwaysApply: true
 - Create a new branch if the current branch is `main`.
 - Run any `git` commands sequentially.
 - Write tests ONLY if explicitly requested. If requested, follow these rules:
-  - Continue modifying the tests and code until all tests pass.
-  - Ensure tests reset any related persistent data, as our test infrastructure does not clear it automatically.
-  - Prefer actual API calls over mocks. Use mocks when actual calls are impractical, have unintended side effects, or are explicitly requested.
+  - Continue modifying tests and/or code until all tests pass.
+  - Ensure tests are idempotent and independent (e.g., reset persistent data) so they can run repeatedly or in parallel.
+  - Prefer actual API calls over mocks, unless actual calls are impractical, have unintended side effects, or mocks are explicitly requested.
   - Always investigate the root cause of a test failure before fixing it.
-  - Avoid adding wait functions in E2E tests unless you are confident they are necessary.
+  - Avoid adding wait functions in E2E tests unless strictly necessary.
 - When fixing issues, follow these rules:
   - Investigate the root cause first (e.g., by gathering debug logs, taking screenshots, etc.).
   - Fix the actual root cause instead of applying workarounds.
-- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or `yarn check-for-ai` for only type checking and linting (takes up to 10 minutes).
-  - If you are confident that your changes will not break any tests, you may use `check-for-ai`.
+- After making code changes, run `yarn verify-full` to execute all tests (takes up to 1 hour), or `yarn verify` for only type checking and linting (takes up to 10 minutes).
+  - If you are confident that your changes will not break any tests, you may use `verify`.
   - Use `oxlint` ignore comments with reasons (e.g., `// oxlint-disable-next-line <rule> -- <reason>`) if lint errors or warnings cannot be fixed.
 - Once you have verified your changes, commit and push them to the current (non-main) branch, then create a PR via `gh`.
   - Follow the conventional commits; your commit message should start with `feat:`, `fix:`, etc.
   - If not specified, make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Cursor) <agent@willbooster.com>`.
   - Always create new commits. Avoid using `--amend`.
 - Always use heredoc syntax when passing multi-line content to any command.
+- Use `wb start --mode test` to launch a web server for debugging or testing.
 
 ## Coding Style
 
@@ -42,9 +43,10 @@ alwaysApply: true
 - Place calling functions above the functions they call to maintain a clear top-down order.
   - e.g., `function caller() { callee(); } function callee() { ... }`
   - Unlike functions, place variable and type declarations ABOVE their usage.
-- Write comments that explain "why" and use JSDoc to explain "what".
+- Write comments and JSDoc for complex or hard-to-understand code.
+  - Explain "why" in comments and "what" in JSDoc.
   - Avoid stating what can be easily understood from the code itself.
 - Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
-- Prefer using a single template literal for prompts instead of `join()` with an array of strings.
+- Prefer using a single template literal for prompts instead of `join()` with a pre-computable array literal of strings.
 - Assume that all environment variables are properly defined.
   - If validation is required, use `assert` to fail fast (e.g., during startup).

.gemini/styleguide.md

@@ -10,9 +10,10 @@ Review in English based on the following coding standards.
 - Place calling functions above the functions they call to maintain a clear top-down order.
   - e.g., `function caller() { callee(); } function callee() { ... }`
   - Unlike functions, place variable and type declarations ABOVE their usage.
-- Write comments that explain "why" and use JSDoc to explain "what".
+- Write comments and JSDoc for complex or hard-to-understand code.
+  - Explain "why" in comments and "what" in JSDoc.
   - Avoid stating what can be easily understood from the code itself.
 - Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
-- Prefer using a single template literal for prompts instead of `join()` with an array of strings.
+- Prefer using a single template literal for prompts instead of `join()` with a pre-computable array literal of strings.
 - Assume that all environment variables are properly defined.
   - If validation is required, use `assert` to fail fast (e.g., during startup).

AGENTS.md

@@ -9,22 +9,23 @@
 - Create a new branch if the current branch is `main`.
 - Run any `git` commands sequentially.
 - Write tests ONLY if explicitly requested. If requested, follow these rules:
-  - Continue modifying the tests and code until all tests pass.
-  - Ensure tests reset any related persistent data, as our test infrastructure does not clear it automatically.
-  - Prefer actual API calls over mocks. Use mocks when actual calls are impractical, have unintended side effects, or are explicitly requested.
+  - Continue modifying tests and/or code until all tests pass.
+  - Ensure tests are idempotent and independent (e.g., reset persistent data) so they can run repeatedly or in parallel.
+  - Prefer actual API calls over mocks, unless actual calls are impractical, have unintended side effects, or mocks are explicitly requested.
   - Always investigate the root cause of a test failure before fixing it.
-  - Avoid adding wait functions in E2E tests unless you are confident they are necessary.
+  - Avoid adding wait functions in E2E tests unless strictly necessary.
 - When fixing issues, follow these rules:
   - Investigate the root cause first (e.g., by gathering debug logs, taking screenshots, etc.).
   - Fix the actual root cause instead of applying workarounds.
-- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or `yarn check-for-ai` for only type checking and linting (takes up to 10 minutes).
-  - If you are confident that your changes will not break any tests, you may use `check-for-ai`.
+- After making code changes, run `yarn verify-full` to execute all tests (takes up to 1 hour), or `yarn verify` for only type checking and linting (takes up to 10 minutes).
+  - If you are confident that your changes will not break any tests, you may use `verify`.
   - Use `oxlint` ignore comments with reasons (e.g., `// oxlint-disable-next-line <rule> -- <reason>`) if lint errors or warnings cannot be fixed.
 - Once you have verified your changes, commit and push them to the current (non-main) branch, then create a PR via `gh`.
   - Follow the conventional commits; your commit message should start with `feat:`, `fix:`, etc.
   - If not specified, make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Codex CLI) <agent@willbooster.com>`.
   - Always create new commits. Avoid using `--amend`.
 - Always use heredoc syntax when passing multi-line content to any command.
+- Use `wb start --mode test` to launch a web server for debugging or testing.
 
 ## Coding Style
 
@@ -36,9 +37,10 @@
 - Place calling functions above the functions they call to maintain a clear top-down order.
   - e.g., `function caller() { callee(); } function callee() { ... }`
   - Unlike functions, place variable and type declarations ABOVE their usage.
-- Write comments that explain "why" and use JSDoc to explain "what".
+- Write comments and JSDoc for complex or hard-to-understand code.
+  - Explain "why" in comments and "what" in JSDoc.
   - Avoid stating what can be easily understood from the code itself.
 - Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
-- Prefer using a single template literal for prompts instead of `join()` with an array of strings.
+- Prefer using a single template literal for prompts instead of `join()` with a pre-computable array literal of strings.
 - Assume that all environment variables are properly defined.
   - If validation is required, use `assert` to fail fast (e.g., during startup).

CLAUDE.md

@@ -9,22 +9,23 @@
 - Create a new branch if the current branch is `main`.
 - Run any `git` commands sequentially.
 - Write tests ONLY if explicitly requested. If requested, follow these rules:
-  - Continue modifying the tests and code until all tests pass.
-  - Ensure tests reset any related persistent data, as our test infrastructure does not clear it automatically.
-  - Prefer actual API calls over mocks. Use mocks when actual calls are impractical, have unintended side effects, or are explicitly requested.
+  - Continue modifying tests and/or code until all tests pass.
+  - Ensure tests are idempotent and independent (e.g., reset persistent data) so they can run repeatedly or in parallel.
+  - Prefer actual API calls over mocks, unless actual calls are impractical, have unintended side effects, or mocks are explicitly requested.
   - Always investigate the root cause of a test failure before fixing it.
-  - Avoid adding wait functions in E2E tests unless you are confident they are necessary.
+  - Avoid adding wait functions in E2E tests unless strictly necessary.
 - When fixing issues, follow these rules:
   - Investigate the root cause first (e.g., by gathering debug logs, taking screenshots, etc.).
   - Fix the actual root cause instead of applying workarounds.
-- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or `yarn check-for-ai` for only type checking and linting (takes up to 10 minutes).
-  - If you are confident that your changes will not break any tests, you may use `check-for-ai`.
+- After making code changes, run `yarn verify-full` to execute all tests (takes up to 1 hour), or `yarn verify` for only type checking and linting (takes up to 10 minutes).
+  - If you are confident that your changes will not break any tests, you may use `verify`.
   - Use `oxlint` ignore comments with reasons (e.g., `// oxlint-disable-next-line <rule> -- <reason>`) if lint errors or warnings cannot be fixed.
 - Once you have verified your changes, commit and push them to the current (non-main) branch, then create a PR via `gh`.
   - Follow the conventional commits; your commit message should start with `feat:`, `fix:`, etc.
   - If not specified, make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Claude Code) <agent@willbooster.com>`.
   - Always create new commits. Avoid using `--amend`.
 - Always use heredoc syntax when passing multi-line content to any command.
+- Use `wb start --mode test` to launch a web server for debugging or testing.
 
 ## Coding Style
 
@@ -36,9 +37,10 @@
 - Place calling functions above the functions they call to maintain a clear top-down order.
   - e.g., `function caller() { callee(); } function callee() { ... }`
   - Unlike functions, place variable and type declarations ABOVE their usage.
-- Write comments that explain "why" and use JSDoc to explain "what".
+- Write comments and JSDoc for complex or hard-to-understand code.
+  - Explain "why" in comments and "what" in JSDoc.
   - Avoid stating what can be easily understood from the code itself.
 - Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
-- Prefer using a single template literal for prompts instead of `join()` with an array of strings.
+- Prefer using a single template literal for prompts instead of `join()` with a pre-computable array literal of strings.
 - Assume that all environment variables are properly defined.
   - If validation is required, use `assert` to fail fast (e.g., during startup).

GEMINI.md

@@ -9,22 +9,23 @@
 - Create a new branch if the current branch is `main`.
 - Run any `git` commands sequentially.
 - Write tests ONLY if explicitly requested. If requested, follow these rules:
-  - Continue modifying the tests and code until all tests pass.
-  - Ensure tests reset any related persistent data, as our test infrastructure does not clear it automatically.
-  - Prefer actual API calls over mocks. Use mocks when actual calls are impractical, have unintended side effects, or are explicitly requested.
+  - Continue modifying tests and/or code until all tests pass.
+  - Ensure tests are idempotent and independent (e.g., reset persistent data) so they can run repeatedly or in parallel.
+  - Prefer actual API calls over mocks, unless actual calls are impractical, have unintended side effects, or mocks are explicitly requested.
   - Always investigate the root cause of a test failure before fixing it.
-  - Avoid adding wait functions in E2E tests unless you are confident they are necessary.
+  - Avoid adding wait functions in E2E tests unless strictly necessary.
 - When fixing issues, follow these rules:
   - Investigate the root cause first (e.g., by gathering debug logs, taking screenshots, etc.).
   - Fix the actual root cause instead of applying workarounds.
-- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or `yarn check-for-ai` for only type checking and linting (takes up to 10 minutes).
-  - If you are confident that your changes will not break any tests, you may use `check-for-ai`.
+- After making code changes, run `yarn verify-full` to execute all tests (takes up to 1 hour), or `yarn verify` for only type checking and linting (takes up to 10 minutes).
+  - If you are confident that your changes will not break any tests, you may use `verify`.
   - Use `oxlint` ignore comments with reasons (e.g., `// oxlint-disable-next-line <rule> -- <reason>`) if lint errors or warnings cannot be fixed.
 - Once you have verified your changes, commit and push them to the current (non-main) branch, then create a PR via `gh`.
   - Follow the conventional commits; your commit message should start with `feat:`, `fix:`, etc.
   - If not specified, make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Gemini CLI) <agent@willbooster.com>`.
   - Always create new commits. Avoid using `--amend`.
 - Always use heredoc syntax when passing multi-line content to any command.
+- Use `wb start --mode test` to launch a web server for debugging or testing.
 
 ## Coding Style
 
@@ -36,9 +37,10 @@
 - Place calling functions above the functions they call to maintain a clear top-down order.
   - e.g., `function caller() { callee(); } function callee() { ... }`
   - Unlike functions, place variable and type declarations ABOVE their usage.
-- Write comments that explain "why" and use JSDoc to explain "what".
+- Write comments and JSDoc for complex or hard-to-understand code.
+  - Explain "why" in comments and "what" in JSDoc.
   - Avoid stating what can be easily understood from the code itself.
 - Prefer `undefined` over `null` unless explicitly required by APIs or libraries.
-- Prefer using a single template literal for prompts instead of `join()` with an array of strings.
+- Prefer using a single template literal for prompts instead of `join()` with a pre-computable array literal of strings.
 - Assume that all environment variables are properly defined.
   - If validation is required, use `assert` to fail fast (e.g., during startup).

package.json

@@ -50,7 +50,9 @@
     "test:e2e:next": "yarn build && next build e2e/next-app && playwright test --config e2e/next-app/playwright.config.ts",
     "test:unit": "vitest",
     "test/ci-setup": "playwright install chromium",
-    "typecheck": "tsgo --noEmit"
+    "typecheck": "tsgo --noEmit",
+    "verify": "wb verify",
+    "verify-full": "wb verify --full"
   },
   "dependencies": {
     "@willbooster/monaco-loader": "1.1.1",
@@ -69,6 +71,7 @@
     "@typescript/native-preview": "7.0.0-dev.20260421.2",
     "@willbooster/oxfmt-config": "1.2.2",
     "@willbooster/oxlint-config": "1.4.6",
+    "@willbooster/wb": "13.12.9",
     "build-ts": "17.1.8",
     "conventional-changelog-conventionalcommits": "9.3.1",
     "jsdom": "29.0.2",