@thinkingai/ae-cli 6.0.31 → 6.1.4

package/skills/ae-analysis/references/create_metric.md

@@ -1,58 +0,0 @@
-# analysis_meta +create_metric (Create Metric)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metadata Query**
-
-## Use Cases
-- When constructing real `events` / `params`, you must supplement project-native metadata; first call `analysis_meta +list_events` and `analysis_meta +list_properties`.
-- Create a metric from analysis configuration.
-- Creates a new metric based on event or retention analysis.
-
-## MUST Prerequisites
-- Before constructing `--events` / `--params`, you must first read and follow these reference documents:
-  - [`./list_events.md`](./list_events.md)
-  - [`./list_properties.md`](./list_properties.md)
-- Do not generate the final `events` / `params` until the document review and prerequisite command calls above are complete.
-
-## Prerequisite Call Chain (Required for Constructing events/params)
-1. Determine `--model_type` first (`event` / `retention`).
-2. Read `list_events.md`, then call `ae-cli analysis_meta +list_events --project_id <project_id>` to get available events.
-3. Read `list_properties.md`, then call `ae-cli analysis_meta +list_properties --project_id <project_id>` to get available properties.
-4. Build `events` / `params` from the metric API payload shape and verified metadata, then call `+create_metric`.
-5. If an accessible URL must be returned, apply resource-link completion according to the unified skill constraints (call `analysis_common +get_resource_url`).
-
-## Commands
-```bash
-ae-cli analysis_meta +create_metric --project_id <project_id> --name demo --display_name demo --model_type event --events '[]' --params '{}'
-ae-cli analysis_meta +create_metric --project_id <project_id> --name demo --display_name demo --remark demo --model_type event --events '[]' --params '{}'
-ae-cli analysis_meta +create_metric --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--name` | Yes | Metric name. Must start with a lowercase letter and contain only lowercase letters, digits, and underscores. Maximum length: 80. |
-| `--display_name` | Yes | Metric display name |
-| `--remark` | No | Optional metric remark |
-| `--model_type` | Yes | Metric model type. Supported values: event and retention |
-| `--events` | Yes | Metric events JSON. Fill event/property fields using metadata from `analysis_meta +list_events` / `analysis_meta +list_properties` in the same `project_id`. |
-| `--params` | Yes | Metric params JSON. Use project metadata from `analysis_meta +list_events` / `analysis_meta +list_properties` when filling referenced fields. |
-
-## Decision Rules
-- `events` / `params` must not be handwritten by intuition alone: they must satisfy the metric API payload shape and the project's real metadata constraints.
-- Set `--model_type` first, then use the matching schema; do not mix event/retention structures.
-- Before calling `list_events` / `list_properties`, you must first study the corresponding reference documents.
-- The smallest valid request still requires `--project_id`, `--name`, `--display_name`, `--model_type`, `--events`, and `--params`; do not omit the model definition to “test the path.” Use `--dry-run` with the complete request for preflight.
-- Wrap JSON parameters in single quotes (for example `--events '{}'` and `--params '{}'`) to avoid shell escaping issues.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-- This is an ordinary `write` operation and does not require CLI confirmation.
-
-## Next Steps After Failure
-- If required parameters are missing, complete all required fields listed above before retrying.
-- If `Invalid JSON` appears, first check required fields, then verify whether the event and property names come from metadata query results in the same `project_id`.
-- If the result after writing does not match expectations, immediately reread the corresponding list/get interfaces for before-and-after comparison.
-
-## Recommended Chaining
-- +list_metrics -> +create_metric -> +get_metric

package/skills/ae-analysis/references/create_virtual_event.md

