tegwick
6ccf349209
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>
2.8 KiB
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 | 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 deep dives & shard-spectrum synthesis (research/260614-*/) |
| Demand | NetKingdom integration asks captured, not yet negotiated |
| Spec | Architecture blueprint drafted; UseCaseCatalog 63 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) |
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
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.