Skip to main content

INTEGRATIONS

Documentation Map​

INTEGRATIONS

Internal Helpifyr Integrations​

Helpifyr access model contracts​

  • Direction: outgoing read-only
  • Type: contract-doc set
  • Surface: docs/ACCESS_MODEL.md, contracts/README.md, contracts/identity-claims.schema.json, contracts/entitlement-model.schema.json, contracts/vaultwarden-projection.schema.json, contracts/reconcile-events.schema.json, contracts/local-consumption.schema.json, contracts/revocation-rules.md, contracts/breakglass-bootstrap.md, contracts/secret-lifecycle.md, contracts/orphan-dangling-state.md, contracts/race-and-versioning.md, contracts/environment-separation.md, contracts/deprovisioning.md, contracts/approval-and-audit.md, contracts/agent-authentication.md, contracts/owner-model.md
  • Auth: none for checked-in docs and schemas
  • Stability: stable
  • Versioning: follows repository version and the current access-model contract set
  • Owner: jhf-keystore as consumer boundary, upstream policy and identity repos as truth sources

Implemented:

  • the repository now ships a canonical access-model document and explicit contract files for downstream consumers.

Planned:

  • no repo-local provisioning or identity authority
  • no remote write surface
  • no additional local truth family beyond the checked-in contracts

OpenClaw exec secret consumer​

  • Direction: incoming
  • Type: execution-contract
  • Surface: scripts/run.sh, python3 -m vaultwarden_oc_keystore, examples/openclaw/gateway.secrets.yaml
  • Auth: local bw authentication at runtime
  • Stability: stable
  • Versioning: follows repository version and the current vw://item/... secret-ref contract
  • Owner: jhf-keystore as local tool boundary, OpenClaw as consumer

Implemented:

  • OpenClaw can consume the local CLI contract through source: exec.

Planned:

  • no broader runtime surface is planned in this repository.

Helpifyr Fabric manifest intake​

  • Direction: outgoing read-only
  • Type: repo-read
  • Surface: fabric-manifest.json, docs/FABRIC_TOOL_PROFILE.md, docs/CAPABILITIES.md, docs/ACCESS_MODEL.md, contracts/README.md, scripts/export-fabric-metadata.py, scripts/fabric-selfcheck.sh
  • Auth: none for checked-in metadata; local execution only for script paths
  • Stability: stable
  • Versioning: follows repository version and the shared Fabric tool standard
  • Owner: jhf-keystore as source repo, helpifyr-fabric as reader

Implemented:

  • the checked-in manifest now carries the shared baseline fields required by the tool standard.
  • the manifest and docs now point to the canonical access-model and contract set.
  • Fabric can read a conservative repository contract without runtime access.

Planned:

  • no runtime control surface is implemented here.

Helpifyr Fabric contract adoption​

  • Direction: outgoing read-only
  • Type: adoption-contract
  • Surface: docs/FABRIC_CONTRACT_ADOPTION.md, contracts/fabric-contract-adoption.json, fabric-manifest.json
  • Fabric surfaces: GET /api/v1/contracts/matrix, GET /api/v1/contracts/docs-standard
  • Auth: none for checked-in adoption declarations; live readback is operator-triggered only
  • Stability: stable
  • Versioning: follows the accepted Fabric contract families declared in the adoption contract
  • Owner: jhf-keystore as consumer boundary, helpifyr-fabric as family owner

Implemented:

  • the repository now declares the Fabric contract families it consumes and the accepted versions for each family.
  • the docs-standard alignment and the wiki-governance adoption are recorded in one explicit repo-owned contract declaration.

Planned:

  • no local Fabric family truth beyond the adoption declaration
  • no implicit version fallback outside the declared compatibility window

Helpifyr Fabric combination profile intake​

  • Direction: outgoing read-only
  • Type: repo-read
  • Surface: fabric-manifest.json, docs/FABRIC_TOOL_PROFILE.md, docs/INTEGRATIONS.md, docs/ACCESS_MODEL.md
  • Fabric endpoint: api/v1
  • Auth: none for the published combination profile truth
  • Stability: stable
  • Versioning: follows the Fabric bundle profile contract; this repository does not define combination truth locally
  • Owner: helpifyr-fabric as truth source, jhf-keystore as consumer

Implemented:

  • the repository now records the Fabric bundle-profile endpoint as a read-only consumer surface.

Planned:

  • no local bundle truth
  • no local detection truth
  • no profile override semantics in this repository