@@ -1,60 +0,0 @@
-# analysis_meta +create_virtual_event (Create Virtual Event)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metadata Query**
-
-## Use Cases
-- When constructing real `events` / `filter`, you must first obtain the project's available event and property metadata.
-- Create a virtual event that combines multiple events with filters.
-- A virtual event is a composite event defined by combining multiple real events with optional filters.
-- Key parameters:
-- eventName: Unique name for the virtual event (must start with 'ta@'); the name after 'ta@' must start with a letter, and it can contain letters, numbers, and underscores, with a maximum of 60 characters.
-- eventDesc: Display name/description
-- events: JSON array of real events to combine, each with eventName and optional filter.
-
-## MUST Prerequisites
-- Before constructing `--events` / `--filter`, you must first read and follow these reference documents:
-  - [`./list_events.md`](./list_events.md)
-  - [`./list_properties.md`](./list_properties.md)
-- Do not generate the final `events` / `filter` until the document review and prerequisite command calls above are complete.
-
-## Prerequisite Call Chain (Required for Constructing events/filter)
-1. Read `list_events.md`, then call `ae-cli analysis_meta +list_events --project_id <project_id>` to get available events.
-2. Read `list_properties.md`, then call `ae-cli analysis_meta +list_properties --project_id <project_id>` to get properties available for filtering.
-3. Build `events` / `filter` from the command payload shape and verified metadata, then call `+create_virtual_event`.
-4. Example events JSON: `[{"eventName":"purchase"},{"eventName":"add_to_cart"}]`
-
-## Commands
-```bash
-ae-cli analysis_meta +create_virtual_event --project_id <project_id> --event_name ta@demo --event_desc demo --events '[{"eventName":"purchase"}]'
-ae-cli analysis_meta +create_virtual_event --project_id <project_id> --event_name ta@demo2 --event_desc demo --remark demo --events '[{"eventName":"add_to_cart"}]' --filter '{}' --override true
-ae-cli analysis_meta +create_virtual_event --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--event_name` | Yes | Unique name for the virtual event (must start with 'ta@') |
-| `--event_desc` | Yes | Display name/description |
-| `--remark` | No | Optional remarks |
-| `--events` | Yes | JSON array of events to combine. Event/property fields must come from `analysis_meta +list_events` / `analysis_meta +list_properties` in the same `project_id`. |
-| `--filter` | No | Optional global filter JSON for all events. If provided, referenced fields must come from `analysis_meta +list_properties`. |
-| `--override` | No | Whether to override if event already exists. Default: false |
-
-## Decision Rules
-- `events` / `filter` must not be handwritten by intuition alone: they must satisfy the command payload shape and the project's real metadata constraints.
-- Before calling `list_events` / `list_properties`, you must first study the corresponding reference documents.
-- For the first run, pass only the required parameters (`--project_id`, `--event_name`, `--event_desc`, `--events`) to confirm the path works, then add optional parameters.
-- Wrap JSON parameters in single quotes (for example `--events '{}'` and `--filter '{}'`) to avoid shell escaping issues.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-- This is an ordinary `write` operation and does not require CLI confirmation.
-
-## Next Steps After Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`, `--event_name`, and `--event_desc`).
-- If `Invalid JSON` appears, first check required fields, then verify whether the event and property names come from metadata query results in the same `project_id`.
-- If the result after writing does not match expectations, immediately reread the corresponding list/get interfaces for before-and-after comparison.
-
-## Recommended Chaining
-- +list_events -> +create_virtual_event

package/skills/ae-analysis/references/create_virtual_property.md

