skillscript-runtime 0.13.8 → 0.14.0

package/docs/adopter-playbook.md

@@ -1,6 +1,6 @@
 # Adopter playbook
 
-How to wire skillscript-runtime into your deployment. Written for Joe-Programmer: you have your own substrate stack (memory system, agent harness, LLM endpoint, filesystem), and you want skillscript to slot in rather than dictate.
+How to wire skillscript-runtime into your deployment. Written for Joe-Programmer: you have your own substrate stack (data store, agent harness, LLM endpoint, filesystem), and you want skillscript to slot in rather than dictate.
 
 This playbook covers the load-bearing decisions, the two wiring patterns, and the conventions that keep your local modifications upstream-merge-friendly.
 
@@ -9,11 +9,11 @@ This playbook covers the load-bearing decisions, the two wiring patterns, and th
 Skillscript-runtime is substrate-neutral and assumes you have (or will choose):
 
 1. **A filesystem** — for skill source files (`.skill.md`), trace records, possibly a memory database. Sandbox via container, chroot, or limited-privilege process — operator's call.
-2. **A memory system** — for knowledge retrieval and memory writes. Could be SQLite-FTS (bundled), a vector database, an in-house store, an Obsidian-style notes system — whatever you already have.
+2. **A data store** — for knowledge retrieval and data writes. Could be SQLite-FTS (bundled), a vector database, an in-house store, an Obsidian-style notes system, a memory broker — whatever you already have.
 3. **An LLM endpoint** — Ollama running locally (bundled), a hosted API like OpenAI / Anthropic / Azure, or your own inference server.
 4. **An agent harness** — where skill output is delivered. Could be tmux sessions, a webhook receiver, an in-house agent runtime, or no harness at all (skills run for their text output only).
 
-Each of these maps to a typed connector contract: `SkillStore`, `MemoryStore`, `LocalModel`, `AgentConnector`. Plus `McpConnector` for any external tool you want to invoke from a skill body.
+Each of these maps to a typed connector contract: `SkillStore`, `DataStore`, `LocalModel`, `AgentConnector`. Plus `McpConnector` for any external tool you want to invoke from a skill body.
 
 ## Case 1 vs Case 2 — the load-bearing wiring decision
 
@@ -21,21 +21,21 @@ This is the most important architectural choice you'll make.
 
 ### Case 1 — typed-contract wiring (substrate-portable)
 
-You implement the typed connector contracts (`MemoryStore`, `LocalModel`, etc.) against your substrate. The bridge classes (`MemoryStoreMcpConnector`, `LocalModelMcpConnector`) surface them as canonical `$ memory` / `$ llm` dispatch.
+You implement the typed connector contracts (`DataStore`, `LocalModel`, etc.) against your substrate. The bridge classes (`DataStoreMcpConnector`, `LocalModelMcpConnector`) surface them as canonical `$ data_read` / `$ llm` dispatch.
 
 ```typescript
-class MyMemoryStore implements MemoryStore {
-  async query(filters: QueryFilters): Promise<PortableMemory[]> { /* ... */ }
+class MyDataStore implements DataStore {
+  async query(filters: QueryFilters): Promise<PortableData[]> { /* ... */ }
   async manifest(): Promise<ManifestInfo> { /* ... */ }
 }
 
-registry.registerMemoryStore("primary", new MyMemoryStore());
-registry.registerMcpConnector("memory", new MemoryStoreMcpConnector(new MyMemoryStore()));
+registry.registerDataStore("primary", new MyDataStore());
+registry.registerMcpConnector("data_read", new DataStoreMcpConnector(new MyDataStore()));
 ```
 
 **In skills:**
 ```
-$ memory mode=fts query="customer feedback" limit=10 -> CONTEXT
+$ data_read mode=fts query="customer feedback" limit=10 -> CONTEXT
 ```
 
 This same skill body runs unchanged against your substrate, against SQLite-FTS (bundled), against Pinecone, against any substrate that conforms to the typed contract. **Skills are portable.**
@@ -100,7 +100,7 @@ Create `skillscript.config.json` in your `$SKILLSCRIPT_HOME`:
 {
   "skillsDir": "${SKILLSCRIPT_HOME}/skills",
   "traceDir": "${SKILLSCRIPT_HOME}/traces",
-  "memoryDbPath": "${SKILLSCRIPT_HOME}/memory.json",
+  "dataDbPath": "${SKILLSCRIPT_HOME}/memory.json",
   "dashboard": { "port": 7878 }
 }
 ```
@@ -154,7 +154,7 @@ src/connectors/local/my-memory-adapter.ts    ← adopter-owned
 src/connectors/local/my-llm-adapter.ts       ← adopter-owned
 ```
 
-Upstream changes to `src/connectors/memory-store.ts` won't conflict with your `local/` files.
+Upstream changes to `src/connectors/data-store.ts` won't conflict with your `local/` files.
 
 ### 2. Use the public registration API; don't edit the closed-set Map
 
@@ -182,17 +182,17 @@ See `examples/custom-bootstrap.example.ts` for a worked walkthrough.
 | Substrate | Shipped contract | Shipped impls | Shipped bridge |
 |---|---|---|---|
 | SkillStore | ✓ `load`/`query`/`store`/`update_status`/`delete`/`versions`/`metadata`/`staticCapabilities` | `FilesystemSkillStore`, `SqliteSkillStore` | n/a |
-| MemoryStore | ✓ `query`/`write` | `SqliteMemoryStore` | ✓ `MemoryStoreMcpConnector` |
+| DataStore | ✓ `query`/`write` | `SqliteDataStore` | ✓ `DataStoreMcpConnector` |
 | LocalModel | ✓ `run` | `OllamaLocalModel` | ✓ `LocalModelMcpConnector` |
 | McpConnector | ✓ `call` | `RemoteMcpConnector`, `CallbackMcpConnector` | n/a |
 | AgentConnector | ✓ `list_agents`/`deliver`/`wake`/`health_check`/`request_response`; optional `agent_status` | `NoOpAgentConnector` (default), `HttpWebhookAgentConnector` | n/a |
 
 **Notable gaps the playbook should be honest about:**
 
