Trait VarMutator 

pub trait VarMutator: Send + Sync {
    // Required methods
    fn delete(&self, id: VarId) -> Result<(), ProviderError>;
    fn create(&self, draft: VarDraft) -> Result<VarId, ProviderError>;
    fn update_value(
        &self,
        id: VarId,
        value: SecretString,
    ) -> Result<(), ProviderError>;
    fn link_to_project(
        &self,
        var_id: VarId,
        var_name: String,
        project_path: PathBuf,
        profile: String,
        materialize: bool,
    ) -> Result<(), ProviderError>;
    fn run_in_project(
        &self,
        project_path: PathBuf,
        profile: String,
        program: String,
        args: Vec<String>,
    ) -> Result<Option<i32>, ProviderError>;
}

Write-side counterpart to VarProvider.

The TUI invokes VarMutator methods on user-confirmed actions (delete in phase 2b2; create / update / link in phase 2c). The trait is split from VarProvider so adapters that only support reading (e.g. a remote read-only view) need not implement writes, though crate::run_tui requires both for now.

Implementations must be safe to share across threads.

Required Methods

fn delete(&self, id: VarId) -> Result<(), ProviderError>

Delete the variable with the given id.

Performance contract

Implementations must return promptly — target ≤ 100 ms, never more than ≈ 1 s. The TUI calls delete synchronously inside the event loop: a slow implementation will freeze the UI and prevent Ctrl-C from being handled until the call returns. Do not perform network I/O or block on user-facing prompts (OS keyring access counts — wrap it with a timeout). Phase 3 will move mutator calls onto a worker thread; until then, treat synchronous responsiveness as part of the API contract.

Idempotency

Implementations should make the call idempotent if at all possible: re-deleting an already-absent variable should not fail. The TUI refreshes its row buffer after every successful delete, so a non-idempotent backend will surface spurious errors when the user clicks delete twice on a stale view.

Errors

Returns ProviderError if the backend refused or could not perform the delete. The TUI surfaces the message as a sticky error toast and the user can retry from the dashboard.

fn create(&self, draft: VarDraft) -> Result<VarId, ProviderError>

Create a new variable from a user-supplied draft, returning its assigned id. Same performance contract as Self::delete.

Errors

Returns ProviderError on validation failure (invalid name, duplicate, empty value) or storage failure.

fn update_value( &self, id: VarId, value: SecretString, ) -> Result<(), ProviderError>

Replace an existing variable’s value. Same performance contract as Self::delete.

Errors

Returns ProviderError on validation failure or storage failure.

fn link_to_project( &self, var_id: VarId, var_name: String, project_path: PathBuf, profile: String, materialize: bool, ) -> Result<(), ProviderError>

Link a variable to a project’s manifest and (optionally) materialise the project’s .env file in one step.

Performs the equivalent of evault link NAME --project PATH followed by an optional evault gen --project PATH:

1. Resolves (or creates) the project record for project_path.
2. Records the link in the registry’s link table.
3. Reads or creates <project_path>/evault.toml and adds a binding pointing at the variable.
4. If materialize is true, resolves every binding of the given profile and writes <project_path>/.env (atomically, with the .gitignore entry).

Errors

Returns ProviderError on missing variable, FS failure, manifest serialization failure, or registry/secret-store failure.

fn run_in_project( &self, project_path: PathBuf, profile: String, program: String, args: Vec<String>, ) -> Result<Option<i32>, ProviderError>

Spawn a child process with the project’s resolved environment overlay injected — equivalent of evault run --project PATH [--profile P] -- CMD [ARGS...] triggered from the TUI.

The implementation loads <project_path>/evault.toml, resolves every binding for profile (secrets via the secret store, inline literals straight from the manifest), and spawns program with args inheriting the parent’s stdio so the user interacts with the child directly.

Terminal lifecycle is the caller’s responsibility. The TUI runtime restores the terminal before invoking this method and re-enters raw mode + alternate screen after it returns, so the implementation may safely block on the child without corrupting the parent’s screen.

Returns the child’s exit code (None if killed by a signal).

Errors

Returns ProviderError on missing manifest, value resolution failure, invalid command, or spawn / I/O failure.

Implementors