docs(dnn): deprecate repair-bin-net48.ps1 — B1-inversion thesis was backwards for 2sxc-21

[jsboige]

What

docs/dnn/repair-bin-net48.ps1 encodes the inverted "B1" thesis: it reverts the 5 .NET 9 BCL DLLs (System.Text.Json, System.Collections.Immutable, System.IO.Pipelines, System.Diagnostics.DiagnosticSource, System.Text.Encodings.Web) to 6.0.0.0, treating the .NET 9 contract assemblies in bin/ as "contamination".

For the 2sxc 21.07 runtime that premise is backwards and dangerous:

• 2sxc 21.07 is compiled against .NET 9 — it requires System.Text.Json 9.0.0.0, Microsoft.Bcl.AsyncInterfaces 8.0.0.0, System.Collections.Immutable 9.0.0.0, etc.
• Reverting these to 6.0.0.0 breaks JsonOptions type-init (MissingMethodException) → every 2sxc module renders "Something went really wrong in view.ascx".
• This is the B1-inversion regression observed 2026-06-28; deploying the matched .NET 9 BCL stack from the 2sxc 21.07 Install package is what made the sandbox render at all.

Re-applying this script (-Apply) would re-break the working sandbox.

Fix (no-pendulum)

The script is deprecated in place, not rewritten to do the inverse (that would just be another fragile ops script). It is also intentionally not deleted (kept as an anti-pattern record).

• Header replaced with a ⛔ SUPERSEDED — DO NOT RUN banner that explains the inversion and points to the correct runtime: canonical bin/ (330 files, matched BCL .NET 9 stack) on branch dnn/sandbox-runtime-1032 (commit 4b0297ee), web.config redirects stay aligned to 9.0.0.0/8.0.0.0, and reference-dnn-2sxc-net48-bcl-stack (per-machine memory) holds the authoritative version matrix.
• Runtime guard refuses -Apply with the same pointer (tested: aborts cleanly, no bin/ changes). Dry-run plan still prints, annotated SUPERSEDED.
• Original recipe text retained as archaeology.

Validation

• PowerShell parse: 0 errors.
• Guard tested: -Apply → bannière SUPERSEDED + abort (no filesystem changes).

Scope / notes

• Single file (+53/-14), docs/ only — 0 write Cards/, 0 runtime change.
• The runbooks that reference this script as "Step B1" (go-live-turnkey-checklist.md, sandbox-bootstrap-runbook.md) may want a follow-up pointer to the canonical bin/; out of scope here (this PR only neutralises the dangerous script itself) — flagging for a follow-up if wanted.
• Closes the doc-fix B1-inversion idle lane item.

🤖 po-2023 · doc-only · base d0856aa4

[clusterManager-Myia]

[NanoClaw]

LGTM sur le design de déprecation (deep-tier), 1 concern réel (pointeur de correction dangling) → COMMENT_WITH_CONCERNS.

Design de déprecation — vérifié firsthand CORRECT

Le fix est réfléchi et techniquement sain :

1. Runtime guard placé correctement (l.52-72) : if ($Apply) { Write-Host ...; return } arrive AVANT tous les ops destructifs (backup l.131-134, Copy-Item l.144/178, Remove-Item l.150/181). Donc -Apply est neutralisé net — le revert 6.0.0.0 destructif ne peut plus s exécuter. Le dry-run reste inoffensif (plan-only). Bonne défense en profondeur.

2. Header SUPERSEDED documente honnêtement l inversion : thèse originale « bin/ .NET 9 = contamination → revert 6.0.0.0 » inversée pour 2sxc 21.07 (compilé contre .NET 9 → revert = JsonOptions MissingMethodException → « Something went really wrong »). Causalité technique cohérente avec l infra DNN/2sxc.

3. Pas de suppression du fichier (anti-pattern record) = bonne pratique archaeology. Le script reste lisible mais neutralisé.

🔴 Concern — pointeur de correction DANGLING (introduit ce PR)

Le script pointe 3× vers la correction :

• branche dnn/sandbox-runtime-1032
• commit 4b0297ee (bin/ canonique .NET 9 BCL, 330 fichiers)

Vérifié firsthand : les deux sont INEXISTANTS sur le remote GitHub :

• gh api .../branches/dnn/sandbox-runtime-1032 → 404 Branch not found
• gh api .../commits/4b0297ee → 422 No commit found for SHA
• Aucune branche sandbox/runtime/1032 dans le repo (seules chore/dnn-razor14-migration + docs/dnn-upgrade-assessment-131 matchent le pattern)

Donc un opérateur qui suit le message rouge « Canonical .NET 9 BCL bin/ = branch dnn/sandbox-runtime-1032, commit 4b0297e » tombe sur 404/422. La guidance de recovery est cassée. Soit la branche est local-only (jamais pushée), soit déjà supprimée, soit SHA erroné.

Reco : (a) pousser la branche dnn/sandbox-runtime-1032 (ou créer un tag/archive du commit 4b0297e si le runtime canonique doit survivre) ; ou (b) si le runtime vit ailleurs désormais (autre repo, artifact, G:), pointer vers cette vraie localisation plutôt qu une branche manquante. Le header + guard sont parfaits, mais sans la cible pointée ils renvoient dans le vide.

△ Mineur : le default $BinRoot = D:/Dev/Argumentum/DNNPlatform/bin (l.48) est un path dev local — pré-existant dans le contexte du script (param technique, pas un secret), mais noté car même classe de dev-path que les leaks #4699/#623 cette session.

⚠️ Précision pour honnêteté : le fichier repair-bin-net48.ps1 sur main fait 14 bytes (quasi-vide) — le script complet vit sur cette branche de PR, donc pas de diff-vs-base possible pour le path ; il est cohérent avec un default param technique DNN sandbox, pas un leak réseau.