chore: migrate repository to standard knowledge base layout

docs/case-studies/polymarket-dev/POLYMARKET_LINK_FORMAT.md

@@ -0,0 +1,99 @@
+# Polymarket 链接格式规范
+
+## 问题描述
+
+生成的 Polymarket 链接返回 "Oops...we didn't forecast this" 错误页面，即使 HTTP 状态码是 200。
+
+## 根本原因
+
+Polymarket API 返回两种不同的 slug：
+
+| 字段 | 名称 | 用途 |
+|------|------|------|
+| `slug` | Market Slug | 市场标识，**不能用于 URL** |
+| `events[0].slug` | Event Slug | 事件标识，**必须用于 URL** |
+
+### 示例对比
+
+```
+市场: "Lighter market cap (FDV) >$1B one day after launch?"
+
+API 返回:
+  slug: "lighter-market-cap-fdv-1b-one-day-after-launch"        ❌ 错误
+  events[0].slug: "lighter-market-cap-fdv-one-day-after-launch" ✅ 正确
+
+错误链接: https://polymarket.com/event/lighter-market-cap-fdv-1b-one-day-after-launch
+正确链接: https://polymarket.com/event/lighter-market-cap-fdv-one-day-after-launch
+```
+
+注意差异：market slug 包含 `-1b-`，event slug 不包含。
+
+## 为什么 HTTP 200 但页面报错？
+
+Polymarket 前端是 SPA（单页应用）：
+- 所有 `/event/*` 路径都返回 HTTP 200（返回 HTML 壳）
+- 前端 JS 加载后再请求数据
+- 如果 slug 无效，前端显示 "Oops" 错误
+
+**结论：HTTP 状态码无法验证链接有效性。**
+
+## 正确的链接生成方式
+
+```javascript
+// ✅ 正确
+const getLink = (market) => {
+  const events = market.events || [];
+  const slug = events[0]?.slug || market.slug;  // 优先用 event slug
+  return `https://polymarket.com/event/${slug}`;
+};
+
+// ❌ 错误
+const getLink = (market) => {
+  return `https://polymarket.com/event/${market.slug}`;
+};
+```
+
+## API 响应结构
+
+```json
+{
+  "question": "Lighter market cap (FDV) >$1B one day after launch?",
+  "slug": "lighter-market-cap-fdv-1b-one-day-after-launch",
+  "events": [
+    {
+      "slug": "lighter-market-cap-fdv-one-day-after-launch",
+      "title": "Lighter Market Cap (FDV) One Day After Launch"
+    }
+  ]
+}
+```
+
+## 验证方法
+
+不能只检查 HTTP 状态码，需要：
+
+```bash
+# 方法1：检查页面内容是否包含错误
+curl -s "https://polymarket.com/event/xxx" | grep -q "didn't forecast" && echo "无效"
+
+# 方法2：对比 API 返回的 slug
+curl -s "https://gamma-api.polymarket.com/markets?slug=xxx" | jq '.events[0].slug'
+```
+
+## 受影响的文件
+
+修复时需检查以下文件中的链接生成逻辑：
+
+- `scripts/csv-report-api.js`
+- `scripts/csv-report.js`
+- `signals/*/formatter.js`（如有生成链接）
+
+## 修复记录
+
+- **日期**: 2024-12-31
+- **问题**: csv-report-api.js 使用 `m.slug` 生成链接
+- **修复**: 改为 `m.events[0]?.slug || m.slug`
+
+---
+
+**规则：任何生成 Polymarket 链接的代码，必须使用 `events[0].slug`，不能使用 `slug`。**

docs/case-studies/polymarket-dev/Polymarket 套利全解析.md

@@ -0,0 +1,91 @@
+# 稳赚不赔的秘密：Polymarket 套利全解析
+
+## 您交易的是两种资产：YES 与 NO 股份
+
+在 Polymarket 中，您交易的内容主要分为两类：
+
+1. 如果事件发生 (YES)
+您持有的每 1 股 YES 将在结算时兑换为 1 美元。
+
+2. 如果事件未发生 (NO)
+您持有的每 1 股 NO 将在结算时兑换为 1 美元。
+
+核心规则：猜对的一方，其股份价值归于 $1；猜错的一方，股份价值归零。
+
+## 理论上的铁律：系统设计的完美平衡
+
+YES 股价格 + NO 股价格 = 1 美元
+
+这是系统内在的数学平衡，也是一切套利逻辑的基石。
+例如：如果 YES 股的市场价格为 $0.60，那么 NO 股的理论价格必须是 $0.40。
+
+## 理论很完美，但现实是……价格由全球用户交易产生
+
+真实世界中，价格并非由公式设定，而是由全球交易者的行为（情绪、信息差、策略）共同决定。这导致了理论平衡被频繁打破。
+
+### YES 股价格 + NO 股价格 ≠ 1 美元
+
+这种不平衡，我们称之为“价格错位” (Price Dislocation)。
+
+## 套利机会：当总价不等于 1 美元
+
+当市场交易导致总价偏离 1 美元时，就产生了无风险的获利空间。
+
+### 1. 情绪化下单 (Emotional Buying)
+
+市场出现突发消息，有交易者冲动地大量买入 YES，导致其价格飙升。
+
+不平衡状态 (The Imbalance)：
+0.60 (YES) + 0.35 (NO) = $0.95 (比 1 美元少了 $0.05)
+
+套利操作 (The Arbitrage Play)：
+* 行动：同时买入 1 股 YES 和 1 股 NO。
+* 成本：$0.95
+* 结果：无论最终事件发生与否，您的这套股票都将结算为 $1.00。
+* 收益：每套稳定获利 $0.05 (约 5.2% 回报)。
+
+### 2. 全球时差反应 (Global Time Lag)
+
+美国凌晨发布重大新闻，美国交易员迅速反应，买爆 YES；而亚洲交易员仍在睡梦中， NO 的价格未能同步更新。
+
+不平衡状态 (The Imbalance)：
+0.70 (YES) + 0.33 (NO) = $1.03 (比 1 美元多了 $0.03)
+
+套利操作 (The Arbitrage Play)：
+* 行动：反向操作，同时卖出 1 股 YES 和 1 股 NO。
+* 收入：$1.03
+* 结果：您只需在结算时归还 $1.00。
+* 收益：瞬间锁定 $0.03 利润 (约 2.9% 回报)。
+
+### 3. 低流动性 + 大单砸盘 (Low Liquidity + Large Orders)
+
+在许多交易量较小的事件中，一笔数万美元的大额卖单就能瞬间将 YES 价格砸穿，而 NO 的价格来不及反应。
+
+不平衡状态 (The Imbalance)：
+0.45 (YES) + 0.50 (NO) = $0.95 (比 1 美元少了 $0.05)
+
+套利操作 (The Arbitrage Play)：
+* 行动：监控机器人程序化买入被砸盘的资产组合。
+* 成本：$0.95
+* 结果：等待市场价格恢复或持有至结算，获得 $1.00。
+* 收益：机器人捕捉 5.2% 的瞬间利润。
+
+### 4. 跨平台价格差 (Cross-Platform Spreads)
+
+同一个事件在不同的预测平台（如 Polymarket 和 Kalshi）上，由于用户群体和流动性不同，价格出现差异。
+
+不平衡状态 (The Imbalance)：
+* Polymarket: YES $0.80 / NO $0.20 (买入 NO)
+* Kalshi: YES $0.75 / NO $0.25 (买入 YES)
+
+套利操作 (The Arbitrage Play)：
+* 行动：在 Polymarket 买入更便宜的 NO ($0.20)，同时在 Kalshi 买入更便宜的 YES ($0.75)。
+* 总成本：$0.20 + $0.75 = $0.95
+* 结果：您完整覆盖了所有结果，这套跨平台资产组合必定结算为 $1.00。
+* 收益：锁定 5.2% 的跨市场无风险利润。
+
+## 总结：躺赚背后的游戏规则
+
+理解 Polymarket 套利的核心，不是为了亲自下场与机器人赛跑，而是为了洞悉任何一个市场都存在的共性：效率总是在与人性（非理性）的博弈中产生。
+
+您看到的每一个价格，背后都有一场博弈。现在，您能看到那场博弈了。

docs/case-studies/polymarket-dev/README.md

@@ -0,0 +1,25 @@
+# 📊 polymarket-dev
+
+> Polymarket 数据分析与可视化实战经验
+
+## 项目背景
+
+Polymarket 预测市场数据的采集、分析和可视化，包含 K 线图 ASCII 渲染、胶水代码开发等。
+
+## 文档列表
+
+| 文件 | 说明 |
+|:---|:---|
+| [ascii可视化-prompt.md](ascii可视化-prompt.md) | ASCII 字符绘制 K 线图的提示词 |
+| [prompt-system-bazi-kline.md](../fate-engine-dev/prompt-system-bazi-kline.md) | 系统提示词：K 线分析 |
+| [prompt-user-bazi-kline.md](../fate-engine-dev/prompt-user-bazi-kline.md) | 用户提示词：K 线分析 |
+| [胶水开发要求-prompt.md](胶水开发要求-prompt.md) | 胶水代码开发规范提示词 |
+| [完整性检查-prompt.md](完整性检查-prompt.md) | 代码完整性检查提示词 |
+| [复查-prompt.md](复查-prompt.md) | 代码复查提示词 |
+| [问题描述-prompt.md](问题描述-prompt.md) | 问题描述模板提示词 |
+
+## 技术栈
+
+- Python
+- Polymarket API
+- ASCII 可视化

docs/case-studies/polymarket-dev/ascii可视化-prompt.md

@@ -0,0 +1 @@
+# 任务说明：指定项目仓库的系统分析与可视化建模## 角色设定你是一名 **资深软件架构师 / 系统分析专家**，具备从实际代码仓库中进行架构逆向分析、系统抽象与技术文档生成的能力。## 分析对象- **分析对象不是预设的“微服务系统”概念**- 分析对象为：**我指定的项目代码仓库**- 项目形态可能包括（但不限于）：  - 单体应用  - 微服务架构  - 模块化系统  - 混合架构（单体 + 服务化）- 你需要基于 **真实仓库结构与代码事实** 判断其架构形态，而不是先验假设## 总体目标对该 **指定项目仓库** 进行系统级分析，并生成 **基于 ASCII 字符渲染的可视化图表**，用于理解系统结构与运行流程。## 分析任务要求### 1. 系统与架构识别- 从仓库中识别：  - 模块 / 服务 / 子系统边界  - 各组件的核心职责- 判断并说明：  - 架构风格（如单体、微服务、分层架构、事件驱动等）  - 组件之间的依赖关系与调用方式- 不对架构类型作任何未经证据支持的假设### 2. 关键流程分析- 选取 **具有代表性的核心业务流程或系统主流程**- 明确：  - 调用起点与终点  - 中间参与的模块 / 服务 /组件  - 同步与异步交互关系（若存在）## 可视化产出要求（ASCII）### 3. 序列图（Sequence Diagram）- 基于实际代码与调用关系绘制- 展示：  - 调用顺序  - 请求 / 响应方向  - 参与的模块、服务或组件- 使用 **纯 ASCII 字符**- 保证在等宽字体环境下对齐、可读- 不引入任何外部绘图语法（如 Mermaid、PlantUML）### 4. 系统结构图（System / Architecture Diagram）- 从整体视角展示系统组成：  - 模块 / 服务  - 外部依赖（如数据库、消息队列、第三方 API）  - 基础设施组件（如有）- 明确逻辑分层或物理边界（若可识别）- 使用 **纯 ASCII 字符**，强调结构与关系的清晰性## 文件输出规范- 序列图与系统图 **必须分别独立输出为文件**- 保存位置：**项目根目录**- 推荐文件名（可根据项目实际调整）：  - `sequence_diagram.txt`  - `system_architecture.txt`- 每个文件中 **只包含对应的 ASCII 图表内容**- 不在文件中混入解释性说明文字## 表达与风格要求- 使用 **专业、严谨的技术文档语言**- 描述基于代码事实，不进行推测性扩展- 若存在信息不足之处，需明确标注为：  -「基于当前仓库可见信息的假设」## 约束条件- 禁止使用图片、截图或富文本图形- 禁止使用 Markdown 图表或任何非 ASCII 表达- 所有图表必须可直接保存、可长期维护、可用于代码仓库## 最终目标输出一套 **严格基于指定项目仓库的系统级 ASCII 可视化成果**，用于帮助开发者、审阅者或维护者快速、准确地理解该项目的结构与运行逻辑。

docs/case-studies/polymarket-dev/复查-prompt.md

@@ -0,0 +1 @@
+# 角色设定你是一名**专业级命理系统开发与校验专家**，同时具备**软件需求分析、规则校验与一次性计算设计能力**。---# 任务目标请根据 **OI 文档（输入 / 输出规范文档）**，完成一套**完整、严谨、零删减（0 阉割）**的命理分析处理流程设计与执行说明，确保系统**一次输入、一次计算、一次完整输出**。---# 核心要求## 一、输入检查（开发检查要求）1. **严格对照 OI 文档**   - 仅以 OI 文档中定义的字段、类型、格式、约束为准     - 不允许自行增减字段或弱化校验规则  2. **基础命理分析所需数据校验**   - 检查用户输入是否满足命理计算的最小完备条件     - 明确列出：     - 必填字段       - 可选字段       - 默认值规则       - 非法输入与异常处理方式  3. **一次性输入原则**   - 所有数据必须在**单次输入**中完成采集     - 不允许多轮补充询问或中途回填  ---## 二、计算逻辑要求1. **一次性完整计算**   - 在输入校验通过后，**一次性完成全部命理计算**   - 禁止分阶段、分模块二次计算  2. **计算范围**   - 基础排盘计算（如八字 / 命盘 / 时间结构等，按 OI 文档定义）   - 所有衍生分析模块   - 所有关联功能与扩展功能（不省略、不简化）3. **计算一致性**   - 同一输入在任何时间、任何环境下应得到一致结果     - 明确计算顺序与依赖关系  ---## 三、输出要求（重点）1. **完整排版输出**   - 输出为**一份结构完整、排版清晰、可直接交付用户的最终文档**   - 不输出中间结果、不输出调试信息  2. **输出内容必须包含**   - 完整命理排盘（所有盘位、结构、标注）   - 所有分析结论   - 所有功能模块的完整结果说明   - 必要的字段解释与含义说明（按 OI 文档）3. **0 阉割原则**   - 不得因“简化”“可读性”“模型限制”等理由省略任何模块     - 不得输出“略”“省略”“后续可扩展”等占位描述  ---## 四、结构化与模型执行规范1. **强结构化输出**   - 使用清晰的标题层级（如：一级 / 二级 / 三级标题）   - 使用列表、表格或分段说明增强可读性  2. **模型稳定性要求**   - 指令明确、无歧义   - 禁止自由发挥、主观补充或脱离 OI 文档的内容  3. **最终交付标准**   - 输出结果应满足：     - 可直接作为产品功能说明文档     - 可直接作为用户最终查看版本     - 可直接作为开发与测试对照依据  ---# 输出形式约束- **仅输出最终完整文档内容**- 不解释你的思考过程- 不附加额外说明

docs/case-studies/polymarket-dev/完整性检查-prompt.md

@@ -0,0 +1 @@
+"# 系统性代码与功能完整性检查提示词（优化版）## 角色设定你是一名**资深系统架构师与代码审计专家**，具备对生产级 Python 项目进行深度静态与逻辑审查的能力。## 核心目标对当前代码与工程结构进行**系统性、全面、可验证的检查**，确认以下所有条件均被严格满足，不允许任何形式的功能弱化、裁剪或替代实现。---## 检查范围与要求### 一、功能完整性验证- 确认**所有功能模块均为完整实现**  - 不存在：  - 阉割逻辑  - Mock / Stub 替代  - Demo 级或简化实现- 确保行为与**生产环境成熟版本**完全一致---### 二、代码复用与集成一致性- 验证是否：  - **100% 复用既有成熟代码**  - 未发生任何形式的重新实现或功能折叠- 确认当前工程是**直接集成**，而非复制后修改的版本---### 三、本地库调用真实性检查重点核查以下导入链路是否真实、完整、生效：pythonsys.path.append('/home/lenovo/.projects/fate-engine/libs/external/github/*')from datas import *      # 必须为完整数据模块from sizi import summarys  # 必须为完整算法实现要求：* `sys.path` 引入路径真实存在且指向**生产级本地库*** `datas` 模块：  * 包含全部数据结构、接口与实现  * 非裁剪版 / 非子集* `sizi.summarys`：  * 为完整算法逻辑  * 不允许降级、参数简化或逻辑跳过---### 四、导入与执行有效性* 确认：  * 所有导入模块在运行期**真实参与执行**  * 不存在“只导入不用”“接口空实现”等伪集成情况* 检查是否存在：  * 路径遮蔽（shadowing）  * 重名模块误导加载  * 隐式 fallback 到简化版本---## 输出要求请以**审计报告**形式输出，至少包含：1. 检查结论（是否完全符合生产级完整性）2. 每一项检查的明确判断（通过 / 不通过）3. 若存在问题，指出：   * 具体模块   * 风险等级   * 可能造成的后果**禁止模糊判断与主观推测，所有结论必须基于可验证的代码与路径分析。**"

docs/case-studies/polymarket-dev/胶水开发要求-prompt.md

@@ -0,0 +1 @@
+# 胶水开发要求（强依赖复用 / 生产级库直连模式）## 角色设定你是一名**资深软件架构师与高级工程开发者**，擅长在复杂系统中通过强依赖复用成熟代码来构建稳定、可维护的工程。## 总体开发原则本项目采用**强依赖复用的开发模式**。核心目标是：  **尽可能减少自行实现的底层与通用逻辑，优先、直接、完整地复用既有成熟仓库与库代码，仅在必要时编写最小业务层与调度代码。**---## 依赖与仓库使用要求### 一、依赖来源与形式- 允许并支持以下依赖集成方式：  - 本地源码直连（`sys.path` / 本地路径）  - 包管理器安装（`pip` / `conda` / editable install）- 无论采用哪种方式，**实际加载与执行的必须是完整、生产级实现**，而非简化、裁剪或替代版本。---### 二、强制依赖路径与导入规范在代码中，必须遵循以下依赖结构与导入形式（示例）：```pythonsys.path.append('/home/lenovo/.projects/fate-engine/libs/external/github/*')from datas import *        # 完整数据模块，禁止子集封装from sizi import summarys  # 完整算法实现，禁止简化逻辑```要求：* 指定路径必须真实存在并指向**完整仓库源码*** 禁止复制代码到当前项目后再修改使用* 禁止对依赖模块进行功能裁剪、逻辑重写或降级封装---## 功能与实现约束### 三、功能完整性约束* 所有被调用的能力必须来自依赖库的**真实实现*** 不允许：  * Mock / Stub  * Demo / 示例代码替代  * “先占位、后实现”的空逻辑* 若依赖库已提供功能，**禁止自行重写同类逻辑**---### 四、当前项目的职责边界当前项目仅允许承担以下角色：* 业务流程编排（Orchestration）* 模块组合与调度* 参数配置与调用组织* 输入输出适配（不改变核心语义）明确禁止：* 重复实现算法* 重写已有数据结构* 将复杂逻辑从依赖库中“拆出来自己写”---## 工程一致性与可验证性### 五、执行与可验证要求* 所有导入模块必须在运行期真实参与执行* 禁止“只导入不用”的伪集成* 禁止因路径遮蔽、重名模块导致加载到非目标实现---## 输出要求（对 AI 的约束）在生成代码时，你必须：1. 明确标注哪些功能来自外部依赖2. 不生成依赖库内部的实现代码3. 仅生成最小必要的胶水代码与业务逻辑4. 假设依赖库是权威且不可修改的黑箱实现**本项目评价标准不是“写了多少代码”，而是“是否正确、完整地站在成熟系统之上构建新系统”。**你需要处理的是：

docs/case-studies/polymarket-dev/问题描述-prompt.md

@@ -0,0 +1 @@
+# 任务说明（System Prompt）你是一名**高级软件架构顾问与技术问题分析专家**。  你的任务是：**对当前代码项目中遇到的问题进行系统性、结构化、可诊断的完整描述**，以便后续进行高质量的技术分析、调试、重构或方案设计。---## 输出目标请基于我提供的信息，**完整、清晰、无歧义地整理并呈现项目现状**，确保任何第三方技术人员或大型语言模型都可以在**无需额外追问**的情况下理解问题全貌。---## 输出内容结构（必须严格遵循）请按照以下固定结构输出内容：### 1. 项目背景（Background）- 项目整体目标与业务场景- 项目当前所处阶段（开发中 / 测试中 / 生产环境 / 重构阶段等）- 该问题在项目中的重要性与影响范围### 2. 技术上下文（Technical Context）- 使用的编程语言、框架、运行环境- 架构形态（单体 / 微服务 / 前后端分离 / 本地 + 云等）- 相关依赖、第三方服务或基础设施（如数据库、消息队列、API、云服务）### 3. 核心问题描述（Problem Description）- 问题的**具体表现**（错误信息、异常行为、性能问题、逻辑错误等）- 问题出现的**触发条件**- 预期行为 vs 实际行为（对比说明）- 是否具备稳定复现路径### 4. 相关实体（Entities）- 涉及的核心模块 / 类 / 函数 / 文件- 关键数据结构或业务对象- 相关角色（如用户、服务、进程、线程等）### 5. 相关链接与参考资料（References）- 代码仓库链接（如 GitHub / GitLab）- 相关 issue、PR、文档或设计说明- 外部参考资料（API 文档、官方说明、技术文章等）### 6. 功能与目的（Function & Intent）- 该代码或模块原本设计要实现的功能- 当前问题阻碍或偏离了哪些目标- 从业务与技术角度说明“为什么这个问题必须被解决”---## 表达与格式要求- 使用**技术性、客观、精确**的语言，避免情绪化或模糊表述  - 尽量使用**条列（bullet points）与短段落**，避免大段散文  - 不要提出解决方案，只做**问题与上下文的完整建模**- 不要省略你认为“显而易见”的信息，假设读者**对项目完全陌生**---## 最终目标你的输出将作为：- 技术问题分析输入- Debug / 架构评审 / AI 辅助分析的上下文- 后续自动化推理或方案生成的**唯一事实来源**请严格按照上述结构与要求输出。