fix(feedback): refine rules for managing active OpenSpec changes and feedback integration

Author: gqcn

.agents/skills/lina-feedback/SKILL.md

@@ -25,9 +25,8 @@ compatibility: 依赖 openspec CLI、lina-e2e 技能、lina-review 技能。
 ### 1. 确定目标变更
 
 **关键规则：**
-1. 始终追加到现有的活跃变更中。仅在不存在活跃变更时才创建新变更。
+1. 根据反馈内容是与当前活跃迭代的相关性，评估是否追加到当前活跃迭代中，还是新建迭代跟进。
 2. **活跃变更**是指仍直接存在于 `openspec/changes/` 下、且**未被移入** `openspec/changes/archive/` 的变更目录。不要将 `status: complete`、所有任务已勾选或其他完成信号视为"非活跃"，除非实际已归档。
-3. 无论反馈内容是否与当前活跃迭代的主要功能相关，都必须追加到当前活跃迭代中。确保所有变更在单个变更记录中统一管理和归档。
 
 ```bash
 openspec list --json

AGENTS.md

@@ -139,7 +139,7 @@ pnpm report            # 查看 HTML 报告
 **关键规则**：
 - 只有在`openspec`工具安装时才启用`openspec`执行流程，包括`/opsx:explore`、`/opsx:propose`、`/opsx:apply`和`/opsx:archive`等斜杠指令，以及相关的技能调用和文档生成；如果未安装`openspec`工具，则不启用这些功能，用户需要手动维护变更文档和执行流程。
 - **活跃`OpenSpec`变更的判定以是否归档为准**：凡是仍位于`openspec/changes/`根目录下、且**未移动到**`openspec/changes/archive/`中的变更目录，都属于活跃变更；**即便该变更已经完成了全部任务、`openspec list --json`中显示为`status: complete`，只要尚未执行归档，仍然必须视为活跃变更**。
-- 当用户报告问题缺陷/改进建议时（无论中文或英文），如果当前项目存在活跃的`OpenSpec`变更，那么必须调用`lina-feedback`技能。**在用户未明确要求新建变更的前提下，无论反馈内容是否与当前活跃迭代的主要功能相关，都必须追加到当前活跃迭代中**，便于统一管理和归档。
+- 当用户报告问题缺陷/改进建议时（无论中文或英文），如果当前项目存在活跃的`OpenSpec`变更，那么必须调用`lina-feedback`技能。
 - 审查技能`/lina-review`自动在以下节点触发：`/opsx:apply`任务完成后、`/opsx:feedback`任务完成后、`/opsx:archive`归档前。
 - 在执行任务时，如果存在适合通过`subagent`并行推进且能够明确提升执行效率的场景，必须优先评估并采用`subagent`协作方式执行，以降低上下文窗口溢出的风险；仅在任务强依赖串行上下文、拆分成本过高或引入明显协作风险时，才可不使用`subagent`。
 - **i18n持续治理要求**：所有功能改动都必须评估对`i18n`的影响面，包括新增功能、修改现有功能、删除功能、调整菜单/路由/按钮/表单/表格/提示文案、接口文档、插件清单与初始化资源等场景；在方案设计、任务拆分、代码实现、测试和审查中必须明确判断相关`i18n JSON`翻译内容是否需要新增、修改或删除，并同步维护前端运行时语言包、宿主/插件运行时`manifest/i18n`资源以及`apidoc i18n JSON`等对应资源，避免硬编码文案、遗漏翻译键或保留无效/过期翻译内容；若本次功能改动确认不影响`i18n`资源，也必须在任务执行或审查结论中明确记录该判断。新增内置语言必须通过新增对应`manifest/i18n/<locale>/*.json`、`manifest/i18n/<locale>/apidoc/**/*.json`资源以及默认配置文件中的`i18n.locales`元数据完成，禁止为了注册语言而修改后端`Go`枚举、宿主`SQL seed`或前端`TypeScript`语言清单；`i18n.enabled=false`时前端必须隐藏语言切换并按`i18n.default`展示。运行时翻译包缓存失效必须传入显式`scope`，按语言、扇区、插件或业务内容范围精细失效，禁止在普通业务路径中无理由清空所有语言和所有扇区。