Access-model upstream contract intake​

  • Direction: incoming read-only
  • Type: contract-consumer
  • Surface: contracts/identity-claims.schema.json, contracts/entitlement-model.schema.json, contracts/vaultwarden-projection.schema.json, contracts/reconcile-events.schema.json, contracts/local-consumption.schema.json, docs/ACCESS_MODEL.md
  • Auth: none for checked-in contract files; live read validation still requires local operator auth
  • Stability: stable
  • Versioning: follows the checked-in contract set, the repo-local acceptance matrix, and the ERP cross-repo acceptance matrix version in this repository
  • Owner: upstream truth remains with jhf-heddle, helpifyr-fabric, and jhf-deployment; jhf-keystore is the read-only consumer

Implemented:

  • the repository now states exactly which upstream access-model truth it consumes
  • contract validation is repo-local and deterministic through python3 scripts/validate-access-model.py
  • contracts/consumed-upstream-contracts.json records the concrete sibling-repo inputs used for optional workspace-level validation
  • the canonical identity claim language is pinned read-only to jhf-heddle/config/identity/claim-vocabulary.v2.yaml
  • contracts/identity-claim-consumption.json records which claim fields may be read and which local reinterpretations are forbidden
  • contracts/access-verification-model.json records the local personal/department/company/agent verification families and their required Fabric/Deployment truth
  • contracts/vault-metadata-inventory.json records metadata-only Vault inventory posture and machine-readable sensitivity classes
  • contracts/operator-verdicts.json records severity, escalation, and next-step context for drift/security incidents
  • contracts/erp-identity-access-acceptance-matrix.json records the operator-facing cross-repo pass/fail and evidence contract

Planned:

  • no local ownership of identity, entitlement, or projection truth
  • no remote fetch of upstream contracts in the default gate

Vaultwarden admitted SSO consumer contract intake​

  • Direction: incoming read-only
  • Type: admitted-surface-contract-consumer
  • Surface: contracts/vaultwarden-sso-consumer-runtime.json, contracts/consumed-upstream-contracts.json, scripts/verify-vaultwarden-sso-consumer-contract.sh
  • Upstream sources: jhf-heddle/config/clients/admitted-surfaces.v1.yaml, jhf-heddle/config/clients/vaultwarden-keystore-client-template.yaml, jhf-spindle/docs/contracts/surface-access-posture-model.json
  • Auth: none for checked-in contracts; live verify is operator-triggered only
  • Stability: stable
  • Versioning: follows SSO v4 admitted-surface contract versions in upstream owner repos
  • Owner: upstream truth remains with jhf-heddle, helpifyr-fabric, and jhf-spindle; jhf-keystore is read-only consumer

Implemented:

  • admitted Vaultwarden surface posture is now explicit and versioned in-repo without local shadow truth.
  • login/admin/revoke posture is covered by a deterministic repo verify script and an optional live verify path.

Planned:

  • no local OIDC client authoring
  • no local role or revocation truth

SSO v4 cross-surface acceptance suite​

  • Direction: incoming read-only plus local deterministic verification
  • Type: acceptance-suite-contract
  • Surface: contracts/sso-v4-cross-surface-acceptance.json, contracts/operator-verdicts.json, scripts/verify-sso-v4-cross-surface-acceptance.sh
  • Upstream sources: jhf-heddle/config/clients/admitted-surfaces.v1.yaml, disable/delete fail-closed contracts, owner-runtime evidence from owning repos
  • Auth: none for contract checks; live add-on is operator-triggered and keystore-surface-scoped
  • Stability: stable
  • Versioning: follows SSO v4 wave contracts and repo acceptance contract version
  • Owner: jhf-keystore owns acceptance contract/verifier; truth remains in upstream owner repos

Implemented:

  • one canonical acceptance matrix now covers all admitted surface keys.
  • superadmin disable/delete propagation checks are explicit and fail-closed.
  • drift routing and operator verdicts are explicit for missing truth and broken runtime auth wiring.

Planned:

  • no local runtime execution for non-keystore surface owners.
  • no local identity/policy/projection shadow truth.

Helpifyr Fabric wiki intake​

  • Direction: outgoing read-only
  • Type: repo-read
  • Surface: docs/OVERVIEW.md, docs/SOLUTION_OVERVIEW_DE.md, docs/FABRIC_TOOL_PROFILE.md, docs/INTEGRATIONS.md, docs/CAPABILITIES.md
  • Auth: none for checked-in documentation
  • Stability: stable
  • Versioning: follows repository version and the shared wiki aggregation contract
  • Owner: jhf-keystore as source repo, helpifyr-fabric as reader

