skillscript-runtime 0.13.8 → 0.14.0

package/examples/connectors/{MemoryStoreTemplate/MemoryStoreTemplate.ts → DataStoreTemplate/DataStoreTemplate.ts}

@@ -1,44 +1,44 @@
 /**
- * MemoryStoreTemplate — fork-me skeleton for writing your own MemoryStore impl.
+ * DataStoreTemplate — fork-me skeleton for writing your own DataStore impl.
  *
  * This is NOT a runnable connector. Every method throws a "TODO" error. The
- * purpose is to surface the MemoryStore contract surface in a copy-and-customize
+ * purpose is to surface the DataStore contract surface in a copy-and-customize
  * shape so adopters writing AMP-, Pinecone-, Weaviate-, Qdrant-, or
- * Postgres-backed MemoryStores have a starting skeleton.
+ * Postgres-backed DataStores have a starting skeleton.
  *
  * Forking workflow:
- *   1. Copy this directory into your codebase (`cp -r examples/connectors/MemoryStoreTemplate examples/connectors/MyMemoryStore`)
- *   2. Rename the class — typically `<Substrate>MemoryStore` (e.g., `PineconeMemoryStore`, `AmpMemoryStore`)
+ *   1. Copy this directory into your codebase (`cp -r examples/connectors/DataStoreTemplate examples/connectors/MyDataStore`)
+ *   2. Rename the class — typically `<Substrate>DataStore` (e.g., `PineconeDataStore`, `AmpDataStore`)
  *   3. Implement each method against your substrate's API
  *   4. Update `staticCapabilities()` to declare what your impl actually supports
  *   5. Register from your adopter bootstrap:
- *        `registry.registerMemoryStore("primary", new MyMemoryStore({ ... }))`
+ *        `registry.registerDataStore("primary", new MyDataStore({ ... }))`
  *   6. Validate via the conformance suite:
- *        `MemoryStoreConformance.buildTests({ build: () => new MyMemoryStore(...), ctor: MyMemoryStore })`
+ *        `DataStoreConformance.buildTests({ build: () => new MyDataStore(...), ctor: MyDataStore })`
  *
- * See `src/connectors/memory-store.ts` for the working reference implementation
- * (`SqliteMemoryStore` — SQLite + FTS5 backing). The full contract spec lives in
- * `src/connectors/types.ts` (`MemoryStore` interface + `PortableMemory` +
- * `QueryFilters` + `MemoryWrite` types).
+ * See `src/connectors/data-store.ts` for the working reference implementation
+ * (`SqliteDataStore` — SQLite + FTS5 backing). The full contract spec lives in
+ * `src/connectors/types.ts` (`DataStore` interface + `PortableData` +
+ * `QueryFilters` + `DataWrite` types).
  *
- * Runtime hosts (MCP server + web dashboard) honor whichever MemoryStore impl
+ * Runtime hosts (MCP server + web dashboard) honor whichever DataStore impl
  * you register via the registry, so once your fork passes the conformance
- * suite the entire `$ memory` / `$ memory_write` dispatch path reads + writes
+ * suite the entire `$ data_read` / `$ data_write` dispatch path reads + writes
  * against your substrate.
  */
 
 import type {
-  MemoryStore,
+  DataStore,
   QueryFilters,
-  PortableMemory,
-  MemoryWrite,
-  MemoryWriteRecord,
-  MemoryStoreCapabilities,
+  PortableData,
+  DataWrite,
+  DataWriteRecord,
+  DataStoreCapabilities,
   ManifestInfo,
 } from "skillscript-runtime/connectors";
 
 /** Replace with your substrate's connection config (host, dbName, API key, etc.). */
