Domain ops: list, resolve, reference, and delete Media #190

New issue

Closed

opened 2026-08-12 05:57:25 +00:00 by rosa · 0 comments

rosa commented

2026-08-12 05:57:25 +00:00

Owner

Parent

Implementation spec: Media management: Library page and editor picker — implementation spec (§1.2–1.3).

What to build

The domain vocabulary the media-manage web surface consumes: listing a user's Media, resolving a picked Media id into a Post's Photo, listing the Posts a Media appears in, and deleting a Media with detach. Pure domain + repository work, verifiable through tests — the Library and picker tickets build the UI on top.

Acceptance criteria

list_media_for returns every Media the owner has, newest-first, with the ordering guaranteed by the repository rather than sorted by callers.
resolve_owned_photo performs the id-based existence + ownership check and yields a PhotoRef; foreign or missing ids resolve to nothing (callers must not be able to distinguish other users' Media from absent). No status gate — attaching a Processing Media is already legal via inline upload.
Micropub's existing photo resolution keeps its URL-parsing head and delegates its existence + ownership tail to resolve_owned_photo, so the ownership decision lives in one place. Behavior unchanged; existing tests pass untouched.
list_posts_referencing returns the Posts whose Photo points at the Media, any status, newest-first.
delete_media is owner-scoped: missing and foreign ids collapse to a single not-found error; a still-Processing Media is refused (the Reconciler owns that state's integrity); Ready and Failed both delete. Deletion detaches every referencing Post's Photo — including clearing the orphaned alt — and drops the rendition; disk returns via the existing reclamation tick, nothing extra here.
The repository-port additions are implemented in both the SQLite and in-memory repositories, with the in-memory one mimicking the detach. Deleting an unknown id at the repository layer is an idempotent no-op, so a concurrent-delete race cannot manufacture an error.
Conformance tests cover the new ops against both implementations, including the detach behavior (no mock-only tests).
mise run format, mise run ci, and mise run clippy pass.

Blocked by

None — can start immediately. (It edits the same Media Service and port modules as the filename-capture ticket, so running the two in parallel means a rebase, but neither gates the other.)

## Parent Implementation spec: [Media management: Library page and editor picker — implementation spec](https://code.cosmicrose.dev/rosa/vernier/issues/188) (§1.2–1.3). ## What to build The domain vocabulary the media-manage web surface consumes: listing a user's Media, resolving a picked Media id into a Post's Photo, listing the Posts a Media appears in, and deleting a Media with detach. Pure domain + repository work, verifiable through tests — the Library and picker tickets build the UI on top. ## Acceptance criteria - [ ] `list_media_for` returns every Media the owner has, newest-first, with the ordering guaranteed by the repository rather than sorted by callers. - [ ] `resolve_owned_photo` performs the id-based existence + ownership check and yields a PhotoRef; foreign or missing ids resolve to nothing (callers must not be able to distinguish other users' Media from absent). No status gate — attaching a Processing Media is already legal via inline upload. - [ ] Micropub's existing photo resolution keeps its URL-parsing head and delegates its existence + ownership tail to `resolve_owned_photo`, so the ownership decision lives in one place. Behavior unchanged; existing tests pass untouched. - [ ] `list_posts_referencing` returns the Posts whose Photo points at the Media, any status, newest-first. - [ ] `delete_media` is owner-scoped: missing and foreign ids collapse to a single not-found error; a still-Processing Media is refused (the Reconciler owns that state's integrity); Ready and Failed both delete. Deletion detaches every referencing Post's Photo — including clearing the orphaned alt — and drops the rendition; disk returns via the existing reclamation tick, nothing extra here. - [ ] The repository-port additions are implemented in both the SQLite and in-memory repositories, with the in-memory one mimicking the detach. Deleting an unknown id at the repository layer is an idempotent no-op, so a concurrent-delete race cannot manufacture an error. - [ ] Conformance tests cover the new ops against both implementations, including the detach behavior (no mock-only tests). - [ ] `mise run format`, `mise run ci`, and `mise run clippy` pass. ## Blocked by None — can start immediately. (It edits the same Media Service and port modules as the filename-capture ticket, so running the two in parallel means a rebase, but neither gates the other.)

rosa referenced this issue

2026-08-12 05:57:55 +00:00

Library page: browse, upload, and delete Media #191

rosa referenced this issue

2026-08-12 05:58:02 +00:00

Post editor picker: attach an existing Media from the library #192

rosa added the

workflow

ready-for-agent

label

2026-08-12 05:58:11 +00:00

rosa added a new dependency