1.5 KiB
1.5 KiB
name, description, type
| name | description | type |
|---|---|---|
| Point vault-access teammates at the SOPS path, don't transcribe | When relaying infra/credential info to Howard (or any teammate with vault access), hand over the SOPS vault path and let them decrypt — don't transcribe the entry's fields into the message | feedback |
When sending infra, service, or credential details to a teammate via coord messages (or any shared channel), point them at the SOPS vault path (e.g. services/azure-trusted-signing.sops.yaml) rather than transcribing the entry's fields into the message body.
Why: Mike, 2026-05-26. Howard has full vault access. I composed a GuruScan signing note to Howard that re-typed a dozen non-secret fields from the Trusted Signing vault entry; Mike's note: "He has vault access, you could just point him at sops for that." Transcribing is redundant work, bloats the message, and risks drift from the source of truth — the vault entry is canonical and self-updating.
How to apply:
- Give the vault path + the one or two anchors needed to act (e.g. "wrapper at
C:\tools\trusted-signing\sign.ps1on Pluto; full details inservices/azure-trusted-signing.sops.yaml"). - Let the teammate
sops -d/vault.sh getthe rest themselves. - Still never paste secrets into shared channels regardless — but for vault-access teammates, the default is "here's the path," not "here's the contents."
- This applies to teammates with vault access (Howard, Mike). For someone without vault access, transcribe the non-secret fields they need.