Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where using the -k flag (specifying a provider key name) inadvertently prevented the system from prompting for the actual secret value. The changes ensure that the set command consistently prompts for or accepts a secret value, even when a key_name is provided, thereby maintaining expected security and data handling practices. It also includes new tests to verify this corrected behavior.

Highlights

• Secret Value Prompting: The key_name flag (-k) no longer bypasses the secret value prompt, ensuring that users are always prompted for the secret value when using this flag.
• Configuration Logic Refinement: Removed logic that incorrectly wrote the key_name directly as the secret's configuration value, ensuring proper provider storage and encryption.
• New Test Coverage: Added new Bats tests to validate that the set -k command correctly reads secret values from both standard input and explicit command-line arguments.

Greptile Summary

This PR fixes a bug where passing -k/--key-name to fnox set caused the command to silently skip reading the secret value and instead write the key name string directly as the stored config value — bypassing encryption and remote-storage providers entirely.

Key changes:

• src/commands/set.rs: Removes key_name from the has_metadata guard and refines the metadata-only skip condition to has_metadata && self.key_name.is_none(). When -k is present (with or without other metadata flags), the command now falls through to stdin-read or interactive prompt as intended. The stale block that wrote self.key_name directly via set_value is also removed, ensuring secrets always flow through provider logic.
• test/set_key_name.bats: Adds three bats tests covering stdin piping, explicit value argument, and -k combined with -d, all verifying that plaintext never leaks into the config and that the encrypted blob is stored instead.

Confidence Score: 4/5

• Safe to merge; the logic fix is correct, no regressions introduced, and tests cover the patched paths.
• The two-line logic change is minimal and provably correct: removing key_name from has_metadata and adding && self.key_name.is_none() to the skip guard covers every combination of flags without any side-effects on existing metadata-only or plain-value flows. The buggy direct set_value(key_name) write is cleanly excised. Three new bats tests exercise stdin, explicit argument, and the combined -k+-d path. The only remaining gap (no test for the remote-storage provider path where key_name is actually consumed) was already noted in a prior review thread and is a follow-up item, not a blocker.
• No files require special attention.

Important Files Changed

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[fnox set KEY] --> B{value arg provided?}
    B -- yes --> C[secret_value = arg]
    B -- no --> D{has_metadata AND key_name is None?}
    D -- yes --> E[secret_value = None\nmetadata-only update]
    D -- no --> F{stdin piped?}
    F -- yes --> G[read from stdin]
    F -- no --> H[interactive prompt]
    G --> I[secret_value = stdin]
    H --> I

    C --> J{provider set?}
    I --> J
    J -- encryption provider --> K[encrypt value]
    J -- remote storage provider --> L[put_secret with key_name or KEY\nreturns stored key]
    J -- none/other --> M[store plaintext]
    K --> N[set_value encrypted blob]
    L --> O[set_value remote key ref]
    M --> P[set_value plaintext]
    E --> Q[update description/if_missing/default only]

_{Reviews (3): Last reviewed commit: "fix(set): don't skip value prompt when -..." | Re-trigger Greptile}