spectra-cli 4.1.1

package/plugins/spec-driver/templates/specify-base/constitution-template.md

@@ -0,0 +1,50 @@
+# [PROJECT_NAME] Constitution
+<!-- Example: Spec Constitution, TaskFlow Constitution, etc. -->
+
+## Core Principles
+
+### [PRINCIPLE_1_NAME]
+<!-- Example: I. Library-First -->
+[PRINCIPLE_1_DESCRIPTION]
+<!-- Example: Every feature starts as a standalone library; Libraries must be self-contained, independently testable, documented; Clear purpose required - no organizational-only libraries -->
+
+### [PRINCIPLE_2_NAME]
+<!-- Example: II. CLI Interface -->
+[PRINCIPLE_2_DESCRIPTION]
+<!-- Example: Every library exposes functionality via CLI; Text in/out protocol: stdin/args → stdout, errors → stderr; Support JSON + human-readable formats -->
+
+### [PRINCIPLE_3_NAME]
+<!-- Example: III. Test-First (NON-NEGOTIABLE) -->
+[PRINCIPLE_3_DESCRIPTION]
+<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced -->
+
+### [PRINCIPLE_4_NAME]
+<!-- Example: IV. Integration Testing -->
+[PRINCIPLE_4_DESCRIPTION]
+<!-- Example: Focus areas requiring integration tests: New library contract tests, Contract changes, Inter-service communication, Shared schemas -->
+
+### [PRINCIPLE_5_NAME]
+<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Simplicity -->
+[PRINCIPLE_5_DESCRIPTION]
+<!-- Example: Text I/O ensures debuggability; Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: Start simple, YAGNI principles -->
+
+## [SECTION_2_NAME]
+<!-- Example: Additional Constraints, Security Requirements, Performance Standards, etc. -->
+
+[SECTION_2_CONTENT]
+<!-- Example: Technology stack requirements, compliance standards, deployment policies, etc. -->
+
+## [SECTION_3_NAME]
+<!-- Example: Development Workflow, Review Process, Quality Gates, etc. -->
+
+[SECTION_3_CONTENT]
+<!-- Example: Code review requirements, testing gates, deployment approval process, etc. -->
+
+## Governance
+<!-- Example: Constitution supersedes all other practices; Amendments require documentation, approval, migration plan -->
+
+[GOVERNANCE_RULES]
+<!-- Example: All PRs/reviews must verify compliance; Complexity must be justified; Use [GUIDANCE_FILE] for runtime development guidance -->
+
+**Version**: [CONSTITUTION_VERSION] | **Ratified**: [RATIFICATION_DATE] | **Last Amended**: [LAST_AMENDED_DATE]
+<!-- Example: Version: 2.1.1 | Ratified: 2025-06-13 | Last Amended: 2025-07-16 -->

package/plugins/spec-driver/templates/specify-base/plan-template.md

@@ -0,0 +1,134 @@
+# Implementation Plan: [FEATURE]
+
+**Branch**: `[###-feature-name]` | **Date**: [DATE] | **Spec**: [link]
+**Input**: Feature specification from `/specs/[###-feature-name]/spec.md`
+
+**Note**: This template is filled in by the plan phase of the spec-driver orchestrator (e.g. `/spec-driver:spec-driver-feature`). See `.specify/templates/commands/plan.md` for the execution workflow.
+
+## Summary
+
+[Extract from feature spec: primary requirement + technical approach from research]
+
+## Technical Context
+
+<!--
+  ACTION REQUIRED: Replace the content in this section with the technical details
+  for the project. The structure here is presented in advisory capacity to guide
+  the iteration process.
+-->
+
+**Language/Version**: [e.g., Python 3.11, Swift 5.9, Rust 1.75 or NEEDS CLARIFICATION]  
+**Primary Dependencies**: [e.g., FastAPI, UIKit, LLVM or NEEDS CLARIFICATION]  
+**Storage**: [if applicable, e.g., PostgreSQL, CoreData, files or N/A]  
+**Testing**: [e.g., pytest, XCTest, cargo test or NEEDS CLARIFICATION]  
+**Target Platform**: [e.g., Linux server, iOS 15+, WASM or NEEDS CLARIFICATION]
+**Project Type**: [single/web/mobile - determines source structure]  
+**Performance Goals**: [domain-specific, e.g., 1000 req/s, 10k lines/sec, 60 fps or NEEDS CLARIFICATION]  
+**Constraints**: [domain-specific, e.g., <200ms p95, <100MB memory, offline-capable or NEEDS CLARIFICATION]  
+**Scale/Scope**: [domain-specific, e.g., 10k users, 1M LOC, 50 screens or NEEDS CLARIFICATION]
+
+## Codebase Reality Check
+
+> **必选区块**：plan 子代理必须对每个将被修改的目标文件执行 Reality Check。
+
+| 文件路径 | LOC | 方法/函数数 | TODO/FIXME | 超长函数(>200L) | 需前置清理 |
+|----------|-----|------------|------------|-----------------|-----------|
+| [path]   | [N] | [N]        | [N]        | [Y/N]           | [Y/N]     |
+
+**前置清理 Task**（仅在需要时填写）：
+- [ ] `[CLEANUP]` {清理任务描述} — 原因: {触发规则}
+
+## Impact Assessment
+
+> **必选区块**：评估变更的影响半径和风险等级。
+
+| 维度 | 评估 |
+|------|------|
+| **直接修改文件数** | [N] |
+| **间接受影响文件数** | [N]（调用方/依赖方） |
+| **跨包影响** | [无 / 涉及 {包列表}] |
+| **数据迁移** | [无 / {迁移描述}] |
+| **API/契约变更** | [无 / {变更描述}] |
+| **风险等级** | [LOW / MEDIUM / HIGH] |
+
+**风险等级判定理由**: [简述判定依据]
+
+**分阶段计划**（仅 HIGH 风险时必填）：
+- Phase A: {范围} — 验证点: {验证方法}
+- Phase B: {范围} — 验证点: {验证方法}
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+[Gates determined based on constitution file]
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+specs/[###-feature]/
+├── plan.md              # This file (plan phase output)
+├── research.md          # Phase 0 output (plan phase)
+├── data-model.md        # Phase 1 output (plan phase)
+├── quickstart.md        # Phase 1 output (plan phase)
+├── contracts/           # Phase 1 output (plan phase)
+└── tasks.md             # Phase 2 output (tasks phase — NOT created by plan phase)
+```
+
+### Source Code (repository root)
+<!--
+  ACTION REQUIRED: Replace the placeholder tree below with the concrete layout
+  for this feature. Delete unused options and expand the chosen structure with
+  real paths (e.g., apps/admin, packages/something). The delivered plan must
+  not include Option labels.
+-->
+
+```text
+# [REMOVE IF UNUSED] Option 1: Single project (DEFAULT)
+src/
+├── models/
+├── services/
+├── cli/
+└── lib/
+
+tests/
+├── contract/
+├── integration/
+└── unit/
+
+# [REMOVE IF UNUSED] Option 2: Web application (when "frontend" + "backend" detected)
+backend/
+├── src/
+│   ├── models/
+│   ├── services/
+│   └── api/
+└── tests/
+
+frontend/
+├── src/
+│   ├── components/
+│   ├── pages/
+│   └── services/
+└── tests/
+
+# [REMOVE IF UNUSED] Option 3: Mobile + API (when "iOS/Android" detected)
+api/
+└── [same as backend above]
+
+ios/ or android/
+└── [platform-specific structure: feature modules, UI flows, platform tests]
+```
+
+**Structure Decision**: [Document the selected structure and reference the real
+directories captured above]
+
+## Complexity Tracking
+
+> **Fill ONLY if Constitution Check has violations that must be justified**
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
+| [e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |

package/plugins/spec-driver/templates/specify-base/product-research-template.md

@@ -0,0 +1,95 @@
+# 产品调研报告: {FEATURE_NAME}
+
+**特性分支**: `{BRANCH_NAME}`
+**调研日期**: {DATE}
+**调研模式**: {在线/离线}
+
+## 1. 需求概述
+
+**需求描述**: {用户原始需求}
+
+**核心功能点**:
+- {功能点 1}
+- {功能点 2}
+- {功能点 3}
+
+**目标用户**: {用户群体描述}
+
+## 2. 市场现状
+
+### 市场趋势
+{当前市场趋势分析}
+
+### 市场机会
+{识别的市场机会}
+
+### 用户痛点
+- {痛点 1}
+- {痛点 2}
+
+## 3. 竞品分析
+
+### 竞品对比表
+
+| 维度 | {竞品 1} | {竞品 2} | {竞品 3} | 本产品（计划） |
+|------|---------|---------|---------|--------------|
+| 核心功能 | | | | |
+| 目标用户 | | | | |
+| 定价模式 | | | | |
+| 优势 | | | | |
+| 劣势 | | | | |
+| 用户评价 | | | | |
+
+### 差异化机会
+
+1. **{机会 1}**: {描述}
+2. **{机会 2}**: {描述}
+3. **{机会 3}**: {描述}
+
+## 4. 用户场景验证
+
+### 核心用户角色
+
+**Persona 1: {角色名}**
+- 背景: {描述}
+- 目标: {描述}
+- 痛点: {描述}
+
+### 关键用户旅程
+
+1. **{旅程 1}**: {用户如何完成核心任务}
+2. **{旅程 2}**: {用户如何处理异常情况}
+
+### 需求假设验证
+
+| 假设 | 验证结果 | 证据 |
+|------|---------|------|
+| {假设 1} | ✅ 已验证 / ❌ 已否定 / ⚠️ 待确认 | {来源} |
+
+## 5. MVP 范围建议
+
+### Must-have（MVP 核心）
+- {功能 1}
+- {功能 2}
+
+### Nice-to-have（二期）
+- {功能 3}
+- {功能 4}
+
+### Future（远期）
+- {功能 5}
+
+### 优先级排序理由
+{为什么 Must-have 功能是最重要的}
+
+## 6. 结论与建议
+
+### 总结
+{产品调研的核心结论}
+
+### 对技术调研的建议
+- {技术调研应关注的方向 1}
+- {技术调研应关注的方向 2}
+
+### 风险与不确定性
+- {风险 1}: {缓解建议}

package/plugins/spec-driver/templates/specify-base/project-context-template.yaml

@@ -0,0 +1,40 @@
+# Canonical project-level context for Spec Driver.
+# Keep only stable, cross-task defaults here.
+
+product:
+  name: ""
+  summary: ""
+
+owner:
+  name: ""
+  team: ""
+  email: ""
+
+references: []
+# - label: "Architecture Notes"
+#   path: "docs/architecture.md"
+#   required: true
+#   purpose: "Shared design constraints"
+
+architecture_constraints: []
+# - "Prefer editing source files under plugins/** and src/** before touching generated wrappers."
+
+verification_policy:
+  require_real_execution: true
+  required_commands: []
+  notes: []
+
+research_policy:
+  online_required: false
+  min_points: 0
+  max_points: 5
+  preferred_tools: []
+  notes: []
+
+workflow_preferences:
+  default_mode: ""
+  preferred_preset: ""
+  notes: []
+
+forbidden_changes: []
+notes: []

package/plugins/spec-driver/templates/specify-base/research-synthesis-template.md

@@ -0,0 +1,102 @@
+# 产研汇总: {FEATURE_NAME}
+
+**特性分支**: `{BRANCH_NAME}`
+**汇总日期**: {DATE}
+**输入**: [product-research.md](product-research.md) + [tech-research.md](tech-research.md)
+**执行者**: 主编排器（非子代理）
+
+## 1. 产品×技术交叉分析矩阵
+
+| MVP 功能 | 产品优先级 | 技术可行性 | 实现复杂度 | 综合评分 | 建议 |
+|---------|-----------|-----------|-----------|---------|------|
+| {功能 1} | P1 | 高/中/低 | 高/中/低 | ⭐⭐⭐ | 纳入 MVP |
+| {功能 2} | P1 | 高/中/低 | 高/中/低 | ⭐⭐⭐ | 纳入 MVP |
+| {功能 3} | P2 | 高/中/低 | 高/中/低 | ⭐⭐ | 二期 |
+
+**评分说明**:
+- ⭐⭐⭐: 高优先 + 高可行 + 低复杂度 → 纳入 MVP
+- ⭐⭐: 中等匹配 → 视资源纳入 MVP 或推迟
+- ⭐: 低匹配 → 推迟
+
+## 2. 可行性评估
+
+### 技术可行性
+
+{总体技术可行性评估}
+
+### 资源评估
+
+- **预估工作量**: {概述}
+- **关键技能需求**: {技术栈需求}
+- **外部依赖**: {外部服务或库}
+
+### 约束与限制
+
+- {约束 1}
+- {约束 2}
+
+## 3. 风险评估
+
+### 综合风险矩阵
+
+| # | 风险 | 来源 | 概率 | 影响 | 缓解策略 | 状态 |
+|---|------|------|------|------|---------|------|
+| 1 | {风险 1} | 产品/技术 | 高/中/低 | 高/中/低 | {策略} | 待监控 |
+
+### 风险分布
+
+- **产品风险**: {N} 项（高:{n1} 中:{n2} 低:{n3}）
+- **技术风险**: {M} 项（高:{m1} 中:{m2} 低:{m3}）
+
+## 4. 最终推荐方案
+
+### 推荐架构
+
+{综合产品需求和技术评估后的推荐架构方案}
+
+### 推荐技术栈
+
+| 类别 | 选择 | 理由 |
+|------|------|------|
+| {类别 1} | {技术/库} | {产品+技术综合理由} |
+
+### 推荐实施路径
+
+1. **Phase 1 (MVP)**: {核心功能集}
+2. **Phase 2**: {扩展功能}
+3. **Phase 3**: {优化和高级功能}
+
+## 5. MVP 范围界定
+
+### 最终 MVP 范围
+
+**纳入**:
+- {功能 1}: {理由——产品价值 + 技术可行}
+- {功能 2}: {理由}
+
+**排除（明确不在 MVP）**:
+- {功能 X}: {理由——技术复杂度高 / 产品价值低}
+
+### MVP 成功标准
+
+- {可测量标准 1}
+- {可测量标准 2}
+
+## 6. 结论
+
+### 综合判断
+
+{一段话概述产品方向+技术方案的最终推荐}
+
+### 置信度
+
+| 维度 | 置信度 | 说明 |
+|------|--------|------|
+| 产品方向 | 高/中/低 | {理由} |
+| 技术方案 | 高/中/低 | {理由} |
+| MVP 范围 | 高/中/低 | {理由} |
+
+### 后续行动建议
+
+- 确认推荐方案后，进入需求规范阶段（specify）
+- {其他建议}

package/plugins/spec-driver/templates/specify-base/spec-template.md

@@ -0,0 +1,115 @@
+# Feature Specification: [FEATURE NAME]
+
+**Feature Branch**: `[###-feature-name]`  
+**Created**: [DATE]  
+**Status**: Draft  
+**Input**: User description: "$ARGUMENTS"
+
+## User Scenarios & Testing *(mandatory)*
+
+<!--
+  IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
+  Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
+  you should still have a viable MVP (Minimum Viable Product) that delivers value.
+  
+  Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
+  Think of each story as a standalone slice of functionality that can be:
+  - Developed independently
+  - Tested independently
+  - Deployed independently
+  - Demonstrated to users independently
+-->
+
+### User Story 1 - [Brief Title] (Priority: P1)
+
+[Describe this user journey in plain language]
+
+**Why this priority**: [Explain the value and why it has this priority level]
+
+**Independent Test**: [Describe how this can be tested independently - e.g., "Can be fully tested by [specific action] and delivers [specific value]"]
+
+**Acceptance Scenarios**:
+
+1. **Given** [initial state], **When** [action], **Then** [expected outcome]
+2. **Given** [initial state], **When** [action], **Then** [expected outcome]
+
+---
+
+### User Story 2 - [Brief Title] (Priority: P2)
+
+[Describe this user journey in plain language]
+
+**Why this priority**: [Explain the value and why it has this priority level]
+
+**Independent Test**: [Describe how this can be tested independently]
+
+**Acceptance Scenarios**:
+
+1. **Given** [initial state], **When** [action], **Then** [expected outcome]
+
+---
+
+### User Story 3 - [Brief Title] (Priority: P3)
+
+[Describe this user journey in plain language]
+
+**Why this priority**: [Explain the value and why it has this priority level]
+
+**Independent Test**: [Describe how this can be tested independently]
+
+**Acceptance Scenarios**:
+
+1. **Given** [initial state], **When** [action], **Then** [expected outcome]
+
+---
+
+[Add more user stories as needed, each with an assigned priority]
+
+### Edge Cases
+
+<!--
+  ACTION REQUIRED: The content in this section represents placeholders.
+  Fill them out with the right edge cases.
+-->
+
+- What happens when [boundary condition]?
+- How does system handle [error scenario]?
+
+## Requirements *(mandatory)*
+
+<!--
+  ACTION REQUIRED: The content in this section represents placeholders.
+  Fill them out with the right functional requirements.
+-->
+
+### Functional Requirements
+
+- **FR-001**: System MUST [specific capability, e.g., "allow users to create accounts"]
+- **FR-002**: System MUST [specific capability, e.g., "validate email addresses"]  
+- **FR-003**: Users MUST be able to [key interaction, e.g., "reset their password"]
+- **FR-004**: System MUST [data requirement, e.g., "persist user preferences"]
+- **FR-005**: System MUST [behavior, e.g., "log all security events"]
+
+*Example of marking unclear requirements:*
+
+- **FR-006**: System MUST authenticate users via [NEEDS CLARIFICATION: auth method not specified - email/password, SSO, OAuth?]
+- **FR-007**: System MUST retain user data for [NEEDS CLARIFICATION: retention period not specified]
+
+### Key Entities *(include if feature involves data)*
+
+- **[Entity 1]**: [What it represents, key attributes without implementation]
+- **[Entity 2]**: [What it represents, relationships to other entities]
+
+## Success Criteria *(mandatory)*
+
+<!--
+  ACTION REQUIRED: Define measurable success criteria.
+  These must be technology-agnostic and measurable.
+-->
+
+### Measurable Outcomes
+
+- **SC-001**: [Measurable metric, e.g., "Users can complete account creation in under 2 minutes"]
+- **SC-002**: [Measurable metric, e.g., "System handles 1000 concurrent users without degradation"]
+- **SC-003**: [User satisfaction metric, e.g., "90% of users successfully complete primary task on first attempt"]
+- **SC-004**: [Business metric, e.g., "Reduce support tickets related to [X] by 50%"]