npm - @timurproko/a1 - Versions diffs - 0.2.4-dev.663 → 0.2.4-dev.667 - Mend

@timurproko/a1 0.2.4-dev.663 → 0.2.4-dev.667

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (90) hide show

package/docs/architecture/internal-naming.md CHANGED Viewed

@@ -80,7 +80,7 @@ Metadata that predates contract declaration is stale, never fatal. A pre-cutover
 Activation after the global installation is handed over the same way. The package manifest declares `updateActivationContracts` (`activate-v1`) and ships `bin/activate.js`; an updater that serves a declared contract starts that entry with the data directory and the target version and relays its line-delimited progress events (`materializing`, `phase`, `warmup`, `completed`, `failed`) into its own journal and progress bar, while the entry materializes, certifies, warms, and supervises the tree it ships in with that tree's own code. The updater resolves nothing inside the installed tree but `package.json` and that entry; `test/repository-governance/update-activation-contract.test.ts` pins this. A tree that declares no contract the updater serves is activated in-process with the layout it had, which keeps an updater older than the contract and a downgrade to an older preview working.
-`test/foundation/release/update-predecessor.integration.test.ts` is the gate for this. It installs each of the most recent published releases and drives the candidate through **that release's own** materialization and warmup, because a fixture built from the candidate would only prove the candidate agrees with itself. No reset or migration runs automatically. If disposable state blocks installation, inspect its resolved paths and obtain separate approval before removal.
+`test/foundation/release/update-predecessor.integration.test.ts` is the gate for this. It installs each of the most recent published releases and drives the candidate through **that release's own** materialization and warmup, because a fixture built from the candidate would only prove the candidate agrees with itself. On Windows it also drives the newest predecessor's protected package replacement from a user-style A1 prefix with npm beside a separate Node installation, then exercises the explicit `0.2.2` installer-context bridge. Candidate-only recovery success therefore cannot hide a target-side fix that its installed predecessor cannot reach. No reset or migration runs automatically. If disposable state blocks installation, inspect its resolved paths and obtain separate approval before removal.
 | State | Treatment |
 | --- | --- |