spec(SHARD-WP-0005 T9): known scaling risks & open problems; close-out

Adds §12 'Known scaling risks & open problems' (O-1..O-7 with chosen
direction + revisit trigger); renumbers §13-17. Refreshes §14 decisions
(several earlier 'open' items now decided), §16 traceability (links the
review + per-finding section map), and I-1..I-13. Flips SHARD-WP-0005 done.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

SCOPE.md

@@ -21,8 +21,8 @@ Learnings update both SCOPE and INTENT where necessary.
 | Intent | `INTENT.md` established; authorization-in-core amendments drafted |
 | Research | yawex prior art; c2 origins; federation concepts; wikiengines overview (`research/260608-*/`); XWiki/TWiki/Foswiki deep dives (`research/260613-*/`); Xanadu + ZigZag + Roam + Obsidian + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) + Trilium + Wiki.js + Federated Wiki + Wikibase + git-forge wikis + TiddlyWiki + ikiwiki + Quip + MojoMojo + Oddmuse + UseModWiki deep dives & shard-spectrum synthesis (`research/260614-*/`) |
 | Demand | NetKingdom integration asks captured, not yet negotiated |
-| Spec | CoreArchitectureBlueprint (whole-system architecture) + ArchitectureBlueprint (auth/history) drafted; UseCaseCatalog 84 UCs from research; PRD/TSD scaffolds |
-| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (18 tasks: T1–T10 federation + T11–T16 adapter contract + T17 federation-model taxonomy + T18 computational content, re-folded from synthesis v3 + the computational page model); `SHARD-WP-0003` **done** (9 engine dives complete); `SHARD-WP-0004` **done** (all 8 computational-knowledge dives T1–T8 complete + "computational page model" synthesis) |
+| Spec | CoreArchitectureBlueprint (whole-system architecture, hardened via SHARD-WP-0005) + ArchitectureBlueprint (auth/history) drafted; UseCaseCatalog 84 UCs from research; PRD/TSD scaffolds |
+| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (18 tasks: T1–T10 federation + T11–T16 adapter contract + T17 federation-model taxonomy + T18 computational content, re-folded from synthesis v3 + the computational page model); `SHARD-WP-0003` **done** (9 engine dives complete); `SHARD-WP-0004` **done** (all 8 computational-knowledge dives T1–T8 complete + "computational page model" synthesis); `SHARD-WP-0005` **done** (9 tasks: CoreArchitectureBlueprint hardened against the 260615 review) |
 
 ## In Scope (today)
 

spec/CoreArchitectureBlueprint.md

@@ -101,6 +101,7 @@ principles fused with the research through-lines.
 | I-10 | **History is the floor.** Every write is a recoverable commit; recoverability, not gatekeeping, is the baseline protection. | ArchitectureBlueprint §2 |
 | I-11 | **Authorization in core, authentication delegated.** Core decides who-may; an external provider says who-is. | INTENT; ArchitectureBlueprint |
 | I-12 | **Not a file-sync daemon; not an execution platform.** Sync is wiki-page-semantic; computation is recognised+projected, not hosted. | INTENT; computational-page-model synthesis |
+| I-13 | **Tenant-partitioned derived state.** Derived state is partitioned by tenant/root entity; no derived artifact spans tenants except via explicit, authorised cross-root federation. | §9.1; review B-3 |
 
 ---
 
@@ -262,6 +263,51 @@ only via export→files (I-12).
 - **Absence is first-class** — the profile must express *can't* cleanly (Oddmuse floor), so
   degradation paths are explicit, never guessed.
 
