research: Joplin deep dive (SQLite-local/Markdown-on-sync, interchange-format attach, E2EE content opacity); UC-60/61

Architecturally distinct from the Obsidian/Roam/Notion trio: content is
Markdown, the local store is SQLite, and the sync representation is a
folder of per-item Markdown+metadata files on a backend of choice
(filesystem, WebDAV, Nextcloud, Dropbox, OneDrive, S3, Joplin
Server/Cloud). Two new findings: (1) attach the sync/interchange mirror,
not the app or the SQLite store, offline and app-independent, landing on
INTENT's WebDAV/Nextcloud/S3 backends (UC-60, distinct from native
on-disk store UC-40 and app-files UC-53); (2) E2EE => content opacity, a
proposed twelfth capability spectrum for encrypted-at-rest shards (UC-61).
Also: Joplin is the file-sync-daemon boundary case (attach the mirror as
pages, never re-sync); store-minted page-level :/id links (addressing
spectrum middle); dual surface (plugin host + local Data API on
localhost:41184). Enriched UC-31/36/38/40/51/55. Catalog now 61 UCs.
Architecture for SHARD-WP-0002 T11/T14: interchange-format attach,
content-opacity field, local-REST sub-mode, format-aware file-store
profiles.

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

spec/UseCaseCatalog.md

@@ -7,8 +7,8 @@ Promoted from `research/260608-c2-wiki-origins/`,
 `research/260608-wikiengines-overview/`, `research/260613-xwiki-deep-dive/`,
 `research/260613-twiki-deep-dive/`, `research/260613-foswiki-deep-dive/`,
 `research/260614-xanadu-deep-dive/`, `research/260614-zigzag-deep-dive/`,
-`research/260614-roam-deep-dive/`, `research/260614-obsidian-deep-dive/`, and
-`research/260614-notion-deep-dive/`.
+`research/260614-roam-deep-dive/`, `research/260614-obsidian-deep-dive/`,
+`research/260614-notion-deep-dive/`, and `research/260614-joplin-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
 ## Conventions
@@ -181,7 +181,9 @@ concrete push transport: an engine event bus (`ObservationManager`
 (`research/260613-xwiki-deep-dive/findings.md` §2.5, §8 Q4). Notion adds **webhooks**
 (2026) delivering page/database change events — a SaaS push transport, weighed against
 eventual consistency and the rate limit (`research/260614-notion-deep-dive/findings.md`
-§4).  
+§4). **Joplin** is poll-based and turns concurrent edits into **conflict notes**
+(keep-both, not silent overwrite) — conflict-as-data, links UC-07
+(`research/260614-joplin-deep-dive/findings.md` §2).  
 **Priority:** Later
 
 ### UC-32 — Transclude remote span with live freshness
@@ -274,7 +276,9 @@ onto a vault that has none natively (`research/260614-obsidian-deep-dive/finding
 §5, §7), exactly the gap the coordination journal fills as core. **Notion** is the
 closed-SaaS instance: internal page history bounded by plan, **not portable** and not
 exported as git (`research/260614-notion-deep-dive/findings.md` §4) — a supplementation
-case like Confluence/MediaWiki, not an import case.  
+case like Confluence/MediaWiki, not an import case. **Joplin** keeps internal note
+revisions locally, likewise not portable (`research/260614-joplin-deep-dive/findings.md`
+§1) — supplement.  
 **Priority:** Later
 
 ### UC-37 — Attach a static engine export as a read-only backup shard
@@ -310,7 +314,11 @@ Generalizes beyond XWiki: TWiki's plugin handler API (`beforeSaveHandler`,
 template: an extension default-exports `onload`/`onunload` and drives
 `window.roamAlphaAPI` read (`q`/`pull`) + write (`block.*`/`page.create`)
 (`research/260614-roam-deep-dive/findings.md` §5) — note Roam's API runs *inside* the
-client, so write-through requires in-engine hosting (findings §11 Q2).  
+client, so write-through requires in-engine hosting (findings §11 Q2). **Joplin** offers
+*two* surfaces: an in-app plugin host (`joplin.data`/`workspace`/`contentScripts`) **and**
+a **local Data API** (REST on `localhost:41184`, token, app-running) — a local-REST attach
+sub-mode between in-engine host and external API (UC-57,
+`research/260614-joplin-deep-dive/findings.md` §4).  
 **Priority:** Later
 
 ### UC-39 — Attach a wiki-as-application-platform shard (pages as typed records)
