2026-06-08 13:55:27 +02:00
|
|
|
|
# SCOPE
|
|
|
|
|
|
|
|
|
|
|
|
## One-Liner
|
|
|
|
|
|
|
|
|
|
|
|
Git-based Markdown wiki orchestrator and federation layer — early-stage scaffold
|
|
|
|
|
|
with intent, research, and specification groundwork; domain model not yet
|
|
|
|
|
|
implemented.
|
|
|
|
|
|
|
|
|
|
|
|
## Mode Of Operation
|
|
|
|
|
|
|
|
|
|
|
|
Close the gap between this file and `INTENT.md` by exploring the problem space
|
|
|
|
|
|
(`research/`), reviewing inbound demand (`demand/`), refining specifications
|
|
|
|
|
|
(`spec/`), and implementing through registered workplans (`workplans/`).
|
|
|
|
|
|
Learnings update both SCOPE and INTENT where necessary.
|
|
|
|
|
|
|
|
|
|
|
|
## Current Status
|
|
|
|
|
|
|
|
|
|
|
|
| Layer | State |
|
|
|
|
|
|
|-------|-------|
|
|
|
|
|
|
| Code | Python package scaffold (`src/shard_wiki/`, smoke tests only) |
|
|
|
|
|
|
| Intent | `INTENT.md` established; authorization-in-core amendments drafted |
|
research: Joplin deep dive (SQLite-local/Markdown-on-sync, interchange-format attach, E2EE content opacity); UC-60/61
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>
2026-06-14 14:21:31 +02:00
|
|
|
|
| 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 deep dives & shard-spectrum synthesis (`research/260614-*/`) |
|
2026-06-08 13:55:27 +02:00
|
|
|
|
| Demand | NetKingdom integration asks captured, not yet negotiated |
|
research: Joplin deep dive (SQLite-local/Markdown-on-sync, interchange-format attach, E2EE content opacity); UC-60/61
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>
2026-06-14 14:21:31 +02:00
|
|
|
|
| Spec | Architecture blueprint drafted; UseCaseCatalog 61 UCs from research; PRD/TSD scaffolds |
|
synthesis: shard spectrum across nine systems; fold into SHARD-WP-0002 (T11 eleven spectra, new T16)
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>
2026-06-14 14:01:49 +02:00
|
|
|
|
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (16 tasks: T1–T10 federation + T11–T16 adapter contract) |
|
2026-06-08 13:55:27 +02:00
|
|
|
|
|
|
|
|
|
|
## In Scope (today)
|
|
|
|
|
|
|
|
|
|
|
|
- Establishing repository documentation structure and specification groundwork.
|
|
|
|
|
|
- Federation design informed by yawex prior art (page resolution, namespaces,
|
|
|
|
|
|
derived views, provenance, overlays).
|
|
|
|
|
|
- Authorization model design (delegated authentication, core authorization).
|
|
|
|
|
|
- Shard adapter contract and wiki page model (to be specified, then implemented).
|
|
|
|
|
|
- Git-backed coordination journal for information spaces.
|
|
|
|
|
|
- State Hub workplan registration and consistency sync.
|
|
|
|
|
|
|
|
|
|
|
|
## Out Of Scope (today)
|
|
|
|
|
|
|
|
|
|
|
|
- A standalone wiki engine UI or rendering pipeline.
|
|
|
|
|
|
- Authentication, credential storage, or user directory implementation.
|
|
|
|
|
|
- Hard-coded editorial, sync, or conflict-resolution policy.
|
|
|
|
|
|
- Generic file mirroring independent of wiki-page semantics.
|
|
|
|
|
|
- Production deployment, multi-tenant operations, or enterprise IAM rollout.
|
|
|
|
|
|
|
|
|
|
|
|
## Boundary Rule
|
|
|
|
|
|
|
|
|
|
|
|
`shard-wiki` orchestrates wiki-shaped content across heterogeneous shards. It
|
|
|
|
|
|
provides mechanisms (federation, projection, overlay, patching, reconciliation);
|
|
|
|
|
|
policy (canonical source, conflict preference, access rules) remains explicit and
|
|
|
|
|
|
configurable. Identity comes from pluggable providers; authorization decisions
|
|
|
|
|
|
live in core.
|
|
|
|
|
|
|
|
|
|
|
|
## Current Planning
|
|
|
|
|
|
|
2026-06-08 14:55:13 +02:00
|
|
|
|
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.
|