feat: 数据导出审批流程模板 - DMS CE 部分

.cursor/rules/clean-code.mdc

@@ -0,0 +1,54 @@
+---
+alwaysApply: true
+---
+# Clean Code Guidelines
+
+## Constants Over Magic Numbers
+- Replace hard-coded values with named constants
+- Use descriptive constant names that explain the value's purpose
+- Keep constants at the top of the file or in a dedicated constants file
+
+## Meaningful Names
+- Variables, functions, and classes should reveal their purpose
+- Names should explain why something exists and how it's used
+- Avoid abbreviations unless they're universally understood
+
+## Smart Comments
+- Don't comment on what the code does - make the code self-documenting
+- Use comments to explain why something is done a certain way
+- Document APIs, complex algorithms, and non-obvious side effects
+
+## Single Responsibility
+- Each function should do exactly one thing
+- Functions should be small and focused
+- If a function needs a comment to explain what it does, it should be split
+
+## DRY (Don't Repeat Yourself)
+- Extract repeated code into reusable functions
+- Share common logic through proper abstraction
+- Maintain single sources of truth
+
+## Clean Structure
+- Keep related code together
+- Organize code in a logical hierarchy
+- Use consistent file and folder naming conventions
+
+## Encapsulation
+- Hide implementation details
+- Expose clear interfaces
+- Move nested conditionals into well-named functions
+
+## Code Quality Maintenance
+- Refactor continuously
+- Fix technical debt early
+- Leave code cleaner than you found it
+
+## Testing
+- Write tests before fixing bugs
+- Keep tests readable and maintainable
+- Test edge cases and error conditions
+
+## Version Control
+- Write clear commit messages
+- Make small, focused commits
+- Use meaningful branch names 

.cursor/rules/codequality.mdc

@@ -0,0 +1,46 @@
+---
+alwaysApply: true
+---
+# Code Quality Guidelines
+
+## Verify Information
+Always verify information before presenting it. Do not make assumptions or speculate without clear evidence.
+
+## File-by-File Changes
+Make changes file by file and give me a chance to spot mistakes.
+
+## No Apologies
+Never use apologies.
+
+## No Understanding Feedback
+Avoid giving feedback about understanding in comments or documentation.
+
+## No Whitespace Suggestions
+Don't suggest whitespace changes.
+
+## No Summaries
+Don't summarize changes made.
+
+## No Inventions
+Don't invent changes other than what's explicitly requested.
+
+## No Unnecessary Confirmations
+Don't ask for confirmation of information already provided in the context.
+
+## Preserve Existing Code
+Don't remove unrelated code or functionalities. Pay attention to preserving existing structures.
+
+## Single Chunk Edits
+Provide all edits in a single chunk instead of multiple-step instructions or explanations for the same file.
+
+## No Implementation Checks
+Don't ask the user to verify implementations that are visible in the provided context.
+
+## No Unnecessary Updates
+Don't suggest updates or changes to files when there are no actual modifications needed.
+
+## Provide Real File Links
+Always provide links to the real files, not x.md.
+
+## No Current Implementation
+Don't show or discuss the current implementation unless specifically requested.

.cursor/rules/dms/biz.mdc

@@ -0,0 +1,48 @@
+---
+description:
+globs:
+alwaysApply: false
+---
+
+
+#### Biz Layer Implementation Guidelines (`internal/dms/biz/`)
+- Use usecase pattern for business logic:
+  ```go
+  type SomeUsecase struct {
+      repo Repository
+      // Other dependencies
+  }
+  ```
+- Define clear domain models:
+  ```go
+  type DomainModel struct {
+      UID string
+      // Domain-specific fields
+  }
+  ```
+- Implement business validation:
+  ```go
+  func (u *SomeUsecase) validateData(ctx context.Context, data *DomainModel) error {
+      if err := u.validateBusinessRules(data); err != nil {
+          return fmt.Errorf("business validation failed: %v", err)
+      }
+      return nil
+  }
+  ```
+- Handle state transitions:
+  ```go
+  func (u *SomeUsecase) UpdateState(ctx context.Context, model *DomainModel, newState State) error {
+      if !model.CanTransitionTo(newState) {
+          return pkgErr.ErrInvalidStateTransition
+      }
+      // Update state
+  }
+  ```
+- Define repository interfaces:
+  ```go
+  type DBModelRepository interface {
+      Create(ctx context.Context, model *DomainModel) error
+      Update(ctx context.Context, model *DomainModel) error
+      // Other methods
+  }
+  ```

.cursor/rules/dms/dms-api-standards.mdc

