Hinata Wiki

Appearance

No Auto Vaultwarden Writes ​

Agents NEVER run bw create, bw edit, or any other Vaultwarden mutation. Every Vaultwarden write is Michael-manual through the UI. Reads (bw get, bw list, metadata queries, value-to-0600-file pipelines) remain permitted.

Cross-link: bitwarden-canonical-credential-store (Vaultwarden as canonical store), no-credential-print (never print secrets in chat), bw-create-stdout-echo (its stdout law still governs read pipelines; this law supersedes its write half).

The Rule ​

Pipelines requesting a new key may:

  • Generate the value system-side (e.g. a random token, an OAuth refresh token, an HMAC secret)
  • Install it system-side as a 0600 env file on Z2 (or wherever the consumer reads)
  • Hand Michael: the item name, the field list, the values via secure channel (never chat)

Pipelines may NOT:

  • Run bw create item ...
  • Run bw edit item ... — including renames and notes updates
  • Create items "behind the scenes" because a precedent exists (the original violation)

Michael-ordered renames/updates: give him the click-path in the UI. Do not execute on his behalf.

Why this law exists ​

Michael ruling 2026-06-12 (verbatim): "anytime hinata wants to write new key to vaultwarden, i have to manually do it. no longer allow auto write."

During the 2026-06-12 collector-allmight build, Jimmy auto-created item allmight_webhook following the sanji_webhook precedent. Michael found an item he didn't create in his credential store ("i did not make an allmight_webhook / why does it exist") — auto-writes break his trust in and inventory of Vaultwarden, regardless of how safely the values were handled. Trust in the credential store is the foundation of the entire security model; the rule exists to keep that trust intact.

How agents apply it ​

When a pipeline needs a new credential surface:

  1. Generate the value system-side (ssh into Z2, run the generator)
  2. Install it as a 0600 env file at the consumer's expected path
  3. Surface Michael a one-message summary:
    • Item name (his choice or your suggestion)
    • Fields to add (name, login, password, custom fields)
    • Why this item is needed
  4. Wait for him to add it. Do not proceed past step 4 without confirmation.
  5. If the consumer needs to read the value at runtime, the read pipeline (per bw-create-stdout-echo) governs — pipe to file, never print.

If a Vaultwarden item must be renamed: surface the click-path, never bw edit.

Graduation note ​

Lifted from harness memory feedback_no-auto-vaultwarden-writes on 2026-06-14 via the memory-graduation scout (vault citations: 13; commander-memory spread: 3 — Bulma, Itachi, Jimmy-Neutron). Strongest doctrine signal in the first hardened run. The original memory file is deleted; the index pointer in MEMORY.md directs here.