Decision log

Do not rewrite past entries to hide a changed decision. Add a superseding entry with its rationale and links to the affected project checkpoint.

2026-08-03: Keep batch approval exact but make the sandbox workflow usable

Context: The first live sandbox pilot expired while the user copied an internal approval token. The selected mailbox is intentionally low-risk test space, but onboarding approval still must not become standing mutation authority.

Decision: Keep separate per-batch cleanup and unsubscribe approvals bound to one attested mailbox, immutable targets, action, policy, and full internal digest. Use a 60-minute default window, show a short human-readable approval code, retain the existing 100-message cleanup cap and 20-target unsubscribe apply cap, and persist exact unsubscribe plans in the private machine-local operation store so a root-runtime restart does not invalidate them.

Alternatives considered: Reusable query-level approval; automatic refresh-and-execute; retaining ten-minute plans and requiring the user to repeat internal hashes.

Tradeoffs: A longer window increases potential staleness, so execution must continue to re-attest identity and revalidate every target. Private unsubscribe plans contain personalized endpoints and therefore require access-controlled local storage and strict output redaction.

Follow-ups: Complete the isolated Roadtrippers pilot, verify receipts, and assess whether the 60-minute window remains appropriate before enabling another mailbox.

2026-08-02: Execute the remaining program as one continuous run

Context: The initial autonomous backlog deliberately stopped after one isolated audit item. Maggie subsequently requested one persistent end-to-end execution run that does not pause at routine checkpoints or tranches.

Alternatives considered: Continue one item per run; merge each tranche before beginning the next; perform the implementation directly on main.

Tradeoffs: A longer branch carries more integrated change, while eliminating repeated restart overhead and context loss. Frequent verified commits and durable evidence keep the run recoverable.

Follow-ups: Keep codex/end-to-end-gateway pushed at meaningful intervals and do not treat a checkpoint as a stopping condition.

2026-07-31: Use a three-layer hybrid architecture

Context: A single connected Gmail account is insufficient, while a forwarded hub does not preserve source-account authority.

Decision: Use the standard Gmail connector as a proof layer, an optional hub as a convenience layer, and a custom multi-account gateway as the authoritative operations layer.

Alternatives considered: Standard connector only; hub-only consolidation; direct custom gateway with no early proof.

Tradeoffs: The hybrid introduces more architecture and clear state boundaries, but it permits rapid validation without confusing convenience copies with source truth.

Follow-ups: Document observed proof-layer capabilities, decide whether to enable the hub, and build gateway identity isolation before production mutation.

2026-07-31: Make V1 structurally draft-only

Context: The primary response use case is preparing a draft for human review. Accidental or stale sends are the highest-consequence avoidable failure.

Decision: Do not expose or authorize any send, scheduled-send, or automatic-reply capability in V1. “Respond” means create or update a draft in the selected source mailbox.

Alternatives considered: Prompt-level “never send” policy; send after per-message approval; delayed send with cancellation window.

Tradeoffs: Maggie must send from Gmail, but the safety boundary is enforceable through capabilities rather than conversational compliance alone.

Follow-ups: Add tool-manifest, OAuth-scope attestation, endpoint-deny, and integration tests proving send is absent from the gateway, including indirect paths. Document that Google's minimum draft/modify scope can technically authorize sending even though the gateway must never expose or call it.

2026-07-31: Require explicit named-mailbox routing

Context: Browser sessions, connectors, hub copies, and OAuth accounts can point to different identities.

Decision: Every operation must resolve one explicit account ID or unique alias and return the verified canonical address. Missing, partial, ambiguous, expired, or mismatched identity fails closed.

Alternatives considered: A default mailbox; infer mailbox from conversation; search all mailboxes automatically.

Tradeoffs: Requests may need a brief clarification, but the system cannot silently act on the wrong account.

Follow-ups: Approve an alias registry and create identity/capability health checks.

2026-07-31: Keep the hub non-authoritative and optional

Context: Forwarding or import can make cross-account discovery easier, but it creates copies whose labels, read state, archive state, and thread identity may diverge from source accounts.

