From 8386a0b81aec574218233aeb6ff82106a1999060 Mon Sep 17 00:00:00 2001 From: tegwick Date: Wed, 26 Aug 2026 02:18:51 +0200 Subject: [PATCH] feat(workplan): record the central backfill and the short-task-id defect MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 5248 rows identified but only 5100 identities distinct: bare T01 task ids stored as canonical gave every workplan's first task one identity, 51 ids across 148 rows. The backfill's conflict check could not see it — it detects one UUID claimed by two ids, and this was the inverse — so it surfaced only because the two counts did not reconcile. Central now holds 5112 of 5974 identified, 5077 distinct. The remaining 34 duplicates are unqualified ad-hoc ids reused across repositories, the problem CUST-WP-0066 closed for new records only. Co-Authored-By: Claude Opus 5 Assistant: claude-code Assistant-Model: opus Assistant-Process: 2583210@bnt-lap001 Assistant-Session: f2bff2d5-e9b2-4338-92ca-10282a927006 --- ...-WP-0083-forge-derived-projection-reset.md | 38 +++++++++++++++++++ 1 file changed, 38 insertions(+) diff --git a/workplans/STATE-WP-0083-forge-derived-projection-reset.md b/workplans/STATE-WP-0083-forge-derived-projection-reset.md index c835460..1e7a7bd 100644 --- a/workplans/STATE-WP-0083-forge-derived-projection-reset.md +++ b/workplans/STATE-WP-0083-forge-derived-projection-reset.md @@ -268,6 +268,44 @@ Only then may `T03` be extended to tasks of existing workplans, which is a further change with its own verification. `CUST-WP-0068-T09` is therefore two moves away, not one. +**Backfill run against central (2026-08-26), and a defect it exposed.** + +The first implementation read local filesystem paths. Central has no workstation +checkout and must not depend on one — `ADR-012` decision 1 makes the forge the +projection source — and the point became concrete rather than theoretical: +central's Postgres is unreachable from the workstation, since the tunnel carries +HTTP only. A forge-sourced variant now clones each repository in-cluster and +reads the pairing from what the forge holds. + +Dry run across 121 repositories: 1094 files, 5620 pairs, 5248 to update, 372 +file-declared UUIDs central does not hold, **zero conflicts**. The count +differing from the cache's 4456 of 6073 was the check that mattered — central +holds the re-keyed records the cache never had, so a *matching* number would have +meant cache state was leaking in. The forge scan reading 1094 files against the +workstation's 1104 is the preliminary-overlay distinction showing up in the +numbers. + +**Then applied, and wrong.** 5248 rows were identified but only 5100 identities +were distinct. A task id written as a bare `T01` is unique only inside its own +workplan; stored as canonical it gave every workplan's first task one identity. +51 such ids landed on 148 rows. + +The backfill's own conflict detection could not see it: it checks one UUID +claimed by two ids, and this was the inverse. It surfaced only because the +identified count and the distinct count did not reconcile — a check that could +easily have been skipped after a dry run reporting zero conflicts. + +Short ids are now qualified as `WORKPLAN-ID-T01`, and a short id in a file with +no workplan id gets no identity at all. The 136 affected rows on central were +cleared for reassignment, since the backfill never overwrites an existing +identity. + +**Central now: 5112 of 5974 identified, 5077 distinct.** The remaining 34 +duplicates are not from this work. They are unqualified ad-hoc ids reused across +repositories — `ADHOC-2026-07-02-T01` exists in three workplans — which is the +problem `CUST-WP-0066` closed for new records while existing ones kept their +unqualified ids. They need their own disposition. + ## Restore a migration mechanism for central