Group/stack decisions: date the event, not the photo #109

New issue

Open

opened 2026-07-28 06:06:03 +00:00 by claude-bot · 0 comments

claude-bot commented

2026-07-28 06:06:03 +00:00

Severity: HIGH value

The idea

Most of a collection arrives in event-sized clumps — a roll of film is 24 photos of the same two
days. Forcing one decision per photo multiplies total work by roughly the average event size.

Multi-select in the browser or album (plus auto-suggested clusters from album adjacency and
near-duplicate similarity from #16), form an event group, then make one date decision that
fans out to every member as individual DateDecision rows sharing provenance.

Why it preserves the product's covenant

This is not auto-approval. It is one deliberate, explicitly scoped human decision — the reviewer
sees exactly which photos they are deciding for. A member can be individually re-decided later
without breaking the group.

Also implements PhotoGroup

docs/circa-spec.md §8 specifies a PhotoGroup entity — "Christmas 1989" event groups with
bounds and auto_grouped — which is absent from the models and tracked nowhere. #19 is titled
"group constraint propagation" but its body only uses albums and anchors. This issue creates the
missing entity.

Scope

PhotoGroup model and migration, with label, date bounds, and auto_grouped.
Multi-select in browser and album views, with keyboard-friendly range selection.
"Group as event" action, then a group date decision.
Per-photo DateDecision rows written transactionally, each recording the group id in provenance.
The constraint engine (#19) treats group bounds as the spec already describes.
Auto-suggested groups from album adjacency and pHash similarity, always confirmed by a human.

Honest assessment

The riskiest part is bulk-selection ergonomics, not the data model. Probably the single largest
reducer of total project hours in the backlog.

Done when

A reviewer can group photos and date them in one action
Every member gets its own decision row with shared provenance
A member can be individually re-decided
Groups feed constraint propagation
Auto-suggestions are proposals only

References

docs/circa-spec.md §8 (PhotoGroup)

Depends on: #18 (album ordering) helps; #16 (pHash) improves suggestions.

## Severity: HIGH value ## The idea Most of a collection arrives in event-sized clumps — a roll of film is 24 photos of the same two days. Forcing one decision per photo multiplies total work by roughly the average event size. Multi-select in the browser or album (plus auto-suggested clusters from album adjacency and near-duplicate similarity from #16), form an event group, then make **one** date decision that fans out to every member as individual `DateDecision` rows sharing provenance. ## Why it preserves the product's covenant This is not auto-approval. It is one deliberate, explicitly scoped human decision — the reviewer sees exactly which photos they are deciding for. A member can be individually re-decided later without breaking the group. ## Also implements PhotoGroup `docs/circa-spec.md` §8 specifies a `PhotoGroup` entity — "Christmas 1989" event groups with bounds and `auto_grouped` — which is absent from the models and tracked nowhere. #19 is *titled* "group constraint propagation" but its body only uses albums and anchors. This issue creates the missing entity. ## Scope - `PhotoGroup` model and migration, with label, date bounds, and `auto_grouped`. - Multi-select in browser and album views, with keyboard-friendly range selection. - "Group as event" action, then a group date decision. - Per-photo `DateDecision` rows written transactionally, each recording the group id in provenance. - The constraint engine (#19) treats group bounds as the spec already describes. - Auto-suggested groups from album adjacency and pHash similarity, always confirmed by a human. ## Honest assessment The riskiest part is bulk-selection ergonomics, not the data model. Probably the single largest reducer of total project hours in the backlog. ## Done when - [ ] A reviewer can group photos and date them in one action - [ ] Every member gets its own decision row with shared provenance - [ ] A member can be individually re-decided - [ ] Groups feed constraint propagation - [ ] Auto-suggestions are proposals only ## References - `docs/circa-spec.md` §8 (`PhotoGroup`) Depends on: #18 (album ordering) helps; #16 (pHash) improves suggestions.

claude-bot added this to the v0.4.0 milestone

2026-07-28 06:06:03 +00:00

claude-bot added the

backend

enhancement

frontend

labels

2026-07-28 06:06:03 +00:00

claude-bot referenced this issue

2026-07-28 06:07:52 +00:00

Implement the group constraint propagation engine #19