diff --git a/reference/configuration/overview.md b/reference/configuration/overview.md index 73f6f98f..112327b2 100644 --- a/reference/configuration/overview.md +++ b/reference/configuration/overview.md @@ -9,6 +9,10 @@ title: Configuration Overview Harper is configured through a [YAML](https://yaml.org/) file called `harper-config.yaml` located in the Harper root directory. By default the root directory is a folder named `hdb` in the home directory of the current user. +:::note Which file your instance reads +The active config file is the one named by `settings_path` in Harper's boot properties file (usually `~/.harperdb/hdb_boot_properties.file`); a `ROOTPATH` environment variable or `--ROOTPATH` argument overrides it. A fresh v5 install records `harper-config.yaml`, but an instance upgraded from v4 keeps whatever its boot properties already named — usually `harperdb-config.yaml`, which Harper still reads. Upgrading neither renames the file nor repoints `settings_path`, so renaming it alone will break startup; update `settings_path` in the same step, and avoid leaving both files in the root directory at once. +::: + Some configuration values are pre-populated in the config file on install, regardless of whether they are used. For a complete reference of all available configuration options, see [Configuration Options](./options.md). diff --git a/reference/mcp/cli.md b/reference/mcp/cli.md index fe8c8b76..a572610d 100644 --- a/reference/mcp/cli.md +++ b/reference/mcp/cli.md @@ -31,7 +31,7 @@ harper mcp [subcommand] [flags] With no `--target` flag, the CLI connects to the Harper running on the same host via the operations API Unix Domain Socket — the same socket `bin/cliOperations` uses. Filesystem permissions on the socket are the access gate; no credentials are required or sent. -The UDS path is derived from `operationsApi.network.domainSocket` in `harperdb-config.yaml` and is typically `/sockets/operations-server`. +The UDS path is derived from `operationsApi.network.domainSocket` in `harper-config.yaml` and is typically `/sockets/operations-server`. ### Network HTTPS / HTTP diff --git a/reference/mcp/configuration.md b/reference/mcp/configuration.md index 205c2609..2915d5d8 100644 --- a/reference/mcp/configuration.md +++ b/reference/mcp/configuration.md @@ -6,7 +6,7 @@ title: MCP Configuration -All MCP configuration lives under the top-level `mcp:` block in `harperdb-config.yaml`. Each profile (`operations`, `application`) is enabled by the **presence** of its sub-block — there is no separate `enabled` flag. A minimal "turn it on" config is therefore just: +All MCP configuration lives under the top-level `mcp:` block in `harper-config.yaml`. Each profile (`operations`, `application`) is enabled by the **presence** of its sub-block — there is no separate `enabled` flag. A minimal "turn it on" config is therefore just: ```yaml mcp: diff --git a/reference/mcp/migration.md b/reference/mcp/migration.md index bcc7cb97..0315772d 100644 --- a/reference/mcp/migration.md +++ b/reference/mcp/migration.md @@ -23,13 +23,13 @@ This page covers what changes for you and how to migrate. | Rate limiting | Not present | Per-session, per-tool token-bucket on both profiles | | Audit logging | Operations API audit log only | Dedicated `mcp.audit` category with credential redaction | | Per-attribute permissions | Not honored in the tool surface | Narrowed at schema-derivation time | -| Config | Env vars + addon's own JSON | Top-level `mcp:` block in `harperdb-config.yaml` | +| Config | Env vars + addon's own JSON | Top-level `mcp:` block in `harper-config.yaml` | ## Migration checklist ### 1. Enable the built-in MCP surface -Add an `mcp:` block to `harperdb-config.yaml`. The minimal "turn it on" form is: +Add an `mcp:` block to `harper-config.yaml`. The minimal "turn it on" form is: ```yaml mcp: diff --git a/reference/resources/resource-api.md b/reference/resources/resource-api.md index a5268333..1f121d54 100644 --- a/reference/resources/resource-api.md +++ b/reference/resources/resource-api.md @@ -745,7 +745,7 @@ async get(target) { ### Session and Login from a Resource -The context returned by `getContext()` exposes `login` and `session` for handling sign-in/out flows in a custom Resource. Sessions require `authentication.enableSessions: true` in `harperdb-config.yaml`. +The context returned by `getContext()` exposes `login` and `session` for handling sign-in/out flows in a custom Resource. Sessions require `authentication.enableSessions: true` in `harper-config.yaml`. ```typescript export class SignIn extends Resource { diff --git a/release-notes/v5-lincoln/v5-migration.md b/release-notes/v5-lincoln/v5-migration.md index 8a95f9ba..905475ab 100644 --- a/release-notes/v5-lincoln/v5-migration.md +++ b/release-notes/v5-lincoln/v5-migration.md @@ -120,7 +120,7 @@ The `blob.save()` method has been removed. Please use the `saveBeforeCommit` fla Harper v5 loads application modules through Node.js's VM module API, giving each application its own module cache and a `harper` module scoped to that application — the `logger` it exports is tagged with the application name, and `config` reflects that application's own configuration. By default (`vm-current-context`), applications share JavaScript intrinsics (`Object`, `Array`, `Promise`, and so on) with Harper. Sharing intrinsics avoids the compatibility problems that separate per-application intrinsics can cause — most commonly `instanceof` and other identity checks failing for values that cross the application/Harper boundary. -All module loading behavior is controlled by the `applications` section in `harperdb-config.yaml`: +All module loading behavior is controlled by the `applications` section in `harper-config.yaml`: ```yaml applications: