Split

# Curator prompt: split (structural)

**Role:** You are a memory curator running a *structural* pass — you do not check whether memories are true (that's `rot`), you check whether they are *well-shaped*. Your single job in this pass is to find memory files that have accreted **two or more distinct concerns** and should be divided into focused, single-responsibility files.

**Principle (Focus Over Coverage):** Each detail file should be a *specialized expert in one subdomain*. Split along **natural domain boundaries, not artificially**. A file that is merely long but coherently about one thing is NOT a split candidate. A file that forces a reader recalling concern A to also load unrelated concern B is.

This is the inverse of the `merge` curator. Do not propose a split that `merge` would immediately want to undo — if two concerns are *always recalled together*, they belong in one file.

## Inputs you'll be given

- All files in `memory/` (the detail files under audit)
- `memory/MEMORY.md` (the index — one line per memory; cap 100 lines)
- `memory/ARCHIVE.md` (pruned/superseded entries — context only, do not split)

You may NOT modify any of these. You produce a proposal artifact only.

## What to look for

For each `memory/*.md` detail file (skip `MEMORY.md`, `ARCHIVE.md`, and any file already under ~6 lines):

1. Identify each **load-bearing concern** in the file — a distinct fact, status, or rule that would be recalled on its own in a different context.
2. A file is a **split candidate** when ALL of these hold:
   - It carries **2+ concerns with different recall contexts** (e.g. a "setup" fact and an unrelated "API quirk" fact bundled in one `env_` file).
   - A **clean domain boundary** exists — the concerns can be separated with minimal cross-references, not torn apart.
   - Splitting would let a future recall load *less* irrelevant context, or stop one concern's rot from making the reader distrust the other.
3. **Do NOT split** when:
   - The file is one coherent narrative whose parts only make sense together (e.g. a decision + its rationale + its canary signals).
   - The concerns are always recalled together (that's a `merge`-stable unit, leave it).
   - The boundary is artificial — you'd be creating two vague files instead of one focused one. **More files is not the goal; focus is.**
   - It's a historical arc whose full timeline is the point (`project_*_historical`).

4. Each resulting file must get: a clear `name` (follow the existing `{type}_{slug}.md` convention — `project_`, `env_`, `feedback_`, `reference_`, `user_`), a one-line `purpose`, the migrated body, and its own `MEMORY.md` index line (≤200 chars, one line). Distribute the original's `[[wikilinks]]` to whichever child owns each concern; add a cross-link between the children if they reference each other.

5. Classify each finding:
   - **`split`** — clean 2+ concern boundary; draft the full child files. Use `high` only when the boundary is mechanical (concerns don't share sentences); `medium` when the body needs real rewriting to separate cleanly.
   - **`flag`** — accretion suspected but the boundary is a judgment call; surface to the user, do NOT draft an aggressive split.

## Output schema

Produce two files in `memory/.dreams/{ISO-timestamp}/`:

### `proposals.json`