@@ -1,69 +0,0 @@
-# analysis_meta +create_virtual_property (Create Virtual Property)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metadata Query**
-
-## Use Cases
-- Before creating a virtual property, first confirm the available properties and, as needed, available events from the project metadata.
-- Create a SQL-based virtual property.
-- A SQL virtual property is a computed property defined by a SQL expression.
-- Key parameters:
-- propertyName: Unique name for the virtual property (must start with '#vp@'), the name after '#vp@' must start with a letter, and can contain letters, numbers and underscores, with a maximum of 60 characters.
-- propertyDesc: Display name/description
-- tableType: event or user. Determine based on the prompt whether to create a virtual event property or a virtual user property
-- selectType: Data type (string, number, bool, datetime)
-- sqlExpression: SQL expression for computing the property
-- sqlEventRelationType: relation_default, relation_always, or relation_by_setting
-
-## Mandatory Prerequisites (MUST)
-- Before building `--sql_expression` / `--related_events`, you must first read and follow the reference docs below:
-  - [`./list_properties.md`](./list_properties.md)
-  - [`./list_events.md`](./list_events.md) (only when `sql_event_relation_type=relation_by_setting`)
-- Do not submit the final SQL and event-association configuration until the above docs have been read and the prerequisite commands have been run.
-
-## Prerequisite Call Chain (required for building SQL and relations)
-1. Read `list_properties.md`, then run `ae-cli analysis_meta +list_properties --project_id <project_id>` to get the available properties.
-2. Use `--table_type` to determine the SQL field source (event or user scope).
-3. Write `--sql_expression` using only fields confirmed in the previous step; the expression must conform to Trino syntax.
-4. If `--sql_event_relation_type=relation_by_setting`, read `list_events.md`, then run `ae-cli analysis_meta +list_events --project_id <project_id>` to get the available events and build `--related_events`.
-5. Call `+create_virtual_property` to create the virtual property.
-6. Example `sql_expression`: `property_a + property_b` or `CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END`.
-
-## Command
-```bash
-ae-cli analysis_meta +create_virtual_property --project_id <project_id> --property_name '#vp@demo' --table_type event --select_type string --sql_expression 'event_name' --sql_event_relation_type relation_default
-ae-cli analysis_meta +create_virtual_property --project_id <project_id> --property_name '#vp@demo' --property_desc demo --table_type event --select_type string --sql_expression "CASE WHEN status = 1 THEN 'active' ELSE 'inactive' END" --sql_event_relation_type relation_by_setting --related_events '[{"eventName":"purchase"}]' --property_remark demo
-ae-cli analysis_meta +create_virtual_property --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--property_name` | Yes | Name for the virtual property (must start with '#vp@'), the name after '#vp@' must start with a letter, and can contain letters, numbers and underscores, with a maximum of 60 characters. |
-| `--property_desc` | No | Display name/description |
-| `--table_type` | Yes | Table type. event: create virtual event property(virtual property generated based on event or user properties), user: create virtual user property(virtual property generated based on user properties) |
-| `--select_type` | Yes | Data type: string, number, bool, datetime |
-| `--sql_expression` | Yes | SQL expression for computing the property. MUST be built from fields confirmed by `analysis_meta +list_properties` in the same `project_id`, and MUST conform to Trino syntax (for example, columns starting with '#' or containing '@' should be double-quoted). |
-| `--sql_event_relation_type` | Yes | Type of associating attributes with events, relation_default: auto; relation_always: all events; relation_by_setting: specified events |
-| `--related_events` | No | Optional JSON array of related events. When `sql_event_relation_type=relation_by_setting`, this field is required and event names MUST come from `analysis_meta +list_events` in the same `project_id`. |
-| `--property_remark` | No | Optional property remark |
-
-## Decision Rules
-- `sql_expression` / `related_events` cannot be written from experience alone: they must be built from real project metadata.
-- `list_properties` / `list_events` must be read before their corresponding commands are run.
-- First run should only pass required parameters (`--project_id`, `--property_name`, `--table_type`, `--select_type`, `--sql_expression`, `--sql_event_relation_type`), and add optional parameters only after the path is confirmed to work.
-- Wrap JSON arguments in single quotes (for example `--related_events '{}'`) to avoid shell escaping issues.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-- This is an ordinary `write` operation and does not require CLI confirmation.
-
-## Next Steps After Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill them in (focus on `--project_id`, `--property_name`, and `--table_type`).
-- If `Invalid JSON` occurs, first check the `related_events` structure, then verify whether the event names came from the `list_events` result for the same `project_id`.
-- If SQL execution or validation fails, first check whether the field names came from `list_properties`, then check whether the Trino syntax and field references are correct.
-- If the result after writing is not as expected, immediately read back the corresponding list/get interface for a before-and-after comparison.
-
-## Recommended Chaining
-- +list_properties -> +create_virtual_property
-- +list_properties -> +list_events -> +create_virtual_property (sql_event_relation_type=relation_by_setting)

package/skills/ae-analysis/references/delete_metric.md

@@ -1,32 +0,0 @@
-# analysis_meta +delete_metric (Delete Metric)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metric Management**
-
-## Use Cases
-- Permanently delete a metric by its ID.
-- Do not use it when the metric should be retained with a corrected definition; use `+update_metric` instead.
-
-## Output
-Success confirms deletion of the specified metric. The command does not return a metric definition; verify absence with `+list_metrics`.
-
-## Commands
-```bash
-ae-cli analysis_meta +delete_metric --project_id <project_id> --metric_id <metric_id> --dry-run
-# Summarize the target and impact, then wait for explicit user confirmation.
-ae-cli analysis_meta +delete_metric --project_id <project_id> --metric_id <metric_id> --yes
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--metric_id` | Yes | Metric ID to delete |
-
-## Decision Rules
-- Use `+list_metrics` first to confirm the metric ID before deleting.
-- This is `high-risk-write`: inspect the dry-run, summarize the target and impact, and wait for explicit user confirmation before the `--yes` execution.
-
-## Recommended Chain
-- `+list_metrics` -> `+delete_metric`

