grow-muselisted

# grow-muse — the growth cycle One invocation = one new user-visible capability slice, end-to-end: source → score → design-gate → build → verify → push. Sibling `improve-muse` hardens what exists. Every slice MUST carry a one-sentence **user story** — "진안 asks X / lives situation X, and Muse now does Y." No user story ⇒ filler, drop the item. **Boundary (one item, one owner):** MISSING capability → here. Working-but-poor UX of an existing surface → here (usable and correct, just clunky — slow flows, confusing labels). BROKEN — including failing its function without erroring (unreadable, dead affordance, wrong output) → improve-muse; hardening debt found mid-build gets one `- [open] for=improve-muse :: ...` record in backlog.md, never absorbed into the slice. A loop calling only this skill grows forever — pair with improve-muse. **Standing authorizations (Jinan 2026-06-27, this skill only):** push on green verify (never red); auto-pick — but new outbound send classes, privacy-posture changes, and product-boundary calls are ALWAYS ⏳ (skip with the exact question recorded, never guess); scope a real capability, not a stub. ## The cycle 1. **ORIENT** — `pnpm self-eval` red ⇒ do NOT build growth: this fire BECOMES the hardening slice — run improve-muse's cycle inline and fix the regression to green (never end the fire having merely reported a red board). Else check recent log; is Ollama up? 2. **SOURCE — take the FIRST rung that yields:** 1. **Owner's stated dir