GKaszewski/k-mood
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Migrate Activities, photos and voice memos to the EntryDimension pattern #6

New Issue
Closed
opened 2026-08-26 09:13:34 +00:00 by GKaszewski · 0 comments
GKaszewski commented 2026-08-26 09:13:34 +00:00
Owner
Copy Link

What to build

Completes ADR 0002 by moving the three remaining dimensions onto the pattern proven in #1. After this, MoodEntry is exactly six fields — identity, User, Mood, the instant logged, and timestamps — and stops growing forever.

This is mechanical repetition of an established pattern, not new design. If it turns out not to be mechanical, that means #1's composer is wrong and the problem belongs there, not here.

These three already live in side tables, so there is no data migration — only the domain types, ports, composer registration, and mappers change.

The reason to finish rather than leave a partial retrofit: two competing answers to "what is attached to this entry" means every consumer has to know which dimension is which kind, and the split becomes permanent.

Acceptance criteria

  • MoodEntry has exactly six fields and no dimension accessors or setters
  • Activities, photos, and voice memos are each self-contained dimension modules
  • All four dimensions load through the same composer with no special cases
  • Photo and voice memo blob cleanup on removal still works
  • Filtering entries by Activity still works
  • Import, export, and the entry form round-trip all four dimensions unchanged
  • Existing test suite passes

Blocked by

## What to build Completes ADR 0002 by moving the three remaining dimensions onto the pattern proven in #1. After this, `MoodEntry` is exactly six fields — identity, User, Mood, the instant logged, and timestamps — and stops growing forever. This is mechanical repetition of an established pattern, not new design. If it turns out not to be mechanical, that means #1's composer is wrong and the problem belongs there, not here. These three already live in side tables, so there is no data migration — only the domain types, ports, composer registration, and mappers change. The reason to finish rather than leave a partial retrofit: two competing answers to "what is attached to this entry" means every consumer has to know which dimension is which kind, and the split becomes permanent. ## Acceptance criteria - [ ] `MoodEntry` has exactly six fields and no dimension accessors or setters - [ ] Activities, photos, and voice memos are each self-contained dimension modules - [ ] All four dimensions load through the same composer with no special cases - [ ] Photo and voice memo blob cleanup on removal still works - [ ] Filtering entries by Activity still works - [ ] Import, export, and the entry form round-trip all four dimensions unchanged - [ ] Existing test suite passes ## Blocked by - #1
GKaszewski added the ready-for-agent label 2026-08-26 09:13:34 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
needs-info
Waiting on reporter
 needs-triage
Maintainer needs to evaluate
 ready-for-agent
Fully specified; an AFK agent can pick it up with no human context
 ready-for-human
Needs human implementation or design review
 wontfix
Will not be actioned
No Label ready-for-agent
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GKaszewski
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GKaszewski/k-mood#6
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?