Publish Forge resource economics evidence

Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a02669-87ee-7a31-b111-edc95a16e0fa

INTENT.md

@@ -122,10 +122,12 @@ description left it unplaced - which is how layer boundaries erode.
 Placement was decided 2026-08-11 (hub decision `d151d817`):
 
 * the **Forgejo workload** becomes `rapp-forgejo`, a managed workload package
-* the **layer responsibility** - runner placement and labels, registry
-  retention, artifact lifecycle, package credentials - folds into **S4
-  `railiance-enablement`**, which already declares a handoff contract for
-  exactly these concerns
+* the **consumer-facing contract** - reusable workflow expectations for runner
+  labels, registry interfaces, package credentials, and artifact evidence -
+  belongs to **S4 `railiance-enablement`**
+* this repo remains the **operational provider** for the live forge, registry,
+  runner substrate, retention, custody references, and operating evidence
+  until a separately approved migration changes that boundary
 
 A retirement hypothesis was tested and rejected: this repo and `helix-forge` are
 different lineages, not one maturing into the other. `helix-forge` is
@@ -133,8 +135,11 @@ methodological (capability-first ecosystem, OAS dimensions, VSM vocabulary);
 this repo is operational. Retiring it would orphan responsibilities nothing
 else owns.
 
-Until the migration completes, this repo remains the operating home for forge
-concerns. See `railiance-platform/ArchitectureBlueprint.md` section 5.2.
+This split does not require a physical merge: enablement owns the paved
+consumer path, while this repo owns the capability that path consumes. The
+Forgejo workload is expected to become `rapp-forgejo` without moving its
+operator contract into enablement. See `railiance-platform/ArchitectureBlueprint.md`
+section 5.2.
 
 ---