chore: willboosterify this repo

Author: WillBooster-bot

.cursor/rules/general.mdc

@@ -8,23 +8,26 @@ alwaysApply: true
 
 - Name: @exercode/problem-utils
 - Description: :100: A set of utilities for judging programs on Exercode (https://exercode.willbooster.com/).
-- Package Manager: yarn
+- Package Manager: yarn on zsh
 
 ## General Instructions
 
+- Create a new branch if the current branch is `main`.
 - Do not write tests unless explicitly requested.
 - When fixing tests, gather debug information through logging and screenshots before modifying the code.
-- After making code changes, run `yarn check-all-for-ai` to execute all tests (note: this may take up to 30 minutes), or run `yarn check-for-ai` for type checking and linting only.
+- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or run `yarn check-for-ai` for type checking and linting only (takes up to 10 minutes).
   - If you are confident your changes will not break any tests, you may use `check-for-ai`.
-- Once you have verified your changes, commit them to the non-main branch using the `--no-verify` option and push to the current branch.
-  - Follow conventional commits, i.e., your commit message should start with `feat:`, `fix:`, etc.
-  - Make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Cursor) <agent@willbooster.com>`.
+- Once you have verified your changes, commit them to a non-main branch using the `--no-verify` option and push to the current branch.
+  - Follow 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`.
 
 ## Coding Style
 
-- Write comments that explain "why" rather than "what". Avoid explanations that can be understood from the code itself.
-- Use stderr for logging debug messages temporarily since stdout output is sometimes omitted.
-- When adding new functions or classes, define them below any functions or classes that call them to maintain clear call order.
-- Prefer `undefined` over `null` unless explicitly dealing with APIs or libraries that require `null`.
-- Always perform existence checks on array due to `noUncheckedIndexedAccess: true`.
+- Simplify code as much as possible to eliminate redundancy.
+- 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.
+- When adding new functions or classes, define them below any functions or classes that call them to maintain a clear top-down call order.
+- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- Prefer `undefined` over `null` unless explicitly required by APIs or libraries.

.husky/pre-commit

@@ -1,3 +1,5 @@
+#!/bin/bash
+
 changed_files="$(git diff-tree -r --name-only --no-commit-id ORIG_HEAD HEAD)"
 
 run_if_changed() {
@@ -6,7 +8,5 @@ run_if_changed() {
   fi
 }
 
-run_if_changed "\..+-version" "awk '{print \$1}' .tool-versions | xargs -I{} asdf plugin add {}"
-run_if_changed "\..+-version" "asdf plugin update --all"
-run_if_changed "\..+-version" "asdf install"
+run_if_changed "(mise\.toml|\.mise\.toml|\.tool-versions|\..+-version)" "mise install"
 run_if_changed "package\.json" "yarn"

.husky/pre-push

@@ -0,0 +1 @@
+yarn run typecheck

.husky/post-merge .lefthook/post-merge/prepare.sh.husky/post-merge renamed to .lefthook/post-merge/prepare.sh

@@ -1,6 +1,5 @@
-const fs = require('node:fs');
-const path = require('node:path');
-
+const fs = require('fs');
+const path = require('path');
 const micromatch = require('micromatch');
 
 module.exports = {
@@ -25,7 +24,7 @@ module.exports = {
   },
   './**/migration.sql': (files) => {
     for (const file of files) {
-      const content = fs.readFileSync(file, 'utf8');
+      const content = fs.readFileSync(file, 'utf-8');
       if (content.includes('Warnings:')) {
         return [
           `echo '!!! Migration SQL file (${path.relative('', file)}) contains warnings !!! Solve the warnings and commit again.'`,

.lefthook/pre-push/check.sh

@@ -2,23 +2,26 @@
 
 - Name: @exercode/problem-utils
 - Description: :100: A set of utilities for judging programs on Exercode (https://exercode.willbooster.com/).
-- Package Manager: yarn
+- Package Manager: yarn on zsh
 
 ## General Instructions
 
+- Create a new branch if the current branch is `main`.
 - Do not write tests unless explicitly requested.
 - When fixing tests, gather debug information through logging and screenshots before modifying the code.
-- After making code changes, run `yarn check-all-for-ai` to execute all tests (note: this may take up to 30 minutes), or run `yarn check-for-ai` for type checking and linting only.
+- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or run `yarn check-for-ai` for type checking and linting only (takes up to 10 minutes).
   - If you are confident your changes will not break any tests, you may use `check-for-ai`.
-- Once you have verified your changes, commit them to the non-main branch using the `--no-verify` option and push to the current branch.
-  - Follow conventional commits, i.e., your commit message should start with `feat:`, `fix:`, etc.
-  - Make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Codex CLI) <agent@willbooster.com>`.
+- Once you have verified your changes, commit them to a non-main branch using the `--no-verify` option and push to the current branch.
+  - Follow 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`.
 
 ## Coding Style
 
-- Write comments that explain "why" rather than "what". Avoid explanations that can be understood from the code itself.
-- Use stderr for logging debug messages temporarily since stdout output is sometimes omitted.
-- When adding new functions or classes, define them below any functions or classes that call them to maintain clear call order.
-- Prefer `undefined` over `null` unless explicitly dealing with APIs or libraries that require `null`.
-- Always perform existence checks on array due to `noUncheckedIndexedAccess: true`.
+- Simplify code as much as possible to eliminate redundancy.
+- 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.
+- When adding new functions or classes, define them below any functions or classes that call them to maintain a clear top-down call order.
+- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- Prefer `undefined` over `null` unless explicitly required by APIs or libraries.

.lintstagedrc.cjs

@@ -2,23 +2,26 @@
 
 - Name: @exercode/problem-utils
 - Description: :100: A set of utilities for judging programs on Exercode (https://exercode.willbooster.com/).
-- Package Manager: yarn
+- Package Manager: yarn on zsh
 
 ## General Instructions
 
+- Create a new branch if the current branch is `main`.
 - Do not write tests unless explicitly requested.
 - When fixing tests, gather debug information through logging and screenshots before modifying the code.
-- After making code changes, run `yarn check-all-for-ai` to execute all tests (note: this may take up to 30 minutes), or run `yarn check-for-ai` for type checking and linting only.
+- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or run `yarn check-for-ai` for type checking and linting only (takes up to 10 minutes).
   - If you are confident your changes will not break any tests, you may use `check-for-ai`.
-- Once you have verified your changes, commit them to the non-main branch using the `--no-verify` option and push to the current branch.
-  - Follow conventional commits, i.e., your commit message should start with `feat:`, `fix:`, etc.
-  - Make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Claude Code) <agent@willbooster.com>`.
+- Once you have verified your changes, commit them to a non-main branch using the `--no-verify` option and push to the current branch.
+  - Follow 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`.
 
 ## Coding Style
 
-- Write comments that explain "why" rather than "what". Avoid explanations that can be understood from the code itself.
-- Use stderr for logging debug messages temporarily since stdout output is sometimes omitted.
-- When adding new functions or classes, define them below any functions or classes that call them to maintain clear call order.
-- Prefer `undefined` over `null` unless explicitly dealing with APIs or libraries that require `null`.
-- Always perform existence checks on array due to `noUncheckedIndexedAccess: true`.
+- Simplify code as much as possible to eliminate redundancy.
+- 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.
+- When adding new functions or classes, define them below any functions or classes that call them to maintain a clear top-down call order.
+- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- Prefer `undefined` over `null` unless explicitly required by APIs or libraries.

AGENTS.md

@@ -2,23 +2,26 @@
 
 - Name: @exercode/problem-utils
 - Description: :100: A set of utilities for judging programs on Exercode (https://exercode.willbooster.com/).
-- Package Manager: yarn
+- Package Manager: yarn on zsh
 
 ## General Instructions
 
+- Create a new branch if the current branch is `main`.
 - Do not write tests unless explicitly requested.
 - When fixing tests, gather debug information through logging and screenshots before modifying the code.
-- After making code changes, run `yarn check-all-for-ai` to execute all tests (note: this may take up to 30 minutes), or run `yarn check-for-ai` for type checking and linting only.
+- After making code changes, run `yarn check-all-for-ai` to execute all tests (takes up to 1 hour), or run `yarn check-for-ai` for type checking and linting only (takes up to 10 minutes).
   - If you are confident your changes will not break any tests, you may use `check-for-ai`.
-- Once you have verified your changes, commit them to the non-main branch using the `--no-verify` option and push to the current branch.
-  - Follow conventional commits, i.e., your commit message should start with `feat:`, `fix:`, etc.
-  - Make sure to add a new line at the end of your commit message with: `Co-authored-by: WillBooster (Gemini CLI) <agent@willbooster.com>`.
+- Once you have verified your changes, commit them to a non-main branch using the `--no-verify` option and push to the current branch.
+  - Follow 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`.
 
 ## Coding Style
 
-- Write comments that explain "why" rather than "what". Avoid explanations that can be understood from the code itself.
-- Use stderr for logging debug messages temporarily since stdout output is sometimes omitted.
-- When adding new functions or classes, define them below any functions or classes that call them to maintain clear call order.
-- Prefer `undefined` over `null` unless explicitly dealing with APIs or libraries that require `null`.
-- Always perform existence checks on array due to `noUncheckedIndexedAccess: true`.
+- Simplify code as much as possible to eliminate redundancy.
+- 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.
+- When adding new functions or classes, define them below any functions or classes that call them to maintain a clear top-down call order.
+- Write comments that explain "why" rather than "what". Avoid stating what can be understood from the code itself.
+- Prefer `undefined` over `null` unless explicitly required by APIs or libraries.

CLAUDE.md

@@ -0,0 +1,20 @@
+post-merge:
+  scripts:
+    prepare.sh:
+      runner: bash
+pre-push:
+  scripts:
+    check.sh:
+      runner: bash
+pre-commit:
+  commands:
+    cleanup:
+      glob: '*.{cjs,css,cts,htm,html,js,json,json5,jsonc,jsx,md,mjs,mts,scss,ts,tsx,vue,yaml,yml}'
+      run: yarn run cleanup && git add {staged_files}
+    check-migrations:
+      glob: '**/migration.sql'
+      run: |-
+        if grep -q 'Warnings:' {staged_files}; then
+          echo "Migration SQL files ({staged_files}) contain warnings! Please solve the warnings and commit again."
+          exit 1
+        fi