research: Oddmuse deep dive (minimal single-script wiki); UC-82

SHARD-WP-0003 T7. The minimal file-store floor: one Perl CGI script over
plain-text page files + a keep/ revision dir, no DB/API. Anchors the
graceful-degradation baseline / minimal capability-profile floor -- every
richer shard is measured against it; capability-awareness in its purest form
(profile must express absence; truncated history reported honestly). UC-82.
Enriched UC-40/01/36/41. Marks T7 done. Feeds SHARD-WP-0002 T11/T13.

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

research/260614-oddmuse-deep-dive/README.md

@@ -0,0 +1,13 @@
+# 260614 — Oddmuse deep dive
+
+Deep dive on **Oddmuse**: a deliberately minimal wiki — a **single Perl CGI script** over
+**plain-text page files** (one file per page, old revisions in a `keep/` dir), no database.
+The low-complexity **file-store floor** — useful as the **minimal-adapter / graceful-
+degradation baseline** of the capability profile.
+
+- `findings.md` — the minimal model, storage layout, capability profile, INTENT mapping, UC
+  seed (UC-82), architecture notes for SHARD-WP-0002, open questions, sources, traceability.
+
+Catalog yield: UC-82 (attach a **minimal flat-file wiki** — plain-text page files + a simple
+revision dir — as the **graceful-degradation baseline / minimal capability-profile floor**).
+Enriched UC-40/01/36/41. Feeds SHARD-WP-0002 T11 (minimal capability profile).

research/260614-oddmuse-deep-dive/findings.md

@@ -0,0 +1,124 @@
+# Oddmuse — deep dive (findings)
+
+**Date:** 2026-06-14 · **Source:** SHARD-WP-0003 T7 · **Subject:** Oddmuse, Alex Schroeder's
+minimal single-script wiki (EmacsWiki, Community Wiki).
+
+## Why this dive
+
+After the structure/graph/SaaS far-ends, Oddmuse anchors the **opposite** corner: the
+*minimal* file-store wiki. It is the reference for shard-wiki's **graceful-degradation**
+promise — *a limited backend must still be usable* — and defines the **floor** of the
+capability profile (T11): what the simplest possible real wiki looks like as a shard.
+
+## 1. The minimal model
+
+- **One Perl CGI script** (`wiki.pl`) is the whole engine — drop it on any CGI host. No
+  framework, no database, minimal dependencies.
+- **Plain-text page files**: each page is a text file in a **page directory** (`page/`),
+  with a small header of metadata and the body; **old revisions** are kept in a **`keep/`**
+  directory (recent history retained, older optionally expired).
+- **Locking** via lock files; edits append a new keep-revision.
+- **Markup:** simple wiki markup; **CamelCase** and **free links** `[[Like This]]`;
+  InterWiki/near-links; tags and "clusters."
+- **No DB, no API** (beyond the CGI itself); content *is* the files on disk.
+
+## 2. The shard view — the file-store floor
+
+Because pages are **plain-text files on disk**, Oddmuse is **trivially attachable** as a
+**file-store shard** even though the engine offers nothing fancy:
+
+- Read the `page/` files → pages (parse the tiny header + body).
+- Read `keep/` → recent revision history (import to the journal; note it may be **truncated**
+  — older revisions can be expired, so history is *partial*).
+- Write = write a page file + a keep-revision (respecting the lock) — but the engine's own
+  invariants (indexes) mean **write-through is best done via the engine or carefully**.
+
+This is the **minimal capability profile**: file-store, page-granularity, plain-text,
+possibly-truncated history, no query, no structured fields, open editing. Everything richer
+in the synthesis matrix is measured *against this floor*.
+
+## 3. Capability profile (the floor)
+
+| Dimension (synthesis spectrum) | Oddmuse |
+|--------------------------------|---------|
+| Attachment mode | **file-store** (plain-text files); CGI, no API |
+| Addressing granularity | page = file |
+| Content identity | page name = filename |
+| Identity vs placement | name-bound |
+| Structure | none beyond tags/clusters; flat page space |
+| History | **`keep/` revisions — recent, possibly truncated** |
+| Merge model | lock-file; last-writer |
+| Native query | none |
+| Translation | simple wiki markup (→ Markdown translation needed) |
+| Write granularity | page (file) |
+| Operational envelope | a CGI script; tiny |
+| Access grant | open by default (optional password) |
+| Content opacity | transparent text |
+| Provenance | minimal (timestamp, optional username) |
+
+## 4. INTENT mapping
+
+### Reinforcements
+
+- **Graceful degradation** (INTENT): Oddmuse is the *definition* of the limited-backend case
+  — still a perfectly good read/projection/overlay/backup shard via its files.
+- **Union without erasure**: even a minimal shard contributes pages with provenance; its
+  **truncated history** must be surfaced honestly (don't imply full history when `keep/` is
+  partial).
+- **Open wiki** (UC-01): Oddmuse is open-editing by default — the c2-era ethos.
+- **Markdown-first but backend-neutral**: its wiki markup needs translation to the
+  Markdown-first page model (UC-42-style), a small lossy step.
+
+### Divergences (boundaries / notes)
+
+- **Partial history**: `keep/` may expire old revisions — the journal import must record that
+  history is **truncated/partial**, not complete (a freshness/provenance honesty point).
+- **Minimal profile** means many capabilities are simply **absent** — the adapter advertises
+  a sparse profile; the orchestrator must not assume query/structure/locking semantics it
+  doesn't have (T11 capability-awareness in its purest form).
+
+### What to keep
+
+1. **Minimal flat-file wiki as the graceful-degradation baseline** (UC-82): plain-text files
+   + simple revision dir = the floor every richer profile extends.
+2. **Honest partial-history reporting** when a shard's revision store is truncated.
+3. **Sparse capability profile** handling — absence of a capability is first-class (T11).
+
+## 5. UC seed
+
+| # | Seed | Disposition |
+|---|------|-------------|
+| UC-82 | Attach a **minimal flat-file wiki** (plain-text page files + a simple revision dir, Oddmuse) as the **graceful-degradation baseline / minimal capability-profile floor**, surfacing **partial history** honestly | **new** |
+| — | plain-text file-store at the simple end | enrich **UC-40** |
+| — | open-editing wiki | enrich **UC-01** |
+| — | `keep/` plain-text revision history (possibly truncated) | enrich **UC-36** / **UC-41** |
+
+## 6. Architecture notes for SHARD-WP-0002
+
+- **T11 (capability model):** Oddmuse defines the **minimal/floor profile** — file-store,
+  page granularity, plain-text, **partial** history, no query/structure. Validate that the
+  capability vocabulary can express **absence** cleanly and that the orchestrator degrades
+  to read/projection/overlay/backup against it.
+- **History portability (T13):** `keep/` revisions import as journal entries but may be
+  **truncated** — record completeness as metadata (full vs partial history).
+
+## 7. Open questions
+
+1. How does shard-wiki represent a shard with **partial/truncated history** in the journal
+   and provenance UI (UC-24) — explicit "history begins at" marker?
+2. Is write-through to a minimal CGI wiki (write page + keep-revision under its lock) ever
+   sanctioned, or read/projection/overlay/backup only by default?
+
+## 8. Sources
+
+- oddmuse.org — Oddmuse wiki (single-script install, `page/` + `keep/` storage, markup,
+  CamelCase/free links, clusters/tags)
+- EmacsWiki / Community Wiki (Oddmuse in production)
+- prior: `research/260608-c2-wiki-origins/` (open-wiki ethos); `research/260613-twiki-deep-dive/`
+  (file-store + RCS contrast)
+
+## 9. Traceability
+
+New UC **UC-82** carries the marker **⊚** in the wikiengines column of
+`spec/UseCaseCatalog.md`. Enriched: UC-40, UC-01, UC-36, UC-41. Architecture cross-refs:
+SHARD-WP-0002 T11 (minimal/floor profile), T13 (partial-history import).

