deepspider 0.2.12 → 0.3.1

package/.claude/agents/research.md

@@ -1,120 +0,0 @@
----
-name: research
-description: |
-  Code and tech search expert. Pure research, no code modifications. Finds files, patterns, and tech solutions.
-tools: Read, Glob, Grep, mcp__exa__web_search_exa, mcp__exa__get_code_context_exa, Skill, mcp__chrome-devtools__*
-model: opus
----
-# Research Agent
-
-You are the Research Agent in the Trellis workflow.
-
-## Core Principle
-
-**You do one thing: find and explain information.**
-
-You are a documenter, not a reviewer. Your job is to help get the information needed.
-
----
-
-## Core Responsibilities
-
-### 1. Internal Search (Project Code)
-
-| Search Type | Goal | Tools |
-|-------------|------|-------|
-| **WHERE** | Locate files/components | Glob, Grep |
-| **HOW** | Understand code logic | Read, Grep |
-| **PATTERN** | Discover existing patterns | Grep, Read |
-
-### 2. External Search (Tech Solutions)
-
-Use web search for best practices and code examples.
-
----
-
-## Strict Boundaries
-
-### Only Allowed
-
-- Describe **what exists**
-- Describe **where it is**
-- Describe **how it works**
-- Describe **how components interact**
-
-### Forbidden (unless explicitly asked)
-
-- Suggest improvements
-- Criticize implementation
-- Recommend refactoring
-- Modify any files
-- Execute git commands
-
----
-
-## Workflow
-
-### Step 1: Understand Search Request
-
-Analyze the query, determine:
-
-- Search type (internal/external/mixed)
-- Search scope (global/specific directory)
-- Expected output (file list/code patterns/tech solutions)
-
-### Step 2: Execute Search
-
-Execute multiple independent searches in parallel for efficiency.
-
-### Step 3: Organize Results
-
-Output structured results in report format.
-
----
-
-## Report Format
-
-```markdown
-## Search Results
-
-### Query
-
-{original query}
-
-### Files Found
-
-| File Path | Description |
-|-----------|-------------|
-| `src/services/xxx.ts` | Main implementation |
-| `src/types/xxx.ts` | Type definitions |
-
-### Code Pattern Analysis
-
-{Describe discovered patterns, cite specific files and line numbers}
-
-### Related Spec Documents
-
-- `.trellis/spec/xxx.md` - {description}
-
-### Not Found
-
-{If some content was not found, explain}
-```
-
----
-
-## Guidelines
-
-### DO
-
-- Provide specific file paths and line numbers
-- Quote actual code snippets
-- Distinguish "definitely found" and "possibly related"
-- Explain search scope and limitations
-
-### DON'T
-
-- Don't guess uncertain info
-- Don't omit important search results
-- Don't add improvement suggestions in report (unless explicitly asked)
-- Don't modify any files

package/.claude/commands/evolve/merge.md

@@ -1,80 +0,0 @@
-# Evolve Merge - 合并动态经验到静态 Skills
-
-将 evolved.md 中的核心经验合并到 SKILL.md，并进行深度提炼。
-
-## 用法
-
-```
-/evolve:merge <skill-name>
-```
-
-## 执行步骤
-
-### 1. 读取动态经验
-
-```bash
-cat src/agent/skills/<skill-name>/evolved.md
-```
-
-### 2. 深度分析（核心步骤）
-
-对每条经验进行第一性原理分析：
-
-**2.1 提炼本质**
-- 这条经验的根本原因是什么？
-- 背后的技术原理是什么？
-
-**2.2 举一反三**
-- 是否存在类似的场景？
-- 同类问题还有哪些表现形式？
-
-**2.3 通用化**
-- 能否提炼成更通用的规则？
-- 是否适用于其他加密库/算法？
-
-**示例：**
-```
-原始经验: CryptoJS CFB 用 segment_size=128，PyCryptodome 默认 CFB8
-
-第一性原理: 不同库对同一算法的默认参数可能不同
-
-举一反三:
-- CBC 模式的 IV 处理方式
-- PKCS7 vs PKCS5 填充
-- 密钥派生函数差异
-
-通用规则: JS/Python 加密转换时，必须逐一核对：模式、填充、IV、密钥派生、输出编码
-```
-
-### 3. 合并到 SKILL.md
-
-将提炼后的通用经验追加到 SKILL.md：
-- 优先写通用规则，而非具体案例
-- 用简洁的一句话总结
-- 必要时附带检查清单
-
-### 4. 清理 evolved.md
-
-- 保留已合并的核心经验标记
-- 清空近期发现
-- 更新 last_merged 日期
-- 重置 total 计数
-
-### 5. 提交变更
-
-```bash
-git add src/agent/skills/<skill-name>/
-git commit -m "docs: merge evolved experiences to <skill-name>"
-```
-
-## 可用的 skill 名称
-
-- static-analysis
-- dynamic-analysis
-- sandbox
-- env
-- js2python
-- report
-- captcha
-- anti-detect
-- crawler

