docs: publish reviewed NetKingdom evidence batch 2

This commit is contained in:
codex 2026-10-14 09:46:26 +02:00
parent 2b6901eb9c
commit f728073b4d
40 changed files with 2505 additions and 0 deletions

View file

@ -0,0 +1,88 @@
---
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: production
domain: infotech
tags: [audit, retention, compliance]
joins:
itc_cap: operations.audit
provision: data/capability/audit-core-operational.json
provision_maturity: D4
external_evidence:
completeness:
level: C3
name: Substantial
confidence: medium
basis: live_receiver_and_restore_walk
satisfied_expectations:
- HTTP ingest through the backend contract
- append-only Postgres custody on platform-pg
- recovery cited to the live platform data.backup provision
broken_expectations:
- data.archive sink not provided
out_of_scope_expectations:
- application business audit semantics ownership
- booked-cost origination
reliability:
level: R2
confidence: medium
basis: failure_matrix_and_restore_walk
known_reliability_risks:
- single replica
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
- procuring or operating platform backup
- booked financial facts
use_cases: []
availability:
current_level: A4
target_level: A5
current_artifacts:
- audit-core/deploy/audit-core.yaml
- audit-core/audit_core/postgres_backend.py
- rapp-postgres/consumers/audit-core.yaml
consumption_modes:
- http ingest
- source module
relations:
depends_on: []
related_to:
- capability.activity.event-coordinate
- capability.statehub.progress-log
uses_provisions:
- data.transactional (rapp-postgres/platform-pg)
- data.backup (resource:platform:audit-storage, cited)
- security.secrets (OpenBao / ESO)
consumer_guidance:
recommended_for:
- platform and application audit event delivery over POST /v1/events
not_recommended_for:
- treating this store as WORM archive
- replacing application-level logging only
known_limitations:
- recoverable history is the 30-day platform backup window
- no hash-chain or export API yet
---
# Audit Event Retention
Audit Core provides the operational custody layer for audit events.
ITC-CAP join: `operations.audit` at provision maturity D4
(`data/capability/audit-core-operational.json`). Maturity is not a
property of this abstract capability.

View file

@ -0,0 +1,22 @@
version: 1
updated: '2026-08-16'
domain: infotech
capabilities:
- id: capability.audit.event-retain
name: Audit Event Retention
summary: Collect, normalize, retain, and search audit events with integrity evidence
across tenants.
joins: operations.audit
provision: data/capability/audit-core-operational.json
vector: D4 provision / A4 / C3 / R2
domain: infotech
status: production
owner: audit-core
path: registry/capabilities/capability.audit.event-retain.md
tags:
- audit
- retention
- compliance
consumption_modes:
- http ingest
- source module

View file

@ -0,0 +1,15 @@
---
repo: coordination-engine
reason: >
Ambitious coordination-framework prose in INTENT, but only history/spec/registry dirs exist — no runtime code yet.
reviewed: "2026-07-06"
reviewed_by: claude-code
revisit: >
Revisit once runtime code for the coordination framework lands.
---
# No reusable capability
This repo was reviewed for the `reuse-surface` capability registry
(REUSE-WP-0017 coverage campaign) and has no capability to register at this
time. See the `reason` field above.

View file

@ -0,0 +1,4 @@
version: 1
updated: '2026-06-16'
domain: helix_forge
capabilities: []

View file

@ -0,0 +1,4 @@
version: 1
updated: '2026-06-16'
domain: helix_forge
capabilities: []

View file

@ -0,0 +1,120 @@
---
id: capability.infotech.canon-service
name: InfoTechCanon Service Surface
summary: Concrete service surface (CLI, importable functions, read-only local HTTP API) over the InfoTechCanon
information-processing infospace, backed by infospace-bench.
owner: info-tech-canon
status: draft
domain: infotech
tags:
- canon
- infospace
- service
maturity:
discovery:
current: D2
target: D4
confidence: medium
rationale: README documents a working CLI surface (inspect, artifacts, models, standards, review-kit,
alignment-template, validate, graph) over one concrete infospace under infospace/.
availability:
current: A2
target: A3
confidence: medium
rationale: Runnable today via `PYTHONPATH=src python3 -m info_tech_canon ...`; includes a read-only
local HTTP API in addition to the CLI.
external_evidence:
completeness:
level: C1
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- CLI commands for inspect/artifacts/models/standards/review-kit/alignment-template/validate/graph
- read-only local HTTP API
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- depends on infospace-bench for artifact loading/checks/graph summaries; only one concrete infospace
implemented so far
discovery:
intent: Provide a small, concrete service surface over one InfoTechCanon infospace so the canon corpus
is usable via CLI, importable functions, or a read-only API, not just documentation.
includes:
- JSON-first CLI over the infospace
- importable Python service functions
- read-only local HTTP API
excludes:
- the underlying infospace-bench workspace/evaluation tooling itself (separate capability)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- Python package (`info_tech_canon`)
target_artifacts: []
consumption_modes:
- cli
- library import
- http api (read-only, local)
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.md
tests:
- tests/
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- consumers wanting programmatic or CLI access to the InfoTechCanon infospace
not_recommended_for:
- needs requiring a writable or hosted API
known_limitations:
- only one concrete infospace implemented under infospace/ so far
promotion_history: []
---
# InfoTechCanon Service Surface
## Overview
`info-tech-canon` implements a concrete service surface over one InfoTechCanon infospace: a JSON-first CLI, importable Python functions, and a read-only local HTTP API, backed by artifact loading and graph summaries from `infospace-bench`.
## Assessment notes
### Discovery
README documents a working CLI surface (inspect, artifacts, models, standards, review-kit, alignment-template, validate, graph) over one concrete infospace under infospace/.
### Availability
Runnable today via `PYTHONPATH=src python3 -m info_tech_canon ...`; includes a read-only local HTTP API in addition to the CLI.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,21 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.infotech.canon-service
name: InfoTechCanon Service Surface
summary: Concrete service surface (CLI, importable functions, read-only local HTTP API) over the InfoTechCanon
information-processing infospace, backed by infospace-bench.
vector: D2 / A2 / C1 / R0
domain: infotech
status: draft
owner: info-tech-canon
path: registry/capabilities/capability.infotech.canon-service.md
tags:
- canon
- infospace
- service
consumption_modes:
- cli
- library import
- http api (read-only, local)

View file

@ -0,0 +1,85 @@
---
id: capability.infotech.issue-tracking
name: External Issue Tracker Connector
summary: Backend-agnostic CLI/Python connector to Forgejo (and SQLite cache)
with work-record UUID ↔ external issue mapping. Not the fleet work origin.
owner: issue-core
status: draft
domain: infotech
tags:
- issue-tracking
- connector
- work-record
maturity:
discovery:
current: D4
target: D5
confidence: high
rationale: INTENT.md, SCOPE.md, CAPABILITY-issue-tracking.yaml, mapping design,
boundary-sync policy, AGENT_INTEGRATION.md.
availability:
current: A2
target: A3
confidence: high
rationale: Python package + CLI (list/create/project/map) installable via pip;
mapping store shipped; MCP not yet available.
external_evidence:
completeness:
level: C2
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- Forgejo + local SQLite backends
- CLI with JSON output; project/map commands
- work_record_uuid optional on TaskSpec
- credential handling via env vars (FORGEJO_TOKEN preferred; GITEA_API_TOKEN deprecated alias; ISSUE_CORE_API_KEY)
broken_expectations: []
out_of_scope_expectations:
- Fleet task origin / intake promotion (work-record canon)
- Default IssueSink for internal findings (activity-core)
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- manual backend configuration (auto-detect planned)
- no built-in issue locking beyond assignee+state
- inward boundary sync not shipped
discovery:
intent: Project and operate on external issue trackers with a stable link to
work-record UUIDs; never replace file-first work records as coordination substrate.
includes:
- unified Python API and CLI over Forgejo/SQLite issue operations
- work_record_issue_map store + project/map/push-status
- local offline cache and backend sync
- credential handling via environment variables
excludes:
- originating workplans/tasks/intake
- MCP server (planned)
- multi-agent fleet board semantics on Forgejo
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- Python package (`issue_core`)
- '`issue` CLI (including project/map)'
target_artifacts: []
consumption_modes:
- cli
- library import
- rest (optional `[api]` extra)
relations:
depends_on: []
supports: []
related_to:
- capability.activity.event-coordinate
evidence:
documentation:
- INTENT.md
- SCOPE.md
- CAPABILITY-issue-tracking.yaml
- docs/uuid-external-id-mapping.md
- docs/boundary-sync-and-status-mapping.md

