> ## Documentation Index
> Fetch the complete documentation index at: https://86d.store/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# How Modules package Store capabilities

> The difference between a Feature, an Integration, and a Module, and how to turn one on without breaking your Store.

<Warning>
  **In development.** Every Module in the catalog currently publishes as Experimental with no recorded evidence. See [maturity levels](/docs/resources/versioning) before you enable one on a Store that matters.
</Warning>

Your Store does not come with everything switched on. You pick what it does by enabling [Modules](/docs/resources/glossary#module), and a Module you never enable costs you nothing: no routes, no tables, no admin pages, no attack surface.

If you are deciding what to turn on, start at the [Module catalog](/docs/modules/overview). If you are writing one, start at [Build a custom Module](/docs/guides/building-a-module).

## Three words, three layers

| Term                                    | What it means                                                                        |
| --------------------------------------- | ------------------------------------------------------------------------------------ |
| **Feature**                             | Something your Store does. Products, Loyalty, Discounts                              |
| **Integration**                         | Something your Store does with an outside company. Stripe, EasyPost, Meta            |
| **Module**                              | The package that delivers either one. The word you need when installing or upgrading |
| **[Connection](/docs/concepts/connections)** | The configured provider account an Integration uses                                  |

A merchant thinks in Features and Integrations. A Module is how those arrive.

## What a Module can add

Enabling one Module can give your Store:

* public Store endpoints under `/api/...`
* authenticated [Store Admin](/docs/concepts/admin) endpoints under `/api/admin/...`
* [Storefront](/docs/concepts/storefront) React components you can drop into MDX
* Store Admin pages, placed in the sidebar automatically
* database schema and controller behavior
* declared requirements on, and exports to, other Modules

First-party Modules live under the `@86d-store` npm scope, with source in `modules/` in the [public repository](https://github.com/86d-store/86d).

<Warning>
  A package being in the repository, the registry, or npm says nothing about whether it works. Read its reference page, its source, its tests, and how it behaves when a provider is down before you enable it.
</Warning>

## Turn one on

Your active [Template](/docs/concepts/templates)'s `config.json` holds the list:

```json templates/brisa/config.json theme={null}
{
  "modules": [
    "@86d-store/products",
    "@86d-store/collections",
    "@86d-store/blog"
  ],
  "advanced": {
    "version": 1,
    "allowExperimentalModules": true
  }
}
```

<Steps>
  <Step title="Read the page first">
    Open the Module's page in the [catalog](/docs/modules/overview). Check what it depends on and what it does when something fails.
  </Step>

  <Step title="Add the package name">
    Put the exact npm package name in the active Template's `modules` array.
  </Step>

  <Step title="Regenerate">
    ```bash theme={null}
    86d generate
    ```

    The generator installs anything missing and writes the static Module and component imports.
  </Step>

  <Step title="Prove it works">
    Run the affected tests, open the Storefront and Store Admin pages it added, and check its failure states, not only its happy path.
  </Step>
</Steps>

Every first-party registry entry currently publishes as Experimental, so the resolver needs both an explicit package list and `advanced.version: 1` with `allowExperimentalModules: true`. Writing `"modules": "*"`, or leaving `modules` out entirely, discovers entries but admits no Experimental code even with the flag set.

## Use a Module's components

Enabled Storefront components are registered for MDX, so they need no import:

```mdx theme={null}
<FeaturedProducts limit={4} />

<CollectionGrid featured />
```

## Declared binding and storage

Every edge between Modules (capabilities, hooks, readers, template data, and durable events) is declared when the Store is provisioned and compiled into one deterministic execution graph. Nothing discovers another Module at request time. An unsatisfied, incompatible, ambiguous, or cyclic edge fails the build instead of degrading silently.

**Authoring contract:** every Module declares one explicit `storage.kind`: `none`, `config`, or `relational`. Relational storage contains native Zod `tables` with the `col` registry and may add `config`, `extends`, `anchors`, and `publishes`. A storage-free Module writes `storage: { kind: "none" }`; storage is never inferred from absence. [`ModuleDataService`](/docs/resources/glossary#moduledataservice) reads and writes compiled Postgres tables under `mod_<moduleId>` and declared Config keys only through the compiled data service.

Synchronous contract versions use stable SemVer with exact or caret (`^`) ranges; durable event schema versions are exact positive integers. Optional edges are allowed only when the owner Module is not installed; an installed owner with a missing or incompatible contract fails the build.

Storage kinds:

| Kind           | What the Store creates                                                                                                                 |
| -------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **None**       | Nothing. Common for Integrations such as Stripe                                                                                        |
| **Config**     | Zod-validated declared keys in `core.module_config`                                                                                    |
| **Relational** | Native `mod_<moduleId>` tables and/or approved typed core extensions, with optional declared Config keys, anchors, and published views |

## Isolation

Database isolation is the enforceable boundary: each Module runs under its own Postgres role with access to its schema and column-projected views published to it. An unpublished column is unreachable, not filtered. Request transactions enter the Module role with `SET LOCAL ROLE`; the login role holds no Module privileges, so a missed role switch fails closed.

In-process JavaScript isolation is not claimed. Modules share one event loop. Cross-Module decisions use typed capabilities; cross-Module reads use published views, not direct table access.

Today the runtime still carries legacy `requires`/`exports` field metadata and an in-memory event path beside the compiled durable outbox. Cross-Module decisions use typed capabilities; cross-Module reads use published views and compiled readers. See [cross-Module communication](/docs/concepts/architecture#how-modules-talk-to-each-other).

## External Modules

The CLI resolves compatible npm and GitHub specifiers:

```bash theme={null}
86d module add npm:package_name_here
86d module add github:owner_name_here/repository_name_here/modules/module_name_here
```

External code runs inside your Store Runtime with the same access your own code has. Pin a version or a commit, read the whole source, check compatibility, and look at install scripts before enabling it. The first-party registry is a manifest, not a trust service: there is no review process, no ranking, and no badge behind it.

## Related pages

* [Module catalog](/docs/modules/overview)
* [Add a Module](/docs/guides/adding-modules)
* [Build a custom Module](/docs/guides/building-a-module)
* [Templates](/docs/concepts/templates)
* [CLI command reference](/docs/cli/commands)
* [Glossary](/docs/resources/glossary)
* [Versioning and maturity](/docs/resources/versioning)