package/.claude/commands/trellis/before-backend-dev.md

@@ -1,13 +0,0 @@
-Read the backend development guidelines before starting your development task.
-
-Execute these steps:
-1. Read `.trellis/spec/backend/index.md` to understand available guidelines
-2. Based on your task, read the relevant guideline files:
-   - Database work → `.trellis/spec/backend/database-guidelines.md`
-   - Error handling → `.trellis/spec/backend/error-handling.md`
-   - Logging → `.trellis/spec/backend/logging-guidelines.md`
-   - Type questions → `.trellis/spec/backend/type-safety.md`
-3. Understand the coding standards and patterns you need to follow
-4. Then proceed with your development plan
-
-This step is **mandatory** before writing any backend code.

package/.claude/commands/trellis/before-frontend-dev.md

@@ -1,13 +0,0 @@
-Read the frontend development guidelines before starting your development task.
-
-Execute these steps:
-1. Read `.trellis/spec/frontend/index.md` to understand available guidelines
-2. Based on your task, read the relevant guideline files:
-   - Component work → `.trellis/spec/frontend/component-guidelines.md`
-   - Hook work → `.trellis/spec/frontend/hook-guidelines.md`
-   - State management → `.trellis/spec/frontend/state-management.md`
-   - Type questions → `.trellis/spec/frontend/type-safety.md`
-3. Understand the coding standards and patterns you need to follow
-4. Then proceed with your development plan
-
-This step is **mandatory** before writing any frontend code.

package/.claude/commands/trellis/break-loop.md

