railiance-fabric/workplans/RAIL-FAB-WP-0012-baseline-rollout-and-conflict-review.md

id, type, title, domain, repo, status, owner, topic_slug, planning_priority, planning_order, created, updated, state_hub_workstream_id

id	type	title	domain	repo	status	owner	topic_slug	planning_priority	planning_order	created	updated	state_hub_workstream_id
RAIL-FAB-WP-0012	workplan	Baseline Rollout And Conflict Review	railiance	railiance-fabric	finished	codex	railiance	high	12	2026-05-20	2026-05-20	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

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

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

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

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

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.