MailOps v0.2.1: Discoverability and a clearer first run

MailOps v0.2.1: Discoverability and a clearer first run

MailOps 0.2.1 makes the public project easier to find and try. It explains the
supported Proton Mail Bridge CLI workflows and optional Codex skills up front,
with release installation and an isolated synthetic demonstration.

What changed

• Populated the repository About description, documentation link, and twelve
  relevant GitHub topics.
• Reworked the README and alpha guide around search, triage, reviewed drafts,
  and audit export, with concise capability limits and direct documentation links.
• Added CI, release, and license badges, a reproducible synthetic terminal
  demonstration, and social preview artwork.
• Updated package description, documentation URL, and keywords to match shipped
  functionality; removed the unsupported Gmail keyword and monitoring classifier.

Install or upgrade

Install the wheel attached to this release in a Python 3.10+ virtual environment:

python -m pip install ./mailops-0.2.1-py3-none-any.whl

There are no new schema or provider behavior changes from 0.2.0. Users upgrading
from 0.1.x must first read the 0.2.0 migration and draft recovery notes
and back up their established MailOps home. Use a separate temporary home for demos.
The attached artifacts are published on GitHub; this release does not publish to PyPI.

Validation and limitations

Release validation covers structural/documentation checks, lint, the automated
test suite, isolated synthetic CLI workflows, built-package inspection, metadata
checks, dependency advisories, and an installed-wheel smoke test. CI runs on
Windows and Linux with Python 3.10 and 3.13; results are available in
Validate MailOps.

Proton Mail Bridge is the supported provider. Sending, deletion, bulk archive/move,
provider rule application, and Gmail runtime remain unimplemented. Reviewed draft
creation never sends mail. Local state and exports remain plaintext. Automated
tests and the showcase use synthetic data; no operational mailbox was accessed or
migrated, and live Bridge acceptance was not exercised for this patch.

See the changelog,
alpha guide,
demo, and
release checks.

MailOps v0.2.0: Safer multi-account operations and development harness

MailOps v0.2.0: Safer multi-account operations and development harness

MailOps 0.2.0 fixes account-isolation and draft-execution defects while keeping
the local-first operator loop: sync, inspect, triage, draft, review, apply, audit.
This is a minor alpha release because it changes local schema and policy behavior.

What changed

• Message identity is scoped to each account, preventing identical Message-IDs in
  different mailboxes from overwriting each other. Migration preserves stored IDs,
  content, folder links, indexes, and triggers transactionally.
• Proton sync binds cursors to UIDVALIDITY, validates returned UIDs, reads with
  BODY.PEEK[], and retains bounded retry behavior after errors and mailbox resets.
• Draft proposals freeze reviewed account, recipients, and reply context. Apply
  checks account/login identity and enforces risk floors and per-action approval.
• Durable execution claims prevent duplicate concurrent or interrupted apply
  attempts. Uncertain provider results block automatic retries and local rollback.
• New draft references verify Message-ID and UIDVALIDITY during reconciliation.
• TOML parsing, credential/traceback redaction, resource cleanup, and literal
  terminal rendering are hardened. Untrusted mail cannot use Rich markup to hide
  reviewed text; control characters display as visible escapes.
• A shared validation command checks architecture, docs, lint, tests, and synthetic
  CLI behavior. CI covers Windows/Linux with Python 3.10/3.13, builds packages,
  checks private-file exclusion and metadata, and audits resolved dependencies.
• All six MailOps Codex skills now use deliberate mailbox-home/account targeting
  and current credential, installation, review, and release guidance.

Upgrade instructions

1. Stop MailOps operations and back up the entire established MAILOPS_HOME
   before running 0.2.0. Most state-using commands initialize/migrate the database.
   Migration cannot reconstruct messages already overwritten by older versions.

2. Install the wheel attached to this GitHub release in the intended environment:

   python -m pip install ./mailops-0.2.0-py3-none-any.whl
   

