chore(deps): bump the console-production group across 1 directory with 11 updates

.agents/rules/antigravity-rtk-rules.md

@@ -0,0 +1,32 @@
+# RTK - Rust Token Killer (Google Antigravity)
+
+**Usage**: Token-optimized CLI proxy for shell commands.
+
+## Rule
+
+Always prefix shell commands with `rtk` to minimize token consumption.
+
+Examples:
+
+```bash
+rtk git status
+rtk cargo test
+rtk ls src/
+rtk grep "pattern" src/
+rtk find "*.rs" .
+rtk docker ps
+rtk gh pr list
+```
+
+## Meta Commands
+
+```bash
+rtk gain              # Show token savings
+rtk gain --history    # Command history with savings
+rtk discover          # Find missed RTK opportunities
+rtk proxy <cmd>       # Run raw (no filtering, for debugging)
+```
+
+## Why
+
+RTK filters and compresses command output before it reaches the LLM context, saving 60-90% tokens on common operations. Always use `rtk <cmd>` instead of raw commands.

.agents/skills/arthas-mcp-pm2-integration/SKILL.md

@@ -0,0 +1,115 @@
+# Arthas MCP Server Integration with PM2
+
+**Extracted:** 2026-06-05
+**Context:** Adding Arthas MCP (Model Context Protocol) server to a Spring Boot project managed by PM2, so Codex can call Arthas diagnostic tools directly.
+
+## Problem
+
+Integrating Arthas MCP into PM2-managed projects has multiple pitfalls:
+- arthas-boot.jar CLI parameter parsing errors
+- Process lifecycle mismatch (agent runs in target JVM, not the boot process)
+- Health check false negatives (Spring Boot root path returns 302/401)
+- Path resolution issues in PM2-managed scripts
+
+## Solution
+
+### 1. arthas-boot.jar parameter gotchas
+
+| Parameter | Issue | Correct approach |
+|-----------|-------|-----------------|
+| `--properties-file` | **NOT supported** by arthas-boot.jar (it parses this as PID, causing `NumberFormatException`) | Put config in `~/.arthas/arthas.properties` — Arthas auto-loads it |
+| `--telnet-port -1` | **Causes `port out of range`** exception | Omit the flag entirely; telnet is enabled by default on 3658 |
+| `--http-port 8563` | ✅ Works — enables HTTP/MCP endpoint | This is the MCP port |
+| `--attach-only` | ✅ Works — attaches agent then exits boot process | PM2 must use `autorestart: false` |
+
+### 2. Startup script pattern
+
+```bash
+#!/usr/bin/env bash
+set -euo pipefail
+
+# Use CLAUDE_PROJECT_DIR, NOT script's own directory
+PROJECT_DIR="${CLAUDE_PROJECT_DIR:-$(cd "$(dirname "$0")/.." && pwd)}"
+ARTHAS_JAR="${PROJECT_DIR}/tools/arthas-boot.jar"
+ARTHAS_PORT=8563
+SPRING_BOOT_PORT=9001
+MAX_WAIT=120
+
+# Install arthas.properties to ~/.arthas/ (auto-loaded by Arthas)
+ARTHAS_HOME="${HOME}/.arthas"
+mkdir -p "$ARTHAS_HOME"
+if [ ! -f "${ARTHAS_HOME}/arthas.properties" ]; then
+  cat > "${ARTHAS_HOME}/arthas.properties" << 'EOF'
+arthas.mcpEndpoint=/mcp
+arthas.mcpProtocol=STREAMABLE
+EOF
+fi
+
+# Wait for Spring Boot using PORT CHECK, NOT curl
+# (curl fails because root path may return 302/401)
+elapsed=0
+while [ $elapsed -lt $MAX_WAIT ]; do
+  if lsof -ti :$SPRING_BOOT_PORT > /dev/null 2>&1; then
+    break
+  fi
+  sleep 2
+  elapsed=$((elapsed + 2))
+done
+
+# Check if already attached (MCP port already listening)
+if lsof -ti :$ARTHAS_PORT > /dev/null 2>&1; then
+  exit 0
+fi
+
+APP_PID=$(lsof -ti :$SPRING_BOOT_PORT | head -1)
+
+# --attach-only: boot process exits, but MCP agent runs in target JVM
+java -jar "$ARTHAS_JAR" \
+  --attach-only \
+  --http-port $ARTHAS_PORT \
+  "$APP_PID"
+```
+
+### 3. PM2 ecosystem config entry
+
+```javascript
+{
+  name: 'ulticode-arthas',
+  script: './scripts/start-arthas.sh',
+  interpreter: 'bash',
+  autorestart: false,  // CRITICAL: agent lives in target JVM, not boot process
+  kill_timeout: 10000,
+  ...logConfig('arthas'),
+  env: { ...envFromFile }
+}
+```
+
+### 4. `.mcp.json` for Codex
+
+```json
+{
+  "mcpServers": {
+    "arthas-mcp": {
+      "type": "http",
+      "url": "http://localhost:8563/mcp"
+    }
+  }
+}
+```
+
+Use `"type": "http"` (Codex official). `"streamableHttp"` is the MCP spec name and accepted as alias, but `"http"` is canonical.
+
+### 5. arthas.properties content
+
+```properties
+arthas.mcpEndpoint=/mcp
+arthas.mcpProtocol=STREAMABLE
+```
+
+## When to Use
+
+- Adding Arthas MCP server to any Spring Boot + PM2 project
+- When `java -jar arthas-boot.jar` throws `NumberFormatException: For input string: "--properties-file"`
+- When `--telnet-port -1` throws `port out of range`
+- When PM2 restarts Arthas process in a loop (agent lifecycle mismatch)
+- When Spring Boot health check `curl -sf` returns non-200

