# Remaining packing/grouping scope: source findings

Current HEAD e040adf8 completes ownership/mapping integration. The active full-refactor goal remains unfinished. No production edits for this next stage have been made.

`mid/packing.rs::with_distributed_packing` is still driven by one `Recipe::packing_rows`. It rewrites each eligible row-major FP16-to-panel copy into receive/pack/distribute work, then refreshes costing. It clones the result owner map into its new workspace. Consequently a small explicit result domain can prevent a larger packing workspace, the same distinction already fixed for fragment binding. `packing_layout` also divides by its unchecked u16 rows argument; use a checked/nonzero policy representation rather than retaining a zero-divisor checkpoint path.

A concrete next direction is a typed per-WorkSite panel-packing choice containing panel rows and a workspace OwnerMap. This is an algorithm/workspace choice, not a retained executable fragment. Mid values keep the actual assignments. Discover the supported choices before applying the packing rewrite, because its root Copy no longer has the original output layout afterward; retain only this compact choice inventory on Candidate, as with cast sites. Keep the existing four joint row alternatives initially, expressed as scoped entries, without a Cartesian-product search. Exact unavailable site requests should fail. Moving a layout proposal past a now-inapplicable packing choice must be an explicit recipe proposal, not a silent compiler fixup.

Checkpoint migration of the former global rows must resolve the actually eligible sites and their old workspace maps once during construction, preserving old behavior. Workspace maps need to participate in Recipe's joint physical relabeling, alongside the existing owner choices; use the same OwnerMap composition/validation rather than inventing a second mapping representation. Distinguish the absolute selected packing workspace from the base/relative-rotation semantics of constructor result choices to avoid applying rotations twice. The currently validated default real-model checkpoints have packing_rows=None, parallel_reductions=0 and disjoint_copy_sources=false, so a separate nondefault fixture is required to prove migration compatibility.

`mid/ownership.rs` currently also owns the old independent-reduction/preparation grouping rewrites. They rotate owner groups and move work recursively, controlled by global Recipe flags. Scope these to named independent groups, preserving region boundaries and shared-use checks. Keep their ownership interactions explicit: a grouping rotation must not silently override an independently selected result home. Separate policy/binding from grouping by responsibility when that work is done, not by arbitrary file length.

Further full-goal work after these policies: mixed attention state typing; resolved storage/read bindings; complete local-copy family call construction; measured cache consolidation; final requirements/operation-extension and non-test-size audit. None is proved complete by the ownership package comparisons.