m/paliad
1
0
Fork 0
Code Issues 146 Pull Requests 8 Actions 1 Packages Projects Releases Wiki Activity

Inbox overhaul: project-events feed, filtering, list/cards/calendar toggles (inventor design) #80

New Issue
Open
opened 2026-05-25 11:23:33 +00:00 by mAi · 0 comments
mAi commented 2026-05-25 11:23:33 +00:00
Collaborator
Copy Link

m's report (2026-05-25 12:47)

https://paliad.de/inbox currently only has approvals. We should introduce filtering and also display new events that relate to one's projects. Or maybe later other developments.

And i want to select different views as well - we need list / cards / calendar etc, like we have elsewhere.

Phase: inventor design (READ-ONLY)

Inventor → coder gate per project CLAUDE.md.

Context

/inbox today is approval-request-centric. m wants it to become the actual notification surface — recent developments tied to visible projects + view-toggle parity with /events and Custom Views.

Open design questions (R = recommended default — escalate only material picks)

  1. What event types belong in inbox?
    • Always: approval requests (current behavior).
    • (R) New (last 30 days?) events on visible projects: new deadlines, deadline-actual-set, new appointments, new notes, project membership changes, archive/unarchive.
    • Lower priority: dashboard digest items, paliadin chat unread, system messages.
    • Inventor picks the minimum viable set for slice A.
  2. Time window — last 30 days? Pinned-until-read?
    • (R) Last 30 days default, with a "show older" pagination knob.
  3. Read / unread state — per-user inbox_read_at per item, or a single high-watermark cursor ("everything before X is read")?
    • (R) Single high-watermark cursor per user — simpler, covers the common case of "I checked my inbox, mark all as read". Per-item dismiss can be slice B if asked.
  4. Filters:
    • By project (autocomplete from visible projects)
    • By type (approval / deadline / appointment / note / membership / …)
    • By read state (unread only)
    • Date range (uses the new symmetric picker if it lands first — otherwise the existing pattern)
  5. View toggle parity — same paradigm as /events:
    • list (default — table-style, dense)
    • cards (richer per-item layout, more breathing room)
    • calendar (only items that have a date — approvals + deadlines + appointments)
  6. Architecture — is /inbox reading from a derived feed view, or aggregating across paliad.events, paliad.deadlines, paliad.appointments, paliad.notes, etc. at request time?
    • (R) Aggregate at request time via a service that fans out per source (small N, well-indexed projects-visible filter). Avoid prematurely materialising a feed table.
  7. Notification badge — does the sidebar Inbox entry get a (n) badge for unread count?
    • (R) Yes — but slice B if the high-watermark cursor proves enough.
  8. Acknowledgement flow — current approvals page has accept/reject inline. Other inbox item types: just "mark read" or "open". Stay non-destructive.
  9. Empty-state copy — when no items, what does the page show?

Deliverable