View file

@ -0,0 +1,20 @@
version: 1
updated: '2026-07-07'
domain: helix_forge
capabilities:
- id: capability.infotech.issue-tracking
name: Universal Issue Tracking Coordination
summary: Unified Python/CLI interface for issue tracking across Forgejo, GitHub, and GitLab, preventing
direct platform API usage and credential sprawl for coordinating agents.
vector: D4 / A2 / C2 / R1
domain: infotech
status: draft
owner: issue-core
path: registry/capabilities/capability.infotech.issue-tracking.md
tags:
- issue-tracking
- coordination
- multi-platform
consumption_modes:
- cli
- library import

View file

@ -0,0 +1,125 @@
---
id: capability.iam.key-cape
name: KeyCape Lightweight IAM (NetKingdom Profile)
summary: Lightweight-mode implementation of the NetKingdom IAM Profile (versioned OIDC/PKCE contract),
orchestrating Authelia, LLDAP, and privacyIDEA so applications integrate against the profile, not against
implementation internals.
owner: key-cape
status: draft
domain: infotech
tags:
- iam
- oidc
- netkingdom
- security
maturity:
discovery:
current: D4
target: D5
confidence: high
rationale: README documents a versioned canonical contract (net-kingdom canon/standards/iam-profile_v0.2.md),
explicit lightweight-vs-expanded (Keycloak) migration story, and a completed implementation status
(all 23 workplan tasks, 21 green test packages).
availability:
current: A2
target: A3
confidence: high
rationale: README states 'Implementation complete (v0.1)'; has both `.gitea/workflows/` and `.forgejo/workflows/`
CI already in place — ahead of most siblings on the Forgejo transition.
external_evidence:
completeness:
level: C2
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- full v0.1 implementation per its own workplan (23/23 tasks)
- 21 test packages, all green
- documented lightweight-to-expanded (Keycloak) migration path
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- maturity claims rely on the repo's own workplan completion record, not independently re-verified
in this sweep
discovery:
intent: Let applications integrate against a versioned IAM profile contract rather than against Keycape
internals, so migrating from lightweight (Authelia/LLDAP/privacyIDEA) to expanded (Keycloak) mode
is a tested operation, not a rewrite.
includes:
- NetKingdom IAM Profile v0.2 lightweight-mode orchestration (Authelia, LLDAP, privacyIDEA)
- profile-contract conformance
excludes:
- expanded-mode (Keycloak) implementation itself (separate deployment target for the same profile)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- deployable lightweight-mode IAM stack
target_artifacts: []
consumption_modes:
- service (self-hosted deployment)
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.md
- workplans/KEY-WP-0001-keycape-implementation.md
tests:
- .gitea/workflows/
- .forgejo/workflows/
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- NetKingdom deployments wanting a lightweight, self-hosted IAM profile implementation with a tested
migration path to Keycloak
not_recommended_for:
- deployments already committed to expanded/Keycloak mode
known_limitations:
- v0.1 completion claim not independently re-verified during this coverage sweep
promotion_history: []
---
# KeyCape Lightweight IAM (NetKingdom Profile)
## Overview
KeyCape is the lightweight IAM component of NetKingdom, implementing the versioned NetKingdom IAM Profile (OIDC/PKCE) by orchestrating Authelia, LLDAP, and privacyIDEA — the same profile Keycloak implements in expanded-mode deployments, so migration is a tested operation rather than a rewrite.
## Assessment notes
### Discovery
README documents a versioned canonical contract (net-kingdom canon/standards/iam-profile_v0.2.md), explicit lightweight-vs-expanded (Keycloak) migration story, and a completed implementation status (all 23 workplan tasks, 21 green test packages).
### Availability
README states 'Implementation complete (v0.1)'; has both `.gitea/workflows/` and `.forgejo/workflows/` CI already in place — ahead of most siblings on the Forgejo transition.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,21 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.iam.key-cape
name: KeyCape Lightweight IAM (NetKingdom Profile)
summary: Lightweight-mode implementation of the NetKingdom IAM Profile (versioned OIDC/PKCE contract),
orchestrating Authelia, LLDAP, and privacyIDEA so applications integrate against the profile, not
against implementation internals.
vector: D4 / A2 / C2 / R1
domain: infotech
status: draft
owner: key-cape
path: registry/capabilities/capability.iam.key-cape.md
tags:
- iam
- oidc
- netkingdom
- security
consumption_modes:
- service (self-hosted deployment)

View file

