docs: design offline ERP planning from physical selection to deployment

[zzylol]

Summary

Propose one-shot planning from a fixed workload, offline error–resource–performance profiles, and deployment constraints: select one executable physical plan, then produce deployment artifacts through the existing publication contracts. Automatic replanning and live observation dependencies are out of scope.

Before this PR

Existing documentation describes ERP parameter selection, shape observations, and physical candidate pricing, but does not specify how offline ERP alternatives and the global optimizer from sketch-bench PR #129 should produce a single deployable plan together.

After this PR

The design defines Planner/backend responsibilities, immutable inputs, ERP candidate preservation, CPU-based global selection, accuracy and resource constraints, fallback behavior, and deployment compilation. For example, aligned one-hour and one-day KLL queries can be evaluated for shared maintenance using offline evidence, with the selected parameters preserved through publication and no automatic replanning after installation.

It explicitly covers the integration gaps in the prototype: semantic sharing identities, backend window layouts, merged-result accuracy, complete component pricing, and solver scope/status. Acceptance criteria cover exhaustive-search agreement and eventual end-to-end deployment validation. The design index links the proposal.

Validation

• git diff --cached --check passed before commit.
• Local Markdown links in both changed documents resolve.
• Documentation-only change; no runtime code or tests changed.

[zzylol]

Superseded by the #818 → #822 stack (draft). The backend no longer selects plans: it executes the PhysicalASAPDAG that ASAPPlanner selects (#509), with the Planner pinned at one stack revision. Leaving this open for now; close it when the new stack is accepted.

🤖 Generated with Claude Code