@haaaiawd/anws 1.2.5 → 2.0.0

package/templates/.agent/skills/git-forensics/scripts/git_hotspots.py

@@ -1,118 +0,0 @@
-import os
-import argparse
-import subprocess
-import json
-import csv
-from datetime import datetime
-try:
-    import lizard
-except ImportError:
-    print("Error: lizard not installed. Run: pip install lizard")
-    exit(1)
-
-def get_git_churn(repo_path: str, days: int) -> dict:
-    cmd = [
-        "git",
-        "-C", repo_path,
-        "log",
-        f"--since={days}.days.ago",
-        "--name-only",
-        "--format="
-    ]
-    try:
-        result = subprocess.check_output(cmd, encoding='utf-8')
-    except subprocess.CalledProcessError as e:
-        print(f"Git command failed: {e}")
-        return {}
-        
-    churn_map = {}
-    for line in result.splitlines():
-        if line.strip():
-            file_path = line.strip()
-            churn_map[file_path] = churn_map.get(file_path, 0) + 1
-            
-    return churn_map
-
-def get_complexity(repo_path: str, files: list) -> dict:
-    complexity_map = {}
-    for file_rel_path in files:
-        full_path = os.path.join(repo_path, file_rel_path)
-        if not os.path.exists(full_path):
-            continue
-            
-        try:
-            analysis = lizard.analyze_file(full_path)
-            # Use average cyclomatic complexity (CCN) or max CCN
-            # Max CCN is often a better indicator of "scary code"
-            max_ccn = 0
-            for func in analysis.function_list:
-                if func.cyclomatic_complexity > max_ccn:
-                    max_ccn = func.cyclomatic_complexity
-            
-            # File length is also a complexity factor
-            nloc = analysis.nloc
-            
-            complexity_map[file_rel_path] = {
-                "max_ccn": max_ccn,
-                "nloc": nloc,
-                "avg_ccn": analysis.average_cyclomatic_complexity
-            }
-        except Exception as e:
-            # lizard might fail on non-code files
-            pass
-            
-    return complexity_map
-
-def analyze_hotspots(repo_path: str, days: int, output_file: str):
-    print(f"Analyzing git churn for past {days} days...")
-    churn_data = get_git_churn(repo_path, days)
-    
-    print("Analyzing code complexity...")
-    # Only analyze files that exist and have churn
-    target_files = [f for f in churn_data.keys()]
-    complexity_data = get_complexity(repo_path, target_files)
-    
-    hotspots = []
-    for file, churn in churn_data.items():
-        if file in complexity_data:
-            comp = complexity_data[file]
-            hotspots.append({
-                "file": file,
-                "churn": churn,
-                "max_ccn": comp["max_ccn"],
-                "nloc": comp["nloc"],
-                # Simple score: Churn * CCN. 
-                # Prompts usually care about this metric.
-                "debt_score": churn * comp["max_ccn"] 
-            })
-    
-    # Sort by debt score descending
-    hotspots.sort(key=lambda x: x["debt_score"], reverse=True)
-    
-    # Output
-    result = {
-        "analysis_date": datetime.now().isoformat(),
-        "period_days": days,
-        "total_files_analyzed": len(hotspots),
-        "hotspots": hotspots[:50] # Top 50
-    }
-    
-    if output_file:
-        with open(output_file, 'w') as f:
-            json.dump(result, f, indent=2)
-        print(f"Hotspot analysis saved to {output_file}")
-    else:
-        print(json.dumps(result, indent=2))
-
-def main():
-    parser = argparse.ArgumentParser(description="Git Hotspot Analysis (Churn vs Complexity)")
-    parser.add_argument("--repo", default=".", help="Repository path")
-    parser.add_argument("--days", type=int, default=180, help="Analysis period in days")
-    parser.add_argument("--output", "-o", help="Output JSON file")
-    
-    args = parser.parse_args()
-    
-    analyze_hotspots(args.repo, args.days, args.output)
-
-if __name__ == "__main__":
-    main()

package/templates/.agent/skills/report-template/references/REPORT_TEMPLATE.md

