Engine messages hard-code CLI flag names; give them structured codes instead
維護者通常 1 天內回覆
還沒有人認領這個 Issue。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 35/100
- Issue 類型
- 重構
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
- 技術堆疊
- go
研究方向
Start by reading the message strings in internal/scan/runner.go, options.go, scope.go, verdict.go, internal/dns/resolver.go and transport.go, then inspect the rewrite tables in pkg/subenum/subenum.go and their tests. The issue allows either structured codes and settings or neutral setting names, but replacing message parsing across engine and front ends is broad design work. Done means no engine message hard-codes CLI flags and the CLI, TUI and pkg/subenum each present settings in their own terms without parsing message text.
由索引模型根據 Issue 內容生成。
描述
Why it matters
Engine messages name command-line flags ("Use -force to scan anyway", "set -max-queries or -force", "concurrency (-t) must be at least 1"). That reads well in the CLI but is wrong anywhere else: the TUI has form fields, and pkg/subenum callers have Config fields, not flags.
Evidence
- About 40 flag references in message strings across
internal/scan/runner.go,options.go,scope.go,verdict.goandinternal/dns/resolver.go,transport.go. pkg/subenumworks around this with a regexp that rewrites-flagto the matchingConfigfield (flagFieldsandfieldNamesinpkg/subenum/subenum.go). It works and is tested, but a new message that names a flag missing from the table gets through unchanged.
Suggested approach
- Give events and validation errors a structured part: a code such as
wildcard_refusedorcap_reached, and the setting involved (force,max_queries). Each front end then writes its own wording. - Or, as a smaller step, have the engine refer to settings by neutral names and let each front end map them.
- Delete the regexp rewrite in
pkg/subenumonce the engine no longer writes flag names.
Done when
No engine message hard-codes a CLI flag, and the CLI, the TUI and pkg/subenum each name settings in their own terms without parsing message text.
- 主要語言
- Go
- 星號
- 1
- 分支
- 1
- 平均合併
- 14 天 9 小時
- 30 天內合併 PR
- 1
環境準備
在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。
- 提供 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
TMHSDigital/subenum 的其他 Issue
-
documentation testing
難度 1/5 1-3 小時 新手友好度 88/100
TMHSDigital/subenum#103 ·
維護者通常 1 天內回覆
-
area: release bug
難度 2/5 1-3 小時 新手友好度 78/100
TMHSDigital/subenum#102 ·
維護者通常 1 天內回覆
-
community marketing priority: low
難度 5/5 一週以上 新手友好度 35/100
TMHSDigital/subenum#132 ·
維護者通常 1 天內回覆
-
feature priority: low
難度 5/5 一週以上 新手友好度 35/100
TMHSDigital/subenum#131 ·
維護者通常 1 天內回覆
-
documentation marketing priority: medium
難度 5/5 一週以上 新手友好度 25/100
TMHSDigital/subenum#127 ·
維護者通常 1 天內回覆
查看 TMHSDigital/subenum 的全部 Issue
相似的 Issue
-
automation models
難度 2/5 1-3 小時 新手友好度 75/100
維護者通常 1 天內回覆
-
bug llm-stack needs-triage
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
-
Alert email subjects don't identify the host — same container on multiple hosts, identical subjects未關閉
難度 2/5 1-3 小時 新手友好度 74/100
維護者通常 1 天內回覆
-
P3 Type: Bug
難度 2/5 1-3 小時 新手友好度 76/100
維護者通常 2 天內回覆
-
needs-area needs-kind needs-priority needs-status needs-triage
難度 2/5 1 小時以內 新手友好度 85/100
cncf/automation#736 ·
維護者通常 1 天內回覆