Split

LEAF Split

Splitting one work item is not one move. It is three layers, and the common mistake is to cut along several grains at once. A work item splits cleanly along only one grain at a time — pick one, and the grains you did not pick scatter and tangle (the "tyranny of the dominant decomposition"). So this skill's real job is not "cut it every way" but "choose which coherence you are willing to lose."

The three layers:

(a) and (b) are co-determined, not strictly sequential — seeing a clean grain is evidence to split; seeing none is evidence to keep grouped. Only (c) is strictly downstream: order and links only mean something after a cut exists.

(a)+(b) — split now, and along which grain

Look at both together:

1. Is there a clean grain? Scan the menu below for an axis this work divides cleanly along.
   • A clear grain is visible → that visibility is the case for split now.
   • No clean grain is visible → that is the case for keep grouped (it is one work item). "No grain" is a valid terminal answer, not a failure to look harder.
2. Cross-check with learn's Split Check (split now / keep grouped / ask first). Reuse that judgment — do not invent competing criteria.

The cut-axis menu (open, not closed)

Pick the single sharpest grain. These are the common ones; if none fits, name the sharpest cut yourself from the broader taxonomy.

Choosing the dominant grain

1. Take the one grain it divides along most cleanly (one axis per pass).
2. Name the lost cohesion in one line — the most painful thing the unpicked grains will scatter. The unpicked axes always scatter; say which loss hurts.
3. Reject gate: weigh the lost cohesion against the separation gained. If the loss hurts more than the separation helps, drop that axis and try another. (Splitting a feature by file-type/layer gains separation but loses feature cohesion → reject.) This step rejects bad axes, it does not just disclose them.
4. Second axis also load-bearing? Do not cut two ways at once. Split on the dominant axis now, then re-enter this skill on a child for the second cut (recursive split).
5. Tie between axes? Keep the one that loses the less-painful cohesion; record the other in the lost-cohesion line. If still undecidable, ask the user which cut dominates? — do not bounce this back to (a).

When to stop / ask

(c) — order & link the pieces

Split the work into children (N ≥ 2). For each child record:

• grain — which side of the dominant cut it is.
• lineage — split from: <parent> (one direction, ancestry).
• directional dependency (if any) — "A blocked-by B". Write it as human-readable prose in the status file (split reason:, source <X>:), and also record the eventual graph edge it implies. Split itself still does not create linked.md before a child is pressed, because linked.md belongs next to a pressed digest. The split judgment should make the later edge obvious.

Use this mapping when a split relationship becomes pressed knowledge:

Order: topologically sort by the directional dependencies → which child must come first.

Cycle? A cycle means the cut was wrong, not that ordering is hard. Re-cut on a different grain (back to (b)); if the pieces are genuinely mutually inseparable, keep grouped / ship atomically (back to (a)).

Over-decomposition guard (every level)

Before emitting children, and at every recursion level:

• "Can any child be dropped or deferred?" If no, the split is wrong → fall back to keep grouped.
• Premature-decomposition pressure is real (the microservices rebound): when in doubt, do not split — keep or ask.
• Recursion terminates when a node is atomic (its pieces cannot be deferred) or the second axis is no longer load-bearing in that child. Stop descending there.

Output

• verdict: split now / keep grouped / ask
• if split: the dominant grain + the lost-cohesion line
• child list: each child's grain, lineage, directional dependency
• link plan: future linked.md rows for pressed children, using only derived_from, depends_on, or related_to
• order: the topological sequence
• the over-decomposition guard result

Boundaries

• Reuse learn's Split Check for (a) — do not author new split criteria here.
• Execution is a later increment. This skill produces the judgment; the parent leaf fall --reason split, child leaf new, and link wiring are not automated yet. The keep/press/fall actions and the split fallen reason live in ../using-leaf/references/lifecycle.md ("Ending a leaf").
• Do not create linked.md early. It belongs beside pressed.md in .leaf/02-leaves/<slug>/ after the relevant child becomes citable. Before then, keep the link plan in the split output/status prose.
• Conduct, voice, and language come from soul.

Worked check

Reverse-validate against a real split: folder-tree-visualization bundled tree rendering + link-edge recording; the recording was split off as citation-link-recording. Running the framework: (a)+(b) a clean responsibility grain is visible (rendering vs edge data) → split now; lost cohesion = "seeing links right inside the tree"; (c) the tree is blocked-by the link model, so the link model comes first. That reproduces the decision actually made — which is the bar this framework must clear.