docs(notifications): change-driven in-app notification design#677
Merged
Conversation
…og rewrite The shipped bell MVP only counts report.ready, which is the least valuable thing it could surface. Repoint it at meaningful state changes — first the write-on-change transaction log (a passing rule now failing), plus connectivity loss, compliance band drops, fleet drift, failed scans/remediation, and governance items needing a decision. Adds docs/engineering/notifications_design.md: two-surface model (Activity vs Notifications), a producer-anchored taxonomy (transactions state_changed / first_seen, alertrouter host_unreachable/recovered/drift_*, exceptions, license), explicit noise exclusions, an architecture that adds an in-app channel to the existing alertrouter + a transaction-log regression projector feeding a durable per-user notifications table, RBAC scoping, grouping/dedup, and a 4-slice phasing. Rewrites the BACKLOG row from 'Planned' to 'Partial (MVP shipped)' around this change-driven model.
github-actions
Bot
added
documentation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Repoints the in-app notification bell from
report.readyto meaningful state changes, per the discussion.What & why
A bell that counts finished reports surfaces the least valuable thing it could. The headline case is the one this app is built for: a rule that was passing is now failing — already a first-class record in the write-on-change
transactionslog (state_changed/first_seen). Most of the change-detection already exists (alertrouterclassifieshost_unreachable/host_recovered/drift_*with severity + dedup;driftsuppresses sub-threshold jitter), so this is mostly surfacing data, not computing it.Contents
docs/engineering/notifications_design.md(new): two-surface model (Activity = everything; Notifications = the actionable per-user subset), a producer-anchored taxonomy (compliance regressions, fleet health, scans, remediation, governance, security, reports — each tied to a real identifier), explicit noise exclusions (no scheduler ticks / package churn / sub-threshold jitter), an architecture that adds an in-app channel to the existingalertrouter+ a small transaction-log regression projector → a durable per-usernotificationstable →GET /api/v1/notifications+ unread +:markRead+ drawer + SSE push, plus RBAC scoping, grouping/dedup, and a 4-slice phasing.BACKLOG.md: rewrites the In-app notifications row from "Planned" to "Partial (MVP shipped)" around the change-driven model (the MVP bell +report.readybump is actually live, just pointed at the wrong thing).Docs-only. Slice 1 (durable feed + wire the existing alerts into the bell) is the recommended starting point.