Ae Generate Tracking Plan

ae-generate-tracking-plan

Conversation language: This skill document is in English, but all output to the user MUST be in the user's input language. English input → English reply; Chinese input → Chinese reply; Japanese input → Japanese reply. If uncertain, default to English. This applies to all output: section titles, phase names, template prompts, example text, option lists, etc. ⚠️ CRITICAL: Template localization is CLI-owned. Do NOT manually translate imported template content with the model. Use the src/tracking/i18n module as the source of truth by setting AE_LANG=<user_lang>, writing draft.meta.lang, and regenerating through ae-cli tracking code import-template / ae-cli tracking plan draft. Before changing any template-owned localized label, first look up the corresponding translation in src/tracking/i18n (for example resources/xlsx/sheets.ts, resources/xlsx/headers.ts, resources/xlsx/types.ts, and resources/cli/*.json). If no matching translation exists there, preserve the imported text and ask before rewriting business semantics. Do NOT copy Chinese text verbatim from this document into English/Japanese replies unless it is an identifier, template name needed for CLI import, or original source material quoted for traceability.

Terminology Glossary

When to Trigger

Trigger when user mentions: "tracking plan / tracking template / AE plan / help me create tracking" etc. App types covered: H5 / Web / iOS / Android / Mini-program / Unity. Follow strictly Phase 0 → 1 → 2 → 3 → 4, do not skip steps.

Phase 1 / 3 / 4 are executed via ae-cli tracking CLI (ae-cli tracking plan draft / ae-cli auth login / ae-cli tracking plan upload / ae-cli tracking plan delete). All CLI commands must be prefixed with AE_LANG=<user_lang> (e.g. AE_LANG=en ae-cli tracking plan draft ...), ensuring CLI output messages and generated xlsx headers match the user's language. Upload commands MUST also pass --lang <user_lang> so the server parses the uploaded xlsx with the same sheet/header language.

Language rules: For newly generated content, user-facing fields in draft.json (display_name, event_desc, event_tag, property display_name, property desc, etc.) should be generated in the user's input language. Every event, event property, common event property, and user property must have a non-empty display_name. A canonical snake_case identifier is not a substitute for a user-facing display name. For imported templates, do NOT translate those fields manually. Template sheet names, headers, property type display values, CLI messages, and auto-track/i18n-owned labels must come from src/tracking/i18n via AE_LANG=<user_lang> and draft.meta.lang. When a localized label is needed, inspect src/tracking/i18n and use the existing resource key/value; do not invent translations from the model. If template business text needs localization and the CLI/i18n resources do not provide it, preserve the imported text and ask the user before rewriting business semantics. Only identifier fields like event_name, prop_name remain in English snake_case (canonical format). This skill only cares about command behavior, not internal implementation.

Phase 0 — Anchor (one question per message)

Step 1: Language initialization

Determine <user_lang> from user's input language: Chinese→zh, English→en, Japanese→ja, Korean→ko. Other languages default to en. 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 5 items sequentially, do NOT ask all at once:

Item 1 — Application Scenario

Ask: "What is your application's business scenario? One sentence summary, e.g.: An e-commerce website where users browse products and place orders"

After user responds, record to meta.scenario and generate meta.plan_name.

Item 2 — Source Material + Business Dimension (combined)

Before asking, decide whether the current runtime is an agent sandbox. The agent may judge this from runtime context such as sandbox-provisioned cli-token.json, restricted filesystem access, or absence of the user's local files. Do not ask the user just to decide sandbox visibility.

Product document is available in sandbox environments only for files that are readable inside the sandbox workspace, including files the user attaches/uploads into the conversation workspace. It cannot read arbitrary local paths outside the sandbox unless those files are mounted or attached. Codebase is a local-material option and must be hidden in sandbox environments unless the codebase is already present in the readable workspace. When options are hidden, renumber the visible list contiguously from 1; never show skipped numbers.

If not in a sandbox environment, ask exactly:

Choose your source material (up to 2):

1 - Product document (local path, image file, or folder) — Extract events and properties from product docs; supports md/pdf/docx/URL/images (png/jpg/jpeg/webp)
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
6 - Data sample / file profile (from ae-data-integration inspect) — Map data columns (CSV/Excel/JSONL) to events & properties from an inspect profile; single-source path, not combinable with other options

Reply with number(s), e.g. 1,5 or 4. Select up to 2 (option 6 is single-source).

If in a sandbox environment, ask exactly:

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
5 - Data sample / file profile (from ae-data-integration inspect) — Map data columns (CSV/Excel/JSONL) to events & properties from an inspect profile; single-source path, not combinable with other options

Reply with number(s), e.g. 1,4 or 3. Select up to 2 (option 5 is single-source).

