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>
