Memory distill + cortex visibility integration across TUI and webchat

[njfio]

Problem statement

Memory distill is running but operators cannot reliably tell when it is active, what it distilled, or whether distilled memories are persisted and surfaced consistently across TUI, dashboard/webchat, and gateway status. This creates a disconnected operator experience and weak trust in memory/cortex integration.

Acceptance criteria

1. Distill extraction coverage

• Distill extracts additional high-signal user facts/goals/preferences/constraints from session user messages beyond the current narrow phrase set.
• Distill writes are idempotent and observable with deterministic reason codes on skip/failure.

2. Gateway status + web UI observability

• /gateway/status gateway.web_ui.memory_distill_runtime reports: enabled, in_flight, cycle_count, writes_applied, write_failures, checkpoint path, last_cycle timestamps/counters, and recent write summaries.
• Failures are hard-fail/explicit in status reason codes; no silent fallback semantics.

3. TUI operator surface

• Add first-class /memory-distill command (keep /memory alias) that renders current distill runtime snapshot from gateway sync.
• Output is concise and deterministic, includes last cycle stats and recent writes/reason codes.

4. Webchat/dashboard parity

• Webchat/dashboard memory-related surfaces expose the same distill runtime status contract so TUI and webchat are not divergent islands.

5. Integration coverage

• Add integration tests proving: user turn appended -> distill cycle runs -> memory entry persisted -> status surfaces updated -> TUI command/web endpoint reflect same state.

Non-goals

• Full TUI visual redesign.
• New memory model/ontology redesign.
• Provider-level LLM/tool orchestration changes unrelated to distill observability.

Notes

• Keep strict error semantics: no silent fallbacks, explicit structured reason codes.
• Preserve existing command compatibility while adding /memory-distill.

[njfio]

Spec created: \n\nProceeding with TDD gates (RED -> GREEN -> REFACTOR -> INTEGRATION).

[njfio]

Spec created at specs/3570-memory-distill-cortex-visibility.md.\n\nProceeding with TDD gates (RED -> GREEN -> REFACTOR -> INTEGRATION).

[njfio]

Implementation complete on branch with TDD arc commits:\n- docs(3570): spec\n- test(3570): RED tests\n- feat(3570): status + extraction + TUI alias\n- refactor(3570): dedupe helpers\n- integrate(3570): startup command surface wiring\n\nKey outcomes:\n- Distill extraction expanded (, , patterns).\n- now includes per-cycle counters and status data.\n- TUI now accepts (alias to ) and renders last-cycle + recent-write lines in memory snapshot sync output.\n\nTargeted verification commands are listed in .

[njfio]

Implementation complete on branch codex/issue-3558-timeout-marker-clarity with TDD arc commits (docs/test/feat/refactor/integrate).\n\nKey outcomes:\n- Distill extraction expanded for phrases: call me, i am based in, i am allergic to.\n- gateway.web_ui.memory_distill_runtime now includes per-cycle counters and recent_writes status data.\n- TUI accepts /memory-distill (alias of /memory) and renders last-cycle + recent-write lines in memory snapshot output.\n\nTargeted verification commands are listed in specs/3570-memory-distill-cortex-visibility.md.

[njfio]

Follow-up scope (same issue): add operator-visible failure rendering contract.\n\nAdditional AC:\n- When a turn fails (for example with error payload) and no assistant answer text exists, TUI must append a concise explicit failure line into the Assistant pane so operators never see a blank assistant result on failed turns.

[njfio]

Follow-up scope (same issue): add operator-visible failure rendering contract.\n\nAdditional AC:\n- When a turn fails with an error payload and no assistant answer text exists, TUI must append a concise explicit failure line into the Assistant pane so operators never see a blank assistant result on failed turns.

[njfio]

Follow-up failure-visibility fix is now implemented and pushed to PR #3571.\n\nBehavior now:\n- Structured turn.failed events append an Assistant pane error line when no assistant answer text exists.\n- Plain runtime stderr failures (interactive turn failed / request timed out / request cancelled) also append Assistant pane error fallback.\n- Duplicate identical failure lines are deduped.\n\nTargeted tests passed for all three paths.

[njfio]

Follow-up stale-status fix pushed: turn.submitted now always resets progress to queued and parses numeric string prompt_chars, so old failed status does not linger into new turns. Added regression and verification evidence in spec.