docs: clean stale sections in GITEA_NPM_REGISTRY_MIGRATION.md

docs/devops/GITEA_NPM_REGISTRY_MIGRATION.md

@@ -26,21 +26,15 @@ Once that is stable, we replicate the same validated shape on the Azure single V
 
 ## 2. Why We Want This
 
-### Current pain
+### Previous state (resolved)
 
-Today many repos still depend on one of these Docker-time workarounds:
+Before this migration, repos depended on Docker-time workarounds:
 
 - `file:` references to sibling `learning_ai_common_plat/packages/*`
-- `docker-prep.sh`
+- `docker-prep.sh` + `.docker-deps` or `.tarballs` copy steps
-- `.docker-deps` or older `.tarballs` copy steps
 - temporary `package.json` rewriting before builds
 
-This works, but it creates repeated operational drag:
+These are now eliminated. All repos use the Gitea npm registry.
-
-- every build may need prep
-- Dockerfiles become repo-specific and fragile
-- CI, local development, and Docker are not using one clean dependency source
-- path and build-context mismatches keep surfacing during ecosystem validation
 
 ### Target outcome
 
@@ -138,7 +132,7 @@ That is enough to treat this Mac as the single-VM rehearsal environment.
 
 - shared packages build cleanly in `learning_ai_common_plat`
 - a local-only Gitea package token was created and used successfully for local package publishing
-- **48 `@bytelyst/*` packages** published to local Gitea npm registry
+- **49 `@bytelyst/*` packages** published to local Gitea npm registry
 - a clean scratch `pnpm install` from the local Gitea registry works on all migrated repos
 - **all 10 product repos migrated** from `file:` refs + `docker-prep.sh` to semver `^0.1.0` + registry-backed Dockerfiles
 - all migrated repos pass host-side `pnpm install` and backend typecheck
@@ -186,7 +180,7 @@ At the time of writing (2026-03-24):
 - host-side registry usage is validated across all 10 migrated repos
 - Docker builds verified for all repos with Dockerfiles
 - local Gitea CI green for all 8 repos with CI workflows
-- 48 `@bytelyst/*` packages published to local Gitea
+- 49 `@bytelyst/*` packages published to local Gitea
 - `docker-prep.sh` retired from all repos
 
 Verified local FlowMonk Docker recipe (`NETWORK=corp`):
@@ -222,7 +216,7 @@ The local rehearsal on this Mac has validated the **host-side** registry model,
 - Local Gitea CI green for all 8 repos with CI workflows
 - Runner re-registered against `127.0.0.1` (avoids IPv6 `[::1]` declaration failure)
 - `GITEA_NPM_TOKEN` added to act_runner config for CI registry access
-- 48 `@bytelyst/*` packages published and consumed successfully
+- 49 `@bytelyst/*` packages published and consumed successfully
 - Backend typecheck passes for all 10 migrated repos
 - `docker-prep.sh` removed from all 10 repos
 
@@ -432,9 +426,7 @@ Success means:
 
 Current status on this Mac:
 
-- **not yet fully green**
+- **fully green** — host-side installs, Docker builds, and local CI all validated
-- the remaining issue is the local Homebrew Gitea instance serving package metadata/tarball URLs across the Docker build boundary
-- host-side validation is complete, Docker-side validation is still open
 
 ### Step 6 — Validate local Gitea Actions path
 
@@ -504,9 +496,7 @@ The objective is to prove the local VM pattern first.
 
 - use local-only credentials for this phase
 - keep `@bytelyst` scoped registry config explicit
-- do not remove tarball fallback globally until the pilot is green
+- keep rollback steps documented per repo (§12)
-- migrate one consumer repo at a time
-- keep rollback steps documented per repo
 
 ---
 
@@ -576,11 +566,11 @@ Expected low-change areas:
 - scaling stateless services should mostly mean changing replica counts, resource requests/limits, and HPA settings
 - moving from single-node K3s to multi-node K3s or managed Kubernetes should mostly reuse the same manifests with infra-level adjustments
 
-What is **not** yet proven enough to call low-change:
+All package-distribution concerns are resolved:
 
-- the package-distribution layer for Docker/K8s image builds
+- All 10 repos consume `@bytelyst/*` from Gitea registry
-- the exact image build/publish flow for the full ecosystem after registry migration
+- Docker builds verified for all repos with Dockerfiles
-- the complete repo-by-repo removal of tarball-based Docker prep
+- `docker-prep.sh` removed from all repos
 
 ---
 
@@ -589,7 +579,7 @@ What is **not** yet proven enough to call low-change:
 This migration plan is locally validated only when all are true:
 
 - [x] local Gitea package publish auth verified
-- [x] local package publish path verified — 48 packages published
+- [x] local package publish path verified — 49 packages published
 - [x] local consumer install path verified on the host — all 10 repos
 - [x] Docker build path verified without `docker-prep.sh` — all repos with Dockerfiles
 - [x] local Gitea CI verified — 8/8 repos with CI workflows green
@@ -604,7 +594,7 @@ This migration plan is locally validated only when all are true:
 ## 15. Migration Complete — Summary
 
 1. ~~create or verify a local-only Gitea package token~~ ✅
-2. ~~publish `@bytelyst/*` packages to local Gitea~~ ✅ (48 packages)
+2. ~~publish `@bytelyst/*` packages to local Gitea~~ ✅ (49 packages)
 3. ~~migrate pilot repo (FlowMonk) end-to-end~~ ✅
 4. ~~expand to remaining standard-layout repos~~ ✅ (7 repos)
 5. ~~confirm Gitea CI green for all repos~~ ✅ (8/8 with CI workflows)
@@ -670,6 +660,6 @@ After completing the migration and audit, all Dockerfiles were tested with actua
 
 ### Full verification sweep
 
-- **Backend tests**: 1,591 tests passing across all 10 repos
+- **Backend tests**: 1,700+ tests passing across all 12 backend services (platform 1,483 + extraction 136 + 10 products)
 - **Web typecheck**: 9/9 web apps typecheck clean
 - **Backend typecheck**: 10/10 repos typecheck clean