3. Set MAILOPS_HOME to the existing absolute store path. Verify the account and
   inspect pending batches before any provider action. Recreate and review legacy
   proposals that lack frozen recipients.

4. Legacy UID-only draft refs now report unverified. Actions marked executing
   or uncertain need Proton Drafts/audit inspection; do not reset/retry them blindly.

5. Refresh installed skills from skills/ using the maintained installation guide.

The attached wheel and source archive are GitHub release artifacts. Do not assume
this version is available from PyPI unless separately published there.

Validation and limits

Local Windows validation passed 140 tests, structural checks, lint, isolated CLI
scenarios, packaging checks, and built-wheel smoke tests. A point-in-time audit of
57 resolved development/runtime packages found no known vulnerabilities. Remote
results are available in Validate MailOps.

No operational mailbox database was migrated during release validation. Live Bridge
login/sync/draft acceptance remains untested for this release; provider tests use
fakes. Thread grouping and triage remain heuristic; bounded sync is not a complete
mirror of existing flags/deletions. State and exports are plaintext on disk.

Sending, deletion, bulk archive/move, provider rule application, and Gmail runtime
remain unimplemented. Creating a reviewed Proton draft never sends it.

See the changelog,
alpha guide,
release checks,
and quality report.

MailOps v0.1.0: Public Alpha

MailOps v0.1.0: Public Alpha

MailOps v0.1.0 is the first public alpha of a local-first, review-first inbox operations harness for serious multi-account email workflows.

This release proves the Proton operator loop:

sync -> inspect -> triage -> draft -> review -> apply -> audit

What Works

• Local SQLite runtime state, diagnostics, and markdown audit export
• Proton Bridge discovery on Windows, Linux desktop, and supported WSL-to-Windows topologies
• Saved non-secret Proton profiles
• Proton folder listing with role and capability detection
• Bounded Proton sync into local state with cursor safety
• Search over synced local messages
• Read-only local thread and message inspection
• Thread triage and follow-up classification
• Natural-language requests compiled into explicit actions or local queries
• Local draft proposal batches
• Custom outbound draft proposal batches from explicit operator context
• Review-first Proton draft materialization through IMAP APPEND
• Provider draft syncback snapshots for executed draft refs
• Review-only Proton Sieve previews
• Local-only demo mailbox fixture for contributors without Proton Bridge
• Repo-local Codex Skills for email context, contextual drafting, draft review, Proton validation, product development, and release checks

Safety Boundaries

MailOps is not an autonomous email client. It does not silently send, delete, archive, bulk mutate, or apply provider rules.

In v0.1.0, the only provider write path is creating reviewed Proton Drafts. Gmail remains a placeholder until the Proton loop is stable in public use.

Secrets are runtime-only. Saved Proton profiles store non-secret host, port, username, account email, and canonical email metadata, but never Bridge passwords.

Install

For local development:

python -m pip install -e ".[dev]"

For a packaged install after PyPI publication:

python -m pip install mailops

Validation

The release was validated on Windows PowerShell with:

py -m pytest
py -m mailops.cli.main --help
py -m mailops.cli.main doctor
py -m mailops.cli.main status
py -m build
py -m twine check dist\*

The local-only demo path was also validated with mailops demo seed, mailops search invoice, mailops triage --since 3d, and mailops ask "show unanswered finance threads".

Known Limitations

• Gmail OAuth, sync, labels, and draft operations are placeholders.
• SMTP send is not implemented.
• Delete, bulk archive, bulk move, and provider rule application are not implemented.
• Proton draft syncback records provider-visible draft metadata but does not yet import full provider draft bodies into the normal message index.
• Triage heuristics are useful but still heuristic; they are not a substitute for operator review.
• Live provider validation assumes Proton Bridge is already installed and running.

Links

• CHANGELOG.md
• docs/public-alpha.md
• docs/release-checklist.md
• docs/release-process.md