--- id: RAIL-FAB-WP-0012 type: workplan title: "Baseline Rollout And Conflict Review" domain: railiance repo: railiance-fabric status: finished owner: codex topic_slug: railiance planning_priority: high planning_order: 12 created: "2026-05-20" updated: "2026-05-20" state_hub_workstream_id: "c7f85db5-59db-4f4b-bfe5-f984edb201f9" --- # RAIL-FAB-WP-0012 - Baseline Rollout And Conflict Review ## Goal Start using the operational rescan loop in anger: run the local Fabric registry, ingest a controlled baseline for a small repo allowlist, review the `repo-scoping` discovery conflicts found by the dry-run, and decide whether the baseline is clean enough to expand toward all-local-repo rollout. The implementation should prove that `RAIL-FAB-WP-0011` is not just a command surface, but a usable operating loop for keeping Fabric discovery state fresh. ## Background `RAIL-FAB-WP-0011` implemented: - `.fabric-discovery` snapshot/report caches - previous-from-registry reconciliation - idempotent unchanged ingest skipping - safe acceptance policy - registry discovery health/status surfaces - automation-safe exit codes and locking The first local-cache dry-run on 2026-05-20 scanned: - `repo-scoping` - `llm-connect` - `railiance-fabric` It completed with 3 scanned repos, 2 baselines, 1 changed repo, 7 conflicts, and 1 review-required repo. The registry-backed path could not run because the local Fabric registry service was not listening on `127.0.0.1:8765`. ## Design Principles - Keep the first baseline small and inspectable. - Do not broaden to all repos while review conflicts are still unexplained. - Prefer ingesting discovery baselines over accepting/projection until the conflict set is understood. - Treat the registry service bootstrap as operational setup, not a source-code feature unless implementation gaps appear. - Record enough evidence in docs and State Hub to make the next operator run repeatable. ## Tasks ### T01 - Registry Service Bootstrap ```task id: RAIL-FAB-WP-0012-T01 status: done priority: high state_hub_task_id: "53880e37-6800-47db-8c35-4278eb241da4" ``` Start or verify the local Fabric registry service on `127.0.0.1:8765` using the repo-local `.railiance-fabric/registry.sqlite3` database. Acceptance notes: - Verify whether a registry service is already listening on `127.0.0.1:8765`. - Start `railiance-fabric-registry --db .railiance-fabric/registry.sqlite3 --port 8765` when needed. - Confirm `/health`, `/status`, and graph explorer routes respond. - Record the service command, database path, and log path used for the session. - Avoid changing source code unless startup reveals a real defect. ### T02 - Controlled Baseline Ingest ```task id: RAIL-FAB-WP-0012-T02 status: done priority: high state_hub_task_id: "1b945a9e-6193-4e34-8e3b-9b2d5a6aa828" ``` Run the small allowlist operational rescan against the live registry and ingest baseline discovery snapshots. Acceptance notes: - Use allowlist: `repo-scoping`, `llm-connect`, `railiance-fabric`. - Use `--previous-from-registry` and `--ingest`; do not use `--accept` yet. - Confirm registry-backed first-baseline behavior for repos without prior discovery snapshots. - Confirm unchanged follow-up runs skip ingest by default. - Record discovery snapshot ids, report path, counts, and review-required conditions. ### T03 - Repo-Scoping Conflict Review ```task id: RAIL-FAB-WP-0012-T03 status: done priority: high state_hub_task_id: "52e18533-df3f-4478-84bd-f8fa688d83e3" ``` Inspect the `repo-scoping` conflicts from the rescan report and classify what they mean. Acceptance notes: - Open the latest report and/or discovery snapshot for `repo-scoping`. - List the 7 conflicted candidates by stable key, kind, label, and evidence. - Determine whether conflicts are expected duplicate-detection noise, real declaration/discovery disagreement, or scanner identity defects. - Capture recommended action for each conflict: accept, ignore, improve scanner identity, improve repo declarations, or create follow-up workplan. - Do not project accepted graph changes until this review is complete. Review result: - Latest `repo-scoping` discovery snapshot: `4`, commit `fd7f25866a94897acfdefaafc83a9d8336c1081b`, generated `2026-05-20T21:21:22Z`. - Conflicted candidates are all `Lockfile` nodes with labels `uv.lock` or `package-lock.json` under distinct `var/checkouts/...` paths: `llm-connect-ce2118b9dc59/uv.lock`, `markitect-main-1e0f80026926/package-lock.json`, `ops-bridge-9733411215b8/uv.lock`, `ops-warden-eac790a4872c/uv.lock`, `railiance-cluster-95d336518aae/uv.lock`, `vergabe-teilnahme-336b6f081ec8/package-lock.json`, and `vergabe-teilnahme-336b6f081ec8/uv.lock`. - Classification: duplicate-detection noise for path-scoped lockfile entities. The scanner is treating same kind plus same normalized label as enough to raise `possible_duplicate_node`, even when source paths clearly distinguish separate lockfiles. - Recommended action: refine duplicate detection for path-scoped nodes before broad rollout or acceptance projection. Lockfiles should require matching source anchor/path identity, not label alone, before being treated as possible duplicates. ### T04 - Acceptance Policy Trial ```task id: RAIL-FAB-WP-0012-T04 status: done priority: medium state_hub_task_id: "7ceaa12a-8044-4fa1-82c3-d202a815e494" ``` Exercise the safe acceptance policy on the clean subset without forcing conflicted candidates through projection. Acceptance notes: - Identify whether `llm-connect` and `railiance-fabric` have accepted repo-owned declaration candidates suitable for projection. - Run accept only where the safe policy allows it. - Verify projected graph snapshots do not overwrite repo-owned declarations. - Confirm `registry rescan-status --review-only` still highlights unresolved conflict/review work. - Record any blocked acceptance reasons. Trial result: - `llm-connect` discovery snapshot `2` is clean but contains only `candidate` review-state discoveries, so no candidates were projected. - `railiance-fabric` discovery snapshot `3` is clean, has accepted repo-declaration candidates, and was projected into accepted graph snapshot `24` with 49 nodes and 63 edges. - Projection appended a new graph snapshot with commit `discovery:9ad2750965f0100adcee2473b31ede6f7098205c`; it did not mutate the earlier repo-owned graph snapshots. - `registry rescan-status --review-only` still shows only `repo-scoping` snapshot `4` as review-required. ### T05 - Rollout Readiness Decision ```task id: RAIL-FAB-WP-0012-T05 status: done priority: medium state_hub_task_id: "4a73225c-18ce-4ba6-89b9-cdc8c76ca5d9" ``` Decide whether the operational loop is ready for all-local-repo rollout or needs another targeted refinement first. Acceptance notes: - Summarize the small baseline outcome in docs and State Hub. - State whether broad rollout is recommended now, recommended after conflict fixes, or blocked. - If blocked or deferred, create a focused follow-up backlog item/workplan. - If ready, propose the command and guardrails for all-local-repo baseline ingestion. Decision: - Broad all-local-repo rollout is deferred until duplicate detection respects path-scoped node identity for lockfile-style evidence. - The operational loop itself is usable: registry service bootstrap, baseline ingest, unchanged skip, review-only status, and safe projection for clean accepted declarations all worked locally. - Follow-up: `RAIL-FAB-WP-0013` owns the path-scoped duplicate identity refinement and should be completed before the next broad rollout attempt. ## Open Questions - Are `repo-scoping` conflicts caused by stale cache baselines from before the latest scanner refinements? - Should the first ingested baseline include conflicted discovery snapshots, or should conflicted repos be ingested only after review? - Should the registry service be treated as a long-running local service with a documented startup command, or should this repo provide a helper command? ## Close Criteria - The local registry service is running and verified. - The three-repo controlled baseline has been run against registry-backed previous snapshots. - Baseline discovery snapshots are ingested or intentionally withheld with reasons. - `repo-scoping` conflicts are classified and turned into concrete next steps. - We know whether to proceed to all-local-repo rollout.