---
name: Complete vault operations end-to-end (don't hand off the commit/push)
description: When writing a new vault entry, do the full sequence (write plaintext → sops -e -i → git add/commit/push) yourself. Don't stop at "encrypted on disk, you push it."
type: feedback
---

When the user asks to vault a credential or any new vault entry, complete the entire operation in one flow. Resolve the vault root from `.claude/identity.json` `vault_path` (the path the `vault.sh` wrapper uses) — it is per-machine, never hardcoded:

1. Write the plaintext yaml to `<vault_path>/<path>.sops.yaml`
2. `sops -e -i <path>` to encrypt in place
3. Verify round-trip (`vault.sh get` shows correct decrypted output)
4. `git add` + `git commit` + `git push` from the vault repo (`<vault_path>`) via the Bash tool

**Why:** Howard explicitly flagged on 2026-04-29 that he doesn't understand why I'd hand off the trivial last-mile step. He has bash via Git for Windows but invokes from PowerShell, so a "run this bash one-liner" handoff costs him a context switch — and there's no privilege/risk reason to stop at "encrypted on disk." Pushing a clean SOPS-encrypted vault entry is routine, not destructive.

**How to apply:**
- Just push. Trust the encrypted blob, the round-trip verify, and the standard git workflow.
- If `git push` fails (auth, conflict, etc.), surface the error and ask — that's a real handoff. But "I created the file, you push it" is unnecessary friction.
- The LF→CRLF warning on Windows is benign for SOPS yaml — line endings on the yaml file don't affect SOPS integrity (the MAC covers values inside `ENC[...]` blobs and structural data). Don't surface it as a problem.
- Same principle applies to commits in the claudetools repo when I'm done with a discrete unit of work — don't park "you should /scc this" as a task; just do it (unless the user has explicitly said wait).
