Sync wiki from project files

Codex-Project-Index.md

@@ -5,3 +5,4 @@
 This page is generated from repository and product-directory project files.
 
 - [Repo-README](Repo-README) - `/mnt/DATA/git/govoplan-mail/README.md`
+- [Repo-docs-MAIL-PROTOCOL-ROADMAP](Repo-docs-MAIL-PROTOCOL-ROADMAP) - `/mnt/DATA/git/govoplan-mail/docs/MAIL_PROTOCOL_ROADMAP.md`

Repo-README.md

@@ -1,4 +1,4 @@
-<!-- codex-wiki-sync:ff2ec077f7ec5c5d857c3379 -->
+<!-- codex-wiki-sync:d8151662f7ed0ba554199c1f -->
 
 > Mirrored from `/mnt/DATA/git/govoplan-mail/README.md`.
 > Origin: `repository`.
@@ -57,7 +57,20 @@ Frontend package:
 @govoplan/mail-webui
 ```
 
-The campaign module depends on this module for sending, append-to-Sent behavior, profile selection, and read-only mailbox inspection.
+The campaign module consumes `mail.campaign_delivery` for sending,
+append-to-Sent behavior, profile selection, and policy checks. Mail does not
+import campaign internals; campaign-scoped policy and owner context are resolved
+through the core `campaigns.mailPolicyContext` capability when the campaign
+module is installed.
+
+Development mailbox routes are registered by the mail module only when the
+core runtime is in `dev` mode and `dev_mailbox_api_enabled` is enabled. Core
+does not contribute these routes directly.
+
+POP3 and JMAP are deferred. The protocol decision is documented in
+[docs/MAIL_PROTOCOL_ROADMAP.md](docs/MAIL_PROTOCOL_ROADMAP.md): stabilize
+SMTP/IMAP first, prefer JMAP for modern mailbox sync/search later, and add POP3
+only for explicit legacy-download requirements.
 
 Platform RBAC and governance rules are documented in `govoplan-core/docs/`.
 

Repo-docs-MAIL-PROTOCOL-ROADMAP.md

@@ -0,0 +1,57 @@
+<!-- codex-wiki-sync:4b23dd9ca1e75c81edfd3053 -->
+
+> Mirrored from `/mnt/DATA/git/govoplan-mail/docs/MAIL_PROTOCOL_ROADMAP.md`.
+> Origin: `repository`.
+> Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.
+
+---
+# Mail Protocol Roadmap
+
+GovOPlaN Mail currently focuses on SMTP sending and IMAP mailbox access. POP3
+and JMAP are deferred until the IMAP mailbox MVP is stable.
+
+## Current Baseline
+
+- SMTP is the send protocol.
+- IMAP is the read/append protocol.
+- Mail profile policy, encrypted credentials, mailbox folder parsing, test
+  buttons, and read-only mailbox UI are built around SMTP and IMAP.
+
+This baseline matches the first production use case: send campaign mail, append
+sent copies when configured, and inspect mailboxes read-only.
+
+## JMAP
+
+JMAP is the preferred future sync/search protocol where target mail servers
+support it.
+
+Reasons:
+
+- HTTP/JSON transport fits the platform API style better than stateful IMAP
+- efficient mailbox state sync and changes endpoints
+- modern search and thread models
+- better fit for browser-facing mailbox UX through a server proxy
+
+JMAP should be added only after:
+
+- the IMAP mailbox MVP has stable folder/message pagination behavior
+- mail profile policy can express protocol-specific availability
+- mailbox UI can handle protocol-neutral folder/message DTOs
+- test infrastructure includes at least one reliable JMAP server target
+
+## POP3
+
+POP3 should remain legacy-only.
+
+Add it only when a concrete deployment requires mailbox download from a server
+that cannot offer IMAP or JMAP. POP3 is a poor fit for the normal GovOPlaN
+mailbox UX because it has limited folder, sync, and server-side state semantics.
+
+If implemented, POP3 should be scoped to explicit download/import workflows, not
+general mailbox browsing.
+
+## Decision
+
+Do not add POP3 or JMAP now. Stabilize SMTP/IMAP first, design protocol-neutral
+mailbox DTOs, then prefer JMAP for modern servers and reserve POP3 for explicit
+legacy download requirements.