-- **`SqliteMemoryStore` is a deliberately minimal reference impl.** It satisfies the contract (`query` / `write` / `get` / `staticCapabilities` / `manifest`) and exposes `supports_writes` + `supports_tag_filter` as true. It does NOT support semantic retrieval, pinning, decay scoring, or thread-status filtering (`supports_semantic` / `supports_pinning` / `supports_decay_model` / `supports_thread_status_filter` are all false). The bundled impl exists so the runtime works out-of-box for FTS-style tag/text retrieval. Deployments that need richer memory semantics fork `examples/connectors/MemoryStoreTemplate/` and wire their backing system (memory broker, vector DB, AMP, etc.). Check `manifest()` at runtime to confirm what your wired MemoryStore actually supports.
-- **SkillStore and MemoryStore have different lifecycle models — by design.** SkillStore is mutable / versioned / named CRUD (Draft→Approved→Disabled→Delete with audit trail; specific named artifacts). MemoryStore is an append-only search log (write → query/get; no per-record lifecycle beyond TTL/decay if substrate has one). Backing both onto one substrate (per [[project_memorystore_holds_skills]] — skill payloads ride as `payload_type: "skill"` memories) means serving both lifecycle models at once. The contract doesn't state the asymmetry as a design stance, but it's load-bearing: substrates that conflate "memory expiry" with "skill expiry" silently break authored code. Phase 3 cold-adopter dogfood surfaced this — AMP's 7-day TTL on `knowledge_type: common` memories would have decayed skills if AmpSkillStore had defaulted to `common`. Adopter mitigation: pick a `knowledge_type` your substrate treats as durable (e.g., `hard_won` in AMP), or wrap the SkillStore with a re-pin sweep.
-- **Durability is implementer's responsibility.** The typed SkillStore and MemoryStore contracts assume durable storage. Neither interface declares "writes live forever" — but the runtime + lint + dashboard all behave as if writes persist indefinitely. Substrate backends with their own GC / TTL / decay scoring surprise the skillscript layer invisibly. **If your substrate has these behaviors, build adopter-side guards** (pin-rules, retention policies, periodic re-pin sweeps) OR pick a substrate posture that satisfies "durable forever." The contract doesn't enforce — silent staleness is the failure mode. See `docs/connector-contract-reference.md` § "Storage-layer conventions" for the full discussion.
-- **Filter scope is advisory today; v0.14.0 will make it enforceable.** `query(filters)` accepts arbitrary fields; substrates honor what they support and silently drop the rest. For non-scope-sensitive filters (`tag`, `since`) this is fine. For scope/visibility/security-relevant filters (any future `vault` filter, tenant-id, access-control) the silent-drop is a leak waiting to happen. Until v0.14.0's `strict_filters: true`, enforce scope-relevant filters *above* the contract — adopter wraps the SkillStore/MemoryStore with a guard that asserts the substrate honors the filter, or the wrapping layer applies the filter in-memory after the substrate returns. Banked meta-pattern ([[feedback_defaults_over_knobs_security]]): defaults that protect by default > knobs that adopters opt into for security-relevant surfaces; aware adopters opt out, naive adopters get protection.
+- **`SqliteDataStore` is a deliberately minimal reference impl.** It satisfies the contract (`query` / `write` / `get` / `staticCapabilities` / `manifest`) and exposes `supports_writes` + `supports_tag_filter` as true. It does NOT support semantic retrieval, pinning, decay scoring, or thread-status filtering (`supports_semantic` / `supports_pinning` / `supports_decay_model` / `supports_thread_status_filter` are all false). The bundled impl exists so the runtime works out-of-box for FTS-style tag/text retrieval. Deployments that need richer query semantics fork `examples/connectors/DataStoreTemplate/` and wire their backing system (memory broker, vector DB, AMP, etc.). Check `manifest()` at runtime to confirm what your wired DataStore actually supports.
+- **SkillStore and DataStore have different lifecycle models — by design.** SkillStore is mutable / versioned / named CRUD (Draft→Approved→Disabled→Delete with audit trail; specific named artifacts). DataStore is an append-only search log (write → query/get; no per-record lifecycle beyond TTL/decay if substrate has one). Backing both onto one substrate (per [[project_memorystore_holds_skills]] — skill payloads ride as `payload_type: "skill"` memories) means serving both lifecycle models at once. The contract doesn't state the asymmetry as a design stance, but it's load-bearing: substrates that conflate "memory expiry" with "skill expiry" silently break authored code. Phase 3 cold-adopter dogfood surfaced this — AMP's 7-day TTL on `knowledge_type: common` memories would have decayed skills if AmpSkillStore had defaulted to `common`. Adopter mitigation: pick a `knowledge_type` your substrate treats as durable (e.g., `hard_won` in AMP), or wrap the SkillStore with a re-pin sweep.
+- **Durability is implementer's responsibility.** The typed SkillStore and DataStore contracts assume durable storage. Neither interface declares "writes live forever" — but the runtime + lint + dashboard all behave as if writes persist indefinitely. Substrate backends with their own GC / TTL / decay scoring surprise the skillscript layer invisibly. **If your substrate has these behaviors, build adopter-side guards** (pin-rules, retention policies, periodic re-pin sweeps) OR pick a substrate posture that satisfies "durable forever." The contract doesn't enforce — silent staleness is the failure mode. See `docs/connector-contract-reference.md` § "Storage-layer conventions" for the full discussion.
+- **Filter scope is advisory today; v0.14.0 will make it enforceable.** `query(filters)` accepts arbitrary fields; substrates honor what they support and silently drop the rest. For non-scope-sensitive filters (`tag`, `since`) this is fine. For scope/visibility/security-relevant filters (any future `vault` filter, tenant-id, access-control) the silent-drop is a leak waiting to happen. Until v0.14.0's `strict_filters: true`, enforce scope-relevant filters *above* the contract — adopter wraps the SkillStore/DataStore with a guard that asserts the substrate honors the filter, or the wrapping layer applies the filter in-memory after the substrate returns. Banked meta-pattern ([[feedback_defaults_over_knobs_security]]): defaults that protect by default > knobs that adopters opt into for security-relevant surfaces; aware adopters opt out, naive adopters get protection.
 - **4 of 6 trigger sources parse but don't fire.** `cron` and `session: start` work; `event`, `agent-event`, `file-watch`, `sensor` are parser-only stubs awaiting the event-bus surface.
 - **Output kinds are intentionally substrate-neutral.** `# Output:` accepts `text` / `agent: <name>` / `template: <name>` / `file: <path>` / `none`. Substrate-specific values (`slack:`, `card:`, etc.) are deliberately out of scope — adopters wanting Slack / WhatsApp / Discord / etc. delivery use either `$ slack.post ...` MCP dispatch inside the skill body OR deliver via `agent: <name>` and let the receiving agent decide.
 - **Authorization is hash-token approval.** Skills must carry `# Status: Approved vN:<token>` where the token re-computes from the body minus its `# Status:` line. Bundled `v1:` is CRC32 — discipline-barrier strength, suited to single-operator deployments. Adversarial threat models swap a stronger function:
