# Email Triage Instructions

*Created: 2026-02-01*
*Updated: 2026-02-07 (Added Specific Sender Rules)*

## Message Center (MC) API

**Unified endpoint for all messages (email + WhatsApp):**
- Base URL: `http://localhost:8025`
- Fetch new: `GET /messages/new`
- Replay: `GET /messages?since=24h`
- Actions: `POST /messages/{id}/archive`, `/delete`, `/reply`, `/to-docs`, `/seen`

**Account identifiers:**
- `tj_jongsma_me` (tj@jongsma.me) — family/shared account
- `johan_jongsma_me` (johan@jongsma.me) — Johan's personal account
- `whatsapp` — WhatsApp messages

All messages use unified ID format: `{source}:{sourceID}` (e.g., `tj_jongsma_me:12345`)

## CRITICAL RULE

**ALWAYS read the FULL message content before triaging. NO EXCEPTIONS.**

Every email gets read in full — regardless of sender, subject, or apparent category. The content determines the action.

## Reporting Rule (2026-02-08, updated 2026-02-09)

- **Needs Johan's attention** (kept in inbox, flagged, Sophia-related, action required) → Ping immediately
- **All other processing** (trash, archive, shipping updates, routine) → Batched summary at **9:00 AM** and **9:00 PM** ET via cron jobs
- Do NOT ping Johan for every routine email processed
- **DO NOT RE-REPORT:** Before pinging about an email, check recent session history / daily memory. If you already told Johan about it, don't tell him again. Un-actioned in inbox ≠ unreported. Emails stay in inbox until Johan acts — that's by design, not a signal to re-alert.

---

## Attachment Processing

When emails have attachments (`has_attachments: true`, `attachment_names: [...]`), decide if any are worth archiving.

### Trigger Ingest (Forward to Documents Inbox)
```bash
curl -X POST "http://localhost:8025/messages/{id}/to-docs" \
  -H "Content-Type: application/json" \
  -d '{"attachments": ["invoice.pdf"]}'
```

MC fetches attachments and saves to `~/documents/inbox/` for DocSys processing.

**Response:**
```json
{"saved": ["/home/johan/documents/inbox/invoice.pdf"], "errors": []}
```

**Ingest all attachments:** omit the `attachments` array or pass `{}`.

### When to Ingest
**Trigger ingest for anything interesting/worth keeping:**
- Invoices, receipts, bills, statements
- Contracts, agreements, legal documents
- Medical records, insurance docs
- Tax forms (W-2, 1099, etc.)
- Any document worth keeping/finding later
- Use judgment — if it looks useful, ingest it

**Skip these:**
- Marketing fluff, promo images
- Logos, signatures (image-only attachments)
- Spam attachments
- Duplicate documents already ingested

### Supported Formats
- **Vision (K2.5):** .pdf, .png, .jpg, .jpeg, .gif, .webp, .tiff, .bmp, .doc, .docx, .odt, .rtf, .xls, .xlsx, .ppt, .pptx
- **Text (K2):** .txt, .md, .csv, .json, .xml, .yaml, .log

---

## James Tasks (assign to myself)

These emails are ACTIONABLE for me — create a dashboard task (owner: james), don't just archive:

- **Google Search Console** (sc-noreply@google.com) — inou.com indexing issues, crawl errors, etc.
- **inou.com alerts** — uptime, errors, anything about the platform
- **Infrastructure alerts** — Uptime Kuma, server notifications, SSL expiry
- **Security alerts** — breach notifications, vulnerability disclosures for our stack

**Workflow:**
1. Read the full email
2. Create task: `POST http://localhost:9200/api/tasks` with `owner: "james"`, appropriate domain
3. THEN archive the email

---

## Sophia Triggers

Anything matching these → Sophia's recovery folder (or ASK if unclear):
- "brain", "neuro", "therapy", "activator"
- Medical devices, equipment, serial numbers
- Pediatric suppliers (All About Pediatrics, Tri-Med, etc.)
- Insurance claims mentioning Sophia
- Any person name "S. Jongsma" or "Sophia"
- Therapy appointments, medical follow-ups

## Conversation Detection

- "Re:" from a person = active conversation, READ IT
- Thread replies are not spam
- Check context before deleting

## Action Required Detection

- Credits/refunds → check expiry, action needed?
- Payment reminders → notify Johan
- "ACTION REQUIRED" → read and assess
- Medical advice → flag for attention, don't just file

## Phishing / Scam Detection

**Phishing ≠ Spam.** Spam is junk. Phishing is fraud. Different handling.

### Red Flags (read body carefully if ANY present):
- Unexpected "payment processed" or "transaction" language
- Phone numbers to call "if you didn't authorize"
- Urgent action required + money involved
- Generic sender names ("Your Teacher", "Support Team")
- Legitimate service used as delivery mechanism (Canva class, Google Doc share, etc.)
- Message-ID from unexpected domain (e.g., amazonses.com for a "Canva" email)
- Mismatched context (class invite containing payment info)

