[zzylol]

Part of #1047 (step P5a) and #1054 (step 4: stage-boundary types live in asap_types::stages).

Why

P5 moves the Stage 2 catalog code from plan-selection into asap-physical-asap-optimization. That code reads Pass 2's output, but under #1054 the Stage 2 crate may not depend on the Stage 1 crate. The Stage 1 → Stage 2 boundary types therefore have to live in asap-types.

What

Move only. These items go from the logical crate to asap_types::stages:

Old path	New path
asap_logical_asap_optimization::pass2::memo::{MemoGroupId, MemoGroup, CandidateGenerationTimeout, root_groups, queries_rooted_at}	asap_types::stages::…
…::pass2::memo::candidates::{CandidateMemo, CandidateForMemoGroup, OriginOfCandidateForMemoGroup} (+ CandidateMemo::topological_order)	asap_types::stages::…
…::pass2::logical_memo_candidates::LogicalASAPMemoCandidates	asap_types::stages::LogicalASAPMemoCandidates

These stay in the logical crate because they are Stage 1 internals: DagOfLogicalMemoGroups, Pass2RoundState, the generators and rules, and PerComputationLogicalMemoCandidates.

There are no compatibility re-exports, and asap-types gains no dependency. No logic, plan or JSON changes.

How

The types move with their inherent impls; everything else is derives, which move with the types. Every user is updated (logical, plan-selection, devtools, integration-tests, docs).

MemoGroup.parents and .queries go from pub(crate) to pub, with a doc note that only Stage 1 maintains them. The logical crate builds and changes them in several places, and fields need less API than constructors and mutators would. Later stages read them through parent_groups() and reached_by_queries().

Key code interfaces added / modified

crates/types/src/stages/: every type here is the same as before, apart from its module path.

// asap_types::stages (was asap_logical_asap_optimization::pass2::{memo, memo::candidates, logical_memo_candidates})
pub struct MemoGroupId(pub u32);
pub struct MemoGroup {
    pub logical_node: Rc<OperatorNode>,   // unchanged
    pub child_groups: Vec<MemoGroupId>,   // unchanged
    pub parents: Vec<MemoGroupId>,        // was pub(crate): only Stage 1 maintains it
    pub queries: Vec<usize>,              // was pub(crate): only Stage 1 maintains it
}
pub struct CandidateMemo { /* unchanged */ }
pub struct CandidateForMemoGroup { /* unchanged */ }
pub enum OriginOfCandidateForMemoGroup { /* unchanged */ }
pub struct LogicalASAPMemoCandidates { pub memo: CandidateMemo }   // Stage 2 input
pub struct CandidateGenerationTimeout;

Usage: Pass 2 (logical crate) returns asap_types::stages::LogicalASAPMemoCandidates, and the Stage 2 catalog code reads it from asap-types. After P5, that catalog code lives in the physical crate and needs no dependency on the logical crate. Plans are unchanged.

Major algorithm changes

None.

Before / After

Before, the types passed from Stage 1 to Stage 2 were defined in the Stage 1 crate. After, they are shared types in asap-types.

Verification

At c2f146f20 (on main 41c515465):

• fmt and clippy --workspace --all-targets -D warnings are clean.
• cargo tree -p asap-types --edges normal --depth 1 is unchanged and contains no workspace crates.
• Tests:
  • asap-types: 146 + 97 + 8 passed.
  • asap-logical-asap-optimization: 182 + 35 passed.
  • asap-plan-selection --lib: 344 passed.
  • asap-planner: passed.
  • asap-devtools, asap-integration-tests: passed; the known time-budget failures pass alone.
• Corpus snapshots (release, --ignored): pass.
• An independent review found:
  • moved bodies are identical, including topological_order;
  • no impls were dropped;
  • error chains and messages are unchanged;
  • no stale paths remain;
  • only the two documented fields are newly public.

🤖 Generated with Claude Code