@anchrd/intel

Intel is a customer-deployed, model-agnostic operating layer for company intelligence and processes. It gives people and MCP-capable AI clients the same governed access to two surfaces:

• Intelligence — company content as nodes, with sharing, immutable versions, retrieval, citations and a graph. A process is a node too: skill documents say in prose how a piece of work is done, and process boards carry work that needs several hands over several days
• Applications — a register of the applications the company uses, one document per application in the folder Anwendungen at the top of Shared, written by an administrator. Intel connects to none of them: every AI client uses its own tools, and a card or a skill refers to an application by a link to its document

The UI, the HTTP API and the Intel MCP surface call the same application services, so authorization, validation and side effects never differ by surface. You deploy it into your own Cloudflare account against your own Gate; nothing runs on Anchrd infrastructure.

This package contains the portable server, the Cloudflare adapter, the D1 migrations and the customer CLI.

Requirements

• A Gate instance — Gate owns identity and capabilities, and is the only required Anchrd dependency
• A Cloudflare account with Workers, D1, R2 and Queues (Vectorize, Workers AI and an AI Gateway are optional and only add semantic search and attachment conversion)
• Node 22 or newer

Setting Intel up

Nine steps. Step 3 talks only to Gate and can happen at any point; the rest run in this order, because each one needs what the one before it produced. Step 8 is the one people skip, and skipping it produces an installation that looks broken and is not.

npm install @anchrd/intel

1. Create the Cloudflare resources

All of these have to exist before the deploy in step 7.

wrangler d1 create intel                  # note the printed database_id
wrangler r2 bucket create intel-content
wrangler queues create intel-indexing
wrangler queues create intel-indexing-dlq # without it an exhausted message is dropped silently
wrangler vectorize create intel-nodes --dimensions=1024 --metric=cosine   # optional, see Bindings

The Vectorize shape is not a free choice: 1024 dimensions and cosine are what Intel's default multilingual Workers AI embedding model (@cf/baai/bge-m3) produces. Nothing in the deploy compares the two, so an index created with other values fails later, at the first write.

2. Write the Worker

The customer edge re-exports the ready-made Cloudflare shell and nothing else:

// biome-ignore lint/performance/noBarrelFile: This is the intentional two-line Wrangler entrypoint.
export { default } from "@anchrd/intel/cloudflare";

⚠️ Up to 0.84 the edge also exported IntelFlowWorkflow and bound it as the Workflow FLOWS. Both are gone with the flows: an edge that still names the export fails to build, and a Workflow binding whose class the script no longer exports is refused at deploy. Take both out together.

Its Wrangler configuration declares the bindings from the table below, and points migrations_dir at .intel/migrations — the directory step 4 fills. assets.directory points at .intel/ui, which step 5 fills.

3. Declare Intel's interfaces in Gate

GATE_URL=… GATE_SERVICE_KEY=… npx intel bootstrap

⚠️ bootstrap reads its configuration from the environment of the shell it runs in, not from the Worker's secrets — the two are different places that happen to use the same names. Without both values it stops with Error: GATE_URL and GATE_SERVICE_KEY must be set. before it does anything.

It declares four interfaces — intel, nodes, tools, mcp — with the functions listed under Permission, layer one below. It is idempotent and safe to repeat after an upgrade.

⚠️ bootstrap hands out no grant, and it takes none away as long as the declared list does not change. It creates the permissions an administrator can hand out; it hands out none of them. This is step 8, and it is why a fresh installation shows an empty screen to everybody including the person who installed it.

⚠️ But a function that falls out of a still-declared interface takes its grants with it. Declaring is an upsert that REPLACES an interface's function list, and Gate deletes every grant on a function the new list no longer names. So an upgrade that retires a function also retires every role assignment on it — against a running installation that is a change to who may do what, not a read. bootstrap reads the catalog before it writes and names each one as it goes (flows:approve went this way in 0.x, #73):

Removed tools:admin from Gate; every grant on it was deleted with it.
Declared 4 Intel interfaces in Gate.

A run that dropped nothing says so instead: No declared function was dropped, so Gate deleted no grant. And if the catalog cannot be read, bootstrap writes nothing at all rather than delete grants it would then be unable to name.

⚠️ It never revokes a whole interface. One an older version declared stays declared in Gate: bootstrap writes only the handles it names, so an interface outside that list keeps its functions and its grants. That is harmless, and removing one is an act in Gate, by hand. flows is one of them since the flows left Intel: doctor names it as a surplus with the reason.