package/skills/ae-analysis/references/drilldown_users_export.md

@@ -1,17 +0,0 @@
-# analysis drilldown-users export
-
-Export all users for a selected result target from a previous analysis query context. Do not pass raw QP.
-
-## Command
-
-```bash
-ae-cli analysis drilldown-users export \
-  --query-context-id <query_context_id> \
-  --target '<json>' \
-  [--artifact-format jsonl] \
-  [--timeout-seconds 21600]
-```
-
-Use the same `query_context_id`, `target`, and optional `properties` contract as `analysis drilldown-users run`. Export does not accept `--limit` or `--offset`; Common reads backend batches internally and writes one JSONL artifact.
-
-Inspect the returned `run_id` with `analysis run inspect`, then download the completed artifact with `analysis artifact download`. The final metadata line includes `rows`, `total`, and `drilldown_context_id`.

package/skills/ae-analysis/references/drilldown_users_run.md

@@ -1,61 +0,0 @@
-# analysis drilldown-users run
-
-Precondition: the upstream response must have `drilldown_available=true` and the selected source must contain `target_contract`. If either is absent, do not call this command or reconstruct a target from display text.
-
-Drill down to users from a previous analysis data query context.
-
-Use this after any analysis data command that returns `query_context_id`:
-
-- `analysis adhoc run`
-- `analysis adhoc export`
-- `analysis report-data run`
-- `analysis report-data export`
-- `analysis dashboard-report-data run`
-- `analysis dashboard-report-data export`
-
-Do not pass raw QP.
-
-## Command
-
-```bash
-ae-cli analysis drilldown-users run \
-  --query-context-id <query_context_id> \
-  --target '<json>' \
-  [--limit 100] \
-  [--timeout-seconds 120]
-```
-
-## Input
-
-- `--query-context-id`: returned by an analysis data run/export submit response, or by the first metadata line of a JSONL artifact.
-- `--target`: pass the selected source's `target_contract.default_target` directly for the whole-result default. For a specific result row or cell, copy that object and replace only the fields named by `target_contract.copy_from_selected_result`.
-- `--properties`: optional backend property request object array. Omit this in normal agent calls and use the default returned columns. Do not pass string-name arrays such as `["#user_id"]`.
-
-Do not use raw QP or reconstruct the first query request. The server resolves the source QP from Redis by `query_context_id`.
-
-## Target
-
-`--target` identifies the cell/step/bucket/date to drill down. The upstream `sources[]` entry is the machine-readable contract. Do not infer a target shape from model memory or reuse a target from a different source/model.
-
-`target_contract.default_target` already contains `report_id` or `chart_id` when needed. Preserve it unchanged:
-
-```json
-{"report_id":1001,"drilldown_date":"2026-07-01","drilldown_groups":["ios"],"event_index":0}
-```
-
-Common fields:
-
-- `report_id`: required when the context contains multiple report sources.
-- `chart_id`: required when the context contains multiple BI chart sources. BI SQL chart contexts normally return `drilldown_available=false`; do not call drilldown unless the first response explicitly says `drilldown_available=true`.
-- `drilldown_date` or `target_dates`: target date(s) from the result row. Include one of these when you plan to call `drilldown-user-events` next; `include_total` alone can list users but may not carry enough date context for event-sequence lookup.
-- `drilldown_groups`: group values from the result row.
-- `event_index`: event model index, starting from 0.
-- `retention_days`, `is_lost`: retention target.
-- `funnel_step`, `is_churned_user`: funnel target.
-- `interval`, `distribution_bucket`, `compare_index`, `include_total`, `relation_val`: model-specific target fields.
-
-## Output
-
-The response contains at most `limit` user rows and a `drilldown_context_id`. When `truncated=true`, use `analysis drilldown-users export`; do not attempt to fetch another page.
-
-Use `drilldown_context_id` with `analysis drilldown-user-events run` or `analysis drilldown-user-events export`.

