@thinkingai/ae-cli 6.0.32 → 6.0.33

package/skills/ae-community/references/community-data-report.md

@@ -0,0 +1,301 @@
+# Community Data Reporting
+
+Use `ae-cli community data report` to validate, normalize, and submit community records directly to an authorized Iris ingress endpoint. This is an ingestion data-plane command, not an AE analysis-host command.
+
+## Contents
+
+- [Safety and delivery contract](#safety-and-delivery-contract)
+- [Endpoint and identifiers](#endpoint-and-identifiers)
+- [Input modes](#input-modes)
+- [Chat example](#chat-example)
+- [Mixed payload example](#mixed-payload-example)
+- [Common record rules](#common-record-rules)
+- [Schemas](#schemas)
+- [Normalization](#normalization)
+- [Dry-run and output](#dry-run-and-output)
+- [Errors and retry policy](#errors-and-retry-policy)
+- [Privacy](#privacy)
+
+## Safety and delivery contract
+
+- The command has `risk: write`. A clear user request to report the data is sufficient; do not add `--yes` or ask for a second confirmation.
+- Run a redacted `--dry-run` before the first submission of a dataset.
+- A successful response means only that Iris queued the request. It does not prove that every record passed asynchronous processing or reached durable storage.
+- Never describe `status: "queued"` as accepted, imported, persisted, or queryable.
+- The client makes at most one POST, never follows redirects, and never retries automatically.
+- After a timeout, the delivery state is unknown. Check the downstream query or storage side before deciding whether a manual resubmission is safe.
+
+## Endpoint and identifiers
+
+The endpoint precedence is:
+
+1. `--endpoint`
+2. `AE_IRIS_SYNC_ENDPOINT`
+
+The endpoint must be a complete `http` or `https` URL whose path ends in `/sync_content`. It must not contain credentials, a query string, or a fragment. Never guess, concatenate, or derive this URL from `--host`; `--host` is unrelated to this command.
+
+Verify all three identifiers with the user or an authoritative system:
+
+| Flag | Iris field | Contract |
+|------|------------|----------|
+| `--space-id` | `game_id` | Positive signed int64 |
+| `--channel-id` | `channel_id` | Positive signed int64 |
+| `--source-id` | `source_id` | Positive signed int64 |
+
+The CLI reads these flags as strings to preserve precision, then emits JSON numeric values without quotes. It fixes `source_type` to `#standard` and `version` to `5.0.0`. `--zone-id` defaults to `Asia/Shanghai` and accepts a valid IANA time-zone ID.
+
+The reporting command does not provide a `--game-id` alias. It also does not accept `zone_offset` or top-level `timestamp`/`datetime` request overrides.
+
+## Input modes
+
+Choose exactly one mode:
+
+```text
+--data-type <type> --data <inline|path|@path|->
+--payload <inline|path|@path|->
+```
+
+`--data` accepts one record object or a non-empty record array. `--payload` accepts one segment object or a non-empty segment array. A segment has this shape:
+
+```json
+{
+  "data_type": "chat",
+  "data": [
+    { "chat_uuid": "example" }
+  ]
+}
+```
+
+Supported `data_type` values are `post`, `video`, `reply`, `danmu`, `live_room`, `live_interaction`, `chat`, and `interaction`.
+
+Before constructing records, run `ae-cli community data report --help`. The installed command's schema summary is the source of truth for the required fields of every supported `data_type`; use the schema sections below for field limits and normalization behavior.
+
+For either input flag:
+
+- Inline JSON is accepted for non-sensitive examples.
+- `@path/to/file.json` is the preferred, unambiguous file form.
+- A plain existing path is also accepted.
+- `-` reads JSON from stdin.
+- JSONL is not supported.
+
+## Chat example
+
+Store records in `chat.json` so message content does not enter shell history:
+
+```json
+[
+  {
+    "chat_uuid": "wecom-chat-0001",
+    "user_id": "user-001",
+    "user_name": "Example User",
+    "chat_room_type": "wecom_group",
+    "chat_room_id": "room-001",
+    "chat_room": "Example support group",
+    "content": "Example redacted message",
+    "publish_time": "2026-07-21 09:30:00",
+    "extras": {
+      "source": "wecom"
+    }
+  }
+]
+```
+
+Run the redacted preview, then submit only if the endpoint and IDs are verified:
+
+```bash
+ae-cli --dry-run community data report \
+  --endpoint https://<iris-ingress>/sync_content \
+  --space-id <space-id> \
+  --channel-id <channel-id> \
+  --source-id <source-id> \
+  --data-type chat \
+  --data @chat.json
+
+ae-cli community data report \
+  --endpoint https://<iris-ingress>/sync_content \
+  --space-id <space-id> \
+  --channel-id <channel-id> \
+  --source-id <source-id> \
+  --data-type chat \
+  --data @chat.json
+```
+
+## Mixed payload example
+
+Use `--payload` when one request contains multiple data types. For example, `mixed.json` can contain a post with a sidecar interaction plus a standalone interaction snapshot:
+
+```json
+[
+  {
+    "data_type": "post",
+    "data": [
+      {
+        "post_uuid": "post-0001",
+        "user_id": "author-001",
+        "title": "Example post",
+        "content": "Example body",
+        "publish_time": "2026-07-21 10:00:00",
+        "interaction": {
+          "collect_time": "2026-07-21 10:05:00",
+          "metrics": {
+            "views": 100,
+            "likes": 8
+          }
+        }
+      }
+    ]
+  },
+  {
+    "data_type": "interaction",
+    "data": [
+      {
+        "content_uuid": "post-0001",
+        "content_type": 0,
+        "collect_time": "2026-07-21 11:00:00",
+        "metrics": {
+          "views": "125",
+          "comments": 3
+        }
+      }
+    ]
+  }
+]
+```
+
+```bash
+AE_IRIS_SYNC_ENDPOINT=https://<iris-ingress>/sync_content \
+  ae-cli --dry-run community data report \
+  --space-id <space-id> --channel-id <channel-id> --source-id <source-id> \
+  --payload @mixed.json
+```
+
+## Common record rules
+
+- Each record and segment must be a JSON object; arrays must be non-empty.
+- Text fields accept only JSON strings. Numbers and booleans are not coerced to text.
+- Optional `null` fields are treated as omitted.
+- Unknown record fields are preserved.
+- Signed int64 inputs may be JSON integer numbers or canonical decimal strings. The wire body contains lossless, unquoted JSON numbers.
+- Fields constrained to non-negative int64 reject negative values, fractions, and values above `9223372036854775807`.
+- Date/time strings accept only `yyyy-MM-dd HH:mm:ss`, `yyyy-MM-dd HH:mm:ss.SSS`, `yyyy-MM-dd HH:mm`, or `yyyy-MM-dd` where the field permits a date-only value.
+- `extras` and `user_extra` accept an object or a JSON-encoded object string. Missing, null, or invalid values normalize to `{}`. Serialized `user_extra` must not exceed 1024 UTF-16 code units.
+- `subtitle` accepts an object array or a JSON-encoded object array. Every element must be an object.
+- Lengths and truncation use UTF-16 code units, matching Iris/Java string behavior.
+- A field with an Iris truncation fallback is truncated and counted in normalization statistics. An overlong field without a fallback is rejected.
+
+## Schemas
+
+Only the key ingestion constraints are listed below. Unknown fields remain on the record after validation.
+
+### `post`
+
+Required: `post_uuid`, a string no longer than 32 UTF-16 code units.
+
+Optional normalized fields include `user_id` (64), `user_name` (80), `title` (200), `content` (65533), `publish_time`, and `extras`. Values in parentheses are truncation limits. An optional `interaction` sidecar requires `collect_time` and a non-empty `metrics` object using the same metric rules as standalone `interaction` with `content_type=0`.
+
+### `video`
+
+Required: `video_uuid`, a string no longer than 32 UTF-16 code units.
+
+Optional normalized fields include `user_id` (64), `user_name` (80), `title` (1000), `description` (65533), `publish_time`, `subtitle`, and `extras`. An optional `interaction` sidecar uses the standalone metric rules with `content_type=1`.
+
+### `reply`
+
+Required: `reply_uuid` (maximum 32), `root_id` (maximum 32), and `root_type`, which must be `post`, `video`, or `live`.
+
+Optional normalized fields include `user_id` (64), `user_name` (80), `content` (65533), `publish_time`, `parent_id` (32), and `extras`.
+
+### `danmu`
+
+Required: `danmu_uuid` (maximum 32), non-negative int64 `timestamp`, `root_id` (maximum 32), and `root_type`, which must be `post`, `video`, or `live`.
+
+Optional normalized fields include `user_id` (64), `user_name` (80), `content` (65533), and `publish_time`.
+
+### `live_room`
+
+Required: non-negative int64 `uuid`, `room_id` (maximum 32), `room_name` (maximum 80), `room_avatar` (maximum 65533), non-negative int64 `fans`, and date/time `timestamp`.
+
+Optional room/stream fields include `room_type` (truncated to 128), `stream_cover` (65533), `stream_title` (80), `stream_status`, `stream_start_time`, `stream_end_time`, and `stream_notice` (maximum 255, rejected if longer). Missing or `2` `stream_status` becomes `0`; only normalized values `0` and `1` are allowed.
+
+The optional metrics `online`, `heat`, `noble_count`, `guardian_count`, `diamond_fan_count`, and `dfans_count` are non-negative int64 values. At most one of the three guardian aliases may be present. If stream details or metrics are present, `stream_start_time` is required and must include a time component; a date-only value is rejected. The derived `stream_id` must not exceed 64 UTF-16 code units, and every derived metric ID (`uuid * 5 + metric_type`) must remain within signed int64 range.
+
+### `live_interaction`
+
+Required: non-negative int64 `uuid`, `activity_type`, `activity_content`, `room_id`, `stream_start_time`, and date/time `timestamp`.
+
+`activity_type` must be `danmu`, `gift`, `superchat`, or `premium`. `activity_content` is truncated to 1024. `room_id` is at most 32. `stream_start_time` must include a time component. Optional normalized fields include `user_id` (80), `user_name` (80), and `user_extra`.
+
+### `chat`
+
+The six required string fields are:
+
+| Field | Limit |
+|-------|-------|
+| `chat_uuid` | 36 UTF-16 code units; overlong values are truncated |
+| `user_id` | 80 |
+| `chat_room_type` | 16; no enum restriction |
+| `chat_room_id` | 80 |
+| `content` | 65533 |
+| `publish_time` | One supported date/time format |
+
+Optional normalized fields are `user_name`, `chat_room`, `chat_server`, and `chat_server_id` (each 80), plus `extras`.
+
+`chat_uuid` is a required JSON string. If it exceeds 36 UTF-16 code units, the client keeps the first 36 units and reports the change under `chat.chat_uuid` in the normalization statistics; it does not reject the record for length. Supply source identifiers that already fit the limit to avoid truncation changing record identity or collapsing distinct identifiers to the same normalized value.
+
+### `interaction`
+
+Required: `content_uuid` (maximum 32), integer `content_type` from 0 through 7, `collect_time`, and a non-empty `metrics` object.
+
+Every metric value must be a non-negative int64. A single invalid metric rejects the whole record; it is never silently dropped. Metric names must match `content_type`:
+
+| `content_type` | Meaning | Allowed metric names |
+|----------------|---------|----------------------|
+| `0`, `1` | post, video | `views`, `likes`, `comments`, `shares`, `favorites`, `coins`, `danmaku`, `dislikes` |
+| `2`-`6` | live, chat, comment, reply, danmu | `favorites`, `coins`, `danmaku`, `dislikes` |
+| `7` | user | `followers`, `total_views`, `total_likes` |
+
+## Normalization
+
+The CLI normalizes the input before dry-run or submission:
+
+- A single record becomes a one-element `data` array; a single segment becomes a one-element `payload` array.
+- Fixed request metadata is `source_type: "#standard"` and `version: "5.0.0"`.
+- Integer strings become lossless JSON numeric literals.
+- Optional `null` properties are removed.
+- Fields with Iris truncation fallbacks are truncated by UTF-16 code units.
+- Invalid or missing `extras`/`user_extra` becomes `{}`; encoded objects and `subtitle` arrays become native JSON structures.
+- Missing or legacy `stream_status: 2` becomes `0`.
+
+The summary counts truncated, defaulted, and integer-converted fields without exposing their original values.
+
+## Dry-run and output
+
+`--dry-run` performs local parsing, schema validation, and normalization, but sends no network request. Its redacted output contains endpoint, data types, segment/record counts, encoded byte count, and normalization statistics. It never prints the business payload.
+
+A successful live submission has these semantics:
+
+```json
+{
+  "status": "queued",
+  "persistence_verified": false,
+  "next_step": "After asynchronous processing, verify the submitted record identifiers through an authorized downstream query or storage path before treating this submission as persisted."
+}
+```
+
+The complete output also reports submission counts and normalization statistics. Treat them as submitted-to-queue counts, not per-record acceptance counts. Iris does not currently return a query URL or trace ID in this response, so the CLI does not invent one; use the submitted identifiers with an authorized downstream query or storage path.
+
+## Errors and retry policy
+
+- Input, schema, file, identifier, and endpoint failures use a `validation` error envelope. Locations identify segment, record, and field but do not echo the invalid business value.
+- Iris HTTP 400 errors expose the safe `return_message` when available.
+- HTTP 5xx responses, non-JSON responses, missing `return_code`, non-zero `return_code`, redirects, and buffer-full responses use a standard API error envelope. Server stack traces are not echoed.
+- The request timeout is 30 seconds. A timeout does not establish whether Iris queued the request.
+- Never automate a retry. For timeout or ambiguous transport failure, check downstream state first and ask the user before any deliberate resubmission.
+
+## Privacy
+
+- Prefer `@file` or stdin for chat text, usernames, identifiers, and other sensitive content. Inline JSON can remain in shell history or process listings.
+- The reporting client sends only `Content-Type: application/json` and `Accept: application/json`. It does not send AE access tokens, CLI tokens, or custom authorization headers.
+- Request and response bodies are excluded from CLI HTTP logs. Logs contain only endpoint, status, and byte counts.
+- Dry-run output is redacted by default. Do not paste raw records into reports or error explanations.
+- An endpoint URL must not contain embedded credentials, query parameters, or fragments.

package/skills/ae-dataops/SKILL.md

@@ -39,8 +39,9 @@ Global parameters:
 | `--host <url>` | Override the active AE host. Available on every command and may be placed after the subcommand, e.g. `ae-cli dataops_ide +<command> --host <url>`. |
 
 Output and errors:
-- Successful commands return machine-readable JSON by default.
+- Successful commands return machine-readable JSON by default. Envelope may include optional `_notice.host_compat`.
 - Failed commands return `{ "ok": false, "error": { "type": "...", "message": "...", "hint": "..." } }` and exit non-zero.
+- **CRITICAL — Host compat (do this first):** After each `ae-cli` run, check stderr and `_notice.host_compat`. If either is present, open the user reply with a short ⚠️ version warning and **quote the `npm i -g` / `npx skills add` (or update-cluster) lines verbatim**, then present the business result. Soft tip; `ok: true` can still carry the notice.
 
 Safety constraints:
 - Read commands can execute directly after required IDs and references are verified.

package/skills/ae-engage/SKILL.md

@@ -21,8 +21,9 @@ Global parameters:
 | `--host <url>` | Override the active AE host. Available on every command and may be placed after the subcommand, e.g. `ae-cli engage +<command> --host <url>`. |
 
 Output and errors:
-- Successful commands return machine-readable JSON by default.
+- Successful commands return machine-readable JSON by default. Envelope may include optional `_notice.host_compat`.
 - Failed commands return `{ "ok": false, "error": { "type": "...", "message": "...", "hint": "..." } }` and exit non-zero.
+- **CRITICAL — Host compat (do this first):** After each `ae-cli` run, check stderr and `_notice.host_compat`. If either is present, open the user reply with a short ⚠️ version warning and **quote the `npm i -g` / `npx skills add` (or update-cluster) lines verbatim**, then present the business result. Soft tip; `ok: true` can still carry the notice.
 
 Safety constraints:
 - Read commands can execute directly after required IDs and references are verified.

package/skills/ae-generate-tracking-code/SKILL.md

@@ -118,15 +118,15 @@ First, check if both `.ae-cli/draft.json` and `.ae-cli/draft.xlsx` exist:
    - Reference: tracking plan document (Feishu: https://www.feishu.cn/docx/Jt0VdhNB6oSJ4TxISs1cq2Ebnmg)
 
 2. **If you already have a tracking plan**
-   - Provide the xlsx file path and use `ae-cli tracking code import-xlsx` to import
+   - Provide the xlsx file path and use `ae-cli tracking code import-template --template` to import
    - Or place the xlsx file at `.ae-cli/draft.xlsx` and re-run
 
-**If xlsx file exists** (provided via `ae-cli tracking code import-xlsx` or placed at `.ae-cli/draft.xlsx`):
+**If xlsx file exists** (provided via `ae-cli tracking code import-template --template` or placed at `.ae-cli/draft.xlsx`):
 
 **Step 1: Parse the xlsx file**
 
 ```bash
-ae-cli tracking code import-xlsx --xlsx <xlsx-path> --out .ae-cli/draft.json
+ae-cli tracking code import-template --template <xlsx-path> --out .ae-cli/draft.json
 ```
 
 This command:
@@ -155,7 +155,7 @@ This command:
 - `服务端` / `server` → server-only collection, parsed as `platform: "server"`
 - `客户端,服务端` / `client,server` / `服务端,客户端` / `server,client` → both platforms, parsed as `platform: "both"`
 
-**Internal representation**: xlsx "Platform" column values are parsed by `ae-cli tracking code import-xlsx` into internal `platform` field values:
+**Internal representation**: xlsx "Platform" column values are parsed by `ae-cli tracking code import-template --template` into internal `platform` field values:
 - `client` → client-side collection
 - `server` → server-side collection
 - `both` → both platforms

package/skills/ae-generate-tracking-plan/SKILL.md

@@ -33,8 +33,9 @@ description: "Interactive generation of an AE tracking plan and upload. Trigger
 | 用户属性 | User Property | Property on the user profile (persistent state) |
 | 预置属性 | Preset Property | System property prefixed with `#` (`#device_id`, `#time`, etc.) |
 | 自动采集事件 | Auto-track Event | SDK auto-collected events (`ta_app_start`, `ta_page_show`, etc.) |
-| 系统事件 | System Event | Auto-track event tag category |
-| 业务事件 | Business Event | Custom business event tag category |
+| 系统事件 | System Event | event_tag value reserved for SDK auto-track events (`ta_*`). One of two non-module tags (together with 基础事件). |
+| 基础事件 | Basic | event_tag value for account-level lifecycle/progression events (register, login, level_up, create_role, etc.). Not tied to any functional module. |
+| 功能模块 | Functional Module | event_tag value for feature-specific business events; identifies which module the event belongs to (e.g. Battle, Shop, Ads, Payment, Basic) |
 | SDK 集成模式 | SDK Integration Mode | `client_only` / `server_only` / `both` / `none` |
 | 客户端平台 | Client Platform | Android, iOS, Web, Unity, Mini-program, etc. |
 | 服务端语言 | Server Language | Java, Python, Go, Node.js, PHP, etc. |
@@ -54,7 +55,7 @@ description: "Interactive generation of an AE tracking plan and upload. Trigger
 | xlsx 格式契约 | xlsx Format Contract | Column rules for AE-compatible Excel generation |
 | draft.json | draft.json | Internal intermediate representation (JSON) of the tracking plan |
 | display_name | Display Name | Human-readable name in the user's language |
-| event_tag | Event Tag | Category label for grouping events |
+| event_tag | Event Tag | Functional module the event belongs to (e.g. Battle, Shop, Ads, Payment). Auto-track events use "System Event". |
 | snake_case | snake_case | Canonical naming format: `lowercase_with_underscores` |
 
 ## When to Trigger
@@ -88,7 +89,7 @@ Phase 0 → 1 → 2 → 3 → 4, do not skip steps.
 > All subsequent CLI commands must be prefixed with `AE_LANG=<user_lang>` to ensure CLI output and generated xlsx headers match the user's language.
 > When uploading the xlsx, pass `--lang <user_lang>` as well; it must match `draft.meta.lang` / the generated xlsx language.
 
-Collect the following **4 items** sequentially, **do NOT ask all at once**:
+Collect the following **5 items** sequentially, **do NOT ask all at once**:
 
 ### Item 1 — Application Scenario
 
@@ -111,8 +112,9 @@ Choose your source material (up to 2):
 2 - Detailed description (conversational) — Describe app business flow, core features, user behaviors, monetization model, etc.
 3 - Codebase (local project path; hidden in sandbox) — Analyze source code to extract events and properties
 4 - Pre-built template (built-in industry and game genre templates) — Select a built-in template
+5 - Modify existing tracking plan (local AE format xlsx file) — Import an existing tracking plan xlsx as baseline for modification; can be combined with Product doc / Description / Codebase, but NOT with Pre-built template
 
-Reply with number(s), e.g. 1 or 1,4. Select up to 2.
+Reply with number(s), e.g. 1,5 or 4. Select up to 2.
 ```
 
 If in a sandbox environment, ask exactly:
@@ -123,8 +125,9 @@ Choose your source material (up to 2):
 1 - Product document (sandbox workspace path, uploaded attachment, URL, image file, or folder) — Extract events and properties from product docs; supports md/pdf/docx/URL/images (png/jpg/jpeg/webp). You can attach/upload relevant files here.
 2 - Detailed description (conversational) — Describe app business flow, core features, user behaviors, monetization model, etc.
 3 - Pre-built template (built-in industry and game genre templates) — Select a built-in template
+4 - Modify existing tracking plan (sandbox workspace path) — Import an existing tracking plan xlsx as baseline for modification; can be combined with Product doc / Description, but NOT with Pre-built template
 
-Reply with number(s), e.g. 1 or 1,3. Select up to 2.
+Reply with number(s), e.g. 1,4 or 3. Select up to 2.
 ```
 
 Do not rewrite this source material list as unnumbered bullets, cards, or prose. The user must be able to reply with the visible numbers.
@@ -147,9 +150,11 @@ Based on user selection, determine source material type and record to `meta.sour
 | Description only | `chat` | Construct events in Draft phase based on description |
 | Codebase only | `codebase` | Scan source code, extract events/properties from business logic |
 | Template only | `template` | Provide built-in template selection |
-| Any two-item combo | Join two types with `_` | First as baseline, second as supplement (priority: template → codebase → prd → chat) |
+| Existing plan only | `existing_plan` | Import xlsx as baseline (see "Modify Existing Tracking Plan Flow" below) |
+| Any two-item combo | Join two types with `_` | First as baseline, second as supplement (priority: existing_plan → template → codebase → prd → chat) |
+| Existing plan + Pre-built template | **NOT allowed** | Both provide event baselines; semantic conflict |
 
-**Follow-up questions** (ask in selection order):
+**Follow-up questions** (ask in follow-up order defined in Multi-Source Combination Rules below):
 - Product doc → if not in a sandbox environment, ask exactly:
   ```text
   What is the product document path?
@@ -176,6 +181,49 @@ Based on user selection, determine source material type and record to `meta.sour
 - Detailed description → If too vague, follow up on core features, user behaviors, business flows, monetization
 - Codebase → ask **"What is the project directory path?"**, then scan source to extract business logic
 - Pre-built template → display matching templates for user confirmation
+- Modify existing tracking plan → ask **"Please provide the xlsx file path of your existing tracking plan"**, then follow the flow below
+
+**Modify Existing Tracking Plan Flow** (when user selects this option):
+
+1. **Import**: Ask user for the file path, then immediately import:
+   ```bash
+   AE_LANG=<user_lang> ae-cli tracking code import-template --template <path> --out .ae-cli/draft.json
+   ```
+2. **Check result**:
+   - If CLI errors (file not found / parse failure) → report error, ask user to fix the file and retry
+   - If `draft.json` has `events` array empty → 🛑 **Severe: No AE-format sheets found** (missing `#` prefix sheets like `#事件数据`). Tell user the file does not appear to be an AE tracking plan xlsx. User must fix the original file and re-import.
+3. **Content validation** (when events are non-empty):
+   ```bash
+   AE_LANG=<user_lang> ae-cli tracking plan validate --in .ae-cli/draft.json --fix
+   ```
+4. **Handle validation results by severity**:
+   - If validate passes with **no issues at all** → skip to Step 5.
+
+   | Severity | Examples | Handling | User Action |
+   |---|---|---|---|
+   | 🔧 **Minor** (auto-fixable) | `display_name` duplicate, `array_row` sub-property inconsistency, event name duplicate | `--fix` auto-fixes, writes to `draft.json`. Inform user of what was fixed. | None (informed) |
+   | ⚠️ **Medium** (needs confirmation) | snake_case violation, property name duplicate, invalid property type, nested property parent is not a composite type | List each issue with current value → suggested fix. User confirms item by item before writing to `draft.json`. | Confirm each fix |
+   | 🛑 **Severe** | File cannot be parsed, or events array is empty after import | Reject. Tell user the specific issue. User fixes **original file** and re-imports. | Fix original file |
+
+   **Medium issue confirmation format**:
+   ```
+   ⚠️ The following content needs to be fixed:
+
+   | # | Issue | Location | Current | Suggested |
+   |---|-------|----------|---------|------------|
+   | 1 | snake_case | event_name | UserLogin | user_login |
+   | 2 | snake_case | prop_name | vipLevel | vip_level |
+   | 3 | invalid type | property "level" | integer | number |
+
+   Apply all suggested fixes? ok / specify per item / skip
+   ```
+   - `ok` → apply all suggested fixes to `draft.json`
+   - `specify per item` → confirm each item one by one
+   - `skip` → keep current values, handle in Refine phase later
+
+   ⚠️ **Never modify the user's original xlsx file.** All changes go into `draft.json`.
+
+5. **Re-validate** after fixes → loop until clean, then continue to the next follow-up question (if combined with another source material), or Item 3 (if existing_plan is the only source).
 
 **Codebase analysis flow** (when source_type includes `codebase`):
 
@@ -196,9 +244,11 @@ After source material is confirmed, **must** process business dimension info bas
 | source_type | Handling |
 |---|---|
 | `template` | Directly display template's inherited business dimensions; skip detailed inference |
+| `existing_plan` | Infer business dimensions from existing plan content (analyze event modules, payment events, currency properties); follow up on missing items; event injection preview |
 | `prd` / `codebase` / `chat` | Infer business dimensions → follow up on missing items → event injection preview |
+| Combo (e.g. `template_prd`) | See detailed rules below — baseline source's method is primary, supplementary source contributes additional context |
 
-**If source_type = template**:
+**If source_type is template or starts with template_** (covers `template`, `template_prd`, `template_codebase`, `template_chat`):
 
 Display template's preset business dimensions:
 
@@ -215,6 +265,27 @@ Confirm using these business dimensions? ok / modify
 
 - User `ok` → proceed to next step
 - User says "modify" → switch to prd/chat flow for user to supplement
+- For combos (e.g. `template_prd`): after confirming template dimensions, also note any supplementary insights from `prd`/`chat` as context for Phase 1.2.
+
+**If source_type includes existing_plan**:
+
+Infer business dimensions from the imported plan content:
+
+1. **Analyze existing events**: Examine `event_tag` values to identify functional modules (e.g. events tagged "Battle" → 战斗 module). Examine event names for payment/ad-related patterns to infer revenue model.
+2. **Inference display**: Format inference results as a summary:
+   ```
+   Business Dimension (inferred from existing plan: <filename>)
+
+   Revenue Model: <inferred from payment/ad events>
+   Core Loop: <inferred from event flow>
+   Functional Entries: <inferred from event_tag values>
+   Currency System: <inferred from currency-related properties>
+
+   Confirm these business dimensions? ok / modify
+   ```
+3. **Follow up missing**: Only ask about items that could not be inferred
+4. **Event injection preview**: Show suggested injected event modules (only add events not already in the plan); user `ok` to proceed
+- For combos (e.g. `existing_plan_prd`): after confirming dimensions from the plan, also note any supplementary insights from `prd`/`chat` as context for Phase 1.2.
 
 **If source_type is prd / codebase / chat**:
 
@@ -224,7 +295,7 @@ Confirm using these business dimensions? ok / modify
 
 Platform validation: Use `business-dimension-mapping.md` Chapter 5 decision rules to check if injected events' platform assignments are reasonable.
 
-**Template matching** (prd / codebase / chat scenarios, optional):
+**Template matching** (prd / codebase / chat scenarios, optional; **NOT applicable to existing_plan or template scenarios**):
 
 After business dimension confirmation, auto-detect matching templates based on app type:
 ```bash
@@ -233,6 +304,51 @@ AE_LANG=<user_lang> ae-cli tracking plan list-templates --json
 
 Show matching templates to user for confirmation. Confirmed templates serve as baseline and participate in Phase 1 event merging.
 
+### Multi-Source Combination Rules (when user selects 2 source materials)
+
+**Follow-up Order** (Phase 0 questioning sequence):
+
+Do **not** follow user's selection order. Instead, use this order:
+
+```
+existing_plan（blocking validation, always first）→ codebase/prd（user's selection order）→ chat → template
+```
+
+Rationale:
+- `existing_plan` must go first — import + validate may require the user to fix their file; processing it early avoids wasted context
+- `codebase` / `prd` — directly reflect actual business requirements, prioritized over generic descriptions and templates
+- `chat` — conversational description, supplements business context
+- `template` — generic industry template, least specific to the user's business
+
+Source material processing happens primarily in Phase 1.2 (Merge Source Materials). The one exception is `existing_plan`: it is imported and validated in Phase 0 because user-provided files may need fixing before proceeding. All other sources are processed in Phase 1.2 per their standard flow.
+
+Merge priority (Phase 1.2): `existing_plan → template → codebase → prd → chat → autotrack`
+Earlier sources take precedence — same-name events keep the earlier version, later sources only add new events or merge `prop_names` without overwriting.
+
+**Business Dimension Inference (combined scenarios)**:
+
+Use the baseline source's inference method as primary. Supplementary sources (especially prd/chat) may contribute additional information — present a merged view for user confirmation.
+
+**Valid Combinations**:
+
+> The "Baseline" column identifies which source has higher merge priority (see Phase 1.2 merge order), which may differ from the user's selection order. Follow-up questioning uses the fixed order in "Multi-Source Combination Rules" above, not the user's selection order.
+
+| Baseline | Supplementary | Phase 0 for supplementary |
+|---|---|---|
+| existing_plan | codebase | Collect path + quick tech stack detection |
+| existing_plan | prd | Collect path |
+| existing_plan | chat | Collect description; participates in dimension inference |
+| template | codebase | Collect path + quick tech stack detection; template matching/import deferred to Phase 1.2 |
+| template | prd | Collect path; template matching/import deferred to Phase 1.2 |
+| template | chat | Collect description |
+| codebase | prd | Collect path |
+| codebase | chat | Collect description |
+| prd | chat | Collect description |
+| codebase | template | Same as template+codebase row above (template is baseline per merge priority) |
+| prd | template | Same as template+prd row above (template is baseline per merge priority) |
+
+**Forbidden**: `existing_plan + template` (both provide event baselines; semantic conflict).
+
 **Record business dimension info to `meta.business_dimension`**:
 ```json
 "business_dimension": {
@@ -493,8 +609,11 @@ Draft
 
 ### 1.2 Merge Source Materials
 
-Priority from low to high: **template → codebase → prd → chat → autotrack**
+Merge order: **existing_plan → template → codebase → prd → chat → autotrack**
 
+Earlier sources take precedence — same-name events keep the earlier version, later sources only add new events or merge `prop_names` without overwriting.
+
+- **existing_plan**: Already imported and validated in Phase 0 (see "Modify Existing Tracking Plan Flow"). Events are in draft.json as the baseline; each item marked `source: "existing_plan"`. Higher-priority sources supplement with new events only; same-name events keep the existing_plan version.
 - **template**: User-selected industry template (see "Template Lookup Convention" below) as baseline; each item marked `source: "template"`
   - Templates are resolved by ae-cli from the ae-cli package root and user template directory
   - Import command: `AE_LANG=<user_lang> ae-cli tracking code import-template --template-name "<template name>" --out .ae-cli/draft.json`
@@ -657,6 +776,8 @@ AE_LANG=<user_lang> ae-cli tracking plan draft --in .ae-cli/draft.json --out .ae
 
 **Note**: Display names can be the same across different property pools (e.g. `vip_level` can be both an event property and a user property).
 
+> **Relationship to Phase 0 existing_plan validation**: The underlying rule engine is the same, but Phase 0 uses **interactive 3-tier** (Minor/Medium/Severe) because the user is present to confirm each fix. Phase 1.6 uses **batch 2-tier** (auto-fixable / manual-fix-needed) because it runs as part of the automated draft generation. Rules that are "Medium (needs confirmation)" in Phase 0 appear as "❌ Manual fix needed" here — the same rule, just without the interactive prompt.
+
 ### 1.7 Show Summary
 
 Display to user via markdown table: event count / event property pool size / super property count / user property count; show deliverable paths.