@@ -1,107 +0,0 @@
-# Break the Loop - Deep Bug Analysis
-
-When debug is complete, use this command for deep analysis to break the "fix bug -> forget -> repeat" cycle.
-
----
-
-## Analysis Framework
-
-Analyze the bug you just fixed from these 5 dimensions:
-
-### 1. Root Cause Category
-
-Which category does this bug belong to?
-
-| Category | Characteristics | Example |
-|----------|-----------------|---------|
-| **A. Missing Spec** | No documentation on how to do it | New feature without checklist |
-| **B. Cross-Layer Contract** | Interface between layers unclear | API returns different format than expected |
-| **C. Change Propagation Failure** | Changed one place, missed others | Changed function signature, missed call sites |
-| **D. Test Coverage Gap** | Unit test passes, integration fails | Works alone, breaks when combined |
-| **E. Implicit Assumption** | Code relies on undocumented assumption | Timestamp seconds vs milliseconds |
-
-### 2. Why Fixes Failed (if applicable)
-
-If you tried multiple fixes before succeeding, analyze each failure:
-
-- **Surface Fix**: Fixed symptom, not root cause
-- **Incomplete Scope**: Found root cause, didn't cover all cases
-- **Tool Limitation**: grep missed it, type check wasn't strict
-- **Mental Model**: Kept looking in same layer, didn't think cross-layer
-
-### 3. Prevention Mechanisms
-
-What mechanisms would prevent this from happening again?
-
-| Type | Description | Example |
-|------|-------------|---------|
-| **Documentation** | Write it down so people know | Update thinking guide |
-| **Architecture** | Make the error impossible structurally | Type-safe wrappers |
-| **Compile-time** | TypeScript strict, no any | Signature change causes compile error |
-| **Runtime** | Monitoring, alerts, scans | Detect orphan entities |
-| **Test Coverage** | E2E tests, integration tests | Verify full flow |
-| **Code Review** | Checklist, PR template | "Did you check X?" |
-
-### 4. Systematic Expansion
-
-What broader problems does this bug reveal?
-
-- **Similar Issues**: Where else might this problem exist?
-- **Design Flaw**: Is there a fundamental architecture issue?
-- **Process Flaw**: Is there a development process improvement?
-- **Knowledge Gap**: Is the team missing some understanding?
-
-### 5. Knowledge Capture
-
-Solidify insights into the system:
-
-- [ ] Update `.trellis/spec/guides/` thinking guides
-- [ ] Update `.trellis/spec/backend/` or `frontend/` docs
-- [ ] Create issue record (if applicable)
-- [ ] Create feature ticket for root fix
-- [ ] Update check commands if needed
-
----
-
-## Output Format
-
-Please output analysis in this format:
-
-```markdown
-## Bug Analysis: [Short Description]
-
-### 1. Root Cause Category
-- **Category**: [A/B/C/D/E] - [Category Name]
-- **Specific Cause**: [Detailed description]
-
-### 2. Why Fixes Failed (if applicable)
-1. [First attempt]: [Why it failed]
-2. [Second attempt]: [Why it failed]
-...
-
-### 3. Prevention Mechanisms
-| Priority | Mechanism | Specific Action | Status |
-|----------|-----------|-----------------|--------|
-| P0 | ... | ... | TODO/DONE |
-
-### 4. Systematic Expansion
-- **Similar Issues**: [List places with similar problems]
-- **Design Improvement**: [Architecture-level suggestions]
-- **Process Improvement**: [Development process suggestions]
-
-### 5. Knowledge Capture
-- [ ] [Documents to update / tickets to create]
-```
-
----
-
-## Core Philosophy
-
-> **The value of debugging is not in fixing the bug, but in making this class of bugs never happen again.**
-
-Three levels of insight:
-1. **Tactical**: How to fix THIS bug
-2. **Strategic**: How to prevent THIS CLASS of bugs
-3. **Philosophical**: How to expand thinking patterns
-
-30 minutes of analysis saves 30 hours of future debugging.

package/.claude/commands/trellis/check-backend.md

@@ -1,13 +0,0 @@
-Check if the code you just wrote follows the backend development guidelines.
-
-Execute these steps:
-1. Run `git status` to see modified files
-2. Read `.trellis/spec/backend/index.md` to understand which guidelines apply
-3. Based on what you changed, read the relevant guideline files:
-   - Database changes → `.trellis/spec/backend/database-guidelines.md`
-   - Error handling → `.trellis/spec/backend/error-handling.md`
-   - Logging changes → `.trellis/spec/backend/logging-guidelines.md`
-   - Type changes → `.trellis/spec/backend/type-safety.md`
-   - Any changes → `.trellis/spec/backend/quality-guidelines.md`
-4. Review your code against the guidelines
-5. Report any violations and fix them if found

package/.claude/commands/trellis/check-cross-layer.md

