Sync wiki from project files

Codex-Project-Index.md

@@ -5,5 +5,4 @@
 This page is generated from repository and product-directory project files.
 
 - [Repo-README](Repo-README) - `/mnt/DATA/git/govoplan-postbox/README.md`
-- [Repo-docs-POSTBOX-BACKLOG](Repo-docs-POSTBOX-BACKLOG) - `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_BACKLOG.md`
 - [Repo-docs-POSTBOX-CONCEPT](Repo-docs-POSTBOX-CONCEPT) - `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_CONCEPT.md`

Repo-docs-POSTBOX-CONCEPT.md

@@ -1,4 +1,4 @@
-<!-- codex-wiki-sync:995fac876969a8a7a228ec7d -->
+<!-- codex-wiki-sync:acf0243600f0d03c2bb67109 -->
 
 > Mirrored from `/mnt/DATA/git/govoplan-postbox/docs/POSTBOX_CONCEPT.md`.
 > Origin: `repository`.
@@ -13,6 +13,13 @@ GovOPlaN Postbox provides in-platform postboxes that are addressable containers
 
 The key distinction from a mailbox is ownership. A mailbox is usually bound to a login, user credential, or external mail account. A GovOPlaN postbox is bound to platform context: organization, role, process, portal, campaign, or service responsibility.
 
+The strategic target is an encrypted administrative postbox. The first
+implementation may start with ordinary persisted messages, but the model must
+not prevent later end-to-end encryption, role/function key epochs, signed
+manifests, external-recipient tokens, or honest retraction semantics. The
+cross-module target architecture is recorded in
+`govoplan-core/docs/POSTBOX_E2EE_ARCHITECTURE.md`.
+
 ## Role-Organization-Bound Access
 
 The special access pattern is a postbox linked to an organizational unit and one or more roles. A person can access that postbox while their identity has an effective matching role in that organizational unit.
@@ -94,6 +101,11 @@ Optional consumers:
 - Administration of bindings should require explicit postbox administration permission plus access/RBAC authority for the target organization.
 - Sensitive access decisions and binding changes should emit audit events.
 - Retention rules should be postbox-owned but able to reference campaign, file, and portal provenance.
+- Expiry, withdrawal, and retraction UI must distinguish future access control
+  from already fetched or decrypted plaintext.
+- Message metadata should preserve room for ciphertext manifests, wrapped keys,
+  key epochs, recipient device references, and external capability tokens even
+  before full E2EE ships.
 
 ## First Implementation Shape
 
@@ -108,3 +120,16 @@ The WebUI should start as an administration and inbox surface:
 - audit-visible administrative actions
 
 Campaign, files, portal, and mail behavior should arrive as optional integrations after the core postbox model is stable.
+
+## E2EE Readiness Checklist
+
+Before the data model is considered stable, verify that it can represent:
+
+- message or attachment ciphertext references
+- signed manifest references
+- recipient, role, or function key wrapping records
+- key epoch and device-key references
+- key-fetch/access audit events
+- external recipient token state
+- expiry and withdrawal state separate from deletion
+- retention state that can operate without decrypting content