CLAUDE.md

RCM Email Automation — Claude Operational Context

── START HERE ──────────────────────────────────────────────────────────────

This repo is a dual-surface environment:

1. Python service (FastAPI + Microsoft Graph) — the production target. Code in app/. Containerized via Docker.
2. Asterion / SA-Orchestration onboarding (this is what you are doing) — bringing up a parallel local WordPress + Fluent stack + SA-Orchestration on this machine for the human + agent workflow that surrounds the Python service.

Read first, in order:

1. README.md (root) → "Asterion / SA-Orchestration Onboarding" section
2. ONBOARDING.md (root) → step-by-step JNO setup
3. asterion/README.md → the truth contract
4. asterion/01-ontology.md and asterion/02-invariants.md → vocabulary + laws

After reading these four, audit the local environment. Do not run setup commands until the audit is complete and surfaced in chat.

---

── DOCTRINE LINE (operating discipline) ───────────────────────────────────

Sara interprets. Asterion verifies. Attention signals. Humans decide. Reality resolves.

This compass holds for every action you take in this repo. You (the agent) are an NPC at the Sara position when interpreting, drafting, observing, advising. You may emit Attention. You may not resolve outcomes, plant canonical content, accept gates, or close work by your own authority. Reality — what the human confirmed, what the wire delivered, what the test actually passed — is the only resolver.

Failure mode this guards against: an agent that auto-accepts work, closes a question by its own judgment, or marks something "done" before reality has confirmed it. Stay on your position.

---

── PROVENANCE / I9 ─────────────────────────────────────────────────────────

The doctrine, vocabulary, invariants, and concepts in asterion/ are pre-existing intellectual property authored by Mark Holak. They are preserved under Invariant I9 of the SA-Orchestration spec pack. Cite them when you reference them. Do not re-author them as agent-original or implementation-original.

The framework lineage:

CR ⊇ CA ⊇ JourneySeeker ⊇ MissionNet/MeshNet ⊇ SA-Orchestration ⊇ Brand ⊇ Client

This SleeperAgents-internal project (RcmEmailAutomation) sits at the SA-Orchestration ⊇ Brand layer. Authority and oversight are direct SleeperAgents — no client-scoped carve-out.

---

── REPO LAYOUT (root level) ────────────────────────────────────────────────

F:\SleeperAgents\RcmEmailAutomation\
├── app/                     ← Python FastAPI service (production target)
│   ├── main.py
│   ├── auth.py, config.py, database.py, email_processor.py
│   ├── folder_resolver.py, graph_client.py, scheduler.py
│   ├── storage.py, subscription.py, webhook.py
│   └── __init__.py
├── asterion/                ← canonical doctrine corpus (read-only)
│   ├── 01-ontology.md       ← vocabulary lock
│   ├── 02-invariants.md     ← I1–I10 laws
│   ├── 03-realm-adapter-contract.md
│   ├── 04-async-execution.md
│   ├── 05-zoom-quantum-engine.md
│   ├── 06-toolbox-action-contract.md
│   ├── README.md            ← truth contract entry
│   ├── concepts/            ← Mark-Holak-authored framework artifacts
│   │   ├── attention-doctrine.md
│   │   ├── cognitive-heatsink.md
│   │   ├── compass-doctrine.md
│   │   ├── concept-vs-label.md
│   │   ├── legacy-prime-prompt.md
│   │   ├── lineage-chain.md
│   │   ├── prime-prompt-conjecture.md
│   │   ├── reference-traversal-continuity.md
│   │   ├── signal-telemetry-doctrine.md
│   │   └── story-seed-pattern.md
│   └── seeds/               ← (created at runtime; non-canonical)
├── Dockerfile               ← Python service container
├── docker-compose.yml       ← Python service orchestration
├── entrypoint.sh
├── requirements.txt         ← Python dependencies
├── .env.example             ← Azure AD / Graph config template
├── README.md                ← Asterion seed (read first)
├── ONBOARDING.md            ← JNO step-by-step (read second)
└── CLAUDE.md                ← THIS FILE

---

── WHAT YOU ARE DOING (THE TASK) ──────────────────────────────────────────

JourneySeeker Node Onboarding (JNO) — bring this machine to a state where SA-Orchestration is operational on a local WordPress install at wordpress.localhost, with the free Fluent stack underneath. Endpoint: SA-Orchestration turned on. Not SA-Core.

The 11 acceptance points of JNO are listed in README.md → "The end state of JNO." Verify each before claiming completion.

The Python service in app/ is separate work — do not modify it as part of JNO. JNO is the orchestration-layer setup that lives parallel to the Python service.

---

── CONSTRAINTS (LOCKED) ────────────────────────────────────────────────────

• Do not deploy to any production host.
• Do not modify the Python app/ code.
• Do not enable SA-Core. SA-Orchestration is the JNO endpoint.
• Do not invent credentials. Do not copy secrets between environments.
• Do not perform destructive database operations.
• Do not author content into asterion/ (read-only from this repo's perspective).
• Do not push to remote without explicit human direction.
• Do not assume capabilities the human has not declared. If you don't know whether a tool is installed, ask before running it.

---

── WHEN THE HUMAN SAYS "CHECK CLAUDE.MD" ──────────────────────────────────

That phrase is the full-sync trigger. When you hear it, re-read this file AND README.md (root, Asterion section) AND ONBOARDING.md AND asterion/README.md. Treat the state in those files as ground truth — discard any stale assumptions from earlier in the conversation.

---

── AT WORK START ──────────────────────────────────────────────────────────

Begin every session with:

1. Read this file in full.
2. Read README.md (Asterion section).
3. Read ONBOARDING.md.
4. Phase 0 — Constraint elicitation. 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 full prompt list is in ONBOARDING.md → Phase 0. Surface a constraint summary back to the developer; wait for explicit "proceed" before moving on.
5. Audit current local state (what's already installed, what's missing) — only after Phase 0 gates open.
6. Surface findings to the human before running any setup commands.

The compass holds. The developer's constraints override defaults. Stop and surface when uncertain.