Implement notifications for disputes and reviewable photos #27

New issue

Open

opened 2026-07-28 04:55:10 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-28 04:55:10 +00:00

Context

The Phase 2 acceptance criteria require notifications to fire for disputes and newly
reviewable photos. Collaborative review across a family stalls without them â€” nobody
polls a review queue voluntarily.

Scope

Notification generation and delivery for the events that need a human.

Implementation notes

Trigger events: a photo is disputed, a dispute you are involved in is resolved, you are
mentioned in a comment, a new batch finishes ingest and is ready to review, and a
background job you started fails.
In-app notification centre first â€” it needs no external configuration and works for a
local-only deployment. Put delivery behind an interface so email or another channel can
be added later without touching the trigger sites.
Per-user preferences per event type, including off entirely.
Batch or digest high-volume events. A 400-photo ingest must produce one notification,
not four hundred â€” an unbatched flood trains people to ignore notifications permanently.
Never notify someone about their own action.
Read/unread state with a bulk mark-all-read.
Generation belongs on the worker, not in the request path. A slow or failing
notification must not slow down or fail the review action that triggered it.

Done when

Disputes, mentions, resolutions, ready-to-review batches, and job failures generate notifications
Users can configure preferences per event type
High-volume events are batched
Self-triggered actions never notify
Notification failures never affect the originating action

References

docs/circa-spec.md Phase 2 acceptance criteria

Depends on: multi-user roles and attribution, threaded comments, #2 (worker runtime).

## Context The Phase 2 acceptance criteria require notifications to fire for disputes and newly reviewable photos. Collaborative review across a family stalls without them â€” nobody polls a review queue voluntarily. ## Scope Notification generation and delivery for the events that need a human. ## Implementation notes - Trigger events: a photo is disputed, a dispute you are involved in is resolved, you are mentioned in a comment, a new batch finishes ingest and is ready to review, and a background job you started fails. - In-app notification centre first â€” it needs no external configuration and works for a local-only deployment. Put delivery behind an interface so email or another channel can be added later without touching the trigger sites. - Per-user preferences per event type, including off entirely. - Batch or digest high-volume events. A 400-photo ingest must produce one notification, not four hundred â€” an unbatched flood trains people to ignore notifications permanently. - Never notify someone about their own action. - Read/unread state with a bulk mark-all-read. - Generation belongs on the worker, not in the request path. A slow or failing notification must not slow down or fail the review action that triggered it. ## Done when - [ ] Disputes, mentions, resolutions, ready-to-review batches, and job failures generate notifications - [ ] Users can configure preferences per event type - [ ] High-volume events are batched - [ ] Self-triggered actions never notify - [ ] Notification failures never affect the originating action ## References - `docs/circa-spec.md` Phase 2 acceptance criteria Depends on: multi-user roles and attribution, threaded comments, #2 (worker runtime).

claude-bot added this to the v0.4.0 milestone

2026-07-28 04:55:10 +00:00

claude-bot added the

frontend

enhancement

backend

labels

2026-07-28 04:55:10 +00:00

claude-bot referenced this issue

2026-07-28 04:57:34 +00:00

Build the admin notification configuration UI #39

claude-bot referenced this issue