Complete WP-0006 through WP-0009: registry expansion, catalog, graph, tests

Register six new capabilities (12 total), add searchable catalog UI and graph
explorer, introduce pytest suite with CI fail-on-warnings, and close gap
analysis priorities 13 and 16. WP-0010 remains backlog for network federation.

registry/capabilities/capability.activity.event-coordinate.md

@@ -0,0 +1,77 @@
+---
+id: capability.activity.event-coordinate
+name: Organizational Event Coordination
+summary: Coordinate structured responses to cross-domain events through activity workflows and automation.
+owner: activity-core
+status: draft
+domain: helix_forge
+tags: [activity, coordination, automation]
+
+maturity:
+  discovery:
+    current: D3
+    target: D5
+    confidence: medium
+    rationale: activity-core INTENT defines org-wide event response boundary.
+  availability:
+    current: A1
+    target: A4
+    confidence: low
+    rationale: Conceptual workflows exist; consumable API surface still emerging.
+
+external_evidence:
+  completeness:
+    level: C1
+    name: Fragmentary
+    confidence: low
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+      - problem and boundary documented in INTENT
+    broken_expectations:
+      - no registry-native automation artifacts indexed yet
+    out_of_scope_expectations:
+      - owning domain-specific business logic
+  reliability:
+    level: R0
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks: []
+
+discovery:
+  intent: >
+    Give the organization a structural home for responding to events across repos
+    and domains in an auditable, automation-ready way.
+  includes:
+    - event-triggered coordination
+    - cross-domain maintenance workflows
+  excludes:
+    - single-repo cron replacements only
+  use_cases: []
+
+availability:
+  current_level: A1
+  target_level: A4
+  current_artifacts:
+    - activity-core/INTENT.md
+  consumption_modes:
+    - informational
+
+relations:
+  depends_on: []
+  related_to:
+    - capability.statehub.workstream-coordinate
+    - capability.audit.event-retain
+
+consumer_guidance:
+  recommended_for:
+    - planning org-wide event response patterns
+  not_recommended_for:
+    - assuming production automation is available
+  known_limitations:
+    - early discovery stage
+---
+
+# Organizational Event Coordination
+
+activity-core coordinates how the org responds to events—not the domain logic
+inside each repo.

registry/capabilities/capability.audit.event-retain.md

@@ -0,0 +1,80 @@
+---
+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.

registry/capabilities/capability.authorization.policy-evaluate.md

@@ -0,0 +1,80 @@
+---
+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.

registry/capabilities/capability.feature-control.visibility.md

@@ -0,0 +1,77 @@
+---
+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.

registry/capabilities/capability.registry.validate.md

@@ -0,0 +1,88 @@
+---
+id: capability.registry.validate
+name: Registry Entry Validation
+summary: Validate capability registry entries against schema, index consistency, and relation integrity.
+owner: reuse-surface
+status: draft
+domain: helix_forge
+tags: [registry, validation, cli]
+
+maturity:
+  discovery:
+    current: D4
+    target: D5
+    confidence: medium
+    rationale: UC-RS-023 is implemented via reuse-surface validate with schema and drift checks.
+  availability:
+    current: A3
+    target: A3
+    confidence: high
+    rationale: Available as reuse-surface validate CLI command.
+
+external_evidence:
+  completeness:
+    level: C3
+    name: Functional Core
+    confidence: medium
+    basis: scope_vs_intent_and_consumer_expectations
+    satisfied_expectations:
+      - schema validation for entry front matter
+      - index drift detection
+      - optional relation integrity checks
+    broken_expectations: []
+    out_of_scope_expectations:
+      - runtime validation of registered capability implementations
+  reliability:
+    level: R2
+    name: Tolerable
+    confidence: medium
+    basis: consumer_quality_signals
+    known_reliability_risks:
+      - requires local venv install
+
+discovery:
+  intent: Keep registry data structurally sound so agents and humans can trust discovery metadata.
+  includes:
+    - JSON Schema validation
+    - index drift warnings
+    - relation reference checks
+  excludes:
+    - validating implementation code in other repos
+  use_cases:
+    - UC-RS-023
+  research_memos:
+    - specs/UseCaseCatalog.md
+
+availability:
+  current_level: A3
+  target_level: A3
+  current_artifacts:
+    - reuse_surface/cli.py
+    - schemas/capability.schema.yaml
+  consumption_modes:
+    - cli
+
+relations:
+  depends_on:
+    - capability.registry.register
+  supports: []
+  related_to:
+    - capability.registry.register
+
+evidence:
+  documentation:
+    - tools/README.md
+  tests: []
+
+consumer_guidance:
+  recommended_for:
+    - pre-commit and CI validation of registry changes
+  not_recommended_for:
+    - certifying business correctness of capability claims
+  known_limitations:
+    - warnings do not fail CI unless --fail-on-warnings is set
+---
+
+# Registry Entry Validation
+
+Validates registry shape and consistency through the reuse-surface CLI.

registry/capabilities/capability.statehub.progress-log.md

@@ -0,0 +1,78 @@
+---
+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: R2
+    confidence: low
+    basis: consumer_quality_signals
+    known_reliability_risks:
+      - depends on hub availability
+
+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
+
+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.