generated from coulomb/repo-seed
tegwick
0ee972f2e2
Headless, API-first, agent-optimized native engine = canonical-mode shard backend. Thesis: a page-store kernel with a typed-extension runtime; everything beyond the c2-minimum is a typed extension activated per shard, and the shard's §A capability profile is DERIVED from its active extensions (configuration->capability->conformance). 9 engine invariants (engine-is-one-shard, small kernel, per-shard activation, profile-from-extensions, headless/agent-first, reuse-not-reinvent, typed+verified). Kernel (4 concepts), typed-extension model (typed hooks + deterministic composition + feature-control activation), T2 featureset/conflict-mediation realized, engine-as-shard, agent-first API surface, module sketch, reuse (consumes feature-control/authorization; G1 framework proposal), traceability, decisions/open, stability note. Marks T5 done. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
shard-wiki
Git-based Markdown wiki orchestrator and federation layer.
shard-wiki joins heterogeneous wiki-shaped page stores (shards) into a
coherent information space while preserving provenance, capabilities, and
history. It is an orchestration layer, not a wiki engine.
Status
Early-stage: Python scaffold, intent and specification groundwork, active design
workplan. See SCOPE.md for current maturity.
Documentation
| Document | Purpose |
|---|---|
| INTENT.md | Aspiration and boundaries |
| SCOPE.md | What we achieve now |
| AGENTS.md | Agent working guide |
| docs/repository-layout.md | How this repo organizes information |
Quick start
pip install -e ".[dev]"
pytest
Layout
research/ explorations (yymmdd-prefixed)
demand/ inbound unreviewed requirements
spec/ implementation specifications
workplans/ State Hub–registered tasks
docs/ stakeholder documentation
wiki/ collaborative knowledge (wiki UI when connected)
issues/ ticket mirrors
history/ archived material (yymmdd-prefixed)