research: TiddlyWiki deep dive (single-file wiki, write-granularity extreme); UC-78

SHARD-WP-0003 T3. Whole-file write-granularity anchor: an entire wiki (content
+ app engine) in one self-contained HTML file -> save rewrites the whole file,
no per-page atomicity. Node .tid file-per-tiddler substrate is git-diffable/
fine-grained, so the same engine spans the granularity spectrum by substrate
(cf. Logseq file/DB UC-62, backend-swap UC-43). Tiddler = flexible-field
record (UC-34); filter expressions = native-query tier (UC-52). UC-78
(single-file container-format attach). Enriched UC-35/40/34/52/43. Marks T3
done. Feeds SHARD-WP-0002 T11/T14.

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

spec/UseCaseCatalog.md

@@ -14,7 +14,8 @@ Promoted from `research/260608-c2-wiki-origins/`,
 `research/260614-trilium-deep-dive/`, `research/260614-wikijs-deep-dive/`, and
 `research/260614-federated-wiki-deep-dive/`, and
 `research/260614-wikibase-deep-dive/`, and
-`research/260614-forge-wikis-deep-dive/`.
+`research/260614-forge-wikis-deep-dive/`, and
+`research/260614-tiddlywiki-deep-dive/`.
 See InfoTechPrimers on coulomb.social for use-case catalog conventions.
 
 ## Conventions
@@ -272,7 +273,12 @@ granularity** (per-page / per-file / per-space / append-only). Overlay and
 patch flows must adapt (findings §5 #1). Affects conflict scope and locking. Roam marks
 the **fine extreme** — block-level writes (`block.create/update/move/delete`), the
 opposite of TiddlyWiki's whole-file granularity
-(`research/260614-roam-deep-dive/findings.md` §6).  
+(`research/260614-roam-deep-dive/findings.md` §6). The **TiddlyWiki** dive confirms the
+coarse anchor and its consequence: in single-file mode a save **rewrites the whole HTML
+file**, so an overlay to *any* page **conflicts with any concurrent write** (no per-page
+atomicity) — whereas its Node `.tid` substrate is **file-per-tiddler** (fine), so the *same
+engine* sits at both ends by substrate (UC-78,
+`research/260614-tiddlywiki-deep-dive/findings.md` §1, §3; cf. UC-43/UC-62).  
 **Priority:** Later
 
 ### UC-36 — Supply a git-addressable history to an internal-history engine
@@ -1051,6 +1057,24 @@ external-API host sub-mode (UC-38) beside the file-store attach (UC-76). Feeds
 SHARD-WP-0002 T11 (capability flag), T14 (binding).  
 **Priority:** Later
 
+### UC-78 — Attach a single-file self-contained wiki (whole-file write granularity)
+
+**Actor:** Orchestrator / adapter  
+**Goal:** Attach a **single-file self-contained wiki** (a TiddlyWiki HTML file that bundles
+both content and the app engine) as one shard — **parse the tiddler store out of the
+container**, project pages, and treat **writing as rewriting the whole file**.  
+**Source:** wikiengines, intent  
+**Notes:** Classic TiddlyWiki is *one HTML file* = engine + every tiddler
+(`research/260614-tiddlywiki-deep-dive/findings.md` §1) — the **portability and
+write-granularity extreme**. Write granularity is **whole-file** (the coarsest tier): an
+overlay to any one page still rewrites the entire artifact, so per-page atomicity does not
+exist (T11) — model overlays/locks accordingly, or require the Node.js **`.tid`
+file-per-tiddler** substrate for fine-grained write-through and keep single-file as
+read/projection/backup. Treat the HTML as a **container format** (extract content tiddlers,
+ignore the embedded engine). Feeds SHARD-WP-0002 T11 (whole-file tier), T14 (single-file vs
+`.tid` binding; cf. UC-43/UC-62).  
+**Priority:** Later
+
 ---
 
 ## B. Knowledge work and collaboration
@@ -1325,6 +1349,7 @@ CamelCase and `[[free links]]`. Markdown-first link semantics TBD.
 | UC-75 | | | | ⬡ | ✓ |
 | UC-76 | | | | ⎇ | ✓ |
 | UC-77 | | | | ⎇ | ✓ |
+| UC-78 | | | | ⊡ | ✓ |
 | UC-08 | ✓ | | |
 | UC-09 | ✓ | | |
 | UC-10 | ✓ | | |
@@ -1827,6 +1852,35 @@ overlay→review→apply flow is shard-wiki's to provide. Architecture logged fo
 `SHARD-WP-0002` (T14/T11): `.wiki.git` clone as the canonical file-store attach, wiki API as
 an optional per-forge capability, git log adopted directly as the journal.
 
+### tiddlywiki mapping
+
+(⊡ UC-78 is placed in the **wikiengines** matrix column; lineage = the **TiddlyWiki deep
+dive**, `research/260614-tiddlywiki-deep-dive/findings.md`.)
+
+| TiddlyWiki mechanism (findings §) | Catalog UC |
+|-----------------------------------|------------|
+| One HTML file = engine + all tiddlers; save rewrites whole file (§1) | UC-78 (new) |
+| Whole-file write granularity = coarsest tier; no per-page atomicity (§1, §6) | UC-35 (enriched) |
+| Single HTML file as a container-format file-store shard (§1) | UC-40 (enriched) |
+| Tiddler = flat record with arbitrary fields + tags (§2) | UC-34 (enriched) |
+| Filter expressions `[tag[x]sort[...]]` = native-query tier (§4) | UC-52 (enriched) |
+| Single-file ↔ Node `.tid` file-per-tiddler substrate swap (§3) | UC-43 (enriched); links UC-62 |
+| Transclusion `{{tiddler}}` / `{{tiddler!!field}}` (§2) | links UC-32 |
+| Identity = `title` (file-local) (§2, §5) | links UC-25 |
+
+Note: TiddlyWiki is the **write-granularity and portability extreme** — a complete wiki
+(content **plus** the app engine) in **one self-contained HTML file**, where every save
+**rewrites the whole file** (whole-file write granularity, the coarsest tier: no per-page
+atomicity — model overlays/locks accordingly). Its Node.js substrate stores **one `.tid`
+file per tiddler**, git-diffable and fine-grained — so TiddlyWiki **spans the granularity
+spectrum by substrate** exactly as Logseq spans file/DB (UC-62) and UC-43 anticipates. The
+tiddler is a **flexible record with arbitrary fields** (UC-34), and **filter expressions**
+are a real native-query tier (UC-52). **Boundary recorded:** treat the single HTML file as a
+**container format** — extract content tiddlers, ignore the embedded engine; prefer the
+`.tid` substrate for fine-grained write-through, single-file as read/projection/backup.
+Architecture logged for `SHARD-WP-0002` (T11/T14): whole-file as the coarsest write tier,
+single-file-container vs `.tid`-dir dual binding.
+
 ---
 
 ## Open questions
@@ -1894,5 +1948,8 @@ an optional per-forge capability, git log adopted directly as the journal.
     git+Markdown adapter with the **forge wiki repo** shard (parameterized by repo/path), or
     stay distinct? Since forge wikis lack wiki-MRs, does shard-wiki supply the
     overlay→review→apply layer? (Forge-wikis dive §8.)
+26. For a **single-file wiki** (UC-78), does shard-wiki support per-page overlays by
+    buffering and re-serializing the whole file, or require the Node `.tid` substrate for
+    write-through and treat single-file as read/projection/backup only? (TiddlyWiki dive §9.)
 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.)