@ -0,0 +1,148 @@
---
id: capability.security.iam-tooling-suite
name: NetKingdom Security/IAM Tooling Suite
summary: Canonical security architecture and executable reference tooling for IAM, bootstrap, posture validation,
deterministic plan-only security scenario composition, and proposal-only posture feedback.
owner: net-kingdom
status: draft
domain: infotech
tags:
- security
- iam
- kubernetes
- conformance
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: SCOPE plus docs/secrets-engine-security-infrastructure-boundary.md describe an explicit
integration boundary with OpenBao, flex-auth, user-engine, ops-warden, ops-bridge, info-tech-canon,
and State Hub; canon/standards/ holds versioned IAM v0.3, playbook capability, scenario composition,
tenancy, zone, and boundary standards that provider repos implement against.
availability:
current: A2
target: A3
confidence: medium
rationale: 'No top-level package manifest, but tools/ holds independently documented and runnable
conformance, posture, posture-feedback, scenario-composition, and guarded bootstrap tools; local-identity is separately
packaged and tested.'
external_evidence:
completeness:
level: C1
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- versioned canon standards already implemented by a sibling repo (key-cape)
- documented, runnable conformance, posture, composition, and bootstrap tools under tools/
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- no top-level packaging; each tool under tools/ has its own runtime dependencies, no unified install
path yet
discovery:
intent: Own canonical NetKingdom security semantics and provide executable reference and conformance tooling
so provider implementations can integrate without inferred authority or hidden deployment coupling.
includes:
- canon/standards/ versioned IAM, tenancy, zone, credential, boundary, and composition standards
- IAM profile conformance checker
- playbook capability contract validator
- deterministic plan-only security scenario composer
- tenancy posture schema and validator
- deterministic proposal-only posture feedback evaluator
- security bootstrap console (local, non-secret-collecting)
- packaged local bootstrap identity CLI
excludes:
- concrete IAM implementations themselves (see key-cape for lightweight mode)
- live secret value handling (bootstrap console explicitly refuses live OpenBao initialization)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- tools/iam-profile-conformance
- tools/playbook-capability-contract
- tools/security-scenario-composer
- tools/tenancy-posture
- tools/posture-feedback
- tools/security-bootstrap-console
- local-identity
target_artifacts: []
consumption_modes:
- cli
- local web ui
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.md
- docs/secrets-engine-security-infrastructure-boundary.md
- tools/*/README.md
tests:
- tools/iam-profile-conformance (pytest fixtures)
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- implementers needing to verify IAM/security conformance against Coulomb's canonical standards
not_recommended_for:
- needs for a packaged, single-install security suite (currently three separate tools)
known_limitations:
- no unified top-level packaging across the three tools
promotion_history: []
---
# NetKingdom Security/IAM Tooling Suite
## Overview
`net-kingdom` provides canonical IAM and security architecture, executable
conformance and posture checks, deterministic plan-only scenario composition,
proposal-only posture feedback, a local bootstrap identity package, and a non-secret-collecting security
bootstrap console. Provider implementations remain in sibling repositories such
as `key-cape`; the self-optimizing platform remains an intent rather than a
current delivery claim.
## Assessment notes
### Discovery
SCOPE plus docs/secrets-engine-security-infrastructure-boundary.md describe an
explicit integration boundary with OpenBao, flex-auth, user-engine, ops-warden,
ops-bridge, info-tech-canon, and State Hub. `canon/standards/` holds the current
IAM v0.3 and related boundary, posture, zone, credential, playbook, and scenario
composition standards.
### Availability
No top-level package manifest exists. The independently runnable surfaces are
documented under `tools/`, and `local-identity` has its own package manifest and
test environment.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,21 @@
version: 1
updated: '2026-08-23'
domain: helix_forge
capabilities:
- id: capability.security.iam-tooling-suite
name: NetKingdom Security/IAM Tooling Suite
summary: Canonical security architecture and executable reference tooling for IAM, bootstrap, posture
validation, deterministic plan-only security scenario composition, and proposal-only posture feedback.
vector: D3 / A2 / C1 / R1
domain: infotech
status: draft
owner: net-kingdom
path: registry/capabilities/capability.security.iam-tooling-suite.md
tags:
- security
- iam
- kubernetes
- conformance
consumption_modes:
- cli
- local web ui

View file

@ -0,0 +1,122 @@
---
id: capability.ops.tunnel-bridge
name: SSH Reverse Tunnel Lifecycle Manager (ops-bridge)
summary: CLI that manages named SSH reverse tunnels keeping remote execution environments connected to
the local Custodian State Hub, with auto-reconnect, health checks, and structured audit events.
owner: ops-bridge
status: draft
domain: infotech
tags:
- ssh
- tunnel
- ops
- connectivity
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: README.txt documents named tunnels, auto-reconnect with exponential backoff, HTTP health
checks, and structured JSON audit events per tunnel; this is also the tool underlying reuse-surface's
own `/bridge` skill.
availability:
current: A2
target: A3
confidence: medium
rationale: Ships a `bridge` CLI, installable via pyproject; already actively used to keep remote Claude
Code sessions (COULOMBCORE, Railiance nodes) connected to the State Hub MCP.
external_evidence:
completeness:
level: C2
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- auto-reconnecting named SSH reverse tunnels
- HTTP health checks confirming forwarded service reachability, not just SSH liveness
- structured audit event log per tunnel
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- operational tool with real production usage but no independent load/failure testing recorded in
this sweep
discovery:
intent: Keep remote execution environments' MCP connectivity to the local State Hub alive and observable
via managed, auto-reconnecting SSH reverse tunnels.
includes:
- named SSH reverse tunnel lifecycle management
- auto-reconnect with exponential backoff
- HTTP health checks
- structured audit event logging
excludes:
- the State Hub or MCP servers themselves (bridge only manages connectivity)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- '`bridge` CLI'
target_artifacts: []
consumption_modes:
- cli
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.txt
tests:
- tests/
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- any workstation/remote-machine pair needing durable SSH-tunneled MCP or service connectivity
not_recommended_for:
- needs for tunnel types other than SSH reverse port-forwards
known_limitations:
- no independent load/failure testing recorded beyond production usage observations
promotion_history: []
---
# SSH Reverse Tunnel Lifecycle Manager (ops-bridge)
## Overview
`ops-bridge` is an SSH reverse tunnel lifecycle manager: a `bridge` CLI that keeps remote execution environments (COULOMBCORE, Railiance nodes) connected to the local Custodian State Hub, with auto-reconnect, health checks, and structured audit logging per tunnel.
## Assessment notes
### Discovery
README.txt documents named tunnels, auto-reconnect with exponential backoff, HTTP health checks, and structured JSON audit events per tunnel; this is also the tool underlying reuse-surface's own `/bridge` skill.
### Availability
Ships a `bridge` CLI, installable via pyproject; already actively used to keep remote Claude Code sessions (COULOMBCORE, Railiance nodes) connected to the State Hub MCP.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,20 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.ops.tunnel-bridge
name: SSH Reverse Tunnel Lifecycle Manager (ops-bridge)
summary: CLI that manages named SSH reverse tunnels keeping remote execution environments connected
to the local Custodian State Hub, with auto-reconnect, health checks, and structured audit events.
vector: D3 / A2 / C2 / R1
domain: infotech
status: draft
owner: ops-bridge
path: registry/capabilities/capability.ops.tunnel-bridge.md
tags:
- ssh
- tunnel
- ops
- connectivity
consumption_modes:
- cli

View file

@ -0,0 +1,137 @@
---
id: capability.security.ssh-certificate-issuance
name: SSH Certificate Issuance
summary: Issue short-lived CA-signed SSH certificates for adm, agt, and atm actors through a stable cert_command CLI interface; steward operational access routing across NetKingdom security lanes.
owner: ops-warden
status: draft
domain: helix_forge
tags:
- ssh
- certificate
- ca
- ops-warden
- openbao
- security
maturity:
discovery:
current: D4
target: D5
confidence: medium
rationale: >
SCOPE, AccessManagementDirective alignment, config runbooks, and cert_command
contract are documented; production OpenBao integration is documented but
engine deployment lives in railiance-platform. A machine-readable routing
catalog (registry/routing/catalog.yaml) and wiki/AccessRouting.md make the
"issue SSH, route the rest" boundary discoverable.
availability:
current: A3
target: A5
confidence: medium
rationale: >
Installable `warden` CLI and `ops-ssh-wrapper` entry points; ops-bridge and
other callers integrate via cert_command without backend-specific branching.
A `warden route` lookup over the pointer catalog (WARDEN-WP-0011) will move
routing discovery from wiki prose to a structured surface for agents (A3 -> A4).
external_evidence:
completeness:
level: C3
name: Functional Core
confidence: medium
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- local and OpenBao/Vault-compatible signing backends
- TTL policy enforcement per actor type
- principals inventory and cert-side scorecard
- signatures audit log and stale-cert cleanup
- cert_command stdout contract for ops-bridge
broken_expectations:
- host-side principal deployment not owned here
- OpenBao SSH engine mount not deployed from this repo
out_of_scope_expectations:
- long-lived API key custody
- tunnel lifecycle management
- Vault/OpenBao cluster operations
reliability:
level: R2
name: Tolerable
confidence: medium
basis: consumer_quality_signals
known_reliability_risks:
- production signing depends on OpenBao availability and token policy
- local backend requires protected CA key handling by operators
discovery:
intent: >
Give the ops fleet short-lived SSH credentials for humans, agents, and
automations without static keys, through a single cert_command surface that
callers can rely on regardless of CA backend; route non-SSH credential needs
to the correct NetKingdom subsystems (OpenBao, flex-auth, key-cape).
includes:
- certificate signing for adm, agt, and atm actors
- actor principals inventory and TTL policy
- cert_command interface (`warden sign`)
- cert-side compliance scorecard and signatures log
- ops-ssh-wrapper for automatic cert acquisition
- NetKingdom credential routing and alignment documentation
- machine-readable routing pointer catalog (registry/routing/catalog.yaml)
excludes:
- tunnel lifecycle
- host /etc/ssh/auth_principals deployment
- OpenBao or Vault cluster setup
- long-lived secret storage
assumptions:
- callers supply actor public keys; humans self-issue admin keys
- production platform uses OpenBao with Vault-compatible SSH engine API
use_cases:
- ops-bridge tunnel cert_command
- Inter-Hub bootstrap short-lived agent access
research_memos:
- ops-warden/SCOPE.md
- ops-warden/wiki/CertCommandInterface.md
- ops-warden/wiki/OpsWardenConfig.md
- ops-warden/wiki/AccessRouting.md
availability:
current_level: A3
target_level: A5
current_artifacts:
- ops-warden/src/warden/
- ops-warden/wiki/CertCommandInterface.md
- ops-warden/wiki/OpsWardenConfig.md
target_artifacts:
- packaged ops-warden release with documented OpenBao role bootstrap
- "`warden route` lookup CLI over the pointer catalog (WARDEN-WP-0011)"
consumption_modes:
- CLI
- cert_command subprocess
relations:
depends_on: []
supports: []
related_to: []
consumer_guidance:
recommended_for:
- issuing short-lived SSH certs for ops-bridge tunnels
- agent or automation access with TTL-bound principals
- checking cert-side compliance before rotation windows
- orienting dev workers on which NetKingdom subsystem owns each credential type
not_recommended_for:
- storing OpenRouter or Inter-Hub API keys
- replacing OpenBao deployment or host SSH hardening playbooks
- static-key-only legacy access (use ops-bridge static key mode instead)
known_limitations:
- "VaultCA backend config key remains backend: vault for API compatibility"
- host-side scorecard checks live in railiance-infra
---
# SSH Certificate Issuance
ops-warden is the custodian-domain SSH CA tool. It signs short-lived certificates,
maintains the actor inventory, and exposes `warden sign` as the cert_command
contract for ops-bridge and other callers.
Production environments point the vault-compatible backend at OpenBao; labs use
the local ssh-keygen CA backend without platform dependencies.

View file

@ -0,0 +1,23 @@
version: 1
updated: '2026-06-17'
domain: helix_forge
capabilities:
- id: capability.security.ssh-certificate-issuance
name: SSH Certificate Issuance
summary: Issue short-lived CA-signed SSH certificates for adm, agt, and atm actors
through a stable cert_command CLI interface; steward NetKingdom operational access routing.
vector: D4 / A3 / C3 / R2
domain: helix_forge
status: draft
owner: ops-warden
path: registry/capabilities/capability.security.ssh-certificate-issuance.md
tags:
- ssh
- certificate
- ca
- ops-warden
- openbao
- security
consumption_modes:
- CLI
- cert_command subprocess

View file

@ -0,0 +1,127 @@
---
id: capability.railiance.workload-deployment-tooling
name: Railiance Application Workload Deployment Tooling
summary: S5 Workloads and Experience Endpoints layer of the Railiance OAS Stack — application Helm releases,
Kubernetes workload manifests, deployment guardrails, and smoke-test/check tooling for user-facing services.
owner: railiance-apps
status: draft
domain: financials
tags:
- railiance
- kubernetes
- helm
- deployment
maturity:
discovery:
current: D3
target: D4
confidence: medium
rationale: SCOPE.md places this repo precisely in the Railiance OAS Stack layering (S5), scoped to
application Helm releases, workload manifests, and operator runbooks for user-facing services such
as vergabe-teilnahme.
availability:
current: A2
target: A3
confidence: medium
rationale: No top-level package manifest, but ships real, runnable tooling under tools/ (build-database-url-secret.sh,
check-oci-image.sh, check-sops.sh, forgejo-smoke.sh, inter-hub-smoke.sh, k8s-server-dry-run.sh,
smoke-service.sh) plus charts/ and manifests/; has both .gitea and .forgejo CI already.
external_evidence:
completeness:
level: C1
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- Helm charts and Kubernetes manifests for application workloads
- smoke-test and dry-run check scripts, including a forgejo-smoke.sh already ahead of the platform-wide
Forgejo transition
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- no top-level packaging; tooling is a collection of shell scripts under tools/
discovery:
intent: 'Own the S5 layer of the Railiance OAS Stack: deploying and verifying user-facing application
workloads via Helm/Kubernetes with guardrails and operator runbooks.'
includes:
- application Helm releases and Kubernetes workload manifests
- deployment guardrails
- smoke-test and dry-run tooling (including forgejo-smoke.sh)
excludes:
- cluster/platform substrate (see railiance-cluster, railiance-platform)
- CI/CD enablement templates (see railiance-enablement)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- Helm charts
- Kubernetes manifests
- tools/*.sh smoke and check scripts
target_artifacts: []
consumption_modes:
- cli (shell scripts)
- helm/kubernetes deployment
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- SCOPE.md
tests:
- tools/forgejo-smoke.sh
- tools/inter-hub-smoke.sh
- tools/k8s-server-dry-run.sh
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- operators deploying or verifying Railiance user-facing application workloads
not_recommended_for:
- needs at the cluster/platform substrate layer (see railiance-cluster, railiance-platform)
known_limitations:
- no unified packaging; tooling is a set of independent shell scripts
promotion_history: []
---
# Railiance Application Workload Deployment Tooling
## Overview
`railiance-apps` is the S5 Workloads and Experience Endpoints layer of the Railiance OAS Stack: Helm releases, Kubernetes workload manifests, deployment guardrails, and operator runbooks for user-facing services such as `vergabe-teilnahme`, including a `forgejo-smoke.sh` check already ahead of the platform-wide Gitea-to-Forgejo transition.
## Assessment notes
### Discovery
SCOPE.md places this repo precisely in the Railiance OAS Stack layering (S5), scoped to application Helm releases, workload manifests, and operator runbooks for user-facing services such as vergabe-teilnahme.
### Availability
No top-level package manifest, but ships real, runnable tooling under tools/ (build-database-url-secret.sh, check-oci-image.sh, check-sops.sh, forgejo-smoke.sh, inter-hub-smoke.sh, k8s-server-dry-run.sh, smoke-service.sh) plus charts/ and manifests/; has both .gitea and .forgejo CI already.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,22 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.railiance.workload-deployment-tooling
name: Railiance Application Workload Deployment Tooling
summary: S5 Workloads and Experience Endpoints layer of the Railiance OAS Stack — application Helm releases,
Kubernetes workload manifests, deployment guardrails, and smoke-test/check tooling for user-facing
services.
vector: D3 / A2 / C1 / R1
domain: financials
status: draft
owner: railiance-apps
path: registry/capabilities/capability.railiance.workload-deployment-tooling.md
tags:
- railiance
- kubernetes
- helm
- deployment
consumption_modes:
- cli (shell scripts)
- helm/kubernetes deployment

View file

@ -0,0 +1,4 @@
version: 1
updated: '2026-06-16'
domain: helix_forge
capabilities: []

View file

@ -0,0 +1,122 @@
---
id: capability.railiance.cluster-bootstrap
name: Railiance Cluster Runtime Bootstrap
summary: 'Cluster runtime entry point of the Railiance Infrastructure-as-Code framework: from two bare
Linux servers, a Git repo, and credentials, rebuilds a fully automated Kubernetes-based environment.'
owner: railiance-cluster
status: draft
domain: financials
tags:
- railiance
- kubernetes
- iac
- bootstrap
maturity:
discovery:
current: D3
target: D4
confidence: medium
rationale: README documents the 'Rails for Ops' convention-over-configuration philosophy and a concrete
quick-start (clone, from two bare servers rebuild a full k8s environment); has .forgejo CI already
in place.
availability:
current: A2
target: A3
confidence: medium
rationale: Real Python package (pyproject, requires-python >=3.11) plus bin/railiance CLI and ansible
playbooks (bootstrap/harden), with a documented quick-start path.
external_evidence:
completeness:
level: C1
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- documented quick-start from two bare servers to a running Kubernetes environment
- bootstrap/harden ansible playbooks
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- reproducibility claims not independently re-verified (no live bootstrap run during this sweep)
discovery:
intent: 'Provide the cluster runtime entry point for Railiance: reproducible, self-reliant Kubernetes
environment bootstrap from bare servers via convention-over-configuration IaC.'
includes:
- cluster bootstrap CLI and ansible playbooks (bootstrap/harden)
- Kubernetes-based environment rebuild path
excludes:
- application workload deployment (see railiance-apps)
- platform services like Postgres/Valkey (see railiance-platform)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- '`railiance` CLI (bin/railiance)'
- ansible playbooks
target_artifacts: []
consumption_modes:
- cli
- ansible playbook
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.md
tests:
- tests/
- .forgejo/
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- operators bootstrapping a new Railiance Kubernetes cluster from bare servers
not_recommended_for:
- application-level or platform-service deployment (see railiance-apps, railiance-platform)
known_limitations:
- reproducibility not independently re-verified via a live bootstrap run in this sweep
promotion_history: []
---
# Railiance Cluster Runtime Bootstrap
## Overview
`railiance-cluster` is the cluster runtime entry point of the Railiance Infrastructure-as-Code framework: from two bare Linux servers, a Git repo, and credentials, it rebuilds a fully automated Kubernetes-based environment via convention-over-configuration IaC (Terraform/cloud-init/Ansible-adjacent tooling, `railiance` CLI).
## Assessment notes
### Discovery
README documents the 'Rails for Ops' convention-over-configuration philosophy and a concrete quick-start (clone, from two bare servers rebuild a full k8s environment); has .forgejo CI already in place.
### Availability
Real Python package (pyproject, requires-python >=3.11) plus bin/railiance CLI and ansible playbooks (bootstrap/harden), with a documented quick-start path.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,21 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.railiance.cluster-bootstrap
name: Railiance Cluster Runtime Bootstrap
summary: 'Cluster runtime entry point of the Railiance Infrastructure-as-Code framework: from two bare
Linux servers, a Git repo, and credentials, rebuilds a fully automated Kubernetes-based environment.'
vector: D3 / A2 / C1 / R0
domain: financials
status: draft
owner: railiance-cluster
path: registry/capabilities/capability.railiance.cluster-bootstrap.md
tags:
- railiance
- kubernetes
- iac
- bootstrap
consumption_modes:
- cli
- ansible playbook

View file

@ -0,0 +1,125 @@
---
id: capability.railiance.ci-enablement
name: Railiance Developer Enablement And CI/CD Templates
summary: S4 Developer Enablement layer of the Railiance OAS Stack — reusable CI/CD workflow templates,
developer portal paths, platform templates, SDKs, and buildpacks, using forge capabilities without owning
forge runtime.
owner: railiance-enablement
status: draft
domain: financials
tags:
- railiance
- ci-cd
- developer-enablement
- forgejo
maturity:
discovery:
current: D3
target: D4
confidence: medium
rationale: SCOPE.md places this repo precisely at S4 in the Railiance OAS Stack, explicitly scoped
to reusable CI/CD templates and enablement tooling while using (not owning) forge capabilities.
availability:
current: A2
target: A3
confidence: high
rationale: Ships real, reusable Forgejo Actions workflow templates (container-build-push.yaml, container-build-push-multirepo.yaml,
ci-smoke.yaml) plus `tools/promote-repo-to-forgejo.sh` — directly relevant tooling for the ecosystem-wide
Gitea-to-Forgejo transition (REUSE-WP-0019).
external_evidence:
completeness:
level: C2
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- reusable Forgejo Actions CI/CD workflow templates already in production shape
- a repo-promotion-to-forgejo script directly usable for the platform-wide forge transition
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- templates are workflow YAML, not a packaged/versioned artifact; consumption is copy/reference rather
than dependency-managed
discovery:
intent: Give Railiance repos reusable CI/CD templates and developer-enablement tooling (including forge-promotion
tooling) without each repo owning the forge runtime or runner substrate itself.
includes:
- reusable Forgejo Actions CI/CD workflow templates
- repo-to-forgejo promotion tooling
- developer portal/platform template scope (per SCOPE.md)
excludes:
- forge runtime and runner substrate ownership (see railiance-forge)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- workflows/container-build-push.yaml
- workflows/ci-smoke.yaml
- tools/promote-repo-to-forgejo.sh
target_artifacts: []
consumption_modes:
- ci workflow template (copy/reference)
- cli (promote-repo-to-forgejo.sh)
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- SCOPE.md
tests:
- workflows/ci-smoke.yaml
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- Railiance repos needing reusable Forgejo Actions CI/CD templates, or any repo executing a Gitea-to-Forgejo
promotion
not_recommended_for:
- needs for owning forge runtime/runner infrastructure itself (see railiance-forge)
known_limitations:
- templates are consumed by copy/reference, not as a versioned dependency
promotion_history: []
---
# Railiance Developer Enablement And CI/CD Templates
## Overview
`railiance-enablement` is the S4 Developer Enablement layer of the Railiance OAS Stack: reusable CI/CD workflow templates and developer-enablement tooling, including a `promote-repo-to-forgejo.sh` script directly relevant to the ecosystem-wide Gitea-to-Forgejo transition tracked in REUSE-WP-0019.
## Assessment notes
### Discovery
SCOPE.md places this repo precisely at S4 in the Railiance OAS Stack, explicitly scoped to reusable CI/CD templates and enablement tooling while using (not owning) forge capabilities.
### Availability
Ships real, reusable Forgejo Actions workflow templates (container-build-push.yaml, container-build-push-multirepo.yaml, ci-smoke.yaml) plus `tools/promote-repo-to-forgejo.sh` — directly relevant tooling for the ecosystem-wide Gitea-to-Forgejo transition (REUSE-WP-0019).
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,22 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.railiance.ci-enablement
name: Railiance Developer Enablement And CI/CD Templates
summary: S4 Developer Enablement layer of the Railiance OAS Stack — reusable CI/CD workflow templates,
developer portal paths, platform templates, SDKs, and buildpacks, using forge capabilities without
owning forge runtime.
vector: D3 / A2 / C2 / R1
domain: financials
status: draft
owner: railiance-enablement
path: registry/capabilities/capability.railiance.ci-enablement.md
tags:
- railiance
- ci-cd
- developer-enablement
- forgejo
consumption_modes:
- ci workflow template (copy/reference)
- cli (promote-repo-to-forgejo.sh)

View file

@ -0,0 +1,122 @@
---
id: capability.railiance.fabric-graph
name: Railiance Fabric Ecosystem Graph
summary: 'Models the durable infrastructure-responsibility graph of the Railiance netkingdom: schemas,
discovery tools, registry services, graph queries, and State Hub export contracts for services, machines,
repos, deployables, endpoints, ownership, dependencies, and bindings.'
owner: railiance-fabric
status: draft
domain: financials
tags:
- railiance
- graph
- ownership
- discovery
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: README and SCOPE.md document the ecosystem graph model bounded by financial/operational
accountability (who pays, who is accountable), with king/lord/tenant ownership concepts referenced
in docs/FabricDiscoveryAndUpdate.md.
availability:
current: A1
target: A3
confidence: medium
rationale: Python package (`railiance-fabric`) providing a declaration loader and validator; consumed
as a library, no hosted service documented yet.
external_evidence:
completeness:
level: C1
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- ecosystem graph declaration loader and validator
- schemas for services/machines/repos/deployables/endpoints/ownership/dependencies/bindings
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- discovery/rebuild/update-loop architecture documented as still evolving per docs/FabricDiscoveryAndUpdate.md
discovery:
intent: Let repos declare services, capabilities, interfaces, dependencies, and bindings in source-controlled
files, and model the resulting durable infrastructure-responsibility graph across the Railiance ecosystem.
includes:
- ecosystem graph schema and declaration loader/validator
- State Hub export contracts for the graph
excludes:
- actual infrastructure provisioning (see railiance-infra, railiance-cluster)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A1
target_level: A3
current_artifacts:
- Python package (`railiance-fabric`)
target_artifacts: []
consumption_modes:
- library import
- cli (validation)
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.md
- SCOPE.md
- docs/FabricDiscoveryAndUpdate.md
tests:
- tests/
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- Railiance repos wanting to declare their place in the ecosystem ownership/dependency graph
not_recommended_for:
- needs for actual infrastructure provisioning (see railiance-infra/-cluster)
known_limitations:
- discovery/rebuild/update-loop architecture still evolving
promotion_history: []
---
# Railiance Fabric Ecosystem Graph
## Overview
`railiance-fabric` models the durable infrastructure-responsibility graph of the Railiance netkingdom — who pays for infrastructure, who is accountable for it, and which durable interfaces create value across boundaries — via schemas, a declaration loader/validator, and State Hub export contracts.
## Assessment notes
### Discovery
README and SCOPE.md document the ecosystem graph model bounded by financial/operational accountability (who pays, who is accountable), with king/lord/tenant ownership concepts referenced in docs/FabricDiscoveryAndUpdate.md.
### Availability
Python package (`railiance-fabric`) providing a declaration loader and validator; consumed as a library, no hosted service documented yet.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,22 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.railiance.fabric-graph
name: Railiance Fabric Ecosystem Graph
summary: 'Models the durable infrastructure-responsibility graph of the Railiance netkingdom: schemas,
discovery tools, registry services, graph queries, and State Hub export contracts for services, machines,
repos, deployables, endpoints, ownership, dependencies, and bindings.'
vector: D3 / A1 / C1 / R0
domain: financials
status: draft
owner: railiance-fabric
path: registry/capabilities/capability.railiance.fabric-graph.md
tags:
- railiance
- graph
- ownership
- discovery
consumption_modes:
- library import
- cli (validation)

View file

@ -0,0 +1,129 @@
---
id: capability.railiance.forge-infrastructure
name: Railiance Forge And Artifact Infrastructure
summary: Source forge, registry, and automation-runner infrastructure for Railiance, separated out from
railiance-apps/railiance-enablement; covers current Gitea operation, the Forgejo migration, container/package
registries, and Actions runner substrate.
owner: railiance-forge
status: draft
domain: financials
tags:
- railiance
- forgejo
- forge
- ci-runner
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: README and SCOPE.md explicitly name 'current Gitea operation, future Forgejo migration,
container and package registries, Actions runner substrate, artifact lifecycle' as the scope; status
noted as 'active forge extraction' with canonical registry operation docs already landed.
availability:
current: A1
target: A3
confidence: medium
rationale: README explicitly states 'no live Helm deploy or Kubernetes apply was run as part of the
move' — documentation and operator targets exist, but this repo is mid-extraction; has .gitea CI
(not yet migrated to .forgejo itself, notably, despite owning the migration).
external_evidence:
completeness:
level: C1
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- scope separation from railiance-apps/railiance-enablement documented
- canonical registry operation docs and runner ownership contracts
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- repo is actively being founded/extracted; no live deploy yet by its own account
- directly relevant to REUSE-WP-0019 but hasn't migrated its own CI to .forgejo/ yet
discovery:
intent: Own source forge, artifact registry, and CI runner substrate responsibilities for Railiance,
separated from application (railiance-apps) and enablement (railiance-enablement) concerns, across
the Gitea-to-Forgejo transition.
includes:
- forge operation (current Gitea, migrating to Forgejo)
- container/package registries
- Actions runner substrate
- artifact lifecycle
excludes:
- application workload deployment (railiance-apps)
- CI/CD templates for consuming repos (railiance-enablement)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A1
target_level: A3
current_artifacts:
- operator docs and tools/ (extraction in progress)
target_artifacts: []
consumption_modes:
- cli (operator tooling)
- documentation/runbooks
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.md
- SCOPE.md
tests: []
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- Railiance operators managing forge/registry/runner infrastructure, especially during the Gitea-to-Forgejo
transition
not_recommended_for:
- treating this as production-stable — the repo's own README states the extraction is active and no
live deploy has run yet
known_limitations:
- actively being founded; no live Helm/k8s deploy has run as part of the extraction yet; own CI still
under .gitea/ pending its own Forgejo migration
promotion_history: []
---
# Railiance Forge And Artifact Infrastructure
## Overview
`railiance-forge` is being founded to separate source forge, artifact registry, and CI/Actions runner responsibilities from `railiance-apps` and `railiance-enablement`. It directly owns the current Gitea operation and the future Forgejo migration — of particular relevance to REUSE-WP-0019 — though by its own account no live deploy has run yet.
## Assessment notes
### Discovery
README and SCOPE.md explicitly name 'current Gitea operation, future Forgejo migration, container and package registries, Actions runner substrate, artifact lifecycle' as the scope; status noted as 'active forge extraction' with canonical registry operation docs already landed.
### Availability
README explicitly states 'no live Helm deploy or Kubernetes apply was run as part of the move' — documentation and operator targets exist, but this repo is mid-extraction; has .gitea CI (not yet migrated to .forgejo itself, notably, despite owning the migration).
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,22 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.railiance.forge-infrastructure
name: Railiance Forge And Artifact Infrastructure
summary: Source forge, registry, and automation-runner infrastructure for Railiance, separated out from
railiance-apps/railiance-enablement; covers current Gitea operation, the Forgejo migration, container/package
registries, and Actions runner substrate.
vector: D3 / A1 / C1 / R0
domain: financials
status: draft
owner: railiance-forge
path: registry/capabilities/capability.railiance.forge-infrastructure.md
tags:
- railiance
- forgejo
- forge
- ci-runner
consumption_modes:
- cli (operator tooling)
- documentation/runbooks

View file

@ -0,0 +1,131 @@
---
id: capability.railiance.infra-provisioning
name: RailianceHosts Infrastructure Provisioning
summary: Git-driven server provisioning and convergence for Hosteurope/Hetzner Cloud using Terraform,
cloud-init, and Ansible, with SOPS+age encrypted in-repo secrets and a servers.yaml inventory as source
of truth.
owner: railiance-infra
status: draft
domain: financials
tags:
- railiance
- terraform
- ansible
- infrastructure
maturity:
discovery:
current: D4
target: D5
confidence: high
rationale: README documents a complete, concrete quickstart (clone, prerequisites, SOPS/age secrets
setup, provider setup, terraform apply, ansible convergence) with a specific inventory file (`inventory/servers.yaml`)
as source of truth — an unusually complete operational README among the swept repos.
availability:
current: A2
target: A3
confidence: high
rationale: Real ansible playbooks, terraform config, and scripts/tools present; has `.forgejo/` CI
already; documented as the S1 Infrastructure Substrate layer of the Railiance OAS Stack.
external_evidence:
completeness:
level: C2
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- documented end-to-end quickstart from bare cloud account to converged servers
- SOPS+age encrypted secrets with a documented key-custody model
- inventory/servers.yaml as explicit source of truth
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R1
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- reproducibility not independently re-verified via a live provisioning run in this sweep
discovery:
intent: Provision and manage servers on Hosteurope/Hetzner Cloud entirely from Git — Terraform for lifecycle,
cloud-init for first boot, Ansible for convergence — as the S1 Infrastructure Substrate of the Railiance
OAS Stack.
includes:
- Terraform server lifecycle management
- cloud-init first-boot configuration
- Ansible convergence playbooks
- SOPS+age encrypted secrets in-repo
excludes:
- Kubernetes cluster bootstrap on top of provisioned hosts (see railiance-cluster)
- platform services (see railiance-platform)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- Terraform configs
- Ansible playbooks
- scripts/
- tools/
target_artifacts: []
consumption_modes:
- cli (terraform/ansible)
- gitops
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- README.md
- SCOPE.md
tests:
- sbom-tools.yaml
- .forgejo/
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- operators provisioning Railiance bare-metal/cloud hosts from Git with encrypted-secret custody
not_recommended_for:
- needs above the OS/host substrate layer (see railiance-cluster for Kubernetes, railiance-platform
for shared services)
known_limitations:
- reproducibility not independently re-verified via a live provisioning run in this sweep
promotion_history: []
---
# RailianceHosts Infrastructure Provisioning
## Overview
`railiance-infra` (RailianceHosts) is Git-driven automation for provisioning and converging servers on Hosteurope and Hetzner Cloud — Terraform for lifecycle, cloud-init for first boot, Ansible for convergence — with secrets encrypted in-repo via SOPS/age and `inventory/servers.yaml` as the source of truth. It is the S1 Infrastructure Substrate layer of the Railiance OAS Stack.
## Assessment notes
### Discovery
README documents a complete, concrete quickstart (clone, prerequisites, SOPS/age secrets setup, provider setup, terraform apply, ansible convergence) with a specific inventory file (`inventory/servers.yaml`) as source of truth — an unusually complete operational README among the swept repos.
### Availability
Real ansible playbooks, terraform config, and scripts/tools present; has `.forgejo/` CI already; documented as the S1 Infrastructure Substrate layer of the Railiance OAS Stack.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,22 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.railiance.infra-provisioning
name: RailianceHosts Infrastructure Provisioning
summary: Git-driven server provisioning and convergence for Hosteurope/Hetzner Cloud using Terraform,
cloud-init, and Ansible, with SOPS+age encrypted in-repo secrets and a servers.yaml inventory as source
of truth.
vector: D4 / A2 / C2 / R1
domain: financials
status: draft
owner: railiance-infra
path: registry/capabilities/capability.railiance.infra-provisioning.md
tags:
- railiance
- terraform
- ansible
- infrastructure
consumption_modes:
- cli (terraform/ansible)
- gitops

View file

@ -0,0 +1,122 @@
---
id: capability.railiance.platform-services
name: Railiance Platform Services
summary: 'S3 Platform Services layer of the Railiance OAS Stack — shared cluster services: PostgreSQL
HA, Valkey cache, secret management, identity integration, and object storage.'
owner: railiance-platform
status: draft
domain: financials
tags:
- railiance
- platform
- secrets
- postgres
maturity:
discovery:
current: D3
target: D4
confidence: medium
rationale: SCOPE.md places this repo precisely at S3 in the Railiance OAS Stack, scoped to shared
cluster services (PostgreSQL HA, Valkey, secrets, identity integration, object storage).
availability:
current: A2
target: A3
confidence: medium
rationale: No top-level package manifest, but ships real scripts/ (OpenBao/Vault apply/verify, credential-change
Python tooling) and tools/; has `.forgejo/` CI already in place.
external_evidence:
completeness:
level: C1
confidence: low
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- OpenBao/Vault secret-management apply/verify scripting
- credential-change tooling
broken_expectations: []
out_of_scope_expectations: []
reliability:
level: R0
confidence: low
basis: consumer_quality_signals
known_reliability_risks:
- no top-level packaging; scripts/tools have no unified install path
discovery:
intent: Own the shared platform services layer (Postgres HA, Valkey, secrets, identity integration,
object storage) that application and enablement layers depend on, without owning the underlying host/cluster
substrate.
includes:
- PostgreSQL HA and Valkey cache service management
- secret management (OpenBao/Vault) apply/verify tooling
- identity integration and object storage
excludes:
- host/cluster substrate provisioning (see railiance-infra, railiance-cluster)
- application workload deployment (see railiance-apps)
assumptions: []
use_cases: []
research_memos: []
availability:
current_level: A2
target_level: A3
current_artifacts:
- scripts/ (OpenBao/Vault, credential-change tooling)
- tools/
target_artifacts: []
consumption_modes:
- cli (shell/python scripts)
relations:
depends_on: []
supports: []
related_to: []
evidence:
documentation:
- SCOPE.md
tests:
- tests/
consumer_feedback: []
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- Railiance operators managing shared platform services (Postgres, Valkey, secrets, identity, storage)
not_recommended_for:
- needs at the host/cluster substrate layer (see railiance-infra/-cluster) or application layer (see
railiance-apps)
known_limitations:
- no unified top-level packaging across scripts/tools
promotion_history: []
---
# Railiance Platform Services
## Overview
`railiance-platform` is the S3 Platform Services layer of the Railiance OAS Stack: shared cluster services including PostgreSQL HA, Valkey cache, OpenBao/Vault secret management, identity integration, and object storage, consumed by application and enablement layers above it.
## Assessment notes
### Discovery
SCOPE.md places this repo precisely at S3 in the Railiance OAS Stack, scoped to shared cluster services (PostgreSQL HA, Valkey, secrets, identity integration, object storage).
### Availability
No top-level package manifest, but ships real scripts/ (OpenBao/Vault apply/verify, credential-change Python tooling) and tools/; has `.forgejo/` CI already in place.
### Completeness
First-pass honest assessment from the REUSE-WP-0017 coverage campaign
(reuse-surface). No external consumer feedback exists yet; levels reflect
scope-vs-intent documentation quality, not internal code quality.
### Reliability
No production consumer telemetry exists yet; reliability level is
intentionally conservative pending REUSE-WP-0019 reuse-telemetry evidence.
## Promotion checklist
- [x] ID follows `capability.<domain>.<name>` pattern
- [x] Maturity enums match `specs/CapabilityMaturityStandard.md`
- [x] `external_evidence` is populated separately from `maturity`
- [ ] Relations reference valid capability IDs (none yet)
- [x] Index entry added in `registry/indexes/capabilities.yaml`

View file

@ -0,0 +1,20 @@
version: 1
updated: '2026-07-06'
domain: helix_forge
capabilities:
- id: capability.railiance.platform-services
name: Railiance Platform Services
summary: 'S3 Platform Services layer of the Railiance OAS Stack — shared cluster services: PostgreSQL
HA, Valkey cache, secret management, identity integration, and object storage.'
vector: D3 / A2 / C1 / R0
domain: financials
status: draft
owner: railiance-platform
path: registry/capabilities/capability.railiance.platform-services.md
tags:
- railiance
- platform
- secrets
- postgres
consumption_modes:
- cli (shell/python scripts)

View file

@ -0,0 +1,199 @@
---
id: capability.registry.register
name: Capability Registration
summary: Register a new capability so it becomes visible for planning and implementation reuse.
owner: reuse-surface
status: draft
domain: helix_forge
tags:
- registry
- governance
- meta
maturity:
discovery:
current: D3
target: D5
confidence: medium
rationale: >
Core use case UC-RS-001 is documented in specs/UseCaseCatalog.md and the
registry model is bounded in INTENT.md, but concrete promotion workflows
are not yet grounded in registry artifacts.
availability:
current: A4
target: A5
confidence: medium
rationale: >
Local registry workflows use the reuse-surface CLI (A3). Federation repo
registration is also available through the hosted hub HTTP API at
reuse.coulomb.social (POST/PATCH /v1/repos), deployed and dogfood-tested
on Railiance01 (REUSE-WP-0011).
external_evidence:
completeness:
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
- federation repo registration via hosted hub API and hub CLI
broken_expectations:
- no automated duplicate detection yet
out_of_scope_expectations:
- hosting registered capabilities
- enforcing implementation architecture
reliability:
level: R3
name: Usable
confidence: medium
basis: consumer_quality_signals
known_reliability_risks:
- index drift still possible if authors skip validate
- CLI requires local venv install
- sibling repos cannot register until indexes publish raw URLs
evidence:
satisfied_signals:
- CI validate with fail-on-warnings on every push
- hub register/list/federated smoke on production reuse.coulomb.social
- pytest coverage for hub API and federation compose paths
discovery:
intent: >
Make a capability candidate visible in the registry so humans and agents can
discover, assess, compare, and reuse it instead of rebuilding it in isolation.
includes:
- stable capability ID assignment
- initial discovery and availability classification
- explicit completeness and reliability placeholders
- evidence and relation references
excludes:
- implementing the registered capability
- certifying implementation quality
- operating runtime services for registered capabilities
assumptions:
- unregistered capabilities are invisible for registry-driven reuse
- low-maturity entries are acceptable when evidence gaps are explicit
use_cases:
- UC-RS-001
research_memos:
- specs/UseCaseCatalog.md
- specs/ProductRequirementsDocument.md
availability:
current_level: A4
target_level: A5
current_artifacts:
- templates/capability-entry.template.md
- registry/indexes/capabilities.yaml
- reuse_surface/cli.py
- reuse_surface/hub/
- specs/FederationHubAPI.md
- https://reuse.coulomb.social
target_artifacts:
- packaged container release with documented SLO
consumption_modes:
- informational
- markdown authoring
- cli
- service API
relations:
depends_on: []
supports:
- capability.feature-control.evaluate
- capability.identity.vocabulary-canonicalize
related_to:
- capability.registry.validate
evidence:
documentation:
- INTENT.md
- specs/UseCaseCatalog.md
- specs/FederationHubAPI.md
- docs/deploy/reuse-kubernetes.md
tests:
- tests/test_hub.py
- tests/test_hub_sync.py
- .forgejo/workflows/ci.yml
consumer_feedback:
- >
reuse-surface dogfood (REUSE-WP-0011): production hub registration and
/v1/federated compose succeeded on Railiance01 without write-path
regressions after WP-0011 deploy.
bug_reports: []
incidents: []
consumer_guidance:
recommended_for:
- making a new capability visible at D0/A0/C0/R0 with minimal friction
- seeding planning discussions before implementation exists
not_recommended_for:
- treating registry presence as proof of implementation readiness
- skipping explicit evidence for maturity promotion
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
- date: "2026-06-15"
dimension: availability
from: A3
to: A4
rationale: >
Hosted federation hub live at reuse.coulomb.social; hub register/update
via HTTP API and reuse-surface hub CLI; production deploy on Railiance01.
author: reuse-surface
- date: "2026-06-16"
dimension: reliability
from: R2
to: R3
rationale: >
CI gates, pytest hub/federation coverage, and production hub smoke support
normal registration workflows with documented limitations.
author: reuse-surface
---
# Capability Registration
## Overview
Registration is the entry point for reuse visibility. A capability that is not
registered cannot be discovered through the registry surface, even if code or
documentation exists elsewhere.
## Current reuse mode
**Local registry (A3 CLI):** add Markdown entries under `registry/capabilities/`,
update `registry/indexes/capabilities.yaml`, run `reuse-surface validate`.
**Federation registration (A4 API):** register published index URLs on the hosted
hub (`reuse-surface hub register`, `POST /v1/repos`) for cross-repo discovery
via `GET /v1/federated`.
## Next promotion steps
1. Attach concrete use cases and actors to reach D5.
2. Package hub as a versioned container release with operator SLO (A5).
3. Record consumer expectations and broken expectations as external evidence.

View file

@ -0,0 +1,107 @@
---
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: R3
name: Usable
confidence: medium
basis: consumer_quality_signals
known_reliability_risks:
- requires local venv install
- relation warnings require explicit --relations flag
evidence:
satisfied_signals:
- validate --relations --fail-on-warnings in CI
- tests/test_registry.py schema and drift coverage
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
- .forgejo/workflows/ci.yml
tests:
- tests/test_registry.py
consumer_feedback:
- >
reuse-surface CI: registry changes fail when schema validation or relation
checks warn with --fail-on-warnings, giving agents a dependable pre-merge gate.
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
promotion_history:
- date: "2026-06-16"
dimension: reliability
from: R2
to: R3
rationale: CI fail-on-warnings and pytest registry coverage support dependable validation.
author: reuse-surface
---
# Registry Entry Validation
Validates registry shape and consistency through the reuse-surface CLI.

View file

@ -0,0 +1,49 @@
# Manually maintained capability index for humans and agents.
version: 1
updated: "2026-10-13"
domain: helix_forge
capabilities:
- id: capability.infotech.headless-browser
name: Headless Browser Automation
summary: >-
Headless browser automation, screenshots and keyboard trials through
rapp-playwright 0.1.0 (Playwright 1.64.0, Chromium 156.0.8078.4).
Published A5 local container; managed Railiance admission is pending.
Download the Python 3.10+ standalone client from
https://forgejo.coulomb.social/coulomb/rapp-playwright/raw/commit/8831a05aeba5ce588f3b395ade676dde2a151c5d/client/rapp_playwright.py
and run `python3 rapp_playwright.py --url http://127.0.0.1:18083 preflight`,
then `python3 rapp_playwright.py --url http://127.0.0.1:18083 trial --out trial-01`
with a fresh output directory. This endpoint was verified locally on 2026-10-13
and is ephemeral; it installs no browser for the caller. If unreachable,
follow the local container setup in the capability card or adapt its A2 source
examples; this is an availability gap on the existing capability.
Contract: https://forgejo.coulomb.social/coulomb/rapp-playwright/src/commit/8831a05aeba5ce588f3b395ade676dde2a151c5d/docs/consumer-contract.md.
vector: D3 / A5 / C2 / R2
domain: infotech
status: reviewed
owner: reuse-surface
path: registry/capabilities/capability.infotech.headless-browser.md
tags: [headless, browser, automation, playwright, chromium, testing, screenshots, extraction, firefox, webkit, selenium, puppeteer]
consumption_modes: [informational, source adaptation, JavaScript library, Python library, cli, service API, container]
- id: capability.registry.register
name: Capability Registration
summary: Register a new capability so it becomes visible for planning and implementation reuse.
vector: D3 / A4 / C2 / R3
domain: helix_forge
status: draft
owner: reuse-surface
path: registry/capabilities/capability.registry.register.md
tags: [registry, governance, meta]
consumption_modes: [informational, markdown authoring, cli, service API]
- id: capability.registry.validate
name: Registry Entry Validation
summary: Validate capability registry entries against schema, index consistency, and relation integrity.
vector: D4 / A3 / C3 / R3
domain: helix_forge
status: draft
owner: reuse-surface
path: registry/capabilities/capability.registry.validate.md
tags: [registry, validation, cli]
consumption_modes: [cli]

View file

@ -0,0 +1,18 @@
---
id: capability.infotech.runbook-tutorials
name: Runbook-tutorial engine
summary: Engine, local UI and CLI for guided, parameterized operator runbooks: pack specification and validators, runs with evidence and locked records, maturity, attribute sets, projects and whole-project runs. Packs live in the repos that own the procedure.
owner: runbook-tutorials
status: active
domain: infotech
tags:
- runbook
- tutorial
- operator
- guided
---
Working: specifications `runbook-pack/v0.1` and `v0.2` with validators, the engine and local UI, projects and project templates, and the `rtut`
CLI (see `SCOPE.md`). Not built by decision: execution of steps, a cross-repository pack index, a feedback assistant (`workplans/RBT-WP-0006`).
Only the NetKingdom repository provides packs so far, and its three v0.2 packs have not had their first attended run, so this capability is
`active` but has no operational evidence yet. The fleet maturity vector is not assessed here: it needs the fleet's assessment method.

View file

@ -0,0 +1,13 @@
version: 1
updated: '2026-09-29'
domain: infotech
capabilities:
- id: capability.infotech.runbook-tutorials
name: Runbook-tutorial engine
summary: Engine, local UI and CLI for guided, parameterized operator runbooks; packs live in the repos that own the procedure.
domain: infotech
status: active
owner: runbook-tutorials
path: registry/capabilities/capability.infotech.runbook-tutorials.md
tags: [runbook, tutorial, operator, guided]
consumption_modes: [git clone, cli]

View file

@ -0,0 +1,48 @@
---
id: capability.execution.sandbox-provision
name: Sandbox Provisioning
summary: Isolated execution environments for agentic development, e2e testing, and bounded automations — profile-based provision, TTL teardown, and State Hub lifecycle registration.
owner: sand-boxer
status: draft
domain: infotech
tags: [sandbox, isolation, provision, e2e, agentic, execution, profile]
maturity:
discovery:
current: D5
target: D6
confidence: high
rationale: >
Charter (INTENT.md), meta-framework spec, extension SDK, integration docs,
and research synthesis. Capability indexed in registry/.
availability:
current: A5
target: A5
confidence: high
rationale: >
CLI v0 (create/destroy/snapshot/TTL), HTTP API, CoulombCore remote smoke.
Cloud adapters E2B/Modal + routing + credits (SAND-WP-0010).
external_evidence:
completeness:
level: C5
name: Mature
confidence: high
basis: scope_vs_intent_and_consumer_expectations
satisfied_expectations:
- profile-based create/destroy/snapshot/restore via CLI
- TTL extend and expire/reap (SAND-WP-0009)
- E2B and Modal cloud adapters with BYOK (SAND-WP-0010)
- State Hub lifecycle events on transitions
- wise-validator and the-custodian migration arc complete
- extension SDK with compose-ssh, vm-packer attach, saas-stub, e2b, modal
broken_expectations:
- sandboxer01 dedicated host not live (CoulombCore interim)
out_of_scope_expectations:
- agent harness and tool orchestration (glas-harness)
- e2e test semantics (wise-validator)
consumption_modes:
- CLI (sandboxer)
- core library (Python)
- HTTP API (uvicorn sandboxer.api.app:app)

View file

@ -0,0 +1,23 @@
version: 1
updated: '2026-06-22'
domain: infotech
capabilities:
- id: capability.execution.sandbox-provision
name: Sandbox Provisioning
summary: Isolated execution environments for agentic development, e2e testing, and bounded automations — profile-based provision, TTL teardown, and State Hub lifecycle registration.
vector: D4 / A2 / C2 / R1
domain: infotech
status: draft
owner: sand-boxer
path: registry/capabilities/execution.sandbox-provision.md
tags:
- sandbox
- isolation
- provision
- e2e
- agentic
- execution
- profile
consumption_modes:
- CLI
- core library

View file

@ -0,0 +1,19 @@
---
id: capability.infotech.sbom-management
type: capability
name: SBOM management
repo: sbom-nexus
domain: infotech
status: emerging
interfaces:
- http
- cli
---
# SBOM management
Capture repository dependency evidence, preserve immutable SBOM snapshot
history, query current inventory and licence signals, and select a deterministic
bounded fleet catch-up queue.
The extraction interface is documented in `ProductRequirementsDocument.md`.