feat: 为每个控制器缓存任务勾选状态

[1204244136]

已实现：

• 每个标签页、每个任务按控制器名称独立缓存勾选状态，支持任意数量控制器。
• A→B→C→A 会分别恢复状态，不会继承“不支持任务”导致的假 false。
• 缓存随配置持久化，并支持标签页复制、关闭恢复和导入导出；分享协议保持 v1，新字段可选，兼容旧数据。
• 标签页的控制器/资源映射同步更新，不会跨标签页串状态。

Summary by Sourcery

为每个控制器添加任务启用状态的缓存，并在标签页和配置的导出/导入之间持久化该状态。

新功能：

• 为每个控制器分别跟踪各任务的启用状态，并在切换控制器时使用该状态。
• 在已保存的配置和标签页的导出/导入中包含每个控制器的任务启用状态，以在不同会话之间持久化。

增强：

• 在更新实例时保持选定的控制器和资源映射同步，避免跨标签页的状态泄漏。

Original summary in English

Summary by Sourcery

Add per-controller caching of task enabled state and persist it across tabs and config export/import.

New Features:

• Track each task’s enabled state separately for each controller and use it when switching controllers.
• Include per-controller task enabled state in saved configurations and tab export/import for persistence across sessions.

Enhancements:

• Keep selected controller and resource mappings in sync when updating instances to avoid cross-tab state leakage.

[sourcery-ai]

Hey - 我发现了 1 个问题，并给出了一些更高层次的反馈：

• 在 setSelectedController 中，const enabledByController = { ...task.enabledByController }; 会在 enabledByController 为 undefined 时抛出错误；可以考虑默认使用一个空对象（例如：const enabledByController = { ...(task.enabledByController ?? {}) };）。
• 在 generateConfig 和 buildTabConfigExportText 中类似的 ...t.enabledByController 展开操作，在旧配置中 enabledByController 不存在时也会报错；在展开前使用空值合并运算符作为回退，以保持兼容性。
• 将 enabledByController 与当前 controller 合并（添加 [controllerName]: enabled）的逻辑在多个位置重复；提取一个小的辅助函数来完成这个合并，可以减少配置持久化与运行时状态更新之间行为不一致的风险。

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `setSelectedController`, `const enabledByController = { ...task.enabledByController };` will throw if `enabledByController` is undefined; consider defaulting to an empty object (e.g. `const enabledByController = { ...(task.enabledByController ?? {}) };`).
- Similar `...t.enabledByController` spreads in `generateConfig` and `buildTabConfigExportText` will fail when `enabledByController` is absent on older configs; use a nullish coalescing fallback before spreading to keep compatibility.
- The logic to merge `enabledByController` with the current controller (adding `[controllerName]: enabled`) is repeated in several places; extracting a small helper for this merge would reduce the chance of diverging behavior between config persistence and runtime state updates.

## Individual Comments

### Comment 1
<location path="src/stores/appStore.ts" line_range="472-481" />
<code_context>
     updateInstance: (id, updates) =>
       set((state) => ({
         instances: state.instances.map((i) => (i.id === id ? { ...i, ...updates } : i)),
+        ...(updates.controllerName !== undefined && {
+          selectedController: {
+            ...state.selectedController,
+            [id]: updates.controllerName,
+          },
+        }),
+        ...(updates.resourceName !== undefined && {
+          selectedResource: {
+            ...state.selectedResource,
</code_context>
<issue_to_address>
**issue (bug_risk):** Updating `selectedController`/`selectedResource` only through `updateInstance` may diverge from `setSelectedController` / `setSelectedResource` behavior.

Currently, `updateInstance` keeps `selectedController`/`selectedResource` in sync only when changes go through it, but `setSelectedController` still updates only `instance.controllerName`. This creates two inconsistent paths for changing controllers while `state.selectedController` is treated as the source of truth (e.g., for `previousControllerName`). Please either route all controller changes through `updateInstance` or update `setSelectedController` to also maintain the `selectedController` map so both representations stay aligned.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

Original comment in English

Hey - I've found 1 issue, and left some high level feedback:

• In setSelectedController, const enabledByController = { ...task.enabledByController }; will throw if enabledByController is undefined; consider defaulting to an empty object (e.g. const enabledByController = { ...(task.enabledByController ?? {}) };).
• Similar ...t.enabledByController spreads in generateConfig and buildTabConfigExportText will fail when enabledByController is absent on older configs; use a nullish coalescing fallback before spreading to keep compatibility.
• The logic to merge enabledByController with the current controller (adding [controllerName]: enabled) is repeated in several places; extracting a small helper for this merge would reduce the chance of diverging behavior between config persistence and runtime state updates.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- In `setSelectedController`, `const enabledByController = { ...task.enabledByController };` will throw if `enabledByController` is undefined; consider defaulting to an empty object (e.g. `const enabledByController = { ...(task.enabledByController ?? {}) };`).
- Similar `...t.enabledByController` spreads in `generateConfig` and `buildTabConfigExportText` will fail when `enabledByController` is absent on older configs; use a nullish coalescing fallback before spreading to keep compatibility.
- The logic to merge `enabledByController` with the current controller (adding `[controllerName]: enabled`) is repeated in several places; extracting a small helper for this merge would reduce the chance of diverging behavior between config persistence and runtime state updates.

## Individual Comments

### Comment 1
<location path="src/stores/appStore.ts" line_range="472-481" />
<code_context>
     updateInstance: (id, updates) =>
       set((state) => ({
         instances: state.instances.map((i) => (i.id === id ? { ...i, ...updates } : i)),
+        ...(updates.controllerName !== undefined && {
+          selectedController: {
+            ...state.selectedController,
+            [id]: updates.controllerName,
+          },
+        }),
+        ...(updates.resourceName !== undefined && {
+          selectedResource: {
+            ...state.selectedResource,
</code_context>
<issue_to_address>
**issue (bug_risk):** Updating `selectedController`/`selectedResource` only through `updateInstance` may diverge from `setSelectedController` / `setSelectedResource` behavior.

Currently, `updateInstance` keeps `selectedController`/`selectedResource` in sync only when changes go through it, but `setSelectedController` still updates only `instance.controllerName`. This creates two inconsistent paths for changing controllers while `state.selectedController` is treated as the source of truth (e.g., for `previousControllerName`). Please either route all controller changes through `updateInstance` or update `setSelectedController` to also maintain the `selectedController` map so both representations stay aligned.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}