.agents/skills/caveman/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: caveman
+description: >
+  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
+  filler, articles, and pleasantries while keeping full technical accuracy.
+  Use when user says "caveman mode", "talk like caveman", "use caveman",
+  "less tokens", "be brief", or invokes /caveman.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
+
+Technical terms stay exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+### Examples
+
+**"Why React component re-render?"**
+
+> Inline obj prop -> new ref -> re-render. `useMemo`.
+
+**"Explain database connection pooling."**
+
+> Pool = reuse DB conn. Skip handshake -> fast under load.
+
+## Auto-Clarity Exception
+
+Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.
+
+Example -- destructive op:
+
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+>
+> ```sql
+> DROP TABLE users;
+> ```
+>
+> Caveman resume. Verify backup exist first.

.agents/skills/cpu-high/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: arthas-cpu-high
+description: Diagnose JVM / application CPU spikes via thread identification and code path analysis using Arthas
+---
+
+# JVM CPU 飙高排查指南（Arthas）
+
+适用场景：机器 CPU 飙高、应用响应变慢、负载异常升高。
+
+原则：先用低风险工具定位「哪个线程在忙」，再逐步缩小到「哪个方法/代码路径」。
+
+## 1) 先确认当前 JVM 整体状态（低风险）
+
+- 使用 `dashboard` 查看 CPU/线程/GC 概况（建议设置有限次数）：
+  - 关注：CPU、线程数、GC 次数/耗时是否异常。
+
+## 2) 定位最忙线程（关键步骤）
+
+- 使用 `thread` 找出最忙的前 N 个线程并打印堆栈：
+  - 例如：`topN=3` 或 `topN=5`
+- 记录每个热点线程的 `threadId` 与堆栈关键方法名。
+
+判断方向：
+- 如果堆栈显示在 `java.util.regex`、JSON 序列化、日志格式化等：可能是 CPU 密集计算。
+- 如果堆栈显示在锁竞争：继续看是否有大量 `BLOCKED`，并考虑用 `thread(blocking=true)` 找出阻塞源头线程。
+
+## 3) 进一步确认热点方法的调用路径（按需、有限制）
+
+当热点线程堆栈指向某个「可疑方法」时：
+- 优先使用 `stack` / `trace` 针对该方法做路径确认（避免宽泛匹配）。
+- 如果需要观测入参/返回值，再考虑 `watch` 或 `tt`，并设置合理的执行次数与超时，避免对线上造成压力。
+
+## 4) 输出诊断结论
+
+报告至少包含：
+- 现象与证据：dashboard 摘要 + topN 线程堆栈关键片段
+- 初步结论：CPU 主要消耗在什么类型的逻辑（计算/锁/GC/日志等）
+- 下一步：建议进一步 trace/watch 的目标方法（给出类名+方法名的精确范围），或建议用户提供主包名/关键接口信息以继续收敛