+### 6.5 Orthogonal core, implied positions, and the interaction subset
+
+Fifteen independent ordinal axes is *descriptively* right but would be *operationally* a mess
+if treated as fifteen free dimensions: the axes are **not orthogonal**, and a degradation
+function over all 15 jointly is the flat-checklist problem returning in higher dimensions
+(review D-1). Three rules tame it.
+
+**(a) A small orthogonal core; the rest are implied.** Most axes are *correlated* and collapse
+to a few independent choices. The **core axes** an adapter must independently declare:
+
+1. **Substrate** → drives attachment-mode, history, merge, and native-query positions together
+   (git-IS-store ⟹ history=git-native ⟹ merge=git/text ⟹ query=build-your-own-index;
+   relational-DB ⟹ direct-DB attach ⟹ DB-version-row history ⟹ DB query).
+2. **Write granularity** → drives addressing granularity and the overlay/patch shape.
+3. **Content opacity** → drives translation and (where encrypted) collapses native-query.
+4. **Operational envelope** → drives freshness mode (§8.8) and rebuild expectations (§8.7).
+5. **Access grant** → independent (authz, L5).
+6. **Computational/liveness** → independent (projection kind, §8.5).
+
+The remaining axes are **implied/derived** from these via published implication rules; an
+adapter *may* override an implied position, but the default is computed, not hand-set. This
+turns ~15 free dimensions into ~6 independent ones plus derivations — fewer things to get
+wrong, and impossible combinations become unrepresentable.
+
+**(b) Implication rules forbid impossible profiles.** E.g. `attachment=git-IS-store ⟹
+history≥git-native`; `opacity=encrypted-whole-shard ⟹ native-query=none ∧ translation≤opaque`;
+`merge=native-CRDT ⟹ history=CRDT-log ∧ envelope=realtime`. A profile that violates an
+implication is rejected at registration — capability-as-data (I-3) with integrity constraints.
+
+**(c) The degradation function reads a *named, small* interaction subset — not all pairs.**
+"No per-backend code" is only credible if we say *which* axis interactions the generic logic
+actually consults. They are:
+
+| Operation | Axes consulted (jointly) |
+|-----------|--------------------------|
+| **write / overlay-apply** | write-granularity × merge-model × history × access-grant |
+| **transclude / address a span** | addressing-granularity × write-granularity × identity-vs-placement |
+| **project / cache** | operational-envelope × computational-liveness × content-opacity |
+| **query** | native-query × content-opacity (encrypted ⇒ derive-index-or-none) |
+| **translate** | translation × content-opacity × structure |
+| **federate** | substrate × history × merge (per the §8.3 model) |
+
+Everything else is a single-axis check. This table *is* the degradation contract: it is small,
+enumerated, and testable — the proof obligation behind "core logic written once."
+
 ---
 
 ## 7. Top waist — the Wiki Page Model (L2)
@@ -315,6 +361,24 @@ break every reference to it (review bug B-1). They are pulled apart here:
 So the chain is: **identity (stable) → placements (N, mutable) → equivalence (cross-identity
 sameness, fingerprint-based)** — three concepts, three mechanisms, never conflated.
 
+### 7.3 Provenance is layered, not per-span-duplicated
+
+A provenance envelope on *every span* (source shard, freshness, liveness, overlay status,
+authz context, divergence, lineage) would, at block granularity, mean ~10k near-identical
+envelopes for a 10k-block page — provenance dwarfing content (review D-2). The fix is the exact
+pattern the page model already uses for Trilium's computed metadata: **effective-vs-own**.
+
+- **Page-level envelope** holds the values that are uniform across the page (almost always:
+  source shard, observed-at, liveness, authz context).
+- **Span-level deltas** record *only where a span differs* from its page envelope — a
+  transcluded span from another shard, an overlaid span, a span that diverges. A span with no
+  delta inherits the page envelope at zero storage cost.
+- **Effective provenance** for any span = page envelope ⊕ span delta, computed on read.
+
+Per-span cost is therefore **near-zero in the common (uniform) case** and pays only for genuine
+heterogeneity — the same "carry only the difference" principle, applied to shard-wiki's own
+metadata. Provenance remains complete (I-4); it is just not redundantly materialised.
+
 ---
 
 ## 8. Coordination, federation & projection
@@ -327,6 +391,23 @@ operations (fork, import, reconcile, overlay-apply, space-branch) and **is** the
 the journal supplements (begins-now / mirrors-forward / snapshots-replica) or imports
 (backfill open file history). History portability is a spectrum, handled per profile (axis 5).
 
+**History must stay recoverable *and* bounded (review C-3).** "Every write is a commit" + open
+L0 means an unbounded, bot-/vandalism-amplified journal that eventually degrades Git itself.
+Recoverability (I-10) is non-negotiable, so the answer is *compaction, not deletion*:
+
+- **Routine git maintenance** — background `gc`/repack, commit-graph, and (for very large
+  spaces) partial-clone / sparse strategies; operational, no semantic change.
+- **Squash-compaction of low-value churn (policy, §10)** — long runs of rapid same-author
+  edits or revert-pairs can be folded into checkpoint commits *while preserving the recoverable
+  endpoints*; what is squashed is configurable and always leaves the content recoverable (it
+  compacts the *path*, not the *reachable states*).
+- **Per-shard history offload** — a git-IS-store shard keeps its own history in its own repo;
+  the coordination journal references it rather than duplicating it (the journal records
+  *coordination* events, not a second copy of every shard commit).
+- **Anti-abuse hooks (policy)** — rate-limiting / quarantine for anonymous L0 writers feed the
+  authz/policy layer; they throttle *abuse*, never legitimate history. Recoverability is the
+  floor; bounding is how it survives at scale.
+
 ### 8.2 Overlay / patch engine (L3)
 
 The default write path for anything below write-through capability (I-5): an edit becomes a
@@ -366,18 +447,24 @@ derived**; recompute reads them, never regenerates them. It comprises:
 - **Transclusion** — one **reference-not-copy** primitive unifying Xanadu transclusion, ZigZag
   clone, Roam/Obsidian/Logseq embed, Notion synced block, Trilium note-cloning, and literate
   named-chunk assembly, over the addressable union.
-- **Projection — the two-axis model:**
-  - *Kind:* **replication-projection** (lazy cache of remote content — the default) vs
-    **derivation-projection** (transform/compile/weave/evaluate a source).
-  - *Liveness:* static → captured snapshot → live-over-files → view-time → irreducibly-live.
-  - Derivation facets: materialization timing (ahead-of-time vs view-time), multiplicity (one
-    output vs N co-equal), continuity (one-shot vs continuous). Every projection declares its
-    liveness + freshness + provenance; the irreducibly-live far end has no faithful static
-    form (source + a marked recording).
-- **Moldable view registry** — projection generalises to an **open, type-keyed set of
-  co-equal, possibly-computed views, none canonical-by-fact** (display-canonical is policy).
-  This unifies replication/derivation/dimensional/query projection and answers the "pluggable
-  content-type registry" question (GT prior art).
+- **Projection — trivial by default, extensible for the tail.** The 95% case (Markdown in a
+  shard) must cost nothing conceptually, so:
+  - **Default = plain lazy replication-projection** — a freshness-stamped cache of remote
+    content (§8.8). This is *the* projection for ordinary pages; it needs no taxonomy, no
+    liveness reasoning, no registry. Most shards never touch anything below.
+  - **Extension point — derivation-projection** — invoked *only* for content that is a
+    *source* needing transform/compile/weave/evaluate (computational/typed content, §8.5). It
+    adds the liveness axis (static → captured → live-over-files → view-time → irreducibly-live)
+    and facets (materialization timing, multiplicity, continuity); the irreducibly-live far end
+    has no faithful static form (source + a marked recording). A binding that never serves such
+    content never instantiates any of this.
+  - Both kinds stamp freshness + provenance; only derivation carries the liveness machinery.
+- **Moldable view registry — also an extension point, not a tax on every page.** Where a content
+  type offers multiple co-equal views (typed/computed/dimensional content), they are registered
+  as an **open, type-keyed set, none canonical-by-fact** (display-canonical is policy; GT prior
+  art, answers the "pluggable content-type registry" question). An ordinary Markdown page has
+  exactly one view and never consults the registry — the registry is queried only when a type
+  declares >1 view.
 - **Derived query index** — delegate to a shard's native query engine where present
   (Roam/Logseq Datalog, Notion DB query, XWiki XWQL, Wikibase SPARQL); else build a derived
   index over the projection (the Logseq DataScript-over-files pattern). The index is
@@ -543,6 +630,30 @@ summarised here for completeness:
   is resolved. Provenance carries authz context so the union never leaks unreadable content
   (the L5↔provenance-rail interaction).
 
