[Refactor] Clarify configuration-to-physical-plan naming

[milindsrivastava1997]

Concrete maintenance problem

The configuration → planning → pricing → installation path uses overlapping terms such as “plan,” “alternative,” “selection,” “leaf,” “mask,” “binding,” “snapshot,” and “config.” Several names describe implementation history rather than the value’s current domain role, making it hard to follow one query from input through an active data-plane plan.

Behavior that must remain unchanged

• Candidate enumeration, feasibility checks, pricing, and cheapest-feasible selection.
• Exact fallback and mixed summary/exact execution behavior.
• Plan publication, staging, activation, and retirement semantics.
• Existing serialized inputs/outputs during a compatibility transition.

Before and after structure

1. Planning input and selected DAGs

• BackendLocalPlanningSnapshot → BackendLocalPlanInput
• BackendLocalImplementation → BackendLocalPlanningInputs
• PlanningRequest → PhysicalCompilationRequest
• PlanningQuery → SelectedQueryInput
• post_asap → selected_summary_plan_root
• logical_selection → planner_selection_trace
• window_implementations → window_realization_candidates
• window_secs → query_lookback_seconds
• group_by → group_by_labels
• accuracy → accuracy_target
• lifecycle → summary_lifecycle_inputs
• erp → empirical_runtime_profile

2. Candidate selection and pricing

• materialization_policy → enabled_optional_materializations
• materialization_candidate_keys() → optional_materialization_ids()
• Do not call a BTreeSet<String> a “mask.”
• with_exact_alternative() → enumerate_exact_and_materialized_candidates()
• bind_alternative() → compile_candidate_for_pricing()
• prepare_manifests() → compile_candidates_for_pricing()
• AlternativeCost → CandidatePlanEvaluation
• WorkloadCostComparison → CandidatePlanSelectionReport
• CostDemand → CostComponentDemand
• unit → cost_unit
• multiplicity → occurrences_per_horizon
• WorkloadQuote.executable → deployable
• Replace free-form candidate status strings with an enum.

3. Physical compilation and publication

• PhysicalCompiler → PhysicalPlanCompiler
• PhysicalPlan → CompiledPhysicalPlan
• compile_transmission_plan() → build_transmission_plan_from_precompute_plan()
• publication() → to_publication_artifact()
• DeploymentEnvironment → PhysicalDeploymentContext
• synthesized_window_queries → queries_with_derived_window_candidates
• Align max_retained_summary_bytes with retained_summary_memory_budget_bytes.

4. Data-plane active configuration

• build_active_physical_plan() → validate_and_build_active_physical_plan()
• HotReloadActivePhysicalPlan → ActivePhysicalPlanHandle
• physical_plan_snapshot() → active_physical_plan_snapshot()
• Rename or split HotReloadStreamingConfig, since active-plan mode reads configuration from ActivePhysicalPlan while legacy mode owns a separately swappable config.
• ActivePhysicalPlan.runtime_config → streaming_config
• aggregation_configs → materializations_by_policy_fingerprint
• get_all_aggregation_configs() → materializations()

Why the proposed structure is minimally complex

This terminology-only refactor preserves the current conceptual boundaries while making the lifecycle explicit:

plan input → candidate requests → compiled candidate plans → pricing evaluations → selected physical plan → active physical plan

No new planner, abstraction layer, or runtime behavior is introduced.

Existing unit and end-to-end protection

Retain and run existing compiler, workload-cost, plan-installation, hot-reload lifecycle, and backend process end-to-end tests. Add focused assertions only where renamed serialized fields require compatibility aliases.

Compatibility or migration impact

For externally serialized or public Rust names, use a staged migration:

• Add new Rust names first.
• Accept old serialized field names via serde aliases.
• Preserve externally used API names temporarily with deprecated forwarding methods where needed.
• Remove aliases only after documented consumer migration.

Acceptance criteria

• Names distinguish planner input, selected DAG, candidate, compiled plan, priced evaluation, selected plan, and active plan.
• No mask terminology remains for set-valued materialization selection.
• Public/serialized compatibility is preserved during the migration.
• Existing planning, pricing, publication, and active-plan lifecycle tests pass.

Blocked by

None - can start immediately

[milindsrivastava1997]

@zzylol, could you please review this naming-refactor proposal, especially the suggested lifecycle terminology and any externally visible compatibility concerns?