Introduce a data-source abstraction behind all surfaces #38

New issue

Open

opened 2026-07-01 01:05:41 +00:00 by manlycucumber · 0 comments

manlycucumber commented

2026-07-01 01:05:41 +00:00

(Migrated from github.com)

Problem

Surfaces currently call the bundled engine directly. Introducing a single data-source interface lets the Api client, cache, and fallback sit behind one seam so surfaces do not care where data comes from.

Acceptance criteria

A data-source interface defines day and month retrieval.
All surfaces (today, strip, calendar, day view, pretty pages) call the interface, not the engine directly.
The interface implementation chains cache then Api then fallback.
Existing render-harness snapshots remain unchanged after the refactor.

Notes

Visual output must not regress; this is a plumbing change only.

## Problem Surfaces currently call the bundled engine directly. Introducing a single data-source interface lets the Api client, cache, and fallback sit behind one seam so surfaces do not care where data comes from. ## Acceptance criteria - [ ] A data-source interface defines day and month retrieval. - [ ] All surfaces (today, strip, calendar, day view, pretty pages) call the interface, not the engine directly. - [ ] The interface implementation chains cache then Api then fallback. - [ ] Existing render-harness snapshots remain unchanged after the refactor. ## Notes Visual output must not regress; this is a plumbing change only.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Directorium/Ordo#38

No description provided.

Rows
Columns