4. Copy the migrations out of node_modules

npx intel prepare

This writes the versioned SQL to .intel/migrations. It only copies — applying them is the next step, and nothing does it for you:

wrangler d1 migrations apply intel --local    # a local Worker
wrangler d1 migrations apply intel --remote   # the deployed one

Migration filenames and their order are immutable after release. Re-run intel prepare after every upgrade of this package, before applying.

5. Build the UI

npx intel build

intel build reads an optional strict intel.json, applies the customer branding, and writes the static output to .intel/ui. See Branding below. No customer build output ever lives in node_modules.

6. Configure the Worker

Set the variables and secrets from the two tables below. GATE_SERVICE_KEY, INTEL_SESSION_SECRET and, for the Resend way, RESEND_API_KEY are Wrangler secrets (wrangler secret put …); the rest are plain vars. Which way a notification mail leaves the Worker is named in INTEL_MAILER: see Mail: three ways out below.

For a local Worker, copy node_modules/@anchrd/intel/examples/dev.vars.example to .dev.vars.

7. Check it, then deploy

npx intel doctor
wrangler deploy

doctor checks the same environment bootstrap uses, plus the installed packages and migrations and the Gate interfaces. It reports every problem at once rather than the first:

NOTE INTEL_MAILER is unset, so the console mailer is active: a notification is logged and never sent.
FAIL GATE_URL is missing
FAIL INTEL_URL is missing
FAIL GATE_SERVICE_KEY is missing
FAIL INTEL_SESSION_SECRET must contain at least 32 bytes

It also compares the Gate interfaces in both directions. A function or a whole interface Gate carries that this version of Intel no longer declares is reported as a NOTE, never as a FAIL: nothing is broken by it, and a check one knows red stops being read. Each note names the surplus, why it went, and what to do about it:

