2026-06-14 18:28:06 +02:00
parent 4543f5dc43
commit 9b5defa6d8
3 changed files with 413 additions and 4 deletions
							
							
								
							
							
						
@@ -22,7 +22,7 @@ Learnings update both SCOPE and INTENT where necessary.
| 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 deep dives & shard-spectrum synthesis (`research/260614-*/`) |
| Demand | NetKingdom integration asks captured, not yet negotiated |
| Spec | Architecture blueprint drafted; UseCaseCatalog 69 UCs from research; PRD/TSD scaffolds |
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract) |
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract); `SHARD-WP-0003` active (9 engine dives); `SHARD-WP-0004` active (8 computational-knowledge dives) |
## In Scope (today)
							
								
							
							
								
							
							
						
@@ -55,6 +55,11 @@ live in core.
Design work is tracked in `workplans/SHARD-WP-0001-yawex-requirements.md`
(yawex-derived resolution, namespaces, overlays) and
`workplans/SHARD-WP-0002-federation-architecture.md` (federation architecture,
decisions, tradeoffs). Specification outputs land in `spec/`. Inbound
integration asks remain in `demand/` until reviewed and promoted into spec or
workplans.
decisions, tradeoffs). Research continues under
`workplans/SHARD-WP-0003-engine-dives-batch.md` (remaining new-insight wiki
engines + git-forge wikis + classic engines) and
`workplans/SHARD-WP-0004-computational-knowledge-systems.md` (literate
programming, computational notebooks, live-coding REPLs, image-based/moldable
environments — the executable/computational page-model thread). Specification
outputs land in `spec/`. Inbound integration asks remain in `demand/` until
reviewed and promoted into spec or workplans.
							
							
							
						
@@ -0,0 +1,205 @@
---
id: SHARD-WP-0003
type: workplan
title: "wiki-engine deep-dive batch (new-insight + git-forge + classic engines)"
domain: whynot
repo: shard-wiki
status: active
owner: tegwick
topic_slug: whynot
created: "2026-06-14"
updated: "2026-06-14"
---
# SHARD-WP-0003 — wiki-engine deep-dive batch
## Goal
Close the remaining coverage gaps in the wiki-engine research set. Each task is one
**deep dive**: persist a research memo, promote/enrich the use-case catalog, and log any
adapter-contract architecture notes for `SHARD-WP-0002`. The set was chosen (per the
2026-06-14 coverage review against `research/260614-shard-spectrum-synthesis/findings.md`)
to favour engines that promise **genuinely new architecture** over ones that merely
reinforce existing families, plus the INTENT-named git-forge wikis and four additional
engines requested for breadth/lineage.
Each dive follows the established tradition (cf. the 260613/260614 dives): a
`research/<yymmdd>-<slug>-deep-dive/` dir with `README.md` + `findings.md`; new UCs and
enrichments promoted to `spec/UseCaseCatalog.md` (with a per-source mapping subsection,
traceability rows, and header update); `research/README.md` and `SCOPE.md` updated;
commit + state-hub sync.
## Context
- Coverage review: `research/260614-shard-spectrum-synthesis/findings.md` (v2) — the
  shard family matrix and thirteen spectra define what "new insight" means here.
- Use cases: `spec/UseCaseCatalog.md` (currently UC-26–UC-69 from research).
- Adapter contract: `workplans/SHARD-WP-0002-federation-architecture.md` (T11–T16) —
  dives that touch the contract feed it; a **re-synthesis** may be warranted after the
  batch (see Acceptance).
- Prior engine dives: `research/260613-{xwiki,twiki,foswiki}-deep-dive/`,
  `research/260614-wikijs-deep-dive/` (storage-module prior art).
