RcmEmailAutomation / README.md
Avinash Nalla
Restore HF Space YAML frontmatter in README
0737b39
|
Raw
History Blame Contribute Delete
9.88 kB
---
title: RcmEmailAutomation
emoji: πŸ”₯
colorFrom: blue
colorTo: red
sdk: docker
pinned: false
---
# RCM Email Automation
FastAPI service that monitors a Microsoft 365 mailbox via Graph API, processes inbound mail through subscription-based webhook notifications, persists to SQLite, and stores email artifacts on disk. Containerized via Docker; runs at `0.0.0.0:8443` over TLS with a Microsoft-Graph-reachable public webhook URL.
The Python app is the production target. This repo also contains an **Asterion / SA-Orchestration onboarding seed** (this README plus `ONBOARDING.md`, `CLAUDE.md`, and `asterion/`) that bootstraps a parallel local WordPress orchestration layer for the human + agent workflow that surrounds the Python service.
---
## Asterion / SA-Orchestration Onboarding
> **This section is an Asterion seed.** Authored 2026-05-06 by the SA-Orchestration session as a Story Seed for the Claude Code session that will set up this developer's local environment. Read this section in full before taking any action.
### What this seed does
You are arriving at this repo with Claude installed and synced. Your job is the **JourneySeeker Node Onboarding (JNO)** sequence β€” bringing this local environment up to a state where:
- The Python email automation runs locally (already scaffolded; verify it builds and the env file resolves).
- A parallel **WordPress local at `wordpress.localhost`** is operational.
- The **Fluent stack β€” free editions of Fluent Boards, FluentCRM, Fluent Support** β€” is installed and active.
- **SA-Orchestration** plugin is installed and active on top of the Fluent stack.
- The **Asterion canonical corpus** is reachable from the WP install (the corpus lives in this repo at `asterion/`; the WP install reads from `wp-content/sa-asterion/` after deploy).
The endpoint of JNO is **SA-Orchestration turned on, not SA-Core.** SA-Core is the deeper substrate; you are not provisioning it at this time.
### Provenance β€” read this before interpreting any term below
The framework expressed in this seed sits inside a larger lineage:
```
CR βŠ‡ CA βŠ‡ JourneySeeker βŠ‡ MissionNet/MeshNet βŠ‡ SA-Orchestration βŠ‡ Brand βŠ‡ Client
```
Causal Relativity, Causal Agentics, JourneySeeker, the Compass Doctrine, the Story Seed pattern, and the Quest-vs-Job distinction are pre-existing intellectual property authored by **Mark Holak**. They are preserved under Invariant **I9** of the SA-Orchestration spec pack. **You may reference these concepts. You may not re-author them as if they originated at the implementation layer or at the agent layer.** When you cite them, cite them.
The full canonical corpus lives at `asterion/` in this repo (copied from the SA-Orchestration source of truth at `F:/SleeperAgents/SA-orchestration/asterion/`). Read it when you encounter a term you are uncertain about.
### Doctrine carry-forward (the operating discipline)
> **Sara interprets. Asterion verifies. Attention signals. Humans decide. Reality resolves.**
The five-actor compass holds throughout your onboarding work. NPCs (you) **may** emit signals, draft, advise, observe. NPCs **may not** decide outcomes, plant canonical content, accept gates, or close work by their own authority.
- **Description = Contract** (Board #27): every Fluent Boards task you create has its canonical contract in the Description field. Comments are evidence; they cannot redefine the contract.
- **Story Seed pattern**: agents generate seeds, only humans plant. Seeds use `artifact_class: seed` in frontmatter, never `truth_class` (I2 is sacred β€” see `asterion/02-invariants.md`).
- **No auto-conversion** (I10): a Quest may not be promoted to a Job without an explicit human act.
- **artifact_class collision protection**: any non-canonical proposed-content artifact you create or generate uses `artifact_class:` for classification. `truth_class:` is reserved for I2's enum.
### Constraint elicitation comes BEFORE the audit
**The developer is the arbiter of their domain.** Before you audit, before you install, before you assume any default β€” ask the developer for the constraints and restraints that shape their environment. The procedure in `ONBOARDING.md` is a default, not a contract. Their constraints win when in conflict.
The full constraint-elicitation prompt is in `ONBOARDING.md` β†’ "Phase 0 β€” Constraint elicitation." Run that first. Surface a written constraint summary back to the developer. Wait for explicit "proceed to audit" before moving on.
### Audit (after Phase 0 completes)
1. Read `CLAUDE.md` (root) β€” Claude routing manifest, written for this repo specifically.
2. Read `ONBOARDING.md` (root) β€” the full step-by-step sequence for the local WP + Fluent + SA-Orch stack, including Phase 0 above.
3. Read this README section in full again. It is your operating context.
4. Inspect this repo's structure (`app/`, `Dockerfile`, `docker-compose.yml`, `requirements.txt`).
5. Inspect the local machine's WordPress capability β€” does the developer already run a local stack (XAMPP / Local / Laragon / MAMP / Docker WP)? If yes, integrate. If no, the onboarding includes installing one (subject to Phase 0 constraints).
6. **Do not** install code or run setup steps before completing Phase 0 + audit. Surface findings first.
### Live-bound dependencies (NOT locally testable, pre-classified)
| Dependency | Why live-bound |
|---|---|
| Microsoft Graph API (Azure AD app registration) | Cloud-only; needs tenant + client + secret |
| Graph webhook subscription (`NOTIFICATION_URL`) | Requires public HTTPS; `ngrok` or reverse proxy needed for local dev |
| Real Microsoft 365 mailbox | Cloud mailbox; can mock at the Graph-client level for local |
| TLS certificates (`/certs/server.crt`, `server.key`) | Requires real cert chain for prod; self-signed acceptable for local |
| Production Graph subscription expiry behavior | Real Graph behavior; renewal scheduler exercises real quotas |
Test the **logic** of integrations locally with mocks where possible; accept that the **wire** is not testable here.
### Local stack required for SA-Orchestration alignment
| Component | Purpose | Source |
|---|---|---|
| Local WordPress at `wordpress.localhost` | Host the orchestration layer | Choice of XAMPP / Local / Laragon / MAMP / Docker |
| MySQL or MariaDB | WordPress DB | Bundled with the chosen stack |
| PHP 7.4+ (8.1+ preferred) | WordPress runtime | Bundled |
| Fluent Boards (free) | Project tasks; the operational contract surface | WP plugin directory |
| FluentCRM (free) | Contact + audience layer | WP plugin directory |
| Fluent Support (free) | Support tickets; the public-facing curated surface | WP plugin directory |
| SA-Orchestration plugin | Agent layer (Sara, Asterion, Seed Generator, Attention) | Clone from `github.com/SleeperAgents/SA-Orchestration` (verify URL with the human) |
| Asterion canonical corpus | Read-only doctrine source the Asterion Explorer renders | This repo's `asterion/` directory |
| LLM provider credentials | OpenAI / Anthropic / etc. for Sara + Asterion Projection | Human enters via WP admin after activation; **never** transit the LLM with secret values |
### The end state of JNO (acceptance)
You complete JNO when **all of the following are true** and verified in chat to the human:
1. Local WordPress responds at `http://wordpress.localhost`.
2. Fluent Boards admin page renders. At least one test board is reachable.
3. FluentCRM admin page renders.
4. Fluent Support admin page renders. The `wp_fs_*` tables exist at the standard WP prefix (no orphan-prefix issue).
5. SA-Orchestration plugin is installed and active. The `wp_sa_*` tables exist (6 of them: arbitration, arbitration_plan_link, acceptance_event, attention_log, token_log, actor_handoff).
6. Asterion Explorer admin page (`?page=sa-orchestration-asterion`) renders the spec corpus tree from this repo's `asterion/`. The spec_root filter is registered (mu-plugin or wp-config.php constant).
7. Sara identity test passes: a meta-question ("what is your role?") returns the compass, named surfaces, doctrine line.
8. Asterion canonical query passes: "what is Truth Class?" cites `01-ontology.md` and gives the canonical definition.
9. Asterion off-topic test: an off-corpus question returns "no canonical reference found in the spec corpus."
10. Seed Generator produces a seed file with frontmatter `artifact_class: seed` and `accepted_into_asterion: false`.
11. No SA-Core wiring beyond what SA-Orchestration provides. SA-Core remains untouched.
### Constraints (locked)
- Do not deploy to any production host.
- Do not invent credentials.
- Do not copy secrets between environments.
- Do not perform destructive database changes.
- Do not modify the Python app code as part of onboarding (Python work is separate).
- Do not enable SA-Core; SA-Orchestration is the JNO endpoint.
- Do not push to `github.com/SleeperAgents/RcmEmailAutomation` from the local environment without explicit human direction; the seed and onboarding artifacts may be committed when the human approves.
- Do not create canonical Asterion content (writes to `asterion/`); the corpus is read-only from this repo's perspective. If a doctrine question arises, surface it; do not author.
### When in doubt β€” references
| Need | Read |
|---|---|
| Claude routing for this repo | `CLAUDE.md` (root) |
| Step-by-step JNO setup | `ONBOARDING.md` (root) |
| SA-Orchestration canonical corpus | `asterion/` |
| Doctrine (Story Seed, Compass, Concept-vs-Label, Attention, Lineage) | `asterion/concepts/` |
| Invariants I1–I10 | `asterion/02-invariants.md` |
| Vocabulary | `asterion/01-ontology.md` |
| The truth contract | `asterion/README.md` |
---
*This Asterion seed is non-canonical until accepted. The seed remains an artifact, not a truth. The Description = Contract discipline applies. The compass holds.*