chore: willboosterify this repo

.cursor/rules/general.mdc

@@ -15,16 +15,16 @@ 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.
@@ -42,9 +42,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).

.gitignore

@@ -18,6 +18,7 @@
 __generated__/
 @willbooster/
 dist/
+drizzle/mount/
 temp/
 tmp/
 

.prettierignore

@@ -28,6 +28,7 @@ test/fixtures/
 __generated__/
 @willbooster/
 dist/
+drizzle/mount/
 temp/
 tmp/
 

AGENTS.md

@@ -9,16 +9,16 @@
 - 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.
@@ -36,9 +36,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,16 +9,16 @@
 - 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.
@@ -36,9 +36,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,16 +9,16 @@
 - 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.
@@ -36,9 +36,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).

oxlint.config.ts

@@ -1,3 +1,7 @@
+// wbfy:start oxlint-base
 import config from '@willbooster/oxlint-config';
+// wbfy:end oxlint-base
 
+// wbfy:start oxlint-export
 export default config;
+// wbfy:end oxlint-export

package.json

@@ -46,7 +46,9 @@
     "start": "build-ts run src/index.ts",
     "test": "rm -fr temp && dotenv -c test -- vitest test",
     "test/ci-setup": "yarn build && bun install --cwd example",
-    "typecheck": "tsgo --noEmit"
+    "typecheck": "tsgo --noEmit",
+    "verify": "wb verify",
+    "verify-full": "wb verify --full"
   },
   "prettier": "@willbooster/prettier-config",
   "dependencies": {
@@ -67,6 +69,7 @@
     "@willbooster/oxfmt-config": "1.2.2",
     "@willbooster/oxlint-config": "1.4.6",
     "@willbooster/prettier-config": "10.4.0",
+    "@willbooster/wb": "13.12.9",
     "build-ts": "17.1.8",
     "conventional-changelog-conventionalcommits": "9.3.1",
     "dotenv-cli": "11.0.0",