**Non-goal:** Implement anything. This workplan produces research + catalog updates only.
---
## Federated Wiki — federation model (fork / journal / happenings)
```task
id: SHARD-WP-0003-T1
status: todo
priority: high
```
Deep-dive Ward Cunningham's **Federated Wiki** (Smallest Federated Wiki). Distinctive
angle: it is a **federation model**, not just a shard — fork-with-provenance, the
per-page **JSON journal** (ordered actions), the **story** (typed item array), and
**happenings** (bounded collaborations). This is prior art for shard-wiki's *coordination
layer itself*, complementing the federation track. Already touched in
`research/260608-federation-concepts/` §3 — go deeper into the data model and protocol.
Map to UC-26 (fork), UC-28 (carry-forward), UC-30 (time-bounded space), UC-05/27 (union/
chorus); feed `SHARD-WP-0002` T1–T5.
## Wikibase / Wikidata — RDF entity-statement knowledge graph
```task
id: SHARD-WP-0003-T2
status: todo
priority: high
```
Deep-dive **Wikibase** (the engine behind **Wikidata**). Distinctive angle: an
**entity-statement (RDF-ish) data model** — items, properties, statements with
qualifiers and references — plus **SPARQL** query. This is a *new far end* of the
structure and native-query spectra (beyond Notion's DB / XWiki XObjects): a true typed
knowledge graph with provenance-bearing statements. Map to/enrich UC-34, UC-58 (typed
records + relations), UC-52 (native query → SPARQL), UC-24 (statement-level provenance);
feed `SHARD-WP-0002` T12/T16.
## TiddlyWiki — the self-contained single-file wiki
```task
id: SHARD-WP-0003-T3
status: todo
priority: medium
```
Deep-dive **TiddlyWiki**. Distinctive angle: an **entire wiki in one self-contained HTML
file** (tiddlers + the app), the **whole-file write-granularity** anchor already named in
the synthesis matrix, with TiddlyWeb / Node.js sync variants and a tiddler/field data
model. The portability/granularity extreme. Enrich UC-35 (write granularity), UC-40
(file-store), UC-34 (tiddler fields); confirm the single-file shard attach story; feed
`SHARD-WP-0002` T11/T14.
## ikiwiki — compile-to-static, git-backed, distributed peer wikis
```task
id: SHARD-WP-0003-T4
status: todo
priority: medium
```
Deep-dive **ikiwiki**. Distinctive angle: a wiki **compiled to static HTML** from a
**git-backed** source, with **distributed** operation (push/pull between wiki clones,
edit-triggered pingers). Referenced in `260608-federation-concepts/` — go deeper into the
git-distributed federation + static-publish model. Map to/enrich UC-31 (subscribe/ping),
UC-56 (outbound publish), UC-37 (static), UC-33 (git-branch space); feed `SHARD-WP-0002`
T4/T6.
## Gitea / GitLab / GitHub wikis — git-forge-hosted Markdown wikis
```task
id: SHARD-WP-0003-T5
status: todo
priority: high
```
Deep-dive the **git-forge wikis** (Gitea, GitLab, GitHub) as one grouped memo. Distinctive
angle: each is a **git repo of Markdown** exposed through a forge (clone the wiki repo
directly *or* use the forge API). INTENT explicitly names **Gitea wikis** as a shard
participant, so this confirms a first-class backend. Compare with Wiki.js's
engine-maintained git mirror (UC-68): here the git repo *is* the native store. Enrich
UC-40 (file-store native), UC-02 (attach), UC-68 (git attach), UC-38 (forge API host);
feed `SHARD-WP-0002` T14.
## Salesforce Quip — collaborative live docs + embedded spreadsheets
```task
id: SHARD-WP-0003-T6
status: todo
priority: medium
```
Deep-dive **Salesforce Quip**. Distinctive angle: a **closed SaaS** of live collaborative
documents with **embedded spreadsheets/live apps** and a REST API, tied to Salesforce
identity/permissions. A hosted-collab contrast point (vs Notion): document+spreadsheet
hybrid, enterprise auth. Enrich UC-57 (external-API), UC-55/58 (embedded
spreadsheet/structured content), UC-36 (internal history), UC-06 (enterprise ACL); feed
`SHARD-WP-0002` T11/T14.
## Oddmuse — minimalist single-script Perl wiki
```task
id: SHARD-WP-0003-T7
status: todo
priority: low
```
Deep-dive **Oddmuse**. Distinctive angle: a **single Perl script**, **plain-text page
files**, deliberately minimal — the low-complexity file-store end. Useful as a
graceful-degradation / minimal-adapter reference. Enrich UC-40 (file-store), UC-01 (open
wiki), UC-36/41 (plain-text history); feed `SHARD-WP-0002` T11 (minimal capability
profile).
## Mojomojo — Perl Catalyst DB-backed wiki
```task
id: SHARD-WP-0003-T8
status: todo
priority: low
```
Deep-dive **MojoMojo**. Distinctive angle: a **Perl Catalyst / DBIx::Class** DB-backed
wiki with page hierarchy, attachments, and inline editing — a classic MVC DB engine
contrast to the file-store classics. Enrich UC-02/40 (DB vs file attach), UC-36 (DB
history), UC-34 (structured fields); feed `SHARD-WP-0002` T13/T14.
## UseModWiki — the flat-file ancestor
```task
id: SHARD-WP-0003-T9
status: todo
priority: low
```
Deep-dive **UseModWiki**. Distinctive angle: the **historical ancestor** — a Perl CGI
flat-file wiki, CamelCase linking, the lineage behind c2-era wikis and **MediaWiki Phase
I**. Origins/lineage value (pairs with `260608-c2-wiki-origins/`): the minimal flat-file
page+history model the whole field descends from. Enrich UC-01 (open wiki), UC-40
(flat-file store), UC-25 (CamelCase naming), UC-36/41 (flat-file revision history); note
lineage for the origins record.
---
## Acceptance criteria
- Each of T1–T9 has a `research/<yymmdd>-<slug>-deep-dive/` dir with `README.md` +
  `findings.md`, following the dive template (capability profile, INTENT mapping, UC
  seeds, sources, traceability).
- `spec/UseCaseCatalog.md` updated per dive (new UCs + enrichments + a per-source mapping
  subsection + traceability rows + header/promoted-from); `research/README.md` and
  `SCOPE.md` (UC count, research row) updated.
- Findings that touch the adapter contract are cross-referenced to `SHARD-WP-0002`
  (T11–T16); their architecture notes are captured for the next synthesis.
- Each dive is committed (`research:` message) and state-hub-synced (progress event).
- **After the batch:** assess whether a `research/260614-shard-spectrum-synthesis`
  **v3** is warranted (new spectra/modes from Wikibase RDF, Federated Wiki coordination,
  TiddlyWiki single-file, ikiwiki distributed) and re-fold into `SHARD-WP-0002` if so.
## Suggested task order
High-insight first: **T1 Federated Wiki → T2 Wikibase → T5 git-forge wikis** (INTENT-named)
→ **T3 TiddlyWiki → T4 ikiwiki** → then the contrast/lineage set **T6 Quip → T8 MojoMojo
→ T7 Oddmuse → T9 UseModWiki**.
</content>
							
							
							
						
@@ -0,0 +1,199 @@
---
id: SHARD-WP-0004
type: workplan
title: "computational / interactive-knowledge systems research"
domain: whynot
repo: shard-wiki
status: active
owner: tegwick
topic_slug: whynot
created: "2026-06-14"
updated: "2026-06-14"
---
# SHARD-WP-0004 — computational / interactive-knowledge systems research
## Goal
Research systems **tuned to interactive usage of knowledge interacting with computation,
programming, and mathematics** — literate programming, computational notebooks, live-
coding REPLs, and image-based/moldable programming environments — to extract patterns for
shard-wiki's treatment of **executable / computational / live page content** and
**one-source-many-projections**.
This workplan is more *exploratory* than the engine batch (`SHARD-WP-0003`): these systems
are mostly **not candidate shards**, they are **design prior art** for questions the
modern-tool dives raised but did not answer — what a "page" is when it is a *live
computation*, how *computed results* carry provenance/reproducibility, and how one source
projects into multiple rendered forms. Outputs feed the **page model** and the **addressing/
navigation** threads of the adapter contract, and may produce a dedicated synthesis
("the computational page model").
Each subject follows the dive tradition (`research/<yymmdd>-<slug>-deep-dive/` with
`README.md` + `findings.md`) but the catalog yield is expected to be **fewer new UCs and
more page-model / projection design notes**. Promote UCs only where a genuine new
*orchestration* scenario appears; otherwise enrich (UC-44 compose-by-reference, UC-54
query-defined page, UC-55 non-Markdown content, UC-32 transclusion) and log page-model
implications for `SHARD-WP-0002` T12/T16.
## Context
- Page-model thread: `SHARD-WP-0002` T12 (structured/typed/computed payload, query-defined
  pages, non-Markdown content) and T16 (addressing, transclusion, dimensional/query nav).
- Relevant existing UCs: UC-44 (compose-by-reference / EDL manifest), UC-54 (query-defined
  dynamic page), UC-55 (non-Markdown content), UC-32 (transclusion), UC-63 (derived index).
- Synthesis: `research/260614-shard-spectrum-synthesis/findings.md` (the spectra a
  "computational content" capability would extend).
**Framing question carried across all subjects:** *Can a shard-wiki page be a live
computational artifact — a source that is woven/tangled/evaluated into rendered forms —
and if so, how do projection, transclusion, provenance, and the adapter contract treat the
source, the kernel/environment, and the computed output?*
**Non-goal:** Implement a kernel or execution layer. Research + design notes only; any
"executable content" remains mechanism-over-policy and capability-gated.
---
## Literate Programming — Knuth's WEB / weave / tangle
```task
id: SHARD-WP-0004-T1
status: todo
priority: high
```
Deep-dive **Donald Knuth's WEB** and the **weave/tangle** model of **literate
programming**. The keystone pattern: **one WEB source → `weave` (typeset documentation)
+ `tangle` (compilable code)** — *one source, two projections* — plus **named code
chunks** referenced/embedded across the document (transclusion-like). This is the deepest
ancestor of shard-wiki's **projection** and **transclusion** ideas applied to
*executable* content. Map to UC-44 (compose-by-reference), UC-32 (transclusion), and the
projection model; log "source-with-multiple-projections" as a page-model pattern for T12.
## Mathematica Notebooks
```task
id: SHARD-WP-0004-T2
status: todo
priority: medium
```
Deep-dive **Mathematica Notebooks** (the `.nb` format and cell model). The original
computational notebook: **cells** (input/output/text), an **expression-tree** document,
symbolic evaluation, interactive results inline. Study the document format, output
provenance, and reproducibility. Enrich UC-54 (query/computation-defined content), UC-55
(rich computed output); page-model notes on **computed-output cells** for T12.
## Jupyter Notebooks
```task
id: SHARD-WP-0004-T3
status: todo
priority: high
```
Deep-dive **Jupyter Notebooks**: the **`.ipynb` JSON** model (cells: markdown / code /
output), **kernels**, embedded outputs, and execution-count/provenance. The dominant
computational document — and a concrete **non-Markdown, partially-executable content
type** with **embedded computed outputs** that carry (fragile) provenance. Highly relevant
to a "computational shard" and to output reproducibility. Enrich UC-54, UC-55, UC-59
(lossy capture of rich outputs); consider a new UC for **attaching/projecting a notebook
with computed-output provenance**; feed T12/T15.
## Processing.org and Processing.js
```task
id: SHARD-WP-0004-T4
status: todo
priority: low
```
Deep-dive **Processing.org** (creative-coding) and especially **Processing.js**
(browser-run sketches). The pattern: **the sketch *is* the document** — a program whose
rendered form is live visual output, runnable in the browser. Study "program-as-page" and
client-side live rendering. Notes on **executable/visual content rendered at view time**
for the page model (UC-54/55).
## Strudel.cc — live-coding REPL
```task
id: SHARD-WP-0004-T5
status: todo
priority: low
```
Deep-dive **Strudel.cc** (the JS port of TidalCycles): a **browser REPL** for live-coding
music/patterns. The pattern: **code as a live, evaluated performance**; a page whose
"content" is a running pattern. Study the REPL/live-evaluation model and pattern language.
Notes on **live-evaluated, time-based content** and the limits of static projection
(UC-54/55; graceful degradation to a snapshot).
## Squeak Smalltalk
```task
id: SHARD-WP-0004-T6
status: todo
priority: medium
```
Deep-dive **Squeak Smalltalk**: the **image-based** live-object environment — "everything
is a live object," the **image as a persistent world**, Morphic. The pattern:
**knowledge-as-live-objects** rather than files, and an environment with no
file/document/app boundary. Contrast hard with shard-wiki's files-canonical stance
(design-bug boundary), but mine it for **live-object / moldable** ideas. Page-model and
boundary notes (image-as-store is the anti-pattern; the live-object inspection is the
inspiration).
## Glamorous Toolkit — moldable development
```task
id: SHARD-WP-0004-T7
status: todo
priority: high
```
Deep-dive **Glamorous Toolkit** (on Pharo): **moldable development** — **custom views/
inspectors per object/domain**, a notebook + IDE where the *environment adapts to the
knowledge*. The pattern: **many co-equal, domain-specific views over the same live
objects** — a striking parallel to the ZigZag dimensional model (UC-47/48) and to
"query-defined / computed views" (UC-54). The strongest source for **moldable, multi-view
projection** of knowledge. Enrich UC-47/48 (dimensional/multi-view), UC-54; feed T16.
## Pharo
```task
id: SHARD-WP-0004-T8
status: todo
priority: low
```
Deep-dive **Pharo**: the modern Smalltalk that GT is built on — live image, reflective
environment, the substrate for moldable tools. Largely **context for T6/T7** (Squeak
lineage → Pharo → Glamorous Toolkit); keep brief unless it surfaces distinct page-model
ideas. May be folded into the GT memo if thin.
---
## Acceptance criteria
- Each of T1–T8 has a `research/<yymmdd>-<slug>-deep-dive/` dir with `README.md` +
  `findings.md` (or a justified merge, e.g. Pharo folded into GT), framed by the carried
  question above.
- `spec/UseCaseCatalog.md` updated **where a genuine orchestration UC appears**; otherwise
  enrichments to UC-32/44/54/55 and explicit **page-model / projection design notes**
  recorded in findings for `SHARD-WP-0002` T12/T16.
- `research/README.md` and `SCOPE.md` updated; each dive committed + state-hub-synced.
- **After the batch:** produce a short synthesis — *"the computational page model"* —
  consolidating literate-programming projection, notebook computed-output provenance, and
  moldable multi-view, with a recommendation on whether shard-wiki needs an **executable/
  computational content capability** (and how it stays mechanism-over-policy + capability-
  gated + degradable to a static snapshot).
## Suggested task order
Conceptual keystones first: **T1 Literate Programming → T3 Jupyter → T7 Glamorous
Toolkit**, then **T2 Mathematica → T6 Squeak (+ T8 Pharo)** for lineage, then the live/
visual REPLs **T4 Processing → T5 Strudel**. Close with the "computational page model"
synthesis.
</content>