docs: publish reviewed NetKingdom evidence batch 2
This commit is contained in:
parent
2b6901eb9c
commit
f728073b4d
40 changed files with 2505 additions and 0 deletions
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
version: 1
|
||||
updated: '2026-06-16'
|
||||
domain: helix_forge
|
||||
capabilities: []
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
version: 1
|
||||
updated: '2026-06-16'
|
||||
domain: helix_forge
|
||||
capabilities: []
|
||||
|
|
@ -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`
|
||||
|
|
@ -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)
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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`
|
||||
|
|
@ -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)
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
|
@ -0,0 +1,4 @@
|
|||
version: 1
|
||||
updated: '2026-06-16'
|
||||
domain: helix_forge
|
||||
capabilities: []
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
|
@ -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`
|
||||
|
|
@ -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)
|
||||
|
|
@ -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`
|
||||
|
|
@ -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)
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
|
@ -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`
|
||||
|
|
@ -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
|
||||
|
|
@ -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`
|
||||
|
|
@ -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)
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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]
|
||||
|
|
@ -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.
|
||||
|
|
@ -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]
|
||||
|
|
@ -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)
|
||||
|
|
@ -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
|
||||
|
|
@ -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`.
|
||||
Loading…
Add table
Add a link
Reference in a new issue