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

3.8 KiB

id type title domain repo status owner topic_slug created updated state_hub_workstream_id
RAIL-FAB-WP-0026 workplan Project repo-family relations from repo-local declarations financials railiance-fabric finished codex railiance 2026-07-26 2026-07-26 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

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

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

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.