generated from coulomb/repo-seed
tegwick
3ea0cc1226
edit()/overlay()/apply_overlay() on InformationSpace. edit() unifies the write path through one principled route — draft overlay then apply: write-through-capable target fast-forwards (APPLIED), read-only target keeps the draft as local truth (KEPT_DRAFT), external drift refuses (no clobber). Integration tests cover all four. 64 tests green, pyflakes clean. Flips WP-0008 done. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
65 lines
4.5 KiB
Markdown
65 lines
4.5 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 | Foundation slice implemented (SHARD-WP-0007): `provenance` + `policy` leaves, `model` (Identity/Placement/Span/Page/CapabilityProfile), `adapters` (contract + FolderAdapter + conformance suite), `coordination` (event-sourced DecisionLog), `union` (resolution + chorus, overlay-aware), `InformationSpace` orchestrator. Write path added (SHARD-WP-0008): writable adapter, overlay engine (draft→patch→apply-under-drift), edit() unifies write-through + overlay-before-mutation. attach→resolve→read + edit/overlay/apply work; 64 tests green |
|
||
| 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) + Trilium + Wiki.js + Federated Wiki + Wikibase + git-forge wikis + TiddlyWiki + ikiwiki + Quip + MojoMojo + Oddmuse + UseModWiki deep dives & shard-spectrum synthesis (`research/260614-*/`) |
|
||
| Demand | NetKingdom integration asks captured, not yet negotiated |
|
||
| Spec | CoreArchitectureBlueprint (whole-system architecture, hardened via SHARD-WP-0005) + ArchitectureBlueprint (auth/history) drafted; UseCaseCatalog 84 UCs from research; PRD/TSD scaffolds |
|
||
| Work | `SHARD-WP-0001` **done** (6 ADRs: yawex-derived federation requirements → `spec/FederationRequirements.md`); `SHARD-WP-0002` **done** (18 tasks → `FederationArchitecture.md` [T1–T10, T17] + `TechnicalSpecificationDocument.md` §A adapter contract [T11–T16, T18]); `SHARD-WP-0003` **done** (9 engine dives complete); `SHARD-WP-0004` **done** (all 8 computational-knowledge dives T1–T8 complete + "computational page model" synthesis); `SHARD-WP-0005` **done** (9 tasks: CoreArchitectureBlueprint hardened against the 260615 review); `SHARD-WP-0006` **done** (5 tasks: round-2 hardening — overview reconciled, event-sourced coordination + append authority, adapter conformance, incremental correctness + I-2 verification) |
|
||
|
||
## 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). Research continues under
|
||
`workplans/SHARD-WP-0003-engine-dives-batch.md` (remaining new-insight wiki
|
||
engines + git-forge wikis + classic engines) and
|
||
`workplans/SHARD-WP-0004-computational-knowledge-systems.md` (literate
|
||
programming, computational notebooks, live-coding REPLs, image-based/moldable
|
||
environments — the executable/computational page-model thread). Specification
|
||
outputs land in `spec/`. Inbound integration asks remain in `demand/` until
|
||
reviewed and promoted into spec or workplans. |