|
|
|
|
@@ -15,12 +15,13 @@ Workflow:
|
|
|
|
|
1. Run `himalaya folder list` first and use those folders as the primary taxonomy.
|
|
|
|
|
2. Use this existing folder set as defaults when it fits:
|
|
|
|
|
- `INBOX`
|
|
|
|
|
- `Orders and Invoices`
|
|
|
|
|
- `Payments`
|
|
|
|
|
- `Outgoing Shipments`
|
|
|
|
|
- `Newsletters and Marketing`
|
|
|
|
|
- `Junk`
|
|
|
|
|
- `Deleted Messages`
|
|
|
|
|
- `Correspondence`
|
|
|
|
|
- `Orders and Invoices`
|
|
|
|
|
- `Payments`
|
|
|
|
|
- `Outgoing Shipments`
|
|
|
|
|
- `Newsletters and Marketing`
|
|
|
|
|
- `Junk`
|
|
|
|
|
- `Deleted Messages`
|
|
|
|
|
3. Determine source folder:
|
|
|
|
|
- If `$ARGUMENTS` is a single known folder name (matches a folder from step 1), use that as source.
|
|
|
|
|
- Otherwise use `INBOX`.
|
|
|
|
|
@@ -32,23 +33,26 @@ Workflow:
|
|
|
|
|
- When all IDs on the current page are in the reviewed set, advance to the next page.
|
|
|
|
|
- Stop when a page returns fewer results than the page size (end of folder) and all its IDs are in the reviewed set.
|
|
|
|
|
5. For each single envelope ID, do all checks before any move/delete:
|
|
|
|
|
- Read the message: `himalaya message read -f "<source>" <id>`.
|
|
|
|
|
- If needed for classification, inspect attachments: `himalaya attachment download -f "<source>" <id> --dir /tmp/himalaya-triage`.
|
|
|
|
|
- If attachments are downloaded, inspect them and `rm` the downloaded files from `/tmp/himalaya-triage` after use.
|
|
|
|
|
- Move: `himalaya message move -f "<source>" "<destination>" <id>`.
|
|
|
|
|
- Delete: `himalaya message delete -f "<source>" <id>`.
|
|
|
|
|
- Check envelope flags from the JSON listing (seen/answered/flagged) before reading.
|
|
|
|
|
- Read the message: `himalaya message read -f "<source>" <id>`.
|
|
|
|
|
- If needed for classification, inspect attachments: `himalaya attachment download -f "<source>" <id> --dir /tmp/himalaya-triage`.
|
|
|
|
|
- If attachments are downloaded, inspect them and `rm` the downloaded files from `/tmp/himalaya-triage` after use.
|
|
|
|
|
- Move: `himalaya message move -f "<source>" "<destination>" <id>`.
|
|
|
|
|
- Delete: `himalaya message delete -f "<source>" <id>`.
|
|
|
|
|
6. Classification precedence (higher rule wins on conflict):
|
|
|
|
|
- Human communication — a message with freeform natural-language content written by a human, not templated or autogenerated. When in doubt whether a message is human or automated, leave it untouched.
|
|
|
|
|
- Clearly ephemeral automated/system message (alerts, bot/status updates, OTP/2FA, password reset codes, login codes) with no archival value: move to `Deleted Messages`.
|
|
|
|
|
- Payment transaction correspondence (actual charge/payment confirmations, receipts, failed-payment notices, provider payment events such as Klarna/PayPal/Stripe): move to `Payments`.
|
|
|
|
|
- Subscription renewal notifications (auto-renew reminders, "will renew soon", price-change notices without a concrete transaction) are operational alerts, not payment records: move to `Deleted Messages`.
|
|
|
|
|
- Installment plan activation notifications (e.g. Barclays "Ihr Ratenkauf wurde aktiviert") are operational confirmations, not payment records: move to `Deleted Messages`.
|
|
|
|
|
- "Kontoauszug verfügbar/ist online" notifications are availability alerts, not payment records: move to `Deleted Messages`.
|
|
|
|
|
- Orders/invoices/business records: move to `Orders and Invoices`.
|
|
|
|
|
- Shipping/tracking notifications (dispatch confirmations, carrier updates, delivery ETAs) without invoice or order-document value: move to `Deleted Messages`.
|
|
|
|
|
- Marketing/newsletters: move to `Newsletters and Marketing`.
|
|
|
|
|
- Delivery/submission confirmations for items you shipped outbound: move to `Outgoing Shipments`.
|
|
|
|
|
- Long-term but uncategorized messages: create a concise new folder and move there.
|
|
|
|
|
- **Actionable and unhandled** — if the message needs a reply, requires manual payment, needs a confirmation, or demands any human action, AND has NOT been replied to (no `answered` flag), leave it in the source folder untouched. This is the highest-priority rule: anything that still needs attention stays in `INBOX`.
|
|
|
|
|
- Human correspondence already handled — freeform natural-language messages written by a human that have been replied to (`answered` flag set): move to `Correspondence`.
|
|
|
|
|
- Human communication not yet replied to but not clearly actionable — when in doubt whether a human message requires action, leave it untouched.
|
|
|
|
|
- Clearly ephemeral automated/system message (alerts, bot/status updates, OTP/2FA, password reset codes, login codes) with no archival value: move to `Deleted Messages`.
|
|
|
|
|
- Automatic payment transaction notifications (charge/payment confirmations, receipts, failed-payment notices, provider payment events such as Klarna/PayPal/Stripe) that are purely informational and require no action: move to `Payments`.
|
|
|
|
|
- Subscription renewal notifications (auto-renew reminders, "will renew soon", price-change notices without a concrete transaction) are operational alerts, not payment records: move to `Deleted Messages`.
|
|
|
|
|
- Installment plan activation notifications (e.g. Barclays "Ihr Ratenkauf wurde aktiviert") are operational confirmations, not payment records: move to `Deleted Messages`.
|
|
|
|
|
- "Kontoauszug verfügbar/ist online" notifications are availability alerts, not payment records: move to `Deleted Messages`.
|
|
|
|
|
- Orders/invoices/business records: move to `Orders and Invoices`.
|
|
|
|
|
- Shipping/tracking notifications (dispatch confirmations, carrier updates, delivery ETAs) without invoice or order-document value: move to `Deleted Messages`.
|
|
|
|
|
- Marketing/newsletters: move to `Newsletters and Marketing`.
|
|
|
|
|
- Delivery/submission confirmations for items you shipped outbound: move to `Outgoing Shipments`.
|
|
|
|
|
- Long-term but uncategorized messages: create a concise new folder and move there.
|
|
|
|
|
7. Folder creation rule:
|
|
|
|
|
- Create a new folder only if no existing folder fits and the message should be kept.
|
|
|
|
|
- Naming constraints: concise topic name, avoid duplicates, and avoid broad catch-all names.
|
|
|
|
|
@@ -59,8 +63,9 @@ Execution rules:
|
|
|
|
|
- Always use page size 20 for envelope listing (`-s 20`).
|
|
|
|
|
- If any single-ID command fails, log the error and continue with the next unreviewed ID.
|
|
|
|
|
- Never skip reading message content before deciding.
|
|
|
|
|
- Keep decisions conservative: only route clearly ephemeral automated/system messages to `Deleted Messages`.
|
|
|
|
|
- Never move or delete human communications via automation.
|
|
|
|
|
- Keep decisions conservative: when in doubt about whether something needs action, leave it in `INBOX`.
|
|
|
|
|
- Never move or delete unhandled actionable messages.
|
|
|
|
|
- Never move human communications that haven't been replied to, unless clearly non-actionable.
|
|
|
|
|
- Define "processed" as "reviewed once in this run" (including intentionally untouched human messages).
|
|
|
|
|
- Include only messages observed during this run's listings; if new mail arrives mid-run, leave it for the next run.
|
|
|
|
|
- Report a compact action log at the end with:
|
|
|
|
|
|