@@ -0,0 +1,69 @@
+---
+description: DMS project API architecture, development standards, and implementation guidelines. Apply these rules when working with DMS API code to ensure consistency with existing patterns and maintainability.
+globs: 
+  - "internal/apiserver/**/*.go"
+  - "api/**/*.go"
+  - "pkg/dms-common/**/*.go"
+---
+
+# DMS API Standards
+
+## Framework and Architecture
+- Use Echo v4 as the web framework for all HTTP handling
+- Maintain Go 1.19+ compatibility
+- Follow layered architecture: API -> Service -> Business Logic
+- Support both v1 and v2 API versions with proper versioning strategy
+- Use JWT authentication with echo-jwt middleware
+
+## API Versioning
+- Implement versioned routes: `/v1/dms/`, `/v2/dms/`
+- Keep v1 APIs backward compatible
+- Introduce new features in v2 first
+- Use route groups for version management
+- Mark deprecated endpoints with `DeprecatedBy()` function
+
+
+## Routing Standards
+- Organize routes in `router.go` by functional modules
+- Use Echo route groups for logical separation
+- Apply middleware selectively to specific route groups
+- Support RESTful resource patterns: `GET /resource`, `POST /resource`, `PUT /resource/:id`, `DELETE /resource/:id`
+- Implement proper HTTP method handling for each endpoint
+
+## Request and Response Handling
+- Use `base.GenericResp` for consistent response structure
+- Implement proper request validation with validator tags
+- Support JSON and form data binding
+- Return standardized error codes using `apiError.ErrorCode`
+- Include proper HTTP status codes in responses
+
+## Data Models
+- Define all API models in `api/dms/service/v1/` and `api/dms/service/v2/`
+- Use consistent naming: `{Action}{Resource}Req` for requests, `{Action}{Resource}Reply` for responses
+- Include proper JSON tags and validation rules
+- Support pagination, filtering, and sorting where appropriate
+- Use `UidWithName` struct for common identifier patterns
+
+## Error Handling
+- Implement centralized error handling in controllers
+- Use predefined error codes from `apiError` package
+- Log errors with appropriate context and stack traces
+- Return user-friendly error messages
+- Support internationalization for error messages
+
+## Security Implementation
+- Enable HTTPS with TLS 1.2+ configuration
+- Implement JWT token validation and refresh
+- Use role-based access control (RBAC)
+- Validate all input parameters and request data
+- Implement proper session management and timeout
+
+## Middleware Usage
+- Apply authentication middleware to protected routes
+- Use compression middleware for response optimization
+- Implement logging middleware for request tracking
+- Apply rate limiting where necessary
+- Use custom middleware for business-specific concerns
+
+## Swagger Documentation Standards
+@swagger-documentation-standards.mdc

.cursor/rules/dms/dms-development.mdc

@@ -0,0 +1,123 @@
+---
+alwaysApply: true
+---
+# DMS Architecture Standards
+
+## Layered Architecture Design
+
+### API Definition Layer (`api/`)
+- Define Request and Response structures
+@dms-api-standards.mdc
+- Version-controlled API definitions (v1, v2, etc.)
+
+### API Layer (`internal/apiserver/service/route.go`)
+- Implement RESTful API design standards
+- Handle HTTP requests and responses
+- Implement request parameter binding and validation
+- Unified error handling and response format
+- Route registration and middleware configuration
+
+#### Controller Implementation Guidelines(`internal/apiserver/service/*_controller.go`)
+- Use `DMSController` struct for controller implementation
+- Include service dependencies and logger in controller struct
+- Use swagger annotations for API documentation
+@dms-api-standards.mdc  
+- Follow standard error handling pattern:
+  ```go
+  func (ctl *DMSController) MethodName(c echo.Context) error {
+      req := new(aV1.RequestStruct)
+      err := bindAndValidateReq(c, req)
+      if nil != err {
+          return NewErrResp(c, err, apiError.BadRequestErr)
+      }
+      // Business logic
+      return NewOkRespWithReply(c, reply)
+  }
+  ```
+
+
+### Service Layer (`internal/dms/service/`)
+- Implement business process orchestration without specific business rules
+- Handle transaction control and concurrency
+- Combine multiple Biz layer interfaces to complete business functions
+- Business parameter validation
+
+#### Service Implementation Guidelines
+- Use service struct with required dependencies:
+  ```go
+  type DMSService struct {
+      // Biz layer dependencies
+      BusinessUsecase *biz.BusinessUsecase
+      // Other dependencies
+  }
+  ```
+- Follow standard method signature pattern:
+  ```go
+  func (d *DMSService) MethodName(ctx context.Context, req *dmsV1.RequestStruct, currentUserUid string) (reply *dmsV1.ReplyStruct, err error)
+  ```
+- Handle request transformation:
+  ```go
+  // Transform API request to biz layer args
+  args := &biz.SomeStruct{
+      Field1: req.Field1,
+      Field2: req.Field2,
+  }
+  ```
+- Proper error handling and wrapping:
+  ```go
+  if err != nil {
+      return nil, fmt.Errorf("operation failed: %v", err)
+  }
+  ```
+- Standard response structure:
+  ```go
+  return &dmsV1.ReplyStruct{
+      Data: struct {
+          Field string `json:"field"`
+      }{Field: value},
+  }, nil
+  ```
+
+### Biz Layer (`internal/dms/biz/`)
+- Implement core business logic of domain models
+- Define domain object behaviors and rules
+- Independent of specific storage implementations
+- Include business rule validation
+- Implement core features like permission verification
+@biz.mdc
+
+### Storage Layer (`internal/{module}/storage/`)
+- Implement data access interfaces
+- Implement DBModelRepository interface,Handle database CRUD operations
+- Support multiple storage implementations
+- Contains no business logic
+@storage.mdc
+
+
+## Development Standards
+
+### Dependency Principles
+- Each layer maintains single responsibility, no cross-layer calls
+- Upper layers depend on lower layers, no reverse dependencies
+- Isolate dependencies through interfaces
+- Follow Clean Code principles
+
+### Testing Requirements
+- Write unit tests for all controller methods
+- Implement integration tests for complete API flows
+- Use `testify` library for assertions and mocking
+- Maintain test coverage above 80%
+- Test both success and error scenarios
+
+### Logging Standards
+- Use structured logging with consistent field naming
+- Include essential context fields in all log entries
+- Follow proper log level classification for different types of messages
+- Ensure logs are searchable and traceable across distributed systems
+
+### Module Development Guidelines
+- Each module should follow the layered architecture
+- Implement related functionality in corresponding directories
+- When adding new APIs, first define interfaces and data structures in the api directory
+- Then implement corresponding functionality in each layer
+- Maintain module independence and low coupling