## 用户目标

确认 TagLauncher 在“免费版 + Pro 解锁”首期中，是否需要把所有高级功能统一做成 `V` 图标锁定标识。

## 当前起点

- 已确认首期免费/Pro 功能边界与老用户自动 Pro 规则。
- 已收敛的设置页方案：
  - `Data` 页放完整 Pro 状态区
  - `Theme` 页放轻量镜像状态条
  - 主题卡只保留小型 `Pro / Preview` 状态槽
- 风格约束：原生 macOS、克制、非营销化，不做付费墙式视觉。

## 讨论结论

不建议把所有高级功能统一挂 `V` 图标锁。

更合适的做法是分层表达：

- 页面级：`Data` 页 Pro 状态区承担主要权益说明
- 次级页：`Theme` 页轻量镜像提醒
- 对象级：主题卡等对象保留小型 `Pro / Preview` 状态槽
- 控件级：只有少量当前不可操作的具体入口，才使用轻量锁定态

## 关键原因

### UI 视角

- `V` 不是天然的“锁定”语义，用户理解不如 `Pro` 文案或 `lock` 图标直接。
- 全局铺满 `V` 会让设置页更像付费墙，而不是系统设置。
- 会把页面级、卡片级、控件级三层状态混成一层，造成视觉噪音。

### 架构视角

- 全局 `V` 会额外引入一套新的权益可视化语义系统。
- 后续所有高级功能、主题、浅深色、hover/disabled 状态都要跟这套语义耦合，维护成本上升。

### 代码评审视角

- 真正复杂点不在“加图标”，而在一致性：位置、间距、颜色、禁用态、主题态、文案共存都会变成长期维护点。
- 现有 `Pro / Preview / 锁定态` 已足够表达，不需要再叠一层 `V` 体系。

### QA 视角

- 全局 `V` 会显著扩大状态矩阵：免费/Pro、预览中/非预览、浅色/深色、多语种、可点击/禁用。
- 容易出现遗漏、错位、语义不一致，回归成本明显增加。

## 落地规则

后续实现按下面规则执行：

1. 不做全局 `V` 锁图标体系。
2. 需要表达付费权益时，优先使用 `Pro` 文本标识。
3. 需要表达“当前不可操作”时，才使用系统风格 `lock` + disabled 样式。
4. 不在分组标题、说明文案、整页所有高级项上重复挂标。

## 未决事项

- 如后续产品仍希望增强“高级功能识别度”，应单独讨论一版组件级标记规范，而不是直接上全局 `V`。