f-stack F-Stack Issue 分析处理标准操作流程（SOP）
适用范围：分析 F-Stack GitHub 仓库（F-Stack/f-stack）的 issue，判断状态并给出处理建议。
环境准备
- GitHub Token 已配置（GH_TOKEN 环境变量）
- F-Stack 官方仓库已 clone 至 /data/workspace/f-stack
- gh CLI 已安装
第一步：读 Issue 全文
必须完整获取 issue 原文及全部讨论，不可仅看标题。
export GH_TOKEN='<token>'
# 获取 issue 正文
gh issue view <NUMBER> -R F-Stack/f-stack
# 获取全部评论（API 方式，无截断）
gh api repos/F-Stack/f-stack/issues/<NUMBER>/comments --jq '.[] | {user: .user.login, created_at: .created_at, body: .body}'
记录以下信息：
- 报告者（author）
- F-Stack / DPDK 版本
- 错误现象（crash、性能、编译失败、功能异常等）
- 复现步骤或环境描述
- 已有讨论结论（维护者是否回复、是否有解决方案）
第二步：搜索资料
调用 f-stack-info-search 技能完成资料搜索，包含五部分：
- 查项目架构文档与知识图谱：docs/ 下三层架构文档（LAYER1/2/3）+ KNOWLEDGE_GRAPH_WIKI
- 查代码提交记录：本地 git log 搜索修复性提交 + DPDK 上游
- 查关联 Issue 和 PR：先查本地 issue 分析档案（docs/zh_cn/f-stack-issue-ana.md、docs/f-stack-issue-ana.md），再 gh search issues/prs + DPDK Patchwork
- 查公开资料：DPDK Bugzilla / Patchwork / inbox.dpdk.org / 外网搜索
- 常规分析调研任务的内外网资料搜索：技术博客 / 公众号 / 技术社区 / 内网知识库 / iWiki，中英双语关键词构造与三方证据收敛
搜索完成后回到本技能继续第三步综合判断。
第三步：综合判断
使用中文给出明确结论，格式如下：
结论模板
## Issue #<NUMBER> 分析结论
**标题:** <issue 标题>
**状态判断:** <以下之一>
### 情况一：已修复
- 结论: 已修复
- 修复 commit: <hash> (<commit message>)
- 修复版本: F-Stack v<x.y> / DPDK <版本>
- 是否已 backport: 是/否
- 建议操作: 可关闭，回复告知用户升级到 v<x.y> 即可
### 情况二：有上游 patch 未合入
- 结论: 有上游 patch 未合入
- Patch 链接: <URL>
- Patch 状态: Accepted / Under Review / Superseded
- 影响版本: DPDK 22.11 / 23.11 / 24.11 各 LTS 修复状态
- 建议操作: 等待合入 / 手动 cherry-pick
### 情况三：未修复
- 结论: 未修复
- 根因分析: <详细描述>
- 影响范围: <哪些版本/场景受影响>
- 修复方案: <建议的修复思路>
- 建议操作: 需要开发修复
### 情况四：有 Workaround
- 结论: 有 workaround
- Workaround 步骤: <具体操作>
- 是否需要根本修复: 是/否
- 建议操作: 回复告知 workaround，保持 issue open 等待根本修复
### 情况五：非 Bug（使用咨询/已过时/无法复现）
- 结论: 非 Bug / 已过时 / 无法复现
- 理由: <详细说明>
- 建议操作: 可关闭，回复说明原因
关键注意事项
不可自动操作 Issue
- 分析完成后，必须人工确认无误后才可以评论或关闭 issue
- 给出建议操作，但不直接执行
- 等待用户明确指令后再操作（评论、关闭、打标签等）
- 回复 issue 的评论都使用英文，不要@任何人，不要长篇大论分析，不要重复回复历史回复已有的内容，只说核心结论和关键步骤
区分问题归属
- F-Stack 自身问题: lib/ 目录下的代码、FreeBSD 移植层、ff_* API
- DPDK 上游问题: dpdk/ 目录下的代码、驱动、EAL 层
- 用户配置问题: config.ini、hugepage、NIC offload、ASLR 等
- 应用集成问题: Nginx/Redis 集成、多进程架构
DPDK 版本追踪
- F-Stack v2.0 → DPDK 24.11.6
- F-Stack v1.25 → DPDK 23.11.5
- F-Stack v1.24 → DPDK 22.11.6
- F-Stack v1.22.1 → DPDK 20.11.9
- F-Stack v1.21.x → DPDK 19.11.14
- 涉及 DPDK 版本时，明确 22.11 / 23.11 / 24.11 各 LTS 的修复状态
同步更新 issue 分析档案
- 每次提交回复或修改 issue 后，必须同步更新本地 issue 分析档案：
- 中文：docs/zh_cn/f-stack-issue-ana.md
- 英文：docs/f-stack-issue-ana.md
- 两份档案内容保持一致（中英对照），记录：issue 编号、标题、分析结论、处理动作（回复/关闭/修复 commit）
- 每次提交回复或修改 issue 后，必须同步更新本地 issue 分析档案：
编译修复规则
修复文件后，必须确保所有依赖该文件的其他文件也能正常编译
修改公共头文件后，需逐一验证所有 include 它的文件
PR 前必须执行完整 make 确认无 error
编译验证命令：
# F-Stack lib 编译验证 cd /data/workspace/f-stack/lib && make clean && make # ftdns-dev src 编译验证 cd /data/workspace/ftdns-dev/src && make clean && make
批量分析流程
当需要批量分析多个 issue 时：
# 1. 获取指定范围内所有 open issue
gh issue list -R F-Stack/f-stack --state open --limit 500 \
--json number,title,labels,createdAt,author \
--jq '[.[] | select(.number >= <START> and .number <= <END>)] | sort_by(.number)'
# 2. 逐个执行上述三步分析流程
# 3. 汇总分类报告，包含：
# - 总数统计
# - 按类型分类（Bug / 功能请求 / 使用咨询 / 编译问题）
# - 按状态分类（已修复 / 未修复 / 有 workaround / 过时）
# - 建议操作清单（哪些可关闭、哪些需修复、哪些需回复）
与开发规约的关系
issue 处理过程中若涉及代码修改，必须同时遵守 f-stack-dev-rule 技能的全部强制规约（rm/kill/chmod 脚本、make clean 编译、config.ini 不入库、文档禁真实 IP、代码注释英文、lib 最小注释等）。