Context
The superseded work in #24 explored backward-compatible DISCOVER and SELECTED modes for dynamic columns, extension columns, and pivots, plus recipe-aware candidate discovery and stale-selection diagnostics.
The implementation is built on the obsolete stacked Explorer/GraphQL architecture and conflicts heavily with current main. Explorer V2 now owns interactive candidate discovery and occurrence-scoped selection through immutable capability snapshots, so the old implementation should not be rebased directly.
Goal
Determine whether explicit column-selection modes are still needed for generic/versioned dataframe recipes outside Explorer V2, and if so, implement them through the current recipe, semantic, compiler, and capability boundaries.
Questions to resolve
- Is this capability needed outside Explorer V2, or do current V2 selections fully cover the product requirement?
- What are the exact semantics of omitted mode,
DISCOVER, and SELECTED for root and nested dynamic columns, extension columns, and pivots?
- Should an explicitly empty selected set materialize zero columns, and how does that interact with publication validation?
- How are selected keys represented canonically and checked for staleness?
- Which layer owns candidate enumeration without coupling recipe execution to mutable catalog discovery?
- How do completeness, authorization, generation, and schema digests participate in validation?
Acceptance direction
- Existing recipes remain backward compatible.
- No hidden catalog lookup during deterministic execution.
- Selection semantics are validated before physical lowering.
- Root and nested traversal behavior is covered.
- Current compiler/package-boundary checks remain clean.
- Public API work uses the current OpenAPI V2 authoring surface unless a non-Explorer API is explicitly justified.
Historical reference
The PR is historical design input, not a merge candidate.
Context
The superseded work in #24 explored backward-compatible
DISCOVERandSELECTEDmodes for dynamic columns, extension columns, and pivots, plus recipe-aware candidate discovery and stale-selection diagnostics.The implementation is built on the obsolete stacked Explorer/GraphQL architecture and conflicts heavily with current
main. Explorer V2 now owns interactive candidate discovery and occurrence-scoped selection through immutable capability snapshots, so the old implementation should not be rebased directly.Goal
Determine whether explicit column-selection modes are still needed for generic/versioned dataframe recipes outside Explorer V2, and if so, implement them through the current recipe, semantic, compiler, and capability boundaries.
Questions to resolve
DISCOVER, andSELECTEDfor root and nested dynamic columns, extension columns, and pivots?Acceptance direction
Historical reference
The PR is historical design input, not a merge candidate.