docs: add F-Stack dev-rule, issue-process, and info-search skills (zh/en)

Add three CodeBuddy skills covering mandatory development rules, the issue
analysis SOP, and information search, in both Chinese (docs/zh_cn/skills/) and
English (docs/skills/).

Author: jfb8856606

docs/skills/f-stack-dev-rule/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: f-stack-dev-rule
+description: Mandatory development rules for the F-Stack project (zero tolerance). Covers: shell operations must go through rm_tmp_file.sh / kill_process.sh / chmod_modify.sh scripts, make clean before full rebuild after code changes, local config.ini test values must not be committed, no real IPs in docs (use placeholders), English commit messages (1-3 sentences), English-only short comments in F-Stack code, minimal comments in lib/, multi-agent collaboration rules (write/review separation, bounce<=3, leader polling without early exit), no speculation without actual execution (code is authoritative), and all question/analysis/research tasks must use the f-stack-info-search skill. Use this skill for any development, debugging, testing, or commit task in the /data/workspace/f-stack workspace.
+---
+
+# F-Stack Mandatory Development Rules
+
+This skill is a collection of mandatory rules for all development tasks in the /data/workspace/f-stack workspace. Violating any of them causes the task to be bounced back for correction. Zero tolerance.
+
+## 1. Shell Operation Script Rules
+
+Direct invocation of rm / kill / chmod command families is forbidden. Always use the following scripts:
+
+### 1.1 Delete files -> /data/workspace/rm_tmp_file.sh
+
+- Single file: `/data/workspace/rm_tmp_file.sh /full/path/to/file`
+- Multiple files: `/data/workspace/rm_tmp_file.sh /path/a /path/b`
+- Directory: `/data/workspace/rm_tmp_file.sh /full/path/to/dir`
+- Trash location: `/tmp/.trash` (keeps the path prefix for traceability)
+- Permanent purge: `/data/workspace/rm_tmp_file.sh --purge <trash_path> [--older-than Nd] [--dry-run]` (purge whitelist is only /tmp/.trash, /data/.Trash-0/files, /data/.Trash-0/info)
+- Forbidden: direct `rm`, `rm -rf`, `find -delete`, or embedding rm inside bash snippets
+- Bulk deletion of *.o etc.: first collect absolute paths with `ls`/`find`, then pass them all to the script at once
+
+### 1.2 Stop processes -> /data/workspace/kill_process.sh
+
+- Single PID: `/data/workspace/kill_process.sh <pid>`
+- Multiple PIDs: `/data/workspace/kill_process.sh <pid1> <pid2>`
+- Forbidden: `kill`, `pkill`, `killall`, `kill -9`, `pgrep | xargs kill`, kill embedded in trap/cleanup, or any other form
+
+### 1.3 Change permissions -> /data/workspace/chmod_modify.sh
+
+- Usage: `/data/workspace/chmod_modify.sh <mode> <path1> <path2> ...` (mode is compatible with chmod(1), octal or symbolic)
+- Forbidden: direct `chmod`, `chmod -R`, `install -m`, `setfacl`, or any other form
+- Note: the script snapshots pre-change permissions to /tmp/.trash/, audits to /data/workspace/.chmod_audit.log, refuses high-risk paths, and warns on setuid/setgid bits
+
+### 1.4 General rules
+
+- make clean / make install and other build-system targets are build tool operations and may run directly
+- If a script lacks a needed feature (e.g. --reference=), extend the script first, then use it; no temporary bypasses allowed
+
+## 2. Build Rules
+
+- After modifying any .c/.h file, run `make clean` (or an equivalent full-clean target) before a full rebuild; incremental builds are forbidden
+- Header changes affect every translation unit that includes them; clean is required even for a single-file change
+- Build verification is only valid with a clean build; a passing incremental build is not evidence
+- After modifying a common header, verify every file that includes it still compiles; a full make with no errors is required before a PR
+- Two known local build pitfalls and their workarounds:
+  - The IDE-injected safe-delete hook blocks the rm inside make clean: use `PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin" make clean`
+  - `make -j16` races with machine_includes: run `make machine_includes` first, then `make -j16`
+- Baseline reference: lib builds with error 0 / warning 51 (existing baseline; new changes must not add warnings)
+
+## 3. config.ini Rules
+
+- For config.ini and similar committed config files, only changes directly related to the current feature may be committed
+- Never commit local test/debug environment tweaks: lcore_mask, vlan_filter, idle_sleep, real local IPs in [portN], temporary perf-tuning values, etc.
+- Always review `git diff` item by item before `git add config.ini`
+- Never restore local test values with `git checkout config.ini` (local config is required for local runs and must be kept)
+- Correct approach: do not select config.ini in git add; leave local test values in the unstaged area
+
+## 4. No Real IPs in Docs
+
+- Never record real IPs of the local runtime environment in any document (docs, README, spec, test reports, execution logs, commit messages, PR comments, etc.)
+- Use descriptive placeholders: `<DPDK_NIC_IP>`, `<DPDK_NIC_IPV6>`, `<KERNEL_NIC_IP>`, `<CLIENT_IP>`, `<CLIENT_IPV6>`, `<GATEWAY_IP>`, `<GATEWAY_IPV6>`, `<BROADCAST_IP>`, `<NETWORK_PREFIX>`, `<VIP_IPV6>`, `<BACKEND_IPV6>`, etc.
+- Generic forms (e.g. 9.134.x) are allowed; complete real addresses are forbidden
+- `127.0.0.1` and `fe80::` link-local addresses may be written
+
+## 5. Commit Rules
+
+- Commit messages are always in English, 1-3 short sentences, no long essays
+- Local config.ini test values must not be committed (see section 3)
+- Fixing an accidental commit uses forward-fix (a new commit to roll back), never rewriting history
+
+## 6. Code Comment Language Rules
+
+- F-Stack project (/data/workspace/f-stack, including all code files under lib/, freebsd/, example/, tests/, etc.): comments and git commit messages must use short English; Chinese is forbidden
+- Documentation files (docs/*.md, Chinese spec docs) are exempt and follow the required document language
+
+## 7. Minimal Comments in lib/
+
+- Only add comments where truly necessary: public interface contracts (e.g. ff_api.h), config item meanings (e.g. config.ini), and genuinely complex/non-obvious algorithms or edge handling
+- Never comment self-evident code (simple assignments, obvious branches, self-explanatory calls)
+- Even for complex logic, keep comments concise; prefer clear naming and structure for self-explanatory code
+
+## 8. Multi-Agent Collaboration Rules
+
+Applies to harness-engineering + multi-agent (agent team / spec-driven) tasks:
+
+- **Leader must not exit early**: the leader must not end the task before every sub-agent reports its final result; actively poll and wait
+- **Sub-agent timeout detection**: no unbounded waiting; side-channel probing (reading written files, git status, artifacts) takes priority over message probing
+- **Write/review separation**: writing code/docs and reviewing must be done by different agents; the leader must never write and review its own work; pure research/probing/summarizing single-role tasks may be done by the leader
+- **bounce<=3**: any stage-gate failure must bounce back to the previous step for a fix, never ship with known failures; after 3 bounces on one step, stop immediately and escalate to a human decision
+- **Failure fallback**: on sub-agent timeout/stall/verdict conflict, the leader may take over or spawn a new agent to redo it, without violating write/review separation
+
+## 9. No Speculation Rules
+
+- All actions must actually be executed; never give results based on guesswork without execution
+- Cross-verify code/docs/external data sources; where they conflict, the actual code is authoritative
+- Items that cannot be statically verified or where the environment is insufficient must be honestly marked "unverified/not executed"; never assert PASS by assumption
+
+## 10. Information Search Rules
+
+- All question/analysis/research tasks must use the **f-stack-info-search** skill to search for information
+- Coverage: issue analysis, bug location, feature research, information gathering before design, technical Q&A, and any other scenario requiring research
+- Follow the five parts of f-stack-info-search: architecture docs and knowledge graph -> commit history -> related issues/PRs -> public resources -> internal/external websites, blogs, WeChat articles, etc.
+- Cross-validation: converge evidence from internal docs + external resources + actual code/testing; where they conflict, the actual code is authoritative
+- Never answer or conclude based on guesswork without searching
+
+## 11. Runtime Test Environment
+
+- This machine has two NICs: the DPDK-exclusive NIC and eth1 are different cards
+- Testing DPDK NIC programs: access the DPDK-managed NIC on this machine from the peer via `ssh f-stack-client` (use the `<DPDK_NIC_IP>` placeholder)
+- Testing the kernel stack on this machine: use 127.0.0.1 on lo
+- Stop processes via kill_process.sh, clean temp files via rm_tmp_file.sh, restore config.ini temp test values after testing, and never commit them

docs/skills/f-stack-info-search/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: f-stack-info-search
+description: F-Stack information search skill. Use when gathering evidence for issue analysis, bug location, or feature research in the F-Stack/f-stack repository. Contains five parts: check project architecture docs and knowledge graph (three-layer architecture docs LAYER1/2/3 and KNOWLEDGE_GRAPH_WIKI under docs/), check commit history (local git log search for fixing commits + DPDK upstream), check related Issues and PRs (first check the local issue analysis archives docs/f-stack-issue-ana.md and docs/zh_cn/f-stack-issue-ana.md, then gh search issues/prs + DPDK Patchwork), check public resources (DPDK Bugzilla/Patchwork/inbox.dpdk.org/web search), and internal/external information search for general analysis and research tasks (tech blogs/WeChat articles/tech communities/internal knowledge bases/iWiki, bilingual keyword construction and three-way evidence convergence). Invoked by the search step of the f-stack-issue-process skill; can also be used standalone. Trigger words: check commit history, search for information, check related issues, check public resources, git log search, gh search, architecture docs, knowledge graph, research information.
+---
+
+# F-Stack Information Search Skill
+
+Gather evidence for F-Stack issue analysis, bug location, and feature research. Invoked by the search step of the f-stack-issue-process skill; can also be used standalone.
+
+## Environment Preparation
+
+- GitHub Token configured (GH_TOKEN environment variable)
+- Official F-Stack repository cloned to /data/workspace/f-stack
+- gh CLI installed
+
+## Part 1: Check Architecture Docs and Knowledge Graph
+
+Before searching code, first consult f-stack's existing three-layer architecture docs and knowledge graph (`/data/workspace/f-stack/docs/`) to quickly locate the layers, modules, interfaces, and functions involved, narrowing the later search scope.
+
+Three-layer architecture docs (bilingual, identical content):
+
+- Layer1 system overview: `01-LAYER1-ARCHITECTURE.md` (Chinese) / `F-Stack_Architecture_Layer1_System_Overview.md` (English)
+- Layer2 interface specification: `02-LAYER2-INTERFACES.md` (Chinese) / `F-Stack_Architecture_Layer2_Interface_Specification.md` (English)
+- Layer3 function index: `03-LAYER3-FUNCTIONS.md` (Chinese) / `F-Stack_Architecture_Layer3_Function_Index.md` (English)
+
+Knowledge graph:
+
+- `KNOWLEDGE_GRAPH_WIKI.md`: knowledge graph wiki
+- `F-Stack_Knowledge_Base_Summary.md`: knowledge base overview
+
+Usage:
+
+- Locate the involved layers and components (e.g. protocol stack layer, DPDK abstraction layer, interface layer) by keyword/module name in the architecture docs
+- Use the knowledge graph to locate related code paths and functions, then narrow the git log / gh search scope accordingly
+- The Chinese and English content is identical; consult either language
+
+## Part 2: Check Commit History
+
+Search for related fixes in the local F-Stack repository.
+
+```bash
+cd /data/workspace/f-stack
+
+# Search commit messages by keyword
+git log --all --oneline --grep='<keyword>'
+
+# Search change history by file path
+git log --all --oneline -- <file path>
+
+# Search for fixing commits
+git log --all --oneline --grep='fix' --grep='<keyword>' --all-match
+
+# View the details of a commit
+git show <commit-hash>
+```
+
+Also check f-stack's own modifications to DPDK (the local dpdk/ directory is a plain directory inside the f-stack repository with **no DPDK upstream commit history**; git log can only find f-stack's own few modifications):
+
+```bash
+# f-stack's own modifications to dpdk/ (not upstream commits)
+git log --all --oneline -- dpdk/
+git show <commit-hash>
+```
+
+Checking DPDK upstream fixes must go through external channels (no upstream history locally):
+
+```bash
+# Search fixing commits in the official DPDK repository
+gh search commits '<keyword>' -R DPDK/dpdk --limit 20
+```
+
+Or use the DPDK Patchwork API (see Part 3), DPDK Bugzilla/mailing lists (see Part 4).
+
+Points of interest:
+
+- Whether DPDK upstream has fixing commits (Fixes/fix/patch) after the version mentioned in the issue
+- Whether the fix has been backported to the version in use (F-Stack currently uses DPDK 24.11.6)
+- Whether f-stack's dpdk/ has a corresponding local patch or a missed port
+
+## Part 3: Check Related Issues and PRs
+
+First check the local issue analysis archives (highest priority, avoid re-analyzing):
+
+- Chinese: docs/zh_cn/f-stack-issue-ana.md
+- English: docs/f-stack-issue-ana.md
+
+When looking for similar issues, first search these two archives for existing analysis records (issue number, keyword, error symptom). If found, cite the existing conclusion directly; if not, analyze and supplement. The Chinese and English archives stay in sync.
+
+```bash
+export GH_TOKEN='<token>'
+
+# Search related issues (open + closed)
+gh search issues '<keyword>' -R F-Stack/f-stack --limit 20
+
+# Search related PRs (especially merged ones)
+gh search prs '<keyword>' -R F-Stack/f-stack --limit 20
+
+# View a specific PR
+gh pr view <NUMBER> -R F-Stack/f-stack
+
+# View a PR's diff
+gh pr diff <NUMBER> -R F-Stack/f-stack
+```
+
+DPDK upstream Patchwork (when tracking upstream patches):
+
+- API: `https://patches.dpdk.org/api/patches/?q=<keyword>`
+- Fetch with the WebFetch tool
+
+## Part 4: Check Public Resources
+
+Search the following sources by priority:
+
+1. DPDK Bugzilla: https://bugs.dpdk.org
+2. DPDK Patchwork: https://patches.dpdk.org
+3. DPDK mailing list archive: https://inbox.dpdk.org (prefer the API to avoid the Anubis bot)
+4. Web search: Stack Overflow, CSDN, GitHub global search
+
+Note: sites like lore.kernel.org may be blocked by the Anubis bot; prefer API endpoints or inbox.dpdk.org.
+
+## Part 5: Internal/External Information Search for General Analysis and Research Tasks
+
+For general tasks such as issue analysis, bug location, and feature research, after completing the previous four parts, further search internal and external resources such as tech websites, blogs, and WeChat articles for cross-validation and background.
+
+### 5.1 Search goals
+
+- Existing analysis and solutions for similar problems (pitfalls others hit, fix ideas)
+- Explanations and implementation details of related features (to understand the design intent)
+- Upstream/community discussion and handling of the problem
+- Industry best practices and performance data (for design reference)
+
+### 5.2 Search channels (by priority)
+
+1. External technical resources (web_search / web_fetch):
+   - GitHub issues / wiki / discussions (F-Stack, DPDK, FreeBSD upstream repositories)
+   - Tech blogs and personal sites (e.g. medium, dev.to, personal tech blogs)
+   - Tech communities (Stack Overflow, Server Fault, Unix & Linux SE, CSDN, Zhihu, Juejin, SegmentFault)
+   - WeChat official account articles (search on weixin.sogou.com, then web_fetch the article body)
+2. Internal knowledge bases (RAG_search, if enterprise knowledge bases are connected): search internal best practices, historical handling records, and internal component docs
+3. Tencent internal iWiki (if iWiki documents are involved, use the iwiki-doc skill to search docs, spaces, and directory trees on iwiki.woa.com)
+
+### 5.3 Keyword construction
+
+- Search in both Chinese and English, one round each; construct Chinese and English keywords separately
+- Combinations: `<tech term> + <version>` (e.g. "DPDK 24.11 RSS hash"), `<exact error message>` (pasting the original log/error text gives the highest hit rate), `<function name> + <symptom>` (e.g. "rte_thash_adjust_tuple misqueue"), `<issue title keyword> + fix/regression`
+- Add qualifiers: `site:github.com`, `site:stackoverflow.com`, `inurl:blog`, etc.
+- Mind version timeliness: prefer resources close in time to the version in use (F-Stack v2.0 / DPDK 24.11.6 / FreeBSD 15.0) to avoid outdated conclusions
+
+### 5.4 Cross-validation and evidence convergence
+
+- Three-way evidence convergence: internal docs + external resources + actual code/testing, mutually confirming
+- External conclusions must be checked against the local actual code; **where they conflict, the actual code is authoritative**
+- Mark external resources with source and publication time; conclusions from a single source are marked "only this source, not double-verified"
+- Honestly mark what cannot be verified as "unverified/not executed"; never speculate
+
+## Search Output Requirements
+
+- For each source, give the query terms and a summary of hits, with concrete links or commit hashes
+- Cross-validation: converge evidence from code/docs/external data sources; where they conflict, the actual code is authoritative
+- Honestly mark items that cannot be verified or where the environment is insufficient as "unverified/not executed"; never speculate
+- Never include real IPs in the output (use placeholders like `<DPDK_NIC_IP>`)