research: MojoMojo deep dive (Perl Catalyst DB-backed wiki); UC-81

SHARD-WP-0003 T8. Classic relational-DB-backed wiki: Catalyst/DBIx::Class app,
pages + path tree + full history in SQL tables, Markdown body in a column, no
file store and no content API. Anchors the direct-DB-read binding (map schema
-> page model + journal); DB version rows = a third history source beside git
commits and RCS files. UC-81. Enriched UC-02/40/36/34. Marks T8 done.
Feeds SHARD-WP-0002 T14/T13/T11.

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

spec/UseCaseCatalog.md

@@ -17,7 +17,8 @@ Promoted from `research/260608-c2-wiki-origins/`,
 `research/260614-forge-wikis-deep-dive/`, and
 `research/260614-tiddlywiki-deep-dive/`, and
 `research/260614-ikiwiki-deep-dive/`, and
-`research/260614-quip-deep-dive/`.
+`research/260614-quip-deep-dive/`, and
+`research/260614-mojomojo-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
 ## Conventions
@@ -52,7 +53,11 @@ history, not gatekeeping. Aligns with L0 in `spec/ArchitectureBlueprint.md`.
 **Goal:** Attach a repository, directory, or other backend as a shard of a root entity.  
 **Source:** intent, yawex  
 **Notes:** yawex `Conf::TestWiki / FriendsWiki` foreshadows multiple roots/shards.
-Preserve shard sovereignty and adapter capability profile.  
+Preserve shard sovereignty and adapter capability profile. Attach paths now span a wide
+range: file-store clone (UC-40/UC-76), in-engine host (UC-38/50), external-API (UC-57/80),
+CRDT-replica (UC-64), P2P (UC-65), and — for a **DB-backed engine with no file store/API** —
+**direct relational read** of its schema (UC-81,
+`research/260614-mojomojo-deep-dive/findings.md` §2).  
 **Priority:** MVP
 
 ### UC-03 — Project a remote shard page locally
@@ -1121,6 +1126,24 @@ lossy export. Feeds SHARD-WP-0002 T11 (payload-format + content-opacity), T12 (i
 objects), T14.  
 **Priority:** Later
 
+### UC-81 — Attach a DB-backed wiki with no file store/API by reading its store directly
+
+**Actor:** Maintainer / adapter  
+**Goal:** Attach a **relational-DB-backed wiki with no file store and no content API**
+(MojoMojo) by **reading its database directly** — mapping the **page + version tables** to
+the wiki page model and **importing DB-resident history** to the coordination journal.  
+**Source:** wikiengines, intent  
+**Notes:** MojoMojo is a Perl Catalyst / DBIx::Class app whose pages, path tree, and full
+revision history live in **SQL tables** (`page`/`page_version`/`content`/`attachment`); the
+body is **Markdown in a column** (`research/260614-mojomojo-deep-dive/findings.md` §1, §2).
+The **direct-DB-read** binding is the archetype for DB-backed engines lacking file/API
+access (HTML scrape is the lossy fallback). **DB version rows** are a third history source
+beside git commits and RCS files (T13). Caution: reading a third-party schema is a
+**versioned coupling** that can drift across engine versions (UC-43); writing by direct DB
+risks app invariants → default read/projection/overlay. Feeds SHARD-WP-0002 T14 (direct-DB
+binding), T13.  
+**Priority:** Later
+
 ---
 
 ## B. Knowledge work and collaboration
@@ -1398,6 +1421,7 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-78 | | | | ⊡ | ✓ |
 | UC-79 | | | ✓ | ⊟ | ✓ |
 | UC-80 | | | | ◧ | ✓ |
+| UC-81 | | | | ⊙ | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -1985,6 +2009,31 @@ default to read/projection/overlay given rate limits + lossy export. Architectur
 lossy-exportable" content-opacity tier, inline-embedded-object page model, enterprise-ACL
 binding.
 
+### mojomojo mapping
+
+(⊙ UC-81 lineage = the **MojoMojo deep dive**, `research/260614-mojomojo-deep-dive/findings.md`.)
+
+| MojoMojo mechanism (findings §) | Catalog UC |
+|---------------------------------|------------|
+| Catalyst/DBIx::Class app; pages + history in SQL tables; no file store/API (§1, §2) | UC-81 (new) |
+| Direct relational read (page/version tables) vs file attach (§2) | UC-02 / UC-40 (enriched) |
+| DB version rows = history source for the journal (§1, §4) | UC-36 (enriched) |
+| Relational page rows + parent/lineage as structure (§1) | UC-34 (enriched) |
+| Markdown body in a DB column → extract, minimal translation (§1) | links UC-42 |
+| Schema is a versioned coupling that can drift (§4) | links UC-43 |
+
+Note: MojoMojo is the **classic relational-DB-backed wiki** — a Perl Catalyst / DBIx::Class
+app whose pages, path tree, and full revision history live in **SQL tables**, with **no file
+store and no content API**. It anchors the **direct-DB-read** binding: the canonical store is
+a relational schema, and the adapter maps **schema → wiki page model + journal** (the body is
+**Markdown in a column**, so extraction not format-translation is the work). **DB version
+rows** become a third **history source** beside git commits and RCS files (T13). **Boundary
+recorded:** reading a third-party schema is a **versioned coupling** that can drift (UC-43),
+and writing by direct DB risks app invariants → default read/projection/overlay; HTML scrape
+is the lossy last resort. Architecture logged for `SHARD-WP-0002` (T14/T13/T11): direct-DB
+binding (or external-store-via-SQL-schema sub-mode), DB-version-row history import, sparse
+"has-readable-DB" capability profile.
+
 ---
 
 ## Open questions
@@ -2063,5 +2112,9 @@ binding.
     sub-object with provenance (preferred) or a flattened static Markdown table — can
     overlays target a spreadsheet cell or only prose — and given HTML-only lossy interchange,
     is Quip ever write-through or read/projection/overlay/backup by default? (Quip dive §8.)
+29. Does shard-wiki sanction **direct third-party DB reads** as a binding (UC-81), or
+    restrict them (schema coupling/drift, UC-43) to a best-effort mode — and is
+    **write-through by direct DB** ever allowed, or are DB-backed no-API engines
+    read/projection/overlay/backup only? (MojoMojo dive §7.)
 23. How does shard-wiki **honor/surface a shard's path-based access rules** (UC-06) in a
     projection without re-implementing its ACL engine? (Wiki.js dive §9.)