Do not rewrite this source material list as unnumbered bullets, cards, or prose. The user must be able to reply with the visible numbers. When translating this prompt, preserve the numeric prefixes and line breaks exactly. Every visible option MUST be on its own line and MUST begin with 1 -, 2 -, 3 -, etc. Never place two numbered options in the same paragraph or visual line. If a Markdown renderer may collapse soft line breaks, use Markdown hard line breaks (two trailing spaces before newline) rather than blank lines. Translation may change only the option text, not the numbering prefix or one-option-per-line structure.

User can multi-select (max 2). Interpret numbers by the visible list shown to the user, not by the non-sandbox canonical list.

Canonical source material options (non-sandbox numbering):

1. Product document ****(****local path, 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)
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 (run AE_LANG=<user_lang> ae-cli tracking plan list-templates --json to see available templates)

Based on user selection, determine source material type and record to meta.source_type:

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:

  What is the product document path?
  
  You can provide one or more items, separated by commas or newlines:
  1. Local file path
  2. URL
  3. Image file path
  4. Folder path
  

• Product doc → if in a sandbox environment, ask exactly:

  What is the product document path?
  
  You can provide one or more items, separated by commas or newlines:
  1. Sandbox workspace path
  2. Uploaded attachment path
  3. URL
  4. Image file path
  5. Folder path
  
  You can also attach/upload relevant files here, and I will read them from the sandbox workspace if available.
  

• 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
• Data sample → ask "Please provide the path of the inspect profile JSON (or the run directory containing it)", then read the ae-local-data-profile/v1 product and follow the "Data-path (source_type = data)" flow below

Modify Existing Tracking Plan Flow (when user selects this option):

1. Import: Ask user for the file path, then immediately import:

   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):

   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):

1. User provides project directory path
2. Scan directory structure, identify tech stack (engine/framework/language)
3. Read core business modules (game logic, scene management, UI interaction, state/data models, networking/payment, etc.)
4. Extract from code:
   • Events: Player interaction actions (click/swipe/trigger), scene transitions, game state changes (start/pause/end), business flow nodes (purchase/upgrade/unlock)
   • Event Properties: Action parameters (bullet type/enemy level/item ID), state values (score/HP/coins), context (level ID/difficulty/mode)
   • User Properties: Persistent state (level/experience/VIP/cumulative spend)
5. Map extracted results to AE naming conventions (snake_case event names + display_name in user's language)
6. Confirm extracted results with user, supplement missing items

Business Dimension Confirmation:

After source material is confirmed, must process business dimension info based on source_type. User must explicitly confirm before proceeding.

If source_type is template or starts with template_ (covers template, template_prd, template_codebase, template_chat):

Display template's preset business dimensions:

Business Dimension (inherited from template: <template name>)

Revenue Model: <revenue_model>
Core Loop: <core_loop>
Functional Entries: <functional_entries>
Currency System: <currency_system>

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:

1. Inference display: Format inference results as a summary, using business-dimension-mapping.md as the mapping baseline
2. Follow up missing: Only ask about missing items or items inferred as "simple"
3. Event injection preview: Show suggested injected event modules; user ok to proceed

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; NOT applicable to existing_plan or template scenarios):

After business dimension confirmation, auto-detect matching templates based on app type:

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.

Forbidden: existing_plan + template (both provide event baselines; semantic conflict).

Record business dimension info to meta.business_dimension:

"business_dimension": {
  "revenue_model": "<model>",
  "core_loop": "<description>",
  "functional_entries": ["<entry list>"],
  "currency_system": { ... },
  "ad_scenes": [],
  "iap_items": []
}

Data-path (source_type = data) — condensed single-gate flow

When the user selects the Data sample / file profile option (source_type = data), the flow diverges from the standard 5-item anchor. This path maps table columns → events/properties instead of inventing events from business understanding, and uses a single confirmation gate instead of the 5-segment Refine loop.

What to skip (only Item 1 — Application Scenario and Item 2 — Data sample are collected):

• Item 3 (SDK Integration Config) → skip. meta.sdk_integration_mode = "none" (data ingested via RESTful / LogBus / DataX, no SDK). No SDK auto-track events are injected (Phase 1.4 already skips none).
• Item 4 (User Identity System) → skip the visitor-ID strategy question. Derive meta.user_identity from the inspect profile's identity_candidates instead (e.g. a distinct_id / account_id column), account_id_source: "user_account" when an account column exists, otherwise "none".
• Business Dimension confirmation → skip. Mapping is driven by columns, not by revenue model / core loop. meta.business_dimension stays empty.

Draft construction (replaces Phase 1.1/1.2/1.3 for the data path):

