Establish clean starting point: workplan, access model, INTENT amendments

Add SHARD-WP-0001 workplan backed by the StateHub yawex-requirements
workstream (6 design tasks, all todo). Includes access-model blueprint,
NetKingdom integration requirements draft, and INTENT amendments for
open-by-default authorization delegated to external identity providers.

INTENT.md

@@ -27,6 +27,7 @@ It allows wiki-like systems to:
 * Detect and reconcile divergence between equivalent pages stored in different shards
 * Keep selected representations of the same wiki content synchronized where appropriate
 * Provide backup, versioning, and recovery for local, remote, and projected wiki content
+* 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
 
@@ -94,7 +95,7 @@ This repository is **not** intended to:
 * Silently mutate remote systems without explicit adapter support and user intent
 * Act as a generic file synchronization daemon independent of wiki semantics
 * Guarantee real-time consistency across all shards and backends
-* Solve organizational permissions, identity management, or secret storage by itself
+* Implement its own authentication, identity store, user directory, or secret storage — these are **delegated to an external identity provider** (in the reference deployment, `user-engine` for accounts/memberships and `net-kingdom` for IAM/SSO). shard-wiki *does* own an **authorization model** (who may read/write/patch/merge a page or shard) and the **change history** that makes edits recoverable; it does not own authentication or identity lifecycle.
 * Collapse all shards into one permanently canonical source of truth
 
 Its responsibility is limited to **orchestrating wiki-shaped content across shards**, providing normalized interfaces, projections, overlays, synchronization mechanisms, Git-backed coordination, and versioned change flows.
@@ -147,6 +148,15 @@ 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.
 
+* **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).
+
+* **History as the safety net**  
+  Because the open mode trusts all writers, every change must be captured in a complete, Git-backed history so that accidental loss, vandalism, or mistaken edits are always recoverable. Recoverability — not gatekeeping — is the baseline protection; access control hardens it but never replaces it.
+
+* **Authorization in core, authentication delegated**  
+  shard-wiki owns the *authorization* model (capability-based decisions about who may read/write/patch/merge a page or shard) and expresses identity through a pluggable provider interface. It never implements its own authentication, credential store, or user directory; those are supplied by an external identity provider such as `user-engine` (accounts, memberships, profiles, audit) over a `net-kingdom` IAM backend (OIDC/PKCE in lightweight mode, Keycloak/SAML in expanded mode).
+
 ---
 
 ## Maturity Target
@@ -173,6 +183,10 @@ A mature version of this repository should:
 * Provide a UI for browsing, editing, projecting, comparing, and reconciling the full information space
 * Provide an API that allows wiki engines to become federation-enabled
 * Provide backup and recovery workflows for attached wiki shards
+* Run standalone with zero external dependencies in an open, c2-style read/write-for-all mode
+* Preserve a complete, Git-backed change history that enables recovery from accidental loss, vandalism, or mistaken edits
+* Provide a pluggable authorization model that spans the full range from anonymous-open, through authenticated and group/role-based, to multi-tenant enterprise access control — without changing the core
+* Integrate with `user-engine` (accounts, memberships, profiles, audit, events) and its `net-kingdom` IAM backend (OIDC/PKCE lightweight mode, Keycloak/SAML expanded mode) to deliver enterprise-grade multi-tenant access control
 * Serve as the default orchestration layer for federated Markdown wiki content across dependent systems
 
 A mature `shard-wiki` should make the practical mixture of repository wikis, application databases, synced directories, local Obsidian vaults, WebDAV folders, projected pages, and Git-backed content feel like a deliberate architecture rather than an accidental workaround.