@zeyue0329/xiaoma-cli 1.0.48 → 6.0.0-alpha.13

package/xiaoma-core/templates/maven-lombok-template.xml

@@ -1,111 +0,0 @@
-<!-- Powered by XIAOMA™ Core -->
-<!-- Maven POM配置模板 - Lombok最佳实践 -->
-<!-- 基于首周期经验优化，解决编译问题 -->
-
-<project>
-    <!-- 属性配置 -->
-    <properties>
-        <java.version>17</java.version>
-        <maven.compiler.source>17</maven.compiler.source>
-        <maven.compiler.target>17</maven.compiler.target>
-        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
-        <lombok.version>1.18.34</lombok.version>
-        <spring-boot.version>2.7.18</spring-boot.version>
-    </properties>
-
-    <!-- 依赖配置 -->
-    <dependencies>
-        <!-- Lombok依赖（关键配置） -->
-        <dependency>
-            <groupId>org.projectlombok</groupId>
-            <artifactId>lombok</artifactId>
-            <version>${lombok.version}</version>
-            <scope>provided</scope>
-        </dependency>
-    </dependencies>
-
-    <!-- 构建配置（关键：解决Lombok编译问题） -->
-    <build>
-        <plugins>
-            <!-- Maven编译器插件 - 必须配置注解处理器路径 -->
-            <plugin>
-                <groupId>org.apache.maven.plugins</groupId>
-                <artifactId>maven-compiler-plugin</artifactId>
-                <version>3.11.0</version>
-                <configuration>
-                    <source>${java.version}</source>
-                    <target>${java.version}</target>
-                    <encoding>${project.build.sourceEncoding}</encoding>
-                    <!-- 关键配置：Lombok注解处理器路径 -->
-                    <annotationProcessorPaths>
-                        <path>
-                            <groupId>org.projectlombok</groupId>
-                            <artifactId>lombok</artifactId>
-                            <version>${lombok.version}</version>
-                        </path>
-                        <!-- 如果使用MyBatis Plus，添加其注解处理器 -->
-                        <path>
-                            <groupId>com.baomidou</groupId>
-                            <artifactId>mybatis-plus-processor</artifactId>
-                            <version>3.5.3.1</version>
-                        </path>
-                    </annotationProcessorPaths>
-                    <compilerArgs>
-                        <arg>-parameters</arg>
-                    </compilerArgs>
-                </configuration>
-            </plugin>
-
-            <!-- Surefire插件 - 测试配置 -->
-            <plugin>
-                <groupId>org.apache.maven.plugins</groupId>
-                <artifactId>maven-surefire-plugin</artifactId>
-                <version>2.22.2</version>
-                <configuration>
-                    <skipTests>false</skipTests>
-                    <testFailureIgnore>false</testFailureIgnore>
-                    <includes>
-                        <include>**/*Test.java</include>
-                        <include>**/*Tests.java</include>
-                    </includes>
-                </configuration>
-            </plugin>
-
-            <!-- Failsafe插件 - 集成测试配置 -->
-            <plugin>
-                <groupId>org.apache.maven.plugins</groupId>
-                <artifactId>maven-failsafe-plugin</artifactId>
-                <version>2.22.2</version>
-                <configuration>
-                    <includes>
-                        <include>**/*IT.java</include>
-                        <include>**/*IntegrationTest.java</include>
-                    </includes>
-                </configuration>
-                <executions>
-                    <execution>
-                        <goals>
-                            <goal>integration-test</goal>
-                            <goal>verify</goal>
-                        </goals>
-                    </execution>
-                </executions>
-            </plugin>
-        </plugins>
-    </build>
-
-    <!-- 配置说明 -->
-    <!-- 
-    关键点：
-    1. Lombok版本使用1.18.34（兼容Java 17）
-    2. 必须配置annotationProcessorPaths
-    3. 编译器参数添加-parameters
-    4. scope设置为provided
-    5. 测试插件正确配置
-    
-    常见问题解决：
-    - 编译错误：检查annotationProcessorPaths配置
-    - IDE不识别：安装Lombok插件并启用注解处理
-    - 版本冲突：统一使用属性管理版本
-    -->
-</project>

package/xiaoma-core/templates/prd-tmpl.yaml

@@ -1,202 +0,0 @@
-template:
-  id: prd-template-v2
-  name: 产品需求文档
-  version: 2.0
-  output:
-    format: markdown
-    filename: docs/prd.md
-    title: "{{project_name}} Product Requirements Document (PRD)"
-
-workflow:
-  mode: interactive
-  elicitation: advanced-elicitation
-
-sections:
-  - id: goals-context
-    title: 目标与背景上下文
-    instruction: |
-      询问“项目简报”文档是否可用。如果不存在“项目简报”，强烈建议首先使用 project-brief-tmpl 创建一个（它提供了必要的基础：问题陈述、目标用户、成功指标、MVP 范围、约束条件）。如果用户坚持在没有简报的情况下编写 PRD，请在“目标”部分收集这些信息。如果“项目简报”存在，请审阅并用它来填充“目标”（期望成果的项目符号列表）和“背景上下文”（1-2 段关于此项目解决什么问题及其原因的说明），以便我们能确定 PRD MVP 的范围内外事项。无论哪种方式，这对于确定需求都至关重要。请包含“变更日志”表格。
-    sections:
-      - id: goals
-        title: 目标
-        type: bullet-list
-        instruction: 以项目符号列表形式，每行一个，列出 PRD 成功后将交付的预期成果——用户和项目的期望。
-      - id: background
-        title: 背景上下文
-        type: paragraphs
-        instruction: 用 1-2 个简短段落总结背景上下文，例如我们在项目简报中学到了什么（避免与目标重复），这个项目解决什么问题以及为什么，当前的行业状况或需求是什么。
-      - id: changelog
-        title: 变更日志
-        type: table
-        columns: [日期, 版本, 描述, 作者]
-        instruction: 跟踪文档版本和变更
-
-  - id: requirements
-    title: 需求
-    instruction: 在两个子部分下起草功能性和非功能性需求列表。
-    elicit: true
-    sections:
-      - id: functional
-        title: 功能性需求
-        type: numbered-list
-        prefix: FR
-        instruction: 每个需求将是一个 Markdown 项目符号，并带有一个以 FR 开头的标识符序列。
-        examples:
-          - "FR6: 待办事项列表使用 AI 检测并警告措辞不同但可能重复的待办事项。"
-      - id: non-functional
-        title: 非功能性需求
-        type: numbered-list
-        prefix: NFR
-        instruction: 每个需求将是一个 Markdown 项目符号，并带有一个以 NFR 开头的标识符序列。
-        examples:
-          - "NFR1: 在可行的情况下，AWS 服务的使用必须力求保持在免费套餐限制内。"
-
-  - id: ui-goals
-    title: 用户界面设计目标
-    condition: PRD 包含 UX/UI 需求时
-    instruction: |
-      捕获高层次的 UI/UX 愿景，以指导设计架构师并为创建用户故事提供信息。步骤：
-
-      1. 基于项目上下文，用有根据的猜测预先填充所有子部分。
-      2. 将渲染后的完整部分呈现给用户。
-      3. 清晰地告知用户哪些地方做了假设。
-      4. 针对不清晰/缺失的元素或需要更具体说明的领域提出有针对性的问题。
-      5. 这不是详细的 UI 规范——重点关注产品愿景和用户目标。
-    elicit: true
-    choices:
-      accessibility: [无, WCAG AA, WCAG AAA]
-      platforms: [响应式网页, 仅移动端, 仅桌面端, 跨平台]
-    sections:
-      - id: ux-vision
-        title: 整体 UX 愿景
-      - id: interaction-paradigms
-        title: 关键交互范式
-      - id: core-screens
-        title: 核心屏幕与视图
-        instruction: 从产品角度看，为实现 PRD 的价值和目标，最关键的屏幕或视图是什么？这旨在提供概念性的高层概览，以驱动粗略的模块或用户故事。
-        examples:
-          - "登录屏幕"
-          - "主仪表盘"
-          - "项目详情页"
-          - "设置页面"
-      - id: accessibility
-        title: "无障碍性: {无|WCAG AA|WCAG AAA|自定义要求}"
-      - id: branding
-        title: 品牌
-        instruction: 是否有任何已知的品牌元素或风格指南必须被整合进来？
-        examples:
-          - "复制 20 世纪初黑白电影的观感，包括在页面或状态转换期间模拟胶片损坏或投影仪故障的动画效果。"
-          - "附件是我司品牌的全套调色板和设计元素。"
-      - id: target-platforms
-        title: "目标设备与平台: {响应式网页|仅移动端|仅桌面端|跨平台}"
-        examples:
-          - "响应式网页，以及所有移动平台"
-          - "仅限 iPhone"
-          - "ASCII 码 Windows 桌面"
-
-  - id: technical-assumptions
-    title: 技术假设
-    instruction: |
-      收集将指导架构师的技术决策。步骤：
-
-      1. 检查 {root}/data/technical-preferences.yaml 或附加的技术偏好文件是否存在——用它来预填充选项。
-      2. 询问用户关于：语言、框架、启动模板、库、API、部署目标。
-      3. 对于未知项，根据项目目标和 MVP 范围提供指导。
-      4. 记录所有技术选择及其理由（为什么这个选择适合该项目）。
-      5. 这些将成为架构师的约束条件——务必具体和完整。
-    elicit: true
-    choices:
-      repository: [Monorepo, Polyrepo]
-      architecture: [Monolith, Microservices, Serverless]
-      testing: [仅单元测试, 单元+集成测试, 完整测试金字塔]
-    sections:
-      - id: repository-structure
-        title: "代码仓库结构: {Monorepo|Polyrepo|Multi-repo}"
-      - id: service-architecture
-        title: 服务架构
-        instruction: "关键决策 - 记录高层服务架构（例如，Monolith, Microservices, Monorepo 内的 Serverless 函数）。"
-      - id: testing-requirements
-        title: 测试要求
-        instruction: "关键决策 - 记录测试要求（仅单元测试、集成测试、e2e 测试、手动测试，以及是否需要方便手动测试的方法）。"
-      - id: additional-assumptions
-        title: 其他技术假设与请求
-        instruction: 在起草本文档的整个过程中，如果提出或发现任何其他适合架构师的技术假设，请在此处作为额外的项目符号添加。
-
-  - id: epic-list
-    title: 模块列表
-    instruction: |
-      向用户呈现一份高层次的模块列表以供批准。每个模块应有一个标题和一个简短的（1句话）目标陈述。这使用户能在深入细节之前审阅整体结构。
-
-      关键：模块必须遵循敏捷最佳实践，保持逻辑上的顺序：
-
-      - 每个模块都应交付一个重要的、端到端的、完全可部署且可测试的功能增量。
-      - 模块 1 必须建立基础项目设施（应用设置、Git、CI/CD、核心服务），除非我们是向现有应用添加新功能。同时，它还应交付一个初始功能，即使只是一个健康检查路由或一个简单的金丝雀页面显示——在为第一个模块编写用户故事时要记住这一点！
-      - 每个后续的模块都在之前模块功能的基础上构建，交付主要的功能模块，这些模块在部署时能为用户或业务提供切实的价值。
-      - 并非每个项目都需要多个模块，一个模块需要交付价值。例如，一个已完成的 API 即使 UI 尚未完成并计划在另一个模块中实现，也可以交付价值。
-      - 倾向于设置较少的模块，但要告知用户你的理由，并提供拆分选项，如果某些模块看起来太大或关注点分散的话。
-      - 横切关注点应该贯穿于模块和用户故事中，而不是作为最后的用户故事。例如，在一个模块的最后一个故事中添加日志框架，或者在项目结束时作为最后一个模块或故事来做，这将非常糟糕，因为我们从一开始就没有日志记录。
-    elicit: true
-    examples:
-      - "模块 1：基础与核心设施：建立项目设置、认证和基本用户管理"
-      - "模块 2：核心业务实体：创建和管理主要领域对象的 CRUD 操作"
-      - "模块 3：用户工作流与交互：实现关键用户旅程和业务流程"
-      - "模块 4：报告与分析：为用户提供洞察和数据可视化"
-
-  - id: epic-details
-    title: 模块 {{epic_number}} {{epic_title}}
-    repeatable: true
-    instruction: |
-      在模块列表被批准后，将每个模块及其所有的用户故事和验收标准作为一个完整的审查单元呈现。
-
-      为每个模块提供扩展的目标（2-3 句话描述所有故事将实现的目标和价值）。
-
-      关键的用户故事排序要求：
-
-      - 每个模块中的用户故事必须在逻辑上是顺序的。
-      - 每个故事都应该是一个“垂直切片”，交付完整的功能，除了项目基础的早期使能型故事。
-      - 任何故事都不应依赖于后续故事或模块的工作。
-      - 识别并注明任何直接的前置故事。
-      - 关注“做什么”和“为什么”，而不是“怎么做”（将技术实现留给架构师），但要足够精确以支持故事之间逻辑上顺序的操作。
-      - 确保每个故事都交付明确的用户或业务价值，尽量避免使能型故事，而是将它们构建到交付价值的故事中。
-      - 为 AI 代理执行调整故事的大小：每个故事必须能由单个 AI 代理在一次专注的会话中完成，而不会出现上下文溢出。
-      - 想象一个“初级开发人员工作 2-4 小时”的场景——故事必须是小型的、专注的、自包含的。
-      - 如果一个故事看起来很复杂，只要它能交付一个垂直切片，就应进一步拆分。
-    elicit: true
-    template: "{{epic_goal}}"
-    sections:
-      - id: story
-        title: 用户故事 {{epic_number}}.{{story_number}} {{story_title}}
-        repeatable: true
-        template: |
-          作为一名 {{user_type}}，
-          我想要 {{action}}，
-          以便 {{benefit}}。
-        sections:
-          - id: acceptance-criteria
-            title: 验收标准
-            type: numbered-list
-            item_template: "{{criterion_number}}: {{criteria}}"
-            repeatable: true
-            instruction: |
-              定义清晰、全面且可测试的验收标准，这些标准应：
-
-              - 从功能角度精确定义“完成”的含义。
-              - 明确无歧义，并作为验证的基础。
-              - 包括来自 PRD 的任何关键非功能性需求。
-              - 考虑后端/数据组件的本地可测试性。
-              - 在适用时，指定 UI/UX 需求和框架遵循情况。
-              - 避免应放在其他故事或 PRD 部分的横切关注点。
-
-  - id: checklist-results
-    title: 检查清单结果报告
-    instruction: 在运行检查清单和起草提示之前，提议输出更新后的完整 PRD。如果输出，请与用户确认你将继续运行检查清单并生成报告。一旦用户确认，执行 pm-checklist 并在此部分填充结果。
-
-  - id: next-steps
-    title: 后续步骤
-    sections:
-      - id: ux-expert-prompt
-        title: UX 专家提示
-        instruction: 此部分将包含给 UX 专家的提示，保持简短扼要，以启动使用本文档作为输入的架构创建模式。
-      - id: architect-prompt
-        title: 架构师提示
-        instruction: 此部分将包含给架构师的提示，保持简短扼要，以启动使用本文档作为输入的架构创建模式。

package/xiaoma-core/templates/project-brief-tmpl.yaml

@@ -1,221 +0,0 @@
-template:
-  id: project-brief-template-v2
-  name: 项目简报
-  version: 2.0
-  output:
-    format: markdown
-    filename: docs/brief.md
-    title: "Project Brief: {{project_name}}"
-
-workflow:
-  mode: interactive
-  elicitation: advanced-elicitation
-  custom_elicitation:
-    title: "项目简报启发式操作"
-    options:
-      - "用更具体的细节扩展该部分"
-      - "与类似的成功产品进行验证对比"
-      - "用边缘案例对假设进行压力测试"
-      - "探索替代的解决方案"
-      - "分析资源/约束的权衡"
-      - "生成风险缓解策略"
-      - "从 MVP 极简主义视角挑战范围"
-      - "头脑风暴创新的功能可能性"
-      - "如果我们当初拥有 [资源/能力/时间]..."
-      - "进入下一节"
-
-sections:
-  - id: introduction
-    instruction: |
-      本模板旨在指导创建一份全面的项目简报，作为产品开发的基础输入。
-
-      首先询问用户偏好哪种模式：
-
-      1. **交互模式 (Interactive Mode)** - 协同完成每个部分
-      2. **“干就完了”模式 (YOLO Mode)** - 生成完整草稿以供审查和完善
-
-      在开始之前，了解有哪些可用的输入（头脑风暴结果、市场研究、竞品分析、初步想法）并收集项目背景。
-
-  - id: executive-summary
-    title: 执行摘要
-    instruction: |
-      创建一个简洁的概述，抓住项目的精髓。包括：
-      - 用 1-2 句话说明产品概念
-      - 正在解决的主要问题
-      - 目标市场识别
-      - 核心价值主张
-    template: "{{executive_summary_content}}"
-
-  - id: problem-statement
-    title: 问题陈述
-    instruction: |
-      用清晰的证据阐明问题。说明：
-      - 现状与痛点
-      - 问题的影响（如果可能，进行量化）
-      - 为何现有解决方案不足
-      - 现在解决此问题的紧迫性和重要性
-    template: "{{detailed_problem_description}}"
-
-  - id: proposed-solution
-    title: 提议的解决方案
-    instruction: |
-      从高层次描述解决方案。包括：
-      - 核心概念与方法
-      - 与现有解决方案的关键差异化因素
-      - 为什么这个解决方案能在其他方案失败的地方取得成功
-      - 产品的高层愿景
-    template: "{{solution_description}}"
-
-  - id: target-users
-    title: 目标用户
-    instruction: |
-      具体地定义和描述目标用户。每个用户细分包括：
-      - 人口统计/公司统计画像
-      - 当前行为和工作流程
-      - 具体需求和痛点
-      - 他们试图实现的目标
-    sections:
-      - id: primary-segment
-        title: "主要用户细分: {{segment_name}}"
-        template: "{{primary_user_description}}"
-      - id: secondary-segment
-        title: "次要用户细分: {{segment_name}}"
-        condition: 存在次要用户细分时
-        template: "{{secondary_user_description}}"
-
-  - id: goals-metrics
-    title: 目标与成功指标
-    instruction: 建立明确的目标以及衡量成功的方法。使目标符合 SMART 原则（具体的、可衡量的、可实现的、相关的、有时限的）
-    sections:
-      - id: business-objectives
-        title: 业务目标
-        type: bullet-list
-        template: "- {{objective_with_metric}}"
-      - id: user-success-metrics
-        title: 用户成功指标
-        type: bullet-list
-        template: "- {{user_metric}}"
-      - id: kpis
-        title: 关键绩效指标 (KPIs)
-        type: bullet-list
-        template: "- {{kpi}}: {{definition_and_target}}"
-
-  - id: mvp-scope
-    title: MVP 范围
-    instruction: 清晰地定义最小可行产品。具体说明哪些功能在范围内，哪些在范围外。帮助用户区分“必须有”和“可以有”的功能。
-    sections:
-      - id: core-features
-        title: 核心功能 (必须有)
-        type: bullet-list
-        template: "- **{{feature}}:** {{description_and_rationale}}"
-      - id: out-of-scope
-        title: MVP 范围之外
-        type: bullet-list
-        template: "- {{feature_or_capability}}"
-      - id: mvp-success-criteria
-        title: MVP 成功标准
-        template: "{{mvp_success_definition}}"
-
-  - id: post-mvp-vision
-    title: MVP 后愿景
-    instruction: 概述产品的长期方向，但不对具体细节做出过多承诺。
-    sections:
-      - id: phase-2-features
-        title: 第二阶段功能
-        template: "{{next_priority_features}}"
-      - id: long-term-vision
-        title: 长期愿景
-        template: "{{one_two_year_vision}}"
-      - id: expansion-opportunities
-        title: 扩展机会
-        template: "{{potential_expansions}}"
-
-  - id: technical-considerations
-    title: 技术考量
-    instruction: 记录已知的技术约束和偏好。注意这些是初步想法，而非最终决定。
-    sections:
-      - id: platform-requirements
-        title: 平台要求
-        template: |
-          - **目标平台:** {{platforms}}
-          - **浏览器/操作系统支持:** {{specific_requirements}}
-          - **性能要求:** {{performance_specs}}
-      - id: technology-preferences
-        title: 技术偏好
-        template: |
-          - **前端:** {{frontend_preferences}}
-          - **后端:** {{backend_preferences}}
-          - **数据库:** {{database_preferences}}
-          - **托管/基础设施:** {{infrastructure_preferences}}
-      - id: architecture-considerations
-        title: 架构考量
-        template: |
-          - **代码仓库结构:** {{repo_thoughts}}
-          - **服务架构:** {{service_thoughts}}
-          - **集成要求:** {{integration_needs}}
-          - **安全/合规:** {{security_requirements}}
-
-  - id: constraints-assumptions
-    title: 约束与假设
-    instruction: 清晰地陈述限制和假设，以设定切合实际的期望。
-    sections:
-      - id: constraints
-        title: 约束
-        template: |
-          - **预算:** {{budget_info}}
-          - **时间线:** {{timeline_info}}
-          - **资源:** {{resource_info}}
-          - **技术:** {{technical_constraints}}
-      - id: key-assumptions
-        title: 关键假设
-        type: bullet-list
-        template: "- {{assumption}}"
-
-  - id: risks-questions
-    title: 风险与待解决问题
-    instruction: 主动识别未知因素和潜在挑战。
-    sections:
-      - id: key-risks
-        title: 关键风险
-        type: bullet-list
-        template: "- **{{risk}}:** {{description_and_impact}}"
-      - id: open-questions
-        title: 待解决问题
-        type: bullet-list
-        template: "- {{question}}"
-      - id: research-areas
-        title: 需要进一步研究的领域
-        type: bullet-list
-        template: "- {{research_topic}}"
-
-  - id: appendices
-    title: 附录
-    sections:
-      - id: research-summary
-        title: A. 研究摘要
-        condition: 存在研究发现时
-        instruction: |
-          如果适用，总结以下方面的关键发现：
-          - 市场研究
-          - 竞品分析
-          - 用户访谈
-          - 技术可行性研究
-      - id: stakeholder-input
-        title: B. 利益相关者意见
-        condition: 存在利益相关者反馈时
-        template: "{{stakeholder_feedback}}"
-      - id: references
-        title: C. 参考资料
-        template: "{{relevant_links_and_docs}}"
-
-  - id: next-steps
-    title: 后续步骤
-    sections:
-      - id: immediate-actions
-        title: 立即行动
-        type: numbered-list
-        template: "{{action_item}}"
-      - id: pm-handoff
-        title: 项目经理交接
-        content: |
-          这份项目简报为 {{project_name}} 提供了完整的背景信息。请启动‘PRD 生成模式’，彻底审阅此简报，并与用户合作，按照模板指示逐节创建 PRD，同时请求任何必要的澄清或提出改进建议。

package/xiaoma-core/templates/qa-gate-tmpl.yaml

@@ -1,102 +0,0 @@
-template:
-  id: qa-gate-template-v1
-  name: 质量门禁决策
-  version: 1.0
-  output:
-    format: yaml
-    filename: qa.qaLocation/gates/{{epic_num}}.{{story_num}}-{{story_slug}}.yml
-    title: "Quality Gate: {{epic_num}}.{{story_num}}"
-
-# 必填字段 (置于首部)
-schema: 1
-story: "{{epic_num}}.{{story_num}}"
-story_title: "{{story_title}}"
-gate: "{{gate_status}}" # 可选值: PASS|CONCERNS|FAIL|WAIVED
-status_reason: "{{status_reason}}" # 关于此门禁决策原因的1-2句话摘要
-reviewer: "Quinn (测试架构师)"
-updated: "{{iso_timestamp}}"
-
-# 始终存在，但仅在状态为 WAIVED 时激活
-waiver: { active: false }
-
-# 问题列表 (如有) - 使用固定严重性: low | medium | high
-top_issues: []
-
-# 风险摘要 (如果运行了 risk-profile 任务)
-risk_summary:
-  totals: { critical: 0, high: 0, medium: 0, low: 0 }
-  recommendations:
-    must_fix: []
-    monitor: []
-
-# 为清晰起见，使用块标量的示例部分
-examples:
-  with_issues: |
-    top_issues:
-      - id: "SEC-001"
-        severity: high  # 仅限: low|medium|high
-        finding: "登录端点上没有速率限制"
-        suggested_action: "在生产部署前添加速率限制中间件"
-      - id: "TEST-001"  
-        severity: medium
-        finding: "认证流程缺少集成测试"
-        suggested_action: "为关键路径添加测试覆盖"
-
-  when_waived: |
-    waiver:
-      active: true
-      reason: "为 MVP 版本发布而接受 - 将在下个迭代中解决"
-      approved_by: "产品负责人"
-
-# ============ 可选扩展字段 ============
-# 如果您的团队需要更详细的信息，请取消注释并使用
-
-optional_fields_examples:
-  quality_and_expiry: |
-    quality_score: 75  # 0-100 (可选评分)
-    expires: "2025-01-26T00:00:00Z"  # 可选的门禁有效时间窗口
-
-  evidence: |
-    evidence:
-      tests_reviewed: 15
-      risks_identified: 3
-      trace:
-        ac_covered: [1, 2, 3]  # 已有测试覆盖的验收标准 (AC) 编号
-        ac_gaps: [4]  # 缺少测试覆盖的验收标准 (AC) 编号
-
-  nfr_validation: |
-    nfr_validation:
-      security: { status: CONCERNS, notes: "缺少速率限制" }
-      performance: { status: PASS, notes: "" }
-      reliability: { status: PASS, notes: "" }
-      maintainability: { status: PASS, notes: "" }
-
-  history: |
-    history:  # 只可追加的审计追踪记录
-      - at: "2025-01-12T10:00:00Z"
-        gate: FAIL
-        note: "初次评审 - 缺少测试"
-      - at: "2025-01-12T15:00:00Z"  
-        gate: CONCERNS
-        note: "已添加测试，但仍缺少速率限制"
-
-  risk_summary: |
-    risk_summary:  # 来自 risk-profile 任务
-      totals:
-        critical: 0
-        high: 0
-        medium: 0
-        low: 0
-      # 'highest' 仅在存在风险时才会输出
-      recommendations:
-        must_fix: []
-        monitor: []
-
-  recommendations: |
-    recommendations:
-      immediate:  # 生产环境发布前必须修复
-        - action: "为认证端点添加速率限制"
-          refs: ["api/auth/login.ts:42-68"]
-      future:  # 可在以后解决
-        - action: "考虑使用缓存以提高性能"
-          refs: ["services/data.service.ts"]