.agents/skills/cross-stack-dto-granularity-alignment/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: cross-stack-dto-granularity-alignment
+description: Systematic method to analyze and align DTO types, API endpoints, and enums between frontend and backend codebases. Trigger when debugging type mismatches, before major releases, or when onboarding to a full-stack module.
+---
+
+# Cross-Stack DTO Granularity Alignment
+
+**Context:** When frontend and backend evolve independently, DTO fields, enum values, and API endpoints drift out of sync. This pattern provides a systematic method to audit and document alignment gaps.
+
+## Problem
+Frontend TypeScript types and backend Java DTOs drift over time: missing fields, mismatched enum values, phantom types (frontend types with no backend endpoint), and unused backend endpoints. Manual spot-checking misses these gaps.
+
+## Solution
+
+### Step 1: Parallel Code Exploration
+Launch parallel agents to explore backend and frontend independently:
+- **Agent 1 (Backend):** Find all controllers, DTOs (request + response), enums, and service methods. List every API endpoint with HTTP method, path, parameters, and return type.
+- **Agent 2 (Frontend):** Find all API functions, type definitions, and page components. List every API call with method, URL, and typed parameters/returns.
+- **Agent 3 (Other frontends):** Check if additional frontend apps (e.g., user-facing vs admin) consume the same APIs.
+
+### Step 2: Field-Level DTO Comparison
+For each shared DTO, create a comparison table:
+| Field | Backend Type | Frontend Type | Alignment |
+Backend `String` vs frontend enum is a common mismatch — frontend is stricter/correct, backend should adopt enums.
+
+### Step 3: Enum Value Audit
+Compare every enum across all frontends and backend. Tabulate which values exist where. Common pattern: admin frontend has all values, user frontend is missing some, backend has all.
+
+### Step 4: Identify Ghost Types and Orphan Endpoints
+- **Ghost types**: Frontend types defined but never backed by a backend endpoint (dead code or future scaffolding)
+- **Orphan endpoints**: Backend endpoints no frontend calls (unused or undiscovered)
+
+### Step 5: Service Layer Granularity
+Flag backend methods over ~50 lines or with 5+ conditional branches as candidates for decomposition (strategy pattern, etc.).
+
+### Step 6: Generate Prioritized Report
+Output a structured report to `docs/` with:
+- Full alignment tables
+- Mismatch issues ranked by severity (P1-P4)
+- Specific file:line references for each issue
+
+## When to Use
+- After a module has been developed independently on frontend and backend
+- Before a major release or API versioning effort
+- When debugging "type mismatch" or "missing field" errors at the FE/BE boundary
+- When onboarding to a new full-stack module

.agents/skills/design-an-interface/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: design-an-interface
+description: Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".
+---
+
+# Design an Interface
+
+Based on "Design It Twice" from "A Philosophy of Software Design": your first idea is unlikely to be the best. Generate multiple radically different designs, then compare.
+
+## Workflow
+
+### 1. Gather Requirements
+
+Before designing, understand:
+
+- [ ] What problem does this module solve?
+- [ ] Who are the callers? (other modules, external users, tests)
+- [ ] What are the key operations?
+- [ ] Any constraints? (performance, compatibility, existing patterns)
+- [ ] What should be hidden inside vs exposed?
+
+Ask: "What does this module need to do? Who will use it?"
+
+### 2. Generate Designs (Parallel Sub-Agents)
+
+Spawn 3+ sub-agents simultaneously using Task tool. Each must produce a **radically different** approach.
+
+```
+Prompt template for each sub-agent:
+
+Design an interface for: [module description]
+
+Requirements: [gathered requirements]
+
+Constraints for this design: [assign a different constraint to each agent]
+- Agent 1: "Minimize method count - aim for 1-3 methods max"
+- Agent 2: "Maximize flexibility - support many use cases"
+- Agent 3: "Optimize for the most common case"
+- Agent 4: "Take inspiration from [specific paradigm/library]"
+
+Output format:
+1. Interface signature (types/methods)
+2. Usage example (how caller uses it)
+3. What this design hides internally
+4. Trade-offs of this approach
+```
+
+### 3. Present Designs
+
+Show each design with:
+
+1. **Interface signature** - types, methods, params
+2. **Usage examples** - how callers actually use it in practice
+3. **What it hides** - complexity kept internal
+
+Present designs sequentially so user can absorb each approach before comparison.
+
+### 4. Compare Designs
+
+After showing all designs, compare them on:
+
+- **Interface simplicity**: fewer methods, simpler params
+- **General-purpose vs specialized**: flexibility vs focus
+- **Implementation efficiency**: does shape allow efficient internals?
+- **Depth**: small interface hiding significant complexity (good) vs large interface with thin implementation (bad)
+- **Ease of correct use** vs **ease of misuse**
+
+Discuss trade-offs in prose, not tables. Highlight where designs diverge most.
+
+### 5. Synthesize
+
+Often the best design combines insights from multiple options. Ask:
+
+- "Which design best fits your primary use case?"
+- "Any elements from other designs worth incorporating?"
+
+## Evaluation Criteria
+
+From "A Philosophy of Software Design":
+
+**Interface simplicity**: Fewer methods, simpler params = easier to learn and use correctly.
+
+**General-purpose**: Can handle future use cases without changes. But beware over-generalization.
+
+**Implementation efficiency**: Does interface shape allow efficient implementation? Or force awkward internals?
+
+**Depth**: Small interface hiding significant complexity = deep module (good). Large interface with thin implementation = shallow module (avoid).
+
+## Anti-Patterns
+
+- Don't let sub-agents produce similar designs - enforce radical difference
+- Don't skip comparison - the value is in contrast
+- Don't implement - this is purely about interface shape
+- Don't evaluate based on implementation effort