@thinkingai/ae-cli 6.1.20 → 6.1.23

package/skills/ae-data-integration-helper/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: ae-data-integration-helper
-description: "Answers questions about ThinkingData SDK integration and usage, including the LogBus2 data import tool. Trigger words: 怎么接入 / 如何集成 / SDK / 埋点 / 报错 / 使用方式 / API / LogBus / tracking / integration / how to integrate / data import / データ連携 / インテグレーション / 트래킹 / 연동."
+description: "Answers questions about ThinkingAI SDK integration and usage, including the LogBus2 data import tool. Trigger words: 怎么接入 / 如何集成 / SDK / 埋点 / 报错 / 使用方式 / API / LogBus / tracking / integration / how to integrate / data import / データ連携 / インテグレーション / 트래킹 / 연동."
 ---
 
 # ae-data-integration-helper
@@ -16,12 +16,12 @@ description: "Answers questions about ThinkingData SDK integration and usage, in
 
 | 中文 | English | Notes |
 |------|---------|-------|
-| 埋点 / 数据上报 | Tracking / Data Ingestion | Sending event data to TE |
+| 埋点 / 数据上报 | Tracking / Data Ingestion | Sending event data to AE |
 | 用户识别规则 | User Identification Rule | distinct_id / account_id mapping |
 | 访客 ID | Visitor ID / Guest ID | Anonymous user before login |
 | 登录 ID | Login ID / Account ID | Identified user after login |
 | 预置属性 | Preset Property | `#device_id`, `#time`, `#ip`, etc. |
-| 系统字段 | System Field | TE built-in fields prefixed with `#` |
+| 系统字段 | System Field | AE built-in fields prefixed with `#` |
 | 事件格式 | Event Format | Event name + properties structure |
 | 属性类型 | Property Type | String / Number / Boolean / Date / Array |
 | 数据校验 | Data Validation | Verify event format & property types |
@@ -37,7 +37,7 @@ description: "Answers questions about ThinkingData SDK integration and usage, in
 | 数据加密 | Data Encryption | Encrypt event data before upload |
 | 时间校准 | Time Calibration | Sync device time with server time |
 | 多端上报 | Multi-platform Tracking | Report events from multiple clients/services |
-| 用户割裂 | User Fragmentation | Same user split into multiple TE user profiles |
+| 用户割裂 | User Fragmentation | Same user split into multiple AE user profiles |
 | 上报模式 | Upload Mode | Normal / Debug / Debug_Only |
 | LoggerConsumer | LoggerConsumer | Server SDK consumer that writes events to local log files |
 | BatchConsumer | BatchConsumer | Server SDK consumer that uploads events in batches |
@@ -62,7 +62,7 @@ Trigger when a user asks about:
 - **Configuration**: Debug mode / data validation / retry strategy
 - **Troubleshooting**: Upload failures / missing data / format errors
 
-**Do NOT trigger**: Inline Q&A within `ae-generate-tracking-plan` or `ae-generate-tracking-code` sessions (those skills have their own workflows). Offline local-file import (CSV / Excel / JSONL → AE) is owned by the `ae-data-integration` skill — route those requests there instead of answering with LogBus / RESTful guidance.
+**Do NOT trigger**: Inline Q&A within `ae-generate-tracking-plan` or `ae-generate-tracking-code` sessions (those skills have their own workflows). Offline local-file import (CSV / Excel / JSONL → AE) and Feishu sheet URL import are owned by the `ae-data-integration` skill — route those requests there instead of answering with LogBus / RESTful guidance.
 
 ## Workflow
 

package/skills/ae-data-integration-helper/references/android_sdk_faq.md

