Files
shard-wiki/SCOPE.md
tegwick f0be5799aa research: Obsidian deep dive (file-over-app vaults, plugin API, ecosystem-popularity signal); UC-53/54/55/56
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>
2026-06-14 12:51:22 +02:00

60 lines
2.7 KiB
Markdown

# 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 deep dives (`research/260614-*/`) |
| Demand | NetKingdom integration asks captured, not yet negotiated |
| Spec | Architecture blueprint drafted; UseCaseCatalog 56 UCs from research; PRD/TSD scaffolds |
| Work | `SHARD-WP-0001` active (6 tasks); `SHARD-WP-0002` active (10 tasks) |
## 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.