docs/design-inbox-overhaul-2026-05-25.md on branch mai/<inventor>/inbox-overhaul. Sections:

  • §0 TL;DR
  • §1 Current /inbox state (read the existing code; enumerate the approvals data path)
  • §2 Event-type catalogue for inbox v1 (per Q1)
  • §3 Read/unread model decision (per Q3)
  • §4 Filter contract
  • §5 View toggle implementation plan (list/cards/calendar)
  • §6 Backend aggregation service (per Q6)
  • §7 Slice plan (A: list view + project-event aggregation + basic filters; B: card + calendar views; C: badge + per-item dismiss)
  • §8 Out of scope
  • §9 Open questions for m (only the picks the inventor couldn't default with R)

Hard rules

  • READ-ONLY design phase. No code, no migrations.
  • Head answers questions — NO AskUserQuestion. Inventor uses mai instruct head. Defaults to (R); escalate to head only on material picks (esp. Q1 — what counts as an inbox item).
  • Read the existing /inbox code before designing — the current shape will inform what aggregates cleanly.

When done

Push design doc + mai report completed with "DESIGN READY FOR REVIEW". Inventor stays parked. Head gates coder shift.

Out of scope

  • Push notifications (Telegram, e-mail, WA) — those are separate channel routing concerns.
  • Cross-user inbox views (admin sees others' inboxes) — single-user only for v1.
  • Pinning / starring items.
## m's report (2026-05-25 12:47) > https://paliad.de/inbox currently only has approvals. We should introduce filtering and also display new events that relate to one's projects. Or maybe later other developments. > > And i want to select different views as well - we need list / cards / calendar etc, like we have elsewhere. ## Phase: inventor design (READ-ONLY) Inventor → coder gate per project CLAUDE.md. ## Context `/inbox` today is approval-request-centric. m wants it to become the actual notification surface — recent developments tied to visible projects + view-toggle parity with /events and Custom Views. ## Open design questions (R = recommended default — escalate only material picks) 1. **What event types belong in inbox?** - Always: approval requests (current behavior). - **(R) New (last 30 days?)** events on visible projects: new deadlines, deadline-actual-set, new appointments, new notes, project membership changes, archive/unarchive. - Lower priority: dashboard digest items, paliadin chat unread, system messages. - Inventor picks the minimum viable set for slice A. 2. **Time window** — last 30 days? Pinned-until-read? - **(R)** Last 30 days default, with a "show older" pagination knob. 3. **Read / unread state** — per-user `inbox_read_at` per item, or a single high-watermark cursor ("everything before X is read")? - **(R)** Single high-watermark cursor per user — simpler, covers the common case of "I checked my inbox, mark all as read". Per-item dismiss can be slice B if asked. 4. **Filters**: - By project (autocomplete from visible projects) - By type (approval / deadline / appointment / note / membership / …) - By read state (unread only) - Date range (uses the new symmetric picker if it lands first — otherwise the existing pattern) 5. **View toggle parity** — same paradigm as `/events`: - **list** (default — table-style, dense) - **cards** (richer per-item layout, more breathing room) - **calendar** (only items that have a date — approvals + deadlines + appointments) 6. **Architecture** — is `/inbox` reading from a derived feed view, or aggregating across `paliad.events`, `paliad.deadlines`, `paliad.appointments`, `paliad.notes`, etc. at request time? - **(R)** Aggregate at request time via a service that fans out per source (small N, well-indexed projects-visible filter). Avoid prematurely materialising a feed table. 7. **Notification badge** — does the sidebar `Inbox` entry get a (n) badge for unread count? - **(R)** Yes — but slice B if the high-watermark cursor proves enough. 8. **Acknowledgement flow** — current approvals page has accept/reject inline. Other inbox item types: just "mark read" or "open". Stay non-destructive. 9. **Empty-state copy** — when no items, what does the page show? ## Deliverable `docs/design-inbox-overhaul-2026-05-25.md` on branch `mai/<inventor>/inbox-overhaul`. Sections: - §0 TL;DR - §1 Current `/inbox` state (read the existing code; enumerate the approvals data path) - §2 Event-type catalogue for inbox v1 (per Q1) - §3 Read/unread model decision (per Q3) - §4 Filter contract - §5 View toggle implementation plan (list/cards/calendar) - §6 Backend aggregation service (per Q6) - §7 Slice plan (A: list view + project-event aggregation + basic filters; B: card + calendar views; C: badge + per-item dismiss) - §8 Out of scope - §9 Open questions for m (only the picks the inventor couldn't default with R) ## Hard rules - READ-ONLY design phase. No code, no migrations. - **Head answers questions** — NO AskUserQuestion. Inventor uses `mai instruct head`. Defaults to (R); escalate to head only on material picks (esp. Q1 — what counts as an inbox item). - Read the existing `/inbox` code before designing — the current shape will inform what aggregates cleanly. ## When done Push design doc + `mai report completed` with "DESIGN READY FOR REVIEW". Inventor stays parked. Head gates coder shift. ## Out of scope - Push notifications (Telegram, e-mail, WA) — those are separate channel routing concerns. - Cross-user inbox views (admin sees others' inboxes) — single-user only for v1. - Pinning / starring items.
mAi self-assigned this 2026-05-25 11:23:33 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
deferred
Parked — not pursuing now, may un-park later
done
Work completed by an agent; awaiting m to close
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
mAi m
No Assignees mAi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: m/paliad#80
No description provided.
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?