docs(pnpm): fix tracker audit gaps

docs/pnpm/PNPM_MIGRATION.md

@@ -2,6 +2,12 @@
 
 This document is the canonical ecosystem tracker for migrating ByteLyst Node.js and TypeScript repositories from `npm` to `pnpm`.
 
+## Scope
+
+This tracker is for repos that still require an `npm` to `pnpm` migration, plus the shared tracker-hosting and downstream validation work needed to safely roll those migrations through the ecosystem.
+
+This tracker is **not** a claim that every listed repo is still on `npm` today. Some repos may already use `pnpm` in part or in full; those repos should be handled here only if they still require migration cleanup, downstream validation, or tracker-hosting updates.
+
 ## Objective
 
 Standardize on `pnpm` for:
@@ -19,6 +25,13 @@ Standardize on `pnpm` for:
 - **Incremental commits required** — commit migration work, fix work, and docs/tracker updates in logical batches.
 - **Tracker updates are mandatory** — every completed repo must have its checkbox updated and commit links recorded here.
 
+## Tracker State Semantics
+
+- A wave checkbox means the repo has fully cleared the migration sequence and can be considered done for this tracker.
+- A repo-section checkbox is only updated when there is evidence in code, verification output, and pushed commits.
+- `TBD` commit fields mean the repo has not yet cleared that stage.
+- If a repo is blocked, document the blocker in that repo's `notes:` line before moving away from it.
+
 ## Definition of Done For Each Repo
 
 A repo is only complete when **all** of the following are true:
@@ -38,6 +51,8 @@ A repo is only complete when **all** of the following are true:
 - [ ] docs/tracker commit links added here
 - [ ] commits pushed
 
+If any item above is false, the repo remains in-progress for this tracker.
+
 ## Mandatory Verification Before Moving To The Next Repo
 
 For every repo migration:
@@ -65,6 +80,8 @@ The `/production-readiness` workflow is mandatory quality enforcement for covere
 
 For the other product repos, run their repo-native verification plus the equivalent readiness checks expected by this tracker. If a migration affects shared dependencies, CI assumptions, shared Docker behavior, or downstream integrations, rerun any impacted `/production-readiness` phases before moving on.
 
+Equivalent readiness checks should include, at minimum, the repo's canonical install, typecheck, test, build, and any documented quality gates required by its own AGENTS/README/workflows.
+
 ## Current Status
 
 - **Ready for sequential rollout:** yes
@@ -109,6 +126,9 @@ Do not change the order below unless a later repo becomes a hard dependency bloc
 ### Wave 3 — Higher blast-radius repos
 
 - [ ] `learning_voice_ai_agent`
+
+### Wave 4 — Shared-platform validation and tracker-hosting cleanup
+
 - [ ] `learning_ai_common_plat`
 
 ## Repo Tracker
@@ -233,7 +253,16 @@ Update each repo section immediately after work lands.
 - migration commit: `TBD`
 - fix/audit commit: `TBD`
 - docs/tracker commit: `TBD`
-- notes: highest blast-radius repo; keep last in sequence unless it becomes a hard blocker
+- notes: tracker host and shared-platform validation repo; treat this as the final shared cleanup/sign-off phase rather than a standard product-repo npm→pnpm migration
+
+## Blocker Logging Rule
+
+If a repo cannot be completed in sequence:
+
+- do not silently skip it
+- record the blocker in that repo's `notes:` line
+- record any partial commit links already created
+- explain why it is safe to proceed to a later repo, if an exception is required
 
 ## Why The Sequence Matters