+### 9.1 Tenant isolation of the derived tier (review B-3)
+
+Read-time authz filtering is necessary but **not sufficient** when the derived tier is
+*persisted*: a single cross-tenant union/index cache guarded only by a filter on read is a
+standing leak surface (one filtering bug exposes another tenant's content). So isolation is
+**structural, not just procedural**:
+
+- **The derived tier is partitioned per tenant / root entity.** A tenant maps to a root entity
+  (§4); its union graph, equivalence index, projections, and caches live in a **separate
+  partition** keyed by that tenant. There is no shared cross-tenant derived store to leak from.
+- **No cross-tenant equivalence by default.** Blocking/LSH (§8.7) operates *within* a partition;
+  cross-tenant equivalence is an explicit, authorised, opt-in federation between roots, never an
+  accident of a shared index.
+- **Read-time filtering remains, as defence-in-depth** — the provenance envelope's authz context
+  is still checked, so even within a partition a principal sees only what it may; partitioning
+  removes the *blast radius*, filtering removes the *fine-grained* leak.
+- **This reconciles I-2 with L5:** recomputability (a persisted-but-disposable derived tier) is
+  preserved *per partition* — each tenant's derived tier is independently rebuildable from that
+  tenant's canonical state — so isolation costs nothing in the rebuild model. At L0/L1 (single
+  tenant) there is one partition and the machinery is invisible.
+
+**Isolation invariant (add to §2 as I-13):** *derived state is partitioned by tenant; no
+derived artifact spans tenants except through an explicit, authorised cross-root federation.*
+
 ---
 
 ## 10. The policy surface (mechanism over policy, made concrete)
@@ -586,17 +697,51 @@ src/shard_wiki/
   projection/     # L4 (derived): ReplicationProjection, DerivationProjection,
                   #   ViewRegistry (moldable), QueryIndex (delegate|derive)
   authz/          # L5 cross-cut: PDP, PEP, IdentityProvider iface, NullProvider
