coulomb/railiance-enablement
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Clarify enablement forge handoffs

Browse source
This commit is contained in:
tegwick 2026-06-05 15:43:13 +02:00
parent a9301a009c
commit b6712300c6
2 changed files with 54 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

18
INTENT.md
View file

@ -40,7 +40,8 @@ Railiance evolve faster without dissolving its layer boundaries.
To become the **canonical home for developer and delivery enablement** -
CI/CD pipelines, GitOps workflows, workload templates, SDKs, buildpacks,
developer portal surfaces, and promotion conventions that help source repos
move safely toward S5 application releases.
move safely toward S5 application releases while consuming forge-provided
runners, registries, and artifact evidence.
This means:
@ -48,6 +49,7 @@ This means:
* Build and deployment templates encode **Railiance platform expectations**
* Developers get fast feedback through **standard checks and pipelines**
* S5 can consume release artifacts through **clear handoff contracts**
* Forge runtime and runner substrate remain owned by **railiance-forge**
* Enablement improves delivery without taking ownership of app runtime
operation
@ -75,13 +77,20 @@ consumers do not need to rediscover platform assumptions.
CI/CD and promotion flows should produce artifacts, metadata, and evidence that
the application layer can deploy and verify without guessing.
### 5. Fast Feedback
### 5. Clear Handoff to Forge
Reusable workflows should state the forge capabilities they require: repository
events, runner labels, package credentials, registry endpoints, and artifact
evidence. This layer defines the reusable workflow shape; `railiance-forge`
owns the runtime and credentials behind it.
### 6. Fast Feedback
Developers should learn about broken builds, missing declarations, incompatible
interfaces, and release-readiness gaps before those problems reach live
application deployments.
### 6. Boundaries Preserve Velocity
### 7. Boundaries Preserve Velocity
Enablement should make the layered architecture easier to use, not become a
shortcut for mutating infrastructure, cluster, platform, or application
@ -110,6 +119,7 @@ This layer is not:
* the Kubernetes runtime
* the shared platform-services layer
* the application deployment and operations layer
* the source forge, package/container registry, or runner substrate layer
* the source-code home for business workloads
* a replacement for repo-owned workplans, ADRs, or implementation decisions
@ -125,6 +135,8 @@ This layer is expected to evolve toward:
* Standard **pipeline templates** for Railiance workloads
* Reusable **build and image promotion** conventions
* GitOps workflows with clear **review and rollback** expectations
* Handoff contracts with `railiance-forge` for **runner labels, package
credentials, registry endpoints, and artifact evidence**
* Developer-facing **self-service templates** and portal entry points
* SDKs and examples that make platform capabilities easy to consume correctly
* Release evidence that S5 can use for **deployment readiness**