generated from coulomb/repo-seed
REUSE-WP-0015: dedup owner entries, add report gaps (T02/T03/T05)
Some checks failed
ci / validate-registry (push) Has been cancelled
Some checks failed
ci / validate-registry (push) Has been cancelled
Remove 17 owner-migrated capabilities from reuse-surface index (keep activity-core stub). Add report gaps CLI, roster stats + gaps CI steps. T01 remains operator-blocked on Gitea publish.
This commit is contained in:
@@ -1,80 +0,0 @@
|
||||
---
|
||||
id: capability.audit.event-retain
|
||||
name: Audit Event Retention
|
||||
summary: Collect, normalize, retain, and search audit events with integrity evidence across tenants.
|
||||
owner: audit-core
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [audit, retention, compliance]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D4
|
||||
target: D6
|
||||
confidence: medium
|
||||
rationale: audit-core INTENT defines full audit fabric scope and integration boundaries.
|
||||
availability:
|
||||
current: A2
|
||||
target: A5
|
||||
confidence: low
|
||||
rationale: Core modules exist; deployable service packaging in progress.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- retention and integrity goals documented
|
||||
broken_expectations:
|
||||
- federation with all platform runtimes not proven in registry
|
||||
out_of_scope_expectations:
|
||||
- application business audit semantics ownership
|
||||
reliability:
|
||||
level: R1
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- multi-tenant isolation not evidenced here
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Provide independent audit fabric for collecting, retaining, searching, and
|
||||
proving integrity of audit events.
|
||||
includes:
|
||||
- audit ingestion
|
||||
- retention policy
|
||||
- search and export
|
||||
- tamper evidence
|
||||
excludes:
|
||||
- generating domain business events
|
||||
use_cases: []
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A5
|
||||
current_artifacts:
|
||||
- audit-core/
|
||||
consumption_modes:
|
||||
- source module
|
||||
|
||||
relations:
|
||||
depends_on: []
|
||||
related_to:
|
||||
- capability.activity.event-coordinate
|
||||
- capability.statehub.progress-log
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- planning audit retention independent of a single product
|
||||
not_recommended_for:
|
||||
- replacing application-level logging only
|
||||
known_limitations:
|
||||
- consumer evidence not yet collected in registry
|
||||
---
|
||||
|
||||
# Audit Event Retention
|
||||
|
||||
Audit Core provides the retention and integrity layer for audit events across
|
||||
the platform.
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
id: capability.authorization.policy-evaluate
|
||||
name: Authorization Policy Evaluation
|
||||
summary: Evaluate access decisions from policy-as-code rules for subjects, resources, and actions.
|
||||
owner: flex-auth
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [authorization, policy, flex-auth]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D4
|
||||
target: D6
|
||||
confidence: medium
|
||||
rationale: flex-auth INTENT defines policy-as-code boundary and enterprise growth path.
|
||||
availability:
|
||||
current: A2
|
||||
target: A5
|
||||
confidence: low
|
||||
rationale: Policy registry and evaluation logic exist in repo; service packaging evolving.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- policy-as-code intent documented
|
||||
broken_expectations:
|
||||
- not yet indexed from flex-auth native registry
|
||||
out_of_scope_expectations:
|
||||
- identity proofing
|
||||
reliability:
|
||||
level: R1
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- early implementation phase
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Provide inspectable authorization decisions between verified identity and
|
||||
protected resources using policy-as-code.
|
||||
includes:
|
||||
- policy evaluation
|
||||
- authorization registry
|
||||
- decision explainability
|
||||
excludes:
|
||||
- identity issuance
|
||||
- authentication protocols
|
||||
use_cases: []
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A5
|
||||
current_artifacts:
|
||||
- flex-auth/
|
||||
consumption_modes:
|
||||
- source module
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.identity.subject-resolution
|
||||
related_to:
|
||||
- capability.feature-control.evaluate
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- planning authorization layer between identity and resources
|
||||
not_recommended_for:
|
||||
- feature visibility toggles without policy intent
|
||||
known_limitations:
|
||||
- maturity evidence is registry-external today
|
||||
---
|
||||
|
||||
# Authorization Policy Evaluation
|
||||
|
||||
Policy evaluation from flex-auth sits between identity resolution and protected
|
||||
systems.
|
||||
@@ -1,138 +0,0 @@
|
||||
---
|
||||
id: capability.feature-control.evaluate
|
||||
name: Feature Availability Evaluation
|
||||
summary: Evaluate whether a feature is active, hidden, disabled, or unavailable for a subject in context.
|
||||
owner: feature-control
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags:
|
||||
- feature-control
|
||||
- evaluation
|
||||
- sdk
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D5
|
||||
target: D7
|
||||
confidence: medium
|
||||
rationale: >
|
||||
Concrete use cases and research references are documented in the maturity
|
||||
standard example and feature-control domain work.
|
||||
availability:
|
||||
current: A4
|
||||
target: A6
|
||||
confidence: medium
|
||||
rationale: >
|
||||
SDK and service API artifacts exist in the feature-control repository.
|
||||
Managed platform operation is the natural target for multi-tenant reuse.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C3
|
||||
name: Functional Core
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- tenant-level feature evaluation
|
||||
- user-level feature evaluation
|
||||
- machine-readable decision result
|
||||
broken_expectations:
|
||||
- no agent-specific rule simulation
|
||||
- no bulk import/export of rules
|
||||
out_of_scope_expectations:
|
||||
- billing entitlement ownership
|
||||
- authorization policy enforcement
|
||||
reliability:
|
||||
level: R3
|
||||
name: Usable
|
||||
confidence: medium
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- unclear timeout behavior under heavy load
|
||||
- limited diagnostics for complex tenant rule conflicts
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Support controlled feature availability across installations, tenants,
|
||||
domains, groups, users, and agents.
|
||||
includes:
|
||||
- feature decision evaluation
|
||||
- context-aware targeting
|
||||
- explainable decision result
|
||||
excludes:
|
||||
- user authorization
|
||||
- billing entitlement ownership
|
||||
- UI rendering
|
||||
assumptions:
|
||||
- subject and tenant context can be resolved by adjacent capabilities
|
||||
use_cases:
|
||||
- ucc.feature-control.tenant-toggle
|
||||
- ucc.feature-control.agent-disable
|
||||
- ucc.feature-control.domain-rollout
|
||||
research_memos:
|
||||
- specs/CapabilityMaturityStandard.md
|
||||
|
||||
availability:
|
||||
current_level: A4
|
||||
target_level: A6
|
||||
current_artifacts:
|
||||
- feature-control/packages/feature-control-sdk
|
||||
- feature-control/services/feature-control-api
|
||||
target_artifacts:
|
||||
- feature-control/charts/feature-control
|
||||
- feature-control/platform/feature-control-service
|
||||
consumption_modes:
|
||||
- SDK
|
||||
- service API
|
||||
- managed platform service
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.identity.vocabulary-canonicalize
|
||||
supports:
|
||||
- capability.registry.register
|
||||
related_to:
|
||||
- capability.feature-control.rollout
|
||||
- capability.feature-control.visibility
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- specs/CapabilityMaturityStandard.md
|
||||
tests: []
|
||||
consumer_feedback: []
|
||||
bug_reports: []
|
||||
incidents: []
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- application integration through SDK or service API
|
||||
- tenant-aware feature gating in helix_forge products
|
||||
not_recommended_for:
|
||||
- authorization decisions
|
||||
- billing entitlement ownership
|
||||
- assuming agent-specific simulation without checking current scope
|
||||
known_limitations:
|
||||
- bulk rule management is not yet covered
|
||||
- agent-specific simulation remains a known gap
|
||||
---
|
||||
|
||||
# Feature Availability Evaluation
|
||||
|
||||
## Overview
|
||||
|
||||
This capability evaluates whether a feature should be available for a subject in
|
||||
a given context. It is the primary implementation-ready example in the sample
|
||||
registry and demonstrates a D5/A4/C3/R3 vector.
|
||||
|
||||
## Current reuse mode
|
||||
|
||||
Consumers can integrate through SDK or service API artifacts in the
|
||||
feature-control repository. This is implementation reuse (A4), not just planning
|
||||
metadata.
|
||||
|
||||
## Comparison notes
|
||||
|
||||
Compared with `capability.registry.register`, this entry is far stronger on
|
||||
availability and external evidence. Compared with
|
||||
`capability.identity.vocabulary-canonicalize`, it is stronger on delivery mode
|
||||
and weaker on cross-domain generalization.
|
||||
@@ -1,111 +0,0 @@
|
||||
---
|
||||
id: capability.feature-control.rollout
|
||||
name: Feature Rollout Control
|
||||
summary: Gradually expose features to subjects across tenants, domains, groups, or cohorts using rollout rules and staged availability.
|
||||
owner: feature-control
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags:
|
||||
- feature-control
|
||||
- rollout
|
||||
- planning
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D4
|
||||
target: D6
|
||||
confidence: medium
|
||||
rationale: >
|
||||
Rollout is a distinct bounded behavior from single-point evaluation, with
|
||||
research references in the feature-control domain and maturity standard.
|
||||
availability:
|
||||
current: A2
|
||||
target: A4
|
||||
confidence: low
|
||||
rationale: >
|
||||
Rollout logic may exist in source modules but is not yet consistently
|
||||
exposed as a standalone SDK or API surface distinct from evaluate.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- rollout concepts documented adjacent to feature evaluation
|
||||
broken_expectations:
|
||||
- no dedicated rollout artifact called out separately from evaluate
|
||||
- percentage and cohort rollout variants not indexed independently
|
||||
out_of_scope_expectations:
|
||||
- billing-driven entitlements
|
||||
reliability:
|
||||
level: R1
|
||||
name: Fragile
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- rollout behavior may be conflated with evaluate in consumer mental models
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Control how features become available over time and across cohorts without
|
||||
conflating rollout policy with authorization or billing.
|
||||
includes:
|
||||
- staged rollout rules
|
||||
- cohort and context targeting for rollout
|
||||
- explainable rollout state
|
||||
excludes:
|
||||
- one-time feature evaluation only
|
||||
- authorization decisions
|
||||
- billing entitlements
|
||||
assumptions:
|
||||
- feature evaluation capability exists for final availability decisions
|
||||
use_cases:
|
||||
- ucc.feature-control.domain-rollout
|
||||
research_memos:
|
||||
- specs/CapabilityMaturityStandard.md
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A4
|
||||
current_artifacts:
|
||||
- feature-control/packages/feature-control-sdk
|
||||
target_artifacts:
|
||||
- feature-control/services/feature-control-api
|
||||
consumption_modes:
|
||||
- source module
|
||||
- SDK
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.feature-control.evaluate
|
||||
supports: []
|
||||
related_to:
|
||||
- capability.feature-control.visibility
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- specs/CapabilityMaturityStandard.md
|
||||
tests: []
|
||||
consumer_feedback: []
|
||||
bug_reports: []
|
||||
incidents: []
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- planning staged feature exposure separate from binary evaluation
|
||||
not_recommended_for:
|
||||
- simple on/off evaluation without rollout semantics
|
||||
- entitlement or billing ownership
|
||||
known_limitations:
|
||||
- distinguish carefully from capability.feature-control.evaluate
|
||||
---
|
||||
|
||||
# Feature Rollout Control
|
||||
|
||||
## Overview
|
||||
|
||||
Rollout governs how availability changes over time and across cohorts. It
|
||||
complements evaluation, which answers whether a feature is available for a
|
||||
subject in a context right now.
|
||||
@@ -1,77 +0,0 @@
|
||||
---
|
||||
id: capability.feature-control.visibility
|
||||
name: Feature Visibility Control
|
||||
summary: Control whether features are visible or hidden for subjects without changing underlying entitlement or authorization.
|
||||
owner: feature-control
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [feature-control, visibility]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D4
|
||||
target: D5
|
||||
confidence: medium
|
||||
rationale: Bounded as distinct from evaluation and rollout in feature-control domain.
|
||||
availability:
|
||||
current: A2
|
||||
target: A4
|
||||
confidence: low
|
||||
rationale: May share SDK artifacts with evaluate but is not separately exposed as API.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- visibility distinguished from evaluation in registry model
|
||||
broken_expectations:
|
||||
- no standalone visibility API documented separately
|
||||
out_of_scope_expectations:
|
||||
- authorization policy decisions
|
||||
reliability:
|
||||
level: R1
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- easily conflated with evaluate capability
|
||||
|
||||
discovery:
|
||||
intent: Govern feature visibility separately from availability evaluation and rollout staging.
|
||||
includes:
|
||||
- hide/show feature UI or capability surfaces
|
||||
- visibility rules per subject context
|
||||
excludes:
|
||||
- entitlement ownership
|
||||
- rollout percentage control
|
||||
use_cases: []
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A4
|
||||
current_artifacts:
|
||||
- feature-control/packages/feature-control-sdk
|
||||
consumption_modes:
|
||||
- source module
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.feature-control.evaluate
|
||||
related_to:
|
||||
- capability.feature-control.rollout
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- planning visibility behavior separate from on/off evaluation
|
||||
not_recommended_for:
|
||||
- authorization or billing gating
|
||||
known_limitations:
|
||||
- implementation may be bundled with evaluate SDK today
|
||||
---
|
||||
|
||||
# Feature Visibility Control
|
||||
|
||||
Visibility governs whether a feature surface appears, distinct from whether the
|
||||
feature is enabled for a subject.
|
||||
@@ -1,115 +0,0 @@
|
||||
---
|
||||
id: capability.identity.subject-resolution
|
||||
name: Identity Subject Resolution
|
||||
summary: Resolve who or what is acting in a context by mapping principals, accounts, actors, and identifiers to a stable subject model.
|
||||
owner: identity-canon
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags:
|
||||
- identity
|
||||
- subject
|
||||
- architecture
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D3
|
||||
target: D5
|
||||
confidence: medium
|
||||
rationale: >
|
||||
Subject/principal terminology is explored in identity-canon conflict maps
|
||||
and conceptual model, but dedicated use-case grounding is incomplete.
|
||||
availability:
|
||||
current: A0
|
||||
target: A4
|
||||
confidence: low
|
||||
rationale: >
|
||||
Canon and research artifacts exist; no standalone resolver service or SDK
|
||||
is registered yet.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C1
|
||||
name: Fragmentary
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- overloaded subject and principal terms are mapped as candidates
|
||||
broken_expectations:
|
||||
- no runtime resolver artifact
|
||||
- canonical subject model not finalized across all actor types
|
||||
out_of_scope_expectations:
|
||||
- authentication protocol implementation
|
||||
- credential storage
|
||||
reliability:
|
||||
level: R0
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- draft terminology may change during source-note backfill
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Give planners and implementers a consistent subject concept for authorization,
|
||||
feature control, tenancy, and agent workflows without collapsing product-specific
|
||||
identity models.
|
||||
includes:
|
||||
- subject vs principal vs account distinctions
|
||||
- actor type modeling
|
||||
- identifier resolution concepts
|
||||
excludes:
|
||||
- authentication execution
|
||||
- credential issuance
|
||||
- directory provisioning
|
||||
assumptions:
|
||||
- vocabulary canonicalization supports but does not replace subject resolution
|
||||
use_cases:
|
||||
- UC-RS-004
|
||||
research_memos:
|
||||
- identity-canon/terminology/TerminologyConflictMap.md
|
||||
- identity-canon/model/ConceptualModel.md
|
||||
|
||||
availability:
|
||||
current_level: A0
|
||||
target_level: A4
|
||||
current_artifacts:
|
||||
- identity-canon/model/ConceptualModel.md
|
||||
- identity-canon/canon/CanonicalGlossary.md
|
||||
target_artifacts:
|
||||
- identity-canon/packages/subject-resolution-sdk
|
||||
consumption_modes:
|
||||
- informational
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.identity.vocabulary-canonicalize
|
||||
supports:
|
||||
- capability.feature-control.evaluate
|
||||
- capability.statehub.workstream-coordinate
|
||||
related_to: []
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- identity-canon/canon/CanonicalGlossary.md
|
||||
- identity-canon/scenarios/ScenarioTests.md
|
||||
tests: []
|
||||
consumer_feedback: []
|
||||
bug_reports: []
|
||||
incidents: []
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- architecture planning where subject/principal/account terms overlap
|
||||
not_recommended_for:
|
||||
- runtime authentication or token validation
|
||||
- treating draft canon as finalized resolver behavior
|
||||
known_limitations:
|
||||
- resolver artifacts are not yet available
|
||||
---
|
||||
|
||||
# Identity Subject Resolution
|
||||
|
||||
## Overview
|
||||
|
||||
Subject resolution defines how actors and identifiers map to a stable subject
|
||||
concept for downstream capabilities such as feature evaluation and coordination.
|
||||
Today this capability is planning-heavy (D3/A0).
|
||||
@@ -1,136 +0,0 @@
|
||||
---
|
||||
id: capability.identity.vocabulary-canonicalize
|
||||
name: Identity Vocabulary Canonicalization
|
||||
summary: Define and maintain an implementation-neutral vocabulary for identity-related concepts across overlapping domains.
|
||||
owner: identity-canon
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags:
|
||||
- identity
|
||||
- terminology
|
||||
- research
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D4
|
||||
target: D6
|
||||
confidence: medium
|
||||
rationale: >
|
||||
identity-canon has researched overlapping terminology across IAM,
|
||||
directory, federation, and authorization domains, but use-case saturation
|
||||
is not yet demonstrated.
|
||||
availability:
|
||||
current: A0
|
||||
target: A2
|
||||
confidence: medium
|
||||
rationale: >
|
||||
The capability is available as research and canon documentation only.
|
||||
Future source modules or libraries could raise availability to A2.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- draft canonical glossary exists
|
||||
- terminology conflict map exists
|
||||
- conceptual model and scenario tests exist
|
||||
broken_expectations:
|
||||
- individual source notes are not fully backfilled
|
||||
- many mappings remain candidate rather than finalized
|
||||
out_of_scope_expectations:
|
||||
- operating identity providers
|
||||
- provisioning or authorization engines
|
||||
reliability:
|
||||
level: R0
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- draft canon terms may change as source evidence is backfilled
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Provide a reusable planning primitive for identity vocabulary so architects
|
||||
and agents can compare overlapping terms consistently without collapsing
|
||||
product-specific meanings into one ambiguous label.
|
||||
includes:
|
||||
- canonical glossary maintenance
|
||||
- terminology conflict mapping
|
||||
- conceptual model and scenario tests
|
||||
- research corpus indexing
|
||||
excludes:
|
||||
- identity provider implementation
|
||||
- account lifecycle services
|
||||
- authorization policy enforcement
|
||||
assumptions:
|
||||
- external product mappings remain separate from canonical definitions
|
||||
use_cases:
|
||||
- UC-RS-004
|
||||
- UC-RS-006
|
||||
research_memos:
|
||||
- identity-canon/ResearchProposal.md
|
||||
- identity-canon/canon/CanonicalGlossary.md
|
||||
|
||||
availability:
|
||||
current_level: A0
|
||||
target_level: A2
|
||||
current_artifacts:
|
||||
- identity-canon/canon/CanonicalGlossary.md
|
||||
- identity-canon/terminology/TerminologyConflictMap.md
|
||||
- identity-canon/model/ConceptualModel.md
|
||||
target_artifacts:
|
||||
- identity-canon/packages/identity-vocabulary
|
||||
consumption_modes:
|
||||
- informational
|
||||
- markdown research artifacts
|
||||
|
||||
relations:
|
||||
depends_on: []
|
||||
supports:
|
||||
- capability.feature-control.evaluate
|
||||
- capability.registry.register
|
||||
related_to:
|
||||
- capability.identity.subject-resolution
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- identity-canon/INTENT.md
|
||||
- identity-canon/canon/CanonicalGlossary.md
|
||||
tests: []
|
||||
consumer_feedback: []
|
||||
bug_reports: []
|
||||
incidents: []
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- architecture and planning conversations involving overloaded identity terms
|
||||
- comparing IAM, directory, and authorization vocabulary without forcing one product model
|
||||
not_recommended_for:
|
||||
- runtime identity resolution
|
||||
- assuming draft canon entries are finalized standards
|
||||
known_limitations:
|
||||
- source-note backfill is incomplete
|
||||
- mappings may remain candidate until evidence review completes
|
||||
---
|
||||
|
||||
# Identity Vocabulary Canonicalization
|
||||
|
||||
## Overview
|
||||
|
||||
This capability makes identity vocabulary reusable for planning across adjacent
|
||||
domains. It is intentionally research-heavy and informational, illustrating a
|
||||
D4/A0/C2/R0 vector that contrasts with implementation-ready entries.
|
||||
|
||||
## Current reuse mode
|
||||
|
||||
Consumers read canon, terminology, and model artifacts in the identity-canon
|
||||
repository. The value is planning reuse through shared vocabulary, not runtime
|
||||
integration.
|
||||
|
||||
## Relation to adjacent capabilities
|
||||
|
||||
Feature-control evaluation depends on consistent subject and tenant concepts.
|
||||
This capability supports that planning layer without providing runtime identity
|
||||
services itself.
|
||||
@@ -1,91 +0,0 @@
|
||||
---
|
||||
id: capability.statehub.progress-log
|
||||
name: Work Progress Logging
|
||||
summary: Record progress events, decisions, and session notes against workstreams and tasks in State Hub.
|
||||
owner: state-hub
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [state-hub, progress, coordination]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D4
|
||||
target: D5
|
||||
confidence: medium
|
||||
rationale: Progress API and agent session protocol are documented in state-hub AGENTS.md.
|
||||
availability:
|
||||
current: A4
|
||||
target: A6
|
||||
confidence: medium
|
||||
rationale: Available via State Hub HTTP POST /progress/ endpoint.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C3
|
||||
name: Functional Core
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- progress events attach to workstreams
|
||||
- agents can log session summaries
|
||||
broken_expectations: []
|
||||
out_of_scope_expectations:
|
||||
- replacing git commit history
|
||||
reliability:
|
||||
level: R3
|
||||
name: Usable
|
||||
confidence: medium
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- depends on hub availability and tunnel health for remote agents
|
||||
evidence:
|
||||
satisfied_signals:
|
||||
- reuse-surface AGENTS.md session-close protocol cites POST /progress/
|
||||
- cross-repo agents log progress with workstream_id linkage
|
||||
|
||||
discovery:
|
||||
intent: Provide auditable progress memory for cross-repo agent and operator work.
|
||||
includes:
|
||||
- progress event creation
|
||||
- workstream and task linkage
|
||||
- author attribution
|
||||
excludes:
|
||||
- canonical workplan storage
|
||||
use_cases: []
|
||||
|
||||
availability:
|
||||
current_level: A4
|
||||
target_level: A6
|
||||
current_artifacts:
|
||||
- state-hub/api/
|
||||
consumption_modes:
|
||||
- service API
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.statehub.workstream-coordinate
|
||||
supports: []
|
||||
related_to:
|
||||
- capability.statehub.workstream-coordinate
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- AGENTS.md
|
||||
consumer_feedback:
|
||||
- >
|
||||
reuse-surface agents (REUSE-WP-0012): session-close progress posts to State
|
||||
Hub succeeded for workstream fb0b6067 during federation workplan work.
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- closing agent sessions with hub progress notes
|
||||
not_recommended_for:
|
||||
- authoritative task status (use workplan files + fix-consistency)
|
||||
known_limitations:
|
||||
- hub must be running locally or via tunnel
|
||||
---
|
||||
|
||||
# Work Progress Logging
|
||||
|
||||
Progress logging complements file-backed workplans with live session memory in
|
||||
State Hub.
|
||||
@@ -1,117 +0,0 @@
|
||||
---
|
||||
id: capability.statehub.workstream-coordinate
|
||||
name: Workstream And Task Coordination
|
||||
summary: Track active workstreams, tasks, progress, and consistency across domain repositories through a local-first coordination service.
|
||||
owner: state-hub
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags:
|
||||
- state-hub
|
||||
- coordination
|
||||
- workplans
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D4
|
||||
target: D5
|
||||
confidence: medium
|
||||
rationale: >
|
||||
State Hub intent, scope, and ADR-001 workplan conventions are documented;
|
||||
concrete agent workflows are still being standardized across repos.
|
||||
availability:
|
||||
current: A4
|
||||
target: A6
|
||||
confidence: medium
|
||||
rationale: >
|
||||
Consumers integrate through the State Hub HTTP API and custodian scripts.
|
||||
Managed platform operation is the natural target for multi-repo agents.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C3
|
||||
name: Functional Core
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- workstream and task tracking via HTTP API
|
||||
- workplan file to database consistency sync
|
||||
- progress event logging
|
||||
broken_expectations:
|
||||
- no native MCP server for all agent environments
|
||||
out_of_scope_expectations:
|
||||
- replacing git-backed workplan canon
|
||||
- identity authority
|
||||
reliability:
|
||||
level: R2
|
||||
name: Tolerable
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- depends on local hub availability and operator maintenance
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Give agents and operators a live, queryable memory of work across domains
|
||||
without replacing file-backed workplans and governance canon.
|
||||
includes:
|
||||
- workstream and task indexing
|
||||
- progress and decision events
|
||||
- repo consistency synchronization
|
||||
- inbox and human-review flags
|
||||
excludes:
|
||||
- canon ownership
|
||||
- task factory for all work origins
|
||||
- identity authority
|
||||
assumptions:
|
||||
- workplans remain authoritative in git for ADR-001 repos
|
||||
use_cases:
|
||||
- UC-RS-013
|
||||
research_memos:
|
||||
- state-hub/INTENT.md
|
||||
|
||||
availability:
|
||||
current_level: A4
|
||||
target_level: A6
|
||||
current_artifacts:
|
||||
- state-hub/api/
|
||||
- state-hub/scripts/consistency_check.py
|
||||
target_artifacts:
|
||||
- state-hub/platform/state-hub-service
|
||||
consumption_modes:
|
||||
- service API
|
||||
- HTTP REST
|
||||
|
||||
relations:
|
||||
depends_on: []
|
||||
supports:
|
||||
- capability.registry.register
|
||||
related_to:
|
||||
- capability.statehub.progress-log
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- state-hub/INTENT.md
|
||||
- state-hub/AGENTS.md
|
||||
tests: []
|
||||
consumer_feedback: []
|
||||
bug_reports: []
|
||||
incidents: []
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- cross-repo agent orientation and task status sync
|
||||
- logging progress after workplan changes
|
||||
not_recommended_for:
|
||||
- storing canonical requirements or architecture canon
|
||||
- assuming hub state overrides git workplan files
|
||||
known_limitations:
|
||||
- requires running State Hub locally or via tunnel
|
||||
---
|
||||
|
||||
# Workstream And Task Coordination
|
||||
|
||||
## Overview
|
||||
|
||||
State Hub provides live coordination for helix_forge repositories while
|
||||
workplans remain file-backed. This entry represents the service/API consumption
|
||||
mode for cross-repo agent work.
|
||||
@@ -1,103 +0,0 @@
|
||||
---
|
||||
id: capability.wiki.adapter-contract
|
||||
name: Capability-Aware Shard Adapter Contract
|
||||
summary: A versioned backend interface where each binding declares a verified capability profile (positions on capability spectra), so federation ops degrade by capability.
|
||||
owner: shard-wiki
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [wiki, adapter, capability, contract, conformance, shard-wiki]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D5
|
||||
target: D6
|
||||
confidence: high
|
||||
rationale: >
|
||||
Fifteen capability spectra with an orthogonal core + implication rules, plus
|
||||
a normative contract spec (TSD Section A); derived from a ~23-system synthesis.
|
||||
availability:
|
||||
current: A2
|
||||
target: A5
|
||||
confidence: medium
|
||||
rationale: >
|
||||
AdapterContract + a read/write FolderAdapter + a conformance suite that
|
||||
verifies declared profile == observed behaviour exist as a source module.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- versioned interface with declared, conformance-verified capability profiles
|
||||
- one concrete adapter (file-store) passes the conformance suite
|
||||
broken_expectations:
|
||||
- only one substrate implemented (git-IS-store, REST, CRDT adapters planned)
|
||||
out_of_scope_expectations:
|
||||
- hosting backends
|
||||
reliability:
|
||||
level: R1
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- single adapter implemented so far
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Mediate heterogeneity at one narrow waist: a backend participates by implementing a
|
||||
versioned interface and declaring a verified position on each capability spectrum.
|
||||
includes:
|
||||
- capability profile as data (orthogonal-core spectra + implied positions)
|
||||
- operation verbs (read/write/diff/merge/notify/.../derive-projection/execute)
|
||||
- a conformance suite (profiles verified, not self-asserted)
|
||||
excludes:
|
||||
- assuming uniform backend capabilities
|
||||
use_cases:
|
||||
- "shard-wiki UseCaseCatalog UC-34..UC-43, UC-50, UC-57, UC-60..UC-69 (shard attachment & adapter binding)"
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A5
|
||||
current_artifacts:
|
||||
- "shard-wiki/src/shard_wiki/adapters/"
|
||||
consumption_modes:
|
||||
- source module
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.wiki.page-model
|
||||
supports:
|
||||
- capability.wiki.shard-orchestration
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- "shard-wiki/spec/TechnicalSpecificationDocument.md (Section A)"
|
||||
- "shard-wiki/spec/CoreArchitectureBlueprint.md (Section 6)"
|
||||
tests:
|
||||
- "shard-wiki/tests/test_folder_adapter.py"
|
||||
- "shard-wiki/tests/test_conformance.py"
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- exposing any page store as a capability-described, conformance-checked shard
|
||||
not_recommended_for:
|
||||
- backends that cannot honestly describe their capabilities
|
||||
known_limitations:
|
||||
- reference implementation covers the file-store substrate only so far
|
||||
---
|
||||
|
||||
# Capability-Aware Shard Adapter Contract
|
||||
|
||||
The bottom narrow waist of shard-wiki: a versioned interface plus a **verified** capability
|
||||
profile per binding. Core logic is written once against capabilities (not per-backend), and
|
||||
the conformance suite rejects profiles whose declared abilities don't match observed behaviour.
|
||||
|
||||
## Assessment notes
|
||||
|
||||
### Discovery
|
||||
Fifteen spectra reduced to an orthogonal core with implication rules (CoreArchitectureBlueprint
|
||||
Section 6.5); normative in TSD Section A.
|
||||
|
||||
### Availability
|
||||
`adapters/` ships the contract, a folder adapter, and `assert_conformant`.
|
||||
@@ -1,103 +0,0 @@
|
||||
---
|
||||
id: capability.wiki.coordination-journal
|
||||
name: Event-Sourced Coordination Journal
|
||||
summary: An append-only, totally-ordered-per-space decision log (overlays, bindings, aliases, merges, forks) whose current state is a derived fold; git-addressable history.
|
||||
owner: shard-wiki
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [wiki, event-sourcing, coordination, git, journal, shard-wiki]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D5
|
||||
target: D6
|
||||
confidence: high
|
||||
rationale: >
|
||||
Keystone resolved across two architecture reviews: coordination-canonical state
|
||||
as an append-only decision log with a per-space append authority; current state
|
||||
is a derived fold (derived = f(log)).
|
||||
availability:
|
||||
current: A2
|
||||
target: A4
|
||||
confidence: medium
|
||||
rationale: >
|
||||
In-memory DecisionLog + fold work as a source module; the git-backed store with a
|
||||
per-space lease (the production backing) is planned.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- append-only, totally-ordered-per-space log with read-your-writes
|
||||
- derived fold to aliases + transitively-merged equivalence groups
|
||||
broken_expectations:
|
||||
- git-backed storage and per-space lease/append-authority not yet implemented
|
||||
out_of_scope_expectations:
|
||||
- general-purpose event bus
|
||||
reliability:
|
||||
level: R1
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- in-memory backing only; cross-process durability pending
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Make coordination-canonical decisions durable and git-addressable as events, with the
|
||||
queryable current state always recomputable by replay.
|
||||
includes:
|
||||
- append-only decision log, totally ordered per information space
|
||||
- derived fold to current coordination state (aliases, equivalence groups, overlays)
|
||||
- per-space append authority (concurrency model)
|
||||
excludes:
|
||||
- storing derived/disposable union state
|
||||
use_cases:
|
||||
- "shard-wiki UseCaseCatalog UC-29, UC-33 (history, attribution, coordination journal)"
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A4
|
||||
current_artifacts:
|
||||
- "shard-wiki/src/shard_wiki/coordination/decision_log.py"
|
||||
target_artifacts:
|
||||
- git-backed log store with per-space lease
|
||||
consumption_modes:
|
||||
- source module
|
||||
|
||||
relations:
|
||||
supports:
|
||||
- capability.wiki.shard-orchestration
|
||||
- capability.wiki.overlay
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- "shard-wiki/spec/CoreArchitectureBlueprint.md (Section 8.1)"
|
||||
tests:
|
||||
- "shard-wiki/tests/test_decision_log.py"
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- durable, replayable, git-addressable coordination state for a federated space
|
||||
not_recommended_for:
|
||||
- high-frequency general event streaming
|
||||
known_limitations:
|
||||
- production git backing + lease are still on the roadmap (SHARD-WP-0009)
|
||||
---
|
||||
|
||||
# Event-Sourced Coordination Journal
|
||||
|
||||
The keystone: coordination-canonical state (overlays, equivalence bindings, aliases, merges,
|
||||
forks) is an append-only **decision log**, totally ordered per information space; the queryable
|
||||
current state is a derived **fold** of the log (`derived = f(log)`). The log is git-addressable,
|
||||
giving history/patch/review/backup for coordination decisions for free.
|
||||
|
||||
## Assessment notes
|
||||
|
||||
### Discovery
|
||||
Resolved across the round-1/round-2 architecture reviews (CoreArchitectureBlueprint Section 8.1).
|
||||
|
||||
### Availability
|
||||
`decision_log.py` ships an in-memory, totally-ordered log + fold; git+lease backing is planned.
|
||||
@@ -1,87 +0,0 @@
|
||||
---
|
||||
id: capability.wiki.derived-views
|
||||
name: Wiki Derived Views
|
||||
summary: Recomputable views over a wiki union — BackLinks, RecentChanges, AllPages, SiteMap, and (delegate-or-derive) Search — carrying provenance.
|
||||
owner: shard-wiki
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [wiki, derived-views, backlinks, recentchanges, search, shard-wiki]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D3
|
||||
target: D5
|
||||
confidence: medium
|
||||
rationale: >
|
||||
Core-vs-adapter classification and behaviours are decided (FederationRequirements ADR-03);
|
||||
implementation is planned (SHARD-WP-0010), not built.
|
||||
availability:
|
||||
current: A0
|
||||
target: A4
|
||||
confidence: low
|
||||
rationale: >
|
||||
Designed; no implementation yet. Informational/planning reuse only today.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C0
|
||||
name: Absent
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations: []
|
||||
broken_expectations:
|
||||
- no derived view is implemented yet
|
||||
out_of_scope_expectations:
|
||||
- presentation / rendering of views
|
||||
reliability:
|
||||
level: R0
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- planning-stage
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Provide recomputable, provenance-carrying views over the union (link graph, change feed,
|
||||
enumeration, search) without introducing canonical state.
|
||||
includes:
|
||||
- BackLinks (link graph), RecentChanges (journal + shard signals), AllPages, SiteMap
|
||||
- Search as delegate-to-native-or-derive-index
|
||||
excludes:
|
||||
- view presentation / UI
|
||||
use_cases:
|
||||
- "shard-wiki UseCaseCatalog UC-17..UC-21, UC-63"
|
||||
|
||||
availability:
|
||||
current_level: A0
|
||||
target_level: A4
|
||||
current_artifacts:
|
||||
- "shard-wiki/workplans/SHARD-WP-0010-derived-views.md"
|
||||
consumption_modes:
|
||||
- informational
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.wiki.shard-orchestration
|
||||
- capability.wiki.page-model
|
||||
related_to:
|
||||
- capability.wiki.engine-typed-extensions
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- "shard-wiki/spec/FederationRequirements.md (ADR-03)"
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- planning derived navigation/discovery over a federated wiki union
|
||||
not_recommended_for:
|
||||
- implementation reuse today (planning-stage)
|
||||
known_limitations:
|
||||
- not implemented; Search ranking policy undecided
|
||||
---
|
||||
|
||||
# Wiki Derived Views
|
||||
|
||||
Recomputable views over the union (BackLinks, RecentChanges, AllPages, SiteMap, Search). All
|
||||
are derived/disposable (no canonical state) and carry provenance; Search is delegate-to-native
|
||||
where a shard's query capability allows, else a derived index. Planned in SHARD-WP-0010.
|
||||
@@ -1,115 +0,0 @@
|
||||
---
|
||||
id: capability.wiki.engine-typed-extensions
|
||||
name: Wiki Engine with Typed Extensions
|
||||
summary: A small-core wiki engine realizing a stringent typed-extension framework that addresses all wiki use cases and lets each shard activate only the features it needs.
|
||||
owner: shard-wiki
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [wiki, engine, typed-extensions, feature-activation, shard-wiki]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D3
|
||||
target: D5
|
||||
confidence: medium
|
||||
rationale: >
|
||||
Architecture authored (shard-wiki/spec/WikiEngineCoreArchitecture.md): small page-store
|
||||
kernel + typed-extension framework, per-shard activation, engine-as-canonical-mode-shard,
|
||||
and a conflict-mediation realization are explored. Detailed extension SDK/ABI and the API
|
||||
protocol remain (so D3 Explored, not yet D4/D5).
|
||||
availability:
|
||||
current: A0
|
||||
target: A4
|
||||
confidence: low
|
||||
rationale: >
|
||||
Planned. No engine kernel or extensions exist yet; informational/planning reuse only.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C0
|
||||
name: Absent
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations: []
|
||||
broken_expectations:
|
||||
- engine core and typed-extension mechanism not yet designed in detail
|
||||
out_of_scope_expectations:
|
||||
- replacing other wiki engines or mandating one implementation
|
||||
reliability:
|
||||
level: R0
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- planning-stage capability
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Provide shard-wiki's reference first-party shard backend: a small core + a stringent
|
||||
typed-extension framework covering all collected use cases, mediating conflicting
|
||||
requirements into an integrated whole, with per-shard activation (only what you need).
|
||||
includes:
|
||||
- a minimal engine kernel (page lifecycle, storage via the adapter contract, the typing mechanism)
|
||||
- typed extensions that declare contracts and compose
|
||||
- per-shard feature activation
|
||||
excludes:
|
||||
- replacing or mandating other wiki engines (it is one shard type among many)
|
||||
- a single canonical implementation for all wikis
|
||||
use_cases:
|
||||
- "shard-wiki UseCaseCatalog UC-08..UC-25 and the full catalog (the engine must cover all)"
|
||||
|
||||
availability:
|
||||
current_level: A0
|
||||
target_level: A4
|
||||
current_artifacts:
|
||||
- "shard-wiki/workplans/SHARD-WP-0013-wiki-engine-prep.md"
|
||||
- "shard-wiki/spec/WikiEngineCoreArchitecture.md"
|
||||
consumption_modes:
|
||||
- informational
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.wiki.adapter-contract
|
||||
- capability.wiki.page-model
|
||||
related_to:
|
||||
- capability.feature-control.evaluate
|
||||
- capability.authorization.policy-evaluate
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- "shard-wiki/workplans/SHARD-WP-0013-wiki-engine-prep.md"
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- planning a composable, feature-activatable native wiki engine
|
||||
not_recommended_for:
|
||||
- implementation reuse today (planning-stage)
|
||||
known_limitations:
|
||||
- architecture authored; extension SDK/ABI + API protocol still to design; not yet built
|
||||
|
||||
promotion_history:
|
||||
- date: "2026-06-15"
|
||||
dimension: discovery
|
||||
from: D2
|
||||
to: D3
|
||||
rationale: WikiEngineCoreArchitecture.md authored (kernel + typed-extension framework explored); INTENT amendment ratified.
|
||||
author: shard-wiki
|
||||
---
|
||||
|
||||
# Wiki Engine with Typed Extensions
|
||||
|
||||
shard-wiki's planned reference first-party shard backend — a *canonical-mode shard* it
|
||||
implements natively: a small core plus a stringent typed-extension framework addressing all
|
||||
collected use cases, mediating conflicting requirements into a consistent whole, with per-shard
|
||||
activation (activate only what you need). It is one shard type among many — not a replacement
|
||||
for other engines. Per-shard activation is a candidate consumer of
|
||||
`capability.feature-control.evaluate`.
|
||||
|
||||
## Assessment notes
|
||||
|
||||
### Discovery
|
||||
Architecture authored: `shard-wiki/spec/WikiEngineCoreArchitecture.md` (small kernel +
|
||||
typed-extension framework; engine = canonical-mode shard). INTENT amendment ratified
|
||||
(2026-06-15, decision 84ffdb48). Extension SDK/ABI + API protocol are the next deliverables.
|
||||
|
||||
### Availability
|
||||
Planning-stage; informational reuse only.
|
||||
@@ -1,97 +0,0 @@
|
||||
---
|
||||
id: capability.wiki.federation-models
|
||||
name: Selectable Federation-Model Taxonomy
|
||||
summary: Federation as a plural, composable coordination axis (fork+journal, VCS-replication+ping, query-time graph-join, feed, activity-streams, engine-mirror) selected per space.
|
||||
owner: shard-wiki
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [wiki, federation, taxonomy, composable, shard-wiki]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D4
|
||||
target: D6
|
||||
confidence: high
|
||||
rationale: >
|
||||
A six-model taxonomy distilled from a ~23-system synthesis, each model anchored in a
|
||||
real system, with capability prerequisites and per-space/per-shard composition rules.
|
||||
availability:
|
||||
current: A0
|
||||
target: A4
|
||||
confidence: low
|
||||
rationale: >
|
||||
Designed and specified (FederationArchitecture T17) but not implemented; informational
|
||||
reuse only today.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C1
|
||||
name: Sparse
|
||||
confidence: low
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- the model taxonomy and selection/composition rules are documented
|
||||
broken_expectations:
|
||||
- no federation transport is implemented yet
|
||||
out_of_scope_expectations:
|
||||
- mandating a single federation mechanism
|
||||
reliability:
|
||||
level: R0
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- design-stage; no runtime evidence
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Treat federation as selectable and composable rather than one mechanism, so each space
|
||||
picks fork+journal, VCS-replication, query-join, feed, activity-streams, or engine-mirror.
|
||||
includes:
|
||||
- the six federation models + their capability floors
|
||||
- per-space selection and per-shard composition
|
||||
excludes:
|
||||
- imposing one homogeneous federation network
|
||||
use_cases:
|
||||
- "shard-wiki UseCaseCatalog UC-26, UC-31, UC-33, UC-71, UC-72, UC-74, UC-79"
|
||||
|
||||
availability:
|
||||
current_level: A0
|
||||
target_level: A4
|
||||
current_artifacts:
|
||||
- "shard-wiki/spec/FederationArchitecture.md (T17)"
|
||||
consumption_modes:
|
||||
- informational
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.wiki.shard-orchestration
|
||||
- capability.wiki.coordination-journal
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- "shard-wiki/spec/FederationArchitecture.md"
|
||||
- "shard-wiki/research/260614-shard-spectrum-synthesis/findings.md"
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- planning a federation strategy that mixes models per source
|
||||
not_recommended_for:
|
||||
- implementation reuse today (design-stage)
|
||||
known_limitations:
|
||||
- no transport implemented; informational planning reuse only
|
||||
---
|
||||
|
||||
# Selectable Federation-Model Taxonomy
|
||||
|
||||
Federation is plural and composable: fork+journal (Federated Wiki), VCS-replication+ping
|
||||
(ikiwiki), query-time graph-join (Wikibase SERVICE), feed aggregation, activity streams
|
||||
(ActivityPub), and engine-mirror (Wiki.js). A space selects a model and composes per shard;
|
||||
the default is fork+journal over git. Design-stage capability — strong for planning reuse.
|
||||
|
||||
## Assessment notes
|
||||
|
||||
### Discovery
|
||||
FederationArchitecture T17, distilled from the shard-spectrum synthesis (v3).
|
||||
|
||||
### Availability
|
||||
Specified, not implemented — informational reuse only.
|
||||
@@ -1,102 +0,0 @@
|
||||
---
|
||||
id: capability.wiki.overlay
|
||||
name: Overlay-Before-Mutation Write Path
|
||||
summary: Non-destructive edits (draft -> patch -> apply-under-drift) that let read-only, rate-limited, or lossy backends be edited safely without silent remote mutation.
|
||||
owner: shard-wiki
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [wiki, overlay, patch, write-path, conflict, shard-wiki]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D5
|
||||
target: D6
|
||||
confidence: high
|
||||
rationale: >
|
||||
Overlay lifecycle and apply-under-drift semantics are specified (ADR-05, blueprint
|
||||
Section 8.6) and implemented as a single principled write path.
|
||||
availability:
|
||||
current: A2
|
||||
target: A4
|
||||
confidence: medium
|
||||
rationale: >
|
||||
OverlayEngine (draft/patch/apply), writable adapter, and InformationSpace.edit
|
||||
exist as a source module; three-way merge is not (refuse-on-drift only).
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- draft -> patch -> apply with fast-forward / refuse-on-drift / keep-draft outcomes
|
||||
- no silent remote mutation; overlay_state surfaced in provenance
|
||||
broken_expectations:
|
||||
- three-way / auto merge not implemented (refuse-on-conflict only)
|
||||
out_of_scope_expectations:
|
||||
- federation propagation of applied overlays
|
||||
reliability:
|
||||
level: R1
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- early implementation; conflict handling is detect-and-refuse only
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Make any sub-write-through backend editable safely: an edit is an overlay first, applied
|
||||
only on explicit intent and only when the source has not drifted.
|
||||
includes:
|
||||
- overlay drafts recorded as coordination-canonical events
|
||||
- patch rendering (unified diff)
|
||||
- apply-under-drift (fast-forward / refuse / keep-draft)
|
||||
excludes:
|
||||
- destructive write without drift check
|
||||
use_cases:
|
||||
- "shard-wiki UseCaseCatalog UC-04, UC-26, UC-29 (remix primitives, overlay)"
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A4
|
||||
current_artifacts:
|
||||
- "shard-wiki/src/shard_wiki/coordination/overlay.py"
|
||||
- "shard-wiki/src/shard_wiki/coordination/patch.py"
|
||||
consumption_modes:
|
||||
- source module
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.wiki.coordination-journal
|
||||
- capability.wiki.adapter-contract
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- "shard-wiki/spec/FederationRequirements.md (ADR-05)"
|
||||
- "shard-wiki/spec/CoreArchitectureBlueprint.md (Section 8.2, 8.6)"
|
||||
tests:
|
||||
- "shard-wiki/tests/test_apply.py"
|
||||
- "shard-wiki/tests/test_write_path_integration.py"
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- safe editing over read-only / rate-limited / lossy backends
|
||||
not_recommended_for:
|
||||
- workflows needing automatic conflict resolution today
|
||||
known_limitations:
|
||||
- merge is detect-and-refuse; three-way merge is future work
|
||||
---
|
||||
|
||||
# Overlay-Before-Mutation Write Path
|
||||
|
||||
One principled write path: every edit drafts an overlay (a coordination-canonical event),
|
||||
renders as a patch, and applies under drift checks — fast-forwarding a writable target,
|
||||
keeping a local draft on a read-only target, and refusing (never clobbering) on external drift.
|
||||
|
||||
## Assessment notes
|
||||
|
||||
### Discovery
|
||||
Specified in FederationRequirements ADR-05 and CoreArchitectureBlueprint Section 8.2/8.6.
|
||||
|
||||
### Availability
|
||||
`overlay.py` + `patch.py` + `InformationSpace.edit` ship the path; built in SHARD-WP-0008.
|
||||
@@ -1,104 +0,0 @@
|
||||
---
|
||||
id: capability.wiki.page-model
|
||||
name: Backend-Neutral Wiki Page Model
|
||||
summary: A Markdown-first but stretchable page model with stable identity separate from placement and layered provenance, spanning prose to typed-graph and computational shapes.
|
||||
owner: shard-wiki
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [wiki, page-model, identity, provenance, markdown, shard-wiki]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D5
|
||||
target: D6
|
||||
confidence: high
|
||||
rationale: >
|
||||
Page shapes (prose, typed records, typed-graph, inline-embedded, non-Markdown,
|
||||
and four computational shapes) plus identity != placement and layered provenance
|
||||
are specified and grounded in the dive research.
|
||||
availability:
|
||||
current: A2
|
||||
target: A5
|
||||
confidence: medium
|
||||
rationale: >
|
||||
Identity/Placement/Span/Page and layered ProvenanceEnvelope exist as a source
|
||||
module; richer shapes (typed-graph, notebook) are modeled but not all built.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- stable identity distinct from placement and from content fingerprint
|
||||
- layered (effective-vs-own) provenance with near-zero per-span cost
|
||||
broken_expectations:
|
||||
- non-prose shapes (typed-graph, notebook, inline-embedded) not fully realized
|
||||
out_of_scope_expectations:
|
||||
- rendering / presentation
|
||||
reliability:
|
||||
level: R1
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- prose shape is the only exercised path so far
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
One backend-neutral lingua franca every consumer sees; every shape reduces to
|
||||
(content|source, structure, provenance envelope, optional derivation rule).
|
||||
includes:
|
||||
- page identity (stable handle) vs placement (N paths/shards) vs equivalence (fingerprint)
|
||||
- layered provenance envelope (page + span deltas)
|
||||
- page-shape taxonomy incl. computational shapes
|
||||
excludes:
|
||||
- deriving identity from content (a fingerprint identifies a version, not a page)
|
||||
use_cases:
|
||||
- "shard-wiki UseCaseCatalog UC-34, UC-39, UC-44..UC-49, UC-55, UC-73, UC-83, UC-84"
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A5
|
||||
current_artifacts:
|
||||
- "shard-wiki/src/shard_wiki/model/"
|
||||
- "shard-wiki/src/shard_wiki/provenance/"
|
||||
consumption_modes:
|
||||
- source module
|
||||
|
||||
relations:
|
||||
supports:
|
||||
- capability.wiki.adapter-contract
|
||||
- capability.wiki.shard-orchestration
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- "shard-wiki/spec/CoreArchitectureBlueprint.md (Section 7)"
|
||||
- "shard-wiki/spec/FederationRequirements.md (ADR-02, ADR-04)"
|
||||
tests:
|
||||
- "shard-wiki/tests/test_model.py"
|
||||
- "shard-wiki/tests/test_provenance.py"
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- a portable, provenance-carrying representation of wiki pages across backends
|
||||
not_recommended_for:
|
||||
- cases needing a single canonical path per page (use identity, not path)
|
||||
known_limitations:
|
||||
- non-prose shapes specified ahead of implementation
|
||||
---
|
||||
|
||||
# Backend-Neutral Wiki Page Model
|
||||
|
||||
The top narrow waist: a Markdown-first model that stretches to typed records, typed-graph
|
||||
statements, inline-embedded objects, non-Markdown assets, and computational shapes. Identity
|
||||
is a stable handle; placement and equivalence are separate mechanisms; provenance is layered
|
||||
(effective = page envelope + span delta).
|
||||
|
||||
## Assessment notes
|
||||
|
||||
### Discovery
|
||||
Specified in CoreArchitectureBlueprint Section 7 and FederationRequirements ADR-02/04.
|
||||
|
||||
### Availability
|
||||
`model/` + `provenance/` ship the prose path and the layered envelope today.
|
||||
@@ -1,114 +0,0 @@
|
||||
---
|
||||
id: capability.wiki.shard-orchestration
|
||||
name: Wiki Shard Orchestration
|
||||
summary: Present a union of pages across heterogeneous wiki-shaped shards while preserving each shard's provenance, capabilities, and history.
|
||||
owner: shard-wiki
|
||||
status: draft
|
||||
domain: helix_forge
|
||||
tags: [wiki, federation, orchestration, union, shard-wiki]
|
||||
|
||||
maturity:
|
||||
discovery:
|
||||
current: D5
|
||||
target: D6
|
||||
confidence: high
|
||||
rationale: >
|
||||
Grounded in 84 documented use cases and a twice-reviewed whole-system
|
||||
architecture (CoreArchitectureBlueprint) derived from ~23 prior-art systems.
|
||||
availability:
|
||||
current: A2
|
||||
target: A5
|
||||
confidence: medium
|
||||
rationale: >
|
||||
InformationSpace orchestrator (attach -> resolve -> read, chorus on
|
||||
ambiguity) works as a Python source module; network API and incremental
|
||||
union are planned.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- attach folder shards and read a union page with layered provenance
|
||||
- chorus presentation of equivalent-but-divergent pages (union without erasure)
|
||||
broken_expectations:
|
||||
- incremental union maintenance and equivalence index not yet built
|
||||
- write-through federation transports not yet built
|
||||
out_of_scope_expectations:
|
||||
- hosting or replacing the underlying wiki engines
|
||||
reliability:
|
||||
level: R1
|
||||
confidence: low
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- early implementation; 64 tests but no production exposure
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
Let independently stored, differently implemented wikis behave as one
|
||||
coherent, versionable, inspectable information space without homogenizing them.
|
||||
includes:
|
||||
- union resolution across shards (identity-keyed)
|
||||
- chorus / designated-canonical presentation of equivalent pages
|
||||
- lazy replication projection of remote content with freshness
|
||||
excludes:
|
||||
- implementing a backend wiki engine (see capability.wiki.engine-typed-extensions)
|
||||
- silent remote mutation
|
||||
assumptions:
|
||||
- canonical truth lives in shards + a git coordination journal; the union is derived
|
||||
use_cases:
|
||||
- "shard-wiki UseCaseCatalog UC-01..UC-07, UC-26..UC-33 (information space, federation, coordination)"
|
||||
|
||||
availability:
|
||||
current_level: A2
|
||||
target_level: A5
|
||||
current_artifacts:
|
||||
- "shard-wiki/src/shard_wiki/union/"
|
||||
- "shard-wiki/src/shard_wiki/space.py"
|
||||
target_artifacts:
|
||||
- orchestrator network API
|
||||
consumption_modes:
|
||||
- source module
|
||||
|
||||
relations:
|
||||
depends_on:
|
||||
- capability.wiki.adapter-contract
|
||||
- capability.wiki.page-model
|
||||
- capability.wiki.coordination-journal
|
||||
supports:
|
||||
- capability.wiki.federation-models
|
||||
|
||||
evidence:
|
||||
documentation:
|
||||
- "shard-wiki/spec/CoreArchitectureBlueprint.md"
|
||||
- "shard-wiki/spec/FederationArchitecture.md"
|
||||
tests:
|
||||
- "shard-wiki/tests/test_union.py"
|
||||
- "shard-wiki/tests/test_integration.py"
|
||||
|
||||
consumer_guidance:
|
||||
recommended_for:
|
||||
- composing multiple Markdown/wiki stores into one provenance-preserving view
|
||||
not_recommended_for:
|
||||
- replacing a single wiki engine
|
||||
known_limitations:
|
||||
- resolution is recompute-on-read until the incremental tier lands
|
||||
---
|
||||
|
||||
# Wiki Shard Orchestration
|
||||
|
||||
shard-wiki's core capability: orchestrate wiki-shaped content across heterogeneous *shards*
|
||||
as a union of pages, preserving provenance, capabilities, and history per shard. Canonical
|
||||
truth stays at the edges (shards + the git coordination journal); the union is a derived,
|
||||
recomputable view (orchestrator, not engine).
|
||||
|
||||
## Assessment notes
|
||||
|
||||
### Discovery
|
||||
Grounded by `UseCaseCatalog.md` (84 UCs) and the hardened `CoreArchitectureBlueprint.md`.
|
||||
|
||||
### Availability
|
||||
`InformationSpace` provides attach/resolve/read today (source module); a network API is the
|
||||
target availability step.
|
||||
Reference in New Issue
Block a user