Context
Surfaced during the design re-read of PR #304. The MSGVAULT_ENABLE_REMOTE_DELETE=1 env-var gate is the right shape for v1 — staging/listing/inspecting work without it, only the destructive Gmail-API call requires it. What's missing is the operational story for removing the gate.
The gap
The README and spec (docs/accounts-identities-collections-dedup/spec.md) describe the gate as "intended to be removed once the read side has had a release in the wild." That commitment is vibes-based:
- No specific version target ("removed in v0.X.Y")
- No observability requirement that proves the staging side is sound
- No long-term path for users who want it on permanently
The env-var-only path is fine for "I want to test deletion this one time" but bad for the documented serve-on-a-NAS deployment, where:
- Users would need to re-export the variable on every shell that talks to the daemon.
- Headless / scheduled deployments need the variable in a service file or unit env, which is less discoverable than a config-file setting.
- There's no way to make the gate a permanent decision via the same
~/.msgvault/config.toml users already manage.
Proposed approach
Two complementary improvements, neither of which has to ship together:
- Config-file alternative. Add
[deletion] remote_enabled = true (or similar) so headless deployments can set the gate once. Env var stays as the override for one-off invocations. Document the precedence order.
- Explicit removal commitment. Pick a version target ("the env-var gate is removed in
v0.X.Y; configure permanently with [deletion] remote_enabled after that version") and document it in the spec. Add a deprecation warning when the env var is set, once a config-file alternative exists.
Lower priority: a tiny delete-staged --check-gate subcommand that prints "remote delete is/is not enabled and why" so users can debug their config state without trying a destructive call.
Context
Surfaced during the design re-read of PR #304. The
MSGVAULT_ENABLE_REMOTE_DELETE=1env-var gate is the right shape for v1 — staging/listing/inspecting work without it, only the destructive Gmail-API call requires it. What's missing is the operational story for removing the gate.The gap
The README and spec (
docs/accounts-identities-collections-dedup/spec.md) describe the gate as "intended to be removed once the read side has had a release in the wild." That commitment is vibes-based:The env-var-only path is fine for "I want to test deletion this one time" but bad for the documented
serve-on-a-NAS deployment, where:~/.msgvault/config.tomlusers already manage.Proposed approach
Two complementary improvements, neither of which has to ship together:
[deletion] remote_enabled = true(or similar) so headless deployments can set the gate once. Env var stays as the override for one-off invocations. Document the precedence order.v0.X.Y; configure permanently with[deletion] remote_enabledafter that version") and document it in the spec. Add a deprecation warning when the env var is set, once a config-file alternative exists.Lower priority: a tiny
delete-staged --check-gatesubcommand that prints "remote delete is/is not enabled and why" so users can debug their config state without trying a destructive call.