问题描述
当前 TUI 启动链中，安全模块存在重复初始化。
cmd/tui/main.go 在调用 prepareWorkspace(...) 之后，又额外调用了一次 initializeSecurity(...)。
但 prepareWorkspace(...) 的实现内部其实已经完成了安全初始化。
这不是一个立即导致错误的严重 bug，但说明启动生命周期职责尚未完全收束。
相关位置
第一次初始化：
internal/tui/bootstrap/setup.go:32internal/tui/bootstrap/setup.go:40
第二次初始化：
cmd/tui/main.go:91cmd/tui/main.go:96
当前行为
启动流程中大致是：
runWithDeps(...) 调用 prepareWorkspace(...)PrepareWorkspace(...) 内部调用 initializeSecurity(...)- 回到
runWithDeps(...) 后又再次调用 initializeSecurity(...)
影响
1. 启动职责边界不清晰
阅读代码时不容易判断：
- 工作区准备负责什么
- 安全初始化到底属于哪一层
- 后续类似初始化逻辑应该放在哪
2. 增加后续维护成本
当前初始化逻辑比较轻，所以重复执行暂时问题不大。
但如果未来安全模块增加：
- 缓存
- watcher
- 动态 reload
- 状态统计
- 日志埋点
那么重复初始化就可能演变成真实问题。
3. 测试与排障复杂度增加
启动阶段一旦出问题，不容易快速定位是哪个层级负责初始化。
预期行为
安全初始化应只有一个明确入口。
也就是说：
- 要么由
PrepareWorkspace(...) 负责
- 要么由
cmd/tui/main.go 负责
但不应两边同时做。
建议方案
推荐方案
把安全初始化职责统一收敛到 PrepareWorkspace(...)。
原因：
- 安全配置依赖工作区路径
PrepareWorkspace(...) 本身就承担“运行前环境准备”职责- 这样
main.go 可以只保留编排，不重复做底层初始化
对应改法
删除 cmd/tui/main.go 中重复的安全初始化逻辑，保留 PrepareWorkspace(...) 中的实现。
验收建议
修复后应满足：
- TUI 启动时安全模块只初始化一次
SetSecurityChecker(...) 仍然生效- 启动流程保持正常
- 相关测试通过
- 启动链职责更清晰
问题描述
当前 TUI 启动链中，安全模块存在重复初始化。
cmd/tui/main.go在调用prepareWorkspace(...)之后，又额外调用了一次initializeSecurity(...)。但
prepareWorkspace(...)的实现内部其实已经完成了安全初始化。这不是一个立即导致错误的严重 bug，但说明启动生命周期职责尚未完全收束。
相关位置
第一次初始化：
internal/tui/bootstrap/setup.go:32internal/tui/bootstrap/setup.go:40第二次初始化：
cmd/tui/main.go:91cmd/tui/main.go:96当前行为
启动流程中大致是：
runWithDeps(...)调用prepareWorkspace(...)PrepareWorkspace(...)内部调用initializeSecurity(...)runWithDeps(...)后又再次调用initializeSecurity(...)影响
1. 启动职责边界不清晰
阅读代码时不容易判断：
2. 增加后续维护成本
当前初始化逻辑比较轻，所以重复执行暂时问题不大。
但如果未来安全模块增加：
那么重复初始化就可能演变成真实问题。
3. 测试与排障复杂度增加
启动阶段一旦出问题，不容易快速定位是哪个层级负责初始化。
预期行为
安全初始化应只有一个明确入口。
也就是说：
PrepareWorkspace(...)负责cmd/tui/main.go负责但不应两边同时做。
建议方案
推荐方案
把安全初始化职责统一收敛到
PrepareWorkspace(...)。原因：
PrepareWorkspace(...)本身就承担“运行前环境准备”职责main.go可以只保留编排，不重复做底层初始化对应改法
删除
cmd/tui/main.go中重复的安全初始化逻辑，保留PrepareWorkspace(...)中的实现。验收建议
修复后应满足：
SetSecurityChecker(...)仍然生效