### Phishing Workflow:
1. **PRESERVE** — do NOT delete. Move to a folder or keep in inbox.
2. **FLAG** — mark for Johan's attention
3. **ALERT** — ping Johan: "Phishing attempt detected, preserved for review"
4. **LOG** — dashboard entry with `action: "flagged"`, `reason: "Phishing - [brief description]"`
5. **DO NOT AUTO-REPORT** — Never send abuse reports to Canva/Google/PayPal/etc. without Johan's explicit approval. We don't want to become spam ourselves, and false positives happen.

**Johan decides** if an abuse report is warranted. I preserve evidence, he takes action.

### Why This Matters:
- Phishing evolves — today's "class invite" scam is tomorrow's "shared document" scam
- Evidence has value for reporting (if Johan chooses to)
- Auto-reporting could flag legitimate emails, annoy abuse teams, or get our accounts flagged

---

## Delete Behavior

**NEVER hard-delete. Always move to Trash.**

Before moving to Trash:
1. Read full content
2. Summarize what it contains
3. Confirm no action is needed
4. Confirm it's NOT phishing (phishing = preserve, not trash)

## Processed Email Routing

### → Trash (delete)
- Marketing/promotional emails
- Spam
- Phishing attempts
- Newsletters not worth keeping
- Automated notifications with no value
- Test emails

**Rule:** If Johan would never want to find this again → Trash

### → Shopping (mark read, move)
- Order confirmations ONLY

**Rule:** Actual order/purchase confirmation → mark read, move to `Folders/Shopping`

### → Trash (after processing)
- Shipping notifications
- Delivery updates
- "Out for delivery" / "Delivered" notices

**Workflow for shipping/delivery emails:**
1. Read the full message
2. **ALWAYS use upsert** (never POST): `PUT http://localhost:9200/api/deliveries/upsert` — matches by tracking_number or description+retailer, updates if found, creates if not. Include tracking_number when available.
3. THEN move to Trash

This keeps the delivery schedule current without cluttering Shopping folder.

### → Archive (keep but out of inbox)
- Processed bills after payment
- Travel confirmations (past trips)
- Payment receipts from subscriptions (reference value)
- Security alerts (password changes, new logins)

**Rule:** Archive is for things worth FINDING AGAIN. If Johan would never search for it → Trash, not Archive.

### → Trash (common false-archive candidates)
- **Amazon:** Everything except order confirmations and outliers (product recalls, credits). Promos, recommendations, "items you viewed", shipping updates (after updating deliveries) → all trash.
- **Retailers:** Marketing, sales, "new arrivals" → trash
- **Account notifications** with no future value → trash
- **Generic "your statement is ready"** → trash (he can check the app)

### → Keep in Inbox (flag for Johan)
- Action required
- Bills/renewals pending payment
- Personal correspondence awaiting reply
- Anything Sophia-related
- Medical/insurance matters

**Important:** After flagging, mark as seen so it doesn't retrigger:
```bash
curl -X POST "http://localhost:8025/messages/{id}/seen"
```
This removes it from `/messages/new` without archiving/deleting.

## Specific Sender Rules

These override general routing:

- **Kaseya Marketing:** Read fully -> Summarize (rundown) -> Post to Dashboard News -> **Trash**.
- **Lansweeper:** (Johan is ex-CTO) Read fully -> Summarize what's going on -> Post to Dashboard News -> **Trash**.
- **inou Verification Codes:** (noreply@inou.com) -> **Trash** immediately (Johan uses backdoors).
- **Immich:** (GitHub/Releases) Read fully -> **Trigger update on server 192.168.1.253** -> Post to Dashboard News -> **Trash**.
- **Lingerie & Beach Wear (e.g., Pain de Sucre, Fleur du Mal):** Use your judgment. If the email introduces a **new collection, series, or seasonal release**, **Keep in Inbox**. If it is just general sales/marketing/shipping alerts, **Trash**.
- **Domain Purchase Inquiries (e.g., Jacob):** -> Deny (Reply "not for sale") -> **Archive**.
- **DigiKey** (e.digikey.com): Marketing/newsletters → **Trash** immediately.
- **Verizon Wireless** (ecrmemail.verizonwireless.com): Purchase/order emails → **Keep in Inbox**. Even if they look like "abandoned cart" marketing, Johan may have an active purchase in progress. Only trash obvious generic promos (plan upgrades, add-a-line offers).

## Mistakes Made

### 2026-02-01
- Hard-deleted GenerX thread (permanently lost)
- Deleted Amazon promo credit without checking if action needed
- Almost deleted MBL Brain Activator emails (Sophia's therapy device repair)
- Triaged MosaicDx by subject without reading their medical advice

### 2026-02-02
- **Canva phishing email:** Deleted as "educational marketing spam" without reading body. Missed scam payload ($769.68 fake payment + scam phone number). Should have: read full content, recognized phishing red flags, preserved + flagged for Johan. **Violated my own rule: "ALWAYS read the FULL message content before triaging."**

Learn from these. Don't repeat.