NOTE Gate carries the interface tools (read, test, execute), which Intel does not declare — the whole interface went when Intel stopped connecting to tools; an application is a document in Anwendungen at the top of Shared (anchrd/intel#1150, #1291, #1327, ADR-0009).
NOTE Gate carries the interface flows (read, create, write, publish, run, share), which Intel does not declare — the whole interface went when flows left Intel; skills and process boards replace them (anchrd/intel#1149, ADR-0008).
NOTE The next `intel bootstrap` removes a surplus function and every grant on it (#474). Take the grant away in Gate first if anybody should keep it.
NOTE `bootstrap` never touches an interface Intel does not declare, so a surplus one stays until somebody removes it in Gate by hand — which takes its grants with it.
OK Intel packages, configuration, and Gate interfaces are ready.

⚠️ doctor cannot see the Worker's secrets. It answers about the shell it runs in, so it says nothing about whether the deployed Worker is configured. GET /health on the deployed Worker answers {"status":"ok"}; a Worker missing one of the four required variables answers 500 configuration_missing and names them.

⚠️ doctor does not check that step 4 happened. It looks for the migrations installed in node_modules, not for the copies in .intel/migrations, so it answers OK on a project that never ran intel prepare. wrangler deploy does not mind an empty migrations_dir either, and the first sign is a database with no tables in it. The .intel/migrations directory has to be checked by eye.

8. Hand out permissions — both layers

This is the step that decides whether anybody sees anything, and it is entirely manual.

1. In Gate, grant people the Intel capabilities from Permission, layer one. Without nodes.read the sidebar answers 403 and says a permission is missing.
2. In Intel, share a node with them. Without a grant the tree is empty — correctly, because nothing has been shared yet.

Both are needed. Neither on its own produces a usable screen, and the symptom of missing either one is the same shape: a view with nothing in it. See Permission has two layers below.

9. Write the register of applications

Intel connects to no application. In the folder Anwendungen at the top of Shared an administrator files one document per application the company uses — what it is for, who may use it, how to connect it in one's own AI client, and who is responsible. A card or a skill refers to an application by a link to that document, and what stands in the register counts as approved. See Applications are references below.

An installation that was seeded

Up to 0.95 Intel wrote its own documentation, processes and an intake board into the tree (doc_seed). Nothing is seeded any more. An installation that was seeded puts what the seed filed away once, as an administrator with the admin mode on (see Permission has two layers), through node_seed_archive (POST /api/v1/nodes/seed/archive):

1. Call it with dryRun: true. It names every seeded tree it would archive with the number of nodes in it, and under kept every seeded folder it leaves standing because the company filed entries of its own in it. A process with a schedule or a live run counts as the company's and is never archived. Out of Doku, move names what goes to the top of Shared.
2. Call it with dryRun: false. Everything it named is archived — never deleted, and every node can be restored with node_archive. A second call finds nothing left.

A folder under kept is yours to sort: move the company's entries out, then archive it by hand.

Bindings

The reference Wrangler deployment binds all of these. "Required" means a request fails without it, not that Wrangler refuses to deploy.

| Binding | Resource | Required | What its absence costs | |---|---|---|---| | DB | D1 | yes | Nothing works: D1 owns metadata, relationships, grants, board and run state, audit | | CONTENT | R2 | yes | Node content and attachments cannot be read or written | | INDEXING | Queue | yes | Every save fails; this is the queue that builds the indexes | | ASSETS | static assets from .intel/ui | for the UI | The API and MCP surface still answer; the browser application is not served at all | | AI | Workers AI | no | Two losses, and only one is obvious. No semantic search, and no attachment conversion — an uploaded PDF or Word file is stored intact but never becomes searchable text | | SEARCH | Vectorize index, 1024 dims, cosine | no | Search silently falls back to lexical only. Nothing says so, and half a search looks exactly like a whole one | | EMAIL | Cloudflare Email Service, send_email | for INTEL_MAILER=cloudflare | Read only for that way; with it named and the binding missing, the first request answers 500 configuration_missing. The Resend way and the console never touch it |

⚠️ Semantic search needs AI, SEARCH and the variable AI_GATEWAY_ID. Any one of the three missing leaves search lexical. If you add them to an existing installation, run intel reindex afterwards — the embeddings for content already stored are built by that pass and by nothing else.

⚠️ The gateway is a condition, not an option. Intel makes no Workers AI call without it: no gateway name, no semantic index and no attachment conversion. The alternative — calling Workers AI directly whenever the variable is absent — is the failure this rule exists against, because a spend limit set on the gateway counts only what passes through it. An installation embedding past it works perfectly, costs money, and tells nobody.

There is no AGENT service binding, and AI_GATEWAY_ACCOUNT_ID and the AI_GATEWAY_READ_TOKEN secret are gone. All three belonged to the agent runtime, which is no longer part of Intel; an installation that still carries them can drop them, including wrangler secret delete AI_GATEWAY_READ_TOKEN. ⚠️ AI_GATEWAY_ID is not among them: it carries a different job now, described in the row below.

Mail: three ways out

Intel sends two kinds of mail: the notification that a new todo card is waiting for somebody, and the one that somebody was mentioned in a chat as a person (@jack, never @jack/session). Each goes out at once or waits for the one daily digest that carries both, as the person chose. Which way it leaves the Worker is named in INTEL_MAILER, and it is named or nothing is sent:

| INTEL_MAILER | Sends through | Needs | Notes | |---|---|---|---| | resend | Resend's HTTP API | the secret RESEND_API_KEY and INTEL_MAIL_FROM | The sender's domain has to be verified at Resend. No send_email binding needed | | cloudflare | the EMAIL binding of the Cloudflare Email Service | the binding EMAIL and INTEL_MAIL_FROM | The sender's domain has to be onboarded in the Email Service; until it is, the binding refuses every unverified destination with E_SENDER_NOT_VERIFIED | | unset or console | the worker log | nothing | Writes recipient and subject to the log, never the body, and sends nothing. What a fresh installation and the local dev stub run with |

⚠️ A named way with a half missing refuses the first request with 500 configuration_missing, and so does a value that is none of the three. That is deliberate: a typo must not fall back to the log and become noticeable only once a notification never arrived. intel doctor reports the same from the shell, and it reports an unset INTEL_MAILER as a NOTE, because a binding beside a sender no longer picks the Cloudflare way on its own: an installation that relied on that names the way now.

⚠️ Why the reference installation uses Resend although Cloudflare would be cheaper: Microsoft blocks the sending network of the Cloudflare Email Service. The first real mail to an outlook.de address came back as a hard bounce (550 5.7.1), and only the owner of the IP can have it delisted. A delivery path that fails silently on Microsoft addresses does not carry a notification.

Variables and secrets

Every value below is read in two different places depending on the command, and mixing them up is the most common setup failure:

• the Worker's environment — what the deployed Intel reads on every request;
• the shell's environment — what intel bootstrap, intel doctor and intel reindex read.

GATE_URL, GATE_SERVICE_KEY, INTEL_URL and INTEL_SESSION_SECRET are needed in both. Setting them only as Wrangler secrets leaves the CLI blind, and setting them only in a shell leaves the Worker answering 500 configuration_missing.

⚠️ The three mail values (INTEL_MAILER, INTEL_MAIL_FROM, RESEND_API_KEY) are in the same trap, and they fail quietly: set only on the Worker, doctor reads them as unset and notes the console mailer about an installation that sends.

⚠️ MCP_PORTAL_URL and TOOL_SOURCE_ORIGINS are read by nothing since 0.86.0 (anchrd/intel#1150). An installation that still sets them keeps two values that do nothing; remove them from the Worker and from the shell.

| Name | Where | Required | What it does, and what a wrong value does | |---|---|---|---| | GATE_URL | Worker + shell | yes | The Gate this installation authenticates against. Wrong: every request is refused and no login completes | | GATE_SERVICE_KEY | Worker secret + shell | yes | Intel's own service credential at Gate. Wrong: every authorization call fails, so everything answers as unauthenticated. It is a secret and never appears in a response, log or tool result | | INTEL_URL | Worker + shell | yes | Intel's own public base URL. It is also the OAuth resource identifier: Intel asks Gate for a token for <INTEL_URL>/mcp. ⚠️ A trailing-slash or scheme difference is a different resource. ⚠️ Changing it later is a one-way street: the resource is bound once on the Gate side and cannot be re-pointed — the way back is deleting the Gate service and setting it up again. Decide the hostname before the first login, not after | | INTEL_SESSION_SECRET | Worker secret + shell | yes | Derives the key for the encrypted HttpOnly session cookie. Must be at least 32 bytes. ⚠️ Changing it invalidates every session — everybody signs in again | | ALLOW_INSECURE_OAUTH | Worker | no | true permits an http:// OAuth issuer. Local development only. Production issuers must be HTTPS | | INTEL_MAILER | Worker + shell (for doctor) | no | Which way a notification mail leaves the Worker: resend, cloudflare or console. Unset means the console (logged, never sent), whatever else is configured. A named way with a half missing, or a value that is none of the three, answers 500 configuration_missing on the first request | | INTEL_MAIL_FROM | Worker + shell (for doctor) | for resend and cloudflare | The sender address, whose domain has to be verified with the provider the way names. Not a secret | | RESEND_API_KEY | Worker secret + shell (for doctor) | for resend | The Resend API key. It never appears in a response, log line or tool result; whatever Resend answers is struck out of it before it is logged | | AI_GATEWAY_ID | Worker | for AI | The name of the AI Gateway every Workers AI call is routed through, as it stands in the address of its dashboard page. ⚠️ Unset means Intel calls Workers AI not at all — no semantic index, no attachment conversion — rather than calling it directly. A wrong name fails the embedding and conversion calls loudly, which is the intended direction: a spend limit set on the gateway counts only what reaches it | | INTEL_SENTRY_DSN | Worker + shell (for doctor) | no | The DSN of an error endpoint that speaks the Sentry protocol (anchrd runs GlitchTip at https://glitchtip.anchrd.sh). Where this installation reports its own errors to, in the Worker and in the browser: the shell hands the surface the same value on GET /api/v1/session. Unset means no SDK is started and nothing is sent, which is the default. It is not a secret, so it is a var rather than a Worker secret. What is sent: the exception, its stack, the request url and method, and the tags installation and release. What is not: sendDefaultPii stays off, so no reader's address, no cookie and no request body, and no traces (tracesSampleRate: 0). ⚠️ The Content-Security-Policy intel build writes lets the browser reach https://glitchtip.anchrd.sh only: a DSN pointing at another host still reports from the Worker, but the browser drops every report of the interface | | INTEL_OPERATOR_TOKEN | shell | for reindex | A short-lived bearer carrying the Gate capability intel.admin, used only by intel reindex. Not a Worker value and not a stored one |

Gate OAuth uses PKCE and dynamic public-client registration; browser access tokens stay inside an encrypted HttpOnly cookie and are never exposed to the UI bundle or D1.

Branding: intel.json

Put intel.json next to the customer project's package.json:

{
  "ui": {
    "theme": "./branding/theme.css",
    "logo": "./branding/logo.svg",
    "favicon": "./branding/favicon.svg",
    "defaultLanguage": "en",
    "languages": {}
  }
}

The theme is plain CSS containing shadcn semantic tokens such as --primary, --background, --sidebar, and --radius. It is loaded after Intel's defaults, so customer tokens win without a component fork. Unknown config fields, missing assets, non-SVG branding, and incomplete language catalogs fail the build rather than producing a half-branded application. A ready-to-copy starting point is included under node_modules/@anchrd/intel/examples.

The file is optional: intel build without it produces the default Intel branding.

Permission has two layers

Access to anything in Intel is the and of two independent answers, and neither layer knows about the other. This is the single most common source of "it is broken" reports, because a person missing either layer sees roughly the same thing: a screen with nothing on it.

Layer one: the Gate capability

What somebody may do at all, granted in Gate. intel bootstrap declares these; an administrator grants them.

| Interface | Functions | |---|---| | intel | admin | | nodes | read, create, write, share | | tools | read, test, execute | | mcp | connect |

A missing capability answers 403, and the screen says a permission is missing.

intel.admin is also who a missing tool reaches. A person's AI files what the person is missing as one card, assigned to everybody who holds intel.admin at that moment — each of them finds it on their todo board and is notified. The same people are named in the browser's onboarding guide under "I can't get any further". Intel asks Gate for them on every call (directory_admin_list, GET /api/v1/directory/admins, through Gate's directory/holders door, which Gate answers from 0.37 on); there is nothing to configure. With nobody holding it, the card is filed without an assignee and the person is asked to pass it on.

⚠️ mcp.connect is the one that gates a whole endpoint rather than an action. Intel's own MCP endpoint (POST /mcp, the one an MCP client connects to) checks it on every request and answers 403 without it — before any tool runs and before anything is read. Two things follow for an operator:

• Somebody who should use Intel through an MCP client needs mcp.connect in Intel, beside their nodes.* capabilities. Without it the client authenticates successfully and every call is refused.
• Revoking it takes effect on the next call, with no new sign-in and nothing to press. If a Cloudflare Access policy in front of the endpoint also compares the mcp claim, that layer is the slower of the two — the claim is written once per sign-in and a running session carries it for up to 24 hours, while this check reads the live grant rows every time.

The web UI is unaffected: it speaks the HTTP surface, which is gated by nodes.* and tools.* as before.

⚠️ intel.admin counts only with the admin mode on

Holding intel.admin is not enough on its own: the caller has to ask for it, on every request. The browser does it through the switch Admin mode in the user menu; over HTTP the request carries the header intel-admin-mode: on, over MCP the tool call carries asAdmin: true (every tool takes it). Without it an administrator is treated as the person they are — their own grants, no admin area, no admin action, and an admin route such as POST /api/v1/nodes/reindex answers 403.

A script or scheduled run that acts as an administrator has to send it, or it is refused: filing at the top level, node_reindex, node_transfer, node_seed_archive, notification_digest_run and the digest route alike.

Layer two: the grant on the node

What somebody may reach in this tree, granted in Intel on a node. Three verbs — read, write, share — each granted on its own; none implies another.

A grant on a folder is inherited by everything beneath it, including nodes created after the grant was made. That is the usual way to share a whole area.

A missing grant answers 404, never 403: Intel gives the same answer for "there is no such node" and "not for you", so that a refusal never confirms that something exists.

Reading the empty screen

| What you see | Which layer | |---|---| | A sentence naming a missing permission | Gate — layer one | | An empty tree, no error | Intel — nothing has been shared with this person yet | | A node that vanished between two visits | Its grant was revoked; revocation takes effect immediately, on every path, without a new login |

A shared node appears in the recipient's navigation on its own, at the top level, without exposing the titles of the folders above it. Nobody has to be sent a link.

Export and import

GET /api/v1/nodes/export writes the whole installation as this caller may read it; the same route under a node id exports that subtree. Import is the mirror:

curl -X POST https://intel.example.com/api/v1/nodes/import \
  -H "authorization: Bearer $TOKEN" \
  -H "content-type: application/zip" \
  -H "idempotency-key: $(uuidgen)" \
  --data-binary @bundle.zip

⚠️ The idempotency key travels as a header. The body is the zip itself, so there is nowhere else to put it. A request without the header is refused.

Only nodes the caller may read enter the bundle; exporting a folder that is out of reach answers 404. A fresh import answers 201; a repeat of the same idempotency key answers 200 with the summary of the earlier import, because this request created nothing.

⚠️ A bundle carries only the current state of each node. Version history does not survive export → import. A document with two versions comes back with one, and the earlier one is then retrievable nowhere. Everything else survives in full — nodes per kind, table content including a previous redefine, and attachments byte for byte. The loss is accepted and deliberate, but anyone moving an installation this way has to know about it before they start: after the import there is nothing to recover from.

Applications are references

Intel connects to no application and runs no tool (ADR-0009). Every AI client that works with Intel uses its own tools — its connectors, its MCP servers, their OAuth and their credentials — and Intel stores none of that: no catalog, no tool permission, no tool secret.

What Intel holds is the register: one document per application in the folder Anwendungen in the top of Shared, written by an administrator by hand. An installation that still has Doku keeps it under Doku/Anwendungen; node_seed_archive moves it there. It says what the application is for, who may use it, how to connect it in one's own client and who is responsible, and what stands there counts as approved. Everything else refers to it:

• A card, a skill or a rule names an application by a link to its document. It is an ordinary document link; nothing about it is special.
• A check is a linked node, not a tool (ADR-0010). An entry links the skill, document or table that describes or carries what its validity hangs on (node_check_create); whoever runs the check reads it, does what it describes with their own client, and reports with node_verdict_create.
• A removed application is found by the Lint guard. An administrator archives the document of an application nobody uses any more, and lint_run reports every link to it as dangling_link.
• A missing application is a card, not a state. Where a person's client lacks an application a card or a skill needs, the person's AI files a card assigned to everybody holding intel.admin.

⚠️ An MCP portal in front of your other MCP servers is your choice, outside Intel. A hosted customer may use the Cloudflare MCP Portal to hand its people one address for many servers; Intel neither consumes nor configures it. Up to 0.85.0 Intel did — the tool_* tools, the Tools screen and a sealed per-user portal token in D1 — and 0.86.0 removed all of it; migration 0049 drops the token table.

The intel CLI

intel prepare    Copy versioned D1 migrations to .intel/migrations
intel bootstrap  Idempotently declare Intel interfaces in Gate
intel build      Apply intel.json and atomically build the customer UI
intel doctor     Check packages, environment, migrations, UI, and Gate interfaces
intel reindex    Request a full authorized search-index rebuild

All five run in the customer project directory — the one holding package.json, intel.json and node_modules — and read their configuration from that shell's environment.

intel reindex needs INTEL_URL and a short-lived INTEL_OPERATOR_TOKEN. It asks the running installation to rebuild the derived indexes from D1 and R2 and returns as soon as the request is accepted; the work happens on the indexing queue. Reach for it after adding AI, SEARCH and AI_GATEWAY_ID to an installation that ran without them, and after restoring an emptied Vectorize index.

Writing against the API directly

Everything the browser does is available over HTTP and over the Intel MCP surface, against the same application services. The schemas are inside this package under src/contract — the runtime- validated wire formats the server, the browser application and every MCP tool share. Read src/contract/README.md first: it carries the six things that reliably cost a first-time caller an afternoon.

What is in this package

One package carries all of Intel, and that is deliberate: an installation pins one version number instead of three that could drift apart.

| Path | What it is | |---|---| | dist/ | the server: portable application services, the HTTP and MCP adapters, the Cloudflare shell behind @anchrd/intel/cloudflare | | bin/intel.mjs | the intel CLI — prepare, bootstrap, build, doctor, reindex | | migrations/ | the D1 migrations, copied out by intel prepare | | src/contract/ | the wire schemas, as source, because the browser application compiles them too | | ui/ | the browser application, shipped as source so intel build applies your own theme, logo and languages — see ui/README.md |

⚠️ Installing this package pulls the browser build toolchain with it — Vite, React, Tailwind and the document renderers are runtime dependencies here, even if you never run intel build. That is the knowingly accepted cost of one version number: a headless Intel has no consumer today, and splitting one out later is more expensive than not building it now.

⚠️ @anchrd/intel-api, @anchrd/intel-ui and @anchrd/intel-contract are the predecessors of this package. Once this package is on npm they get an npm deprecate pointing here. They are not deleted, and the versions that are published stay published.

License

Proprietary. Published publicly for installation convenience; this is not an open-source license and grants no right to use, copy, modify or redistribute the software. Contact Anchrd for licensing.