chore: willboosterify this repo

.cursor/rules/general.mdc

@@ -18,6 +18,8 @@ alwaysApply: true
   - 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.
+  - 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.
 - 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.
@@ -28,6 +30,7 @@ alwaysApply: true
   - 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.
 
 ## Coding Style
 
@@ -36,8 +39,10 @@ alwaysApply: true
 - Design each module with high cohesion, grouping related functionality together.
   - Refactor existing large modules into smaller, focused modules when necessary.
   - Create well-organized directory structures with low coupling and high cohesion.
-- Place calling functions in the file above the functions they call to maintain a clear top-down order.
-  - e.g. `function caller() { callee(); } function callee() { ... }`
-- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- 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".
+  - 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.

.gemini/styleguide.md

@@ -7,8 +7,10 @@ Review in English based on the following coding standards.
 - Design each module with high cohesion, grouping related functionality together.
   - Refactor existing large modules into smaller, focused modules when necessary.
   - Create well-organized directory structures with low coupling and high cohesion.
-- Place calling functions in the file above the functions they call to maintain a clear top-down order.
-  - e.g. `function caller() { callee(); } function callee() { ... }`
-- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- 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".
+  - 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.

.lefthook/pre-push/check.sh

@@ -1 +1 @@
-yarn run lint
+yarn run lint --quiet

AGENTS.md

@@ -12,6 +12,8 @@
   - 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.
+  - 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.
 - 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.
@@ -22,6 +24,7 @@
   - 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.
 
 ## Coding Style
 
@@ -30,8 +33,10 @@
 - Design each module with high cohesion, grouping related functionality together.
   - Refactor existing large modules into smaller, focused modules when necessary.
   - Create well-organized directory structures with low coupling and high cohesion.
-- Place calling functions in the file above the functions they call to maintain a clear top-down order.
-  - e.g. `function caller() { callee(); } function callee() { ... }`
-- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- 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".
+  - 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.

CLAUDE.md

@@ -12,6 +12,8 @@
   - 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.
+  - 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.
 - 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.
@@ -22,6 +24,7 @@
   - 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.
 
 ## Coding Style
 
@@ -30,8 +33,10 @@
 - Design each module with high cohesion, grouping related functionality together.
   - Refactor existing large modules into smaller, focused modules when necessary.
   - Create well-organized directory structures with low coupling and high cohesion.
-- Place calling functions in the file above the functions they call to maintain a clear top-down order.
-  - e.g. `function caller() { callee(); } function callee() { ... }`
-- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- 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".
+  - 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.

GEMINI.md

@@ -12,6 +12,8 @@
   - 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.
+  - 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.
 - 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.
@@ -22,6 +24,7 @@
   - 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.
 
 ## Coding Style
 
@@ -30,8 +33,10 @@
 - Design each module with high cohesion, grouping related functionality together.
   - Refactor existing large modules into smaller, focused modules when necessary.
   - Create well-organized directory structures with low coupling and high cohesion.
-- Place calling functions in the file above the functions they call to maintain a clear top-down order.
-  - e.g. `function caller() { callee(); } function callee() { ... }`
-- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- 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".
+  - 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.

package.json

@@ -69,7 +69,7 @@
     "@types/node": "25.6.0",
     "@types/react": "19.2.14",
     "@types/react-dom": "19.2.3",
-    "@typescript/native-preview": "7.0.0-dev.20260419.1",
+    "@typescript/native-preview": "7.0.0-dev.20260421.2",
     "@willbooster/oxfmt-config": "1.2.1",
     "@willbooster/oxlint-config": "1.4.4",
     "build-ts": "17.1.6",
@@ -78,7 +78,7 @@
     "lefthook": "2.1.5",
     "next": "16.2.4",
     "oxfmt": "0.45.0",
-    "oxlint": "1.60.0",
+    "oxlint": "1.61.0",
     "oxlint-tsgolint": "0.21.0",
     "react": "19.2.5",
     "react-dom": "19.2.5",