chore: update ai-review findings [ai-review-bot][failure]
This commit is contained in:
@@ -0,0 +1,14 @@
|
||||
# Triage Findings
|
||||
|
||||
When the task is to triage review findings, follow this workflow:
|
||||
|
||||
1. Merge all findings into one list.
|
||||
2. Remove duplicates.
|
||||
3. Sort by severity: `critical` -> `warning` -> `info`.
|
||||
4. Renumber from 1 after sorting.
|
||||
5. Fix real issues with the smallest safe change.
|
||||
6. Add false positives to `.gitea/ai-review/exclusions.json`, preserving the original wording, language, and semantics as much as possible.
|
||||
7. Add or update tests when behavior changes.
|
||||
8. Re-check the issue after each fix.
|
||||
|
||||
Use the repo-local `triage-findings` skill for the same workflow when running in Codex.
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: triage-findings
|
||||
description: Triage findings, fix real issues, and exclude false positives.
|
||||
---
|
||||
|
||||
# Triage Findings
|
||||
|
||||
## Use
|
||||
|
||||
直接輸入:`triage-findings 問題原始檔(文字或截圖)`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Merge all findings.
|
||||
2. Sort by severity:
|
||||
- critical
|
||||
- warning
|
||||
- info
|
||||
3. Renumber from 1.
|
||||
4. Fix real issues.
|
||||
5. Put false positives into `.gitea/ai-review/exclusions.json`, preserving the original wording, language, and semantics as much as possible.
|
||||
6. Add tests when behavior changes.
|
||||
|
||||
## Output Rules
|
||||
|
||||
- Keep the final list short.
|
||||
- Keep numbering contiguous.
|
||||
- Preserve file path, location, and fix.
|
||||
- When writing exclusions, prefer the original issue text over paraphrased rewrites.
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
name: triage-findings
|
||||
description: Merge code-review findings, sort and renumber them by severity, resolve real issues, and move false positives into exclusions.
|
||||
---
|
||||
|
||||
# Triage Findings
|
||||
|
||||
## When To Use
|
||||
|
||||
Use this skill when you receive multiple review findings, screenshots, comments, or issue lists that need to become one final triaged list.
|
||||
It is also used when some findings are false positives and should be moved into the exclusions list.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Collect all findings into one list.
|
||||
2. Merge duplicates into a single finding when they describe the same issue.
|
||||
3. Sort the final list by severity:
|
||||
- critical
|
||||
- warning
|
||||
- info
|
||||
4. Renumber the sorted list from 1 upward.
|
||||
5. Rewrite each finding concisely so the final list reads cleanly and consistently.
|
||||
6. If a finding is a false positive, do not keep it in the final list.
|
||||
7. Add false positives to the exclusions list using the existing schema in the repo or task context, and preserve the original finding wording as much as possible, including language and semantics.
|
||||
|
||||
## Resolution Flow
|
||||
|
||||
After the list is merged and ordered, resolve the remaining findings one by one.
|
||||
|
||||
1. Start from the highest severity item.
|
||||
2. Identify the root cause in the relevant file or context.
|
||||
3. Apply the smallest safe change that fixes the issue.
|
||||
4. Add or update tests when behavior changes.
|
||||
5. Re-check the issue after the change.
|
||||
6. If the item is confirmed false positive, move it to exclusions instead of changing code.
|
||||
7. Continue until the list is either fixed or explicitly excluded.
|
||||
|
||||
## Output Rules
|
||||
|
||||
- Keep the final findings list in severity order, then by any stable secondary order needed to make it readable.
|
||||
- Keep numbering contiguous after filtering and merging.
|
||||
- Preserve useful details like file path, location, and suggested fix.
|
||||
- Keep exclusions entries minimal and consistent with the project schema.
|
||||
- When writing exclusions, prefer the original issue text and language; only paraphrase if needed to fit the schema.
|
||||
- If the source already provides a severity or title, keep it unless it conflicts with the final ordering.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Triage Findings"
|
||||
short_description: "Triage, sort, fix, and exclude review findings"
|
||||
default_prompt: "Use $triage-findings to merge review findings, sort and renumber them by severity, resolve real issues one by one, and add false positives to exclusions."
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
name: triage-findings
|
||||
description: Triage findings, fix real issues, and exclude false positives.
|
||||
---
|
||||
|
||||
# Triage Findings
|
||||
|
||||
## Use
|
||||
|
||||
直接輸入:`triage-findings 問題原始檔(文字或截圖)`
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Merge all findings.
|
||||
2. Sort by severity:
|
||||
- critical
|
||||
- warning
|
||||
- info
|
||||
3. Renumber from 1.
|
||||
4. Fix real issues.
|
||||
5. Put false positives into `.gitea/ai-review/exclusions.json`, preserving the original wording, language, and semantics as much as possible.
|
||||
6. Add tests when behavior changes.
|
||||
|
||||
## Output Rules
|
||||
|
||||
- Keep the final list short.
|
||||
- Keep numbering contiguous.
|
||||
- Preserve file path, location, and fix.
|
||||
- When writing exclusions, prefer the original issue text over paraphrased rewrites.
|
||||
@@ -0,0 +1,93 @@
|
||||
[
|
||||
{
|
||||
"level": "critical",
|
||||
"role": "Aria",
|
||||
"location": "Dockerfile",
|
||||
"suggestion": "檔案末尾應包含一個空行,以符合 POSIX 規範並避免工具處理問題。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "critical",
|
||||
"role": "Rex",
|
||||
"location": "entrypoint.sh:82",
|
||||
"suggestion": "移除 `dotnet nuget push` 命令中的 `--allow-insecure-connections` 旗標。透過不安全的 HTTP 連線傳輸 `RUNNER_TOKEN` 等敏感資訊會使其容易被竊聽(中間人攻擊)。請確保您的 NuGet 來源 (`NUGET_SOURCE`) 使用 HTTPS。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "critical",
|
||||
"role": "Maya",
|
||||
"location": "entrypoint.sh:88",
|
||||
"suggestion": "目前的邏輯 `nuget_package=\"${nuget_packages[0]}\"` 只會推送找到的第一個 `.nupkg` 檔案。如果發佈成品中包含多個 `.nupkg` 檔案,這將導致其他套件未被推送,與舊版行為(推送所有符合的套件)不符。請明確定義預期行為:如果預期只會有一個,請在找到多個時拋出錯誤;如果預期可能有多個,請修改為迴圈推送所有找到的 `.nupkg` 檔案。務必為此情境新增測試案例。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Zara",
|
||||
"location": "Dockerfile:10",
|
||||
"suggestion": "在 `apt-get install` 命令中加入 `--no-install-recommends` 參數是一個很好的優化,它能減少安裝不必要的推薦套件,進而縮小 Docker 映像檔的體積。較小的映像檔能加快建置、推送與拉取的速度,並節省儲存空間。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Rex",
|
||||
"location": "entrypoint.sh:20",
|
||||
"suggestion": "在 `require_value` 函數中,`printf '%s=%s\\n' \"$name\" \"$value\"` 會將所有傳入的變數名稱及其值印出。這可能導致敏感資訊(例如 `RUNNER_TOKEN`)洩漏到標準輸出或日誌中。建議對敏感變數進行遮蔽處理,或避免將其值印出。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Rex",
|
||||
"location": "entrypoint.sh:65",
|
||||
"suggestion": "使用 `unzip \"$release_name\"` 解壓縮從外部來源下載的檔案時,存在 Zip Slip 漏洞的風險。惡意壓縮檔可能包含路徑遍歷(path traversal)的檔案名稱(例如 `../../etc/passwd`),導致檔案被解壓縮到預期目錄之外。建議在解壓縮前對壓縮檔內容進行更嚴格的驗證,或使用更安全的解壓縮機制來明確防範此類攻擊。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Maya",
|
||||
"location": "entrypoint.sh:28-34",
|
||||
"suggestion": "新增了 `require_index` 函數來驗證 `RELEASE_INDEX` 必須是非負整數。這是一個很好的改進,但需要為此新增測試案例,例如傳入非數字字串或負數,確保腳本能正確地捕捉錯誤並退出。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "warning",
|
||||
"role": "Maya",
|
||||
"location": "entrypoint.sh:83-87",
|
||||
"suggestion": "新增了檢查解壓縮後是否找到 `.nupkg` 檔案的邏輯。這是一個重要的邊界條件處理,請為此新增測試案例,確保當成品中不包含 `.nupkg` 檔案時,腳本能正確地報錯並退出。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Zara",
|
||||
"location": "entrypoint.sh:3",
|
||||
"suggestion": "使用 `set -Eeuo pipefail` 是一個良好的 Shell 腳本實踐。它能確保腳本在遇到錯誤時立即終止 (`-e`)、未定義變數時報錯 (`-u`),並在管道命令中捕捉錯誤 (`-o pipefail`)。這提升了腳本的健壯性和可靠性,間接避免因錯誤導致的資源浪費。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Zara",
|
||||
"location": "entrypoint.sh:40",
|
||||
"suggestion": "在 `curl` 命令中加入 `-f` (fail fast) 參數,可以在 HTTP 錯誤時立即終止腳本,避免處理無效資料,提高腳本的穩定性。同時,`-L` (follow redirects) 參數確保能正確處理重定向,提升可靠性。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Zara",
|
||||
"location": "entrypoint.sh:54",
|
||||
"suggestion": "在 `unzip` 命令中使用 `-q` (quiet) 參數可以抑制詳細輸出,減少控制台 I/O,使日誌更簡潔。這是一個輕微的效能優化和日誌清理。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Aria",
|
||||
"location": "entrypoint.sh",
|
||||
"suggestion": "腳本內部變數從 `UPPER_SNAKE_CASE` (例如 `RELEASE_HEADER`) 變更為 `snake_case` (例如 `release_header`),這與 shell 腳本的常見慣例更一致,有助於區分環境變數和內部變數。此為風格改善。",
|
||||
"is_new": true
|
||||
},
|
||||
{
|
||||
"level": "info",
|
||||
"role": "Maya",
|
||||
"location": "entrypoint.sh",
|
||||
"suggestion": "此腳本經過重構後,錯誤處理和參數驗證變得更加健壯(例如使用 `set -Eeuo pipefail` 和自定義驗證函數)。為了確保這些改進的穩定性,建議導入一個輕量級的 shell 腳本測試框架(如 `bats` 或 `shunit2`),為所有關鍵函數和端到端流程編寫單元測試和整合測試,以覆蓋各種成功和失敗情境。",
|
||||
"is_new": true
|
||||
}
|
||||
]
|
||||
@@ -0,0 +1,14 @@
|
||||
# Triage Findings
|
||||
|
||||
Use the triage-finding workflow for review issue lists:
|
||||
|
||||
1. Merge findings into one list.
|
||||
2. Remove duplicates.
|
||||
3. Sort by severity: `critical` -> `warning` -> `info`.
|
||||
4. Renumber from 1.
|
||||
5. Fix real issues with the smallest safe change.
|
||||
6. Put false positives into `.gitea/ai-review/exclusions.json`, preserving the original wording, language, and semantics as much as possible.
|
||||
7. Add or update tests when behavior changes.
|
||||
8. Re-check after each fix.
|
||||
|
||||
The full reusable skill lives in `.claude/skills/triage-findings/SKILL.md`.
|
||||
@@ -0,0 +1,14 @@
|
||||
# Triage Findings
|
||||
|
||||
Use the triage-finding workflow for review issue lists:
|
||||
|
||||
1. Merge findings into one list.
|
||||
2. Remove duplicates.
|
||||
3. Sort by severity: `critical` -> `warning` -> `info`.
|
||||
4. Renumber from 1.
|
||||
5. Fix real issues with the smallest safe change.
|
||||
6. Put false positives into `.gitea/ai-review/exclusions.json`, preserving the original wording, language, and semantics as much as possible.
|
||||
7. Add or update tests when behavior changes.
|
||||
8. Re-check after each fix.
|
||||
|
||||
The reusable skill lives in `.gemini/skills/triage-findings/SKILL.md`.
|
||||
@@ -0,0 +1,16 @@
|
||||
# Triage Findings
|
||||
|
||||
When the task is to triage review findings, follow this workflow:
|
||||
|
||||
1. Merge all findings into one list.
|
||||
2. Remove duplicates.
|
||||
3. Sort by severity: `critical` -> `warning` -> `info`.
|
||||
4. Renumber from 1 after sorting.
|
||||
5. Fix real issues with the smallest safe change.
|
||||
6. Add false positives to `.gitea/ai-review/exclusions.json`, preserving the original wording, language, and semantics as much as possible.
|
||||
7. Add or update tests when behavior changes.
|
||||
8. Re-check the issue after each fix.
|
||||
|
||||
Use the repo-local `triage-findings` skill for the same workflow when running in Codex.
|
||||
|
||||
Trigger it with `/triage-findings`.
|
||||
@@ -0,0 +1,14 @@
|
||||
# Triage Findings
|
||||
|
||||
Use the triage-finding workflow for review issue lists:
|
||||
|
||||
1. Merge findings into one list.
|
||||
2. Remove duplicates.
|
||||
3. Sort by severity: `critical` -> `warning` -> `info`.
|
||||
4. Renumber from 1.
|
||||
5. Fix real issues with the smallest safe change.
|
||||
6. Put false positives into `.gitea/ai-review/exclusions.json`, preserving the original wording, language, and semantics as much as possible.
|
||||
7. Add or update tests when behavior changes.
|
||||
8. Re-check after each fix.
|
||||
|
||||
The reusable skill lives in `.gemini/skills/triage-findings/SKILL.md`.
|
||||
Reference in New Issue
Block a user