generated from coulomb/repo-seed
Adds 'Capability structure for the wiki engine (reuse-surface-aligned)' to UseCaseCatalog.md (no UC renumbered): a small always-on engine core (EC-1..EC-5), ten typed per-shard-activatable extensions (X-OVERLAY/AUTHZ/VIEW/STRUCT/ADDR/COMP/ PROV/COLLAB/FED/ATT) each mapped to a reuse-surface capability with activation defaults, and a conflict-mediation map turning conflicting requirements into mechanisms. Bridges demand -> the engine typed-extension model (T5). Marks T2 done. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
spec/
Specification files that guide and guardrail implementation.
Background on document types: InfoTechPrimers on coulomb.social.
| File | Status | Role |
|---|---|---|
CoreArchitectureBlueprint.md |
draft for review | Whole-system architecture — layers, abstractions, load-bearing decisions (synthesised from all research) |
FederationArchitecture.md |
draft for review | federation design — what the union does: T1–T10 decision records + the federation-model taxonomy (SHARD-WP-0002) |
FederationRequirements.md |
draft for review | yawex-derived union/federation design notes — resolution, namespace, derived views, provenance, overlay, links (ADR-01…06; SHARD-WP-0001) |
ProductRequirementsDocument.md |
draft scaffold | What the product must deliver |
TechnicalSpecificationDocument.md |
draft + §A | How the system is built; §A = the normative shard adapter contract (T11–T16, T18; SHARD-WP-0002) |
UseCaseCatalog.md |
draft | 84 use cases promoted from c2 + yawex + ~23-system research |
ArchitectureBlueprint.md |
draft | Access, history, and identity sub-blueprint (the L0–L4 authorization ladder; referenced by CoreArchitectureBlueprint §9) |
Promote material from research/ and reviewed items from demand/ into spec
before treating it as implementation authority.