gap-alertlisted

A scheduled loop is draining faster than you've been refilling it. Top it up from the work you've **actually shipped since it was last filled** — capx never generates content; you write the posts from the real git history, and each one passes the casserole guardrail at send. This is the back half of `build-in-public`: together they turn a queue into a self-refilling engine. User's extra intent, if any: "$ARGUMENTS" Follow these steps: 1. **Find the loop that's low.** Call `list_loops`. Each loop reports how many posts remain and its schedule. Pick the one running low — the loop named/id'd in "$ARGUMENTS" if given, otherwise the loop with the fewest posts left (a loop at 0–2 remaining is the one to refill). If nothing is actually low, say so and stop — don't manufacture posts to pad a healthy queue. 2. **Find where you left off.** You're refilling from *new* work only, not re-posting old news. Establish the waterline: check what that loop already has queued/sent so you don't repeat it, then read the commits since then — `git log --oneline -30` (or the range in "$ARGUMENTS"), skimming diffs of the substantive ones. **Skip the noise** — merges, `wip`, `fix typo`, formatting, dep bumps. You want the shippable, interesting changes: new features, real fixes, milestones, hard problems solved. 3. **Check there's genuinely something new to say.** If the only commits since the last fill are noise, don't force it — tell the user the loop is low but there's no