Project rail composition and readiness
This commit is contained in:
parent
9af9ee3e72
commit
4fcfee0479
7 changed files with 238 additions and 4 deletions
|
|
@ -83,6 +83,16 @@ 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.
|
||||
|
||||
Second-wave projection also retains:
|
||||
|
||||
- rail contract version and base/derived composition kind
|
||||
- a derived rail's `base_rail` and compatible base contract
|
||||
- rail and package readiness state
|
||||
- binding readiness, contract version, and evidence references
|
||||
|
||||
Topology remains distinct from readiness. A relation can be declared without
|
||||
being installed, verified, or production-approved.
|
||||
|
||||
## First New Capability Type
|
||||
|
||||
Fabric now reserves:
|
||||
|
|
@ -111,6 +121,7 @@ repo-local files:
|
|||
declaration
|
||||
- `binds_rapp` from `bindings/rapps.yaml` with a fallback to the reef
|
||||
declaration
|
||||
- `base_rail` from a derived rail declaration
|
||||
|
||||
This keeps the relation path anchored in reviewed repo-local files rather than
|
||||
guessing solely from registry metadata.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue