Project repo-family relations from local declarations

docs/rail-rapp-reef-adaptation.md

@@ -1,6 +1,6 @@
 # Rail Rapp Reef Adaptation
 
-Date: 2026-07-25
+Date: 2026-07-26
 
 ## Purpose
 
@@ -79,6 +79,10 @@ This metadata is available through repository registration, manifest sync, and
 repository projections such as the graph explorer's synthesized repository
 nodes.
 
+The registry now also retains the local checkout `path` used during onboarding.
+That lets Fabric reopen the conventional repo-local `rail`, `rapp`, and `reef`
+files when it needs to project first-wave relation edges.
+
 ## First New Capability Type
 
 Fabric now reserves:
@@ -95,23 +99,35 @@ Meaning:
 This is intentionally rail-focused. `rapp-*` and `reef-*` can start with
 service-level visibility before they need their own dedicated capability types.
 
+## Relation Projection Path
+
+Fabric now projects the minimum first-wave repo-family relations from
+repo-local files:
+
+- `governed_by` from `declarations/rail.yaml`, `declarations/rapp.yaml`, and
+  `declarations/reef.yaml`
+- `supports_rail` from `declarations/rapp.yaml`
+- `hosts_rail` from `bindings/rails.yaml` with a fallback to the reef
+  declaration
+- `binds_rapp` from `bindings/rapps.yaml` with a fallback to the reef
+  declaration
+
+This keeps the relation path anchored in reviewed repo-local files rather than
+guessing solely from registry metadata.
+
 ## What Is Still Missing
 
-The following are not done by this adaptation slice:
+The following are still not done:
 
-- export relations such as `supports_rail`, `hosts_rail`, `binds_rapp`, or
-  `governed_by`
 - validator rules for repo-family-specific declaration completeness
-- graph queries that resolve placement or governance directly from the new
-  repo-family metadata
+- richer graph queries that answer reef/workload placement beyond the first
+  projected repo edges
 - State Hub read-model fields that surface repo family directly in generated
   repo briefs or inventory views
-
-Those require a second wave after the first real `rail-*`, `rapp-*`, and
-`reef-*` repos exist.
+- deeper runtime placement semantics than the first repo-level topology
 
 ## Outcome
 
 Fabric can now move from "the new repo families exist only in architecture
-docs" to "the registry and declaration guidance are ready for the first repo
-instances" without overcommitting to a premature graph redesign.
+docs" to "the registry can project the first repo-family topology from
+repo-local evidence" without overcommitting to a premature graph redesign.

docs/registry-onboarding.md

@@ -51,7 +51,9 @@ repositories:
     sbom: bom.json
 ```
 
-`path` is the local checkout used for git metadata and default graph discovery.
+`path` is the local checkout used for git metadata, default graph discovery,
+and repo-family relation projection when the registry later needs to reopen
+repo-local `rail`, `rapp`, or `reef` files.
 `declaration_paths` is optional; when omitted, the repo path is scanned for a
 `fabric/` directory. Relative paths are resolved from the manifest file.
 
@@ -68,7 +70,7 @@ The following repo-family metadata fields are also optional:
   declared
 - `supported_rails`: array of supported rail ids for `rapp-*` repos
 - `substrate_kind`: grouped substrate category such as `server`,
-  `workstation-group`, or `cluster`
+  `server-group`, `workstation-group`, or `cluster`
 
 `sbom` or `sboms` may point to CycloneDX JSON/YAML files. When present, the
 command ingests them as queryable library inventory after repository
@@ -81,6 +83,12 @@ no Fabric declarations yet, the command leaves the repo registered and reports a
 warning. This lets the registry represent known repos before every repo has
 published local evidence.
 
+For `rail-*`, `rapp-*`, and `reef-*` repos, registration-only entries still
+matter: the registry stores the checkout path and repo-family metadata, and the
+graph export can use the conventional repo-local declaration files to project
+first-wave `governed_by`, `supports_rail`, `hosts_rail`, and `binds_rapp`
+edges even when the repo does not yet publish native Fabric declarations.
+
 When declarations exist, the command validates them, builds a graph snapshot,
 and posts it to: