towry · towry · Oct 16, 2025 · Oct 14, 2025 · Oct 15, 2025 · Oct 15, 2025
diff --git a/.claude/settings.local.json b/.claude/settings.local.json
@@ -1,8 +1,8 @@
 {
   "permissions": {
     "allow": [
-      "mcp__datetime__get-current-time",
-      "mcp__grep-code__searchGitHub"
+      "mcp__grep-code__searchGitHub",
+      "Bash(fd:*)"
     ],
     "deny": [],
     "ask": []

diff --git a/.trae/rules/project_rules.md b/.trae/rules/project_rules.md
diff --git a/.vscode/settings.json b/.vscode/settings.json
@@ -1,5 +1,4 @@
 {
-    "kiroAgent.configureMCP": "Disabled",
     "files.exclude": {
         "**/.git": true,
         "**/.svn": true,

diff --git a/conf/ghostty/config b/conf/ghostty/config
@@ -9,7 +9,7 @@ window-title-font-family = "PT Sans"
 font-feature = "+calt"
 # font-family = "Maple Mono"
 # font-feature = "-zero, +calt, +cv01, +ss03, +ss06, +ss02, -cv35"
-font-size = 15
+font-size = 14
 bold-is-bright = true
 font-thicken = false
 font-codepoint-map = U+4E00-U+9FFF,U+3400-U+4DBF=LXGW WenKai Mono

diff --git a/conf/ghostty/config-default-keybind b/conf/ghostty/config-default-keybind
@@ -36,7 +36,7 @@ keybind = super+0=toggle_split_zoom
 # select all
 keybind = super+a=select_all
 # clear screen
-keybind = ctrl+l=clear_screen
+# keybind = ctrl+l=clear_screen
 # scroll to top
 keybind = ctrl+a>y=scroll_to_top
 # # scroll to bottom

diff --git a/conf/llm/docs/coding-rules.md b/conf/llm/docs/coding-rules.md
@@ -1,93 +1,113 @@
-# Core Principles
-
-Avoid over-engineering. Prefer simple, correct, and maintainable solutions.
-
-- use existing fd, rg modern command tools, do not use find, grep that are not installed.
-- When search files, grep for file content, use `fd` and `rg` instead of `find` and `grep`, `find` or `grep` is not installed.
-- Prioritize project conventions over general best practices
-- *Maintainability*: Long-term convenience over short-term hacks
-- Avoid over-engineering and unnecessary complexity
-- *Pragmatic Solutions*: Favor obviously correct code over clever tricks
-- Ensuring every abstraction justifies
-- Complexity is only introduced when it solves real problems
-- Be Organized: Use numbered items format when providing options or steps
-- Gather Context: Ask for missing info before implementing
-- Explicit over Implicit: If the intent is unclear, provide a list of guessed options and allow the user to make a selection
-- Separation of Concerns: Keep boundaries clear; confirm before crossing layers
-- Be Humble: Recognize your limitations and seek assistance when facing challenges, use `brightdata` mcp tool when you lacking knowledge in a specific area, or you not familiar with the latest trends and best practices, tool uses, libraries, or frameworks.
-- Ask user approval after plan is approved with "Do you want me to proceed with the implementation?"
-- Correct user's English grammar and spelling mistakes, ensuring not to alter any quoted or copied content such as code snippets, by starting with "Let's rephrase for clarity: "
-
-# When implementing and fixing
-
-- Clarify Requirements: Ask questions when tasks are unclear
-- Validate Requirements: Identify key specifications and edge cases
-- Break Down Tasks: Split complex tasks into small, verifiable steps for better clarity and manageability
-- Consider Scope: check impact on surrounding code
+# Agent Rules
+
+## Critical
+
+- Avoid over-engineering, only write coding that explicitly addresses the user's request.
+- **Easy to reference your options**: Use numbered lists for options, steps, or requirements, so user can use number to reference the choice.
+- **Be Transparent**: Use FIXME, TODO, NOTE when relevant.
+- **Be Clear**: Document non-obvious logic and the purpose of complex functions.
+- **Explicit over Implicit**: If the intent is unclear, provide a list of guessed options and allow the user to make a selection.
+- **Keep boundaries clear**: UI components should not contain business logic, demo code, debug logic, temporary code, or mock code.
+- **Be Humble**: Recognize your limitations and seek assistance when facing challenges.
+- Seek user approval for your implementation plan before proceeding.
+- Correct user's English grammar and spelling mistakes, ensuring not to alter any quoted or copied content such as code snippets, by starting with "Let's rephrase for clarity: ".
+- **Ability**: You know everything about code, with `codex` mcp tool, you can search any local codebase in any workspaces; With web search tool, brightdata, you can search anything on the web, and scrape html content; with grep-code mcp tool (if available), you can search code patterns from GitHub public codebase.
+- **Allowed search dirs**: `$HOME/workspace/`, `/tmp`; do not search on `$HOME` root directory;
+
+## Plan
+
+- Prioritize existing codebase convention over edge-cutting best practices, search for `.github/instructions/*.md`, `.windsurf/rules/` for project convention rules, use `codex` mcp tool for codebase research.
+- Plan based on existing similar functionality, unless user explicitly requests otherwise, for example, When implement feature X, with slightly difference between feature Y, then plan based on feature Y, search if there are similar feature Y at the start of plan; It is ok to explicitly ask for such information about similar feature.
+- Each implementation step should contain file location and changes.
+- Add verification steps to the plan, options: unit testing; playwright interactive verify; manually verify.
+
+## Review
+
+- Read project AGENTS.md and `~/.config/AGENTS.md`, or your instructions, ensure changes follow the coding rules, especially the `## Critical` section.
+- Check if code changes is unused or disconnected from the system, for example, added an event handler function/method, but did not bind to the ui component, cause event flow disruption.
+- **correct code reference**: For api, constant, variable usage, use `ast-grep` or `rg` to fast search for code patterns, ensure no assumption code added, for example, added `this.userType = 123`, but `userType` with value `123` is none-sense in the project.
+
+## Implementation
+
+- **Prioritize functionality**: Ensure the core features work correctly before optimizing or adding enhancements, like excessive ui animations.
+- **Clarify Requirements**: Ask questions when tasks are unclear.
+- **Validate Requirements**: Identify key specifications and edge cases.
+- **Break Down Tasks**: Split complex tasks into small, verifiable steps for better clarity and manageability.
 - Avoid integrating _mock code_ or _demo code_ into intermediate layers. Ensure that the foundational implementation(components, modules) is finalized, and contain all mocking/demo behavior in the highest layer.
-- Use annotations like FIXME, TODO, and NOTE to highlight areas that require attention, further improvement, or documentation for future reference
-- Use descriptive constants instead of magic numbers (e.g., const MAX_RETRIES =
-  3).
-- Prefer dependency injection and localized state over globals: allow direct
-  access in small standalone scripts or configuration files where DI overhead
-  outweighs its benefit.
-- Use explicit parameter passing instead of parent/ambient access
-- Don’t break existing functionality without understanding impact
-- Only modify code relevant to the task: any cross-module or cross-layer changes
-  must be documented and justified.
-- Prefer simple solutions that minimize side effects and blast radius
+- Use annotations like FIXME, TODO, and NOTE to highlight areas that require attention, further improvement, or documentation for future reference.
+- Use descriptive constants instead of magic numbers (e.g., `const MAX_RETRIES = 3`).
+- Prefer dependency injection and localized state over globals: allow direct access in small standalone scripts or configuration files where DI overhead outweighs its benefit.
+- **function/method**: Use explicit parameter passing instead of parent/ambient access.
+- Only modify code relevant to the task: any cross-module or cross-layer changes must be documented and justified.
 - **Fail Fast, Don't Hide Bugs**: Avoid using try-catch blocks, optional chaining (`?.`), or other defensive coding techniques to silence errors that indicate a contract violation. Instead, prefer fail-fast and allow the system to quickly detect and report errors. If an object is expected to have a certain method or property, its absence is a bug that should be surfaced immediately. Hiding such errors leads to deferred failures that are much harder to debug.
 
-**Good function signature design**
-
-- Pass only needed primitives, not entire objects
-- Use clear parameter names that reveal purpose
-- When passing objects, document exact properties used
-
-Example: ✗ Bad: `downloadResume(candidateData, $store, componentInstance)` ✓
-Good: `downloadResume(candidateId, candidateName, authToken)`
-
-**Error Handling**
-
-1. Prefer explicit error propagation over silent failures
-2. Validate behavior preservation during refactoring
-3. Update documentation and tests for significant changes
-4. Ask for help when details are needed for decisions
-5. Avoid duplicate user-facing error messages across layers
-
-# When testing
-
-1. Use BDD: GIVEN/WHEN/THEN
-2. Write descriptive test names by scenario
-3. Use `actual` for results and `expected` for assertions
-4. Test one behavior per test
-
-# When debugging
-
-1. Verify that no existing debug or development processes are running
-2. Run shell command `curl -I <dev-server-address>` to check dev server before
-   starting a new one
-3. Ask user to commit current changes before running lint/format to avoid unexpected
-   diffs
-
-# When researching/refactoring code
-
-Your bash environment has access to some useful non-default tools:
-
-- *MCP tools* When using MCP tools, provide absolute file paths
-- Package Managers: Detect the correct one (npm/pnpm/yarn)
-- *killport*: Kill process that owning a port: `killport <port>`
-- *fish*: the default shell is fish
-- *Git* View file changed vs main in git repo: `jj df-file-base <file-path>`
-- *Git* View file changed vs previous commit in git repo: `jj df-file-prev <file-path>`
-- *brightdata* mcp tool to fetch latest context from the web, like version, framework tools, documentation.
-- "fd" is a simple, fast and user-friendly alternative to "find". 
-- "rg" (ripgrep) is a line-oriented search tool that recursively searches the current directory for a regex pattern. It is similar to "grep", but faster and more user-friendly.
-- `ast-grep`. It is described as "a fast and polyglot tool for code structural search, lint, rewriting at large scale." More info at https://ast-grep.github.io/llms.txt
-- `fastmod` is a code modification tool forked from codemod. Very useful for large refactors or refactoring code. When applicable, use fastmod over grepping for usages and manually editing the file.
-- `concurrently` is a tool to run multiple commands concurrently. Useful for starting dev server and running tests/watchers in parallel.
-- `jq` is a lightweight and flexible command-line JSON processor. Useful for parsing and manipulating JSON data in shell scripts or command line.
-- `bun` and `bunx` are modern JavaScript runtimes and package managers. They are designed to be fast and efficient, with a focus on performance and developer experience.
-- `pnpm` is a fast, disk space efficient package manager. It is an alternative to npm and yarn, and is designed to be faster and more efficient.
-- `watchexec` is a tool to run commands when files change. Useful for running tests or linters when code changes.
-- `scc` is a tool to count lines of code. Useful for getting a quick overview of the size of a codebase.
+### Function Signature Design
+
+- Pass only needed primitives, not entire objects.
+- Use clear parameter names that reveal purpose.
+- When passing objects, document exact properties used.
+
+**Example**:
+- ✗ **Bad**: `downloadResume(candidateData, $store, componentInstance)`
+- ✓ **Good**: `downloadResume(candidateId, candidateName, authToken)`
+
+### Error Handling
+
+- Prefer explicit error propagation over silent failures.
+- Validate behavior preservation during refactoring.
+- Update documentation and tests for significant changes.
+- Ask for help when details are needed for decisions.
+- Avoid duplicate user-facing error messages across layers.
+
+## Testing
+
+- **Use BDD**: GIVEN/WHEN/THEN
+- Write descriptive test names by scenario.
+- Use `actual` for results and `expected` for assertions.
+- Test one behavior per test.
+
+## Debugging
+
+- Verify that no existing debug or development processes are running.
+- Run shell command `curl -I $dev-server-address$` to check dev server before starting a new one.
+- Ask user to commit current changes before running lint/format to avoid unexpected diffs.
+
+## Tool Usage
+
+- **grep**: Whenever a search requires syntax-aware or structural matching, use `ast-grep run --lang ? --pattern ? [PATHS]...` (set `--lang` appropriately, default to lang in `lang` tags), fallback to text-only tool `rg`.
+- **find**: To search for files, use `fd`. The `find` shell command is deprecated and removed.
+- **Package Managers**: Use pnpm when possible.
+- **port occupied**: To kill a process that is using a port, use `killport $port$`.
+- **shell**: The current shell is `fish`.
+- **git**: To view file changes against the main branch, use `jj df-file-base ?file-path?`.
+- **git**: To view file changes against the previous commit, use `jj df-file-prev ?file-path?`.
+- **search web and scrape html**: Use the `brightdata` mcp tool to fetch the latest context from the web, like version, framework tools, and documentation.
+- *codex*: Use the `codex` mcp tool with specific profile for different tasks, "sage" profile for codebase research, "claude" for high reasoning tasks; 'claude_fast' for low reasoning task; Do not use model argument; Limit the cwd argument up to the allowed search dirs in our critical rule; do not use `cwd` argument, include the cwd in the `prompt` argument.
+
+### codex codebase research usage example
+
+```json
+{
+  "prompt": "Search xxx in cwd: yyy",
+  "profile": "sage"
+}
+```
+
+### GitHub Code Search, do not use this when request for local codebase search
+
+*Pattern search code from GitHub with the tool in `mcp-grep-code` tags, default to `grep-code` mcp tool, example:*
+
+```json
+{
+ "query": "(?s)server\\.tool.*catch",
+ "language": [
+  "TypeScript",
+  "JavaScript"
+ ],
+ "useRegexp": true
+}
+```
+
+## Troubleshooting for tool issues
+
+- grep, search failed with our builtin tools, try use `codex` mcp tool with "sage" profile.
diff --git a/conf/llm/opencode/opencode.jsonc b/conf/llm/opencode/opencode.jsonc
@@ -128,9 +128,13 @@
     },
     "permission": {
         "bash": {
-            "*": "ask",
             "git commit": "ask",
-            "git add": "ask"
+            "git add": "ask",
+            "rg": "allow",
+            "ast-grep": "allow",
+            "fd": "allow",
+            "ls": "allow",
+            "cd": "allow"
         },
         "edit": "allow",
         "webfetch": "ask"
@@ -184,11 +188,6 @@
                 "Z_AI_API_KEY": "{env:ZAI_API_KEY}"
             }
         },
-        // "tidewave": {
-        //     "type": "remote",
-        //     "url": "http://localhost:4000/tidewave/mcp",
-        //     "enabled": false
-        // },
         "github": {
             "type": "local",
             "command": [
@@ -202,14 +201,6 @@
                 "GITHUB_PERSONAL_ACCESS_TOKEN": "{env:GITHUB_PERSONAL_ACCESS_TOKEN}"
             }
         },
-        "datetime": {
-            "type": "local",
-            "command": [
-                "bunx",
-                "@odgrim/mcp-datetime"
-            ],
-            "enabled": true
-        },
         "mermaid": {
             "type": "local",
             "command": [

diff --git a/conf/llm/windsurf/rules.md b/conf/llm/windsurf/rules.md
@@ -0,0 +1,11 @@
+# Windsurf Agent Rules
+
+## Tools
+
+- When user request like "use codex", "research codebase", just use `codex` mcp tool.
+- code research in all local workspaces: Use `codex` mcp tool to search local codebase in any workspaces, use it to ask for implementation details of any code, must provide codebase directory in the prompt and use "sage" profile
+- Do not use `codex-reply` in `codex`, it has bugs.
+- Please be explicit when using `codex`, provide sufficient context to `codex` to speed up the search process. In follow up search, you must not assume codex has previous search context, `codex` does not preserve search context; Must use "sage" for "profile" argument (critical);
+- `codex` is powerful but a bit slow, so use it only search code outside of current project.
+
+@CONTENT@
diff --git a/conf/llm/windsurf/workflows/kick-muse.md b/conf/llm/windsurf/workflows/kick-muse.md