SHARD-WP-0003 — nine wiki-engine deep dives chosen against the synthesis
coverage review: high-insight (Federated Wiki, Wikibase/Wikidata,
TiddlyWiki, ikiwiki), the INTENT-named git-forge wikis (Gitea/GitLab/
GitHub), and four for breadth/lineage (Salesforce Quip, Oddmuse, MojoMojo,
UseModWiki). Each task = persist a deep-dive memo + promote/enrich the
use-case catalog + log adapter-contract notes for SHARD-WP-0002;
post-batch synthesis-v3 decision.
SHARD-WP-0004 — eight computational / interactive-knowledge systems as
design prior art for executable/computational/live page content and
one-source-many-projections: Knuth WEB/weave/tangle, Mathematica & Jupyter
notebooks, Processing/Processing.js, Strudel.cc, Squeak, Glamorous
Toolkit, Pharo. Carries the question of whether a page can be a live
computational artifact; closes with a "computational page model"
synthesis. Both workplans authored file-authoritative (no state_hub IDs;
sync will create+link workstreams and tasks).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The closest existing engine to shard-wiki's own design: DB-canonical
(Postgres/MySQL/SQLite) but with a pluggable storage-module abstraction
that bidirectionally syncs clean Markdown (+ YAML frontmatter) to Git
(also FS/S3/Azure), each provider acting as backup or source of truth.
Two big findings: (1) the storage-module interface is concrete
adapter-contract prior art alongside Foswiki::Store, and the closer one
(medium = Markdown in Git); (2) the engine-maintained bidirectional Git
mirror is the ideal file-store attach (clean MD + git history) and, being
bidirectional, makes git commit a write path (overlay/patch as a commit,
no API). Also GraphQL API (introspection = capability discovery;
selective fields = efficient projection) and authn-delegated auth modules
+ path-based rule ACL. Added UC-68 (engine-maintained bidirectional Git
mirror, write-by-commit), UC-69 (typed/introspectable API for schema
discovery + selective projection); enriched UC-06/36/38/40/42/57. Catalog
now 69 UCs. Architecture for SHARD-WP-0002 T11/T14: storage-module
abstraction as 2nd adapter-contract prior art, engine-maintained Git
mirror as attach+write surface, GraphQL introspection for capability
discovery.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Extend the cross-dive synthesis from nine systems to the full fourteen
(added Joplin, Logseq, the CRDT cohort Anytype/AFFiNE/AppFlowy, Trilium).
Spectra grown 11 -> 13: new merge-model (none/git/conflict-notes/
native-CRDT) and content-opacity (plaintext/whole-shard-E2EE/per-item),
plus identity-vs-placement emphasis (Trilium note/branch DAG), Logseq's
in-file id:: addressing sweet spot, build-your-own derived query index,
and a six-mode attachment taxonomy (file-store native/interchange-mirror,
in-engine-host, local-REST, external-API, CRDT-replica, P2P). New
through-lines: CRDT changes the merge math; identity != placement;
metadata can be computed; attach surface != native store (+ substrate
migration). UC fold-in extended UC-44-59 -> UC-44-67.
Folded into SHARD-WP-0002: T11 thirteen spectra; T12 computed metadata +
multi-placement/DAG identity; T13 CRDT-log supplement; T14 full six-mode
attachment taxonomy; T15 HTML source model; T16 identity!=placement +
derived index. Context inputs += four dives; acceptance UC-26-67. No new
tasks, no new UCs (synthesis only).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SQLite-local PKB whose standout is note cloning — a single note can sit in
multiple tree locations at once via the note (identity) vs branch
(placement) split, so the hierarchy is a DAG, not a tree, with no single
canonical path. The identity-not-equal-placement model is the clean way to
represent a page in multiple locations/shards and the namespace-level form
of the clone/reference primitive. Also: attributes (labels + typed
relations) are inherited + templated, so metadata is computed (own +
inherited + template), not a flat bag; content opacity is per-item
(per-note encryption / protected notes), refining the proposed 12th
spectrum; HTML-native (CKEditor, lossy to Markdown); dual extension
surface (scripting code notes + ETAPI token REST). TriliumNext is the
active community fork of zadam's Trilium (TWiki->Foswiki pattern). Added
UC-66 (DAG hierarchy / note cloning), UC-67 (inherited/templated
attributes, effective vs own); enriched UC-15/22/34/38/42/61. Catalog now
67 UCs. Architecture for SHARD-WP-0002 T11/T12/T14/T15/T16: DAG namespace
+ identity/placement split, computed/inherited metadata, per-item content
opacity, HTML source model, scripting + ETAPI host surfaces.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Combined cohort memo for the three open-source local-first all-in-one
workspaces, studied together because they share the trait none of the
prior eleven systems had: the store is a CRDT (Anytype any-sync, AFFiNE
Yjs/y-octo, AppFlowy Yrs). The cohort thesis: CRDT changes the adapter
math — the backend performs conflict-free merge itself (shard-wiki must
not impose git/text merge; speak the CRDT via a replica or stay
projection/overlay), history is a CRDT update log (supplement not git),
and the attach surface is a replica or self-host sync endpoint, with
Anytype adding P2P (no single endpoint) + E2EE (opaque). Added UC-64
(CRDT-synced shard with native merge), UC-65 (P2P/decentralized shard,
no single canonical endpoint); enriched UC-36/47/48/51/55/57/58/61.
Catalog now 65 UCs. Architecture for SHARD-WP-0002 T11/T14: merge-model
capability (proposed 13th spectrum: none/git/native-CRDT), CRDT-replica
substrate + P2P/no-central-endpoint attach mode, endpoint-model
capability, MCP as an integration surface. Boundary: CRDT local-first
candidate shards — attach a replica/projection as pages, respect native
merge, never re-drive their sync; not substrates and not the federation
layer.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Occupies the point the other modern tools leave empty: block-graph
semantics (UUID-addressable, embeddable, queryable blocks) stored as plain
Markdown/Org files on disk, with a DataScript graph derived from the files
(files canonical, index derived). The bridge between Roam (block-DB) and
Obsidian (file-over-app). Headline finding: Logseq resolves the
addressing-spectrum tension — block-level addressing that is also
git-diffable in-file text (id:: property) — and proves a file-backed shard
can serve rich Datalog queries via a derived index. Also: file->SQLite
"DB graph" migration is a live UC-43 (substrate swap under stable
identity); whiteboards = non-Markdown content; dual-attachable (file-store
direct with a Logseq format profile, or in-app plugin). Added UC-62
(attach block-graph-on-plain-files shard), UC-63 (serve structured
queries over a file shard via a derived index shard-wiki builds — converse
of UC-52); enriched UC-32/34/43/50/51/52/55. Catalog now 63 UCs.
Architecture for SHARD-WP-0002 T11/T14/T16: Logseq format profile,
derived-query-index capability, substrate-migration tolerance, in-file
block addressing as the T16 span-address target.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
Cross-dive synthesis (research/260614-shard-spectrum-synthesis/) reading
the two Nelson conceptual systems, four engines, and three modern tools
across each other: a shard family matrix and eleven capability spectra
(addressing, content identity, structure, history, native query,
translation, attachment mode, operational envelope, access grant, write
granularity, content types) — positions anchored at both ends by a real
system, federation ops degrading by position. Through-lines:
files-canonical/index-derived wins; fine-grained addressing is adoptable;
transclusion=clone=embed is one primitive; structure/history federate iff
in-text; attach mode is a per-binding choice; Notion proves the platform
can enforce no-silent-mutation.
Folded into SHARD-WP-0002: T11 reframed around the eleven spectra; T12
page model stretched four ways (prose + typed records + non-Markdown
assets + query-defined); T13 adds Notion supplement; T14 rewritten as the
three-mode attachment taxonomy (file-store / in-engine-host /
external-API); T15 adds lossy-with-fidelity-report; new T16 (addressing,
content identity, dimensional/query navigation). UC coverage UC-34-43 ->
UC-34-59. Workplan now 16 tasks. No new UCs (synthesis only).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The closed/hosted/schema-rich extreme: everything is a block (UUID id,
type, properties, ordered child content, single parent), pages are blocks
and database rows are pages with a schema, Postgres-backed hosted SaaS.
Databases add typed properties + relations + rollups + formulas across
many views = the apex of wiki-page-as-structured-record. Extension model
has no in-app plugin runtime; the only extensibility is the external REST
API (+ webhooks 2026) inside a tight envelope (~3 rps, eventual
consistency, recursive child fetch, scoped/revocable per-page grants).
Adds the third attachment mode (external-API-only) alongside file-store
(Obsidian/TWiki) and in-engine host (Roam/XWiki); Notion enforces no
silent remote mutation via scoped grants. Added UC-57 (attach closed
external-API-only shard w/ operational envelope + scoped grant), UC-58
(typed database w/ schema+relations+views, no flattening), UC-59
(lossy-aware translation w/ fidelity report); enriched
UC-31/34/36/39/50/51/52/54/56. Boundary: one external-API candidate shard,
best as projection/mirror/overlay/backup, not a substrate and not the
federation layer.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The most INTENT-aligned tool yet and the file-backed counterpart to Roam:
file-over-app vaults (plain .md folders, files canonical, MetadataCache a
derived index), in-file git-diffable addressing/structure (^block-id,
wikilink embeds, YAML frontmatter), and a plugin API (Plugin onload/onunload
over App.vault/metadataCache/workspace) that doubles as an adapter host —
so a vault is dual-attachable (file-store direct or in-app plugin). Mined
the plugin download rankings as demand evidence per the research brief:
#1 is drawings (Excalidraw, non-Markdown content), query-as-DB
(Dataview/Tasks) is top-tier but an add-on, Git is top-7 (bolt-on history),
Remotely Save shows sync-to-anywhere demand. Added UC-53 (attach local
vault w/ live concurrent native editor), UC-54 (query-defined dynamic
page), UC-55 (non-Markdown content types), UC-56 (outbound publish of a
projection); enriched UC-15/28/34/36/40/51/52. Boundary: a vault is one
file-backed candidate shard, not the federation layer and not a file-sync
target.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The modern bookend to the Xanadu/ZigZag dives: where those are unbuilt
ideals, Roam shipped fine-grained addressing (:block/uid), live
transclusion (block embeds), bidirectional links, and a queryable
structured space (DataScript datoms + Datalog). Studied as a candidate
DB-backed/API-attached shard (XWiki family) and as a concrete
engine-hosts-adapter surface (Roam Depot onload/onunload over
window.roamAlphaAPI). Added UC-50 (attach block-graph DB shard, block<->page
mapping), UC-51 (adopt native span IDs as portable span addresses), UC-52
(delegate derived views to a shard's native query engine); enriched
UC-32/34/35/38. Boundary: Roam is one candidate shard mapped into the
Markdown-first page model, not a substrate and not the federation layer.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Evaluated modelling a wiki information space as a zzstructure: a page is
a cell at the intersection of many co-equal dimensions (namespace tree,
created-from genealogy, version, shard, equivalence, links).
Recommendation: adopt zzstructure as a navigation/visualization/indexing
LENS (a derived dimensional projection over the union), not as the
storage substrate — Git and sovereign shards stay canonical, and the
many-to-many link graph does not fit the one-neighbour-per-dimension rank
rule. Clone <-> transclusion convergence with the Xanadu dive. Added
UC-47/48/49; enriched UC-05/22/26/29; dimensional projection layer +
genealogy-edges-in-journal logged as architecture for SHARD-WP-0002.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Xanadu studied as conceptual ancestor, not a candidate shard. Yield:
reference-not-copy EDL/xanadoc validates projection+overlay+union;
content-identity bidirectional transclusion; portable span-address
(tumbler) problem logged as adapter-contract architecture for
SHARD-WP-0002. Recorded design-bug boundaries: reject
single-global-docuverse, single-canonical-instance, baked-in economic
policy. Added UC-44/45/46; enriched UC-24/27/29/32.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Distill the cross-cutting adapter-contract constraints from the four engine
deep dives (wiki-engines landscape, XWiki, TWiki, Foswiki) into five concrete
design tasks, complementing the federation tasks (T1-T10):
- T11 adapter contract: capability model & versioned interface (Foswiki::Store
prior art; write-granularity as a capability dimension)
- T12 page model: structured/typed payload representation (XObjects, %META%,
multi-record, bodiless pages)
- T13 history portability: supplement (DB-internal) vs import (open file history)
- T14 adapter binding: attach path, engine-hosted vs external, backend-swap
- T15 syntax translation & content fidelity (non-Markdown round-trip)
Adds an adapter-contract decision-topics table, cross-links T10<->T11 on the
shared capability vocabulary, and updates context/acceptance/task-order. Tasks
registered in the state hub (workstream 2af4c46d).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deep dive into Foswiki focused on its deltas from TWiki (not the shared
lineage): the pluggable Foswiki::Store backend (RcsWrap/RcsLite/PlainFile)
behind a versioned interface via Foswiki::Meta, the OO/MVC core rewrite,
Foswiki::Func + registerTagHandler, DataForms + MetaDataPlugin multi-record,
and WysiwygPlugin TML<->HTML round-trip. The store abstraction is logged as
prior art for shard-wiki's own adapter contract (SHARD-WP-0002).
Catalog (now 43 UCs):
- UC-42 read/write a non-Markdown shard via lossless syntax translation
(Markdown-first for prose; Foswiki WysiwygPlugin is proof)
- UC-43 tolerate a shard's storage-backend swap (RCS<->PlainFile) under a
stable identity
- enrich UC-39 (multi-record metadata) and UC-40 (PlainFile direct-attach)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deep dive into TWiki as the file-based Perl counterpoint to XWiki: flat-file +
RCS store (data/<Web>/<Topic>.txt), Webs/Topics, TWiki Forms storing fields as
%META% in the topic text, TWikiML/variables, TWiki::Func API; the plugin handler
callback surface (initPlugin, commonTagsHandler, before/afterSaveHandler,
afterRenameHandler, REST handlers) and package types (Plugin/Skin/AddOn/Contrib);
per-topic ALLOW/DENY access control (origin of yawex's model); Foswiki fork.
Catalog (now 41 UCs):
- UC-40 attach a file-backed engine's on-disk store directly (dual-path attach)
- UC-41 import an engine's native file history (RCS .txt,v) into the journal
- enrich UC-06 (TWiki per-topic ACL lineage), UC-34 (file-embedded %META%),
UC-36 (RCS-import vs DB-supplement), UC-38 (TWiki handlers as adapter host)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deep dive into XWiki past the landscape scan: component/DI architecture,
document + class/object data model, oldcore, Hibernate storage + xwikircs
history, ObservationManager events, rendering pipeline, multi-wiki; the full
extension-interface surface (components, Java/wiki macros, script services,
UIX/UIXP, JAX-RS REST, event listeners, resource handlers); and the
extensions.xwiki.org ecosystem (XAR/JAR/WebJar, 900+ extensions).
Catalog:
- UC-38 make a wiki engine federation-capable via its native extension API
(composable integration — first engine-side-direction UC; XWiki is proof)
- UC-39 attach a wiki-as-application-platform shard (bodiless typed pages)
- enrich UC-31 (ObservationManager event-driven sync), UC-34 (XObject model),
UC-36 (xwikircs internal history) with concrete XWiki specifics
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mine the one research dir not yet promoted (260608-wikiengines-overview) into
the catalog. Adds four heterogeneous-backend attachment scenarios the other
research didn't surface:
- UC-34 attach structured/semantic shard without lossy flattening (SMW, XWiki)
- UC-35 attach shard with coarse write granularity (TiddlyWiki single-file)
- UC-36 supply git-addressable history to internal-history engine (Confluence)
- UC-37 attach static export as read-only backup shard (MediaWiki dump)
Adds a `wikiengines` source token + traceability column and a wikiengines
mapping subsection. The scan mostly reinforced existing UCs and the L0→L4
ladder; its main yield is adapter-contract constraints tracked in SHARD-WP-0002.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Add README.md + findings.md to research/260608-wikiengines-overview/ to
match sibling research convention (was a bare Perplexity dump). findings.md
synthesizes the engine landscape into adapter-contract implications and maps
to INTENT (capability heterogeneity, L0->L4 ladder, backend-neutrality).
- Mark the netkingdom integration demand as sent: capability request
3136a9e2 (auto-routed to netkingdom) + inbox message 46c60f17.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Document Federated Wiki mechanics (fork, journal, inverted browser model),
Caulfield lifecycle concepts, and comparison with git-backed wikis,
ActivityPub/XWiki, Xanadu patterns, and yawex REMOTE/VIRTUAL. Map
findings to shard-wiki INTENT without equating fedwiki to orchestration.
Explores WikiWikiWeb beginnings: design principles, social conventions,
navigation vocabulary, and documented use cases. Federation explicitly
deferred to a later research track.
Add SHARD-WP-0001 workplan backed by the StateHub yawex-requirements
workstream (6 design tasks, all todo). Includes access-model blueprint,
NetKingdom integration requirements draft, and INTENT amendments for
open-by-default authorization delegated to external identity providers.
Distill the yawex-0.7.4 Perl wiki engine into shard-wiki requirements:
KEEP federation-relevant ideas (page-resolution state space as inspiration,
namespace hierarchy, page/shard roles, derived views, provenance, blueprints,
overlay/append, multi-shard config), TRANSFORM markup to CommonMark + wikilink
extension, DROP engine/era artifacts. Flags a contested decision: a minimal
access model in core revises an INTENT non-goal and needs an INTENT amendment.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Add a src/-layout package (shard_wiki), hatchling build config, pytest
and ruff configuration, and smoke tests proving the import path and test
harness are wired correctly. Update CLAUDE.md with real build/test commands.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
