Why start here?
Keystore makes sensitive access traceable instead of letting hidden secret logic grow somewhere in the stack.
Identity / Keys
The controlled path to sensitive access
The governed secrets and access layer.
Keystore makes sensitive access traceable instead of letting hidden secret logic grow somewhere in the stack.
jhf-keystore is a local-first helper for controlled Vaultwarden- or Bitwarden-backed reads. It is a consumer, verifier, and packaging/documentation boundary. It is not a remote secret service, not a policy engine, and not a second Fabric truth.
The repo is designed so that operators, OpenClaw, Fabric, deployment tooling, and Wiki.js can all consume the same checked-in description of what exists today.
Status Available now README sync 29 Apr 2026
When do I need this?
Start here when you want to understand how the system permits sensitive access without losing control.
What role it plays here
The governed secrets and access layer.
Safe execution needs governed secret access. Without Keystore, security quickly becomes implicit and hard to verify.
What the module actually does
It makes secret usage traceable, bounds access cleanly, and prevents runtime modules from growing their own hidden credential logic.
At the core
resolve vw://item/... references through a local authenticated bw workflow
expose bounded probe and doctor checks for runtime diagnosis
generate stable OpenClaw source: exec snippets
produce versioned package artifacts and Fabric-readable repo metadata
validate read-only access-model and contract consumption without re-owning upstream truth
provide a canonical cross-surface SSO v4 acceptance suite for admitted surfaces
What role it plays in the stack
This repository consumes Fabric-owned truth and must not create a second local truth.
Fabric-owned surfaces consumed here:
GET /api/v1/contracts/matrix GET /api/v1/contracts/docs-standard GET /api/v1/contracts/wiki-governance GET /api/v1/combinations/profiles
Upstream identity truth consumed here:
jhf-heddle/config/identity/claim-vocabulary.v2.yaml
What this repo does locally:
declares adoption and compatibility validates contract drift materializes documentation and repo-readable views
What this repo must not do locally:
redefine docs-standard redefine wiki-governance redefine identity semantics invent local projection or entitlement truth
What this looks like in practice
Safe execution needs governed secret access. Without Keystore, security quickly becomes implicit and hard to verify.
A signal comes in.
The system assigns the right role and path.
Execution happens through controlled handoffs.
Result and evidence return together.
How it fits into the system
Keystore does not stand alone. It connects to neighboring modules so a single capability becomes dependable follow-through.
Important boundary
Keystore stays bounded to its role as The governed secrets and access layer. It does not replace other modules; it makes its part of the system traceable, connectable, and reviewable.
What comes next
What is intentionally out of scope
live host checks still depend on external runtime prerequisites
the repo can diagnose upstream drift, but not repair host-owned state from here
secret values and long-lived sessions must stay outside checked-in files
What keeps this page honest
This explanation stays anchored to the module’s current truth, including its real boundaries, responsibilities, and contracts.
Keystore is the layer through which sensitive credentials and secret access are controlled.
It makes secret usage traceable, bounds access cleanly, and prevents runtime modules from growing their own hidden credential logic.
Safe execution needs governed secret access. Without Keystore, security quickly becomes implicit and hard to verify.
Active part of the system with clearly defined boundaries.
Source and repo truth
This page is rendered from the repo-owned projection truth and remains tied to the README, module boundaries, and status.
GitHub JaddaHelpifyr/jhf-keystoreKeystore
Safe execution needs governed secret access. Without Keystore, security quickly becomes implicit and hard to verify.