generated from coulomb/repo-seed
tegwick
5d8608aeae
Organize 25 use cases across federation, collaboration, discovery, and provenance. Include traceability tables mapping research IDs to catalog UCs.
57 lines
2.4 KiB
Markdown
57 lines
2.4 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 wiki origins (`research/260608-*/`) |
|
|
| Demand | NetKingdom integration asks captured, not yet negotiated |
|
|
| Spec | Architecture blueprint drafted; UseCaseCatalog 25 UCs from research; PRD/TSD scaffolds |
|
|
| Work | `SHARD-WP-0001` active — 6 design tasks, all todo |
|
|
|
|
## 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`.
|
|
Specification outputs from that workplan land in `spec/`. Inbound integration
|
|
asks remain in `demand/` until reviewed and promoted into spec or workplans. |