33 lines
1.6 KiB
Markdown
33 lines
1.6 KiB
Markdown
# GovOPlaN Postbox Codex Guide
|
|
|
|
## Scope
|
|
|
|
This repository owns the `postbox` module: in-platform postboxes, function-organization-bound access, postbox messages, postbox directory APIs, internal and portal postbox surfaces, campaign postbox integration, postbox-owned migrations, and future `@govoplan/postbox-webui`.
|
|
|
|
Postboxes are not login-bound mailboxes. They are platform-owned communication and access containers whose visibility is derived primarily from effective identity-to-organization-function assignments, explicit postbox bindings, and capability contracts.
|
|
|
|
## Local Commands
|
|
|
|
Install and run through core:
|
|
|
|
```bash
|
|
cd /mnt/DATA/git/govoplan-core
|
|
./.venv/bin/python -m pip install -r requirements-dev.txt
|
|
```
|
|
|
|
For combined checks once implementation starts, run:
|
|
|
|
```bash
|
|
cd /mnt/DATA/git/govoplan
|
|
tools/checks/check-focused.sh
|
|
```
|
|
|
|
## Working Rules
|
|
|
|
- Keep postbox behavior in this module, not core.
|
|
- Resolve units and functions through Organizations and effective identity-to-function assignments through IDM. Use Core/Access for generic Postbox action authorization; do not turn a function assignment into an RBAC role merely to open its function postbox.
|
|
- Do not duplicate identity, organization, assignment, hierarchy, or RBAC logic locally.
|
|
- Do not import mail, files, campaign, or portal internals. Use manifests, capabilities, events, API routes, and typed DTOs.
|
|
- Treat postbox access changes as auditable security events, especially when access changes because a function assignment, delegation, acting context, or generic Postbox permission changes.
|
|
- Keep campaign delivery, file evidence, and portal usage optional behind capability boundaries.
|