Surfaced when rebasing ACE-083 (#199) onto ACE-059 (#197). Not a defect in either spec and not a false clean; both claims are true under their own stated criterion. Filing it because a reader joining the two sections sees them contradict each other about one edge.
WITH o AS (SELECT * FROM orders)
SELECT SUM(o.total_amount) FROM o JOIN order_items ON order_items.order_id = o.id
receipt.aggregates: multiplied, fan_trap, joins: ["orders (1) <- order_items (N)"]. ACE-083 rebinds o to orders (grain-preserving CTE) and names the real edge.
receipt.joins: from_to: "o → order_items", status: "undeclarable". ACE-059 does not resolve o past the name the statement bound, so nothing declared can be about it.
So the multiplication is attributed to orders while the join item beside it says the endpoint is unresolvable, and joins.undetermined is null because a settled undeclarable deliberately does not count toward the marker.
Both are defensible in isolation. ACE-059's item is "one join the STATEMENT wrote", and rewriting the endpoint would misreport what the author typed. ACE-083's is "what the analysis resolved that name to", and declining to resolve it would reintroduce the S3 defect it exists to close. The receipt just does not say anywhere that the two sections mean different things by a table name.
If a future spec wants them to agree, _grain_preserving_source is the resolution _join_sites would need to consume, probably as a second field on the join item (what was written, and what it resolves to) rather than by changing either section's existing meaning.
Related drift surface, same origin. _own_alias_map (ACE-059) and _alias_map(in_scope_only=True) (ACE-083) are two implementations of "this SELECT's own sources", reached by different walks. They agreed on every shape probed during the rebase, differing only in that ACE-083's additionally binds derived sources to "". Two answers to nearly one question in a module whose stated invariant is one reference walk.
Surfaced when rebasing ACE-083 (#199) onto ACE-059 (#197). Not a defect in either spec and not a false clean; both claims are true under their own stated criterion. Filing it because a reader joining the two sections sees them contradict each other about one edge.
receipt.aggregates:multiplied,fan_trap,joins: ["orders (1) <- order_items (N)"]. ACE-083 rebindsotoorders(grain-preserving CTE) and names the real edge.receipt.joins:from_to: "o → order_items",status: "undeclarable". ACE-059 does not resolveopast the name the statement bound, so nothing declared can be about it.So the multiplication is attributed to
orderswhile the join item beside it says the endpoint is unresolvable, andjoins.undeterminedisnullbecause a settledundeclarabledeliberately does not count toward the marker.Both are defensible in isolation. ACE-059's item is "one join the STATEMENT wrote", and rewriting the endpoint would misreport what the author typed. ACE-083's is "what the analysis resolved that name to", and declining to resolve it would reintroduce the S3 defect it exists to close. The receipt just does not say anywhere that the two sections mean different things by a table name.
If a future spec wants them to agree,
_grain_preserving_sourceis the resolution_join_siteswould need to consume, probably as a second field on the join item (what was written, and what it resolves to) rather than by changing either section's existing meaning.Related drift surface, same origin.
_own_alias_map(ACE-059) and_alias_map(in_scope_only=True)(ACE-083) are two implementations of "this SELECT's own sources", reached by different walks. They agreed on every shape probed during the rebase, differing only in that ACE-083's additionally binds derived sources to"". Two answers to nearly one question in a module whose stated invariant is one reference walk.