Wave Tracking Validation

Goal

Validate actual event data against a published Tracking Plan and return an acceptance result with concrete fix targets.

Project and baseline: list_projects, list_tracking_plans, get_tracking_plan_detail
Quality check: get_tracking_plan_quality_check
Cross-checks: list_events, list_event_properties, list_pipelines

The user must have a project and a Tracking Plan baseline.
The plan should be published before validation. If it is not published, hand off to wave-tracking.
The user must confirm the app/service has been rebuilt/redeployed/restarted if code changed.
The user must confirm key events are already firing.
The user must explicitly ask to begin validation. "事件触发了" alone is not enough.

Confirm project and plan. If the user does not provide a plan id, list plans and ask them to choose.
Confirm the plan status and explain limitations if it is not published.
Confirm runtime verification and explicit consent to start validation.
Call get_tracking_plan_quality_check.
Summarize the result as pass/fail plus issue list. Group issues by event, property, platform/pipeline if available, and likely fix owner.
Use cross-check tools only when the validation result is ambiguous or the user asks for deeper diagnosis.

Do not modify Tracking Plans, SDK code, Pipeline settings, or Catalog metadata from this skill.
Do not infer that missing data is fixed until a later validation run confirms it.
Do not run analytics interpretation here; hand off to wave-analytics for trend, funnel, retention, or SQL investigation.

Return:

Acceptance verdict: passed, failed, or blocked by missing prerequisite.
Evidence: plan id/name/status and checked scope.
Issues: missing events, missing properties, no recent data, unexpected value coverage, or partial implementation.
Next action: route each issue to wave-tracking, wave-catalog-governance, or wave-analytics.

Stop after reporting the validation result. Wait for the user to decide whether to fix tracking, update Catalog metadata, or run analysis.