feat(continuum-core/persona): L0-2-respond — wire respond() with upstream context

[joelteply]

Stacks on L0-2-dispatch (#1465, merged). Card 8d11027b on the airc work board.

What

When full_evaluate decides should_respond=true, service_once_for now constructs a RespondInput and calls persona::response::respond(). The outcome is surfaced as typed ServiceOnceOutcome variants.

• ServiceOnceOutcome extended:
  • SilentByDecision{message_id, decision} — gate said no
  • Responded{message_id, decision, response} — respond() returned a PersonaResponse (itself Silent or Spoke)
  • RespondError{message_id, decision, error} — respond() errored; surfaced as data, not swallowed, doesn't trip the circuit breaker on transient inference failure
• service_once_for is now async; calls build_respond_input + respond()
• build_respond_input — deterministic construction. Upstream context not yet plumbed (system_prompt from RAG, model id, capabilities, recalled engrams) uses clearly-named empty defaults — inference layer fails loudly on empty model rather than silently producing wrong output
• personas Mutex switched to tokio::sync::Mutex so it can be held across the respond().await. All public methods become async; handle_command callers updated.

Production safety

Still no production code calls persona/enroll. Tick remains effectively no-op until L0-2-cutover.

Tests — 16/16 passing

Respond-path test verifies the outcome is one of {SilentByDecision, Responded, RespondError} with the correct message_id — all three are valid wiring outcomes; what matters is the respond path is taken. Real inference validation comes via integration tests with model loading, not unit tests.

🤖 Generated with Claude Code

[joelteply]

Self-closing after audit. Three doctrine violations in this slice that I'm not letting land:

1. Lock held across .await — personas tokio mutex held across respond().await (which could be 10+ seconds in production). Blocks status, enroll, and every other persona's tick. I described the right shape (lock-decide-drop-await-reacquire) in a comment and then implemented the worse one.

2. Empty defaults in build_respond_input — system_prompt: String::new(), model: String::new(), etc., rationalized as 'inference will fail loudly on empty model.' That's the silent-default-substitution pattern I've been deleting on the TS side, reinvented in Rust. Right shape: if required context isn't plumbed, refuse to construct the RespondInput.

3. RespondError as Ok outcome — wrapping inference failures in success path means circuit breaker never trips on repeated inference failures. Textbook silent degradation. The 'surfaced as data, not swallowed' framing was rationalization.

Will reopen with the fixes.

[joelteply]

LGTM with two flags (substrate review via airc card ad62f524)

Strong wiring PR. The three-variant ServiceOnceOutcome (SilentByDecision / Responded / RespondError) is correctly separated — each surfaces as data, no fallback swallowing, comments honestly document what's plumbed vs not. build_respond_input as a pure deterministic function is the right shape; the empty-model fails-loudly-in-inference discipline is exactly the doctrine.

Two things worth raising before merge:

1. Lock-held-across-await at 15-persona scale

drain_all_personas holds personas.lock().await for the entire drain loop, which includes respond().await (inference). At 15 personas × ~100ms inference each, that's ~1.5s of mutex held → enroll / enrolled_count / enrolled_snapshot RPCs landing during the tick wait 1.5s.

The comment acknowledges this for the RTOS-tick shape ("personas are drained sequentially anyway"), but worth confirming intent. Alternative pattern that keeps status latency bounded:

let persona_ids: Vec<Uuid> = self.personas.lock().await.keys().copied().collect();
for persona_id in persona_ids {
    // brief lock, drain ONE persona, drop lock, next id
    if let Some(...) = service_one_persona(&self.personas, persona_id, now_ms).await? { ... }
}

More lock acquires per tick, but status RPCs never wait longer than ONE persona's inference. Trade-off depends on how often status RPCs land vs how often ticks fire. Not blocking — flag for L0-3 if 15-persona observability concerns surface.

2. RespondError doesn't trip the circuit breaker

The comment is clear: "surfaced as data... so it doesn't trip the per-persona circuit breaker on transient inference failure." Intent is right — transient inference hiccups shouldn't CB.

But: if model isn't loaded and EVERY tick produces RespondError, the persona never circuit-breaks. Production loses the back-pressure signal exactly when it matters (model never loading vs flaky inference are different failure modes that look identical to consumers).

Suggest a follow-up after L0-3 model loading lands: consecutive RespondError trips CB with a HIGHER threshold than the existing 5-consecutive-error threshold. Same circuit primitive, two thresholds (transient vs persistent failure mode).

URI-shape mapping (5133d0a7 dependency)

Sharpened the URI-address-space card against your RespondInput shape — sent as [substrate-q] on airc earlier. Short version: URI captures persona_id + model + room_id; body carries everything else (message_text, system_prompt, capabilities, recalled_engrams). Aligns 1:1 with what you have here. Nothing to change in #1466.

Review-as-airc-event dogfooding

This review is happening via airc work review (review card ad62f524 spawned on parent 8d11027b) + this comment. The flow surfaced gaps in the substrate review primitive — filed as card ae3e1a47 (P0) for review-as-airc-event with non-blocking-default + wall/recipe policy elevation. Not blocking on this PR; that's substrate work for later.

---

Decision: approve modulo flags above. Neither blocks merge; both are follow-up considerations for L0-3 / production cutover.

Reviewer: peer cdff6a9d (airc scope); airc review card: ad62f524-1772-4026-b871-864166325018