@@ -1,153 +0,0 @@
-# Cross-Layer Check
-
-Check if your changes considered all dimensions. Most bugs come from "didn't think of it", not lack of technical skill.
-
-> **Note**: This is a **post-implementation** safety net. Ideally, read the [Pre-Implementation Checklist](.trellis/spec/guides/pre-implementation-checklist.md) **before** writing code.
-
----
-
-## Related Documents
-
-| Document | Purpose | Timing |
-|----------|---------|--------|
-| [Pre-Implementation Checklist](.trellis/spec/guides/pre-implementation-checklist.md) | Questions before coding | **Before** writing code |
-| [Code Reuse Thinking Guide](.trellis/spec/guides/code-reuse-thinking-guide.md) | Pattern recognition | During implementation |
-| **`/trellis:check-cross-layer`** (this) | Verification check | **After** implementation |
-
----
-
-## Execution Steps
-
-### 1. Identify Change Scope
-
-```bash
-git status
-git diff --name-only
-```
-
-### 2. Select Applicable Check Dimensions
-
-Based on your change type, execute relevant checks below:
-
----
-
-## Dimension A: Cross-Layer Data Flow (Required when 3+ layers)
-
-**Trigger**: Changes involve 3 or more layers
-
-| Layer | Common Locations |
-|-------|------------------|
-| API/Routes | `routes/`, `api/`, `handlers/`, `controllers/` |
-| Service/Business Logic | `services/`, `lib/`, `core/`, `domain/` |
-| Database/Storage | `db/`, `models/`, `repositories/`, `schema/` |
-| UI/Presentation | `components/`, `views/`, `templates/`, `pages/` |
-| Utility | `utils/`, `helpers/`, `common/` |
-
-**Checklist**:
-- [ ] Read flow: Database -> Service -> API -> UI
-- [ ] Write flow: UI -> API -> Service -> Database
-- [ ] Types/schemas correctly passed between layers?
-- [ ] Errors properly propagated to caller?
-- [ ] Loading/pending states handled at each layer?
-
-**Detailed Guide**: `.trellis/spec/guides/cross-layer-thinking-guide.md`
-
----
-
-## Dimension B: Code Reuse (Required when modifying constants/config)
-
-**Trigger**: 
-- Modifying UI constants (label, icon, color)
-- Modifying any hardcoded value
-- Seeing similar code in multiple places
-- Creating a new utility/helper function
-- Just finished batch modifications across files
-
-**Checklist**:
-- [ ] Search first: How many places define this value?
-  ```bash
-  # Search in source files (adjust extensions for your project)
-  grep -r "value-to-change" src/
-  ```
-- [ ] If 2+ places define same value -> Should extract to shared constant
-- [ ] After modification, all usage sites updated?
-- [ ] If creating utility: Does similar utility already exist?
-
-**Detailed Guide**: `.trellis/spec/guides/code-reuse-thinking-guide.md`
-
----
-
-## Dimension B2: New Utility Functions
-
-**Trigger**: About to create a new utility/helper function
-
-**Checklist**:
-- [ ] Search for existing similar utilities first
-  ```bash
-  grep -r "functionNamePattern" src/
-  ```
-- [ ] If similar exists, can you extend it instead?
-- [ ] If creating new, is it in the right location (shared vs domain-specific)?
-
----
-
-## Dimension B3: After Batch Modifications
-
-**Trigger**: Just modified similar patterns in multiple files
-
-**Checklist**:
-- [ ] Did you check ALL files with similar patterns?
-  ```bash
-  grep -r "patternYouChanged" src/
-  ```
-- [ ] Any files missed that should also be updated?
-- [ ] Should this pattern be abstracted to prevent future duplication?
-
----
-
-## Dimension C: Import/Dependency Paths (Required when creating new files)
-
-**Trigger**: Creating new source files
-
-**Checklist**:
-- [ ] Using correct import paths (relative vs absolute)?
-- [ ] No circular dependencies?
-- [ ] Consistent with project's module organization?
-
----
-
-## Dimension D: Same-Layer Consistency
-
-**Trigger**: 
-- Modifying display logic or formatting
-- Same domain concept used in multiple places
-
-**Checklist**:
-- [ ] Search for other places using same concept
-  ```bash
-  grep -r "ConceptName" src/
-  ```
-- [ ] Are these usages consistent?
-- [ ] Should they share configuration/constants?
-
----
-
-## Common Issues Quick Reference
-
-| Issue | Root Cause | Prevention |
-|-------|------------|------------|
-| Changed one place, missed others | Didn't search impact scope | `grep` before changing |
-| Data lost at some layer | Didn't check data flow | Trace data source to destination |
-| Type/schema mismatch | Cross-layer types inconsistent | Use shared type definitions |
-| UI/output inconsistent | Same concept in multiple places | Extract shared constants |
-| Similar utility exists | Didn't search first | Search before creating |
-| Batch fix incomplete | Didn't verify all occurrences | grep after fixing |
-
----
-
-## Output
-
-Report:
-1. Which dimensions your changes involve
-2. Check results for each dimension
-3. Issues found and fix suggestions

package/.claude/commands/trellis/check-frontend.md

