generated from coulomb/repo-seed
tegwick
4543f5dc43
The closest existing engine to shard-wiki's own design: DB-canonical (Postgres/MySQL/SQLite) but with a pluggable storage-module abstraction that bidirectionally syncs clean Markdown (+ YAML frontmatter) to Git (also FS/S3/Azure), each provider acting as backup or source of truth. Two big findings: (1) the storage-module interface is concrete adapter-contract prior art alongside Foswiki::Store, and the closer one (medium = Markdown in Git); (2) the engine-maintained bidirectional Git mirror is the ideal file-store attach (clean MD + git history) and, being bidirectional, makes git commit a write path (overlay/patch as a commit, no API). Also GraphQL API (introspection = capability discovery; selective fields = efficient projection) and authn-delegated auth modules + path-based rule ACL. Added UC-68 (engine-maintained bidirectional Git mirror, write-by-commit), UC-69 (typed/introspectable API for schema discovery + selective projection); enriched UC-06/36/38/40/42/57. Catalog now 69 UCs. Architecture for SHARD-WP-0002 T11/T14: storage-module abstraction as 2nd adapter-contract prior art, engine-maintained Git mirror as attach+write surface, GraphQL introspection for capability discovery. 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 |
|---|---|---|
ProductRequirementsDocument.md |
draft scaffold | What the product must deliver |
TechnicalSpecificationDocument.md |
draft scaffold | How the system is built |
UseCaseCatalog.md |
draft | 25 use cases promoted from c2 + yawex research |
ArchitectureBlueprint.md |
draft | Access, history, and identity architecture |
Promote material from research/ and reviewed items from demand/ into spec
before treating it as implementation authority.