Capability slices before platform expansion

A capability slice solves one real user job inside the architecture you already own. A platform expansion adds a new domain, new state model, and a longer maintenance contract.

Calendar email is a capability slice. A full calendar is a platform expansion.

Decision test

Before expanding the platform, ask:

• Can the user job be solved inside the current source of truth?
• Can the action use an existing transport?
• Can failure be explained without inventing a new mental model?
• Does the feature still work if the larger platform never arrives?

If yes, ship the slice and document the boundary.

mxr invites list --format jsonl \
  | jq -r 'select(.metadata.viewer_partstat == "needs_action") | .message_id'

The result is a useful scheduling workflow using only synced mail and local state.

Why this matters

Platform expansion can be the right call. It is just expensive. It brings ownership of new data, new sync loops, new failure modes, new security posture, new UI expectations, and new support language.

A capability slice lets the product learn from real use without pretending it has already accepted the whole domain.

In mxr

Mxr added one mail-derived table, IPC actions, CLI commands, TUI/web surfaces, and iMIP replies. It did not add a calendar account model. That is the useful boundary.

See Calendar Email Support in Mxr and Email Invites Are Mail State Before Calendar State.