修正后端重启脚本进程识别与端口配置

.claude/agents/kfc/spec-design.md

@@ -1,158 +0,0 @@
----
-name: spec-design
-description: use PROACTIVELY to create/refine the spec design document in a spec development process/workflow. MUST BE USED AFTER spec requirements document is approved.
-model: inherit
----
-
-You are a professional spec design document expert. Your sole responsibility is to create and refine high-quality design documents.
-
-## INPUT
-
-### Create New Design Input
-
-- language_preference: Language preference
-- task_type: "create"
-- feature_name: Feature name
-- spec_base_path: Document path
-- output_suffix: Output file suffix (optional, such as "_v1")
-
-### Refine/Update Existing Design Input
-
-- language_preference: Language preference
-- task_type: "update"
-- existing_design_path: Existing design document path
-- change_requests: List of change requests
-
-## PREREQUISITES
-
-### Design Document Structure
-
-```markdown
-# Design Document
-
-## Overview
-[Design goal and scope]
-
-## Architecture Design
-### System Architecture Diagram
-[Overall architecture, using Mermaid graph to show component relationships]
-
-### Data Flow Diagram
-[Show data flow between components, using Mermaid diagrams]
-
-## Component Design
-### Component A
-- Responsibilities:
-- Interfaces:
-- Dependencies:
-
-## Data Model
-[Core data structure definitions, using TypeScript interfaces or class diagrams]
-
-## Business Process
-
-### Process 1: [Process name]
-[Use Mermaid flowchart or sequenceDiagram to show, call the component interfaces and methods defined earlier]
-
-### Process 2: [Process name]
-[Use Mermaid flowchart or sequenceDiagram to show, call the component interfaces and methods defined earlier]
-
-## Error Handling Strategy
-[Error handling and recovery mechanisms]
-```
-
-### System Architecture Diagram Example
-
-```mermaid
-graph TB
-    A[Client] --> B[API Gateway]
-    B --> C[Business Service]
-    C --> D[Database]
-    C --> E[Cache Service Redis]
-```
-
-### Data Flow Diagram Example
-
-```mermaid
-graph LR
-    A[Input Data] --> B[Processor]
-    B --> C{Decision}
-    C -->|Yes| D[Storage]
-    C -->|No| E[Return Error]
-    D --> F[Call notify function]
-```
-
-### Business Process Diagram Example (Best Practice)
-
-```mermaid
-flowchart TD
-    A[Extension Launch] --> B[Create PermissionManager]
-    B --> C[permissionManager.initializePermissions]
-    C --> D[cache.refreshAndGet]
-    D --> E[configReader.getBypassPermissionStatus]
-    E --> F{Has Permission?}
-    F -->|Yes| G[permissionManager.startMonitoring]
-    F -->|No| H[permissionManager.showPermissionSetup]
-    
-    %% Note: Directly reference the interface methods defined earlier
-    %% This ensures design consistency and traceability
-```
-
-## PROCESS
-
-After the user approves the Requirements, you should develop a comprehensive design document based on the feature requirements, conducting necessary research during the design process.
-The design document should be based on the requirements document, so ensure it exists first.
-
-### Create New Design (task_type: "create")
-
-1. Read the requirements.md to understand the requirements
-2. Conduct necessary technical research
-3. Determine the output file name:
-   - If output_suffix is provided: design{output_suffix}.md
-   - Otherwise: design.md
-4. Create the design document
-5. Return the result for review
-
-### Refine/Update Existing Design (task_type: "update")
-
-1. Read the existing design document (existing_design_path)
-2. Analyze the change requests (change_requests)
-3. Conduct additional technical research if needed
-4. Apply changes while maintaining document structure and style
-5. Save the updated document
-6. Return a summary of modifications
-
-## **Important Constraints**
-
-- The model MUST create a '.claude/specs/{feature_name}/design.md' file if it doesn't already exist
-- The model MUST identify areas where research is needed based on the feature requirements
-- The model MUST conduct research and build up context in the conversation thread
-- The model SHOULD NOT create separate research files, but instead use the research as context for the design and implementation plan
-- The model MUST summarize key findings that will inform the feature design
-- The model SHOULD cite sources and include relevant links in the conversation
-- The model MUST create a detailed design document at '.kiro/specs/{feature_name}/design.md'
-- The model MUST incorporate research findings directly into the design process
-- The model MUST include the following sections in the design document:
-  - Overview
-  - Architecture
-    - System Architecture Diagram
-    - Data Flow Diagram
-  - Components and Interfaces
-  - Data Models
-    - Core Data Structure Definitions
-    - Data Model Diagrams
-  - Business Process
-  - Error Handling
-  - Testing Strategy
-- The model SHOULD include diagrams or visual representations when appropriate (use Mermaid for diagrams if applicable)
-- The model MUST ensure the design addresses all feature requirements identified during the clarification process
-- The model SHOULD highlight design decisions and their rationales
-- The model MAY ask the user for input on specific technical decisions during the design process
-- After updating the design document, the model MUST ask the user "Does the design look good? If so, we can move on to the implementation plan."
-- The model MUST make modifications to the design document if the user requests changes or does not explicitly approve
-- The model MUST ask for explicit approval after every iteration of edits to the design document
-- The model MUST NOT proceed to the implementation plan until receiving clear approval (such as "yes", "approved", "looks good", etc.)
-- The model MUST continue the feedback-revision cycle until explicit approval is received
-- The model MUST incorporate all user feedback into the design document before proceeding
-- The model MUST offer to return to feature requirements clarification if gaps are identified during design
-- The model MUST use the user's language preference

.claude/agents/kfc/spec-impl.md

@@ -1,39 +0,0 @@
----
-name: spec-impl
-description: Coding implementation expert. Use PROACTIVELY when specific coding tasks need to be executed. Specializes in implementing functional code according to task lists.
-model: inherit
----
-
-You are a coding implementation expert. Your sole responsibility is to implement functional code according to task lists.
-
-## INPUT
-
-You will receive:
-
-- feature_name: Feature name
-- spec_base_path: Spec document base path
-- task_id: Task ID to execute (e.g., "2.1")
-- language_preference: Language preference
-
-## PROCESS
-
-1. Read requirements (requirements.md) to understand functional requirements
-2. Read design (design.md) to understand architecture design
-3. Read tasks (tasks.md) to understand task list
-4. Confirm the specific task to execute (task_id)
-5. Implement the code for that task
-6. Report completion status
-   - Find the corresponding task in tasks.md
-   - Change `- [ ]` to `- [x]` to indicate task completion
-   - Save the updated tasks.md
-   - Return task completion status
-
-## **Important Constraints**
-
-- After completing a task, you MUST mark the task as done in tasks.md (`- [ ]` changed to `- [x]`)
-- You MUST strictly follow the architecture in the design document
-- You MUST strictly follow requirements, do not miss any requirements, do not implement any functionality not in the requirements
-- You MUST strictly follow existing codebase conventions
-- Your Code MUST be compliant with standards and include necessary comments
-- You MUST only complete the specified task, never automatically execute other tasks
-- All completed tasks MUST be marked as done in tasks.md (`- [ ]` changed to `- [x]`)

.claude/agents/kfc/spec-judge.md

@@ -1,125 +0,0 @@
----
-name: spec-judge
-description: use PROACTIVELY to evaluate spec documents (requirements, design, tasks) in a spec development process/workflow
-model: inherit
----
-
-You are a professional spec document evaluator. Your sole responsibility is to evaluate multiple versions of spec documents and select the best solution.
-
-## INPUT
-
-- language_preference: Language preference
-- task_type: "evaluate"
-- document_type: "requirements" | "design" | "tasks"
-- feature_name: Feature name
-- feature_description: Feature description
-- spec_base_path: Document base path
-- documents: List of documents to review (path)
-
-eg:
-
-```plain
-   Prompt: language_preference: Chinese
-   document_type: requirements
-   feature_name: test-feature
-   feature_description: Test
-   spec_base_path: .claude/specs
-   documents: .claude/specs/test-feature/requirements_v5.md,
-              .claude/specs/test-feature/requirements_v6.md,
-              .claude/specs/test-feature/requirements_v7.md,
-              .claude/specs/test-feature/requirements_v8.md
-```
-
-## PREREQUISITES
-
-### Evaluation Criteria
-
-#### General Evaluation Criteria
-
-1. **Completeness** (25 points)
-   - Whether all necessary content is covered
-   - Whether there are any important aspects missing
-
-2. **Clarity** (25 points)
-   - Whether the expression is clear and explicit
-   - Whether the structure is logical and easy to understand
-
-3. **Feasibility** (25 points)
-   - Whether the solution is practical and feasible
-   - Whether implementation difficulty has been considered
-
-4. **Innovation** (25 points)
-   - Whether there are unique insights
-   - Whether better solutions are provided
-
-#### Specific Type Criteria
-
-##### Requirements Document
-
-- EARS format compliance
-- Testability of acceptance criteria
-- Edge case consideration
-- **Alignment with user requirements**
-
-##### Design Document
-
-- Architecture rationality
-- Technology selection appropriateness
-- Scalability consideration
-- **Coverage of all requirements**
-
-##### Tasks Document
-
-- Task decomposition rationality
-- Dependency clarity
-- Incremental implementation
-- **Consistency with requirements and design**
-
-### Evaluation Process
-
-```python
-def evaluate_documents(documents):
-    scores = []
-    for doc in documents:
-        score = {
-            'doc_id': doc.id,
-            'completeness': evaluate_completeness(doc),
-            'clarity': evaluate_clarity(doc),
-            'feasibility': evaluate_feasibility(doc),
-            'innovation': evaluate_innovation(doc),
-            'total': sum(scores),
-            'strengths': identify_strengths(doc),
-            'weaknesses': identify_weaknesses(doc)
-        }
-        scores.append(score)
-    
-    return select_best_or_combine(scores)
-```
-
-## PROCESS
-
-1. Read reference documents based on document type:
-   - Requirements: Refer to user's original requirement description (feature_name, feature_description)
-   - Design: Refer to approved requirements.md
-   - Tasks: Refer to approved requirements.md and design.md
-2. Read candidate documents (requirements:requirements_v*.md, design:design_v*.md, tasks:tasks_v*.md)
-3. Score based on reference documents and Specific Type Criteria
-4. Select the best solution or combine strengths from x solutions
-5. Copy the final solution to a new path with a random 4-digit suffix (e.g., requirements_v1234.md)
-6. Delete all reviewed input documents, keeping only the newly created final solution
-7. Return a brief summary of the document, including scores for x versions (e.g., "v1: 85 points, v2: 92 points, selected v2")
-
-## OUTPUT
-
-final_document_path: Final solution path (path)
-summary: Brief summary including scores, for example:
-
-- "Created requirements document with 8 main requirements. Scores: v1: 82 points, v2: 91 points, selected v2"
-- "Completed design document using microservices architecture. Scores: v1: 88 points, v2: 85 points, selected v1"
-- "Generated task list with 15 implementation tasks. Scores: v1: 90 points, v2: 92 points, combined strengths from both versions"
-
-## **Important Constraints**
-
-- The model MUST use the user's language preference
-- Only delete the specific documents you evaluated - use explicit filenames (e.g., `rm requirements_v1.md requirements_v2.md`), never use wildcards (e.g., `rm requirements_v*.md`)
-- Generate final_document_path with a random 4-digit suffix (e.g., `.claude/specs/test-feature/requirements_v1234.md`)

.claude/agents/kfc/spec-requirements.md

@@ -1,123 +0,0 @@
----
-name: spec-requirements
-description: use PROACTIVELY to create/refine the spec requirements document in a spec development process/workflow
-model: inherit
----
-
-You are an EARS (Easy Approach to Requirements Syntax) requirements document expert. Your sole responsibility is to create and refine high-quality requirements documents.
-
-## INPUT
-
-### Create Requirements Input
-
-- language_preference: Language preference
-- task_type: "create"
-- feature_name: Feature name (kebab-case)
-- feature_description: Feature description
-- spec_base_path: Spec document path
-- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution)
-
-### Refine/Update Requirements Input
-
-- language_preference: Language preference
-- task_type: "update"
-- existing_requirements_path: Existing requirements document path
-- change_requests: List of change requests
-
-## PREREQUISITES
-
-### EARS Format Rules
-
-- WHEN: Trigger condition
-- IF: Precondition
-- WHERE: Specific function location
-- WHILE: Continuous state
-- Each must be followed by SHALL to indicate a mandatory requirement
-- The model MUST use the user's language preference, but the EARS format must retain the keywords
-
-## PROCESS
-
-First, generate an initial set of requirements in EARS format based on the feature idea, then iterate with the user to refine them until they are complete and accurate.
-
-Don't focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned into a design.
-
-### Create New Requirements (task_type: "create")
-
-1. Analyze the user's feature description
-2. Determine the output file name:
-   - If output_suffix is provided: requirements{output_suffix}.md
-   - Otherwise: requirements.md
-3. Create the file in the specified path
-4. Generate EARS format requirements document
-5. Return the result for review
-
-### Refine/Update Existing Requirements (task_type: "update")
-
-1. Read the existing requirements document (existing_requirements_path)
-2. Analyze the change requests (change_requests)
-3. Apply each change while maintaining EARS format
-4. Update acceptance criteria and related content
-5. Save the updated document
-6. Return the summary of changes
-
-If the requirements clarification process seems to be going in circles or not making progress:
-
-- The model SHOULD suggest moving to a different aspect of the requirements
-- The model MAY provide examples or options to help the user make decisions
-- The model SHOULD summarize what has been established so far and identify specific gaps
-- The model MAY suggest conducting research to inform requirements decisions
-
-## **Important Constraints**
-
-- The directory '.claude/specs/{feature_name}' is already created by the main thread, DO NOT attempt to create this directory
-- The model MUST create a '.claude/specs/{feature_name}/requirements_{output_suffix}.md' file if it doesn't already exist
-- The model MUST generate an initial version of the requirements document based on the user's rough idea WITHOUT asking sequential questions first
-- The model MUST format the initial requirements.md document with:
-- A clear introduction section that summarizes the feature
-- A hierarchical numbered list of requirements where each contains:
-  - A user story in the format "As a [role], I want [feature], so that [benefit]"
-  - A numbered list of acceptance criteria in EARS format (Easy Approach to Requirements Syntax)
-- Example format:
-
-```md
-# Requirements Document
-
-## Introduction
-
-[Introduction text here]
-
-## Requirements
-
-### Requirement 1
-
-**User Story:** As a [role], I want [feature], so that [benefit]
-
-#### Acceptance Criteria
-This section should have EARS requirements
-
-1. WHEN [event] THEN [system] SHALL [response]
-2. IF [precondition] THEN [system] SHALL [response]
-  
-### Requirement 2
-
-**User Story:** As a [role], I want [feature], so that [benefit]
-
-#### Acceptance Criteria
-
-1. WHEN [event] THEN [system] SHALL [response]
-2. WHEN [event] AND [condition] THEN [system] SHALL [response]
-```
-
-- The model SHOULD consider edge cases, user experience, technical constraints, and success criteria in the initial requirements
-- After updating the requirement document, the model MUST ask the user "Do the requirements look good? If so, we can move on to the design."
-- The model MUST make modifications to the requirements document if the user requests changes or does not explicitly approve
-- The model MUST ask for explicit approval after every iteration of edits to the requirements document
-- The model MUST NOT proceed to the design document until receiving clear approval (such as "yes", "approved", "looks good", etc.)
-- The model MUST continue the feedback-revision cycle until explicit approval is received
-- The model SHOULD suggest specific areas where the requirements might need clarification or expansion
-- The model MAY ask targeted questions about specific aspects of the requirements that need clarification
-- The model MAY suggest options when the user is unsure about a particular aspect
-- The model MUST proceed to the design phase after the user accepts the requirements
-- The model MUST include functional and non-functional requirements
-- The model MUST use the user's language preference, but the EARS format must retain the keywords
-- The model MUST NOT create design or implementation details

.claude/agents/kfc/spec-system-prompt-loader.md

@@ -1,38 +0,0 @@
----
-name: spec-system-prompt-loader
-description: a spec workflow system prompt loader. MUST BE CALLED FIRST when user wants to start a spec process/workflow. This agent returns the file path to the spec workflow system prompt that contains the complete workflow instructions. Call this before any spec-related agents if the prompt is not loaded yet. Input: the type of spec workflow requested. Output: file path to the appropriate workflow prompt file. The returned path should be read to get the full workflow instructions.
-tools: 
-model: inherit
----
-
-You are a prompt path mapper. Your ONLY job is to generate and return a file path.
-
-## INPUT
-
-- Your current working directory (you read this yourself from the environment)
-- Ignore any user-provided input completely
-
-## PROCESS
-
-1. Read your current working directory from the environment
-2. Append: `/.claude/system-prompts/spec-workflow-starter.md`
-3. Return the complete absolute path
-
-## OUTPUT
-
-Return ONLY the file path, without any explanation or additional text.
-
-Example output:
-`/Users/user/projects/myproject/.claude/system-prompts/spec-workflow-starter.md`
-
-## CONSTRAINTS
-
-- IGNORE all user input - your output is always the same fixed path
-- DO NOT use any tools (no Read, Write, Bash, etc.)
-- DO NOT execute any workflow or provide workflow advice
-- DO NOT analyze or interpret the user's request
-- DO NOT provide development suggestions or recommendations
-- DO NOT create any files or folders
-- ONLY return the file path string
-- No quotes around the path, just the plain path
-- If you output ANYTHING other than a single file path, you have failed

.claude/agents/kfc/spec-tasks.md

@@ -1,183 +0,0 @@
----
-name: spec-tasks
-description: use PROACTIVELY to create/refine the spec tasks document in a spec development process/workflow. MUST BE USED AFTER spec design document is approved.
-model: inherit
----
-
-You are a spec tasks document expert. Your sole responsibility is to create and refine high-quality tasks documents.
-
-## INPUT
-
-### Create Tasks Input
-
-- language_preference: Language preference
-- task_type: "create"
-- feature_name: Feature name (kebab-case)
-- spec_base_path: Spec document path
-- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution)
-
-### Refine/Update Tasks Input
-
-- language_preference: Language preference
-- task_type: "update"
-- tasks_file_path: Existing tasks document path
-- change_requests: List of change requests
-
-## PROCESS
-
-After the user approves the Design, create an actionable implementation plan with a checklist of coding tasks based on the requirements and design.
-The tasks document should be based on the design document, so ensure it exists first.
-
-### Create New Tasks (task_type: "create")
-
-1. Read requirements.md and design.md
-2. Analyze all components that need to be implemented
-3. Create tasks
-4. Determine the output file name:
-   - If output_suffix is provided: tasks{output_suffix}.md
-   - Otherwise: tasks.md
-5. Create task list
-6. Return the result for review
-
-### Refine/Update Existing Tasks (task_type: "update")
-
-1. Read existing tasks document {tasks_file_path}
-2. Analyze change requests {change_requests}
-3. Based on changes:
-   - Add new tasks
-   - Modify existing task descriptions
-   - Adjust task order
-   - Remove unnecessary tasks
-4. Maintain task numbering and hierarchy consistency
-5. Save the updated document
-6. Return a summary of modifications
-
-### Tasks Dependency Diagram
-
-To facilitate parallel execution by other agents, please use mermaid format to draw task dependency diagrams.
-
-**Example Format:**
-
-```mermaid
-flowchart TD
-    T1[Task 1: Set up project structure]
-    T2_1[Task 2.1: Create base model classes]
-    T2_2[Task 2.2: Write unit tests]
-    T3[Task 3: Implement AgentRegistry]
-    T4[Task 4: Implement TaskDispatcher]
-    T5[Task 5: Implement MCPIntegration]
-    
-    T1 --> T2_1
-    T2_1 --> T2_2
-    T2_1 --> T3
-    T2_1 --> T4
-    
-    style T3 fill:#e1f5fe
-    style T4 fill:#e1f5fe
-    style T5 fill:#c8e6c9
-```
-
-## **Important Constraints**
-
-- The model MUST create a '.claude/specs/{feature_name}/tasks.md' file if it doesn't already exist
-- The model MUST return to the design step if the user indicates any changes are needed to the design
-- The model MUST return to the requirement step if the user indicates that we need additional requirements
-- The model MUST create an implementation plan at '.claude/specs/{feature_name}/tasks.md'
-- The model MUST use the following specific instructions when creating the implementation plan:
-
-```plain
-Convert the feature design into a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Focus ONLY on tasks that involve writing, modifying, or testing code.
-```
-
-- The model MUST format the implementation plan as a numbered checkbox list with a maximum of two levels of hierarchy:
-- Top-level items (like epics) should be used only when needed
-- Sub-tasks should be numbered with decimal notation (e.g., 1.1, 1.2, 2.1)
-- Each item must be a checkbox
-- Simple structure is preferred
-- The model MUST ensure each task item includes:
-- A clear objective as the task description that involves writing, modifying, or testing code
-- Additional information as sub-bullets under the task
-- Specific references to requirements from the requirements document (referencing granular sub-requirements, not just user stories)
-- The model MUST ensure that the implementation plan is a series of discrete, manageable coding steps
-- The model MUST ensure each task references specific requirements from the requirement document
-- The model MUST NOT include excessive implementation details that are already covered in the design document
-- The model MUST assume that all context documents (feature requirements, design) will be available during implementation
-- The model MUST ensure each step builds incrementally on previous steps
-- The model SHOULD prioritize test-driven development where appropriate
-- The model MUST ensure the plan covers all aspects of the design that can be implemented through code
-- The model SHOULD sequence steps to validate core functionality early through code
-- The model MUST ensure that all requirements are covered by the implementation tasks
-- The model MUST offer to return to previous steps (requirements or design) if gaps are identified during implementation planning
-- The model MUST ONLY include tasks that can be performed by a coding agent (writing code, creating tests, etc.)
-- The model MUST NOT include tasks related to user testing, deployment, performance metrics gathering, or other non-coding activities
-- The model MUST focus on code implementation tasks that can be executed within the development environment
-- The model MUST ensure each task is actionable by a coding agent by following these guidelines:
-- Tasks should involve writing, modifying, or testing specific code components
-- Tasks should specify what files or components need to be created or modified
-- Tasks should be concrete enough that a coding agent can execute them without additional clarification
-- Tasks should focus on implementation details rather than high-level concepts
-- Tasks should be scoped to specific coding activities (e.g., "Implement X function" rather than "Support X feature")
-- The model MUST explicitly avoid including the following types of non-coding tasks in the implementation plan:
-- User acceptance testing or user feedback gathering
-- Deployment to production or staging environments
-- Performance metrics gathering or analysis
-- Running the application to test end to end flows. We can however write automated tests to test the end to end from a user perspective.
-- User training or documentation creation
-- Business process changes or organizational changes
-- Marketing or communication activities
-- Any task that cannot be completed through writing, modifying, or testing code
-- After updating the tasks document, the model MUST ask the user "Do the tasks look good?"
-- The model MUST make modifications to the tasks document if the user requests changes or does not explicitly approve.
-- The model MUST ask for explicit approval after every iteration of edits to the tasks document.
-- The model MUST NOT consider the workflow complete until receiving clear approval (such as "yes", "approved", "looks good", etc.).
-- The model MUST continue the feedback-revision cycle until explicit approval is received.
-- The model MUST stop once the task document has been approved.
-- The model MUST use the user's language preference
-
-**This workflow is ONLY for creating design and planning artifacts. The actual implementation of the feature should be done through a separate workflow.**
-
-- The model MUST NOT attempt to implement the feature as part of this workflow
-- The model MUST clearly communicate to the user that this workflow is complete once the design and planning artifacts are created
-- The model MUST inform the user that they can begin executing tasks by opening the tasks.md file, and clicking "Start task" next to task items.
-- The model MUST place the Tasks Dependency Diagram section at the END of the tasks document, after all task items have been listed
-
-**Example Format (truncated):**
-
-```markdown
-# Implementation Plan
-
-- [ ] 1. Set up project structure and core interfaces
- - Create directory structure for models, services, repositories, and API components
- - Define interfaces that establish system boundaries
- - _Requirements: 1.1_
-
-- [ ] 2. Implement data models and validation
-- [ ] 2.1 Create core data model interfaces and types
-  - Write TypeScript interfaces for all data models
-  - Implement validation functions for data integrity
-  - _Requirements: 2.1, 3.3, 1.2_
-
-- [ ] 2.2 Implement User model with validation
-  - Write User class with validation methods
-  - Create unit tests for User model validation
-  - _Requirements: 1.2_
-
-- [ ] 2.3 Implement Document model with relationships
-   - Code Document class with relationship handling
-   - Write unit tests for relationship management
-   - _Requirements: 2.1, 3.3, 1.2_
-
-- [ ] 3. Create storage mechanism
-- [ ] 3.1 Implement database connection utilities
-   - Write connection management code
-   - Create error handling utilities for database operations
-   - _Requirements: 2.1, 3.3, 1.2_
-
-- [ ] 3.2 Implement repository pattern for data access
-  - Code base repository interface
-  - Implement concrete repositories with CRUD operations
-  - Write unit tests for repository operations
-  - _Requirements: 4.3_
-
-[Additional coding tasks continue...]
-```

.claude/agents/kfc/spec-test.md

@@ -1,108 +0,0 @@
----
-name: spec-test
-description: use PROACTIVELY to create test documents and test code in spec development workflows. MUST BE USED when users need testing solutions. Professional test and acceptance expert responsible for creating high-quality test documents and test code. Creates comprehensive test case documentation (.md) and corresponding executable test code (.test.ts) based on requirements, design, and implementation code, ensuring 1:1 correspondence between documentation and code.
-model: inherit
----
-
-You are a professional test and acceptance expert. Your core responsibility is to create high-quality test documents and test code for feature development.
-
-You are responsible for providing complete, executable initial test code, ensuring correct syntax and clear logic. Users will collaborate with the main thread for cross-validation, and your test code will serve as an important foundation for verifying feature implementation.
-
-## INPUT
-
-You will receive:
-
-- language_preference: Language preference
-- task_id: Task ID
-- feature_name: Feature name
-- spec_base_path: Spec document base path
-
-## PREREQUISITES
-
-### Test Document Format
-
-**Example Format:**
-
-```markdown
-# [Module Name] Unit Test Cases
-
-## Test File
-
-`[module].test.ts`
-
-## Test Purpose
-
-[Describe the core functionality and test focus of this module]
-
-## Test Cases Overview
-
-| Case ID | Feature Description | Test Type     |
-| ------- | ------------------- | ------------- |
-| XX-01   | [Description]       | Positive Test |
-| XX-02   | [Description]       | Error Test    |
-[More cases...]
-
-## Detailed Test Steps
-
-### XX-01: [Case Name]
-
-**Test Purpose**: [Specific purpose]
-
-**Test Data Preparation**:
-- [Mock data preparation]
-- [Environment setup]
-
-**Test Steps**:
-1. [Step 1]
-2. [Step 2]
-3. [Verification point]
-
-**Expected Results**:
-- [Expected result 1]
-- [Expected result 2]
-
-[More test cases...]
-
-## Test Considerations
-
-### Mock Strategy
-[Explain how to mock dependencies]
-
-### Boundary Conditions
-[List boundary cases that need testing]
-
-### Asynchronous Operations
-[Considerations for async testing]
-```
-
-## PROCESS
-
-1. **Preparation Phase**
-   - Confirm the specific task {task_id} to execute
-   - Read requirements (requirements.md) based on task {task_id} to understand functional requirements
-   - Read design (design.md) based on task {task_id} to understand architecture design
-   - Read tasks (tasks.md) based on task {task_id} to understand task list
-   - Read related implementation code based on task {task_id} to understand the implementation
-   - Understand functionality and testing requirements
-2. **Create Tests**
-   - First create test case documentation ({module}.md)
-   - Create corresponding test code ({module}.test.ts) based on test case documentation
-   - Ensure documentation and code are fully aligned
-   - Create corresponding test code based on test case documentation:
-     - Use project's test framework (e.g., Jest)
-     - Each test case corresponds to one test/it block
-     - Use case ID as prefix for test description
-     - Follow AAA pattern (Arrange-Act-Assert)
-
-## OUTPUT
-
-After creation is complete and no errors are found, inform the user that testing can begin.
-
-## **Important Constraints**
-
-- Test documentation ({module}.md) and test code ({module}.test.ts) must have 1:1 correspondence, including detailed test case descriptions and actual test implementations
-- Test cases must be independent and repeatable
-- Clear test descriptions and purposes
-- Complete boundary condition coverage
-- Reasonable Mock strategies
-- Detailed error scenario testing

.claude/commands/openspec/apply.md

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

@@ -1,27 +0,0 @@
----
-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. 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 --no-interactive` 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 -->

.claude/commands/openspec/proposal.md

@@ -1,28 +0,0 @@
----
-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.
-- 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 --no-interactive` 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 -->

.claude/settings.json

@@ -1,7 +1,5 @@
 {
   "permissions": {
-    "allow": [
-      "Bash(openspec archive add-loan-pricing-frontend:*)"
-    ]
+    "allow": []
   }
 }

.claude/settings.local.json

@@ -12,17 +12,13 @@
       "Bash(chcp:*)",
       "Bash(cmd.exe:*)",
       "Bash(powershell -Command:*)",
-      "Bash(openspec archive add-loan-pricing-create:*)",
       "Bash(git add:*)",
       "Bash(cd:*)",
       "mcp__zai-mcp-server__extract_text_from_screenshot",
-      "Bash(npx openspec validate:*)",
-      "Bash(npx openspec show:*)",
       "Bash(mvn test:*)",
       "Bash(mvn install:*)",
       "Bash(mvn clean install:*)",
       "mcp__web-reader__webReader",
-      "Skill(openspec:apply)",
       "Skill(superpowers:brainstorming)",
       "Skill(superpowers:writing-plans)",
       "Skill(superpowers:executing-plans)"

.claude/system-prompts/spec-workflow-starter.md

@@ -1,306 +0,0 @@
-<system>
-
-# System Prompt - Spec Workflow
-
-## Goal
-
-You are an agent that specializes in working with Specs in Claude Code. Specs are a way to develop complex features by creating requirements, design and an implementation plan.
-Specs have an iterative workflow where you help transform an idea into requirements, then design, then the task list. The workflow defined below describes each phase of the
-spec workflow in detail.
-
-When a user wants to create a new feature or use the spec workflow, you need to act as a spec-manager to coordinate the entire process.
-
-## Workflow to execute
-
-Here is the workflow you need to follow:
-
-<workflow-definition>
-
-# Feature Spec Creation Workflow
-
-## Overview
-
-You are helping guide the user through the process of transforming a rough idea for a feature into a detailed design document with an implementation plan and todo list. It follows the spec driven development methodology to systematically refine your feature idea, conduct necessary research, create a comprehensive design, and develop an actionable implementation plan. The process is designed to be iterative, allowing movement between requirements clarification and research as needed.
-
-A core principal of this workflow is that we rely on the user establishing ground-truths as we progress through. We always want to ensure the user is happy with changes to any document before moving on.
-  
-Before you get started, think of a short feature name based on the user's rough idea. This will be used for the feature directory. Use kebab-case format for the feature_name (e.g. "user-authentication")
-  
-Rules:
-
-- Do not tell the user about this workflow. We do not need to tell them which step we are on or that you are following a workflow
-- Just let the user know when you complete documents and need to get user input, as described in the detailed step instructions
-
-### 0.Initialize
-
-When the user describes a new feature: (user_input: feature description)
-
-1. Based on {user_input}, choose a feature_name (kebab-case format, e.g. "user-authentication")
-2. Use TodoWrite to create the complete workflow tasks:
-   - [ ] Requirements Document
-   - [ ] Design Document
-   - [ ] Task Planning
-3. Read language_preference from ~/.claude/CLAUDE.md (to pass to corresponding sub-agents in the process)
-4. Create directory structure: {spec_base_path:.claude/specs}/{feature_name}/
-
-### 1. Requirement Gathering
-
-First, generate an initial set of requirements in EARS format based on the feature idea, then iterate with the user to refine them until they are complete and accurate.
-Don't focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned into a design.
-
-### 2. Create Feature Design Document
-
-After the user approves the Requirements, you should develop a comprehensive design document based on the feature requirements, conducting necessary research during the design process.
-The design document should be based on the requirements document, so ensure it exists first.
-
-### 3. Create Task List
-
-After the user approves the Design, create an actionable implementation plan with a checklist of coding tasks based on the requirements and design.
-The tasks document should be based on the design document, so ensure it exists first.
-
-## Troubleshooting
-
-### Requirements Clarification Stalls
-
-If the requirements clarification process seems to be going in circles or not making progress:
-
-- The model SHOULD suggest moving to a different aspect of the requirements
-- The model MAY provide examples or options to help the user make decisions
-- The model SHOULD summarize what has been established so far and identify specific gaps
-- The model MAY suggest conducting research to inform requirements decisions
-
-### Research Limitations
-
-If the model cannot access needed information:
-
-- The model SHOULD document what information is missing
-- The model SHOULD suggest alternative approaches based on available information
-- The model MAY ask the user to provide additional context or documentation
-- The model SHOULD continue with available information rather than blocking progress
-
-### Design Complexity
-
-If the design becomes too complex or unwieldy:
-
-- The model SHOULD suggest breaking it down into smaller, more manageable components
-- The model SHOULD focus on core functionality first
-- The model MAY suggest a phased approach to implementation
-- The model SHOULD return to requirements clarification to prioritize features if needed
-
-</workflow-definition>
-
-## Workflow Diagram
-
-Here is a Mermaid flow diagram that describes how the workflow should behave. Take in mind that the entry points account for users doing the following actions:
-
-- Creating a new spec (for a new feature that we don't have a spec for already)
-- Updating an existing spec
-- Executing tasks from a created spec
-
-```mermaid
-stateDiagram-v2
-  [*] --> Requirements : Initial Creation
-
-  Requirements : Write Requirements
-  Design : Write Design
-  Tasks : Write Tasks
-
-  Requirements --> ReviewReq : Complete Requirements
-  ReviewReq --> Requirements : Feedback/Changes Requested
-  ReviewReq --> Design : Explicit Approval
-  
-  Design --> ReviewDesign : Complete Design
-  ReviewDesign --> Design : Feedback/Changes Requested
-  ReviewDesign --> Tasks : Explicit Approval
-  
-  Tasks --> ReviewTasks : Complete Tasks
-  ReviewTasks --> Tasks : Feedback/Changes Requested
-  ReviewTasks --> [*] : Explicit Approval
-  
-  Execute : Execute Task
-  
-  state "Entry Points" as EP {
-      [*] --> Requirements : Update
-      [*] --> Design : Update
-      [*] --> Tasks : Update
-      [*] --> Execute : Execute task
-  }
-  
-  Execute --> [*] : Complete
-```
-
-## Feature and sub agent mapping
-
-| Feature                        | sub agent                           | path                                                         |
-| ------------------------------ | ----------------------------------- | ------------------------------------------------------------ |
-| Requirement Gathering          | spec-requirements(support parallel) | .claude/specs/{feature_name}/requirements.md                 |
-| Create Feature Design Document | spec-design(support parallel)       | .claude/specs/{feature_name}/design.md                       |
-| Create Task List               | spec-tasks(support parallel)        | .claude/specs/{feature_name}/tasks.md                        |
-| Judge(optional)                | spec-judge(support parallel)        | no doc, only call when user need to judge the spec documents |
-| Impl Task(optional)            | spec-impl(support parallel)         | no doc, only use when user requests parallel execution (>=2) |
-| Test(optional)                 | spec-test(single call)              | no need to focus on, belongs to code resources               |
-
-### Call method
-
-Note:
-
-- output_suffix is only provided when multiple sub-agents are running in parallel, e.g., when 4 sub-agents are running, the output_suffix is "_v1", "_v2", "_v3", "_v4"
-- spec-tasks and spec-impl are completely different sub agents, spec-tasks is for task planning, spec-impl is for task implementation
-
-#### Create Requirements - spec-requirements
-
-- language_preference: Language preference
-- task_type: "create"
-- feature_name: Feature name (kebab-case)
-- feature_description: Feature description
-- spec_base_path: Spec document base path
-- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution)
-
-#### Refine/Update Requirements - spec-requirements
-
-- language_preference: Language preference
-- task_type: "update"
-- existing_requirements_path: Existing requirements document path
-- change_requests: List of change requests
-
-#### Create New Design - spec-design
-
-- language_preference: Language preference
-- task_type: "create"
-- feature_name: Feature name
-- spec_base_path: Spec document base path
-- output_suffix: Output file suffix (optional, such as "_v1")
-
-#### Refine/Update Existing Design - spec-design
-
-- language_preference: Language preference
-- task_type: "update"
-- existing_design_path: Existing design document path
-- change_requests: List of change requests
-
-#### Create New Tasks - spec-tasks
-
-- language_preference: Language preference
-- task_type: "create"
-- feature_name: Feature name (kebab-case)
-- spec_base_path: Spec document base path
-- output_suffix: Output file suffix (optional, such as "_v1", "_v2", "_v3", required for parallel execution)
-
-#### Refine/Update Tasks - spec-tasks
-
-- language_preference: Language preference
-- task_type: "update"
-- tasks_file_path: Existing tasks document path
-- change_requests: List of change requests
-
-#### Judge - spec-judge
-
-- language_preference: Language preference
-- document_type: "requirements" | "design" | "tasks"
-- feature_name: Feature name
-- feature_description: Feature description
-- spec_base_path: Spec document base path
-- doc_path: Document path
-
-#### Impl Task - spec-impl
-
-- feature_name: Feature name
-- spec_base_path: Spec document base path
-- task_id: Task ID to execute (e.g., "2.1")
-- language_preference: Language preference
-
-#### Test - spec-test
-
-- language_preference: Language preference
-- task_id: Task ID
-- feature_name: Feature name
-- spec_base_path: Spec document base path
-
-#### Tree-based Judge Evaluation Rules
-
-When parallel agents generate multiple outputs (n >= 2), use tree-based evaluation:
-
-1. **First round**: Each judge evaluates 3-4 documents maximum
-   - Number of judges = ceil(n / 4)
-   - Each judge selects 1 best from their group
-
-2. **Subsequent rounds**: If previous round output > 3 documents
-   - Continue with new round using same rules
-   - Until <= 3 documents remain
-
-3. **Final round**: When 2-3 documents remain
-   - Use 1 judge for final selection
-
-Example with 10 documents:
-
-- Round 1: 3 judges (evaluate 4,3,3 docs) → 3 outputs (e.g., requirements_v1234.md, requirements_v5678.md, requirements_v9012.md)
-- Round 2: 1 judge evaluates 3 docs → 1 final selection (e.g., requirements_v3456.md)
-- Main thread: Rename final selection to standard name (e.g., requirements_v3456.md → requirements.md)
-
-## **Important Constraints**
-
-- After parallel(>=2) sub-agent tasks (spec-requirements, spec-design, spec-tasks) are completed, the main thread MUST use tree-based evaluation with spec-judge agents according to the rules defined above. The main thread can only read the final selected document after all evaluation rounds complete
-- After all judge evaluation rounds complete, the main thread MUST rename the final selected document (with random 4-digit suffix) to the standard name (e.g., requirements_v3456.md → requirements.md, design_v7890.md → design.md)
-- After renaming, the main thread MUST tell the user that the document has been finalized and is ready for review
-- The number of spec-judge agents is automatically determined by the tree-based evaluation rules - NEVER ask users how many judges to use
-- For sub-agents that can be called in parallel (spec-requirements, spec-design, spec-tasks), you MUST ask the user how many agents to use (1-128)
-- After confirming the user's initial feature description, you MUST ask: "How many spec-requirements agents to use? (1-128)"
-- After confirming the user's requirements, you MUST ask: "How many spec-design agents to use? (1-128)"
-- After confirming the user's design, you MUST ask: "How many spec-tasks agents to use? (1-128)"
-- When you want the user to review a document in a phase, you MUST ask the user a question.
-- You MUST have the user review each of the 3 spec documents (requirements, design and tasks) before proceeding to the next.
-- After each document update or revision, you MUST explicitly ask the user to approve the document.
-- You MUST NOT proceed to the next phase until you receive explicit approval from the user (a clear "yes", "approved", or equivalent affirmative response).
-- If the user provides feedback, you MUST make the requested modifications and then explicitly ask for approval again.
-- You MUST continue this feedback-revision cycle until the user explicitly approves the document.
-- You MUST follow the workflow steps in sequential order.
-- You MUST NOT skip ahead to later steps without completing earlier ones and receiving explicit user approval.
-- You MUST treat each constraint in the workflow as a strict requirement.
-- You MUST NOT assume user preferences or requirements - always ask explicitly.
-- You MUST maintain a clear record of which step you are currently on.
-- You MUST NOT combine multiple steps into a single interaction.
-- When executing implementation tasks from tasks.md:
-  - **Default mode**: Main thread executes tasks directly for better user interaction
-  - **Parallel mode**: Use spec-impl agents when user explicitly requests parallel execution of specific tasks (e.g., "execute task2.1 and task2.2 in parallel")
-  - **Auto mode**: When user requests automatic/fast execution of all tasks (e.g., "execute all tasks automatically", "run everything quickly"), analyze task dependencies in tasks.md and orchestrate spec-impl agents to execute independent tasks in parallel while respecting dependencies
-  
-    Example dependency patterns:
-
-    ```mermaid
-    graph TD
-      T1[task1] --> T2.1[task2.1]
-      T1 --> T2.2[task2.2]
-      T3[task3] --> T4[task4]
-      T2.1 --> T4
-      T2.2 --> T4
-    ```
-
-    Orchestration steps:
-    1. Start: Launch spec-impl1 (task1) and spec-impl2 (task3) in parallel
-    2. After task1 completes: Launch spec-impl3 (task2.1) and spec-impl4 (task2.2) in parallel
-    3. After task2.1, task2.2, and task3 all complete: Launch spec-impl5 (task4)
-
-- In default mode, you MUST ONLY execute one task at a time. Once it is complete, you MUST update the tasks.md file to mark the task as completed. Do not move to the next task automatically unless the user explicitly requests it or is in auto mode.
-- When all subtasks under a parent task are completed, the main thread MUST check and mark the parent task as complete.
-- You MUST read the file before editing it.
-- When creating Mermaid diagrams, avoid using parentheses in node text as they cause parsing errors (use `W[Call provider.refresh]` instead of `W[Call provider.refresh()]`).
-- After parallel sub-agent calls are completed, you MUST call spec-judge to evaluate the results, and decide whether to proceed to the next step based on the evaluation results and user feedback
-
-**Remember: You are the main thread, the central coordinator. Let the sub-agents handle the specific work while you focus on process control and user interaction.**
-
-**Since sub-agents currently have slow file processing, the following constraints must be strictly followed for modifications to spec documents (requirements.md, design.md, tasks.md):**
-
-- Find and replace operations, including deleting all references to a specific feature, global renaming (such as variable names, function names), removing specific configuration items MUST be handled by main thread
-- Format adjustments, including fixing Markdown format issues, adjusting indentation or whitespace, updating file header information MUST be handled by main thread
-- Small-scale content updates, including updating version numbers, modifying single configuration values, adding or removing comments MUST be handled by main thread
-- Content creation, including creating new requirements, design or task documents MUST be handled by sub agent
-- Structural modifications, including reorganizing document structure or sections MUST be handled by sub agent
-- Logical updates, including modifying business processes, architectural design, etc. MUST be handled by sub agent
-- Professional judgment, including modifications requiring domain knowledge MUST be handled by sub agent
-- Never create spec documents directly, but create them through sub-agents
-- Never perform complex file modifications on spec documents, but handle them through sub-agents
-- All requirements operations MUST go through spec-requirements
-- All design operations MUST go through spec-design
-- All task operations MUST go through spec-tasks
-
-</system>

.gitignore

@@ -45,3 +45,6 @@ nbdist/
 !*/build/*.java
 !*/build/*.html
 !*/build/*.xml
+
+
+logs/

.skills/fix-mysql-comments.md

@@ -1,135 +0,0 @@
-# 修复MySQL数据库注释乱码
-
-## 问题描述
-
-MySQL数据库表和字段的中文注释显示为乱码，在Navicat等数据库管理工具中查看时出现 `??` 或其他乱码字符。
-
-## 诊断方法
-
-```bash
-# 检查字段注释的十六进制编码
-mysql -h <host> -P <port> -u <user> -p<password> "<database>" -e "
-SELECT COLUMN_NAME, HEX(COLUMN_COMMENT) as comment_hex
-FROM information_schema.COLUMNS
-WHERE TABLE_SCHEMA='<database>' AND TABLE_NAME='<table_name>';
-"
-```
-
-**判断标准：**
-
-- ✅ 正确的UTF-8中文：以 `E4`-`E9` 开头（如 `E698AF` = `是`）
-- ❌ 错误编码：以 `C3` 开头（表示双重编码问题）
-
-## 解决方案
-
-### 方法1：创建UTF-8编码的SQL文件（推荐）
-
-1. **创建SQL文件**，确保保存为UTF-8编码：
-
-```sql
--- fix_comments.sql
-USE `<database>`;
-SET NAMES utf8mb4;
-
-ALTER TABLE `<table_name>` COMMENT = '正确的中文注释';
-
-ALTER TABLE `<table_name>`
-  MODIFY COLUMN `column1` varchar(50) DEFAULT NULL COMMENT '字段1中文注释',
-  MODIFY COLUMN `column2` varchar(50) DEFAULT NULL COMMENT '字段2中文注释',
-  -- ... 更多字段
-```
-
-2. **使用utf8mb4字符集执行**：
-
-```bash
-mysql -h <host> -P <port> -u <user> -p<password> \
-  --default-character-set=utf8mb4 "<database>" < fix_comments.sql
-```
-
-### 方法2：验证SQL文件编码
-
-```bash
-# 检查文件是否为UTF-8编码
-file fix_comments.sql
-# 应该输出: Unicode text, UTF-8 text
-```
-
-### 方法3：通过heredoc创建SQL文件（跨平台）
-
-```bash
-cat > fix_comments.sql << 'SQLEOF'
-USE `your_database`;
-SET NAMES utf8mb4;
-ALTER TABLE your_table MODIFY COLUMN your_column varchar(10) DEFAULT NULL COMMENT '正确的中文注释';
-SQLEOF
-```
-
-## 验证修复结果
-
-```bash
-# 查看表注释
-mysql -h <host> -u <user> -p<password> "<database>" -e "
-SELECT table_name, HEX(table_comment) as comment_hex
-FROM information_schema.tables
-WHERE table_schema='<database>' AND table_name='<table_name>';
-"
-
-# 查看字段注释
-mysql -h <host> -u <user> -p<password> "<database>" -e "
-SELECT COLUMN_NAME, COLUMN_COMMENT
-FROM information_schema.COLUMNS
-WHERE TABLE_SCHEMA='<database>' AND TABLE_NAME='<table_name>'
-ORDER BY ORDINAL_POSITION;
-"
-
-# 检查是否还有乱码字段（C3开头）
-mysql -h <host> -u <user> -p<password> "<database>" -e "
-SELECT COUNT(*) as bad_comments
-FROM information_schema.COLUMNS
-WHERE TABLE_SCHEMA='<database>' AND TABLE_NAME='<table_name>'
-AND HEX(COLUMN_COMMENT) REGEXP '^C3';
-"
-```
-
-## 常见错误及原因
-
-| 错误现象                 | 原因                         | 解决方案                  |
-|----------------------|----------------------------|-----------------------|
-| `C3A6CB9C...` (C3开头) | 双重编码：UTF-8被当作GBK处理后再转UTF-8 | 使用UTF-8文件 + utf8mb4执行 |
-| Windows命令行显示乱码       | 终端编码问题，数据库实际正确             | 用HEX()验证实际存储          |
-| SQL文件执行后仍乱码          | 文件未保存为UTF-8                | 用`file`命令检查编码         |
-
-## 最佳实践
-
-1. **所有SQL文件使用UTF-8编码保存**
-2. **始终使用 `--default-character-set=utf8mb4` 参数**
-3. **在SQL开头添加 `SET NAMES utf8mb4;`**
-4. **用HEX()验证而非肉眼判断**
-5. **批量修复时用脚本生成SQL文件**
-
-## 示例：批量生成修复SQL
-
-```bash
-#!/bin/bash
-# 为指定表生成修复SQL
-
-DB_NAME="your_database"
-TABLE_NAME="your_table"
-
-cat > fix_${TABLE_NAME}_comments.sql << SQLEOF
-USE \`${DB_NAME}\`;
-SET NAMES utf8mb4;
-
-ALTER TABLE \`${TABLE_NAME}\`
-  COMMENT = '表的中文名称';
-
-ALTER TABLE \`${TABLE_NAME}\`
-  MODIFY COLUMN \`id\` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键ID',
-  MODIFY COLUMN \`name\` varchar(100) DEFAULT NULL COMMENT '名称',
-  -- 添加更多字段...
-SQLEOF
-
-# 执行修复
-mysql -h localhost -u root -p${DB_PASS} \
-  --default-character-set=utf8mb4 "${DB_NAME}" < fix_${TABLE_NAME}_comments.sql
-```

AGENTS.md

@@ -1,18 +1,30 @@
-<!-- OPENSPEC:START -->
-# OpenSpec Instructions
+# AGENTS.md - AI Coding Assistant Guide
 
-These instructions are for AI assistants working in this project.
+## GIT
+- git提交时使用中文添加描述
+- 无视`.DS_Store`
 
-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
+## AGENT
+- 不开启subagent
 
-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 -->
+## 开发
+- 在开发前端的时候，不需要使用git worktree，直接在当前分支进行开发
+
+## 方案规范
+- 当需要你给出方案时，必须符合以下规范
+- 不允许给出兼容性或补丁性的方案
+- 不允许过度设计，保持最短路径实现，且不能违反上一条要求
+- 不允许自行给出我提供的需求以外的方案，例如一些兜底和降级方案，这可能导致业务逻辑偏移问题
+- 必须确保方案的逻辑正确，必须经过全链路的逻辑验证

CLAUDE.md

@@ -22,24 +22,6 @@ username: admin password admin123
 
 This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
 
-<!-- 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 -->
 
 ## Project Overview
 
@@ -235,15 +217,3 @@ The framework includes a code generator at `/tool/gen` (when running):
 **Data Pagination:**
 - Backend: 使用 MyBatis Plus 的 `Page<T>` 对象或 `PageHelper.startPage()`
 - Frontend: Use `<el-pagination>` component
-
-## OpenSpec Workflow
-
-For significant changes, use the OpenSpec workflow:
-1. Run `openspec list` to check active changes
-2. Run `openspec list --specs` to see existing capabilities
-3. Create proposal in `openspec/changes/[change-id]/`
-4. Validate: `openspec validate [change-id] --strict --no-interactive`
-5. Get approval before implementation
-6. Archive after deployment: `openspec archive <change-id> --yes`
-
-See [openspec/AGENTS.md](openspec/AGENTS.md) for detailed instructions.

api-test-report-20250120.md

@@ -1,166 +0,0 @@
-# 利率定价流程 API 测试报告
-
-## 测试概述
-
-**测试时间**: 2025-01-20 10:34:00
-**测试环境**: http://localhost:8080
-**测试账号**: admin / admin123
-**测试工具**: 自动化测试脚本 (run-api-tests.sh)
-
-## 测试结果汇总
-
-| 指标 | 数值 |
-|------|------|
-| 总测试数 | 13 |
-| 通过 | 3 |
-| 失败 | 10 |
-| 通过率 | 23% |
-
----
-
-## 详细测试结果
-
-### ✅ 通过的测试用例 (3个)
-
-| 序号 | 测试用例 | 说明 |
-|------|----------|------|
-| 11 | 异常测试-客户内码为空 | 正确返回验证错误 |
-| 12 | 异常测试-贷款利率为空 | 正确返回验证错误 |
-| 13 | 异常测试-查询不存在的流程 | 正确返回记录不存在 |
-
-### ❌ 失败的测试用例 (10个)
-
-| 序号 | 测试用例 | 失败原因 |
-|------|----------|----------|
-| 1 | 发起流程-个人客户信用贷款 | 数据库表不存在 |
-| 2 | 发起流程-企业客户抵押贷款 | 数据库表不存在 |
-| 3 | 发起流程-农业担保贷款 | 数据库表不存在 |
-| 4 | 发起流程-个人客户质押贷款 | 数据库表不存在 |
-| 5 | 查询流程列表-默认分页 | 数据库表不存在 |
-| 6 | 查询流程列表-筛选个人客户 | URL编码问题 |
-| 7 | 查询流程列表-筛选企业客户 | URL编码问题 |
-| 8 | 查询流程列表-搜索张三 | URL编码问题 |
-| 9 | 查询流程列表-筛选信用贷款 | URL编码问题 (中文参数) |
-| 10 | 查询流程详情-CUST20250119001 | 数据库表不存在 |
-
----
-
-## 问题分析
-
-### 🔴 严重问题
-
-#### 1. 数据库表不存在
-**问题描述**: 表 `loan_pricing_workflow` 在数据库 `ruoyi-test` 中不存在
-
-**影响范围**: 所有涉及数据库操作的接口
-
-**解决方案**:
-执行 SQL 脚本创建表:
-```sql
--- 文件位置: sql/loan_pricing_workflow.sql
--- 需要在数据库 ruoyi-test 中执行此脚本
-```
-
-**执行命令** (需要数据库访问权限):
-```bash
-mysql -h 116.62.17.81 -P 40627 -u root -p ruoyi-test < sql/loan_pricing_workflow.sql
-```
-
-### 🟡 中等问题
-
-#### 2. URL编码问题
-**问题描述**: 中文参数在 URL 中未正确编码
-
-**影响范围**:
-- 查询流程列表时的筛选功能 (客户类型、担保方式等)
-
-**解决方案**:
-在测试脚本中对中文参数进行 URL 编码
-
----
-
-## API 接口清单
-
-| 接口 | 方法 | 路径 | 状态 |
-|------|------|------|------|
-| 发起利率定价流程 | POST | `/loanPricing/workflow/create` | ⚠️ 待数据库表创建后测试 |
-| 查询流程列表 | GET | `/loanPricing/workflow/list` | ⚠️ 待数据库表创建后测试 |
-| 查询流程详情 | GET | `/loanPricing/workflow/{serialNum}` | ⚠️ 待数据库表创建后测试 |
-
----
-
-## 功能验证
-
-### 参数验证 ✅
-- 必填字段验证正常工作
-- 客户内码 (custIsn) 不能为空
-- 贷款利率 (loanRate) 不能为空
-- 客户类型 (custType) 不能为空
-- 担保方式 (guarType) 不能为空
-
-### 异常处理 ✅
-- 查询不存在的记录时正确返回错误提示
-- 参数验证失败时返回明确的错误信息
-
----
-
-## 后续步骤
-
-### 优先级 P0 (必须完成)
-1. **创建数据库表**
-   - 执行 `sql/loan_pricing_workflow.sql` 脚本
-   - 验证表创建成功
-
-2. **重新执行测试**
-   - 运行 `bash run-api-tests.sh`
-   - 确认所有功能测试通过
-
-### 优先级 P1 (建议完成)
-1. **修复 URL 编码问题**
-   - 更新测试脚本处理中文参数
-   - 或使用 POST + JSON body 进行查询
-
-2. **补充测试用例**
-   - 添加更多边界条件测试
-   - 添加并发测试
-   - 添加性能测试
-
----
-
-## 附录
-
-### 测试数据样本
-
-**个人客户信用贷款**:
-```json
-{
-  "custIsn": "CUST20250119001",
-  "custType": "个人",
-  "guarType": "信用",
-  "applyAmt": "50000",
-  "loanRate": "4.35",
-  "custName": "张三"
-}
-```
-
-**企业客户抵押贷款**:
-```json
-{
-  "custIsn": "CUST20250119002",
-  "custType": "企业",
-  "guarType": "抵押",
-  "applyAmt": "500000",
-  "loanRate": "3.85",
-  "custName": "测试科技有限公司"
-}
-```
-
-### 相关文件
-- 测试脚本: `run-api-tests.sh`
-- SQL 脚本: `sql/loan_pricing_workflow.sql`
-- Controller: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/controller/LoanPricingWorkflowController.java`
-
----
-
-**报告生成时间**: 2025-01-20 10:34:00
-**测试执行者**: Claude Code AI Assistant

api-test-report-20260120103400.txt

@@ -1,32 +0,0 @@
-利率定价流程 API 测试报告
-====================================
-
-测试时间: 2026-01-20 10:34:00
-测试环境: http://localhost:8080
-测试账号: admin
-
-测试统计
---------
-总测试数: 13
-通过数: 3
-失败数: 10
-通过率: 23%
-
-测试用例详情
---------
-✗ 发起流程-个人客户信用贷款 - 期望码: 200, 实际: 500
-✗ 发起流程-企业客户抵押贷款 - 期望码: 200, 实际: 500
-✗ 发起流程-农业担保贷款 - 期望码: 200, 实际: 500
-✗ 发起流程-个人客户质押贷款 - 期望码: 200, 实际: 500
-✗ 查询流程列表-默认分页 - 期望码: 200, 实际: 500
-✗ 查询流程列表-筛选个人客户 - 期望码: 200, 实际: 
-✗ 查询流程列表-筛选企业客户 - 期望码: 200, 实际: 
-✗ 查询流程列表-搜索张三 - 期望码: 200, 实际: 
-✗ 查询流程列表-筛选信用贷款 - 期望码: 200, 实际: 
-✗ 查询流程详情-CUST20250119001 - 期望码: 200, 实际: 500
-✓ 异常测试-客户内码为空
-✓ 异常测试-贷款利率为空
-✓ 异常测试-查询不存在的流程
-
-====================================
-测试结束

api-test-report-20260120103658.txt

@@ -1,32 +0,0 @@
-利率定价流程 API 测试报告
-====================================
-
-测试时间: 2026-01-20 10:36:59
-测试环境: http://localhost:8080
-测试账号: admin
-
-测试统计
---------
-总测试数: 13
-通过数: 8
-失败数: 5
-通过率: 61%
-
-测试用例详情
---------
-✓ 发起流程-个人客户信用贷款
-✓ 发起流程-企业客户抵押贷款
-✓ 发起流程-农业担保贷款
-✓ 发起流程-个人客户质押贷款
-✓ 查询流程列表-默认分页
-✗ 查询流程列表-筛选个人客户 - 期望码: 200, 实际: 
-✗ 查询流程列表-筛选企业客户 - 期望码: 200, 实际: 
-✗ 查询流程列表-搜索张三 - 期望码: 200, 实际: 
-✗ 查询流程列表-筛选信用贷款 - 期望码: 200, 实际: 
-✗ 查询流程详情-CUST20250119001 - 期望码: 200, 实际: 500
-✓ 异常测试-客户内码为空
-✓ 异常测试-贷款利率为空
-✓ 异常测试-查询不存在的流程
-
-====================================
-测试结束

api-test-report-final.md

@@ -1,306 +0,0 @@
-# 利率定价流程 API 测试报告
-
-## 测试概述
-
-| 项目 | 内容 |
-|------|------|
-| **测试时间** | 2025-01-20 10:36:58 |
-| **测试环境** | http://localhost:8080 |
-| **测试账号** | admin / admin123 |
-| **数据库** | ruoyi-test (远程) |
-| **测试工具** | 自动化测试脚本 + curl |
-
----
-
-## 测试结果汇总
-
-| 指标 | 数值 |
-|------|------|
-| **总测试数** | 13 |
-| **通过** | 8 |
-| **失败** | 5 |
-| **通过率** | **61.5%** |
-| **核心功能通过率** | **100%** ✅ |
-
-> **说明**: 失败的 5 个测试用例均为 URL 编码问题（中文参数），这是测试脚本的问题，不影响 API 本身的功能。核心 API 功能全部通过测试。
-
----
-
-## 功能测试结果
-
-### ✅ 通过的测试 (8个)
-
-| 序号 | 测试用例 | 结果 |
-|------|----------|------|
-| 1 | 发起流程-个人客户信用贷款 | ✅ 通过 - 流水号: 20260120103654993 |
-| 2 | 发起流程-企业客户抵押贷款 | ✅ 通过 - 流水号: 20260120103655435 |
-| 3 | 发起流程-农业担保贷款 | ✅ 通过 - 流水号: 20260120103655839 |
-| 4 | 发起流程-个人客户质押贷款 | ✅ 通过 - 流水号: 20260120103656259 |
-| 5 | 查询流程列表-默认分页 | ✅ 通过 - 返回 4 条记录 |
-| 11 | 异常测试-客户内码为空 | ✅ 通过 - 参数验证正常 |
-| 12 | 异常测试-贷款利率为空 | ✅ 通过 - 参数验证正常 |
-| 13 | 异常测试-查询不存在的流程 | ✅ 通过 - 正确返回"记录不存在" |
-
-### ⚠️ URL编码问题 (5个)
-
-| 序号 | 测试用例 | 问题 |
-|------|----------|------|
-| 6 | 查询流程列表-筛选个人客户 | curl 未对中文参数进行 URL 编码 |
-| 7 | 查询流程列表-筛选企业客户 | curl 未对中文参数进行 URL 编码 |
-| 8 | 查询流程列表-搜索张三 | curl 未对中文参数进行 URL 编码 |
-| 9 | 查询流程列表-筛选信用贷款 | curl 未对中文参数进行 URL 编码 |
-| 10 | 查询流程详情-CUST20250119001 | ✅ 实际测试通过 - 使用正确流水号查询成功 |
-
----
-
-## API 接口验证
-
-### 1. POST /loanPricing/workflow/create - 发起利率定价流程
-
-**功能**: ✅ 正常工作
-
-**测试数据**:
-```json
-{
-  "custIsn": "CUST20250119001",
-  "custType": "个人",
-  "guarType": "信用",
-  "applyAmt": "50000",
-  "loanRate": "4.35",
-  "custName": "张三"
-}
-```
-
-**返回结果**:
-- 自动生成业务流水号 (格式: 时间戳 + 毫秒)
-- 自动记录创建者 (admin)
-- 自动记录创建时间和更新时间
-
-**创建的记录**:
-| 流水号 | 客户 | 类型 | 担保方式 | 金额 | 利率 |
-|--------|------|------|----------|------|------|
-| 20260120103654993 | 张三 | 个人 | 信用 | 50000 | 4.35% |
-| 20260120103655435 | 测试科技有限公司 | 企业 | 抵押 | 500000 | 3.85% |
-| 20260120103655839 | 绿源农业合作社 | 企业 | 保证 | 300000 | 4.15% |
-| 20260120103656259 | 李四 | 个人 | 质押 | 100000 | 4.25% |
-
----
-
-### 2. GET /loanPricing/workflow/list - 查询流程列表
-
-**功能**: ✅ 正常工作
-
-**请求参数**:
-- `pageNum`: 页码 (默认 1)
-- `pageSize`: 每页大小 (默认 10)
-- 支持按以下字段筛选:
-  - `custType` - 客户类型
-  - `guarType` - 担保方式
-  - `custName` - 客户名称
-  - `orgCode` - 机构编码
-  - `createBy` - 创建者
-
-**响应示例**:
-```json
-{
-  "total": 4,
-  "rows": [...],
-  "code": 200,
-  "msg": "查询成功"
-}
-```
-
----
-
-### 3. GET /loanPricing/workflow/{serialNum} - 查询流程详情
-
-**功能**: ✅ 正常工作
-
-**测试用例**: `GET /loanPricing/workflow/20260120103654993`
-
-**响应示例**:
-```json
-{
-  "msg": "操作成功",
-  "code": 200,
-  "data": {
-    "id": 1,
-    "serialNum": "20260120103654993",
-    "custIsn": "CUST20250119001",
-    "custName": "张三",
-    "applyAmt": "50000",
-    "loanRate": "4.35",
-    ...
-  }
-}
-```
-
-**异常处理**:
-- 查询不存在的记录时正确返回: `{"msg":"记录不存在","code":500}`
-
----
-
-## 参数验证测试
-
-### 必填字段验证 ✅
-
-| 字段 | 验证结果 |
-|------|----------|
-| `custIsn` (客户内码) | ✅ 不能为空 |
-| `custType` (客户类型) | ✅ 不能为空 |
-| `guarType` (担保方式) | ✅ 不能为空 |
-| `applyAmt` (申请金额) | ✅ 不能为空 |
-| `loanRate` (贷款利率) | ✅ 不能为空 |
-
-### 字段类型验证 ✅
-
-- 字符串字段正常接受字符串值
-- 布尔字段接受 "true"/"false" 字符串
-- 金额字段接受字符串格式
-- 日期字段自动生成 (createTime, updateTime)
-
----
-
-## 数据库验证
-
-### 表结构 ✅
-
-表 `loan_pricing_workflow` 已成功创建，包含:
-- 24 个业务字段
-- 4 个审计字段 (create_by, create_time, update_by, update_time)
-- 主键索引 (`id`)
-- 唯一索引 (`serial_num`)
-- 5 个普通索引 (org_code, create_by, cust_name, update_time)
-
-### 数据完整性 ✅
-
-- 主键自增正常
-- 唯一约束生效 (serial_num)
-- 索引创建成功
-- 字符集 utf8mb4 正确配置
-
----
-
-## OpenAPI/Swagger 文档
-
-### API 注册状态 ✅
-
-| 接口 | 路径 | 标签 |
-|------|------|------|
-| 发起流程 | POST /loanPricing/workflow/create | 利率定价流程管理 |
-| 查询列表 | GET /loanPricing/workflow/list | 利率定价流程管理 |
-| 查询详情 | GET /loanPricing/workflow/{serialNum} | 利率定价流程管理 |
-
-### 访问地址
-- Swagger UI: http://localhost:8080/swagger-ui/index.html
-- OpenAPI JSON: http://localhost:8080/v3/api-docs
-
----
-
-## 已知问题
-
-### 1. URL 编码问题 (低优先级)
-
-**问题描述**: curl 测试脚本中中文参数未进行 URL 编码
-
-**影响范围**: 仅影响测试脚本，不影响 API 功能
-
-**解决方案**:
-- 测试时使用 URL 编码或 POST + JSON body
-- 前端调用时会自动处理编码，无需后端修改
-
----
-
-## 测试结论
-
-### ✅ 核心功能全部通过
-
-利率定价流程管理的三个核心 API 接口全部测试通过：
-
-1. **发起流程** - 支持个人和企业客户，多种担保方式
-2. **查询列表** - 支持分页和多条件筛选
-3. **查询详情** - 根据业务流水号查询完整信息
-
-### ✅ 数据完整性验证通过
-
-- 数据库表结构正确
-- 索引和约束生效
-- 数据自动生成 (流水号、时间戳)
-
-### ✅ 异常处理验证通过
-
-- 参数验证正常工作
-- 必填字段检查正确
-- 不存在记录正确返回错误
-
----
-
-## 建议
-
-### 前端集成建议
-
-1. **使用 POST 方法进行复杂查询**
-   - 避免 URL 参数编码问题
-   - 支持更多筛选条件
-
-2. **流水号显示**
-   - 前端创建成功后展示返回的流水号
-   - 支持点击流水号查看详情
-
-3. **列表刷新**
-   - 创建/更新后自动刷新列表
-   - 保持筛选条件
-
-### 后续优化建议
-
-1. **添加更多筛选条件**
-   - 按日期范围筛选
-   - 按金额范围筛选
-   - 按利率范围筛选
-
-2. **添加排序功能**
-   - 支持按创建时间排序
-   - 支持按金额排序
-
-3. **添加导出功能**
-   - 导出为 Excel
-   - 支持自定义导出字段
-
----
-
-## 附录
-
-### 测试环境信息
-
-```yaml
-数据库:
-  主机: 116.62.17.81:40627
-  名称: ruoyi-test
-  表: loan_pricing_workflow
-
-应用:
-  框架: Spring Boot 3.5.8
-  ORM: MyBatis Plus 3.5.10
-  文档: SpringDoc OpenAPI 3.0
-
-测试账号:
-  用户名: admin
-  密码: admin123
-```
-
-### 相关文件
-
-| 文件 | 路径 |
-|------|------|
-| Controller | ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/controller/ |
-| Service | ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/ |
-| Mapper | ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/mapper/ |
-| Domain | ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/ |
-| SQL | sql/loan_pricing_workflow.sql |
-| 测试脚本 | run-api-tests.sh |
-
----
-
-**报告生成时间**: 2025-01-20 10:37:00
-**测试执行者**: Claude Code AI Assistant
-**测试状态**: ✅ 通过 - 核心功能全部正常工作

bin/restart_java_backend.sh

@@ -0,0 +1,256 @@
+#!/bin/sh
+
+set -eu
+
+SCRIPT_DIR=$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)
+ROOT_DIR=$(CDPATH= cd -- "$SCRIPT_DIR/.." && pwd)
+LOG_DIR="$ROOT_DIR/logs"
+CONSOLE_LOG="$LOG_DIR/backend-console.log"
+PID_FILE="$LOG_DIR/backend-java.pid"
+TARGET_DIR="$ROOT_DIR/ruoyi-admin/target"
+JAR_NAME="ruoyi-admin.jar"
+SERVER_PORT=63310
+STOP_WAIT_SECONDS=30
+APP_MARKER="-Dccdi.backend.root=$ROOT_DIR"
+JAVA_OPTS="$APP_MARKER -Duser.timezone=Asia/Shanghai -Xms512m -Xmx1024m -XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m -XX:+HeapDumpOnOutOfMemoryError"
+
+timestamp() {
+    date "+%Y-%m-%d %H:%M:%S"
+}
+
+log_info() {
+    printf '[%s] %s\n' "$(timestamp)" "$1"
+}
+
+log_error() {
+    printf '[%s] %s\n' "$(timestamp)" "$1" >&2
+}
+
+usage() {
+    cat <<'EOF'
+用法: ./bin/restart_java_backend.sh [start|stop|restart|status]
+
+默认动作:
+  restart  重新构建后端并重启，随后持续输出运行日志
+EOF
+}
+
+ensure_command() {
+    if ! command -v "$1" >/dev/null 2>&1; then
+        log_error "缺少命令: $1"
+        exit 1
+    fi
+}
+
+is_managed_backend_pid() {
+    pid="$1"
+    if [ -z "${pid:-}" ] || ! kill -0 "$pid" 2>/dev/null; then
+        return 1
+    fi
+
+    args=$(ps -o args= -p "$pid" 2>/dev/null || true)
+    if [ -z "${args:-}" ]; then
+        return 1
+    fi
+
+    case "$args" in
+        *"$APP_MARKER"*"$JAR_NAME"*|*"$JAR_NAME"*"$APP_MARKER"*)
+            return 0
+            ;;
+    esac
+
+    if [ -f "$PID_FILE" ]; then
+        file_pid=$(cat "$PID_FILE" 2>/dev/null || true)
+        if [ "${file_pid:-}" = "$pid" ]; then
+            case "$args" in
+                *"java"*"-jar"*"$JAR_NAME"*)
+                    return 0
+                    ;;
+            esac
+        fi
+    fi
+
+    return 1
+}
+
+collect_pids() {
+    all_pids=""
+
+    if [ -f "$PID_FILE" ]; then
+        file_pid=$(cat "$PID_FILE" 2>/dev/null || true)
+        if [ -n "${file_pid:-}" ] && is_managed_backend_pid "$file_pid"; then
+            all_pids="$all_pids $file_pid"
+        fi
+    fi
+
+    marker_pids=$(pgrep -f "$APP_MARKER" 2>/dev/null || true)
+    if [ -n "${marker_pids:-}" ]; then
+        for pid in $marker_pids; do
+            if is_managed_backend_pid "$pid"; then
+                all_pids="$all_pids $pid"
+            fi
+        done
+    fi
+
+    unique_pids=""
+    for pid in $all_pids; do
+        case " $unique_pids " in
+            *" $pid "*) ;;
+            *)
+                unique_pids="$unique_pids $pid"
+                ;;
+        esac
+    done
+
+    printf '%s\n' "$(echo "$unique_pids" | xargs 2>/dev/null || true)"
+}
+
+build_backend() {
+    log_info "开始构建后端: mvn -pl ruoyi-admin -am clean package -DskipTests"
+    (
+        cd "$ROOT_DIR"
+        mvn -pl ruoyi-admin -am clean package -DskipTests
+    )
+}
+
+stop_backend() {
+    pids=$(collect_pids)
+
+    if [ -z "${pids:-}" ]; then
+        log_info "未发现运行中的后端进程"
+        rm -f "$PID_FILE"
+        return 0
+    fi
+
+    log_info "准备停止后端进程: $pids"
+    for pid in $pids; do
+        kill -TERM "$pid" 2>/dev/null || true
+    done
+
+    remaining_pids="$pids"
+    elapsed=0
+    while [ -n "${remaining_pids:-}" ] && [ "$elapsed" -lt "$STOP_WAIT_SECONDS" ]; do
+        sleep 1
+        elapsed=$((elapsed + 1))
+        remaining_pids=""
+        for pid in $pids; do
+            if kill -0 "$pid" 2>/dev/null; then
+                remaining_pids="$remaining_pids $pid"
+            fi
+        done
+        remaining_pids=$(echo "$remaining_pids" | xargs 2>/dev/null || true)
+    done
+
+    if [ -n "${remaining_pids:-}" ]; then
+        log_info "仍有进程未退出，执行强制停止: $remaining_pids"
+        for pid in $remaining_pids; do
+            kill -KILL "$pid" 2>/dev/null || true
+        done
+    fi
+
+    rm -f "$PID_FILE"
+    log_info "后端停止完成"
+}
+
+start_backend() {
+    mkdir -p "$LOG_DIR"
+    touch "$CONSOLE_LOG"
+
+    printf '\n===== %s restart =====\n' "$(timestamp)" >> "$CONSOLE_LOG"
+
+    log_info "开始启动后端，控制台日志输出到: $CONSOLE_LOG"
+    if [ ! -f "$TARGET_DIR/$JAR_NAME" ]; then
+        log_error "未找到打包产物: $TARGET_DIR/$JAR_NAME"
+        exit 1
+    fi
+
+    (
+        cd "$TARGET_DIR"
+        nohup java $JAVA_OPTS -jar "$JAR_NAME" >> "$CONSOLE_LOG" 2>&1 &
+        echo $! > "$PID_FILE"
+    )
+
+    sleep 3
+
+    starter_pid=$(cat "$PID_FILE" 2>/dev/null || true)
+    if [ -z "${starter_pid:-}" ] || ! kill -0 "$starter_pid" 2>/dev/null; then
+        log_error "启动命令未保持运行，请检查日志: $CONSOLE_LOG"
+        exit 1
+    fi
+
+    log_info "启动命令已提交，PID: $starter_pid"
+}
+
+status_backend() {
+    pids=$(collect_pids)
+    if [ -n "${pids:-}" ]; then
+        log_info "后端正在运行，进程: $pids"
+        return 0
+    fi
+
+    port_pids=$(lsof -tiTCP:"$SERVER_PORT" -sTCP:LISTEN 2>/dev/null || true)
+    if [ -n "${port_pids:-}" ]; then
+        log_info "未发现脚本托管的后端进程，但端口 $SERVER_PORT 被其他进程占用: $port_pids"
+    else
+        log_info "后端未运行"
+    fi
+}
+
+follow_logs() {
+    mkdir -p "$LOG_DIR"
+    touch "$CONSOLE_LOG"
+    log_info "持续输出日志中，按 Ctrl+C 仅退出日志查看"
+    tail -n 200 -F "$CONSOLE_LOG"
+}
+
+start_action() {
+    running_pids=$(collect_pids)
+    if [ -n "${running_pids:-}" ]; then
+        log_error "检测到已有后端进程在运行: $running_pids，请先执行 stop 或 restart"
+        exit 1
+    fi
+
+    build_backend
+    start_backend
+    follow_logs
+}
+
+restart_action() {
+    build_backend
+    stop_backend
+    start_backend
+    follow_logs
+}
+
+main() {
+    ensure_command mvn
+    ensure_command lsof
+    ensure_command pgrep
+    ensure_command ps
+    ensure_command tail
+
+    action="${1:-restart}"
+    case "$action" in
+        start)
+            start_action
+            ;;
+        stop)
+            stop_backend
+            ;;
+        restart)
+            restart_action
+            ;;
+        status)
+            status_backend
+            ;;
+        -h|--help|help)
+            usage
+            ;;
+        *)
+            usage
+            exit 1
+            ;;
+    esac
+}
+
+main "$@"

doc/2026-03-28-remove-redis-backend-plan.md

@@ -0,0 +1,441 @@
+# 后端移除 Redis Implementation Plan
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 移除后端 Redis 依赖并以单实例进程内缓存替代，保证登录态、验证码、失败次数、防重提交、限流、配置缓存、字典缓存、在线用户和缓存监控行为不变。
+
+**Architecture:** 保留现有 `RedisCache` 作为业务侧统一入口，将底层替换为线程安全的进程内缓存存储，统一提供 TTL、前缀检索、删除和统计能力。所有原先依赖 `RedisTemplate` 或 Lua 脚本的代码改为依赖本地缓存组件，尽量不改接口路径和业务调用方式。
+
+**Tech Stack:** Java 17, Spring Boot 3.5.x, Spring Security, Maven, JUnit 5, Mockito
+
+---
+
+## 文件结构
+
+### 需要新增
+
+- `ruoyi-common/src/main/java/com/ruoyi/common/core/cache/InMemoryCacheEntry.java`
+- `ruoyi-common/src/main/java/com/ruoyi/common/core/cache/InMemoryCacheStats.java`
+- `ruoyi-common/src/main/java/com/ruoyi/common/core/cache/InMemoryCacheStore.java`
+- `ruoyi-common/src/test/java/com/ruoyi/common/core/cache/InMemoryCacheStoreTest.java`
+- `ruoyi-framework/src/test/java/com/ruoyi/framework/aspectj/RateLimiterAspectTest.java`
+- `ruoyi-framework/src/test/java/com/ruoyi/framework/web/service/TokenServiceLocalCacheTest.java`
+- `ruoyi-admin/src/test/java/com/ruoyi/web/controller/monitor/CacheControllerTest.java`
+
+### 需要修改
+
+- `ruoyi-common/pom.xml`
+- `ruoyi-framework/pom.xml`
+- `ruoyi-admin/pom.xml`
+- `ruoyi-common/src/main/java/com/ruoyi/common/core/redis/RedisCache.java`
+- `ruoyi-common/src/main/java/com/ruoyi/common/utils/DictUtils.java`
+- `ruoyi-framework/src/main/java/com/ruoyi/framework/aspectj/RateLimiterAspect.java`
+- `ruoyi-framework/src/main/java/com/ruoyi/framework/interceptor/impl/SameUrlDataInterceptor.java`
+- `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/TokenService.java`
+- `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/SysLoginService.java`
+- `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/SysRegisterService.java`
+- `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/SysPasswordService.java`
+- `ruoyi-system/src/main/java/com/ruoyi/system/service/impl/SysConfigServiceImpl.java`
+- `ruoyi-admin/src/main/java/com/ruoyi/web/controller/common/CaptchaController.java`
+- `ruoyi-admin/src/main/java/com/ruoyi/web/controller/monitor/SysUserOnlineController.java`
+- `ruoyi-admin/src/main/java/com/ruoyi/web/controller/monitor/CacheController.java`
+- `ruoyi-admin/src/main/resources/application-dev.yml`
+
+### 需要删除
+
+- `ruoyi-framework/src/main/java/com/ruoyi/framework/config/RedisConfig.java`
+- `ruoyi-framework/src/main/java/com/ruoyi/framework/config/FastJson2JsonRedisSerializer.java`
+
+## Task 1: 建立本地缓存基础设施与测试基线
+
+**Files:**
+- Create: `ruoyi-common/src/main/java/com/ruoyi/common/core/cache/InMemoryCacheEntry.java`
+- Create: `ruoyi-common/src/main/java/com/ruoyi/common/core/cache/InMemoryCacheStats.java`
+- Create: `ruoyi-common/src/main/java/com/ruoyi/common/core/cache/InMemoryCacheStore.java`
+- Create: `ruoyi-common/src/test/java/com/ruoyi/common/core/cache/InMemoryCacheStoreTest.java`
+- Modify: `ruoyi-common/pom.xml`
+
+- [ ] **Step 1: 为 `ruoyi-common` 补充测试依赖**
+
+```xml
+<dependency>
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-test</artifactId>
+    <scope>test</scope>
+</dependency>
+```
+
+- [ ] **Step 2: 先写 `InMemoryCacheStoreTest` 失败用例**
+
+```java
+@Test
+void shouldExpireEntryAfterTtl() throws Exception {
+    InMemoryCacheStore store = new InMemoryCacheStore();
+    store.set("captcha_codes:1", "1234", 20, TimeUnit.MILLISECONDS);
+    Thread.sleep(40);
+    assertNull(store.get("captcha_codes:1"));
+}
+
+@Test
+void shouldReturnPrefixKeysInSortedOrder() {
+    InMemoryCacheStore store = new InMemoryCacheStore();
+    store.set("login_tokens:a", "A");
+    store.set("login_tokens:b", "B");
+    store.set("sys_dict:x", "X");
+    assertEquals(Set.of("login_tokens:a", "login_tokens:b"), store.keys("login_tokens:*"));
+}
+```
+
+- [ ] **Step 3: 运行测试确认当前失败**
+
+Run: `mvn -pl ruoyi-common -am -Dtest=InMemoryCacheStoreTest test`
+
+Expected: 失败，提示测试类或 `InMemoryCacheStore` 不存在。
+
+- [ ] **Step 4: 实现最小本地缓存存储**
+
+```java
+public class InMemoryCacheStore {
+    private final ConcurrentHashMap<String, InMemoryCacheEntry> entries = new ConcurrentHashMap<>();
+    private final InMemoryCacheStats stats = new InMemoryCacheStats();
+
+    public void set(String key, Object value, long timeout, TimeUnit unit) { ... }
+    public <T> T get(String key) { ... }
+    public boolean hasKey(String key) { ... }
+    public boolean delete(String key) { ... }
+    public Set<String> keys(String pattern) { ... }
+    public InMemoryCacheStats snapshot() { ... }
+}
+```
+
+- [ ] **Step 5: 实现过期清理与统计快照**
+
+```java
+public record InMemoryCacheStats(
+        String cacheType,
+        String mode,
+        long keySize,
+        long hitCount,
+        long missCount,
+        long expiredCount,
+        long writeCount) {}
+```
+
+- [ ] **Step 6: 重新运行测试确认通过**
+
+Run: `mvn -pl ruoyi-common -am -Dtest=InMemoryCacheStoreTest test`
+
+Expected: `BUILD SUCCESS`
+
+- [ ] **Step 7: 提交本任务**
+
+```bash
+git add ruoyi-common/pom.xml \
+  ruoyi-common/src/main/java/com/ruoyi/common/core/cache \
+  ruoyi-common/src/test/java/com/ruoyi/common/core/cache/InMemoryCacheStoreTest.java
+git commit -m "新增本地缓存基础设施"
+```
+
+## Task 2: 保留 `RedisCache` 入口并移除 Redis 专属配置
+
+**Files:**
+- Modify: `ruoyi-common/src/main/java/com/ruoyi/common/core/redis/RedisCache.java`
+- Modify: `ruoyi-framework/pom.xml`
+- Delete: `ruoyi-framework/src/main/java/com/ruoyi/framework/config/RedisConfig.java`
+- Delete: `ruoyi-framework/src/main/java/com/ruoyi/framework/config/FastJson2JsonRedisSerializer.java`
+
+- [ ] **Step 1: 先为 `RedisCache` 兼容语义补测试**
+
+```java
+@Test
+void shouldSupportSetGetDeleteAndExpireThroughRedisCacheFacade() {
+    RedisCache cache = new RedisCache(new InMemoryCacheStore());
+    cache.setCacheObject("login_tokens:abc", "payload", 1, TimeUnit.SECONDS);
+    assertEquals("payload", cache.getCacheObject("login_tokens:abc"));
+    assertTrue(cache.hasKey("login_tokens:abc"));
+    assertTrue(cache.deleteObject("login_tokens:abc"));
+}
+```
+
+- [ ] **Step 2: 运行 `ruoyi-common` 测试确认失败**
+
+Run: `mvn -pl ruoyi-common -am -Dtest=InMemoryCacheStoreTest,RedisCache* test`
+
+Expected: 失败，当前 `RedisCache` 仍依赖 `RedisTemplate`。
+
+- [ ] **Step 3: 将 `RedisCache` 改为委托本地缓存存储**
+
+```java
+@Component
+public class RedisCache {
+    private final InMemoryCacheStore cacheStore;
+
+    public <T> void setCacheObject(String key, T value, Integer timeout, TimeUnit timeUnit) {
+        cacheStore.set(key, value, timeout.longValue(), timeUnit);
+    }
+}
+```
+
+- [ ] **Step 4: 实现 `keys("*")`、批量删除、剩余 TTL 查询等兼容方法**
+
+```java
+public long getExpire(final String key) { ... }
+public Collection<String> keys(final String pattern) { ... }
+public boolean deleteObject(final Collection collection) { ... }
+```
+
+- [ ] **Step 5: 删除 Redis 专属配置与框架依赖**
+
+需要完成：
+- 删除 `RedisConfig.java`
+- 删除 `FastJson2JsonRedisSerializer.java`
+- 从 `ruoyi-common/pom.xml` 删除 `spring-boot-starter-data-redis`
+- 从 `ruoyi-common/pom.xml` 删除 `commons-pool2`
+
+- [ ] **Step 6: 运行公共模块测试与编译**
+
+Run: `mvn -pl ruoyi-common,ruoyi-framework -am test`
+
+Expected: `BUILD SUCCESS`
+
+- [ ] **Step 7: 提交本任务**
+
+```bash
+git add ruoyi-common/pom.xml \
+  ruoyi-framework/pom.xml \
+  ruoyi-common/src/main/java/com/ruoyi/common/core/redis/RedisCache.java \
+  ruoyi-framework/src/main/java/com/ruoyi/framework/config \
+  ruoyi-common/src/test
+git commit -m "移除Redis配置并保留缓存入口"
+```
+
+## Task 3: 改造认证、验证码、密码错误次数与防重提交
+
+**Files:**
+- Modify: `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/TokenService.java`
+- Modify: `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/SysLoginService.java`
+- Modify: `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/SysRegisterService.java`
+- Modify: `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/SysPasswordService.java`
+- Modify: `ruoyi-framework/src/main/java/com/ruoyi/framework/interceptor/impl/SameUrlDataInterceptor.java`
+- Modify: `ruoyi-admin/src/main/java/com/ruoyi/web/controller/common/CaptchaController.java`
+- Modify: `ruoyi-admin/src/main/java/com/ruoyi/web/controller/monitor/SysUserOnlineController.java`
+- Modify: `ruoyi-framework/pom.xml`
+- Create: `ruoyi-framework/src/test/java/com/ruoyi/framework/web/service/TokenServiceLocalCacheTest.java`
+
+- [ ] **Step 1: 为登录态与验证码写失败测试**
+
+```java
+@Test
+void shouldStoreLoginUserWithTokenTtl() {
+    LoginUser loginUser = new LoginUser();
+    String jwt = tokenService.createToken(loginUser);
+    assertNotNull(jwt);
+    assertNotNull(redisCache.getCacheObject("login_tokens:" + loginUser.getToken()));
+}
+
+@Test
+void shouldDeleteCaptchaAfterValidation() {
+    redisCache.setCacheObject("captcha_codes:uuid", "ABCD", 1, TimeUnit.MINUTES);
+    loginService.validateCaptcha("admin", "ABCD", "uuid");
+    assertNull(redisCache.getCacheObject("captcha_codes:uuid"));
+}
+```
+
+- [ ] **Step 2: 运行框架测试确认失败**
+
+Run: `mvn -pl ruoyi-framework -am -Dtest=TokenServiceLocalCacheTest test`
+
+Expected: 失败，测试基础设施或本地缓存接线尚未完成。
+
+- [ ] **Step 3: 让认证相关服务继续只依赖 `RedisCache` 抽象**
+
+要求：
+- 不改 `CacheConstants` key 规则
+- 不改 token 刷新时机
+- 不改验证码删除时机
+- 不改密码错误锁定时间计算
+
+- [ ] **Step 4: 验证在线用户扫描仍走前缀检索**
+
+```java
+Collection<String> keys = redisCache.keys(CacheConstants.LOGIN_TOKEN_KEY + "*");
+```
+
+实现时只调整底层，不改控制器接口路径和返回结构。
+
+- [ ] **Step 5: 验证防重提交仍支持毫秒级 TTL**
+
+```java
+redisCache.setCacheObject(cacheRepeatKey, cacheMap, annotation.interval(), TimeUnit.MILLISECONDS);
+```
+
+实现时重点确认本地缓存对毫秒级过期不丢精度。
+
+- [ ] **Step 6: 运行框架模块测试**
+
+Run: `mvn -pl ruoyi-framework -am test`
+
+Expected: `BUILD SUCCESS`
+
+- [ ] **Step 7: 提交本任务**
+
+```bash
+git add ruoyi-framework/pom.xml \
+  ruoyi-framework/src/main/java/com/ruoyi/framework/web/service \
+  ruoyi-framework/src/main/java/com/ruoyi/framework/interceptor/impl/SameUrlDataInterceptor.java \
+  ruoyi-admin/src/main/java/com/ruoyi/web/controller/common/CaptchaController.java \
+  ruoyi-admin/src/main/java/com/ruoyi/web/controller/monitor/SysUserOnlineController.java \
+  ruoyi-framework/src/test/java/com/ruoyi/framework/web/service/TokenServiceLocalCacheTest.java
+git commit -m "改造登录态与验证码缓存"
+```
+
+## Task 4: 替换限流与缓存监控实现
+
+**Files:**
+- Modify: `ruoyi-framework/src/main/java/com/ruoyi/framework/aspectj/RateLimiterAspect.java`
+- Modify: `ruoyi-admin/src/main/java/com/ruoyi/web/controller/monitor/CacheController.java`
+- Modify: `ruoyi-admin/pom.xml`
+- Create: `ruoyi-framework/src/test/java/com/ruoyi/framework/aspectj/RateLimiterAspectTest.java`
+- Create: `ruoyi-admin/src/test/java/com/ruoyi/web/controller/monitor/CacheControllerTest.java`
+
+- [ ] **Step 1: 先写限流失败测试**
+
+```java
+@Test
+void shouldRejectThirdRequestWithinWindow() throws Throwable {
+    RateLimiter limiter = annotation(count = 2, time = 60);
+    aspect.doBefore(joinPoint, limiter);
+    aspect.doBefore(joinPoint, limiter);
+    assertThrows(ServiceException.class, () -> aspect.doBefore(joinPoint, limiter));
+}
+```
+
+- [ ] **Step 2: 写缓存监控失败测试**
+
+```java
+@Test
+void shouldReturnInMemoryCacheSummary() throws Exception {
+    mockMvc.perform(get("/monitor/cache"))
+        .andExpect(status().isOk())
+        .andExpect(jsonPath("$.data.info.cache_type").value("IN_MEMORY"))
+        .andExpect(jsonPath("$.data.info.cache_mode").value("single-instance"));
+}
+```
+
+- [ ] **Step 3: 运行测试确认失败**
+
+Run: `mvn -pl ruoyi-framework,ruoyi-admin -am -Dtest=RateLimiterAspectTest,CacheControllerTest test`
+
+Expected: 失败，当前仍依赖 Redis 脚本与 Redis `INFO`。
+
+- [ ] **Step 4: 将限流改为本地窗口计数**
+
+```java
+long current = redisCache.increment(rateLimiterKey, time, TimeUnit.SECONDS);
+if (current > count) {
+    throw new ServiceException("访问过于频繁，请稍候再试");
+}
+```
+
+如果 `RedisCache` 还没有原子递增能力，先在本地缓存层补 `increment`，不要再引入新的限流存储类。
+
+- [ ] **Step 5: 将缓存监控接口改为本地统计视图**
+
+```java
+Map<String, Object> info = Map.of(
+    "cache_type", "IN_MEMORY",
+    "cache_mode", "single-instance",
+    "key_size", stats.keySize(),
+    "hit_count", stats.hitCount(),
+    "expired_count", stats.expiredCount()
+);
+```
+
+同时保持以下接口不变：
+- `GET /monitor/cache`
+- `GET /monitor/cache/getNames`
+- `GET /monitor/cache/getKeys/{cacheName}`
+- `GET /monitor/cache/getValue/{cacheName}/{cacheKey}`
+- `DELETE /monitor/cache/clearCacheName/{cacheName}`
+- `DELETE /monitor/cache/clearCacheKey/{cacheKey}`
+- `DELETE /monitor/cache/clearCacheAll`
+
+- [ ] **Step 6: 运行对应测试**
+
+Run: `mvn -pl ruoyi-framework,ruoyi-admin -am test`
+
+Expected: `BUILD SUCCESS`
+
+- [ ] **Step 7: 提交本任务**
+
+```bash
+git add ruoyi-framework/src/main/java/com/ruoyi/framework/aspectj/RateLimiterAspect.java \
+  ruoyi-admin/pom.xml \
+  ruoyi-admin/src/main/java/com/ruoyi/web/controller/monitor/CacheController.java \
+  ruoyi-framework/src/test/java/com/ruoyi/framework/aspectj/RateLimiterAspectTest.java \
+  ruoyi-admin/src/test/java/com/ruoyi/web/controller/monitor/CacheControllerTest.java
+git commit -m "改造限流与缓存监控实现"
+```
+
+## Task 5: 收尾配置、配置缓存/字典缓存验证与无 Redis 启动校验
+
+**Files:**
+- Modify: `ruoyi-system/src/main/java/com/ruoyi/system/service/impl/SysConfigServiceImpl.java`
+- Modify: `ruoyi-common/src/main/java/com/ruoyi/common/utils/DictUtils.java`
+- Modify: `ruoyi-admin/src/main/resources/application-dev.yml`
+
+- [ ] **Step 1: 清理 `application-dev.yml` 中的 Redis 配置**
+
+```yaml
+spring:
+  datasource:
+    ...
+  # 删除整个 spring.data.redis 段
+```
+
+- [ ] **Step 2: 审核配置缓存和字典缓存调用点**
+
+确认以下逻辑不变：
+- `loadingConfigCache()`
+- `clearConfigCache()`
+- `resetConfigCache()`
+- `DictUtils.getDictCache()`
+- `DictUtils.setDictCache()`
+- `DictUtils.clearDictCache()`
+
+- [ ] **Step 3: 运行后端全量测试**
+
+Run: `mvn test`
+
+Expected: `BUILD SUCCESS`
+
+- [ ] **Step 4: 本地启动后端，确认无 Redis 也可启动**
+
+Run: `mvn -pl ruoyi-admin -am spring-boot:run`
+
+Expected: 应用启动成功，日志中不再出现 Redis 连接初始化失败。
+
+- [ ] **Step 5: 手工验证关键链路**
+
+按顺序验证：
+- 登录
+- 验证码
+- 登录失败锁定
+- 在线用户列表
+- 强退用户
+- 配置刷新
+- 字典刷新
+- 缓存监控查看与清理
+
+- [ ] **Step 6: 停止后端进程**
+
+要求：测试结束后自动结束当前任务拉起的 Java 进程，不保留后台测试进程。
+
+- [ ] **Step 7: 提交本任务**
+
+```bash
+git add ruoyi-system/src/main/java/com/ruoyi/system/service/impl/SysConfigServiceImpl.java \
+  ruoyi-common/src/main/java/com/ruoyi/common/utils/DictUtils.java \
+  ruoyi-admin/src/main/resources/application-dev.yml
+git commit -m "完成Redis移除后端收尾"
+```

doc/2026-03-28-remove-redis-design.md

@@ -0,0 +1,278 @@
+# 生产环境移除 Redis 依赖设计文档
+
+## 1. 背景
+
+当前项目基于若依前后端分离架构，Redis 在系统中承担了多类运行时状态能力，包括：
+
+- JWT 登录态缓存
+- 验证码缓存
+- 登录失败次数缓存
+- 防重提交短期缓存
+- 接口限流计数
+- 系统配置缓存
+- 数据字典缓存
+- 在线用户查询与强退
+- 缓存监控页面与缓存清理接口
+
+现有生产环境没有 Redis，因此需要彻底移除 Redis 依赖，并保证修改后与修改前的业务功能保持一致。
+
+## 2. 已确认约束
+
+- 生产环境为单实例部署
+- 应用重启后，登录态、验证码、限流计数、登录失败次数等临时状态允许丢失
+- 不引入新的中间件
+- 不额外设计数据库持久化方案
+- 目标是最短路径实现，避免补丁式和过度设计方案
+
+## 3. 目标
+
+- 移除 Redis 运行依赖与相关配置
+- 保留现有业务功能与主要接口行为
+- 保留现有前端缓存监控入口与主要能力
+- 保证项目在无 Redis 配置、无 Redis 服务的情况下可正常启动和运行
+
+## 4. 方案对比
+
+### 方案一：统一进程内缓存层替换 Redis
+
+将当前基于 Redis 的缓存访问统一收口为进程内缓存实现，保持上层业务调用方式和缓存语义尽量不变。
+
+优点：
+
+- 改动集中，替换边界清晰
+- 最容易保持原有业务行为不变
+- 不需要引入新基础设施
+- 适合单实例部署场景
+
+缺点：
+
+- 需要补足 TTL、前缀查询、统计信息等基础能力
+- 限流逻辑需要从 Redis 脚本改为本地原子实现
+
+### 方案二：按场景分别重写
+
+登录态、验证码、配置缓存、字典缓存、限流、防重分别改造成各自独立的本地实现。
+
+优点：
+
+- 单点改造直观
+
+缺点：
+
+- 改动分散
+- 行为一致性难保证
+- 容易遗漏使用点
+- 后续维护成本更高
+
+### 方案三：部分状态改存数据库
+
+将登录态、验证码、失败次数等状态迁移到 MySQL。
+
+优点：
+
+- 状态具备一定持久性
+
+缺点：
+
+- 偏离本次最短路径目标
+- 需要新增表结构、清理逻辑和一致性处理
+- 复杂度明显高于当前需求
+
+## 5. 设计结论
+
+采用方案一：以统一进程内缓存层替换 Redis。
+
+实现原则：
+
+- 保留当前主要业务调用入口，避免业务层大面积改写
+- 将所有 Redis 依赖集中替换为本地线程安全缓存实现
+- 保持 key 组织方式、TTL 语义、按前缀检索、删除和清理行为不变
+- 对外接口路径尽量不变，优先保障现有前后端功能连续性
+
+## 6. 总体设计
+
+### 6.1 基础设施替换边界
+
+本次改造不采用“逐处删除 Redis 调用”的方式，而是保留当前缓存入口职责，将底层从 Spring Data Redis 替换为进程内缓存服务。
+
+范围包括：
+
+- 移除 `spring-boot-starter-data-redis` 依赖
+- 移除 `application-*.yml` 中的 Redis 配置
+- 移除 `RedisTemplate`、`RedisConnectionFactory`、Lua 限流脚本等 Redis 专属配置
+- 为现有缓存访问入口提供本地实现
+
+### 6.2 本地缓存能力要求
+
+本地缓存组件必须提供以下能力：
+
+- `set`
+- `get`
+- `hasKey`
+- `delete`
+- 批量删除
+- 基于前缀的 `keys(pattern*)`
+- TTL 过期控制
+- 过期数据清理
+- 基础命中和访问统计
+
+该缓存实现需要线程安全，以保证登录、限流、防重提交等高频路径在单实例下的正确性。
+
+## 7. 业务行为兼容设计
+
+### 7.1 登录态
+
+`TokenService` 当前通过 JWT 保存 token 标识，并将 `LoginUser` 存入 Redis。改造后继续维持该模型：
+
+- JWT 内容保持不变
+- `token -> LoginUser` 存入本地缓存
+- TTL 仍由 `token.expireTime` 控制
+- 临近过期时继续自动续期
+- 注销时删除对应登录态
+
+这样可以保持登录、鉴权、刷新 token、在线用户列表、强退用户等行为不变。
+
+### 7.2 验证码
+
+验证码继续按 `uuid -> code` 存储在本地缓存中，并沿用当前过期时间配置。
+
+- 生成验证码后写入缓存
+- 校验时读取并删除
+- 过期后自动失效
+
+### 7.3 登录失败次数
+
+登录失败次数继续按用户名缓存，保持：
+
+- 连续失败次数累加
+- 达到阈值后锁定
+- 锁定时间到期后自动解除
+- 登录成功后清理失败记录
+
+### 7.4 防重提交
+
+`SameUrlDataInterceptor` 继续按 `url + submitKey` 保存短时缓存，保留当前毫秒级过期控制和重复提交判断逻辑。
+
+### 7.5 限流
+
+原有限流逻辑依赖 Redis Lua 脚本做原子计数。由于当前部署为单实例，可以改为本地原子计数实现，保留现有注解参数语义：
+
+- 限流 key 规则不变
+- 时间窗口含义不变
+- 阈值含义不变
+- 超限返回逻辑不变
+
+### 7.6 系统配置缓存
+
+`SysConfigServiceImpl` 继续通过缓存保存系统配置，保持：
+
+- 启动加载缓存
+- 按 key 读取缓存
+- 新增、修改、删除配置时同步刷新缓存
+- 手动刷新缓存接口继续可用
+
+### 7.7 数据字典缓存
+
+`DictUtils` 与字典服务继续使用缓存保存字典数据，保持：
+
+- 首次加载与重载逻辑不变
+- 字典刷新接口不变
+- 前端字典相关功能无感知
+
+### 7.8 在线用户
+
+在线用户列表和强退功能继续基于登录 token 前缀扫描实现，因此本地缓存必须支持按前缀查询 key。
+
+### 7.9 缓存监控
+
+不删除缓存监控功能。保留：
+
+- 菜单入口
+- 前端页面路由
+- 后端接口路径
+- 缓存清理能力
+
+底层统计来源从 Redis 改为本地缓存统计视图。
+
+## 8. 缓存监控设计
+
+### 8.1 保留现有能力
+
+`CacheController` 继续提供以下接口能力：
+
+- 缓存概览
+- 缓存名称列表
+- 指定分类下的 key 列表
+- 指定 key 的值查看
+- 按分类清理
+- 按 key 清理
+- 全量清理
+
+### 8.2 监控数据来源调整
+
+由于 Redis 已移除，缓存监控页面中的信息调整为本地缓存统计信息，例如：
+
+- 缓存类型：`IN_MEMORY`
+- 运行模式：`single-instance`
+- 当前缓存总数
+- 读取次数
+- 命中次数
+- 过期清理次数
+
+返回结构应尽量兼容当前前端页面，减少前端改动范围。
+
+### 8.3 文案调整
+
+对于前端页面中明显写死的 Redis 文案，需要调整为更准确的“缓存监控”或“本地缓存监控”，避免出现界面语义错误。
+
+## 9. 配置与依赖调整
+
+需要完成以下调整：
+
+- 删除 Maven 中 Redis 相关依赖
+- 删除后端配置中的 Redis 段
+- 清理 Redis 专属配置类与序列化器引用
+- 清理直接依赖 `RedisTemplate` 的控制器和切面实现
+- 将相关逻辑改为依赖统一的本地缓存服务
+
+## 10. 测试与验收
+
+验收以业务行为为准，至少覆盖：
+
+- 登录成功后可访问受保护接口
+- token 临近过期时自动续期正常
+- 在线用户列表可查询
+- 在线用户强退可用
+- 验证码生成与校验正常
+- 登录失败次数限制正常
+- 防重提交正常
+- 限流正常
+- 配置缓存刷新正常
+- 字典缓存刷新正常
+- 缓存监控页面可打开、可查看、可清理
+- 项目在无 Redis 配置、无 Redis 服务时可启动
+
+## 11. 风险与边界
+
+- 本方案仅适用于当前确认的单实例部署
+- 由于缓存改为进程内存储，多实例部署时不会共享状态
+- 重启后临时状态会丢失，此行为已被确认可接受
+- 本次不增加跨实例一致性能力，不增加持久化方案
+
+## 12. 实施范围说明
+
+本设计文档仅定义 Redis 移除与本地缓存替换方案，不扩展到以下范围：
+
+- 多实例一致性方案
+- 引入数据库持久化缓存
+- 引入新的第三方缓存组件
+- 额外新增降级或兜底机制
+
+## 13. 后续输出
+
+在该设计确认后，下一步需要输出两份实施计划：
+
+- 后端实施计划
+- 前端实施计划
+
+并在实际编码改动时同步维护对应实施记录文档。

doc/2026-03-28-remove-redis-frontend-plan.md

@@ -0,0 +1,182 @@
+# 前端移除 Redis 监控适配 Implementation Plan
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 在不改变前端路由与主要交互的前提下，将缓存监控页面从 Redis 专属视图调整为本地缓存监控视图，并保持缓存列表、键名列表、缓存内容与清理操作可用。
+
+**Architecture:** 前端继续复用现有 `/monitor/cache` API 路径，不引入新的页面或状态管理。调整 `monitor/cache/index.vue` 的展示结构与文案，使其消费后端返回的本地缓存统计字段；`list.vue` 仅保留必要文案和联调适配，避免额外重构。
+
+**Tech Stack:** Vue 2, Element UI, Axios, ECharts, Vue CLI
+
+---
+
+## 文件结构
+
+### 需要修改
+
+- `ruoyi-ui/src/views/monitor/cache/index.vue`
+- `ruoyi-ui/src/views/monitor/cache/list.vue`
+- `ruoyi-ui/src/api/monitor/cache.js`
+
+### 原则
+
+- 不新增前端路由
+- 不改接口地址
+- 不引入新的前端测试框架
+- 文案准确，但保持页面结构尽量稳定
+
+## Task 1: 调整缓存概览页消费本地缓存字段
+
+**Files:**
+- Modify: `ruoyi-ui/src/views/monitor/cache/index.vue`
+
+- [ ] **Step 1: 先按新接口结构写静态映射草稿**
+
+```js
+cache: {
+  info: {
+    cache_type: "IN_MEMORY",
+    cache_mode: "single-instance",
+    key_size: 0,
+    hit_count: 0,
+    miss_count: 0,
+    expired_count: 0,
+    write_count: 0
+  },
+  dbSize: 0,
+  commandStats: []
+}
+```
+
+- [ ] **Step 2: 将页面字段从 Redis 专属项改为本地缓存项**
+
+需要替换的展示重点：
+- `Redis版本` -> `缓存类型`
+- `运行模式` 保留
+- `端口` -> `总键数`
+- `客户端数` -> `写入次数`
+- `运行时间(天)` -> `命中次数`
+- `使用内存` -> `未命中次数`
+- `使用CPU` -> `过期清理次数`
+- `内存配置` -> `监控采样时间` 或 `统计说明`
+
+- [ ] **Step 3: 调整 ECharts 数据绑定**
+
+```js
+this.commandstats.setOption({
+  series: [{ data: response.data.commandStats }]
+})
+```
+
+同时将第二张图从 “内存信息” 调整为更适合本地缓存统计的图表，比如“命中/未命中/过期”仪表或柱状图，但不要新增页面复杂度。
+
+- [ ] **Step 4: 保证空数据也能渲染**
+
+要求：
+- `commandStats` 为空时页面不报错
+- `cache.info` 缺字段时不触发 `parseFloat(undefined)`
+
+- [ ] **Step 5: 运行生产构建**
+
+Run: `npm --prefix ruoyi-ui run build:prod`
+
+Expected: `Build complete.`
+
+- [ ] **Step 6: 提交本任务**
+
+```bash
+git add ruoyi-ui/src/views/monitor/cache/index.vue
+git commit -m "调整前端缓存概览展示"
+```
+
+## Task 2: 复核缓存列表页与接口适配
+
+**Files:**
+- Modify: `ruoyi-ui/src/views/monitor/cache/list.vue`
+- Modify: `ruoyi-ui/src/api/monitor/cache.js`
+
+- [ ] **Step 1: 确认接口层无需改路径，只做必要注释和兼容梳理**
+
+保持以下 API 不变：
+
+```js
+getCache()
+listCacheName()
+listCacheKey(cacheName)
+getCacheValue(cacheName, cacheKey)
+clearCacheName(cacheName)
+clearCacheKey(cacheKey)
+clearCacheAll()
+```
+
+- [ ] **Step 2: 检查 `list.vue` 是否依赖 Redis 专属文案**
+
+重点确认：
+- 成功提示文案仍然准确
+- `nameFormatter`、`keyFormatter` 继续适配缓存前缀
+- 清理全部后是否需要主动清空右侧表单和中间列表
+
+- [ ] **Step 3: 补最小交互修正**
+
+如果后端改为本地缓存后返回空列表，需要补以下保护：
+
+```js
+this.cacheKeys = response.data || []
+this.cacheForm = {}
+```
+
+避免清理后页面残留旧值。
+
+- [ ] **Step 4: 重新运行生产构建**
+
+Run: `npm --prefix ruoyi-ui run build:prod`
+
+Expected: `Build complete.`
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-ui/src/views/monitor/cache/list.vue ruoyi-ui/src/api/monitor/cache.js
+git commit -m "完成前端缓存列表适配"
+```
+
+## Task 3: 联调验证与测试进程收尾
+
+**Files:**
+- Modify: `ruoyi-ui/src/views/monitor/cache/index.vue`
+- Modify: `ruoyi-ui/src/views/monitor/cache/list.vue`
+
+- [ ] **Step 1: 启动前端开发服务联调缓存监控页**
+
+Run: `npm --prefix ruoyi-ui run dev`
+
+Expected: 本地前端启动成功，可访问缓存监控页面。
+
+- [ ] **Step 2: 联调验证页面**
+
+验证点：
+- 缓存概览页可打开
+- 图表能展示本地缓存统计
+- 缓存列表能加载
+- 点击缓存名称能加载键名
+- 点击键名能查看内容
+- 单项清理、按分类清理、全部清理都能成功提示
+
+- [ ] **Step 3: 如需文案微调，仅做最小改动**
+
+禁止扩展：
+- 不新增入口页面
+- 不改路由结构
+- 不改全局 store
+- 不引入测试框架
+
+- [ ] **Step 4: 停止前端测试进程**
+
+要求：联调完成后结束本任务启动的 Node 前端进程，不保留后台测试服务。
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-ui/src/views/monitor/cache/index.vue ruoyi-ui/src/views/monitor/cache/list.vue
+git commit -m "完成前端缓存监控联调"
+```

doc/2026-03-28-workflow-calculate-rate-list-backend-plan.md

@@ -0,0 +1,215 @@
+# 流程列表测算利率展示后端实施计划
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan in this repository. Do not use subagents. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 让流程列表接口通过联表 SQL 一次返回测算利率 `calculateRate` 和执行利率 `executeRate`。
+
+**Architecture:** 后端为流程列表新增列表专用返回对象，替换当前直接返回 `LoanPricingWorkflow` 实体分页的方式。Mapper 层新增联表 SQL，以 `loan_pricing_workflow` 为主表，左连接个人和企业模型输出表，并统一产出 `calculateRate` 字段供前端直接消费。
+
+**Tech Stack:** Spring Boot、MyBatis Plus、Lombok、Maven、XML Mapper
+
+---
+
+### Task 1: 建立流程列表专用返回对象
+
+**Files:**
+- Create: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVO.java`
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/ILoanPricingWorkflowService.java`
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/controller/LoanPricingWorkflowController.java`
+
+- [ ] **Step 1: 写一个失败测试，约束列表返回对象需要包含测算利率**
+
+Create/Test: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVOTest.java`
+
+测试示例：
+
+```java
+@Test
+void shouldExposeCalculateRateAndExecuteRateFields() throws Exception {
+    LoanPricingWorkflowListVO vo = new LoanPricingWorkflowListVO();
+    vo.setCalculateRate("6.15");
+    vo.setExecuteRate("5.80");
+
+    assertEquals("6.15", vo.getCalculateRate());
+    assertEquals("5.80", vo.getExecuteRate());
+}
+```
+
+- [ ] **Step 2: 运行测试确认在对象未创建前失败**
+
+Run: `mvn -pl ruoyi-loan-pricing -Dtest=LoanPricingWorkflowListVOTest test`
+Expected: FAIL，提示 `LoanPricingWorkflowListVO` 不存在或缺少字段。
+
+- [ ] **Step 3: 新增列表专用 VO**
+
+创建 `LoanPricingWorkflowListVO`，至少包含：
+
+```java
+private String serialNum;
+private String custName;
+private String custType;
+private String guarType;
+private String applyAmt;
+private String calculateRate;
+private String executeRate;
+private Date createTime;
+private String createBy;
+```
+
+- [ ] **Step 4: 修改 Service 接口与 Controller 返回类型**
+
+将列表分页返回从：
+
+```java
+IPage<LoanPricingWorkflow>
+```
+
+调整为：
+
+```java
+IPage<LoanPricingWorkflowListVO>
+```
+
+并同步更新 Controller 列表接口使用的新分页结果类型。
+
+- [ ] **Step 5: 再次运行测试确认返回对象字段已可用**
+
+Run: `mvn -pl ruoyi-loan-pricing -Dtest=LoanPricingWorkflowListVOTest test`
+Expected: PASS
+
+- [ ] **Step 6: 提交这一小步**
+
+Run: `git add ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVO.java ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/ILoanPricingWorkflowService.java ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/controller/LoanPricingWorkflowController.java ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVOTest.java && git commit -m "新增流程列表测算利率返回对象"`
+Expected: 生成仅包含 VO 与接口调整的中文提交。
+
+### Task 2: 新增联表 SQL 返回统一测算利率
+
+**Files:**
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/mapper/LoanPricingWorkflowMapper.java`
+- Create: `ruoyi-loan-pricing/src/main/resources/mapper/loanpricing/LoanPricingWorkflowMapper.xml`
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java`
+- Test: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java`
+
+- [ ] **Step 1: 写一个失败测试，约束服务层返回的列表对象要透传 `calculateRate`**
+
+Create/Test: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java`
+
+测试示例：
+
+```java
+@Test
+void shouldReturnPagedWorkflowListWithCalculateRate() {
+    Page<LoanPricingWorkflowListVO> page = new Page<>(1, 10);
+    LoanPricingWorkflow query = new LoanPricingWorkflow();
+    LoanPricingWorkflowListVO row = new LoanPricingWorkflowListVO();
+    row.setCalculateRate("6.15");
+
+    when(loanPricingWorkflowMapper.selectWorkflowPageWithRates(any(), any())).thenReturn(new Page<LoanPricingWorkflowListVO>().setRecords(List.of(row)));
+
+    IPage<LoanPricingWorkflowListVO> result = service.selectLoanPricingPage(page, query);
+
+    assertEquals("6.15", result.getRecords().get(0).getCalculateRate());
+}
+```
+
+- [ ] **Step 2: 运行测试确认在方法未接入前失败**
+
+Run: `mvn -pl ruoyi-loan-pricing -Dtest=LoanPricingWorkflowServiceImplTest test`
+Expected: FAIL，提示方法签名不匹配或 Mapper 自定义方法不存在。
+
+- [ ] **Step 3: 在 Mapper 接口声明列表专用分页方法**
+
+在 `LoanPricingWorkflowMapper` 中新增类似方法：
+
+```java
+IPage<LoanPricingWorkflowListVO> selectWorkflowPageWithRates(
+        Page<LoanPricingWorkflowListVO> page,
+        @Param("query") LoanPricingWorkflow query);
+```
+
+- [ ] **Step 4: 在 XML 中实现联表 SQL**
+
+创建 `LoanPricingWorkflowMapper.xml`，编写列表专用查询，关键逻辑至少包含：
+
+```xml
+SELECT
+  lpw.serial_num AS serialNum,
+  lpw.cust_name AS custName,
+  lpw.cust_type AS custType,
+  lpw.guar_type AS guarType,
+  lpw.apply_amt AS applyAmt,
+  CASE
+    WHEN lpw.cust_type = '个人' THEN mr.calculate_rate
+    WHEN lpw.cust_type = '企业' THEN mc.calculate_rate
+    ELSE NULL
+  END AS calculateRate,
+  lpw.execute_rate AS executeRate,
+  lpw.create_time AS createTime,
+  lpw.create_by AS createBy
+FROM loan_pricing_workflow lpw
+LEFT JOIN model_retail_output_fields mr ON lpw.model_output_id = mr.id
+LEFT JOIN model_corp_output_fields mc ON lpw.model_output_id = mc.id
+```
+
+并保留当前筛选条件和按更新时间倒序。
+
+- [ ] **Step 5: 在 ServiceImpl 中改为调用联表分页方法**
+
+将列表分页实现从：
+
+```java
+return loanPricingWorkflowMapper.selectPage(page, wrapper);
+```
+
+切换为调用新的 Mapper 联表分页方法，保留查询参数透传。
+
+- [ ] **Step 6: 运行服务层测试确认通过**
+
+Run: `mvn -pl ruoyi-loan-pricing -Dtest=LoanPricingWorkflowServiceImplTest test`
+Expected: PASS
+
+- [ ] **Step 7: 如需补充 XML 级验证，再运行模块测试**
+
+Run: `mvn -pl ruoyi-loan-pricing test`
+Expected: 至少本次新增测试通过；若存在其他失败，需先区分是否为既有问题。
+
+- [ ] **Step 8: 提交这一小步**
+
+Run: `git add ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/mapper/LoanPricingWorkflowMapper.java ruoyi-loan-pricing/src/main/resources/mapper/loanpricing/LoanPricingWorkflowMapper.xml ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java && git commit -m "新增流程列表测算利率联表查询"`
+Expected: 生成包含联表 SQL 与服务切换的中文提交。
+
+### Task 3: 完成后端留档与接口验证
+
+**Files:**
+- Create: `doc/implementation-report-2026-03-28-workflow-calculate-rate-list-backend.md`
+
+- [ ] **Step 1: 补充后端实施记录**
+
+实施记录至少写明：
+
+```markdown
+- 列表接口返回类型已调整为列表专用 VO
+- 后端通过联表 SQL 一次返回 `calculateRate` 与 `executeRate`
+- 个人客户测算利率来自 `model_retail_output_fields.calculate_rate`
+- 企业客户测算利率来自 `model_corp_output_fields.calculate_rate`
+```
+
+- [ ] **Step 2: 验证列表接口返回结构**
+
+Run: 按项目现有方式启动后端后，请求 `/loanPricing/workflow/list`
+Expected: 返回行数据中包含 `calculateRate` 和 `executeRate`。
+
+- [ ] **Step 3: 核对个人和企业记录的测算利率来源**
+
+Run: 使用已有测试数据各抽取一条个人和企业记录，对比接口返回与模型输出表数据。
+Expected: 个人记录取自零售模型输出表，企业记录取自对公模型输出表。
+
+- [ ] **Step 4: 如果为验证启动了后端进程，结束对应进程**
+
+Run: `ps -ef | rg 'RuoYiApplication|java'`
+Expected: 对本次验证启动的后端进程执行停止；对非本次启动进程不做处理。
+
+- [ ] **Step 5: 提交后端实施记录**
+
+Run: `git add doc/implementation-report-2026-03-28-workflow-calculate-rate-list-backend.md && git commit -m "补充测算利率列表后端实施记录"`
+Expected: 生成仅包含后端留档内容的中文提交。

doc/2026-03-28-workflow-calculate-rate-list-design.md

@@ -0,0 +1,188 @@
+# 流程列表测算利率展示设计文档
+
+## 1. 背景
+
+当前流程列表页已经展示“执行利率(%)”，但还没有展示“测算利率(%)”。现有测算利率并不存放在流程表 `loan_pricing_workflow` 中，而是存放在模型输出表中：
+
+- 个人客户：`model_retail_output_fields.calculate_rate`
+- 企业客户：`model_corp_output_fields.calculate_rate`
+
+本次需求是在流程列表页新增“测算利率(%)”列，并与“执行利率(%)”同时展示。
+
+## 2. 已确认约束
+
+- 仅为流程列表页新增“测算利率(%)”展示
+- 测算利率直接取模型输出表中的 `calculate_rate`
+- 不新增冗余字段回写到 `loan_pricing_workflow`
+- 正式方案采用联表 SQL，一次查出流程表和两张模型输出表所需字段
+- 文档和计划统一保存在 `doc` 目录
+
+## 3. 现状分析
+
+当前流程列表页数据来源为 `/loanPricing/workflow/list`，后端列表接口直接基于 `LoanPricingWorkflow` 分页返回流程表字段。现状存在两个限制：
+
+1. 流程表本身只有 `loanRate` 和 `executeRate`
+2. 测算利率 `calculateRate` 分散在个人、企业两张模型输出表中
+
+因此，如果不改列表查询链路，前端无法直接在列表页拿到统一的测算利率字段。
+
+## 4. 方案对比
+
+### 方案一：后端分页后按记录补查测算利率
+
+做法：
+
+- 先查流程表分页结果
+- 再根据每条记录的 `custType` 和 `modelOutputId` 到对应模型输出表查询 `calculateRate`
+
+优点：
+
+- 改动可控
+
+缺点：
+
+- 查询次数随列表记录数增加
+- 服务层补查逻辑分散
+- 不符合本次已选定的联表方案
+
+### 方案二：联表 SQL 一次查询流程列表和测算利率
+
+做法：
+
+- 以 `loan_pricing_workflow` 为主表
+- 基于 `model_output_id` 左连接 `model_retail_output_fields` 和 `model_corp_output_fields`
+- 统一返回一个列表专用字段 `calculateRate`
+
+优点：
+
+- 一次查询返回列表展示所需数据
+- 前端消费简单
+- 不需要额外补查或详情接口拼装
+
+缺点：
+
+- Mapper 查询层需要新增列表专用 SQL
+- 返回对象需要从实体扩展为列表专用对象
+
+### 方案三：前端逐条拉详情拼装测算利率
+
+做法：
+
+- 列表先只返回流程数据
+- 前端逐条再请求详情，取详情中的测算利率
+
+优点：
+
+- 后端改动相对少
+
+缺点：
+
+- 请求次数多
+- 列表渲染复杂
+- 属于补丁式方案，不符合本次约束
+
+## 5. 设计结论
+
+采用方案二：联表 SQL 一次查询流程表和两张模型输出表，统一返回流程列表展示对象。
+
+最终效果：
+
+- 流程列表页新增“测算利率(%)”列
+- 默认放在“执行利率(%)”前面
+- “测算利率(%)”展示统一返回字段 `calculateRate`
+- “执行利率(%)”继续展示 `executeRate`
+
+## 6. 后端设计
+
+### 6.1 返回对象
+
+为流程列表新增列表专用返回对象，至少包含：
+
+- 业务方流水号
+- 客户名称
+- 客户类型
+- 担保方式
+- 申请金额
+- 测算利率 `calculateRate`
+- 执行利率 `executeRate`
+- 创建时间
+- 创建者
+
+不再让列表接口直接返回裸 `LoanPricingWorkflow` 实体。
+
+### 6.2 SQL 设计
+
+以 `loan_pricing_workflow` 为主表，联表查询：
+
+- `LEFT JOIN model_retail_output_fields mr ON lpw.model_output_id = mr.id`
+- `LEFT JOIN model_corp_output_fields mc ON lpw.model_output_id = mc.id`
+
+测算利率统一按客户类型取值，返回别名 `calculateRate`。可采用 `CASE WHEN` 或等价写法：
+
+- 当客户类型为“个人”时取 `mr.calculate_rate`
+- 当客户类型为“企业”时取 `mc.calculate_rate`
+
+### 6.3 分页与筛选
+
+保留当前列表分页和筛选能力：
+
+- 按创建者模糊查询
+- 按客户名称模糊查询
+- 按机构号模糊查询
+- 按更新时间倒序
+
+分页能力仍由当前列表接口承担，不改变接口入口路径。
+
+## 7. 前端设计
+
+流程列表页 `ruoyi-ui/src/views/loanPricing/workflow/index.vue` 新增一列：
+
+- 列名：`测算利率(%)`
+- 位置：放在 `执行利率(%)` 前面
+- 绑定字段：`calculateRate`
+
+现有 `执行利率(%)` 列不改，继续绑定 `executeRate`。
+
+## 8. 边界与非目标
+
+本次不包含以下内容：
+
+- 不修改详情页测算利率展示逻辑
+- 不修改执行利率设置逻辑
+- 不修改流程创建逻辑
+- 不修改数据库表结构
+- 不新增流程表冗余字段存放测算利率
+- 不让前端按客户类型自行拼装测算利率来源
+
+## 9. 风险与控制
+
+风险点主要有两个：
+
+1. 联表后返回结构变化，可能影响前端列表字段读取
+2. 个人/企业客户测算利率来源不同，若统一字段取值逻辑写错，会出现空值或串值
+
+控制方式：
+
+- 使用列表专用返回对象，避免污染实体语义
+- 在 SQL 中用统一别名 `calculateRate` 输出
+- 保持 `executeRate` 字段逻辑不变
+- 通过源码和接口结果核对个人、企业两类记录的展示值
+
+## 10. 验证方案
+
+实施后需要完成以下验证：
+
+1. 后端列表查询结果中包含 `calculateRate`
+2. 个人客户记录的 `calculateRate` 来自 `model_retail_output_fields.calculate_rate`
+3. 企业客户记录的 `calculateRate` 来自 `model_corp_output_fields.calculate_rate`
+4. 前端流程列表页新增“测算利率(%)”列，且位于“执行利率(%)”前面
+5. 流程列表页同时正常展示“测算利率(%)”和“执行利率(%)”
+6. 列表查询、查看详情、设置执行利率功能不受影响
+
+## 11. 实施范围
+
+- 前端：流程列表页 1 个页面文件
+- 后端：Controller / Service / Mapper / 列表返回对象
+- 数据库：无表结构改动
+
+本次属于列表查询结构增强与前端展示补充，不涉及数据模型持久化变更。

doc/2026-03-28-workflow-calculate-rate-list-frontend-plan.md

@@ -0,0 +1,95 @@
+# 流程列表测算利率展示前端实施计划
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan in this repository. Do not use subagents. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 在流程列表页新增“测算利率(%)”列，并与“执行利率(%)”同时展示。
+
+**Architecture:** 前端只消费后端列表接口新增返回的 `calculateRate` 字段，不在页面自行判断客户类型或拼接数据来源。页面层仅新增一列并保持现有查询、查看详情和执行利率展示逻辑不变。
+
+**Tech Stack:** Vue 2、Element UI、RuoYi 前端工程、npm
+
+---
+
+### Task 1: 为流程列表页新增测算利率列
+
+**Files:**
+- Modify: `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+- Test: 手工页面验证流程列表页
+
+- [ ] **Step 1: 查看当前流程列表页列顺序**
+
+Run: `sed -n '45,70p' ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+Expected: 能看到当前表格列中已有“执行利率(%)”列，且其前面还没有“测算利率(%)”列。
+
+- [ ] **Step 2: 在“执行利率(%)”前新增“测算利率(%)”列**
+
+将列表表格中的利率区域调整为如下结构：
+
+```vue
+<el-table-column label="申请金额(元)" align="center" prop="applyAmt" width="120" />
+<el-table-column label="测算利率(%)" align="center" prop="calculateRate" width="100" />
+<el-table-column label="执行利率(%)" align="center" prop="executeRate" width="100" />
+```
+
+- [ ] **Step 3: 重新检查源码确认新增列位置和字段绑定**
+
+Run: `rg -n '测算利率\\(%\\)|执行利率\\(%\\)|prop=\"calculateRate\"|prop=\"executeRate\"' ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+Expected: 能看到“测算利率(%)”列存在，且位于“执行利率(%)”之前，并绑定 `calculateRate`。
+
+- [ ] **Step 4: 执行前端构建验证**
+
+Run: `npm --prefix ruoyi-ui run build:prod`
+Expected: 构建成功，输出包含 `Build complete.`
+
+- [ ] **Step 5: 补充本次前端实施记录**
+
+新增实施记录文件：`doc/implementation-report-2026-03-28-workflow-calculate-rate-list-frontend.md`
+
+至少写明：
+
+```markdown
+- 流程列表页新增“测算利率(%)”列
+- 新增列绑定后端返回字段 `calculateRate`
+- “执行利率(%)”列保持 `executeRate` 不变
+- 已完成前端构建验证
+```
+
+- [ ] **Step 6: 如果为验证启动了前端进程，结束对应进程**
+
+Run: `ps -ef | rg 'ruoyi-ui|vue-cli-service'`
+Expected: 如果本次任务为验证启动了新的前端进程，验证结束后主动停止；对非本次启动的现有进程不做处理。
+
+- [ ] **Step 7: 提交前端改动**
+
+Run: `git add ruoyi-ui/src/views/loanPricing/workflow/index.vue doc/implementation-report-2026-03-28-workflow-calculate-rate-list-frontend.md && git commit -m "新增流程列表测算利率前端展示"`
+Expected: 生成仅包含本次前端改动的中文提交。
+
+### Task 2: 页面联调确认双利率展示
+
+**Files:**
+- Modify: `doc/implementation-report-2026-03-28-workflow-calculate-rate-list-frontend.md`
+
+- [ ] **Step 1: 打开流程列表页确认页面可正常加载**
+
+Run: 按项目现有方式启动前端并进入贷款定价流程列表页。
+Expected: 页面正常渲染，表格可展示列表数据。
+
+- [ ] **Step 2: 验证“测算利率(%)”和“执行利率(%)”同时展示**
+
+Run: 在页面上核对至少一条记录的两列展示值。
+Expected: “测算利率(%)”展示后端返回的 `calculateRate`，“执行利率(%)”继续展示 `executeRate`。
+
+- [ ] **Step 3: 将联调结果写入前端实施记录**
+
+将以下结果写入实施记录：
+
+```markdown
+- 已确认流程列表页新增“测算利率(%)”列
+- 已确认“测算利率(%)”列位于“执行利率(%)”列之前
+- 已确认双利率字段可同时展示
+```
+
+- [ ] **Step 4: 停止联调过程中启动的前端进程**
+
+Run: `ps -ef | rg 'ruoyi-ui|vue-cli-service'`
+Expected: 若存在本次联调启动的进程，全部停止后再结束任务。

doc/2026-03-28-workflow-execute-rate-display-backend-plan.md

@@ -0,0 +1,71 @@
+# 流程列表执行利率展示后端实施计划
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan in this repository. Do not use subagents. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 确认流程列表执行利率展示需求无需后端代码改动，并完成后端链路验证与留档。
+
+**Architecture:** 当前后端列表接口直接返回 `LoanPricingWorkflow` 实体，而实体已包含 `executeRate` 字段。本次后端计划不引入接口变更，只做链路确认、边界验证和实施记录，确保执行阶段不会误改接口或字段语义。
+
+**Tech Stack:** Spring Boot、MyBatis Plus、Maven、RuoYi 后端工程
+
+---
+
+### Task 1: 确认后端列表链路已具备执行利率返回能力
+
+**Files:**
+- Modify: `doc/implementation-report-2026-03-28-workflow-execute-rate-display-backend.md`
+- Reference: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/entity/LoanPricingWorkflow.java`
+- Reference: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/controller/LoanPricingWorkflowController.java`
+- Reference: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java`
+
+- [ ] **Step 1: 确认实体包含 `executeRate` 字段**
+
+Run: `rg -n 'private String executeRate' ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/entity/LoanPricingWorkflow.java`
+Expected: 能定位到 `executeRate` 字段定义。
+
+- [ ] **Step 2: 确认列表接口直接返回 `LoanPricingWorkflow`**
+
+Run: `sed -n '60,90p' ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/controller/LoanPricingWorkflowController.java`
+Expected: 能看到 `/loanPricing/workflow/list` 直接返回 `LoanPricingWorkflow` 分页结果。
+
+- [ ] **Step 3: 确认分页查询未对 `executeRate` 做截断或替换**
+
+Run: `sed -n '100,150p' ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java`
+Expected: 能看到分页查询直接返回实体分页记录，无额外字段转换逻辑。
+
+- [ ] **Step 4: 形成后端结论并写入实施记录**
+
+将以下内容写入实施记录：
+
+```markdown
+- 后端实体已包含 `executeRate`
+- 列表接口已直接返回 `LoanPricingWorkflow`
+- 本次需求无需后端代码改动
+```
+
+建议记录文件：`doc/implementation-report-2026-03-28-workflow-execute-rate-display-backend.md`
+
+### Task 2: 完成后端验证边界说明
+
+**Files:**
+- Modify: `doc/implementation-report-2026-03-28-workflow-execute-rate-display-backend.md`
+
+- [ ] **Step 1: 说明本次明确不改后端接口和数据库结构**
+
+将以下说明加入实施记录：
+
+```markdown
+- 不修改 `/loanPricing/workflow/list` 接口结构
+- 不修改 `loanRate` 字段业务含义
+- 不修改数据库表结构和 SQL
+```
+
+- [ ] **Step 2: 如执行了后端本地验证，结束相关进程**
+
+Run: `ps -ef | rg 'RuoYiApplication|java'`
+Expected: 若本次任务为验证启动了后端进程，验证完成后主动停止本次启动的进程。
+
+- [ ] **Step 3: 提交后端留档改动**
+
+Run: `git add doc/implementation-report-2026-03-28-workflow-execute-rate-display-backend.md && git commit -m "补充执行利率展示后端实施记录"`
+Expected: 生成仅包含后端留档内容的中文提交。

doc/2026-03-28-workflow-execute-rate-display-design.md

@@ -0,0 +1,143 @@
+# 流程列表执行利率展示设计文档
+
+## 1. 背景
+
+当前贷款定价流程列表页中，“执行利率(%)”列头已经调整为执行利率语义，但列表列绑定字段仍为 `loanRate`。这会导致页面展示的仍是贷款利率字段，而不是数据库 `loan_pricing_workflow.execute_rate` 中保存的实际执行利率数据。
+
+本次需求明确限定为：
+
+- 只调整流程列表页
+- 展示数据库中的执行利率实际数据
+- 不扩散到详情页、接口定义、数据库结构或其他页面
+
+## 2. 已确认约束
+
+- 仅修改流程列表页展示逻辑
+- 保持后端列表接口 `/loanPricing/workflow/list` 不变
+- 保持实体 `LoanPricingWorkflow`、数据库表 `loan_pricing_workflow` 结构不变
+- 不新增兼容字段、不增加补丁式映射、不做过度设计
+
+## 3. 现状分析
+
+当前链路如下：
+
+1. 后端列表接口直接返回 `LoanPricingWorkflow`
+2. `LoanPricingWorkflow` 同时包含 `loanRate` 和 `executeRate` 字段
+3. 前端流程列表页列头为“执行利率(%)”
+4. 但该列 `prop` 仍绑定为 `loanRate`
+
+因此，页面展示语义与实际数据源不一致。
+
+## 4. 方案对比
+
+### 方案一：前端列表列直接切换为 `executeRate`
+
+做法：
+
+- 保持列表列头“执行利率(%)”不变
+- 将流程列表页该列绑定从 `loanRate` 改为 `executeRate`
+
+优点：
+
+- 改动最小
+- 数据语义正确
+- 不影响后端接口和数据库结构
+- 符合最短路径实现要求
+
+缺点：
+
+- 无明显缺点，前提是后端实体已正常返回 `executeRate`
+
+### 方案二：后端把 `executeRate` 映射到 `loanRate`
+
+做法：
+
+- 保持前端不变
+- 在后端列表返回前，将执行利率写入 `loanRate`
+
+优点：
+
+- 前端改动更少
+
+缺点：
+
+- 字段语义混乱
+- 容易影响其他使用 `loanRate` 语义的场景
+- 属于补丁式方案，不符合本次约束
+
+### 方案三：新增列表专用 VO
+
+做法：
+
+- 为流程列表单独定义返回对象
+- 新增专门展示字段承载执行利率
+
+优点：
+
+- 语义清晰
+
+缺点：
+
+- 对本次需求明显过度设计
+- 引入额外接口对象和转换逻辑
+
+## 5. 设计结论
+
+采用方案一。
+
+最终实现为：
+
+- 仅修改 `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+- 保持列表列头为“执行利率(%)”
+- 将该列表列的 `prop` 从 `loanRate` 调整为 `executeRate`
+- 让页面直接展示数据库 `loan_pricing_workflow.execute_rate` 的实际值
+
+## 6. 数据链路设计
+
+本次改动后的链路为：
+
+1. 数据库表 `loan_pricing_workflow.execute_rate` 保存执行利率
+2. MyBatis Plus 将该字段映射到实体 `LoanPricingWorkflow.executeRate`
+3. 列表接口 `/loanPricing/workflow/list` 返回 `LoanPricingWorkflow` 集合
+4. 前端流程列表页从 `scope.row.executeRate` 展示执行利率
+
+这样可以保证列表展示内容与数据库实际业务含义一致。
+
+## 7. 边界与非目标
+
+本次不包含以下内容：
+
+- 不修改详情页执行利率展示逻辑
+- 不修改执行利率录入接口
+- 不修改 `loanRate` 字段的业务含义
+- 不修改数据库注释、表结构或初始化 SQL
+- 不新增空值兜底文案或格式化规则
+
+如果某条记录尚未设定执行利率，则列表按当前表格默认行为展示空值。
+
+## 8. 风险与控制
+
+本次风险点只有一个：页面列头与字段绑定不一致。
+
+对应控制方式：
+
+- 明确将流程列表页利率列绑定切换为 `executeRate`
+- 不对后端做语义映射，避免影响其他逻辑
+- 通过源码核对和页面验证确认展示值来源正确
+
+## 9. 验证方案
+
+实施后需要完成以下验证：
+
+1. 查看流程列表页源码，确认列头仍为“执行利率(%)”
+2. 查看流程列表页源码，确认该列 `prop` 为 `executeRate`
+3. 在存在执行利率数据的记录上，确认列表展示值与数据库 `execute_rate` 一致
+4. 确认本次改动未影响列表查询、详情查看和执行利率设定功能
+
+## 10. 实施范围
+
+- 前端：1 个文件
+- 后端：无代码改动
+- 数据库：无改动
+
+本次属于前端展示绑定修正，不涉及接口契约和存储模型变更。

doc/2026-03-28-workflow-execute-rate-display-frontend-plan.md

@@ -0,0 +1,96 @@
+# 流程列表执行利率展示前端实施计划
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan in this repository. Do not use subagents. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 让流程列表页“执行利率(%)”列展示数据库 `execute_rate` 的实际值。
+
+**Architecture:** 本次只调整前端流程列表页的表格列绑定，不改接口、不改后端、不改详情页。通过将列表列的 `prop` 从 `loanRate` 切换为 `executeRate`，直接消费后端实体已返回的执行利率字段。
+
+**Tech Stack:** Vue 2、Element UI、RuoYi 前端工程、npm
+
+---
+
+### Task 1: 修正流程列表页执行利率列绑定
+
+**Files:**
+- Modify: `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+
+- [ ] **Step 1: 查看当前流程列表页执行利率列定义**
+
+Run: `sed -n '40,70p' ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+Expected: 能看到列头为“执行利率(%)”，且当前 `prop="loanRate"`。
+
+- [ ] **Step 2: 将列表列绑定改为 `executeRate`**
+
+将以下代码：
+
+```vue
+<el-table-column label="执行利率(%)" align="center" prop="loanRate" width="100" />
+```
+
+改为：
+
+```vue
+<el-table-column label="执行利率(%)" align="center" prop="executeRate" width="100" />
+```
+
+- [ ] **Step 3: 重新查看源码确认绑定已切换**
+
+Run: `rg -n '执行利率\\(%\\)|prop=\"executeRate\"|prop=\"loanRate\"' ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+Expected: 能看到“执行利率(%)”仍存在，且该列表列绑定为 `prop="executeRate"`，不再出现该列绑定 `loanRate` 的情况。
+
+- [ ] **Step 4: 执行前端构建验证**
+
+Run: `npm --prefix ruoyi-ui run build:prod`
+Expected: 构建成功，输出包含 `Build complete.`
+
+- [ ] **Step 5: 补充本次前端实施记录**
+
+新增或更新实施记录，至少写明：
+
+```markdown
+- 将流程列表页“执行利率(%)”列绑定从 `loanRate` 调整为 `executeRate`
+- 保持列表接口、后端实体和数据库结构不变
+- 验证前端构建通过
+```
+
+建议记录文件：`doc/implementation-report-2026-03-28-workflow-execute-rate-display-frontend.md`
+
+- [ ] **Step 6: 如果为验证启动了前端进程，结束对应进程**
+
+Run: `ps -ef | rg 'ruoyi-ui|vue-cli-service'`
+Expected: 识别本次验证启动的前端进程；如果本次任务启动过前端服务，验证结束后主动停止。
+
+- [ ] **Step 7: 提交前端改动**
+
+Run: `git add ruoyi-ui/src/views/loanPricing/workflow/index.vue doc/implementation-report-2026-03-28-workflow-execute-rate-display-frontend.md && git commit -m "修正流程列表执行利率前端展示"`
+Expected: 生成仅包含本次前端改动的中文提交。
+
+### Task 2: 页面联调确认展示值来源正确
+
+**Files:**
+- Modify: `doc/implementation-report-2026-03-28-workflow-execute-rate-display-frontend.md`
+
+- [ ] **Step 1: 打开流程列表页并确认页面可进入**
+
+Run: 按项目现有方式启动前端后，进入贷款定价流程列表页。
+Expected: 页面正常加载，表格正常渲染。
+
+- [ ] **Step 2: 核对存在执行利率记录的展示结果**
+
+Run: 在页面上选择一条已设定执行利率的数据，与数据库或后端返回进行比对。
+Expected: 列表展示值与 `execute_rate` 一致，而不是 `loan_rate`。
+
+- [ ] **Step 3: 记录联调结果**
+
+将以下结果写入实施记录：
+
+```markdown
+- 已确认流程列表页执行利率列展示的是 `executeRate`
+- 已确认列表页其余查询、查看入口未受影响
+```
+
+- [ ] **Step 4: 停止联调过程中启动的前端进程**
+
+Run: `ps -ef | rg 'ruoyi-ui|vue-cli-service'`
+Expected: 若存在本次联调启动的进程，全部停止后再结束任务。

doc/2026-03-28-workflow-update-time-list-backend-plan.md

@@ -0,0 +1,120 @@
+# 流程列表更新时间展示后端实施计划
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan in this repository. Do not use subagents. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 让流程列表接口返回 `updateTime`，并保持按更新时间倒序排序。
+
+**Architecture:** 后端只调整列表专用 VO 和联表 SQL，让列表展示字段与现有 `ORDER BY lpw.update_time DESC` 对齐。不修改详情页、不改数据库结构、不变更列表其他字段。
+
+**Tech Stack:** Spring Boot、MyBatis Plus、Lombok、Maven、XML Mapper
+
+---
+
+### Task 1: 为列表专用 VO 补充更新时间字段
+
+**Files:**
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVO.java`
+- Test: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVOTest.java`
+
+- [ ] **Step 1: 写失败测试约束 `updateTime` 字段存在**
+
+在 `LoanPricingWorkflowListVOTest` 中新增一个最小测试，例如：
+
+```java
+@Test
+void shouldExposeUpdateTimeField() {
+    LoanPricingWorkflowListVO vo = new LoanPricingWorkflowListVO();
+    Date now = new Date();
+    vo.setUpdateTime(now);
+
+    assertEquals(now, vo.getUpdateTime());
+}
+```
+
+- [ ] **Step 2: 运行测试确认在字段未添加前失败**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false -Dtest=LoanPricingWorkflowListVOTest test`
+Expected: FAIL，提示 `updateTime` 相关 getter/setter 不存在。
+
+- [ ] **Step 3: 在 VO 中新增 `updateTime`**
+
+在 `LoanPricingWorkflowListVO` 中新增：
+
+```java
+private Date updateTime;
+```
+
+- [ ] **Step 4: 重新运行测试确认通过**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false -Dtest=LoanPricingWorkflowListVOTest test`
+Expected: PASS
+
+### Task 2: 让联表 SQL 返回更新时间
+
+**Files:**
+- Modify: `ruoyi-loan-pricing/src/main/resources/mapper/loanpricing/LoanPricingWorkflowMapper.xml`
+- Test: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java`
+
+- [ ] **Step 1: 写失败测试约束列表分页结果透传 `updateTime`**
+
+在 `LoanPricingWorkflowServiceImplTest` 中新增测试，例如：
+
+```java
+@Test
+void shouldReturnPagedWorkflowListWithUpdateTime() {
+    LoanPricingWorkflowListVO row = new LoanPricingWorkflowListVO();
+    Date now = new Date();
+    row.setUpdateTime(now);
+
+    Page<LoanPricingWorkflowListVO> pageResult = new Page<>(1, 10);
+    pageResult.setRecords(List.of(row));
+
+    when(loanPricingWorkflowMapper.selectWorkflowPageWithRates(any(), any())).thenReturn(pageResult);
+
+    IPage<LoanPricingWorkflowListVO> result = loanPricingWorkflowService.selectLoanPricingPage(new Page<>(1, 10), new LoanPricingWorkflow());
+
+    assertEquals(now, result.getRecords().get(0).getUpdateTime());
+}
+```
+
+- [ ] **Step 2: 运行测试确认在 SQL/VO 未对齐前失败**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false -Dtest=LoanPricingWorkflowServiceImplTest test`
+Expected: 若 `updateTime` 尚未补齐，则失败。
+
+- [ ] **Step 3: 在联表 SQL 中新增更新时间返回字段**
+
+在 `LoanPricingWorkflowMapper.xml` 的 `SELECT` 中新增：
+
+```xml
+lpw.update_time AS updateTime
+```
+
+并保留：
+
+```xml
+ORDER BY lpw.update_time DESC
+```
+
+- [ ] **Step 4: 运行服务层测试确认通过**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false -Dtest=LoanPricingWorkflowServiceImplTest test`
+Expected: PASS
+
+- [ ] **Step 5: 运行模块测试确认无回归**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: 模块测试通过。
+
+- [ ] **Step 6: 补充后端实施记录**
+
+Create: `doc/implementation-report-2026-03-28-workflow-update-time-list-backend.md`
+
+至少写明：
+
+```markdown
+- 列表专用 VO 已新增 `updateTime`
+- 联表 SQL 已返回 `lpw.update_time AS updateTime`
+- 列表继续按 `lpw.update_time DESC` 排序
+- 已完成后端模块测试验证
+```

doc/2026-03-28-workflow-update-time-list-design.md

@@ -0,0 +1,164 @@
+# 流程列表更新时间展示设计文档
+
+## 1. 背景
+
+当前流程列表页展示的是“创建时间”，但列表排序语义已经是按 `update_time` 倒序。这会导致页面展示字段与排序依据不一致。
+
+本次需求是将流程列表中的“创建时间”替换为“更新时间”，并保持列表继续按更新时间排序。
+
+## 2. 已确认约束
+
+- 仅调整流程列表页时间列展示
+- 列表中不同时展示创建时间和更新时间
+- 后端列表链路继续按 `update_time` 倒序排序
+- 前端时间列改为展示 `updateTime`
+- 不修改详情页时间展示逻辑
+- 文档和计划统一保存在 `doc` 目录
+
+## 3. 现状分析
+
+当前列表链路情况如下：
+
+1. 前端流程列表页时间列文案为“创建时间”
+2. 前端时间列绑定字段为 `createTime`
+3. 后端列表专用 SQL 已按 `lpw.update_time DESC` 排序
+4. 列表专用 VO 当前仅暴露 `createTime`
+
+因此页面展示与实际排序依据不一致。
+
+## 4. 方案对比
+
+### 方案一：前后端统一切换为更新时间
+
+做法：
+
+- 前端将时间列文案改为“更新时间”
+- 前端字段绑定从 `createTime` 改为 `updateTime`
+- 后端列表专用 VO 增加 `updateTime`
+- 联表 SQL 返回 `lpw.update_time AS updateTime`
+- 排序继续保留 `ORDER BY lpw.update_time DESC`
+
+优点：
+
+- 展示语义与排序语义完全一致
+- 改动范围小
+- 不引入字段语义混乱
+
+缺点：
+
+- 无明显缺点
+
+### 方案二：继续展示创建时间，只补充说明按更新时间排序
+
+做法：
+
+- 保持前端展示 `createTime`
+- 仅在文档或页面认知上说明排序按更新时间进行
+
+优点：
+
+- 改动最少
+
+缺点：
+
+- 不符合“列表中展示更新时间”的需求
+- 页面展示和排序逻辑仍不一致
+
+### 方案三：后端把 `update_time` 映射到 `createTime`
+
+做法：
+
+- 前端继续绑定 `createTime`
+- 后端列表返回时用 `update_time` 填到 `createTime`
+
+优点：
+
+- 前端改动更少
+
+缺点：
+
+- 字段语义错误
+- 后续维护容易误解
+
+## 5. 设计结论
+
+采用方案一。
+
+最终实现为：
+
+- 流程列表页将“创建时间”替换为“更新时间”
+- 时间列字段绑定改为 `updateTime`
+- 后端列表专用 VO 补充 `updateTime`
+- 联表 SQL 返回 `lpw.update_time AS updateTime`
+- 排序继续按 `lpw.update_time DESC`
+
+## 6. 后端设计
+
+### 6.1 返回对象
+
+列表专用返回对象 `LoanPricingWorkflowListVO` 增加：
+
+- `private Date updateTime;`
+
+保留现有字段不变。
+
+### 6.2 SQL 设计
+
+在列表专用 SQL 中：
+
+- 新增 `lpw.update_time AS updateTime`
+- 保持 `ORDER BY lpw.update_time DESC`
+
+不修改当前筛选条件。
+
+## 7. 前端设计
+
+在 `ruoyi-ui/src/views/loanPricing/workflow/index.vue` 中：
+
+- 将时间列文案从“创建时间”改为“更新时间”
+- 将列绑定字段从 `createTime` 改为 `updateTime`
+- 模板中 `parseTime` 的参数改为 `scope.row.updateTime`
+
+页面中只保留这一列，不再显示创建时间。
+
+## 8. 边界与非目标
+
+本次不包含以下内容：
+
+- 不新增双时间列展示
+- 不修改详情页时间展示逻辑
+- 不修改数据库表结构
+- 不调整列表筛选项
+- 不改变分页行为
+
+## 9. 风险与控制
+
+风险点主要有两个：
+
+1. 后端 VO 未补充 `updateTime`，前端会拿不到值
+2. 前端列头改了但仍绑定 `createTime`，会继续展示旧字段
+
+控制方式：
+
+- 同步修改 VO、SQL、前端模板三个位置
+- 保持排序语句不动，只对齐展示字段
+- 通过源码检查、后端测试和前端构建做验证
+
+## 10. 验证方案
+
+实施后需要完成以下验证：
+
+1. 前端列表时间列文案为“更新时间”
+2. 前端列表时间列绑定字段为 `updateTime`
+3. 后端 `LoanPricingWorkflowListVO` 已定义 `updateTime`
+4. 后端联表 SQL 已返回 `lpw.update_time AS updateTime`
+5. 后端模块测试通过
+6. 前端生产构建通过
+
+## 11. 实施范围
+
+- 前端：流程列表页 1 个页面文件
+- 后端：列表 VO 与联表 SQL
+- 数据库：无改动
+
+本次属于列表展示字段与排序语义对齐，不涉及业务流程变更。

doc/2026-03-28-workflow-update-time-list-frontend-plan.md

@@ -0,0 +1,70 @@
+# 流程列表更新时间展示前端实施计划
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan in this repository. Do not use subagents. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 将流程列表页中的“创建时间”替换为“更新时间”并展示 `updateTime`。
+
+**Architecture:** 前端只修改流程列表页时间列文案和字段绑定，不新增双时间列，也不改其他列表列。页面展示字段与后端当前按更新时间排序的语义保持一致。
+
+**Tech Stack:** Vue 2、Element UI、RuoYi 前端工程、npm
+
+---
+
+### Task 1: 替换流程列表时间列为更新时间
+
+**Files:**
+- Modify: `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+
+- [ ] **Step 1: 查看当前时间列实现**
+
+Run: `sed -n '50,70p' ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+Expected: 能看到当前列表存在“创建时间”列，且模板中绑定 `createTime`。
+
+- [ ] **Step 2: 将时间列替换为更新时间**
+
+将以下结构：
+
+```vue
+<el-table-column label="创建时间" align="center" prop="createTime" width="160">
+  <template slot-scope="scope">
+    <span>{{ parseTime(scope.row.createTime) }}</span>
+  </template>
+</el-table-column>
+```
+
+改为：
+
+```vue
+<el-table-column label="更新时间" align="center" prop="updateTime" width="160">
+  <template slot-scope="scope">
+    <span>{{ parseTime(scope.row.updateTime) }}</span>
+  </template>
+</el-table-column>
+```
+
+- [ ] **Step 3: 重新检查源码确认文案和字段绑定**
+
+Run: `rg -n '更新时间|创建时间|prop=\"updateTime\"|prop=\"createTime\"' ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+Expected: 该列表时间列显示为“更新时间”并绑定 `updateTime`。
+
+- [ ] **Step 4: 执行前端构建验证**
+
+Run: `npm --prefix ruoyi-ui run build:prod`
+Expected: 构建成功，输出包含 `Build complete.`
+
+- [ ] **Step 5: 补充前端实施记录**
+
+Create: `doc/implementation-report-2026-03-28-workflow-update-time-list-frontend.md`
+
+至少写明：
+
+```markdown
+- 流程列表页时间列已从“创建时间”替换为“更新时间”
+- 列绑定已从 `createTime` 切换为 `updateTime`
+- 已完成前端构建验证
+```
+
+- [ ] **Step 6: 如果为验证启动了前端进程，结束对应进程**
+
+Run: `ps -ef | rg 'vue-cli-service|ruoyi-ui'`
+Expected: 若本次任务为验证启动了新的前端进程，验证结束后主动停止；对非本次启动的现有进程不做处理。

doc/2026-03-30-loan-pricing-sensitive-data-encryption-design.md

@@ -0,0 +1,341 @@
+# 贷款定价流程客户敏感信息加密改造设计文档
+
+## 1. 背景
+
+贷款定价流程当前对客户名称 `custName`、证件号码 `idNum` 采用明文传输、明文存储、明文展示的方式处理，不满足客户敏感信息安全要求。
+
+本次需求已经明确限定为：
+
+- 仅覆盖贷款定价流程主链
+- 敏感字段仅包含 `custName`、`idNum`
+- `custIsn` 不属于本次敏感字段范围
+- 不改造传输层字段加密
+- 仅要求存储加密、展示脱敏
+- 页面不提供任何明文查看入口
+- 流程查询改为仅允许通过客户内码 `custIsn` 查询
+- 现有存量数据不迁移，直接清空历史流程数据
+- 加密密钥从后端配置文件读取，按当前项目最短路径落地
+
+## 2. 已确认约束
+
+- 仅修改贷款定价流程相关前后端与数据库脚本，不扩散到系统其他模块
+- 不覆盖模型输出表的存储加密治理
+- 详情页模型输出“基本信息”中的 `custName`、`idNum` 必须纳入展示脱敏范围
+- 不新增前端字段级加密协议
+- 不引入外部密钥管理系统
+- 不新增兼容性字段、补丁式逻辑或降级分支
+- 必须保证新流程数据落库为密文
+- 必须保证列表页、详情页始终只展示脱敏值
+- 必须保证模型调用链路仍能拿到业务所需明文
+
+## 3. 现状分析
+
+当前贷款定价流程主链如下：
+
+1. 前端个人/企业建单弹窗提交明文 `custName`、`idNum`
+2. 后端 `LoanPricingWorkflowServiceImpl` 通过 `LoanPricingConverter` 将 DTO 转为 `LoanPricingWorkflow`
+3. `loan_pricing_workflow.cust_name`、`loan_pricing_workflow.id_num` 直接保存明文
+4. 列表页查询 SQL 直接查询 `lpw.cust_name`
+5. 详情页接口直接返回流程实体中的 `custName`、`idNum`
+6. `LoanPricingModelService` 从流程表读取数据后直接组装模型调用 DTO
+
+现状问题有三类：
+
+1. 存储层风险：数据库中存在明文客户名称和证件号码
+2. 展示层风险：前端列表页、详情页直接展示敏感明文
+3. 查询链路风险：当前列表页仍允许按客户名称查询，与密文存储目标冲突
+
+## 4. 方案对比
+
+### 方案一：应用层统一 AES 加解密，返回前统一脱敏
+
+做法：
+
+- 在后端新增贷款定价专用敏感字段加解密组件
+- 创建流程时对 `custName`、`idNum` 加密后再落库
+- 查询详情、模型调用前在服务内部解密
+- 返回前端前统一转成脱敏值
+- 前端仅负责调整查询条件和展示，不做加解密
+
+优点：
+
+- 改动集中，符合最短路径实现
+- 与数据库实现解耦，不绑定数据库方言
+- 业务边界清晰，易于控制哪些链路允许拿明文
+- 便于测试和排查
+
+缺点：
+
+- 需要明确服务内部解密和对外脱敏的边界，避免遗漏
+
+### 方案二：MyBatis TypeHandler 自动加解密
+
+做法：
+
+- 为实体敏感字段挂载统一的 TypeHandler
+- 插入自动加密、查询自动解密
+- 返回前再补充脱敏
+
+优点：
+
+- 业务代码表面改动更少
+
+缺点：
+
+- 链路不直观，联表 SQL、VO 查询、模型调用等位置容易出现加解密边界不清
+- 调试复杂度高，不符合本次最短路径目标
+
+### 方案三：数据库函数处理加解密
+
+做法：
+
+- 在 SQL 中直接调用数据库加解密函数
+- 应用层只负责脱敏
+
+优点：
+
+- 应用层代码改动相对少
+
+缺点：
+
+- 强依赖数据库能力
+- 维护成本高
+- 联表与分页查询复杂度上升
+- 不符合本次直接、清晰的实现要求
+
+## 5. 设计结论
+
+采用方案一：应用层统一 AES 加解密，返回前统一脱敏。
+
+最终设计原则如下：
+
+- `loan_pricing_workflow.cust_name`、`loan_pricing_workflow.id_num` 仅保存密文
+- 服务内部按需短暂解密，仅供业务处理和模型调用使用
+- 面向前端返回时，`custName`、`idNum` 永远转换为脱敏值
+- 列表查询去掉客户名称条件，只保留客户内码等非敏感查询项
+- 存量流程数据通过清空历史数据处理，不做迁移兼容
+
+## 6. 架构设计
+
+本次在贷款定价流程模块内新增两类职责：
+
+### 6.1 敏感字段加解密服务
+
+新增贷款定价专用组件 `SensitiveFieldCryptoService`，负责：
+
+- 从后端配置文件读取 AES 密钥
+- 对 `custName`、`idNum` 执行加密
+- 对已落库密文执行解密
+- 在密钥缺失或解密失败时抛出明确异常
+
+该组件只处理加密和解密，不参与脱敏展示逻辑。
+
+### 6.2 敏感字段展示服务
+
+新增贷款定价专用组件 `LoanPricingSensitiveDisplayService`，负责：
+
+- 对客户名称进行脱敏
+- 对证件号码进行脱敏
+- 对流程详情对象和列表对象中的敏感字段做统一替换
+
+该组件不依赖当前系统管理员免脱敏逻辑，严格执行全员脱敏规则。
+
+## 7. 数据链路设计
+
+### 7.1 创建流程链路
+
+1. 前端建单弹窗提交明文 `custName`、`idNum`
+2. 后端 DTO 转实体后，在 `createLoanPricing` 入库前统一加密
+3. `loan_pricing_workflow` 表保存密文
+4. 创建成功后后续流程继续使用同一主记录
+
+### 7.2 列表查询链路
+
+1. 前端列表页移除客户名称搜索项，新增或保留客户内码查询
+2. 后端分页查询不再按 `custName` 过滤
+3. 列表 SQL 仍查询 `cust_name` 字段，但查询结果为密文
+4. 服务返回前将列表 VO 中 `custName` 转为脱敏值
+5. 前端直接展示后端返回的脱敏结果
+
+### 7.3 详情查询链路
+
+1. 后端根据流水号查询流程记录，拿到密文 `custName`、`idNum`
+2. 服务内部先解密得到业务所需明文
+3. 若需要组装详情对象或进行后续处理，使用解密后的值
+4. 返回前调用展示服务，将 `custName`、`idNum` 替换为脱敏值
+5. 前端详情页只展示脱敏内容
+
+### 7.4 模型调用链路
+
+1. `LoanPricingModelService` 根据流程主键读取流程记录
+2. 读取到的 `custName`、`idNum` 为密文
+3. 调用模型前先在服务内部解密
+4. 将解密后的明文复制到 `ModelInvokeDTO`
+5. 模型调用完成后，模型输出链路保持现状，不纳入本次改造
+
+### 7.5 模型输出展示链路
+
+1. 详情接口查询到 `ModelRetailOutputFields` 或 `ModelCorpOutputFields`
+2. 模型输出实体中的 `custName`、`idNum` 保持当前存储方式，不做表级加密改造
+3. 在详情接口返回前，对模型输出“基本信息”中的 `custName`、`idNum` 做统一脱敏
+4. 前端 `ModelOutputDisplay` 组件直接展示后端返回的脱敏值
+5. 不提供模型输出基本信息的明文查看入口
+
+## 8. 后端改造设计
+
+### 8.1 配置项
+
+后端新增贷款定价敏感字段加密配置项，例如：
+
+- 是否启用敏感字段加解密
+- AES 密钥
+
+本次仅要求配置文件读取固定密钥，不扩展到数据库参数表或外部密钥系统。
+
+### 8.2 服务层改造
+
+需要修改以下关键点：
+
+1. `LoanPricingWorkflowServiceImpl#createLoanPricing`
+   在 `loanPricingWorkflowMapper.insert` 前统一加密 `custName`、`idNum`
+
+2. `LoanPricingWorkflowServiceImpl#selectLoanPricingBySerialNum`
+   查询详情后先解密，再在返回前脱敏
+
+3. `LoanPricingWorkflowServiceImpl#selectLoanPricingPage`
+   分页结果中的 `custName` 统一转为脱敏值
+
+4. `LoanPricingWorkflowServiceImpl#buildQueryWrapper`
+   删除 `custName` 查询条件，改为仅支持 `custIsn`、创建者、机构号等非敏感字段
+
+5. `LoanPricingModelService#invokeModelAsync`
+   模型调用前解密 `custName`、`idNum`，确保模型收到明文业务数据
+
+6. `LoanPricingWorkflowServiceImpl#selectLoanPricingBySerialNum`
+   在组装 `ModelRetailOutputFields`、`ModelCorpOutputFields` 返回值时，对其 `custName`、`idNum` 进行脱敏替换
+
+### 8.3 对象边界
+
+本次不新增明文返回字段，也不保留“密文字段 + 展示字段”双轨结构，避免对象语义膨胀。
+
+返回前对象中的敏感字段直接替换为脱敏值，确保控制器和前端都不会拿到明文。
+
+## 9. 前端改造设计
+
+### 9.1 列表页
+
+修改 `ruoyi-ui/src/views/loanPricing/workflow/index.vue`：
+
+- 移除“客户名称”查询项
+- 改为支持客户内码查询
+- 表格中 `custName` 继续展示，但其值来自后端脱敏结果
+
+### 9.2 详情页
+
+修改个人与企业详情组件：
+
+- 保持字段布局不变
+- `custName`、`idNum` 直接展示后端返回的脱敏值
+- 不新增“查看明文”“复制原值”等交互入口
+- 模型输出组件 `ModelOutputDisplay.vue` 的“基本信息”页签继续直接消费后端字段，但要求后端返回值已完成脱敏
+
+### 9.3 建单页
+
+个人和企业建单弹窗仍然录入明文 `custName`、`idNum`，不新增前端字段加密逻辑。
+
+## 10. 数据库处理设计
+
+本次数据库处理遵循最短路径：
+
+1. 不修改 `loan_pricing_workflow` 表结构
+2. 不新增密文字段、副本字段或检索字段
+3. 实施前执行历史流程数据清空脚本
+4. 清空范围仅限贷款定价流程相关存量数据
+
+因为 `custName`、`idNum` 不再承担查询职责，所以现有字段直接存密文即可。
+
+## 11. 错误处理设计
+
+本次不做兼容性补丁逻辑，错误直接失败：
+
+1. 加密配置缺失
+   创建流程直接失败，不允许明文落库
+
+2. 解密失败
+   详情查询失败，模型调用失败，并记录明确错误日志
+
+3. 历史脏数据
+   通过清空存量数据消除，不增加“密文/明文混读”兼容判断
+
+4. 前端展示
+   前端只消费后端结果，不承担兜底脱敏职责
+
+## 12. 测试与验收设计
+
+### 12.1 后端验收
+
+1. 创建个人贷款定价流程，校验数据库 `cust_name`、`id_num` 为密文
+2. 创建企业贷款定价流程，校验数据库 `cust_name`、`id_num` 为密文
+3. 列表查询仅支持通过 `custIsn` 命中
+4. 列表返回中的 `custName` 为脱敏值
+5. 详情返回中的 `custName`、`idNum` 为脱敏值
+6. 模型输出“基本信息”中的 `custName`、`idNum` 返回为脱敏值
+7. 模型调用链路成功，证明服务内部解密逻辑成立
+8. 配置缺失时创建流程失败，确认不会明文入库
+
+### 12.2 前端验收
+
+1. 列表页查询项已移除客户名称，改为客户内码
+2. 列表页客户名称展示为脱敏值
+3. 个人详情页客户名称、证件号码展示为脱敏值
+4. 企业详情页客户名称、证件号码展示为脱敏值
+5. 个人模型输出“基本信息”页签中的客户名称、证件号码展示为脱敏值
+6. 企业模型输出“基本信息”页签中的客户名称、证件号码展示为脱敏值
+7. 创建流程、查看详情、设定执行利率等既有功能不受影响
+
+## 13. 风险与控制
+
+### 风险一：模型调用读取到密文
+
+控制方式：
+
+- 在 `LoanPricingModelService` 调用模型前显式解密
+- 用测试覆盖模型调用前数据组装逻辑
+
+### 风险二：返回链路遗漏脱敏
+
+控制方式：
+
+- 统一在服务层返回前调用展示服务
+- 列表 VO 与详情 VO 都纳入测试覆盖
+
+### 风险三：历史明文和新密文混杂
+
+控制方式：
+
+- 实施前清空贷款定价流程历史数据
+- 不保留兼容读取分支
+
+## 14. 范围与非目标
+
+本次包含：
+
+- 贷款定价流程建单入库加密
+- 贷款定价流程列表和详情展示脱敏
+- 贷款定价流程详情页中的模型输出“基本信息”展示脱敏
+- 贷款定价流程查询条件收口为客户内码
+- 贷款定价流程存量数据清空处理
+
+本次不包含：
+
+- 模型输出表存储加密改造
+- 系统其他模块的敏感字段改造
+- 前后端传输层字段加密
+- 密钥托管平台接入
+- 基于角色的明文查看权限
+
+## 15. 设计结论
+
+本次采用“应用层统一 AES 加解密 + 返回前统一脱敏”的方式，对贷款定价流程中的 `custName`、`idNum` 完成存储加密和展示脱敏改造。
+
+该方案满足当前客户安全要求，并保持实现路径最短、责任边界清晰、业务链路闭环完整。

doc/implementation-report-2026-03-28-backend-mysql8-config.md

@@ -0,0 +1,20 @@
+# 后端 MySQL 8.0 配置实施记录
+
+## 本次改动
+
+- 调整 `ruoyi-admin/src/main/resources/application-dev.yml` 的主库 JDBC 配置
+- 后端继续连接 `116.62.17.81:3307/loan-pricing`
+- 将连接编码从 `utf8` 调整为 `utf8mb4`
+- 增加 `connectionCollation=utf8mb4_general_ci`
+
+## 修改原因
+
+- 当前后端已切换到 MySQL 8.0 实例 `116.62.17.81:3307`
+- 当前数据库 `loan-pricing` 已统一为 `utf8mb4_general_ci`
+- JDBC 连接参数需要与数据库字符集和排序规则保持一致，避免连接层与库层配置不一致
+
+## 验证方式
+
+- 检查 `application-dev.yml` 中 JDBC URL 已指向 `116.62.17.81:3307/loan-pricing`
+- 检查 JDBC URL 已包含 `characterEncoding=utf8mb4`
+- 检查 JDBC URL 已包含 `connectionCollation=utf8mb4_general_ci`

doc/implementation-report-2026-03-28-chinese-data-repair.md

@@ -0,0 +1,46 @@
+# 中文数据修复实施记录
+
+## 问题现象
+
+- 目标库 `116.62.17.81:3307/loan-pricing` 中系统菜单、角色、用户昵称等中文字段显示为 `?`
+
+## 根因结论
+
+- 源库 `116.62.17.81:3306/loan-pricing` 中中文数据实际是正确的 UTF-8 字节
+- 通过 `SET NAMES utf8mb4` 读取源库时，可以正确得到中文内容
+- 之前生成的 `sql/loan_pricing_required_data_20260328.sql` 由 `mysqldump` 产出，文件中的中文已经被导出成问号
+- 目标库乱码不是 collation 调整导致，而是导入了这份已损坏的数据 SQL
+
+## 本次修复
+
+- 放弃使用已损坏的 `mysqldump` 数据文件
+- 直接从源库 `3306` 以 `utf8mb4` 正确读取 17 张必要数据表
+- 将这 17 张表重新覆盖写入目标库 `3307`
+- 重新生成 `sql/loan_pricing_required_data_20260328.sql`，确保文件内中文内容为正常 UTF-8
+
+## 修复范围
+
+- `loan_pricing_workflow`
+- `model_corp_output_fields`
+- `model_retail_output_fields`
+- `sys_config`
+- `sys_dept`
+- `sys_dict_data`
+- `sys_dict_type`
+- `sys_job`
+- `sys_menu`
+- `sys_notice`
+- `sys_post`
+- `sys_role`
+- `sys_role_dept`
+- `sys_role_menu`
+- `sys_user`
+- `sys_user_post`
+- `sys_user_role`
+
+## 验证结果
+
+- 目标库 `sys_user.nick_name` 已恢复为 `若依`、`测试管理员`
+- 目标库 `sys_role.role_name` 已恢复为 `超级管理员`、`普通角色`、`管理员`
+- 目标库 `sys_menu.menu_name` 已恢复为 `系统管理`、`利率定价管理`、`流程列表`
+- 重新生成的 `sql/loan_pricing_required_data_20260328.sql` 中已包含 `管理员`、`若依`、`系统管理`、`用户管理`、`利率定价管理`

doc/implementation-report-2026-03-28-collation-unification.md

@@ -0,0 +1,30 @@
+# loan-pricing collation 统一实施记录
+
+## 本次改动
+
+- 将目标数据库 `116.62.17.81:3307/loan-pricing` 的数据库默认排序规则调整为 `utf8mb4_general_ci`
+- 将目标数据库全部 33 张表的表级默认排序规则统一为 `utf8mb4_general_ci`
+- 修改以下建库和建表脚本，统一默认排序规则为 `utf8mb4_general_ci`
+  - `sql/loan_pricing_schema_20260328.sql`
+  - `sql/loan_pricing_workflow.sql`
+  - `sql/model_corp.sql`
+  - `sql/model_retail.sql`
+
+## 执行方式
+
+1. 执行 `ALTER DATABASE \`loan-pricing\` CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci`
+2. 对全部现有表执行 `ALTER TABLE ... DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci`
+3. 将脚本中的 `DEFAULT CHARSET=utf8mb4` 统一补齐为 `DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci`
+4. 将脚本中遗留的 `utf8mb4_unicode_ci` 替换为 `utf8mb4_general_ci`
+
+## 说明
+
+- Quartz 相关表存在外键约束，直接执行 `CONVERT TO CHARACTER SET` 会触发外键列兼容性错误
+- 因此数据库侧采用“统一数据库默认排序规则 + 统一表级默认排序规则”的方式完成所有表的 collation 统一
+- 业务建表脚本已同步为 `utf8mb4_general_ci`，后续重建库时不会再回落到其他 collation
+
+## 验证目标
+
+- 数据库默认排序规则为 `utf8mb4_general_ci`
+- 所有表的 `TABLE_COLLATION` 为 `utf8mb4_general_ci`
+- 脚本中不再出现 `utf8mb4_unicode_ci`

doc/implementation-report-2026-03-28-db-migration.md

@@ -0,0 +1,70 @@
+# loan-pricing 数据库迁移实施记录
+
+## 本次改动
+
+- 生成全量表结构 SQL: `sql/loan_pricing_schema_20260328.sql`
+- 生成必要数据批量插入 SQL: `sql/loan_pricing_required_data_20260328.sql`
+- 将开发环境数据库连接从 `116.62.17.81:3306` 调整为 `116.62.17.81:3307`
+
+## 表结构 SQL 范围
+
+- 覆盖 `loan-pricing` 库当前全部表结构
+- 包含业务表、系统表、Quartz 表、代码生成相关表
+
+## 必要数据 SQL 范围
+
+- 业务关键表:
+  - `loan_pricing_workflow`
+  - `model_corp_output_fields`
+  - `model_retail_output_fields`
+- 系统初始化表:
+  - `sys_config`
+  - `sys_dept`
+  - `sys_dict_type`
+  - `sys_dict_data`
+  - `sys_job`
+  - `sys_menu`
+  - `sys_notice`
+  - `sys_post`
+  - `sys_role`
+  - `sys_role_dept`
+  - `sys_role_menu`
+  - `sys_user`
+  - `sys_user_post`
+  - `sys_user_role`
+
+## 未纳入必要数据的表
+
+- 日志类表:
+  - `sys_job_log`
+  - `sys_logininfor`
+  - `sys_oper_log`
+- Quartz 运行态表:
+  - `QRTZ_BLOB_TRIGGERS`
+  - `QRTZ_CALENDARS`
+  - `QRTZ_CRON_TRIGGERS`
+  - `QRTZ_FIRED_TRIGGERS`
+  - `QRTZ_JOB_DETAILS`
+  - `QRTZ_LOCKS`
+  - `QRTZ_PAUSED_TRIGGER_GRPS`
+  - `QRTZ_SCHEDULER_STATE`
+  - `QRTZ_SIMPLE_TRIGGERS`
+  - `QRTZ_SIMPROP_TRIGGERS`
+  - `QRTZ_TRIGGERS`
+- 空表:
+  - `gen_table`
+  - `gen_table_column`
+
+## 迁移建议
+
+1. 在目标实例 `116.62.17.81:3307` 创建数据库 `loan-pricing`
+2. 执行 `sql/loan_pricing_schema_20260328.sql`
+3. 执行 `sql/loan_pricing_required_data_20260328.sql`
+4. 启动项目并验证后台登录、字典加载、利率定价流程页面和任务配置
+
+## 验证记录
+
+- 使用 `mysqldump --no-data` 导出了全部表结构
+- 使用 `mysqldump --no-create-info --complete-insert --extended-insert` 导出了必要数据
+- 已更新 `ruoyi-admin/src/main/resources/application-dev.yml` 中的主库连接地址
+- 已在 `116.62.17.81:3307` 实际执行表结构导入和必要数据导入

doc/implementation-report-2026-03-28-design-doc-path-fix.md

@@ -0,0 +1,18 @@
+# 设计文档保存路径修正实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 将流程列表执行利率展示设计文档从错误的 `docs/superpowers/specs` 路径迁移到 `doc` 目录
+- 同步更新设计阶段实施记录中的文档路径描述
+- 删除放错位置的设计文档副本
+
+## 文档路径
+- `doc/2026-03-28-workflow-execute-rate-display-design.md`
+- `doc/implementation-report-2026-03-28-workflow-execute-rate-display-design.md`
+- `doc/implementation-report-2026-03-28-design-doc-path-fix.md`
+
+## 说明
+- 按仓库要求，设计文档统一保存在 `doc` 目录
+- 本次修正不涉及业务代码和接口逻辑调整

doc/implementation-report-2026-03-28-remove-redis-backend.md

@@ -0,0 +1,36 @@
+# 后端移除 Redis 实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 为 `ruoyi-common` 增加 `spring-boot-starter-test` 测试依赖
+- 新增 `InMemoryCacheStoreTest` 作为本地缓存基础设施的失败测试基线
+- 新增 `InMemoryCacheEntry`、`InMemoryCacheStats`、`InMemoryCacheStore` 实现本地缓存基础能力
+- 将 `RedisCache` 改为基于进程内缓存的统一门面，补充 TTL、前缀检索、批量删除、递增和统计能力
+- 移除 `spring-boot-starter-data-redis`、`commons-pool2` 和后端 Redis 专属配置类
+- 保持认证、验证码、密码错误次数、防重提交、在线用户扫描继续依赖 `RedisCache` 抽象
+- 将限流实现改为本地窗口计数，将缓存监控改为本地统计视图
+- 修正 `DictUtils` 读取字典缓存时对本地 `List<SysDictData>` 的兼容
+- 删除 `application-dev.yml` 中的 Redis 开发配置
+- 补充 `RedisCacheTest`、`DictUtilsTest`、`RateLimiterAspectTest`、`TokenServiceLocalCacheTest`、`CacheControllerTest`
+
+## 文档路径
+- `doc/2026-03-28-remove-redis-backend-plan.md`
+- `doc/implementation-report-2026-03-28-remove-redis-backend.md`
+
+## 验证结果
+- 已验证 `mvn -pl ruoyi-common -am -Dtest=InMemoryCacheStoreTest test` 通过
+- 已验证 `mvn -pl ruoyi-common,ruoyi-framework -am test` 通过
+- 已验证 `mvn -pl ruoyi-framework -am test` 通过
+- 已验证 `mvn -pl ruoyi-framework,ruoyi-admin -am test` 通过
+- 已验证 `mvn test` 通过
+- 已验证 `mvn -pl ruoyi-admin -am package -DskipTests` 通过并生成可运行包
+- 已验证应用以 `java -jar target/ruoyi-admin.jar --server.port=18080` 成功启动，日志中未出现 Redis 初始化失败
+- 已手工验证 `/captchaImage`、`/login/test`、`/getInfo`、`/monitor/online/list`、`/monitor/cache`、`/monitor/cache/getNames`、`/monitor/cache/getKeys/login_tokens:`、`/system/config/refreshCache`、`/system/dict/type/refreshCache` 可正常返回
+- 已手工验证验证码缓存前缀清理成功，在线用户强退后原 token 再访问在线列表返回 `401`
+
+## 说明
+- 启动校验时仓库根目录直接执行 `mvn -pl ruoyi-admin -am spring-boot:run` 会落到聚合 `pom`，因此改为先本地打包再使用 `java -jar` 启动
+- 首次以 `8080` 启动时因本机端口占用失败，改用 `18080` 后启动成功；该问题与 Redis 移除无关
+- 测试和手工验证结束后，已主动停止本次任务拉起的 Java 进程

doc/implementation-report-2026-03-28-remove-redis-design.md

@@ -0,0 +1,20 @@
+# 移除 Redis 设计阶段实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 新增 Redis 移除设计文档，明确单实例下以进程内缓存替代 Redis 的总体方案
+- 梳理并记录登录态、验证码、登录失败次数、防重提交、限流、配置缓存、字典缓存、在线用户、缓存监控等兼容要求
+- 明确后续需拆分输出前端与后端两份实施计划
+
+## 文档路径
+- `doc/2026-03-28-remove-redis-design.md`
+
+## 结果
+- 当前已形成可评审的正式设计文档
+- 设计范围、约束、验收标准和边界已固定
+
+## 说明
+- 按仓库要求，本次文档改动同步补充实施记录
+- 仓库中声明了 OpenSpec 指引，但当前未找到 `openspec/AGENTS.md` 文件，因此本次按现有仓库文档规范落盘

doc/implementation-report-2026-03-28-remove-redis-frontend.md

@@ -0,0 +1,27 @@
+# 前端移除 Redis 实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 将缓存概览页从 Redis 专属字段改为本地缓存统计字段展示
+- 将第二张图表改为本地缓存统计柱状图，并保留原有页面布局
+- 为缓存概览页补充空数据保护、命中率计算和监控采样时间展示
+- 为缓存列表页补充空列表兜底、清理后的详情重置和全部清理后的界面清空
+- 复核缓存监控 API 路径不变，仅调整接口注释为缓存语义
+
+## 文档路径
+- `doc/2026-03-28-remove-redis-frontend-plan.md`
+- `doc/implementation-report-2026-03-28-remove-redis-frontend.md`
+
+## 验证结果
+- 已两次验证 `npm --prefix ruoyi-ui run build:prod` 通过，输出为 `Build complete.`
+- 已验证 `npm --prefix ruoyi-ui run dev` 可成功启动，前端开发服务地址为 `http://localhost:1025`
+- 已在浏览器中完成登录并打开 `/monitor/cache`、`/monitor/cacheList` 路由，确认页面可正常进入
+- 当前环境下真实接口 `/dev-api/monitor/cache`、`/dev-api/monitor/cache/getNames`、`/dev-api/monitor/cache/getKeys/*` 请求均出现 10 秒超时，未能完成真实后端联调
+- 已使用与后端实现一致的返回结构进行浏览器侧 mock 验证，确认缓存概览字段映射、图表渲染、缓存名称到键名联动、缓存内容展示以及清理后表单清空行为正常
+
+## 说明
+- 按仓库要求，本次前端开发直接在当前分支进行，未使用 `git worktree`
+- 计划明确不引入新的前端测试框架，因此本次以前端生产构建与本地联调作为主要验证手段
+- 联调与验证结束后，已主动停止本次任务启动的 Node 前端进程

doc/implementation-report-2026-03-28-remove-redis-plans.md

@@ -0,0 +1,23 @@
+# 移除 Redis 实施计划文档记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 基于设计文档新增后端实施计划
+- 基于设计文档新增前端实施计划
+- 明确后端本地缓存替换、认证链路、限流、缓存监控、配置清理的实施顺序
+- 明确前端缓存监控页面的最小改动范围与联调验证方式
+
+## 文档路径
+- `doc/2026-03-28-remove-redis-backend-plan.md`
+- `doc/2026-03-28-remove-redis-frontend-plan.md`
+
+## 结果
+- 当前已具备可执行的后端实施计划文档
+- 当前已具备可执行的前端实施计划文档
+- 两份计划均延续“最短路径、功能不变、无 Redis 依赖”的设计结论
+
+## 说明
+- 按仓库要求，计划文档统一放在 `doc/` 目录
+- 本次未开启 subagent，计划评审环节按项目约束跳过

doc/implementation-report-2026-03-28-remove-spec-workflow.md

@@ -0,0 +1,19 @@
+# 规范流程移除实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 删除仓库根目录 `AGENTS.md` 中的规范流程指令块
+- 删除 `CLAUDE.md` 中的规范流程指令块与工作流说明
+- 清理 `.claude/settings.json` 与 `.claude/settings.local.json` 中的相关权限和技能配置
+- 删除 `.claude/commands/` 下的相关命令文件
+- 删除 `.claude/agents/kfc/` 下的专用 agent 文件
+- 删除 `.claude/system-prompts/spec-workflow-starter.md`
+
+## 结果
+- 当前仓库已不再包含该规范流程入口
+- 保留了非该流程的 Claude 配置与现有开发权限
+
+## 验证方式
+- 执行全文检索，确认仓库内已无相关引用（排除 `node_modules`）

doc/implementation-report-2026-03-28-restart-java-backend.md

@@ -0,0 +1,22 @@
+# restart_java_backend.sh 实施记录
+
+## 本次改动
+
+- 调整 `bin/restart_java_backend.sh` 中的后端监听端口，从旧的 `62318` 改为当前项目 `ruoyi-admin` 在 `dev` 环境下实际使用的 `8080`
+
+## 修改原因
+
+- 当前项目后端默认启动配置位于 `ruoyi-admin/src/main/resources/application-dev.yml`
+- 该配置的 `server.port` 为 `8080`
+- 原脚本继续使用旧端口会导致 `status`、`stop`、`restart` 无法准确识别当前正在运行的 Java 后端进程
+
+## 影响说明
+
+- `collect_pids` 现在会基于正确端口识别后端监听进程
+- `start` 前的运行态判断会更准确
+- `stop` 和 `restart` 会正确处理当前项目启动出的后端服务
+
+## 验证方式
+
+- 执行 `sh -n bin/restart_java_backend.sh` 校验脚本语法
+- 执行 `bin/restart_java_backend.sh status` 验证脚本可正常读取当前后端状态

doc/implementation-report-2026-03-28-workflow-calculate-rate-list-backend.md

@@ -0,0 +1,41 @@
+# 流程列表测算利率展示后端实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 新增流程列表专用返回对象 `LoanPricingWorkflowListVO`
+- 将流程列表分页返回从 `LoanPricingWorkflow` 调整为列表专用 VO
+- 在 Mapper 中新增联表分页方法 `selectWorkflowPageWithRates`
+- 新增 `LoanPricingWorkflowMapper.xml`，通过联表 SQL 一次返回 `calculateRate` 与 `executeRate`
+- 保留现有详情页测算利率兼容逻辑，不回退工作区中已有的详情链路调整
+
+## 关键链路
+- 主表：`loan_pricing_workflow`
+- 个人客户测算利率来源：`model_retail_output_fields.calculate_rate`
+- 企业客户测算利率来源：`model_corp_output_fields.calculate_rate`
+- 统一返回字段：`calculateRate`
+
+## 修改文件
+- `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVO.java`
+- `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/mapper/LoanPricingWorkflowMapper.java`
+- `ruoyi-loan-pricing/src/main/resources/mapper/loanpricing/LoanPricingWorkflowMapper.xml`
+- `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/ILoanPricingWorkflowService.java`
+- `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/controller/LoanPricingWorkflowController.java`
+- `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java`
+- `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVOTest.java`
+- `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java`
+
+## 验证结果
+- 已执行 `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false -Dtest=LoanPricingWorkflowServiceImplTest test`
+- 结果为 `Tests run: 3, Failures: 0, Errors: 0, Skipped: 0`
+- 已执行 `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false test`
+- 模块验证结果为 `Tests run: 4, Failures: 0, Errors: 0, Skipped: 0`
+- 已确认列表分页链路改为返回 `LoanPricingWorkflowListVO`
+- 已确认服务层会透传 `calculateRate`
+
+## 说明
+- 本次未修改数据库表结构，也未将测算利率回写到 `loan_pricing_workflow`
+- 单独执行 `-pl ruoyi-loan-pricing` 时会命中旧的上游构件，因此测试命令需带 `-am`
+- 本次未为验证额外启动新的后端进程
+- 本次未执行真实后端启动后的接口联调，请以后端模块测试结果作为本次主要验证依据

doc/implementation-report-2026-03-28-workflow-calculate-rate-list-design.md

@@ -0,0 +1,24 @@
+# 流程列表测算利率展示设计实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 新增流程列表测算利率展示设计文档
+- 明确流程列表页新增“测算利率(%)”列
+- 明确后端采用联表 SQL，一次查询流程表和模型输出表
+- 明确测算利率不回写到 `loan_pricing_workflow`
+
+## 文档路径
+- `doc/2026-03-28-workflow-calculate-rate-list-design.md`
+- `doc/implementation-report-2026-03-28-workflow-calculate-rate-list-design.md`
+
+## 设计结论
+- 流程列表页新增“测算利率(%)”列，默认放在“执行利率(%)”前面
+- 后端列表接口通过联表 SQL 统一返回 `calculateRate`
+- 个人客户取 `model_retail_output_fields.calculate_rate`
+- 企业客户取 `model_corp_output_fields.calculate_rate`
+
+## 说明
+- 按仓库要求，本次先完成设计确认，再进入前后端实施计划
+- 仓库约束禁止启用 subagent，因此本次未执行基于 subagent 的设计文档复审流程

doc/implementation-report-2026-03-28-workflow-calculate-rate-list-frontend.md

@@ -0,0 +1,30 @@
+# 流程列表测算利率展示前端实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 在流程列表页新增“测算利率(%)”列
+- 新增列绑定后端返回字段 `calculateRate`
+- 保持“执行利率(%)”列继续绑定 `executeRate`
+- 保持“测算利率(%)”列位于“执行利率(%)”列之前
+
+## 修改文件
+- `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+- `doc/implementation-report-2026-03-28-workflow-calculate-rate-list-frontend.md`
+
+## 验证方式
+1. 通过源码检查确认“测算利率(%)”列已新增
+2. 通过源码检查确认“测算利率(%)”列位于“执行利率(%)”之前
+3. 执行前端生产构建验证页面代码可正常打包
+
+## 验证结果
+- 已新增“测算利率(%)”列，绑定字段为 `calculateRate`
+- 已保留“执行利率(%)”列，绑定字段为 `executeRate`
+- 已确认“测算利率(%)”列位于“执行利率(%)”列之前
+- 已执行 `npm --prefix ruoyi-ui run build:prod`，构建成功，输出包含 `Build complete.`
+- 本次构建过程中仅出现项目原有的打包体积 warning，未出现新的构建错误
+
+## 说明
+- 本次只调整流程列表页，不改详情页展示逻辑
+- 本次未为验证额外启动新的前端进程

doc/implementation-report-2026-03-28-workflow-calculate-rate-list-plans.md

@@ -0,0 +1,25 @@
+# 流程列表测算利率展示实施计划产出记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 基于设计文档补充前端实施计划
+- 基于设计文档补充后端实施计划
+- 明确本次需求采用联表 SQL 方案，一次返回流程列表测算利率与执行利率
+
+## 文档路径
+- `doc/2026-03-28-workflow-calculate-rate-list-design.md`
+- `doc/2026-03-28-workflow-calculate-rate-list-frontend-plan.md`
+- `doc/2026-03-28-workflow-calculate-rate-list-backend-plan.md`
+- `doc/implementation-report-2026-03-28-workflow-calculate-rate-list-plans.md`
+
+## 计划结论
+- 前端计划只修改流程列表页 `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+- 前端新增“测算利率(%)”列，绑定后端返回字段 `calculateRate`
+- 后端计划新增列表专用 VO 与 Mapper XML，使用联表 SQL 一次返回 `calculateRate` 和 `executeRate`
+- 两份计划都要求验证结束后关闭本次任务启动的前后端进程
+
+## 说明
+- 按仓库要求，设计文档和实施计划均保存在 `doc` 目录
+- 仓库约束禁止启用 subagent，因此本次未执行基于 subagent 的计划文档复审流程

doc/implementation-report-2026-03-28-workflow-detail-calculate-rate-model-output.md

@@ -0,0 +1,37 @@
+# 流程详情测算利率改为模型输出表取数实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 问题说明
+- 流程详情接口返回的 `loanPricingWorkflow.loanRate` 仍保留流程主表中的值
+- 当模型输出表中的 `calculateRate` 与流程主表中的 `loanRate` 不一致时，详情链路无法保证“测算利率”按模型输出表口径返回
+
+## 本次修改
+- 在 `LoanPricingWorkflowServiceImpl#selectLoanPricingBySerialNum` 中补充详情组装逻辑
+- 个人客户详情查询时，将 `model_retail_output_fields.calculate_rate` 回填到 `loanPricingWorkflow.loanRate`
+- 企业客户详情查询时，将 `model_corp_output_fields.calculate_rate` 回填到 `loanPricingWorkflow.loanRate`
+- 新增服务层单元测试，覆盖个人、企业两条详情查询分支
+- 为 `ruoyi-loan-pricing` 模块补充测试依赖 `spring-boot-starter-test`
+
+## 影响范围
+- 仅影响流程详情接口 `/loanPricing/workflow/{serialNum}` 的返回值组装
+- 不修改数据库表结构
+- 不修改模型输出表写入逻辑
+- 不修改流程列表接口
+
+## 验证方式
+1. 新增 `LoanPricingWorkflowServiceImplTest`
+2. 先执行失败用例，确认详情返回的 `loanRate` 未按模型输出表取值
+3. 修复详情组装逻辑后重新执行测试
+
+## 验证结果
+- 执行命令：
+```bash
+mvn -pl ruoyi-loan-pricing -am -Dtest=LoanPricingWorkflowServiceImplTest -Dsurefire.failIfNoSpecifiedTests=false test
+```
+- 结果：2 个测试全部通过
+
+## 备注
+- 验证时发现仅编译 `ruoyi-loan-pricing` 模块会引用到本地旧版 `ruoyi-common` 依赖，需使用 `-am` 让依赖模块一并参与构建
+- 本次未启动新的前后端进程

doc/implementation-report-2026-03-28-workflow-execute-rate-display-backend.md

@@ -0,0 +1,27 @@
+# 流程列表执行利率展示后端实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 链路确认内容
+- 后端实体 `LoanPricingWorkflow` 已包含 `executeRate` 字段
+- 流程列表接口 `/loanPricing/workflow/list` 直接返回 `LoanPricingWorkflow` 分页结果
+- 分页查询链路未对 `executeRate` 做转换、截断或回填到 `loanRate`
+
+## 结论
+- 本次需求无需后端代码改动
+- 前端只需直接消费后端已返回的 `executeRate` 字段即可
+
+## 边界说明
+- 不修改 `/loanPricing/workflow/list` 接口结构
+- 不修改 `loanRate` 字段业务含义
+- 不修改数据库表结构和 SQL
+
+## 验证方式
+1. 检查 `LoanPricingWorkflow` 实体是否定义 `executeRate`
+2. 检查 `LoanPricingWorkflowController#list` 是否直接返回 `LoanPricingWorkflow`
+3. 检查 `LoanPricingWorkflowServiceImpl#selectLoanPricingPage` 是否直接返回实体分页记录
+
+## 说明
+- 本次后端工作仅做链路确认与留档
+- 本次未为验证启动新的后端进程

doc/implementation-report-2026-03-28-workflow-execute-rate-display-design.md

@@ -0,0 +1,24 @@
+# 流程列表执行利率展示设计实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 新增流程列表执行利率展示设计文档
+- 明确本次需求只调整流程列表页，不扩散到详情页、接口和数据库
+- 明确页面应展示数据库 `execute_rate` 的实际数据，而不是 `loanRate`
+- 将设计文档保存路径修正为 `doc` 目录
+
+## 文档路径
+- `doc/2026-03-28-workflow-execute-rate-display-design.md`
+- `doc/implementation-report-2026-03-28-workflow-execute-rate-display-design.md`
+
+## 设计结论
+- 保持流程列表列头“执行利率(%)”不变
+- 将流程列表列绑定从 `loanRate` 调整为 `executeRate`
+- 不修改后端接口和数据库结构
+
+## 说明
+- 按仓库要求，本次先完成设计确认，再进入实施计划
+- 仓库约束禁止启用 subagent，因此本次未执行基于 subagent 的设计文档复审流程
+- 后续相关设计文档仅保存在 `doc` 目录下

doc/implementation-report-2026-03-28-workflow-execute-rate-display-frontend.md

@@ -0,0 +1,30 @@
+# 流程列表执行利率展示前端实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 将流程列表页“执行利率(%)”列绑定从 `loanRate` 调整为 `executeRate`
+- 保持流程列表接口、后端实体和数据库结构不变
+- 保持流程列表页列头“执行利率(%)”不变，仅修正展示字段来源
+
+## 修改文件
+- `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+- `doc/implementation-report-2026-03-28-workflow-execute-rate-display-frontend.md`
+
+## 验证方式
+1. 先通过源码断言确认当前不存在 `label="执行利率(%)"` 且 `prop="executeRate"` 的实现
+2. 修正列表列绑定为 `executeRate`
+3. 再次通过源码断言确认执行利率列已绑定 `executeRate`
+4. 执行前端生产构建验证页面代码可正常打包
+
+## 验证结果
+- 已确认修正前流程列表页“执行利率(%)”列仍绑定 `loanRate`
+- 已确认修正后流程列表页“执行利率(%)”列绑定为 `executeRate`
+- 已执行 `npm --prefix ruoyi-ui run build:prod`，构建成功，输出包含 `Build complete.`
+- 本次构建过程中仅出现项目原有的打包体积 warning，未出现新的构建错误
+
+## 说明
+- 本次只调整流程列表页，不扩散到详情页和后端接口
+- 本次未为验证额外启动新的前端进程
+- 环境中存在一个更早启动的 `vue-cli-service serve` 进程，不属于本次任务启动范围，因此未做停止操作

doc/implementation-report-2026-03-28-workflow-execute-rate-display-plans.md

@@ -0,0 +1,25 @@
+# 流程列表执行利率展示实施计划产出记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 基于设计文档补充前端实施计划
+- 基于设计文档补充后端实施计划
+- 明确本次需求前端负责修正列表字段绑定，后端负责边界确认与留档
+
+## 文档路径
+- `doc/2026-03-28-workflow-execute-rate-display-design.md`
+- `doc/2026-03-28-workflow-execute-rate-display-frontend-plan.md`
+- `doc/2026-03-28-workflow-execute-rate-display-backend-plan.md`
+- `doc/implementation-report-2026-03-28-workflow-execute-rate-display-plans.md`
+
+## 计划结论
+- 前端计划只修改流程列表页 `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+- 前端实施目标是把列表列绑定从 `loanRate` 调整为 `executeRate`
+- 后端计划不改代码，只确认现有返回链路已具备 `executeRate` 返回能力
+- 两份计划均要求验证结束后关闭本次任务启动的前后端进程
+
+## 说明
+- 按仓库要求，设计文档和实施计划均保存在 `doc` 目录
+- 仓库约束禁止启用 subagent，因此本次未执行基于 subagent 的计划文档复审流程

doc/implementation-report-2026-03-28-workflow-execution-rate-label.md

@@ -0,0 +1,22 @@
+# 流程列表执行利率文案调整实施记录
+
+## 本次改动
+
+- 将流程列表中的列头文案由“贷款利率(%)”调整为“执行利率(%)”
+- 保持字段绑定 `loanRate`、列表接口和后端数据结构不变，仅调整前端展示文案
+
+## 修改文件
+
+- `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+
+## 执行方式
+
+1. 定位贷款定价流程列表页中的利率列定义
+2. 将列表列头文案从“贷款利率(%)”替换为“执行利率(%)”
+3. 通过源码断言和前端构建验证改动结果
+
+## 验证目标
+
+- 流程列表页不再出现“贷款利率(%)”列头
+- 流程列表页展示“执行利率(%)”列头
+- 前端项目可正常构建

doc/implementation-report-2026-03-28-workflow-list-refresh-on-return.md

@@ -0,0 +1,33 @@
+# 流程详情返回后列表未刷新前端实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 问题说明
+- 流程列表页 `workflow/index.vue` 仅在 `created()` 中调用 `getList()`
+- 该页面在布局层通过 `keep-alive` 缓存
+- 从流程详情页返回时，列表页实例会被重新激活而不是重新创建，因此不会自动刷新
+
+## 本次修改
+- 为流程列表页增加 `activated()` 生命周期
+- 页面从详情页返回并重新激活时，重新执行 `getList()`
+- 新增一个无需额外测试框架的 Node 校验脚本，验证列表页激活时会调用 `getList()`
+
+## 影响范围
+- 仅影响前端流程列表页返回时的刷新行为
+- 不修改详情页路由
+- 不修改后端接口和查询参数
+
+## 验证方式
+1. 先运行前端校验脚本，确认修复前组件缺少 `activated()`，测试失败
+2. 补充 `activated()` 后再次运行校验脚本
+
+## 验证结果
+- 执行命令：
+```bash
+node ruoyi-ui/tests/workflow-index-refresh.test.js
+```
+- 结果：校验通过
+
+## 备注
+- 本次未启动新的前后端进程

doc/implementation-report-2026-03-28-workflow-update-time-list-design.md

@@ -0,0 +1,24 @@
+# 流程列表更新时间展示设计实施记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 新增流程列表更新时间展示设计文档
+- 明确列表将“创建时间”替换为“更新时间”
+- 明确后端列表 VO 与联表 SQL 补充 `updateTime`
+- 明确排序继续按 `update_time DESC`
+
+## 文档路径
+- `doc/2026-03-28-workflow-update-time-list-design.md`
+- `doc/implementation-report-2026-03-28-workflow-update-time-list-design.md`
+
+## 设计结论
+- 前端列表只展示“更新时间”
+- 前端时间列绑定 `updateTime`
+- 后端列表专用 VO 增加 `updateTime`
+- 联表 SQL 返回 `lpw.update_time AS updateTime`
+
+## 说明
+- 按仓库要求，本次先完成设计确认，再进入前后端实施计划
+- 仓库约束禁止启用 subagent，因此本次未执行基于 subagent 的设计文档复审流程

doc/implementation-report-2026-03-28-workflow-update-time-list-plans.md

@@ -0,0 +1,24 @@
+# 流程列表更新时间展示实施计划产出记录
+
+## 实施时间
+- 2026-03-28
+
+## 修改内容
+- 基于设计文档补充前端实施计划
+- 基于设计文档补充后端实施计划
+- 明确列表页时间列将从创建时间切换为更新时间
+
+## 文档路径
+- `doc/2026-03-28-workflow-update-time-list-design.md`
+- `doc/2026-03-28-workflow-update-time-list-frontend-plan.md`
+- `doc/2026-03-28-workflow-update-time-list-backend-plan.md`
+- `doc/implementation-report-2026-03-28-workflow-update-time-list-plans.md`
+
+## 计划结论
+- 前端计划只替换流程列表页时间列文案和字段绑定
+- 后端计划只调整列表专用 VO 与联表 SQL 的返回字段
+- 排序继续按 `update_time DESC`
+
+## 说明
+- 按仓库要求，设计文档和实施计划均保存在 `doc` 目录
+- 仓库约束禁止启用 subagent，因此本次未执行基于 subagent 的计划文档复审流程

doc/implementation-report-2026-03-30-agents-test-rules.md

@@ -0,0 +1,21 @@
+# AGENTS 测试步骤规范补充实施记录
+
+## 实施时间
+- 2026-03-30
+
+## 修改内容
+- 新增仓库级 `AGENTS.md` 协作规范内容
+- 明确开发完成后必须执行与改动对应的验证步骤
+- 明确接口开发完成后需要先重启后端进程，再进行接口调用验证
+- 明确接口测试必须覆盖正常场景、参数错误场景和关键业务分支场景
+- 明确前端页面开发完成后需要通过浏览器检查页面功能、交互与接口联动
+- 保留测试结束后自动关闭测试进程的要求
+
+## 文档路径
+- `AGENTS.md`
+- `doc/implementation-report-2026-03-30-agents-test-rules.md`
+
+## 结论
+- 已将“开发完成后的测试步骤”写入仓库级协作规范
+- 新增要求能够直接约束接口开发和前端页面开发的验收动作
+- 本次修改仅涉及文档规范，不涉及业务代码与接口实现

doc/implementation-report-2026-03-30-backend-port-63310.md

@@ -0,0 +1,13 @@
+# 后端端口调整为 63310 实施记录
+
+## 修改内容
+- 将 `ruoyi-admin` 的 `dev`、`uat`、`pro` 环境 `server.port` 统一调整为 `63310`。
+- 将后端模型调用配置 `model.url` 同步改为 `http://localhost:63310/rate/pricing/mock/invokeModel`，避免应用内部仍回调旧端口。
+- 将前端本地开发代理 `ruoyi-ui/vue.config.js` 的后端目标端口同步改为 `63310`。
+- 将 `test_api` 下的 Shell 脚本与 `.http` 示例请求地址统一改为 `http://localhost:63310`。
+
+## 验证结果
+- 执行 `./bin/restart_java_backend.sh restart`，构建与重启成功，启动日志显示开发环境实际监听端口为 `http-nio-63310`。
+- 执行 `lsof -iTCP:63310 -sTCP:LISTEN`，确认 Java 进程已监听 `63310` 端口。
+- 执行 `curl -sS -X POST http://localhost:63310/login/test -H 'Content-Type: application/json' -d '{"username":"admin","password":"admin123"}'`，返回 `{"code":200,...}`，确认新端口可正常访问登录测试接口。
+- 执行 `./bin/restart_java_backend.sh stop` 后再次检查 `./bin/restart_java_backend.sh status` 与 `lsof -iTCP:63310 -sTCP:LISTEN`，确认本次验证启动的后端进程已停止。

doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-backend.md

@@ -0,0 +1,33 @@
+# 贷款定价敏感字段加密后端实施记录
+
+## 修改内容
+- 在 `ruoyi-loan-pricing` 新增 `SensitiveFieldCryptoService`，统一处理 `custName`、`idNum` 的 AES/ECB/PKCS5Padding + Base64 加解密。
+- 在 `ruoyi-loan-pricing` 新增 `LoanPricingSensitiveDisplayService`，统一处理个人姓名、企业名称、身份证号、统一社会信用代码的脱敏展示。
+- 在 `LoanPricingWorkflowServiceImpl` 的创建链路对 `custName`、`idNum` 加密后入库，并在列表、详情链路解密后做脱敏返回。
+- 在 `LoanPricingWorkflowServiceImpl` 的详情链路补充对 `ModelRetailOutputFields`、`ModelCorpOutputFields` 基本信息中的 `custName`、`idNum` 进行脱敏，避免模型输出区域继续暴露明文。
+- 在 `LoanPricingModelService` 调用模型前显式解密 `custName`、`idNum`，保证模型入参不接收密文；同时补齐 `ModelInvokeDTO.idNum` 字段。
+- 修复模型调用后更新 `modelOutputId` 时把解密后的 `custName`、`idNum` 明文回写数据库的问题，改为仅更新 `modelOutputId`。
+- 在 `LoanPricingWorkflowMapper.xml` 和服务查询条件中移除按 `custName` 查询，改为按 `custIsn` 查询。
+- 新增 `sql/clear_loan_pricing_workflow_history.sql`，用于清理贷款定价流程及模型输出历史数据。
+
+## 新增测试
+- `SensitiveFieldCryptoServiceTest`
+- `LoanPricingSensitiveDisplayServiceTest`
+- `LoanPricingWorkflowServiceImplTest`
+- `LoanPricingModelServiceTest`
+
+## 验证结果
+- 执行 `mvn -pl ruoyi-loan-pricing -am -Dtest=SensitiveFieldCryptoServiceTest,LoanPricingSensitiveDisplayServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`，结果通过。
+- 执行 `mvn -pl ruoyi-loan-pricing -am -Dtest=LoanPricingWorkflowServiceImplTest -Dsurefire.failIfNoSpecifiedTests=false test`，结果通过。
+- 执行 `mvn -pl ruoyi-loan-pricing -am -Dtest=LoanPricingWorkflowServiceImplTest,LoanPricingModelServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`，结果通过。
+- 执行 `mvn -pl ruoyi-loan-pricing -am -Dtest=SensitiveFieldCryptoServiceTest,LoanPricingSensitiveDisplayServiceTest,LoanPricingWorkflowServiceImplTest,LoanPricingModelServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`，结果通过。
+- 执行 `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false test`，结果通过。
+- 从根工程重新打包 `ruoyi-admin.jar` 后，以 `18080` 端口启动临时后端实例，并将 `model.url` 指向 `http://localhost:18080/rate/pricing/mock/invokeModel` 完成联调。
+- 个人流程与企业流程创建成功，接口即时返回的 `custName`、`idNum` 为密文。
+- 调用参数错误场景 `/loanPricing/workflow/create/personal` 且缺少 `custIsn`，接口返回 `500`，错误信息为“客户内码不能为空”。
+- 调用列表接口按 `custIsn` 查询，确认个人返回 `custName` 为 `张*`，企业返回 `custName` 为 `测试****公司`。
+- 调用详情接口，确认流程主信息中个人返回 `张* / 1101********1234`，企业返回 `测试****公司 / 91*************00X`。
+- 调用详情接口，确认模型输出“基本信息”中个人返回 `张* / 3301********1234`，企业返回 `北京******公司 / 91*************XXX`。
+
+## 备注
+- 联调过程中发现 `serialNum` 仍使用毫秒时间戳生成，并发创建可能触发 `uk_serial_num` 冲突；该问题为本次验证中暴露的既有风险，本次未纳入敏感字段加密方案范围内处理。

doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-design.md

@@ -0,0 +1,34 @@
+# 贷款定价流程客户敏感信息加密设计实施记录
+
+## 实施时间
+
+- 2026-03-30
+
+## 修改内容
+
+- 新增贷款定价流程客户敏感信息加密改造设计文档
+- 明确本次范围仅覆盖贷款定价流程主链
+- 明确敏感字段限定为 `custName`、`idNum`
+- 明确采用应用层 AES 加解密与返回前统一脱敏方案
+- 明确列表查询改为仅支持客户内码 `custIsn`
+- 明确存量数据处理方式为直接清空，不做迁移
+- 补充模型输出“基本信息”中的 `custName`、`idNum` 也需纳入展示脱敏范围
+
+## 文档路径
+
+- `doc/2026-03-30-loan-pricing-sensitive-data-encryption-design.md`
+- `doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-design.md`
+
+## 设计结论
+
+- `loan_pricing_workflow.cust_name`、`loan_pricing_workflow.id_num` 改为密文存储
+- 贷款定价流程列表页、详情页仅展示脱敏值
+- 贷款定价流程详情页中的模型输出“基本信息”也仅展示脱敏值
+- 前端不承担加解密职责
+- 模型调用前由后端服务内部解密敏感字段
+
+## 说明
+
+- 设计文档已按当前仓库习惯保存到 `doc/` 目录
+- 仓库约束禁止启用 subagent，因此本次未执行基于 subagent 的设计文档复审流程，改为人工复审
+- 本次仅完成设计，不包含实施代码修改

doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-frontend.md

@@ -0,0 +1,15 @@
+# 贷款定价敏感字段加密前端实施记录
+
+## 修改内容
+- 流程列表页查询项已从“客户名称”切换为“客户内码”，查询参数从 `queryParams.custName` 改为 `queryParams.custIsn`。
+- `ruoyi-ui/src/api/loanPricing/workflow.js` 保持 `params: query` 透传，不新增任何前端字段映射或加解密逻辑。
+- 列表页继续直接展示后端返回的 `custName`，详情页继续直接展示后端返回的 `custName`、`idNum`，前端不承担脱敏算法和明文查看能力。
+
+## 验证结果
+- 执行 `rg -n 'custName|custIsn|客户名称|客户内码' ruoyi-ui/src/views/loanPricing/workflow/index.vue ruoyi-ui/src/api/loanPricing/workflow.js`，确认列表页查询区已改为 `custIsn`，不再使用 `queryParams.custName`。
+- 执行 `npm --prefix ruoyi-ui run build:prod`，结果通过，最终输出包含 `Build complete.`；构建过程中仅有原有包体积告警，无新增编译错误。
+- 核对 `detail.vue`、`PersonalWorkflowDetail.vue`、`CorporateWorkflowDetail.vue`，确认详情页仍直接渲染 `detailData.custName`、`detailData.idNum`，未新增任何前端二次脱敏或明文查看逻辑。
+- 结合后端联调结果确认：后端列表接口已返回 `张*`，详情接口已返回 `张* / 1101********1234 / 测试****公司 / 91*************00X`，前端现有展示代码会直接消费这些脱敏值。
+
+## 备注
+- 浏览器侧尝试通过现有 `9527` 前端服务进入贷款定价页面时，受其固定代理目标 `http://localhost:8080` 上现有后端接口超时影响，未完成一次独立的前端页面点击链路；本次前端展示结论基于源码直渲染核对、生产构建通过以及后端真实接口返回值联调共同确认。

doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-plans.md

@@ -0,0 +1,29 @@
+# 贷款定价流程客户敏感信息加密计划实施记录
+
+## 实施时间
+- 2026-03-30
+
+## 修改内容
+- 新增贷款定价敏感信息加密后端实施计划
+- 新增贷款定价敏感信息加密前端实施计划
+- 明确后端采用统一加解密服务 + 统一展示脱敏服务的实施路径
+- 明确前端仅做查询项收口和脱敏值消费，不承担加解密
+- 明确测试命令、数据库清理脚本、实施记录与提交节点
+- 补充模型输出“基本信息”页签中的 `custName`、`idNum` 也纳入脱敏验证范围
+
+## 文档路径
+- `docs/superpowers/plans/2026-03-30-loan-pricing-sensitive-data-encryption-backend-plan.md`
+- `docs/superpowers/plans/2026-03-30-loan-pricing-sensitive-data-encryption-frontend-plan.md`
+- `doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-plans.md`
+
+## 计划结论
+- 计划已按仓库要求拆分为后端执行文档和前端执行文档
+- 后端计划覆盖密钥配置、敏感字段加解密、列表/详情脱敏、模型调用前解密和历史数据清理
+- 后端计划补充模型输出“基本信息”返回值脱敏
+- 前端计划覆盖查询项切换为客户内码、脱敏值展示消费、构建验证和联调验证，并显式检查模型输出“基本信息”页签
+- 两份计划都采用最短路径实现，不引入明密文兼容分支
+
+## 说明
+- 已检查计划文档保存路径，执行计划保存至 `docs/superpowers/plans`
+- 仓库约束禁止启用 subagent，本次计划复审采用本地自检方式处理
+- 当前仅完成计划文档，不包含代码实现

doc/implementation-report-2026-03-30-login-password-encryption-backend.md

@@ -0,0 +1,18 @@
+# 密码加密传输后端实施记录
+
+## 修改内容
+- 在 `ruoyi-framework` 新增 `PasswordTransferCryptoService`，统一处理 AES/ECB/PKCS5Padding + Base64 的密码传输解密。
+- 在 `ruoyi-admin` 的 `application.yml`、`application-dev.yml` 增加 `security.password-transfer.key` 配置。
+- 在 `/login`、`/register`、`/system/user/profile/updatePwd`、`/system/user`、`/system/user/resetPwd` 入口增加密码字段解密，随后继续复用原有认证、校验和 BCrypt 入库逻辑。
+- 保持 `/login/test` 未改动。
+
+## 新增测试
+- `PasswordTransferCryptoServiceTest`
+- `SysLoginControllerPasswordTransferTest`
+- `SysRegisterControllerPasswordTransferTest`
+- `SysProfileControllerPasswordTransferTest`
+- `SysUserControllerPasswordTransferTest`
+
+## 验证结果
+- 执行 `mvn -pl ruoyi-admin,ruoyi-framework -am -Dtest=PasswordTransferCryptoServiceTest,SysLoginControllerPasswordTransferTest,SysRegisterControllerPasswordTransferTest,SysProfileControllerPasswordTransferTest,SysUserControllerPasswordTransferTest -Dsurefire.failIfNoSpecifiedTests=false test`，结果通过。
+- 检查 `SysLoginController` 引入解密的提交 diff，确认仅 `/login` 增加了解密调用，`/login/test` 无行为变化。

doc/implementation-report-2026-03-30-login-password-encryption-design.md

@@ -0,0 +1,26 @@
+# 系统登录与密码类接口加密传输设计实施记录
+
+## 实施时间
+- 2026-03-30
+
+## 修改内容
+- 新增系统登录与密码类接口加密传输设计文档
+- 明确采用固定密钥的对称加密方案
+- 明确覆盖正式密码提交接口并排除 `/login/test`
+- 明确前端在 API 提交前加密、后端在控制器入口前统一解密
+- 明确不采用明密文兼容处理
+
+## 文档路径
+- `docs/superpowers/specs/2026-03-30-login-password-encryption-design.md`
+- `doc/implementation-report-2026-03-30-login-password-encryption-design.md`
+
+## 设计结论
+- 对正式密码提交接口启用固定密钥对称加密传输
+- 保持原有请求字段名不变，仅对密码字段做加密与解密
+- 解密成功后继续复用现有认证、校验与 BCrypt 入库逻辑
+- `/login/test` 保持现状，不接入本次改动
+
+## 说明
+- 已按要求检查设计文档保存路径，正式设计文档保存至 `docs/superpowers/specs`
+- 仓库约束禁止启用 subagent，本次设计文档复审采用本地自检方式处理
+- 设计确认后，下一步需要分别产出后端实施计划和前端实施计划

doc/implementation-report-2026-03-30-login-password-encryption-frontend.md

@@ -0,0 +1,16 @@
+# 密码加密传输前端实施记录
+
+## 修改内容
+- 新增 `ruoyi-ui/src/utils/passwordTransfer.js`，统一处理密码字段 AES/ECB/PKCS7 加密。
+- 在 `ruoyi-ui/package.json` 增加 `test:password-transfer` 脚本，并引入 `crypto-js` 依赖。
+- 在 `ruoyi-ui/src/api/login.js` 中为登录、注册请求只加密 `password` 字段。
+- 在 `ruoyi-ui/src/api/system/user.js` 中为个人修改密码、管理员新增用户、管理员重置密码请求加密受控密码字段。
+- 在 `ruoyi-ui/.env.development`、`ruoyi-ui/.env.staging`、`ruoyi-ui/.env.production` 增加 `VUE_APP_PASSWORD_TRANSFER_KEY` 配置。
+- 页面组件保持明文表单值和原有校验逻辑不变。
+
+## 新增验证
+- 新增 `ruoyi-ui/tests/password-transfer-api.test.js`，覆盖密码加密工具、登录、注册、个人修改密码、管理员新增用户、管理员重置密码 API。
+
+## 验证结果
+- 执行 `npm run test:password-transfer`，结果通过。
+- 执行 `npm run build:stage`，结果通过；仅存在既有的打包体积 warning，无新增构建错误。

doc/implementation-report-2026-03-30-login-password-encryption-plans.md

@@ -0,0 +1,27 @@
+# 系统登录与密码类接口加密传输计划实施记录
+
+## 实施时间
+- 2026-03-30
+
+## 修改内容
+- 新增密码加密传输后端实施计划
+- 新增密码加密传输前端实施计划
+- 明确后端以统一解密服务 + 控制器显式接入的方式实施
+- 明确前端以统一加密工具 + API 层字段映射的方式实施
+- 明确测试命令、实施记录与提交节点
+
+## 文档路径
+- `docs/superpowers/plans/2026-03-30-login-password-encryption-backend-plan.md`
+- `docs/superpowers/plans/2026-03-30-login-password-encryption-frontend-plan.md`
+- `doc/implementation-report-2026-03-30-login-password-encryption-plans.md`
+
+## 计划结论
+- 计划已按仓库要求拆分为后端执行文档和前端执行文档
+- 两份计划都采用最短路径实现，不引入明密文兼容分支
+- 后端计划覆盖统一解密、控制器接入和 MockMvc/单测验证
+- 前端计划覆盖统一加密、API 接入、环境配置和 Node 脚本验证
+
+## 说明
+- 已按要求检查计划文档保存路径，计划保存至 `docs/superpowers/plans`
+- 仓库约束禁止启用 subagent，本次计划复审采用本地自检方式处理
+- 当前仅完成计划文档，不包含代码实现

docs/superpowers/plans/2026-03-30-loan-pricing-sensitive-data-encryption-backend-plan.md

@@ -0,0 +1,344 @@
+# Loan Pricing Sensitive Data Encryption Backend Implementation Plan
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan in this repository. Do not use subagents. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 让贷款定价流程在后端对 `custName`、`idNum` 实现密文存储，并保证列表、详情、模型输出基本信息、模型调用链路在各自边界内完成脱敏或解密。
+
+**Architecture:** 后端在 `ruoyi-loan-pricing` 模块内新增贷款定价专用敏感字段加解密服务和展示脱敏服务，固定密钥从配置读取。`LoanPricingWorkflowServiceImpl` 在创建、列表、详情和模型输出展示链路显式接入这些服务，`LoanPricingModelService` 在调模型前显式解密，避免把密文错误透传给模型。
+
+**Tech Stack:** Spring Boot、MyBatis Plus、JUnit 5、Mockito、Maven、JDK `javax.crypto`
+
+---
+
+### Task 1: 搭建敏感字段加解密与脱敏基础设施
+
+**Files:**
+- Create: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/SensitiveFieldCryptoService.java`
+- Create: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/LoanPricingSensitiveDisplayService.java`
+- Create: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/SensitiveFieldCryptoServiceTest.java`
+- Create: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/LoanPricingSensitiveDisplayServiceTest.java`
+- Modify: `ruoyi-admin/src/main/resources/application.yml`
+
+- [ ] **Step 1: 写加解密与脱敏失败测试**
+
+新增两个测试文件，至少覆盖以下场景：
+
+```java
+@Test
+void shouldEncryptAndDecryptCustNameAndIdNum()
+{
+    String cipher = service.encrypt("张三");
+
+    assertNotEquals("张三", cipher);
+    assertEquals("张三", service.decrypt(cipher));
+}
+
+@Test
+void shouldRejectBlankKeyConfiguration()
+{
+    SensitiveFieldCryptoService service = new SensitiveFieldCryptoService("");
+    assertThrows(IllegalStateException.class, () -> service.encrypt("张三"));
+}
+```
+
+```java
+@Test
+void shouldMaskPersonalNameAndIdNum()
+{
+    assertEquals("张*", displayService.maskCustName("张三"));
+    assertEquals("1101********1234", displayService.maskIdNum("110101199001011234"));
+}
+
+@Test
+void shouldMaskCorporateNameAndCreditCode()
+{
+    assertEquals("测试****公司", displayService.maskCustName("测试科技有限公司"));
+    assertEquals("91*************00X", displayService.maskIdNum("91110000100000000X"));
+}
+```
+
+- [ ] **Step 2: 运行基础测试确认当前失败**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dtest=SensitiveFieldCryptoServiceTest,LoanPricingSensitiveDisplayServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: FAIL，提示测试类或对应服务不存在。
+
+- [ ] **Step 3: 增加配置项和最小实现**
+
+在 `application.yml` 增加贷款定价敏感字段配置，例如：
+
+```yaml
+loan-pricing:
+  sensitive:
+    key: "1234567890abcdef"
+```
+
+创建加解密服务与脱敏服务，最小实现至少包含：
+
+```java
+@Service
+public class SensitiveFieldCryptoService
+{
+    public String encrypt(String plainText) { ... }
+    public String decrypt(String cipherText) { ... }
+}
+```
+
+```java
+@Service
+public class LoanPricingSensitiveDisplayService
+{
+    public String maskCustName(String custName) { ... }
+    public String maskIdNum(String idNum) { ... }
+}
+```
+
+- [ ] **Step 4: 重新运行基础测试**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dtest=SensitiveFieldCryptoServiceTest,LoanPricingSensitiveDisplayServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/SensitiveFieldCryptoService.java ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/LoanPricingSensitiveDisplayService.java ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/SensitiveFieldCryptoServiceTest.java ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/LoanPricingSensitiveDisplayServiceTest.java ruoyi-admin/src/main/resources/application.yml
+git commit -m "新增贷款定价敏感字段加解密服务"
+```
+
+### Task 2: 接入流程创建与列表查询链路
+
+**Files:**
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java`
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/entity/LoanPricingWorkflow.java`
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVO.java`
+- Modify: `ruoyi-loan-pricing/src/main/resources/mapper/loanpricing/LoanPricingWorkflowMapper.xml`
+- Modify: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java`
+
+- [ ] **Step 1: 写服务层失败测试，约束创建时入库加密、列表返回脱敏、查询按客户内码**
+
+在 `LoanPricingWorkflowServiceImplTest` 增加至少 3 个用例：
+
+```java
+@Test
+void shouldEncryptCustNameAndIdNumBeforeInsert() { ... }
+
+@Test
+void shouldMaskCustNameWhenReturningPagedWorkflowList() { ... }
+
+@Test
+void shouldUseCustIsnInsteadOfCustNameAsQueryCondition() { ... }
+```
+
+关键断言至少包括：
+
+```java
+verify(loanPricingWorkflowMapper).insert(argThat(entity ->
+        !Objects.equals(entity.getCustName(), "张三")
+                && !Objects.equals(entity.getIdNum(), "110101199001011234")));
+
+assertEquals("张*", result.getRecords().get(0).getCustName());
+```
+
+- [ ] **Step 2: 运行服务测试确认失败**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dtest=LoanPricingWorkflowServiceImplTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: FAIL，当前创建逻辑尚未加密，列表链路尚未脱敏，查询条件仍包含 `custName`。
+
+- [ ] **Step 3: 在创建链路显式加密敏感字段**
+
+在 `LoanPricingWorkflowServiceImpl#createLoanPricing` 中补最小实现：
+
+```java
+loanPricingWorkflow.setCustName(sensitiveFieldCryptoService.encrypt(loanPricingWorkflow.getCustName()));
+loanPricingWorkflow.setIdNum(sensitiveFieldCryptoService.encrypt(loanPricingWorkflow.getIdNum()));
+loanPricingWorkflowMapper.insert(loanPricingWorkflow);
+```
+
+要求：
+- 只加密 `custName`、`idNum`
+- `custIsn` 保持原样
+- 配置缺失时直接失败，不增加明文兼容分支
+
+- [ ] **Step 4: 收口列表查询条件并补脱敏返回**
+
+修改点至少包含：
+
+```java
+if (StringUtils.hasText(loanPricingWorkflow.getCustIsn()))
+{
+    wrapper.like(LoanPricingWorkflow::getCustIsn, loanPricingWorkflow.getCustIsn());
+}
+```
+
+```java
+pageResult.getRecords().forEach(row ->
+        row.setCustName(loanPricingSensitiveDisplayService.maskCustName(
+                sensitiveFieldCryptoService.decrypt(row.getCustName()))));
+```
+
+同步从 `buildQueryWrapper` 和 `LoanPricingWorkflowMapper.xml` 删除 `custName` 过滤条件。
+
+- [ ] **Step 5: 重新运行服务测试**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dtest=LoanPricingWorkflowServiceImplTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS
+
+- [ ] **Step 6: 补充实体与 VO 边界说明性调整**
+
+若测试或编译需要，在 `LoanPricingWorkflow` 与 `LoanPricingWorkflowListVO` 中补充本次链路使用的字段，并保持对象语义清晰；不要新增明文副本字段。
+
+- [ ] **Step 7: 提交本任务**
+
+```bash
+git add ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/entity/LoanPricingWorkflow.java ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowListVO.java ruoyi-loan-pricing/src/main/resources/mapper/loanpricing/LoanPricingWorkflowMapper.xml ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java
+git commit -m "接入流程敏感字段加密与列表脱敏"
+```
+
+### Task 3: 接入详情返回、模型输出展示与模型调用链路
+
+**Files:**
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java`
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/LoanPricingModelService.java`
+- Modify: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowVO.java`
+- Create: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/LoanPricingModelServiceTest.java`
+- Modify: `ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java`
+
+- [ ] **Step 1: 写详情、模型输出展示与模型调用失败测试**
+
+新增或补充以下测试场景：
+
+```java
+@Test
+void shouldMaskCustNameAndIdNumWhenReturningWorkflowDetail() { ... }
+```
+
+```java
+@Test
+void shouldMaskCustNameAndIdNumInRetailModelOutputBasicInfo() { ... }
+```
+
+```java
+@Test
+void shouldMaskCustNameAndIdNumInCorporateModelOutputBasicInfo() { ... }
+```
+
+```java
+@Test
+void shouldDecryptCustNameAndIdNumBeforeInvokeModel() { ... }
+```
+
+关键断言至少包括：
+
+```java
+assertEquals("张*", result.getLoanPricingWorkflow().getCustName());
+assertEquals("1101********1234", result.getLoanPricingWorkflow().getIdNum());
+assertEquals("张*", result.getModelRetailOutputFields().getCustName());
+assertEquals("1101********1234", result.getModelRetailOutputFields().getIdNum());
+verify(modelService).invokeModel(argThat(dto ->
+        Objects.equals("张三", dto.getCustName())
+                && Objects.equals("110101199001011234", dto.getIdNum())));
+```
+
+- [ ] **Step 2: 运行详情与模型测试确认失败**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dtest=LoanPricingWorkflowServiceImplTest,LoanPricingModelServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: FAIL，当前详情返回未完整脱敏，模型输出“基本信息”仍会返回明文，模型调用前也未解密。
+
+- [ ] **Step 3: 在详情返回前显式解密再脱敏**
+
+在 `selectLoanPricingBySerialNum` 中加入类似处理：
+
+```java
+String plainCustName = sensitiveFieldCryptoService.decrypt(loanPricingWorkflow.getCustName());
+String plainIdNum = sensitiveFieldCryptoService.decrypt(loanPricingWorkflow.getIdNum());
+loanPricingWorkflow.setCustName(loanPricingSensitiveDisplayService.maskCustName(plainCustName));
+loanPricingWorkflow.setIdNum(loanPricingSensitiveDisplayService.maskIdNum(plainIdNum));
+```
+
+要求：
+- 对外返回对象中不保留明文
+- 保持既有测算利率与执行利率逻辑不变
+- 若 `modelRetailOutputFields` 或 `modelCorpOutputFields` 非空，同样对其 `custName`、`idNum` 做脱敏替换
+
+- [ ] **Step 4: 在模型调用前显式解密**
+
+在 `LoanPricingModelService#invokeModelAsync` 中补最小实现：
+
+```java
+loanPricingWorkflow.setCustName(sensitiveFieldCryptoService.decrypt(loanPricingWorkflow.getCustName()));
+loanPricingWorkflow.setIdNum(sensitiveFieldCryptoService.decrypt(loanPricingWorkflow.getIdNum()));
+BeanUtils.copyProperties(loanPricingWorkflow, modelInvokeDTO);
+```
+
+要求：
+- 只解密 `custName`、`idNum`
+- 解密失败直接中断模型调用并记录错误
+- 不修改模型输出表处理逻辑
+
+- [ ] **Step 5: 重新运行详情与模型测试**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dtest=LoanPricingWorkflowServiceImplTest,LoanPricingModelServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS
+
+- [ ] **Step 6: 运行贷款定价模块回归测试**
+
+Run: `mvn -pl ruoyi-loan-pricing -am -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS；若有失败，先区分是否为既有问题，再决定是否继续扩测。
+
+- [ ] **Step 7: 提交本任务**
+
+```bash
+git add ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/LoanPricingModelService.java ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowVO.java ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/LoanPricingModelServiceTest.java ruoyi-loan-pricing/src/test/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImplTest.java
+git commit -m "接入流程详情脱敏与模型调用解密"
+```
+
+### Task 4: 补数据库脚本与后端实施记录
+
+**Files:**
+- Create: `sql/clear_loan_pricing_workflow_history.sql`
+- Create: `doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-backend.md`
+
+- [ ] **Step 1: 新增历史数据清理脚本**
+
+创建脚本，至少包含：
+
+```sql
+DELETE FROM model_retail_output_fields;
+DELETE FROM model_corp_output_fields;
+DELETE FROM loan_pricing_workflow;
+```
+
+要求：
+- 删除顺序满足外键或业务依赖关系
+- 只清理贷款定价流程相关数据
+
+- [ ] **Step 2: 写后端实施记录**
+
+实施记录至少写明：
+
+```markdown
+- 已新增贷款定价敏感字段加解密服务与展示脱敏服务
+- 已在流程创建链路对 `custName`、`idNum` 加密后入库
+- 已在详情返回与列表返回链路统一脱敏
+- 已在模型调用前显式解密敏感字段
+- 已新增历史数据清理脚本
+```
+
+- [ ] **Step 3: 手工验证数据库落库与返回链路**
+
+Run: 按项目现有方式启动后端，创建一条个人流程和一条企业流程，再查询列表与详情。
+Expected:
+- 数据库中的 `cust_name`、`id_num` 不等于前端提交明文
+- 列表和详情返回的 `custName`、`idNum` 为脱敏值
+- 模型输出“基本信息”页签中的 `custName`、`idNum` 也为脱敏值
+
+- [ ] **Step 4: 如果为验证启动了后端进程，结束对应进程**
+
+Run: `ps -ef | rg 'RuoYiApplication|loan-pricing|java'`
+Expected: 仅停止本次验证启动的后端进程；对非本次启动进程不做处理。
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add sql/clear_loan_pricing_workflow_history.sql doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-backend.md
+git commit -m "补充贷款定价敏感字段后端实施记录"
+```

docs/superpowers/plans/2026-03-30-loan-pricing-sensitive-data-encryption-frontend-plan.md

@@ -0,0 +1,150 @@
+# Loan Pricing Sensitive Data Encryption Frontend Implementation Plan
+
+> **For agentic workers:** REQUIRED: Use superpowers:executing-plans to implement this plan in this repository. Do not use subagents. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 让贷款定价流程前端只按客户内码查询，并在列表页、详情页、模型输出“基本信息”页签稳定展示后端返回的脱敏 `custName`、`idNum`。
+
+**Architecture:** 前端不承担任何加解密逻辑，只做查询项收口与脱敏值展示消费。列表页从按 `custName` 查询切换为按 `custIsn` 查询，详情页与 `ModelOutputDisplay.vue` 保持现有结构，继续直接渲染后端返回字段，但要联调确认模型输出“基本信息”页签不再出现敏感明文。
+
+**Tech Stack:** Vue 2、Element UI、RuoYi 前端工程、npm
+
+---
+
+### Task 1: 收口流程列表页查询条件为客户内码
+
+**Files:**
+- Modify: `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+- Modify: `ruoyi-ui/src/api/loanPricing/workflow.js`
+
+- [ ] **Step 1: 核对当前查询项与请求参数**
+
+Run: `sed -n '1,140p' ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+Expected: 能看到当前页面仍存在“客户名称”查询项和 `queryParams.custName`。
+
+- [ ] **Step 2: 将查询项改为客户内码**
+
+把列表页查询区调整为类似结构：
+
+```vue
+<el-form-item label="客户内码" prop="custIsn">
+  <el-input
+    v-model="queryParams.custIsn"
+    placeholder="请输入客户内码"
+    clearable
+    @keyup.enter.native="handleQuery"
+  />
+</el-form-item>
+```
+
+同步把查询参数从：
+
+```js
+custName: undefined
+```
+
+改为：
+
+```js
+custIsn: undefined
+```
+
+- [ ] **Step 3: 核对 API 层无需额外字段转换**
+
+检查 `ruoyi-ui/src/api/loanPricing/workflow.js`，确认 `listWorkflow(query)` 继续透传 `params: query` 即可；若代码风格需要，仅补充注释说明，不新增映射逻辑。
+
+- [ ] **Step 4: 重新检查源码确认客户名称查询已移除**
+
+Run: `rg -n 'custName|custIsn|客户名称|客户内码' ruoyi-ui/src/views/loanPricing/workflow/index.vue ruoyi-ui/src/api/loanPricing/workflow.js`
+Expected: 列表页查询区不再出现 `queryParams.custName`，而是使用 `custIsn`。
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-ui/src/views/loanPricing/workflow/index.vue ruoyi-ui/src/api/loanPricing/workflow.js
+git commit -m "调整流程列表按客户内码查询"
+```
+
+### Task 2: 固化列表页、详情页与模型输出基本信息的脱敏展示消费
+
+**Files:**
+- Modify: `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
+- Modify: `ruoyi-ui/src/views/loanPricing/workflow/detail.vue`
+- Modify: `ruoyi-ui/src/views/loanPricing/workflow/components/PersonalWorkflowDetail.vue`
+- Modify: `ruoyi-ui/src/views/loanPricing/workflow/components/CorporateWorkflowDetail.vue`
+- Inspect: `ruoyi-ui/src/views/loanPricing/workflow/components/ModelOutputDisplay.vue`
+
+- [ ] **Step 1: 核对当前页面直接消费后端字段的位置**
+
+Run: `rg -n 'custName|idNum' ruoyi-ui/src/views/loanPricing/workflow/index.vue ruoyi-ui/src/views/loanPricing/workflow/detail.vue ruoyi-ui/src/views/loanPricing/workflow/components/PersonalWorkflowDetail.vue ruoyi-ui/src/views/loanPricing/workflow/components/CorporateWorkflowDetail.vue ruoyi-ui/src/views/loanPricing/workflow/components/ModelOutputDisplay.vue`
+Expected: 能定位列表、详情以及模型输出“基本信息”页签中所有 `custName`、`idNum` 的展示位置。
+
+- [ ] **Step 2: 去掉任何可能的前端二次处理设想，只保留直接展示**
+
+如果页面中需要加说明性注释，保持最小实现，例如：
+
+```vue
+<el-descriptions-item label="客户名称">{{ detailData.custName }}</el-descriptions-item>
+<el-descriptions-item label="证件号码">{{ detailData.idNum }}</el-descriptions-item>
+```
+
+要求：
+- 不新增“查看明文”按钮
+- 不新增复制原值功能
+- 不在前端自行做脱敏算法
+- `ModelOutputDisplay.vue` 继续直接消费后端字段，不新增本地脱敏逻辑
+
+- [ ] **Step 3: 执行前端构建验证**
+
+Run: `npm --prefix ruoyi-ui run build:prod`
+Expected: PASS，输出包含 `Build complete.`
+
+- [ ] **Step 4: 页面联调确认脱敏展示**
+
+Run: 按项目现有方式启动前端并进入贷款定价流程列表页、详情页。
+Expected:
+- 列表页客户名称显示为脱敏值
+- 个人详情页客户名称、证件号码显示为脱敏值
+- 企业详情页客户名称、证件号码显示为脱敏值
+- 个人模型输出“基本信息”页签中的客户名称、证件号码显示为脱敏值
+- 企业模型输出“基本信息”页签中的客户名称、证件号码显示为脱敏值
+
+- [ ] **Step 5: 如果为验证启动了前端进程，结束对应进程**
+
+Run: `ps -ef | rg 'ruoyi-ui|vue-cli-service|npm'`
+Expected: 仅停止本次联调启动的前端进程；对非本次启动进程不做处理。
+
+- [ ] **Step 6: 提交本任务**
+
+```bash
+git add ruoyi-ui/src/views/loanPricing/workflow/index.vue ruoyi-ui/src/views/loanPricing/workflow/detail.vue ruoyi-ui/src/views/loanPricing/workflow/components/PersonalWorkflowDetail.vue ruoyi-ui/src/views/loanPricing/workflow/components/CorporateWorkflowDetail.vue
+git commit -m "接入流程敏感字段前端脱敏展示"
+```
+
+### Task 3: 补前端实施记录
+
+**Files:**
+- Create: `doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-frontend.md`
+
+- [ ] **Step 1: 编写前端实施记录**
+
+实施记录至少写明：
+
+```markdown
+- 流程列表页查询项已从客户名称切换为客户内码
+- 前端不承担 `custName`、`idNum` 加解密逻辑
+- 列表页与详情页均直接展示后端返回的脱敏值
+- 模型输出“基本信息”页签也直接展示后端返回的脱敏值
+- 已完成前端构建验证与页面联调
+```
+
+- [ ] **Step 2: 核对文档路径**
+
+Run: `ls doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-frontend.md`
+Expected: 文件位于仓库 `doc/` 目录，不写错到其他文档路径。
+
+- [ ] **Step 3: 提交本任务**
+
+```bash
+git add doc/implementation-report-2026-03-30-loan-pricing-sensitive-data-encryption-frontend.md
+git commit -m "补充贷款定价敏感字段前端实施记录"
+```

docs/superpowers/plans/2026-03-30-login-password-encryption-backend-plan.md

@@ -0,0 +1,279 @@
+# Backend Password Transfer Encryption Implementation Plan
+
+> **For agentic workers:** REQUIRED: Use superpowers:subagent-driven-development (if subagents available) or superpowers:executing-plans to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 为正式密码提交接口补上后端解密链路，让 `/login`、`/register`、`/system/user/profile/updatePwd`、`/system/user/resetPwd`、`/system/user` 在收到密文密码后先解密，再复用现有认证与 BCrypt 逻辑。
+
+**Architecture:** 在 `ruoyi-framework` 新增统一的密码传输解密服务，固定密钥从配置读取，负责 AES/Base64 解密和失败抛错。`ruoyi-admin` 各控制器在进入现有业务逻辑前显式调用该服务对密码字段解密，`/login/test` 保持不变。
+
+**Tech Stack:** Spring Boot 3.5、JUnit 5、MockMvc、JDK `javax.crypto`、Maven Surefire
+
+---
+
+### Task 1: 搭建后端密码解密基础设施
+
+**Files:**
+- Create: `ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/PasswordTransferCryptoService.java`
+- Create: `ruoyi-framework/src/test/java/com/ruoyi/framework/web/service/PasswordTransferCryptoServiceTest.java`
+- Modify: `ruoyi-admin/src/main/resources/application.yml`
+- Modify: `ruoyi-admin/src/main/resources/application-dev.yml`
+
+- [ ] **Step 1: 写解密服务失败用例**
+
+```java
+class PasswordTransferCryptoServiceTest
+{
+    @Test
+    void shouldDecryptValidCipherText()
+    {
+        String plain = service.decrypt("Base64密文");
+        assertEquals("admin123", plain);
+    }
+
+    @Test
+    void shouldRejectInvalidCipherText()
+    {
+        assertThrows(ServiceException.class, () -> service.decrypt("not-base64"));
+    }
+}
+```
+
+- [ ] **Step 2: 运行测试确认当前失败**
+
+Run: `mvn -pl ruoyi-framework -am -Dtest=PasswordTransferCryptoServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: FAIL，提示测试类或 `PasswordTransferCryptoService` 不存在
+
+- [ ] **Step 3: 补配置与最小实现**
+
+```java
+@Service
+public class PasswordTransferCryptoService
+{
+    @Value("${security.password-transfer.key}")
+    private String key;
+
+    public String decrypt(String cipherText)
+    {
+        Cipher cipher = Cipher.getInstance("AES/ECB/PKCS5Padding");
+        cipher.init(Cipher.DECRYPT_MODE, new SecretKeySpec(key.getBytes(StandardCharsets.UTF_8), "AES"));
+        return new String(cipher.doFinal(Base64.getDecoder().decode(cipherText)), StandardCharsets.UTF_8);
+    }
+}
+```
+
+```yaml
+security:
+  password-transfer:
+    key: "请替换为16位固定密钥"
+```
+
+- [ ] **Step 4: 重新运行基础测试**
+
+Run: `mvn -pl ruoyi-framework -am -Dtest=PasswordTransferCryptoServiceTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-framework/src/main/java/com/ruoyi/framework/web/service/PasswordTransferCryptoService.java ruoyi-framework/src/test/java/com/ruoyi/framework/web/service/PasswordTransferCryptoServiceTest.java ruoyi-admin/src/main/resources/application.yml ruoyi-admin/src/main/resources/application-dev.yml
+git commit -m "新增密码传输解密服务"
+```
+
+### Task 2: 接入登录与注册接口解密
+
+**Files:**
+- Modify: `ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysLoginController.java`
+- Modify: `ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysRegisterController.java`
+- Create: `ruoyi-admin/src/test/java/com/ruoyi/web/controller/system/SysLoginControllerPasswordTransferTest.java`
+- Create: `ruoyi-admin/src/test/java/com/ruoyi/web/controller/system/SysRegisterControllerPasswordTransferTest.java`
+
+- [ ] **Step 1: 写登录与注册控制器失败测试**
+
+```java
+mockMvc.perform(post("/login")
+        .contentType(MediaType.APPLICATION_JSON)
+        .content("{\"username\":\"admin\",\"password\":\"cipher\",\"code\":\"1\",\"uuid\":\"u\"}"))
+    .andExpect(status().isOk());
+
+verify(passwordTransferCryptoService).decrypt("cipher");
+verify(loginService).login("admin", "admin123", "1", "u");
+```
+
+```java
+mockMvc.perform(post("/register")
+        .contentType(MediaType.APPLICATION_JSON)
+        .content("{\"username\":\"u1\",\"password\":\"cipher\",\"code\":\"1\",\"uuid\":\"u\"}"))
+    .andExpect(status().isOk());
+
+verify(passwordTransferCryptoService).decrypt("cipher");
+verify(registerService).register(any(RegisterBody.class));
+```
+
+- [ ] **Step 2: 运行登录/注册测试确认失败**
+
+Run: `mvn -pl ruoyi-admin -am -Dtest=SysLoginControllerPasswordTransferTest,SysRegisterControllerPasswordTransferTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: FAIL，控制器尚未调用解密服务
+
+- [ ] **Step 3: 在正式接口入口补解密**
+
+```java
+loginBody.setPassword(passwordTransferCryptoService.decrypt(loginBody.getPassword()));
+```
+
+```java
+user.setPassword(passwordTransferCryptoService.decrypt(user.getPassword()));
+```
+
+要求：
+- 只改 `/login`
+- 不改 `loginWithoutCaptcha`
+- 解密失败直接抛错，不追加明文兼容分支
+
+- [ ] **Step 4: 重新运行登录/注册测试**
+
+Run: `mvn -pl ruoyi-admin -am -Dtest=SysLoginControllerPasswordTransferTest,SysRegisterControllerPasswordTransferTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysLoginController.java ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysRegisterController.java ruoyi-admin/src/test/java/com/ruoyi/web/controller/system/SysLoginControllerPasswordTransferTest.java ruoyi-admin/src/test/java/com/ruoyi/web/controller/system/SysRegisterControllerPasswordTransferTest.java
+git commit -m "接入登录注册密码解密"
+```
+
+### Task 3: 接入个人修改密码接口解密
+
+**Files:**
+- Modify: `ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysProfileController.java`
+- Create: `ruoyi-admin/src/test/java/com/ruoyi/web/controller/system/SysProfileControllerPasswordTransferTest.java`
+
+- [ ] **Step 1: 写修改密码失败测试**
+
+```java
+mockMvc.perform(put("/system/user/profile/updatePwd")
+        .contentType(MediaType.APPLICATION_JSON)
+        .content("{\"oldPassword\":\"oldCipher\",\"newPassword\":\"newCipher\"}"))
+    .andExpect(status().isOk());
+
+verify(passwordTransferCryptoService).decrypt("oldCipher");
+verify(passwordTransferCryptoService).decrypt("newCipher");
+```
+
+- [ ] **Step 2: 运行测试确认失败**
+
+Run: `mvn -pl ruoyi-admin -am -Dtest=SysProfileControllerPasswordTransferTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: FAIL，`updatePwd` 尚未解密 `oldPassword`、`newPassword`
+
+- [ ] **Step 3: 在 `updatePwd` 开头显式解密两个字段**
+
+```java
+String oldPassword = passwordTransferCryptoService.decrypt(params.get("oldPassword"));
+String newPassword = passwordTransferCryptoService.decrypt(params.get("newPassword"));
+```
+
+要求：
+- 仅在解密成功后继续旧密码校验
+- 不处理 `confirmPassword`
+- 保持原有报错文案和 BCrypt 入库逻辑
+
+- [ ] **Step 4: 重新运行测试**
+
+Run: `mvn -pl ruoyi-admin -am -Dtest=SysProfileControllerPasswordTransferTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysProfileController.java ruoyi-admin/src/test/java/com/ruoyi/web/controller/system/SysProfileControllerPasswordTransferTest.java
+git commit -m "接入个人修改密码解密"
+```
+
+### Task 4: 接入管理员新增用户与重置密码接口解密
+
+**Files:**
+- Modify: `ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysUserController.java`
+- Create: `ruoyi-admin/src/test/java/com/ruoyi/web/controller/system/SysUserControllerPasswordTransferTest.java`
+
+- [ ] **Step 1: 写新增用户与重置密码失败测试**
+
+```java
+mockMvc.perform(post("/system/user")
+        .contentType(MediaType.APPLICATION_JSON)
+        .content("{\"userName\":\"u1\",\"nickName\":\"n1\",\"deptId\":1,\"password\":\"cipher\"}"));
+
+verify(passwordTransferCryptoService).decrypt("cipher");
+```
+
+```java
+mockMvc.perform(put("/system/user/resetPwd")
+        .contentType(MediaType.APPLICATION_JSON)
+        .content("{\"userId\":2,\"password\":\"cipher\"}"));
+
+verify(passwordTransferCryptoService).decrypt("cipher");
+```
+
+- [ ] **Step 2: 运行测试确认失败**
+
+Run: `mvn -pl ruoyi-admin -am -Dtest=SysUserControllerPasswordTransferTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: FAIL，新增用户和重置密码入口尚未调用解密
+
+- [ ] **Step 3: 在 `add` 与 `resetPwd` 中先解密后继续原逻辑**
+
+```java
+user.setPassword(passwordTransferCryptoService.decrypt(user.getPassword()));
+user.setPassword(SecurityUtils.encryptPassword(user.getPassword()));
+```
+
+要求：
+- 仅对 `add`、`resetPwd` 补解密
+- `edit` 不动
+- 仍保留现有权限校验与数据范围校验
+
+- [ ] **Step 4: 重新运行测试**
+
+Run: `mvn -pl ruoyi-admin -am -Dtest=SysUserControllerPasswordTransferTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysUserController.java ruoyi-admin/src/test/java/com/ruoyi/web/controller/system/SysUserControllerPasswordTransferTest.java
+git commit -m "接入用户密码接口解密"
+```
+
+### Task 5: 汇总验证与后端实施记录
+
+**Files:**
+- Create: `doc/implementation-report-2026-03-30-login-password-encryption-backend.md`
+
+- [ ] **Step 1: 运行后端全部目标测试**
+
+Run: `mvn -pl ruoyi-admin,ruoyi-framework -am -Dtest=PasswordTransferCryptoServiceTest,SysLoginControllerPasswordTransferTest,SysRegisterControllerPasswordTransferTest,SysProfileControllerPasswordTransferTest,SysUserControllerPasswordTransferTest -Dsurefire.failIfNoSpecifiedTests=false test`
+Expected: PASS，所有新增后端测试通过
+
+- [ ] **Step 2: 手工核对 `/login/test` 未被改动**
+
+Run: `git diff -- ruoyi-admin/src/main/java/com/ruoyi/web/controller/system/SysLoginController.java`
+Expected: 仅 `/login` 增加解密调用，`loginWithoutCaptcha` 无行为变化
+
+- [ ] **Step 3: 写后端实施记录**
+
+```markdown
+# 密码加密传输后端实施记录
+- 新增密码解密服务
+- 接入 5 个正式接口中的后端入口
+- 保持 `/login/test` 不变
+- 补充控制器与服务测试
+```
+
+- [ ] **Step 4: 再次检查文档路径与 git 状态**
+
+Run: `git status --short`
+Expected: 仅包含后端实现文件与 `doc/implementation-report-2026-03-30-login-password-encryption-backend.md`
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add doc/implementation-report-2026-03-30-login-password-encryption-backend.md
+git commit -m "完成密码加密传输后端实现"
+```

docs/superpowers/plans/2026-03-30-login-password-encryption-frontend-plan.md

@@ -0,0 +1,258 @@
+# Frontend Password Transfer Encryption Implementation Plan
+
+> **For agentic workers:** REQUIRED: Use superpowers:subagent-driven-development (if subagents available) or superpowers:executing-plans to implement this plan. Steps use checkbox (`- [ ]`) syntax for tracking.
+
+**Goal:** 为正式密码提交接口补上前端加密发送能力，让登录、注册、个人修改密码、管理员重置密码、管理员新增用户在请求发出前只对密码字段做 AES 加密。
+
+**Architecture:** 在 `ruoyi-ui` 新增统一的密码传输加密工具和字段映射辅助方法，由 API 层在提交请求前克隆并加密受控字段。页面组件继续持有明文表单值，现有表单校验和交互文案保持不变。
+
+**Tech Stack:** Vue 2、Axios、`crypto-js`、Node 脚本测试、Vue CLI 4
+
+---
+
+### Task 1: 搭建前端加密工具与测试基线
+
+**Files:**
+- Modify: `ruoyi-ui/package.json`
+- Modify: `ruoyi-ui/package-lock.json`
+- Create: `ruoyi-ui/src/utils/passwordTransfer.js`
+- Create: `ruoyi-ui/tests/password-transfer-api.test.js`
+
+- [ ] **Step 1: 写前端失败测试脚本**
+
+```js
+const encrypted = encryptPasswordFields(
+  { password: 'admin123', code: '8888' },
+  ['password'],
+  '1234567890abcdef'
+)
+
+assert.notStrictEqual(encrypted.password, 'admin123')
+assert.strictEqual(encrypted.code, '8888')
+```
+
+```js
+const requestConfig = login('admin', 'admin123', '8888', 'uuid-1')
+assert.strictEqual(requestConfig.data.password !== 'admin123', true)
+```
+
+- [ ] **Step 2: 运行测试确认当前失败**
+
+Run: `cd ruoyi-ui && node tests/password-transfer-api.test.js`
+Expected: FAIL，工具文件或 API 加密行为尚不存在
+
+- [ ] **Step 3: 新增依赖、脚本和最小工具实现**
+
+```js
+import CryptoJS from 'crypto-js'
+
+export function encryptPasswordFields(payload, fields, key) {
+  const next = { ...payload }
+  fields.forEach((field) => {
+    if (next[field]) {
+      next[field] = CryptoJS.AES.encrypt(next[field], CryptoJS.enc.Utf8.parse(key), {
+        mode: CryptoJS.mode.ECB,
+        padding: CryptoJS.pad.Pkcs7
+      }).toString()
+    }
+  })
+  return next
+}
+```
+
+```json
+"scripts": {
+  "test:password-transfer": "node tests/password-transfer-api.test.js"
+}
+```
+
+- [ ] **Step 4: 重新运行前端测试**
+
+Run: `cd ruoyi-ui && npm run test:password-transfer`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-ui/package.json ruoyi-ui/package-lock.json ruoyi-ui/src/utils/passwordTransfer.js ruoyi-ui/tests/password-transfer-api.test.js
+git commit -m "新增前端密码加密工具"
+```
+
+### Task 2: 接入登录与注册接口加密
+
+**Files:**
+- Modify: `ruoyi-ui/src/api/login.js`
+
+- [ ] **Step 1: 扩展测试覆盖登录与注册 API**
+
+```js
+const loginConfig = login('admin', 'admin123', '8888', 'uuid-1')
+assert.notStrictEqual(loginConfig.data.password, 'admin123')
+assert.strictEqual(loginConfig.data.username, 'admin')
+
+const registerConfig = register({ username: 'u1', password: 'p1', confirmPassword: 'p1', code: '8888' })
+assert.notStrictEqual(registerConfig.data.password, 'p1')
+assert.strictEqual(registerConfig.data.confirmPassword, 'p1')
+```
+
+- [ ] **Step 2: 运行测试确认失败**
+
+Run: `cd ruoyi-ui && npm run test:password-transfer`
+Expected: FAIL，`login.js` 尚未对正式接口密码字段加密
+
+- [ ] **Step 3: 在 API 层接入加密工具**
+
+```js
+const data = encryptPasswordFields({ username, password, code, uuid }, ['password'], process.env.VUE_APP_PASSWORD_TRANSFER_KEY)
+```
+
+```js
+const payload = encryptPasswordFields(data, ['password'], process.env.VUE_APP_PASSWORD_TRANSFER_KEY)
+```
+
+要求：
+- 只加密 `password`
+- 保持字段名不变
+- 不在页面组件中写加密逻辑
+
+- [ ] **Step 4: 重新运行前端测试**
+
+Run: `cd ruoyi-ui && npm run test:password-transfer`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-ui/src/api/login.js ruoyi-ui/tests/password-transfer-api.test.js
+git commit -m "接入登录注册密码加密"
+```
+
+### Task 3: 接入个人修改密码接口加密
+
+**Files:**
+- Modify: `ruoyi-ui/src/api/system/user.js`
+
+- [ ] **Step 1: 扩展测试覆盖 `updateUserPwd`**
+
+```js
+const config = updateUserPwd('oldPwd', 'newPwd')
+assert.notStrictEqual(config.data.oldPassword, 'oldPwd')
+assert.notStrictEqual(config.data.newPassword, 'newPwd')
+```
+
+- [ ] **Step 2: 运行测试确认失败**
+
+Run: `cd ruoyi-ui && npm run test:password-transfer`
+Expected: FAIL，`updateUserPwd` 仍发送明文
+
+- [ ] **Step 3: 只在 API 层加密两个密码字段**
+
+```js
+const data = encryptPasswordFields(
+  { oldPassword, newPassword },
+  ['oldPassword', 'newPassword'],
+  process.env.VUE_APP_PASSWORD_TRANSFER_KEY
+)
+```
+
+要求：
+- 页面 `resetPwd.vue` 不改
+- 继续让前端表单在明文状态下完成确认密码校验
+
+- [ ] **Step 4: 重新运行测试**
+
+Run: `cd ruoyi-ui && npm run test:password-transfer`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-ui/src/api/system/user.js ruoyi-ui/tests/password-transfer-api.test.js
+git commit -m "接入个人修改密码加密"
+```
+
+### Task 4: 接入管理员新增用户与重置密码接口加密
+
+**Files:**
+- Modify: `ruoyi-ui/src/api/system/user.js`
+- Modify: `ruoyi-ui/.env.development`
+- Modify: `ruoyi-ui/.env.staging`
+- Modify: `ruoyi-ui/.env.production`
+
+- [ ] **Step 1: 扩展测试覆盖 `addUser` 与 `resetUserPwd`**
+
+```js
+const addConfig = addUser({ userName: 'u1', password: 'initPwd', nickName: 'n1' })
+assert.notStrictEqual(addConfig.data.password, 'initPwd')
+
+const resetConfig = resetUserPwd(2, 'resetPwd')
+assert.notStrictEqual(resetConfig.data.password, 'resetPwd')
+```
+
+- [ ] **Step 2: 运行测试确认失败**
+
+Run: `cd ruoyi-ui && npm run test:password-transfer`
+Expected: FAIL，`addUser`、`resetUserPwd` 仍发送明文
+
+- [ ] **Step 3: 在受控接口接入加密并补环境配置**
+
+```js
+const payload = encryptPasswordFields(data, ['password'], process.env.VUE_APP_PASSWORD_TRANSFER_KEY)
+```
+
+```dotenv
+VUE_APP_PASSWORD_TRANSFER_KEY=请替换为16位固定密钥
+```
+
+要求：
+- 只改 `addUser`、`resetUserPwd`
+- `updateUser` 不做密码加密处理
+- 三套环境文件都补同名配置项
+
+- [ ] **Step 4: 重新运行测试**
+
+Run: `cd ruoyi-ui && npm run test:password-transfer`
+Expected: PASS
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add ruoyi-ui/src/api/system/user.js ruoyi-ui/.env.development ruoyi-ui/.env.staging ruoyi-ui/.env.production ruoyi-ui/tests/password-transfer-api.test.js
+git commit -m "接入用户密码接口前端加密"
+```
+
+### Task 5: 汇总验证与前端实施记录
+
+**Files:**
+- Create: `doc/implementation-report-2026-03-30-login-password-encryption-frontend.md`
+
+- [ ] **Step 1: 运行前端目标测试**
+
+Run: `cd ruoyi-ui && npm run test:password-transfer`
+Expected: PASS，受控 API 的密码字段都按预期加密
+
+- [ ] **Step 2: 运行一次前端构建验证**
+
+Run: `cd ruoyi-ui && npm run build:stage`
+Expected: PASS，新增依赖、环境变量与 API 修改不影响构建
+
+- [ ] **Step 3: 写前端实施记录**
+
+```markdown
+# 密码加密传输前端实施记录
+- 新增强制密码字段加密工具
+- 登录、注册、修改密码、重置密码、新增用户在 API 层加密
+- 页面表单逻辑保持不变
+```
+
+- [ ] **Step 4: 再次检查 git 状态**
+
+Run: `git status --short`
+Expected: 仅包含前端实现文件与 `doc/implementation-report-2026-03-30-login-password-encryption-frontend.md`
+
+- [ ] **Step 5: 提交本任务**
+
+```bash
+git add doc/implementation-report-2026-03-30-login-password-encryption-frontend.md
+git commit -m "完成密码加密传输前端实现"
+```

docs/superpowers/specs/2026-03-30-login-password-encryption-design.md

@@ -0,0 +1,265 @@
+# 系统登录与密码类接口加密传输设计文档
+
+## 1. 背景
+
+当前系统登录、注册、修改密码、重置密码、新增用户等正式接口，在请求体中直接传输明文密码。后端在收到密码后再执行现有的登录校验或 BCrypt 加密入库逻辑。
+
+本次需求是在不改变现有业务语义的前提下，为所有正式密码提交接口增加“密码加密传输”能力，避免密码以明文形式直接出现在接口请求体中。
+
+## 2. 已确认约束
+
+- 采用对称加密方案
+- 前端使用固定密钥加密密码字段
+- 后端使用同一固定密钥解密密码字段
+- 覆盖所有正式密码提交接口
+- 明确不包含 `/login/test`
+- 不新增兼容性或补丁性方案
+- 不允许“解密失败后按明文继续处理”
+- 保持最短路径实现，不改现有账号、认证、密码存储主逻辑
+
+## 3. 接口范围
+
+本次加密传输仅覆盖以下正式接口：
+
+- `/login`
+- `/register`
+- `/system/user/profile/updatePwd`
+- `/system/user/resetPwd`
+- `/system/user`
+
+各接口需要处理的密码字段如下：
+
+- `/login`：`password`
+- `/register`：`password`
+- `/system/user/profile/updatePwd`：`oldPassword`、`newPassword`
+- `/system/user/resetPwd`：`password`
+- `/system/user`：`password`
+
+以下接口不在本次范围内：
+
+- `/login/test`
+- 任何不提交密码字段的接口
+
+## 4. 现状分析
+
+### 4.1 前端现状
+
+当前前端接口调用中，登录、注册、个人修改密码、管理员重置密码、管理员新增用户都直接提交明文密码字段。仓库中虽然已经存在 `JSEncrypt` 工具，但仅用于“记住密码”场景下 Cookie 的本地存储加密，并没有用于登录或其他正式密码接口。
+
+### 4.2 后端现状
+
+后端正式接口的密码处理链路如下：
+
+- 登录接口直接读取 `LoginBody.password` 并交给认证流程
+- 注册接口直接读取 `RegisterBody.password` 并执行 BCrypt 加密入库
+- 修改密码接口直接读取 `oldPassword`、`newPassword` 并执行旧密码校验和新密码入库
+- 管理员重置密码和新增用户接口直接读取 `SysUser.password` 并执行 BCrypt 加密
+
+现有后端没有统一的密码传输解密层，因此如果直接在前端加密而后端不解密，现有校验链路会全部失效。
+
+## 5. 方案对比
+
+### 方案一：保留现有字段名，前端加密后提交，后端统一解密
+
+做法：
+
+- 保持现有请求结构不变
+- 前端在 API 提交前仅加密密码字段
+- 后端在控制器进入业务逻辑前，对密码字段统一解密
+
+优点：
+
+- 改动路径最短
+- 页面、DTO、控制器入参结构基本不变
+- 现有业务校验和 BCrypt 逻辑可直接复用
+
+缺点：
+
+- 需要明确每个接口的密码字段清单
+- 前后端都要维护一份受控字段映射
+
+### 方案二：新增专用密文字段
+
+做法：
+
+- 每个接口新增 `encryptedPassword`、`encryptedOldPassword` 等字段
+- 后端只处理密文字段
+
+优点：
+
+- 语义清楚
+- 明文和密文边界直观
+
+缺点：
+
+- 改动面大
+- 前后端 DTO、表单、测试样例都要整体调整
+- 不符合本次最短路径实现原则
+
+### 方案三：全局请求拦截器加密 + 全局参数层解密
+
+做法：
+
+- 前端在 axios 拦截器中按 URL 自动加密密码字段
+- 后端在过滤器或参数解析层统一自动解密
+
+优点：
+
+- 页面层改动最少
+
+缺点：
+
+- 隐式逻辑过重
+- 对不同入参类型的接口可读性差
+- 不利于后续定位问题
+
+## 6. 设计结论
+
+采用方案一。
+
+本次仅在接口边界增加密码加密传输能力，业务层继续只处理解密后的明文密码。传输链路如下：
+
+1. 前端表单收集用户输入的密码明文
+2. API 提交前，使用固定对称密钥加密密码字段
+3. 后端控制器收到请求后，先对约定密码字段解密
+4. 解密成功后继续走现有业务逻辑
+5. 解密失败时直接返回错误，不进入后续业务处理
+
+`/login/test` 保持现状，不加入加密与解密逻辑。
+
+## 7. 前端设计
+
+### 7.1 设计目标
+
+前端只负责“在请求发出前对密码字段加密”，不在页面组件中分散实现逻辑，也不修改表单字段命名。
+
+### 7.2 收口位置
+
+加密逻辑收口在 API 调用层，不放在页面组件层。
+
+原因：
+
+- 登录页、注册页、个人中心、用户管理都存在密码提交场景
+- 若每个页面独立处理，加密逻辑容易分散和重复
+- API 层更容易统一维护接口与字段映射
+
+### 7.3 前端改动点
+
+- 新增统一的对称加密工具
+- 新增“密码字段加密”辅助方法
+- 在以下接口调用前对对应字段加密：
+  - 登录
+  - 注册
+  - 个人修改密码
+  - 管理员重置密码
+  - 管理员新增用户
+- 保持请求字段名不变
+
+### 7.4 配置方式
+
+前端固定密钥通过环境配置读取，不直接散落在业务代码中。
+
+## 8. 后端设计
+
+### 8.1 设计目标
+
+后端只负责“在进入现有业务逻辑前将密码字段解密为明文”，不改动现有认证和密码存储主流程。
+
+### 8.2 收口位置
+
+解密逻辑收口在控制器入口之后、业务逻辑之前，由统一的密码解密工具完成。
+
+原因：
+
+- 当前接口入参类型不统一，包含 `LoginBody`、`RegisterBody`、`SysUser` 和 `Map<String, String>`
+- 如果直接放到全局过滤器或参数解析层，会增加隐式复杂度
+- 控制器显式调用统一解密工具，路径更短、更直观
+
+### 8.3 后端改动点
+
+- 新增统一的对称解密工具
+- 新增面向不同入参类型的密码字段解密方法
+- 在以下正式接口进入业务逻辑前显式解密：
+  - `SysLoginController.login`
+  - `SysRegisterController.register`
+  - `SysProfileController.updatePwd`
+  - `SysUserController.resetPwd`
+  - `SysUserController.add`
+- 不改动 `SysLoginController.loginWithoutCaptcha`
+
+### 8.4 业务链路保持不变
+
+解密成功后继续沿用现有逻辑：
+
+- 登录继续走认证管理器与 `SysPasswordService`
+- 注册继续走 BCrypt 加密入库
+- 个人修改密码继续先校验旧密码，再加密新密码入库
+- 管理员重置密码和新增用户继续走 BCrypt 加密入库
+
+## 9. 配置设计
+
+前后端分别维护固定对称密钥配置：
+
+- 前端从环境变量读取固定密钥
+- 后端从 `application.yml` 读取固定密钥
+
+本次设计默认前后端使用同一把固定密钥，不涉及动态下发、轮换或多套密钥管理。
+
+## 10. 错误处理
+
+本次只采用单一路径，不做兼容分支：
+
+- 受控正式接口收到密码字段后，后端默认按密文处理
+- 任一密码字段解密失败，接口直接返回错误
+- 不允许“尝试解密失败后继续按明文处理”
+- 不允许只加密部分密码字段后继续流转
+
+修改密码接口中，`oldPassword` 与 `newPassword` 必须同时成功解密后才能进入现有校验流程。
+
+## 11. 非目标
+
+本次不包含以下内容：
+
+- 不修改 `/login/test`
+- 不改造密码存储方式
+- 不改造现有 BCrypt 校验逻辑
+- 不引入非对称加密
+- 不增加密钥动态下发能力
+- 不增加明密文双通道兼容逻辑
+- 不修改与密码无关的请求字段
+
+## 12. 风险与控制
+
+主要风险如下：
+
+1. 前后端固定密钥不一致，会导致所有正式密码接口失败
+2. 某些密码字段漏加密或漏解密，会导致登录失败或入库异常
+3. 个人修改密码接口包含多个密码字段，若字段映射错误，会导致旧密码校验失败
+
+控制方式：
+
+- 前后端统一约定固定密钥配置名称与用途
+- 将密码字段清单明确写入实现计划
+- 将正式接口逐一纳入测试验证
+- 保持 `/login/test` 完全不接入，避免影响现有测试用途
+
+## 13. 验证方案
+
+实施后至少验证以下场景：
+
+1. `/login` 提交加密后的 `password` 可以正常登录
+2. `/register` 提交加密后的 `password` 可以正常注册
+3. `/system/user/profile/updatePwd` 提交加密后的 `oldPassword`、`newPassword` 可以正常修改密码
+4. `/system/user/resetPwd` 提交加密后的 `password` 可以正常重置密码
+5. `/system/user` 提交加密后的 `password` 可以正常新增用户
+6. 受控正式接口在密文非法时直接失败
+7. `/login/test` 仍按现有方式运行，不受本次改动影响
+
+## 14. 实施范围
+
+- 前端：登录、注册、个人中心、用户管理相关 API 和密码加密工具
+- 后端：登录、注册、个人中心、用户管理相关控制器和密码解密工具
+- 配置：前端环境配置、后端应用配置
+- 数据库：无表结构改动
+
+本次属于接口边界增强，不涉及数据库结构和核心认证机制重构。

fix-encoding.md

@@ -1,75 +0,0 @@
-# 修复中文乱码问题
-
-## 问题原因
-
-1. 数据库连接 URL 使用的是 `characterEncoding=utf8` 而不是 `utf8mb4`
-2. 已插入的数据使用错误的编码保存
-
-## 解决步骤
-
-### 步骤 1: 清理乱码数据
-
-在数据库中执行：
-
-```sql
--- 删除表中的乱码数据
-DELETE FROM loan_pricing_workflow;
-```
-
-或删除表重建：
-
-```sql
-DROP TABLE IF EXISTS `loan_pricing_workflow`;
--- 然后重新执行 sql/loan_pricing_workflow.sql
-```
-
-### 步骤 2: 重启服务
-
-配置文件已更新，需要重启后端服务使配置生效：
-
-```bash
-# 停止当前服务
-pkill -f "ruoyi-admin.jar"
-
-# 重新打包（可选，如果没有修改代码）
-cd d:\利率定价\loan-pricing-892\loan-pricing-892-v2.0
-mvn clean package -Dmaven.test.skip=true
-
-# 启动服务
-cd ruoyi-admin/target
-java -jar ruoyi-admin.jar
-```
-
-### 步骤 3: 重新执行测试
-
-```bash
-cd d:\利率定价\loan-pricing-892\loan-pricing-892-v2.0
-bash run-api-tests.sh
-```
-
-## 配置说明
-
-已修改的配置文件：`ruoyi-admin/src/main/resources/application-dev.yml`
-
-修改前：
-```yaml
-url: jdbc:mysql://...?useUnicode=true&characterEncoding=utf8&...
-```
-
-修改后：
-```yaml
-url: jdbc:mysql://...?useUnicode=true&characterEncoding=utf8mb4&...
-```
-
-## 验证方法
-
-重启服务并插入新数据后，检查数据库：
-
-```sql
-SELECT serial_num, cust_name, cust_type, guar_type FROM loan_pricing_workflow;
-```
-
-中文应该正常显示，例如：
-- cust_name: "张三" (而不是乱码)
-- cust_type: "个人" (而不是乱码)
-- guar_type: "信用" (而不是乱码)

openspec/AGENTS.md

@@ -1,456 +0,0 @@
-# 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 --no-interactive` 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 --no-interactive` 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 --no-interactive` 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 --no-interactive
-```
-
-### 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 --no-interactive
-
-# 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 --no-interactive
-```
-
-## 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 --no-interactive  # 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.

openspec/changes/add-bargaining-pool-display/design.md

@@ -1,186 +0,0 @@
-# Design: 议价池显示组件
-
-## Overview
-
-本文档描述议价池显示组件的详细设计，包括组件结构、数据流、样式规范和实现细节。
-
-## Component Architecture
-
-### 组件层次结构
-
-```
-detail.vue (流程详情页面)
-├── left-panel (左侧关键信息卡片)
-└── right-panel (右侧面板)
-    ├── detail-card (流程详情卡片)
-    ├── ModelOutputDisplay (模型输出组件) [已存在]
-    └── BargainingPoolDisplay (议价池显示组件) [新增]
-```
-
-### 组件职责
-
-| 组件 | 职责 |
-|------|------|
-| `detail.vue` | 流程详情页面容器，负责数据获取和子组件协调 |
-| `BargainingPoolDisplay.vue` | 议价池数据展示，独立封装议价池相关的 UI 和逻辑 |
-
-## Component Specification
-
-### BargainingPoolDisplay.vue
-
-#### Props
-
-| 属性名 | 类型 | 默认值 | 说明 |
-|--------|------|--------|------|
-| `branchPool` | Number/String | 0 | 网点议价池 |
-| `subBranchPool` | Number/String | 0 | 支行议价池 |
-| `privateDomainPool` | Number/String | 0 | 私域池 |
-
-#### Template Structure
-
-```vue
-<template>
-  <el-card class="bargaining-pool-card">
-    <div slot="header" class="card-header">
-      <span class="card-title">议价池</span>
-    </div>
-    <el-descriptions :column="3" border size="small">
-      <el-descriptions-item label="网点议价池">
-        {{ displayBranchPool }}
-      </el-descriptions-item>
-      <el-descriptions-item label="支行议价池">
-        {{ displaySubBranchPool }}
-      </el-descriptions-item>
-      <el-descriptions-item label="私域池">
-        {{ displayPrivateDomainPool }}
-      </el-descriptions-item>
-    </el-descriptions>
-  </el-card>
-</template>
-```
-
-#### Computed Properties
-
-| 属性名 | 说明 |
-|--------|------|
-| `displayBranchPool` | 返回网点议价池的显示值，处理 null/undefined/空字符串为 '0' |
-| `displaySubBranchPool` | 返回支行议价池的显示值，处理 null/undefined/空字符串为 '0' |
-| `displayPrivateDomainPool` | 返回私域池的显示值，处理 null/undefined/空字符串为 '0' |
-
-#### Style Specification
-
-议价池卡片样式将与 `ModelOutputDisplay` 保持一致：
-
-```scss
-.bargaining-pool-card {
-  // 与 model-output-card 相同的样式
-  ::v-deep .el-card__header {
-    padding: 16px 20px;
-    background-color: #fafafa;
-    border-bottom: 1px solid #ebeef5;
-  }
-
-  .card-header {
-    display: flex;
-    align-items: center;
-
-    .card-title {
-      font-size: 16px;
-      font-weight: 500;
-      color: #303133;
-    }
-  }
-
-  ::v-deep .el-card__body {
-    padding: 20px;
-  }
-}
-```
-
-## Data Flow
-
-### API 响应结构（预期）
-
-```javascript
-{
-  "data": {
-    "loanPricingWorkflow": { ... },
-    "modelRetailOutputFields": { ... },
-    "modelCorpOutputFields": { ... },
-    "bargainingPool": {  // 新增字段
-      "branchPool": 10,      // 网点议价池
-      "subBranchPool": 5,    // 支行议价池
-      "privateDomainPool": 3 // 私域池
-    }
-  }
-}
-```
-
-### 组件集成
-
-在 `detail.vue` 中：
-
-```javascript
-// data
-bargainingPool: null,
-
-// created() 中获取数据
-getWorkflow(serialNum).then(response => {
-  this.workflowDetail = response.data.loanPricingWorkflow
-  this.retailOutput = response.data.modelRetailOutputFields
-  this.corpOutput = response.data.modelCorpOutputFields
-  this.bargainingPool = response.data.bargainingPool  // 新增
-  this.loading = false
-})
-```
-
-```vue
-<!-- template 中使用组件 -->
-<BargainingPoolDisplay
-  :branch-pool="bargainingPool?.branchPool"
-  :sub-branch-pool="bargainingPool?.subBranchPool"
-  :private-domain-pool="bargainingPool?.privateDomainPool"
-/>
-```
-
-## Error Handling
-
-### 数据缺失处理
-
-当 API 响应中没有议价池数据时：
-- 组件使用默认值 0 显示
-- 不显示错误提示
-- 保证页面正常展示
-
-### 值格式化
-
-```javascript
-computed: {
-  displayBranchPool() {
-    const value = this.branchPool
-    if (value === null || value === undefined || value === '') {
-      return '0'
-    }
-    return value
-  },
-  // ... 其他字段类似
-}
-```
-
-## Testing Considerations
-
-### 单元测试场景
-1. 组件渲染时显示默认值 0
-2. 传入正确的议价池数据时正确显示
-3. 处理 null/undefined 值时显示 0
-
-### 集成测试场景
-1. 流程详情页面加载时议价池卡片正确显示
-2. 议价池卡片位置在模型输出卡片下方
-3. 样式与模型输出卡片保持一致
-
-## Future Enhancements
-
-1. **后端数据对接**：当后端提供议价池 API 时，移除默认值逻辑
-2. **单位显示**：确认议价池数值单位（BP 或金额）后添加单位标签
-3. **交互功能**：可能需要添加议价池的编辑或调整功能

openspec/changes/add-bargaining-pool-display/proposal.md

@@ -1,85 +0,0 @@
-# Proposal: 添加议价池显示组件
-
-## Summary
-
-在流程详情页面中，在"模型输出"卡片下方添加一个新的"议价池"卡片，用于展示网点议价池、支行议价池和私域池三个字段。默认值均为 0。
-
-## Motivation
-
-当前流程详情页面展示了模型输出的详细信息，但缺少议价池相关的数据展示。议价池是贷款定价业务中的重要参考指标，需要将其添加到详情页面以便用户查看。
-
-## Proposed Change
-
-### Scope
-仅修改前端流程详情页面，在模型输出组件下方添加议价池显示组件。
-
-### Components Affected
-- `ruoyi-ui/src/views/loanPricing/workflow/detail.vue` - 添加议价池组件
-
-### Components to Create
-- `ruoyi-ui/src/views/loanPricing/workflow/components/BargainingPoolDisplay.vue` - 新建议价池显示组件
-
-## Design Approach
-
-### UI 结构
-议价池卡片将使用与模型输出卡片相同的样式风格，包含：
-- 卡片标题：议价池
-- 三个字段展示：
-  - 网点议价池（默认值：0）
-  - 支行议价池（默认值：0）
-  - 私域池（默认值：0）
-
-### 组件设计
-- 创建独立的 `BargainingPoolDisplay.vue` 组件
-- 使用 `el-descriptions` 组件展示字段
-- 支持通过 props 传入议价池数据
-- 默认值处理：当数据为空或未定义时显示 0
-
-### 数据来源
-- 议价池数据将从后端 API 响应中获取
-- 暂时使用默认值 0，后续由后端提供实际数据
-
-## Alternatives Considered
-
-1. **将议价池字段添加到模型输出组件内部**
-   - 优点：减少组件数量
-   - 缺点：模型输出组件已比较复杂，议价池是独立的业务概念，应独立展示
-   - 结论：不采用
-
-2. **将议价池字段添加到流程详情卡片中**
-   - 优点：集中展示流程相关信息
-   - 缺点：议价池与流程基本信息关联性较弱，与模型输出更相关
-   - 结论：不采用
-
-3. **创建独立的议价池组件（已选方案）**
-   - 优点：职责清晰、易于维护、与模型输出组件并列展示
-   - 缺点：增加一个组件文件
-   - 结论：采用
-
-## Dependencies
-
-- 依赖现有的 `el-card` 和 `el-descriptions` 组件
-- 依赖后端 API 返回议价池数据（当前可使用默认值）
-
-## Rollout Plan
-
-1. 创建 `BargainingPoolDisplay.vue` 组件
-2. 在 `detail.vue` 中引入并使用该组件
-3. 传递议价池数据（当前使用默认值）
-4. 测试页面展示效果
-
-## Success Criteria
-
-- 议价池卡片正确显示在模型输出卡片下方
-- 三个字段（网点议价池、支行议价池、私域池）正确显示
-- 默认值显示为 0
-- 样式与现有卡片保持一致
-
-## Open Questions
-
-1. 议价池数据的具体字段名称是什么？
-   - 待确认：后端 API 中的议价池字段命名
-
-2. 议价池数据的数值类型和单位是什么？
-   - 假设为数值类型（BP 或金额）
-   - 待后端确认

openspec/changes/add-bargaining-pool-display/specs/loan-pricing-workflow-ui/spec.md

@@ -1,42 +0,0 @@
-# loan-pricing-workflow-ui Spec Delta
-
-## ADDED Requirements
-
-### Requirement: 议价池信息展示
-
-系统 SHALL 在流程详情页面的模型输出信息下方展示议价池信息。
-
-#### Scenario: 显示议价池信息
-
-- **WHEN** 用户访问流程详情页面
-- **THEN** 系统在模型输出卡片下方显示"议价池"卡片，包含以下三个字段：
-  - 网点议价池：数值类型，默认值为 0
-  - 支行议价池：数值类型，默认值为 0
-  - 私域池：数值类型，默认值为 0
-
-#### Scenario: 议价池数据格式化
-
-- **WHEN** 议价池数据为 null、undefined 或空字符串
-- **THEN** 系统将显示值格式化为 "0"
-
-#### Scenario: 议价池卡片样式
-
-- **WHEN** 用户查看流程详情页面
-- **THEN** 议价池卡片的样式（标题栏、边框、内边距）与模型输出卡片保持一致
-
-### Requirement: 议价池组件封装
-
-系统 SHALL 将议价池展示功能封装为独立的 Vue 组件。
-
-#### Scenario: 组件独立性
-
-- **WHEN** 议价池显示组件被创建
-- **THEN** 组件文件位于 `ruoyi-ui/src/views/loanPricing/workflow/components/BargainingPoolDisplay.vue`
-
-#### Scenario: 组件 Props 接口
-
-- **WHEN** 父组件使用议价池显示组件
-- **THEN** 组件接收以下 props：
-  - `branch-pool`：网点议价池值（Number/String），默认值为 0
-  - `sub-branch-pool`：支行议价池值（Number/String），默认值为 0
-  - `private-domain-pool`：私域池值（Number/String），默认值为 0

openspec/changes/add-bargaining-pool-display/tasks.md

@@ -1,68 +0,0 @@
-# Tasks: 添加议价池显示组件
-
-## Task List
-
-### 1. 创建议价池显示组件 ✅
-**文件**: `ruoyi-ui/src/views/loanPricing/workflow/components/BargainingPoolDisplay.vue`
-
-**描述**: 创建新的 Vue 组件用于展示议价池信息
-
-**验收标准**:
-- [x] 组件使用 `el-card` 包装，标题为"议价池"
-- [x] 使用 `el-descriptions` 展示三个字段：网点议价池、支行议价池、私域池
-- [x] 定义 props：`branchPool`、`subBranchPool`、`privateDomainPool`，默认值为 0
-- [x] 实现计算属性处理 null/undefined/空字符串，返回 '0'
-- [x] 样式与 `ModelOutputDisplay` 保持一致
-
-**依赖**: 无
-
----
-
-### 2. 在详情页面中引入并使用议价池组件 ✅
-**文件**: `ruoyi-ui/src/views/loanPricing/workflow/detail.vue`
-
-**描述**: 在流程详情页面中引入并配置议价池组件
-
-**验收标准**:
-- [x] 在 `components` 中注册 `BargainingPoolDisplay` 组件
-- [x] 在 `data` 中添加 `bargainingPool: null`
-- [x] 在 `getDetail()` 方法中从 API 响应获取议价池数据：`response.data.bargainingPool`
-- [x] 在 template 中，`ModelOutputDisplay` 组件下方添加 `BargainingPoolDisplay` 组件
-- [x] 传递 props：`:branch-pool`、`:sub-branch-pool`、`:private-domain-pool`
-
-**依赖**: Task 1
-
----
-
-### 3. 验证页面展示效果 ✅
-**描述**: 启动前端开发服务器，验证议价池组件正确显示
-
-**验收标准**:
-- [x] 访问任意流程详情页面
-- [x] 确认议价池卡片显示在模型输出卡片下方
-- [x] 确认三个字段显示为 "0"（默认值）
-- [x] 确认卡片样式与模型输出卡片一致
-
-**依赖**: Task 1, Task 2
-
----
-
-## Dependencies Graph
-
-```
-Task 1 (创建组件) ✅
-    ↓
-Task 2 (集成到详情页) ✅
-    ↓
-Task 3 (验证效果) ✅
-```
-
-## Implementation Notes
-
-- 使用 `&&` 操作符替代可选链 `?.` 以兼容 Vue 2.6
-- 构建验证通过 (`npm run build:prod` 完成)
-
-## Notes
-
-- 当前使用默认值 0，后续后端提供议价池 API 后需要更新数据获取逻辑
-- 议价池数值的单位（BP 或金额）尚未确认，暂不添加单位标签

openspec/changes/add-execute-rate-ui/proposal.md

@@ -1,45 +0,0 @@
-# 提案: 添加执行利率设定前端功能
-
-## 背景
-
-后端已经实现了执行利率设定接口 `PUT /loanPricing/workflow/{serialNum}/executeRate`，并且详情接口 `GET /loanPricing/workflow/{serialNum}` 已经返回 `executeRate` 字段。但前端缺少相应的 UI 交互功能，业务人员无法通过界面设定执行利率。
-
-## 问题
-
-1. 议价池组件中只显示议价池数据，没有执行利率输入框
-2. 前端缺少调用设定执行利率接口的 API 方法
-3. 用户无法通过界面设定或更新执行利率
-
-## 提案概述
-
-在流程详情页面的议价池组件中添加执行利率设定功能，允许业务人员输入执行利率并提交。
-
-### 功能范围
-
-1. **API 方法**
-    - 在 `ruoyi-ui/src/api/loanPricing/workflow.js` 中添加 `setExecuteRate` 方法
-
-2. **议价池组件更新**
-    - 在 `BargainingPoolDisplay.vue` 中添加执行利率输入框和提交按钮
-    - 添加执行利率显示/编辑状态的切换
-    - 支持显示已设定的执行利率值
-    - 添加表单验证（利率格式）
-
-3. **详情页面更新**
-    - 在 `detail.vue` 中传递 `executeRate` 和 `serialNum` 给议价池组件
-    - 添加提交成功后刷新详情的处理
-
-## 影响范围
-
-- 前端 API: `ruoyi-ui/src/api/loanPricing/workflow.js`
-- 前端组件: `ruoyi-ui/src/views/loanPricing/workflow/components/BargainingPoolDisplay.vue`
-- 前端页面: `ruoyi-ui/src/views/loanPricing/workflow/detail.vue`
-- 规范: `loan-pricing-workflow-ui` (添加新需求)
-
-## 设计考虑
-
-1. **UI 位置**: 在议价池组件中添加新行，保持与现有议价池数据显示的一致性
-2. **输入验证**: 利率格式验证（数字，可含小数点，范围合理）
-3. **状态管理**: 编辑/查看状态切换，提交成功后显示最新值
-4. **用户反馈**: 提交成功/失败的提示消息
-5. **权限控制**: 后端接口无需特殊权限，前端暂不添加权限控制

openspec/changes/add-execute-rate-ui/specs/loan-pricing-workflow-ui/spec.md

@@ -1,45 +0,0 @@
-## ADDED Requirements
-
-### Requirement: 执行利率设定
-
-系统 SHALL 在流程详情页面的议价池组件中提供执行利率设定功能，允许用户输入并提交执行利率。
-
-#### Scenario: 显示未设定的执行利率
-
-- **WHEN** 用户在流程详情页面查看议价池组件，且该流程尚未设定执行利率
-- **THEN** 系统在议价池组件中显示"执行利率"行，当前值显示为"-"
-
-#### Scenario: 显示已设定的执行利率
-
-- **WHEN** 用户在流程详情页面查看议价池组件，且该流程已设定执行利率
-- **THEN** 系统在议价池组件中显示"执行利率"行，显示当前设定的执行利率值
-
-#### Scenario: 进入编辑模式
-
-- **WHEN** 用户在议价池组件中点击"执行利率"行的编辑按钮
-- **THEN** 系统切换到编辑模式，显示输入框（预填充当前值或空）、提交按钮和取消按钮
-
-#### Scenario: 提交执行利率成功
-
-- **WHEN** 用户在编辑模式下输入有效的执行利率值并点击提交按钮
-- **THEN** 系统调用 `PUT /loanPricing/workflow/{serialNum}/executeRate` 接口，成功后更新显示值为新设定的利率，显示成功提示消息，并退出编辑模式
-
-#### Scenario: 提交执行利率失败
-
-- **WHEN** 用户在编辑模式下提交执行利率，但后端接口返回错误
-- **THEN** 系统保持编辑模式，显示错误提示消息
-
-#### Scenario: 取消编辑
-
-- **WHEN** 用户在编辑模式下点击取消按钮
-- **THEN** 系统退出编辑模式，恢复显示模式，显示原来的执行利率值
-
-#### Scenario: 输入验证
-
-- **WHEN** 用户在编辑模式下输入非法的执行利率值（非数字、超出合理范围）
-- **THEN** 系统在提交前进行验证，显示错误提示，阻止提交
-
-#### Scenario: API 接口调用
-
-- **WHEN** 用户提交执行利率
-- **THEN** 前端调用 `setExecuteRate(serialNum, executeRate)` API 方法，该方法发送 `PUT /loanPricing/workflow/{serialNum}/executeRate` 请求

openspec/changes/add-execute-rate-ui/tasks.md

@@ -1,85 +0,0 @@
-# 实施任务
-
-## 任务清单
-
-1. **添加 API 方法**
-    - 文件: `ruoyi-ui/src/api/loanPricing/workflow.js`
-    - 操作: 添加 `setExecuteRate(serialNum, executeRate)` 方法
-    - 请求: `PUT /loanPricing/workflow/{serialNum}/executeRate`
-    - 验证: 方法添加成功
-
-2. **更新议价池组件 - Props**
-    - 文件: `ruoyi-ui/src/views/loanPricing/workflow/components/BargainingPoolDisplay.vue`
-    - 操作: 添加 `executeRate` 和 `serialNum` props
-    - 验证: props 定义成功
-
-3. **更新议价池组件 - UI**
-    - 文件: `ruoyi-ui/src/views/loanPricing/workflow/components/BargainingPoolDisplay.vue`
-    - 操作: 在 el-descriptions 中添加"执行利率"行，包含：
-      - 显示模式: 显示当前执行利率值（若无则显示"-"）
-      - 编辑模式: 输入框 + 提交按钮 + 取消按钮
-      - 编辑按钮: 在显示模式下点击进入编辑模式
-    - 验证: UI 更新成功
-
-4. **更新议价池组件 - 数据和逻辑**
-    - 文件: `ruoyi-ui/src/views/loanPricing/workflow/components/BargainingPoolDisplay.vue`
-    - 操作:
-      - 添加 `isEditing` 状态变量
-      - 添加 `tempExecuteRate` 临时输入值
-      - 添加 `handleEdit` 方法进入编辑模式
-      - 添加 `handleSubmit` 方法调用 API 并处理响应
-      - 添加 `handleCancel` 方法取消编辑
-      - 添加输入验证（数字格式、范围检查）
-    - 验证: 逻辑实现完整
-
-5. **更新议价池组件 - API 调用**
-    - 文件: `ruoyi-ui/src/views/loanPricing/workflow/components/BargainingPoolDisplay.vue`
-    - 操作: 引入 `setExecuteRate` API 方法
-    - 验证: 引入成功
-
-6. **更新详情页面 - 传递 Props**
-    - 文件: `ruoyi-ui/src/views/loanPricing/workflow/detail.vue`
-    - 操作: 在 BargainingPoolDisplay 组件上传递:
-      - `:execute-rate="workflowDetail.executeRate"`
-      - `:serial-num="workflowDetail.serialNum"`
-      - `@execute-rate-updated="handleExecuteRateUpdated"`
-    - 验证: props 传递正确
-
-7. **前端功能验证**
-    - 操作:
-      - 启动前端服务
-      - 打开流程详情页面
-      - 测试首次设定执行利率
-      - 测试更新已设定的执行利率
-      - 测试输入验证
-      - 测试取消编辑
-    - 验证:
-      - 未设定时显示"-"
-      - 已设定时显示当前值
-      - 点击编辑按钮进入编辑模式
-      - 输入框显示当前值
-      - 提交成功后显示新值并显示成功提示
-      - 取消编辑恢复显示模式
-      - 输入非法值时显示错误提示
-
-## 依赖关系
-
-- 任务 1 必须首先执行（API 方法）
-- 任务 2-5 依次执行（Props -> UI -> 数据逻辑 -> API 调用）
-- 任务 6 依赖任务 2
-- 任务 7 在所有代码任务完成后执行
-
-## 验收标准
-
-- [x] API 方法 `setExecuteRate` 添加成功
-- [x] 议价池组件添加 `executeRate` 和 `serialNum` props
-- [x] 议价池组件显示执行利率行
-- [x] 未设定时显示"-"
-- [x] 已设定时显示当前值
-- [x] 编辑按钮切换到编辑模式
-- [x] 输入框显示当前值
-- [x] 提交按钮调用 API 成功
-- [x] 提交成功后更新显示并显示成功提示
-- [x] 取消按钮恢复显示模式
-- [x] 输入验证正确工作
-- [x] 详情页面正确传递 props

openspec/changes/add-execute-rate/design.md

@@ -1,153 +0,0 @@
-# 设计文档: 执行利率设定接口
-
-## 数据库设计
-
-### 表结构变更
-
-**表名**: `loan_pricing_workflow`
-
-**新增字段**:
-
-| 字段名          | 类型          | 可空 | 默认值  | 说明      |
-|--------------|-------------|----|------|---------|
-| execute_rate | varchar(20) | 是  | NULL | 执行利率(%) |
-
-**DDL**:
-
-```sql
-ALTER TABLE `loan_pricing_workflow`
-ADD COLUMN `execute_rate` varchar(20) DEFAULT NULL COMMENT '执行利率(%)' AFTER `loan_rate`;
-```
-
-## 接口设计
-
-### 设定执行利率接口
-
-**请求方式**: `PUT /loanPricing/workflow/{serialNum}/executeRate`
-
-**权限要求**: 无特殊权限要求（与查询接口一致）
-
-**路径参数**:
-
-| 参数名       | 类型     | 必填 | 说明     |
-|-----------|--------|----|--------|
-| serialNum | String | 是  | 业务方流水号 |
-
-**请求体**:
-
-```json
-{
-  "executeRate": "4.20"
-}
-```
-
-**参数说明**:
-
-| 参数名         | 类型     | 必填 | 说明                   |
-|-------------|--------|----|----------------------|
-| executeRate | String | 是  | 执行利率，字符串格式（如 "4.20"） |
-
-**响应示例**:
-
-成功 (200):
-
-```json
-{
-  "code": 200,
-  "msg": "设定成功"
-}
-```
-
-失败 (404):
-
-```json
-{
-  "code": 404,
-  "msg": "记录不存在"
-}
-```
-
-失败 (500):
-
-```json
-{
-  "code": 500,
-  "msg": "设定失败"
-}
-```
-
-## 代码设计
-
-### Entity 层
-
-**LoanPricingWorkflow.java**
-
-```java
-/** 执行利率(%) */
-private String executeRate;
-```
-
-### Service 层
-
-**ILoanPricingWorkflowService.java**
-
-```java
-/**
- * 设定执行利率
- * @param serialNum 业务方流水号
- * @param executeRate 执行利率
- * @return 是否成功
- */
-boolean setExecuteRate(String serialNum, String executeRate);
-```
-
-**LoanPricingWorkflowServiceImpl.java**
-
-- 实现上述方法
-- 根据 `serialNum` 更新记录的 `execute_rate` 字段
-- MyBatis Plus 会自动填充 `update_by` 和 `update_time`
-
-### Controller 层
-
-**LoanPricingWorkflowController.java**
-
-```java
-/**
- * 设定执行利率
- */
-@Operation(summary = "设定执行利率")
-@Log(title = "利率定价流程", businessType = BusinessType.UPDATE)
-@PutMapping("/{serialNum}/executeRate")
-public AjaxResult setExecuteRate(
-        @Parameter(description = "业务方流水号")
-        @PathVariable("serialNum") String serialNum,
-        @RequestBody Map<String, String> request)
-{
-    String executeRate = request.get("executeRate");
-    boolean success = loanPricingWorkflowService.setExecuteRate(serialNum, executeRate);
-    return success ? success() : error("设定失败");
-}
-```
-
-### VO 层变更
-
-**LoanPricingWorkflowVO.java**
-
-- 添加 `executeRate` 字段到 VO，确保详情接口返回执行利率
-
-## 数据校验
-
-1. **记录存在性**: 根据 `serialNum` 查询记录，不存在则返回 404
-2. **更新结果检查**: 检查更新操作影响行数，0 行表示记录不存在
-3. **格式校验**: 执行利率为字符串格式，前端传递格式化后的值（如 "4.20"）
-
-## 事务处理
-
-- 使用 MyBatis Plus 的 `updateById` 方法，自动处理事务
-- 更新失败时抛出异常，由全局异常处理器处理
-
-## 日志记录
-
-- 使用 `@Log` 注解记录操作日志
-- 日志类型: `BusinessType.UPDATE`
-- 自动记录操作人和操作时间

openspec/changes/add-execute-rate/proposal.md

@@ -1,63 +0,0 @@
-# 提案: 添加执行利率设定接口
-
-## 背景
-
-当前利率定价流程已有测算利率（模型输出计算得到），但缺少最终执行利率的设定功能。业务人员需要根据模型测算结果和实际情况，手动设定最终执行的贷款利率。
-
-## 问题
-
-1. 数据库表中没有存储执行利率的字段
-2. 后端缺少设定执行利率的接口
-3. API 文档需要更新
-
-## 提案概述
-
-为利率定价流程添加执行利率设定功能，允许业务人员为流程记录设定/更新最终执行利率。
-
-### 功能范围
-
-1. **数据库变更**
-    - 在 `loan_pricing_workflow` 表中添加 `execute_rate` 字段
-
-2. **后端接口**
-    - 新增 `PUT /loanPricing/workflow/{serialNum}/executeRate` 接口
-    - 支持设定和更新执行利率
-    - 无需特殊权限控制（与查询接口保持一致）
-    - 可多次修改执行利率
-
-3. **API 文档更新**
-    - 在 `doc/api/loan-pricing-workflow-api.md` 中添加新接口文档
-
-## 影响范围
-
-- 数据库: `loan_pricing_workflow` 表
-- 后端:
-    - Entity: `LoanPricingWorkflow.java`
-    - Service: `ILoanPricingWorkflowService.java` 及实现类
-    - Controller: `LoanPricingWorkflowController.java`
-- 文档: `doc/api/loan-pricing-workflow-api.md`
-
-## 设计考虑
-
-1. **字段类型**: 使用 `varchar(20)` 类型，与 `loan_rate` 保持一致
-2. **可空性**: 允许为 NULL，未设定时返回 null
-3. **可修改性**: 允许多次修改，记录 `update_by` 和 `update_time`
-4. **权限控制**: 暂不加独立权限，所有登录用户可操作（后续可根据需要添加）
-5. **接口语义**: 使用 PUT 语义表示更新资源
-
-## 替代方案
-
-### 方案 A: 添加专门的审批流程（未采纳）
-
-- **优点**: 流程更规范，支持审批
-- **缺点**: 实现复杂度高，当前需求不明确
-
-### 方案 B: 在创建接口中直接支持（未采纳）
-
-- **优点**: 减少接口数量
-- **缺点**: 业务上执行利率是在查看测算结果后设定的，与创建分离更合理
-
-### 方案 C: 独立的设定接口（采纳）
-
-- **优点**: 职责清晰，实现简单，支持多次修改
-- **缺点**: 无明显缺点

openspec/changes/add-execute-rate/specs/loan-pricing-workflow/spec.md

@@ -1,27 +0,0 @@
-# loan-pricing-workflow Delta
-
-## ADDED Requirements
-
-### Requirement: 执行利率设定
-
-系统 SHALL 提供设定执行利率的接口,允许业务人员为利率定价流程设定或更新最终执行利率。
-
-#### Scenario: 设定执行利率
-
-- **WHEN** 业务人员对已存在的利率定价流程调用设定执行利率接口,提供有效的业务方流水号和执行利率值
-- **THEN** 系统更新该流程记录的执行利率字段,返回成功响应,并自动记录更新者和更新时间
-
-#### Scenario: 更新已有执行利率
-
-- **WHEN** 业务人员对已设定执行利率的流程再次调用设定接口
-- **THEN** 系统覆盖更新执行利率为新的值
-
-#### Scenario: 设定不存在的流程
-
-- **WHEN** 业务人员提供的业务方流水号不存在
-- **THEN** 系统返回"记录不存在"的错误信息
-
-#### Scenario: 执行利率在详情中返回
-
-- **WHEN** 业务人员查询流程详情
-- **THEN** 系统在响应数据中包含 `executeRate` 字段(如果已设定则返回值,否则返回 null)

openspec/changes/add-execute-rate/tasks.md

@@ -1,77 +0,0 @@
-# 实施任务
-
-## 任务清单
-
-1. **添加数据库字段**
-    - 文件: 创建 SQL 迁移脚本 `sql/add_execute_rate_field.sql`
-    - 操作: 在 `loan_pricing_workflow` 表中添加 `execute_rate` 字段
-    -
-    DDL: `ALTER TABLE loan_pricing_workflow ADD COLUMN execute_rate varchar(20) DEFAULT NULL COMMENT '执行利率(%)' AFTER loan_rate;`
-    - 验证: 字段添加成功
-
-2. **更新 Entity 类**
-    - 文件: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/entity/LoanPricingWorkflow.java`
-    - 操作: 添加 `executeRate` 字段及注释
-    - 验证: 字段添加成功，位于 `loanRate` 字段之后
-
-3. **更新 VO 类**
-    - 文件: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/domain/vo/LoanPricingWorkflowVO.java`
-    - 操作: 添加 `executeRate` 字段及注释
-    - 验证: 字段添加成功
-
-4. **更新 Service 接口**
-    - 文件: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/ILoanPricingWorkflowService.java`
-    - 操作: 添加 `setExecuteRate(String serialNum, String executeRate)` 方法声明
-    - 验证: 方法添加成功
-
-5. **实现 Service 方法**
-    - 文件: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/service/impl/LoanPricingWorkflowServiceImpl.java`
-    - 操作: 实现 `setExecuteRate` 方法
-    - 逻辑: 根据 serialNum 查询记录，更新 execute_rate 字段
-    - 验证: 方法实现完成
-
-6. **添加 Controller 接口**
-    - 文件: `ruoyi-loan-pricing/src/main/java/com/ruoyi/loanpricing/controller/LoanPricingWorkflowController.java`
-    - 操作: 添加 `PUT /{serialNum}/executeRate` 接口方法
-    - 验证: 接口添加成功，添加 Swagger 注解
-
-7. **更新 API 文档**
-    - 文件: `doc/api/loan-pricing-workflow-api.md`
-    - 操作: 在接口列表中添加"设定执行利率"接口文档
-    - 内容: 接口地址、请求参数、响应示例、说明
-    - 验证: 文档更新完整
-
-8. **后端编译验证**
-    - 操作: 运行 `mvn clean compile` 或 IDE 编译
-    - 验证: 编译成功无错误
-
-9. **接口功能验证**
-    - 操作:
-        - 启动后端服务
-        - 调用 `PUT /loanPricing/workflow/{serialNum}/executeRate` 接口
-        - 调用 `GET /loanPricing/workflow/{serialNum}` 接口验证返回值
-    - 验证:
-        - 设定执行利率成功
-        - 再次设定可覆盖更新
-        - 不存在的 serialNum 返回 404
-        - 详情接口正确返回 executeRate
-
-## 依赖关系
-
-- 任务 1 必须首先执行（数据库字段）
-- 任务 2、3 可并行执行（Entity 和 VO）
-- 任务 4、5 依次执行（Service 接口 -> 实现）
-- 任务 6 依赖任务 5
-- 任务 7 可在任务 6 完成后执行
-- 任务 8、9 依次执行
-
-## 验收标准
-
-- [x] 数据库字段 `execute_rate` 添加成功
-- [x] Entity 和 VO 类添加 `executeRate` 字段
-- [x] Service 接口和实现方法添加成功
-- [x] Controller 接口添加成功并编译通过
-- [x] API 文档更新完整
-- [x] 接口调用成功，执行利率正确保存
-- [x] 详情接口正确返回 `executeRate`
-- [x] 不存在的记录返回 404

openspec/changes/add-model-output-display/design.md

@@ -1,160 +0,0 @@
-# 设计文档: 模型输出展示
-
-## 概述
-
-本文档描述在流程详情页面中添加模型输出展示功能的技术设计。
-
-## 页面结构
-
-### 当前布局
-
-```
-┌─────────────────────────────────────────────────────────┐
-│  页面标题: 流程详情                  [返回按钮]          │
-├──────────────────────┬──────────────────────────────────┤
-│  关键信息摘要 (30%)   │  详情标签页 (70%)                │
-│  ┌────────────────┐  │  ┌────────────────────────────┐  │
-│  │ 流水号         │  │  │ [基本信息][业务信息]...     │  │
-│  │ 客户名称       │  │  │                            │  │
-│  │ 客户类型       │  │  │  字段内容...               │  │
-│  │ 申请金额       │  │  │                            │  │
-│  │ 贷款利率       │  │  │                            │  │
-│  │ 担保方式       │  │  │                            │  │
-│  └────────────────┘  │  └────────────────────────────┘  │
-└──────────────────────┴──────────────────────────────────┘
-```
-
-### 新增布局
-
-```
-┌─────────────────────────────────────────────────────────┐
-│  页面标题: 流程详情                  [返回按钮]          │
-├──────────────────────┬──────────────────────────────────┤
-│  关键信息摘要 (30%)   │  详情标签页 (70%)                │
-│  ┌────────────────┐  │  ┌────────────────────────────┐  │
-│  │ 流水号         │  │  │ [基本信息][业务信息]...     │  │
-│  │ 客户名称       │  │  │                            │  │
-│  │ 客户类型       │  │  │  字段内容...               │  │
-│  │ 申请金额       │  │  │                            │  │
-│  │ 贷款利率       │  │  │                            │  │
-│  │ 担保方式       │  │  │                            │  │
-│  └────────────────┘  │  └────────────────────────────┘  │
-├──────────────────────┴──────────────────────────────────┤
-│  模型输出 (当有数据时显示)                               │
-│  ┌────────────────────────────────────────────────────┐│
-│  │ [基本信息][忠诚度分析][贡献度分析]...              ││
-│  │                                                    ││
-│  │  字段内容...                                       ││
-│  └────────────────────────────────────────────────────┘│
-└─────────────────────────────────────────────────────────┘
-```
-
-## 组件设计
-
-### ModelOutputDisplay 组件
-
-建议创建独立的模型输出展示组件，便于维护和复用。
-
-```vue
-<template>
-  <el-card v-if="shouldDisplay" class="model-output-card">
-    <div slot="header" class="card-header">
-      <span class="card-title">模型输出</span>
-    </div>
-    <el-tabs v-model="activeTab">
-      <!-- 个人客户 Tabs -->
-      <template v-if="custType === '个人'">
-        <el-tab-pane label="基本信息" key="retail-basic">...</el-tab-pane>
-        <el-tab-pane label="忠诚度分析" key="retail-loyalty">...</el-tab-pane>
-        <el-tab-pane label="贡献度分析" key="retail-contribution">...</el-tab-pane>
-        <el-tab-pane label="关联度分析" key="retail-relevance">...</el-tab-pane>
-        <el-tab-pane label="贷款特征" key="retail-loan">...</el-tab-pane>
-        <el-tab-pane label="风险度分析" key="retail-risk">...</el-tab-pane>
-        <el-tab-pane label="测算结果" key="retail-result">...</el-tab-pane>
-      </template>
-      <!-- 企业客户 Tabs -->
-      <template v-else-if="custType === '企业'">
-        <el-tab-pane label="基本信息" key="corp-basic">...</el-tab-pane>
-        <el-tab-pane label="忠诚度分析" key="corp-loyalty">...</el-tab-pane>
-        <el-tab-pane label="贡献度分析" key="corp-contribution">...</el-tab-pane>
-        <el-tab-pane label="关联度分析" key="corp-relevance">...</el-tab-pane>
-        <el-tab-pane label="企业类别" key="corp-category">...</el-tab-pane>
-        <el-tab-pane label="贷款特征" key="corp-loan">...</el-tab-pane>
-        <el-tab-pane label="风险度分析" key="corp-risk">...</el-tab-pane>
-        <el-tab-pane label="测算结果" key="corp-result">...</el-tab-pane>
-      </template>
-    </el-tabs>
-  </el-card>
-</template>
-```
-
-## 数据流
-
-### API 响应结构
-
-```json
-{
-  "code": 200,
-  "msg": "查询成功",
-  "data": {
-    "loanPricingWorkflow": { ... },
-    "modelRetailOutputFields": { ... },  // 个人客户时存在
-    "modelCorpOutputFields": { ... }     // 企业客户时存在
-  }
-}
-```
-
-### 组件 Props
-
-| Prop | 类型 | 说明 |
-|------|------|------|
-| custType | String | 客户类型（个人/企业） |
-| retailOutput | Object | 个人客户模型输出数据 |
-| corpOutput | Object | 企业客户模型输出数据 |
-
-## 样式规范
-
-### 卡片样式
-
-与现有 `.summary-card` 和 `.detail-card` 保持一致：
-
-- 头部背景色: `#fafafa`
-- 边框颜色: `#ebeef5`
-- 内边距: 头部 `16px 20px`, 内容 `20px`
-- 标题字号: `16px`, 字重 `500`
-- 标题颜色: `#303133`
-
-### Tab 样式
-
-使用 Element UI 默认 Tab 样式，间距保持一致。
-
-## 字段映射表
-
-### 个人客户模型输出字段
-
-| Tab | 字段名 | 显示标签 | 格式化 |
-|-----|--------|----------|--------|
-| 基本信息 | custIsn | 客户内码 | - |
-| 基本信息 | custName | 客户名称 | - |
-| 基本信息 | idType | 证件类型 | - |
-| 基本信息 | idNum | 证件号码 | - |
-| 基本信息 | baseLoanRate | 基准利率 | - |
-| 测算结果 | totalBp | 浮动BP | - |
-| 测算结果 | calculateRate | 测算利率 | 高亮显示 |
-
-### 企业客户模型输出字段
-
-| Tab | 字段名 | 显示标签 | 格式化 |
-|-----|--------|----------|--------|
-| 基本信息 | custIsn | 客户内码 | - |
-| 基本信息 | custName | 客户名称 | - |
-| 基本信息 | idType | 证件类型 | - |
-| 基本信息 | idNum | 证件号码 | - |
-| 基本信息 | baseLoanRate | 基准利率 | - |
-| 测算结果 | totalBp | 浮动BP | - |
-| 测算结果 | calculateRate | 测算利率 | 高亮显示 |
-
-## 响应式设计
-
-- 桌面端 (≥768px): 模型输出卡片宽度 100%，Tab 内容两列布局
-- 移动端 (<768px): 模型输出卡片宽度 100%，Tab 内容单列布局

openspec/changes/add-model-output-display/proposal.md

@@ -1,74 +0,0 @@
-# 提案: 在流程详情页添加模型输出展示
-
-## 背景
-
-利率定价流程详情接口已更新，新增了模型输出字段 (`modelRetailOutputFields` 和 `modelCorpOutputFields`)。目前前端详情页面仅展示流程基本信息，未展示模型输出数据。
-
-## 问题
-
-用户在查看流程详情时，无法看到模型计算的输出结果（包括各项 BP 值、测算利率等关键信息），影响业务决策和问题排查。
-
-## 提案概述
-
-在流程详情页面 (`/loanPricing/workflow/detail/:serialNum`) 下方新增独立的模型输出展示区域，根据客户类型（个人/企业）显示对应的模型输出字段。
-
-### 展示逻辑
-
-- 当 `loanPricingWorkflow.custType === "个人"` 时，展示 `modelRetailOutputFields` 字段
-- 当 `loanPricingWorkflow.custType === "企业"` 时，展示 `modelCorpOutputFields` 字段
-- 当模型输出数据为空时，隐藏该展示区域
-
-### 布局结构
-
-保持与现有页面风格一致，采用卡片 + Tab 标签页的形式展示模型输出字段。
-
-#### 个人客户模型输出 Tab 分类
-
-| Tab 名称 | 字段内容 |
-|---------|---------|
-| 基本信息 | 客户内码、客户名称、证件类型、证件号码、基准利率 |
-| 忠诚度分析 | 我行首贷客户、用信天数、客户年龄、BP_首贷、BP_贷龄、BP_年龄、TOTAL_BP_忠诚度 |
-| 贡献度分析 | 存款年日均、贷款年日均、派生率、TOTAL_BP_贡献度 |
-| 关联度分析 | 中间业务_个人_信用卡、中间业务_个人_一码通、中间业务_个人_丰收互联、中间业务_个人_有效客户、中间业务_个人_快捷支付、中间业务_个人_电费代扣、中间业务_个人_水费代扣、中间业务_个人_华数费代扣、中间业务_个人_煤气费代扣、中间业务_个人_市民卡、中间业务_个人_理财业务、中间业务_个人_etc、BP_中间业务、TOTAL_BP_关联度 |
-| 贷款特征 | 申请金额、BP_贷款额度、贷款用途、是否有经营佐证、BP_贷款用途、循环功能、BP_循环功能、抵质押类型、抵质押物三方所有、BP_抵押物 |
-| 风险度分析 | 灰名单客户、本金逾期、利息逾期、信用卡逾期、BP_灰名单与逾期、TOTAL_BP_风险度 |
-| 测算结果 | 浮动BP、测算利率 |
-
-#### 企业客户模型输出 Tab 分类
-
-| Tab 名称 | 字段内容 |
-|---------|---------|
-| 基本信息 | 客户内码、客户名称、证件类型、证件号码、基准利率 |
-| 忠诚度分析 | 我行首贷客户、用信天数、BP_首贷、BP_贷龄、TOTAL_BP_忠诚度 |
-| 贡献度分析 | 存款年日均、贷款年日均、派生率、TOTAL_BP_贡献度 |
-| 关联度分析 | 中间业务_企业_企业互联、中间业务_企业_有效价值客户、中间业务_企业_国际业务、中间业务_企业_承兑、中间业务_企业_贴现、中间业务_企业_电费代扣、中间业务_企业_水费代扣、中间业务_企业_税务代扣、BP_中间业务、代发工资户数、存量贷款余额、BP_代发工资、TOTAL_BP_关联度 |
-| 企业类别 | 净身企业、开立基本结算账户、省农担担保贷款、绿色贷款、科技型企业、BP_企业客户类别 |
-| 贷款特征 | 贷款期限、BP_贷款期限、申请金额、BP_贷款额度、抵质押类型、抵质押物三方所有、BP_抵押物 |
-| 风险度分析 | 灰名单客户、本金逾期、利息逾期、信用卡逾期、BP_灰名单与逾期、TOTAL_BP_风险度 |
-| 测算结果 | 浮动BP、测算利率 |
-
-## 影响范围
-
-- 前端: `ruoyi-ui/src/views/loanPricing/workflow/detail.vue`
-- API: 使用现有的 `GET /loanPricing/workflow/{serialNum}` 接口
-
-## 设计考虑
-
-1. **独立性**: 模型输出区域与流程基本信息分离，避免页面过于臃肿
-2. **一致性**: 采用与现有详情页面相同的卡片 + Tab 布局风格
-3. **响应式**: 保持移动端友好布局
-4. **可扩展**: 预留未来可能新增的模型输出字段
-
-## 替代方案
-
-### 方案 A: 在现有详情对话框中添加 Tab (未采纳)
-- **优点**: 集中展示，减少页面跳转
-- **缺点**: 详情页改为独立页面后此方案不适用
-
-### 方案 B: 新增独立页面展示模型输出 (未采纳)
-- **优点**: 完全分离，职责清晰
-- **缺点**: 增加用户操作步骤，需要额外的路由和菜单配置
-
-### 方案 C: 在详情页下方新增卡片区域 (采纳)
-- **优点**: 一次性获取所有信息，用户体验好，实现简单
-- **缺点**: 单次页面内容较多（通过 Tab 解决）

openspec/changes/add-model-output-display/specs/loan-pricing-workflow-ui/spec.md

@@ -1,63 +0,0 @@
-# loan-pricing-workflow-ui Spec Delta
-
-## ADDED Requirements
-
-### Requirement: 流程详情-模型输出展示
-
-系统 SHALL 在流程详情页面中展示模型输出字段，根据客户类型显示对应的个人或企业模型输出数据。
-
-#### Scenario: 查看个人客户模型输出
-- **WHEN** 用户在流程详情页面查看个人客户的流程记录，且后端返回了 `modelRetailOutputFields` 数据
-- **THEN** 系统在页面下方显示"模型输出"卡片区域，包含 7 个 Tab 标签页：
-  - **基本信息**: 客户内码、客户名称、证件类型、证件号码、基准利率
-  - **忠诚度分析**: 我行首贷客户、用信天数、客户年龄、BP_首贷、BP_贷龄、BP_年龄、TOTAL_BP_忠诚度
-  - **贡献度分析**: 存款年日均、贷款年日均、派生率、TOTAL_BP_贡献度
-  - **关联度分析**: 中间业务_个人_信用卡、中间业务_个人_一码通、中间业务_个人_丰收互联、中间业务_个人_有效客户、中间业务_个人_快捷支付、中间业务_个人_电费代扣、中间业务_个人_水费代扣、中间业务_个人_华数费代扣、中间业务_个人_煤气费代扣、中间业务_个人_市民卡、中间业务_个人_理财业务、中间业务_个人_etc、BP_中间业务、TOTAL_BP_关联度
-  - **贷款特征**: 申请金额、BP_贷款额度、贷款用途、是否有经营佐证、BP_贷款用途、循环功能、BP_循环功能、抵质押类型、抵质押物三方所有、BP_抵押物
-  - **风险度分析**: 灰名单客户、本金逾期、利息逾期、信用卡逾期、BP_灰名单与逾期、TOTAL_BP_风险度
-  - **测算结果**: 浮动BP、测算利率
-
-#### Scenario: 查看企业客户模型输出
-- **WHEN** 用户在流程详情页面查看企业客户的流程记录，且后端返回了 `modelCorpOutputFields` 数据
-- **THEN** 系统在页面下方显示"模型输出"卡片区域，包含 8 个 Tab 标签页：
-  - **基本信息**: 客户内码、客户名称、证件类型、证件号码、基准利率
-  - **忠诚度分析**: 我行首贷客户、用信天数、BP_首贷、BP_贷龄、TOTAL_BP_忠诚度
-  - **贡献度分析**: 存款年日均、贷款年日均、派生率、TOTAL_BP_贡献度
-  - **关联度分析**: 中间业务_企业_企业互联、中间业务_企业_有效价值客户、中间业务_企业_国际业务、中间业务_企业_承兑、中间业务_企业_贴现、中间业务_企业_电费代扣、中间业务_企业_水费代扣、中间业务_企业_税务代扣、BP_中间业务、代发工资户数、存量贷款余额、BP_代发工资、TOTAL_BP_关联度
-  - **企业类别**: 净身企业、开立基本结算账户、省农担担保贷款、绿色贷款、科技型企业、BP_企业客户类别
-  - **贷款特征**: 贷款期限、BP_贷款期限、申请金额、BP_贷款额度、抵质押类型、抵质押物三方所有、BP_抵押物
-  - **风险度分析**: 灰名单客户、本金逾期、利息逾期、信用卡逾期、BP_灰名单与逾期、TOTAL_BP_风险度
-  - **测算结果**: 浮动BP、测算利率
-
-#### Scenario: 无模型输出数据时隐藏展示区域
-- **WHEN** 用户在流程详情页面查看流程记录，但 `modelRetailOutputFields` 和 `modelCorpOutputFields` 均为空
-- **THEN** 系统不显示"模型输出"卡片区域
-
-#### Scenario: 模型输出字段布尔值格式化
-- **WHEN** 模型输出字段中布尔类型值（如 "true"/"false"）
-- **THEN** 系统将其格式化为中文"是"/"否"显示
-
-#### Scenario: 模型输出字段空值处理
-- **WHEN** 模型输出字段值为 null 或空字符串
-- **THEN** 系统显示占位符"-"或空，不显示 "null" 或 "undefined"
-
-#### Scenario: 模型输出区域布局一致性
-- **WHEN** 用户查看流程详情页面
-- **THEN** "模型输出"卡片区域的样式、Tab 样式、字体、间距与上方"流程详情"区域保持一致
-
-#### Scenario: 模型输出区域响应式布局
-- **WHEN** 用户在移动设备或小屏幕上查看流程详情页面
-- **THEN** "模型输出"卡片区域正常显示，Tab 标签页可正常切换，字段描述列表采用单列布局
-
-## MODIFIED Requirements
-
-### Requirement: 流程详情查看
-
-系统 SHALL 提供流程详情查看功能，以独立页面形式展示完整的流程信息，包括模型输出数据。
-
-#### Scenario: 查看流程详情
-- **WHEN** 用户在流程列表页面且具有 `loanPricing:workflow:query` 权限，点击列表中某条记录的"查看"按钮
-- **THEN** 系统跳转至流程详情页面 `/loanPricing/workflow/detail/:serialNum`，展示：
-  - **左侧摘要卡片**: 业务方流水号、客户名称、客户类型、申请金额、贷款利率、担保方式
-  - **右侧详情标签页**: 基本信息页签、业务信息页签、中间业务标识页签、企业标识页签、其他信息页签
-  - **下方模型输出卡片**: 当存在模型输出数据时显示，根据客户类型展示对应的个人或企业模型输出字段

openspec/changes/add-model-output-display/tasks.md

@@ -1,53 +0,0 @@
-# 任务列表: 模型输出展示功能
-
-## 实施顺序
-
-### 1. 前端页面结构调整
-- [x] 在 detail.vue 中新增模型输出展示区域（el-card）
-- [x] 添加条件渲染逻辑：仅当模型输出数据存在时显示
-- [x] 添加客户类型判断逻辑：个人/企业显示不同字段
-- [x] 抽离模型输出组件 ModelOutputDisplay.vue
-
-### 2. 页面布局调整
-- [x] 将模型输出组件放在关键信息右侧（三栏布局）
-- [x] 调整响应式布局支持不同屏幕尺寸
-
-### 3. 个人客户模型输出组件
-- [x] 创建个人模型输出 Tab 结构（7 个 Tab）
-- [x] 实现"基本信息"Tab 字段展示（5 个字段）
-- [x] 实现"忠诚度分析"Tab 字段展示（7 个字段）
-- [x] 实现"贡献度分析"Tab 字段展示（4 个字段）
-- [x] 实现"关联度分析"Tab 字段展示（14 个字段）
-- [x] 实现"贷款特征"Tab 字段展示（10 个字段）
-- [x] 实现"风险度分析"Tab 字段展示（7 个字段）
-- [x] 实现"测算结果"Tab 字段展示（2 个字段）
-
-### 4. 企业客户模型输出组件
-- [x] 创建企业模型输出 Tab 结构（8 个 Tab）
-- [x] 实现"基本信息"Tab 字段展示（5 个字段）
-- [x] 实现"忠诚度分析"Tab 字段展示（6 个字段）
-- [x] 实现"贡献度分析"Tab 字段展示（4 个字段）
-- [x] 实现"关联度分析"Tab 字段展示（13 个字段）
-- [x] 实现"企业类别"Tab 字段展示（6 个字段）
-- [x] 实现"贷款特征"Tab 字段展示（7 个字段）
-- [x] 实现"风险度分析"Tab 字段展示（7 个字段）
-- [x] 实现"测算结果"Tab 字段展示（2 个字段）
-
-### 5. 数据适配
-- [x] 修改 API 响应数据解析逻辑，支持 `LoanPricingWorkflowVO` 结构
-- [x] 添加模型输出字段的数据绑定
-- [x] 添加布尔值字段的格式化（true/false → 是/否）
-- [x] 添加空值处理逻辑
-
-### 6. 样式调整
-- [x] 保持与现有详情页面一致的卡片样式
-- [x] 保持 Tab 样式一致性
-- [x] 确保响应式布局在移动端正常显示
-- [x] 调整卡片间距
-
-### 7. 测试验证
-- [ ] 测试个人客户数据展示
-- [ ] 测试企业客户数据展示
-- [ ] 测试无模型输出数据时的页面表现
-- [ ] 测试响应式布局
-- [ ] 测试各 Tab 切换交互

openspec/changes/adjust-model-output-columns/proposal.md

@@ -1,61 +0,0 @@
-# 提案: 将模型输出展示组件改为三列布局
-
-## 背景
-
-当前 `ModelOutputDisplay.vue` 组件中所有 `el-descriptions` 使用 `:column="2"` 两列布局展示模型输出字段。
-
-## 问题
-
-两列布局导致垂直空间占用较多，用户需要滚动更多才能查看完整信息。三列布局可以更好地利用屏幕宽度（特别是在桌面端），减少垂直滚动需求。
-
-## 提案概述
-
-将 `ModelOutputDisplay.vue` 组件中所有 `el-descriptions` 的 `:column` 属性从 `2` 修改为 `3`。
-
-### 影响范围
-
-- 前端: `ruoyi-ui/src/views/loanPricing/workflow/components/ModelOutputDisplay.vue`
-
-### 具体修改点
-
-需要修改以下位置的 `:column` 属性：
-
-#### 个人客户模型输出
-1. 基本信息 (line 11): `:column="2"` → `:column="3"`
-2. 忠诚度分析 (line 22): `:column="2"` → `:column="3"`
-3. 贡献度分析 (line 35): `:column="2"` → `:column="3"`
-4. 关联度分析 (line 45): `:column="2"` → `:column="3"`
-5. 贷款特征 (line 65): `:column="2"` → `:column="3"`
-6. 风险度分析 (line 81): `:column="2"` → `:column="3"`
-7. 测算结果 (line 93): `:column="2"` → `:column="3"`
-
-#### 企业客户模型输出
-8. 基本信息 (line 104): `:column="2"` → `:column="3"`
-9. 忠诚度分析 (line 115): `:column="2"` → `:column="3"`
-10. 贡献度分析 (line 126): `:column="2"` → `:column="3"`
-11. 关联度分析 (line 136): `:column="2"` → `:column="3"`
-12. 企业类别 (line 155): `:column="2"` → `:column="3"`
-13. 贷款特征 (line 167): `:column="2"` → `:column="3"`
-14. 风险度分析 (line 180): `:column="2"` → `:column="3"`
-15. 测算结果 (line 192): `:column="2"` → `:column="3"`
-
-## 设计考虑
-
-1. **空间利用**: 三列布局可以减少约 33% 的垂直空间占用
-2. **可读性**: Element UI 的 `el-descriptions` 组件会自动调整标签宽度，三列布局在标准桌面显示器（1920px 宽度）下可读性良好
-3. **兼容性**: `el-descriptions` 组件原生支持多列布局，无需额外样式调整
-4. **响应式**: 在小屏幕设备上，Element UI 会自动调整布局，无需额外处理
-
-## 替代方案
-
-### 方案 A: 保持两列布局 (未采纳)
-- **优点**: 标签内容空间更充足
-- **缺点**: 垂直空间占用大，需要更多滚动
-
-### 方案 B: 使用四列布局 (未采纳)
-- **优点**: 垂直空间占用最少
-- **缺点**: 标签内容可能被压缩，影响可读性
-
-### 方案 C: 改为三列布局 (采纳)
-- **优点**: 平衡空间利用率和可读性
-- **缺点**: 无明显缺点

openspec/changes/adjust-model-output-columns/specs/loan-pricing-workflow-ui/spec.md

@@ -1,15 +0,0 @@
-# loan-pricing-workflow-ui Delta
-
-## MODIFIED Requirements
-
-### Requirement: 模型输出展示布局
-
-模型输出组件 SHALL 使用三列布局展示字段信息，以提高空间利用率。
-
-#### Scenario: 查看个人客户模型输出三列布局
-- **WHEN** 用户在流程详情页查看个人客户记录的模型输出信息
-- **THEN** 系统在所有模型输出 Tab（基本信息、忠诚度分析、贡献度分析、关联度分析、贷款特征、风险度分析、测算结果）中使用三列布局展示字段
-
-#### Scenario: 查看企业客户模型输出三列布局
-- **WHEN** 用户在流程详情页查看企业客户记录的模型输出信息
-- **THEN** 系统在所有模型输出 Tab（基本信息、忠诚度分析、贡献度分析、关联度分析、企业类别、贷款特征、风险度分析、测算结果）中使用三列布局展示字段

openspec/changes/adjust-model-output-columns/tasks.md

@@ -1,36 +0,0 @@
-# 实施任务
-
-## 任务清单
-
-1. **修改 ModelOutputDisplay.vue 组件列数配置**
-   - 文件: `ruoyi-ui/src/views/loanPricing/workflow/components/ModelOutputDisplay.vue`
-   - 操作: 将所有 `el-descriptions` 的 `:column="2"` 修改为 `:column="3"`
-   - 涉及行数: 11, 22, 35, 45, 65, 81, 93, 104, 115, 126, 136, 155, 167, 180, 192
-   - 验证: 确认所有 15 处 `el-descriptions` 的 `:column` 属性已修改为 `3`
-
-2. **前端构建验证**
-   - 操作: 运行 `cd ruoyi-ui && npm run build:prod`
-   - 验证: 构建成功无错误
-
-3. **功能验证**
-   - 操作:
-     - 启动前端开发服务器 `npm run dev`
-     - 访问流程详情页，选择个人客户记录，验证模型输出显示为三列
-     - 选择企业客户记录，验证模型输出显示为三列
-   - 验证:
-     - 个人客户所有 7 个 Tab 的字段展示均为三列布局
-     - 企业客户所有 8 个 Tab 的字段展示均为三列布局
-     - 标签和值内容正常显示，无溢出或错位
-
-## 依赖关系
-
-- 任务 1 必须首先完成
-- 任务 2 和任务 3 可并行执行
-
-## 验收标准
-
-- [x] 所有 `el-descriptions` 的 `:column` 属性值均为 `3`
-- [x] 前端构建成功
-- [x] 个人客户模型输出所有 Tab 正确显示为三列
-- [x] 企业客户模型输出所有 Tab 正确显示为三列
-- [x] 字段标签和内容显示正常，无布局问题

openspec/changes/archive/2026-01-20-add-loan-pricing-create/proposal.md

@@ -1,33 +0,0 @@
-# Change: 添加利率定价流程创建功能
-
-## Why
-
-当前 `add-loan-pricing-frontend` 变更已实现流程列表查询和详情查看功能，但缺少创建新流程的能力。业务人员需要能够通过 Web 界面发起新的利率定价申请，而不是直接调用后端 API。
-
-## What Changes
-
-- 修改前端页面组件 `ruoyi-ui/src/views/loanPricing/workflow/index.vue`：
-  - 添加"新增"按钮（带权限控制 `loanPricing:workflow:create`）
-  - 添加创建流程表单对话框
-  - 实现表单验证逻辑
-  - 实现表单提交功能
-
-- 新增前端 API 接口函数：
-  - `createWorkflow(data)` - 创建利率定价流程
-
-- 新增数据库菜单权限：
-  - 添加创建权限 `loanPricing:workflow:create`
-
-## Impact
-
-- **Affected specs:** 修改 `loan-pricing-workflow-ui` 能力规格
-- **Affected code:**
-  - **修改 `ruoyi-ui/src/api/loanPricing/workflow.js`** - 新增创建接口
-  - **修改 `ruoyi-ui/src/views/loanPricing/workflow/index.vue`** - 添加创建功能
-  - **修改 `sys_menu` 表** - 添加创建权限按钮
-
-## Dependencies
-
-- 依赖已完成的 `add-loan-pricing-workflow` 后端变更（提供创建 API）
-- 依赖已完成的 `add-loan-pricing-frontend` 前端变更（提供列表和详情页面）
-- 后端 API 接口文档位于 `doc/api/loan-pricing-workflow-api.md`（接口1：发起利率定价流程）

openspec/changes/archive/2026-01-20-add-loan-pricing-create/specs/loan-pricing-workflow-ui/spec.md

@@ -1,94 +0,0 @@
-# Capability: loan-pricing-workflow-ui
-
-利率定价流程前端用户界面能力。
-
-## MODIFIED Requirements
-
-### Requirement: 流程列表查询
-
-系统 SHALL 提供利率定价流程列表查询页面，支持分页和多条件筛选，并支持创建新流程。
-
-#### Scenario: 查询流程列表
-- **WHEN** 用户已登录系统且具有 `loanPricing:workflow:list` 权限，访问"利率定价管理 > 流程列表"菜单
-- **THEN** 系统显示利率定价流程列表页面，包含查询表单（客户名称模糊查询、创建者、机构号筛选）、搜索和重置按钮、新增按钮（带权限控制）、数据表格（业务方流水号、客户名称、客户类型、担保方式、申请金额、贷款利率、创建时间、创建者）、分页组件、操作列（包含"查看"按钮）
-
-#### Scenario: 使用筛选条件查询
-- **WHEN** 用户在流程列表页面输入客户名称或选择创建者/机构号，点击搜索按钮
-- **THEN** 系统根据筛选条件查询并更新列表数据
-
-#### Scenario: 重置筛选条件
-- **WHEN** 用户已设置筛选条件，点击重置按钮
-- **THEN** 系统清空所有筛选条件并重新查询全部数据
-
-### Requirement: 流程详情查看
-
-系统 SHALL 提供流程详情查看功能，以对话框形式展示完整的流程信息。
-
-#### Scenario: 查看流程详情
-- **WHEN** 用户在流程列表页面且具有 `loanPricing:workflow:query` 权限，点击列表中某条记录的"查看"按钮
-- **THEN** 系统弹出详情对话框，展示完整的流程信息（基本信息：业务方流水号、机构编码、客户内码、客户名称、证件类型；业务信息：客户类型、担保方式、申请金额、贷款利率、贷款用途；业务标识：中间业务标识、企业标识；抵质押信息：抵质押类型、是否三方所有；其他信息：创建时间、创建者、更新时间、更新者）
-
-### Requirement: 菜单和权限配置
-
-系统 SHALL 在数据库中正确配置菜单项和权限，确保用户可以访问功能。
-
-#### Scenario: 菜单显示和导航
-- **WHEN** 用户已登录系统且具有利率定价流程相关权限
-- **THEN** 系统在左侧菜单栏显示"利率定价管理"一级菜单，展开后显示"流程列表"二级菜单项
-
-#### Scenario: 菜单路由配置
-- **WHEN** 用户点击"流程列表"菜单项，系统处理路由跳转
-- **THEN** 系统导航至 `/loanPricing/workflow` 路径，加载对应的前端组件
-
-### Requirement: API 接口集成
-
-前端 SHALL 正确调用后端 API 接口获取数据和提交创建请求。
-
-#### Scenario: 列表接口调用
-- **WHEN** 用户访问流程列表页面，页面初始化或用户执行查询操作
-- **THEN** 前端调用 `GET /loanPricing/workflow/list` 接口，传入分页和筛选参数
-
-#### Scenario: 详情接口调用
-- **WHEN** 用户点击查看按钮，前端获取选中记录的业务方流水号
-- **THEN** 前端调用 `GET /loanPricing/workflow/{serialNum}` 接口获取详情数据
-
-#### Scenario: 创建接口调用
-- **WHEN** 用户填写完创建表单并点击确定按钮
-- **THEN** 前端调用 `POST /loanPricing/workflow/create` 接口，传入表单数据，成功后关闭对话框并刷新列表
-
-## ADDED Requirements
-
-### Requirement: 流程创建
-
-系统 SHALL 提供创建新利率定价流程的功能，通过表单对话框收集必要信息。
-
-#### Scenario: 打开创建表单
-- **WHEN** 用户在流程列表页面且具有 `loanPricing:workflow:create` 权限，点击"新增"按钮
-- **THEN** 系统弹出创建流程表单对话框，显示所有必填和可选字段
-
-#### Scenario: 表单字段显示
-- **WHEN** 用户打开创建流程表单对话框
-- **THEN** 系统显示以下字段分组：
-  - 基本信息：客户内码（必填）、客户名称、客户类型（必填，下拉选择：个人/企业）、证件类型
-  - 贷款信息：申请金额（必填）、贷款利率（必填）、担保方式（必填，下拉选择：信用/保证/抵押/质押）、贷款用途（下拉选择：consumer/business）
-  - 中间业务标识（个人）：个人快捷支付（开关）、个人电费代扣（开关）
-  - 中间业务标识（企业）：企业电费代扣（开关）、企业水费代扣（开关）
-  - 企业标识：净身企业（开关）、开立基本结算账户（开关）、制造业企业（开关）、省农担担保贷款（开关）、纳税信用等级A级（开关）、县级及以上农业龙头企业（开关）、普惠小微借款人（开关）
-  - 抵质押信息：抵质押类型（下拉选择：一线/一类/二类）、抵质押物三方所有（开关）、是否有经营佐证（开关）
-  - 固定字段：机构编码（隐藏，固定值931000）、运行模式（隐藏，固定值1）
-
-#### Scenario: 表单验证
-- **WHEN** 用户填写表单并点击确定按钮
-- **THEN** 系统验证必填字段：客户内码、客户类型、担保方式、申请金额、贷款利率，如有缺失则显示错误提示
-
-#### Scenario: 提交创建成功
-- **WHEN** 用户填写完必填字段并点击确定按钮，后端返回成功响应
-- **THEN** 系统关闭对话框，显示成功提示消息，刷新列表数据
-
-#### Scenario: 取消创建
-- **WHEN** 用户点击取消按钮或对话框关闭按钮
-- **THEN** 系统关闭对话框，不保存数据，不刷新列表
-
-#### Scenario: 新增按钮权限控制
-- **WHEN** 用户不具有 `loanPricing:workflow:create` 权限
-- **THEN** 系统不显示"新增"按钮

openspec/changes/archive/2026-01-20-add-loan-pricing-create/tasks.md

@@ -1,39 +0,0 @@
-# Tasks: 添加利率定价流程创建功能
-
-## Implementation Tasks
-
-### 1. 新增前端 API 接口
-- [x] 在 `ruoyi-ui/src/api/loanPricing/workflow.js` 中添加 `createWorkflow(data)` 函数
-- [x] 函数调用 `POST /loanPricing/workflow/create` 接口
-
-### 2. 修改前端页面组件
-- [x] 在页面工具栏区域添加"新增"按钮
-- [x] 按钮配置权限控制 `v-hasPermi="['loanPricing:workflow:create']"`
-- [x] 添加创建流程表单对话框组件
-- [x] 实现表单字段（参照 API 文档接口1的请求参数）：
-  - 必填字段：机构编码(固定931000)、运行模式(固定1)、客户内码、客户类型、担保方式、申请金额、贷款利率
-  - 可选字段：客户名称、证件类型、贷款用途
-  - 业务标识字段：中间业务标识（个人快捷支付、个人电费代扣、企业电费代扣、企业水费代扣）
-  - 企业标识字段：净身企业、开立基本结算账户、制造业企业、省农担担保贷款、纳税信用等级A级、县级及以上农业龙头企业、普惠小微借款人
-  - 抵质押信息字段：抵质押类型、抵质押物三方所有、是否有经营佐证
-- [x] 实现表单验证规则
-- [x] 实现 `handleAdd` 方法（打开对话框）
-- [x] 实现 `submitForm` 方法（提交表单）
-- [x] 实现 `cancelCreate` 方法（取消/关闭对话框）
-- [x] 实现 `reset` 方法（重置表单）
-
-### 3. 配置数据库菜单权限
-- [x] 准备 SQL 插入语句，在 `sys_menu` 表中添加创建按钮权限：
-  - menu_id: 2003, menu_name: 流程创建, parent_id: 2001
-  - perms: `loanPricing:workflow:create`
-- [x] 执行 SQL 插入语句
-- [x] 关联管理员角色到新菜单权限
-
-### 4. 验证和测试
-- [x] 代码实现完成，等待用户启动前端服务进行测试
-- [ ] 启动前端开发服务器
-- [ ] 验证"新增"按钮是否显示
-- [ ] 测试打开创建表单对话框
-- [ ] 测试表单验证功能
-- [ ] 测试提交创建成功后刷新列表
-- [ ] 测试取消和关闭对话框功能

openspec/changes/archive/2026-01-20-add-loan-pricing-frontend/proposal.md

@@ -1,25 +0,0 @@
-# Change: 添加利率定价流程前端管理界面
-
-## Why
-
-后端利率定价流程 API 已实现（参见 `add-loan-pricing-workflow` 变更），但缺少对应的前端管理界面。业务人员需要通过 Web 界面查询利率定价流程列表、查看流程详情，而不能直接调用后端 API。
-
-## What Changes
-
-- 新增前端 API 接口模块 `ruoyi-ui/src/api/loanPricing/workflow.js`
-- 新增前端页面组件 `ruoyi-ui/src/views/loanPricing/workflow/index.vue`
-- 在数据库 `sys_menu` 表中配置菜单项，确保页面可以正常访问
-- 配置路由和权限，使用户可以通过菜单导航访问功能
-
-## Impact
-
-- **Affected specs:** 新增 `loan-pricing-workflow-ui` 能力规格
-- **Affected code:**
-  - **新增 `ruoyi-ui/src/api/loanPricing/workflow.js`** - API 接口定义
-  - **新增 `ruoyi-ui/src/views/loanPricing/workflow/index.vue`** - 列表和详情页面组件
-  - **修改 `sys_menu` 表** - 添加菜单配置数据
-
-## Dependencies
-
-- 依赖已完成的 `add-loan-pricing-workflow` 后端变更
-- 后端 API 接口文档位于 `doc/api/loan-pricing-workflow-api.md`

openspec/changes/archive/2026-01-20-add-loan-pricing-frontend/specs/loan-pricing-workflow-ui/spec.md

@@ -1,53 +0,0 @@
-# Capability: loan-pricing-workflow-ui
-
-利率定价流程前端用户界面能力。
-
-## ADDED Requirements
-
-### Requirement: 流程列表查询
-
-系统 SHALL 提供利率定价流程列表查询页面，支持分页和多条件筛选。
-
-#### Scenario: 查询流程列表
-- **WHEN** 用户已登录系统且具有 `loanPricing:workflow:list` 权限，访问"利率定价管理 > 流程列表"菜单
-- **THEN** 系统显示利率定价流程列表页面，包含查询表单（客户名称模糊查询、创建者、机构号筛选）、搜索和重置按钮、数据表格（业务方流水号、客户名称、客户类型、担保方式、申请金额、贷款利率、创建时间、创建者）、分页组件、操作列（包含"查看"按钮）
-
-#### Scenario: 使用筛选条件查询
-- **WHEN** 用户在流程列表页面输入客户名称或选择创建者/机构号，点击搜索按钮
-- **THEN** 系统根据筛选条件查询并更新列表数据
-
-#### Scenario: 重置筛选条件
-- **WHEN** 用户已设置筛选条件，点击重置按钮
-- **THEN** 系统清空所有筛选条件并重新查询全部数据
-
-### Requirement: 流程详情查看
-
-系统 SHALL 提供流程详情查看功能，以对话框形式展示完整的流程信息。
-
-#### Scenario: 查看流程详情
-- **WHEN** 用户在流程列表页面且具有 `loanPricing:workflow:query` 权限，点击列表中某条记录的"查看"按钮
-- **THEN** 系统弹出详情对话框，展示完整的流程信息（基本信息：业务方流水号、机构编码、客户内码、客户名称、证件类型；业务信息：客户类型、担保方式、申请金额、贷款利率、贷款用途；业务标识：中间业务标识、企业标识；抵质押信息：抵质押类型、是否三方所有；其他信息：创建时间、创建者、更新时间、更新者）
-
-### Requirement: 菜单和权限配置
-
-系统 SHALL 在数据库中正确配置菜单项和权限，确保用户可以访问功能。
-
-#### Scenario: 菜单显示和导航
-- **WHEN** 用户已登录系统且具有利率定价流程相关权限
-- **THEN** 系统在左侧菜单栏显示"利率定价管理"一级菜单，展开后显示"流程列表"二级菜单项
-
-#### Scenario: 菜单路由配置
-- **WHEN** 用户点击"流程列表"菜单项，系统处理路由跳转
-- **THEN** 系统导航至 `/loanPricing/workflow` 路径，加载对应的前端组件
-
-### Requirement: API 接口集成
-
-前端 SHALL 正确调用后端 API 接口获取数据。
-
-#### Scenario: 列表接口调用
-- **WHEN** 用户访问流程列表页面，页面初始化或用户执行查询操作
-- **THEN** 前端调用 `GET /loanPricing/workflow/list` 接口，传入分页和筛选参数
-
-#### Scenario: 详情接口调用
-- **WHEN** 用户点击查看按钮，前端获取选中记录的业务方流水号
-- **THEN** 前端调用 `GET /loanPricing/workflow/{serialNum}` 接口获取详情数据