generated from coulomb/repo-seed
tegwick
3e0c05a2b3
Combined cohort memo for the three open-source local-first all-in-one workspaces, studied together because they share the trait none of the prior eleven systems had: the store is a CRDT (Anytype any-sync, AFFiNE Yjs/y-octo, AppFlowy Yrs). The cohort thesis: CRDT changes the adapter math — the backend performs conflict-free merge itself (shard-wiki must not impose git/text merge; speak the CRDT via a replica or stay projection/overlay), history is a CRDT update log (supplement not git), and the attach surface is a replica or self-host sync endpoint, with Anytype adding P2P (no single endpoint) + E2EE (opaque). Added UC-64 (CRDT-synced shard with native merge), UC-65 (P2P/decentralized shard, no single canonical endpoint); enriched UC-36/47/48/51/55/57/58/61. Catalog now 65 UCs. Architecture for SHARD-WP-0002 T11/T14: merge-model capability (proposed 13th spectrum: none/git/native-CRDT), CRDT-replica substrate + P2P/no-central-endpoint attach mode, endpoint-model capability, MCP as an integration surface. Boundary: CRDT local-first candidate shards — attach a replica/projection as pages, respect native merge, never re-drive their sync; not substrates and not the federation layer. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
60 lines
2.9 KiB
Markdown
60 lines
2.9 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 + Notion + Joplin + Logseq + local-first workspaces (Anytype/AFFiNE/AppFlowy) deep dives & shard-spectrum synthesis (`research/260614-*/`) |
|
||
| Demand | NetKingdom integration asks captured, not yet negotiated |
|
||
| Spec | Architecture blueprint drafted; UseCaseCatalog 65 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. |