-export interface MemoryStoreTemplateConfig {
+export interface DataStoreTemplateConfig {
   // TODO — declare the fields your substrate needs to connect.
   // Examples:
   //   pineconeApiKey?: string;
@@ -48,16 +48,16 @@ export interface MemoryStoreTemplateConfig {
   exampleConfigField?: string;
 }
 
-export class MemoryStoreTemplate implements MemoryStore {
+export class DataStoreTemplate implements DataStore {
   /**
    * Declare what your impl supports. The runtime + lint consult these flags
    * before exercising features. Set conservatively — overclaiming triggers
    * cryptic downstream failures; underclaiming hides usable features.
    */
-  static staticCapabilities(): MemoryStoreCapabilities {
+  static staticCapabilities(): DataStoreCapabilities {
     return {
-      connector_type: "memory_store",
-      implementation: "MemoryStoreTemplate", // ← rename to your class name
+      connector_type: "data_store",
+      implementation: "DataStoreTemplate", // ← rename to your class name
       contract_version: "1.0.0",
       features: {
         // TODO — set each flag based on what your substrate can actually do.
@@ -73,29 +73,29 @@ export class MemoryStoreTemplate implements MemoryStore {
   }
 
   // eslint-disable-next-line @typescript-eslint/no-unused-vars
-  constructor(_config: MemoryStoreTemplateConfig) {
+  constructor(_config: DataStoreTemplateConfig) {
     // TODO — establish your substrate connection. For SQL: open the database
     // + run schema migrations. For vector DB: cache the SDK client + index
     // name. For HTTP: store the base URL + auth headers.
-    throw new Error("MemoryStoreTemplate is a fork-me skeleton; replace with your impl.");
+    throw new Error("DataStoreTemplate is a fork-me skeleton; replace with your impl.");
   }
 
   /**
    * Capability snapshot for `runtime_capabilities` discovery. Return free-form
    * substrate-specific metadata (kind, version, supported modes, score range, etc.).
    *
-   * The bundled `SqliteMemoryStore.manifest()` returns:
+   * The bundled `SqliteDataStore.manifest()` returns:
    *   { capabilities_version: "1", manifest: { kind: "sqlite-fts",
    *       supported_modes: ["fts"], score_range: "unbounded",
    *       supported_filters: ["domain_tags"], supports_write: true } }
    */
-  async manifest(): Promise<ManifestInfo<"memory_store">> {
+  async manifest(): Promise<ManifestInfo<"data_store">> {
     // TODO — return a snapshot of your substrate's capabilities.
     throw new Error("TODO: manifest() — return substrate-specific capability snapshot.");
   }
 
   /**
-   * Query memories by mode + filter. Return `PortableMemory[]` ordered by
+   * Query memories by mode + filter. Return `PortableData[]` ordered by
    * relevance (most relevant first). Empty result is fine; never throw "not
    * found" — return [].
    *
@@ -109,7 +109,7 @@ export class MemoryStoreTemplate implements MemoryStore {
    *     `types.ts`, these top-level fields are first-class for substrates
    *     that have them.
    *
-   * `PortableMemory` core fields:
+   * `PortableData` core fields:
    *   - Always: `id`, `summary`, `created_at`
    *   - Often: `detail`, `score`, `domain_tags`, `payload_type`
    *   - Per-substrate (curated): `pinned`, `confidence`, `thread_status`,
@@ -117,23 +117,23 @@ export class MemoryStoreTemplate implements MemoryStore {
    *   - Catch-all: `metadata` object for substrate-specific extensions
    */
   // eslint-disable-next-line @typescript-eslint/no-unused-vars
-  async query(_filters: QueryFilters): Promise<PortableMemory[]> {
+  async query(_filters: QueryFilters): Promise<PortableData[]> {
     // TODO — translate `filters` to your substrate's query API.
     //   - Reject unsupported `mode` values with a clear error (don't silently
     //     fall back; cold authors will be confused)
     //   - Apply curated-subset filters (domain_tags, payload_type, etc.) where
     //     the substrate supports them
-    //   - Map your substrate's result rows into `PortableMemory` shape
+    //   - Map your substrate's result rows into `PortableData` shape
     //   - Order by relevance (most relevant first)
     //   - Honor `limit`
-    throw new Error("TODO: query() — return PortableMemory[] ordered by relevance.");
+    throw new Error("TODO: query() — return PortableData[] ordered by relevance.");
   }
 
   /**
    * Persist a new memory entry. Return the substrate-assigned `id` +
    * `created_at` (unix seconds).
    *
-   * `MemoryWrite` shape:
+   * `DataWrite` shape:
    *   - `content`: string (required; the memory body)
    *   - `tags`: string[] (optional; routed to substrate's tag mechanism)
    *   - `recipients`: string[] (optional advisory — substrates with alerting
@@ -143,7 +143,7 @@ export class MemoryStoreTemplate implements MemoryStore {
    *     extensions like `vault`, `payload_type`, `confidence`)
    */
   // eslint-disable-next-line @typescript-eslint/no-unused-vars
-  async write(_entry: MemoryWrite): Promise<MemoryWriteRecord> {
+  async write(_entry: DataWrite): Promise<DataWriteRecord> {
     // TODO — persist the memory via your substrate.
     //   - Generate or accept an id (substrate-dependent)
     //   - Persist content + tags + metadata

package/examples/connectors/{MemoryStoreTemplate → DataStoreTemplate}/README.md

@@ -1,10 +1,10 @@
-# MemoryStoreTemplate — fork-me skeleton
+# DataStoreTemplate — fork-me skeleton
 
-A skeleton `MemoryStore` implementation for adopters writing their own. Not runnable; every method throws a `TODO` error. Copy this directory, rename, fill in the substrate-specific work.
+A skeleton `DataStore` implementation for adopters writing their own. Not runnable; every method throws a `TODO` error. Copy this directory, rename, fill in the substrate-specific work.
 
 Use this when you want skillscript memories backed by:
 - A vector database (Pinecone, Weaviate, Qdrant, Chroma)
-- A memory system (AMP, hosted memory API)
+- A data store backing (memory broker like AMP, hosted memory API, vector DB, etc.)
 - A different SQL flavor (Postgres + pgvector, MySQL)
 - An HTTP CRUD service
 - Anything else with query + write semantics
@@ -12,32 +12,32 @@ Use this when you want skillscript memories backed by:
 ## The three legs
 
 ```
-MemoryStore (choose which connector)
-   ├── SqliteMemoryStore (bundled, SQLite + FTS5 — src/connectors/memory-store.ts)
+DataStore (choose which connector)
+   ├── SqliteDataStore (bundled, SQLite + FTS5 — src/connectors/data-store.ts)
    ├── (no other bundled impl — vector DBs and remote services are adopter-side)
    └── Your fork from this template
 ```
 
-The runtime is substrate-agnostic. Memories don't know which backend they're stored against — the contract is the `MemoryStore` interface, and any class implementing it works.
+The runtime is substrate-agnostic. Memories don't know which backend they're stored against — the contract is the `DataStore` interface, and any class implementing it works.
 
 ## Forking workflow
 
 ```bash
-cp -r examples/connectors/MemoryStoreTemplate examples/connectors/MyMemoryStore
+cp -r examples/connectors/DataStoreTemplate examples/connectors/MyDataStore
 ```
 
-1. **Rename the class.** Convention: `<Substrate>MemoryStore` (e.g., `PineconeMemoryStore`, `PostgresMemoryStore`, `AmpMemoryStore`).
-2. **Define your config interface.** Edit `MemoryStoreTemplateConfig` to declare what your substrate needs (connection URL, API key, vault name, index name, etc.).
+1. **Rename the class.** Convention: `<Substrate>DataStore` (e.g., `PineconeDataStore`, `PostgresDataStore`, `AmpDataStore`).
+2. **Define your config interface.** Edit `DataStoreTemplateConfig` to declare what your substrate needs (connection URL, API key, vault name, index name, etc.).
 3. **Implement each method.** Three methods + `staticCapabilities()`. Each has a TODO comment in the skeleton explaining what to do.
 4. **Update `staticCapabilities()`** to declare what your impl actually supports. The runtime + lint consult these flags before exercising features.
 5. **Wire from your adopter bootstrap:**
 
    ```typescript
    import { Registry } from "skillscript-runtime";
-   import { MyMemoryStore } from "./MyMemoryStore.js";
+   import { MyDataStore } from "./MyDataStore.js";
 
    const registry = new Registry();
-   registry.registerMemoryStore("primary", new MyMemoryStore({
+   registry.registerDataStore("primary", new MyDataStore({
      // your config
    }));
    ```
@@ -46,37 +46,37 @@ cp -r examples/connectors/MemoryStoreTemplate examples/connectors/MyMemoryStore
 
    ```typescript
    import { describe, it } from "vitest";
-   import { MemoryStoreConformance } from "skillscript-runtime/testing";
-   import { MyMemoryStore } from "./MyMemoryStore.js";
+   import { DataStoreConformance } from "skillscript-runtime/testing";
+   import { MyDataStore } from "./MyDataStore.js";
 
-   describe("MyMemoryStore conformance", () => {
-     const tests = MemoryStoreConformance.buildTests({
-       build: () => new MyMemoryStore({ /* test config */ }),
-       ctor: MyMemoryStore,
+   describe("MyDataStore conformance", () => {
+     const tests = DataStoreConformance.buildTests({
+       build: () => new MyDataStore({ /* test config */ }),
+       ctor: MyDataStore,
      });
      for (const t of tests) it(`[${t.category}] ${t.name}`, t.run);
    });
    ```
 
-   The conformance suite verifies your impl honors the contract: method presence, return-type shape, capability flag self-consistency. Passes → runtime treats your impl interchangeably with `SqliteMemoryStore`.
+   The conformance suite verifies your impl honors the contract: method presence, return-type shape, capability flag self-consistency. Passes → runtime treats your impl interchangeably with `SqliteDataStore`.
 
 ## Reference implementation
 
 When in doubt about semantics, read the bundled impl:
 
-- **`src/connectors/memory-store.ts`** — `SqliteMemoryStore`, SQLite + FTS5-backed. Schema lives in `bootstrap()` (memories table + FTS virtual table + AFTER INSERT/UPDATE/DELETE triggers). Single-process. Capability flags: `supports_writes: true`, `supports_tag_filter: true`, FTS only (semantic / rerank false).
+- **`src/connectors/data-store.ts`** — `SqliteDataStore`, SQLite + FTS5-backed. Schema lives in `bootstrap()` (memories table + FTS virtual table + AFTER INSERT/UPDATE/DELETE triggers). Single-process. Capability flags: `supports_writes: true`, `supports_tag_filter: true`, FTS only (semantic / rerank false).
 
 ## Contract surface (3 methods)
 
-The MemoryStore contract is narrower than SkillStore. Three methods + `staticCapabilities()`:
+The DataStore contract is narrower than SkillStore. Three methods + `staticCapabilities()`:
 
 | Method | What it does | When called |
 |---|---|---|
-| `query(filters)` | Read memories by mode + filter; return `PortableMemory[]` | Every `$ memory mode=... query=...` op |
-| `write(entry)` | Persist a new memory; return `{id, created_at}` | Every `$ memory_write content=... -> R` op + `memory_write` skill notify routes |
+| `query(filters)` | Read memories by mode + filter; return `PortableData[]` | Every `$ data_read mode=... query=...` op |
+| `write(entry)` | Persist a new memory; return `{id, created_at}` | Every `$ data_write content=... -> R` op + `data_write` skill notify routes |
 | `manifest()` | Capability snapshot for `runtime_capabilities` discovery | At startup + on-demand from MCP clients |
 
-Per the curated-subset framing in `src/connectors/types.ts`, `PortableMemory` has a 4-tier field model:
+Per the curated-subset framing in `src/connectors/types.ts`, `PortableData` has a 4-tier field model:
 
 1. **Core fields** — `id`, `summary`, `detail`, `score` (always-meaningful)
 2. **Curated substrate subset** — top-level fields with portable concepts: `domain_tags`, `payload_type`, `knowledge_type`, `pinned`, `confidence`, `thread_status`, `recipients`, `expires_at`, `agent_id`, `vault`
@@ -89,8 +89,8 @@ Per the curated-subset framing in `src/connectors/types.ts`, `PortableMemory` ha
 
 `QueryFilters.mode` is the dispatch axis:
 
-- **`"fts"`** — full-text search; substrate-defined (BM25, BM25F, etc.). `SqliteMemoryStore` supports this via FTS5.
-- **`"semantic"`** — embedding-based similarity. Vector-DB substrates support this; `SqliteMemoryStore` does not.
+- **`"fts"`** — full-text search; substrate-defined (BM25, BM25F, etc.). `SqliteDataStore` supports this via FTS5.
+- **`"semantic"`** — embedding-based similarity. Vector-DB substrates support this; `SqliteDataStore` does not.
 - **`"rerank"`** — substrate-defined hybrid (e.g., FTS retrieve + embedding rerank). Optional.
 - **substrate-specific strings** — your fork can define its own modes; document them in `manifest().manifest.supported_modes`.
 
@@ -111,7 +111,7 @@ Honor what your substrate supports; ignore the rest. Document the supported set
 
 ## `write()` semantics
 
-The `MemoryWrite` shape:
+The `DataWrite` shape:
 
 - **`content`** (required) — the memory body
 - **`tags`** (optional) — routed to your substrate's tag mechanism
@@ -125,18 +125,18 @@ If your substrate doesn't support writes (read-only memory like a search index o
 
 ## Wiring against the dashboard / MCP
 
-Runtime hosts honor whichever MemoryStore impl your registry has. To make your fork visible through `skillfile dashboard`:
+Runtime hosts honor whichever DataStore impl your registry has. To make your fork visible through `skillfile dashboard`:
 
-- Write a custom bootstrap that constructs the runtime with your MemoryStore (see `src/bootstrap.ts` for the reference shape)
+- Write a custom bootstrap that constructs the runtime with your DataStore (see `src/bootstrap.ts` for the reference shape)
 - OR (planned future) declare in `~/.skillscript/connectors.json`:
 
   ```json
   {
     "substrate": {
-      "memory_store": {
+      "data_store": {
         "type": "custom",
-        "module": "./my-memory-store.js",
-        "export": "MyMemoryStore",
+        "module": "./my-data-store.js",
+        "export": "MyDataStore",
         "config": { "pineconeApiKey": "${PINECONE_KEY}" }
       }
     }
@@ -145,11 +145,11 @@ Runtime hosts honor whichever MemoryStore impl your registry has. To make your f
 
   Current limitation: sync `bootstrap()` can't dynamic-import, so the `custom` form surfaces an error today. Programmatic bootstrap is the path until async-bootstrap support lands.
 
-## MemoryStore vs SkillStore differences
+## DataStore vs SkillStore differences
 
 Both are substrate-agnostic, but they differ in shape:
 
-| Aspect | SkillStore | MemoryStore |
+| Aspect | SkillStore | DataStore |
 |---|---|---|
 | Methods | 8 (load, query, metadata, versions, store, delete, update_status, manifest) | 3 (query, write, manifest) |
 | Versioning | First-class (`versions()`, `load(name, version)`) | Substrate-side (e.g., `supersededById` in AMP); not in contract |
@@ -158,12 +158,12 @@ Both are substrate-agnostic, but they differ in shape:
 | Curated-subset fields | None | Many (`domain_tags`, `pinned`, `confidence`, `recipients`, etc.) |
 | Forking complexity | Higher (multi-method state machine) | Lower (three methods, simpler semantics) |
 
-The narrower contract is why MemoryStoreTemplate ships sooner + smaller than SkillStoreTemplate.
+The narrower contract is why DataStoreTemplate ships sooner + smaller than SkillStoreTemplate.
 
 ## Further reading
 
 - **[`../../../docs/configuration.md`](../../../docs/configuration.md)** — substrate selection via `connectors.json`
 - **[`../../../docs/adopter-playbook.md`](../../../docs/adopter-playbook.md)** — programmatic-bootstrap patterns; two-instance posture
-- **`src/connectors/types.ts`** — authoritative `MemoryStore` interface, `PortableMemory`, `QueryFilters`, `MemoryWrite` types
+- **`src/connectors/types.ts`** — authoritative `DataStore` interface, `PortableData`, `QueryFilters`, `DataWrite` types
 - **`src/testing/conformance.ts`** — the per-contract conformance test suites
-- **`src/connectors/memory-store.ts`** — `SqliteMemoryStore` reference impl + schema
+- **`src/connectors/data-store.ts`** — `SqliteDataStore` reference impl + schema

package/examples/connectors/LocalModelTemplate/README.md

@@ -113,7 +113,7 @@ Adopters wire their custom LocalModel **programmatically** from their bootstrap:
 registry.registerLocalModel("default", new MyLocalModel({ /* config */ }));
 ```
 
-Declarative custom-LocalModel via `connectors.json` `substrate.local_model: {type: "custom", module, export, config}` form is **deferred** until async-bootstrap support lands. Same limitation applies to `SkillStore` and `MemoryStore` custom forms — sync `bootstrap()` can't `await import()`. Not LocalModel-specific.
+Declarative custom-LocalModel via `connectors.json` `substrate.local_model: {type: "custom", module, export, config}` form is **deferred** until async-bootstrap support lands. Same limitation applies to `SkillStore` and `DataStore` custom forms — sync `bootstrap()` can't `await import()`. Not LocalModel-specific.
 
 ## Wiring against the dashboard / MCP
 

package/examples/connectors/McpConnectorTemplate/McpConnectorTemplate.ts

@@ -15,8 +15,8 @@
  *   - `LocalModelMcpConnector` — bridges a registered LocalModel as
  *     `$ llm prompt=...` MCP dispatch. Auto-wired when LocalModel substrate
  *     is configured.
- *   - `MemoryStoreMcpConnector` — bridges a registered MemoryStore as
- *     `$ memory mode=...` MCP dispatch. Auto-wired when MemoryStore substrate
+ *   - `DataStoreMcpConnector` — bridges a registered DataStore as
+ *     `$ data_read mode=...` MCP dispatch. Auto-wired when DataStore substrate
  *     is configured.
  *
  * Fork from this template when none of those fit — e.g.:

package/examples/connectors/McpConnectorTemplate/README.md

@@ -9,7 +9,7 @@ A skeleton `McpConnector` implementation for adopters writing their own. Not run
 | `RemoteMcpConnector` | Stdio bridging to remote MCP servers (`npx mcp-remote ...`). YouTrack, GitHub, Linear, most adopter MCP wiring goes through this. JSON-configurable via `connectors.json`. |
 | `CallbackMcpConnector` | Wraps a JS function. Test rigs + embedder-wired transports where the dispatch is local code. |
 | `LocalModelMcpConnector` | Bridges a registered `LocalModel` as `$ llm prompt=...`. Auto-wired when `substrate.local_model` is set. |
-| `MemoryStoreMcpConnector` | Bridges a registered `MemoryStore` as `$ memory mode=...`. Auto-wired when `substrate.memory_store` is set. |
+| `DataStoreMcpConnector` | Bridges a registered `DataStore` as `$ data_read mode=...`. Auto-wired when `substrate.data_store` is set. |
 
 **Fork this template only when none of those fit** — e.g.:
 
@@ -72,7 +72,7 @@ The bundled impls are the canonical reference:
 - **`src/connectors/mcp-remote.ts`** — `RemoteMcpConnector`. Most comprehensive: stdio framing (LSP and newline), child process lifecycle (spawn → initialize → tools/list cache → SIGTERM/SIGKILL on dispose), `fromConfig` factory with strict validation, per-message timeout discipline. The closest reference for any transport that needs robust lifecycle management.
 - **`src/connectors/mcp.ts`** — `CallbackMcpConnector`. Minimal reference: 60 LOC. The closest reference for embedder-wired transports.
 
-When in doubt, read both + the bridge classes (`local-model-mcp.ts`, `memory-store-mcp.ts`) for how single-substrate bridges work.
+When in doubt, read both + the bridge classes (`local-model-mcp.ts`, `data-store-mcp.ts`) for how single-substrate bridges work.
 
 ## Contract surface (2 methods)
 
@@ -131,15 +131,15 @@ Two registration paths:
 
 The declarative path is the canonical adopter pattern for stdio-bridged remote MCPs. Your fork is for transports the declarative path can't express.
 
-## McpConnector vs. SkillStore / MemoryStore differences
+## McpConnector vs. SkillStore / DataStore differences
 
-| Aspect | McpConnector | SkillStore / MemoryStore |
+| Aspect | McpConnector | SkillStore / DataStore |
 |---|---|---|
 | Methods | 2 (call, manifest) | 3-8 (more state machine) |
 | Cardinality | Many instances per deployment | One singleton per slot |
 | Substrate config | Per-instance via top-level keys | `substrate` section short/object/custom |
 | Class extensibility | `registerConnectorClass()` for adopter-custom classes | Programmatic bootstrap (or `substrate.skill_store: {type: "custom", ...}` once async-bootstrap lands) |
-| Auto-wired bridges | `llm` + `memory` + `memory_write` (LocalModel + MemoryStore exposed via bridge connectors) | n/a (these ARE the substrates being bridged) |
+| Auto-wired bridges | `llm` + `memory` + `data_write` (LocalModel + DataStore exposed via bridge connectors) | n/a (these ARE the substrates being bridged) |
 
 McpConnector is fundamentally the "dispatch to external tools" surface — narrowest contract, broadest range of impls.
 

package/examples/connectors/README.md

@@ -7,9 +7,9 @@ Worked examples + fork-me templates for adopter-written connectors. The bundled
 | Contract | Bundled defaults | Worked example | Fork template |
 |---|---|---|---|
 | `SkillStore` | `FilesystemSkillStore`, `SqliteSkillStore` (in `src/connectors/`) | — | **[SkillStoreTemplate/](./SkillStoreTemplate/)** |
-| `MemoryStore` | `SqliteMemoryStore` (in `src/connectors/`) | — | **[MemoryStoreTemplate/](./MemoryStoreTemplate/)** |
+| `DataStore` | `SqliteDataStore` (in `src/connectors/`) | — | **[DataStoreTemplate/](./DataStoreTemplate/)** |
 | `LocalModel` | `OllamaLocalModel` (in `src/connectors/`; opt-in via substrate config) | — | **[LocalModelTemplate/](./LocalModelTemplate/)** |
-| `McpConnector` | `RemoteMcpConnector`, `CallbackMcpConnector`, `LocalModelMcpConnector`, `MemoryStoreMcpConnector` (in `src/connectors/`) | — | **[McpConnectorTemplate/](./McpConnectorTemplate/)** |
+| `McpConnector` | `RemoteMcpConnector`, `CallbackMcpConnector`, `LocalModelMcpConnector`, `DataStoreMcpConnector` (in `src/connectors/`) | — | **[McpConnectorTemplate/](./McpConnectorTemplate/)** |
 | `AgentConnector` | `NoOpAgentConnector` (in `src/connectors/`) | **[HttpWebhookAgentConnector/](./HttpWebhookAgentConnector/)** | — |
 
 **Bundled defaults** are runnable out of the box — wired through `connectors.json` substrate config or programmatic bootstrap.
@@ -35,7 +35,7 @@ Worked examples + fork-me templates for adopter-written connectors. The bundled
 - **[`docs/configuration.md`](../../docs/configuration.md)** — substrate selection via `connectors.json`; programmatic-bootstrap vs declarative patterns
 - **[`docs/adopter-playbook.md`](../../docs/adopter-playbook.md)** — Case 1 vs Case 2 wiring decisions; two-instance posture; upstream-merge-friendly conventions
 - **[`docs/connector-contract-reference.md`](../../docs/connector-contract-reference.md)** — interface contracts for adopter agents writing connector impls
-- **`src/connectors/types.ts`** — authoritative contract interfaces (SkillStore, MemoryStore, LocalModel, McpConnector)
+- **`src/connectors/types.ts`** — authoritative contract interfaces (SkillStore, DataStore, LocalModel, McpConnector)
 - **`src/testing/conformance.ts`** — the per-contract conformance test suites
 
 ## Naming convention

package/examples/connectors/SkillStoreTemplate/README.md

@@ -5,7 +5,7 @@ A skeleton `SkillStore` implementation for adopters writing their own. Not runna
 Use this when you want skillscript skills backed by:
 - A database the bundled impls don't cover (Postgres, MySQL, MongoDB, etc.)
 - A vector store (Pinecone, Weaviate, Qdrant)
-- A memory system (AMP, hosted memory API)
+- A data store backing (memory broker like AMP, hosted memory API, vector DB, etc.)
 - An HTTP CRUD service
 - Anything else with a query/write interface
 

package/examples/connectors/SkillStoreTemplate/SkillStoreTemplate.ts

@@ -138,7 +138,7 @@ export class SkillStoreTemplate implements SkillStore {
   // eslint-disable-next-line @typescript-eslint/no-unused-vars
   async versions(_name: string): Promise<VersionInfo[]> {
     // TODO — return version chain. SQL substrates: SELECT FROM skill_versions
-    // ORDER BY changed_at. MemoryStore-style: query memories with the right tag.
+    // ORDER BY changed_at. DataStore-style: query memories with the right tag.
     throw new Error("TODO: versions() — return VersionInfo[] chronologically.");
   }
 

package/examples/custom-bootstrap.example.ts

@@ -3,8 +3,8 @@
 //
 // **When to write your own bootstrap.** The bundled `bootstrap()` from
 // `skillscript-runtime` wires `FilesystemSkillStore` + `OllamaLocalModel` +
-// `SqliteMemoryStore` + the v0.7.2 bridges. If your deployment uses
-// different substrates (your own memory system, a hosted LLM API, an MCP
+// `SqliteDataStore` + the v0.7.2 bridges. If your deployment uses
+// different substrates (your own data store, a hosted LLM API, an MCP
 // server for agent delivery, etc.), write your own bootstrap rather than
 // modifying the bundled one. Prevents merge conflicts on every upstream
 // release that touches `src/bootstrap.ts`.
@@ -83,17 +83,17 @@ const registry = new Registry();
 const skillStore = new FilesystemSkillStore(config.skillsDir ?? `${HOME}/skills`);
 registry.registerSkillStore("primary", skillStore);
 
-// Wire your own LocalModel, MemoryStore, AgentConnector here. For typed-
+// Wire your own LocalModel, DataStore, AgentConnector here. For typed-
 // contract impls, this is the "case 1" wiring — substrate-portable.
 //   registry.registerLocalModel("default", new MyHostedLlmAdapter(...));
-//   registry.registerMemoryStore("primary", new MyMemoryAdapter(...));
+//   registry.registerDataStore("primary", new MyMemoryAdapter(...));
 //   registry.registerAgentConnector("primary", new MyAgentHarnessAdapter(...));
 
-// Then wire bridges if you want the canonical `$ llm` / `$ memory` surfaces:
-//   import { LocalModelMcpConnector, MemoryStoreMcpConnector } from "skillscript-runtime";
+// Then wire bridges if you want the canonical `$ llm` / `$ data_read` surfaces:
+//   import { LocalModelMcpConnector, DataStoreMcpConnector } from "skillscript-runtime";
 //   registry.registerMcpConnector("llm", new LocalModelMcpConnector(registry.getLocalModel("default")));
-//   const ms = registry.listMemoryStores().find((e) => e.name === "primary");
-//   if (ms !== undefined) registry.registerMcpConnector("memory", new MemoryStoreMcpConnector(ms.instance));
+//   const ms = registry.listDataStores().find((e) => e.name === "primary");
+//   if (ms !== undefined) registry.registerMcpConnector("data_read", new DataStoreMcpConnector(ms.instance));
 
 // Wire any connectors.json instances.
 for (const c of connectors) {

package/examples/onboarding-scaffold/README.md

@@ -6,11 +6,11 @@ A complete adopter-deployment example demonstrating substrate-portable wiring fo
 
 Skillscript's substrate-portability story is conditional: **typed-contract wiring (Case 1)** keeps skills portable across substrates; **MCP-tools wiring (Case 2)** locks skills to a specific substrate. This scaffold is Case 1 end-to-end.
 
-- **MemoryStore** → `FileMemoryStore` (JSON file with simple substring FTS)
+- **DataStore** → `FileDataStore` (JSON file with simple substring FTS)
 - **LocalModel** → `OpenAILocalModel` (HTTP to Chat Completions API)
 - **AgentConnector** → `TmuxShellAgentConnector` (delivers to tmux sessions via `send-keys`)
 
-Each impl conforms to the typed contract from `skillscript-runtime/connectors`. Skills authored against this scaffold use the canonical `$ llm prompt=...` and `$ memory mode=fts query=...` surfaces — *the same calls would work against any other Case-1-wired substrate* (Pinecone, Ollama, Anthropic API, etc.).
+Each impl conforms to the typed contract from `skillscript-runtime/connectors`. Skills authored against this scaffold use the canonical `$ llm prompt=...` and `$ data_read mode=fts query=...` surfaces — *the same calls would work against any other Case-1-wired substrate* (Pinecone, Ollama, Anthropic API, etc.).
 
 ## Quick start
 
@@ -44,7 +44,7 @@ node --loader ts-node/esm bootstrap.ts
 
 | File | Purpose | LOC |
 |---|---|---|
-| `file-memory-store.ts` | `MemoryStore` impl — JSON file substrate | ~95 |
+| `file-data-store.ts` | `DataStore` impl — JSON file substrate | ~95 |
 | `openai-local-model.ts` | `LocalModel` impl — Chat Completions API | ~85 |
 | `tmux-shell-agent-connector.ts` | `AgentConnector` impl — tmux send-keys | ~75 |
 | `bootstrap.ts` | Wiring — Registry, bridges, scheduler, MCP server | ~75 |
@@ -53,7 +53,7 @@ node --loader ts-node/esm bootstrap.ts
 
 ## Two-instance posture
 
-To run this scaffold *alongside* an existing skillscript dev instance, just copy the scaffold to a separate directory with its own `skillscript.config.json` pointing at different `dashboard.port` + `skillsDir` + `memoryDbPath` etc. The `--config <path>` CLI flag selects which config to use; no two instances will collide on disk or port.
+To run this scaffold *alongside* an existing skillscript dev instance, just copy the scaffold to a separate directory with its own `skillscript.config.json` pointing at different `dashboard.port` + `skillsDir` + `dataDbPath` etc. The `--config <path>` CLI flag selects which config to use; no two instances will collide on disk or port.
 
 ```bash
 # dev instance on default port
@@ -67,14 +67,14 @@ skillfile dashboard --config ./adopter.config.json  # contains "dashboard": { "p
 
 For your real deployment, swap each adapter:
 
-- `FileMemoryStore` → your actual memory system (Pinecone, Postgres-pgvector, Obsidian-backed, your in-house store, etc.)
+- `FileDataStore` → your actual data store (Pinecone, Postgres-pgvector, Obsidian-backed, in-house store, memory broker, etc.)
 - `OpenAILocalModel` → your actual LLM (Ollama via the bundled `OllamaLocalModel`, Anthropic via your own adapter, hosted-OpenAI as shown, etc.)
 - `TmuxShellAgentConnector` → your actual agent delivery (webhook POST, named-pipe write, your harness's API, etc.)
 
-The skill bodies don't need to change. `$ llm prompt=...` keeps working; `$ memory mode=fts query=...` keeps working. That's the substrate-portability claim, validated by you wiring different substrates against the same typed contracts.
+The skill bodies don't need to change. `$ llm prompt=...` keeps working; `$ data_read mode=fts query=...` keeps working. That's the substrate-portability claim, validated by you wiring different substrates against the same typed contracts.
 
 ## Where to go next
 
 - **Adopter playbook** — `docs/adopter-playbook.md` walks through Case 1 vs Case 2 wiring patterns
 - **Custom bootstrap walkthrough** — `examples/custom-bootstrap.example.ts` shows registering custom McpConnector classes via `registerConnectorClass`
-- **v0.8.x roadmap** — `$ memory_write` ships in v0.8.x bundled with the auth model. When that lands, extend `FileMemoryStore` with the corresponding `write()` method.
+- **v0.8.x roadmap** — `$ data_write` ships in v0.8.x bundled with the auth model. When that lands, extend `FileDataStore` with the corresponding `write()` method.

package/examples/onboarding-scaffold/bootstrap.ts

@@ -4,8 +4,8 @@
 // Copy this file into your deployment and modify substrate choices to
 // match your environment. The shape is:
 //   1. Construct a Registry
-//   2. Register your substrate impls (SkillStore + LocalModel + MemoryStore + AgentConnector)
-//   3. Wire bridges so canonical `$ llm` / `$ memory` dispatch works
+//   2. Register your substrate impls (SkillStore + LocalModel + DataStore + AgentConnector)
+//   3. Wire bridges so canonical `$ llm` / `$ data_read` dispatch works
 //   4. Load connectors.json + skillscript.config.json
 //   5. Wire scheduler + MCP server
 //   6. Start
@@ -20,15 +20,15 @@ import {
 import { Scheduler } from "skillscript-runtime/scheduler";
 import { FilesystemTraceStore } from "skillscript-runtime/trace";
 import { McpServer } from "skillscript-runtime/mcp-server";
-// Note: LocalModelMcpConnector + MemoryStoreMcpConnector are bridge classes
+// Note: LocalModelMcpConnector + DataStoreMcpConnector are bridge classes
 // already exported from skillscript-runtime/connectors. They wrap any
 // typed-contract impl as an MCP-dispatchable connector.
 import {
   LocalModelMcpConnector,
-  MemoryStoreMcpConnector,
+  DataStoreMcpConnector,
 } from "skillscript-runtime/connectors";
 
-import { FileMemoryStore } from "./file-memory-store.js";
+import { FileDataStore } from "./file-data-store.js";
 import { OpenAILocalModel } from "./openai-local-model.js";
 import { TmuxShellAgentConnector } from "./tmux-shell-agent-connector.js";
 
@@ -44,10 +44,10 @@ const skillStore = new FilesystemSkillStore(config.skillsDir ?? `${HOME}/skills`
 registry.registerSkillStore("primary", skillStore);
 
 // File-backed memory at $SKILLSCRIPT_HOME/memory.json
-const memoryStore = new FileMemoryStore({
-  filePath: config.memoryDbPath ?? `${HOME}/memory.json`,
+const dataStore = new FileDataStore({
+  filePath: config.dataDbPath ?? `${HOME}/memory.json`,
 });
-registry.registerMemoryStore("primary", memoryStore);
+registry.registerDataStore("primary", dataStore);
 
 // OpenAI LLM — reads OPENAI_API_KEY from env.
 const openai = new OpenAILocalModel({ defaultModel: "gpt-4o-mini" });
@@ -63,10 +63,10 @@ const agentConnector = new TmuxShellAgentConnector({
 });
 registry.registerAgentConnector("primary", agentConnector);
 
-// Step 3: wire bridges so `$ llm` / `$ memory` dispatch through the
+// Step 3: wire bridges so `$ llm` / `$ data_read` dispatch through the
 // adopter substrates above (case 1 typed-contract wiring — portable).
 registry.registerMcpConnector("llm", new LocalModelMcpConnector(openai));
-registry.registerMcpConnector("memory", new MemoryStoreMcpConnector(memoryStore));
+registry.registerMcpConnector("data_read", new DataStoreMcpConnector(dataStore));
 
 // Step 4: wire connectors.json instances (adopter-defined MCP servers).
 for (const c of connectors) {