@@ -1,13 +0,0 @@
-Check if the code you just wrote follows the frontend development guidelines.
-
-Execute these steps:
-1. Run `git status` to see modified files
-2. Read `.trellis/spec/frontend/index.md` to understand which guidelines apply
-3. Based on what you changed, read the relevant guideline files:
-   - Component changes → `.trellis/spec/frontend/component-guidelines.md`
-   - Hook changes → `.trellis/spec/frontend/hook-guidelines.md`
-   - State changes → `.trellis/spec/frontend/state-management.md`
-   - Type changes → `.trellis/spec/frontend/type-safety.md`
-   - Any changes → `.trellis/spec/frontend/quality-guidelines.md`
-4. Review your code against the guidelines
-5. Report any violations and fix them if found

package/.claude/commands/trellis/create-command.md

@@ -1,154 +0,0 @@
-# Create New Slash Command
-
-Create a new slash command in both `.cursor/commands/` (with `trellis-` prefix) and `.claude/commands/trellis/` directories based on user requirements.
-
-## Usage
-
-```
-/trellis:create-command <command-name> <description>
-```
-
-**Example**:
-```
-/trellis:create-command review-pr Check PR code changes against project guidelines
-```
-
-## Execution Steps
-
-### 1. Parse Input
-
-Extract from user input:
-- **Command name**: Use kebab-case (e.g., `review-pr`)
-- **Description**: What the command should accomplish
-
-### 2. Analyze Requirements
-
-Determine command type based on description:
-- **Initialization**: Read docs, establish context
-- **Pre-development**: Read guidelines, check dependencies
-- **Code check**: Validate code quality and guideline compliance
-- **Recording**: Record progress, questions, structure changes
-- **Generation**: Generate docs, code templates
-
-### 3. Generate Command Content
-
-Based on command type, generate appropriate content:
-
-**Simple command** (1-3 lines):
-```markdown
-Concise instruction describing what to do
-```
-
-**Complex command** (with steps):
-```markdown
-# Command Title
-
-Command description
-
-## Steps
-
-### 1. First Step
-Specific action
-
-### 2. Second Step
-Specific action
-
-## Output Format (if needed)
-
-Template
-```
-
-### 4. Create Files
-
-Create in both directories:
-- `.cursor/commands/trellis-<command-name>.md`
-- `.claude/commands/trellis/<command-name>.md`
-
-### 5. Confirm Creation
-
-Output result:
-```
-[OK] Created Slash Command: /<command-name>
-
-File paths:
-- .cursor/commands/trellis-<command-name>.md
-- .claude/commands/trellis/<command-name>.md
-
-Usage:
-/trellis:<command-name>
-
-Description:
-<description>
-```
-
-## Command Content Guidelines
-
-### [OK] Good command content
-
-1. **Clear and concise**: Immediately understandable
-2. **Executable**: AI can follow steps directly
-3. **Well-scoped**: Clear boundaries of what to do and not do
-4. **Has output**: Specifies expected output format (if needed)
-
-### [X] Avoid
-
-1. **Too vague**: e.g., "optimize code"
-2. **Too complex**: Single command should not exceed 100 lines
-3. **Duplicate functionality**: Check if similar command exists first
-
-## Naming Conventions
-
-| Command Type | Prefix | Example |
-|--------------|--------|---------|
-| Session Start | `start` | `start` |
-| Pre-development | `before-` | `before-frontend-dev` |
-| Check | `check-` | `check-frontend` |
-| Record | `record-` | `record-session` |
-| Generate | `generate-` | `generate-api-doc` |
-| Update | `update-` | `update-changelog` |
-| Other | Verb-first | `review-code`, `sync-data` |
-
-## Example
-
-### Input
-```
-/trellis:create-command review-pr Check PR code changes against project guidelines
-```
-
-### Generated Command Content
-```markdown
-# PR Code Review
-
-Check current PR code changes against project guidelines.
-
-## Steps
-
-### 1. Get Changed Files
-```bash
-git diff main...HEAD --name-only
-```
-
-### 2. Categorized Review
-
-**Frontend files** (`apps/web/`):
-- Reference `.trellis/spec/frontend/index.md`
-
-**Backend files** (`packages/api/`):
-- Reference `.trellis/spec/backend/index.md`
-
-### 3. Output Review Report
-
-Format:
-
-## PR Review Report
-
-### Changed Files
-- [file list]
-
-### Check Results
-- [OK] Passed items
-- [X] Issues found
-
-### Suggestions
-- [improvement suggestions]
-```