---
name: feedback-vault-every-credential
description: ANY credential surfaced in a session must be vaulted via the vault skill AND thoroughly documented — immediately
metadata:
  type: feedback
---

When ANY credential appears in a session — the user pastes one, you create/rotate one, or you
discover one in a log/config — **immediately store it in the SOPS vault via the `vault` skill
and document it thoroughly** (what it is, what it's for, how it's used: auth method, endpoint,
gotchas). This is a standing job requirement, not a per-task ask — it is literally why the vault
exists.

**Why:** Mike (2026-06-12) was "highly irritated" after ~an hour was wasted because the IX WHM
access method had been lost/forgotten and I fell back to a password method that no longer works.
The original rule ("recognize any credential in-session, vault it, document what it's for and how
it's used") had drifted out of the always-loaded instructions.

**How to apply:**
- Use the **`vault` skill** (`vault-helper.sh new`/`set`, `vault.sh get`/`get-field`) — the
  canonical path. Do NOT improvise raw `sops`/`vault.sh` with hand-built paths. (Exception: the
  helper only writes under `credentials:`; a top-level metadata `notes` edit still needs `sops
  --set` — but the secret itself always goes through the skill.)
- Document in the entry's `notes`: purpose + exact usage (e.g. header vs basic-auth, endpoint,
  "force curl -4", what does NOT work and why). Future me reads this instead of re-deriving.
- Finish the job: store -> `verify` encrypted -> publish (sync/commit). Never paste the secret
  into chat/commit/coord.
- Now reinforced in CORE `.claude/CLAUDE.md` "Key rules". See [[ix-whm-dns-api-access]] for the
  concrete case that triggered this.