research/README.md

@@ -34,4 +34,5 @@ when multiple files or sources are involved. Findings here inform `spec/` and
 | 2026-06-14 | `260614-tiddlywiki-deep-dive/` | TiddlyWiki — entire wiki (content + app) in one self-contained HTML file = whole-file write-granularity extreme; Node `.tid` file-per-tiddler substrate (git-diffable); tiddler/field records, filter-expression query; UC-78 |
 | 2026-06-14 | `260614-ikiwiki-deep-dive/` | ikiwiki — wiki compiler: git-canonical Markdown source → static HTML (derived publish/projection); git-distributed clone federation + XML-RPC pinger (third federation flavor); UC-79 |
 | 2026-06-14 | `260614-quip-deep-dive/` | Salesforce Quip — closed-SaaS live docs + embedded spreadsheets/live apps; REST + lossy HTML import/export; Salesforce enterprise ACL; external-API payload-format facet + inline-object page model; UC-80 |
-| 2026-06-14 | `260614-mojomojo-deep-dive/` | MojoMojo — Perl Catalyst/DBIx::Class DB-backed wiki; pages + history in SQL tables, no file store/API → direct-DB-read binding; DB version rows as history source; UC-81 |
+| 2026-06-14 | `260614-mojomojo-deep-dive/` | MojoMojo — Perl Catalyst/DBIx::Class DB-backed wiki; pages + history in SQL tables, no file store/API → direct-DB-read binding; DB version rows as history source; UC-81 |
+| 2026-06-14 | `260614-oddmuse-deep-dive/` | Oddmuse — single Perl CGI, plain-text `page/` files + `keep/` revisions, no DB; the minimal file-store floor / graceful-degradation baseline; partial-history honesty; UC-82 |