railiance-fabric/workplans/RAIL-FAB-WP-0026-repo-family-relation-projection.md
codex 949f8a6aac
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
fix(workplans): adopt ADR-007 derived identifiers for unregistered records
These workplans exist only in the retired local hub. Their random pre-ADR-007
identifiers are refused by C-06 as stale references, so they cannot be
registered. Deriving from the canonical record id takes no identity from
anything: central does not hold them and the old ids die with the cache.

Records central already holds were deliberately left untouched.

Refs CUST-WP-0068-T06

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 2583210@bnt-lap001
Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006
2026-08-25 20:19:11 +02:00

112 lines
3.8 KiB
Markdown

---
id: RAIL-FAB-WP-0026
type: workplan
title: "Project repo-family relations from repo-local declarations"
domain: financials
repo: railiance-fabric
status: finished
owner: codex
topic_slug: railiance
created: "2026-07-26"
updated: "2026-07-26"
state_hub_workstream_id: "9158a557-28e4-5f43-99f5-660a67ca998a"
---
# RAIL-FAB-WP-0026 - Project repo-family relations from repo-local declarations
## Goal
Make the first `rail-*`, `rapp-*`, and `reef-*` repos visible in Fabric as a
minimal relation topology instead of only as isolated registered repositories.
## Boundaries
This workplan may:
- persist repo checkout and declaration-location hints in the registry
- project repo-family relations from repo-local declaration files
- update graph-explorer and registry docs to surface the new relation path
It must not:
- redesign the broader Fabric graph model
- invent repo-family relations from registry metadata alone when source-backed
declaration files are available
- claim runtime placement or governance beyond what the repo-local files state
## T01 - Persist local repo path context in repository records
```task
id: RAIL-FAB-WP-0026-T01
status: done
priority: high
state_hub_task_id: "dd0d6d84-c036-5cfa-abae-423a512959d2"
```
Store enough local checkout context in Fabric repository records so later graph
projection can reopen the relevant repo-local declarations.
Acceptance:
- repository records retain the checkout path when onboarding locally
- repository records retain declaration-path hints when they are provided
- the stored shape remains backward compatible for repos that only register by
slug and remote URL
2026-07-26: Extended Fabric repository records to persist the local checkout
`path` and any provided `declaration_paths`, updated the registry schema
compatibly, and carried those fields through direct sync and manifest sync.
## T02 - Project repo-family relations from repo-local files
```task
id: RAIL-FAB-WP-0026-T02
status: done
priority: high
state_hub_task_id: "b52f57db-5fca-533a-b326-fb900c178b47"
```
Project the minimum repo-family relation topology from repo-local declaration
files instead of relying only on registry metadata.
Acceptance:
- Fabric can project `governed_by` from repo-local `rail`, `rapp`, and `reef`
declarations
- Fabric can project `supports_rail` from `rapp` declarations
- Fabric can project `hosts_rail` and `binds_rapp` from `reef` files
- the resulting relations appear in registry-backed exports
2026-07-26: Added declaration-backed repo-family projection in the registry
combined graph. Fabric now projects `governed_by` from the first-wave `rail`,
`rapp`, and `reef` declarations, `supports_rail` from `rapp` declarations, and
`hosts_rail`/`binds_rapp` from the reef binding files with declaration
fallbacks. The graph explorer now preserves repository declaration references
for those projected repo nodes.
## T03 - Verify the first-wave relation path end to end
```task
id: RAIL-FAB-WP-0026-T03
status: done
priority: medium
state_hub_task_id: "7b64b7b6-46d7-56e0-a886-2ea0a28d20b9"
```
Verify that the current first-wave repos expose queryable repo-family relations
through the live Fabric registry/export path.
Acceptance:
- focused tests cover the new projection path
- the live registry export shows the first-wave ownership and rail-host/support
relations
- docs point operators at the declaration-backed projection path
2026-07-26: Verified the projection with focused tests
(`tests/test_registry.py`, `tests/test_graph_explorer.py`, and
`tests/test_canon.py`) and reran them with local HTTP binding enabled. Restarted
the local registry, resynced `registry/railiance-repos.yaml`, and confirmed the
live export now emits `governed_by` for `rail-kubernetes`, `rapp-openbao`, and
`reef-railiance`, plus `supports_rail` for `rapp-openbao` and `hosts_rail` for
`reef-railiance`.