From 12b4e498e193b550b7bfdedba9e2ffb44d0e4124 Mon Sep 17 00:00:00 2001
From: Albrecht Degering <albrecht@degering.name>
Date: Fri, 10 Jul 2026 12:51:23 +0200
Subject: [PATCH] chore: sync GovOPlaN module split state

---
 docs/UNIFIED_INBOX_CONCEPT.md | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)
 create mode 100644 docs/UNIFIED_INBOX_CONCEPT.md

diff --git a/docs/UNIFIED_INBOX_CONCEPT.md b/docs/UNIFIED_INBOX_CONCEPT.md
new file mode 100644
index 0000000..fb7ded8
--- /dev/null
+++ b/docs/UNIFIED_INBOX_CONCEPT.md
@@ -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.