brain-core

@neuralis/brain-core is the platform's brain. It gives every project one URI-addressed view over all of its data — local directories, the vector memory, package contents, machine sandboxes — and keeps that view searchable by syncing connector content into a Qdrant-backed vector index: chunked, embedded, scoped per project, user, and agent, and governed per path by URI policies. Any system you can write a connector for joins the same virtual tree, and a synced source pays back twice — its content becomes searchable memory and its markdown becomes source packages. Agents read, write, list, and search through four fs_* tools; users browse the same data through the Files widget in the workspace.

ResponsibilitiesCopy Anchor Link

• Read, create, modify, list, and search files across every registered source through one URI vocabulary (data://notes/todo.md, brain://insights/...).
• Manage project-, user-, and agent-scoped source configurations, and host the connector registry contract so other packages can plug in new source kinds.
• Sync connector content into the vector index with chunked embeddings, and keep the index healthy (orphan repair, garbage collection, duplicates report).
• Expose the filesystem HTTP routes and the fs_* agent tools.
• Serve the governed git/* routes over git-backed sources — status, diff, history, staging, commit, branch, and fetch / pull / push to a connected remote — under the same per-path URI policy as every other read and write, with a server-side rescue point recorded before a destructive operation wherever a revert baseline can be taken (a file the caller cannot resolve to one is removed raw, and the tool says so).
• Render the workspace Files widget and the filesystem-change card that appears in chat after every fs_write call.

The four-tuple file coordinate (uri, connector, os_uri?, container_dir?) and the full URI scheme table are explained on Sources and connectors.

Folder mapCopy Anchor Link

The pages in this section mirror brain-core's real package folders:

The fs_* tool familyCopy Anchor Link

The fs_* tools cover the whole filesystem surface — fs_read, fs_list, fs_search and fs_write. Each declares its own feature gate (x-neuralis.requires.features) and the matching HTTP routes carry the same gates independently, so the agent path and the direct-HTTP path are both checked. fs_read and fs_list are connector-first (live data even when the index is cold); every write snapshots a baseline so fs_write with revert gives one-level undo, and delete opens an approval interaction in chat unless the run is in auto mode. The full per-tool reference — the three search modes and every write key — is on Tools.

Features providedCopy Anchor Link

brain-core declares its permission vocabulary in the manifest; roles receive defaults that admins can change per project (see roles and features).

The seeded owner role holds the '*' wildcard, so it holds every feature — including ones no package grants. The seeded admin role does NOT: it holds an enumerated list derived from the first-party manifests, so a feature that reaches admin does so because a manifest declared the grant. Most skills and other contributions shipped by brain-core carry requiredFeatures frontmatter and are hidden entirely from callers who lack the grant. The create-package authoring skill is the deliberate exception — it is ungated so any caller can read the contract, while every capability it describes stays gated at the write, the build, and the diagnostics call.

Security and scopeCopy Anchor Link

Every route extracts the caller's identity from the verified session — never from the request body — and rejects mismatched project ids. Source visibility is evaluated per scope: project-scoped sources are visible to all members, while user- and agent-scoped sources require ownership or an observeScoped grant. The brain:// memory source is additionally isolated per agent inside a project: semantic queries filter by the calling agent unless sibling access is explicitly requested. Per-path access on every source is governed by URI policies.

Default workflow templateCopy Anchor Link

The package ships a Sources digest workflow template: a working-day digest of what changed across your synced sources since the last run — new and modified files, per-source summaries, and hygiene flags for stale or contradicting documents. It requires search access to the drive, so it is not offered to read-only viewers.

In this sectionCopy Anchor Link