@haaaiawd/anws 1.0.0

package/templates/.agent/rules/agents.md

@@ -0,0 +1,90 @@
+# AGENTS.md - AI 协作协议
+
+> **"如果你正在阅读此文档，你就是那个智能体 (The Intelligence)。"**
+> 
+> 这个文件是你的**锚点 (Anchor)**。它定义了项目的法则、领地的地图，以及记忆协议。
+> 当你唤醒（开始新会话）时，**请首先阅读此文件**。
+
+---
+
+## 🧠 30秒恢复协议 (Quick Recovery)
+
+**当你开始新会话或感到"迷失"时，立即执行**:
+
+1. **读取 .agent/rules/agents.md** → 获取项目地图
+2. **查看下方"当前状态"** → 找到最新架构版本
+3. **读取 `genesis/v{N}/05_TASKS.md`** → 了解当前待办
+4. **开始工作**
+
+---
+
+## 🗺️ 地图 (领地感知)
+
+以下是这个项目的组织方式：
+
+| 路径 | 描述 | 访问协议 |
+|------|------|----------|
+| `src/` | **实现层**。实际的代码库。 | 通过 Task 读/写。 |
+| `genesis/` | **设计演进史**。版本化架构状态 (v1, v2...)。 | **只读**(旧版) / **写一次**(新版)。 |
+| `genesis/v{N}/` | **当前真理**。最新的架构定义。 | 永远寻找最大的 `v{N}`。 |
+| `.agent/workflows/` | **工作流**。`/genesis`, `/blueprint` 等。 | 通过 `view_file` 阅读。 |
+| `.agent/skills/` | **技能库**。原子能力。 | 通过 `view_file` 调用。 |
+
+---
+
+## 📍 当前状态 (由 Workflow 自动更新)
+
+> **注意**: 此部分由 `/genesis` 和 `/blueprint` 自动维护。
+
+- **最新架构版本**: `尚未初始化`
+- **活动任务清单**: `尚未生成`
+- **待办任务数**: -
+- **最近一次更新**: `-`
+
+---
+
+## 🌳 项目结构 (Project Tree)
+
+> **注意**: 此部分由 `/genesis` 维护。
+
+```text
+(等待 Genesis 初始化结构树...)
+```
+
+---
+
+## 🧭 导航指南 (Navigation Guide)
+
+> **注意**: 此部分由 `/genesis` 维护。
+
+- **在新架构就绪前**: 请勿大规模修改代码。
+- **遇到架构问题**: 请查阅 `genesis/v{N}/03_ADR/`。
+
+---
+
+## 🛠️ 工作流注册表
+
+| 工作流 | 触发时机 | 产出 |
+|--------|---------|------|
+| `/genesis` | 新项目 / 重大重构 | PRD, Architecture, ADRs |
+| `/scout` | 变更前 / 接手项目 | `genesis/v{N}/00_SCOUT_REPORT.md` |
+| `/design-system` | genesis 后 | 04_SYSTEM_DESIGN/*.md |
+| `/blueprint` | genesis 后 | 05_TASKS.md |
+| `/forge` | blueprint 后 | 实际代码实现 |
+| `/change` | 微调已有任务 | 更新 TASKS + SYSTEM_DESIGN (仅修改) + CHANGELOG |
+| `/explore` | 调研时 | 探索报告 |
+| `/challenge` | 决策前质疑 | 07_CHALLENGE_REPORT.md |
+| `/craft` | 创建工作流/技能/提示词 | Workflow / Skill / Prompt 文档 |
+
+---
+
+## 📜 宪法 (The Constitution)
+
+1. **版本即法律**: 不"修补"架构文档，只"演进"。变更必须创建新版本。
+2. **显式上下文**: 决策写入 ADR，不留在"聊天记忆"里。
+3. **交叉验证**: 编码前对照 `05_TASKS.md`。我在做计划好的事吗？
+4. **美学**: 文档应该是美的。善用 Markdown 和 Emoji。
+
+---
+
+> **状态自检**: 准备好了？运行 `/genesis` 开始你的第一个项目设计吧。

package/templates/.agent/skills/build-inspector/SKILL.md

@@ -0,0 +1,83 @@
+---
+name: build-inspector
+description: 分析构建系统拓扑，识别独立构建单元、多产物风险和版本漂移隐患。
+---
+
+# 测绘员手册 (The Surveyor's Field Guide)
+
+> "地图不是领土。你看到的 `Cargo.toml` 可能只是冰山一角。" —— 老测绘员箴言
+
+静态分析看的是**代码结构**，而本技能看的是**工程脚手架**——那些决定了"软件如何从源代码变成可执行物"的规则。
+
+---
+
+## ⚠️ 强制深度思考
+
+> [!IMPORTANT]
+> 在执行任何分析之前，你**必须**调用 `sequential thinking` 工具视情况进行 **2—3 步**推理。
+> 思考内容例如：
+> 1.  "这个项目使用什么构建系统？（Cargo? npm? Make?）"
+> 2.  "我看到多个构建配置文件了吗？它们是独立的还是统一管理的？"
+> 3.  "最终产物（exe, dll, bundle）是一起发布的吗？还是可以独立更新？"
+
+---
+
+## ⚡ 任务目标
+识别**构建边界 (Build Boundaries)**。
+
+**老师傅核心定律**: 如果两个东西是分开构建的，它们之间的任何"接口"都是一颗定时炸弹——因为可能发生**版本漂移 (Version Skew)**。
+
+---
+
+## 🧭 探索流程 (The Expedition)
+
+### 第一步：定位营地 (Locate Base Camps)
+*   **命令**: `find_by_name(pattern="Cargo.toml|package.json|go.mod|pom.xml|build.gradle|requirements.txt|CMakeLists.txt")`
+*   **测绘员直觉**: 每个构建配置 = 一个"营地"。多个营地 = 潜在的分裂势力。
+
+### 第二步：判断统一指挥 (Check for Unified Command)
+如果找到多个营地，你**必须**回答：
+
+| 生态 | 检查项 | 老师傅判定 |
+| :--- | :--- | :--- |
+| Rust | 根 `Cargo.toml` 有 `[workspace]` 吗？成员都列在里面吗？ | 没有 -> 🔴 独立王国 |
+| Node | 根 `package.json` 有 `workspaces` 字段吗？或使用 Lerna/Nx/Turborepo？ | 没有 -> 🔴 独立王国 |
+| Go | 是否使用 `go.work` 统筹？ | 没有 -> 🟡 需进一步确认 |
+
+*   **老师傅警报 (来自业界案例)**:
+    *   ⚠️ **独立王国 (Polyrepo Hell)**: 它们可以各自升级版本，不保证兼容！极易产生"依赖地狱 (Dependency Chaos)"。
+    *   ⚠️ **伪 Monorepo (Distributed Monolith)**: 虽然在同一个仓库，但构建是独立的，实际上和 Polyrepo 风险一样！
+    *   ⚠️ **Sidecar/外挂二进制**: 它和主程序一起打包部署吗？CI 流水线是同一个吗？**如果 Sidecar 可以独立更新，必须有版本握手！**
+
+### 第三步：追踪产物 (Identify Artifacts)
+*   读取构建配置，推断最终二进制/库：
+    *   `[[bin]]` in `Cargo.toml` -> 可执行文件。
+    *   `"bin"` in `package.json` -> CLI 工具。
+    *   `cmd/` 目录在 Go 项目 -> 多个命令行工具。
+    *   `tauri.conf.json` -> Tauri 桌面应用 (检查 `externalBin` 是否有 Sidecar)。
+*   **老师傅必问**:
+    *   "这些产物最终运行在同一台机器上吗？"
+    *   "它们由**同一个 CI 流水线**、**同一个版本号**打出来吗？"
+    *   "用户能否只更新其中一个产物？"
+
+---
+
+## 🛡️ 风险标签体系 (来自业界研究)
+
+| 模式 | 等级 | 老师傅建议 |
+| :--- | :---: | :--- |
+| **单一 Workspace** | 🟢 | 版本一致性有保障。 |
+| **多 Root + 共享 Workspace** | 🟢 | 注意是否所有成员都在 workspace 内。 |
+| **多 Root + 无 Workspace (Polyrepo)** | 🔴 | **Split-Brain**。极易版本漂移。不同仓库的依赖版本可能冲突。 |
+| **Sidecar + 原子发布** | 🟢 | Sidecar 和主程序一起更新，风险可控。 |
+| **Sidecar + 非原子发布** | 🔴 | **高危**！必须在 IPC 层实现版本握手。 |
+
+---
+
+## 📤 输出清单
+
+1.  **Build Roots**: 发现的构建配置路径列表。
+2.  **Topology**: `[Monolith / Workspace / Polyrepo / Distributed-Local]`
+3.  **Artifacts**: 识别出的最终产物列表（名称、类型、来源）。
+4.  **Sidecar Warning**: 如果存在 Sidecar，明确其发布策略（原子/非原子）。
+5.  **Risks Flagged**: 标记的风险及其依据。**尤其要标注"哪两个产物可能版本不同步"**。

package/templates/.agent/skills/complexity-guard/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: complexity-guard
+description: The final gatekeeper. Audits RFCs to reject over-engineering, unnecessary dependencies, and resume-driven development.
+---
+
+# The Gatekeeper's Guide (守门员手册)
+
+> "Perfection is achieved when there is nothing left to take away."
+
+You are the **No** man. You fight entropy.
+
+## ⚡ Quick Start
+
+本技能支持三种审计模式，根据调用场景选择对应的输入文件：
+
+| 模式 | 输入文件 | 调用场景 |
+|------|---------|---------|
+| **架构审计** | `genesis/v{N}/02_ARCHITECTURE_OVERVIEW.md` | genesis Step 6 / 独立调用 |
+| **任务审计** | `genesis/v{N}/05_TASKS.md` | blueprint Step 4 |
+| **设计审计** | `genesis/v{N}/04_SYSTEM_DESIGN/{system}.md` | design-system Step 6 |
+
+1.  **Read Target (MANDATORY)**: 根据调用场景读取对应的文件。如果不确定，读取 `genesis/v{N}/02_ARCHITECTURE_OVERVIEW.md`。
+2.  **Load Blacklist**: `view_file references/anti_patterns.md` to check forbidden patterns.
+3.  **Deep Audit (CRITICAL)**: You MUST call `sequential thinking` with 3-7 reasoning steps (depending on complexity) to:
+    *   Check for over-engineering (unnecessary abstractions)
+    *   Identify YAGNI violations (speculative features)
+    *   Count new dependencies (each is a red flag)
+    *   Verify simplicity (Occam's Razor)
+4.  **Score & Verdict**: Rate complexity 1-10. >7 = REJECT. Use `write_to_file` to save `genesis/v{N}/AUDIT_REPORT.md`.
+
+## 🛑 Mandatory Audit Checklist
+You MUST verify:
+1. Is every new dependency justified? (Default: NO)
+2. Can this be built with existing code? (Prefer YES)
+3. Is the solution the simplest possible? (Apply Occam's Razor)
+4. Are there any "resume-driven" tech choices? (GraphQL for 3 endpoints?)
+5. Use `write_to_file` to save audit report. DO NOT just print verdict.
+
+## ✅ Completion Checklist
+- [ ] Audit file created: `genesis/v{N}/AUDIT_REPORT.md`
+- [ ] Complexity score assigned (1-10)
+- [ ] Clear APPROVE or REJECT verdict with reasoning
+- [ ] Alternative simpler solutions suggested (if REJECT)
+- [ ] User confirmed the verdict
+
+## 🛠️ The Techniques
+
+### 1. Occam's Razor (剃刀)
+*   **Scenario**: "I added GraphQL because it's flexible."
+*   **Verdict**: "REJECT. We have 3 endpoints. Use REST."
+*   **Rule**: Simplest solution that works wins.
+
+### 2. YAGNI (拒绝预测)
+*   **Scenario**: "I made it generic for future cases."
+*   **Gatekeeper**: 只有你点了 `APPROVED`，流程才能进入 Implementation 阶段。你是最后一道防线。
+*   **Verdict**: "REJECT. Implement it for the *current* case only."
+*   **Rule**: Solve today's problem.
+
+## 🧰 The Toolkit
+*   `references/anti_patterns.md`: The "Blacklist" of bad designs.
+
+### 3. The Dependency Diet (依赖节食)
+*   **Scenario**: "Added `lodash` for `isNil`."
+*   **Verdict**: "REJECT. Use `=== null || === undefined`."
+*   **Rule**: Every dependency is liability.
+
+## ⚠️ Gatekeeper's Code
+
+1.  **Be Ruthless**: Politeness causes technical debt. Kill complexity now.
+2.  **Suggest Alternatives**: Don't just block. Say "Use X instead of Y".
+3.  **Protect the Team**: Boring tech stacks let developers sleep at night.

package/templates/.agent/skills/complexity-guard/references/anti_patterns.md

@@ -0,0 +1,21 @@
+# Architectural Anti-Patterns (The "Rejection List")
+
+## 1. Premature Optimization
+*   **Criteria**: Introducing caching (Redis/Memcached) before seeing a slow query log.
+*   **Solution**: "Make it work, then make it fast."
+
+## 2. Generic Hell
+*   **Criteria**: Creating a `BaseService<T, U, V>` when you only have one service.
+*   **Solution**: Write concrete code. Abstraction follows duplication (Rule of Three).
+
+## 3. Tool Fetishism / Resume Driven Development
+*   **Criteria**: Adding a new dependency (e.g., Redux, GraphQL) just because it's popular, when `useState` or REST is sufficient.
+*   **Solution**: Use the "Boring Stack".
+
+## 4. Microservices Envy
+*   **Criteria**: Splitting a simple app into 3 services to "decouple" them.
+*   **Solution**: Monolith First.
+
+## 5. Zombie Code
+*   **Criteria**: Commented out code "just in case".
+*   **Solution**: Delete it. Git has history.

package/templates/.agent/skills/concept-modeler/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: concept-modeler
+description: 从模糊的用户需求中提取领域概念——实体、流程和"暗物质"（用户没说的）。基于 DDD（领域驱动设计）方法论。
+---
+
+# 建模师手册 (The Modeler's Field Guide)
+
+> "如果你描述不清楚，你就造不出来。" —— Eric Evans
+
+本技能将用户的"感觉词"转化为**实体 (Entities)**、**数据流 (Flows)** 和**暗物质 (Missing Components)**。
+
+---
+
+## ⚠️ 强制深度思考
+
+> [!IMPORTANT]
+> 在执行任何分析之前，你**必须**调用 `sequential thinking` 工具，视情况进行 **3—5 步**推理。
+> 思考内容例如：
+> 1.  "用户说的'同步'是单向还是双向？实时还是批量？"
+> 2.  "这个'列表'在代码里对应什么？`Wishlist` 还是 `ShoppingCart`？"
+> 3.  "用户只描述了 Happy Path——如果 X 失败了怎么办？"
+> 4.  "这个功能需要新的数据库表吗？需要新的 API 端点吗？"
+> 5.  "有没有隐藏的安全/性能/可靠性问题用户没提？"
+
+---
+
+## ⚡ 任务目标
+
+从用户的自然语言需求中提取：
+1.  **实体 (Entities)** - 系统中的"名词"
+2.  **数据流 (Flows)** - "名词"之间的"动词"
+3.  **暗物质 (Missing)** - 用户没说但必须存在的组件
+
+---
+
+## 🧭 探索流程 (The Extraction)
+
+### 第一步：名词捕捉 (Noun Hunting)
+*   **输入**: "我想让用户能够*同步*他们的*列表*。"
+*   **建模师追问**: "列表"是什么？`Wishlist`？`ShoppingCart`？`TodoList`？
+*   **老师傅箴言**: 永远不要假设你理解了用户的词汇。**Ubiquitous Language 是 DDD 的核心**。
+*   **输出**: 定义清晰的 **Entity** 列表。
+
+### 第二步：动词分析 (Verb Analysis)
+*   **输入**: "同步。"
+*   **建模师追问**:
+    *   是**单向**还是**双向**？
+    *   是**实时**还是**批量**？
+    *   **失败策略**是什么？重试？回滚？告警？
+*   **老师傅箴言**: 动词决定了系统的复杂度。一个"同步"可能藏着 10 个边界情况。
+*   **输出**: 定义 **Data Flow** 和 **Consistency Model**。
+
+### 第三步：暗物质探测 (Dark Matter Detection)
+*   **老师傅核心定律**: 用户只描述 Happy Path。**你的工作是找到他们没说的一切**。
+*   **检查清单**:
+    | 类别 | 追问 |
+    | :--- | :--- |
+    | **错误处理** | 如果 X 失败了怎么办？ |
+    | **持久化** | 数据存哪里？需要备份吗？ |
+    | **认证授权** | 谁能访问？如何验证身份？ |
+    | **日志监控** | 如何知道系统状态？如何调试？ |
+    | **配置管理** | 硬编码还是外部配置？ |
+    | **限流熔断** | 高并发时如何保护系统？ |
+*   **输出**: 标记 **Missing Components** 及其优先级。
+
+---
+
+## 🛡️ 老师傅守则
+
+1.  **不要编造**: 如果信息不足，把问题列出来让用户澄清。
+2.  **保守估计**: 宁可多识别缺失组件，也不要遗漏。
+3.  **解释推理**: 对每个判断提供理由。
+4.  **关联构建信息**: 将识别出的 Entities 与 `build-inspector` 发现的构建根关联起来。
+
+---
+
+## 📤 输出格式
+
+你**必须**使用 `write_to_file` 保存到 `genesis/v{N}/concept_model.json`，格式如下：
+
+```json
+{
+  "entities": [
+    { "name": "Wishlist", "type": "数据", "necessity": "必须", "description": "用户的愿望清单" }
+  ],
+  "flows": [
+    { "from": "User", "action": "添加", "to": "Wishlist", "data": "Product ID" }
+  ],
+  "missing_components": [
+    { "component": "错误重试", "category": "错误处理", "priority": "高", "reason": "API 可能超时" }
+  ],
+  "questions_for_user": [
+    "同步是实时的还是批量的？"
+  ]
+}
+```
+
+---
+
+## 🧰 工具箱
+
+*   `scripts/glossary_gen.py --path src/`: 从代码中提取候选领域词汇。
+*   `prompts/GLOSSARY_PROMPT.md`: 领域词汇对齐提示词。
+*   `references/ENTITY_EXTRACTION_PROMPT.md`: 完整的实体提取提示词模板（含 Few-Shot 示例）。
+
+---
+
+## Collaboration
+
+*   **Before**: `build-inspector` 和 `runtime-inspector` 揭示了*系统是什么*。
+*   **After**: `spec-writer` 定义*系统将变成什么*。
+*   **Synergy**: 你的领域模型将帮助 Scout 的功能冲突分析更精准。

package/templates/.agent/skills/concept-modeler/prompts/GLOSSARY_PROMPT.md

@@ -0,0 +1,40 @@
+# Ubiquitous Language Extraction Prompt
+
+## Role
+You are a **Domain Linguist** and **DDD Practitioner**. Your job is to facilitate communication between developers and domain experts by extracting a **Ubiquitous Language** dictionary.
+
+## Goal
+Analyze the provided code and documentation to extract the core vocabulary of the domain. We want to identify the "Nouns" (Entities/Value Objects) and "Verbs" (Domain Events/Actions) that constitute the language of this project.
+
+## Input Context
+- **Code Identifiers**: Class names, Struct names, Public Function names.
+- **Documentation text**: User stories, comments.
+
+## Output Format
+Generate a Markdown Glossary table.
+
+### Format Template
+```markdown
+# Domain Glossary (Ubiquitous Language)
+
+## Entities (Nouns)
+| Term | Definition | Code Mappings |
+|---|---|---|
+| User | A registered person who uses the system. | `src/models/User.rs`, `database.users` |
+| Prompt | A text template used for AI generation. | `src/models/Prompt.ts` |
+
+## Actions (Verbs)
+| Term | Definition | Code Mappings |
+|---|---|---|
+| Generate | The process of creating content using AI. | `service/Generator.run()` |
+| Inject | Inserting the generated text into an active window. | `service/Injector.inject()` |
+
+## Inconsistencies Detected
+> [!WARNING]
+> - **Client vs User**: Code uses `Client`, docs use `User`. Recommended: Unify to `User`.
+```
+
+## Constraints
+- **Ignore** technical terms (e.g., "Integer", "HTTP Request"). Focus on DOMAIN terms.
+- **Merge** synonyms if they clearly refer to the same thing, but note the inconsistency.
+- Definitions should be **business-centric**, not code-centric.