diff --git a/.kilocode/workflows/openspec-apply.md b/.kilocode/workflows/openspec-apply.md
new file mode 100644
index 0000000..4e49640
--- /dev/null
+++ b/.kilocode/workflows/openspec-apply.md
@@ -0,0 +1,17 @@
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+Track these steps as TODOs and complete them one by one.
+1. Read `changes/<id>/proposal.md`, `design.md` (if present), and `tasks.md` to confirm scope and acceptance criteria.
+2. Work through tasks sequentially, keeping edits minimal and focused on the requested change.
+3. Confirm completion before updating statuses—make sure every item in `tasks.md` is finished.
+4. Update the checklist after all work is done so each task is marked `- [x]` and reflects reality.
+5. Reference `openspec list` or `openspec show <item>` when additional context is required.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` if you need additional context from the proposal while implementing.
+<!-- OPENSPEC:END -->
diff --git a/.kilocode/workflows/openspec-archive.md b/.kilocode/workflows/openspec-archive.md
new file mode 100644
index 0000000..34795ca
--- /dev/null
+++ b/.kilocode/workflows/openspec-archive.md
@@ -0,0 +1,21 @@
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+
+**Steps**
+1. Determine the change ID to archive:
+   - If this prompt already includes a specific change ID (for example inside a `<ChangeId>` block populated by slash-command arguments), use that value after trimming whitespace.
+   - If the conversation references a change loosely (for example by title or summary), run `openspec list` to surface likely IDs, share the relevant candidates, and confirm which one the user intends.
+   - Otherwise, review the conversation, run `openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding.
+   - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
+2. Validate the change ID by running `openspec list` (or `openspec show <id>`) and stop if the change is missing, already archived, or otherwise not ready to archive.
+3. Run `openspec archive <id> --yes` so the CLI moves the change and applies spec updates without prompts (use `--skip-specs` only for tooling-only work).
+4. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+5. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+- Use `openspec list` to confirm change IDs before archiving.
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->
diff --git a/.kilocode/workflows/openspec-proposal.md b/.kilocode/workflows/openspec-proposal.md
new file mode 100644
index 0000000..15947b8
--- /dev/null
+++ b/.kilocode/workflows/openspec-proposal.md
@@ -0,0 +1,22 @@
+<!-- OPENSPEC:START -->
+**Guardrails**
+- Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
+- Keep changes tightly scoped to the requested outcome.
+- Refer to `openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec` or `openspec update` if you don't see it) if you need additional OpenSpec conventions or clarifications.
+- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.
+- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
+
+**Steps**
+1. Review `openspec/project.md`, run `openspec list` and `openspec list --specs`, and inspect related code or docs (e.g., via `rg`/`ls`) to ground the proposal in current behaviour; note any gaps that require clarification.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, and `design.md` (when needed) under `openspec/changes/<id>/`.
+3. Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
+4. Capture architectural reasoning in `design.md` when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
+5. Draft spec deltas in `changes/<id>/specs/<capability>/spec.md` (one folder per capability) using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement and cross-reference related capabilities when relevant.
+6. Draft `tasks.md` as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work.
+7. Validate with `openspec validate <id> --strict` and resolve every issue before sharing the proposal.
+
+**Reference**
+- Use `openspec show <id> --json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.
+- Search existing requirements with `rg -n "Requirement:|Scenario:" openspec/specs` before writing new ones.
+- Explore the codebase with `rg <keyword>`, `ls`, or direct file reads so proposals align with current implementation realities.
+<!-- OPENSPEC:END -->
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..0669699
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,18 @@
+<!-- OPENSPEC:START -->
+# OpenSpec Instructions
+
+These instructions are for AI assistants working in this project.
+
+Always open `@/openspec/AGENTS.md` when the request:
+- Mentions planning or proposals (words like proposal, spec, change, plan)
+- Introduces new capabilities, breaking changes, architecture shifts, or big performance/security work
+- Sounds ambiguous and you need the authoritative spec before coding
+
+Use `@/openspec/AGENTS.md` to learn:
+- How to create and apply change proposals
+- Spec format and conventions
+- Project structure and guidelines
+
+Keep this managed block so 'openspec update' can refresh the instructions.
+
+<!-- OPENSPEC:END -->
\ No newline at end of file
diff --git a/openspec/AGENTS.md b/openspec/AGENTS.md
new file mode 100644
index 0000000..96ab0bb
--- /dev/null
+++ b/openspec/AGENTS.md
@@ -0,0 +1,456 @@
+# OpenSpec Instructions
+
+Instructions for AI coding assistants using OpenSpec for spec-driven development.
+
+## TL;DR Quick Checklist
+
+- Search existing work: `openspec spec list --long`, `openspec list` (use `rg` only for full-text search)
+- Decide scope: new capability vs modify existing capability
+- Pick a unique `change-id`: kebab-case, verb-led (`add-`, `update-`, `remove-`, `refactor-`)
+- Scaffold: `proposal.md`, `tasks.md`, `design.md` (only if needed), and delta specs per affected capability
+- Write deltas: use `## ADDED|MODIFIED|REMOVED|RENAMED Requirements`; include at least one `#### Scenario:` per requirement
+- Validate: `openspec validate [change-id] --strict` and fix issues
+- Request approval: Do not start implementation until proposal is approved
+
+## Three-Stage Workflow
+
+### Stage 1: Creating Changes
+Create proposal when you need to:
+- Add features or functionality
+- Make breaking changes (API, schema)
+- Change architecture or patterns  
+- Optimize performance (changes behavior)
+- Update security patterns
+
+Triggers (examples):
+- "Help me create a change proposal"
+- "Help me plan a change"
+- "Help me create a proposal"
+- "I want to create a spec proposal"
+- "I want to create a spec"
+
+Loose matching guidance:
+- Contains one of: `proposal`, `change`, `spec`
+- With one of: `create`, `plan`, `make`, `start`, `help`
+
+Skip proposal for:
+- Bug fixes (restore intended behavior)
+- Typos, formatting, comments
+- Dependency updates (non-breaking)
+- Configuration changes
+- Tests for existing behavior
+
+**Workflow**
+1. Review `openspec/project.md`, `openspec list`, and `openspec list --specs` to understand current context.
+2. Choose a unique verb-led `change-id` and scaffold `proposal.md`, `tasks.md`, optional `design.md`, and spec deltas under `openspec/changes/<id>/`.
+3. Draft spec deltas using `## ADDED|MODIFIED|REMOVED Requirements` with at least one `#### Scenario:` per requirement.
+4. Run `openspec validate <id> --strict` and resolve any issues before sharing the proposal.
+
+### Stage 2: Implementing Changes
+Track these steps as TODOs and complete them one by one.
+1. **Read proposal.md** - Understand what's being built
+2. **Read design.md** (if exists) - Review technical decisions
+3. **Read tasks.md** - Get implementation checklist
+4. **Implement tasks sequentially** - Complete in order
+5. **Confirm completion** - Ensure every item in `tasks.md` is finished before updating statuses
+6. **Update checklist** - After all work is done, set every task to `- [x]` so the list reflects reality
+7. **Approval gate** - Do not start implementation until the proposal is reviewed and approved
+
+### Stage 3: Archiving Changes
+After deployment, create separate PR to:
+- Move `changes/[name]/` → `changes/archive/YYYY-MM-DD-[name]/`
+- Update `specs/` if capabilities changed
+- Use `openspec archive <change-id> --skip-specs --yes` for tooling-only changes (always pass the change ID explicitly)
+- Run `openspec validate --strict` to confirm the archived change passes checks
+
+## Before Any Task
+
+**Context Checklist:**
+- [ ] Read relevant specs in `specs/[capability]/spec.md`
+- [ ] Check pending changes in `changes/` for conflicts
+- [ ] Read `openspec/project.md` for conventions
+- [ ] Run `openspec list` to see active changes
+- [ ] Run `openspec list --specs` to see existing capabilities
+
+**Before Creating Specs:**
+- Always check if capability already exists
+- Prefer modifying existing specs over creating duplicates
+- Use `openspec show [spec]` to review current state
+- If request is ambiguous, ask 1–2 clarifying questions before scaffolding
+
+### Search Guidance
+- Enumerate specs: `openspec spec list --long` (or `--json` for scripts)
+- Enumerate changes: `openspec list` (or `openspec change list --json` - deprecated but available)
+- Show details:
+  - Spec: `openspec show <spec-id> --type spec` (use `--json` for filters)
+  - Change: `openspec show <change-id> --json --deltas-only`
+- Full-text search (use ripgrep): `rg -n "Requirement:|Scenario:" openspec/specs`
+
+## Quick Start
+
+### CLI Commands
+
+```bash
+# Essential commands
+openspec list                  # List active changes
+openspec list --specs          # List specifications
+openspec show [item]           # Display change or spec
+openspec validate [item]       # Validate changes or specs
+openspec archive <change-id> [--yes|-y]   # Archive after deployment (add --yes for non-interactive runs)
+
+# Project management
+openspec init [path]           # Initialize OpenSpec
+openspec update [path]         # Update instruction files
+
+# Interactive mode
+openspec show                  # Prompts for selection
+openspec validate              # Bulk validation mode
+
+# Debugging
+openspec show [change] --json --deltas-only
+openspec validate [change] --strict
+```
+
+### Command Flags
+
+- `--json` - Machine-readable output
+- `--type change|spec` - Disambiguate items
+- `--strict` - Comprehensive validation
+- `--no-interactive` - Disable prompts
+- `--skip-specs` - Archive without spec updates
+- `--yes`/`-y` - Skip confirmation prompts (non-interactive archive)
+
+## Directory Structure
+
+```
+openspec/
+├── project.md              # Project conventions
+├── specs/                  # Current truth - what IS built
+│   └── [capability]/       # Single focused capability
+│       ├── spec.md         # Requirements and scenarios
+│       └── design.md       # Technical patterns
+├── changes/                # Proposals - what SHOULD change
+│   ├── [change-name]/
+│   │   ├── proposal.md     # Why, what, impact
+│   │   ├── tasks.md        # Implementation checklist
+│   │   ├── design.md       # Technical decisions (optional; see criteria)
+│   │   └── specs/          # Delta changes
+│   │       └── [capability]/
+│   │           └── spec.md # ADDED/MODIFIED/REMOVED
+│   └── archive/            # Completed changes
+```
+
+## Creating Change Proposals
+
+### Decision Tree
+
+```
+New request?
+├─ Bug fix restoring spec behavior? → Fix directly
+├─ Typo/format/comment? → Fix directly  
+├─ New feature/capability? → Create proposal
+├─ Breaking change? → Create proposal
+├─ Architecture change? → Create proposal
+└─ Unclear? → Create proposal (safer)
+```
+
+### Proposal Structure
+
+1. **Create directory:** `changes/[change-id]/` (kebab-case, verb-led, unique)
+
+2. **Write proposal.md:**
+```markdown
+# Change: [Brief description of change]
+
+## Why
+[1-2 sentences on problem/opportunity]
+
+## What Changes
+- [Bullet list of changes]
+- [Mark breaking changes with **BREAKING**]
+
+## Impact
+- Affected specs: [list capabilities]
+- Affected code: [key files/systems]
+```
+
+3. **Create spec deltas:** `specs/[capability]/spec.md`
+```markdown
+## ADDED Requirements
+### Requirement: New Feature
+The system SHALL provide...
+
+#### Scenario: Success case
+- **WHEN** user performs action
+- **THEN** expected result
+
+## MODIFIED Requirements
+### Requirement: Existing Feature
+[Complete modified requirement]
+
+## REMOVED Requirements
+### Requirement: Old Feature
+**Reason**: [Why removing]
+**Migration**: [How to handle]
+```
+If multiple capabilities are affected, create multiple delta files under `changes/[change-id]/specs/<capability>/spec.md`—one per capability.
+
+4. **Create tasks.md:**
+```markdown
+## 1. Implementation
+- [ ] 1.1 Create database schema
+- [ ] 1.2 Implement API endpoint
+- [ ] 1.3 Add frontend component
+- [ ] 1.4 Write tests
+```
+
+5. **Create design.md when needed:**
+Create `design.md` if any of the following apply; otherwise omit it:
+- Cross-cutting change (multiple services/modules) or a new architectural pattern
+- New external dependency or significant data model changes
+- Security, performance, or migration complexity
+- Ambiguity that benefits from technical decisions before coding
+
+Minimal `design.md` skeleton:
+```markdown
+## Context
+[Background, constraints, stakeholders]
+
+## Goals / Non-Goals
+- Goals: [...]
+- Non-Goals: [...]
+
+## Decisions
+- Decision: [What and why]
+- Alternatives considered: [Options + rationale]
+
+## Risks / Trade-offs
+- [Risk] → Mitigation
+
+## Migration Plan
+[Steps, rollback]
+
+## Open Questions
+- [...]
+```
+
+## Spec File Format
+
+### Critical: Scenario Formatting
+
+**CORRECT** (use #### headers):
+```markdown
+#### Scenario: User login success
+- **WHEN** valid credentials provided
+- **THEN** return JWT token
+```
+
+**WRONG** (don't use bullets or bold):
+```markdown
+- **Scenario: User login**  ❌
+**Scenario**: User login     ❌
+### Scenario: User login      ❌
+```
+
+Every requirement MUST have at least one scenario.
+
+### Requirement Wording
+- Use SHALL/MUST for normative requirements (avoid should/may unless intentionally non-normative)
+
+### Delta Operations
+
+- `## ADDED Requirements` - New capabilities
+- `## MODIFIED Requirements` - Changed behavior
+- `## REMOVED Requirements` - Deprecated features
+- `## RENAMED Requirements` - Name changes
+
+Headers matched with `trim(header)` - whitespace ignored.
+
+#### When to use ADDED vs MODIFIED
+- ADDED: Introduces a new capability or sub-capability that can stand alone as a requirement. Prefer ADDED when the change is orthogonal (e.g., adding "Slash Command Configuration") rather than altering the semantics of an existing requirement.
+- MODIFIED: Changes the behavior, scope, or acceptance criteria of an existing requirement. Always paste the full, updated requirement content (header + all scenarios). The archiver will replace the entire requirement with what you provide here; partial deltas will drop previous details.
+- RENAMED: Use when only the name changes. If you also change behavior, use RENAMED (name) plus MODIFIED (content) referencing the new name.
+
+Common pitfall: Using MODIFIED to add a new concern without including the previous text. This causes loss of detail at archive time. If you aren’t explicitly changing the existing requirement, add a new requirement under ADDED instead.
+
+Authoring a MODIFIED requirement correctly:
+1) Locate the existing requirement in `openspec/specs/<capability>/spec.md`.
+2) Copy the entire requirement block (from `### Requirement: ...` through its scenarios).
+3) Paste it under `## MODIFIED Requirements` and edit to reflect the new behavior.
+4) Ensure the header text matches exactly (whitespace-insensitive) and keep at least one `#### Scenario:`.
+
+Example for RENAMED:
+```markdown
+## RENAMED Requirements
+- FROM: `### Requirement: Login`
+- TO: `### Requirement: User Authentication`
+```
+
+## Troubleshooting
+
+### Common Errors
+
+**"Change must have at least one delta"**
+- Check `changes/[name]/specs/` exists with .md files
+- Verify files have operation prefixes (## ADDED Requirements)
+
+**"Requirement must have at least one scenario"**
+- Check scenarios use `#### Scenario:` format (4 hashtags)
+- Don't use bullet points or bold for scenario headers
+
+**Silent scenario parsing failures**
+- Exact format required: `#### Scenario: Name`
+- Debug with: `openspec show [change] --json --deltas-only`
+
+### Validation Tips
+
+```bash
+# Always use strict mode for comprehensive checks
+openspec validate [change] --strict
+
+# Debug delta parsing
+openspec show [change] --json | jq '.deltas'
+
+# Check specific requirement
+openspec show [spec] --json -r 1
+```
+
+## Happy Path Script
+
+```bash
+# 1) Explore current state
+openspec spec list --long
+openspec list
+# Optional full-text search:
+# rg -n "Requirement:|Scenario:" openspec/specs
+# rg -n "^#|Requirement:" openspec/changes
+
+# 2) Choose change id and scaffold
+CHANGE=add-two-factor-auth
+mkdir -p openspec/changes/$CHANGE/{specs/auth}
+printf "## Why\n...\n\n## What Changes\n- ...\n\n## Impact\n- ...\n" > openspec/changes/$CHANGE/proposal.md
+printf "## 1. Implementation\n- [ ] 1.1 ...\n" > openspec/changes/$CHANGE/tasks.md
+
+# 3) Add deltas (example)
+cat > openspec/changes/$CHANGE/specs/auth/spec.md << 'EOF'
+## ADDED Requirements
+### Requirement: Two-Factor Authentication
+Users MUST provide a second factor during login.
+
+#### Scenario: OTP required
+- **WHEN** valid credentials are provided
+- **THEN** an OTP challenge is required
+EOF
+
+# 4) Validate
+openspec validate $CHANGE --strict
+```
+
+## Multi-Capability Example
+
+```
+openspec/changes/add-2fa-notify/
+├── proposal.md
+├── tasks.md
+└── specs/
+    ├── auth/
+    │   └── spec.md   # ADDED: Two-Factor Authentication
+    └── notifications/
+        └── spec.md   # ADDED: OTP email notification
+```
+
+auth/spec.md
+```markdown
+## ADDED Requirements
+### Requirement: Two-Factor Authentication
+...
+```
+
+notifications/spec.md
+```markdown
+## ADDED Requirements
+### Requirement: OTP Email Notification
+...
+```
+
+## Best Practices
+
+### Simplicity First
+- Default to <100 lines of new code
+- Single-file implementations until proven insufficient
+- Avoid frameworks without clear justification
+- Choose boring, proven patterns
+
+### Complexity Triggers
+Only add complexity with:
+- Performance data showing current solution too slow
+- Concrete scale requirements (>1000 users, >100MB data)
+- Multiple proven use cases requiring abstraction
+
+### Clear References
+- Use `file.ts:42` format for code locations
+- Reference specs as `specs/auth/spec.md`
+- Link related changes and PRs
+
+### Capability Naming
+- Use verb-noun: `user-auth`, `payment-capture`
+- Single purpose per capability
+- 10-minute understandability rule
+- Split if description needs "AND"
+
+### Change ID Naming
+- Use kebab-case, short and descriptive: `add-two-factor-auth`
+- Prefer verb-led prefixes: `add-`, `update-`, `remove-`, `refactor-`
+- Ensure uniqueness; if taken, append `-2`, `-3`, etc.
+
+## Tool Selection Guide
+
+| Task | Tool | Why |
+|------|------|-----|
+| Find files by pattern | Glob | Fast pattern matching |
+| Search code content | Grep | Optimized regex search |
+| Read specific files | Read | Direct file access |
+| Explore unknown scope | Task | Multi-step investigation |
+
+## Error Recovery
+
+### Change Conflicts
+1. Run `openspec list` to see active changes
+2. Check for overlapping specs
+3. Coordinate with change owners
+4. Consider combining proposals
+
+### Validation Failures
+1. Run with `--strict` flag
+2. Check JSON output for details
+3. Verify spec file format
+4. Ensure scenarios properly formatted
+
+### Missing Context
+1. Read project.md first
+2. Check related specs
+3. Review recent archives
+4. Ask for clarification
+
+## Quick Reference
+
+### Stage Indicators
+- `changes/` - Proposed, not yet built
+- `specs/` - Built and deployed
+- `archive/` - Completed changes
+
+### File Purposes
+- `proposal.md` - Why and what
+- `tasks.md` - Implementation steps
+- `design.md` - Technical decisions
+- `spec.md` - Requirements and behavior
+
+### CLI Essentials
+```bash
+openspec list              # What's in progress?
+openspec show [item]       # View details
+openspec validate --strict # Is it correct?
+openspec archive <change-id> [--yes|-y]  # Mark complete (add --yes for automation)
+```
+
+Remember: Specs are truth. Changes are proposals. Keep them in sync.
diff --git a/openspec/project.md b/openspec/project.md
new file mode 100644
index 0000000..991d783
--- /dev/null
+++ b/openspec/project.md
@@ -0,0 +1,216 @@
+# Project Context
+
+## Purpose
+
+这是一个基于 unibest 模板开发的跨平台电商应用系统，包含三个主要端：
+
+1. **用户端**（C端）：提供商品浏览、购物车、订单管理、会员服务、金融服务等功能
+2. **商家端**（B端）：提供商品管理、订单处理、财务管理、贷款协助、店铺设置等功能
+3. **银行端**（B端）：提供客户管理、贷款审核、交易记录、提现管理等功能
+
+项目支持多平台部署，包括 H5、iOS、Android 以及多个小程序平台（微信、支付宝、百度、字节、快手、QQ、钉钉、小红书等）。
+
+## Tech Stack
+
+### 核心框架
+- **uni-app** 3.0.0 - 跨平台开发框架
+- **Vue 3** 3.4.21 - 前端框架
+- **TypeScript** 5.8.0 - 类型系统
+- **Vite** 5.2.8 - 构建工具
+
+### UI 组件库
+- **wot-design-uni** - UI 组件库
+- **UnoCSS** 66.0.0 - 原子化 CSS 框架
+- **z-paging** 2.8.7 - 分页组件
+
+### 状态管理与路由
+- **Pinia** 2.0.36 - 状态管理
+- **pinia-plugin-persistedstate** 3.2.1 - 状态持久化
+- **vue-router** 4.5.1 - 路由管理
+- **vue-i18n** 9.1.9 - 国际化
+
+### HTTP 请求库（支持多种选择）
+- **alova** 3.3.3 - 请求库（推荐）
+- **简单封装的 http** - 轻量级请求方案
+- **vue-query** - 查询状态管理（用于自动生成接口）
+
+### 工具库
+- **dayjs** 1.11.10 - 日期处理
+- **js-cookie** 3.0.5 - Cookie 操作
+
+### 开发工具
+- **pnpm** 10.10.0 - 包管理器
+- **ESLint** 9.31.0 - 代码检查
+- **Husky** 9.1.7 - Git hooks
+- **commitlint** 19.8.1 - 提交信息规范
+
+### Node.js 环境
+- **Node.js** >= 20
+- **pnpm** >= 9
+
+## Project Conventions
+
+### Code Style
+
+#### 命名约定
+- **文件命名**：使用 kebab-case（如 `cart-item.vue`）
+- **组件命名**：使用 PascalCase（如 `CartItem.vue`）
+- **变量/函数命名**：使用 camelCase（如 `getCartList`）
+- **常量命名**：使用 UPPER_SNAKE_CASE（如 `API_BASE_URL`）
+
+#### 代码格式化
+- 使用 `@uni-helper/eslint-config` 作为 ESLint 配置
+- 支持 CSS、LESS、SCSS、HTML 的自动格式化
+- Vue SFC 块顺序：`[script, template]` → `style`
+
+#### 路径别名
+- `@/*` → `./src/*`
+- `@img/*` → `./src/static/images/*`
+
+#### 自动导入
+- Vue 和 uni-app API 自动导入
+- `src/hooks` 目录下的 hooks 自动导入
+- 组件自动导入（支持递归扫描子目录）
+
+### Architecture Patterns
+
+#### 目录结构
+```
+src/
+├── api/           # API 接口定义
+├── components/    # 公共组件
+├── hooks/        # 组合式函数
+├── http/         # HTTP 请求封装
+├── layouts/      # 布局组件
+├── mock/         # Mock 数据
+├── pages/        # 用户端页面
+├── pagesMerchant/# 商家端页面
+├── pagesBank/    # 银行端页面
+├── router/       # 路由配置
+├── service/      # 自动生成的服务接口
+├── static/       # 静态资源
+└── typings/      # 类型定义
+```
+
+#### 路由策略
+- **约定式路由**：基于文件系统自动生成路由
+- **Layout 布局**：支持多布局系统
+- **分包优化**：使用 `@uni-ku/bundle-optimizer` 进行分包优化
+- **异步导入**：支持模块和组件的异步跨包引用
+
+#### 登录策略
+支持两种登录策略（通过 `DEFAULT_NO_NEED_LOGIN` 配置）：
+
+1. **默认无需登录策略**（DEFAULT_NO_NEED_LOGIN）
+   - 进入任何页面都不需要登录
+   - 只有黑名单中的页面需要登录
+   - 适用于大部分 2C 应用（如美团、抖音）
+
+2. **默认需要登录策略**（DEFAULT_NEED_LOGIN）
+   - 进入任何页面都需要登录
+   - 只有白名单中的页面不需要登录
+   - 适用于 2B 和后台管理类应用
+
+#### 请求拦截
+- 统一的请求拦截器（`src/http/interceptor.ts`）
+- 支持登录拦截
+- 支持请求/响应错误处理
+
+### Testing Strategy
+
+当前项目未配置自动化测试框架。建议：
+- 使用 Vitest 进行单元测试
+- 使用 @vue/test-utils 进行组件测试
+- 使用 Playwright 进行端到端测试
+
+### Git Workflow
+
+#### 分支策略
+- `main` / `base` - 主分支
+- `base-i18n` - 国际化分支
+- `base-login` - 登录功能分支
+- `base-login-i18n` - 登录+国际化分支
+
+#### 提交规范
+使用 Conventional Commits 规范：
+- `feat:` - 新功能
+- `fix:` - 修复 bug
+- `docs:` - 文档更新
+- `style:` - 代码格式调整
+- `refactor:` - 重构
+- `test:` - 测试相关
+- `chore:` - 构建/工具相关
+
+#### Git Hooks
+- 使用 Husky 管理 Git hooks
+- 使用 lint-staged 在提交前自动修复代码
+
+## Domain Context
+
+### 业务领域
+
+#### 用户端（C端）
+- **商品模块**：商品列表、详情、分类、搜索
+- **购物车模块**：添加商品、数量调整、结算
+- **订单模块**：订单确认、订单列表、订单详情
+- **会员模块**：会员卡、会员权益
+- **金融模块**：信用额度、结算、核销、贷款申请
+
+#### 商家端（B端）
+- **仪表盘**：数据统计、概览
+- **商品管理**：商品列表、编辑
+- **订单管理**：订单列表、订单详情
+- **财务管理**：财务统计、结算、提现
+- **贷款协助**：协助用户申请贷款
+- **店铺设置**：店铺信息管理
+
+#### 银行端（B端）
+- **仪表盘**：数据统计
+- **客户管理**：客户列表、客户详情、交易记录、提现记录
+- **审核管理**：贷款审核列表、审核详情
+
+### 关键概念
+- **多端适配**：同一套代码适配 H5、App、小程序
+- **角色权限**：用户、商家、银行三种角色
+- **金融服务**：信用额度、贷款申请、结算、核销
+- **会员体系**：会员卡、会员权益
+
+## Important Constraints
+
+### 技术约束
+- **Node.js 版本**：必须 >= 20
+- **pnpm 版本**：必须 >= 9
+- **包管理器**：强制使用 pnpm（通过 `only-allow pnpm`）
+- **TypeScript**：必须使用 TypeScript 开发
+- **平台限制**：不同 UI 框架支持的平台有所不同
+
+### 业务约束
+- **多端兼容性**：需要确保在所有目标平台上正常运行
+- **性能要求**：分包优化、按需加载、减少包体积
+- **安全性**：登录拦截、请求加密、数据验证
+
+### 开发约束
+- **代码规范**：必须通过 ESLint 检查
+- **提交规范**：必须符合 Conventional Commits 规范
+- **文件忽略**：自动生成的文件（如 `src/service/**`）不应提交
+
+## External Dependencies
+
+### 平台依赖
+- **DCloudio** - uni-app 官方框架和工具链
+- **微信开发者工具** - 微信小程序开发调试
+- **HBuilderX** - App 平台打包（可选）
+
+### 第三方服务
+- **OpenAPI** - 用于自动生成 API 接口类型和代码
+- **Iconify** - 图标库（Carbon 图标集）
+
+### 构建依赖
+- **@uni-helper** - uni-app 辅助工具集
+- **@uni-ku** - uni-app 性能优化工具
+- **unplugin-auto-import** - 自动导入插件
+
+### 开发依赖
+- **@dcloudio/types** - uni-app 类型定义
+- **miniprogram-api-typings** - 小程序 API 类型定义
+- **rollup-plugin-visualizer** - 打包分析工具