feat: define policy for mirrored master-stack 1->2 births under append-order constraints #114

New issue

Closed

opened 2026-04-28 01:58:01 +00:00 by barrettruth · 0 comments

barrettruth commented

2026-04-28 01:58:01 +00:00

Problem

For master-stack with m = 1, n = 1, and orientation right or bottom, there is a one-split conflict between correct birth side and append-to-end pane order. This is partly an implementation problem and partly a policy problem.

Blocked by: #101, #102

Proposed solution

Decide which invariant should win, or whether a constrained two-step path is acceptable, for the mirrored 1 -> 2 case:

preserve append-to-end order exactly
preserve correct mirrored birth side exactly
accept a small corrective second step if the first frame is still in the right broad branch

The outcome of this issue should be an explicit repo policy with corresponding tests.

Context

The current matrix classifies this as a mirrored order conflict rather than a plain geometry bug. Surveyed external plugins tend to accept reorder churn rather than making the tradeoff explicit.

Acceptance notes

End with a clear policy, not just implementation experiments.
Make the chosen behavior testable.
Feed any remaining residual into the final documentation issue.

Alternatives considered

Preserve the current behavior without naming the tradeoff.
Relax append-order semantics globally.
Accept wrong-branch birth as unavoidable without actually deciding.

## Problem For `master-stack` with `m = 1`, `n = 1`, and orientation `right` or `bottom`, there is a one-split conflict between correct birth side and append-to-end pane order. This is partly an implementation problem and partly a policy problem. Blocked by: #101, #102 ## Proposed solution Decide which invariant should win, or whether a constrained two-step path is acceptable, for the mirrored `1 -> 2` case: - preserve append-to-end order exactly - preserve correct mirrored birth side exactly - accept a small corrective second step if the first frame is still in the right broad branch The outcome of this issue should be an explicit repo policy with corresponding tests. ## Context The current matrix classifies this as a mirrored order conflict rather than a plain geometry bug. Surveyed external plugins tend to accept reorder churn rather than making the tradeoff explicit. ## Acceptance notes - End with a clear policy, not just implementation experiments. - Make the chosen behavior testable. - Feed any remaining residual into the final documentation issue. ## Alternatives considered - Preserve the current behavior without naming the tradeoff. - Relax append-order semantics globally. - Accept wrong-branch birth as unavoidable without actually deciding.