Archive closed workplans to workplans/archived/ (ADR-001)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
parent
f9e661ec69
commit
7312ed3767
28 changed files with 0 additions and 0 deletions
|
|
@ -1,233 +0,0 @@
|
|||
---
|
||||
id: RAIL-FAB-WP-0012
|
||||
type: workplan
|
||||
title: "Baseline Rollout And Conflict Review"
|
||||
domain: financials
|
||||
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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue