calc-mcp-server 0.1.0

package/.claude/skills/openspec-sync-specs/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: openspec-sync-specs
+description: 将变更中的增量规范同步到主规范。当用户想要用增量规范中的更改更新主规范，而不归档变更时使用。
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+将变更中的增量规范同步到主规范。
+
+这是一个 **Agent 驱动** 的操作 - 你将阅读增量规范并直接编辑主规范以应用更改。这允许智能合并（例如，添加一个场景而不复制整个需求）。
+
+**输入**：可选择指定变更名称。如果省略，检查是否可以从对话上下文中推断。如果模糊或不明确，必须提示可用的变更。
+
+**步骤**
+
+1. **如果没有提供变更名称，提示选择**
+
+   运行 `openspec list --json` 获取可用变更。使用 **AskUserQuestion 工具** 让用户选择。
+
+   显示具有增量规范（在 `specs/` 目录下）的变更。
+
+   **重要**：不要猜测或自动选择变更。始终让用户选择。
+
+2. **查找增量规范**
+
+   在 `openspec/changes/<name>/specs/*/spec.md` 中查找增量规范文件。
+
+   每个增量规范文件包含如下部分：
+   - `## ADDED Requirements` - 要添加的新需求
+   - `## MODIFIED Requirements` - 对现有需求的更改
+   - `## REMOVED Requirements` - 要删除的需求
+   - `## RENAMED Requirements` - 要重命名的需求（FROM:/TO: 格式）
+
+   如果未找到增量规范，通知用户并停止。
+
+3. **对于每个增量规范，将更改应用到主规范**
+
+   对于在 `openspec/changes/<name>/specs/<capability>/spec.md` 具有增量规范的每个 capability：
+
+   a. **阅读增量规范** 以了解预期的更改
+
+   b. **阅读主规范** `openspec/specs/<capability>/spec.md`（可能还不存在）
+
+   c. **智能应用更改**：
+
+      **ADDED Requirements:**
+      - 如果主规范中不存在需求 → 添加它
+      - 如果需求已存在 → 更新它以匹配（视为隐式 MODIFIED）
+
+      **MODIFIED Requirements:**
+      - 在主规范中找到需求
+      - 应用更改 - 这可能是：
+        - 添加新场景（不需要复制现有的）
+        - 修改现有场景
+        - 更改需求描述
+      - 保留未在增量中提及的场景/内容
+
+      **REMOVED Requirements:**
+      - 从主规范中删除整个需求块
+
+      **RENAMED Requirements:**
+      - 找到 FROM 需求，重命名为 TO
+
+   d. **创建新主规范** 如果 capability 尚不存在：
+      - 创建 `openspec/specs/<capability>/spec.md`
+      - 添加 Purpose 部分（可以简短，标记为 TBD）
+      - 添加 Requirements 部分包含 ADDED requirements
+
+4. **显示总结**
+
+   应用所有更改后，总结：
+   - 更新了哪些 capabilities
+   - 做了什么更改（需求添加/修改/删除/重命名）
+
+**增量规范格式参考**
+
+```markdown
+## ADDED Requirements
+
+### Requirement: New Feature
+The system SHALL do something new.
+
+#### Scenario: Basic case
+- **WHEN** user does X
+- **THEN** system does Y
+
+## MODIFIED Requirements
+
+### Requirement: Existing Feature
+#### Scenario: New scenario to add
+- **WHEN** user does A
+- **THEN** system does B
+
+## REMOVED Requirements
+
+### Requirement: Deprecated Feature
+
+## RENAMED Requirements
+
+- FROM: `### Requirement: Old Name`
+- TO: `### Requirement: New Name`
+```
+
+**关键原则：智能合并**
+
+与程序化合并不同，你可以应用 **部分更新**：
+- 要添加场景，只需在 MODIFIED 下包含该场景 - 不要复制现有场景
+- 增量代表 *意图*，而不是全盘替换
+- 使用你的判断力合理合并更改
+
+**成功时的输出**
+
+```
+## 规范已同步：<change-name>
+
+已更新主规范：
+
+**<capability-1>**：
+- 添加需求："New Feature"
+- 修改需求："Existing Feature"（添加了 1 个场景）
+
+**<capability-2>**：
+- 创建了新规范文件
+- 添加需求："Another Feature"
+
+主规范现已更新。变更保持活跃 - 在实施完成后归档。
+```
+
+**护栏**
+- 在进行更改之前阅读增量规范和主规范
+- 保留未在增量中提及的现有内容
+- 如果某事不清楚，寻求澄清
+- 在进行时显示你正在更改的内容
+- 操作应是幂等的 - 运行两次应得到相同的结果

package/.claude/skills/openspec-verify-change/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: openspec-verify-change
+description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.1.1"
+---
+
+Verify that an implementation matches the change artifacts (specs, tasks, design).
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have implementation tasks (tasks artifact exists).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifacts exist for this change
+
+3. **Get the change directory and load artifacts**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
+
+4. **Initialize verification report structure**
+
+   Create a report structure with three dimensions:
+   - **Completeness**: Track tasks and spec coverage
+   - **Correctness**: Track requirement implementation and scenario coverage
+   - **Coherence**: Track design adherence and pattern consistency
+
+   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
+
+5. **Verify Completeness**
+
+   **Task Completion**:
+   - If tasks.md exists in contextFiles, read it
+   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
+   - Count complete vs total tasks
+   - If incomplete tasks exist:
+     - Add CRITICAL issue for each incomplete task
+     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
+
+   **Spec Coverage**:
+   - If delta specs exist in `openspec/changes/<name>/specs/`:
+     - Extract all requirements (marked with "### Requirement:")
+     - For each requirement:
+       - Search codebase for keywords related to the requirement
+       - Assess if implementation likely exists
+     - If requirements appear unimplemented:
+       - Add CRITICAL issue: "Requirement not found: <requirement name>"
+       - Recommendation: "Implement requirement X: <description>"
+
+6. **Verify Correctness**
+
+   **Requirement Implementation Mapping**:
+   - For each requirement from delta specs:
+     - Search codebase for implementation evidence
+     - If found, note file paths and line ranges
+     - Assess if implementation matches requirement intent
+     - If divergence detected:
+       - Add WARNING: "Implementation may diverge from spec: <details>"
+       - Recommendation: "Review <file>:<lines> against requirement X"
+
+   **Scenario Coverage**:
+   - For each scenario in delta specs (marked with "#### Scenario:"):
+     - Check if conditions are handled in code
+     - Check if tests exist covering the scenario
+     - If scenario appears uncovered:
+       - Add WARNING: "Scenario not covered: <scenario name>"
+       - Recommendation: "Add test or implementation for scenario: <description>"
+
+7. **Verify Coherence**
+
+   **Design Adherence**:
+   - If design.md exists in contextFiles:
+     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
+     - Verify implementation follows those decisions
+     - If contradiction detected:
+       - Add WARNING: "Design decision not followed: <decision>"
+       - Recommendation: "Update implementation or revise design.md to match reality"
+   - If no design.md: Skip design adherence check, note "No design.md to verify against"
+
+   **Code Pattern Consistency**:
+   - Review new code for consistency with project patterns
+   - Check file naming, directory structure, coding style
+   - If significant deviations found:
+     - Add SUGGESTION: "Code pattern deviation: <details>"
+     - Recommendation: "Consider following project pattern: <example>"
+
+8. **Generate Verification Report**
+
+   **Summary Scorecard**:
+   ```
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   ```
+
+   **Issues by Priority**:
+
+   1. **CRITICAL** (Must fix before archive):
+      - Incomplete tasks
+      - Missing requirement implementations
+      - Each with specific, actionable recommendation
+
+   2. **WARNING** (Should fix):
+      - Spec/design divergences
+      - Missing scenario coverage
+      - Each with specific recommendation
+
+   3. **SUGGESTION** (Nice to fix):
+      - Pattern inconsistencies
+      - Minor improvements
+      - Each with specific recommendation
+
+   **Final Assessment**:
+   - If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
+   - If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
+   - If all clear: "All checks passed. Ready for archive."
+
+**Verification Heuristics**
+
+- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
+- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
+- **Coherence**: Look for glaring inconsistencies, don't nitpick style
+- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
+- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
+
+**Graceful Degradation**
+
+- If only tasks.md exists: verify task completion only, skip spec/design checks
+- If tasks + specs exist: verify completeness and correctness, skip design
+- If full artifacts: verify all three dimensions
+- Always note which checks were skipped and why
+
+**Output Format**
+
+Use clear markdown with:
+- Table for summary scorecard
+- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
+- Code references in format: `file.ts:123`
+- Specific, actionable recommendations
+- No vague suggestions like "consider reviewing"

package/CLAUDE.md

@@ -0,0 +1,92 @@
+# CLAUDE.md
+
+本文件为 Claude Code (claude.ai/code) 在此仓库中工作时提供指导。
+
+## 项目概述
+
+这是一个使用 TypeScript 实现的 MCP (Model Context Protocol) Server 计算器项目。
+
+## 常用命令
+
+### 构建与开发
+```bash
+npm run build          # 构建项目到 dist/
+npm run dev            # 开发模式（监听文件变化）
+npm run typecheck      # TypeScript 类型检查
+npm run lint           # ESLint 代码检查
+```
+
+### 测试
+```bash
+npm run test            # 运行所有测试
+npm run test:ui         # 运行测试（带 UI）
+npm run test:coverage   # 运行测试并生成覆盖率报告
+
+# 运行单个测试文件
+npm test -- <test-file-path>
+```
+
+### MCP Server
+```bash
+# 构建后可运行
+node dist/index.js
+```
+
+## 架构概览
+
+项目采用经典的编译器架构，分为以下层次：
+
+```
+src/
+├── index.ts              # MCP Server 入口（stdio 传输）
+├── mcp/
+│   ├── server.ts         # MCP Server 实现，注册所有工具
+│   └── tools/            # MCP 工具封装层
+│       ├── basic.ts      # basic_calculate 工具
+│       ├── programmer.ts # programmer_calculate 工具
+│       ├── conversion.ts # convert_base 工具
+│       └── ascii.ts      # ASCII 转换工具
+├── engines/
+│   ├── decimal.ts        # 高精度十进制计算引擎（使用 Decimal.js）
+│   └── programmer.ts     # 程序员整数计算引擎（使用 BigInt）
+├── parser/
+│   ├── lexer.ts          # 词法分析器（Token 化）
+│   ├── parser.ts         # 语法分析器（AST 构建）
+│   └── ast.ts            # 抽象语法树类型定义
+└── errors/
+    ├── types.ts          # 错误类型和响应类型
+    └── handler.ts        # 错误处理器
+```
+
+### 核心设计
+
+1. **双层计算引擎**：
+   - `DecimalEngine`：使用 Decimal.js 处理高精度十进制运算，解决浮点数精度问题（如 0.1 + 0.2）
+   - `ProgrammerEngine`：使用 BigInt 处理整数运算和位运算（&、|、^、~、<<、>>、>>>）
+
+2. **统一响应格式**（`src/errors/types.ts`）：
+   ```typescript
+   // 成功响应
+   { success: true, result: string, details?: { expression?, steps?[] } }
+   // 错误响应
+   { success: false, error: { type, message, position?, suggestion } }
+   ```
+
+3. **AST 节点类型**（`src/parser/ast.ts`）：
+   - `BinaryOp`：二元运算（+、-、*、/、%、&、|、^、<<、>>、>>>）
+   - `UnaryOp`：一元运算（-、+、~）
+   - `Literal`：字面量（支持十进制、十六进制 0x、二进制 0b、八进制 0o、字符字面量 'A'）
+   - `Group`：括号分组
+
+4. **MCP 工具注册**：在 `src/mcp/server.ts` 中注册新工具，添加到 `TOOLS` 数组和 `CallToolRequestSchema` 处理器的 switch 语句中。
+
+## 必须遵守
+
+不管是**提问**还是生成 Markdown **文档**，都必须使用中文。
+
+包括但不限于以下文档生成：
+- 在使用 OpenSpec 规范驱动开发过程中生成的文档（proposal.md、design.md、tasks.md 和 spec.md）
+- 在使用 superpower 规范驱动开发过程中生成的文档（设计文档、实施文档）
+- README.md 说明文档
+- 使用指南文档
+- 任何需要生成文档的地方