@@ -212,10 +212,10 @@ See `examples/custom-bootstrap.example.ts` for a worked walkthrough.
 
 ## Skill discovery + cross-agent composition
 
-Under Case-1 wiring against a memory substrate that holds skill payloads (e.g., AMP's payload_type model where compiled `.skill.md` artifacts live alongside thread / prose / document entries), skill discovery uses the canonical `$ memory` surface:
+Under Case-1 wiring against a memory substrate that holds skill payloads (e.g., AMP's payload_type model where compiled `.skill.md` artifacts live alongside thread / prose / document entries), skill discovery uses the canonical `$ data_read` surface:
 
 ```
-$ memory mode=fts query="incident triage" limit=5 -> SKILLS
+$ data_read mode=fts query="incident triage" limit=5 -> SKILLS
 foreach S in ${SKILLS.items}:
     execute_skill(skill_name="${S.name}", ...) -> RESULT
 ```

package/docs/configuration.md

@@ -4,7 +4,7 @@ How to configure a skillscript-runtime deployment.
 
 The single config file is **`~/.skillscript/connectors.json`** (or any path passed via `--connectors`). It has two top-level concerns:
 
-1. **`substrate`** — which `SkillStore`, `MemoryStore`, and `LocalModel` the runtime hosts (MCP server + web dashboard) use.
+1. **`substrate`** — which `SkillStore`, `DataStore`, and `LocalModel` the runtime hosts (MCP server + web dashboard) use.
 2. **Named MCP connector instances** — `youtrack`, `github`, etc. — invoked via `$ <name>` in skill source.
 
 The runtime loads `connectors.json` at startup. Missing file → graceful empty config (substrate defaults to filesystem skills + conditional sqlite memories; no MCP connectors). Malformed JSON or unknown fields → structured errors surfaced at bootstrap.
@@ -22,7 +22,7 @@ Every default path the runtime computes is rooted under `SKILLSCRIPT_HOME`:
 | Triggers file | `$SKILLSCRIPT_HOME/triggers.json` |
 | Skills directory (`skillsDir`) | `$SKILLSCRIPT_HOME/skills/` |
 | Sqlite skill store dbPath | `$SKILLSCRIPT_HOME/skills/skills.db` |
-| Sqlite memory store dbPath | `$SKILLSCRIPT_HOME/memory.db` |
+| Sqlite data store dbPath | `$SKILLSCRIPT_HOME/data.db` |
 | Trace directory | `$SKILLSCRIPT_HOME/traces/` |
 
 `SKILLSCRIPT_HOME` defaults to `~/.skillscript`. Set the env var to relocate **everything** under a different root — the cleanest multi-instance isolation primitive:
@@ -47,7 +47,7 @@ A typical out-of-the-box `~/.skillscript/connectors.json`:
 {
   "substrate": {
     "skill_store": "filesystem",
-    "memory_store": "sqlite",
+    "data_store": "sqlite",
     "local_model": null
   }
 }
@@ -88,7 +88,7 @@ Valid short-form values per slot:
 | Slot | Values |
 |---|---|
 | `skill_store` | `"filesystem"` \| `"sqlite"` |
-| `memory_store` | `"sqlite"` |
+| `data_store` | `"sqlite"` |
 | `local_model` | (none — `"ollama"` requires the object form with `defaultModelTag`; see below) |
 
 ### Null — explicit "no substrate"
@@ -116,10 +116,10 @@ The runtime doesn't register a connector for this slot. Useful for explicitly di
 |---|---|
 | `filesystem` (skill_store) | none — uses the CLI's `skillsDir` (defaults to `$SKILLSCRIPT_HOME/skills/`) |
 | `sqlite` (skill_store) | `dbPath` (default: `$SKILLSCRIPT_HOME/skills/skills.db`) |
-| `sqlite` (memory_store) | `dbPath` (default: `$SKILLSCRIPT_HOME/memory.db`; `MEMORY_DB` env overrides) |
+| `sqlite` (data_store) | `dbPath` (default: `$SKILLSCRIPT_HOME/data.db`; `DATA_DB` env overrides) |
 | `ollama` (local_model) | `baseUrl` (default: `OLLAMA_BASE_URL` env or `http://localhost:11434`), **`defaultModelTag` (required — e.g., `"gemma2:9b"`, `"llama3.1:8b"`)** |
 
-> **`SqliteMemoryStore` feature surface.** The bundled `sqlite` memory_store is a deliberately minimal reference implementation: `supports_writes` + `supports_tag_filter` are true; `supports_semantic`, `supports_pinning`, `supports_decay_model`, `supports_thread_status_filter` are all false. Rich features (semantic retrieval, pinning, decay scoring, thread-status workflow) come from substrate impls — adopters fork `examples/connectors/MemoryStoreTemplate/` and wire their backing system (memory broker, vector DB, AMP, etc.). The bundled impl exists so the runtime works out-of-box; adopters with richer memory substrates write their own.
+> **`SqliteDataStore` feature surface.** The bundled `sqlite` data_store is a deliberately minimal reference implementation: `supports_writes` + `supports_tag_filter` are true; `supports_semantic`, `supports_pinning`, `supports_decay_model`, `supports_thread_status_filter` are all false. Rich features (semantic retrieval, pinning, decay scoring, thread-status workflow) come from substrate impls — adopters fork `examples/connectors/DataStoreTemplate/` and wire their backing system (memory broker, vector DB, AMP, etc.). The bundled impl exists so the runtime works out-of-box; adopters with richer query semantics write their own.
 
 Worked Ollama example (because the short form isn't valid for `local_model`):
 
@@ -163,7 +163,7 @@ When multiple config sources speak:
 
 1. **Programmatic opts** (`opts.skillStore` passed to `bootstrap()`) — explicit, highest priority
 2. **`connectors.json` substrate section** — declarative, deployment-durable
-3. **Built-in default** — fallback (filesystem skill_store; conditional sqlite memory_store; no local_model)
+3. **Built-in default** — fallback (filesystem skill_store; conditional sqlite data_store; no local_model)
 
 If two configs disagree, the higher-priority one wins; lower-priority is ignored without error.
 
@@ -256,7 +256,7 @@ Underscore-prefixed top-level keys (`_comment`, `_note_security`, etc.) are igno
 
 ## Adopter-custom substrate impls
 
-Write `class FooSkillStore implements SkillStore { ... }` (or MemoryStore, LocalModel). Wire it via either:
+Write `class FooSkillStore implements SkillStore { ... }` (or DataStore, LocalModel). Wire it via either:
 
 **(a) Programmatic bootstrap (recommended today)** — write your own bootstrap script that constructs the registry directly:
 

package/docs/connector-contract-reference.md

@@ -4,7 +4,7 @@ The substrate-neutral contracts skillscript-runtime exposes for adopters to wire
 
 **Audience**: this doc is written for the agent that's implementing an adopter's AgentConnector — typically an LLM-class agent supervised by a human. If you're a human reading it directly, the same content applies; the prose is tightened for agent comprehension (literal field semantics, explicit precedence rules, worked examples).
 
-Other contracts (McpConnector, SkillStore, MemoryStore, LocalModel) audit + lock in subsequent v0.9.x slots; this doc grows with each lock.
+Other contracts (McpConnector, SkillStore, DataStore, LocalModel) audit + lock in subsequent v0.9.x slots; this doc grows with each lock.
 
 ---
 
@@ -161,9 +161,9 @@ These are the load-bearing semantic rules. Internalize before implementing.
 
 ---
 
-## Storage-layer conventions (SkillStore + MemoryStore)
+## Storage-layer conventions (SkillStore + DataStore)
 
-The cold-adopter Phase 3 dogfood (writing AmpSkillStore + AmpMemoryStore against AMP) surfaced several conventions that live in the bundled reference impls but aren't first-class in the typed contracts. Adopters writing their own SkillStore/MemoryStore impls need to know about these, or skills/memories misbehave silently.
+The cold-adopter Phase 3 dogfood (writing AmpSkillStore + AmpDataStore against AMP) surfaced several conventions that live in the bundled reference impls but aren't first-class in the typed contracts. Adopters writing their own SkillStore/DataStore impls need to know about these, or skills/memories misbehave silently.
 
 ### SkillStore conventions
 
@@ -173,18 +173,18 @@ The cold-adopter Phase 3 dogfood (writing AmpSkillStore + AmpMemoryStore against
 
 **`store()` auto-stamps the approval token.** When a caller writes a skill with `# Status: Approved` (no `vN:<token>`), the store MUST stamp the v1 CRC32 (or whatever version is currently `setPreferredApprovalVersion`'d) onto the body before persisting. Otherwise the skill is non-executable — the approval gate refuses bodies without a valid token. This is a **runtime-semantic concern that leaked into the storage layer**: ideally the runtime would stamp at execute-time, but for forward-compat reasons the convention is store-side stamping. See `src/approval.ts` and the v0.9.x hash-token auth thread.
 
-### MemoryStore conventions
+### DataStore conventions
 
-**`summary`/`detail` split is convention, not contract field.** The MemoryStore contract gives `write()` a single `content: string`. Bundled `SqliteMemoryStore` maps this to `summary = first line (≤200 chars)` and `detail = full content`. Adopter substrates with native summary/detail concepts (AMP's `summary` + `detail` columns) can pre-compose and pass via `metadata`, but the basic mapping convention is "first line is the preview." Diverge and the dashboard's memory rendering looks weird, but skills still work.
+**`summary`/`detail` split is convention, not contract field.** The DataStore contract gives `write()` a single `content: string`. Bundled `SqliteDataStore` maps this to `summary = first line (≤200 chars)` and `detail = full content`. Adopter substrates with native summary/detail concepts (AMP's `summary` + `detail` columns) can pre-compose and pass via `metadata`, but the basic mapping convention is "first line is the preview." Diverge and the dashboard's memory rendering looks weird, but skills still work.
 
-**`get(id)` returns null on miss, doesn't throw.** Distinct from SkillStore's `load(name)` which throws `SkillNotFoundError`. MemoryStore's empty-set convention (`query()` returns `[]` not throws; `get()` returns `null` not throws) is **load-bearing for the runtime's control flow** — query callers branch on `result.length`, get callers branch on `result === null`. Don't change this in your impl. Per cold agent's "credit where due": *"unambiguous, and the runtime keys control flow on the specific classes."*
+**`get(id)` returns null on miss, doesn't throw.** Distinct from SkillStore's `load(name)` which throws `SkillNotFoundError`. DataStore's empty-set convention (`query()` returns `[]` not throws; `get()` returns `null` not throws) is **load-bearing for the runtime's control flow** — query callers branch on `result.length`, get callers branch on `result === null`. Don't change this in your impl. Per cold agent's "credit where due": *"unambiguous, and the runtime keys control flow on the specific classes."*
 
 ### Durability stance (both contracts)
 
-**The typed contracts assume durable storage.** Neither SkillStore nor MemoryStore declare "writes live forever" anywhere in the interface — but the runtime + lint + dashboard all behave as if writes persist indefinitely. Substrate backends with their own GC / TTL / decay scoring surprise the skillscript layer invisibly:
+**The typed contracts assume durable storage.** Neither SkillStore nor DataStore declare "writes live forever" anywhere in the interface — but the runtime + lint + dashboard all behave as if writes persist indefinitely. Substrate backends with their own GC / TTL / decay scoring surprise the skillscript layer invisibly:
 
 - A skill written to a substrate that auto-expires after N days disappears from `skill_list` without warning
-- A memory written with an implicit TTL gets pruned, breaking later `$ memory query` references
+- A memory written with an implicit TTL gets pruned, breaking later `$ data_read query` references
 - A substrate that pin-deletes stale content silently invalidates persisted skill references
 
 Implementer responsibility: either pick a substrate posture that satisfies "durable forever," or build adopter-side guards (e.g., pin-rules, retention policies, periodic re-pin sweeps) that maintain the assumption. The contract doesn't enforce — silent staleness is the failure mode.
@@ -193,7 +193,7 @@ Implementer responsibility: either pick a substrate posture that satisfies "dura
 
 **Filters are advisory at the contract layer (v0.13.x and earlier).** `query(filters)` accepts arbitrary fields via the `[key: string]: unknown` extension; substrates honor what they support and silently drop the rest. For non-scope-sensitive filters (`tag`, `since`) this is fine. For **scope/visibility/security-relevant filters** (any future `vault` filter, tenant-id, access-control) — the silent-drop is a leak waiting to happen.
 
-Today's discipline: enforce scope-relevant filters *above* the contract — adopter wraps the SkillStore/MemoryStore with a guard that asserts the substrate honors the filter, or the wrapping layer applies the filter in-memory after the substrate returns.
+Today's discipline: enforce scope-relevant filters *above* the contract — adopter wraps the SkillStore/DataStore with a guard that asserts the substrate honors the filter, or the wrapping layer applies the filter in-memory after the substrate returns.
 
 v0.14.0 plans `strict_filters: true` at the contract layer so the substrate must surface unsupported-filter use via `UnsupportedFilterError`. Until then, adopter-side enforcement is the only option.
 

package/docs/language-reference.md

@@ -4,9 +4,6 @@ Canonical language reference for skillscript. Audience: skill authors (human + a
 
 Implementation state is cross-referenced to commit hashes; pending items mark v2/v3 work.
 
-Companion docs under the Skillscript project anchor:
-- `skillscript-prd` — product positioning, value prop, roadmap
-- `skillscript-erd` — engineering requirements, system architecture, runtime mechanics
 
 ## Not yet implemented, but planned
 
@@ -103,7 +100,7 @@ Skillscript is a constrained domain-specific language for authoring agent workfl
 Every skill follows the same shape:
 
 1. **Trigger** — what fires the skill: cron, command, session-start, agent-event, file-watch, webhook, etc.
-2. **Process** — pull data (MCP / memory / file), classify or compose via sub-LLM + iteration, build the deliverable.
+2. **Process** — pull data (MCP / data store / file), classify or compose via sub-LLM + iteration, build the deliverable.
 3. **Deliver** — emit the result via one or more delivery channels (see below).
 
 Skillscript's job is to express this pipeline declaratively. When there is an agent above the skill, the agent's job is to act on the delivered artifact. When there isn't (autonomous fires), the delivery channel IS the outcome.
@@ -128,9 +125,9 @@ A skill delivers its work via one or more of three channels. Delivery channel is
 |---|---|---|
 | **Augmenting (context to agent)** | `emit(text="...")` + `# Output: agent: <name>` | Skill output is augment-kind payload for the receiving agent's next turn; joined emit stream becomes the delivered context. Pattern: agent-augmenting skills (briefing skills, session-start prepared context). |
 | **Template (playbook to agent)** | `emit(text="...")` + `# Output: template: <name>` | Skill output is a template-kind payload (recipe/playbook) the receiving agent executes. Pattern: instructional skills, reusable recipes. |
-| **Memory handoff** | `$ memory_write content="..." recipients=[<agent>] -> R` | Skill writes a memory the target agent picks up via mailbox at next session. Pattern: async carrier skills, autonomous fires that hand off to a future session. |
+| **Data handoff** | `$ data_write content="..." recipients=[<agent>] -> R` | Skill writes data the target agent picks up via mailbox at next session. Pattern: async carrier skills, autonomous fires that hand off to a future session. |
 
-A single skill can use any combination. An autonomous cron-fired sweep might write a memory to one agent AND emit augment-kind context to another. The combinations are unconstrained — the per-op gating model governs which mutating ops are authorized, not which channels a skill uses.
+A single skill can use any combination. An autonomous cron-fired sweep might write data to one agent AND emit augment-kind context to another. The combinations are unconstrained — the per-op gating model governs which mutating ops are authorized, not which channels a skill uses.
 
 ## Three op classes
 
@@ -148,19 +145,19 @@ Full op catalog and per-op semantics in Ops Reference.
 
 ## Substrate portability
 
-The language doesn't privilege any backend. `$ llm`, `$ memory`, `$ ticketing_search` are not language built-ins — they're connector names resolved at runtime through the registered MCP connector instances. The same skill source runs against any conforming substrate.
+The language doesn't privilege any backend. `$ llm`, `$ data_read`, `$ ticketing_search` are not language built-ins — they're connector names resolved at runtime through the registered MCP connector instances. The same skill source runs against any conforming substrate.
 
 The runtime ships bundled bridges for two common patterns:
 
 - `$ llm` routes through whichever LocalModel is wired (via `substrate.local_model` in `connectors.json`)
-- `$ memory` / `$ memory_write` route through whichever MemoryStore is wired (via `substrate.memory_store`)
+- `$ data_read` / `$ data_write` route through whichever DataStore is wired (via `substrate.data_store`)
 
 Adopters wire OpenAI instead of Ollama, Pinecone instead of SQLite, etc. Configuration lives outside the skill body; the language remains agnostic.
 
 | Connector slot | Adopter A wires | Adopter B wires |
 |---|---|---|
 | `llm` | LocalModel: Ollama (default) | LocalModel: OpenAI |
-| `memory` / `memory_write` | MemoryStore: SqliteMemoryStore (default) | MemoryStore: Pinecone |
+| `data_read` / `data_write` | DataStore: SqliteDataStore (default) | DataStore: Pinecone |
 | `ticketing_search` | YouTrack MCP | Jira MCP |
 
 Substrate config syntax + the three-form configuration shape lives in the adopter playbook, not in this reference. Skill authors don't typically need to touch it — they author against the canonical `$ tool` surfaces and adopters wire whatever's underneath.
@@ -201,7 +198,7 @@ The joined `emit()` stream becomes the augment-kind payload delivered to the on-
 2. **Targets** — named blocks of typed ops, optionally with `needs:` dependencies
 3. **`default:`** — names the goal target the runtime walks toward
 
-Other delivery channels for the same shape: swap `# Output: agent: oncall` + the `emit()` calls for `$ memory_write content="..." recipients=["oncall"] approved="cron-fired" -> R` (one summary memory handoff per fire) or `file_write(path="/var/log/showstoppers-${EVENT.fired_at_unix}.md", content="...", approved="cron-fired")` (one file deliverable per fire).
+Other delivery channels for the same shape: swap `# Output: agent: oncall` + the `emit()` calls for `$ data_write content="..." recipients=["oncall"] approved="cron-fired" -> R` (one summary data handoff per fire) or `file_write(path="/var/log/showstoppers-${EVENT.fired_at_unix}.md", content="...", approved="cron-fired")` (one file deliverable per fire).
 
 ## Lexical conventions
 
@@ -476,14 +473,14 @@ Both forms are first-class. Neither is canonical; choose by what makes the call
 ```
 $ ticketing_search query="project:INFRA" -> R
 $ llm prompt="${INPUT}" -> V
-$ memory mode=fts query="..." limit=5 -> M
+$ data_read mode=fts query="..." limit=5 -> M
 ```
 
 **Dotted-prefix dispatch** is the explicit-routing escape hatch — useful when multiple connectors expose tools with overlapping names, or when an adopter wants the connector identity visible at the call site for audit clarity:
 
 ```
 $ ticketing.search query="project:INFRA" -> R
-$ memory.query_memories query="..." -> M
+$ data_read.query query="..." -> M
 ```
 
 Parser rule: the text before the dot is the connector name (must match an entry in `connectors.json`); the rest is the tool + args.
@@ -493,13 +490,13 @@ Parser rule: the text before the dot is the connector name (must match an entry
 ```
 $ ticketing_search query="project:INFRA state:Open" limit=20 -> ISSUES
 $ llm prompt="Classify: ${INPUT}" -> VERDICT
-$ memory mode=fts query="${TOPIC}" limit=5 -> RESULTS
-$ memory_write content="${SUMMARY}" recipients=["oncall"] approved="morning roundup, 2026-05-25" -> ACK
+$ data_read mode=fts query="${TOPIC}" limit=5 -> RESULTS
+$ data_write content="${SUMMARY}" recipients=["oncall"] approved="morning roundup, 2026-05-25" -> ACK
 ```
 
 Tool args are unconstrained `key=value` pairs — the connector forwards them to the underlying MCP tool. If a dispatched call returns `isError: true`, the executor throws via `makeOpError`, which routes through `else:` / `# OnError:` machinery. The inner tool's error text is preserved in `result.errors[]`.
 
-**Substrate-neutrality.** Connector names like `$ llm`, `$ memory`, `$ ticketing_search` are NOT reserved or built-in — they're whatever the adopter declares in `connectors.json` (substrate config). Bridges for `$ llm` and `$ memory` / `$ memory_write` auto-wire only when the adopter's substrate config sets `substrate.local_model` / `substrate.memory_store` respectively. See the adopter playbook for the full substrate config reference.
+**Substrate-neutrality.** Connector names like `$ llm`, `$ data_read`, `$ ticketing_search` are NOT reserved or built-in — they're whatever the adopter declares in `connectors.json` (substrate config). Bridges for `$ llm` and `$ data_read` / `$ data_write` auto-wire only when the adopter's substrate config sets `substrate.local_model` / `substrate.data_store` respectively. See the adopter playbook for the full substrate config reference.
 
 **Unknown connector** → tier-1 `unknown-connector` lint with the list of wired connector names.
 
@@ -513,7 +510,7 @@ Mutation ops require an authorization signal. The signal is per-op, not a mode b
 
 **Mutation-classified ops:**
 - `file_write(...)` (runtime-intrinsic)
-- `$ memory_write ...` and any MCP connector entry declared `"mutating": true` in `connectors.json`
+- `$ data_write ...` and any MCP connector entry declared `"mutating": true` in `connectors.json`
 - `shell(command=..., unsafe=true)` (always mutation-classified)
 - `shell(command=...)` with destructive verb (rm, mv, dd, mkfs, etc. — heuristic list)
 - `$ <tool>` matching the mutating-verb regex
@@ -537,7 +534,7 @@ Mutation ops require an authorization signal. The signal is per-op, not a mode b
 
 deliver:
     file_write(path="/tmp/sweep.md", content="${REPORT}")        # no approved= needed
-    $ memory_write content="${REPORT}" recipients=["oncall"]     # no approved= needed
+    $ data_write content="${REPORT}" recipients=["oncall"]       # no approved= needed
 ```
 
 ```
@@ -577,35 +574,15 @@ flush:
 | Runtime-intrinsic | `file_write` | `file_write(path="...", content="...", [approved="..."])` | none |
 | External MCP | `$ <connector>` | `$ <name>[.<tool>] kwarg=value, ... [-> R]` | optional |
 
----
-
-## Legacy syntax (deprecated, grace period)
-
-These symbol-forms shipped in earlier versions and still compile during the grace period with tier-2 `deprecated-symbol-op` warnings. New skills should use the canonical forms.
-
-| Deprecated | Canonical replacement |
-|---|---|
-| `~ prompt="..."` | `$ llm prompt="..."` |
-| `> mode=... query=...` | `$ memory mode=... query=...` |
-| `@ <command>` | `shell(command="...")` |
-| `@ unsafe <command>` | `shell(command="...", unsafe=true)` |
-| `! <text>` | `emit(text="<text>")` |
-| `?? "<prompt>" -> R` | `ask(prompt="<prompt>") -> R` |
-| `& <data-skill-name>` | `inline(skill="<data-skill-name>")` |
-| `$(VAR)` (legacy substitution) | `${VAR}` |
-| `(approved: "reason")` trailer | `approved="reason"` kwarg |
-
-The symbol-per-op design was deprecated when verb-word ops in function-call shape proved more author-friendly (training-corpus alignment + human-reviewability). Removal lands in a future version; until then, the canonical surface is the recommended form.
-
 ## Variable resolution — ${VAR} canonical, substitution + ambient refs + # Requires: cascade
 
-Skillscript supports four tiers of variables, each with distinct resolution timing and scope. Substitution uses **`${VAR}` as the canonical form**. The legacy `$(VAR)` form (parentheses) continues to compile during the grace period; see Ops Reference legacy syntax section for the deprecation map.
+Skillscript supports four tiers of variables, each with distinct resolution timing and scope. Substitution uses **`${VAR}` as the canonical form**.
 
 ## Substitution syntax — `${VAR}` canonical
 
 ```
 emit(text="Hello, ${USER.login}!")
-$ memory mode=fts query="${TOPIC}" limit=5 -> R
+$ data_read mode=fts query="${TOPIC}" limit=5 -> R
 $set REPORT = "Triage for ${PROJECT} (${ISSUES|length} open):\n"
 ```
 
@@ -638,7 +615,7 @@ For cron and session triggers, the scheduler injects time-offset ambient fields
 
 These let skill bodies compute `expires_at` and similar bounded-lifetime values without arithmetic in op kwargs. For ISO-formatted rendering of any epoch value, see the `|isodate` filter.
 
-Additional ambient refs may be injected based on connector configuration (e.g., a vault-backed memory connector may expose `${VAULT_ROOT}`). Connectors section documents which ambient refs each connector contributes.
+Additional ambient refs may be injected based on connector configuration. Connector documentation specifies which ambient refs each connector contributes.
 
 ## Tier 2: Input
 
@@ -662,18 +639,16 @@ Bracketed list literals supported (`# Vars: TAGS=[a, b, c]`).
 
 ## Tier 4: Local
 
-Bound to a previous target's output mid-execution. Two forms:
+Bound to a previous target's output mid-execution. Three forms:
 - `${target.output}` — the bound output of a target
 - `${VAR}` — an explicit `-> VAR` binding from any op
-- `${target.output.field}` or `${MEMORY.field}` — dotted field access into structured output
+- `${VAR.field}` / `${VAR.nested.field}` — dotted field access into structured output
 
-**Field access resolution tiers** for `${MEMORY.field}`:
-1. Core `PortableMemory` fields (id, summary, detail, score)
-2. Curated substrate subset (thread_status, pinned, confidence, domain_tags, payload_type, knowledge_type, recipients, expires_at, created_at, agent_id, vault)
-3. `metadata.X` for everything else
-4. Ambient passthrough as literal `${MEMORY.field}` if unresolved
+The exact field set available on a bound variable depends on what the wired connector returns. Field access resolves against the returned object's structure. If a field doesn't resolve, the substitution errors unless `|fallback:"default"` is supplied (see Pipe filters for full `|fallback:` semantics):
 
-**Missing-field opt-out:** `${MEMORY.field|fallback:"-"}` coalesces to the literal when the field doesn't resolve. See Pipe filters for the full `|fallback:` semantics.
+```
+emit(text="Assignee: ${ISSUE.customFields.Assignee|fallback:\"unassigned\"}")
+```
 
 ## Resolution order
 
@@ -751,7 +726,7 @@ Strings that hold JSON arrays get the same tolerance as `in`/`not in` RHS: if th
 Pairs naturally with the numeric comparison operators (see Conditionals section):
 
 ```
-$ memory mode=fts query="urgent" -> ITEMS
+$ data_read mode=fts query="urgent" -> ITEMS
 if ${ITEMS|length} > 5:
     emit(text="Mailbox is getting crowded")
 ```
@@ -901,7 +876,7 @@ The ref-vs-ref form is the canonical change-detection pattern. Both sides resolv
 if ${M.id|trim} in ${SEEN}:
     emit(text="already processed")
 elif ${M.id} not in ${SEEN}:
-    $ memory_write content="..." approved="dedup" -> R
+    $ data_write content="..." approved="dedup" -> R
 ```
 
 Both sides are explicit refs. RHS must resolve to an array at runtime; clean error otherwise. LHS-undefined evaluates to `false` for both polarities. Optional filter on LHS.
@@ -909,9 +884,9 @@ Both sides are explicit refs. RHS must resolve to an array at runtime; clean err
 **JSON-string tolerance on RHS**: if the RHS resolves to a *string* that successfully JSON-parses to an array, the parsed array is used. This accommodates the canonical pattern where the array comes from a `$ llm` call that prompted for JSON output:
 
 ```
-$ llm prompt="List the URGENT memory IDs as a JSON array of strings. Items: ${M|json}" -> SEEN
+$ llm prompt="List the URGENT item IDs as a JSON array of strings. Items: ${M|json}" -> SEEN
 
-foreach M in ${MEMORIES}:
+foreach M in ${ITEMS}:
     if ${M.id} in ${SEEN}:
         emit(text="flagged urgent")
 ```
@@ -932,7 +907,7 @@ elif ${COUNT} <= 0:
 Filters and dotted-field access work on either side, same as equality. The `|length` filter (see Pipe filters section) is the canonical companion — `${LIST|length} > 5` is the natural "more than five items" pattern:
 
 ```
-$ memory mode=fts query="urgent" -> ITEMS
+$ data_read mode=fts query="urgent" -> ITEMS
 if ${ITEMS|length} > 5:
     emit(text="Mailbox is getting crowded")
 ```
@@ -972,7 +947,7 @@ classify:
 
 ```
 mailbox_check:
-    $ memory mode=fts query="addressed:perry" limit=10 -> MAILBOX
+    $ data_read mode=fts query="addressed:perry" limit=10 -> MAILBOX
     if not ${MAILBOX}:
         emit(text="empty mailbox today")
     elif ${MAILBOX|length} > 5:
@@ -1019,12 +994,12 @@ Both can coexist in the same target.
 foreach M in ${RESULTS}:
     emit(text="Processing ${M.id} — ${M.summary}")
     if ${M.id|trim} not in ${SEEN}:
-        $ memory_write content="${M.summary}" approved="dedup" -> ACK
+        $ data_write content="${M.summary}" approved="dedup" -> ACK
 ```
 
 ### Iterator vars
 
-`${M}` and `${M.field}` pass through ambient at compile; runtime substitutes per iteration. Dotted field access against `PortableMemory` shape applies (core fields → curated subset → metadata). Indexed access (`${LIST.0}`, `${LIST.0.id}`) also works on bound results.
+`${M}` and `${M.field}` pass through ambient at compile; runtime substitutes per iteration. Dotted field access resolves against whatever structure the connector returned per item — the exact field set depends on the connector. Indexed access (`${LIST.0}`, `${LIST.0.id}`) also works on bound results.
 
 ### Loop-local scope (and the accumulator exception)
 
@@ -1369,7 +1344,7 @@ Runs if any op in the target's primary body errors. Local to the failing target.
 
 ```
 fetch:
-    $ memory mode=fts query=${TOPIC} limit=5 -> RESULT
+    $ data_read mode=fts query=${TOPIC} limit=5 -> RESULT
 else:
     emit(text="retrieval failed, falling back to empty result")
     $set RESULT = ""
@@ -1412,7 +1387,7 @@ Inline fallback declared on the op line. Used when the call fails or returns emp
 
 ```
 weather:
-    $ memory mode=fts query="weather ${LOCATION}" limit=1 -> CURRENT (fallback: "weather unavailable")
+    $ data_read mode=fts query="weather ${LOCATION}" limit=1 -> CURRENT (fallback: "weather unavailable")
     $ llm prompt="Summarize: ${CURRENT}" -> SUMMARY (fallback: "summary unavailable")
     $ slack.post channel=${CHANNEL} text=${SUMMARY} (fallback: "post failed silently") -> ACK
 ```
@@ -1422,7 +1397,7 @@ Same pattern as the `# Requires:` cascade's `(fallback: ...)` syntax — consist
 **Fallback value parsing.** Permissive: bare identifiers, quoted strings, and bracketed array literals all accepted. Matches the `# Requires:` cascade convention.
 
 ```
-$ memory mode=fts query="..." -> RESULTS (fallback: [])              # array literal
+$ data_read mode=fts query="..." -> RESULTS (fallback: [])           # array literal
 $ llm prompt="..." -> VERDICT (fallback: unknown)                    # bare identifier
 $ slack.post text="..." -> ACK (fallback: "post failed")             # quoted string
 ```
@@ -1728,7 +1703,7 @@ Normal `prompt` / `prose` compilation ignores the `# Tests:` section entirely
 
 ### Runtime assertion sandboxing
 
-`# Tests:` cases that exercise runtime behavior (memory writes, shell ops, LocalModel calls) need a sandbox so they don't pollute production data. Two approaches:
+`# Tests:` cases that exercise runtime behavior (data writes, shell ops, LocalModel calls) need a sandbox so they don't pollute production data. Two approaches:
 - Scratch DB / scratch connector overrides for tests
 - Skip-and-warn for non-deterministic ops, only assert deterministic compile-time properties
 
@@ -1832,7 +1807,7 @@ $set NAME = value scope=session
 
 Backed by a configured data-records connector (the same surface `# Requires:` reads from) with conventionally-namespaced keys (e.g., `state:skill-local:<skill-name>:<key>`).
 
-**Rationale:** Most interesting skills need memory across firings — change-detection, windowing, dedup-against-recent. Without lifecycle, every skill rebuilds state tracking via raw memory-write / memory-query calls.
+**Rationale:** Most interesting skills need persistent state across firings — change-detection, windowing, dedup-against-recent. Without lifecycle, every skill rebuilds state tracking via raw `$ data_write` / `$ data_read` calls.
 
 ## Cross-skill pub-sub
 
@@ -1905,7 +1880,7 @@ ${SELF.confidence-trend}
 Skill declares its required surfaces:
 
 ```
-# Requires-Capabilities: sensors=[mic, camera], tools=[memorystore.write, slack.post]
+# Requires-Capabilities: sensors=[mic, camera], tools=[datastore.write, slack.post]
 # Requires-Privacy: private-channel-only
 ```
 
@@ -1968,5 +1943,5 @@ Hung dispatches hang the skill without explicit timeout configuration. Lean: ski
 
 ---
 
-*Rendered from `skillscript/skillscript-language-reference` — 2026-05-29 10:20 EDT*  
+*Rendered from `skillscript/skillscript-language-reference` — 2026-05-30 09:52 EDT*  
 *Source of truth: AMP (`amp_render_document("skillscript/skillscript-language-reference")`)*

package/docs/sqlite-skill-store.md

@@ -159,7 +159,7 @@ registerApprovalFn("v2", (body) => hmacSha256(SECRET, body));
 When forking into your codebase:
 
 1. Rename the class (e.g., `PostgresSkillStore`, `AmpSkillStore`)
-2. Replace the SQL with your substrate's API (HTTP, MemoryStore, vector DB, etc.)
+2. Replace the SQL with your substrate's API (HTTP, DataStore, vector DB, etc.)
 3. Update `staticCapabilities()` to match what your substrate actually supports — drop `supports_versioning` if you can't track history, drop `supports_tag_filter` if querying tags isn't tractable
 4. Update `manifest()` to describe your substrate (`kind: "amp"` or whatever)
 5. Tests: copy `tests/SqliteSkillStore.test.ts` as a starting point + run the conformance suite (`SkillStoreConformance.buildTests()` from `skillscript-runtime/testing`)

package/examples/README.md

@@ -9,9 +9,9 @@ For full language semantics, see [`../docs/language-reference.md`](../docs/langu
 | [`hello.skill.md`](./skillscripts/hello.skill.md) | Three-command first run; `! emit`; default target; `# Vars:` declared inputs |
 | [`morning-brief.skill.md`](./skillscripts/morning-brief.skill.md) | Multi-target with `needs:`; cron-fired with `EVENT.fired_at_*`; `# OnError:` fallback; dual `# Output:` (slack + prompt-context); `# Requires:` user-var cascade with fallback; LocalModel + retrieval composition |
 | [`doc-qa-with-citations.skill.md`](./skillscripts/doc-qa-with-citations.skill.md) | Single-target retrieval; `(fallback: [])` op-level fallback; LLM-with-citation pattern; pipe filter `\|json` for prompt embedding |
-| [`classify-support-ticket.skill.md`](./skillscripts/classify-support-ticket.skill.md) | `if`/`elif`/`else` multi-branch routing; classifier-cascade pattern; MemoryStore `$` writes with structured `domain_tags`; `$set` literal binding |
+| [`classify-support-ticket.skill.md`](./skillscripts/classify-support-ticket.skill.md) | `if`/`elif`/`else` multi-branch routing; classifier-cascade pattern; DataStore `$` writes with structured `domain_tags`; `$set` literal binding |
 | [`cut-release-tag.skill.md`](./skillscripts/cut-release-tag.skill.md) | `??` interactive ask-for-input; `else:` short-circuit on multiple targets; `@` shell ops with per-op error fallback; rollback-on-failure flow |
-| [`service-health-watch.skill.md`](./skillscripts/service-health-watch.skill.md) | `foreach` iteration; cron-fired with `expires_at=$(EVENT.fired_at_plus_1d_unix)` TTL math; classifier-gated MemoryStore writes; pipe filter `\|url` for path-safe interpolation |
+| [`service-health-watch.skill.md`](./skillscripts/service-health-watch.skill.md) | `foreach` iteration; cron-fired with `expires_at=$(EVENT.fired_at_plus_1d_unix)` TTL math; classifier-gated DataStore writes; pipe filter `\|url` for path-safe interpolation |
 | [`feedback-sentiment-scan.skill.md`](./skillscripts/feedback-sentiment-scan.skill.md) | `in` / `not in` set-membership ops; dedupe-via-seen-markers idiom; nested `if`/`elif` classification cascade; TTL on bookkeeping writes |
 
 ## Connector requirements
@@ -19,9 +19,9 @@ For full language semantics, see [`../docs/language-reference.md`](../docs/langu
 Most examples assume the bundled-default connectors:
 
 - `hello.skill.md` — zero deps (runs cold)
-- `doc-qa-with-citations.skill.md` — Ollama (LocalModel) + MemoryStore for the retrieval cache
-- `morning-brief.skill.md`, `feedback-sentiment-scan.skill.md` — Ollama + MemoryStore + a calendar MCP connector (the `$ calendar.list_events` op)
-- `classify-support-ticket.skill.md` — Ollama + MemoryStore
+- `doc-qa-with-citations.skill.md` — Ollama (LocalModel) + DataStore for the retrieval cache
+- `morning-brief.skill.md`, `feedback-sentiment-scan.skill.md` — Ollama + DataStore + a calendar MCP connector (the `$ calendar.list_events` op)
+- `classify-support-ticket.skill.md` — Ollama + DataStore
 - `cut-release-tag.skill.md` — git CLI on `PATH`; expects to run inside a git repo
 - `service-health-watch.skill.md` — `curl` on `PATH`; network egress to `status.internal/*`