Fixes bug B-1: page identity is a stable assigned handle (survives edits),
not a content fingerprint; fingerprints identify versions/content for the
equivalence mechanism. Chain: identity -> placements -> equivalence. (§7.2)
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Records the critical review (history/260615-...) and establishes SHARD-WP-0005
to fold its findings (A-1, B-1..B-3, C-1..C-3, D-1..D-4) into the blueprint:
correctness (state re-frame, identity/equivalence split, consistency model),
scale (incremental-first union, equivalence indexing, cache invalidation),
elegance (orthogonal spectra, layered provenance, common-case projection,
policy module), security/history scaling, and a known-open-problems section.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The optimal architecture synthesised from INTENT + the full research arc:
- Thesis: canonical at the edges, derived in the middle (orchestrator not engine)
- Dual narrow waist: adapter contract (15 capability spectra) + page model
- 6 layers + provenance/capability rails; L4 union/projection is a rebuildable cache
- Federation-model taxonomy (plural/composable); two-axis projection model;
moldable view registry; identity != placement; computational content in scope
as page-model+projection, out as execution platform
- Concrete src/ module layout with downward-only dependency rule
- Canonical data flows; policy surface; tradeoffs; full traceability to INTENT/UCs
References ArchitectureBlueprint.md as the L5 authorization sub-blueprint.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Consolidates the 8 computational/interactive-knowledge dives into one
source/derivation/projection model on two axes (replication<->derivation,
live<->snapshot); four computational page shapes; recommendation that
executable content is in scope as a page-model+projection concern, out of
scope as an execution platform (capability-gated, degrade to snapshot;
no INTENT amendment). Flips SHARD-WP-0004 status: done.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Code as live time-based audio performance; the far live end of the
live<->snapshot axis (no faithful static form; static = source + marked
recording). The honesty test for graceful degradation. Enrichment-only
(UC-54/55). Marks T5 done — all 8 batch tasks complete.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Program-as-page rendered live at view time (no cached output). Adds
materialization-timing (ahead-of-time vs view-time) + continuity
(one-shot vs continuous) facets to the projection model; execute-in-viewer
= capability+trust. Enrichment-only (UC-54/55). Marks T4 done.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Combined memo (justified merge). The image = purest 'live' end; hardens
the image-is-not-a-store boundary (export->files only), generalizing
'attach files not the kernel/image'. Pharo Tonel/Iceberg confirms even
image traditions externalize to git text. Names the live<->snapshot
projection axis (T16). Boundary/enrichment-only, no new UC. Marks T6+T8 done.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Original computational notebook (.nb = a Wolfram expression); confirms
UC-84 notebook page shape is a genus. Refinements: nestable cell groups
(outline tree), structured re-evaluable outputs (new opacity point).
Manipulate/Dynamic = snapshot-only. Enrichment-only (UC-84/54/55).
Marks T2 done.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Moldable views (gtView) = open, type-keyed set of co-equal, computed
projections, none canonical = a moldable view registry refining the
projection model (T16). Lepiter live notebook over git files. Enrichment-
only (UC-47/48/54); no new UC. Marks T7 done.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Section A had accumulated 64 of 82 UCs (every dive appended to its end),
collapsing four distinct themes into one heading. Regroup the orchestration/
adapter UCs into four coherent sections and re-letter the authoring/reading
sections, with UC numbers kept as stable IDs (never renumbered -- they are
referenced across research/, the synthesis, and the workplans):
A. Information space, federation & coordination
B. Shard attachment & adapter binding
C. Page model, structure & content fidelity
D. Addressing, identity & query
E. Knowledge work and collaboration (was B)
F. Discovery and navigation (was C)
G. Provenance and page metadata (was D; + UC-75 statement provenance)
UC blocks moved byte-for-byte (verified: heading set and Traceability tail
identical to pre-restructure); added an Organization note to Conventions.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Renumber stray open-question 23->31 (mis-numbered during the WP-0003 batch;
questions now run 1-32 sequentially) and add Q32 (federation composition,
from synthesis v3 S2.5).
- Add a dive-source marker legend at the top of Traceability (18 markers were
used across the matrix with no single key).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SHARD-WP-0003 T9 (final). Lineage dive: the flat-file ancestor (Clifford Adams
c.2000, from AtisWiki/CvWiki) that early Wikipedia ran on (MediaWiki Phase I).
No new capability -- reinforces the minimal flat-file floor (UC-82) and
CamelCase linking (UC-25); historical grounding that the file-store floor is
the field's common root. Enrichment-only: UC-01/40/25/36/41. Marks T9 done and
SHARD-WP-0003 complete (9/9). Feeds SHARD-WP-0002 T11.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
SHARD-WP-0003 T8. Classic relational-DB-backed wiki: Catalyst/DBIx::Class app,
pages + path tree + full history in SQL tables, Markdown body in a column, no
file store and no content API. Anchors the direct-DB-read binding (map schema
-> page model + journal); DB version rows = a third history source beside git
commits and RCS files. UC-81. Enriched UC-02/40/36/34. Marks T8 done.
Feeds SHARD-WP-0002 T14/T13/T11.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SHARD-WP-0003 T6. Enterprise document-collab contrast to Notion: a doc +
spreadsheet hybrid where a page is prose interleaved with embedded live
structured objects (spreadsheets, kanban/calendar live apps), reachable only by
REST with HTML import/export (lossy to Markdown), gated by Salesforce
identity/ACL. Generalizes external-API mode with an HTML payload-format facet
(beside Notion block-JSON, Wiki.js GraphQL); pushes page model toward
inline embedded structured objects. UC-80. Enriched UC-57/55/58/36/06. Marks
T6 done. Feeds SHARD-WP-0002 T11/T12/T14.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SHARD-WP-0003 T4. Wiki compiler: git-canonical Markdown source -> static HTML
(derived publish/projection, not the canonical store). Two new insights atop
the git-IS-store home case: compile-to-static = clean canonical-source vs
derived-output separation (attach source repo, UC-37/UC-56), and a third
federation flavor -- git replication + XML-RPC change-ping (pinger), beside
fedwiki fork/journal (UC-72) and Wikibase SERVICE (UC-74). UC-79. Enriched
UC-31/56/37/33. Marks T4 done. Feeds SHARD-WP-0002 T4/T6/T14.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
SHARD-WP-0003 T5. The home case: a forge wiki is a separate .wiki.git repo of
Markdown -> page model, history, coordination journal map 1:1 with near-zero
adapter. git-clone universal across all three; wiki content API
capability-varying (GitLab/Gitea yes, GitHub git-only). git IS the canonical
store (not a mirror), so write-by-commit is safe -- resolves the UC-68/Q22
race for this case. UC-76 (clone .wiki.git attach), UC-77 (forge wiki API,
capability varies). Enriched UC-40/02/68/38. Marks T5 done.
Feeds SHARD-WP-0002 T14/T11.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
SHARD-WP-0003 T1. Federation model (not a shard candidate): per-page
append-only semantic-action journal with story as derived replay,
fork-with-site-provenance, neighborhood/roster discovery + chorus of forks.
Prior art for shard-wiki's own pillars: coordination journal (UC-71),
overlay-before-mutation (UC-26 fork), union-without-erasure (UC-72).
Attach as REST/file-store hybrid (page JSON + CORS, UC-70). Feeds
SHARD-WP-0002 T1-T5, T11, T13, T16.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
State-hub consistency sync created both workstreams and all 17 tasks and
wrote the IDs back into the workplan frontmatter and task blocks; commit
them so the files match the DB.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
