Records the accepted decision: shard-wiki's native engine uses feature-control via
OpenFeature for per-shard extension activation (availability only, never authz),
provider-pluggable with a LocalProvider standalone default (mirrors the identity
ladder), at the engine layer, consuming the mature feature-control.evaluate slice.
Adds spec/adr/ series + README; hub decision abf7830f recorded.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
spec/README + SCOPE list WikiEngineCoreArchitecture.md; CoreArchitectureBlueprint
cross-links the engine as a canonical-mode shard (federation/union stay in the
orchestrator). reuse-surface engine capability promoted D2->D3 (4204255).
Marks T6 + SHARD-WP-0013 done.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The optimal architecture synthesised from INTENT + the full research arc:
- Thesis: canonical at the edges, derived in the middle (orchestrator not engine)
- Dual narrow waist: adapter contract (15 capability spectra) + page model
- 6 layers + provenance/capability rails; L4 union/projection is a rebuildable cache
- Federation-model taxonomy (plural/composable); two-axis projection model;
moldable view registry; identity != placement; computational content in scope
as page-model+projection, out as execution platform
- Concrete src/ module layout with downward-only dependency rule
- Canonical data flows; policy surface; tradeoffs; full traceability to INTENT/UCs
References ArchitectureBlueprint.md as the L5 authorization sub-blueprint.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
