diff --git a/INTENT.md b/INTENT.md
index 2941cae..be3923d 100644
--- a/INTENT.md
+++ b/INTENT.md
@@ -16,6 +16,8 @@ The goal is to allow independently stored and differently implemented wikis, pag
 
 The repository provides a **shard orchestration layer** for interconnected Markdown and markup-based wiki content.
 
+Equivalently, shard-wiki can be used as a **headless, API-first wiki engine** — optimized for **integrating heterogeneous data sources** and for **efficient access by agents and automation** — that ships its own native engine as one (canonical-mode) shard among many. There is no bundled UI: presentation and rendering are consumer concerns.
+
 It allows wiki-like systems to:
 
 * Attach heterogeneous page stores as shards of a shared information space
@@ -30,6 +32,7 @@ It allows wiki-like systems to:
 * Run fully standalone with open read/write access and complete change history, then progressively layer multi-tenant enterprise access control through external identity integration
 * Allow existing wiki engines to become federation-capable through a shared API
 * Allow non-federation-aware systems to participate through adapters and projections
+* Serve as a **headless, API-first wiki engine** (a small typed-extension core) that integrates heterogeneous data sources and is consumed efficiently by agents and automation
 
 It transforms disconnected wiki engines, Git repositories, local folders, WebDAV directories, application-specific content stores, and desktop editing workflows into a **composable federated wiki space**.
 
@@ -85,7 +88,7 @@ A mature `shard-wiki` should allow each participating shard to see the others as
 
 This repository is **not** intended to:
 
-* Replace all wiki engines with a single canonical wiki implementation
+* Replace all wiki engines with a single canonical wiki implementation *(shard-wiki MAY still provide its own native, headless, API-first engine as one optional shard backend — see Design Principles — but never as a mandated or universal replacement)*
 * Force every shard to use the same backend, database, directory layout, or storage format
 * Require every participating system to become federation-aware
 * Require every participating shard to be Git-native
@@ -148,6 +151,9 @@ Policy decisions such as conflict preference, canonical source selection, public
 * **Composable integration**  
   Wiki engines should be able to use the `shard-wiki` API to become federation-enabled without reimplementing federation internally.
 
+* **Native reference engine (additive, headless & API-first)**  
+  shard-wiki MAY provide its own native wiki-engine as a **canonical-mode shard backend** — a **small core** with a **typed-extension framework**, activated **per shard** (only what you need). It is **headless and API-first** (no bundled UI; presentation/rendering are consumer concerns) and tuned for **integrating heterogeneous data sources** and **efficient agent/automation access**. It is *one shard type among many*, implemented against shard-wiki's own adapter contract; it does **not** replace other engines, mandate a single implementation, or change shard-wiki's role as an orchestrator. Shard sovereignty and union-without-erasure are preserved.
+
 * **Open by default, progressively governed**  
   A standalone `shard-wiki` must be runnable with zero external dependencies in a classic Ward Cunningham / c2-style open read/write-for-all mode. Access control is an *additive capability*, not a precondition: the same core progresses — without re-architecture — to authenticated single-user, to group/role-based, to multi-tenant enterprise access control, mirroring the NetKingdom capability ladder (lightweight → expanded).
 
@@ -201,3 +207,5 @@ Such changes should be rare, because they affect all downstream systems relying
 
 In particular, changes that redefine what counts as a shard, what role Git plays, how root entities are modeled, or whether `shard-wiki` is an orchestrator rather than a wiki engine should be treated as architectural changes.
 
+**Amendment — 2026-06-15 (SHARD-WP-0013 T4, decision `84ffdb48`):** admits an **additive** native reference wiki-engine — **headless, API-first**, a small typed-extension core — as a **canonical-mode shard backend** optimized for data-source integration and agent access. Deliberate, narrow scope change; shard-wiki remains an orchestrator and neither mandates nor replaces other engines. (Mirrors the earlier auth-in-core amendment precedent.)
+
diff --git a/SCOPE.md b/SCOPE.md
index 822a5de..a624b5a 100644
--- a/SCOPE.md
+++ b/SCOPE.md
@@ -32,11 +32,15 @@ Learnings update both SCOPE and INTENT where necessary.
 - Authorization model design (delegated authentication, core authorization).
 - Shard adapter contract and wiki page model (to be specified, then implemented).
 - Git-backed coordination journal for information spaces.
+- A **native, headless, API-first wiki-engine core** (small typed-extension core, as a
+  canonical-mode shard backend) — design via SHARD-WP-0013; optimized for data-source
+  integration and agent access.
 - State Hub workplan registration and consistency sync.
 
 ## Out Of Scope (today)
 
-- A standalone wiki engine UI or rendering pipeline.
+- A wiki-engine **UI or rendering pipeline** (the engine is headless/API-first; presentation
+  is a consumer concern). A bundled standalone UI is not provided.
 - Authentication, credential storage, or user directory implementation.
 - Hard-coded editorial, sync, or conflict-resolution policy.
 - Generic file mirroring independent of wiki-page semantics.
diff --git a/workplans/SHARD-WP-0013-wiki-engine-prep.md b/workplans/SHARD-WP-0013-wiki-engine-prep.md
index fd42dc9..84a03ce 100644
--- a/workplans/SHARD-WP-0013-wiki-engine-prep.md
+++ b/workplans/SHARD-WP-0013-wiki-engine-prep.md
@@ -123,7 +123,7 @@ state hub").
 
 ```task
 id: SHARD-WP-0013-T4
-status: todo
+status: done
 priority: high
 state_hub_task_id: "1d0ef72b-2762-4086-9848-fde3b48c8454"
 ```