feat(jd-order): 添加状态6和备注信息显示

- 为JD订单和Cookie管理添加新的状态值6（Cookie账号Ck失败）
- 在订单历史和Cookie历史抽屉中展示备注信息
- 更新状态标签颜色和文本映射以支持新状态
- 调整订单详情中的状态显示逻辑和标签文案
- 修改订单列表中关联订单ID字段的显示逻辑
- 优化历史记录条目的布局对齐方式以适应备注内容
- 在筛选器中添加新的状态选项以支持过滤新状态

.claude/commands/openspec/apply.md

@@ -0,0 +1,28 @@
+---
+name: OpenSpec: Apply
+description: Implement an approved OpenSpec change and keep tasks in sync.
+category: OpenSpec
+tags: [openspec, apply]
+---
+
+<!-- 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 -->

.claude/commands/openspec/archive.md

@@ -0,0 +1,26 @@
+---
+name: OpenSpec: Archive
+description: Archive a deployed OpenSpec change and update specs.
+category: OpenSpec
+tags: [openspec, archive]
+---
+
+<!-- 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. Identify the requested change ID (via the prompt or `openspec list`).
+2. Run `openspec archive <id> --yes` to let the CLI move the change and apply spec updates without prompts (use `--skip-specs` only for tooling-only work).
+3. Review the command output to confirm the target specs were updated and the change landed in `changes/archive/`.
+4. Validate with `openspec validate --strict` and inspect with `openspec show <id>` if anything looks off.
+
+**Reference**
+
+- Inspect refreshed specs with `openspec list --specs` and address any validation issues before handing off.
+<!-- OPENSPEC:END -->

.claude/commands/openspec/proposal.md

@@ -0,0 +1,32 @@
+---
+name: OpenSpec: Proposal
+description: Scaffold a new OpenSpec change and validate strictly.
+category: OpenSpec
+tags: [openspec, change]
+---
+
+<!-- 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.
+
+**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 -->

AGENTS.md

@@ -0,0 +1,21 @@
+<!-- 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 -->

CLAUDE.md

@@ -1,3 +1,25 @@
+<!-- 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 -->
+
 # CLAUDE.md
 
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.

openspec/AGENTS.md

