Add baseline rollout workplan

This commit is contained in:
2026-05-20 23:16:08 +02:00
parent 0db4292db5
commit 9ad2750965

View File

@@ -0,0 +1,187 @@
---
id: RAIL-FAB-WP-0012
type: workplan
title: "Baseline Rollout And Conflict Review"
domain: railiance
repo: railiance-fabric
status: ready
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: todo
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: todo
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: todo
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.
### T04 - Acceptance Policy Trial
```task
id: RAIL-FAB-WP-0012-T04
status: todo
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.
### T05 - Rollout Readiness Decision
```task
id: RAIL-FAB-WP-0012-T05
status: todo
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.
## 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.