feat(soul): surface the most recently active desire as current

[oratis]

Stacked PR (3/3). Base is claude/desire-reflect-evolve (#249), not main — GitHub retargets automatically as parents merge. Merge order: #242 → #249 → #247. The diff below is only this PR's own changes.

Why

The "current desire" ticker (room/island, and the web client) reads current_desire from GET /api/island/ping, which computed it as desires.find(d => d.actionable) over fs.readdir order — an arbitrary, static pick decoupled from recency and relevance. So even once desires start changing (PR #242 / #249), the surfaced one still wouldn't move (root cause #1 in the plan doc).

What

Two store helpers:

• pickCurrentDesire(desires, activityAt?) — pure. Prefers actionable desires (what's actually driving the heartbeat); within that pool the most-recently-active wins; falls back to most-recently-born. Because the ordering key is a stored timestamp, the pick is stable between real events and only moves when something actually happens — add / revise / pursue / close. That's fidelity, not per-request flicker.
• desireActivity(desires) — cheap fs.stat over each <slug>.md and <slug>.progress.md, so "activity" reflects both authoring (add/revise rewrite the desire file) and pursuit (the heartbeat appends the progress file).

Wired into GET /api/island/ping — which the room, island, and web client all consume, so all three update from one change — and marked (← current) in lisa status so the CLI and UI agree.

Design rationale (正反方辩论)

Plan doc Debate 3 weighs recency sort (feels alive) vs stable pick (steady north-star). Decision: sort by activity — the reframing that dissolves the tension is that a timestamp-driven key is stable between events, so you get the north-star feel and the responsiveness, which the readdir accident gave neither of. Full debate in docs/PLAN_DESIRE_EVOLUTION_v1.0.md §4 (landed in #242).

Testing

• src/soul/pick-desire.test.ts — 7 tests: empty→null, actionable preference, activity-recency ordering, independence from array/readdir order, bornAt fallback, pursuit refreshing an old desire, all-dormant fallback.
• npm test: zero regressions — the 3 failures present (mail/scheduler, mail/service from the missing imapflow optional dep; web/auth) fail identically on main with and without this change (verified by stash-and-compare); +7 new passing tests. Typecheck clean.

Merge order

Independent of #242 and #249 (touches disjoint regions of store.ts / server.ts), but the series reads best merged #242 → #249 → this.

🤖 Generated with Claude Code

[oratis]

Review — one robustness fix before merge ⚠️

The pure logic is correct: pickCurrentDesire strictly prefers actionable desires, tie-breaks on most-recent activity, falls back to most-recently-born, and is order-independent (empty→null; recency() is always finite so the sort is stable). The missing-<slug>.progress.md case I went looking for is handled — the fs.stat is inside a try/catch that floors at bornAt, with a passing test. CLI (status.ts) and web (server.ts) call the same pickCurrentDesire, so they agree by construction, and /api/island/ping is a 30s fallback poll (not a hot loop), so 2 stats/desire is negligible.

MUST-FIX — desireActivity can reject on an unsafe slug, and lisa status doesn't guard it. The path construction [desireFile(d.slug), desireProgressFile(d.slug)] runs outside the try/catch, and both call assertSafeSlug, which throws on an empty / dot-leading / >64-char slug. But listDesires() derives slugs from raw filenames without validation — so a stray unsafe-named file makes desireActivity reject, bypassing the very catch that's meant to make per-file failures non-fatal.

Most plausible trigger on a Darwin setup: a macOS AppleDouble ._<name>.md file landing in ~/.lisa/soul/desires/ (created on FAT/exFAT/SMB volumes or when restoring from an archive; the soul dir is git-tracked + synced across machines). Then:

• /api/island/ping — caught by the handler's surrounding try → currentDesire = null → ping still 200s. Degrades gracefully.
• lisa status (status.ts:94) — not wrapped → the rejection propagates to main().catch → lisa status aborts with fatal: unsafe soul slug …, after printing the "Desires" heading but nothing after. That's a new failure mode (pre-PR status.ts tolerated any slug).

Fix I'm pushing: move the two path constructions inside the try in desireActivity, so an unsafe slug is skipped like a stat error — one change fixes both call sites and aligns them. I'm also adding a deterministic secondary sort key (slug) so an exact recency tie doesn't silently fall back to fs.readdir order — the very accident this PR set out to remove.

[oratis]

Superseded by #250 — GitHub auto-closed this PR when its base branch claude/desire-reflect-evolve was deleted on #249's merge, and a closed PR whose base branch is gone can't be reopened or retargeted. The same content (rebased onto main + the review fixes) landed via #250.