Hexis Files

What's new

Several knowledge bases from one process. A Hexis process can now serve many knowledge bases, one per host name, each with its own repository, admin, users, settings, secrets and Postgres schema. Opt in with TENANTS_FILE and TENANT_MASTER_KEY; a deployment that serves one knowledge base changes nothing. DB_SCHEMA lets a single deployment keep its tables on a schema of its own, which is also what a knowledge base moved out of a shared host arrives with. See docs/multi-tenant.md.

Plugin links repair themselves. A link is healthy only when the linked skill's root carries the plugin's own read and write grants. Opening a plugin's page as someone who may write the plugin puts missing grants back, as ordinary commits in their name; what cannot be repaired names the people who can.

Fixed

• Four layout defects: the sidebar's first row started a band below the page title, the file page's history mode lost its column, a plugin row's owner chip and counts sat on different lines, and the tool page's menu rendered under the description.
• Every compose file that pulls the app image now sets pull_policy: always, so a redeploy of :latest fetches the image the tag currently names instead of a build the host pulled months ago. If you copied an older compose file, take the release's.

Upgrading

Nothing is required of an existing deployment. Migrations and the knowledge-base maintenance phase run on boot as usual. A saved git token now reaches git directly and is no longer copied into the process environment.

For overlays built on the @bevel-software/platform-* packages: the knowledge-base context (branch model, folder layout, checkout folder name) travels by constructor as KbContext where kbDirName went; the shared helpers take the layout or model they answer for; syncGitTokenEnv and linksWorkspaceId are gone; createCoreServices takes a TenantConfig. Details in .changeset/multi-tenant-kb-context.md at this tag.