-  provenance/     # cross-cut: the envelope plumbing used by every layer
+  provenance/     # cross-cut LEAF: ProvenanceEnvelope type + ⊕ (effective) only — pure data
+  policy/         # cross-cut LEAF: the §10 policy surface (presets + a resolve() read by
+                  #   coordination/federation/projection/authz); owns NO mechanism
   api/            # L6: orchestrator API (server-side union for agents/CLI)
 ```
 
-Hard import rules: `union/` and `projection/` may import `model/`, `adapters/`,
-`coordination/` but **nothing may import them** (they are the disposable middle). `model/` and
-`adapters/` import nothing else in the tree except `provenance/` (the waists stay thin).
+**The cross-cutting rails are leaves, not god-modules (review D-4).** `provenance/` and
+`policy/` are imported widely, so they are the highest coupling risk; the discipline that caps
+it is: **they may import *nothing* in the tree and contain *only* stable data types + pure
+functions** (the envelope and its `⊕`; the policy presets and a `resolve(question) → choice`).
+Mechanism never lives in a rail — `policy/` says *what* the preset is, `coordination/`/
+`projection/` decide *how* to honour it. A change to a rail is then a change to a small, stable,
+dependency-free leaf, not a ripple through every layer. Capability-spectrum value types live in
+`model/` (also leaf-like) for the same reason.
+
+Hard import rules (enforced by import lint):
+- `union/` and `projection/` may import `model/`, `adapters/`, `coordination/`, `policy/`,
+  `provenance/` — but **nothing may import them** (they are the disposable derived tier).
+- `model/`, `adapters/`, `provenance/`, `policy/` import nothing else in the tree (the waists
+  and rails stay thin); `provenance/` and `policy/` import nothing at all.
+- `coordination/` and `federation/` may import the waists + rails, never the derived tier.
 
 ---
 
-## 12. Canonical data flows (the architecture exercised)
+## 12. Known scaling risks & open problems
+
+Tracked honestly rather than pretend-solved (review disposition F). Each has a **chosen
+direction** and a **revisit trigger** — the thing that, if observed, forces a redesign.
+
+| # | Risk / open problem | Chosen direction | Revisit trigger |
+|---|---------------------|------------------|-----------------|
+| O-1 | **Equivalence blocking misses true matches** (LSH false negatives, §8.7) | accept a small miss rate; curator bindings are the escape hatch | measured recall below an agreed threshold on real corpora |
+| O-2 | **Convergence bound for high-write CRDT shards under partition** (§8.6) | causal via journal + CRDT-native merge at the shard; no global bound promised | user-visible divergence that outlives a partition |
+| O-3 | **Per-equivalence-set divergence tracking** (§8.6) | start with base-rev comparison; add vector clocks only if needed | 3-way concurrent divergence that base-rev mis-orders |
+| O-4 | **Persisted derived-tier cost ceiling** (§8.7/§9.1) | per-tenant partition, incremental-maintained, rebuild is fallback | a tenant whose incremental cost still exceeds budget |
+| O-5 | **Axis-interaction completeness** (§6.5) | the named interaction table is the contract; extend deliberately | a real adapter needing an interaction not in the table |
+| O-6 | **Span-address portability across projection** (§7.2) | shard-scoped native-id wrapping now; tumbler later | cross-shard transclusion that native ids can't satisfy |
+| O-7 | **Squash-compaction vs. perfect auditability** (§8.1) | compact the *path*, preserve reachable states; configurable | a compliance need for every intermediate keystroke |
+
+These are the spec-writing inputs for `SHARD-WP-0002`; none blocks the architecture, each
+scopes an implementation spike.
+
+---
+
+## 13. Canonical data flows (the architecture exercised)
 
 **A. Attach a shard.** Adapter binds (chosen attachment mode) → probes/declares a capability
 profile → core registers the shard under a root entity → if not git-native, the coordination
@@ -621,30 +766,38 @@ gated off. History uses paired-text/nbdime per axis 5.
 
 ---
 
-## 13. Key tradeoffs & decisions to confirm
+## 14. Key tradeoffs & decisions
 
-Resolved here:
+Decided:
 
-- **Capability spectra over a verb checklist** — accept richer contract complexity for precise,
-  uniform degradation. (Decided: spectra.)
-- **Derived middle is a cache, not a store** — accept recompute cost for rebuildability,
-  provenance, and graceful degradation. (Decided: cache.)
-- **Default federation = fork+journal over Git** — the home case; other models opt-in. (Decided.)
-- **Execution off by default** — recognise+project always; execute only when gated on. (Decided.)
+- **Capability spectra over a verb checklist** — richer contract for precise, uniform
+  degradation; tamed by an orthogonal core + implied positions + a named interaction table
+  (§6.5). (Decided.)
+- **Three states; derived = f(canonical)** — sharded + coordination canonical, derived
+  disposable (§1). (Decided; supersedes the earlier "edges vs middle" framing.)
+- **Incremental-first, rebuild-as-fallback** — the derived tier is continuously maintained from
+  change events; full rebuild is rare and need not be cheap (§8.7). (Decided — resolves the
+  earlier "union graph persistence" open item: **persisted, per-tenant, incrementally
+  maintained, rebuildable**, §9.1.)
+- **Identity ≠ fingerprint** — page identity is a stable handle; fingerprints are for
+  equivalence (§7.2). (Decided.)
+- **Consistency = read-your-writes (journal) + causal (derived) + eventual/freshness-labelled
+  (shards)**; conflict detection/representation is core, resolution is policy (§8.6). (Decided.)
+- **Address scheme** — shard-scoped native-id wrapping now; portable tumbler later (§7.2, O-6).
+  (Decided.)
+- **Default federation = fork+journal over Git**; other models opt-in (§8.3). (Decided.)
+- **Execution off by default** — recognise+project always; execute only when gated (§8.5). (Decided.)
+- **Derived tier is tenant-partitioned** (I-13, §9.1). (Decided.)
 
-Open — to confirm before SHARD-WP-0002 spec-writing finalises:
+Still open (carried to §12 / policy):
 
-1. **Union graph persistence.** Pure-recompute (simplest, honours I-2 hardest) vs a persisted-
-   but-disposable cache (faster, must guarantee rebuild equivalence). *Recommendation:
-   persisted-but-disposable with a `rebuild` that must reproduce it byte-for-byte.*
-2. **Address scheme.** Ship shard-scoped native-id wrapping now and treat a portable tumbler as
-   a later capability, or design the tumbler up front? *Recommendation: wrap native ids now.*
-3. **L1 "attributed-but-open" mode** — ship it or jump L0→L2? (Carried from ArchitectureBlueprint.)
-4. **Per-page ACL default** — off (per-shard/namespace) confirmed; revisit only if demand appears.
+1. **L1 "attributed-but-open" mode** — ship it or jump L0→L2? (Carried from ArchitectureBlueprint.)
+2. **Per-page ACL default** — off (per-shard/namespace) confirmed; revisit only if demand appears.
+3. The implementation spikes in **§12** (O-1…O-7).
 
 ---
 
-## 14. What this architecture is *not*
+## 15. What this architecture is *not*
 
 - Not a wiki engine, UI, or rendering pipeline (those are consumers at L6).
 - Not a canonical-source-of-truth — shards keep sovereignty; the middle is derived.
@@ -655,10 +808,16 @@ Open — to confirm before SHARD-WP-0002 spec-writing finalises:
 
 ---
 
-## 15. Traceability
+## 16. Traceability
 
-- **INTENT** — every invariant in §2 cites an INTENT principle or boundary; no invariant
-  contradicts the Stability Note.
+- **INTENT** — every invariant in §2 (I-1…I-13) cites an INTENT principle or boundary; no
+  invariant contradicts the Stability Note.
+- **Review & hardening** — this revision folds in
+  `history/260615-core-architecture-blueprint-review.md` via **`SHARD-WP-0005`**: A-1→§1/§3/§4
+  (three-state re-frame), B-1→§7.2 (identity vs equivalence), B-2→§8.6 (consistency/conflict),
+  B-3→§9.1+I-13 (tenant isolation), C-1/C-2→§8.7/§8.8 (incremental + indexed + invalidation),
+  C-3→§8.1 (history scaling), D-1→§6.5 (orthogonal core), D-2→§7.3 (layered provenance),
+  D-3→§8.4 (common-case projection), D-4→§11 (policy module + rail discipline); open items→§12.
 - **Research** — §6 (spectra) ← `260614-shard-spectrum-synthesis` v3; §8.3 (federation
   taxonomy) ← v3 §2.5; §8.4–§8.5 (two-axis projection, view registry, computational scope) ←
   `260614-computational-page-model-synthesis`; §7 page shapes ← the engine + modern-tool +
@@ -676,7 +835,7 @@ Open — to confirm before SHARD-WP-0002 spec-writing finalises:
 
 ---
 
-## 16. Stability note
+## 17. Stability note
 
 This document defines shard-wiki's **internal** architecture; it may evolve as the spec
 workplans land. But the **thesis (§1)**, the **invariants (§2)**, and the **dual narrow waist

workplans/SHARD-WP-0005-architecture-hardening.md

@@ -4,7 +4,7 @@ type: workplan
 title: "core architecture hardening (blueprint review fixes)"
 domain: whynot
 repo: shard-wiki
-status: active
+status: done
 owner: tegwick
 topic_slug: whynot
 created: "2026-06-15"
@@ -129,7 +129,7 @@ operational expectation).
 
 ```task
 id: SHARD-WP-0005-T5
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "b031715c-00d0-4a0a-99f1-4e74a236d04b"
 ```
@@ -146,7 +146,7 @@ operational-envelope axis (rate-limited shards favour event-driven + long TTL).
 
 ```task
 id: SHARD-WP-0005-T6
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "f04ce101-0d95-4e1a-ab8b-80dfff9d2dda"
 ```
@@ -164,7 +164,7 @@ implied-position rules. Update §6.
 
 ```task
 id: SHARD-WP-0005-T7
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "b84b790f-d208-4a76-af9f-1402a6a87ac1"
 ```
@@ -187,7 +187,7 @@ Fix findings **D-2, D-3, D-4** together (the structural elegance/efficiency clus
 
 ```task
 id: SHARD-WP-0005-T8
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "6ce3584f-ffa1-4568-8175-460adc8e2083"
 ```
@@ -207,7 +207,7 @@ Fix findings **B-3, C-3**:
 
 ```task
 id: SHARD-WP-0005-T9
-status: todo
+status: done
 priority: medium
 state_hub_task_id: "c876a63c-4cfd-4794-be29-1d8226643c82"
 ```