@zeyue0329/xiaoma-cli 1.0.48 → 1.0.66

package/xiaoma-core/scripts/build-validation/quick-check.sh

@@ -1,69 +0,0 @@
-#!/bin/bash
-# <!-- Powered by XIAOMA™ Core -->
-# 30秒快速验证脚本
-# 用于开发过程中的快速反馈
-
-echo "⚡ 执行30秒快速验证..."
-echo "========================"
-
-# 设置超时
-timeout_duration=30
-
-# 使用timeout命令限制执行时间
-timeout $timeout_duration bash <<'EOF'
-set -e
-
-# 1. 快速编译检查（不清理）
-echo "→ 快速编译检查..."
-mvn compile -q -DskipTests=true
-if [ $? -eq 0 ]; then
-    echo "  ✓ 编译通过"
-else
-    echo "  ✗ 编译失败"
-    exit 1
-fi
-
-# 2. 测试编译检查
-echo "→ 测试编译检查..."
-mvn test-compile -q
-if [ $? -eq 0 ]; then
-    echo "  ✓ 测试编译通过"
-else
-    echo "  ✗ 测试编译失败"
-    exit 1
-fi
-
-# 3. 运行冒烟测试（如果存在）
-echo "→ 运行冒烟测试..."
-if ls src/test/java/**/*SmokeTest.java 1> /dev/null 2>&1; then
-    mvn surefire:test -Dtest=*SmokeTest -q
-    if [ $? -eq 0 ]; then
-        echo "  ✓ 冒烟测试通过"
-    else
-        echo "  ✗ 冒烟测试失败"
-        exit 1
-    fi
-else
-    echo "  - 未找到冒烟测试，跳过"
-fi
-
-echo ""
-echo "✅ 快速验证完成！"
-EOF
-
-exit_code=$?
-
-if [ $exit_code -eq 124 ]; then
-    echo ""
-    echo "⚠️  验证超时（超过30秒）"
-    echo "   建议检查编译性能"
-    exit 1
-elif [ $exit_code -ne 0 ]; then
-    echo ""
-    echo "❌ 快速验证失败"
-    echo "   请修复问题后重试"
-    exit $exit_code
-fi
-
-echo "========================"
-echo "⚡ 所有检查通过（用时<30秒）"

package/xiaoma-core/tasks/advanced-elicitation.md

