From 8e6b69f6c7941b4461446a1b3d36130000f9bde7 Mon Sep 17 00:00:00 2001 From: Peanut Date: Sat, 27 Jun 2026 17:32:18 +0800 Subject: [PATCH] =?UTF-8?q?fix:=20=E4=BF=AE=E5=A4=8D=E9=81=97=E6=BC=8F?= =?UTF-8?q?=E7=9A=84=20backend-single=20=E5=BC=95=E7=94=A8=EF=BC=88Java?= =?UTF-8?q?=E6=BA=90=E7=A0=81/=E5=89=8D=E7=AB=AF=E6=B3=A8=E9=87=8A/?= =?UTF-8?q?=E9=85=8D=E7=BD=AE=E6=96=87=E4=BB=B6/IDE=E9=85=8D=E7=BD=AE?= =?UTF-8?q?=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .augment/rules/rules.md | 81 ----- .cursor/commands/speckit.analyze.md | 184 ----------- .cursor/commands/speckit.checklist.md | 294 ------------------ .cursor/commands/speckit.clarify.md | 181 ----------- .cursor/commands/speckit.constitution.md | 84 ----- .cursor/commands/speckit.implement.md | 135 -------- .cursor/commands/speckit.plan.md | 89 ------ .cursor/commands/speckit.specify.md | 258 --------------- .cursor/commands/speckit.tasks.md | 137 -------- .cursor/commands/speckit.taskstoissues.md | 30 -- .cursor/rules/rules.mdc | 80 ----- .idea/compiler.xml | 2 +- .idea/dataSources.xml | 4 +- .idea/encodings.xml | 4 +- .idea/misc.xml | 1 - manage.conf.yaml | 2 +- mini-program/src/pages/main/ScriptView.vue | 8 +- server/API_BASE_URL_MODIFICATION_SUMMARY.md | 14 +- server/docs/ADMIN_AUTH_TEST.md | 2 +- .../com/emotion/EmotionSimpleApplication.java | 2 +- .../emotion/controller/HealthController.java | 4 +- web/src/services/auth.ts | 4 +- web/src/services/chat.ts | 8 +- web/src/services/message.ts | 8 +- 24 files changed, 31 insertions(+), 1585 deletions(-) delete mode 100644 .augment/rules/rules.md delete mode 100644 .cursor/commands/speckit.analyze.md delete mode 100644 .cursor/commands/speckit.checklist.md delete mode 100644 .cursor/commands/speckit.clarify.md delete mode 100644 .cursor/commands/speckit.constitution.md delete mode 100644 .cursor/commands/speckit.implement.md delete mode 100644 .cursor/commands/speckit.plan.md delete mode 100644 .cursor/commands/speckit.specify.md delete mode 100644 .cursor/commands/speckit.tasks.md delete mode 100644 .cursor/commands/speckit.taskstoissues.md delete mode 100644 .cursor/rules/rules.mdc diff --git a/.augment/rules/rules.md b/.augment/rules/rules.md deleted file mode 100644 index 0bb074c..0000000 --- a/.augment/rules/rules.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -type: "always_apply" ---- - -# 项目开发规则 - -## 基础设置 - -1. 保持对话语言为中文 -2. 不允许在未经允许的情况下删除代码和文件,不允许破坏已经正常的业务代码 -3. 执行终端命令时要关注执行情况，避免无效等待 - -## 代码规范 - -4. 生成代码时必须添加类级和函数级注释 -5. 使用import导包，禁止使用全限定名称引用类 -6. 禁止使用枚举类型作为entity、request、response、dto对象的字段类型，禁止以枚举类作为方法的入参，确保接口的通用性和可扩展性 -7. 新增数据的id使用已存在的雪花算法生成器生成 - -## 架构规范 - -8. 所有开发必须遵循当前项目规范 -9. Controller层禁止添加业务逻辑 -10. 使用全局异常处理，禁止使用try-catch -11. 前端接口访问尽可能走网关调用 - -## 接口设计规范 - -12. Controller层接口定义要完整： - - 入参使用request封装传递到service层 - - service层的方法命名与controller层定义的接口的方法名称保持一致 - - 出参使用response封装由service层传递到controller层 - - 禁止在controller层做entity/domain对象与request/response的转换 - - 使用项目已有的Result做接口返回 -13. 接口和方法参数不允许超过两个，超过时使用request或DTO对象封装 -14. Controller层路由禁止添加/api前缀 -15. Controller层接口的Mapping注解value属性值不允许重复且不允许为空，必须明确指定value属性值且使用驼峰结构命名，避免使用下划线分隔符。所有接口注解必须显式指定value属性，如@GetMapping(value = "/page")、@PostMapping(value = "/create")等，禁止使用@GetMapping()或@PostMapping等空注解形式 -16. 用户相关接口禁止直接传递用户id，需要后端根据token获取当前登录用户信息 -17. 禁止使用/{param}格式的路径参数，避免网关路由冲突和分发错误 -18. 路径参数统一使用@RequestParam而非@PathVariable，确保网关分发准确性 -19. 接口路径命名应具有明确的语义，避免使用通用词汇如/get、/list等 -20. 批量操作接口应使用专门的Request对象封装参数，而非直接传递List -21. 接口路径应避免层级过深，建议不超过3级路径结构 -22. 更新操作应直接使用封装了ID和其他数据的Request对象，而不是单独传递ID参数。Service层方法应保持参数简洁，业务逻辑所需数据应全部包含在Request对象中 -23. Controller层接口应保持简洁，避免为特定字段创建独立的更新方法（如updateStatus等），应只保留一个通用的update方法，具体的业务逻辑在Service层实现 -24. Service层在执行更新操作时，应对每个字段进行空值检查，只更新非空字段，避免空字段覆盖原有值，确保数据完整性 -25. Controller层应避免创建多个特定条件的查询接口，只保留一个分页查询方法，通过在请求对象中包含所有可查询字段来支持不同的查询需求 -26. 分页查询接口应支持模糊查询和精确查询，通过在Service层根据字段类型和业务需求判断查询方式 - -## 环境配置 - -27. 为不同环境(local、dev、prod)创建单独配置文件，部署时通过参数选择 -28. 启动服务时禁止擅自修改端口号，使用配置文件中的端口设置 - -## 数据库规范 - -29. 所有数据表必须包含创建时间(create_time)和更新时间(update_time)字段 -30. 删除操作优先使用逻辑删除，添加deleted字段标识 -31. 数据库字段命名使用下划线分隔，Java实体类使用驼峰命名 -32. 优先使用LambdaQueryWrapper构造条件查询，避免硬编码字段名 -33. 使用Lambda表达式引用实体类属性，提高代码可维护性和类型安全 -34. 复杂查询条件应使用LambdaQueryWrapper的链式调用，保持代码清晰 -35. 避免在查询条件中使用字符串字段名，防止字段名变更导致的运行时错误 - -## 安全规范 - -36. 所有外部输入必须进行参数校验 -37. 敏感信息不得在日志中输出 -38. 数据库操作必须使用参数化查询，防止SQL注入 - -## 性能规范 - -39. 避免N+1查询问题，合理使用批量查询 -40. 大数据量查询必须分页处理 -41. 缓存策略要考虑数据一致性问题 - -## 日志规范 - -42. 关键业务操作必须记录操作日志 -43. 异常信息要包含足够的上下文信息 -44. 生产环境禁止输出debug级别日志 diff --git a/.cursor/commands/speckit.analyze.md b/.cursor/commands/speckit.analyze.md deleted file mode 100644 index 98b04b0..0000000 --- a/.cursor/commands/speckit.analyze.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -description: Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation. ---- - -## User Input - -```text -$ARGUMENTS -``` - -You **MUST** consider the user input before proceeding (if not empty). - -## Goal - -Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/speckit.tasks` has successfully produced a complete `tasks.md`. - -## Operating Constraints - -**STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually). - -**Constitution Authority**: The project constitution (`.specify/memory/constitution.md`) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/speckit.analyze`. - -## Execution Steps - -### 1. Initialize Analysis Context - -Run `.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks` once from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS. Derive absolute paths: - -- SPEC = FEATURE_DIR/spec.md -- PLAN = FEATURE_DIR/plan.md -- TASKS = FEATURE_DIR/tasks.md - -Abort with an error message if any required file is missing (instruct the user to run missing prerequisite command). -For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot"). - -### 2. Load Artifacts (Progressive Disclosure) - -Load only the minimal necessary context from each artifact: - -**From spec.md:** - -- Overview/Context -- Functional Requirements -- Non-Functional Requirements -- User Stories -- Edge Cases (if present) - -**From plan.md:** - -- Architecture/stack choices -- Data Model references -- Phases -- Technical constraints - -**From tasks.md:** - -- Task IDs -- Descriptions -- Phase grouping -- Parallel markers [P] -- Referenced file paths - -**From constitution:** - -- Load `.specify/memory/constitution.md` for principle validation - -### 3. Build Semantic Models - -Create internal representations (do not include raw artifacts in output): - -- **Requirements inventory**: Each functional + non-functional requirement with a stable key (derive slug based on imperative phrase; e.g., "User can upload file" → `user-can-upload-file`) -- **User story/action inventory**: Discrete user actions with acceptance criteria -- **Task coverage mapping**: Map each task to one or more requirements or stories (inference by keyword / explicit reference patterns like IDs or key phrases) -- **Constitution rule set**: Extract principle names and MUST/SHOULD normative statements - -### 4. Detection Passes (Token-Efficient Analysis) - -Focus on high-signal findings. Limit to 50 findings total; aggregate remainder in overflow summary. - -#### A. Duplication Detection - -- Identify near-duplicate requirements -- Mark lower-quality phrasing for consolidation - -#### B. Ambiguity Detection - -- Flag vague adjectives (fast, scalable, secure, intuitive, robust) lacking measurable criteria -- Flag unresolved placeholders (TODO, TKTK, ???, ``, etc.) - -#### C. Underspecification - -- Requirements with verbs but missing object or measurable outcome -- User stories missing acceptance criteria alignment -- Tasks referencing files or components not defined in spec/plan - -#### D. Constitution Alignment - -- Any requirement or plan element conflicting with a MUST principle -- Missing mandated sections or quality gates from constitution - -#### E. Coverage Gaps - -- Requirements with zero associated tasks -- Tasks with no mapped requirement/story -- Non-functional requirements not reflected in tasks (e.g., performance, security) - -#### F. Inconsistency - -- Terminology drift (same concept named differently across files) -- Data entities referenced in plan but absent in spec (or vice versa) -- Task ordering contradictions (e.g., integration tasks before foundational setup tasks without dependency note) -- Conflicting requirements (e.g., one requires Next.js while other specifies Vue) - -### 5. Severity Assignment - -Use this heuristic to prioritize findings: - -- **CRITICAL**: Violates constitution MUST, missing core spec artifact, or requirement with zero coverage that blocks baseline functionality -- **HIGH**: Duplicate or conflicting requirement, ambiguous security/performance attribute, untestable acceptance criterion -- **MEDIUM**: Terminology drift, missing non-functional task coverage, underspecified edge case -- **LOW**: Style/wording improvements, minor redundancy not affecting execution order - -### 6. Produce Compact Analysis Report - -Output a Markdown report (no file writes) with the following structure: - -## Specification Analysis Report - -| ID | Category | Severity | Location(s) | Summary | Recommendation | -|----|----------|----------|-------------|---------|----------------| -| A1 | Duplication | HIGH | spec.md:L120-134 | Two similar requirements ... | Merge phrasing; keep clearer version | - -(Add one row per finding; generate stable IDs prefixed by category initial.) - -**Coverage Summary Table:** - -| Requirement Key | Has Task? | Task IDs | Notes | -|-----------------|-----------|----------|-------| - -**Constitution Alignment Issues:** (if any) - -**Unmapped Tasks:** (if any) - -**Metrics:** - -- Total Requirements -- Total Tasks -- Coverage % (requirements with >=1 task) -- Ambiguity Count -- Duplication Count -- Critical Issues Count - -### 7. Provide Next Actions - -At end of report, output a concise Next Actions block: - -- If CRITICAL issues exist: Recommend resolving before `/speckit.implement` -- If only LOW/MEDIUM: User may proceed, but provide improvement suggestions -- Provide explicit command suggestions: e.g., "Run /speckit.specify with refinement", "Run /speckit.plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'" - -### 8. Offer Remediation - -Ask the user: "Would you like me to suggest concrete remediation edits for the top N issues?" (Do NOT apply them automatically.) - -## Operating Principles - -### Context Efficiency - -- **Minimal high-signal tokens**: Focus on actionable findings, not exhaustive documentation -- **Progressive disclosure**: Load artifacts incrementally; don't dump all content into analysis -- **Token-efficient output**: Limit findings table to 50 rows; summarize overflow -- **Deterministic results**: Rerunning without changes should produce consistent IDs and counts - -### Analysis Guidelines - -- **NEVER modify files** (this is read-only analysis) -- **NEVER hallucinate missing sections** (if absent, report them accurately) -- **Prioritize constitution violations** (these are always CRITICAL) -- **Use examples over exhaustive rules** (cite specific instances, not generic patterns) -- **Report zero issues gracefully** (emit success report with coverage statistics) - -## Context - -$ARGUMENTS diff --git a/.cursor/commands/speckit.checklist.md b/.cursor/commands/speckit.checklist.md deleted file mode 100644 index 970e6c9..0000000 --- a/.cursor/commands/speckit.checklist.md +++ /dev/null @@ -1,294 +0,0 @@ ---- -description: Generate a custom checklist for the current feature based on user requirements. ---- - -## Checklist Purpose: "Unit Tests for English" - -**CRITICAL CONCEPT**: Checklists are **UNIT TESTS FOR REQUIREMENTS WRITING** - they validate the quality, clarity, and completeness of requirements in a given domain. - -**NOT for verification/testing**: - -- ❌ NOT "Verify the button clicks correctly" -- ❌ NOT "Test error handling works" -- ❌ NOT "Confirm the API returns 200" -- ❌ NOT checking if code/implementation matches the spec - -**FOR requirements quality validation**: - -- ✅ "Are visual hierarchy requirements defined for all card types?" (completeness) -- ✅ "Is 'prominent display' quantified with specific sizing/positioning?" (clarity) -- ✅ "Are hover state requirements consistent across all interactive elements?" (consistency) -- ✅ "Are accessibility requirements defined for keyboard navigation?" (coverage) -- ✅ "Does the spec define what happens when logo image fails to load?" (edge cases) - -**Metaphor**: If your spec is code written in English, the checklist is its unit test suite. You're testing whether the requirements are well-written, complete, unambiguous, and ready for implementation - NOT whether the implementation works. - -## User Input - -```text -$ARGUMENTS -``` - -You **MUST** consider the user input before proceeding (if not empty). - -## Execution Steps - -1. **Setup**: Run `.specify/scripts/bash/check-prerequisites.sh --json` from repo root and parse JSON for FEATURE_DIR and AVAILABLE_DOCS list. - - All file paths must be absolute. - - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot"). - -2. **Clarify intent (dynamic)**: Derive up to THREE initial contextual clarifying questions (no pre-baked catalog). They MUST: - - Be generated from the user's phrasing + extracted signals from spec/plan/tasks - - Only ask about information that materially changes checklist content - - Be skipped individually if already unambiguous in `$ARGUMENTS` - - Prefer precision over breadth - - Generation algorithm: - 1. Extract signals: feature domain keywords (e.g., auth, latency, UX, API), risk indicators ("critical", "must", "compliance"), stakeholder hints ("QA", "review", "security team"), and explicit deliverables ("a11y", "rollback", "contracts"). - 2. Cluster signals into candidate focus areas (max 4) ranked by relevance. - 3. Identify probable audience & timing (author, reviewer, QA, release) if not explicit. - 4. Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries, measurable acceptance criteria. - 5. Formulate questions chosen from these archetypes: - - Scope refinement (e.g., "Should this include integration touchpoints with X and Y or stay limited to local module correctness?") - - Risk prioritization (e.g., "Which of these potential risk areas should receive mandatory gating checks?") - - Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?") - - Audience framing (e.g., "Will this be used by the author only or peers during PR review?") - - Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?") - - Scenario class gap (e.g., "No recovery flows detected—are rollback / partial failure paths in scope?") - - Question formatting rules: - - If presenting options, generate a compact table with columns: Option | Candidate | Why It Matters - - Limit to A–E options maximum; omit table if a free-form answer is clearer - - Never ask the user to restate what they already said - - Avoid speculative categories (no hallucination). If uncertain, ask explicitly: "Confirm whether X belongs in scope." - - Defaults when interaction impossible: - - Depth: Standard - - Audience: Reviewer (PR) if code-related; Author otherwise - - Focus: Top 2 relevance clusters - - Output the questions (label Q1/Q2/Q3). After answers: if ≥2 scenario classes (Alternate / Exception / Recovery / Non-Functional domain) remain unclear, you MAY ask up to TWO more targeted follow‑ups (Q4/Q5) with a one-line justification each (e.g., "Unresolved recovery path risk"). Do not exceed five total questions. Skip escalation if user explicitly declines more. - -3. **Understand user request**: Combine `$ARGUMENTS` + clarifying answers: - - Derive checklist theme (e.g., security, review, deploy, ux) - - Consolidate explicit must-have items mentioned by user - - Map focus selections to category scaffolding - - Infer any missing context from spec/plan/tasks (do NOT hallucinate) - -4. **Load feature context**: Read from FEATURE_DIR: - - spec.md: Feature requirements and scope - - plan.md (if exists): Technical details, dependencies - - tasks.md (if exists): Implementation tasks - - **Context Loading Strategy**: - - Load only necessary portions relevant to active focus areas (avoid full-file dumping) - - Prefer summarizing long sections into concise scenario/requirement bullets - - Use progressive disclosure: add follow-on retrieval only if gaps detected - - If source docs are large, generate interim summary items instead of embedding raw text - -5. **Generate checklist** - Create "Unit Tests for Requirements": - - Create `FEATURE_DIR/checklists/` directory if it doesn't exist - - Generate unique checklist filename: - - Use short, descriptive name based on domain (e.g., `ux.md`, `api.md`, `security.md`) - - Format: `[domain].md` - - If file exists, append to existing file - - Number items sequentially starting from CHK001 - - Each `/speckit.checklist` run creates a NEW file (never overwrites existing checklists) - - **CORE PRINCIPLE - Test the Requirements, Not the Implementation**: - Every checklist item MUST evaluate the REQUIREMENTS THEMSELVES for: - - **Completeness**: Are all necessary requirements present? - - **Clarity**: Are requirements unambiguous and specific? - - **Consistency**: Do requirements align with each other? - - **Measurability**: Can requirements be objectively verified? - - **Coverage**: Are all scenarios/edge cases addressed? - - **Category Structure** - Group items by requirement quality dimensions: - - **Requirement Completeness** (Are all necessary requirements documented?) - - **Requirement Clarity** (Are requirements specific and unambiguous?) - - **Requirement Consistency** (Do requirements align without conflicts?) - - **Acceptance Criteria Quality** (Are success criteria measurable?) - - **Scenario Coverage** (Are all flows/cases addressed?) - - **Edge Case Coverage** (Are boundary conditions defined?) - - **Non-Functional Requirements** (Performance, Security, Accessibility, etc. - are they specified?) - - **Dependencies & Assumptions** (Are they documented and validated?) - - **Ambiguities & Conflicts** (What needs clarification?) - - **HOW TO WRITE CHECKLIST ITEMS - "Unit Tests for English"**: - - ❌ **WRONG** (Testing implementation): - - "Verify landing page displays 3 episode cards" - - "Test hover states work on desktop" - - "Confirm logo click navigates home" - - ✅ **CORRECT** (Testing requirements quality): - - "Are the exact number and layout of featured episodes specified?" [Completeness] - - "Is 'prominent display' quantified with specific sizing/positioning?" [Clarity] - - "Are hover state requirements consistent across all interactive elements?" [Consistency] - - "Are keyboard navigation requirements defined for all interactive UI?" [Coverage] - - "Is the fallback behavior specified when logo image fails to load?" [Edge Cases] - - "Are loading states defined for asynchronous episode data?" [Completeness] - - "Does the spec define visual hierarchy for competing UI elements?" [Clarity] - - **ITEM STRUCTURE**: - Each item should follow this pattern: - - Question format asking about requirement quality - - Focus on what's WRITTEN (or not written) in the spec/plan - - Include quality dimension in brackets [Completeness/Clarity/Consistency/etc.] - - Reference spec section `[Spec §X.Y]` when checking existing requirements - - Use `[Gap]` marker when checking for missing requirements - - **EXAMPLES BY QUALITY DIMENSION**: - - Completeness: - - "Are error handling requirements defined for all API failure modes? [Gap]" - - "Are accessibility requirements specified for all interactive elements? [Completeness]" - - "Are mobile breakpoint requirements defined for responsive layouts? [Gap]" - - Clarity: - - "Is 'fast loading' quantified with specific timing thresholds? [Clarity, Spec §NFR-2]" - - "Are 'related episodes' selection criteria explicitly defined? [Clarity, Spec §FR-5]" - - "Is 'prominent' defined with measurable visual properties? [Ambiguity, Spec §FR-4]" - - Consistency: - - "Do navigation requirements align across all pages? [Consistency, Spec §FR-10]" - - "Are card component requirements consistent between landing and detail pages? [Consistency]" - - Coverage: - - "Are requirements defined for zero-state scenarios (no episodes)? [Coverage, Edge Case]" - - "Are concurrent user interaction scenarios addressed? [Coverage, Gap]" - - "Are requirements specified for partial data loading failures? [Coverage, Exception Flow]" - - Measurability: - - "Are visual hierarchy requirements measurable/testable? [Acceptance Criteria, Spec §FR-1]" - - "Can 'balanced visual weight' be objectively verified? [Measurability, Spec §FR-2]" - - **Scenario Classification & Coverage** (Requirements Quality Focus): - - Check if requirements exist for: Primary, Alternate, Exception/Error, Recovery, Non-Functional scenarios - - For each scenario class, ask: "Are [scenario type] requirements complete, clear, and consistent?" - - If scenario class missing: "Are [scenario type] requirements intentionally excluded or missing? [Gap]" - - Include resilience/rollback when state mutation occurs: "Are rollback requirements defined for migration failures? [Gap]" - - **Traceability Requirements**: - - MINIMUM: ≥80% of items MUST include at least one traceability reference - - Each item should reference: spec section `[Spec §X.Y]`, or use markers: `[Gap]`, `[Ambiguity]`, `[Conflict]`, `[Assumption]` - - If no ID system exists: "Is a requirement & acceptance criteria ID scheme established? [Traceability]" - - **Surface & Resolve Issues** (Requirements Quality Problems): - Ask questions about the requirements themselves: - - Ambiguities: "Is the term 'fast' quantified with specific metrics? [Ambiguity, Spec §NFR-1]" - - Conflicts: "Do navigation requirements conflict between §FR-10 and §FR-10a? [Conflict]" - - Assumptions: "Is the assumption of 'always available podcast API' validated? [Assumption]" - - Dependencies: "Are external podcast API requirements documented? [Dependency, Gap]" - - Missing definitions: "Is 'visual hierarchy' defined with measurable criteria? [Gap]" - - **Content Consolidation**: - - Soft cap: If raw candidate items > 40, prioritize by risk/impact - - Merge near-duplicates checking the same requirement aspect - - If >5 low-impact edge cases, create one item: "Are edge cases X, Y, Z addressed in requirements? [Coverage]" - - **🚫 ABSOLUTELY PROHIBITED** - These make it an implementation test, not a requirements test: - - ❌ Any item starting with "Verify", "Test", "Confirm", "Check" + implementation behavior - - ❌ References to code execution, user actions, system behavior - - ❌ "Displays correctly", "works properly", "functions as expected" - - ❌ "Click", "navigate", "render", "load", "execute" - - ❌ Test cases, test plans, QA procedures - - ❌ Implementation details (frameworks, APIs, algorithms) - - **✅ REQUIRED PATTERNS** - These test requirements quality: - - ✅ "Are [requirement type] defined/specified/documented for [scenario]?" - - ✅ "Is [vague term] quantified/clarified with specific criteria?" - - ✅ "Are requirements consistent between [section A] and [section B]?" - - ✅ "Can [requirement] be objectively measured/verified?" - - ✅ "Are [edge cases/scenarios] addressed in requirements?" - - ✅ "Does the spec define [missing aspect]?" - -6. **Structure Reference**: Generate the checklist following the canonical template in `.specify/templates/checklist-template.md` for title, meta section, category headings, and ID formatting. If template is unavailable, use: H1 title, purpose/created meta lines, `##` category sections containing `- [ ] CHK### ` lines with globally incrementing IDs starting at CHK001. - -7. **Report**: Output full path to created checklist, item count, and remind user that each run creates a new file. Summarize: - - Focus areas selected - - Depth level - - Actor/timing - - Any explicit user-specified must-have items incorporated - -**Important**: Each `/speckit.checklist` command invocation creates a checklist file using short, descriptive names unless file already exists. This allows: - -- Multiple checklists of different types (e.g., `ux.md`, `test.md`, `security.md`) -- Simple, memorable filenames that indicate checklist purpose -- Easy identification and navigation in the `checklists/` folder - -To avoid clutter, use descriptive types and clean up obsolete checklists when done. - -## Example Checklist Types & Sample Items - -**UX Requirements Quality:** `ux.md` - -Sample items (testing the requirements, NOT the implementation): - -- "Are visual hierarchy requirements defined with measurable criteria? [Clarity, Spec §FR-1]" -- "Is the number and positioning of UI elements explicitly specified? [Completeness, Spec §FR-1]" -- "Are interaction state requirements (hover, focus, active) consistently defined? [Consistency]" -- "Are accessibility requirements specified for all interactive elements? [Coverage, Gap]" -- "Is fallback behavior defined when images fail to load? [Edge Case, Gap]" -- "Can 'prominent display' be objectively measured? [Measurability, Spec §FR-4]" - -**API Requirements Quality:** `api.md` - -Sample items: - -- "Are error response formats specified for all failure scenarios? [Completeness]" -- "Are rate limiting requirements quantified with specific thresholds? [Clarity]" -- "Are authentication requirements consistent across all endpoints? [Consistency]" -- "Are retry/timeout requirements defined for external dependencies? [Coverage, Gap]" -- "Is versioning strategy documented in requirements? [Gap]" - -**Performance Requirements Quality:** `performance.md` - -Sample items: - -- "Are performance requirements quantified with specific metrics? [Clarity]" -- "Are performance targets defined for all critical user journeys? [Coverage]" -- "Are performance requirements under different load conditions specified? [Completeness]" -- "Can performance requirements be objectively measured? [Measurability]" -- "Are degradation requirements defined for high-load scenarios? [Edge Case, Gap]" - -**Security Requirements Quality:** `security.md` - -Sample items: - -- "Are authentication requirements specified for all protected resources? [Coverage]" -- "Are data protection requirements defined for sensitive information? [Completeness]" -- "Is the threat model documented and requirements aligned to it? [Traceability]" -- "Are security requirements consistent with compliance obligations? [Consistency]" -- "Are security failure/breach response requirements defined? [Gap, Exception Flow]" - -## Anti-Examples: What NOT To Do - -**❌ WRONG - These test implementation, not requirements:** - -```markdown -- [ ] CHK001 - Verify landing page displays 3 episode cards [Spec §FR-001] -- [ ] CHK002 - Test hover states work correctly on desktop [Spec §FR-003] -- [ ] CHK003 - Confirm logo click navigates to home page [Spec §FR-010] -- [ ] CHK004 - Check that related episodes section shows 3-5 items [Spec §FR-005] -``` - -**✅ CORRECT - These test requirements quality:** - -```markdown -- [ ] CHK001 - Are the number and layout of featured episodes explicitly specified? [Completeness, Spec §FR-001] -- [ ] CHK002 - Are hover state requirements consistently defined for all interactive elements? [Consistency, Spec §FR-003] -- [ ] CHK003 - Are navigation requirements clear for all clickable brand elements? [Clarity, Spec §FR-010] -- [ ] CHK004 - Is the selection criteria for related episodes documented? [Gap, Spec §FR-005] -- [ ] CHK005 - Are loading state requirements defined for asynchronous episode data? [Gap] -- [ ] CHK006 - Can "visual hierarchy" requirements be objectively measured? [Measurability, Spec §FR-001] -``` - -**Key Differences:** - -- Wrong: Tests if the system works correctly -- Correct: Tests if the requirements are written correctly -- Wrong: Verification of behavior -- Correct: Validation of requirement quality -- Wrong: "Does it do X?" -- Correct: "Is X clearly specified?" diff --git a/.cursor/commands/speckit.clarify.md b/.cursor/commands/speckit.clarify.md deleted file mode 100644 index 6b28dae..0000000 --- a/.cursor/commands/speckit.clarify.md +++ /dev/null @@ -1,181 +0,0 @@ ---- -description: Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec. -handoffs: - - label: Build Technical Plan - agent: speckit.plan - prompt: Create a plan for the spec. I am building with... ---- - -## User Input - -```text -$ARGUMENTS -``` - -You **MUST** consider the user input before proceeding (if not empty). - -## Outline - -Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file. - -Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/speckit.plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases. - -Execution steps: - -1. Run `.specify/scripts/bash/check-prerequisites.sh --json --paths-only` from repo root **once** (combined `--json --paths-only` mode / `-Json -PathsOnly`). Parse minimal JSON payload fields: - - `FEATURE_DIR` - - `FEATURE_SPEC` - - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.) - - If JSON parsing fails, abort and instruct user to re-run `/speckit.specify` or verify feature branch environment. - - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot"). - -2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked). - - Functional Scope & Behavior: - - Core user goals & success criteria - - Explicit out-of-scope declarations - - User roles / personas differentiation - - Domain & Data Model: - - Entities, attributes, relationships - - Identity & uniqueness rules - - Lifecycle/state transitions - - Data volume / scale assumptions - - Interaction & UX Flow: - - Critical user journeys / sequences - - Error/empty/loading states - - Accessibility or localization notes - - Non-Functional Quality Attributes: - - Performance (latency, throughput targets) - - Scalability (horizontal/vertical, limits) - - Reliability & availability (uptime, recovery expectations) - - Observability (logging, metrics, tracing signals) - - Security & privacy (authN/Z, data protection, threat assumptions) - - Compliance / regulatory constraints (if any) - - Integration & External Dependencies: - - External services/APIs and failure modes - - Data import/export formats - - Protocol/versioning assumptions - - Edge Cases & Failure Handling: - - Negative scenarios - - Rate limiting / throttling - - Conflict resolution (e.g., concurrent edits) - - Constraints & Tradeoffs: - - Technical constraints (language, storage, hosting) - - Explicit tradeoffs or rejected alternatives - - Terminology & Consistency: - - Canonical glossary terms - - Avoided synonyms / deprecated terms - - Completion Signals: - - Acceptance criteria testability - - Measurable Definition of Done style indicators - - Misc / Placeholders: - - TODO markers / unresolved decisions - - Ambiguous adjectives ("robust", "intuitive") lacking quantification - - For each category with Partial or Missing status, add a candidate question opportunity unless: - - Clarification would not materially change implementation or validation strategy - - Information is better deferred to planning phase (note internally) - -3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints: - - Maximum of 10 total questions across the whole session. - - Each question must be answerable with EITHER: - - A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR - - A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words"). - - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation. - - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved. - - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness). - - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests. - - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic. - -4. Sequential questioning loop (interactive): - - Present EXACTLY ONE question at a time. - - For multiple‑choice questions: - - **Analyze all options** and determine the **most suitable option** based on: - - Best practices for the project type - - Common patterns in similar implementations - - Risk reduction (security, performance, maintainability) - - Alignment with any explicit project goals or constraints visible in the spec - - Present your **recommended option prominently** at the top with clear reasoning (1-2 sentences explaining why this is the best choice). - - Format as: `**Recommended:** Option [X] - ` - - Then render all options as a Markdown table: - - | Option | Description | - |--------|-------------| - | A | diff --git a/manage.conf.yaml b/manage.conf.yaml index 27f500c..c0fea1f 100644 --- a/manage.conf.yaml +++ b/manage.conf.yaml @@ -4,7 +4,7 @@ services: backend: name: "后端服务" - dir: "backend-single" + dir: "server" type: "java" port: 19089 health_check_path: "/actuator/health" diff --git a/mini-program/src/pages/main/ScriptView.vue b/mini-program/src/pages/main/ScriptView.vue index d71566d..259e163 100644 --- a/mini-program/src/pages/main/ScriptView.vue +++ b/mini-program/src/pages/main/ScriptView.vue @@ -3035,13 +3035,13 @@ onUnmounted(() => { } .chat-voice-btn { - width: 86rpx; - height: 76rpx; + width: 72rpx; + height: 68rpx; flex-shrink: 0; display: flex; align-items: center; justify-content: center; - border-radius: 26rpx; + border-radius: 22rpx; color: #e8ccff; font-size: 24rpx; font-weight: 800; @@ -3057,7 +3057,7 @@ onUnmounted(() => { } .voice-icon { - font-size: 32rpx; + font-size: 24rpx; line-height: 1; } diff --git a/server/API_BASE_URL_MODIFICATION_SUMMARY.md b/server/API_BASE_URL_MODIFICATION_SUMMARY.md index e982766..4c03eba 100644 --- a/server/API_BASE_URL_MODIFICATION_SUMMARY.md +++ b/server/API_BASE_URL_MODIFICATION_SUMMARY.md @@ -9,25 +9,25 @@ ### 1. 实体类和DTO修改 #### 1.1 AiConfig.java -- **文件路径**: `backend-single/src/main/java/com/emotion/entity/AiConfig.java` +- **文件路径**: `server/src/main/java/com/emotion/entity/AiConfig.java` - **修改内容**: 更新 `apiBaseUrl` 字段注释 - **修改前**: `API基础URL` - **修改后**: `API完整URL（包含完整的接口路径，不需要再拼接任何后缀）例如：https://api.coze.cn/v3/chat` #### 1.2 AiConfigCreateRequest.java -- **文件路径**: `backend-single/src/main/java/com/emotion/dto/request/aiconfig/AiConfigCreateRequest.java` +- **文件路径**: `server/src/main/java/com/emotion/dto/request/aiconfig/AiConfigCreateRequest.java` - **修改内容**: 更新 `apiBaseUrl` 字段注释和验证消息 - **修改前**: `API基础URL` / `API基础URL不能为空` - **修改后**: `API完整URL（包含完整的接口路径，不需要再拼接任何后缀）` / `API完整URL不能为空` #### 1.3 AiConfigUpdateRequest.java -- **文件路径**: `backend-single/src/main/java/com/emotion/dto/request/aiconfig/AiConfigUpdateRequest.java` +- **文件路径**: `server/src/main/java/com/emotion/dto/request/aiconfig/AiConfigUpdateRequest.java` - **修改内容**: 更新 `apiBaseUrl` 字段注释 - **修改前**: `API基础URL` - **修改后**: `API完整URL（包含完整的接口路径，不需要再拼接任何后缀）` #### 1.4 AiConfigResponse.java -- **文件路径**: `backend-single/src/main/java/com/emotion/dto/response/aiconfig/AiConfigResponse.java` +- **文件路径**: `server/src/main/java/com/emotion/dto/response/aiconfig/AiConfigResponse.java` - **修改内容**: 更新 `apiBaseUrl` 字段注释 - **修改前**: `API基础URL` - **修改后**: `API完整URL（包含完整的接口路径，不需要再拼接任何后缀）` @@ -35,7 +35,7 @@ ### 2. 后端服务层修改 #### 2.1 AiChatServiceImpl.java -- **文件路径**: `backend-single/src/main/java/com/emotion/service/impl/AiChatServiceImpl.java` +- **文件路径**: `server/src/main/java/com/emotion/service/impl/AiChatServiceImpl.java` ##### 修改1: getApiPath方法 ```java @@ -151,7 +151,7 @@ const initTestData = (config: AiConfig) => { ### 4. 单元测试 #### 4.1 AiChatServiceImplTest.java -- **文件路径**: `backend-single/src/test/java/com/emotion/service/AiChatServiceImplTest.java` +- **文件路径**: `server/src/test/java/com/emotion/service/AiChatServiceImplTest.java` - **测试内容**: 1. `testGetApiPath`: 测试getApiPath方法返回空字符串 2. `testExtractBaseUrl`: 测试extractBaseUrl方法提取基础URL @@ -201,7 +201,7 @@ config.setApiBaseUrl("https://api.coze.cn/v3/chat"); // 完整URL ### 后端测试 ```bash -cd backend-single +cd server mvn test -Dtest=AiChatServiceImplTest ``` diff --git a/server/docs/ADMIN_AUTH_TEST.md b/server/docs/ADMIN_AUTH_TEST.md index ac7ced0..ea25b28 100644 --- a/server/docs/ADMIN_AUTH_TEST.md +++ b/server/docs/ADMIN_AUTH_TEST.md @@ -9,7 +9,7 @@ ### 2. 启动应用 ```bash -cd backend-single +cd server mvn spring-boot:run ``` diff --git a/server/src/main/java/com/emotion/EmotionSimpleApplication.java b/server/src/main/java/com/emotion/EmotionSimpleApplication.java index 1e35276..870e8c8 100644 --- a/server/src/main/java/com/emotion/EmotionSimpleApplication.java +++ b/server/src/main/java/com/emotion/EmotionSimpleApplication.java @@ -23,7 +23,7 @@ public class EmotionSimpleApplication { System.out.println("========================================"); System.out.println("🎉 情感博物馆服务启动成功！"); System.out.println("📋 服务信息:"); - System.out.println(" - 服务名称: backend-single"); + System.out.println(" - 服务名称: server"); System.out.println(" - 服务端口: 19089"); System.out.println(" - 环境配置: " + System.getProperty("spring.profiles.active")); System.out.println(" - API文档: http://localhost:19089/api/health"); diff --git a/server/src/main/java/com/emotion/controller/HealthController.java b/server/src/main/java/com/emotion/controller/HealthController.java index d308496..6baf1e3 100644 --- a/server/src/main/java/com/emotion/controller/HealthController.java +++ b/server/src/main/java/com/emotion/controller/HealthController.java @@ -32,7 +32,7 @@ public class HealthController { log.info("健康检查请求"); Map response = new HashMap<>(); - response.put("service", "backend-single"); + response.put("service", "server"); response.put("message", "情感博物馆单体服务运行正常"); response.put("version", "1.0.0"); response.put("status", "UP"); @@ -50,7 +50,7 @@ public class HealthController { log.info("服务信息请求"); Map response = new HashMap<>(); - response.put("service", "backend-single"); + response.put("service", "server"); response.put("description", "情感博物馆单体服务"); response.put("version", "1.0.0"); response.put("author", "emotion-museum"); diff --git a/web/src/services/auth.ts b/web/src/services/auth.ts index 7532642..a2544b4 100644 --- a/web/src/services/auth.ts +++ b/web/src/services/auth.ts @@ -55,7 +55,7 @@ export class AuthService { * 发送短信验证码（用于登录/注册/找回密码等场景） */ static async sendSmsCode(phone: string) { - // backend-single: GET /auth/sms-code?phone=xxx + // server: GET /auth/sms-code?phone=xxx const response = await http.get('/auth/sms-code', { params: { phone } }) return response.data } @@ -80,7 +80,7 @@ export class AuthService { * 获取当前用户信息 */ static async getCurrentUserInfo(): Promise { - // backend-single: GET /auth/userInfo + // server: GET /auth/userInfo const response = await http.get('/auth/userInfo') return response.data } diff --git a/web/src/services/chat.ts b/web/src/services/chat.ts index 147745c..6b14138 100644 --- a/web/src/services/chat.ts +++ b/web/src/services/chat.ts @@ -52,7 +52,7 @@ export class ChatApiService { async createSession(userId: string, title?: string): Promise { try { console.log('📝 创建会话API调用:', { userId, title }) - // backend-single: POST /conversation/create + // server: POST /conversation/create const response = await http.post('/conversation/create', { userId, title: title || `对话${Date.now()}` @@ -89,7 +89,7 @@ export class ChatApiService { async getUserSessions(userId: string): Promise { try { console.log('📂 获取用户会话API调用:', { userId }) - // backend-single: GET /conversation/page?userId=xxx + // server: GET /conversation/page?userId=xxx const response = await http.get('/conversation/page', { params: { userId, current: 1, size: 100 } }) console.log('📂 获取用户会话API响应:', response) @@ -132,7 +132,7 @@ export class ChatApiService { async deleteSession(sessionId: string): Promise { try { console.log('🗑️ 删除会话API调用:', { sessionId }) - // backend-single: DELETE /conversation/delete?id=xxx + // server: DELETE /conversation/delete?id=xxx await http.delete('/conversation/delete', { params: { id: sessionId } }) console.log('✅ 删除会话成功') } catch (error) { @@ -147,7 +147,7 @@ export class ChatApiService { async updateSessionTitle(sessionId: string, title: string): Promise { try { console.log('✏️ 更新会话标题API调用:', { sessionId, title }) - // backend-single: PUT /conversation/update 传id和title + // server: PUT /conversation/update 传id和title await http.put('/conversation/update', { id: sessionId, title }) console.log('✅ 更新会话标题成功') } catch (error) { diff --git a/web/src/services/message.ts b/web/src/services/message.ts index cdee90d..422f334 100644 --- a/web/src/services/message.ts +++ b/web/src/services/message.ts @@ -58,7 +58,7 @@ export const messageApi = { // 获取用户消息分页 getUserMessages: async (current: number = 1, size: number = 20) => { console.log('📨 调用getUserMessages API:', { current, size }) - // backend-single: GET /message/page （后端根据token识别用户） + // server: GET /message/page （后端根据token识别用户） const response = await http.get(`/message/page`, { params: { current, size } }) console.log('📨 getUserMessages API响应:', response) return response @@ -67,7 +67,7 @@ export const messageApi = { // 搜索用户消息 searchUserMessages: async (keyword: string, limit: number = 50) => { console.log('🔍 调用searchUserMessages API:', { keyword, limit }) - // backend-single: POST /message/search + // server: POST /message/search const resp = await http.post(`/message/search`, { keyword, limit }) console.log('🔍 searchUserMessages API响应:', resp) // 统一返回数组，兼容控制器返回 PageResult 结构 @@ -79,7 +79,7 @@ export const messageApi = { // 获取用户最近的聊天记录 - 返回数组，兼容后端 PageResult 结构 getRecentMessages: async (limit: number = 10) => { console.log('📝 调用getRecentMessages API:', { limit }) - // backend-single: POST /message/recent + // server: POST /message/recent const resp = await http.post(`/message/recent`, { limit }) console.log('📝 getRecentMessages API响应:', resp) const data: any = (resp as any).data || resp @@ -90,7 +90,7 @@ export const messageApi = { // 获取消息详情 getMessageById: async (id: string) => { console.log('📄 调用getMessageById API:', { id }) - // backend-single: GET /message/detail?id=xxx + // server: GET /message/detail?id=xxx const response = await http.get(`/message/detail`, { params: { id } }) console.log('📄 getMessageById API响应:', response) return response