chore: sync GovOPlaN module split state
This commit is contained in:
35
docs/UNIFIED_INBOX_CONCEPT.md
Normal file
35
docs/UNIFIED_INBOX_CONCEPT.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# Unified Inbox Concept
|
||||
|
||||
GovOPlaN should converge messages, tasks, notifications, postbox items, and
|
||||
workflow exceptions into a unified inbox without making one module own every
|
||||
item type.
|
||||
|
||||
## Purpose
|
||||
|
||||
Users should have one place to see work requiring attention:
|
||||
|
||||
- assigned tasks
|
||||
- workflow manual exceptions
|
||||
- postbox messages
|
||||
- notifications
|
||||
- approvals
|
||||
- failed automation requiring review
|
||||
- appointment or booking decisions
|
||||
|
||||
Each item remains owned by its domain module. The inbox is an aggregation and
|
||||
action surface.
|
||||
|
||||
## Contract
|
||||
|
||||
Inbox contributors should provide:
|
||||
|
||||
- item id and owning module
|
||||
- actor/tenant visibility rules
|
||||
- title, summary, priority, due date, and status
|
||||
- required action and available commands
|
||||
- source object references
|
||||
- audit/provenance links
|
||||
- dismissal, completion, or deferral semantics
|
||||
|
||||
The inbox must use core-mediated capabilities and DTOs. It should not import
|
||||
postbox, workflow, notification, or approval internals.
|
||||
Reference in New Issue
Block a user