package/skills/ae-analysis/references/get_metric.md

@@ -1,38 +0,0 @@
-# analysis_meta +get_metric (View Metric Details)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metadata Query**
-
-## Constraints
-
-**Not an ad-hoc pre-step:** Do not call `+get_metric` just to expand a saved metric before normal ad-hoc analysis. If the user asks to query a saved metric, pass the metric display/name/remark directly in `analysis adhoc run --definition`; the backend compiler resolves saved metrics internally.
-
-## Use Cases
-- Get the definition details of a single metric. Returns the metric name, display name, remark, model type, linked events, and parameter definition without executing metric calculation.
-- Use this command for metric metadata inspection, metric editing, auditing, or when the user explicitly asks for metric definition details. Do not use it merely to expand a saved metric before an ad-hoc query.
-
-## Commands
-```bash
-ae-cli analysis_meta +get_metric --project_id <project_id> --metric_id 1
-ae-cli analysis_meta +get_metric --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--metric_id` / `-m` | Yes | Metric ID |
-
-## Decision Rules
-- For the first run, pass only the required parameters (`--project_id` and `--metric_id`) to confirm the path works, then add optional parameters.
-- For ad-hoc analysis, do not read metric details first. Call `analysis adhoc run` or `analysis adhoc export` with the user's metric/event/property wording.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-
-## Next Steps After Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id` and `--metric_id`).
-- If reading fails, first verify that the object ID exists and belongs to the current project.
-
-## Recommended Chaining
-- +get_metric -> +update_metric
-- For ad-hoc saved metric query: analysis adhoc run/export

package/skills/ae-analysis/references/get_resource_url.md

@@ -1,33 +0,0 @@
-# Resource link completion (call analysis_common +get_resource_url)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **cross-module post-write constraint**
-
-## Use Cases
-- After a `create_*` or `update_*` write operation succeeds in this unified skill, complete the clickable asset link.
-- Supported resource types (resourceType): `dashboard`, `report`, `metric`, `alert`, `tag`, `cluster`, `data_table`, `super_event`, `super_prop_user`, `super_prop_event`, `virtual_event`, `user_virtual_prop`, `event_virtual_prop`.
-- Key return fields: `markdown_link`, `raw_url`.
-
-## Mandatory Rules (MUST)
-- As long as `project_id + resource_type + resource_id` can be determined, this command must be called.
-- The final response must output `markdown_link` directly (do not place it in a code block) so the user can click through.
-- If resource link generation fails, keep the main write-operation success conclusion and add the failure reason.
-
-## Command
-```bash
-ae-cli analysis_common +get_resource_url --project_id <project_id> --resource_type dashboard --resource_id 1
-ae-cli analysis_common +get_resource_url --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--resource_type` | Yes | Resource type: dashboard/report/metric/alert/tag/cluster/data_table/super_event/super_prop_user/super_prop_event/virtual_event/user_virtual_prop/event_virtual_prop |
-| `--resource_id` | Yes | Numeric resource ID |
-
-## Recommended Chaining
-- `+create_*` -> `analysis_common +get_resource_url`
-- `+update_*` -> `analysis_common +get_resource_url`
-- For `analysis report create/update`, use the returned `report_id` directly as `--resource_id`; do not run a broad report list to rediscover the asset.

package/skills/ae-analysis/references/list_events.md