@@ -1,100 +0,0 @@
-# System Context Report
-
-**Generated Date**: {{DATE}}
-**Analysis Target**: {{SCOPE}}
-
-## Executive Summary
-> [One sentence summary of the system's state, e.g., "A robust Python backend with some technical debt in the Auth module."]
-
----
-
-## 1. Component Inventory
-
-### 1.1 Existing Components
-| Component | Type | Path | Description |
-|---|---|---|---|
-| [Name] | [Service/UI/DB] | [Path] | [Brief Desc] |
-
-### 1.2 Missing Components (Dark Matter)
-> [!WARNING]
-> The following components are missing but critical for production readiness.
-
-| Component | Category | Why Needed | Impact if Missing |
-|---|---|---|---|
-| Error Handling | Infrastructure | No central error boundary found | Debugging will be difficult |
-| Logging | Observability | No structured logging | Blind in production |
-| Config Mgmt | Ops | Hardcoded secrets detected | Security risk |
-
----
-
-## 2. Dependency Topology
-
-### 2.1 Build Boundaries (Build Inspector)
-> [Insert findings from `build-inspector`: Build Roots, Topology, Sidecar Warnings]
-
-```mermaid
-graph TD
-    A[Module A] --> B[Module B]
-```
-
-### 2.2 Logical Coupling (Git Forensics)
-> [Insert Hotspot Matrix or Coupling Table]
-
-| File A | File B | Coupling | Risk |
-|---|---|---|---|
-| auth.py | user_db.py | 85% | HIGH |
-
----
-
-## 3. Risks & Warnings
-
-### 3.1 IPC Contract Risks (Runtime Inspector)
-> [!CAUTION]
-> [List IPC surfaces with weak/no contracts found by `runtime-inspector`]
-
-### 3.2 God Modules
-> [List modules with excessive Ca (Afferent Coupling)]
-
-### 3.3 Tech Debt Hotspots
-> [List files with High Churn + High Complexity]
-
----
-
-## 4. Implicit Constraints (Invariant Hunter)
-
-### 4.1 Business Invariants
-> [Rules that must never be broken]
-- Order total must be >= 0
-- User must verify email before payment
-
-### 4.2 Assumptions
-> [Unwritten assumptions found in code]
-- "Network is always reliable" (No retry logic)
-- "ID is always an integer"
-
-### 4.3 Hardcoded Values
-- API Keys
-- Timeout values
-
----
-
-## 5. Conceptual Model (Concept Modeler)
-
-### 5.1 Ubiquitous Language
-| Term | Definition |
-|---|---|
-| User | A registered end-user (not an admin) |
-| Order | A purchase request |
-
-### 5.2 Data Flows
-> [Describe key flows]
-
----
-
-## 6. Human Checkpoints
-> [!IMPORTANT]
-> Please confirm the following before proceeding to Blueprint Phase:
-
-- [ ] Is the Component Inventory complete?
-- [ ] Are the identified Risks acceptable for now?
-- [ ] Have all Invariants been captured?

package/templates/.agent/skills/spec-writer/SKILL.md

@@ -1,108 +0,0 @@
----
-name: spec-writer
-description: Transforms ambiguous user requests into rigorous Product Requirements Documents (PRDs). Use when requirements are vague or high-level.
----
-
-# The Detective's Guide (需求侦探手册)
-
-> "The hardest part of building software is deciding precisely what to build."
-
-Your job is to kill ambiguity.
-
-## ⚡ Quick Start
-
-1.  **Read Request (MANDATORY)**: Use `view_file` or context to identify "Vibe Words" (Fast, Modern, Easy).
-2.  **Deep Think (CRITICAL)**: You MUST call `sequential thinking` with 3-7 reasoning steps (depending on complexity) to:
-    *   Extract User Stories (As a X, I want Y, so that Z)
-    *   Identify ambiguities
-    *   Draft clarifying questions
-3.  **Interrogate**: Present questions to user. DO NOT proceed without answers.
-4.  **Draft PRD (MANDATORY)**: Use `view_file references/prd_template.md` then `write_to_file` to create `genesis/v{N}/01_PRD.md`.
-5.  **Ambiguity Scan (MANDATORY)**: After drafting, run the 10-Dimension Ambiguity Scan (see below). Fix issues inline or mark `[ASSUMPTION]`.
-6.  **US Quality Gate (MANDATORY)**: Verify every User Story passes the quality checklist (see below).
-
-## 🛑 Mandatory Steps
-Before creating the PRD, you MUST:
-1. Extract at least 3 clear User Stories.
-2. Define at least 3 Non-Goals (what we're NOT building).
-3. Clarify "Vibe Words" with the user (What does "Fast" mean to you? What does "Modern" imply?).
-4. Use `write_to_file` to save output. DO NOT just print to chat.
-
-After creating the PRD, you MUST:
-5. Run the 10-Dimension Ambiguity Scan — fix or mark all `Partial`/`Missing` items.
-6. Verify every User Story has: Priority / 独立可测 / 涉及系统 / 边界情况.
-7. Ensure `[NEEDS CLARIFICATION]` tags ≤ 3 (hard limit). Excess → use reasonable defaults + `[ASSUMPTION]` tag.
-
-## ✅ Completion Checklist
-- [ ] PRD file created: `genesis/v{N}/01_PRD.md`
-- [ ] Contains User Stories, Acceptance Criteria, Non-Goals
-- [ ] Every requirement is testable/measurable
-- [ ] User has approved the PRD
-
-## 🛠️ The Techniques
-
-### 1. Socratic Interrogation (苏格拉底追问)
-*   **User**: "I want it to be fast."
-*   **You**: "< 100ms p99? Or just UI optimistic updates?"
-*   *Goal*: Turn adjectives into numbers.
-
-### 2. Context Compression (上下文压缩)
-*   **Input**: 500 lines of chat history.
-*   **Action**: Extract the *User Stories*. "As a User, I want X, so that Y."
-*   **Discard**: Implementation details discussed too early (e.g., "Use Redis").
-
-### 3. Non-Goal Setting (画圈)
-*   Define what we are **NOT** doing.
-*   *Why*: Prevents scope creep. Prevents "What about X?" later.
-
-## ⚠️ Detective's Code
-
-1.  **Contract First**: If you can't test it, don't write it.
-2.  **No Solutions**: Describe *what*, not *how*. Leave *how* to the Architect.
-3.  **User Centric**: Every requirement must trace back to a user value.
-
-## 🧰 The Toolkit
-*   `references/prd_template.md`: The Product Requirements Document template.
-
-## 🔍 10-Dimension Ambiguity Scan
-
-After drafting the PRD, you **MUST** systematically scan it against these 10 dimensions. This replaces ad-hoc "any questions?" with a **repeatable, exhaustive** sweep.
-
-For each dimension, mark status: `Clear` ✅ / `Partial` ⚠️ / `Missing` ❌
-
-| # | Dimension | What to Check | Status |
-|---|-----------|--------------|:------:|
-| 1 | **Functional Scope & Behavior** | Core objectives / success criteria / explicit exclusions / user role distinctions | |
-| 2 | **Domain & Data Model** | Entities, attributes, relationships / uniqueness rules / lifecycle & state transitions / data volume assumptions | |
-| 3 | **Interaction & UX Flow** | Key user journeys / error, empty, loading states / accessibility & i18n | |
-| 4 | **Non-Functional Quality** | Performance / scalability / reliability / observability / security & privacy / compliance | |
-| 5 | **Integration & External** | External service failure modes / import-export formats / protocol version assumptions | |
-| 6 | **Edge Cases & Failure** | Negative scenarios / rate limiting / concurrency conflict resolution | |
-| 7 | **Constraints & Tradeoffs** | Technical constraints / explicit tradeoff records / rejected alternative archives | |
-| 8 | **Terminology Consistency** | Canonical glossary / synonym normalization across PRD | |
-| 9 | **Completion Signals** | Acceptance criteria testability / quantifiable DoD | |
-| 10 | **Placeholders** | TODO markers / unquantified vague adjectives (fast, scalable, secure, intuitive, robust) | |
-
-**Rules**:
-- `Partial` or `Missing` items → rank by **Impact × Uncertainty**, pick **top 5** to ask user
-- Ask **one question at a time**; provide your recommended answer; user can accept or customize
-- After user answers → **atomically write** the answer into the corresponding PRD section (never leave contradictory text)
-- **NEEDS CLARIFICATION hard limit ≤ 3** — if more remain, fill with reasonable defaults + `[ASSUMPTION: ...]` tag
-- **Do NOT ask about these reasonable defaults**: industry-standard data retention, standard web/mobile performance expectations, user-friendly error messages with fallbacks, standard session-based or OAuth2 auth
-
-## ✅ User Story Quality Gate
-
-Every User Story in the PRD **MUST** pass these checks before the PRD is considered complete:
-
-| Check | Requirement |
-|-------|------------|
-| **Unique ID** | Has `[REQ-XXX]` identifier for traceability |
-| **Priority** | Marked P0 / P1 / P2 — P0 stories listed first |
-| **独立可测** | Describes how this story can be **independently** demonstrated and verified |
-| **涉及系统** | Lists specific system IDs (must align with `02_ARCHITECTURE_OVERVIEW.md`) |
-| **Acceptance Criteria** | At least 1 Given-When-Then + at least 1 Error Case |
-| **边界情况** | At least 1 boundary condition identified |
-| **No Vibe Words** | No unquantified adjectives (fast → <100ms p99, scalable → support N users) |
-| **User Value** | One sentence describing value to end user |
-
-If any User Story fails a check → fix it before delivering the PRD.

package/templates/.agent/skills/system-architect/references/rfc_template.md

@@ -1,59 +0,0 @@
-# Request for Comments (RFC) / Technical Spec
-
-**PRD Reference**: [Link to PRD]
-**Feature**: [Feature Name]
-**Status**: Draft
-
-## 1. High-Level Design
-### Architecture Diagram (Mermaid)
-<!-- Use Mermaid to show data flow -->
-```mermaid
-graph TD
-    A[User] -->|Action| B(Component)
-    B -->|API Call| C{Service}
-```
-
-### Component Hierarchy
-*   `ParentComponent`
-    *   `ChildA` (Props: x, y)
-    *   `ChildB` (State: z)
-
-## 2. API Contract (The "Signature")
-<!-- CRITICAL: Define exact signatures. No hallucination allowed. -->
-
-### Endpoints
-*   `POST /api/v1/resource`
-    *   **Request Body**:
-        ```typescript
-        interface CreateRequest {
-          field: string; // required
-        }
-        ```
-    *   **Response**: `200 OK` (Schema below)
-
-### Function Interfaces
-<!-- Signatures for key internal functions -->
-```typescript
-function calculateSomething(input: InputType): ResultType
-```
-
-## 3. Data Model Strategy
-### Database Schema Changes
-```sql
--- DDL goes here
-CREATE TABLE ...
-```
-
-### State Management
-*   Global State: [e.g. Redux/Zustand slice]
-*   Local State: [e.g. React.useState]
-
-## 4. Implementation Steps
-<!-- Atomic, ordered steps -->
-1.  [Step 1: DB Migration]
-2.  [Step 2: API Backend]
-3.  [Step 3: Frontend UI]
-
-## 5. Security & Risk
-*   **Auth**: [How is this secured?]
-*   **Validation**: [Input validation library?]

package/templates/.agent/skills/task-planner/references/TASK_TEMPLATE.md

@@ -1,144 +0,0 @@
-# Task Decomposition Template
-
-**Project**: [Project Name]  
-**Blueprint Phase**: Approved  
-**RFC Reference**: `genesis/v{N}/02_ARCHITECTURE_OVERVIEW.md`
-
----
-
-## 📋 Task List
-
-### Legend
-- **ID**: Unique task identifier (T001, T002...)
-- **[P]**: Parallelizable (can run independently)
-- **[Verification]**: Checkpoint task (manual/E2E validation)
-- **User Story**: Maps to PRD (US01, US02...)
-- **Done When**: Verification criterion
-
----
-
-### Phase 1: Foundation
-
-#### T001 - Database Schema Setup
-- **User Story**: US01
-- **Description**: Create `users` table with fields: `id`, `email`, `password_hash`, `created_at`.
-- **Dependencies**: None
-- **Done When**: `psql -c "\d users"` shows correct schema.
-  
-#### T002 - [P] Environment Configuration
-- **User Story**: US01
-- **Description**: Add `.env` file with `DATABASE_URL`, `JWT_SECRET`.
-- **Dependencies**: None
-- **Done When**: `docker-compose up` starts DB without errors.
-
-
----
-
-### Phase 2: Core Logic
-
-#### T003 - User Registration Endpoint
-- **User Story**: US01
-- **Description**: Implement `POST /api/register` that hashes password and stores user.
-- **Dependencies**: T001 (DB Schema)
-- **Done When**: `curl -X POST /api
-
-#### T004 - [P] JWT Token Generation
-- **User Story**: US01
-- **Description**: Create `generate_token(user_id)` helper function.
-- **Dependencies**: T002 (JWT_SECRET configured)
-- **Done When**: Unit test `test_generate_token()` passes.
-
----
-
-## 📊 Sprint 路线图
-
-| Sprint | 代号 | 核心任务 | 退出标准 | 预估 |
-|--------|------|---------|---------|------|
-| S1 | Foundation | T001-T002 | DB 可连接 + 环境变量生效 | 1d |
-| S2 | Core Logic | T003-T005 | 完整认证流程可运行 | 2d |
-
----
-
-### Phase 3: Integration
-
-#### T005 - Login Endpoint
-- **User Story**: US01
-- **Description**: Implement `POST /api/login` that validates credentials and returns JWT.
-- **Dependencies**: T003 (User table populated), T004 (JWT generator ready)
-- **Input**: T003 产出的 `users` 表 + T004 产出的 `generate_token()` 函数
-- **Output**: `/api/login` 端点 (`src/routes/auth.js`)
-- **Done When**: 
-  1. Valid login returns `{token: "..."}`.
-  2. Invalid login returns 401.
-
-#### INT-S2 - [MILESTONE] S2 集成验证 — Core Logic
-- **User Story**: US01
-- **Type**: Integration Verification (Sprint Gate)
-- **Description**: 验证 S2 退出标准：完整认证流程可运行
-- **Dependencies**: All S2 tasks (T003-T005)
-- **Done When**:
-  1. Run `npm run dev` or equivalent
-  2. Register a new user via `/api/register`
-  3. Login with valid credentials → receives JWT token
-  4. Login with invalid credentials → receives 401 error
-  5. All unit tests pass (`npm test`)
-  6. No linter errors (`npm run lint`)
-
----
-
-## 🔗 Dependency Graph
-
-```
-T001 (DB Schema)
-  → T003 (Register)
-      → T005 (Login)
-
-T002 (Env Config) [P]
-  → T004 (JWT Helper) [P]
-      → T005 (Login)
-```
-
----
-
-## 📊 Summary
-
-| Phase | Total Tasks | Parallelizable |
-|-------|-------------|----------------|
-| 1     | 2           | 1              | 
-| 2     | 2           | 1              | 
-| 3     | 1           | 0              | 
-| **Total** | **5**   | **2**          |
-
----
-
-## ✅ Acceptance Criteria
-
-Before marking Blueprint as complete:
-- [ ] All tasks have unique IDs
-- [ ] Dependencies are explicit (→ notation)
-- [ ] Each task has "Done When" criterion
-- [ ] No task contains actual code (only descriptions <10 lines)
-- [ ] Total estimated time is realistic
-- [ ] User has approved this task list
-
----
-
-## 🚫 Anti-Patterns to Avoid
-
-❌ **Bad Task**:
-```
-T001 - Build Authentication System
-- Implement everything related to auth
-- Make it secure and fast
-```
-
-✅ **Good Task**:
-```
-T001 - Database Schema Setup
-- Description: Create `users` table with `id`, `email`, `password_hash`.
-- Done When: `psql -c "\d users"` shows correct schema.
-```
-
----
-
-**Next Step**: Proceed to `/build` workflow to implement tasks sequentially.

package/templates/.agent/workflows/scout.md

@@ -1,139 +0,0 @@
----
-description: 探测系统风险、隐藏耦合和"改了就炸"的暗坑，通过 Git 热点分析和 Gap Analysis 产出风险报告，适用于接手遗留项目或重大变更前。
-
----
-
-# /scout
-
-<phase_context>
-你是 **Scout 2.0 - 结构拆解专家**。
-
-**核心使命**：
-在架构更新 (`genesis/v{N}`) 之前或之后，探测系统风险、暗坑和耦合。
-Scout 的发现将作为**输入**反馈给 Architectural Overview。
-
-**Output Goal**: `genesis/v{N}/00_SCOUT_REPORT.md`
-</phase_context>
-
----
-
-## ⚠️ CRITICAL 流程约束
-
-> [!IMPORTANT]
-> Scout 不修改架构，只**观测**和**报告**。
-> 你的报告应该被 Genesis 过程参考。
-
-> [!NOTE]
-> **Scout 双模式说明**:
-> - **模式 A (Genesis 前)**: 侦察遗留代码，产出作为 genesis 的输入
-> - **模式 B (Genesis 后)**: 验证设计与代码的一致性 (Gap Analysis)
-> 
-> 判断方式: 如果 `genesis/v{N}/concept_model.json` 存在 → 模式 B，Step 5 执行对比  
-> 如果不存在 → 模式 A，Step 5 跳过对比，仅提取代码中的概念
-
----
-
-## Step 1: 建立大局观 (System Fingerprint)
-
-1.  **扫描根目录**: 列出项目根目录下的所有文件和文件夹
-2.  **获取当前架构上下文** (Optional):
-    - 如果存在 `genesis/v{N}`，读取其 `02_ARCHITECTURE_OVERVIEW.md` 以对比"计划"与"现实"。
-
----
-
-## Step 2: 拆解构建系统 (Build Topology)
-
-**目标**: 识别项目的构建边界和产物关系。
-
-1.  **调用技能**: `build-inspector`
-2.  **执行步骤**:
-    - 定位所有构建配置文件 (package.json, Cargo.toml, go.mod, Makefile 等)
-    - 判断是否有统一管理 (workspace/monorepo)
-    - 识别最终产物 (binary, bundle, docker image)
-3.  **输出要点**:
-    - Build Roots 列表
-    - 拓扑类型 (Monolith / Workspace / Polyrepo)
-    - ⚠️ 标记跨根依赖风险
-
----
-
-## Step 3: 拆解运行时通信 (Runtime Topology)
-
-**目标**: 追踪进程间通信和契约状态。
-
-1.  **调用技能**: `runtime-inspector`
-2.  **执行步骤**:
-    - 识别所有入口点 (main 函数)
-    - 追踪进程生成链 (spawn/fork)
-    - 检测 IPC 通道和协议定义
-3.  **输出要点**:
-    - Process Roots 和 Spawning Chains
-    - Contract Status (Strong / Weak / None)
-    - ⚠️ 标记僵尸进程和协议漂移风险
-
----
-
-## Step 4: 拆解历史耦合 (Temporal Topology)
-
-**目标**: 从 Git 历史发现隐藏的耦合关系。
-
-1.  **调用技能**: `git-forensics`
-2.  **执行步骤**:
-    - 分析变更频率和耦合对
-    - 交叉标注构建根信息
-    - 定位热点模块 (高 Churn × 高 Complexity)
-3.  **输出要点**:
-    - Coupling Pairs (标注构建根)
-    - Hotspots 和孤儿文件
-    - ⚠️ 重点标记跨根耦合
-
----
-
-## Step 5: 领域概念建模 (Domain Concept Modeling)
-
-**目标**: 提取*当前代码实现中*的隐式概念。
-
-1.  **调用技能**: `concept-modeler`
-2.  **对比**: 将代码中的概念与 `genesis/v{N}/concept_model.json` 进行对比 (如果存在)。
-    - *Gap Analysis*: "文档里说有 User 实体，但代码里只有 Account 实体？"
-
----
-
-## Step 6: 冲突与风险分析
-
-**目标**: 识别 "Change Impact"。
-
-1.  **如果你正在服务于一次 Genesis 更新**:
-    - 结合 `genesis/v{N}/01_PRD.md` (新需求)。
-    - 分析这些新需求会触碰哪些 "Landmines" (Git Hotspots)。
-
----
-
-## Step 7: 生成报告
-
-**目标**: 保存带有时间戳的报告，防止覆盖历史记录。
-
-保存报告到 `genesis/v{N}/00_SCOUT_REPORT.md`
-
-（注意：如果版本不存在，默认为 v1）
-
-确保 `genesis/v{N}/` 目录存在。
-
-**报告必须包含**:
-1.  **System Fingerprint**
-2.  **Gap Analysis** (Document vs Code)
-3.  **Risk Matrix** (Hotspots, IPC Risks)
-
-<completion_criteria>
-- ✅ 建立了系统指纹
-- ✅ 发现了文档与代码的 Gap
-- ✅ 产出了带有时间戳的风险报告
-</completion_criteria>
-
----
-
-## 🔀 Handoffs
-
-完成本工作流后，根据情况选择：
-
-- **启动新版本架构** → `/genesis` — 基于侦察发现启动架构重构 *(发现需要重大重构时)*