@@ -0,0 +1,522 @@
+# 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] --skip-specs --yes` for tooling-only changes
+- 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 diff [change]         # Show spec differences
+openspec validate [item]       # Validate changes or specs
+openspec archive [change] [--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
+## 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 diff [change]     # What's changing?
+openspec validate --strict # Is it correct?
+openspec archive [change] [--yes|-y]  # Mark complete (add --yes for automation)
+```
+
+Remember: Specs are truth. Changes are proposals. Keep them in sync.

openspec/project.md

@@ -0,0 +1,88 @@
+# Project Context
+
+## Purpose
+
+Kami Frontend is a comprehensive management platform for multi-service card and account operations. The system provides centralized management for Apple Card, JD accounts, Walmart accounts, and T-Mall game accounts, including order tracking, cookie management, and merchant operations.
+
+## Tech Stack
+
+- **Frontend Framework**: Vue 3 with Composition API and `<script setup>` syntax
+- **UI Library**: Arco Design Vue
+- **State Management**: Pinia with modular stores
+- **Routing**: Vue Router 4
+- **Data Fetching**: TanStack Vue Query + Axios
+- **Build Tool**: Vite with TypeScript
+- **Package Manager**: pnpm (>=8.11.0)
+- **Code Quality**: ESLint, Stylelint, Prettier with Husky pre-commit hooks
+- **API Generation**: OpenAPI Generator with TypeScript Axios client
+- **Rich Text**: Milkdown editor
+- **Code Editor**: CodeMirror 6
+- **Charts**: ECharts with Vue integration
+
+## Project Conventions
+
+### Code Style
+
+- **Vue Components**: Use `<script setup>` syntax with Composition API
+- **TypeScript**: Strict mode enabled, prefer explicit typing
+- **File Naming**: kebab-case for directories, PascalCase for components
+- **CSS/Less**: Use Less preprocessor with Arco Design theme variables
+- **Imports**: Use path aliases (`@/` for `src/`)
+- **API Calls**: Use generated clients or manual definitions from `src/api/`
+
+### Architecture Patterns
+
+- **Dual API Approach**: Generated OpenAPI clients + manual API definitions
+- **Component Structure**: Feature-based organization under `src/views/`
+- **Global Components**: Auto-registered via `src/components/index.ts`
+- **State**: Pinia stores for app state, TanStack Query for server state
+- **Authentication**: JWT tokens with automatic refresh via axios interceptors
+
+### Testing Strategy
+
+Currently no formal testing framework is configured. Testing focuses on manual QA and code review.
+
+### Git Workflow
+
+- **Branching**: `develop` for development, `production` for releases
+- **Commits**: Conventional commits with Commitlint
+- **Pre-commit**: Husky + lint-staged for automated code quality checks
+- **PR Target**: Production branch for release merges
+
+## Domain Context
+
+### Business Domains
+
+- **Apple Card Management**: Card info, recharge history, order tracking
+- **JD Account Management**: Cookie management, order processing, account tracking
+- **Walmart Account Management**: Account groups, order management, statistics
+- **T-Mall Game Operations**: Account info, shop management, order processing
+- **Merchant Operations**: Configuration, steal card settings, deployment
+
+### Key Concepts
+
+- **Cookie Management**: JD session cookies for automated operations
+- **Order Processing**: Multi-platform order tracking and management
+- **Account Groups**: Batch account operations and management
+- **Merchant Steal Settings**: Configuration for automated account acquisition
+
+## Important Constraints
+
+- **Node.js**: Requires ^18.0.0 || >=20.0.0
+- **Browser Support**: Modern browsers with ES2020 support
+- **API Base URL**: Configurable via environment variables
+- **Authentication**: JWT-based with automatic token refresh
+- **OpenAPI**: Client generation from backend spec at `http://127.0.0.1:12401/api.json`
+
+## External Dependencies
+
+- **Backend API**: Node.js backend at configurable base URL
+- **OpenAPI Generator**: Client code generation from backend specification
+- **Arco Design**: UI component library with theme customization
+- **Chart Libraries**: ECharts for data visualization
+- **Code Editors**: CodeMirror for code editing, Milkdown for rich text
+
+### Development Services
+
+- **Development API**: `http://127.0.0.1:12401` (local development)
+- **Production API**: Configured via `VITE_API_BASE_URL` environment variable

src/views/jd-order/cookie/components/cookie-detail.vue

@@ -13,7 +13,8 @@
         </a-typography-text>
       </a-descriptions-item>
       <a-descriptions-item label="状态">
-        <a-tag v-if="cookieDetail.status === 1" color="green">正常</a-tag>
+        <a-tag v-if="cookieDetail.status === 0" color="gray">未知</a-tag>
+        <a-tag v-else-if="cookieDetail.status === 1" color="green">正常</a-tag>
         <a-tag v-else-if="cookieDetail.status === 2" color="orange">暂停</a-tag>
         <a-tag v-else-if="cookieDetail.status === 3" color="red">失效</a-tag>
         <a-tag v-else color="gray">未知</a-tag>

src/views/jd-order/cookie/components/cookie-history-drawer.vue

@@ -52,6 +52,15 @@
                   class="order-id"
                 />
               </div>
+
+              <!-- 备注信息 -->
+              <div v-if="item.remark" class="remark-info">
+                <span class="label">备注信息：</span>
+                <a-typography-text
+                  :content="item.remark"
+                  class="remark-content"
+                />
+              </div>
             </div>
           </a-timeline-item>
         </a-timeline>
@@ -302,10 +311,11 @@ watch(
 }
 
 .failure-info,
-.order-info {
+.order-info,
+.remark-info {
   margin: 4px 0;
   display: flex;
-  align-items: center;
+  align-items: flex-start;
   gap: 8px;
 }
 
@@ -320,6 +330,13 @@ watch(
   font-size: 13px;
 }
 
+.remark-content {
+  font-size: 13px;
+  color: var(--color-text-2);
+  word-break: break-all;
+  flex: 1;
+}
+
 .load-more {
   text-align: center;
   margin-top: 24px;

src/views/jd-order/cookie/index.vue

@@ -26,6 +26,7 @@
                     placeholder="请选择状态"
                     allow-clear
                   >
+                    <a-option :value="0">未知</a-option>
                     <a-option :value="1">正常</a-option>
                     <a-option :value="2">暂停</a-option>
                     <a-option :value="3">失效</a-option>
@@ -86,7 +87,8 @@
         @page-size-change="onPageSizeChange"
       >
         <template #status="{ record }">
-          <a-tag v-if="record.status === 1" color="green">正常</a-tag>
+          <a-tag v-if="record.status === 0" color="gray">未知</a-tag>
+          <a-tag v-else-if="record.status === 1" color="green">正常</a-tag>
           <a-tag v-else-if="record.status === 2" color="orange">暂停</a-tag>
           <a-tag v-else-if="record.status === 3" color="red">失效</a-tag>
           <a-tag v-else color="gray">未知</a-tag>

src/views/jd-order/jd-orders/components/jd-order-history-drawer.vue

@@ -74,6 +74,13 @@
                   {{ item.jdOrderId }}
                 </a-typography-text>
               </div>
+
+              <div v-if="item.remark" class="detail-item remark-item">
+                <span class="detail-label">备注信息:</span>
+                <a-typography-text class="remark-content">
+                  {{ item.remark }}
+                </a-typography-text>
+              </div>
             </div>
           </div>
         </a-timeline-item>
@@ -296,11 +303,21 @@ watch(
 
 .detail-item {
   display: flex;
-  align-items: center;
+  align-items: flex-start;
   gap: 8px;
   font-size: 14px;
 }
 
+.remark-item {
+  align-items: flex-start;
+}
+
+.remark-content {
+  color: var(--color-text-2);
+  word-break: break-all;
+  flex: 1;
+}
+
 .detail-label {
   color: var(--color-text-3);
   min-width: 80px;

src/views/jd-order/jd-orders/index.vue

@@ -31,6 +31,7 @@
                     <a-option :value="3">已发货</a-option>
                     <a-option :value="4">已过期</a-option>
                     <a-option :value="5">已取消</a-option>
+                    <a-option :value="6">Cookie账号Ck失败</a-option>
                   </a-select>
                 </a-form-item>
               </a-col>
@@ -93,6 +94,9 @@
           <a-tag v-else-if="record.status === 3" color="blue">已发货</a-tag>
           <a-tag v-else-if="record.status === 4" color="red">已过期</a-tag>
           <a-tag v-else-if="record.status === 5" color="gray">已取消</a-tag>
+          <a-tag v-else-if="record.status === 6" color="purple">
+            Cookie账号Ck失败
+          </a-tag>
           <a-tag v-else color="gray">未知</a-tag>
         </template>
         <template #amount="{ record }">
@@ -201,8 +205,8 @@
           <a-descriptions-item label="支付链接过期时间">
             {{ currentOrder.wxPayExpireAt || '-' }}
           </a-descriptions-item>
-          <a-descriptions-item label="当前关联订单ID">
+          <a-descriptions-item label="关联订单ID">
-            {{ currentOrder.currentOrderId || '-' }}
+            {{ currentOrder.orderId || '-' }}
           </a-descriptions-item>
           <a-descriptions-item label="卡号">
             <a-typography-text v-if="currentOrder.cardNo" copyable>
@@ -354,13 +358,13 @@ const columns: TableColumnData[] = [
     width: 100
   },
   {
-    title: '当前关联订单ID',
+    title: '关联订单ID',
-    dataIndex: 'currentOrderId',
+    dataIndex: 'orderId',
     width: 140,
     ellipsis: true,
     tooltip: true,
     render: ({ record }) => {
-      return record.currentOrderId || '-';
+      return record.orderId || '-';
     }
   },
   {
@@ -538,7 +542,8 @@ const getStatusColor = (status: number): string => {
     2: 'green', // 已支付
     3: 'blue', // 已发货
     4: 'red', // 已过期
-    5: 'gray' // 已取消
+    5: 'gray', // 已取消
+    6: 'purple' // Cookie账号Ck失败
   };
   return colors[status] || 'gray';
 };
@@ -550,7 +555,8 @@ const getStatusText = (status: number): string => {
     2: '已支付',
     3: '已发货',
     4: '已过期',
-    5: '已取消'
+    5: '已取消',
+    6: 'Cookie账号Ck失败'
   };
   return statusMap[status] || '未知';
 };

src/views/jd-order/order/components/order-detail.vue

@@ -30,8 +30,11 @@
         <a-descriptions-item label="订单状态">
           <a-tag v-if="orderData.status === 1" color="orange">待支付</a-tag>
           <a-tag v-else-if="orderData.status === 2" color="green">已支付</a-tag>
-          <a-tag v-else-if="orderData.status === 3" color="blue">已发货</a-tag>
+          <a-tag v-else-if="orderData.status === 3" color="red">已过期</a-tag>
-          <a-tag v-else-if="orderData.status === 4" color="red">已过期</a-tag>
+          <a-tag v-else-if="orderData.status === 4" color="gray">已取消</a-tag>
+          <a-tag v-else-if="orderData.status === 5" color="purple">
+            Cookie账号Ck失败
+          </a-tag>
           <a-tag v-else color="gray">未知</a-tag>
         </a-descriptions-item>
         <a-descriptions-item label="最后请求时间">

src/views/jd-order/order/components/order-history-drawer.vue

@@ -62,6 +62,13 @@
                   {{ item.jdOrderId }}
                 </a-typography-text>
               </div>
+
+              <div v-if="item.remark" class="detail-item remark-item">
+                <span class="detail-label">备注信息:</span>
+                <a-typography-text class="remark-content">
+                  {{ item.remark }}
+                </a-typography-text>
+              </div>
             </div>
           </div>
         </a-timeline-item>
@@ -267,11 +274,21 @@ watch(
 
 .detail-item {
   display: flex;
-  align-items: center;
+  align-items: flex-start;
   gap: 8px;
   font-size: 14px;
 }
 
+.remark-item {
+  align-items: flex-start;
+}
+
+.remark-content {
+  color: var(--color-text-2);
+  word-break: break-all;
+  flex: 1;
+}
+
 .detail-label {
   color: var(--color-text-3);
   min-width: 80px;

src/views/jd-order/order/index.vue

@@ -28,8 +28,9 @@
                   >
                     <a-option :value="1">待支付</a-option>
                     <a-option :value="2">已支付</a-option>
-                    <a-option :value="3">已发货</a-option>
+                    <a-option :value="3">已过期</a-option>
-                    <a-option :value="4">已过期</a-option>
+                    <a-option :value="4">已取消</a-option>
+                    <a-option :value="5">Cookie账号Ck失败</a-option>
                   </a-select>
                 </a-form-item>
               </a-col>
@@ -82,8 +83,11 @@
         <template #status="{ record }">
           <a-tag v-if="record.status === 1" color="orange">待支付</a-tag>
           <a-tag v-else-if="record.status === 2" color="green">已支付</a-tag>
-          <a-tag v-else-if="record.status === 3" color="blue">已发货</a-tag>
+          <a-tag v-else-if="record.status === 3" color="red">已过期</a-tag>
-          <a-tag v-else-if="record.status === 4" color="red">已过期</a-tag>
+          <a-tag v-else-if="record.status === 4" color="gray">已取消</a-tag>
+          <a-tag v-else-if="record.status === 5" color="purple">
+            Cookie账号Ck失败
+          </a-tag>
           <a-tag v-else color="gray">未知</a-tag>
         </template>
         <template #amount="{ record }">