Core

Load and validate YAML configuration for BrightOps SDKs.

Availability and installation

This guide covers @wf/core version 0.3.0-alpha.6. Configure the BrightOps registry in your project’s .npmrc; keep the license key in your local or CI secret store:

@wf:registry=https://store.brightops.io/npm/
//store.brightops.io/npm/:_authToken=${WF_SDK_LICENSE_KEY}

Install with npm install --save-exact @wf/core@0.3.0-alpha.6. A licensed BrightOps SDK includes access to its pinned Core dependency. A paid download preserves access to those exact versions for later rebuilds after cancellation; revocation blocks access. Installed applications do not contact this registry at runtime. This remains a preview API; review the compatibility record before upgrading.

The supported runtime, exported entry points, and compatibility commitments are listed in Compatibility. Check Release notes before upgrading.

Configure and use

Keep SDK settings in a YAML file and pass its path to the package’s public client. Keep credentials in application-owned secret storage; configuration examples contain references, not secret values.

The settings example and buyer script work without credentials or a provider call:

import { readPluginConfig } from '@wf/core'

const settings = readPluginConfig('/absolute/path/settings.yaml', {
  type: 'object', required: ['name'],
  properties: { name: { type: 'string' }, cache: { type: 'path' } },
})

Your application owns this schema and its domain validation. readPluginConfig validates the YAML file, rejects unknown fields and resolves relative paths from that file's directory. Duplicate keys, tags, aliases, executable includes and inline settings objects are rejected. Credentials stay in host secret storage. Core makes no provider call and does not start background work when imported.

For an isolated validation run, relocatePluginConfig identifies declared data paths and nested configuration paths using each SDK's exported schema. The host can copy configuration files and assign empty data locations without opening existing application data. This does not enable arbitrary YAML includes.

Core also supplies bounded bridge/MCP transports and portable identity, immutable JSON, JSON Schema, timeout and output-retention helpers used by BrightOps SDKs. Use the entry points listed in Compatibility. MCP endpoints require protocol 2026-07-28; older initialization protocols are rejected. Update the client and server together and run wf-mcp-check before switching an application endpoint.

Integration responsibilities

The application owns user authorization, credential storage, and permission to make external calls. Review the example before running it: a connected provider or an update action can have real effects. Preserve the package’s cancellation and disposal behavior where those APIs are exposed.

Preview compatibility is limited to the combinations actually recorded in Compatibility. An empty verified-combinations list is not a promise that every platform or client has been tested.