Implemented:

  • documentation is structured for shared aggregation without inventing a repo-local wiki layer.

Planned:

  • no repo-local wiki system.

n8n governance reference​

  • Direction: bidirectional logical integration
  • Type: compatibility-shim
  • Surface: examples/n8n/README.md
  • Auth: no runtime auth contract is implemented in this repository
  • Stability: planned
  • Versioning: documentation-only until a real runtime contract exists
  • Owner: jhf-keystore for documentation, future runtime ownership unresolved

Implemented:

  • documentation of the intended governance direction exists.

Planned:

  • no real write-back integration is implemented.
  • the future write-governance auth contract is document-only and tracked in Gitea issue #30.

integrated-mode runtime registration​

  • Direction: incoming
  • Type: registry-contract
  • Surface: future Fabric-readable metadata only; no runtime endpoint
  • Auth: none for checked-in metadata
  • Stability: planned
  • Versioning: will follow the future Fabric shared contract if and when it exists
  • Owner: jhf-keystore for local documentation, helpifyr-fabric as external discovery consumer

Implemented:

  • the repository currently remains standalone and read-first.

Planned:

  • describe what Fabric may read for integrated-mode discovery
  • keep runtime registration explicitly non-implemented
  • do not add a service surface or remote control path

adopt-first standalone-to-integrated migration​

  • Direction: logical / operational
  • Type: migration-contract
  • Surface: documentation and runbook only
  • Auth: operator-managed
  • Stability: planned
  • Versioning: tied to repository and Fabric contract evolution
  • Owner: jhf-keystore for local guidance, operator for execution

Implemented:

  • standalone operation is documented and reproducible.

Planned:

  • document adopt / reconfigure / migrate / rebuild decisions
  • keep migration read-only and non-automated in this repository
  • no forced migration workflow or secret-write path

Warp dependency track​

  • Direction: outgoing read-only
  • Type: contract-doc set
  • Surface: docs/WARP_DEPENDENCY_TRACK.md, contracts/warp-dependency-track.md, contracts/secret-lifecycle.md, contracts/revocation-rules.md, contracts/orphan-dangling-state.md, contracts/race-and-versioning.md, contracts/approval-and-audit.md
  • Auth: none for checked-in docs and schemas
  • Stability: stable as a documentation boundary, not as a provisioning surface
  • Versioning: follows repository version and the Warp dependency track contract
  • Owner: jhf-keystore as consumer boundary, jhf-warp / downstream operators as consumers of the contract

Implemented:

  • the repository now spells out the secret authority, lease, delegation, rotation, invalidation, degraded-backend, and audit-evidence boundary expected by Warp-facing consumers.

Planned:

  • no repo-local provisioning authority
  • no remote secret lease service
  • no live control plane surface for Warp

External Integrations​

Bitwarden CLI​

  • Direction: outgoing
  • Type: execution-contract
  • Surface: bw
  • Auth: local login/session basis
  • Stability: stable
  • Versioning: follows installed bw CLI behavior and compatibility with the local workflow
  • Owner: external dependency, consumed by jhf-keystore

Implemented:

  • the repository resolves secrets through the local bw process contract.

Vaultwarden or Bitwarden backend​

  • Direction: outgoing read-only
  • Type: provider-contract
  • Surface: backend access via bw; no direct repository-defined endpoint
  • Auth: through bw
  • Stability: experimental
  • Versioning: depends on backend compatibility with the current bw item-resolution path
  • Owner: external backend boundary, consumed indirectly through bw

Implemented:

  • the current verify path is read-first only through the local CLI workflow.

Planned:

  • no direct backend API contract is implemented in this repository.

Event Contracts​

  • none implemented

The repository does not publish or consume event-bus contracts today.

MCP Integration​

  • none implemented

The repository does not expose an MCP server or MCP-based callback surface today.

Planned Connections​

Bounded live verification path​

  • Direction: outgoing read-only
  • Type: operator-consumer
  • Surface: future bounded operator/host-backed verification path; no checked-in runtime surface today
  • Auth: operator-managed local credentials outside default CI
  • Stability: planned
  • Versioning: documentation and workflow only until a bounded path is approved
  • Owner: operator/external verification boundary

Implemented:

  • default CI remains repo-local and does not perform live secret resolution.

Planned:

  • a separate non-default verification path may be documented later without widening the default gate.
  • live drift detection expectations for Vaultwarden-backed reads are tracked in Gitea issue #29.