Remove scan_index, use envelope_id (IMAP UID) as single identifier

scan_index created confusion for the OpenClaw agent which would
sometimes reference emails by scan_index and sometimes by envelope_id.
Since himalaya's envelope ID is an IMAP UID (stable, never recycled),
it works as the sole identifier for review commands.
This commit is contained in:
Yanxin Lu
2026-03-07 22:01:02 -08:00
parent 2c00649488
commit 3c54098b1d
3 changed files with 37 additions and 53 deletions

View File

@@ -31,23 +31,25 @@ The system separates **classification** (what the LLM does) from **confidence**
1. **Cron runs `scan`.** For each email, the LLM suggests an action and assigns tags from a fixed taxonomy. Since there's no history yet, `compute_confidence` returns 50% (below the 85% threshold), so everything gets queued.
2. **You run `review list`.** It prints what's pending. Item numbers are stable within a scan cycle — they don't shift when earlier items are resolved:
2. **You run `review list`.** It prints what's pending, identified by envelope ID (himalaya's IMAP UID):
```
1. [msg_f1d43ea3] Subject: New jobs matching your profile
[42] msg_f1d43ea3
Subject: New jobs matching your profile
From: LinkedIn
Tags: [promotion, social, newsletter]
Suggested: delete (50%)
2. [msg_60c56a87] Subject: Your order shipped
[43] msg_60c56a87
Subject: Your order shipped
From: Amazon
Tags: [shipping, confirmation, receipt]
Suggested: archive (50%)
```
3. **You act on them.** Either individually or in bulk. Numbers stay stable — after deleting item 1, item 2 is still 2:
3. **You act on them.** Either individually or in bulk, using the envelope ID:
```bash
./email-processor.sh review 1 delete # agree with suggestion
./email-processor.sh review 2 archive # still #2, not renumbered
./email-processor.sh review accept # accept all suggestions at once
./email-processor.sh review 42 delete # agree with suggestion
./email-processor.sh review 43 archive # archive by envelope ID
./email-processor.sh review accept # accept all suggestions at once
```
Each command executes via himalaya and appends to `decision_history.json` with tags.
@@ -88,11 +90,11 @@ chmod +x email-processor.sh
# --- Review ---
./email-processor.sh review list # show pending queue
./email-processor.sh review 1 delete # delete item #1
./email-processor.sh review 3 archive # #3 is still #3 even after #1 was deleted
./email-processor.sh review msg_f1d43ea3 archive # archive by ID
./email-processor.sh review all delete # delete all pending
./email-processor.sh review accept # accept all suggestions
./email-processor.sh review 42 delete # delete envelope 42
./email-processor.sh review 43 archive # archive envelope 43
./email-processor.sh review msg_f1d43ea3 archive # archive by msg_id
./email-processor.sh review all delete # delete all pending
./email-processor.sh review accept # accept all suggestions
# --- Other ---
./email-processor.sh stats # show decision history
@@ -238,7 +240,7 @@ ollama list # should show kamekichi128/qwen3-4b-instruct-2507:latest
./email-processor.sh review list
# 6. Act on a queued email to seed decision history
./email-processor.sh review 1 delete
./email-processor.sh review 42 delete
# 7. Check that the decision was recorded
./email-processor.sh stats
@@ -304,9 +306,9 @@ Tags are defined in `classifier.py` as `TAG_TAXONOMY` — a manually curated lis
The `keep` action is a deliberate no-op — it leaves the email unread in the inbox, meaning it needs human attention. This is distinct from `mark_read`, which dismisses low-priority emails without moving them.
### Stable item numbers during review
### Envelope IDs
Each pending item gets a `scan_index` assigned sequentially during `scan`. These numbers are stable within a scan cycle — resolving item 1 doesn't renumber item 2 to 1. This matters when an agent (like OpenClaw) issues multiple `review <n> <action>` commands in sequence: without stable indices, the queue renumbers after each action, causing later commands to target the wrong emails. Indices reset to 1 on each new `scan` (done items from the previous cycle are cleared at scan start).
Emails are identified by their envelope ID, which is himalaya's IMAP UID — a stable, unique identifier assigned by the mail server. UIDs don't shift when other messages are deleted or moved, so the same envelope ID always refers to the same email. Review commands use envelope IDs directly (e.g., `review 93 delete`). The `msg_id` hash (e.g., `msg_f1d43ea3`) is an internal key for the pending queue and can also be used as a selector.
### Fail-safe classification