sensors-tag

标签查询入口。只封装当前已有的标签查找和标签详情能力，不承接分群、创建、更新、重新计算等能力。

职责

查找、筛选、消歧标签对象。
查看已确认标签的定义、数据类型、状态、规则摘要和规则可用性。
输出后续可复用的精确 name、display_name、data_type 和关键状态。
内部可使用标签 list/get 命令，但 reference 按用户任务组织，不按接口组织。

不适用场景

事件、属性、表、字段、枚举值解析，交给 sensors-metadata skill
趋势、漏斗、留存、分布等标准分析问题，交给 sensors-insight skill
看板、概览、书签查询，交给 sensors-dashboard skill
分群对象查询，交给 sensors-cohort skill
用户细查或 SQL 查询，交给 sensors-sql-query skill
创建、更新、删除标签，不在当前已封装能力范围内
触发 tag evaluate 的计算问题，不在当前 skill 范围内

核心边界

| 用户问题 | 归属 | |---|---| | 系统里有哪些标签？这个口语名称对应哪个精确对象？ | sensors-tag | | 这个标签的详情、状态、规则可用性是什么？ | sensors-tag | | 先列一批标签让我筛选，或按已知名称过滤 | sensors-tag | | 这个分群的详情、状态、结果可用性是什么？ | sensors-cohort | | 我想创建、修改、维护一个标签 | 当前不支持 | | 需要重新计算这个标签吗？ | 不在本 skill 范围内 |

名称不确定时先查找候选；多候选必须让用户确认。只有对象唯一确定后，才查看详情。

Iron Law（不可违反）

⛔ 只做标签查询，不触发 sensors tag evaluate
⛔ 不把"规则可用"和"已有有效结果"混为一谈（current_rule_available ≠ 有效结果）
⛔ 名称不确定时，先查候选；多候选必须让用户确认，禁止自行选择
⛔ tag get 返回空（未找到）时，直接告诉用户"未查到该名称对应的标签"，不得进入排查死循环（换参数重试、跨项目查找、转其它 skill 定位）
⛔ 不得把“查找候选”和“查看详情”混为一类
⛔ 不处理分群查询；分群交给 sensors-cohort
⛔ 不得伪造创建、更新、删除或重新计算结果

路由表

按意图加载对应 reference（按需读取，不必全部加载）：

| 用户任务 | 加载 reference | |---|---| | 查找、筛选、消歧标签对象 | references/finding-tags.md | | 查看已确认标签的定义、状态、规则和可用性 | references/inspecting-tags.md |

工作原则

先判断用户是在找标签，还是查看已确认标签详情。
标签名称不唯一时先查找候选，不直接查详情。
输出结果时保留后续可复用的精确标签名称和数据类型。
对命令参数有疑问时，运行 sensors <命令> --help 查看完整参数说明。

前置依赖

调用前依赖 sensors-context 提供 session_id 与 project_name
标签名称解析由本 skill 的查找 reference 完成
如果对话上下文里已经有精确 name，可直接进入查询
如果用户要查询分群，应切换到 sensors-cohort
如果用户要创建、更新、删除或触发计算，应明确说明当前 skill 未封装该能力

衔接点

标签精确名称可继续复用在后续查询中
若后续要做分析，可把已确认的标签对象交给下游分析链路使用
若后续要触发重新计算，应明确说明这是另一个能力边界