@@ -36,7 +36,7 @@ dependencies {
 
 # 初始化
 ## 推荐初始化位置
-- 建议在用户同意隐私协议后再进行 SDK 初始化，详见 ThinkingData 官方文档中的《合规指南》部分。
+- 建议在用户同意隐私协议后再进行 SDK 初始化，详见 ThinkingAI 官方文档中的《合规指南》部分。
 ```json
 // 根据隐私协议判断是否开启数据采集
 if (授权隐私政策) {
@@ -81,11 +81,11 @@ TDAnalytics.init(config);
 
 > 注意：
 > - 在正式上线时，建议避免使用 debug 或 debug_only 模式
-> - debug 模式下如果没有 TE 后台配置白名单会切换成 NORMAL 模式
+> - debug 模式下如果没有 AE 后台配置白名单会切换成 NORMAL 模式
 > - debug_only 不会自动切换成 NORMAL 模式
 
 # 上报策略
-- normal 模式默认 30 秒或者 30 条满足上报一次，TE 项目管理可以设置修改
+- normal 模式默认 30 秒或者 30 条满足上报一次，AE 项目管理可以设置修改
 - debug / debug_only 模式事件会立即上报
 - 手动调用 flush() 接口，会立即上报缓存数据
 - 自动采集事件会立刻上报

package/skills/ae-data-integration-helper/references/c_sdk_faq.md

@@ -203,7 +203,7 @@ int main(void) {
 
 #### **如何获取上报地址和APP_ID？**
 
-项目管理者可以在 TE 后台进入"项目管理 > 项目配置 > 接入配置"获取 `APPID` 与上报地址。
+项目管理者可以在 AE 后台进入"项目管理 > 项目配置 > 接入配置"获取 `APPID` 与上报地址。
 
 - 云服务环境：使用平台提供的 HTTPS 上报地址。
 - 私有化环境：建议为数据接入地址绑定域名并配置 HTTPS 证书。
@@ -241,7 +241,7 @@ int main(void) {
 | `push_url` | 数据上报地址 | 无 | 字符串 | 必填 |
 | `appid` | 项目 APPID | 无 | 字符串 | 必填 |
 | `timeout` | 请求超时时长 | `30` | 整数 | 单位秒 |
-| `device_id` | Debug 设备标识 | 无 | 字符串 | 需在 TE 后台配置同一设备 ID |
+| `device_id` | Debug 设备标识 | 无 | 字符串 | 需在 AE 后台配置同一设备 ID |
 | `debug_mode` | 是否入库 | `0` | `0` / `1` | `0` 表示入库，`1` 表示仅校验不入库 |
 
 # 三、常见问题
@@ -288,7 +288,7 @@ int main(void) {
 
 `ta_free()` 是 1.x 的旧函数名，v2 对应为 `td_free()`。在程序正常结束前调用 `td_free()`，随后调用 `td_consumer_free()`，确保 SDK 内部资源与缓存被正确释放。
 
-#### **在程序中调用了 `ta_track()` 或者 `ta_user_set()` 方法， 为什么在 TE 后台没有看到数据？**
+#### **在程序中调用了 `ta_track()` 或者 `ta_user_set()` 方法， 为什么在 AE 后台没有看到数据？**
 
 `ta_track()` / `ta_user_set()` 为旧版命名，v2 对应 `td_track()` / `td_user_set()`。排查顺序建议如下：
 

package/skills/ae-data-integration-helper/references/cocoscreator_sdk_faq.md

@@ -53,7 +53,7 @@ TDAnalytics.init(config);
 # Debug 模式
 ## debugMode 三种取值
 - none：Normal 模式
-- debug：数据在 TE Debug 模式中看到
+- debug：数据在 AE Debug 模式中看到
 - debugOnly：只校验，不入库
 
 # 自动采集事件

package/skills/ae-data-integration-helper/references/cpp_server_sdk_faq.md

@@ -202,11 +202,11 @@ Total Memory: 15.25GiB
 1. 使用LoggerConsumer + LogBus搭配进行数据上报
 2. batchSize参数不宜设置过大，可能会导致单次发送数据时间增加，会增加发生网络错误的概率
 
-批量实时地向 TE 服务器传输数据，不需要搭配传输工具。**在长时间网络中断情况下，有数据丢失的风险，不建议在正式环境中使用。优点在于使用简单无需搭配上报工具；缺点在于数据没有持久化存储，仅在内存中做缓存，如果网络不稳定缓存数据超过缓存区上限后会丢失数据。**
+批量实时地向 AE 服务器传输数据，不需要搭配传输工具。**在长时间网络中断情况下，有数据丢失的风险，不建议在正式环境中使用。优点在于使用简单无需搭配上报工具；缺点在于数据没有持久化存储，仅在内存中做缓存，如果网络不稳定缓存数据超过缓存区上限后会丢失数据。**
 
 #### **BatchConsumer 性能指标如何？适合在什么场景下使用？**
 
-BatchConsumer适合中小数据量，且日志上报服务器和TE集群内网打通时使用。
+BatchConsumer适合中小数据量，且日志上报服务器和AE集群内网打通时使用。
 
 #### **DebugConsumer 为什么在生产环境禁用？**
 
@@ -216,7 +216,7 @@ BatchConsumer适合中小数据量，且日志上报服务器和TE集群内网
 
 程序需要正常结束时调用，close()方法会将内存中的数据进行写入文件或发送。close() 函数会调用 flush() 上报或写入缓存的数据，并关闭和释放相应资源。一种常见的错误用法是在每次调用 flush() 后调用 close()，这样会导致下一次调用 flush() 时报错，除非每次对SDK重新初始化。
 
-#### **在程序中调用了 `track()` 或者 `user_set()` 方法， 为什么在 TE 后台没有看到数据？**
+#### **在程序中调用了 `track()` 或者 `user_set()` 方法， 为什么在 AE 后台没有看到数据？**
 
 请依次检查以下情况：
 

package/skills/ae-data-integration-helper/references/ios_sdk_faq.md

@@ -111,7 +111,7 @@ if (授权隐私政策) {
 - Keychain 持久化存储，卸载重装后不会改变
 
 ## #ip
-- TE 服务器获取 http 请求 header 中的 ip 信息
+- AE 服务器获取 http 请求 header 中的 ip 信息
 - 使用第三方 IP 库解析地理位置
 
 # 已知问题

package/skills/ae-data-integration-helper/references/java_sdk_faq.md

@@ -159,7 +159,7 @@ public class DebugExample {
 
 > 开启 Debug 模式需要两步：
 > 1. 在代码中使用 `TDDebugConsumer` 并传入 `DEBUG_DEVICE_ID`。
-> 2. 在 TE 后台"数据 > 埋点管理 > Debug 数据"中配置同一个 Debug 设备 ID。只有已配置的设备才能真正开启 Debug 模式。
+> 2. 在 AE 后台"数据 > 埋点管理 > Debug 数据"中配置同一个 Debug 设备 ID。只有已配置的设备才能真正开启 Debug 模式。
 
 # 二、工作原理
 
@@ -221,7 +221,7 @@ v3.x 对应实现为 `TDBatchConsumer`。事件先写入内存队列，满足批
 |------|------|--------|----------|------|
 | `serverUrl` | 数据接入地址 | 无 | 字符串 | 需要与项目配置匹配 |
 | `appId` | 项目 APP_ID | 无 | 字符串 | 可在项目配置页获取 |
-| `deviceId` | Debug 设备 ID | 无 | 字符串 | 需在 TE 后台配置为 Debug 设备 |
+| `deviceId` | Debug 设备 ID | 无 | 字符串 | 需在 AE 后台配置为 Debug 设备 |
 
 调试时建议同时打开 SDK 日志：
 
@@ -287,7 +287,7 @@ TDAnalytics.enableLog(true);
 
 在应用准备正常退出时调用。`close()` 会尝试将缓存中的数据继续刷盘或发送，是避免尾部数据丢失的必要步骤。建议在应用生命周期的关闭钩子中统一执行。
 
-#### **在程序中调用了 `track()` 或者 `userSet()` 方法， 为什么在 TE 后台没有看到数据？**
+#### **在程序中调用了 `track()` 或者 `userSet()` 方法， 为什么在 AE 后台没有看到数据？**
 
 请依次检查以下情况：
 

package/skills/ae-data-integration-helper/references/javascript_sdk_faq.md

@@ -70,7 +70,7 @@ ta.identify("your_distinct_id");
 # Debug 模式
 ## mode 三种取值
 - normal：Normal 模式
-- debug：数据在 TE Debug 模式中看到
+- debug：数据在 AE Debug 模式中看到
 - debug_only：只校验，不入库
 
 # 自动采集

package/skills/ae-data-integration-helper/references/logbus2_guide.md

@@ -13,7 +13,7 @@ LogBus2 是数数科技在原 LogBus 基础上，使用 Go 语言重新开发的
 
 ## 二、使用前准备
 
-1. **数据格式转换**：将需要传输的数据转换成 TE 的数据格式，支持 TA 格式和神策格式
+1. **数据格式转换**：将需要传输的数据转换成 AE 的数据格式，支持 TA 格式和神策格式
 2. **确定数据源**：确定文件存放目录或 Kafka 地址与 topic
 3. **磁盘空间**：相比 LogBus1，LogBus2 去掉了本地磁盘队列，磁盘占用更小
 

package/skills/ae-data-integration-helper/references/logbus2_parser_plugin.md

@@ -2,7 +2,7 @@
 
 > **Terminology**: 数据转译插件 = data parser/translation plugin | 自定义数据解析器 = custom data parser | 数据格式转换 = data format conversion | gRPC 插件 = gRPC plugin | 批量处理 = batch processing | 分隔符 = separator / delimiter | 拼接 = concatenate | proto 文件 = .proto file (Protocol Buffers) | 告警功能 = alerting | 无限重试 = infinite retry | 错误数据 = malformed/error data | 标准 TA 格式 = standard ThinkingAnalytics data format
 
-> Logbus2 from version 2.1.0.0 supports custom data parsers for converting source data formats that differ from the TE data format. This is equivalent to Logbus1's Custom Interceptor feature.
+> Logbus2 from version 2.1.0.0 supports custom data parsers for converting source data formats that differ from the AE data format. This is equivalent to Logbus1's Custom Interceptor feature.
 
 ## 一、准备工作
 
@@ -33,7 +33,7 @@ gRPC插件服务端返回数据格式，以parser.separator拼接转换为标准
 错误处理：
 - 返回非正确json数据，则主程序会跳过错误行
 - 返回非标准ta数据，则数据上报会产生错误
-- 返回第二个参数为error，则会进行无限重试，防止错误数据进入te集群。可搭配告警功能，提前预知错误信息。
+- 返回第二个参数为error，则会进行无限重试，防止错误数据进入AE集群。可搭配告警功能，提前预知错误信息。
 
 ### proto文件
 

package/skills/ae-data-integration-helper/references/minigame_sdk_faq.md

@@ -62,12 +62,12 @@ TDAnalytics.init(config);
 # Debug 模式
 ## debugMode 三种取值
 - none：Normal 模式
-- debug：数据在 TE Debug 模式中看到，参与分析
+- debug：数据在 AE Debug 模式中看到，参与分析
 - debugOnly：只校验，不入库
 
 ## 开启 Debug 模式看不到数据原因
 - 确认模式正确打开
-- 确认设备 ID 已在 TE 后台配置
+- 确认设备 ID 已在 AE 后台配置
 - 确认 appId、serverUrl 正确
 
 # 自动采集

package/skills/ae-data-integration-helper/references/miniprogram_sdk_faq.md

@@ -61,7 +61,7 @@ TDAnalytics.init(config);
 # Debug 模式
 ## debugMode 三种取值
 - none：Normal 模式
-- debug：数据在 TE Debug 模式中看到，参与分析
+- debug：数据在 AE Debug 模式中看到，参与分析
 - debugOnly：只校验，不入库
 
 # 自动采集事件

package/skills/ae-data-integration-helper/references/python_sdk_faq.md

@@ -174,7 +174,7 @@ DebugConsumer 常用配置参数如下表：
 
 #### **BatchConsumer 性能指标如何？适合在什么场景下使用？**
 
-内网环境下适合在并发数据量较低、保证网络的环境下使用（比如与TE集群内网打通）。
+内网环境下适合在并发数据量较低、保证网络的环境下使用（比如与AE集群内网打通）。
 
 #### **DebugConsumer 为什么在生产环境禁用？**
 
@@ -184,7 +184,7 @@ DebugConsumer上传数据时，每条数据都会进行post发送，生产环境
 
 程序需要正常结束时调用，close()方法会将内存中的数据进行写入文件或发送。
 
-#### **在程序中调用了 `track()` 或者 `user_set()` 方法， 为什么在 TE 后台没有看到数据？**
+#### **在程序中调用了 `track()` 或者 `user_set()` 方法， 为什么在 AE 后台没有看到数据？**
 
 请依次检查以下情况：
 

package/skills/ae-data-integration-helper/references/restful_api_notes.md

@@ -1,8 +1,8 @@
 # RESTful API Usage Notes
 
-> **Terminology**: 数据上报 = data ingestion / tracking | 集群 = TE cluster | 请求方式 = request method | 数据压缩 = data compression | 异常处理 = error handling | 数据格式校验 = data format validation | 重试 = retry | 并发 = concurrency | 请求超时 = request timeout | 兜底策略 = fallback strategy
+> **Terminology**: 数据上报 = data ingestion / tracking | 集群 = AE cluster | 请求方式 = request method | 数据压缩 = data compression | 异常处理 = error handling | 数据格式校验 = data format validation | 重试 = retry | 并发 = concurrency | 请求超时 = request timeout | 兜底策略 = fallback strategy
 
-ThinkingData provides a RESTful API for uploading data to the TE cluster via HTTP POST. See the official guide: [RESTful API User Guide](https://docs-v2.thinkingdata.cn/?version=latest&lan=en-US&code=restful_api). This document covers RESTful API usage notes and best practices.
+ThinkingAI provides a RESTful API for uploading data to the AE cluster via HTTP POST. See the official guide: [RESTful API User Guide](https://docs-v2.thinkingdata.cn/?version=latest&lan=en-US&code=restful_api). This document covers RESTful API usage notes and best practices.
 
 #### 使用场景
 

package/skills/ae-data-integration-helper/references/sdk_log_guide.md

@@ -11,8 +11,8 @@
 首先我们简要介绍原生客户端 SDK 的上报机制，Android 和 iOS SDK 都会在本地数据库缓存数据并批量上报。本地缓存数据为了避免网络异常情况下丢失数据，批量上报为了避免频繁上报产生的系统和网络开销。当符合以下任一条件时，均会触发数据上报：
 
 - APP 切换到后台
-- 距上次数据上报时间间隔达到上报时间间隔（默认时间间隔为30秒，可以在 TE 修改）
-- 本地缓存数量达到上报的数量（默认上报的数量达到30条触发上报，可以在 TE 修改）
+- 距上次数据上报时间间隔达到上报时间间隔（默认时间间隔为30秒，可以在 AE 修改）
+- 本地缓存数量达到上报的数量（默认上报的数量达到30条触发上报，可以在 AE 修改）
 
 因此，在调试过程中，如果没有满足触发数据上报的条件，数据仍然缓存在本地。
 
@@ -308,7 +308,7 @@ TDAnalytics.enableLog(true);
 [ThinkingData] Info: Response :{"responseCode":200,...}
 ```
 
-# 三、TE系统查询数据
+# 三、AE系统查询数据
 
 使用sql通过#device_id查询数据，这里数据最及时，实时数据也没这里及时
 

package/skills/ae-data-integration-helper/references/sdk_usage_notes.md

@@ -9,7 +9,7 @@
   - `Debug` 和 `Debug_Only` 模式仅用于测试阶段调试，请勿在生产环境和正式阶段使用；
 
 2. **缓存上报策略**
-  - Android、iOS 原生 SDK 以及底层调用 Android、iOS SDK 的游戏引擎 SDK 和跨平台 SDK，默认采用数据缓存和批量上报策略，上报时机默认 30条/30秒，即设备本地缓存达到 30 条数据或每隔 30 秒触发数据上报。可以在 TE Web "项目管理"页面调整上报频率，但如果上报过于频繁（比如 1条/1秒）会导致客户端系统 CPU、内存、网络等开销增加，引发设备过热、卡顿等问题。
+  - Android、iOS 原生 SDK 以及底层调用 Android、iOS SDK 的游戏引擎 SDK 和跨平台 SDK，默认采用数据缓存和批量上报策略，上报时机默认 30条/30秒，即设备本地缓存达到 30 条数据或每隔 30 秒触发数据上报。可以在 AE Web "项目管理"页面调整上报频率，但如果上报过于频繁（比如 1条/1秒）会导致客户端系统 CPU、内存、网络等开销增加，引发设备过热、卡顿等问题。
   - JS、小游戏/小程序 SDK 默认不开启本地缓存，数据会直接上报，也可以在 SDK 设置开启本地缓存和批量上报功能；
   - 对原生SDK，在Normal模式下，调用`track()`方法不会立刻触发数据上报，会根据缓存上报策略上报；如果希望数据立刻上报，可以调用 `flush()` 方法触发。
 
@@ -18,15 +18,15 @@
   - 如果未开启本地缓存，可以通过callback 对上报失败的情况自定义处理方式，避免数据丢失；
 
 4. **属性类型**
-  - 对于 TE 预置属性（比如 `#account_id`、`#time` 、`#ip` 等），属性类型是 TE 系统固定设置的，预置属性清单详见预置属性与系统字段。
-  - 对于自定义属性（除 TE 预置属性外的属性），属性类型是 TE 系统根据属性值自动识别的，第一条携带该属性的数据中的属性值决定了属性的类型；
-  - 如果上报数据中属性值与 TE 系统的属性类型不一致，系统会尝试强制转换，如果转换成功该属性会入库，如果转换失败**该属性会被丢弃**；
+  - 对于 AE 预置属性（比如 `#account_id`、`#time` 、`#ip` 等），属性类型是 AE 系统固定设置的，预置属性清单详见预置属性与系统字段。
+  - 对于自定义属性（除 AE 预置属性外的属性），属性类型是 AE 系统根据属性值自动识别的，第一条携带该属性的数据中的属性值决定了属性的类型；
+  - 如果上报数据中属性值与 AE 系统的属性类型不一致，系统会尝试强制转换，如果转换成功该属性会入库，如果转换失败**该属性会被丢弃**；
   - 建议关注上报管理中的异常入库，及时识别异常数据和修复；如果对数据质量要求较高，也可以上传埋点方案，并参考项目数据处理规则设置数据处理规则，确保属性类型和预期一致；
   - 元数据管理工具支持修改属性类型，需要注意，**修改类型后属性值会被清空置为NULL**。
 
 5. **时间校准**
   - 建议开启时间校准功能，避免由于设备系统时间不准确导致数据时间偏差，影响后续分析；
-  - 客户端上报，TE 接收前10天至后3天时间范围的数据，超出时间范围的**数据会被丢弃**；
+  - 客户端上报，AE 接收前10天至后3天时间范围的数据，超出时间范围的**数据会被丢弃**；
   - 只需要在 SDK 初始化后做一次时间校准，不需要多次校准；
   - 时间校准方式建议优先用服务器时间戳校准，如果失败再用 NTP 校准作为备选，不要同时使用两种方式校准。
 
@@ -34,7 +34,7 @@
   - SDK 初始化后建议在完成时间校准后立刻开启自动采集，以及时生成 `ta_app_install` `ta_app_start`等自动采集事件，避免自动采集事件生成滞后；
 
 7. **敏感信息采集**
-  - 由于法律要求，通常需要向用户展示隐私协议并获取许可后才能初始化 TE SDK 开启数据采集，请遵循各国法律和各应用商店要求披露和采集敏感信息；
+  - 由于法律要求，通常需要向用户展示隐私协议并获取许可后才能初始化 AE SDK 开启数据采集，请遵循各国法律和各应用商店要求披露和采集敏感信息；
   - Android SDK 会采集 `Android ID` 等信息，可以在配置文件中设置屏蔽。
 
 8. **关键数据上报**
@@ -51,9 +51,9 @@
     ```
 
 10. **应用出海**
-  - 如果应用投放海外，建议 TE 集群就近部署，避免跨墙等原因影响数据上报；
-  - 如果应用全球投放，或数据需要从海外上报至部署在国内的 TE 集群，建议在应用主要投放地区就近部署一组或多组转接点，避免数据丢失和延迟；
-  - 对于 SAAS 客户，TE SAAS 已经在全球多地部署转接点，请使用 TE SAAS 的海外上报地址 `https://global-receiver-ta.thinkingdata.cn`。
+  - 如果应用投放海外，建议 AE 集群就近部署，避免跨墙等原因影响数据上报；
+  - 如果应用全球投放，或数据需要从海外上报至部署在国内的 AE 集群，建议在应用主要投放地区就近部署一组或多组转接点，避免数据丢失和延迟；
+  - 对于 SAAS 客户，AE SAAS 已经在全球多地部署转接点，请使用 AE SAAS 的海外上报地址 `https://global-receiver-ta.thinkingdata.cn`。
 
 # 二、服务端 SDK
 
@@ -79,7 +79,7 @@
   - 公共属性的功能适合在客户端SDK采集用户级信息，服务端SDK不建议使用公共属性功能；
 
 6. **IP、国家、地区信息**
-  - TE 数据中的国家地区信息根据数据的ip信息解析，客户端上报 TE 会自动获取和存储IP信息，服务端上报需要在数据中添加"#ip"后 TE 才会处理；
+  - AE 数据中的国家地区信息根据数据的ip信息解析，客户端上报 AE 会自动获取和存储IP信息，服务端上报需要在数据中添加"#ip"后 AE 才会处理；
 
 7. **多线程和多进程**
   - 服务端SDK基本都支持多线程，`track()`方法中会做加锁处理，可以通过SDK源码确认；
@@ -94,7 +94,7 @@
 
 1. **用户 ID 一致**
   - 从多端上报时，需要保证同一个用户数据 `#distinct_id`和 `#account_id` 一致，否则可能会**导致用户割裂**；
-  - 如果使用单账号多设备分析体系，需要保证数据的`#account_id`相同且数据中带有`#distinct_id`，避免出现用户被割裂为多个 TE 用户的情况；
+  - 如果使用单账号多设备分析体系，需要保证数据的`#account_id`相同且数据中带有`#distinct_id`，避免出现用户被割裂为多个 AE 用户的情况；
 
 2. **多端时间对齐**
   - 客户端SDK会上报时区偏移"#zone_offset"，默认取设备系统时区，部分SDK支持传参指定；

package/skills/ae-data-integration-helper/references/unity_sdk_faq.md

@@ -101,7 +101,7 @@ TDAnalytics.Login("TA");
 
 # 预置属性
 ## #ip
-- TE 服务器获取 http 请求 header 中的 ip
+- AE 服务器获取 http 请求 header 中的 ip
 
 ## #os
 - Unity WebGL 转的微信小游戏 #os 为 "other"

package/skills/ae-dataops/SKILL.md

@@ -29,7 +29,7 @@ The AE Data Development and Operations domain provides capabilities for data war
 
 ## Global AE CLI Rules
 
-AE CLI (`ae-cli`) is the command-line tool for the AE / TE / ThinkingEngine analysis platform. For AE analysis-side requests, prefer `ae-cli` and this skill's reference docs over model memory.
+AE CLI (`ae-cli`) is the command-line tool for the AE (Agentic Engine) analysis platform. For AE analysis-side requests, prefer `ae-cli` and this skill's reference docs over model memory.
 
 Global parameters:
 

package/skills/ae-engage/SKILL.md

@@ -6,11 +6,11 @@ description: "AE Engage capability gateway: config center, flows, push/config ch
 
 # ae-engage
 
-AE CLI (`ae-cli`) is the command-line tool for the ThinkingEngine data analysis platform, used by AI Agents and human users.
+AE CLI (`ae-cli`) is the command-line tool for the Agentic Engine data analysis platform, used by AI Agents and human users.
 
 ## Global AE CLI Rules
 
-AE CLI (`ae-cli`) is the command-line tool for the AE / TE / ThinkingEngine analysis platform. For AE analysis-side requests, prefer `ae-cli` and this skill's reference docs over model memory.
+AE CLI (`ae-cli`) is the command-line tool for the AE (Agentic Engine) analysis platform. For AE analysis-side requests, prefer `ae-cli` and this skill's reference docs over model memory.
 
 Global parameters:
 
@@ -55,7 +55,7 @@ When the user mentions a product term below (including common Chinese UI labels)
 | **Push channel** | Project-level message push channels (Webhook, FCM, APNS, etc.) | `engage-setting` | `references/channel-list.md` | `channel-detail.md`, `add-channel.md` (**Webhook vs Client differ**: `url` = HTTP vs scene key; custom params `user:` vs `user:`/`client:`), `update-channel-status.md`, `delete-channel.md`, `channel-update-config.md`, `channel-test-send.md`, `channel_touch_limits_list.md` |
 | **Config channel** | Config-center Webhook/client config channels (not the same as push channels) | `engage-scene` | `references/scene-config-channel.md` | `channel-mgmt.md` (create/enable-disable/copy/delete workflows). User params in `config.customsParamList` require `columnName` with `user:` prefix (e.g. `user:#account_id`); preflight names with ae-analysis `analysis-meta property list/get`. |
 | **Operation strategy** | Ops/delivery strategies under a config item | `engage-scene` | `references/scene-strategy.md` | Custom audience: [`scene-strategy-audience.md`](references/scene-strategy-audience.md) — semantic `definitionRequest` (Analysis condition shape); do not pass `targetClusterQp`/`qp`; preflight props (stop + list if missing); template: `scene-template.md` |
-| **Operation task** | Hermes push/engagement tasks (list, save, lifecycle, reports) | `engage-task` | `references/task-list.md` | `task-detail.md` (get), `save-task.md`, `build-task-save-guide.md`, `task-stats.md`, `task-delete.md`, `push-record-query.md`, `task-user-detail-export.md`, `task-indicator-user.md`, `task-data-overview.md`, `task-data-detail.md`, `task-metric-detail.md`, `task-experiment-report.md` |
+| **Operation task** | Hermes push/engagement tasks (list, save, lifecycle, reports) | `engage-task` | `references/task-list.md` | `task-detail.md` (get), `save-task.md`, `build-task-save-guide.md`, `task-stats.md`, `task-delete.md`, `push-record-query.md`, `task-user-detail-export.md`, `task-indicator-user.md`, `task-data-overview.md`, `task-data-detail.md`, `task-metric-detail.md`, `task-metric-update.md`, `task-experiment-report.md` |
 | **Operation activity** | Campaign activity management and delivery trends by activity, topic, or standalone task | `engage-activity` | `references/activity-activity.md` | `activity-data-detail.md`, `activity-topic.md`, `activity-task.md`, `activity-approval.md` |
 | **Template** | Strategy templates under a config item | `engage-scene` | `references/scene-template.md` | `scene-config-param.md` (template fields reference `paramId`); enable via `template update` then `template update-status` before strategy create |
 
@@ -518,6 +518,7 @@ More detailed single-command guidance is available in the business-oriented `ref
 - `references/task-submit-approval.md` (`engage-task.task.submit-approval`)
 - `references/task-data-detail.md` (`engage-task data-detail query`; capability `engage-task.task-data.detail`)
 - `references/task-metric-detail.md` (`engage-task effect query`; capability `engage-task.task-data.metric-detail`)
+- `references/task-metric-update.md` (`engage-task metric update`; capability `engage-task.metric.update`)
 - `references/flow-metric-update.md` (`engage-flow metric update`; capability `engage-flow.metric.update`)
 
 This split documentation structure is easier to extend later, because commands with more complex object inputs can stay centralized in the `references/` root directory.

package/skills/ae-engage/references/build-task-save-guide.md

@@ -311,6 +311,9 @@ For `completionIndicatorType=0`, also read and preserve `requiredMainGoalFields`
 and `day` when no custom completion window is requested. Do not rely on static `--validate` alone
 because the save service performs this additional business validation.
 
+For natural goal windows, read `naturalWindowRule` in the same rule object.
+See [save-task.md](save-task.md#natural-completion-goal-windows) for the field contract.
+
 ### 4.9 `handoff`
 
 This is the final section before `save_task`.

package/skills/ae-engage/references/flow-metric-update.md

@@ -32,13 +32,127 @@ The backend uses a clean-and-insert update model: omitted existing metric settin
   - `ab_test`
 - Preserve first-level group keys exactly. Do not convert `ab_test` to `abTest`.
 - Each group value is an array of Hermes metric DTO objects.
-- Use DTO field names from `HermesMetricReqDTO`: `metricSettingId`, `metricType`, `metricName`, `metricQp`, `metricWindowNum`, `metricWindowTimeUnit`, `displayName`, `orderId`, `note`, and `metricParams`.
+- Use DTO field names from `HermesMetricReqDTO`: `metricSettingId`, `metricType`, `metricName`, `metricQp`, `metricWindowNum`, `metricWindowTimeUnit`, `timeCycleDef`, `displayName`, `orderId`, `note`, and `metricParams`.
 - The CLI boundary accepts snake_case nested DTO fields too, but prefer the native camelCase names above in examples and generated payloads.
 - For existing bindings, include `metricSettingId` so Hermes updates that binding instead of treating it as a new binding.
 - For preset metrics, use `metricType: 1` and a real `metricName` discovered from `engage-setting common-metric list/get`.
 - For custom metrics, use `metricType: 2` plus a complete `metricQp`, `metricWindowNum`, `metricWindowTimeUnit`, and `displayName`; Hermes creates the custom metric name.
 - Do not invent metric names, event names, property names, QP structures, or metric-setting IDs. Read the existing flow detail and available metric definitions first, then update the complete desired metric map.
 
+Create/save the flow first and obtain its logical `flow_id`, then configure effect metrics with this command. Do not put the global `metric_map` in the flow-save request.
+
+## Custom metric window semantics
+
+Choose the window from the user's intent, not from the number alone:
+
+| User intent | `metricWindowNum` | `metricWindowTimeUnit` | `timeCycleDef` |
+| --- | --- | --- | --- |
+| One day / 24 hours / rolling one day | `1` | `"day"` | Omit |
+| Until the end of the attribution event's calendar day | `1` | `"day"` | `{"startTime":"00:00"}` |
+| Until the end of the attribution event's calendar week | `1` | `"week"` | `{"startDay":1,"startTime":"00:00"}` |
+| Until the end of the attribution event's calendar month | `1` | `"month"` | `{"startDay":1}` |
+
+`timeCycleDef` selects a natural calendar attribution window. The attribution event (such as a trigger, delivery, or click, according to the metric group) anchors the window; conversions must occur after that event and before the next configured cycle boundary. The boundary is exclusive. `1` + `day` alone remains a rolling one-day window. Resolve calendar boundaries in the flow's configured timezone (`tzOffset`), falling back to the backend default when absent. The report display timezone does not redefine the cycle.
+
+For example, with Monday at midnight as the week boundary, a Wednesday 15:00 attribution event counts subsequent conversions before the following Monday 00:00. It does not count Monday or Tuesday conversions before that event. With midnight as the day boundary, a 23:00 attribution event has only the remainder of that day, rather than 24 hours.
+
+Interpret "today", "this week", or "this month" as these windows only when the user means the attribution event's day, week, or month. A request to view results for the current reporting period belongs to report date filters and does not by itself authorize changing metric configuration.
+
+Treat an unqualified "one day" as the existing rolling window. Use midnight, Monday, and the first day of the month for the calendar defaults above. Honor an explicitly requested valid cycle start. "Daily", "weekly", and "monthly" can describe task execution frequency: resolve the context and ask for clarification only when the metric window intent remains ambiguous.
+
+Natural window constraints:
+
+- `metricWindowNum` must be `1`; the unit must be `day`, `week`, or `month`.
+- Day: require `startTime` in 24-hour `HH:mm`; omit `startDay`.
+- Week: require `startDay` from `1` (Monday) to `7` (Sunday) and `startTime` in `HH:mm`.
+- Month: require `startDay` from `1` to `28`; omit `startTime` or use `"00:00"`.
+- An empty `timeCycleDef: {}` is invalid. Without `timeCycleDef`, only rolling `minute`, `hour`, and `day` units are accepted.
+- When switching rolling to calendar, add the matching `timeCycleDef` and set the number/unit together. When switching back, remove `timeCycleDef` entirely and use a valid rolling unit. Preserve the binding's `metricSettingId` and all other desired metrics.
+- These options apply to custom metrics (`metricType: 2`) through `metric update`. Do not use `engage-setting common-metric create/update` to create natural windows.
+- Task support requires a backend deployment containing the task natural-window feature. Do not silently replace an unsupported calendar window with a rolling duration.
+
+### Custom metric payload examples
+
+Each JSON block is a complete illustrative `--metric-map` value for a configuration containing only that metric. The `purchase` event and QP below are examples, not discovered project metadata: substitute a verified project metric QP (as a JSON string) before use. For an existing configuration, merge the chosen metric into the complete current map and preserve existing binding IDs; do not submit these single-metric examples over other configured metrics.
+
+Rolling one day:
+
+```json
+{
+  "trigger": [
+    {
+      "metricType": 2,
+      "metricQp": "{\"type\":0,\"eventName\":\"purchase\",\"analysis\":\"A100\",\"filts\":[]}",
+      "metricWindowNum": 1,
+      "metricWindowTimeUnit": "day",
+      "displayName": "Purchase - Rolling one day",
+      "orderId": 1
+    }
+  ]
+}
+```
+
+Current calendar day:
+
+```json
+{
+  "trigger": [
+    {
+      "metricType": 2,
+      "metricQp": "{\"type\":0,\"eventName\":\"purchase\",\"analysis\":\"A100\",\"filts\":[]}",
+      "metricWindowNum": 1,
+      "metricWindowTimeUnit": "day",
+      "displayName": "Purchase - Current calendar day",
+      "orderId": 1,
+      "timeCycleDef": {
+        "startTime": "00:00"
+      }
+    }
+  ]
+}
+```
+
+Current calendar week:
+
+```json
+{
+  "trigger": [
+    {
+      "metricType": 2,
+      "metricQp": "{\"type\":0,\"eventName\":\"purchase\",\"analysis\":\"A100\",\"filts\":[]}",
+      "metricWindowNum": 1,
+      "metricWindowTimeUnit": "week",
+      "displayName": "Purchase - Current calendar week",
+      "orderId": 1,
+      "timeCycleDef": {
+        "startDay": 1,
+        "startTime": "00:00"
+      }
+    }
+  ]
+}
+```
+
+Current calendar month:
+
+```json
+{
+  "trigger": [
+    {
+      "metricType": 2,
+      "metricQp": "{\"type\":0,\"eventName\":\"purchase\",\"analysis\":\"A100\",\"filts\":[]}",
+      "metricWindowNum": 1,
+      "metricWindowTimeUnit": "month",
+      "displayName": "Purchase - Current calendar month",
+      "orderId": 1,
+      "timeCycleDef": {
+        "startDay": 1
+      }
+    }
+  ]
+}
+```
+
 ## Examples
 
 Dry-run updating an existing binding:

package/skills/ae-engage/references/save-flow.md

@@ -30,6 +30,9 @@ You still organize user requirements into an intermediate intent first, then map
 
 ---
 
+The current `build` / `preview` / `commit` API does not expose `completionIndicators`.
+Completion-goal editing requires the web editor; CLI JSON passthrough does not add support.
+
 ## 2. Workflow
 
 1. Identify the flow intent from the user input and produce a unified intent JSON.

package/skills/ae-engage/references/save-task.md

@@ -4,6 +4,8 @@ Create or update a Hermes task draft.
 
 Mapped command: `ae-cli engage-task task save`
 
+To configure custom effect metrics after saving (including rolling or current calendar day/week/month windows), use [Task metric update](task-metric-update.md). Do not embed the global metric map in this save request.
+
 This command is the final write step. Do not use it as the first step in task construction.
 
 Recommended workflow:
@@ -437,6 +439,25 @@ For a main goal (`completionIndicatorType=0`), always include `touch_cycle_num`
 `touch_cycle_num=1` and `touch_cycle_num_unit="day"`. Static Capability validation may accept a
 main goal without these fields, but the Hermes save service rejects it.
 
+### Natural completion-goal windows
+
+Set these fields on `req.controlConfig.completionIndicatorDef.completionIndicators[]`,
+alongside `completionIndicatorType` and the semantic `eventDefinition`:
+
+| Window | `touch_cycle_num` | `touch_cycle_num_unit` | `timeCycleDef` |
+| --- | --- | --- | --- |
+| Current day | 1 | `day` | `{"startTime":"00:00"}` |
+| Current week | 1 | `week` | `{"startDay":1,"startTime":"00:00"}` |
+| Current month | 1 | `month` | `{"startDay":1}` |
+
+Custom day/week times use `HH:mm`. Week `startDay` is 1 (Monday) through 7 (Sunday);
+month `startDay` is 1 through 28. Day windows omit `startDay`; month windows omit
+`startTime` or use `00:00`. Natural windows require count 1 and a nonempty `timeCycleDef`.
+Boundaries use the task timezone; conversions must follow attribution and precede the next boundary.
+
+To return to a rolling window, remove `timeCycleDef` and set a valid `minute`, `hour`,
+or `day` count/unit. Without `timeCycleDef`, `1` + `day` remains a rolling one-day window.
+
 Important constraints that still apply:
 
 - `doNotDisturb.enableDoNotDisturb=true` requires `startTime` and `endTime` in `HH:mm`