docs: 添加 API 文档、架构文档和许可证文件 #16

飞书 Webhook 配置的示例格式为 `群名1|URL;群名2|URL|签名密钥`，第一个 Webhook 缺少签名密钥字段。但描述表格中注明格式为 `名称|URL|密钥;...`，示例与文档描述不一致，可能导致用户配置时遗漏签名密钥，从而导致消息发送失败。如果签名密钥确实可选，应在文档中明确说明。

FEISHU_WEBHOOKS=群名1|https://open.feishu.cn/open-apis/bot/v2/hook/xxx;群名2|https://open.feishu.cn/open-apis/bot/v2/hook/xxx|签名密钥

FEISHU_WEBHOOKS=群名1|https://open.feishu.cn/open-apis/bot/v2/hook/xxx|签名密钥;群名2|https://open.feishu.cn/open-apis/bot/v2/hook/xxx|签名密钥

GET /health 的 Response 表格仅列出 status 和 app 两个字段，但下方 Response Example 中 JSON 对象包含 timestamp 字段。表格与示例不一致会导致开发者对接时遗漏字段处理。建议在表格中补充 timestamp 字段的类型和说明。

{
  "status": "ok",
  "app": "prism"
}

{
  "status": "ok",
  "app": "prism",
  "timestamp": "2025-01-01T00:00:00Z"
}

POST /webhook/github 的响应示例中使用 `// 503 Service Unavailable` 注释标记状态码。虽然可读，但在 API 文档中更标准的做法是使用 `HTTP Status:` 前缀明确标注，避免开发者误以为这是 JSON 响应的一部分。建议统一所有示例的状态码标注格式。

// 503 Service Unavailable
{
  "status": "busy",
  "message": "审查队列已满，请稍后重试"
}

// HTTP Status: 503 Service Unavailable
{
  "status": "busy",
  "message": "审查队列已满，请稍后重试"
}

POST /webhook/github 的响应示例中 `action` 字段值 `closed` 代表 GitHub Webhook 事件类型，而 POST /api/review 端点响应中 `action` 字段值 `queued` 代表内部任务状态。同一个字段名在不同端点代表不同语义，容易造成开发者混淆。建议将 Webhook 端点的字段重命名为 `github_action` 以消除歧义。

{
  "status": "tracked",
  "action": "closed"
}

{
  "status": "tracked",
  "github_action": "closed"
}

GET /review 的 Query Parameters 中 number 类型定义为 string，而 GET /api/review/:owner/:repo/:number/stream 的 Path Parameters 中 number 类型定义为 integer。同一概念在不同端点的类型定义不一致。建议统一为 `string (数字)` 并在说明中注明应传递数字的字符串表示（如 "42"），因为 HTTP 中路径和查询参数本质都是字符串。

GET /review:
| `number` | string | 可选，同上 |

GET /api/review/:owner/:repo/:number/stream:
| `number` | integer | PR 编号 |

统一为:
| `number` | string (数字) | PR 编号，应传递数字的字符串表示（如 "42"） |

SSE 流的 Request Headers 表格列出了 X-Accel-Buffering: no，但未解释其作用。这是 Nginx 特有的 header，用于禁用代理缓冲，对 SSE 流的实时传输至关重要。如果部署在 Nginx 反向代理后缺少此 header，SSE 事件会被缓冲导致无法实时推送。建议添加简短说明。

| `X-Accel-Buffering` | `no` |

| `X-Accel-Buffering` | `no` | (Nginx) 禁用代理缓冲，确保 SSE 流实时传输 |

架构文档中的 main.go 内部流程图使用纯 ASCII 艺术绘制，虽然在终端可读，但在 GitHub、GitLab 等平台上无法渲染，且维护修改时对齐困难。建议替换为 Mermaid 图表格式，这些平台原生支持渲染，可读性和可维护性都更好。

┌──────────────────────────────────────────────────────────┐
│              startReviewWorker                           │
│                                                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │ L0: Fetcher.Fetch() ─── GitHub API 并发拉取          │  │

```mermaid
graph TD
    A[startReviewWorker] --> B[L0: Fetcher.Fetch]
    B --> C[Small PR]
    B --> D[Large PR]
    C --> E[L1: ContextCollector]
    D --> E
    E --> F[L2: ReviewerAgent]
    F --> G[L3: ReportGenerator]
```

从 go.mod 中移除间接依赖 github.com/agent-infra/sandbox-sdk-go 是合理的清理操作。但 PR 中未包含 go.sum 文件的同步更新，如果该依赖存在传递性引用关系，移除后可能导致构建失败。建议在合并前执行 `go mod tidy` 和 `go build ./...` 验证模块完整性。

require (
	github.com/bytedance/gopkg v0.1.3 // indirect
	github.com/bytedance/sonic v1.15.0 // indirect
	github.com/bytedance/sonic/loader v0.5.0 // indirect

# 合并前执行以下命令验证:
go mod tidy
go build ./...
go test ./...
# 确认 go.sum 文件也包含在 PR 变更中

技术文档开头缺少 YAML Front Matter 元数据（标题、版本、维护者等），不利于文档工具解析和版本追踪。大型架构文档也缺少明确的结尾标记，不利于标识文档边界。建议补充标准化的文档元数据。

# PRism 架构文档

---
title: PRism 架构文档
description: PRism 系统的整体架构、模块划分和技术选型详解
version: 1.0.0
---

# PRism 架构文档

> **维护者**: PRism Team
> **最后更新**: 2024-01-XX
> **文档版本**: 1.0.0

标准的 Apache License 2.0 模板在附录中通常包含版权声明示例（如 Copyright [yyyy] [name of copyright owner]），供使用者填写。当前文件缺少这部分内容。虽然这不是强制性的，但遵循标准模板是更好的实践，也方便后续使用者快速填写版权信息。

+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/

+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0

OPENAI_BASE_URL 示例值使用了 `https://token-plan-cn.xiaomimimo.com/v1`，MODEL_NAME 使用了 `mimo-v2.5-pro`。这些特定服务商的具体值可能让用户误解为推荐或必需配置。建议使用更通用的占位符，让用户根据自己的实际情况填写。

OPENAI_BASE_URL=https://token-plan-cn.xiaomimimo.com/v1
OPENAI_API_KEY=sk-xxxxxxxxxxxxxxxxxxxx
MODEL_NAME=mimo-v2.5-pro

OPENAI_BASE_URL=https://api.openai.com/v1
OPENAI_API_KEY=sk-your-api-key
MODEL_NAME=gpt-4o