@@ -1,119 +0,0 @@
-<!-- Powered by XiaoMa™ Core -->
-
-# Advanced Elicitation Task
-
-## Purpose
-
-- Provide optional reflective and brainstorming actions to enhance content quality
-- Enable deeper exploration of ideas through structured elicitation techniques
-- Support iterative refinement through multiple analytical perspectives
-- Usable during template-driven document creation or any chat conversation
-
-## Usage Scenarios
-
-### Scenario 1: Template Document Creation
-
-After outputting a section during document creation:
-
-1. **Section Review**: Ask user to review the drafted section
-2. **Offer Elicitation**: Present 9 carefully selected elicitation methods
-3. **Simple Selection**: User types a number (0-8) to engage method, or 9 to proceed
-4. **Execute & Loop**: Apply selected method, then re-offer choices until user proceeds
-
-### Scenario 2: General Chat Elicitation
-
-User can request advanced elicitation on any agent output:
-
-- User says "do advanced elicitation" or similar
-- Agent selects 9 relevant methods for the context
-- Same simple 0-9 selection process
-
-## Task Instructions
-
-### 1. Intelligent Method Selection
-
-**Context Analysis**: Before presenting options, analyze:
-
-- **Content Type**: Technical specs, user stories, architecture, requirements, etc.
-- **Complexity Level**: Simple, moderate, or complex content
-- **Stakeholder Needs**: Who will use this information
-- **Risk Level**: High-impact decisions vs routine items
-- **Creative Potential**: Opportunities for innovation or alternatives
-
-**Method Selection Strategy**:
-
-1. **Always Include Core Methods** (choose 3-4):
-   - Expand or Contract for Audience
-   - Critique and Refine
-   - Identify Potential Risks
-   - Assess Alignment with Goals
-
-2. **Context-Specific Methods** (choose 4-5):
-   - **Technical Content**: Tree of Thoughts, ReWOO, Meta-Prompting
-   - **User-Facing Content**: Agile Team Perspective, Stakeholder Roundtable
-   - **Creative Content**: Innovation Tournament, Escape Room Challenge
-   - **Strategic Content**: Red Team vs Blue Team, Hindsight Reflection
-
-3. **Always Include**: "Proceed / No Further Actions" as option 9
-
-### 2. Section Context and Review
-
-When invoked after outputting a section:
-
-1. **Provide Context Summary**: Give a brief 1-2 sentence summary of what the user should look for in the section just presented
-
-2. **Explain Visual Elements**: If the section contains diagrams, explain them briefly before offering elicitation options
-
-3. **Clarify Scope Options**: If the section contains multiple distinct items, inform the user they can apply elicitation actions to:
-   - The entire section as a whole
-   - Individual items within the section (specify which item when selecting an action)
-
-### 3. Present Elicitation Options
-
-**Review Request Process:**
-
-- Ask the user to review the drafted section
-- In the SAME message, inform them they can suggest direct changes OR select an elicitation method
-- Present 9 intelligently selected methods (0-8) plus "Proceed" (9)
-- Keep descriptions short - just the method name
-- Await simple numeric selection
-
-**Action List Presentation Format:**
-
-```text
-**Advanced Elicitation Options**
-Choose a number (0-8) or 9 to proceed:
-
-0. [Method Name]
-1. [Method Name]
-2. [Method Name]
-3. [Method Name]
-4. [Method Name]
-5. [Method Name]
-6. [Method Name]
-7. [Method Name]
-8. [Method Name]
-9. Proceed / No Further Actions
-```
-
-**Response Handling:**
-
-- **Numbers 0-8**: Execute the selected method, then re-offer the choice
-- **Number 9**: Proceed to next section or continue conversation
-- **Direct Feedback**: Apply user's suggested changes and continue
-
-### 4. Method Execution Framework
-
-**Execution Process:**
-
-1. **Retrieve Method**: Access the specific elicitation method from the elicitation-methods data file
-2. **Apply Context**: Execute the method from your current role's perspective
-3. **Provide Results**: Deliver insights, critiques, or alternatives relevant to the content
-4. **Re-offer Choice**: Present the same 9 options again until user selects 9 or gives direct feedback
-
-**Execution Guidelines:**
-
-- **Be Concise**: Focus on actionable insights, not lengthy explanations
-- **Stay Relevant**: Tie all elicitation back to the specific content being analyzed
-- **Identify Personas**: For multi-persona methods, clearly identify which viewpoint is speaking
-- **Maintain Flow**: Keep the process moving efficiently

package/xiaoma-core/tasks/analyze-existing-database.md