1. Read the inspect profile: the ae-local-data-profile/v1 JSON product (columns / types / samples / UE eligibility / mapping confidence). If it is not present or is stale, re-run ae-cli data-integration inspect for the source file first.
2. Event model determination (reuse UE routing): single-table single-event track / single-table multi-event (event-name column) / single-table user_set / mixed. The agent may propose splitting one table into multiple events (e.g. an ad table split by campaign_type into ad_show / ad_click); such proposals MUST be confirmed in the gate.
3. Column → property mapping draft:
   • Identify system columns first: time field, distinct_id / account_id, event-name column, user-property-name column.
   • Map the remaining columns to event properties / user properties / super properties.
   • Naming: snake_case event/property names + display_name + desc + event_tag (language follows the user's input).
   • Type inference: CSV columns default to string; infer number / bool / datetime / enum from field name + value distribution + business doc/prompt priors. Uncertain or conflicting columns are marked "to-confirm" and asked only inside the gate (do not ask column-by-column beforehand).
4. Single confirmation gate (replaces Phase 2, see below).
5. Merge with existing plan (reuse Phase 4.1/4.2 conflict detection).
6. Persist: .ae-cli/draft.json → xlsx → upload (sdk_integration_mode = none).

Single confirmation gate (one round, one summary table):

Present ONE merged table covering all of the following in a single message, then wait for a single reply:

• Event list: event_name / display_name / desc / event_tag / platform.
• Property list: name / display_name / type / desc / source, with uncertain types highlighted (marked "to-confirm").
• Field scope: default to plan-internal fields only; include a full-import switch for bringing all source columns in.
• Unrecognized / dirty data handling: how unmapped columns, null values, and unparseable rows are treated.
• Same-name property type conflicts: flagged inline in the gate (see Phase 4.2 Type A).

User replies once: ok (accept all), or targeted edits — rename / retype / add / remove individual columns or events. After the gate is confirmed, jump to Phase 3 (project token) then Phase 4 (merge + upload); do NOT enter the 5-segment Refine loop.

dry-run mode:

When the user requests dry-run (or the caller passes data-integration plan --dry-run), produce the draft preview + column→property mapping summary ONLY:

• Show the single confirmation gate table (events + properties + field scope + unrecognized-data handling) and the mapping result, but do NOT write .ae-cli/draft.json.
• Do NOT generate xlsx, do NOT archive to plans/, do NOT upload to AE.
• State explicitly that nothing was persisted; the user can approve a real run afterwards.

Item 3 — SDK Integration Config (client + server combined)

Ask: "What is your client platform? (multi-select OK, e.g. Android + iOS) Will you integrate a server-side SDK?"

After asking this Item 3 question, stop and wait for the user's answer. Do not display Item 4 in the same response.

Language filter: The following SDKs have Chinese-only documentation and are visible to Chinese users only: Mini-program, Mini-game, OpenHarmony, LayaAir, Egret, Cocos2d-Lua. Do not show these to non-Chinese users.

Client integration (multi-select OK):

Programming language (Android / iOS SDK only):

Follow-up: chose Android SDK → ask "Which programming language? Java / Kotlin / both" Follow-up: chose iOS SDK → ask "Which programming language? Objective-C / Swift / both"

Record to client_platform_languages:

"client_platform_languages": {
  "android": ["java", "kotlin"],
  "openharmony": ["typescript"]
}

⚠️ Multi-platform meta field rules: When ≥2 client platforms are selected, Draft meta must use client_platforms (array) + client_platform_languages (dictionary). Do NOT use only client_sdk_type (single value) + client_language (single value), which would only record one platform. Single-platform scenarios use client_sdk_type + client_language.

Server integration:

SDK integration mode auto-detection:

none mode: Suitable for historical data import, batch data sync, third-party system integration, etc. Refine phase does not inject SDK auto-track events.

Item 3 confirmation gate:

After the user answers Item 3, normalize the SDK configuration and ask only the missing follow-up questions (for Android/iOS programming language or Other server language).

Then summarize the normalized SDK config and ask: "Confirm this SDK integration config? Reply ok to continue to Item 4, or describe changes."

Do not display Item 4 or ask identity questions until the user explicitly confirms this SDK integration config.

Item 4 — User Identity System (visitor ID + account ID combined)

Ask: "What is the visitor ID generation strategy?"

Options:

• auto — SDK auto-generates (default, suitable for most scenarios)
• device_id — Use device ID (iOS IDFV / Android AndroidID)
• custom — Custom visitor ID (must call identify() immediately after SDK init)

Follow-up: chose custom → ask "What value should the visitor ID use? e.g.: device ID / UUID / guest temp ID"

Ask: "What is the account ID source?"

Options:

• user_account — User account ID (unique identifier after login)
• role_id — Role ID (game-specific; one account may have multiple roles)
• none — No account system (pure guest mode)

Follow-up:

• chose user_account → ask "What specific value for account ID? e.g.: user_id (user ID), phone (phone number), email (email address)"
• chose role_id → explain "Role ID is suitable for games — one account can create multiple roles, enabling finer-grained per-role behavior analysis"

Record to meta.user_identity:

Phase 1 — Draft

1.1 Construct Canonical Draft

Draft conceptual structure (internal JSON; users do not view directly):

Draft
├── meta:
│   ├── app_type:                   App type
│   ├── sdk_integration_mode:       SDK integration mode: client_only / server_only / both
│   ├── client_platforms?:          Client SDK type list (required when multi-platform, e.g. ["android","ios"])
│   ├── client_sdk_type?:           Primary client SDK type (single platform, backward compatible)
│   ├── client_platform_languages?: Per-platform languages (required when multi-platform, e.g. {"android":["kotlin"],"ios":["swift"]})
│   ├── client_language?:           Client dev language (single platform, backward compatible)
│   ├── server_language?:           Server dev language (only when server_only or both)
│   ├── project_id?:                AE project ID (filled in Phase 3)
│   ├── host?:                      AE web address (filled in Phase 3)
│   ├── plan_name:                  Plan name
│   ├── lang:                       xlsx output language (zh/en/ja/ko), based on user's current language; controls generated xlsx headers/sheet names
│   ├── scenario:                   Business scenario description
│   ├── source_type:                Source material type
│   ├── user_identity:              User identity config
│   │   ├── account_id_source:      Account ID source: user_account / role_id / none
│   │   ├── account_id_field?:      Account ID field name (only when user_account, e.g. user_id / phone / email)
│   │   ├── distinct_id_strategy:   Visitor ID strategy: auto / device_id / custom
│   │   └── distinct_id_custom_value?: Custom visitor ID value
│   └── business_dimension:         Business dimension config (injected in Phase 1.3)
│       ├── revenue_model:          Revenue model: IAA / IAP / mixed / subscription / commission
│       ├── core_loop:              Core gameplay loop description
│       ├── functional_entries:     Functional entry list
│       ├── currency_system:        Currency system
│       ├── ad_scenes:              Ad scenes (IAA / mixed only)
│       └── iap_items:              IAP items (IAP / mixed only)
├── events:                         Event array, each with platform field
├── event_properties:               Global event property pool (deduplicated)
├── common_event_properties:        Common/super properties (attached to every event)
└── user_properties:                User properties

SDK integration mode fields:

// Multi-platform example (Android + iOS)
{
  "sdk_integration_mode": "both",       // client_only / server_only / both
  "client_platforms": ["android", "ios"],   // Required for multi-platform
  "client_platform_languages": {            // Required for multi-platform; per-platform languages
    "android": ["kotlin"],
    "ios": ["swift"]
  },
  "server_language": "java"                // Only when server_only or both
}

// Single platform example (backward compatible)
{
  "sdk_integration_mode": "client_only",
  "client_sdk_type": "android",            // Single platform
  "client_language": "kotlin"              // Single platform
}

Event platform tag (events[].platform):

{
  "event_name": "order_create",
  "display_name": "Order Create",
  "platform": "server",    // client / server / both
  "prop_names": ["order_id", "order_amount", "payment_method"],
  "source": "prd"
}

• platform: "client" — Client-side upload (user behavior events)
• platform: "server" — Server-side upload (business data events)
• platform: "both" — Both sides upload (timestamps must be synced)

Property object format (event_properties / common_event_properties pool entries):

{
  "name": "order_amount",
  "display_name": "Order Amount",
  "type": "number",
  "desc": "Order total in cents",
  "source": "prd"
}

⚠️ Field names: use name (NOT prop_name), display_name, type, desc, source. Events reference properties by prop_names: ["order_amount", ...] — this is an array of property name references (string array), NOT property objects.

User property format (user_properties pool entries):

{
  "name": "vip_level",
  "display_name": "VIP Level",
  "type": "number",
  "desc": "Current VIP level of the user",
  "source": "chat",
  "update_type": "user_set"
}

update_type is one of: user_set (overwrite), user_setOnce (first-set-only), user_add (numeric accumulate).

User identity fields (meta.user_identity):

{
  "account_id_source": "user_account", // Account ID source: user_account / role_id / none
  "account_id_field": "user_id",       // Account ID field name (only when user_account)
  "distinct_id_strategy": "auto",      // Visitor ID strategy: auto / device_id / custom
  "distinct_id_custom_value": null     // Custom visitor ID value description (only when strategy=custom)
}

Property types (enum): string / number / bool / datetime / object (single object, with sub-properties) / array_row (object array, supports parent.child nesting) / array_string (string array)

Naming rules: Event names / property names must be snake_case; use display_name field for human-readable names.

1.2 Merge Source Materials

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

…(truncated)