Decision: The hub may support convenience search and history, but source-account drafts and mutations must resolve through the authoritative gateway. The product remains viable if the hub is deferred.

Alternatives considered: Make the hub the operational inbox; auto-archive source messages after forwarding.

Tradeoffs: Some discovery-to-action flows require a source refresh, but state remains trustworthy.

Follow-ups: Evaluate source-attribution fidelity, duplicates, forwarding privacy, and whether the convenience gain justifies setup.

2026-07-31: Separate cleanup discovery, approval, and execution

Context: A large backlog cannot be safely mutated from a broad natural-language instruction alone, and mailbox state can change between analysis and execution.

Decision: Cleanup follows a fixed sequence: read-only inventory, classification, frozen plan, explicit approval, account and item revalidation, bounded execution, verification, and receipt.

Alternatives considered: Immediate bulk action from a live Gmail query; reusable standing approval; fully autonomous cleanup.

Tradeoffs: The workflow adds a review checkpoint and manifest storage, but prevents scope drift and makes results auditable.

Follow-ups: Set plan expiry, batch caps, mismatch stop thresholds, and production pilot criteria.

2026-07-31: Limit destructive cleanup to recoverable actions

Context: Inbox Zero does not require permanent deletion, and classification mistakes must be recoverable.

Decision: Prefer labels and archive. Allow Trash only for an explicitly approved cohort and record prior labels for rollback. Do not expose permanent delete or empty Trash/Spam.

Alternatives considered: Permanent deletion after approval; archive-only cleanup.

Tradeoffs: Trash continues to rely on provider retention and some storage remains temporarily, but operational risk is materially lower.

Follow-ups: Define Trash approval language and test restore behavior before production use.

2026-07-31: Treat unsubscribe as a separate side-effect workflow

Context: Unsubscribe contacts an external endpoint or may generate an email and cannot be rolled back like a label change.

Decision: Discover and approve unsubscribe candidates separately from inbox cleanup. Support safe standards-based HTTPS mechanisms; do not add general send capability for mailto unsubscribe or follow arbitrary message-body links.

Alternatives considered: Treat unsubscribe as part of cleanup approval; automate every visible unsubscribe link; send unsubscribe emails from the gateway.

Tradeoffs: Some senders remain manual, but unsubscribe cannot bypass the draft-only or destination-safety boundaries.

Follow-ups: Define endpoint validation, sender grouping, verification cadence, and browser/manual fallback.

2026-07-31: Keep production mailbox authority with the root agent in V1

Context: Parallel agents are useful for planning and verification, but expanding mailbox access increases credential, privacy, and conflicting-mutation risk.

Decision: Subagents may handle docs, architecture review, tests with synthetic fixtures, and sanitized read-only analysis. They do not receive production OAuth tokens, raw mailbox content, personalized unsubscribe links, or mutation tools. The root agent owns production identity checks and mutation execution.

Alternatives considered: Per-mailbox subagents with independent tokens; broad agent pool access; no subagent use.

Tradeoffs: Some production operations remain sequential, while independent review and test work can still run in parallel safely.

Follow-ups: Revisit only after a security review and proven need.

2026-07-31: Store sanitized operational evidence, not mailbox content

Context: The repo needs durable restart and audit state, but mail and OAuth data are sensitive.

Decision: Persist policy versions, opaque IDs, counts, timestamps, action state, redacted metadata, and sanitized receipts. Keep tokens in an approved secret store and message content ephemeral. Use fictional data in tests and examples.

Alternatives considered: Store full request/response logs; omit durable evidence entirely.

Tradeoffs: Some debugging requires a new authorized read, but the repository does not become a shadow mailbox.

Follow-ups: Define retention/redaction policy and add secret- and content-leak checks to CI.

Entry template

YYYY-MM-DD: Decision title

Context: What prompted the decision.

Decision: What the team chose.

Alternatives considered: Viable alternatives.

Tradeoffs: Costs, limitations, and benefits.

Follow-ups: Required implementation, validation, or documentation changes.

Dataset Preview

• Raw CSV row/table content is available in the source artifact.