@@ -350,7 +358,10 @@ direct-attach target than RCS diffs (`research/260613-foswiki-deep-dive/findings
 §2.2). An **Obsidian vault** is the cleanest case of all — a plain Markdown folder,
 Markdown-first and git-friendly — and uniquely **dual-attachable**: file-store direct
 *or* via an in-app plugin adapter for write-through + live file events (UC-53,
-`research/260614-obsidian-deep-dive/findings.md` §4, §10).  
+`research/260614-obsidian-deep-dive/findings.md` §4, §10). Counter-example: **Joplin**'s
+native store is a **DB** (SQLite), so its file-attach surface is the *sync/interchange
+mirror* on a WebDAV/S3 target, not the native store — see UC-60
+(`research/260614-joplin-deep-dive/findings.md` §2).  
 **Priority:** Later
 
 ### UC-41 — Import an engine's native file history into the coordination journal
@@ -517,7 +528,10 @@ a shard-scoped address to avoid cross-shard collision and survive projection (fi
 live in the Markdown text — git-diffable and portable (survives a file copy) but opt-in
 (`research/260614-obsidian-deep-dive/findings.md` §2), vs Roam's mandatory DB-minted
 UID. Notion is a second store-minted case: per-block **UUID v4**, exposed via the REST
-API (`research/260614-notion-deep-dive/findings.md` §1).  
+API (`research/260614-notion-deep-dive/findings.md` §1). **Joplin** marks the spectrum's
+middle: a store-minted **page-level** 32-char ID with `:/<id>` links that survive
+rename/move (`research/260614-joplin-deep-dive/findings.md` §1) — coarser than a block
+UUID, more stable than a path.  
 **Priority:** Later
 
 ### UC-52 — Delegate derived views to a shard's native query engine
@@ -582,7 +596,9 @@ content in "Markdown" vaults (`research/260614-obsidian-deep-dive/findings.md`
 Extends UC-34's no-lossy-flatten rule from structured-text to binary/spatial content.
 Pushes the **wiki page model**: page vs. typed asset vs. opaque blob — a page-model
 decision, not just adapter config (findings §10). JSON Canvas is an open format worth
-first-class support.  
+first-class support. **Joplin** resources (attachments, each with an ID, linked `:/<id>`)
+are the same demand in a sync-mirror shard (`research/260614-joplin-deep-dive/findings.md`
+§5).  
 **Priority:** Later
 
 ### UC-56 — Publish a curated projection to an external read-only target
@@ -652,6 +668,42 @@ provenance/sidecar. Embodies union-without-erasure by making *loss of fidelity*
 Open: report format and where it surfaces (findings §10 Q3).  
 **Priority:** Later
 
+### UC-60 — Attach a tool's documented sync / interchange representation
+
+**Actor:** Maintainer  
+**Goal:** Attach a backend's documented **sync or interchange representation** — a folder
+of per-item files a tool writes to a third-party storage target — as a file-store shard,
+without running the tool and without touching its native store.  
+**Source:** joplin, intent  
+**Notes:** Joplin's native store is **SQLite**, but on sync it serializes to per-item
+**Markdown+metadata files** on filesystem / WebDAV / **Nextcloud** / Dropbox / OneDrive /
+**S3** (`research/260614-joplin-deep-dive/findings.md` §2). That mirror is attachable
+offline and app-independently *if* the adapter understands the documented item format
+(body + metadata footer, `:/id` links, resources). **Distinct from UC-40** (native
+on-disk store) and **UC-53** (app files *are* the store): here the attach surface is the
+**interchange/sync representation**, and the tool **owns the format** → treat
+read/projection/overlay-mostly, never re-sync (INTENT not-a-file-sync-daemon). Realizes
+INTENT's WebDAV/Nextcloud/S3 participants. Needs a **format profile** in the adapter
+(findings §8).  
+**Priority:** Later
+
+### UC-61 — Attach an encrypted-at-rest shard with content opacity
+
+**Actor:** Maintainer  
+**Goal:** Attach a shard whose stored content is encrypted (E2EE sync target) and
+participate correctly when bodies are undecryptable — as backup / mirror / structure-
+shell — without ever presenting ciphertext as readable content.  
+**Source:** joplin, intent  
+**Notes:** Joplin encrypts items **before** they leave the device, so the sync target
+holds ciphertext (`research/260614-joplin-deep-dive/findings.md` §3). Introduces a new
+capability dimension — **content opacity** (`plaintext → encrypted-at-rest/opaque`) —
+proposed as a twelfth spectrum for the adapter contract (findings §8; extends
+`research/260614-shard-spectrum-synthesis/findings.md` §2). Graceful degradation extreme:
+IDs/counts/timestamps may be visible while bodies are opaque; never silently surface
+undecryptable content. Open: does shard-wiki ever hold keys, or only treat such shards as
+opaque backups (findings §9 Q1)? Ties [[shard-wiki-auth-in-core-decision]].  
+**Priority:** Later
+
 ---
 
 ## B. Knowledge work and collaboration
@@ -899,6 +951,8 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-57 | | | | ◊ | ✓ |
 | UC-58 | | | | ◊ | ✓ |
 | UC-59 | | | | ◊ | ✓ |
+| UC-60 | | | | ‖ | ✓ |
+| UC-61 | | | | ‖ | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -1151,6 +1205,36 @@ an operational-envelope capability section (rate limit, consistency class, paylo
 push-vs-poll), access-grant semantics, a translation-fidelity capability, and the
 three-way attachment-mode taxonomy.
 
+### joplin mapping
+
+(‖ UC-60–UC-61 are placed in the **wikiengines** matrix column as the nearest existing
+source — Joplin is a shipped tool — but their true lineage is the **Joplin deep dive**,
+`research/260614-joplin-deep-dive/findings.md`.)
+
+| Joplin mechanism (findings §) | Catalog UC |
+|-------------------------------|------------|
+| SQLite-local, Markdown-on-sync; per-item files on WebDAV/Nextcloud/S3 (§2) | UC-60 (new) |
+| E2EE → ciphertext at rest; content opacity (§3) | UC-61 (new) |
+| Store-minted page-level 32-char ID, rename-stable `:/id` links (§1) | UC-51 (enriched) |
+| Native store is a DB; attach surface is the sync mirror, not the store (§2) | UC-40 (enriched) |
+| Internal revisions, not portable (§1) | UC-36 (enriched) |
+| Plugin host + local Data API (localhost:41184, token) (§4) | UC-38 (enriched; links UC-57) |
+| Resources (attachments) with IDs (§5) | UC-55 (enriched) |
+| Poll sync; conflict notes (keep-both) (§2) | UC-31 (enriched; links UC-07) |
+
+Note: Joplin is the **SQLite-local / Markdown-on-sync** case — its best attach surface is
+the **interchange/sync representation** (per-item files on a WebDAV/Nextcloud/S3 target),
+offline and app-independent, landing on INTENT's named backends. It adds two findings for
+the adapter contract: the **interchange/sync-representation attach surface** (distinct
+from native on-disk store UC-40 and app-files UC-53), and **content opacity** (a proposed
+twelfth capability spectrum for encrypted-at-rest shards, extending
+`research/260614-shard-spectrum-synthesis/findings.md` §2). **Boundary recorded:** Joplin
+is a **file-sync daemon over one store**; shard-wiki attaches its **mirror as pages** and
+never re-syncs, and treats the DB-local store and encrypted content as opaque
+(`research/260614-joplin-deep-dive/findings.md` §6). Architecture logged for
+`SHARD-WP-0002` (T11/T14): interchange-format attach, content-opacity field, local-REST
+sub-mode, format-aware file-store profiles.
+
 ---
 
 ## Open questions
@@ -1180,4 +1264,8 @@ three-way attachment-mode taxonomy.
     wiki scale, or do we default such shards to read/projection/overlay/backup? (Notion
     dive §10 Q1; ties UC-57.)
 13. How are **inter-database relations** (UC-58) represented in the union — typed links
-    in the link graph, a separate relation index (cf. ZigZag many-to-many), or both?
+    in the link graph, a separate relation index (cf. ZigZag many-to-many), or both?
+14. For an **encrypted shard** (UC-61), what is visible without keys (IDs/structure vs
+    nothing), and does shard-wiki ever hold keys or only treat it as an opaque backup?
+15. Is writing to a tool's **sync mirror** (UC-60) ever safe, or are interchange-format
+    shards read/projection/overlay-only by policy? (Joplin dive §9.)