generated from coulomb/repo-seed
Complete REUSE-WP-0003: registry CLI, docs alignment, and coverage
Align INTENT.md with delivered layout, add CapabilityRegistryConcept guide, extend schema with promotion_history, ship reuse-surface validate/query/export CLI, register three more helix_forge capabilities, and refresh SCOPE and gap analysis to reflect A3 tooling and D5/A3/C4/R2 self-assessment.
This commit is contained in:
111
registry/capabilities/capability.feature-control.rollout.md
Normal file
111
registry/capabilities/capability.feature-control.rollout.md
Normal file
@@ -0,0 +1,111 @@
|
||||
---
|
||||
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.
|
||||
115
registry/capabilities/capability.identity.subject-resolution.md
Normal file
115
registry/capabilities/capability.identity.subject-resolution.md
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
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).
|
||||
@@ -20,34 +20,38 @@ maturity:
|
||||
registry model is bounded in INTENT.md, but concrete promotion workflows
|
||||
are not yet grounded in registry artifacts.
|
||||
availability:
|
||||
current: A0
|
||||
current: A3
|
||||
target: A3
|
||||
confidence: medium
|
||||
rationale: >
|
||||
Registration is currently manual through Markdown entries and the index.
|
||||
A CLI validator/query tool would raise availability to A3.
|
||||
Registration and maintenance are automatable through the reuse-surface CLI
|
||||
for validate, query, and export workflows.
|
||||
|
||||
external_evidence:
|
||||
completeness:
|
||||
level: C1
|
||||
name: Fragmentary
|
||||
confidence: low
|
||||
level: C2
|
||||
name: Partial
|
||||
confidence: medium
|
||||
basis: scope_vs_intent_and_consumer_expectations
|
||||
satisfied_expectations:
|
||||
- capability IDs can be assigned in registry entries
|
||||
- maturity vectors can be recorded at registration time
|
||||
- CLI validate, query, and export support registry workflows
|
||||
- promotion history can be recorded in entries
|
||||
broken_expectations:
|
||||
- no automated duplicate detection yet
|
||||
- no promotion history tracking yet
|
||||
out_of_scope_expectations:
|
||||
- hosting registered capabilities
|
||||
- enforcing implementation architecture
|
||||
reliability:
|
||||
level: R0
|
||||
confidence: low
|
||||
level: R2
|
||||
name: Tolerable
|
||||
confidence: medium
|
||||
basis: consumer_quality_signals
|
||||
known_reliability_risks:
|
||||
- registry consistency depends on manual index maintenance
|
||||
- index drift still possible if authors skip validate
|
||||
- CLI requires local venv install
|
||||
- schema ID pattern required a fix during WP-0003 dogfooding
|
||||
|
||||
discovery:
|
||||
intent: >
|
||||
@@ -72,17 +76,17 @@ discovery:
|
||||
- specs/ProductRequirementsDocument.md
|
||||
|
||||
availability:
|
||||
current_level: A0
|
||||
current_level: A3
|
||||
target_level: A3
|
||||
current_artifacts:
|
||||
- templates/capability-entry.template.md
|
||||
- registry/indexes/capabilities.yaml
|
||||
target_artifacts:
|
||||
- tools/validate-registry
|
||||
- tools/query-registry
|
||||
- reuse_surface/cli.py
|
||||
target_artifacts: []
|
||||
consumption_modes:
|
||||
- informational
|
||||
- markdown authoring
|
||||
- cli
|
||||
|
||||
relations:
|
||||
depends_on: []
|
||||
@@ -111,6 +115,26 @@ consumer_guidance:
|
||||
known_limitations:
|
||||
- manual index updates are required after adding an entry
|
||||
- duplicate detection is guidance-only in the MVP
|
||||
|
||||
promotion_history:
|
||||
- date: "2026-06-14"
|
||||
dimension: discovery
|
||||
from: D0
|
||||
to: D1
|
||||
rationale: Added name, summary, and registry-first intent from INTENT.md.
|
||||
author: reuse-surface
|
||||
- date: "2026-06-15"
|
||||
dimension: discovery
|
||||
from: D1
|
||||
to: D3
|
||||
rationale: Bounded scope with UC-RS-001 and MVP registry artifacts in specs/.
|
||||
author: reuse-surface
|
||||
- date: "2026-06-15"
|
||||
dimension: availability
|
||||
from: A0
|
||||
to: A3
|
||||
rationale: reuse-surface CLI shipped validate, query, and export commands.
|
||||
author: reuse-surface
|
||||
---
|
||||
|
||||
# Capability Registration
|
||||
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user