@@ -1,155 +0,0 @@
-# 分析现有数据库
-
-## 任务概述
-
-连接到MySQL数据库并分析现有的数据库结构，生成或更新数据库文档。
-
-## 执行步骤
-
-### 1. 检查现有文档
-
-```yaml
-action: check_existing_documentation
-path: docs/database/
-pattern: "{project_name}-database.md"
-```
-
-### 2. 连接数据库
-
-```yaml
-action: connect_mysql_via_mcp
-service: mysql-server
-operation: |
-  使用MCP mysql-server服务连接到数据库
-  获取连接配置信息
-```
-
-### 3. 分析数据库结构
-
-#### 3.1 获取所有表信息
-
-```sql
-SHOW TABLES;
-```
-
-#### 3.2 获取每个表的结构
-
-```sql
-DESCRIBE {table_name};
-SHOW CREATE TABLE {table_name};
-```
-
-#### 3.3 获取外键关系
-
-```sql
-SELECT
-    CONSTRAINT_NAME,
-    TABLE_NAME,
-    COLUMN_NAME,
-    REFERENCED_TABLE_NAME,
-    REFERENCED_COLUMN_NAME
-FROM
-    INFORMATION_SCHEMA.KEY_COLUMN_USAGE
-WHERE
-    REFERENCED_TABLE_NAME IS NOT NULL
-    AND TABLE_SCHEMA = DATABASE();
-```
-
-#### 3.4 获取索引信息
-
-```sql
-SHOW INDEX FROM {table_name};
-```
-
-### 4. 生成关系图
-
-生成Mermaid格式的ER图：
-
-```mermaid
-erDiagram
-    TABLE1 ||--o{ TABLE2 : relationship
-    TABLE1 {
-        type field_name PK
-        type field_name
-    }
-```
-
-### 5. 生成文档
-
-#### 文档结构模板：
-
-```markdown
-# {项目名称} 数据库设计文档
-
-## 数据库概览
-
-- **数据库名称**: {database_name}
-- **字符集**: {charset}
-- **排序规则**: {collation}
-- **更新时间**: {timestamp}
-
-## 表结构清单
-
-{表列表和简要说明}
-
-## 数据表详细设计
-
-### 表名: {table_name}
-
-**描述**: {table_description}
-
-#### 字段定义
-
-| 字段名  | 数据类型 | 允许空 | 默认值    | 主键  | 说明      |
-| ------- | -------- | ------ | --------- | ----- | --------- |
-| {field} | {type}   | {null} | {default} | {key} | {comment} |
-
-#### 索引信息
-
-| 索引名  | 字段      | 类型   | 唯一性   |
-| ------- | --------- | ------ | -------- |
-| {index} | {columns} | {type} | {unique} |
-
-#### 外键约束
-
-| 约束名       | 字段     | 参照表      | 参照字段     |
-| ------------ | -------- | ----------- | ------------ |
-| {constraint} | {column} | {ref_table} | {ref_column} |
-
-## 数据库关系图
-
-{Mermaid ER图}
-
-## 数据字典
-
-{详细的数据字典说明}
-```
-
-### 6. 更新或创建文档
-
-```yaml
-condition: document_exists
-  true:
-    action: compare_and_update
-    steps:
-      - 对比现有文档与数据库实际结构
-      - 标记新增的表和字段
-      - 标记删除的表和字段
-      - 标记修改的字段属性
-      - 更新文档并保留历史版本信息
-  false:
-    action: create_new_document
-    path: "docs/database/{project_name}-database.md"
-```
-
-## 任务输出
-
-- 完整的数据库设计文档
-- 数据库关系图
-- 变更记录（如果是更新）
-
-## 注意事项
-
-- 确保MCP mysql-server服务已配置
-- 需要有数据库的读取权限
-- 文档应包含版本控制信息

package/xiaoma-core/tasks/apply-qa-fixes.md

