cschmatzler/nixos-config
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

harden inbox triage run semantics

Browse Source
This commit is contained in:
Christoph Schmatzler
2026-03-01 20:04:45 +00:00
parent cfe0cc2fb7
commit dc234bbfd0
1 changed files with 35 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

63
profiles/opencode/command/inbox-triage.md
View File

@@ -6,9 +6,10 @@ Process email with strict manual triage using Himalaya only.
Hard requirements: Hard requirements:
- Use `himalaya` for every mailbox interaction (folders, listing, reading, moving, deleting, attachments). - Use `himalaya` for every mailbox interaction (folders, listing, reading, moving, deleting, attachments).
- Process exactly one message at a time. Never run bulk actions on multiple IDs. - Process exactly one message ID at a time. Never run bulk actions on multiple IDs.
- Do not use pattern-matching commands or searches (`grep`, `rg`, `awk`, `sed`, `himalaya envelope list` query filters, etc.). - Do not use pattern-matching commands or searches (`grep`, `rg`, `awk`, `sed`, `himalaya envelope list` query filters, etc.).
- Always inspect current folders first, then triage. - Always inspect current folders first, then triage.
- Treat this as a single deterministic run over a snapshot of message IDs discovered during this run.
Workflow: Workflow:
1. Run `himalaya folder list` first and use those folders as the primary taxonomy. 1. Run `himalaya folder list` first and use those folders as the primary taxonomy.
@@ -27,41 +28,47 @@ Workflow:
4. Determine source folder: 4. Determine source folder:
- If `$ARGUMENTS` contains a folder name, use that as source. - If `$ARGUMENTS` contains a folder name, use that as source.
- Otherwise use `INBOX`. - Otherwise use `INBOX`.
5. List envelopes in explicit pages of 20 from the source folder without search filters. 5. Build a run scope safely:
- Use: `himalaya envelope list -f "<source>" -p <page> -s 20`. - List with fixed page size `20`: `himalaya envelope list -f "<source>" -p 1 -s 20`.
- Start at page `1`. - Enumerate IDs in returned order.
- Work page-by-page in ascending order. - Process each ID fully before touching the next ID.
6. For each page: - After each single-ID action, relist page `1` with `-s 20` and continue with the next unprocessed ID.
- Enumerate IDs in the returned order. - Keep an in-memory reviewed set for this run to avoid reprocessing IDs already handled or intentionally left untouched.
- Process each single envelope ID fully before touching the next ID. - Stop when a fresh page-1 listing contains no unprocessed IDs.
- Do not request the next page until every ID from the current page is finished. 6. For each single envelope ID, do all checks before any move/delete:
7. For each single envelope ID, do all checks before any move/delete: - Read the message: `himalaya message read -f "<source>" <id>`.
- Read the message (`himalaya message read -f "<source>" <id>`). - If needed for classification, inspect attachments with `himalaya attachment download -f "<source>" <id>`.
- If needed for classification, inspect attachments with Himalaya (`himalaya attachment download -f "<source>" <id>`), then reason from the attachment names/content. - If attachments are downloaded, inspect them and remove temporary local files after use.
8. Classify and act for that one ID: 7. Classification precedence (higher rule wins on conflict):
- Ephemeral communication from automated/system senders (alerts, bot/status updates, auth/login codes, OTP/2FA verification emails, password-reset codes, no archival value): delete it. - Human communication from an actual person: do not delete, do not move, leave untouched.
- Communication from actual people: do not delete, do not move, and do not auto-triage; leave untouched in the current folder (typically `INBOX`). - Clearly ephemeral automated/system message (alerts, bot/status updates, OTP/2FA, password reset codes, login codes) with no archival value: move to `Deleted Messages`.
- Orders/invoices: move only real order/invoice/business records to `Orders and Invoices`. - Payment transaction correspondence (payment confirmations/reminders, provider messages such as Klarna/PayPal/Stripe): move to `Payments`.
- Payments: move payment confirmations, payment reminders, and payment-provider messages (e.g. Klarna, PayPal, Stripe) to `Payments`. Do not confuse with order confirmations or invoices — `Payments` is specifically for payment-transaction correspondence. - Orders/invoices/business records: move to `Orders and Invoices`.
- Shipping-only notifications: do not move to `Orders and Invoices` unless there is actual invoice/receipt/order-document value (for example, invoice attached or embedded billing document). - Shipping-only notifications: do not move to `Orders and Invoices` unless there is actual invoice/receipt/order-document value.
- Marketing/newsletters: move to `Newsletters and Marketing`. - Marketing/newsletters: move to `Newsletters and Marketing`.
- Delivery/submission confirmations (`Einlieferungen`) when appropriate. - Delivery/submission confirmations: move to `Einlieferungen` when appropriate.
- Long-term but uncategorized messages: create a new folder and move there. - Long-term but uncategorized messages: create a concise new folder and move there.
9. Folder creation rule: 8. Folder creation rule:
- If none of the existing folders fit but the message should be kept, create a concise new folder with `himalaya folder add "<new-folder>"`, then move the message there. - Create a new folder only if no existing folder fits and the message should be kept.
10. Continue until all messages in source folder are processed: - Naming constraints: concise topic name, avoid duplicates, and avoid broad catch-all names.
- After a page is completely processed, request the next page (`-p <page+1>`) with the same page size (`-s 20`). - Command: `himalaya folder add "<new-folder>"`.
- Stop only when there are no more envelopes to process.
Execution rules: Execution rules:
- Never perform bulk operations. One message ID per `read`, `move`, `delete`, and attachment command. - Never perform bulk operations. One message ID per `read`, `move`, `delete`, and attachment command.
- Never query page `N+1` before fully processing page `N`.
- Always use page size 20 for envelope listing (`-s 20`). - Always use page size 20 for envelope listing (`-s 20`).
- Never skip reading message content before deciding. - Never skip reading message content before deciding.
- Keep decisions conservative: delete only clearly ephemeral automated/system messages. - Keep decisions conservative: only route clearly ephemeral automated/system messages to `Deleted Messages`.
- Never move or delete human communications via automation. - Never move or delete human communications via automation.
- Never route new messages to `Archive`; treat it as deprecated legacy-only. - Never route new messages to `Archive`; treat it as deprecated legacy-only.
- Report a compact action log at the end: per-folder counts, created folders, and a short rationale for non-obvious classifications. - 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:
- source folder,
- total reviewed IDs,
- counts by action (untouched/moved-to-folder/deleted),
- per-destination-folder counts,
- created folders,
- short rationale for non-obvious classifications.
<user-request> <user-request>
$ARGUMENTS $ARGUMENTS