ae-tracking-matrix

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Tracking Matrix · Identification + Routing Foundation

埋点矩阵 · 识别与路由基础

Position: The Tracking Assistant Agent covers generate + audit + optimize + upload. Present a reviewable plan overview from the same canonical JSON in the conversation first, then ask the user to choose direct structured sync to Tracking Management or a local 11-sheet Excel. The sync branch creates no Excel; the Excel branch starts only after selection. After target/baseline/semantic validation, one explicit confirmation authorizes only the displayed remote scope via
references/workflows/validated-upload.md
. No automatic upload, hidden Excel intermediate, implicit deletion/overwrite, or invented UI button. Language: this skill's main text is English; all user-facing replies (including routing, questions, review and acceptance) and newly authored business descriptions follow the user's language. Template-owned Chinese sheet names, headers and type labels remain unchanged. Do not call this an all-English template. This SKILL.md keeps only the "identify + route" logic (≤200 lines); execution flows are offloaded into in-package workflow references (
references/workflows/*.md
), loaded by route after identification. (v2.0: the nine former execution skills were merged into this package as workflow references — routing no longer depends on separate skill descriptions; only the two system skills
ae-generate-tracking-code
and
te-user-id-debug
remain external.)

The

te-user-id-debug

handoff requires the system Skill supplied by the Agent environment; ae-cli does not install it. If it is unavailable, report the missing Skill before starting the deep investigation.

定位：Tracking Assistant Agent 覆盖 generate + audit + optimize + upload。先在对话中基于同一份规范 JSON 展示可审查的方案概览，然后让用户选择直接结构化同步到 Tracking Management还是本地 11 个工作表的 Excel。同步分支不创建 Excel；Excel 分支仅在选择后启动。完成目标（target）、基线（baseline）和语义（semantic）验证后，一次明确确认仅授权通过
references/workflows/validated-upload.md
展示的远端范围。不得自动上传、生成隐藏的 Excel 中间件、隐式删除或覆盖文件，也不得虚构 UI 按钮。语言：此 Skill 的主体文本为英文；所有面向用户的回复（包括路由、问题、审查与验收）以及新编写的业务描述都应遵循用户的语言。模板自带的中文工作表名称、表头和类型标签保持不变。不要将其称为「全英文模板」。此 SKILL.md 仅保留「identify + route」逻辑（≤200 行）；执行流已解包为包内工作流引用（
references/workflows/*.md
），在完成识别后按路由加载。（v2.0：原来的九个执行 Skill 已合并到本包中并改为工作流引用——路由不再依赖单独的 Skill 描述；仅
ae-generate-tracking-code
和
te-user-id-debug
两个系统 Skill 仍为外部依赖。）

te-user-id-debug

交接需要 Agent 环境提供的系统 Skill；ae-cli 不会安装它。如果该 Skill 不可用，请先报告缺失的 Skill，再开始深入排查。

0. Trigger Boundary

0. 触发边界

Enter this flow when the user's request involves any of the following:

Tracking plan: generate / optimize / audit / increment / adjust / upload
Requirements document (PRD) → tracking suggestions
SDK tracking code, integration, reporting Q&A and troubleshooting
Tracking data verification (quality validation, plan acceptance — against the customer's real reported data)
Audit/review of an existing plan counts in ALL cases — even "just take a look". Never read a tracking xlsx with openpyxl/pandas before completing the four-step identification.
Tracking code generation counts too — "give me Android/iOS/Unity tracking code", "写埋点代码", "接入代码" all enter here first. After the four-step identification, this skill routes to the code-delivery execution skill (code_delivery). Never hang the code-generation skill directly from the user request: the identification step carries the naming dictionary and plan-consistency constraints that keep generated code aligned with the plan.

For unrelated requests, exit without forcing a route.

当用户请求涉及以下任何内容时，进入此流程：

Tracking plan：generate / optimize / audit / increment / adjust / upload
需求文档（PRD）→ tracking 建议
SDK tracking 代码、接入、上报问答与故障排查
Tracking 数据验证（质量验证、基于客户真实上报数据的方案验收）
对现有方案的审查和复核在所有情况下都算作 Audit——即使是「只是看一眼」也不例外。在完成四步识别前，绝不能使用 openpyxl/pandas 读取 tracking xlsx。
Tracking 代码生成也属于此范围——「给我 Android/iOS/Unity tracking 代码」「写埋点代码」「接入代码」等请求都必须先进入这里。完成四步识别后，此 Skill 会将任务路由到代码交付执行 Skill（code_delivery）。绝不能直接在用户请求上挂载代码生成 Skill：识别步骤会加载命名字典和方案一致性约束，以确保生成的代码与方案保持一致。

对于无关请求，应退出流程，不要强制进行路由。

Audit & Lint Hard Rules

Audit 与 Lint 硬性规则

Any audit / review / optimize deliverable for an xlsx plan MUST include the machine-check section produced by
```
scripts/lint_tracking_plan.py
```
in read-only check mode. An audit reply without the lint results section is invalid and must be redone.
Lint flow is read-only first: run the check, present findings and suggested fixes, wait for user confirmation, then write to a NEW file — never overwrite the user's original file.
The plan_optimization dispatch table in references/scene-routing.md assigns a single owner per sub-intent; follow it, do not improvise.

对 xlsx 方案执行 Audit、复核或优化时，交付结果必须包含由
```
scripts/lint_tracking_plan.py
```
以只读检查模式生成的机器检查章节。没有 lint 结果章节的 Audit 回复无效，必须重做。
Lint 流程必须先执行只读检查：运行检查、展示发现的问题和建议修复方式，等待用户确认，然后写入一个新文件——绝不能覆盖用户的原始文件。
```
references/scene-routing.md
```
中的 plan_optimization 分发表为每个子意图指定唯一负责人；必须遵循该表，不得自行发挥。

1. Four-Step Identification Mechanism

1. 四步识别机制

After receiving a tracking request, execute these four steps in order, then compose them for execution.

收到 tracking 请求后，依次执行以下四步，然后组合结果并进入执行阶段。

Step 1 · Intent Recognition (what they want to do)

第 1 步 · 意图识别（用户想做什么）

Don't rely on trigger keywords alone; judge the user's action from semantics:

Intent	Typical Phrasing	Execution Mode
Audit	"Take a look / check / review this plan", "Don't modify the file"	Read-only check (audit_only), outputs issue list
Optimize	"Help me optimize / improve this plan"	Modifies file and outputs diff list (optimize_xlsx), no upload
From-scratch design	"Create a tracking plan", "Design from 0"	Full generation flow (generate)
Incremental design	"Add 3 events to the payment module", "Add tracking for XX feature"	Design only the specified module, append to existing plan
Adjustment	"Change the property type of event X", "Modify event XX"	Modify + conflict check
Q&A	"What to do when reporting has no data", "How to integrate the SDK"	FAQ-style answer, no plan changes
Data verification	"Verify if data is reported correctly", "Is event X tracked properly"	Quality validation / plan acceptance against real reported data. Data seeding and presales demo-data generation are OUT OF SCOPE for this customer-facing assistant — customers generate their own real data via test devices / debug mode; if asked to fabricate data, decline and redirect to the verification flow

Different intents within the same container scenario have different execution modes (e.g. in "plan optimization" scenario: audit = read-only, optimize = modify file, incremental = design only the specified module), so lock the intent before routing.

不要只依赖触发关键词；应根据语义判断用户的行为：

意图	典型表述	执行模式
Audit	「看一下」「检查一下」「复核这个方案」「不要修改文件」	只读检查（audit_only），输出问题清单
Optimize	「帮我优化或改进这个方案」	修改文件并输出差异清单（optimize_xlsx），不上传
From-scratch design	「创建一个 tracking 方案」「从 0 设计」	完整生成流程（generate）
Incremental design	「给支付模块增加 3 个事件」「为 XX 功能添加 tracking」	仅设计指定模块，并追加到现有方案
Adjustment	「修改事件 X 的属性类型」「修改事件 XX」	修改并检查冲突
Q&A	「上报没有数据怎么办」「如何接入 SDK」	FAQ 风格回答，不修改方案
Data verification	「验证数据是否正确上报」「事件 X 是否被正确 tracking」	基于真实上报数据进行质量验证或方案验收。数据播种和售前演示数据生成不在此面向客户的 Assistant 的范围内——客户应通过测试设备或调试模式生成自己的真实数据；如果用户要求伪造数据，应拒绝并引导至验证流程

同一个容器场景中的不同意图对应不同的执行模式。例如，在「方案优化」场景中，Audit 是只读模式，Optimize 会修改文件，Incremental 只设计指定模块，因此必须在路由前锁定意图。

Step 2 · Category Recognition (for whom)

第 2 步 · 分类识别（面向谁）

Match against the 24 categories + 1 supplemented category (

interactive_video

) in

references/category-registry.md

. The 29 local Markdown assets are not 29 complete category routes;

idle_card

has a documented cache gap and uses confirmed Idle + Card composition:

Hit → inject that category template's business semantics (what to track)
Fuzzy → list the 2–3 closest candidates and let the user confirm; do not pick on your own
Missing → design using the general spec + standard-base, and at the end of the output remind the user "this category can be deposited as a new category template"

与

references/category-registry.md

中的 24 个基础分类和 1 个补充分类（

interactive_video

）进行匹配。29 个本地 Markdown 资源并不代表 29 条完整分类路由；

idle_card

存在已记录的缓存缺口，需要使用已确认的 Idle + Card 组合：

Hit → 注入对应分类模板的业务语义，即需要 tracking 的内容
Fuzzy → 列出 2～3 个最接近的候选项，让用户确认；不要自行选择
Missing → 使用通用规范和 standard-base 进行设计，并在输出结束时提醒用户「该分类可以沉淀为新的分类模板」

Step 3 · Scenario Recognition (which stage)

第 3 步 · 场景识别（处于哪个阶段）

Match against the 6 scenario workflows in

references/scene-routing.md

Scenario ID	Scenario Name	User Intent
demand_understanding	Requirements Understanding	PRD / requirements doc → tracking suggestion sheet
plan_generation	Plan Generation	0→1 conversation overview → direct sync or optional 11-sheet Excel; confirmed remote write
plan_optimization	Plan Optimization	Incremental / audit / optimize, output diff list
code_delivery	Code Delivery	SDK samples / tracking code
integration_qna	Integration Q&A	SDK integration / reporting / pipeline Q&A and troubleshooting
data_verification	Data Verification	Quality validation / plan acceptance (customer's real data; no seeding)

Scenario is jointly determined by "intent × input form": for the same word "plan", with an existing plan file → plan_optimization; with an empty project and a one-liner → plan_generation.

与

references/scene-routing.md

中的 6 个场景工作流进行匹配：

场景 ID	场景名称	用户意图
demand_understanding	需求理解	PRD／需求文档 → tracking 建议表
plan_generation	方案生成	从 0 到 1 的对话概览 → 直接同步或可选的 11 个工作表 Excel；确认后写入远端
plan_optimization	方案优化	增量设计、Audit、优化，输出差异清单
code_delivery	代码交付	SDK 示例／tracking 代码
integration_qna	接入问答	SDK 接入、上报、数据管道问答及故障排查
data_verification	数据验证	质量验证／方案验收（使用客户的真实数据；不进行数据播种）

场景由「意图 × 输入形式」共同决定。例如，对于同一个「方案」一词，有现有方案文件时应进入 plan_optimization；面对空项目和一句话需求时应进入 plan_generation。

Step 4 · Interactive Confirmation (avoid off-topic answers)

第 4 步 · 交互确认（避免答非所问）

Once positioning is done and before execution, generate differentiated key-detail questions keyed on "intent × category × scenario" to confirm with the user.

Principle: ask only high-impact details (questions that affect whether metrics can be computed and whether the event chain closes). Do not run a fixed 5-step confirmation.
Example: Interactive Film Game × Plan Optimization → What's the hierarchy of the storyline chain nodes? What's the object-group structure of mail rewards? What's the attribution data source?
When info is unclear → record as "To-be-confirmed", do not fabricate.

完成定位后、执行前，应根据「意图 × 分类 × 场景」生成有区分度的关键细节问题，向用户确认。

原则：只询问影响指标能否计算以及事件链能否闭环的高价值细节。不要执行固定的 5 步确认流程。
示例：互动电影游戏 × 方案优化 → 剧情链节点的层级结构是什么？邮件奖励的对象组结构是什么？归因数据源是什么？
信息不清楚时，将其记录为「待确认」（To-be-confirmed），不要编造。

2. Composition and Execution

2. 组合与执行

Cell = Category Template (what to track) × Scenario Workflow (how to track)

Load the corresponding workflow reference by

references/scene-routing.md

— all execution workflows live in-package under

references/workflows/

; read the workflow file before executing, its hard rules apply. For how to read category templates see

category-registry.md

(prefer the local cache at
references/categories/
; for cached categories, do not go to Feishu/Lark). When a category template is missing, use the standard-base foundation (

references/standard-base/

local cache, 12 sheets; prefer local reads).

Cell = 分类模板（tracking 什么） × 场景工作流（如何 tracking）

依据

references/scene-routing.md

加载对应的工作流引用——所有执行工作流都位于包内的

references/workflows/

下；执行前必须读取工作流文件，其硬性规则均适用。有关分类模板的读取方式，请参阅

category-registry.md

（优先使用
references/categories/
中的本地缓存；对于已缓存的分类，不要访问 Feishu/Lark）。缺少分类模板时，使用 standard-base 基础（

references/standard-base/

本地缓存，共 12 个工作表；优先进行本地读取）。

Naming Precheck Before Generation (mandatory before writing the plan JSON, prevents post-lint rework)

写入方案 JSON 前的命名预检（强制执行，可避免 lint 后返工）

Before generating plan content, read the "Standard Event Verb Suffix Table", "Property Name — Display Name — Type Validation Matrix", and "Forbidden Synonym Table" in

references/naming-dict.md

, and cross-check each event/property as you generate:

Within each validation domain, same property name → unique display name + type; different property names → different display names. Event + common properties share a domain, while user properties are independent. Review cross-domain meaning separately; do not claim lint enforces global cross-sheet uniqueness.
Event names use standard verb suffixes (
```
_get
```
/
```
_consume
```
/
```
_click
```
, etc.); do not use forbidden forms
Names starting with
#
are system preset properties (
```
#country
```
/
```
#duration
```
/
```
#ip
```
/
```
#os
```
/
```
#account_id
```
/
```
#distinct_id
```
, etc.), auto-collected by the SDK, forbidden in the custom property tables (
```
#事件数据
```
/
```
#公共事件属性
```
/
```
#用户数据
```
). When copying properties from a category template or the naming dictionary, auto-skip anything starting with
```
#
```
(this is the main source of lint error E01)
Object group modeling (C6): same parent property name with the same child-property structure → reuse one parent property; same parent property name with different structure (e.g. "Mail Reward" vs "Leaderboard Reward") → split into two different parent properties; do not shoehorn fields together to force isomorphism
Common-property judgment (E1): do not mechanically "promote to common property once it appears in 3+ events"; a common property must "apply to nearly all events + have a stable value at trigger time + be a globally high-frequency filter dimension", otherwise keep it as an event property (to avoid null pollution)
Paired events (E1): start/end, request/result and other paired events only need to share a correlation key (e.g.
```
stage_attempt_id
```
,
```
order_id
```
) + common context; the object-group structure does not need to be fully isomorphic
Dual-side deduplication (D4): a single business fact keeps only one authoritative report point (either client or server, pick one); do not split into two records just because both ends emit. When dual-side reporting is truly required, dedupe with
```
#uuid
```
or a business request ID; retries on failure reuse the same
```
#uuid
```

This precheck reduces avoidable conflicts; only actual checks and semantic review establish whether a specific plan passes.

在生成方案内容前，读取

references/naming-dict.md

中的「Standard Event Verb Suffix Table（标准事件动词后缀表）」「Property Name — Display Name — Type Validation Matrix（属性名称—显示名称—类型校验矩阵）」和「Forbidden Synonym Table（禁用同义词表）」，并在生成过程中逐一交叉检查每个事件和属性：

在每个校验域内，相同属性名称必须对应唯一的显示名称和类型；不同属性名称必须对应不同显示名称。事件属性与公共属性共享一个域，而用户属性彼此独立。跨域含义需要单独审查；不要声称 lint 能保证所有工作表之间的全局唯一性。
事件名称应使用标准动词后缀（
```
_get
```
／
```
_consume
```
／
```
_click
```
等）；不得使用禁用形式
以
```
#
```
开头的名称是系统预置属性（
```
#country
```
／
```
#duration
```
／
```
#ip
```
／
```
#os
```
／
```
#account_id
```
／
```
#distinct_id
```
等），由 SDK 自动采集，禁止出现在自定义属性表（
```
#事件数据
```
／
```
#公共事件属性
```
／
```
#用户数据
```
）中。从分类模板或命名字典复制属性时，必须自动跳过所有以
```
#
```
开头的属性（这是 lint 错误 E01 的主要来源）
对象组建模（C6）：父属性名称相同且子属性结构相同 → 复用一个父属性；父属性名称相同但结构不同（例如「邮件奖励」与「排行榜奖励」）→ 拆分为两个不同的父属性；不要强行将字段合并以维持同构
公共属性判断（E1）：不要机械地认为「某个属性在 3 个以上事件中出现，就将其提升为公共属性」；公共属性必须「适用于几乎所有事件、在触发时具有稳定值，并且是全局高频过滤维度」，否则应保留为事件属性，以避免空值污染
配对事件（E1）：开始／结束、请求／结果等配对事件只需共享一个关联键（例如
```
stage_attempt_id
```
、
```
order_id
```
）和公共上下文；对象组结构不需要完全同构
双端去重（D4）：同一个业务事实只保留一个权威上报点（客户端或服务端，二选一）；不要因为两端都会触发就拆分成两条记录。确实需要双端上报时，使用
```
#uuid
```
或业务请求 ID 去重；失败重试时复用同一个
```
#uuid
```

此预检可减少可避免的冲突；只有实际检查和语义审查才能确定某个方案是否通过。

Plan Output Spec (generation/optimization scenarios)

方案输出规范（生成／优化场景）

Conversation first, then delivery choice: run
```
scripts/prepare_delivery.py --conversation-only
```
from canonical JSON and show the complete review, including actual counts, metric mapping, Notes/Timezone and TBC. This mode writes no
```
plan.xlsx
```
or
```
lint.txt
```
. After overview Q&A, ask the user to choose direct sync or local Excel; never default to both.
Direct sync, no Excel: retain the conversation-only directory and follow
```
references/workflows/validated-upload.md
```
with
```
scripts/sync_plan.py
```
. It maps the same JSON to inspected
```
tracking.plan.save_items
```
, performs read-only baseline/dry-run checks and requires a separate explicit target/scope confirmation before writing. No hidden workbook or Excel lint is involved.
Excel only after selection: generate from that same JSON with
```
python3 scripts/finalize_plan.py --plan <plan.json> --template assets/埋点模版.xlsx --output <NEW.xlsx>
```
, then run
```
lint_tracking_plan.py --strict-delivery
```
read-only. The v2.0.1 template retains 11 sheets, official Chinese nine-column event headers with
```
采集端
```
at E, and seven unchanged instruction sheets. Do not add custom sheets or overwrite inputs/outputs.
On repair, show a diff and obtain confirmation; save to a new file and recheck. Synchronize approved changes to canonical JSON, conversation and only the selected branch artifacts. First-run failure remains visible even if repaired-final passes.
Discovery: use known package paths; for unknown CLI/capability contracts use targeted
```
--help
```
or discovery +
```
inspect
```
before composing inputs. Never guess fields or loop on probes. Local lint/dry-run alone is not remote acceptance.

先对话，后选择交付方式：从规范 JSON 运行
```
scripts/prepare_delivery.py --conversation-only
```
，并展示完整审查结果，包括实际数量、指标映射、Notes/Timezone 和待确认项（TBC）。此模式不会写入
```
plan.xlsx
```
或
```
lint.txt
```
。完成概览问答后，让用户选择直接同步或本地 Excel；绝不能默认同时选择两者。
直接同步，不生成 Excel：保留 conversation-only 目录，并按照
```
references/workflows/validated-upload.md
```
使用
```
scripts/sync_plan.py
```
。它会将同一份 JSON 映射到经过检查的
```
tracking.plan.save_items
```
，执行只读基线／dry-run 检查，并要求在写入前单独明确确认目标和范围。不涉及隐藏工作簿或 Excel lint。
仅在选择后生成 Excel：从同一份 JSON 执行
```
python3 scripts/finalize_plan.py --plan <plan.json> --template assets/埋点模版.xlsx --output <NEW.xlsx>
```
，然后以只读模式运行
```
lint_tracking_plan.py --strict-delivery
```
。v2.0.1 模板保留 11 个工作表、官方中文九列事件表头（
```
采集端
```
位于 E 列）以及 7 个保持不变的说明工作表。不要添加自定义工作表，也不要覆盖输入或输出文件。
修复时，应展示差异并获得确认；保存到新文件并重新检查。将已批准的变更同步到规范 JSON、对话内容以及仅被选中的交付分支产物中。即使修复后的最终版本通过检查，首次运行失败仍须保持可见。
能力发现：使用已知包路径；对于未知的 CLI 或能力契约，应在组合输入前有针对性地使用
```
--help
```
，或执行 discovery +
```
inspect
```
。绝不能猜测字段，也不得循环探测。仅执行本地 lint 或 dry-run 不等于获得远端验收结果。

3. Cross-Cutting Concerns (across scenarios, do not occupy cells)

3. 跨场景事项（横跨各场景，不占用单元格）

Multi-attachment parsing: when the user uploads multiple attachments at once, each one must be identified and listed. (Known bug A1: multi-attachment only recognizes one. Before it is fixed, manually confirm every attachment was read.)
Mounting custom skills: handled by route — Route A (cloud preset Agent) does not open this capability (A5); redirect to the cli + local agent route. Route B (cli + local agent, on-machine) supports mounting: drop the custom skill into
```
.claude/skills/
```
(project level or user level), then wire it up in one of three places —
```
category-registry.md
```
/
```
scene-routing.md
```
/ project
```
CLAUDE.md
```
(category route / scenario route / global constraint) — declaring when the skill must be loaded.
Deliverable output: plan output includes a "Notes" + "Timezone" section by default, aligned with the standard-base foundation (A7).

多附件解析：用户一次上传多个附件时，必须识别并列出每一个附件。（已知缺陷 A1：多附件场景目前只能识别一个。在修复前，必须手动确认每个附件均已读取。）
挂载自定义 Skill：由路由处理——Route A（云端预置 Agent）不开放此能力（A5），应将用户引导至 cli + 本地 Agent 路由。Route B（cli + 本地 Agent，本机运行）支持挂载：将自定义 Skill 放入
```
.claude/skills/
```
（项目级或用户级），然后在以下三个位置之一完成连接：
```
category-registry.md
```
／
```
scene-routing.md
```
／项目
```
CLAUDE.md
```
（分类路由／场景路由／全局约束），并声明何时必须加载该 Skill。
交付物输出：方案输出默认包含「Notes」和「Timezone」部分，并与 standard-base 基础保持一致（A7）。

4. Global Constraints

4. 全局约束

No upload by default: only enter the upload flow when the user explicitly asks for "upload to AE".
The original plan is a baseline, not the truth: in optimization scenarios, the user-confirmed business design can override the original plan, but a diff list must be emitted (light-orange mark / change log / to-be-confirmed items).
Non-standard input is not an error: a regular Excel / Feishu sheet / screenshot / PRD is read as a business draft; identify event blocks / property blocks / requirement notes and convert to a standard Draft; do not flag severe errors directly.
Task mode separation: audit_only (check only) / optimize_xlsx (produce a new Excel) / update_existing (continuous iteration) / upload (only after explicit request).
Business-design-layer mandates: metric→event mapping, a scoped property registry (
```
references/naming-dict.md
```
), and all 15 checks in
```
references/business-semantic-checks.md
```
. These are manual/model-assisted semantic review, not implemented automatic scoring. Verify E1
```
ad_fail
```
+ callback/TBC, E2
```
first_media_source
```
/
```
first_campaign
```
, actual event counts, and language following in generation, review and acceptance.

默认不上传：只有当用户明确要求「上传到 AE」时，才能进入上传流程。
原始方案是基线，而非事实来源：在优化场景中，用户确认的业务设计可以覆盖原始方案，但必须输出差异清单（浅橙色标记／变更日志／待确认项）。
非标准输入不是错误：普通 Excel、Feishu 表格、截图或 PRD 应作为业务草案读取；识别事件块、属性块和需求说明，并转换为标准 Draft，不要直接标记为严重错误。
任务模式隔离：audit_only（仅检查）／optimize_xlsx（生成新 Excel）／update_existing（持续迭代）／upload（仅在明确请求后执行）。
业务设计层要求包括：指标到事件的映射、带范围的属性注册表（
```
references/naming-dict.md
```
），以及
```
references/business-semantic-checks.md
```
中的全部 15 项检查。这些属于人工／模型辅助的语义审查，不是自动评分。在生成、审查和验收时，需验证 E1
```
ad_fail
```
+ callback/TBC、E2
```
first_media_source
```
／
```
first_campaign
```
、实际事件数量以及语言遵循情况。

5. References

5. 引用资料

Workflows (execution flows, load after routing):

references/workflows/plan-generation.md

— From-scratch / full-refactor plan generation (absorbed from

tracking-plan-generator-en

)

```
references/workflows/plan-lint.md
```
— Upload-rule validation & auto-fix, E01–E10 (absorbed from
```
tracking-plan-linter-en
```
)
```
references/workflows/plan-review-optimize.md
```
— Semantic audit / optimize / increment of existing plans (absorbed from
```
ae-tracking-plan-en
```
)
```
references/workflows/feasibility-analysis.md
```
— Analysis-requirement coverage & feasibility assessment (absorbed from
```
te-feasibility-analyzer-en
```
)
```
references/workflows/prd-to-suggestions.md
```
— PRD / requirements doc → tracking suggestion table (absorbed from
```
prd-tracking-analyst-en
```
)

references/workflows/data-verification.md

— Data quality validation / plan acceptance (absorbed from

te-data-verifier-en

; SQL checks in

references/data-verification/

)

references/workflows/integration-qna.md

— SDK integration & reporting Q&A (absorbed from

data-integration-assistant-en

; knowledge base in

references/sdk/

)

```
references/workflows/troubleshooting.md
```
— Read-only diagnosis triage (condensed from
```
diagnose-studio-en
```
; local Web Studio engine is Route-B only)

Knowledge bases and dictionaries:

```
references/category-registry.md
```
— 24 base categories + 1 supplemented interactive_video; local-cache first, one Feishu-fallback and a documented Idle Card gap
```
references/scene-routing.md
```
— 6 scenarios × workflow route; official CLI/capability discovery before unknown input, no guessed fields or endless probes
```
references/workflows/validated-upload.md
```
— conversation overview → direct structured sync or selected Excel → explicit scoped confirmation/read-back; no unrequested workbook, implicit delete or overwrite
```
references/business-semantic-checks.md
```
— 15 manual/model-assisted checks, not automated scoring
```
references/eval-cases.md
```
— Seven acceptance cases; historical isolated v2.0 results separated from unrun v2.0.1 runtime status, D1 routing and C5 deployment permissions
```
references/naming-dict.md
```
— Global property registry (event verb table + property-name/display-name/type matrix + forbidden synonym table; authoritative naming across all scenarios; addresses C3)
```
references/te-field-translations.md
```
— Field translation table (full 1791-line version, merged from the former feasibility package in v2.0; the pre-v2.0 copy in this package was a 34-line stub)
```
references/ae-capabilities.md
```
— AE capability quick reference (v2.0: canonical copy taken from the former solution-builder package — verified against official docs, more complete)

references/optimization-checklist.md

— Optimization & acceptance checklist (absorbed from

ae-tracking-plan-en

)

```
references/system-fields.md
```
— System preset fields reference for analysis models (absorbed from
```
system-field-reference-en
```
)
```
references/categories/
```
— 29 local Markdown assets, including shared modules and the incomplete Idle Card cache; presence is not proof of complete business coverage
```
references/standard-base/
```
— Standard-base foundation 12-sheet local cache (2026-09-20, prefer local; see mapping table in category-registry.md)
```
references/plan-generation/
```
— Generation-domain deep references:
```
reference.md
```
(SDK auto-collection, object-group rules, revenue-model rules),
```
naming-dict
```
usage,
```
template-catalog.md
```
,
```
module-baseline.md
```
,
```
export-schema.md
```
```
references/sdk/
```
— Integration knowledge base (client-sdk / server-sdk / faq / integration-tools / te-data-rules, absorbed from
```
data-integration-assistant-en
```
)

references/data-verification/

— Verification SQL library:

sql_checks.md

diagnosis_kb.md

tracking_plan_comparison.md

Scripts:

```
scripts/lint_tracking_plan.py
```
— Plan upload validation (10 rule classes E01-E10; canonical copy, matched to the Chinese deliverable template)
```
scripts/export_tracking_plan.py
```
— Compatibility CLI alias (
```
--input
```
,
```
--output
```
) to the same 11-sheet finalizer; no standalone four-sheet mode or overwrite flag
```
scripts/finalize_plan.py
```
— Template-fill path from JSON to the repaired 11-sheet Chinese template; output must be new
```
scripts/build_template_catalog.py
```
— Reads actual category Markdown metadata only;
```
--output NEW.md
```
required, never overwrites curated business summaries
```
scripts/plan_types.py
```
— Shared property-type and update-method alias normalization; no guessed semantics
```
scripts/plan_contract.py
```
— Shared local plan/template contracts
```
scripts/prepare_delivery.py
```
— with
```
--conversation-only
```
, produces JSON, conversation and validation/review artifacts without XLSX; omit it only for the explicitly selected Excel path
```
scripts/sync_plan.py
```
— guarded no-Excel structured sync through
```
tracking.plan.save_items
```
, with dry-run, target/version/scope confirmation and read-back evidence
```
scripts/upload_plan.py
```
— legacy guarded Excel-import adapter; not used by the direct-sync branch

工作流（执行流程，在路由后加载）：

references/workflows/plan-generation.md

— 从零开始／全面重构的方案生成（吸收自

tracking-plan-generator-en

）

```
references/workflows/plan-lint.md
```
— 上传规则验证与自动修复，E01–E10（吸收自
```
tracking-plan-linter-en
```
）
```
references/workflows/plan-review-optimize.md
```
— 现有方案的语义审查／优化／增量设计（吸收自
```
ae-tracking-plan-en
```
）

references/workflows/feasibility-analysis.md

— 分析需求覆盖度与可行性评估（吸收自

te-feasibility-analyzer-en

）

references/workflows/prd-to-suggestions.md

— PRD／需求文档 → tracking 建议表（吸收自

prd-tracking-analyst-en

）

references/workflows/data-verification.md

— 数据质量验证／方案验收（吸收自

te-data-verifier-en

；SQL 检查位于

references/data-verification/

）

references/workflows/integration-qna.md

— SDK 接入与上报问答（吸收自

data-integration-assistant-en

；知识库位于

references/sdk/

）

```
references/workflows/troubleshooting.md
```
— 只读诊断分流（整合自
```
diagnose-studio-en
```
；本地 Web Studio 引擎仅适用于 Route-B）

知识库与字典：

```
references/category-registry.md
```
— 24 个基础分类和 1 个补充分类
```
interactive_video
```
；优先使用本地缓存，允许一次 Feishu 回退，并记录了 Idle Card 缺口
```
references/scene-routing.md
```
— 6 个场景 × 工作流路由；遇到未知输入时，先通过官方 CLI／能力发现机制处理，不得猜测字段或无限探测
```
references/workflows/validated-upload.md
```
— 对话概览 → 直接结构化同步或用户选择的 Excel → 明确确认范围并回读验证；不得生成未请求的工作簿，不得隐式删除或覆盖
```
references/business-semantic-checks.md
```
— 15 项人工／模型辅助检查，不是自动评分
```
references/eval-cases.md
```
— 7 个验收案例；将历史上孤立的 v2.0 结果与尚未运行的 v2.0.1 运行时状态、D1 路由和 C5 部署权限区分开来
```
references/naming-dict.md
```
— 全局属性注册表（事件动词表 + 属性名称／显示名称／类型矩阵 + 禁用同义词表；所有场景下的权威命名来源；解决 C3）
```
references/te-field-translations.md
```
— 字段翻译表（完整 1791 行版本，由原可行性分析包合并至 v2.0；pre-v2.0 版本在本包中仅为 34 行占位内容）
```
references/ae-capabilities.md
```
— AE 能力快速参考（v2.0：从原 solution-builder 包获取规范副本——已根据官方文档验证，内容更完整）

references/optimization-checklist.md

— 优化与验收检查清单（吸收自

ae-tracking-plan-en

）

```
references/system-fields.md
```
— 分析模型的系统预置字段参考（吸收自
```
system-field-reference-en
```
）
```
references/categories/
```
— 29 个本地 Markdown 资源，包括共享模块和不完整的 Idle Card 缓存；资源存在并不代表业务覆盖完整
```
references/standard-base/
```
— standard-base 基础，本地缓存共 12 个工作表（2026-09-20，优先本地读取；映射表见
```
category-registry.md
```
）
```
references/plan-generation/
```
— 生成领域深度引用：
```
reference.md
```
（SDK 自动采集、对象组规则、收入模型规则）、
```
naming-dict
```
用法、
```
template-catalog.md
```
、
```
module-baseline.md
```
、
```
export-schema.md
```
```
references/sdk/
```
— 接入知识库（client-sdk／server-sdk／faq／integration-tools／te-data-rules，吸收自
```
data-integration-assistant-en
```
）

references/data-verification/

— 验证 SQL 库：

sql_checks.md

、

diagnosis_kb.md

、

tracking_plan_comparison.md

脚本：

```
scripts/lint_tracking_plan.py
```
— 方案上传验证（10 类规则 E01–E10；规范副本，与中文交付模板匹配）
```
scripts/export_tracking_plan.py
```
— 兼容 CLI 别名（
```
--input
```
、
```
--output
```
），指向同一个 11 工作表 finalizer；不支持独立的 4 工作表模式或 overwrite 标志
```
scripts/finalize_plan.py
```
— 从 JSON 到修复后 11 工作表中文模板的模板填充路径；输出必须为新文件
```
scripts/build_template_catalog.py
```
— 仅读取实际分类 Markdown 元数据；必须指定
```
--output NEW.md
```
，绝不覆盖人工整理的业务摘要
```
scripts/plan_types.py
```
— 共享的属性类型与更新方法别名规范化；不得猜测语义
```
scripts/plan_contract.py
```
— 共享的本地方案／模板契约
```
scripts/prepare_delivery.py
```
— 使用
```
--conversation-only
```
时，在不生成 XLSX 的情况下生成 JSON、对话内容和验证／审查产物；仅对明确选择的 Excel 路径省略此步骤
```
scripts/sync_plan.py
```
— 通过
```
tracking.plan.save_items
```
执行受保护的、无 Excel 的结构化同步；包含 dry-run、目标／版本／范围确认和回读证据
```
scripts/upload_plan.py
```
— 旧版受保护的 Excel 导入适配器；不用于直接同步分支