@@ -1,46 +0,0 @@
-# analysis_meta +list_events (Event Metadata Discovery)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metadata Query**
-
-## Constraints
-
-**Fuzzy Search Fallback:** If `--query` returns no results, retry with broader keywords (max 3 attempts), then fall back to full list. See [SKILL.md § C. FUZZY_SEARCH_FALLBACK](../SKILL.md#c-fuzzy_search_fallback).
-
-**Not an ad-hoc pre-step:** Do not call `+list_events` just to prepare `analysis adhoc run/export`. Pass the user's event wording in the AI-facing `definition`; the backend compiler resolves it or returns a structured clarification/error. Use this command only when the user explicitly wants to inspect metadata or when a prior compiler error asks for disambiguation.
-
-## Use Cases
-- Read-only query for SYSTEM METADATA already effective in the project. Use for super events in production metadata. Do NOT use for tracking-plan metadata (bury/track program); that belongs to BuryProgramTool.
-- Read-only query for SYSTEM METADATA already effective in the project. Use when the user explicitly asks to inspect event metadata, not as a required preparation step for ad-hoc AI model construction.
-
-## Commands
-```bash
-ae-cli analysis_meta +list_events --project_id <project_id>
-ae-cli analysis_meta +list_events --project_id <project_id> --query demo
-ae-cli analysis_meta +list_events --project_id <project_id> --query demo --fields '["eventId", "eventName", "eventDesc", "remark"]' --limit 50 --offset 0
-ae-cli analysis_meta +list_events --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--query` / `-q` | No | Optional keyword filter. Performs fuzzy matching against eventName, eventDesc, and remark; if omitted, all events are returned. |
-| `--fields` / `-f` | No | Optional fields to return (JSON array). Supported fields: `eventId`, `eventName`, `eventDesc`, `remark`, `eventTag`, `authenticationStatus`. Default fields when omitted: `eventId`, `eventName`, `eventDesc`, `remark`, `authenticationStatus`. |
-| `--limit` / `-l` | No | Optional page size. Default: 50, maximum: 200. |
-| `--offset` / `-o` | No | Optional page offset. Default: 0. |
-| `--authenticated_only` | No | When true, return only authenticated events. |
-
-## Decision Rules
-- Use `--authenticated_only true` only when the user explicitly asks for authenticated assets. `authenticationStatus` is `1` for authenticated and `0` for unauthenticated.
-- For the first run, pass only the required parameter (`--project_id`) to confirm the path works, then add optional parameters.
-- For ad-hoc analysis, pass the user's event wording in the AI-facing `definition` instead of pre-querying event metadata.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-
-## Next Steps After Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`).
-- If the result is empty, first confirm the project ID/keyword, then try loosening the filter conditions.
-
-## Recommended Chaining
-- +list_events -> +create_virtual_event

package/skills/ae-analysis/references/list_metrics.md

@@ -1,52 +0,0 @@
-# analysis_meta +list_metrics (Metric Search)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metadata Query**
-
-## Constraints
-
-**Fuzzy Search Fallback:** If `--query` returns no results, retry with broader keywords (max 3 attempts), then fall back to full list. See [SKILL.md § C. FUZZY_SEARCH_FALLBACK](../SKILL.md#c-fuzzy_search_fallback).
-
-**Not an ad-hoc pre-step:** Do not call `+list_metrics` just to prepare normal ad-hoc analysis. Pass the saved metric wording directly in `analysis adhoc run/export --definition`; the backend compiler resolves saved metric names internally. If compilation fails, stop and ask for clarification instead of using this command as a fallback.
-
-## Use Cases
-- List metric metadata in the project. Supports keyword filtering and returns metric IDs, names, display names, model types, remarks, and related metadata, but not metric calculation results.
-- Supports pagination with fields/limit/offset for payload governance.
-- Query performs fuzzy matching on metricName, metricDesc, and metricRemark.
-- Use this command for metric metadata management, metric editing, auditing, or when the user explicitly asks to inspect/search metric metadata. Do not use it merely to prepare an ad-hoc query.
-
-## Command
-```bash
-ae-cli analysis_meta +list_metrics --project_id <project_id>
-ae-cli analysis_meta +list_metrics --project_id <project_id> --query demo
-ae-cli analysis_meta +list_metrics --project_id <project_id> --query demo --fields '["metricId","metricName","metricDesc","metricRemark","metricMode"]' --limit 10 --offset 0
-ae-cli analysis_meta +list_metrics --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--query` / `-q` | No | Optional keyword filter. Fuzzy match on metricName, metricDesc, metricRemark. |
-| `--fields` | No | Optional fields to return. Supported: metricId, metricName, metricDesc, metricRemark, metricMode, authenticationStatus, openId, creator, creatorLoginName, updateOpenId, updateCreator, updateLoginName, createTime, updateTime. Default fields when omitted: metricId, metricName, metricDesc, metricRemark, metricMode, authenticationStatus. Invalid fields cause INVALID_FIELDS error. |
-| `--limit` | No | Optional limit. Default: 50, maximum: 200. |
-| `--offset` | No | Optional offset. Default: 0. |
-| `--authenticated_only` | No | When true, return only authenticated metrics. |
-
-## Decision Rules
-- Use `--authenticated_only true` only when the user explicitly asks for authenticated assets. `authenticationStatus` is `1` for authenticated and `0` for unauthenticated.
-- First run should only pass the required parameter (`--project_id`), and add optional parameters only after the path is confirmed to work.
-- For pagination, use `--limit` and `--offset` together. Default limit is 20.
-- Use `--fields` to select specific columns for lighter response payloads.
-- For ad-hoc analysis, do not search metrics here first. Pass the user-provided metric name directly to `analysis adhoc run/export`.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-
-## Next Steps After Failure
-- If the required parameter is missing, fall back to the smallest runnable command and fill it in (focus on `--project_id`).
-- If the result is empty, first confirm the project ID/keyword, then try loosening the filter conditions.
-- If INVALID_FIELDS error appears, check that all field names in `--fields` match the supported list.
-
-## Recommended Chaining
-- +list_metrics -> +create_metric -> +get_metric
-- For ad-hoc event metric query: analysis adhoc run/export

package/skills/ae-analysis/references/list_properties.md

@@ -1,47 +0,0 @@
-# analysis_meta +list_properties (Property Metadata Discovery)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metadata Query**
-
-## Constraints
-
-**Not an ad-hoc pre-step:** Do not call `+list_properties` just to prepare `analysis adhoc run/export`. Pass the user's property wording in the AI-facing `definition`; the backend compiler resolves it or returns a structured clarification/error. Use this command only when the user explicitly wants to inspect metadata or when a prior compiler error asks for disambiguation.
-
-## Use Cases
-- Read-only query for SYSTEM METADATA properties already effective in the project. Supports event/user scope. Do NOT use for tracking-plan metadata (bury/track program); that belongs to BuryProgramTool.
-- Read-only query for SYSTEM METADATA properties already effective in the project. Use when the user explicitly asks to inspect property metadata, not as a required preparation step for ad-hoc AI model construction.
-
-## Commands
-```bash
-ae-cli analysis_meta +list_properties --project_id <project_id>
-ae-cli analysis_meta +list_properties --project_id <project_id> --scope event --event_name purchase --query demo
-ae-cli analysis_meta +list_properties --project_id <project_id> --query demo --fields '["propId", "propName", "propDesc", "remark", "selectType", "tableType"]' --limit 50 --offset 0
-ae-cli analysis_meta +list_properties --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--scope` | No | Optional property scope. event means event properties, user means user properties. If omitted, all scopes are queried. |
-| `--event_name` | No | Optional event name. If provided, only event properties available for that event are returned. |
-| `--query` / `-q` | No | Optional keyword filter. Fuzzy match is applied to propName, propDesc, and remark; if omitted, all matched properties are returned. |
-| `--fields` / `-f` | No | Optional fields to return (JSON array). Supported fields: `propId`, `propName`, `propDesc`, `remark`, `selectType`, `tableType`, `subTableType`, `authenticationStatus`. Default fields when omitted: `propId`, `propName`, `propDesc`, `remark`, `selectType`, `tableType`, `authenticationStatus`. |
-| `--limit` / `-l` | No | Optional page size. Default: 50, maximum: 200. |
-| `--offset` / `-o` | No | Optional page offset. Default: 0. |
-| `--authenticated_only` | No | When true, return only authenticated properties. |
-
-
-## Decision Rules
-- Use `--authenticated_only true` only when the user explicitly asks for authenticated assets. `authenticationStatus` is `1` for authenticated and `0` for unauthenticated.
-- For the first run, pass only the required parameter (`--project_id`) to confirm the path works, then add optional parameters.
-- For ad-hoc analysis, pass the user's property wording in the AI-facing `definition` instead of pre-querying property metadata.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-
-## Next Steps After Failure
-- If required parameters are missing, fall back to the smallest runnable command and fill them in first (focus on `--project_id`).
-- If the result is empty, first confirm the project ID/keyword, then try loosening the filter conditions.
-
-## Recommended Chaining
-- +list_properties -> +create_virtual_property

package/skills/ae-analysis/references/update_metric.md

@@ -1,58 +0,0 @@
-# analysis_meta +update_metric (Update Metric)
-
-> **Prerequisite:** Follow the Global AE CLI Rules in [`../SKILL.md`](../SKILL.md).
-
-Domain: **Metadata Query**
-
-## Use Cases
-- Before updating `events` / `params`, you must supplement the payload with real event/property metadata.
-- Update a metric definition. Currently only the event and retention models are supported. Returns the updated metric information without executing metric calculation.
-- Update a metric definition.
-
-## MUST Prerequisites
-- Before updating `--events` / `--params`, you must first read and follow these reference documents:
-  - [`./list_events.md`](./list_events.md)
-  - [`./list_properties.md`](./list_properties.md)
-- Do not submit new `events` / `params` until the document review and prerequisite command calls above are complete.
-
-## Prerequisite Call Chain (Required for Updating events/params)
-1. Determine `--model_type` first (`event` / `retention`).
-2. Read `list_events.md`, then call `ae-cli analysis_meta +list_events --project_id <project_id>`.
-3. Read `list_properties.md`, then call `ae-cli analysis_meta +list_properties --project_id <project_id>`.
-4. Build the new `events` / `params` from the metric API payload shape and verified metadata, then execute `+update_metric`.
-
-## Commands
-```bash
-ae-cli analysis_meta +update_metric --project_id <project_id> --metric_id 1 --name demo --display_name demo --model_type event --events '[]'
-ae-cli analysis_meta +update_metric --project_id <project_id> --metric_id 1 --name demo --display_name demo --remark demo --model_type event --events '[]' --params '{}'
-ae-cli analysis_meta +update_metric --dry-run
-```
-
-## Parameters
-| Parameter | Required | Description |
-|---|---|---|
-| `--project_id` / `-p` | Yes | Project ID |
-| `--metric_id` / `-m` | Yes | Metric ID |
-| `--name` | Yes | Metric name. Must start with a lowercase letter and contain only lowercase letters, digits, and underscores. Maximum length: 80. |
-| `--display_name` | Yes | Metric display name |
-| `--remark` | No | Optional metric remark |
-| `--model_type` | Yes | Metric model type. Currently supports event and retention. |
-| `--events` | Yes | Metric event JSON. Use fields validated by `analysis_meta +list_events` / `analysis_meta +list_properties` in the same `project_id`. |
-| `--params` | No | Metric params JSON. If provided, use project metadata from `analysis_meta +list_events` / `analysis_meta +list_properties`. |
-
-## Decision Rules
-- `events` / `params` must not be handwritten by intuition alone: they must satisfy the metric API payload shape and the project's real metadata constraints.
-- Set `--model_type` first, then use the matching schema; do not mix event/retention structures.
-- Before calling `list_events` / `list_properties`, you must first study the corresponding reference documents.
-- The smallest valid request still requires `--project_id`, `--metric_id`, `--name`, `--display_name`, `--model_type`, and `--events`; do not omit the new definition to “test the path.” Use `--dry-run` with the complete request for preflight.
-- Wrap JSON parameters in single quotes (for example `--events '{}'` and `--params '{}'`) to avoid shell escaping issues.
-- For cross-project troubleshooting, first confirm whether `--project_id` matches the current permissions and target environment.
-- This is an ordinary `write` operation and does not require CLI confirmation.
-
-## Next Steps After Failure
-- If required parameters are missing, complete all required fields listed above before retrying.
-- If `Invalid JSON` appears, first check required fields, then verify whether the event and property names come from metadata query results in the same `project_id`.
-- If the result after writing does not match expectations, immediately reread the corresponding list/get interfaces for before-and-after comparison.
-
-## Recommended Chaining
-- +list_metrics -> +get_metric -> +update_metric

package/dist/{chunk-HL2AJQ4Q.js → chunk-PTE56QPL.js}

@@ -18,13 +18,13 @@ function findGatewayDomain(cliService) {
   return cliServiceRoutes.get(cliService)?.gatewayDomain;
 }
 function resolveGatewayDomain(cliService, override) {
-  if (override !== void 0) {
-    return override;
-  }
   const envDomain = envGatewayDomain(cliService);
   if (envDomain !== void 0) {
     return envDomain;
   }
+  if (override !== void 0) {
+    return override;
+  }
   const route = cliServiceRoutes.get(cliService);
   if (!route) {
     throw new Error(