@@ -1,150 +0,0 @@
-<!-- Powered by XiaoMa™ Core -->
-
-# apply-qa-fixes
-
-Implement fixes based on QA results (gate and assessments) for a specific story. This task is for the Dev agent to systematically consume QA outputs and apply code/test changes while only updating allowed sections in the story file.
-
-## Purpose
-
-- Read QA outputs for a story (gate YAML + assessment markdowns)
-- Create a prioritized, deterministic fix plan
-- Apply code and test changes to close gaps and address issues
-- Update only the allowed story sections for the Dev agent
-
-## Inputs
-
-```yaml
-required:
-  - story_id: "{epic}.{story}" # e.g., "2.2"
-  - qa_root: from `xiaoma-core/core-config.yaml` key `qa.qaLocation` (e.g., `docs/project/qa`)
-  - story_root: from `xiaoma-core/core-config.yaml` key `devStoryLocation` (e.g., `docs/project/stories`)
-
-optional:
-  - story_title: "{title}" # derive from story H1 if missing
-  - story_slug: "{slug}" # derive from title (lowercase, hyphenated) if missing
-```
-
-## QA Sources to Read
-
-- Gate (YAML): `{qa_root}/gates/{epic}.{story}-*.yml`
-  - If multiple, use the most recent by modified time
-- Assessments (Markdown):
-  - Test Design: `{qa_root}/assessments/{epic}.{story}-test-design-*.md`
-  - Traceability: `{qa_root}/assessments/{epic}.{story}-trace-*.md`
-  - Risk Profile: `{qa_root}/assessments/{epic}.{story}-risk-*.md`
-  - NFR Assessment: `{qa_root}/assessments/{epic}.{story}-nfr-*.md`
-
-## Prerequisites
-
-- Repository builds and tests run locally (Deno 2)
-- Lint and test commands available:
-  - `deno lint`
-  - `deno test -A`
-
-## Process (Do not skip steps)
-
-### 0) Load Core Config & Locate Story
-
-- Read `xiaoma-core/core-config.yaml` and resolve `qa_root` and `story_root`
-- Locate story file in `{story_root}/{epic}.{story}.*.md`
-  - HALT if missing and ask for correct story id/path
-
-### 1) Collect QA Findings
-
-- Parse the latest gate YAML:
-  - `gate` (PASS|CONCERNS|FAIL|WAIVED)
-  - `top_issues[]` with `id`, `severity`, `finding`, `suggested_action`
-  - `nfr_validation.*.status` and notes
-  - `trace` coverage summary/gaps
-  - `test_design.coverage_gaps[]`
-  - `risk_summary.recommendations.must_fix[]` (if present)
-- Read any present assessment markdowns and extract explicit gaps/recommendations
-
-### 2) Build Deterministic Fix Plan (Priority Order)
-
-Apply in order, highest priority first:
-
-1. High severity items in `top_issues` (security/perf/reliability/maintainability)
-2. NFR statuses: all FAIL must be fixed → then CONCERNS
-3. Test Design `coverage_gaps` (prioritize P0 scenarios if specified)
-4. Trace uncovered requirements (AC-level)
-5. Risk `must_fix` recommendations
-6. Medium severity issues, then low
-
-Guidance:
-
-- Prefer tests closing coverage gaps before/with code changes
-- Keep changes minimal and targeted; follow project architecture and TS/Deno rules
-
-### 3) Apply Changes
-
-- Implement code fixes per plan
-- Add missing tests to close coverage gaps (unit first; integration where required by AC)
-- Keep imports centralized via `deps.ts` (see `docs/project/typescript-rules.md`)
-- Follow DI boundaries in `src/core/di.ts` and existing patterns
-
-### 4) Validate
-
-- Run `deno lint` and fix issues
-- Run `deno test -A` until all tests pass
-- Iterate until clean
-
-### 5) Update Story (Allowed Sections ONLY)
-
-CRITICAL: Dev agent is ONLY authorized to update these sections of the story file. Do not modify any other sections (e.g., QA Results, Story, Acceptance Criteria, Dev Notes, Testing):
-
-- Tasks / Subtasks Checkboxes (mark any fix subtask you added as done)
-- Dev Agent Record →
-  - Agent Model Used (if changed)
-  - Debug Log References (commands/results, e.g., lint/tests)
-  - Completion Notes List (what changed, why, how)
-  - File List (all added/modified/deleted files)
-- Change Log (new dated entry describing applied fixes)
-- Status (see Rule below)
-
-Status Rule:
-
-- If gate was PASS and all identified gaps are closed → set `Status: Ready for Done`
-- Otherwise → set `Status: Ready for Review` and notify QA to re-run the review
-
-### 6) Do NOT Edit Gate Files
-
-- Dev does not modify gate YAML. If fixes address issues, request QA to re-run `review-story` to update the gate
-
-## Blocking Conditions
-
-- Missing `xiaoma-core/core-config.yaml`
-- Story file not found for `story_id`
-- No QA artifacts found (neither gate nor assessments)
-  - HALT and request QA to generate at least a gate file (or proceed only with clear developer-provided fix list)
-
-## Completion Checklist
-
-- deno lint: 0 problems
-- deno test -A: all tests pass
-- All high severity `top_issues` addressed
-- NFR FAIL → resolved; CONCERNS minimized or documented
-- Coverage gaps closed or explicitly documented with rationale
-- Story updated (allowed sections only) including File List and Change Log
-- Status set according to Status Rule
-
-## Example: Story 2.2
-
-Given gate `docs/project/qa/gates/2.2-*.yml` shows
-
-- `coverage_gaps`: Back action behavior untested (AC2)
-- `coverage_gaps`: Centralized dependencies enforcement untested (AC4)
-
-Fix plan:
-
-- Add a test ensuring the Toolkit Menu "Back" action returns to Main Menu
-- Add a static test verifying imports for service/view go through `deps.ts`
-- Re-run lint/tests and update Dev Agent Record + File List accordingly
-
-## Key Principles
-
-- Deterministic, risk-first prioritization
-- Minimal, maintainable changes
-- Tests validate behavior and close gaps
-- Strict adherence to allowed story update areas
-- Gate ownership remains with QA; Dev signals readiness via Status