Tighten compile bucketing so projects/systems are adoption-ready

[BlueBirdBack]

Problem

A real Mneme run against my OpenClaw workspace produced compiled outputs that were useful as diagnostics, but too noisy to adopt directly.

The biggest problem was category bucketing / entry granularity:

• compiled/projects.md absorbed one-off notes that are not really projects
• compiled/systems.md included giant dumped sections instead of tighter atomic facts
• some entries preserved whole headings/blocks where a smaller normalized fact would be more useful
• some lanes are semantically off (for example profile/attribution notes drifting into project-like buckets)

Real examples from the run

Examples from BlueBirdBack/mneme run output on my workspace:

• projects.md got entries like About B3 — Attribution/authorship
• projects.md also promoted broad section dumps like Active Projects as a single bulky project entry
• systems.md contained large section-level captures such as AskClaw Notes / Hard Constraints instead of more operator-usable atomic system facts

Why this matters

Right now the compiled pack is great for surfacing material, but not yet clean enough to merge or trust as a curated memory layer.

That makes Mneme feel more like a diagnostic extractor than a memory compiler when the workspace is large/noisy.

Desired improvement

Tighten compilation so it prefers:

• smaller atomic facts over whole-section dumps
• stronger lane assignment (people vs projects vs systems vs decisions)
• suppression/demotion of one-off status lines that are not durable enough
• better handling for top-level summary sections like Active Projects, AskClaw Notes, Hard Constraints

Acceptance sketch

A rerun on a noisy real workspace should:

• reduce obvious mis-bucketed project entries
• reduce giant section dumps in systems.md
• keep the useful operator facts while making the compiled pack more adoption-ready

Filed from a real run by Ash 🌿.