feat(timeline): Integrate memory timeline endpoint end-to-end - #218
Merged
Conversation
Wire the existing GET /timeline uteke-server endpoint through all
3 Corin layers — Tauri command, IPC wrapper, and UI component.
## What
- Layer 1 (Rust): Tauri command + register in lib.rs
- Layer 2 (TS): type + IPC wrapper
- Layer 3 (UI): Timeline section in MemoryDetail.svelte with:
- Vertical timeline with colored event dots (6 event types)
- Collapsible (shows 5, expand for more)
- Relative timestamps ("2h ago")
- Graceful empty/loading states
- Non-fatal: silently empty if uteke-serve unavailable
## Why
The timeline endpoint was fully implemented in uteke-server and the
Rust HTTP client already had timeline() — but the frontend never
called it. This closes the 3-layer gap, letting users see the full
event history of a memory (created, recalled, updated, etc.).
## Changes
- commands.rs: +26 lines (new command)
- lib.rs: +2 lines (handler registration)
- MemoryDetail.svelte: +168 lines (state, helpers, UI, CSS)
- ipc.ts: +9 lines (import + wrapper function)
- types.ts: +9 lines (TimelineEvent interface)
## Testing
- Rust compiles with edition 2024 (async fn + let chains)
- Svelte syntax valid
- Non-fatal error handling: all 3 layers degrade gracefully
when uteke-serve is unavailable (returns empty array)
🔍 Cora AI Code Review✅ No issues found. Code looks good! Review powered by cora-code · BYOK · MIT |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Wire the existing
GET /timelineuteke-server endpoint through all 3 Corin layers — Tauri command, IPC wrapper, and UI component.Why
The timeline endpoint was fully implemented in uteke-server (
handlers.rs:1810,api_registry.rs:455) and the Corin Rust HTTP client already hadtimeline()— but the frontend never called it. This was the single largest untapped endpoint in the Corin audit (38/57 = 67% coverage).This PR closes the 3-layer gap, letting users see the full chronological event history of a memory: when it was created, recalled, updated, consolidated, tagged, or forgotten.
Changes
Layer 1 — Tauri Command (Rust)
commands.rs(+26 lines): Newmemory_timelinecommandid: String+ optionallimit(default 50)Vec<TimelineEvent>— empty array if server unavailableUtekeClient::timeline()method (no new HTTP code)Layer 2 — IPC Wrapper (TypeScript)
types.ts(+9 lines):TimelineEventinterfaceipc.ts(+9 lines):memoryTimeline()async functionLayer 3 — UI Component (Svelte)
MemoryDetail.svelte(+168 lines): Timeline section between feedback and neighborsLayer 4 — Styling (CSS)
Testing
cargo fmt— passDesign Decisions
Why in MemoryDetail? Timeline is memory-specific history. It belongs alongside content, metadata, and neighbors — not as a separate view.
Why 5-item collapse? Prevents timeline from dominating the detail panel for memories with hundreds of events. Users can expand for full history.
Why not a separate TimelineView? The data is per-memory, not per-namespace. A separate view would require a memory selector, adding unnecessary navigation.